Charlie implemented most of the x64 AROS support to freepascal trunk, most important the syscall. Hence I can use the library units I have already for i386. Of course at first try it just crashes. The reason seems to be that some library calls are not implemented, like Error() in dos.library or CreateRastPort() in intuition, strange I remember at ABIv0 it was written one should use CrateRastPort() instead of self get the memory and initialize… and now its not working anymore. Should be not a big task to alloc mem and call init in such a call? What is the reason of removing such call. Same for Error, it usually just give you the pr_CER of your process so why it can’t do that?
Nevertheless a little bit GUI is working (after dealing with the CreateRastPort/FreeRastPort stuff). The tiny Hello world window on the top right side is the MUITest example I ship with the fpc i386, same for Windowtest which uses intuition and gadtools to oppen window and show a button. the other two demos are fpgui examples.
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 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:
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)
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
I try to find the displacement bug. I do not believe that it is some kind of fpgui bug.. and my debug output seems to tell me exactly the same.. it seems that my widget really try to send the right coordinates for a scroll bar (scrollbar is the most common problem) but the AROS Window does not move to there, but move some pixels more/less (depends on movement directions).
At this point I asked myself, how AROS knows where to paint the window?, because the window is REALLY there.. it reacts to clicks and so on, but the window coordinates tell its at a completely different position. Than I found a strange thing for the displaced case… the WindowLayer (PWindow^.WLayer) is at the wrong position. I can directly investigate after the movement for example the window^.top moved by 15 but the Window^.WLayer^.Bounds.MinY moved by 22 pixel. The difference is 17.. hmm suspicious this is width of the border decoration.. but this window has no border… but of course the top window has one. Solution unknown, I have to think about.
The second thing I investigated was the wrong mouse position in Menus/Combobox. In principle the solution was very easy.. even, again, very strange.
First things first. I have a Zero Zero window as top window usually. ZeroZero because then I don’t need to care about paint over the edge when drawing and do now need to calculate. The mouse position in this window work perfect. Also for borderless window, where I switched off the Zero Zero because do not need it (and it troubles the access, seems AROS still try to remove the borders, so I get negative values in side the Window).
So far it work.. but my Widgets are also borderless windows inside this top window (Parent-Children) and the mouse position in this windows seems to depend in what kind of Window they reside, if the parentwindow is a zerozero window with borders this borders also have influence to the mouseposition in this children. After some forward-backward calculations I think I got it right now. there I also found some bugs for Leave/Enter Events.. and Events to not Active Widgets (Mouse Move).
The result is that the Combobox now work much more smooth, always get the right entry when point to it, you can even close it by clicking outside the Combobox window. Also the Menudemo works much better, get the right selection as expected. If you click outside the menu the menu does not close (ESC close it) but this seems by purpose, but it also does not anylonger click to the nearest entry as before. The only Thing what seems to be a little bit strange: the menu opens directly above the MenuName. I thought its some kind of move displacement or WindowToScreen coordiate miscalculation. BUT for the ComboBox it works perfectly. So If I change it to the right position for menu its completly wrong for the combobox. Also something I have to compare, maybe compare in the FPGUI source code to see why it is different.
The commander like interface works very nicely already. Already possible Enter Directory(Return) and go one Directory up (Backspace), Copy(F5), Delete(F8) (Files and Directories) and Create(F7) Directories. Move(F6) I left out for now… I have to think about because of short cuts if on the same device could use the System function instead of recursive moving files.
‘+’ key let you select File with a pattern, ‘-‘ key deselect with a pattern.
And the whole time I’m developing there was NO CRASH of the Program or AROS. :O I’m really surprised. Seems this wrong focus bug after modal window really helped a lot to bring stability to the program.
But of course there is also shadow.. the Alignment does not Work at all. If I make the Alignment by hand it works perfectly. but if I use Align (alTop, alBottom and so on) it looks VERY wrong… difficult to understand whats wrong there.
Still have no idea how to debug this situation.
After the Shift it-game project I switched to a new project I had in mind already long time before.
A two window file explorer, like total commander, midnight commander or so, for aros in fpc or course.
Yeah I know nobody needs such thing today there are already so many of them out there.
Two reason to start this project:
- I’m not really satisfied with the commander like programs at aros, they all missing a good keyboard control. Directory opus is VERY nice, I even use it at Windows, where it has a nice keyboard control. but at aros, it is an ancient version from the old Amiga there the mouse is for sure in the main focus of the programmer. The keybaord control is very difficult, you even have to activate it everytime you have a new window.
- the main reason is not really to create a useable program, (if this happen also ok) but is more or less and study object to search for fpgui-AROS or freepascal bugs. There still many inside. I tried with the example programs, but there often it just works.. or the program is already so complex, and not written by me. Its hard to track such bugs in code written by others.
I already found and fixedtwo nasty bugs on handling modal windows, so I think it worth to continue.
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)
– 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 http://blog.alb42.de/fpc-aros/ for the last Version