This is to incentivise people who would like to try it. Here's a very short video of my old tests with Qt6 for AOS4 on a QEMU Mac Mini M1.
@elfpipe Thanks for your work!
Edited by smarkusg on 2025/7/28 21:23:40 Edited by smarkusg on 2025/7/28 21:25:02 Edited by smarkusg on 2025/7/28 21:47:35 Edited by smarkusg on 2025/7/28 21:48:24 Edited by smarkusg on 2025/7/29 4:16:23
I have to disaggree. I only share this, because it is friday and I really love this place. The following app is groundbreaking for scientific work. It is going to save your ass a million times, if you are caught up in computations. And it thorougly shows, that Amiga is once again on the forefront of computing.
NinjaCyborg wrote:the only problem is qt apps mostly suck. But maybe we can get a new browser if someone can wrap webkitty in a QtWebKit object?
I don't think everything from QT is bad. There are a number of apps that are really great and could fill the gap left by missing software in AmigaOS 4.1.
Here is a short list of Qt apps, and yes, it is quite long.
All we have at the moment are QT demonstrations, but since QT6.x already supports gles2 under AmigaOS 4.1, the GUI of the respective app could be accelerated enough to be user-friendly under AmigaOS 4.1.
@elfpipe
Hey, thanks for the QT6 demos. The cube is really cool. Is there a complete installer for Qt6 for AmigaOs4.1 that permanently installs it in the system? So that an assign is no longer necessary?
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Hey, thanks for the QT6 demos. The cube is really cool. Is there a complete installer for Qt6 for AmigaOs4.1 that permanently installs it in the system? So that an assign is no longer necessary?
The conceptual value of the qt6 assign is to have a root folder to dynamically link against libraries and plugins. Given the fact, that we are linking statically (you probably noticed when downloading the files) this function is not so salient. Qt6 might sometimes save application states, and this goes somewhere in the qt6-amiga folder. So if you are lucious, you choose a folder on your work partition, make a fixed assign there, and that is all the installation you need.
Now we are at it: The reason for the static constraint is, that there is no way to implement signals and slots using the combination of publicly available system libraries and build tools.
Edited by elfpipe on 2025/8/2 14:44:42 Edited by elfpipe on 2025/8/2 14:46:20 Edited by elfpipe on 2025/8/2 14:46:54 Edited by elfpipe on 2025/8/2 14:47:32 Edited by elfpipe on 2025/8/2 14:47:58
Thank you for writing a user friendly installer that installs everything. It works really well without having to do an assaign.
A small criticism...
when I run the installer of the folder favApps which is located in the Ram Disk: the assaign is referred to the RamDsik:favApp which is of course gone after a restart.
The favApps folder must therefore be copied somewhere on the hard drive beforehand and the installation can then be carried out from there so that assaign remains in place in the long term.
Future QT apps (and I hope someone will provide some) can then be started directly from the favAPP folder. I have also added the QT demos of Os4Depot to the favApp folder and yes, it really works very well.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
...when I run the installer of the folder favApps which is located in the Ram Disk: the assaign is referred to the RamDsik:favApp which is of course gone after a restart....
I suppose, that once in a very distant future, we will have individual Qt6 apps not take up so much space (really, it is _ridiculous_ at the moment, there is nothing more to say about it), and then every app will be directed to where it is intended. I thought in this case, that I would just preserve the situation, that the user created for him/herself by the unpacking condition and leave the apps in that special place. I could have been misjudging, sure, but maybe it is time for a change, another way of living, where apps are not just copied again and again, and where there is something about the originating intention, that stays alive along the way. It is up to you to decide. I will gladly stand for the posibility, that linking will be done, as the fathers saw it in the distant sands. And you might think, I am nuts, but it is only 'till you see the livelyhood of the things, these circuits can do. To me and you. And foo. And bar.
The development around clib4 is truly remarkable, and of course it's great that developers get a stable, modern development environment.
Unfortunately, with each new version of clib4.library, older apps seem to stop working. Here's an example from QT with clib4 .library 1.6 everything works perfectly, but when I replace this library with version 2.0, the apps no longer run.
Unfortunately, clib4 is not backward compatible, and every app, no matter how small, that was compiled with older versions has to be recompiled. I'm not a developer, but isn't that a considerable amount of extra work for developers?
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
Clib4 version 1 is backward compatible. We bumped to version 2 because a change in crtbegin.o that has broken the compatibility. Version 2.1 will be backward compatible with version 2.0
Clib4 version 1 is backward compatible. We bumped to version 2 because a change in crtbegin.o that has broken the compatibility. Version 2.1 will be backward compatible with version 2.0
A IMHO better option, you might consider for further incompatible updates, would have been using a library name like clib4_2.library instead of using the same library name as the incompatible clib4 1.x clib4.library. That way users could have both versions installed and use all clib4 software, the ones built with 1.x as well as the ones built with clib4 2.x, without having to wait for all developers who used clib4 1.x to recompile their software with clib4 2.x.
In case I'd ever update the AmigaOS newlib port the new version would be, for obvious reasons, incompatible to the current ones and I'd use something like newlib4.library(.kmod) or newlib_4.4.library(.kmod) for it.
A IMHO better option, you might consider for further incompatible updates, would have been using a library name like clib4_2.library instead of using the same library name as the incompatible clib4 1.x clib4.library. That way users could have both versions installed and use all clib4 software, the ones built with 1.x as well as the ones built with clib4 2.x, without having to wait for all developers who used clib4 1.x to recompile their software with clib4 2.x.
That's a good idea, as it prevents an older clib4, e.g. 1.6, from being overwritten by a new, incompatible version 2, and we remain backward compatible.
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
clib4 except for few programs was used by almost anyone except me.. That's why we decided to bump to version 2. I think that we'll be no other breaking versions at least in crtbegin. In any case the UnLock error wasn't an incompatibility between version but an error on clib4 for some reasons wasn't show on clib4 1.6.. OS4 mysteries..
Not possible on AmigaOS, we only have 2 numbers. Especially for libraries, devices, etc., in which the two uint16 Version and Revison numbers are taken from the embedded struct Resident and struct Library/Device and not from a parsed $VER: string. But even for example for executables, docs, includes, etc. in which there only is the $VER: string using something like 1.2.3 would be a very bad idea as it fails with everything parsing the string (C:Version, AmiUpdate, ...) according to the AmigaOS $VER: standard.
Edit: The wiki article is incomplete, at least for AmigaOS 4.x. It's "$VER: <name> <version>.<revision> (<dd>.<mm>.<yyyy>) <comment>" with <comment> being an unparsed string displayed as is by C:Version FULL which can contain anything, often used for copyright notes. Using something like
$VER: foobar 1.515 (24.8.2025) 1.2.3
(revision 515 = 2<<8 + 3) would be an option.
Edited by joerg on 2025/8/24 15:59:41 Edited by joerg on 2025/8/24 16:03:49 Edited by joerg on 2025/8/24 16:04:40
Another incompatibility is the fact that in Amiga versioning, neither the version nor the revision is ever 0. Both start at 1 - the first version or revision.
News feed
OS4 Feedback forum
OS4Depot Feedback 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
