Qt for nto

bridged with qdn.public.qnxrtp.porting
Armin Steinhoff

Re: Qt for nto

Post by Armin Steinhoff » Mon Feb 04, 2002 11:38 am

Frank Liu wrote:
Frank Liu <liug@mama.indstate.edu> wrote:
Armin Steinhoff <a-steinhoff@web_.de> wrote:
Yes ... but that means you would loose a lot of nice Photon features ...
therefore
embedded Qt for QNX6 makes no sense for me.

that's probably why they didn't release qt/embedded for QNX.

just curious, I sent an email to trolltech and got an reply today.
qt-embedded is fully ported to qnx6!! but it is not open-sourced.
(that's probably why we didn't see it in the downloadable source).
so the discussion is over for qt/embedded :)
Well ... the existence of Qt/embedded should be a good reason for QSSL
to initiate a port of the Qt API to native Photon .... if QSSL is
interested to see Photon based embedded applications ;)

Armin


frank

Jens H Jorgensen

Re: Qt for nto

Post by Jens H Jorgensen » Mon Feb 04, 2002 6:20 pm

Our company is ready to spend some $ for QtE/QNX.

I think the cross platform compatability in Qt(E) is outstanding.
Furthermore the Qt API and Qt Designer are great. I just love the fact that
you would be able to write an application and compile it under Win32 or
under QNX
--
Jens



"Frank Liu" <liug@mama.indstate.edu> wrote in message
news:a3kqdk$nkt$1@inn.qnx.com...
Chris McKillop <cdm@qnx.com> wrote:

Given the strength of QNX, it is probably making more sense to port
Qt/Embedded than Qt/X11, besides, Qt/Embedded is a much easier port
than Qt/Photon. Since Qt/Embedded doesn't need photon or other GUI
environment, it is probably better suited for QNX/embedded.
This sounds like a competing product for photon, and I would understand
why QSSL isn't interested in such a port :)


I am not sure what happened to it, but there was a guy from Troll
hanging
out on #qnx that was doing a port of Qt/Embedded using the "direct mode"
that the devg drivers offer. I bet if someone called Troll with $$ on
the

speaking of $$, I just looked at their site for pricing.
We should probably forget about it :)
frank

table they could get it. Heck, it might even be in the current CVS
release
of Qt3 and no one has noticed.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I
get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/


Mario Charest

Re: Qt for nto

Post by Mario Charest » Mon Feb 04, 2002 8:03 pm

"Jens H Jorgensen" <remove-nospam-jhj@videk.com> wrote in message
news:a3mj2a$476$1@inn.qnx.com...
Our company is ready to spend some $ for QtE/QNX.

I think the cross platform compatability in Qt(E) is outstanding.
Furthermore the Qt API and Qt Designer are great. I just love the fact
that
you would be able to write an application and compile it under Win32 or
under QNX
Tilcon offers a product that allows application to be recompile for
various platform (QNX6, Win32) Never tried it myself.
--
Jens



"Frank Liu" <liug@mama.indstate.edu> wrote in message
news:a3kqdk$nkt$1@inn.qnx.com...

Chris McKillop <cdm@qnx.com> wrote:

Given the strength of QNX, it is probably making more sense to port
Qt/Embedded than Qt/X11, besides, Qt/Embedded is a much easier port
than Qt/Photon. Since Qt/Embedded doesn't need photon or other GUI
environment, it is probably better suited for QNX/embedded.
This sounds like a competing product for photon, and I would
understand
why QSSL isn't interested in such a port :)


I am not sure what happened to it, but there was a guy from Troll
hanging
out on #qnx that was doing a port of Qt/Embedded using the "direct
mode"
that the devg drivers offer. I bet if someone called Troll with $$ on
the

speaking of $$, I just looked at their site for pricing.
We should probably forget about it :)
frank

table they could get it. Heck, it might even be in the current CVS
release
of Qt3 and no one has noticed.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I
get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/




Jens H Jorgensen

Re: Qt for nto

Post by Jens H Jorgensen » Tue Feb 05, 2002 3:07 pm

Thanks for pointing that out.

I am going to take a look at Tilcon's GUI library but it doesn't look as
easy to do cross platform porting as Qt(E). It seems you have the
responsibility of #ifdef...#endif your way out of differences between
platforms in your own code, where as Qt wraps all the OS specifics into
their Qt classes.

