Open Source GUI Library for Assembler

[AGS]

Hi there ASM coders

Open eXternal User Interfaces (OX) is an Open Source Amiga OS GUI Library written 100% in Assembler and optimized for usage from Assembler programs. You do not need to know how to code Amiga OS compatible, you only need to know Amiga 68k assembler. The library does the rest: resizeable font-sensitive frontends, gadgets and widgets.

With OX you can define your whole resizeable GUI by only a list of dc.l statements. No need to call system functions. No need to care about layout, colors, skinning, user-input-messages (ports, wait-loops), tasks and processes. It's all under the hood.

This GUI Library is looking for coders who would like to use it in their programs or who would like to extend its features. Making GUIs with this Lib ans also writing new reuseable GUI elements (external classes) in Assembler is absolutely easy. Questions are welcome and my help and support is promised.

If you are interested or have questions, please leave me a message here. Of course there is going to be a download then.

cheers
AGS


PS / EDIT Jan. 10. 2014: latest download: http://images.quicktunnels.net/openxui_latest.zip



Optimal for coding little tools.

[Thorham]

Interesting

Any links? Also, which OS version?

[daxb]

I thought you stopped development of the gui lib years ago (related to amiga-news forum)? Do you restart again?

[AGS]

Ok, here we go. :-D

This is an example reuseable widget built from some gadgets:



And here is the full GUI definition for the test program that make use of it and adds a "set to red" test button to set the color of the widget to red:



(actually the "set to red" button is not part of the widget but part of the test program that uses the widget)


Here is all you need to try this on your system:

EDIT: update available: http://images.quicktunnels.net/openxui_latest.zip

Some Demo sourcecodes (phxass) are in the archive. For more please write me. It runs fast on UAE and such or on Amigas with PPC, always OS 3.1. Not yet tested on OS 4.x but the previous version did also run there. I did not test it on classic Amigas w/o PPC since some previous version because the jpg/png skins slowed it down there ...

Please give me suggestions and ideas for which little tool(s) to code using this GUI.

I am doing more on it again because there is someone who needs it for his tool. How much I do, that depends on coders interest and feature requests. Creating new gadgets/widgets is so easy.

greets,
AGS

[Thorham]

The demo programs crash on AOS 3.0 (68030)

[AGS]

OK, this is Work In Progress. Do they run on OS 3.1? We tested them as I wrote and it worked.

PS: I just discovered there seems to be a problem with the boopsi colorwheel gadget. In the way I use it in my code it seems to require OS 3.5 at least. Please try.

[Thorham]

Can't try, only have 3.0, sorry.

[AGS]

I replaced the download with a version that should not crash on OS below 3.5:

EDIT: update available: http://images.quicktunnels.net/openxui_latest.zip

... we tested it on different setups. also on 3.0. If it does still crash, please provide me details about your system. Are you using an emu or a native Amiga? Do you have a PPC board? Are you using patches like in AmiKit for example? Do you have an MMU and/or Enforcer or similar running or some NoGuru patch installed?

[Thorham]

Tried it and it still crashes

System is an A1200 with Blizzard 1230 IV 64 MB, with MMU, without FPU. OS is AOS3.0 with MCP, some env variable handler (forgot which one), Fblit/Ftext, PeterK's icon.library replacement and NewIcons. Filesystem is PFS on all partitions and IdeFix for more than 4 GB disks.

I don't use any MMU software at all, except enforcer for debugging purposes (VERY important ).

[daxb]

My system config: A1200 040/40 32MB 3.1

On OS3.1 this Information requester text is shown when oxlibinfo is launched: "colorwheel.gadget version 44+ required"

It seems that sometimes (yes) open xui just crash the system. I got no guru, muforce hit or muguardianangel hit. Overall the gui is slow. I remember (some years ago) it wasn`t that slow. If I had muguardianangel running oxui suddenly open a full screen window and the information window was empty. The newsting class looks wrong (the dropdown menu the font is cut below some pixel).You might do some wired stuff because the SGrab window snapshot has no boarders as you can see:

[AGS]

@thorham Ok, thank you. Please could you provide me debug output, some code part where it crashed or such? (if it happens in part of my code so that i can locate it)

@daxb Thank you, too. Yes, the colorwheel v44+ is required (OS 3.5). Did you test the "xuitest_colorpicker" also? It uses only a few classes. The newstring problem is known, the others are new to me. It is slow w/o PPC or UAE. You can try to turn the skins off in oxlibinfo. This may speed it up a little bit. I am not aware of what weird Stuff I do. Maybe someone wants to look at my window-class code?

[daxb]

I started xuitest_colorpicker and it worked as far as I can say (color changed when edit the values). I had already set skins off and switched to 4 color mode to max speed. If you target open xui to PPC then it migth be not worth to test/support 68k further. You may tell what your target system is.

About speed: They might be something that slow down globaly. Sometimes if I switch between "informations" and "preferences" it takes some seconds. I checked CPU usage with Scout: If the open xui window is active and I just move the mouse somewhere on the screen it takes all the CPU (100%). There is something wrong.

[AGS]

Thanks again. I thought I target UAE and such. But maybe I can improve speed again, as you pointed me to some clue.

The internal behaviour is, that any MOUSEMOVE is 'sent' to every gadget down the whole tree of objects, so that an object can change the pointer when the mouse is above it, or do something else then. Also, after each such message the whole tree is searched for gadgets that have been modified in order to refresh them. And while searching for such gadgets, any wanted clipping from their parent gadgets is applied. I don't know why switching the tabs is only "sometimes" slow. puzzling ...

If you have a good idea how to make this work in another way, I can change it. Now, here is a little testing program with which one can test a single class, if that class supports testing: http://images.quicktunnels.net/oxtestclass ... usage is oxtestclass <classname> ... the classname is the name of the class file in libs:ox/ .. or the name of an internal class as displayed in oxlibinfo.

[AGS]

I made a quick speedup modification: ... not fully implemented but now the lib maintains a chain of all (few) objects that are interested in MOUSEMOVE, instead of traversing the whole object tree with that message. I can do similar for the refreshing, but there are another two bottlenecks: a) creating the object-tree and b) calculating the layout. I have no idea how to improve speed there. Do you?

EDIT: full speed update available: http://images.quicktunnels.net/openxui_latest.zip

[daxb]

I`m not sure but I there weren`t any buttons (cancel, revert, ...) on the preferences page before. Now, after set options to max speed (no images, 4color mode, ...) and hit the use button, then restart it is much better in speed. I noticed when a second screen is open (tried YAM and IBrowse) open xui becomes very slow again. Edit: After some more testing it was also slow without another screen open. This would explain the "sometimes". On emulation you might don`t see that. About how to do things different I can`t help but you may ask on amiga-news forum where you got already help or just stop 68k support so you can ignore the speed issue.

Good news is that it didn`t crashed while playing.

