Experiences with VxWorks compared to QNX

bridged with qdn.public.qnxrtp.advocacy
Armin Steinhoff

Re: Tool Chain

Post by Armin Steinhoff » Mon Mar 18, 2002 10:33 am

Igor Kovalenko wrote:
"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C934D39.6F12F128@web_.de...


Igor Kovalenko wrote:

"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C924A3D.D85242D7@web_.de...


...
Interesting ... so it isn't a threat against Photon :). Or ?


It might be a threat to Photon native API but not for Photon itself
since
the engine and widget library are provided by Photon.

Oh, what a nice statement .. especially from you :)

OK, then tell me why e.g. wxWindows and Qt could be a thread to Photon
when SWT is acceptable ??

SWT maps Java classes into Photon widgets. Qt (last time I checked) has
hardware abstraction layer
No, this was only true for the ealier versions of Qt .... I'm talking
about the classic X11 based Qt version. The Xlib isn't a hardware
abstraction layer ...
with their own drawing primitives. That means
they have their own widgets and map only low level drawing primitives. The
result is okay wrt speed, but it looks 'alien' in the environment.
I'm not convienced ... a XPhoton application e.g doesn't look 'alien' in
Photon.
And it
would not provide integration with other applications, like drag and drop
(not without additional work). What you get is essentialy another
environment, which only shares graphics drivers and Photon engine, just like
Xphoton.
Whay not only sharing graphics drivers and the Photon engine if I get
back a nice object oriented GUI API and an itegration into Photon like
XPhoton??
I don't know what is situation with wxWindows, did not look into their
code.
I heard that the first steps of a port should not be very complicate ...
Would be nice if the SWT/Photon interface could also be used for other
languages like Phython. (Jython should work with it ..)

Is the SWT implementation freely available for XFree86 ??


Not sure, but I'd think so.

[ clip ..]
Is SWT in any way compatible to SWING ??


Compatible? What that would mean? There is no integration between them,
So SWT is a proprietary niche of IBM ... no 'write once ... run
everywhere' !

Armin

Rennie Allen

Re: Tool Chain

Post by Rennie Allen » Mon Mar 18, 2002 4:23 pm

Armin Steinhoff wrote:

I'm not convienced ... a XPhoton application e.g doesn't look 'alien' in
Photon.
Huh ? Beside the fact that the user interface looks completely
different, and cut & paste doesn't work between native Photon apps and
Xphoton apps ;-)

Armin Steinhoff

Re: Tool Chain

Post by Armin Steinhoff » Mon Mar 18, 2002 7:50 pm

Rennie Allen wrote:
Armin Steinhoff wrote:


I'm not convienced ... a XPhoton application e.g doesn't look 'alien' in
Photon.

Huh ? Beside the fact that the user interface looks completely
different, and cut & paste doesn't work between native Photon apps and
Xphoton apps ;-)
Ok ... then try to use cut & paste for Voyager :)

Andrew Sandstrom

Re: Tool Chain

Post by Andrew Sandstrom » Mon Mar 18, 2002 7:51 pm

On Mon, 18 Mar 2002 11:33:31 +0100, Armin Steinhoff
<a-steinhoff@web_.de> wrote:

So SWT is a proprietary niche of IBM ... no 'write once ... run
everywhere' !

Armin
Ummm, what? Swing is necessary for WORA? Must be pain for all of the
cell phone developers then.

I think even Sun has realized WORA is not absolute. At ESC last year
they were talking about WOCRAC (Write Once Carefully Run Anywhere
Conditionally).

Anyway, it also depends on where you draw the WORA line. I can run an
SWT app on Photon, Motif, win32, winCE, Qt/e. GTK and Mac OS ports are
coming.

Plus, SWT is currently open source/CPL on www.eclipse.org, and I have
heard IBM intends to run SWT through JCP. Not proprietary.

-Andrew

Ian Zagorskih

Re: Tool Chain

Post by Ian Zagorskih » Tue Mar 19, 2002 5:55 am

"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C9644F2.F7C62C03@web_.de...

Rennie Allen wrote:

Armin Steinhoff wrote:


I'm not convienced ... a XPhoton application e.g doesn't look 'alien'
in
Photon.

Huh ? Beside the fact that the user interface looks completely
different, and cut & paste doesn't work between native Photon apps and
Xphoton apps ;-)

Ok ... then try to use cut & paste for Voyager :)
Ctrl-Alt-C / Ctrl-Alt-V. Works fine ? :)

// wbr

Armin Steinhoff

Re: Tool Chain