--
Jens



"Mario Charest" <goto@nothingness.com> wrote in message
news:a3mp2e$84d$1@inn.qnx.com...
"Jens H Jorgensen" <remove-nospam-jhj@videk.com> wrote in message
news:a3mj2a$476$1@inn.qnx.com...
Our company is ready to spend some $ for QtE/QNX.

I think the cross platform compatability in Qt(E) is outstanding.
Furthermore the Qt API and Qt Designer are great. I just love the fact
that
you would be able to write an application and compile it under Win32 or
under QNX

Tilcon offers a product that allows application to be recompile for
various platform (QNX6, Win32) Never tried it myself.

--
Jens



"Frank Liu" <liug@mama.indstate.edu> wrote in message
news:a3kqdk$nkt$1@inn.qnx.com...

Chris McKillop <cdm@qnx.com> wrote:

Given the strength of QNX, it is probably making more sense to port
Qt/Embedded than Qt/X11, besides, Qt/Embedded is a much easier port
than Qt/Photon. Since Qt/Embedded doesn't need photon or other GUI
environment, it is probably better suited for QNX/embedded.
This sounds like a competing product for photon, and I would
understand
why QSSL isn't interested in such a port :)


I am not sure what happened to it, but there was a guy from Troll
hanging
out on #qnx that was doing a port of Qt/Embedded using the "direct
mode"
that the devg drivers offer. I bet if someone called Troll with $$
on
the

speaking of $$, I just looked at their site for pricing.
We should probably forget about it :)
frank

table they could get it. Heck, it might even be in the current CVS
release
of Qt3 and no one has noticed.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I
get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/






Armin Steinhoff

Re: Qt for nto

Post by Armin Steinhoff » Tue Feb 05, 2002 4:09 pm

Jens H Jorgensen wrote:
Thanks for pointing that out.

I am going to take a look at Tilcon's GUI library but it doesn't look as
easy to do cross platform porting as Qt(E).
It is more or less easy ... but the C++ support and object orientation
is very limited. They have a big plus in animated virtual instruments.
Qt supports all other areas of GUIs better.
It seems you have the
responsibility of #ifdef...#endif your way out of differences between
platforms in your own code, where as Qt wraps all the OS specifics into
their Qt classes.
Yes, the Qt classes are first class :)

Armin
--
Jens

"Mario Charest" <goto@nothingness.com> wrote in message
news:a3mp2e$84d$1@inn.qnx.com...

"Jens H Jorgensen" <remove-nospam-jhj@videk.com> wrote in message
news:a3mj2a$476$1@inn.qnx.com...
Our company is ready to spend some $ for QtE/QNX.

I think the cross platform compatability in Qt(E) is outstanding.
Furthermore the Qt API and Qt Designer are great. I just love the fact
that you would be able to write an application and compile it under Win32 or
under QNX

Tilcon offers a product that allows application to be recompile for
various platform (QNX6, Win32) Never tried it myself.

--
Jens



"Frank Liu" <liug@mama.indstate.edu> wrote in message
news:a3kqdk$nkt$1@inn.qnx.com...

Chris McKillop <cdm@qnx.com> wrote:

Given the strength of QNX, it is probably making more sense to port
Qt/Embedded than Qt/X11, besides, Qt/Embedded is a much easier port
than Qt/Photon. Since Qt/Embedded doesn't need photon or other GUI
environment, it is probably better suited for QNX/embedded.
This sounds like a competing product for photon, and I would
understand
why QSSL isn't interested in such a port :)


I am not sure what happened to it, but there was a guy from Troll
hanging
out on #qnx that was doing a port of Qt/Embedded using the "direct
mode"
that the devg drivers offer. I bet if someone called Troll with $$
on
the

speaking of $$, I just looked at their site for pricing.
We should probably forget about it :)
frank

table they could get it. Heck, it might even be in the current CVS
release
of Qt3 and no one has noticed.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I
get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/






Joerg Scherer

Re: Qt for nto

Post by Joerg Scherer » Tue Mar 19, 2002 5:28 pm

that's only partly true.

i saw qt/e qnx running on the embedded systems fair in nurnberg.
they had some game of live app running and could not show anything else, so
imho we can consider this an alpha stage.