[AGS]

Thank you. I do not like to ignore the speed issue, because if it happens only sometimes, it looks like a bug to me. Do you think so also? There is a little thing, maybe you can help me. The speedup should especially be visible in the 'newbutton' gadgegt. Please could you select 'newbutton' from the left classes list in oxlibinfo and then move your mouse over the 'tool button' and move your mouse out of that gadget again. Do not click there. In this case the lib sends the mousemove directly to the newbutton gadget. although after that the whole tree is searched for refresh objects, the cpu usage when moving the mouse over the toolbutton should be very reduced and the button should react faster. If this is not the case, maybe the bottleneck is elsewhere, maybe in the refresh. I am already thinking on how to speeding that up.

[Thorham]

To AGS:

Some suggestions:

I've seen numerous instances of the following kind of code in your code:

    cmp.l   #bla.a1,d0
    bne     .l1
    move.l  d1,bla.a1(a0)
.l1
    cmp.l   #bla.a2,d0
    bne     .l2
    move.l  d1,bla.a2(a0)
.l2
    cmp.l   #bla.a3,d0
    bne     .l3
    move.l  d1,bla.a3(a0)
.l3

It's better to try and write it like this, because it's faster, shorter and far less prone to errors:

    move.l  d1,(a0,d0.w*4)  ; for long words
    move.w  d1,(a0,d0.w*2)  ; for words
    move.b  d1,(a0,d0.w)    ; for bytes

I've also seen multiple instances of inlined linked list code and what appears to be code that traverses a whole list to get the last node in the list. A better approach would be to do something like this (excuse the use of rs.l, I haven't looked at the types include ):

    
            rsreset
list.first  rs.l 1  ; pointer to first node in list
list.last   rs.l 1  ; pointer to last node in list
struct_list rs.l 1  ; size of structure
    
            rsreset
node.prev   rs.l 1  ; pointer to previous node
node.next   rs.l 1  ; pointer to next node
struct_node rs.l 1  ; size of structure

list.add            ; add node to list
list.insert         ; insert node between two nodes
list.delete         ; delete node from list

In the case of the methods (add, insert and delete) you simply keep list.last pointing to the last node. No slow loops required.

Using only one set of linked list routines is far easier and less error prone than inlining the code wherever it's needed.

[AGS]

@thorham Thanks for your analysis. I don't understand all what you write.

cmp.l   #bla.a2,d0
bne     .l2
move.l  d1,bla.a2(a0)

But I can't remember to have such a code and I use almost everywhere the Exec-Lists, where the pointer to the last node is in the list-header.

However I found out that i can really speed up the whole thing by maintaining a chain of objects that want refresh instead of traversing the whole object-tree to find them.

[daxb]

If the mouse is moving then 100% cpu usage, so I can`t see any differences to "newbutton" class. I also don`t know or can reproduce why it is sometimes much slower then "normal". E.g. if ox is at normal speed, then I restart ox what is running slow. Also when it is slow it seem to react with other parts. E.g. the left-right arrow mouse pointer don`t switch to normal pointer.

[AGS]

Thank you for trying this. I discovered that there are a lot of redundant MOUSEMOVEs sent by AmigaOS to my code. I now have built in a compare so that if the position that comes is equal to the last one, nothing is done. The pointer, yes, thats because the speedup was not fully implemented. But as I wrote before, speedup seems really possible, so that ox will be useable w/o emu also.

ps: you can try to stop moving the mouse over a tab handle, wait a while, then clicking. Now it could be that the tab switches immediately. If you click directly after moving the mouse w/o waiting, the ox is processing redundant mousmoves that slow down everything. maybe this is the reason for the "sometimes"?