Post by Armin Steinhoff » Tue Mar 19, 2002 3:42 pm

Andrew Sandstrom wrote:
On Mon, 18 Mar 2002 11:33:31 +0100, Armin Steinhoff
a-steinhoff@web_.de> wrote:



So SWT is a proprietary niche of IBM ... no 'write once ... run
everywhere' !

Armin

Ummm, what? Swing is necessary for WORA? Must be pain for all of the
cell phone developers then.

I think even Sun has realized WORA is not absolute. At ESC last year
they were talking about WOCRAC (Write Once Carefully Run Anywhere
Conditionally).
The name would be better WOCRAP ... Write Once Carefully Run Anywhere
Possibly :)
Anyway, it also depends on where you draw the WORA line. I can run an
SWT app on Photon, Motif, win32, winCE, Qt/e. GTK and Mac OS ports are
coming.

Plus, SWT is currently open source/CPL on www.eclipse.org, and I have
heard IBM intends to run SWT through JCP. Not proprietary.
.. any precise URL ??


Armin

-Andrew

Armin Steinhoff

Re: Tool Chain

Post by Armin Steinhoff » Tue Mar 19, 2002 3:43 pm

Ian Zagorskih wrote:
"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C9644F2.F7C62C03@web_.de...


Rennie Allen wrote:

Armin Steinhoff wrote:


I'm not convienced ... a XPhoton application e.g doesn't look 'alien'
in
Photon.

Huh ? Beside the fact that the user interface looks completely
different, and cut & paste doesn't work between native Photon apps and
Xphoton apps ;-)

Ok ... then try to use cut & paste for Voyager :)

Ctrl-Alt-C / Ctrl-Alt-V. Works fine ? :)
As a mouse guy ... I use only the right mouse button :)

Armin

Ian Zagorskih

Re: Tool Chain

Post by Ian Zagorskih » Tue Mar 19, 2002 3:50 pm

"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C975CBF.233322DE@web_.de...

Ian Zagorskih wrote:

"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C9644F2.F7C62C03@web_.de...

Ok ... then try to use cut & paste for Voyager :)

Ctrl-Alt-C / Ctrl-Alt-V. Works fine ? :)

As a mouse guy ... I use only the right mouse button :)
Specially for mouse guys: select from menu Edit->Copy & Edit->Paste.
If you have at least one button on your mouse it should work fine :)

// wbr

Igor Kovalenko

Re: Tool Chain

Post by Igor Kovalenko » Tue Mar 19, 2002 6:24 pm

"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C95C27B.486A9785@web_.de...
SWT maps Java classes into Photon widgets. Qt (last time I checked) has
hardware abstraction layer

No, this was only true for the ealier versions of Qt .... I'm talking
about the classic X11 based Qt version. The Xlib isn't a hardware
abstraction layer ...
The Xlib is not, but I never said that, so don't read between the lines ;)
Qt has its own set of basic drawing primitives (which could be threated as
'abstraction layer') and it is implemented using either Xlib or Win32. It
also covers other OS-specific issues, such as dealing with timers.
with their own drawing primitives. That means
they have their own widgets and map only low level drawing primitives.
The
result is okay wrt speed, but it looks 'alien' in the environment.

I'm not convienced ... a XPhoton application e.g doesn't look 'alien' in
Photon.
Then we have different definitions of 'alien'.
And it
would not provide integration with other applications, like drag and
drop
(not without additional work). What you get is essentialy another
environment, which only shares graphics drivers and Photon engine, just
like
Xphoton.

Whay not only sharing graphics drivers and the Photon engine if I get
back a nice object oriented GUI API and an itegration into Photon like
XPhoton??
If integration was better, maybe. Also, Photon widget set is officially
released/supported product with development budget and manpower behind it.
Using Qt you're throwing that away in favor of another toolkit which is not
supported neither by QNX nor by Trolls (on QNX). That might be just fine for
individual developers but probably won't look all that attractive to
management people at bigger corporations.

Besides, if I know anything about the world, Java is more popular/accepted
than Qt. How the saying goes, 'only big ship makes big waves', so how ever
nice Qt might be, waves made by Sun are bigger than those made by Trolls.
So SWT is a proprietary niche of IBM ... no 'write once ... run
everywhere' !
And how Qt is better in that area?

-- igor

Andrew Sandstrom

Re: Tool Chain

Post by Andrew Sandstrom » Tue Mar 19, 2002 7:47 pm