from troll i received the following info:
We have a running prototype of QtE/QNX 3.0. However, at this point we

are not planning an official release unless we get significant customer

commitments.


"Frank Liu" <liug@mama.indstate.edu> schrieb im Newsbeitrag
news:a3l7i6$23m$1@inn.qnx.com...
Frank Liu <liug@mama.indstate.edu> wrote:
Armin Steinhoff <a-steinhoff@web_.de> wrote:
Yes ... but that means you would loose a lot of nice Photon features
....
therefore
embedded Qt for QNX6 makes no sense for me.

that's probably why they didn't release qt/embedded for QNX.

just curious, I sent an email to trolltech and got an reply today.
qt-embedded is fully ported to qnx6!! but it is not open-sourced.
(that's probably why we didn't see it in the downloadable source).
so the discussion is over for qt/embedded :)

frank

Jens H Jorgensen

Re: Qt for nto

Post by Jens H Jorgensen » Tue Mar 19, 2002 10:50 pm

I got the same comment regarding "significant customer commitment" before
they will officially announce QtE/QNX.

Qt/X11 does run pretty good under XFree86 4.1/4.2 for QNX and it also runs
under XPhoton.

The reason for going with QtE/QNX would be the smaller foot print when
Photon and/or X11 aren't necessary for a graphical application.

--
Jens

"Joerg Scherer" <joerg.schererNOSPAM@am3.com> wrote in message
news:a77s18$sv$1@inn.qnx.com...
that's only partly true.

i saw qt/e qnx running on the embedded systems fair in nurnberg.
they had some game of live app running and could not show anything else,
so
imho we can consider this an alpha stage.

from troll i received the following info:
We have a running prototype of QtE/QNX 3.0. However, at this point we

are not planning an official release unless we get significant customer

commitments.


"Frank Liu" <liug@mama.indstate.edu> schrieb im Newsbeitrag
news:a3l7i6$23m$1@inn.qnx.com...
Frank Liu <liug@mama.indstate.edu> wrote:
Armin Steinhoff <a-steinhoff@web_.de> wrote:
Yes ... but that means you would loose a lot of nice Photon features
...
therefore
embedded Qt for QNX6 makes no sense for me.

that's probably why they didn't release qt/embedded for QNX.

just curious, I sent an email to trolltech and got an reply today.
qt-embedded is fully ported to qnx6!! but it is not open-sourced.
(that's probably why we didn't see it in the downloadable source).
so the discussion is over for qt/embedded :)

frank


Joerg Scherer

Re: Qt for nto

Post by Joerg Scherer » Wed Mar 20, 2002 11:37 am

yes, i think that is a critical point, further:

- "pretty good" is not good enough
- who wants to carry around a networked windowing environment (X-Windows),
when she doesn't need it (slow and memory intensive)

- xphoton is nice for tools and apps on a qnx-desktop, but in a production
environment e.g. embedded target?
- the major advantage imho is directly drawing to the framebuffer, compare
qt/e to qt/x11 on linux, main purpose: avoiding X

my personal point of view:
i'm new to qnx, i used xt/motif and qt before. now i find myself programming
motif-style again, which really sucks badly if you know the beauty of qt.



Jörg

"Jens H Jorgensen" <jhj@remove-nospam-videk.com> schrieb im Newsbeitrag
news:a78et6$df6$1@inn.qnx.com...
I got the same comment regarding "significant customer commitment" before
they will officially announce QtE/QNX.

Qt/X11 does run pretty good under XFree86 4.1/4.2 for QNX and it also runs
under XPhoton.

The reason for going with QtE/QNX would be the smaller foot print when
Photon and/or X11 aren't necessary for a graphical application.

--
Jens

"Joerg Scherer" <joerg.schererNOSPAM@am3.com> wrote in message
news:a77s18$sv$1@inn.qnx.com...
that's only partly true.

i saw qt/e qnx running on the embedded systems fair in nurnberg.
they had some game of live app running and could not show anything else,
so
imho we can consider this an alpha stage.

from troll i received the following info:
We have a running prototype of QtE/QNX 3.0. However, at this point we

are not planning an official release unless we get significant customer

commitments.


