Finally I got it working saving and loading also works now for events, as I described before I had to relocate the complete Eventhandler routine to make that possible (in an abstract way).
Now it’s also possible to add multiple Windows. (But only the first one is open by default), I have to think about how to solve it, but of course you can open the other Windows in the OnShow Event of the MainWindow. Or as I show in the Video on Button Press.
A little demonstration (featuring “awesome drawing skills” icon 😉 ):
Notice to me, stop Delitracker before recording, or the mouse pointer whips with the Music 😉
After that is finished I guess the next one will be properties which are other classes, like Menu or List at the ListView.
I also have some ideas how to deal with special Values (like the Window inital position, MUIV_Window_LeftEdge_Centered and so on) but this will need a little bit more thinking and of course much work 😛 .
Back to topic, after this little Vampire excursion, I continued working on MUIIDE especially the loading and saving, atm. I just save/load a project file which is a simple XML very easy for Trees to handle in XML and also can save nearly every content. But of course with this it will be not possible to export the source code and reload it to add an additional item… especially if you changed the source. It will be very difficult to make that happen, of course Lazarus does this… but Lazarus is a code monster difficult to dig out how this is done and maybe thats even not transferable to my code. I’m not sure what to do here.
Loading and saving for the properties is already finished and working well, but at this position I noticed that I did the eventhandler keeping wrong this way I can not save them to the project file, seems need some more thinking.
After that is finished I will try to add class properties, like Menu (Window), List (on a ListView) and so on Also thinking about to make the project multi window compatible, so that it really can hold the complete application not just a window, then the root of my Tree should be application and not Window.
Wrote a little Makefile and added the MUIClass compilation to the Jenkins build server. On every change in the repository it will recompile MUIClass for all available platforms. At the occasion I noticed that I did some errors for 64 bit (Integer – PtrInt) also corrected this. The Jenkins compilation create a little archive with the compiled units, IDE and examples. If you download them together with FPC release archive for your platform it should be directly usable. It also creates the documentation directly and as archive on the build server.
The exception handling I mentioned yesterday is improved. To satisfy MUI/Zune I put a try, except into every hook function before calling the Eventhandler, it makes sure the program returns from the hook to MUI/Zune. Of course the basic function is still the same, if the User decide to break the program, it will be terminated or if you connect the OnException event is assigned it gets triggered.
When an exception appears which is not covered by any try/except the program will just end (and print the exception to Debugout) which is not very nice. Again take some idea from LCL and catch all exceptions in the Event handler and show to user as nice MessageBox. But MUI certainly does not like it if you leave the Eventhandler in such a rude way 😉 (at least Zune on AROS) so after it the Eventhandler is dead because Zune thinks this is a circular calling. It’s not true but it’s prevents you to call that event again. Best thing here is to end the application an restart. Therefore I ask the user what to do, ignore the exception, knowing that this will have strange effects, or leave the program directly.
The ignore could be interesting if you have the chance to save your data before closing the program. Of course the writer of program can also override the Exception handling (via OnException Event in MuiApp, as used to from Delphi/LCL.
Working hard on the Event stuff for the MUI IDE. Hardest Part to find out how the Eventhandler parameter are via RTTI. In the end just some pointer calculation inside the RTTI structures.
The program already does some basic Source export. So it is somewhat usable! But I’m not sure if that is the final version or I will go the LCL way of some kind of hidden properties (for now the properties are written directly to the Source).
For sure is not finished, it has not saving/loading feature source name and editor name for editing the eventhandler are hard coded, and so on. But for now thats already very cool, at least I think so 😛
My MUIClass implementation is already rather advanced, the basic items are implemented, most of them are even tested and documentation. With this tools you can already write rather easily MUI GUIs but it would be even nicer to use a GUI to create it (especially because on some fields I’m not completely sure how this influence the final result). Already long time before I had some concepts for that in my Head but with the plain MUI classes and my little MUI knowledge thats just too difficult. Now with the MUIClasses and my increased knowledge when writing them 😉 it is possible. The Basic functionality of adding Stuff and changing properties are already there, all completely abstract (via FreePascal RTTI), so I do not need to implement every field for it by hand.
A little demonstration:
For now I only added some basics (Button, String, Text, Group) But the rest is rather the same. There is still much thinking to do with the advanced classes like ListView and so on (how to connect the List to ListView) and EventHandlers but this should be solvable. Also the Source export is not implemented until now, because I’m not completely sure which way I choose.
Basically there are two ways. The first one is more or less like Lazarus does it: The properties you set in the IDE are written to a resource file and without seeing them in the final sourcecode they are streamed to the objects on creation. If I choose that way I would not use resources (because Amiga68k still have no support for it) but maybe an include with a xml/json text which describes the GUI. This way has also the advantage that it is easier to read it back later (if you reopen the file in the IDE again).
The second way would be like fpGUI does, the IDE produces the complete Source to set the properties in the Source code. (with some helper comments to find them back when you reopen it). Advantage much easier to implement on the Saving Side, Disadvantage the Loading part can be very tricky if the User changed the Sources somehow. Still to decide, but so many other problems before that appear so no worry. 😛
Working on the documentation for the MUIClass objects and also implementing Dialogs (File, Font, ScreenMode). Found some stuff to improve in the MUIClass objects when writing the documentation, missed some fields, forget some return values.
The documentation can be found on this server.
Working on the DrawPanel, thats an MUI Area object which exports the usual Events you know from LCL objects, like OnPaint (here OnDrawObject), OnMouse____, OnKey____, such stuff. With this it is very easy to create a simple painting application:
(Notice my awesome drawing skills 😉 )
With it, I developed a TDrawBuffer, which saves you the work of Allocating a Bitmap, create a layer and RastPort. I noticed I have this kind of code in many of my MUI applications, therefore it make sense to make a little handy class out of it. I could have some more functions. I tested the whole stuff on Amiga, AROS and MorphOS and it works fine on all of them, very nice.
Currently I’m working on the idea I had long time before. A pascal interface to MUI classes. MUI uses Amiga boopsi interface to access the GUI elements. But thats not very convenient, especially for pascal users. I started already two time an approach to create such classes. The main problems are the fields which can only set in the moment when the object is created and the TagLists which does not tell you the type of a field you have to cast everything to integer. In LCL I supply the properties as Create parameter TagList, so it’s just the same as using the plain MUI functions.
In this MUIClass implementation the pascal classes will only collect the field values and create the MUI objects on the actual application run and window open. You have more chance to interact with the objects before the MUI objects get created.
It makes the MUI programming much easier, I like it. I’m thinking to change some of my programs to that system, the code looks much easier to read. The code is on GitHub under a public domain license.
A little bit delays, but as always the summary of last year. Due to personal circumstances I have only little time for these things and also not much mood. I hope this will clear up through out the year.
But back to the review. The year started as claimed in the last summary suggested. The MUI-LCL was accepted to the official Lazarus repository and also did some (little) improvements of it. Sadly I always hit the border what MUI can do so not much advance here.
Charlie improved FreePascal and Frank Wille improved vasm and vlink to support section linking for the Amiga Platforms. This decreases the file size very much. Finally vlink and vasm became the default assembler and linker for Amiga68k, MorphOS and AmigaOS4
FPC for Amiga systems got it’s own Subforum at Amigacoding.de and in the beginning there were some discussion, sadly it slept in again.
Over the easter holidays I was on a trip, and I took my raspberry pi with an attached touchscreen and keyboard with me. Of course with AROS arm installed. Therefore I was able to code at the evenings in the hotel. I started to make a new approach for Mapparium. Mapparium is a nice program (I use it mainly to depict my bicycle tours recorded with my GPS device or iPhone) but the GUI ist still rather clumsy because MUI/Zune does not like this direct placement of positions. On a native 68k Amiga it become very slow because of this huge LCL Layer. I decided to write a native MUI/Zune application, as I did before the ZuPaPlayer, again to learn a little bit how to code MUI and also to fix some serious problems I found in Mapparium. The New Version is called MUIMappariumandwentthrough several releases until the current 0.5 release. MUIMapparium got an own Release page. It still does not have the same feature set as the LCL Mapparium but it works much more smooth, really nice even on a native 68k Amiga especially on a Amiga 600 with Vampire.
Speaking of Vampire, I bought a complete Amiga 600 with a Vampire V2 card, really nice piece of hardware. Very fast (the card just keep popping away from the chip where it should be attached). The only drawback is, that there is no FPU included in the FPGA emulation (so it’s more like a 68030/68020 than a 68040/68060 which has built in FPU). For my programs thats not a big problem, there is a SoftFloat option in FreePascal and it works really well. I never thought about the speed of that routines. Yes, I knew they are much slower than a native FPU calculation but I had no idea how much. Later someone released a FPU-emulation software femu which improved the situation a lot. But still a lot to improve there. I heard that the next released core should have included some more basic FPU function and the femu is somehow more connected to the FPGA. I guess they build a way to prevent the Trap which appears on every unknown FPU command and eats up a lot of time. But I have no idea if this is true and this will ever be released, In fact I doubt it a little bit, seems the whole project is sleeping or so. Just to depict that core releases from Vampire:
That means the last FPGA core release was almost a year before, and Screens/Show offs of the coming Gold 2.7 or Gold 3 are there since several month already but no sign of an actual release. (to be complete, there is a Gold 2.5 release, but there the FPGA core is not changed, same build number)
My Blizzard 1260 broke and I send it to repair, (sadly still unknown whats exactly wrong, MACH chips? I have no knowledge about such stuff). For the time without a proper turbocard for my A1200 I bought a Blizzard 1230IV which works very nicely. An other thing the Vampire is missing, is an MMU (at least an Motorola compatible MMU) so until now Linux or NetBSD will not work on Vampire Amiga. But on this Blizzard 1230 it runs… even very slow of course. I did some qemu-m68k stuff on my home server to let some automatic tests run of the freepascal 68k compiler Charlie is improving the whole time. My plan was to also try it on a real Amiga with Linux. Nice, but it really needs ages to do something like compile or install stuff. Maybe when my Blizzard 1260 is back I will try that again.
To keep the enemies separated I kept the Atari online compiler on a different page. Both are still nicely in use by some people.
Currently I try to find some motivation to continue on the MUIMapparium stuff. I already improved it a lot, especially the route finding stuff but it’s still not ready to release. in FPC I was working on the basic threading stuff, like events which were still missing. It was triggered by a change in the FCL package but need the event functionality. It still needs improvement.