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. 😛
The creation of vlink and vasm for Amiga is always a little bit difficult, hence I seldom do that. But Charlie told me, that the creator of vasm and vlink also supply executables for most of the platforms. Even the rather uncommon 68k asm with standard syntax (instead of Motorola syntax) are there. Long text, short meaning, the vlink and vasm for Amiga 68k, Amiga OS4 and MorphOS are updated in the nightly Release packages. And with this it will be much easier to keep them up to date.
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.
I checked the ASL.library units of MorphOS and Amiga 68k against the official C includes of the SDKs. Especially the TFileRequester structure was always a little bit trouble because the old Amiga asl unit still used the old field names rf_* but from V38 of the Library this fields are all names fr_* and some other tiny dame differences (e.g. Dir vs. Drawer). In AROS and AmigaOS4 I only added the newer names because here I do not have any “old” code. This resulted in a big inconsistency between the platforms and need ifdef’s in the final programs. To prevent a direct breakage of the existing sources (e.g. LCL, MUIMapparium) Amiga and MorphOS have both field names in the structure (as case). The aim will be to remove that ifdef’s from the sources.
Finally found some motivation to work on the route display not so difficult at all. But the search for the route I need to think a little bit more. Until now it only shows the saved orders. On double click it jumps to there and also shows the described route points in a different color. That should be ok for now.
Due to user wishes one can now change the color of each track and route individually, which is also saved to the GPX File. Routes and Tracks in GPX have an extension area where you can add own properties without violating the GPX format, which is very nice. The Routes and Track property window have now a Color Button next to the Name to choose the color of the feature (you have to save that before the change is visible in the map).
In principle it would be nice to have the color next to the name in the Track/Route List as a little colored square (like I did for track plot axes). But I’m not sure if and how that is possible at all for such a list, without creating a selfdrawn one.
Besides that I implemented that MUIMapparium remembers the position and open status of the Statistics window, seems some user like to keep it always open to observe the loading status or something like this.
Do you read journals…? I’m not. I seldom read such things and if it happens then science related. But there is still an Amiga related journal the Amiga Future. I saw it once or twice at the Amiga meeting here in Berlin but never actually cared about. But maybe the next issue would be something worth to buy 😉 Especially the one article which already has a preview there.
I decided to release the next Version of MUIMapparium even not all features are finished as I planed just to get the bugfixes out. Routes (calculated directions) can be loaded from GPX and showed on map. But I did not implement the route finding and direction command showing until now. Especially the Track curve plot was still very buggy, and of course I described in a previous blog post the pixel to position calculation which is now much better, much more precise but also much slower than before, with FPU it does not make big difference, but with SoftFloat not really funny. Routes and Tracks are now pre-calculated for the current zoom level. If the zoom level is very small and the track therefore not really good to see, only some pixels wide, it does only paint some points of it, which makes the overviews much faster. Still, with SoftFPU on 68k it still will be too slow if you have some Tracks/Routes. The drawing of Tracks/Marker/Routes can be completely switched off in Menu or buy a FPU 🙂 The package for Amiga68k does contain a FPU and Non-FPU.
I also created a little GPX file with a Track, some Markers and a Route to test the features. (Even you can use any GPX/KML/KMZ/FIT File you can find on the Internet as well)
Bugfix: imperial units
Bugfix: key mapping
Bugfix: 2nd track curve drawing
Bugfix: Date/Time loading from GPX,KML,KMZ files
Level of Detail for Tracks
Precalculation of Trackpositions (Speed optimization for NonFPU systems)
Marker in Plot, shows also a marker in the Track
Turn off Marker, Track and Route drawing via Menu
Define Directory for Images via ToolTypes: e.g. DATAPATH=DH1:TmpDir
Change find IP to freegeoip.net (old one is too slow currently)