"Frank Liu" <liug@mama.indstate.edu> schrieb im Newsbeitrag
news:a3l7i6$23m$1@inn.qnx.com...
Frank Liu <liug@mama.indstate.edu> wrote:
Armin Steinhoff <a-steinhoff@web_.de> wrote:
Yes ... but that means you would loose a lot of nice Photon
features
...
therefore
embedded Qt for QNX6 makes no sense for me.

that's probably why they didn't release qt/embedded for QNX.

just curious, I sent an email to trolltech and got an reply today.
qt-embedded is fully ported to qnx6!! but it is not open-sourced.
(that's probably why we didn't see it in the downloadable source).
so the discussion is over for qt/embedded :)

frank




Armin Steinhoff

Re: Qt for nto

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

Joerg Scherer wrote:
yes, i think that is a critical point, further:

- "pretty good" is not good enough
- who wants to carry around a networked windowing environment (X-Windows),
when she doesn't need it (slow and memory intensive)
Did you use XFree86 4.1 with QNX6.1 ??

My impression is it isn't slow and the memory footprint are in the range
of Photon.
- xphoton is nice for tools and apps on a qnx-desktop, but in a production
environment e.g. embedded target?
Not stable enough ..
- the major advantage imho is directly drawing to the framebuffer, compare
qt/e to qt/x11 on linux, main purpose: avoiding X

my personal point of view:
i'm new to qnx, i used xt/motif and qt before. now i find myself programming
motif-style again,
Why ? Qt works with XFree86.

Armin
which really sucks badly if you know the beauty of qt.

Jörg

"Jens H Jorgensen" <jhj@remove-nospam-videk.com> schrieb im Newsbeitrag
news:a78et6$df6$1@inn.qnx.com...
I got the same comment regarding "significant customer commitment" before
they will officially announce QtE/QNX.

Qt/X11 does run pretty good under XFree86 4.1/4.2 for QNX and it also runs
under XPhoton.

The reason for going with QtE/QNX would be the smaller foot print when
Photon and/or X11 aren't necessary for a graphical application.

--
Jens

"Joerg Scherer" <joerg.schererNOSPAM@am3.com> wrote in message
news:a77s18$sv$1@inn.qnx.com...
that's only partly true.

i saw qt/e qnx running on the embedded systems fair in nurnberg.
they had some game of live app running and could not show anything else,
so
imho we can consider this an alpha stage.

from troll i received the following info:
We have a running prototype of QtE/QNX 3.0. However, at this point we

are not planning an official release unless we get significant customer

commitments.


"Frank Liu" <liug@mama.indstate.edu> schrieb im Newsbeitrag
news:a3l7i6$23m$1@inn.qnx.com...
Frank Liu <liug@mama.indstate.edu> wrote:
Armin Steinhoff <a-steinhoff@web_.de> wrote:
Yes ... but that means you would loose a lot of nice Photon
features
...
therefore
embedded Qt for QNX6 makes no sense for me.

that's probably why they didn't release qt/embedded for QNX.

just curious, I sent an email to trolltech and got an reply today.
qt-embedded is fully ported to qnx6!! but it is not open-sourced.
(that's probably why we didn't see it in the downloadable source).
so the discussion is over for qt/embedded :)

frank




Joerg Scherer

Re: Qt for nto

Post by Joerg Scherer » Wed Mar 20, 2002 1:40 pm

- who wants to carry around a networked windowing environment
(X-Windows),
when she doesn't need it (slow and memory intensive)

Did you use XFree86 4.1 with QNX6.1 ??

no, as i mentioned new to qnx. i downloaded your port from sourceforge, but
honestly i didn't figure out how to get it up running. hint: short howto
would help big time ;-)
i'm really clueless. i think i would have to start up X instead at photon.
right?
i'm used to using X under several *nixen, which means either sysadmin has
done setting it up for me or (linux) having comfortable tools for having set
up my graphic card etc., fiddling with modlines manually scares me off,
honestly.
but maybe all this is easyly accomplished...
My impression is it isn't slow and the memory footprint are in the range
of Photon.

