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.
The image drawing in fpGUI was always a bad point, the routine to draw was simple and slow. I always planed to create a new one to increase the speed. This days I had time and mood to change it, so I introduced the cybergraphics unit to aros and wrote new routines to make the image drawing. Its much faster and much more elegant than before, especially the masked drawing does work now correctly. The old routine was juat a dirty hack to emulate transparent drawing.
The second point at fpGUI is the font handling. The strange thing is, there is a flag for bold and italic design if you load a font, but the most fonts only support the italic style. For bold style a second font is supplied which is named „fontname bold.font“ with various format, sometimes with space between words or minus sign or just without anything. My new font collector try to bring such cases together, try to identify fonts which belongs together, by name.
If noone reports errors or wishes for fpGUI, fpGUI is something like „done“ at the moment. Of course its not really done. But it is working very nicely and stable without big problems or limitations (except the displacement bug which I explained some weeks before and seems to be an AROS bug).
Which brings me to the third very big point, the LCL-MUI/Zune interface which I try to resurrect. I gave it up long time before because the zune, interface is/was so buggy and I didn’t saw a way how to continue. Now the Zune bounty is going and the ABIv0-on-trunk already has some Zune improvements. Some of them I already found. My development system is on a very old stage, but I also have a new sandbox to try… and for StringEdits I noticed a change already. The On Value changed event is fired now, in my development system not.
But still the LCL-MUI interface is in a very early stage, not much things working currently but I will continue to improve it continously. Maybe it will reach a usable level.
This means now you have two interfaces to choose for lcl programs, fpGUI or MUI/Zune, as long as the MUI/Zune is in such an early stage fpGUI will stay as the default. If you wish to test the MUI/Zune interface you can activate it by a compiler switch: „-dLCL_MUI“
As an example I compiled the Editortest, which I created long time before for a youtube video with both interfaces and started them. I changed the TextEditor.mcc background to easier identification of the MUI/Zune interface and as a proof that it does care about the global config.
fpGUI LCL and MUI LCL
Please note that both compiled from the same source, the only difference is the compiler switch.
I put this all together and created a release of all this stuff, maybe someone has fun to play with it.
Download the newest Version from: FPC AROS Page
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.
The Threading is a very difficult thing. The AROS side is working (I guess) but the fpc side is not working properly this time. Everything works fine as long I do not use and AnsiStrings or WideStrings inside the threads. The memory manager destroys the stack of the threads and at the end it will crash, always. The only way I found, until now, to stay with shortstrings. It must have something to do with the threadvars, that are variables with different contents depending in what thread you are. I try to figure out what to do to get this threadvars to work. Long things short I failed … seems there I really need help. I think my thread implementation is wrong at the moment… I implemented the TThread class there I call the AROS threading things… but it seems to me that there I only need to call the abstract functions of the Threadmanager and implement the threadmanager functions for starting threads. (I only implemented there the Crititcal sections). But because thats not a class its a little bit more difficult.. and I do not see it become would better there.
A big problem is the debugging… there is real useable debugger.. I tried once with the hosted compile with debugging and then with the linux gdb (thats the suggested method). It is really bad, you can not really trace the program, because the whole System is with debug informations he jump here and there…. seldom come back to my program.
So in the end there is only the debug output for debugging. Long time before I introduced the Debugln() function to AROS so one can easily write Debugoutput to the error console and show in the hosted linux shell or open sashimi and see directly in AROS. Sadly both are not very comfortable ways (but fast 😉 ) both are lacking of informations who sent the output and what time, for me with threading always important informations, So I always implemented that inside my threads, which is bad because I need strings for that :-P. And in principle the information is there when the debug output is written.
The solution is a little program to catch the debug output identify the task and notice the time. I gave it a little fpGUI interface for better handling. As long the complete AROSbox crash sometimes without giving me the chance to read the output i included a network interface. The messages can be sent via UDP to a windows or linux slave program who show it or sent it further to a file or system log (Linux: Syslog viewable with tail, Windows: OutputDebugString, viewable with DebugView from Microsoft)
it gets an own page:
AROS Debug View
I ported the sockets from the aros branch to the trunk. was not difficult, but later I have to check for more constants and so on, I think there are missing a lot of them, I just introduced some which are needed.
So ArTorr compiles with the new trunk fpc. (An other advantage that I didn’t use threading 😛 or I could not compile it)
ArTorr compiled with trunk Freepascal
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.
The integration of AROS into FPC trunk works very nicely already, I decided to make the first binary release of freepascal for AROS. I changed the installation a bit, introduced the package system to freepascal, so you only need to copy the folder to the harddisk and make sure the Envarc:sys/packages/freepascal points to this directory. (Which can be done by executing install script in the freepascal folder.) The package-Startup will then create all assigns ans pathes needed to operate fpc.
Until now the trunk fpc, the latest fpgui (1.2) are included, lcl/lazarus I didnt try with the new trunk version, I think later I will try also to update to the latest lazarus release and try to compile, which will need again much work I guess. As long as there are still things missing, I will supply both versions for download.
For the trunk integration I always need to check if this things also work at Amiga/MorphOS. I’m very happy that Amiga is working again. Its not so easy to cross compile it, until now I only got it to work on a i386-linux, but not at my x64 machine, the binutils does not want to compile currently.
Thats the reason I also prepared a freepascal m68k-amiga version. This should also work on a m68k-aros machine. At the moment I can not try, as long AROS vision and the nightly AROS iso seems not to work at e-uae at linux. Because its an amiga release (and not AROS) it only contains the Amiga functionality, so no FPGUI (there I need AROS special functions) but the FP-IDE is included.
There is a dedicated page for fpc-amiga:
FPC Amiga/AROS m68k
The AROS (i386) can still be found at:
FPC AROS
Today I finished the ArTorr 0.1 Release.
Download:
ArTorr 0.1
News:
- New fancy gui, with pieces and availibility view and more 😉
- Piece-get randomization
- Can be started from shell with torrent file as parameter
- If no parameter given a requester to select will appear
Howto:
- Download the archive
- Unpack at a location you like (in the archive is a Folder with Icon)
- Navigate to the ArTorr Folder
- Start the Program by double click onto the icon
- Select the torrent file
- See how the download goes
- Press quit or close at any time to break the download, the download will be continue when you restart with the same torrent file
- Downloaded files can be found in „Output“ directory in the ArTorr folder
Atm I’m very busy to bring the AROS-fpc to the main branch and also play a little bit with the Amiga Freepascal (I want it for comparison with AROS). So there is only limited time for ArTorr.
But today I bring the new GUI to live already working rather nice. Ok behind the curtain still much to do. I have to think how to prevent, that the gui has to access deep into the Torrent class properties to get all the informations to show. There should be a better solution.
My original plan was to introduce first seeding to ArTorr and then create a GUI, but hmm I have more fun with GUI creating currently. First time I really use the uidesigner for a little bit gui creation (not only testing)
The final ArTorr LAyout looks at the moment like this:
(I filled the pieces view with some random Values, as it will be later, red missing, yellow downloading, green arrived)
