Its not really important to get the Buttons with images on to work, but its a good opportunity to test my way of drawing to standard MUI Classes. The drawing was not a real problem but to calculate the position and sizes is really trouble and much work. I’m still not sure if it is working right for every case (size of Glyph, Length of Text, Height of Text, Position of Glyph). But as first implementation it is ok so.
The other thing , a little bit more important, I implemented Scrollbars, rather easy, just the property names are a little bit strange and the LCL Event was not so obvious.
BitBtn and Scrollbars AROS (top) and Linux (bottom)
Dealing with bitmaps and images, bring the TImage to work. The principle I got from my fpGUI implementation again, using cybergraphics.library (for Amiga, MorphOS and so on maybe need an other solution? maybe also P96 or some native, but for AROS its ok). As start the WritePixelArrayAlpha() the problem it does not scale the image, but it supports Alpha channel so transparent parts are possible. But for TImage.Stretch we also need a StretchDraw, there is a ScalePixelArray() to scale images on drawing, it also supports ARGB, but sadly it does not work in my AROS sandbox. In the ABIv0-oT it does work but sadly the background is black and not transparent. I found that ScalePixelArray() draws ARGB data as 0RGB so ignore the Alpha channel. So not really useful. So I implemented an own scaling routine, (of course only nearest neighbour, fastest way 😉 ).
LCL-MUI TImage with stretching
The Text is not finished, needs some more work, with the clipping. The theory is not so difficult but when how the clipping is removed is my problem at the moment. The font is still wrong but also easy just needs some diligent work… works exactly like Pens and Brushes which I implemented today. I started with Pens and Brush because it is much easier, next step will be font, I guess and then care about the clipping again. To test the Pen and Brush I used a PaintBox with different colors, with transparent brush. It’s not perfect but working.
PaintBox (Left) and LabelTest (Right)
Working on the Drawing routines for LCL MUI/Zune, there is a Page describe a little bit more about how to implement a new Widgetset also how to make a TLabel. It is working more or less, the Label is painted alos repainted on resize window and so on. But it is on the wrong place. In the example the „clicked“ in the lower left window show be somwhat centered above the button. But the coordinates for the Textout always point to 0,0. I guessed it have something to do with the region defined. I tried to implement it but still it looks like this. Needs some more thinking.
Progressbar, Label, Timer in LCL MUI
Because not so much time and mood for the label things I switched to some easier tasks and implemented the TTimer and ProgressBar, both very easy things.
For the Wiki I tried out every single item in the list and wrote down which is working and which is crashing or error message. Then slowly I can remove all this crashes. the Form I used for this experiments is shown on the right side. Of course I removed all the crashing and Widgets with error messages from the view before. Still much to do. 🙂
Some time before I created a own MUI/Zune class with freepascal to check how this is done and if it opens the possibility for ownerdrawn things in LCL with MUI. It worked but then I put it aside and didn’t care much about, but now as I restarted the MUI Interface for LCL I got it out again and tried to implement.
It’s called LCLGroupClass and created with (MUI-)Group as Basis. In principle its just one difference, The MUIM_DRAW is handled by installing a clipping range and call the OnPaint Event of the connected Pascal object, which then send the paint message to the LCL-Component.
But this was only the half way to go, the paint message also must do something or I can not check if it work. So I traced back the Panel drawing routines to the basic platform dependant function to draw and implemented them to the LCL MUI interface: DrawText and Frame3D. First it looked very easy, espeically the text drawing… but it became tricky again because the GetClientRect routine also have to work properly. The Documentation is very thin about this things, mostly non-existing. But when trace back it become obvious that LCL is still a one-to-one conversation of VCL and hence of Win32 API. So the MSDN help, which is really good was very helpful to find the right way to implement the drawing functions.
Thats the status now:
LCL MUI Panel in comparison with Linux LCL
As you can see the normal Panel border look already very like the original (atm there is not color support so I just use black and white for the shadow/highlight color, Maybe later would be interresting to find out the MUI settings for shadow and highlight) and the Text is more or like in the middle of the panels.
The Panels are still completely transparent, I guess because I still didn’t implement the FillRect routine which is used for initial cleaning.
If this is done, I think I do not need to call the original MUI drawing routine anymore, just use the LCL drawing.
Native Amiga OS sadly does not have the Parent/Child window concept, which I need to implement fpGUI for it (every widget is an own Window). But the m68k AROS of course have this concept so it should be rather easy to bring it to at least a classic machine 😉 . I guessed it will be slow but I had no idea how slow 😛 the compilation of fpgui needs around 10 minutes (in my i386-aros some seconds, even my slow Server with Atom processor only needs around 10 seconds 😉 ).
The only „new“ thing I needs for AROS is the Parent/Child windows, which all reside in intuition unit. So I copied the intuition.pas of Amiga and copied the TWindow structure from AROS into (and renamed it to arosintuition). Some hlper function/constants are needed as well (NP_PARENT, to assign the parent on creation, IS_CHILD(), HAS_CHILD() function for status checking) and finished.
I had to deactivate some String things (mostly path/assign/drive checking, because they use BSTR)
And it worked on nearly the first try.
Problems appeared on Filerequesters, first of course because I did remove the BSTR2String conversion which was easy to reintroduce, but It seems the TDosList structure in Amiga unit is wrong, at Least I do not get the right output if using this one. I copied the one from AROS over, and it works. hmm maybe I have to check the original Amiga SDK, or some kind of alignment problem again?. The second problem in Filerequester was that the file were not visible… the height of every entry was something like one pixel 😐 strange problem. After a while testing of other programs I noticed that every picture is missing (in the screen shot there should be a picture on the Stop Button). SO I tried to trace back whats the problem, the BMP reading routine is just not Big endian compatible, its only little endian. SO I had to add some endianess conversion routines.
And finally it works and looks good.
The next logical step would be to try to compile LCL/Lazarus with m68k-aros and this fpGUI implementations as I did on i386. But BAD News from this side, this is not possible, and maybe it will be not possible soon. The problems appear from a rather unexpected side. LCL need resource Files, but this resources are not implemented for m68k-amiga and as long the file format is not ELF I’m not sure I can use the same resource compiler as for i386-aros, ok let’s say I’m rather sure I cannot use it ;-). That means LCL moves very far away for Amiga or even MorphOS, even I try again to implement a MUI-LCL interface.
Today I brought back the LCL for i386-aros to life, I started from zero, just checked out the lazarus svn trunk, and tried to compile.
of course it does not work at the first try.
I would not believe what was the most difficult step… it was the makefile creation. :O I had same problems… but good that I implemented the environment variables so I can use them to force the fpcmake to work.
The next point are the UTF8 function for file handling. And when I look into the source one could get in rage… seems the bad behaviour
{$ifdef win}
Winthings
{$else}
Unixthings
{$endif}
become the usual way to do it!
There are platforms out there which are NOT Unix and NOT Windows, Aros for example 🙂
Why not:
{$ifdef win}
Winthings
{$endif}
{$ifdef unix}
Unixthings
{$endif}
or even better: 😉
{$undef ThingsImplemented}
{$ifdef win}
{$define ThingsImplemented}
Winthings
{$endif}
{$ifdef unix}
{$define ThingsImplemented}
Unixthings
{$endif}
{$ifndef ThingsImplemented}
{$FATAL Things not implemented}
{$undef}
I will never understand that, it is really trouble and makes the implementation harder than it have to be… because sometimes you get error messages from unix, sometimes from windows implementation, or it just compiles but gives completely non-sense results (mostly path things). And then you have to track back where this was included and why it tries to use the windows/linux things.
the good thing is in LCL seems not such things.. so it seems to be really platform independant, but the lazutils is horrible.
I worked a little bit more on this mouse movement problem and I think now I got it and voila also the displacement bug of Menu disappeared. so now menu and combobox looks ok to me.
The maximus editor didn’t start at my machine anymore.. a little threading bug was the reason.. I didn’t know they use threading… in a EDITOR! how useless.. seems its meant to check for filesystem changes. But… to be honest.. a Timer would do it in this case.
I wanted to try maximus because I remember there was a strange font bug inside: The position of cursor does not fit to the char position. I tried a little bit, but in the end I have to say.. the maximus ist just poorly written. It just takes a width of a char to calculate the cursor position. By default a fixed width font is set, of course with fixes font it works. But this font seems not available by default in AROS so it uses the default font which is NOT fixed width. If no ini file is there for maximus it uses „#Edit2“ as the default font which is „Courier New“.. I changed the default to „ttcourier“ which is available by default in AROS. The #Edit1 I changed to „fixed“ which looks nicer for me. but also other fonts like sans mono or so work nicely.
The uidesigner is working.. but the movement of items is hard.. because it always jumps around. I noticed a hack in the GDI (Windows) implementation of FPGUI which captures the mouse when the editor is there. I also implemented this behaviour and now it moves smoothly.. In fact I did implement before already.. but the initial call to activate this function was missing.
As last I tried every single example in fpgui (/example/gui) and the most of them work really nice now. There I found a strange bug for TimerTest or animation examples.. seems the timer fire very seldom.
Initially I thought the reason is that there comes so seldom messages from aros.. but then I measured the time between messages and it is really short.. 0 to 20 ms, so no or one task switch. so thats not the reason it fires so seldom. In the timertest there is a Timer should fire every 50 ms but it looks more like 500ms-1s. Finally I found the reason, the time when the Timer should fire is determined by a Now() call. My Millisecond count in the result was just wrong, alawys an order to small. Type mismatch in the converter routine.
So now the animtest also works rather fast.. hmm I always thought my image drawing routine is so slow that I should improve it, seems it is not THAT slow 😉 OK in the colorwheel example you can see that it is VERY slow ;).
I think this changing are very important, it really improves the fpgui functionality a lot. So I created a release today for public again.
Available at the FPC DownloadPage
Today I bring all together and release. A not complete lists of changes/bugfixes for this realease:
* some basic units moved from arosunits to rtl, also helpful if later joined with amiga and morphos
– amigados, agraphics, exec, inputevent, intuition, layers,
– longarray, pastoc, tagsarray, timer, utility
– IMPORTANT: DELETE UNITS BEFORE INSTALL NEW VERSION TO GET RID OF UNITS IN OLD DIRECTORY
* changed all library calls to cdecl
* Startup and finishing code improved
* FileGetDate/FileSetDate implemented
* GetEnvironmentVariableCount/GetEnvironmentString implemented (example code by magorium)
* Video unit with fullscreen support (color tag = False)
* Keyboard unit rewritten, better identification of keys for fp ide, mousewheel as pgup/pgdwn
* free vision GetDosTicks implemented (needed for double click)
* layers aros unit (thanks to anon and magorium)
* FPGUI:
– MOUSEENTER/MOUSELEAVE implemented
– MOUSEMOVE with mouse grabbing
– KEYRELEASE implemented
– Input focus implemented
– Modal windows, blocking of other windows
– save closing of window (removing of messages from message port)
– combobox closing when a entry is selected repaired (hopefully)
check out https://blog.alb42.de/fpc-aros/ for the last Version
I got a new interesting bug report… about non working Now() function it always gives the same date and time (something 2112 , wow so later already i missed some time seems).
I was astonished that the same routine like the one now() uses to gather the time works when I directly type in into my Code.. so the error ONLY exists inside the RTL – unit
This bug was very hard to find, seems everything was ok.. just the DoIO for the timer.device returns with IOERR_NOCMD which means the timer.device does not support getting of date/time… really strange… i tried out some thing an noticed it already is strange before when create the timer (which i need to get the time).. the Base Pointer for the timer device was always NIL.
Then finally i got the right idea… I compared the structures for the aros units and for the rtl.. they looks equal BUT there was a tiny difference… the records for the rtl (which doesn’t work) were defined as PACKED record… in aros unit (which works) just as record, means aligned, VERY strange hmm even for Amiga this would meet a problem? Now I changed everything to aligned records and it works…. sometimes easy errors so hard to find.