this is astonishing to me! i would have guessed, that photon should by
nature be faster and be far less memory extensive.
can't understand memory footprint being equal, as photon has no network
modell i think.
speed: should be a minor issue nowadays, one architekture could beat the
other by factors and it wouldn't even be recogniseable by the user. on the
other hand: this surely is true for desktop systems, but on an embedded
target, where you typically have an older 1-2mb graphic-card?
an other point could be: while photon could in principle be faster than X, i
would guess xfree drivers are *much* better optimized than qssl drivers for
photon
- the major advantage imho is directly drawing to the framebuffer,
compare
qt/e to qt/x11 on linux, main purpose: avoiding X

my personal point of view:
i'm new to qnx, i used xt/motif and qt before. now i find myself
programming
motif-style again,

Why ? Qt works with XFree86.

all this is of minor concern to me right now, we won't consider switching
for our current project, but in the future (read: next year) this could be
an option.
couldn't get x running qt didn't compile out of the box...
perhaps i should give it another try, if time permitts.

Jörg

Jens H Jorgensen

Re: Qt for nto

Post by Jens H Jorgensen » Thu Mar 21, 2002 4:50 pm

Hi Joerg

Let me know if you need some help in getting XFree86 4.2 up and running
under QNX 6.1, and can give you an example XF86Config-4 and a startx script
that will make it work.

Regarding Qt/X11 it got the QT library and the basic tools (qmake, uic...)
compiled successfully. The compile did die during compilation of the
designer, and I have simply not had the time to look at that and I only need
the library and the basic tools.

--
Jens


"Joerg Scherer" <joerg.schererNOSPAM@am3.com> wrote in message
news:a7a31m$k1n$1@inn.qnx.com...
- who wants to carry around a networked windowing environment
(X-Windows),
when she doesn't need it (slow and memory intensive)

Did you use XFree86 4.1 with QNX6.1 ??

no, as i mentioned new to qnx. i downloaded your port from sourceforge,
but
honestly i didn't figure out how to get it up running. hint: short howto
would help big time ;-)
i'm really clueless. i think i would have to start up X instead at photon.
right?
i'm used to using X under several *nixen, which means either sysadmin has
done setting it up for me or (linux) having comfortable tools for having
set
up my graphic card etc., fiddling with modlines manually scares me off,
honestly.
but maybe all this is easyly accomplished...

My impression is it isn't slow and the memory footprint are in the range
of Photon.

this is astonishing to me! i would have guessed, that photon should by
nature be faster and be far less memory extensive.
can't understand memory footprint being equal, as photon has no network
modell i think.
speed: should be a minor issue nowadays, one architekture could beat the
other by factors and it wouldn't even be recogniseable by the user. on the
other hand: this surely is true for desktop systems, but on an embedded
target, where you typically have an older 1-2mb graphic-card?
an other point could be: while photon could in principle be faster than X,
i
would guess xfree drivers are *much* better optimized than qssl drivers
for
photon

- the major advantage imho is directly drawing to the framebuffer,
compare
qt/e to qt/x11 on linux, main purpose: avoiding X

my personal point of view:
i'm new to qnx, i used xt/motif and qt before. now i find myself
programming
motif-style again,

Why ? Qt works with XFree86.

all this is of minor concern to me right now, we won't consider switching
for our current project, but in the future (read: next year) this could be
an option.
couldn't get x running qt didn't compile out of the box...
perhaps i should give it another try, if time permitts.

Jörg


Guest

Re: Qt for nto

Post by Guest » Thu Mar 21, 2002 5:00 pm

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:
Hi Joerg

Let me know if you need some help in getting XFree86 4.2 up and running
under QNX 6.1, and can give you an example XF86Config-4 and a startx script
that will make it work.
you don't need an example XF86Config-4, "XFree86 -configure" will generate
one for you, for your graphics card/monitor. You can use the resulting
config file as base, modify as needed (such as pick another color depth
as default..).
as for "startx" script, i never had a need to tweak that. the default
one should just work.

btw Joerg, all your questions should have been answered in the mailing list.
subscribe/browse the mailing list for more info.

frank

Regarding Qt/X11 it got the QT library and the basic tools (qmake, uic...)
compiled successfully. The compile did die during compilation of the
designer, and I have simply not had the time to look at that and I only need
the library and the basic tools.

--
Jens
"Joerg Scherer" <joerg.schererNOSPAM@am3.com> wrote in message
news:a7a31m$k1n$1@inn.qnx.com...

- who wants to carry around a networked windowing environment
(X-Windows),
when she doesn't need it (slow and memory intensive)

