Does the old Qt 4.7 version work for you? I ask because it's maybe a more mature version than the new one currently in development Afaik Qt 4.7's compiled software can also be run from both icon and shell
I only have one question. Do you know what needs to be done to run a program compiled under QT to be run from icony (workbench) not shell ?
Strange, I did not foresee a problem here. There doesn't seem to be any failing calls in snoopy, so perhaps this is a feature of clib4. I haven't studied this, but maybe there is a special main function, that needs to be implemented?
EDIT: I have a question - did you test the native build tool chain?
I was reminded that I once encountered a similar problem with one SDL2 frontend to ffmpeg under clib4 under c++ If I find this program and make sure this is the case, I will definitely report the problem on the clib4 github.
I have tested a basic clib4 app, and I can see that it produces normal functions but it doesn't produce CON: output. Probably there is some path issue, that prevents the qt app from opening the environment, although I have trouble seeing what that could be. If we could redirect the stdout and stderr output, we could probably see what goes wrong.
I have quickly rebuilt clib4 with debug enabled. It looks something like this
(libInit) Current Exec debug level: 7
/work/piaskownica/QT/clib4/library/libc_init_global.c:72:Entering reent_init
/work/piaskownica/QT/clib4/library/stdlib/semaphore.c:11:Entering __create_semaphore
/work/piaskownica/QT/clib4/library/stdlib/semaphore.c:15:semaphore = 0x68557970
/work/piaskownica/QT/clib4/library/stdlib/semaphore.c:16: Leaving __create_semaphore
/work/piaskownica/QT/clib4/library/stdlib/semaphore.c:11:Entering __create_semaphore
/work/piaskownica/QT/clib4/library/stdlib/semaphore.c:15:semaphore = 0x685579A0
/work/piaskownica/QT/clib4/library/stdlib/semaphore.c:16: Leaving __create_semaphore
/work/piaskownica/QT/clib4/library/libc_init_global.c:305:Allocating wide_status
/work/piaskownica/QT/clib4/library/libc_init_global.c:334:Setting cpu family
/work/piaskownica/QT/clib4/library/libc_init_global.c:338:Check if altivec is present
/work/piaskownica/QT/clib4/library/libc_init_global.c:342:Allocating __memalign_pool
/work/piaskownica/QT/clib4/library/libc_init_global.c:362:Try to get elf handle for dl* operations
/work/piaskownica/QT/clib4/library/libc_init_global.c:364:Calling GetProcSegList
/work/piaskownica/QT/clib4/library/libc_init_global.c:369:Calling GetSegListInfoTags
/work/piaskownica/QT/clib4/library/libc_init_global.c:401:Check for .unix file
/work/piaskownica/QT/clib4/library/libc_init_global.c:413:Set signal table to SIG_DFL
(libOpen) IClib4 is NULL. Get interface
(libOpen) DropInterface
() /work/piaskownica/QT/clib4/library/misc/uuid.c:80:[uuid4_generate :] result :
(libOpen) c2n.pid = 131
(libOpen) c2n.pPid = 62
(libOpen) c2n.uuid = afc7ccb2-3d71-4f7a-b043-d9d2a651405b
[DOS] ERROR: WaitPkt() got a message, NOT a DosPacket, - bouncing it.
(libOpen) Enabling clib4 optimizations
(libOpen) Using Altivec family functions
this message only appears if I try to run the QT program from icon(workbench) [DOS] ERROR: WaitPkt() got a message, NOT a DosPacket, - bouncing it.
I will rebuild QT with DEBUG and paste possibly what QT shows (weekend is coming and I may not have time today - I will paste when I rebuild)
@elfpipe I have a question about file handling in QT6. Are you going to use the native AOS4 dialogs for file handling or should file handling be done with Qt?
In order to have the Amiga name displayed in the AOS4 interface, it is simple. You can change this in qfilesystemmodel.cpp- >QString QFileSystemModelPrivate::displayName(const QModelIndex &index) const In order for Amiga files to be displayed correctly in qfiledialog.cpp, I had to add code to QT to handle it (similar to Windows). I have tentatively managed to do this, I still need to finish it. However, I noticed that the native AOS4 file handling windows are faster. I have added the code from QT4 (print to pdf dialog) I'm asking because I don't really know what your plans are on this topic here you have a movie test only with the change of ‘displayName’ , test2 with support for AOS4 paths
Short answer : It is the plan, as soon as the native build environment is confirmed and gl rendering is at an acceptable state, that work should be done to update all relevant modules from the changes done in qt4. I am pretty sure, that most could be used in some form, and it would be quite clear where possible upgrades could be done to those changes.
It is nice, that you are doing experiments with various improvements. If it is ok with you, I would love to include those changes in the final version whenever it seems reasonable.
@elfpipe You are right. It's your project, it's cool that you have a plan as you presented it I, for now, will leave my expemperiments for my own use. I won't litter this topic with my posts. Thank you for your time.
No-no, I mean if you do a better version than mine, that's perfectly all right with me. I am sure that you are on the right track and that the work you are doing is worthwhile. I am keeping the repository open because of legal reasons, but also just because I like to share. And I don't like to take credit for the work, my contribution compared to the whole is very small. So if you feel like going big, go for it. :)
EDIT: I know the project has been stagnant for a while. I am just glad, that there is some progress.
I'm not familiar with QT, but it's great what you're doing it could mean we could use a few more apps and programs under AmigaOs4.1. Maybe even QtWeb one day.
As elfpipe mentioned you should continue and share your progress here as long as you enjoy it. Maybe you two can also work together to get the QT Project moving faster.
@elfpipe There were some cool example videos from you in the thread above
MacStudio ARM M1 Max Qemu//Pegasos2 AmigaOs4.1 FE / AmigaOne x5000/40 AmigaOs4.1 FE
I can recommend, that you do a shared build instead of static. We did some work to fix some symbol resolutions in elf.library, that didn't work before, so now ui signals will actually reach the callback function. This depends on *beep*.