Hello,
just a thought … since there is a QT embedded - that means Qt isn’t
completely bound to X - could it be possible to port Qt to a lower layer
interface of Photon?
Such a port could solve a lot of porting and compatibility problems …
Armin
Oh, oh, let me…
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A6072B1.7CF7C9D9@web_.de…
Hello,
just a thought … since there is a QT embedded - that means Qt isn’t
completely bound to X - could it be possible to port Qt to a lower layer
interface of Photon?
Under the guise of a good idea…
Such a port could solve a lot of porting and compatibility problems …
… still complaining
Armin
qt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;
Go on, say something positive armin, it won’t hurt… 
“me” <a@b.c> wrote in message news:93qb81$7et$1@inn.qnx.com…
qt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;
If Xphoton wheren’t so buggy I think the “Experimental support only!”
comment wouldn’t be there.
Mats
me wrote:
Oh, oh, let me…
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A6072B1.7CF7C9D9@web_.de…Hello,
just a thought … since there is a QT embedded - that means Qt isn’t
completely bound to X - could it be possible to port Qt to a lower layer
interface of Photon?Under the guise of a good idea…
Such a port could solve a lot of porting and compatibility problems …… still complaining
Arminqt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;Go on, say something positive armin, it won’t hurt… >
Oh yes … the statement “- Experimental support only!” seems to be
related to the great experiment Xphoton. Qt works under XFree86 - as
far as I can see - flawless !
Isn’t it positive
Armin
“me” <a@b.c> wrote in message news:93qb81$7et$1@inn.qnx.com…
Oh, oh, let me…
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A6072B1.7CF7C9D9@web_.de…Hello,
just a thought … since there is a QT embedded - that means Qt isn’t
completely bound to X - could it be possible to port Qt to a lower layer
interface of Photon?Under the guise of a good idea…
Such a port could solve a lot of porting and compatibility problems …… still complaining
Arminqt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;Go on, say something positive armin, it won’t hurt… >
It would not hurt either to understand what he said before commenting. Armin
wanted a Qt built directly on top of Photon, instead of Xlib. In the same
way as it is ported to Win32.
It is doable since Qt is written in a portable manner. And indeed would
provide great benefits. A very large number of Qt/KDE applications would be
immediately ‘Photonized’ and besides we’d get a real good C++ API for Photon
along with tools.
I thought about that many times but never had time to do it. It would be
total rewrite of low level interface, some 10,000 lines of code. And good
knowledge of both Xlib and Photon is required.
- igor
“Mats Byggmastar” <mats.byggmastar@mulfi.NOJUNK.fi> wrote in message
news:93qcr4$8ek$1@inn.qnx.com…
“me” <> a@b.c> > wrote in message news:93qb81$7et$> 1@inn.qnx.com> …
qt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;If Xphoton wheren’t so buggy I think the “Experimental support only!”
comment wouldn’t be there.
I’m getting lots of comments
Embedded qt doesn’t use X, so I don’t understand your response.
My guess is experimental means someone just started working on it…
Igor Kovalenko wrote:
“me” <> a@b.c> > wrote in message news:93qb81$7et$> 1@inn.qnx.com> …
Oh, oh, let me…“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A6072B1.7CF7C9D9@web_.de…Hello,
just a thought … since there is a QT embedded - that means Qt isn’t
completely bound to X - could it be possible to port Qt to a lower layer
interface of Photon?Under the guise of a good idea…
Such a port could solve a lot of porting and compatibility problems …… still complaining
Arminqt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;Go on, say something positive armin, it won’t hurt… >
It would not hurt either to understand what he said before commenting.
Huh … who didn’t understand what ?
Armin wanted a Qt built directly on top of Photon, instead of Xlib.
NO … not instead, I mean ‘additionally’.
Why do you misinterpret me in that way??
In the same way as it is ported to Win32.
It is doable since Qt is written in a portable manner. And indeed would
provide great benefits. A very large number of Qt/KDE applications would be
immediately ‘Photonized’ and besides we’d get a real good C++ API for Photon
along with tools.I thought about that many times but never had time to do it.
Interesting … how could you do that?
Do you have access to internal Photon sources from QSSL???
It would be total rewrite of low level interface, some 10,000 lines of code.
I’m not convienced about a ‘total’ rewrite …
And good knowledge of both Xlib
Qt/Embedded doesn’t have a close relationship to X.
and Photon is required.
That’s absolutely true … and I believe that knowledge is only
available at QSSL.
Armin
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A60D7F3.192D50C@web_.de…
Igor Kovalenko wrote:
“me” <> a@b.c> > wrote in message news:93qb81$7et$> 1@inn.qnx.com> …
Oh, oh, let me…“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A6072B1.7CF7C9D9@web_.de…Hello,
just a thought … since there is a QT embedded - that means Qt
isn’t
completely bound to X - could it be possible to port Qt to a lower
layer
interface of Photon?Under the guise of a good idea…
Such a port could solve a lot of porting and compatibility problems
…… still complaining
Arminqt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;Go on, say something positive armin, it won’t hurt… >
It would not hurt either to understand what he said before commenting.Huh … who didn’t understand what ?
Armin wanted a Qt built directly on top of Photon, instead of Xlib.
NO … not instead, I mean ‘additionally’.
Why do you misinterpret me in that way??
You’re in luck, qt embedded does not use X or Photon
[snip]
Igor,
I thought about that many times but never had time to do it. It would be
total rewrite of low level interface, some 10,000 lines of code. And good
knowledge of both Xlib and Photon is required.
You could port the Windows version which, IMO, requires substantially less
work. (Certainly much less that 10K lines.) Unfortunately the Windows
version of QT does not offer a public license so it would require support
from TT.
I assume that the porter had some knowledge of the Windows API of course.
]{ristoph
Armin,
Interesting … how could you do that?
Do you have access to internal Photon sources from QSSL???
Errr … why would you need those? Do you suppose that TT had access to
source of the Windows API when they did that port?
]{ristoph
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A60D7F3.192D50C@web_.de…
It would not hurt either to understand what he said before commenting.
Huh … who didn’t understand what ?
Armin wanted a Qt built directly on top of Photon, instead of Xlib.
NO … not instead, I mean ‘additionally’.
Why do you misinterpret me in that way??
I’m starting to wonder if you understand what you’re saying yourself…
There are 2 versions of Qt - one is built on Xlib, another on Win32. There
could be yet another one, built on Photon Pg/Ph libs. But since you mean
something else, could you give us some insight on your concept of using
Photon ‘additionally’ ? I have hard time grasping the idea…
In the same way as it is ported to Win32.
It is doable since Qt is written in a portable manner. And indeed would
provide great benefits. A very large number of Qt/KDE applications would
be
immediately ‘Photonized’ and besides we’d get a real good C++ API for
Photon
along with tools.I thought about that many times but never had time to do it.
Interesting … how could you do that?
Do you have access to internal Photon sources from QSSL???
What do I need them for?
It would be total rewrite of low level interface, some 10,000 lines of
code.I’m not convienced about a ‘total’ rewrite …
You’d have to reconstruct all Qt widgets using Photon Pg/Ph libs instead of
Xlibs.
And good knowledge of both Xlib
Qt/Embedded doesn’t have a close relationship to X.
‘Qt Embedded’ is NOT just a widget toolkit, like Qt. It is yet another
complete windowing system.
It works by accessing Linux framebuffer directly. Does not that tell you
anything? It can’t coexist with either X or Photon. Even assuming that it is
ported, it would be unaccelerated. To use hardware acceleration it would
need board-specific drivers, just like Photon and X do. Anyone is up to
write them?
Note also, that all advantages over X which are mentioned in the FAQ are
also available in Photon.
- igor
“]{ristoph” <news2@kristoph.net> wrote in message
news:93qm5u$dg4$1@inn.qnx.com…
Igor,
I thought about that many times but never had time to do it. It would be
total rewrite of low level interface, some 10,000 lines of code. And
good
knowledge of both Xlib and Photon is required.You could port the Windows version which, IMO, requires substantially less
work. (Certainly much less that 10K lines.) Unfortunately the Windows
version of QT does not offer a public license so it would require support
from TT.
I’ve never seen Windows Qt sources.
- igor
“]{ristoph” wrote:
Armin,
Interesting … how could you do that?
Do you have access to internal Photon sources from QSSL???Errr … why would you need those?
The base idea was to use the same interface as used for the
implementation of the API of Photon. On the other hand … I heard
that the API of Photon 2.0 is much more powerful than the API of the
version 1.14 … so everyone could port Qt/Embedded on top of the
Photon API with probably good results.
Armin
“me” <a@b.c> wrote in message news:93qjrj$c6t$1@inn.qnx.com…
“Mats Byggmastar” <> mats.byggmastar@mulfi.NOJUNK.fi> > wrote in message
news:93qcr4$8ek$> 1@inn.qnx.com> …“me” <> a@b.c> > wrote in message news:93qb81$7et$> 1@inn.qnx.com> …
qt-2.2.3/configure
438 QNX:*)
439 #PLATFORM=qnx-g++
440 MODULES=echo $MODULES | sed -e 's/opengl//'
441 OPENGL=no
442 PLATFORM=qnx-rtp-g++
443 PLATFORM_NOTES="
444 - Experimental support only!
445 "
446 ;;If Xphoton wheren’t so buggy I think the “Experimental support only!”
comment wouldn’t be there.I’m getting lots of comments >
Embedded qt doesn’t use X, so I don’t understand your response.
Embeddedn Qt goes directly to the Linux framebuffer.
Qt for RTP uses X.
My guess is experimental means someone just started working on it…
I think your guess is correct.
However, if Xphoton ran OK, Qt would just have worked…
Mats
Igor Kovalenko wrote:
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A60D7F3.192D50C@web_.de…It would not hurt either to understand what he said before commenting.
Huh … who didn’t understand what ?
Armin wanted a Qt built directly on top of Photon, instead of Xlib.
NO … not instead, I mean ‘additionally’.
Why do you misinterpret me in that way??
I’m starting to wonder if you understand what you’re saying yourself…
Come on Igor … what a ridiculous statement !
There are 2 versions of Qt - one is built on Xlib, another on Win32.
Wrong … try to use your browser and visit http://www.trolltech.com
There are at least three versions of Qt.
There could be yet another one, built on Photon Pg/Ph libs. But since you mean
something else, could you give us some insight on your concept of using
Photon ‘additionally’ ?
I would implement the QT/Embedded lib using the same interface which
is used for the implementation of the Photon API … and not on top
of something else! That means we will get an ‘additional’ API, not
an API wich will replace anything.
I have hard time grasping the idea…
Seems to be your 'special` problem!
[ … ]
Do you have access to internal Photon sources from QSSL???
What do I need them for?
See above …
It would be total rewrite of low level interface, some 10,000 lines of
code.I’m not convienced about a ‘total’ rewrite …
You’d have to reconstruct all Qt widgets using Photon Pg/Ph libs instead of
Xlibs.
As posted several times in this thread … Qt/Embedded has NOTHING
to do with X !!
Qt/Embedded doesn’t have a close relationship to X.
‘Qt Embedded’ is NOT just a widget toolkit, like Qt. It is yet another
complete windowing system.
Do you are talking to yourself ??
It works by accessing Linux framebuffer directly. Does not that tell you
anything?
Yes … it tells me that you are not imformed about Qt/Embedded.
Qt/Embedded is portable and can be ported in order to use any frame
buffer.
It can’t coexist with either X or Photon.
Why? Could it be that you have just the wrong idea??
Even assuming that it is ported, it would be unaccelerated.
Nope … why should it be unaccelerated when it simply uses the
Photon drivers?
Note also, that all advantages over X which are mentioned in the FAQ are
also available in Photon.
What you are talking about?
Armin
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A617C00.36C4D0A9@web_.de…
Igor Kovalenko wrote:
It can’t coexist with either X or Photon.
Why? Could it be that you have just the wrong idea??
This could be really cool, see below
Even assuming that it is ported, it would be unaccelerated.
Nope … why should it be unaccelerated when it simply uses the
Photon drivers?
Let me see if I’ve got this right (I’m sure I’ll be told if not
Use the Photon graphics ddk to get the accelerated interface to the drivers.
Port qt embedded to this interface and have it talk directly to the driver.
(no Photon)
Exercize for the student,
1 - Make it coexist with Photon the same way Quake3 does.
2 - Getting qt apps to display inside Photon.
you got it right 
me wrote:
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A617C00.36C4D0A9@web_.de…
Igor Kovalenko wrote:It can’t coexist with either X or Photon.
Why? Could it be that you have just the wrong idea??
This could be really cool, see below
Even assuming that it is ported, it would be unaccelerated.Nope … why should it be unaccelerated when it simply uses the
Photon drivers?
Let me see if I’ve got this right (I’m sure I’ll be told if not >
Use the Photon graphics ddk to get the accelerated interface to the drivers.
Port qt embedded to this interface and have it talk directly to the driver.
(no Photon)Exercize for the student,
1 - Make it coexist with Photon the same way Quake3 does.
2 - Getting qt apps to display inside Photon.
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A61DB7B.B8C570EE@web_.de…
you got it right >
Armin, I sure need an interpreter to understand you. If that’s what you
meant, see below…
me wrote:
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A617C00.36C4D0A9@web_.de…
Igor Kovalenko wrote:It can’t coexist with either X or Photon.
Why? Could it be that you have just the wrong idea??
This could be really cool, see below
Even assuming that it is ported, it would be unaccelerated.Nope … why should it be unaccelerated when it simply uses the
Photon drivers?
Let me see if I’ve got this right (I’m sure I’ll be told if not >
Use the Photon graphics ddk to get the accelerated interface to the
drivers.
The ddk allows you to write your own drivers. You’re going to port a widget
toolkit by replacing its own low-level library (the one using framebuffer)
with your library (interfacing existing Photon drivers).
What do you need DDK for? Why not just use Pg library which is a direct
interface to Photon drivers?
Port qt embedded to this interface and have it talk directly to the
driver.
(no Photon)
I see. The term ‘Photon’ is vague. Apparently you mean ‘Photon server’ by
‘Photon’. Some people might assume ‘Photon’ is the whole thing, including
drivers.
You could do that. However, if you ignore Photon, you essentially get
another graphics context, like Glide. You would not be able to play nicely
within Photon environment since there would be no support of regions and
Photon events.
From users’ perspective that is not much better that using Xfree86+Qt. What
you’d get is another windowing system which would work like Quake in
fullscreen mode. It would have its own windows and window manager and
everything else within that full-screen session. Not really what users want.
Exercize for the student,
1 - Make it coexist with Photon the same way Quake3 does.
That’s easy part. But only up to this point.
2 - Getting qt apps to display inside Photon.
To do that you’d have to integrate it with Photon by using regions to create
windows and Photon events to interact with the rest of system. When that is
done you’d realize that what you’re doing is the same thing as porting
‘classic’ Qt.
The Qt Embedded has 2 differences from classic one: its own low level
graphics library and its own window management. Neither of which would be of
any use if you want to play inside Photon. It was designed to be easily
portable into embedded environments, where there is no need to coexist with
anything else. That is the price for ‘easiness’.
Which brings us back to the issue of porting Qt classic. Or bombing Trolls
with requests to do it. They did hack mozilla in few days, should be real
easy for them
- Igor
“Armin Steinhoff” <A-Steinhoff@web_.de> wrote in message
news:3A617C00.36C4D0A9@web_.de…
I would implement the QT/Embedded lib using the same interface which
is used for the implementation of the Photon API … and not on top
of something else!
Nice. It is ‘using the same interface’ but it is ‘not on top of anything
else’. How is that Armin? It is on top of Photon drivers then…
That means we will get an ‘additional’ API, not
an API wich will replace anything.
You think you can just stick your own layer between drivers and Photon API
and it will somehow coexist nicely with whole Photon environment? Just a
magic, huh?
Armin, you’re full of knowledge in some areas but very naive in others.
As posted several times in this thread … Qt/Embedded has NOTHING
to do with X !!
It has nothing to do with Photon either. You however want it to play nice
within Photon, don’t you? Well, if you don’t then there is nothing to argue
about. You can port Qt Embedded easily indeed.
It works by accessing Linux framebuffer directly. Does not that tell you
anything?Yes … it tells me that you are not imformed about Qt/Embedded.
Qt/Embedded is portable and can be ported in order to use any frame
buffer.It can’t coexist with either X or Photon.
Why? Could it be that you have just the wrong idea??
Could it be with you Armin?
See my answer to ‘me’
- igor
Armin Steinhoff wrote:
Hello,
just a thought … since there is a QT embedded - that means Qt isn’t
completely bound to X - could it be possible to port Qt to a lower layer
interface of Photon?Such a port could solve a lot of porting and compatibility problems …
Armin
We have expirience in Photon and Qt under X,
if anybody will started to port Qt to native Photon version
we want to join to this program.
–
Mariusz Hawryluk
PBiWH “Next” s.c.
Warszawa