Did you use XFree86 4.1 with QNX6.1 ??

no, as i mentioned new to qnx. i downloaded your port from sourceforge,
but
honestly i didn't figure out how to get it up running. hint: short howto
would help big time ;-)
i'm really clueless. i think i would have to start up X instead at photon.
right?
i'm used to using X under several *nixen, which means either sysadmin has
done setting it up for me or (linux) having comfortable tools for having
set
up my graphic card etc., fiddling with modlines manually scares me off,
honestly.
but maybe all this is easyly accomplished...

My impression is it isn't slow and the memory footprint are in the range
of Photon.

this is astonishing to me! i would have guessed, that photon should by
nature be faster and be far less memory extensive.
can't understand memory footprint being equal, as photon has no network
modell i think.
speed: should be a minor issue nowadays, one architekture could beat the
other by factors and it wouldn't even be recogniseable by the user. on the
other hand: this surely is true for desktop systems, but on an embedded
target, where you typically have an older 1-2mb graphic-card?
an other point could be: while photon could in principle be faster than X,
i
would guess xfree drivers are *much* better optimized than qssl drivers
for
photon

- the major advantage imho is directly drawing to the framebuffer,
compare
qt/e to qt/x11 on linux, main purpose: avoiding X

my personal point of view:
i'm new to qnx, i used xt/motif and qt before. now i find myself
programming
motif-style again,

Why ? Qt works with XFree86.

all this is of minor concern to me right now, we won't consider switching
for our current project, but in the future (read: next year) this could be
an option.
couldn't get x running qt didn't compile out of the box...
perhaps i should give it another try, if time permitts.



Jens H Jorgensen

Re: Qt for nto

Post by Jens H Jorgensen » Thu Mar 21, 2002 9:51 pm

That is true that XFree86 -configure will create a XF86Config-4. That is
where my sample XF86Config-4 comes from.

As for startx - I included startup of devi-hirun so that you get your mouse
device.

--
Jens
<fliu@bb.vipstage.com> wrote in message news:a7d3ii$qqp$1@inn.qnx.com...
Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:
Hi Joerg

Let me know if you need some help in getting XFree86 4.2 up and running
under QNX 6.1, and can give you an example XF86Config-4 and a startx
script
that will make it work.

you don't need an example XF86Config-4, "XFree86 -configure" will generate
one for you, for your graphics card/monitor. You can use the resulting
config file as base, modify as needed (such as pick another color depth
as default..).
as for "startx" script, i never had a need to tweak that. the default
one should just work.

btw Joerg, all your questions should have been answered in the mailing
list.
subscribe/browse the mailing list for more info.

frank


Regarding Qt/X11 it got the QT library and the basic tools (qmake,
uic...)
compiled successfully. The compile did die during compilation of the
designer, and I have simply not had the time to look at that and I only
need
the library and the basic tools.

--
Jens


"Joerg Scherer" <joerg.schererNOSPAM@am3.com> wrote in message
news:a7a31m$k1n$1@inn.qnx.com...

- who wants to carry around a networked windowing environment
(X-Windows),
when she doesn't need it (slow and memory intensive)

Did you use XFree86 4.1 with QNX6.1 ??

no, as i mentioned new to qnx. i downloaded your port from sourceforge,
but
honestly i didn't figure out how to get it up running. hint: short
howto
would help big time ;-)
i'm really clueless. i think i would have to start up X instead at
photon.
right?
i'm used to using X under several *nixen, which means either sysadmin
has
done setting it up for me or (linux) having comfortable tools for
having
set
up my graphic card etc., fiddling with modlines manually scares me off,
honestly.
but maybe all this is easyly accomplished...

My impression is it isn't slow and the memory footprint are in the
range
of Photon.

this is astonishing to me! i would have guessed, that photon should by
nature be faster and be far less memory extensive.
can't understand memory footprint being equal, as photon has no network
modell i think.
speed: should be a minor issue nowadays, one architekture could beat
the
other by factors and it wouldn't even be recogniseable by the user. on
the
other hand: this surely is true for desktop systems, but on an embedded
target, where you typically have an older 1-2mb graphic-card?
an other point could be: while photon could in principle be faster than
X,
i
would guess xfree drivers are *much* better optimized than qssl drivers
for
photon

