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 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.
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.
Still playing around with this raytracing routine, implemented a better GUI, full MUI of course. It looks very like the one from WireDraw… yeah, I just copied that and replaced the engine, simple as that ;-). Added movement and rotation of the camera and a List of all items so you can move one after the other, and of course calculate that in high resolution and save it. Yeah, just fun no real use but it’s to damn hot for serious work. Would be interesting how fast that works on MorphOS, especially my G5 2.7 Ghz maybe try next week.
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)
Working again a little bit on MUIMapparium. I want to include some more features before the next Release 0.5. I included marker for the plot which is then also shown as little triangle in the map. I’m not really satisfied with the colors and visibility of the current open track and marker for the point maybe I get a better solution later. The marker is atm. only one pixel wide, in principle it would be possible to make it 2 pixel or 3 pixel, but that looked a little bit too massive.
MUIMapparium with Track Marker
Another thing I wanted to include for the next version are calculated routes and maybe also photos with EXIF tags. If this is done MUIMapparium has the same Featureset as Mapparium, even a little bit more. I started with Routes which is not very difficult, some routines even can be reused from tracks drawing and so on. It only loads tracks from gpx files currently (created by Mapparium for example). The creation of a new route will be the next step.
MUIMapparium with a Route
Also visible in the image is the new possibility to disable all Marker, Tracks and Route drawing. Helpful if you have many items and want to concentrate on the Map or so (or just to increase the speed).