On Tue, 19 Mar 2002 16:42:20 +0100, Armin Steinhoff
<a-steinhoff@web_.de> wrote:
The name would be better WOCRAP ... Write Once Carefully Run Anywhere
Possibly :)
heh, I like that ;-)

Plus, SWT is currently open source/CPL on www.eclipse.org, and I have
heard IBM intends to run SWT through JCP. Not proprietary.

.. any precise URL ??


On SWT to JCP? No, I found the following article, which may be where I
got the "heard IBM intends to run through JCP" bit intially.

http://www.esj.com/Columns/article.asp?EditorialsID=16

Nothing official though. You can check www.eclipse.org. There is also
a newsgroup for Eclipse.

-Andrew

Armin Steinhoff

Re: Tool Chain

Post by Armin Steinhoff » Tue Mar 19, 2002 9:27 pm

Igor Kovalenko wrote:
"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C95C27B.486A9785@web_.de...

SWT maps Java classes into Photon widgets. Qt (last time I checked) has
hardware abstraction layer

No, this was only true for the ealier versions of Qt .... I'm talking
about the classic X11 based Qt version. The Xlib isn't a hardware
abstraction layer ...

The Xlib is not, but I never said that, so don't read between the lines ;)
Qt has its own set of basic drawing primitives (which could be threated as
'abstraction layer') and it is implemented using either Xlib or Win32.
... and why should it not work on top of Photon primitives ??
Xlib and Win32 are very different.
It also covers other OS-specific issues, such as dealing with timers.
*unix and M$windows timers are also very different ... but QNX und *nix
are not.

[ clip ..]
If integration was better, maybe. Also, Photon widget set is officially
released/supported product with development budget and manpower behind it.
Using Qt you're throwing that away in favor of another toolkit which is not
supported neither by QNX nor by Trolls (on QNX).
It could also be a commercial product from Troll ... why not?
That might be just fine for
individual developers but probably won't look all that attractive to
management people at bigger corporations.

Besides, if I know anything about the world, Java is more popular/accepted
than Qt.
You can't compare Qt with Java.
How the saying goes, 'only big ship makes big waves', so how ever
nice Qt might be, waves made by Sun are bigger than those made by Trolls.
Then let's use Windows CE 3.0 :)
So SWT is a proprietary niche of IBM ... no 'write once ... run
everywhere' !

And how Qt is better in that area?
Better performance, better widgets classes ... portable.

Armin

Igor Kovalenko

Re: Tool Chain

Post by Igor Kovalenko » Wed Mar 20, 2002 3:18 am

"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C97AD3F.1B42C525@web_.de...
The Xlib is not, but I never said that, so don't read between the lines
;)
Qt has its own set of basic drawing primitives (which could be threated
as
'abstraction layer') and it is implemented using either Xlib or Win32.

... and why should it not work on top of Photon primitives ??
Xlib and Win32 are very different.
When did I say it should not? Reading between the lines again? Yes, it would
work , but there's would be difference between SWT and Qt. SWT maps Java
classes into *Photon widgets*, but Qt would map Qt drawing primitives into
Photon drawing primitives, to implement *Qt widgets* (rather than use Photon
widgets).

That translates into lot of compatibility and support issues, not to mention
different 'look and feel'. If grag'n'drop for example is implemented on
widget level, you won't be able to use it between Qt and Photon apps.
It also covers other OS-specific issues, such as dealing with timers.

*unix and M$windows timers are also very different ... but QNX und *nix
are not.
LOL. For most Unix users '*unix' timer would be System V timers, which are
*very* different from POSIX timers, used by QNX. You can use POSIX timers on
some Unixes, but that often requires obscure compiler flags and extra
libraries.
It could also be a commercial product from Troll ... why not?
Of course of could. However that still is not the case, which should mean
Troll does not see a lot of market to justify efforts.
Better performance, better widgets classes ... portable.
Better performance, perhaps, but SWT has very decent performance. Better
widget classes, highly doubtful. And Qt is less portable than SWT already.

- igor

Armin Steinhoff

Re: Tool Chain

Post by Armin Steinhoff » Wed Mar 20, 2002 12:20 pm

Igor Kovalenko wrote:
"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C97AD3F.1B42C525@web_.de...

The Xlib is not, but I never said that, so don't read between the lines
;)
Qt has its own set of basic drawing primitives (which could be threated
as
'abstraction layer') and it is implemented using either Xlib or Win32.

... and why should it not work on top of Photon primitives ??
Xlib and Win32 are very different.


