@joerg

Quote:

So in fact one should expect incompatible changes on a version increment.

Now, while we're at it, I would love to admit, that it is totally my mistake, that the version bump had to be made. We could have made it backwards compatible. But we chose the cleaner option with less clutter. Appologies.

@joerg

Quote:

Well, given the fact, that Amiga uses libraries that are cross platform, we now need to reinforce this standard on the rest of the world.

@TheMagicSN

clib4_libs_adtools.tar.gz

For anyone who is interested in a spoken introduction:

Qt6 Showcase at AmigaLabs on Discord this Sunday at 19:00 pm CET

@TheMagicSN

Please look in mkspecs/amiga-g++/qmake.conf. This should give you the order of linkage. But to be clear : Doing this manually really defies the purpose of Qt. I will stop commenting on the issue, until you create and use a proper qmake project.

@TheMagicSN

Just to try and keep up with your pace - what you want to do with the Qt sources is probably to create a .pro file for them (in case this doesn't exist alread!). This is very easy, look here :

Qmake tutorial

Run

> qmake-amige

On the .pro file to get the Makefile and configuration items.

Then, if you really want to link this part together with the rest of the objects, you can either copy-paste whatever command lines you need from the Makefile OR you can create some super-level project generator or Makefile that handles the conglomeration facilitation of the project. If your issue is, that you are building it on the Amiga (what a feat, damn...), then I can congratulate you : The build ituls work on the Amiga, just not right now. There will be news on this item at some point, I assure you.

@TheMagicSN

icu for Qt6

@TheMagicSN

LibsPorts at AmigaLabs

@TheMagicSN

Hmm, strange. I have not seen this before. Well, one thing I am curious about is, if the authors intended it that way or if this is specific to the amiga port. Or maybe you created it entirely by youself, which is a massive achievement, but there are certain guiding rules for how these things are best managed. To subtract the amount of stress it would have, trying to maintain these things on non-standardized bases. Well, to tell you one thing - you need to adapt your build tools to compile and link against clib4. For this you might need a new compiler. If that is a longshot, then you are better off waiting for a little bit, until we can get you a hosted entity, that builds it for you in the correct way. Essentially, what you are looking for, is something that is being made and not quite ready yet. Hope you can entertain youself in the meantime. If you get anxious and rhubarb yourself over the terrain of interesting fortunes, then I would say - get core in last then network and gui. Then widgets. Then the rest. If you try and fail, then that's ok with me. We will get there. Cincerely. Good luck.

@Maijestro

Quote:

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.

@TheMagicSN

The last item on the command line is a giveaway : Your project somehow tries to link dynamically, which is not supported by current standards.

What kind of build is this? I assume cmake, but you never know, so I ask. If you are using cmake, then you HAVE TO use /qt-cmake-amiga in place of any cmake command OR at least look in this (text) file and incorporate everything there, so nothing is missing from the configure step. THEN you will have to persistently convince the configuration to do a static build, otherwise nothing is going to work at present.

Also you need all the additional libraries for the build. Maybe that is just what you are asking. I am using a mixture of ready packaged libraries from the ExperimentalSDK in some earlier version combined with probably some selected up-to-date ones. If you give me enough time, I will share with you my entire library setup, I just have to figure out which parts to omit, so it doesn't fill up the entire living room.

Your favorite apps have become updated :

favApps on github

Annnn......nd we have our first contestant! What a wonderful day!

@walkero
I think it is a great idea. There is the caveat, that we don't have a working backend for QAudioOutput, so there will be a bunch of extra points for securing that part. I will, of course, help as much as I can, but I really encourage crowd collaborations and those of you, who are not already familiar with the source code to take on the challenge and participate in the pleasure of working with Qt6 on any level. It is so very fulfilling, especially when all the basic functioning has been taken care of. And there are great prizes.... notch-notch ;) .

Here is a fresh tutorial. Beware of robot noises.

AmiQute Tutorial

@BSZill

clib4 has a strict allocator mode, that enables cosets in front of and after allocated memory sections. You could either build against clib4 or write your own supplementary malloc function and do the same. You would need to manually run the test function at suspected points in the code. I don't know enough about mmu's to tell, if there is some smart way of throwing an exception at exactly the point, where it happens. There probably is, but perhaps not system friendly. I remember doing some address tracking function in db101, so you might want to start there and see, if it suits your needs.

EDIT : I just read the following threads. Of course this creates an overhead, that might exceed the requirements of the app. I hope, you find a solution!

@Maijestro


Quote:

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.

Don't forget to visit the ko-fi page at https://ko-fi.com/amiqute

@NinjaCyborg

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.

I hope, you like it.

favCalc 1.0

Look - somebody dropped a scroll. Let's open it :