Ok, I don't *hate* AmiDock, I am just frustrated about the lack of documentation for it...

(sorry for the rough language in the subject)

Well, there is a story behind it: I have now spent over a week constructing an implementation of the QSystemTrayIcon class from the Qt API. I guess AmiDock is fine for self contained dockies and for storing your favorite app icons, but for this particular purpose (which is to construct an AppDocky that has a context menu with icons and can change icon imagery on command) AmiDock/application.library is just... #OOPS#... (sorry again)

1) There is no way of changing the icon supplied with DOCKYRENDERMODE_Icon without switching to a different mode than APPICONT_Docky and switch back again, which in turns redraws the ENTIRE AmiDock in a very ugly way (sometimes, it seems, multiple times at that). When trying to do it with just reapplying with IApplication->SetApplicationAttrs(..., APPATTR_IconType without changing the type in between, the docky very often just vanishes and doesn't reappear when a new call is made.

2) When switching icon in the above mentioned fashion, AmiDock sometimes (lets say, once in every hour when changing icon every half minute) crashes, apparently because it has lost contact with the docky.library (the ip is in nomans land). I have still not found a solution to this, and it is delaying the release of my newest port on second week now...

3)The "easy" way of creating an AppDocky (APPICONT_ProgramIcon) is completely useless. You can't use it to create a context menu, the only thing you can do is listening for mouse clicks on the message port, which is not very useful.

4) To get a context menu for your docky, you need to use APPICONT_Docky, which in turn means creating an entire library just for the sole purpose of have a little colored image with a menu on your screen. This is an insane amount of wasted energy spent on too simple a task.

4) There is no standard way for a program to communicate with an appdocky that has been created with APPICONT_Docky(!) The way I have done it is to enable my program to send custom commands with DockyGet(), which is obviously not the intention, since there are do bounds given for custom commands (I could easily conflict with a future version of AmiDock). Also, to do this, I need for the DockyClone function to not create a cloned interface, otherwise I would just end up with a NULL interface to communicate with.

5) When trying to use DOCKYRENDERMODE_RP or ARGB (etc.) to get rid of the annoying "complete dock redraw" effects when changing icon... well, that's not going to do it, because there is no way to trigger a redraw from outside AmiDock...(!!) AARGH! Well, there is one way: Do a busy loop, making AmiDock call up the docky once every 10 of a second... Very handy indeed...

Well, that's mostly it. I hope we get something more useful some time in the future. Until then, sorry for the angry attitude, but it is just very frustrating feeling you have wasted your time because of some incompetent piece of API... :-/

Im not a fan of amidock but use it as its in the package :)

@alfkil

I have never written a docky myself, but I do know that others have created dockies that update continually (e.g., the CPUTemp docky). There is also an animated docky provided as an example. So, it is possible.

My understanding is that dockies that regularly update their appearance are supposed to do their own rendering (i.e., forget about "changing the icon," and start "rendering the docky").

You might want to talk to zzd10h, who recently released NetDock. Doing a search for "docky" on os4depot should also get you a list of more developers who have made animated dockies.

Hans

I would like Amidock more if it kept the pop out lists aligned with the dock icon whenever I change screen mode!

@Hans

But the CPU docky doesn't have a client program attached to it that it has to communicate with! Hence the statement "I guess AmiDock is good for standalone Dockies"... The problem is, that apparently noone is using AmiDock for the same purpose as I, hence the lack of API structure.

And of course I tried "doing the rendering" myself, but as I also stated, there is no way to trigger a redraw from outside the docky, which means it is only useful for continually animated dockies that don't need to respong to input. See, it is like this: You get a RastPort pointer from AmiDock, and then you think "oh good, now I just need to render to this port for screen update...!" But sadly no, because the RastPort is a *virtual* rastport, whose content is only updated to the screen when fetched by the AmiDock AMIDOCKSET_RenderNow command. And there is no way to trigger this command unless you set DOCKYGET_FrameDelay to something other than -1. Which means, that to update the docky icon, you need amidock to send you little messages at least once a second. Which is just stupid...

Please someone back me up???

I've never written any docky related. But i find amidock to be very useful..

Quote:

AmiUpdate and Tunenet both have animated dockies attached to a larger program.

Hans

@Antique

For storing your favorite apps, and for standalone dockies, yes, but NOT for AppDockies! How much trouble would it have been to make a context menu entry in the RegisterApplicationTags() function??

@Hans

?? Hmm... I would sure like to see the sourcecode for those...

Quote:

You're unlikely to get the source-code, but you could ask Rigo - the author of AmiUpdate - how he managed it. I haven't seen the author of tunenet around on these forums for a while, so getting useful info from him will be more difficult.

Hans

@Hans

Thanks for the pointer, I didn't know that Rigo was the author of AmiUpdate. And also I didn't notice until now, that AmiDock has everything in it, that I want from the Qt SystemTrayIcon interface: Context menu, changing icon, doesn't crash (until now that is). Well, in any case, I will send him an email, maybe he can help transform my negativity into something more fruitful.

@ddni

Or simply when another icon is added to the bar!

It needs to work exactly like the one in MorphOS in two respects:

1) The position of all child icons are updated when icons are added to the bar.
2) When one parent icon is open any other already opened parent icons and their children should close... it looks messy right now.

Even the "simple" method cocks up if you try to change the icon. I had a workaround for it but it wasn't great.

Those things too!

Amidock needs an overhaul!

I wonder what is required to get push4dock updated etc....

YAM also uses AmiDock (I think) and its source code is available on SourceForge, but I agree that AmiDock is pretty rubbish, having tried to write docky code myself.

@ddni Quote:
SmartSubDock (comes with the SmartButton docky) is your friend! OK, needs a little while to work out how to set it up (which would not be a problem if it was built-in to AmiDock).

@djrikki Quote:
SmartSubDock does that too

Quote:

Yes, but YAM is using a simple icon only to indicate its current state about new mails, downloading mails, etc. But YAM is not using a custom context menu.

You are faced with a problem which I will also need the solution for...

The current plans for Perception and Polymorph will need me to create a menu from button arrangement on AMIdock as well

As I will be taking settings from locale and adding extra options...

However I have the extra step of needing to create an always open and always on top dock that is always following the user to the frontmost screen

As I am splitting my projects into libraries...
I am making a docky by that method...

Are any of the standard docky sources going to be an open to read example?

If you solve this issue... May I see how?

Excalibur does not yet have a plugin system but its planned..
However the API is starting to take form..

Basically pluging will have this api's

plugin_stop_render()
plugin_start_render()
plugin_force_render()

etch of this are protected by a Mutex(). So that plugin can not be rendering while plugin_stop_render() is called.

Excalibur needs total control over plugin, because excalibur can be asked to close when workbench is changing resolution.

In this setup the plugin can render as often as it likes, but after a window open it can be forced to render.

There is probably going to be a plugin_event() and plugin_init() api as well.