When did I say it should not? Reading between the lines again? Yes, it would
work , but there's would be difference between SWT and Qt.
I didn't compare SWT and Qt .. that's off topic.
Did YOU reading between the lines again :)
SWT maps Java
classes into *Photon widgets*, but Qt would map Qt drawing primitives into
Photon drawing primitives, to implement *Qt widgets* (rather than use Photon
widgets).
Yes, indeed the object oriented widgets of Qt are very different to the
Photon widgets.

BUT ... the Qt widgets are used widely in the LINUX area !
And ... who is really using Photon widgets ???
That translates into lot of compatibility and support issues, not to mention
different 'look and feel'. If grag'n'drop for example is implemented on
widget level, you won't be able to use it between Qt and Photon apps.
Yes , could be a disadvantage ... but the advantage to have an excelent
portability of LINUX/Qt applications is much more important.
It also covers other OS-specific issues, such as dealing with timers.

*unix and M$windows timers are also very different ... but QNX und *nix
are not.


LOL. For most Unix users '*unix' timer would be System V timers, which are
*very* different from POSIX timers, used by QNX. You can use POSIX timers on
some Unixes, but that often requires obscure compiler flags and extra
libraries.
When I talk about UNIX ... then I don't talk about old legacy Solaris
versions :)

The timer handling defined by the 'Single UNIX Specification' is not
different to the QNX version. *LOL* ?

( http://www.opengroup.org/onlinepubs/790 ... reate.html)
It could also be a commercial product from Troll ... why not?


Of course of could. However that still is not the case, which should mean
Troll does not see a lot of market to justify efforts.


Better performance, better widgets classes ... portable.


Better performance, perhaps, but SWT has very decent performance. Better
widget classes, highly doubtful. And Qt is less portable than SWT already.
Oh yes ... SWT seems to be a very interessting system indepentend GUI
API.


Armin

Igor Kovalenko

Re: Tool Chain

Post by Igor Kovalenko » Thu Mar 21, 2002 4:46 am

"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C987E84.7F8A0630@web_.de...
BUT ... the Qt widgets are used widely in the LINUX area !
And ... who is really using Photon widgets ???
I understand, their customers do. QNX has many odd habits, but developing
something that nobody uses is not one of them.
That translates into lot of compatibility and support issues, not to
mention
different 'look and feel'. If grag'n'drop for example is implemented on
widget level, you won't be able to use it between Qt and Photon apps.

Yes , could be a disadvantage ... but the advantage to have an excelent
portability of LINUX/Qt applications is much more important.
Embedded market is not really about portability. Industrial automation
market might be different story, but most of their customers is in embedded.
When I talk about UNIX ... then I don't talk about old legacy Solaris
versions :)

The timer handling defined by the 'Single UNIX Specification' is not
different to the QNX version. *LOL* ?

( http://www.opengroup.org/onlinepubs/790 ... reate.html)
SingleUNIX spec is superset of POSIX, Spec1170, SVID and X/Open. It is
supposed to obsolete them all. So yes, there are POSIX timers in single Unix
spec. However there are no implementations of that spec yet.

By the way Solaris happens to have one of most advanced kernels among all
Unixes. I could argue that it might be the best of them all, but that's off
topic. I don't see why would you call it 'old legacy', other than for lack
of knowledge. It is certainly superior to Linux and BSD (as far as kernel
design goes, at least).

-- igor

Armin Steinhoff

Re: Tool Chain

Post by Armin Steinhoff » Thu Mar 21, 2002 6:19 pm

Igor Kovalenko wrote:
"Armin Steinhoff" <a-steinhoff@web_.de> wrote in message
news:3C987E84.7F8A0630@web_.de...

BUT ... the Qt widgets are used widely in the LINUX area !
And ... who is really using Photon widgets ???


I understand, their customers do. QNX has many odd habits, but developing
something that nobody uses is not one of them.
I didn't say that.
That translates into lot of compatibility and support issues, not to
mention
different 'look and feel'. If grag'n'drop for example is implemented on
widget level, you won't be able to use it between Qt and Photon apps.

Yes , could be a disadvantage ... but the advantage to have an excelent
portability of LINUX/Qt applications is much more important.

Embedded market is not really about portability. Industrial automation
market might be different story, but most of their customers is in embedded.
Most of their customers are not in the embedded market (of small
devices).

As Alec Saunders mentioned -> the lion share of the QSSL revenues comes
not from embedded systems; the embedded market is shrinking and is very
riscy.

So I believe the majority are not building very small GUI applications
.... but they need tools and APIs for very efficient application
development.

Armin

Post Reply

Return to “qdn.public.qnxrtp.advocacy”