- the major advantage imho is directly drawing to the framebuffer,
compare
qt/e to qt/x11 on linux, main purpose: avoiding X

my personal point of view:
i'm new to qnx, i used xt/motif and qt before. now i find myself
programming
motif-style again,

Why ? Qt works with XFree86.

all this is of minor concern to me right now, we won't consider
switching
for our current project, but in the future (read: next year) this could
be
an option.
couldn't get x running qt didn't compile out of the box...
perhaps i should give it another try, if time permitts.





Guest

Re: Qt for nto

Post by Guest » Thu Mar 21, 2002 9:53 pm

Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:
As for startx - I included startup of devi-hirun so that you get your mouse
device.
I don't know where is a good place to put devi-hirun other than running
it manually. putting in startx is probably not a good idea because
re-startx will cause multiple copies, unless you automatically kill
devi-hirun after you stop X. things are getting complicated, so
I just do devi-hirun manually once. or kill/restart it if you ever
go to photon once.

frank

Joerg Scherer

Re: Qt for nto

Post by Joerg Scherer » Fri Mar 22, 2002 11:12 am

thanks for your help to everybody!

i wasn't aware, that qnx configuration is included in vanilla xfree4.2
sources.

seems to compile flawlessly out of the box, which it does right now, so i'll
see you in a few hours ;-)



best regards

Jörg

<fliu@bb.vipstage.com> schrieb im Newsbeitrag
news:a7d3ii$qqp$1@inn.qnx.com...
Jens H Jorgensen <jhj@remove-nospam-videk.com> wrote:
Hi Joerg

Let me know if you need some help in getting XFree86 4.2 up and running
under QNX 6.1, and can give you an example XF86Config-4 and a startx
script
that will make it work.

you don't need an example XF86Config-4, "XFree86 -configure" will generate
one for you, for your graphics card/monitor. You can use the resulting
config file as base, modify as needed (such as pick another color depth
as default..).
as for "startx" script, i never had a need to tweak that. the default
one should just work.

btw Joerg, all your questions should have been answered in the mailing
list.
subscribe/browse the mailing list for more info.

frank


Regarding Qt/X11 it got the QT library and the basic tools (qmake,
uic...)
compiled successfully. The compile did die during compilation of the
designer, and I have simply not had the time to look at that and I only
need
the library and the basic tools.

--
Jens


"Joerg Scherer" <joerg.schererNOSPAM@am3.com> wrote in message
news:a7a31m$k1n$1@inn.qnx.com...

- who wants to carry around a networked windowing environment
(X-Windows),
when she doesn't need it (slow and memory intensive)

Did you use XFree86 4.1 with QNX6.1 ??

no, as i mentioned new to qnx. i downloaded your port from sourceforge,
but
honestly i didn't figure out how to get it up running. hint: short
howto
would help big time ;-)
i'm really clueless. i think i would have to start up X instead at
photon.
right?
i'm used to using X under several *nixen, which means either sysadmin
has
done setting it up for me or (linux) having comfortable tools for
having
set
up my graphic card etc., fiddling with modlines manually scares me off,
honestly.
but maybe all this is easyly accomplished...

My impression is it isn't slow and the memory footprint are in the
range
of Photon.

this is astonishing to me! i would have guessed, that photon should by
nature be faster and be far less memory extensive.
can't understand memory footprint being equal, as photon has no network
modell i think.
speed: should be a minor issue nowadays, one architekture could beat
the
other by factors and it wouldn't even be recogniseable by the user. on
the
other hand: this surely is true for desktop systems, but on an embedded
target, where you typically have an older 1-2mb graphic-card?
an other point could be: while photon could in principle be faster than
X,
i
would guess xfree drivers are *much* better optimized than qssl drivers
for
photon

- the major advantage imho is directly drawing to the framebuffer,
compare
qt/e to qt/x11 on linux, main purpose: avoiding X

my personal point of view:
i'm new to qnx, i used xt/motif and qt before. now i find myself
programming
motif-style again,

Why ? Qt works with XFree86.

all this is of minor concern to me right now, we won't consider
switching
for our current project, but in the future (read: next year) this could
be
an option.
couldn't get x running qt didn't compile out of the box...
perhaps i should give it another try, if time permitts.





Post Reply

Return to “qdn.public.qnxrtp.porting”