There is a Window inspection tool in AROS called WiMP sadly it does not show Parent relations for the windows, which i use now intensively.
So i wrote an own program to inspect the windows also bring them to front an paint a red border on it (see screenshot) and show properties (especially the IDCMP flags and flags as Text not only as number).
It was a good way to find bugs. Some small I fixed already. A big one hindered me to write the program directly in maximus compiled on AROS. Some keys seems to send a double key to the GUI mostly when Shift is pressed (for example Shift-L seems sends also the key-up to the gui so the cursor goes one up then write a big „L“), need to debug. but besides this problem it worked rather nice. Also the UIDesigner worked rather nicely to place buttons, edit properties, even movement of items is very slow and atm. its not possible to delete items placed (have to check why).
The Source is included of course.
I want to supply some more informations about the current FPGUI implementation for AROS and about the lcl problems.
First about known Problems (starting from worst):
– sometimes a dialog window freezes complete AROS, when closed via OK button -> workaround: use X of window to close
– crashes in HandleAlignments there are some problems with alignment resulting in circular calling of size function -> there are some code to prevent this but it seems its not always working, big windows with much items and much alignments still produce crashes in „HandleAlignments“
– There are 2 types of windows in AROS, „normal“ windows and GimmeZeroZero(GZZ) windows, the only difference is that the 0,0 postion on a normal window is on top left edge of window decoration and for GZZ 0,0 is top left edge of user area. Atm I use GZZ for windows without a parent -> so real windows with decoration and so on. and normal windows for all items inside the window(Buttons, Labels and so on). So far ok, now we approach the problem, I guess. Popupwindows like Menus or combobox windows have no parent either but they are borderless. Now open a menu by clicking on the entry, the menu opens some pixels to high but the mouse position is at the real position so some pixels under the drawn position. Now guess how many pixels… right, the displacement is exactly the width of window decoration. I changed this behaviour already some times… but always i get the problem: I get this displacement of menus or the click on Buttons and so on does not work anymore because of displacement. Needs a little bit more thinking about „window“ types I guess.
– File requester does not work when starting on drive level, When choose for example „SYS:“ an empty list is shown, sometimes a list of SYS: is shown but when click an entry it says can’t open it. -> Path converting routines still not working for aros well. (maybe change the filerequester to native AROS but it would need a big impact to the „core“ fpgui)
– Mouse over, MouseEnter MouseLeave still no way to implement the mouse enter and mouse leave routine and send the mouse move event to the item under the mouse, instead of the one which have the focus (except the capture mouse routine is called). -> This needs some thinking I guess and again the problem -> which item is under my mouse pointer… which I skipped by changing all items to windows, but now it catches me again, I just hope to find the window under cursor is easier, still had no time to check.
– change of focus with Tab does not change focus in AROS, create 2 edits typesomething in the first, press TAB type some more, cursor is drawn the the 2nd edit but new chars in the first edit. -> needs debugging
– Drag and Drop does not work -> no idea how to implement currently because I dont know how this is working in AROS/Amiga
– Splitter does not work well -> needs some debugging to see why you can’t grab the splitter to drag it.
– Mouse Pointer, The change of mouse pointer is not that easy on AROS (except busy pointer)
– Missing concept of modal windows (The „modal“ windows are just normal windows atm. so all other windows are fully functional)
– Missing Clipboard, I just never cared about up to now (at AROS or Amiga i never used up to now)
– Timers does not work well atm, I’m bound to INTUITICKS recieved by window around one per 50-100 ms, no extra event for timer events -> thinking about writing an Interrupt routine for Timer and send a IntuiMessage to the window.
– Hiding of windows is not possible in AROS atm. There is a function for it in intuition.library but it has some strange effects if the hidden window is a child window (has a parent) complete aros desktop get strange effects (see also Thread in AROS Forum from 2009! the bug is still there) -> Workaround: I change the size of hidden windows to 0,0, which will make strange effects from time to time. An other thing I could do is to change the parent to an hidden window but I’m not sure hpw to change a parent of a window, must first try out in a seperate program, I guess.
canvas drawing problems:
* Line thickness: seems the standard draw routines only support single pixel lines, there is an option for line thickness but it simply does nothing.
* Arc: I did not find a function to draw a part of a circle or even a filled circle, Area functions could be the answer but I had no time to care about because its not a serious problem at all.
* Fonts: Aros/Amiga fonts are a little bit different from other systems. Normaly on Aros font files only contents a single font style normal or bold sometimes italic. Some fonts have the possibility to be changed to Italic, but changed to bold I never found such font, its always saved as a separate font file.-> Could be solved by including possibility to load TrueType fonts.
* I included buffered painting to the Canvas routines, thats the reason it becomes much faster than before, but its still rather slow (compare examples/sprites on Aros and linux or so). The reason is still the difficult way to use colors in aros, with obtaining pens and so on. Sadly it seems there are no new functions directly support chunky modes and 24 bit…. When first copy everything into a non visible RastPort and then justBlit it to the final RastPort, the colors are just not there.. everything is black except 4 first colors. An other thing is masking which is also not easy in Aros with standard procedures.
A Sidemark, the Source Editor Maximus working rather nicely now (of course not completely). The UI Designer works even better but the source created can not be compiled due of wrong(old) uses, but this is also a Linux not working.
Lazarus/LCL:
Lazarus changed a lot this days, I think to get to the 1.0 release. Sadly this makes for me very difficult to compile LCL for AROS (MUI or FPGUI) because now there are much function special for Linux/Windows. As I begun to check the problems I noticed the ,ost of their new things are related to 64Bit and WideStrings,UTF8 and such things…. and no fallbacks to the original functions of Freepascal. At the Lazarus project they have a very bad behaviour to define „not Windows“ = „Unix“ and „not Unix“ = „Windows“which is for sure not true for AROS. So much work for me to change all this statements. but finally I was able to compile lcl and some demoprojects
This compiled lcl is not included in the current release (28.12.2012).
My findings:
– fpgui interface for LCL still very unfinished, TLabel for example still not working, OnPaint events not fired
– perhaps useful for debugging my fpgui things, because Radiobutton does not work but the LCL gives me an error message I could follow to see the reason, perhaps here also a check in Linux could be helpful
– A new „customdrawn“ interface beside fpgui this time directly in lcl, which could be interresting as alternative to fpgui (but changing again…? I’m rather happy that fpgui is working somewhat). The point at fpgui I like is, that the corelib abstraction layer is really simple to understand, so I can concentrate on the AROS problems of the implementation. At LCL this custom drawn interfaces looks much more complicated to understand even the functions should be comparable
The last month I was working on a complete rewrite of the FPGUI native AROS interface.
I found out that AROS allows to make windows as a parent to a window (in contrast to AmigaOS) so now every item on the screen is created as a window. This makes it much easier to handle events especially paint with overlapping layers and so on. Its far from perfect but I think thats the better way.
Sadly I found again a drawback there exist functions to show/hide windows in Aros, but they DO NOT work, especially the HideWindow function. Seems its already known in Aros forum long time and still not changed, so I made a workaround and change the size to 0,0 when a item is Hidden, not a nice way but at I have no other idea.
I’m rather satisfied with the result as it is now, so i put it on to the links for download (together with the source of aros fpgui).
long time no blog entry… too busy over all work.. house.. family too much to do besides programming.
Some days before some guys asked me to bring the aros fpc into the official Sources. So I created a Patch and announced at mailing list, then Charlie and Florian contacted me and I got an own branch for aros. First aros will be implemented, then checked (I guess by Charlie?) and finally, hopefully come to main trunk. After it, it would be a very good idea to bring the 3 Amiga Systems together (AROS, MorphOS and AmigaOS) Charlie did the implementation for MorphOS, I did Aros… so there should be enough knowledge to bring it together to a much smaller codebase.
Besides this today I checked a little bit about bug reports/wishes… first is rather strange… when you open a Modal requester the Windows behind should be disabled/not click-able… and Aros „shows“ also so.. so if you try to click a Button it shows no click animation. But after closing the modal requester all your clicks done meanwhile the requester was open will fire one after the other…. very bad! … the MUIA_Application_Sleep let the application and all windows sleep.. and shows a Busy pointer… but even here you can still click the button… So now I took the hard way…. I just deactivate all Windows before show the requester.. then it really works.. its just slower because the window must be redrawn.
The second thing is the OnChange Event in the TMemo now always fired when there is a text change done. This was again a rather easy thing… ok also needed long time.. but just because I forget to set the Hook-procedure to stdcall… seems too long I didn’t care about Events.
Uploaded also a new Version of fpc (Link section)
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.
Before the Selection in a TMemo seems to be a big problem…. in fact it was not I just misunderstood two function of this TextEditor class.. The main problem was not to get or set the selection.. but the style of LCL to set a Selection Start and a End.. MUI expect an x and y Value for start and end…. so the conversion was the main problem.. ok not a big problem just needed some thinking. and.. its done.. now you can set and set the selection inside the TMemo.. hmm seems the TMemo will be by far the feature-richest component
Connected the OnActivate Event for Windows as requested.
As second Task I cared about Timers. The principle is rather easy, I just create an array of the call back routines, with the interval length and the time of last call. The time values are stored in a Type Ttimeval which is a record with two longwords one for second until 1.1.1978 and one for microseconds. When get the current system time you will always get rounded to 10 ms exact value… so why they extended it to microsecond? because they guessed for far far aways future… who knows. Exact timing better than 10 ms is also not possible in Windows (except you decrease the size of a time slice to 1 ms or so) because one time slice is around 15 ms (depends on Windows Version). So this is more than enough for the TTimer component in LCL. The time Interval should be always taken as the MINIMAL time before fire again (can be a little bit more always, like in windows/linux as well)
The screen size values are rather easy to get from the PScreen structure in AROS, but to give them to LCL TMonitor was rather hard work.. i had to step through the gtk-widget to find all calls needed for it. So now it Works… with Forms.Monitor.Width and Height you can read out the screen size.
Also removed a bug in ComboBox.. since my dirty Event hack the OnChange Event was not fired anymore.
The name of the current binary distribution of FPC + LCL for Aros now contains also the Date for a better identification of the last Version and changes. There is always a Link to the current release in the Link section on this Page.
Today i again looked a little bit closer on the Memo component and include some features:
Copy/Paste/Cut/Undo can be called from Program.. not only from the keystrokes already defined in the texteditor component. Additionally the Caret position can be read (Row and Line position) the justification of text can be changed to left, right or center.
seems there is no direct way to mark a text part (just a strange way I currently do not understand) and even NO way to read out what is selected at the moment. so selStart, selLength will be hard to implement
I really think about to replace the EditBox by this TextEditor Component… just limit it to one line.. only some minor changes must be done for it, perhaps later I will try.
Yesterday I included repainting of Components on change size, width or parent (seems the parent still doesn’t work well).. still some crashes of MuiTextedit when creating and call to redraw… seems I must test if it is visible before, then the crashes disappear.
Panels now also usable as grouping component. hard to see where the panel is everything is gray:
deBlob catched me and now we have colors, so all Area descendants can have a color (or even change) (atm only the background color) the style is again (like always in MUI?) rather strange.. you supply a STRING with 32 bit color informations FOR every color so white looks like: FFFFFFFF,FFFFFFFF,FFFFFFFF but of course the information in lcl all only 8 bit per color: FF,FF,FF, easy solution just print four times the red, green and blue value.. seems that is ok… the color looks equal in linux lazarus and Aros program.
The Button 3 is inside of the Panel… but in MUI is drawn over the borders of the Panel (in Linux/Windows not!). but ok normaly nobody should do such things by intention.
Another problem with colors are the special Windows colors (like clBtnFace) which are not really colors but something like colortable entries (depends on the theme for which color it stands).. it can’t be translate to real color. Perhaps later this could be used to also set the special colors in MUI like MUII_ButtonBack and so on.
The bug that assigning a new Text to the TextEditor (instead of loading a text from file) is also removed… should be now as fast as loading from file (only one drawing after all contents is loaded into the object)