Logo54.159.123.105 
  Home  News  Recent  Forums  Search  Contact
  Menu
 Username

 Password


   Register here

 Main menu
   View images
   BBCode test
 
 Content
   Statement of intent
   Terms Of Service
   IRC Channel
   List Content

 In cooperation with
  OS4Depot.net
  OpenAmiga.org
  OS4Welt

 Links
  AmigaOS4
  IntuitionBase
  UtilityBase
  Amiga Flame
  Amiga Spirit
  AmiKit
  Aminet
  AmiBay
  AmigaBounty
  AmigaWorld
  Exec
  Amiga.cz
  View comments
Title  
  Forums
    Software
      AmigaOS 4  
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 
chrisRe: Qt Native News20101220 14:47  #354
@afxgroup

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 :)
afxgroupRe: Qt Native News20101220 15:28  #355
@chris

indeed, in the meanwhile we can try to understand what to put in .library file.. i think QT has a lot of functions..
alfkilRe: Qt Native News20101220 15:38  #356
@thread

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.
alfkilRe: Qt Native News20101220 16:38  #358
Now the QGLWidget is nicely embedded in the window:

http://dl.dropbox.com/u/5482530/Images/QtOpenGL2.png
RogueRe: Qt Native News20101220 16:59  #359
@kas1e

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.
RogueRe: Qt Native News20101220 17:01  #360
@alfkil

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?
RogueRe: Qt Native News20101220 17:04  #361
@chris

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.
spotUPRe: Qt Native News20101220 17:05  #362
here's a nice page that lists a lot of qt based software..
think os4depot for qt stuff..

http://qt-apps.org
nbacheRe: Qt Native News20101220 23:37  #378
@alfkil

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?

Best regards,

Niels
RogueRe: Qt Native News20101221 01:11  #384
@alfkil

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.
spotUPRe: Qt Native News20101221 01:30  #385
@Rogue

interesting, so actual code is written for gallium/mesa now.. o/
kas1eRe: Qt Native News20101221 10:25  #392
@Rogue
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 ?
RogueRe: Qt Native News20101221 12:41  #396
@spotUP

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.

@kas1e

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.
afxgroupRe: Qt Native News20101221 13:05  #397
@Rogue

Do you think would be possible in a (also far) future that shared objects will share functions like the standard .library?
TSKRe: Qt Native News20101221 15:48  #401
@Rogue

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) ?
kas1eRe: Qt Native News20101222 13:53  #415
@rogue
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).
ssolieRe: Qt Native News20101222 17:52  #417
@kas1e
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!)
eliyahuRe: Qt Native News20101222 18:35  #418
@alfkil

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.

@Rogue

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!

-- eliyahu
chrisRe: Qt Native News20101222 18:41  #419
@eliyahu

between REBOL, QT, timberwolf, a modern graphics stack, and the X1000, this community is on fire!



ssolieRe: Qt Native News20101222 18:52  #420
@eliyahu
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. :-)
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 
Home
Snack! forum website engine, Created in 2008 by Björn Hagström