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.
Qt 4 comes with the tool uic3 for working with old .ui files. It can be used in two ways:
To generate headers and source code for a widget to implement any custom signals and slots added using Qt Designer 3. To generate a new .ui file that can be used with Qt Designer 4. You can use both these methods in combination to obtain .ui, header and source files that you can use as a starting point when porting your user interface to Qt 4.
The first method generates a Qt 3 style header and implementation which uses Qt 4 widgets (this includes the Qt 3 compatibility classes present in the Qt3Support library). This process should be familiar to anyone used to working with Qt Designer 3:
The resulting files myform.h and myform.cpp implement the form in Qt 4 using a QWidget that will include custom signals, slots and connections specified in the .ui file. However, see below for the limitations of this method.
The second method is to use uic3 to convert a Qt Designer 3 .ui file to the Qt Designer 4 format:
uic3 -convert myform3.ui > myform4.ui
The resulting file myform4.ui can be edited in Qt Designer 4. The header file for the form is generated by Qt 4's uic. See the Using a Component in Your Application chapter of the Qt Designer Manual for information about the preferred ways to use forms created with Qt Designer 4.
With the both methods have the same 2 bugs (no q3porting.xml and exit-signal-unfree). Can you have a look at this plz ?:)
New version of Qt that fixes all the 0.7 issues (bad examples) uploaded to os4depot. The link on the front page is broken, though, so you need to go to the development/cross directory manually and upload from there.
@TSK Looks like you are on the moment while transfering/checking from the upload to recent are happens (some time it take about 5-10 minuts by some reassons).
error: qserversocket.h: No such file or directory error: qsocket.h: No such file or directory
They not implemented for now, or its some qt3/qt4 mess ? (maybe for qt4 just different names for it ?)
Hmm... I can't find these files anywhere, so I think they are leftovers from qt3. Try and remove the references and see what it says, if it asks for different objects, you can search for it in the qt/include/QtNetwork directory.
Hmm... I can't find these files anywhere, so I think they are leftovers from qt3. Try and remove the references and see what it says, if it asks for different objects, you can search for it in the qt/include/QtNetwork directory.
I play more with, and looks like i just need to read qt3 to qt4 porting guide mor carefull. For now have just mess with all of this, so will keep it for late when you will fix uic3 (if you will have time for it, not so necessary anyway :) ). Or will use just winxp version of qt to migrate from qt3 to qt4 firstly (no big problems in general).
Anyway, have new question for you :) There is 2 archives (sources + binary to test in each):
While first one i already describe before (plays fine-fast, just menus slow and running slow, i.e. all as expected), the second one by some reassons very-very slow at all. I.e. almost unpossible to do anything in it, while its looks very simply. Dunno, but maybe there is the same problem with framebuffer objects as you describe before ? Also it hangs the same classic way on qt_cleanup() (but i use minigl2.5, because with your ones have big-slowness, dunno if cleanup() exit bug is related to it).
Can you please check briefly the sources (they small enough for both apps), and check the bins yourself, and explain why first one are fast, and second one are so slow ? (just to be sure that we know what going on and what apps we can avoid for now).
1. About/About or F1 (also as AboutQT): you can see how window jumping (firstly spawn one empty window of one size, then resizes, and jump to centrum). I.e. we see what do QT intermaly, but imho for end usage that should be not visibly for users (just end-resulting window). If that possible of course.
2. The whole menu even not have any sublevel. I.e. all is plain. What say one more time for the woth of effort for making native menus, just because as i can see for now, 1 sublevel its really in 99% enough. And with that app for example there is even no any sublevels.
3. Try to do any draw operation (by pencil, or byelipse, or by rectangle) Its all very slow on my peg2 1ghz, and CPU loading jump at 100% when i use it. That is that framebuffer object problems imho again ? If so, maybe (if it will be more or less easy of course) somehow disable OpenGL support at all, to avoid usage of MiniGL for everything (so, maybe it will speedup the stuff in end where framebuffer objects are uses ?).
4. In end of all, i have totally texture trashing of whole of screen, and as result when i trying to exit from programm, eveything halts, with words:
But pretty possible its related to unfixed warp3d on our user-version-of-os4.
What you think, it is possible to disable OpenGL somehow at all ? Something like add #ifdefs everythere, and one more env, QT_OPENGL true/false ? Or without OpenGL it will be even slower than its now ? Or maybe i can on compilation stage, put manually to makefiles QT_OPENGL_FALSE or kind, to avoid OpenGL usage ? (or opengl usage its hardcore done in QT-port, so cant be disabled at all ?)
But well, in whole we already can compile QT apps native :) Just need to sort out all the crap, and yeah !
For example that EasyPainter will be pretty good to have, when menus will be native, with asl requesters, and when drawing and whole programm usage will be fast. Even a bit slow loading of sobjes will be not big deal after all :)
I believe Intuition takes care of garbage collection of BOOPSI objects and muimaster library takes care of garbage collection of MUI objects. So you have to implement garbage collection of Qt objects in your Qt port itself. AmigaOS don't know anything of internal stuff of Qt so it doesn't have any means to do anything with any Qt stuff. Unless you somehow integrate it into Intuition and turn all Qt classes into BOOPSI classes and start using IIntuition->IDoMethod(), OpenClass() and other related functions of Intuition instead of internal methods of Qt.
Check if Qt has its own internal garbage collector and if it works like it should.
You can check from autodocs of AmigaOS SDK if you could use Exec functions AddTrackable(), FindTrackable(), RemTrackable(), DeleteTrackable(), AllocSysObject() internally in Qt.
Rock lobster bit me - so I'm here forever X1000 + AmigaOS 4.1 FE "Anyone can build a fast CPU. The trick is to build a fast system." - Seymour Cray
hijackWindow() context created for QMenu(0x56545ca0) 1
QGLWindowSurface: Failed to create valid pixelbuffer, falling back
QGLWindowSurface: Using plain widget as window surface QGLWindowSurface(0x549588e8)
QColormap::instance(screen = -1)
create_sys: popup: 0x588cec40
QGLContextPrivate::init() 0x56546908
hijackWindow() context created for QMenu(0x56546900) 1
QGLWindowSurface: Failed to create valid pixelbuffer, falling back
QGLWindowSurface: Using plain widget as window surface QGLWindowSurface(0x54958728)
QColormap::instance(screen = -1)
create_sys: popup: 0x588cbab8
QGLContextPrivate::init() 0x565448f8
Failed to create opengl context!
My gfx mem is really low now, so I wonder if it is simply an out of memory condition that should have been trapped in minigl/qt (actually, shouldn't the OS being ensuring gfx mem doesn't run out, and swapping things out to main memory when it gets low?)
My gfx mem is really low now, so I wonder if it is simply an out of memory condition that should have been trapped in minigl/qt (actually, shouldn't the OS being ensuring gfx mem doesn't run out, and swapping things out to main memory when it gets low?)
As i understand it just problem of public warp3d, and its already fixed (i.e. when you out of mem, then it will catch the stuff and do what should to do). Maybe its not relaed, but anyway sad that hyperion just can't do some fast-quickfix with that necessary fix, so we all can test the stuff normally.
From other side, its interesting why its so fast eat all the video mem, and why it 2-3 times slower than LodePaint (which are also opengl).
The problem with garbage collection is, that there are no ways for Qt to detect the difference btw
a) QWidget mywidget;
and
b) QWidget *mywidget = new QWidget();
If I enable smth like garbage collection for widgets, then the a) widget will be deleted twice, which is horrible and even worse than what we have now.
Really, garbage collection for c++ objects should be taken care of by the c++ runtime (ie. newlib, or??). There is nothing I can do about it.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
