Mmm i get a DSI when using drap&drop in draggableicons example, see log:
Quote:
Crash log for task "draggableicons" Generated by GrimReaper 53.2 Crash occured in module libQtGui.so at address 0x6D200950 Type of crash: DSI (Data Storage Interrupt) exception
About integration, I haven't thought much of it. I mean, the easiest way to deal with it from the perspective of developer is to keep qt centered around the QT: assign and keep everything relative to that. Saves me the trouble of dealing with separate building and installing paths. This could of course change in the future. For now, think of it as a single package that is refered by assign qt: <path>.
If you set QT_PUBLICSCREEN, and also set QT_NATIVEDIALOGS, then, for example for Demos/TextEdit , when you press "open", asl requester spawns on the WB screen (but should be the same spawned on qt_public_screen imho).
Anyway, now i can use Crhis port of ImageConverter :) With ASL requesters its pretty usable now. It will be awesome if someday you can implement native menus (with notice about 1 sublevel of menus only) :)
ps. Also looks like that env cant be 1 or 0, if i for example just do: Quote:
setenv QT_PUBLICSCREEN 1
Then QT runs on pubscreen, but if i try to do: Quote:
setenv QT_PUBLICSCREEN 0
Then its still runs on public screen. But if i delete that env at all, then it start to works on main wb one.
Please wait with downloading the new Qt arch, I messed up forgetting to copy the examples from my build directory. Will make a fresh upload asap.
Ah so maybe this is the reason why some of them crash, i played only examples in "examples" folder, btw while waiting for the new archive i'll do more test
On second screenshot you can see i run cpu-metter (left-top area of screen), in which cpu loading almost 1% (even while game on a pause, image at right area of working game-area are moves).
When play in game, cpu loading mostly beetwen 6-20%.
The problems which i see for now (and which are related to QT port itself):
1. Not fast starting (while all that sobjes loads to memory , etc). For me it takes about 8 seconds (but well, maybe that all related to HDD speed, but somehow speedup loading of all that stuff will be good for sure)
2. Native menu will make the game looks 100% native ! No one even will understand that its QT one. Game have only 1 sub-level of menus, so all is fine should be when QT_NATIVE_MENUS env will works.
3. Resizing of window not resezie the working area. I think its related to the source code of game, which not have support of it , but our QT all the time put the gadget that window can be resized (while imho will be cool to not have resazable gadget when game not mean to resize the working areas).
@alfkil
Also while i worring with QT ports today (i tryed 2 games already, that one, and one not finished for now because of some X dependeces (xanrd or kind) ), and they both, after i start compilation, give me such error:
Quote:
In file included from /SDK/newlib/include/sys/time.h:16, from /SDK/newlib/include/sys/resource.h:4, from /SDK/newlib/include/sys/reent.h:19, from /SDK/newlib/include/string.h:11, from /qt/include/QtCore/qbytearray.h:48, from /qt/include/QtCore/qstring.h:46, from /qt/include/QtCore/qobject.h:48, from /qt/include/QtCore/qcoreapplication.h:45, from /qt/include/QtGui/qapplication.h:45, from /qt/include/QtGui/QApplication:1, from main.cpp:1: /SDK/newlib/include/sys/select.h:80: error: expected ',' or '...' before 'protected' gmake: *** [.obj/release-shared/main.o] Error 1
So, i had to comment out manually line 80 in the sdk:newlib/include/sys/select.h, which are:
PS. BTw, it will be easy for you to build uic3 binary ? I see that QT4 come with UIC3 binary as well (it help to rebuild some stuff from qt3 to qt4). For example tryed right now some stuff, and have: Quote:
8/0.Work:QT/my_ports/QtCube/1.1> qmake trying amiga hack to find .qmake.cache... uic: File generated with too old version of Qt Designer (3.3) uic: File generated with too old version of Qt Designer (3.3) uic: File generated with too old version of Qt Designer (3.3)
Do some google, and found that uic3 binary are used for regeneration, but as i see our QT not have it for now ?
PS2. And for now second small game want "QDesktopServices" about which Crhis ask before. It is possible to port it as well ?
Edited by kas1e on 2011/5/5 15:43:47 Edited by kas1e on 2011/5/5 15:52:32
@alfkil And in meanwhile something for todo-maybe list : What you think about creating a "prefs-qt" , which will be placed in prefs, and by which user will setup their QT as they want ? For example:
1. on/off native_dialogs, native_menus, setup timing, dbl-click and all what you have already in the ENVs
2. save/not save window size/position at exit (to make second running where user want)
3. Change the QT window settings (put always draggable gadget, or not, put fat gadget line at bottom of window, or at right area of window).
4 enable/disable everything what you will add later/etc.
And some others. That prefs imho can be done by any skilled reaction coder like trixie, salas00 or others :) And it will be cool for end users : they will run it , and setup as much stack they want for example, all those assigns, all those settings right in the prefs window.
- About windows: If you open that kind of windows there is an automatic (and "not-asked") resize and an automatic allineament of them, don't know why it happen but it's very annoying to see expecially when the graphics refresh are slow like hell
- Is it possible to get rid of all that AmiCygnix assign each time one decide to start an example ? Also each example need it's own assign, of course maybe i need to check my config a bit better but it's quite annoying again .. you know
- How about converting all that SOBjs in "standard" .library ? Sure, not so important for now but if it is possible in future release ...
- How about native fonts rathen than the actual one ? (Did you use FontConfig ?)
@samo79 For me its enough one time to do QT assing (by script which i show in 2 posts above), and then QT apps not ask for them. So you can put it to startup-sequence, and only need to do "stack 2000000" all the time when you will want to run an app
@alfkil Can you add somehow stack-cookie to QT (just to avoid problems with manuall stack settings from users side) ?
1) stack cookie [FAILED] Not possible to set in shared object. Needs to be set manually on a per application basis.
2) Window alignment at beginning.[OK?] This happens because window sizes are only set at some point _after_ the widget has been created. Apparently it is not possible for intuition to open windows "out of bounds" (for instance (-100, -100, 20, 20)). The next best option is to open a very small window at the top left and let it resize. There is not much more I can do without messing things up real bad. Some dialogs will still "spawn", but really there is not much I can do about it.
3) DesktopServices [EXPERIMENTAL] An experimental version included. Didn't test it, but at least it should get your code compiled.
4) Assign problems [FIXED?] Should be fixed now.
5) Prefs app. Planned![DONE!]
6) Native menus[FIXED]
7) Turn into standard .library. [FAIL] Not going to happen, sorry!
8) uic3. [EXPERIMENTAL] Needs a closer look.
9) Slow startup. Not much I can do here except remove debug output. .so's are slow on Amiga.
10) Double click from system prefs. [FIXED]
11) ASL on public screen. Yeah bummer, I will fix this.[FIXED]
12) Window height limited to 1080. [FIXED]This is a terrible example of bad coding on my behalf. My own screen is 1080 high, so any other screen should be the same... Doh!
13) local keymap. Implemented an env variable to define local keymap codec. [CHECK]
14) GLWidget dependence on custom minigl. [FIXED?] Don't know what to do with this one...
15) Installation script. Planned.
16) Mouse wheel support. Planned [DONE!]
17) Right mouse button (and context menus)? [DONE!]
18) Build Assistant
19) Build Designer
Edited by alfkil on 2011/5/5 21:15:55 Edited by alfkil on 2011/5/6 16:48:00 Edited by alfkil on 2011/5/6 18:51:33 Edited by alfkil on 2011/5/11 18:18:01 Edited by alfkil on 2011/5/12 16:32:37 Edited by alfkil on 2011/5/12 17:52:01 Edited by alfkil on 2011/5/12 17:52:49 Edited by alfkil on 2011/5/12 18:09:21 Edited by alfkil on 2011/5/12 18:10:04 Edited by alfkil on 2011/5/12 19:35:04 Edited by alfkil on 2011/5/12 19:35:35 Edited by alfkil on 2011/5/12 19:41:36 Edited by alfkil on 2011/5/12 21:16:05 Edited by alfkil on 2011/5/14 22:12:26 Edited by alfkil on 2011/5/16 19:10:29
1. Not fast starting (while all that sobjes loads to memory , etc). For me it takes about 8 seconds (but well, maybe that all related to HDD speed, but somehow speedup loading of all that stuff will be good for sure)
I doubt alfkil can do anything about this - SObjs have always been pretty slow to load and link (although they are much faster now than when they were first implemented).
@alfkil Yeah thanks for all the worring about :) (not forget plz also that bug , about opening of ASL requester on WB screen, while you have QT_PUBLICSCREEN + QT_NATIVEDIALOGS).
@alfkil & crhis Btw, related to .sobjes they imho can be "stripped" as well ? I mean remove debug info, strip them (to make them smaller), so in end it will loads faster to memory -> faster startup.
Also a bit "bad" that our sobj implementation not really "shared". Because for logic i think should be something like this: one (first) QT app load in the memory necessary sobjes, and then, any app will use it when its need it until reboot. I.e. something like with current *.library.
So for example all what you need for "fast qt usage", its one time do something like:
loadlib qt:lib/qtgui.so loadlib qt:lib/qtopengl.so and so on,
and then, when any QT programm will start after that, it will take 1 second.
I remember that Rogue says that he have ideas to implement something like this (or maybe already ?:) ).
For me its enough one time to do QT assing (by script which i show in 2 posts above), and then QT apps not ask for them. So you can put it to startup-sequence, and only need to do "stack 2000000" all the time when you will want to run an app
Yep, i solve the problem ! ehm it was a bad path into the assign, my mistake ...
@alfkil
Quote:
2) Window alignment at beginning. I will see, if I can get it to open windows out of bounds first. Otherwise there is not much I can do, Qt has it's mysterious ways with screen updates.
Thanks hope you can solve easily, it's a strange effect that it's not so good to see :-/
Quote:
4) Assign problems ??? I have fixed it here, no complaints, so something mysterious is going on. Please try and set the QT_HOME variable to "/ram" and see if the assign req disappears.
Solve, see above !
Quote:
6) Menus. Yeah ok, I will take a look and see if it is possible at all. Not so easy, though.
Mate this is one of the most important thing to add, having native menu means that our developers can start to port "real apps", right now they doesn't look usable, some sort of "integration" is truly essential, also the actual alien menus are slow like hell !
Quote:
7) Turn into standard .library. Not going to happen, sorry!
Can i ask why ? Is there any technical issue, it's impossible to do, too much work or ?
Aniway keep it up mate, good work and as always a big thanks
About the .library thing it is a combination of being way too much work and probably impossible to do. There is no way to import code into an amiga .library, as when subclassing Qt objects with virtual functions. So therefore no.