At present the Calculator example functions pretty much exactly the same way as say with linux. Only exception is, that the resize gadget is visible.
Of course it would be easy to change the code to make the widget resizeable to a certain extend, only this is not how it has been done in the original example, which is why I have choosen to keep the code as it is.
Bearing in mind I don't know QT yet (I assume the "widget" is the window?), I don't see why that causes the window to be resizable. Surely you avoid creating the Intuition window until the window's show() method???
The above code doesn't make the widget resizable, on the contrary it turns the resize gadget off (hence the "fixed" size). The reason it turns it off is, that the fixed size is set _before_ the widget window is created and shown on screen. The reason, that the calculator example has a fixed size _but_ comes with a resize gadget is because, that the constraints for resizing each and every sub-widget are only calculated _after_ the widget has been "shown".
At present the Calculator example functions pretty much exactly the same way as say with linux. Only exception is, that the resize gadget is visible.
Yep but we use Workbench here not KDE so having a consistent look in the GUI (with other MUI/Reaction apps) is not a minor issue
Quote:
Of course it would be easy to change the code to make the widget resizeable to a certain extend, only this is not how it has been done in the original example, which is why I have choosen to keep the code as it is.
When possible i strongly suggest to make it look as close as possible to the typical Amiga interface because when right now isn't so important when developers start to port real QT apps on OS4 this will quickly become an important and decisive factor.
I'm not talking about the theme (plastique or others) but user interaction, this is the same type of problem we discussed weeks ago about Amiga menus VS built-in menus
Aniway it's just me or now QT examples eat too many CPU cycles ? Now i have only QT Calculator opened and my CPU is fixed at 100% according to CPUInfo on my dock
When possible i strongly suggest to make it look as close as possible to the typical Amiga interface because when right now isn't so important when developers start to port real QT apps on OS4 this will quickly become an important and decisive factor.
I really don't think this is something Alfkil needs to worry about too much for a first release. Yes it would be nice, but there is no use him killing himself over it! I'm sure that kind of thing can be tweaked later on, particularly once we have more idea about the actual issues in actual ported apps.
I'm far more concerned about practical issues like: * Reaction speed (we await Gallium3D). * Stability (that mostly seems to have been solved). * Windows taking many secons to appear (I think I would rather the window closes & reopens when it realises it doesn't need a resize gadget - but perhaps this should be user-configurable?).
How does Qt determine which language the user is using? I have some code which utilises translation, and calls QLocale::system().name() to find out the language. No amount of playing around with Locale Prefs changes output from "C" (which I believe is the bizarre Linux default), when instead it should be using Locale Prefs and returning an ISO-style name. I have a list I compiled of the AmigaOS names translation here which might be useful.
Also, I wanted to make you aware of iconv.library. This is libiconv as a shared library rather than a shared object, and comes with a stub shared object so other shared objects can still call it. Because it's a library it will only exist in memory once, which will save ~1MB per application. Given that your Qt shared objects are 30MB or so, it probably doesn't make much difference, but I prefer libraries over sobjs. (see also Hans-Joerg's blog entry)
Whilst we're on the subject of SObjs, your libssl and libcrypto: (a) are named differently to what your code is linked against (libssl.so vs libssl-1.0.0.so) (b) have a datestamp somewhere in the future (c) are a different size to mine, which are MickJT's latest ports on OS4Depot (and due to (b) I have no idea if they are newer or older)
And, additionally: Are there any plans for QtScript to be implemented? I was having a go at porting something and found it needed it. It also appears to need QtTest but I doubt that is important.
About resize issue i found that the ChrisY's solution used on his EasyImageSizer isn't that bad and maybe can be used as reference for all the other QT's examples, explain:
On the plugin window of this program you can resize the window without "corrupt" the buttons or other part of the window (at some point when the resizable area will reach the buttons it stop!)
For example you can try with Calculator, but the old one in your previews QT archive, not the new one (as with the new version you can't resize the window at all)
When, after a resize i reach the minimum size state, the number into the buttons start to be corrupted and/or the numbers will "exit" from the area of the buttons, that's why i ask you to implement it "a bit more Amiga-like"
About QScript and QTest, I think I tried compiling it at some point, but ran into trouble, can't remember exactly. I will try again soon.
About differently named libssl.so, I'm a little confused. I think the version I have included is my own "homegrown" version of it, don't know why the name is different.
About the locale and libiconv stuff, I will look into it.
I've released a DataTypes image format plugin for Qt. This automatically makes all Qt applications use DataTypes to load images (if there isn't a handler for that image type already), and you get an IFF ILBM saver "for free".
I've tested it with Extreme Image Converter, and it happily converts a WebP to an ILBM. Easy Image Sizer loads and thumbnails WebP too. I don't have any other useful test software to try it with (a recompile of EasyPaint might be interesting - hint, hint)
I'd like to add saving in other datatypes' native formats, but I'm not sure how to find out if a particular datatype allows this - the only way seems to be to try it, and then look at the result, which isn't great. Saving is a bit rubbish anyway, as it is only possible to save to a file, not a memory location, so I have to create a temporary file and then re-read it.
Qt for AmigaOS has come a long way and it now seems all bounty requirements are met. Still there's probably bugs to remove which I'm sure Alfkil will do that as they are reported;)
I will transfer the bounty funds to Alfkil monday morning, so now it is the LAST CHANCE to make a donation for the QT project. Could we get past the 800 mark?
Hehe, true I need some new stuff to get my dirty hands on, was thinking about java, mostly because I know nothing about it, so it would be a whole new world for me. Still, at the moment I'm working very hard on the NAPALM business, it is really tough, once I got past the basic initialization stuff it proves much more difficult to get a firm grip on all the mysteries of the code. Still, given time, I think I will be able to solve things.
Some time ago I managed to configure Mono for Amiga OS4 using cross compilers. I am still working on making it compile but since this is open source I am more than happy to share my little work.