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.
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
