GUI toolkit alternatives
 

Over the last few months I've been working on a pretty light weight Dock application intended to work on 3.0 or 3.1 systems. I'm a fan of BetterWB (and my most powerful real Amiga is an A2000 with and 030 and 10MB RAM) so the idea is to have something that fits in with it.

A picture of the dock as it currently looks can be seen at https://www.dropbox.com/s/tlxvb85y5v...60929.png?dl=0

Each object shown on the dock is implemented as a BOOPSI class that is responsible for rendering and responding to user actions. The object can respond to clicks, dropped workbench icons or a hotkey.

The icon button class is built in to application but the clock and memory meter in the linked image are loaded dynamically based on the config file.

One part that I haven't really decided on is the GUI for the preferences application. I'd like to have it dynamic so that each object can provide it's own config UI.

I've considered using MUI but would prefer something a bit lighter.

Are there any GUI libraries around that make it easy to add and remove gadgets to a window at run time?

Looks nice.

Can't really help you with that, two somewhat popular (i.e. I occasionally encountered programs using them) alternative GUI toolkits that were more lightwight than MUI/Classact were gtlayout and BGUI, they're both on Aminet. No idea if they do what you want though.

How about just adding a context sensitive popup menu using popupmenu.library? Checkmarks for "show handlebar/clock/memmeter", an entry for adding a new object to the dock plus a bunch of options (change icon/executable/helptext, remove object etc.) for the current item? The actual requesters could then be simple ASL/gadtools affairs for entering text, picking a file etc.

As you are already working with BOOPSI you might want to have a look at ClassAct:
http://aminet.net/package/dev/gui/ClassAct2Demo
http://aminet.net/package/dev/gui/classact33

The SDK is not publicly available but the examples compile smoothly with the OS 3.9 NDK if you replace all mentions of CA_ by RA_ and classact by reaction.
http://www.haage-partner.de/download/AmigaOS/NDK39.lha

Looks good, already. I'd love to see animation support (like Toolmanager 2.1). Also, variable size tiles might be worth a thought.

So I've been playing around a bit with Triton as it appears to be just a light wrapper around gadtools and boopsi gadgets. The preferences editor is currently looking like this:

Attachment 50326

The plan is to have it support dropping of icons and displaying of icons in the prefs editor.

I'll probably change the dock to support tiles the same size as the icons. Simple animation is possible as each gadget in the dock receives a TICK message several times a second and can request a redraw at that time. This is used to display the icon's alternate image when it is clicked:

Attachment 50327

I've run into a couple of gotchas with Triton: it doesn't seem to deal with TagItem lists in the intended way and won't work if you're trying to append tags using TAG_MORE. Also, even though it provides a way to display a BOOPSI image within the UI there doesn't seem to be a way to actually access the image instance (to, for example, hand my custom image class an icon to render) so unless I'm missing something I'm not sure what use it is.

Old thread, but I wonder if this Dock app was ever completed and if it can be found on Github or something?

https://github.com/adkennan/DockBot

Cool, thanks!

Wow, that's interesting timing... I got distracted working on something else and never got around to tidying this up for release. I've been using it myself for years though.

Over the last couple of weeks I've picked it up again and have been getting it ready - fixing a couple of bugs, writing a manual and an installer. I'll hopefully upload it it Aminet in the next day or so.

Nice, please consider making a release at github as well, and thank you for putting it on github in the first place.

Done!

You're welcome. The more source code available, the better :)

I hope it is OK to request support here... :)

It will not start as it wants

parm.library

which is included in the

.lha

, but not installed into

libs:

or the place it installs DockBot, it seems.

Fixing that (assignd add

libs:

) and it does not start for me, but that might be due to my setup. I use AROS and do not launch any workbench (replacement), there is a screen called Workbench without anything particular on it and a shell window. What I want to do is to use DockBot as part of a desktop setup without any WB replacement, to get a useful and lightweight setup.

Launching

DockBotPrefs

results in a "Couldn't load config." requester and termination. There is a

DockBot.prefs

file in both

ENV:

and

ENVARC:

.

Regarding the icon library, I tried both the one that comes with AROS and the one in icon library 46 (I just copied the icon.library for 68020 and renamed it). Maybe it is my environment here and I do not know how to debug this in a good way.

:great

That's fine. I knew it wouldn't work!

Doh.

I've not tried it on AROS at all.

Strange. It might be masking the real error.

Can you see if the v46 icon library is being loaded and used?

Thanks,

Andrew

I used SnoopDos on DockBotPrefs with the following result
Starting DockBot itself gives the following output:

So it turns out that I did not have the correct icon library. AROS provides version 44 and the button gadget class requires 45, so it stops without saying anything.

I tried LoadResource on the v45 icon library, but it was a no go. Instead I built a new kickstart without icon.library, to allow it to load the v45 one from

libs:

.

This made the prefs tool work. DockBot itself does not start as it expects to find

System:

and I do not have that. It think it should be

SYS:

?

I added an assignment to solve that and then it crashes randomly. Sometimes the dock comes up, but trying to start a shell causes a "Corrupt memory list detected" error, but the shell comes up. Sometimes it just crashes when starting DockBot itself.

That prefs tool look quite tidy, I think this Triton is good?

Awesome, thanks for your help.

The reference to "System:" is actually in the default prefs file. I'll change it to SYS:. It's a text file so you can edit it yourself.

The corrupt memory list bit is a worry. I wonder if I'm doing something dumb that hasn't affected me but AROS doesn't like.

Triton seems pretty neat. It's kind of MUIish wrapper around Gadtools and existing BOOPSI classes, I think. It's certainly much lighter than some of the alternatives.

I've created a new release and actually tried running it on a fresh 3.1 install with just icon.library.

I still can't promise it will work on AROS but if you can get me a minimal setup of it that I can run in fs-uae I can try to work out what's going on.

Cheers,

Andrew

The new release works great. No crashes here as I played around with it. Many thanks!

I will see how I can incorporate it into my setup here as I am just starting out to create a custom work environment (to replace the Workbench). I am developing a tool to allow me to open and handle multiple public screens dynamically. Do you think it would be simple to extend DockBot to exist on multiple (public) screens?

In the source

DB_METHOD_DM(EDITORUPDATE, DockMessageEditorUpdate)

allocates memory chunks for strings without checking that it got a valid pointer back.

That's good to hear, I'm glad it works for someone other than me!

Thanks for pointing out the potentially dangerous allocations. I've had a quick look and there's a couple more scattered about the place.