|Navigate: 1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-180 181-200 201-220 221-238 |
|chris||Re: Qt Native News||20101220 14:47 #354|
|By the way, we need to use a shared amigaos .library with QT otherwise you will have too many copies of QT .so file loaded in memory.|
Yes, definitely. With all the customisation it won't be easy to bump it up to a newer version of QT anyway, so may as well put the extra work in to make it properly shared.
But let's let alf get it working as an .so first :)
|afxgroup||Re: Qt Native News||20101220 15:28 #355|
indeed, in the meanwhile we can try to understand what to put in .library file.. i think QT has a lot of functions..
|alfkil||Re: Qt Native News||20101220 15:38 #356|
Sorry, a qt.library is not going to be possible because of c++ and also a .library doesn't give any interface to variables only functions.
|Rogue||Re: Qt Native News||20101220 16:59 #359|
|Its the same cool as if we will have GTK->MUI or GTK->REACTION someday. |
GTK->another GUI toolkit doesn't make much sense. It works for some simple apps, but as soon as they go to render their own stuff (which e.g. the GIMP does, or Abiword, or just about any app that matters) they will need the GDK which cannot be easily mapped to either of the existing AmigaOS GUI toolkits. A direct port of GTK would be preferable, more so since GTK is quite portable.
|Btw, while you have a rendered data in the bitmap, that "just blit it into the window" are fast ?|
Bitmap-to-Bitmap blits are generally very fast. Of course directly rendering is faster, but that tends to flicker since you can actually see the redraw. A possibility is to render into the backup bitmap of the window is the screen has compositing enabled, but that practice is discouraged since it requires both knowledge of the compositing state on the screen as well as messing with internal structures.
|Rogue||Re: Qt Native News||20101220 17:01 #360|
BTW, congrats on getting this far, I bet that hasn't been trivial :) Good work.
A stupid question maybe, but on the editor window you have a p96PIP_OpenTags, are you using an overlay window as an application window?
|Rogue||Re: Qt Native News||20101220 17:04 #361|
Speaking of Shared Library vs. Shared Object, I am currently faced with the same "issue" with Gallium/Mesa. Luckily, these only export code symbols, and that is easier to achieve than with both code and data export, or (even worse) imports into a library.
If I ever get the time I might also look at adding proper shared code support to the shared objects. Right now, they cause a lot of code duplication, especially for something like Qt this might be an issue.
|spotUP||Re: Qt Native News||20101220 17:05 #362|
|here's a nice page that lists a lot of qt based software..
think os4depot for qt stuff..
|nbache||Re: Qt Native News||20101220 23:37 #378|
|Sorry, a qt.library is not going to be possible because of c++|
Wouldn't it be possible to implement a C++ wrapper around a shared library?
|and also a .library doesn't give any interface to variables only functions.|
That might be solvable with getter/setter functions, right?
|Rogue||Re: Qt Native News||20101221 01:11 #384|
|Sorry, a qt.library is not going to be possible because of c++ and also a .library doesn't give any interface to variables only functions. |
Does Qt export symbols to the application other than code? If it only exports code, then you could use the same method as I use for Mesa.
|spotUP||Re: Qt Native News||20101221 01:30 #385|
interesting, so actual code is written for gallium/mesa now.. o/
|kas1e||Re: Qt Native News||20101221 10:25 #392|
A bit offtopic, but it's only you for now works on gallium/mesa ? I think before, that Hans de Ruiter want to worring about all of this. Anyway, hope you have in mind all that speed issues :) Will be cool if gallium/mesa will faster than w3d/minigl in end. Did you make any actual speed-tests for now, or its too early to ask about speed-tests ?
|Rogue||Re: Qt Native News||20101221 12:41 #396|
More or less trying to nail the native API. I guess we'll go with egl, it's designed for this purpose and compatible with OpenGL, OpenGL ES and OpenVG. For that purpose I have compiled a software driver for Mesa, because there are some concrete issues that need to be solved from the high-level if you want to be multithread and multicore compatible.
|A bit offtopic, but it's only you for now works on gallium/mesa ? I think before, that Hans de Ruiter want to worring about all of this. Anyway, hope you have in mind all that speed issues :) Will be cool if gallium/mesa will faster than w3d/minigl in end. Did you make any actual speed-tests for now, or its too early to ask about speed-tests ?|
Hans is still busy with the RadeonHD driver, so right now it's only me. As I said above, we're experimenting with the native mode interface, the code sharing (not wanting to use .so's since they don't share code) and multithreading/multicore issues (thinking about what it would take to implement tls support for gcc, but that's a different story).
So unless you want to benchmark a software driver, it's way too early for benchmarks.
|afxgroup||Re: Qt Native News||20101221 13:05 #397|
Do you think would be possible in a (also far) future that shared objects will share functions like the standard .library?
|TSK||Re: Qt Native News||20101221 15:48 #401|
|So unless you want to benchmark a software driver, it's way too early for benchmarks.|
Does that mean you have a working Mesa already (running on AmigaOS, I mean) ?
|kas1e||Re: Qt Native News||20101222 13:53 #415|
Just to avoid all that offtopic talks in that thread, maybe you can just post some info related to mesa/gallium/current state on hyperion blog ? (and we can discuss all of this on it).
|ssolie||Re: Qt Native News||20101222 17:52 #417|
I hope Hans-Joerg writes a quick blog entry to let everybody know how things are progressing on the Gallium3D project. Maybe we can get Hans to write an update on the blog regarding the Radeon drivers as well.
I know I'm excited about proper 3D support in AmigaOS as well.
Now back to your regularly scheduled Qt thread. (Great work BTW!)
|eliyahu||Re: Qt Native News||20101222 18:35 #418|
this is magnificent work. thank you! sometime ago a band of plucky coders ported QT over to haiku and since then ports of koffice, arora, and other very useful, modern applications from the GNU/linux world were brought over, filling in some significant gaps in the available haiku software library.
would love to see this happen as well on OS4.
any comments on the progress of your MESA implementation on OS4 would be much appreciated. and now with the official developer blog, it would be all the better to talk about it.
between REBOL, QT, timberwolf, a modern graphics stack, and the X1000, this community is on fire!
|chris||Re: Qt Native News||20101222 18:41 #419|
|between REBOL, QT, timberwolf, a modern graphics stack, and the X1000, this community is on fire!|
Navigate: 1-20 21-40 41-60 61-80 81-100 101-120 121-140 141-160 161-180 181-200 201-220 221-238
|ssolie||Re: Qt Native News||20101222 18:52 #420|
Speaking of REBOL, things are on hold a bit while the team works towards a beta release of the core language itself. This is an extremely important step for REBOL Technologies so we need to step aside and just let the work happen. Carl is still keen on progressing with the Amiga version of R3 of course and I will continue to work on it.
Back to your Qt thread again. :-)