AmiDock and Dockies

Introduction

On most operating systems you will find panel launchers, tray bars, launch bars and so on, and AmigaOS is not an exception. The realization of such thing on AmigaOS is done via AmiDock commodity and while there can be another third party realization of toolbar systems and docking utilities, AmiDock start to be de-facto standard and provided with AmigaOS by default, and that is thing on which our article is based.

What is AmiDock

AmiDock for AmigaOS 4 is a rewritten version of the former AmiDock from AmigaOS 3.9. And while AmiDock is a single commodity, its more than just that as its provide you with necessary for today set of features like ARexx support and feature rich APIs by which your Dockies can control most of AmiDock's features and expand them.

You can follow to that article if you want to know user-kind details about, but there we will concentrate on technical details to help programmers to make their Dockies as best as it possible.

What are a Dock and a Docky?

Dock

A Dock is an area/a window where the user can put a program icon or an interactive program. Some may call it "Panels".

So, Docks can be used and as Launcher Panels:

And as Tray Bar panels:

And as anything else anyone can come up with: you can put everything inside of panels of any size and structure/design them as you wish.

Docky

A Docky is this item the user can place in the dock: a program icon or an interactive program. Dockies are able to control most of AmiDocks feature and provide a great way to expand AmiDocks features beyond its default features. Dockies may be invisible to the user or show static or dynamic (animated) content. You may change their behavior, size and look acording their current equirements. Dockies can be of 2 main types:

Standalone Dockies.

Is a special type of program which is made to show an icon in a Dock, delivering some functionality to the user. It is the most common form of Dockies. This docky-type uses the shared library feature of AmigaOS as common interface to the internal properties and behavioral possibilities of a docky.

Application Dockies.

That second type of dockies are application dockies (short form 'AppDockies' or as some call it 'AppDockIcon Dockies'). An AppDocky is a docky which is introduced to the system during runtime by an application using application.library registration mechanism for applications. The biggest diference between the two docky types is that AppDockies belong to a running application and usually are used to represent the current state of the owning application.

To sum up in "standalone dockies" the docky itself is the application (the only reason of existence of the application is the docky) while for "AppDockIcon dockies" the docky is just a graphical representation of a bigger application (the docky is just here to add user friendliness or visual feedback of the surrounding application)

How to create and manipulate a simple docky

You write a docky just like you'd write a standard Exec library. In your code you must implement certain specifically-named functions like DockyGet(), DockyProcess(), DockySet() etc. The docky manager (AmiDock) calls these functions when it needs to.

See the datetime.docky source code to get started.

One shortage of the current docky system is that AmiDock only provides your docky with a rastport pointer to render data into the dock. You get no window pointer, which makes it impossible to build your docky interface from Intuition gadgets.

How to make a right Docky

For tray-bar kind Docks

If you are a developer and you want to make your dockies to work in tray-bar kind docks, you need to make a docky more flexible when it comes to visual appearance, and you should follow some rules when you do it:

• You should keep in mind, that dockies in tray-bars will have 24x24 pixels of look. Some old and current dockies just don't care about the max/min size of the dock.

For example, in QT port implementing of QSystemTrayIcon() was done like an "application docky":

• Open application.library. Note the interface is called "application" NOT "main".

• Register your application using RegisterApplication()

• Get the application.library port through GetApplicationsAttrs()

• Get events from that port in the usual fashion (the messages are detailed in the autodoc)

• Unregister the application, close the library, etc.

FAQ

Q: Is it possible to create an application docky and then update its content on the fly and how ?

A: Set the icon type to APPICONT_Docky; but you'll need to create a real docky as well then. If it doesn't need to be truly active it is possible just to change the icon's imagery (I think you have to un-register/re-register to get it to change though, so no good for frequent changes)

Q: I have successfully drawn a datatype (a picture) in a Docky and the picture file has more than 256 colors, but it is rendered in 256 colors only. Why ?

A: Just add PDTA_DestMode, PMODE_V43 to the NewDTObject call. You might also want to add DTA_GroupID, GID_PICTURE in order to restrict the file type to pictures.

Q: How are context menus created? I don't see any contextmenu example in the SDK examples, but DOCKYGET_ContextMenu takes en Object * as data. What kind of Object are we talking about?

A: Context menus are dynamically built in response to DOCKYGET_ContextMenu attribute:

BOOL DockyGet (struct DockyIFace *Self, uint32 msgType, uint32 *msgData) 
{ 
switch (msgType) 
{ 
/* ... */ 
 
case DOCKYGET_ContextMenu: 
{ 
Object *contextMenu = (Object *)msgData; 
 
Object *item1 = PopupMenuItemObject, 
        PMIA_Title, GetString(&li, LOCALE_ITEM_PREFS), 
        PMIA_ID, PMID_PREFS, 
    PopupMenuItemEnd; 
 
    Object *item2 = PopupMenuItemObject, 
        PMIA_Title, GetString(&li, LOCALE_ITEM_SAVEASDEFAULT), 
        PMIA_ID, PMID_SAVEASDEFAULT, 
    PopupMenuItemEnd; 
 
    Object *item3 = PopupMenuItemObject, 
        PMIA_Title, GetString(&li, LOCALE_ITEM_USEASDEFAULT), 
        PMIA_ID, PMID_USEASDEFAULT, 
    PopupMenuItemEnd; 
 
if (item1 && item2 && item3) 
    { 
        IIntuition->IDoMethod(contextMenu, OM_ADDMEMBER, item1); 
        IIntuition->IDoMethod(contextMenu, OM_ADDMEMBER, item2); 
        IIntuition->IDoMethod(contextMenu, OM_ADDMEMBER, item3); 
    } 
 
} 
break; 
 
/* ... */ 
}

Q: How to use Alpha layer for Docky ?

A: On non-composited screens, AmiDock uses a "fake" transparency effect (i.e. the bitmap is filled with the contents of the window behind the dock), meaning that you can only add things over the background but you cannot render half or totally transparent contents without doing the blending at the same time (or you'll lose background information).

So if you want to support this configuration you need to follow this rule or provide an alternate rendering if you want to do fancy stuff when compositing is enabled.

Now, what you are trying to do should work on composited screens, but you have to tell AmiDock that you are using composited mode (see DOCKYGET_SupportsComposite and DOCKYGET_CompositeMode) so that it does not try to de-multiply the docky bitmap. Also I'm not sure you can use legacy pens to fill alpha channel, you're better off with direct ARGB painting (see SetRPAttrs() with RPTAG_APenColor).

Q: Is there a way to trigger a redraw from outside the docky ?

A: Use DOCKYGET_NeedsAttention for this. This is how a docky can be notified from an external task by signaling AmiDock process. Quite straightforward, this is how e.g. winbar.docky is told to rethink its layout in response to a change in preferences, or Intuition windows list. A shared structure and Mutex to protect the data.

I.e. you are notified about the task/bit to signal through DOCKYSET_DockyAttention (you would store it in the library base for an easy access by the main program). When your program signals AmiDock, every docky is sent the DOCKYGET_NeedsAttention message, so it is a good idea to use a flag to know if the notification really comes from your program.

Links

1. SDK:Documentation/AutoDocs/docky.doc

2. Sys:Documentation/Commodities/AmiDock_Arexx.doc

3. SDK:Examples/AmiDock/