Aros/Developer/Docs/Libraries/Workbench
Introduction[edit | edit source]
The AOS3 icon info has a priority adjuster. Wonder how the priority can be stored in an icon. These priority adjusters are features of RAWBInfo. workbench.lib's own info window will display them as tooltypes. The normal "Priority" setting corresponds to the TOOLPRI tooltype which is mapped to the NP_Priority tag for CreateNewProc() in workbench.library. For autostart applications in SYS:WBStartup RAWBInfo will display two additional elements for the launch sequence priority (STARTPRI=<-128..+127>) and the optional delay to wait for the application to terminate (WAIT=<seconds>, seconds==0 means 'don't wait'). All tooltypes default to zero.
Please, don't forget to change the array "layout_expansion_table" in the file "workbench/prefs/input/prefs.c" when you add/change keymap names.
SetFunction[edit | edit source]
Its been pointed out that workbench.library may be better implemented by merging Workbook and workbench.library. Wanderer would Exec/SetFunction the routines it needs to override, instead of using the rather limited message passing mechanism we currently have.
If there are no objections, I would like to implement this, by merging Workbook and workbench.library, and updating Wanderer to SetFunction the necessary parts of workbench.library. Well, its against the philosophy of the AROS implementation of workbench.library (which is meant to be "client" agnostic) - however ive already started using SetFunction localy anyhow in my own code. It does mean I will have to rework my AppIcon/Menu code though. In the past people have been talking about some kind of registration API in workbench.library. So that any Workbench implementation like Workbook, Wanderer, ScaleOS could register so that they get the needed information when workbench.library function are called. This way also several workbench implementation could be registered at the same time.
AppIcon[edit | edit source]
I have a questions about AppIcon interfaces.
Currently the interactions look like this:
Application <--A-> workbench.library <-B-> "workbench replacement"
The interfaces between application and workbench.library (A) are public and defined since release 2.0. On the other hand, I was not able to locate any information about interfaces between workbench.library and "workbench replacement" (B). I checked Amiga Developer CD 2.1 RKMS, AmigaOS 4 SDK and MorphOS SDK.
Does anyone know if there is any standardization on this interface between Amiga-like OSs?
Does anyone know how "Workbench replacement" application on Classic Amigas are doing it? Are they providing their own workbench.library replacements/function patches? That is the normal behaviour. AROS's workbench.library is more of a special case, and "tries" to be generic. Normally it is down to the workbench replacements to implement their own workbench.library, or patch the functions in the original.
Additionally, were there any designs and plans in the past to implement the AROS specific interface for (B)? I checked our workbench.library and it has some AROS-specific functions, but this support looks like work-in-progress rather than finished/frozen API.
Is this (patching) also the way you want to port Scalos to AROS? It seems to me each "Workbench replacement" will have to carry some amount of duplicated code this way - for example registering appicons and communication with them. I'm wondering whether it would not make sense to redo current AROS extension functions to allow sending messages from "Workbench replacement" to Application via workbench.library - there already is one such function in the API - SendAppWindowMessage
Alternatives[edit | edit source]
The task of making a new Wanderer file browser, could involve making it a bit more modular one that includes an abstraction layer to allow different types of items to be displayed in it. Case in point: An object-oriented graphical programming language could be implemented in the plugin format to make an AmigaVision-style scripting engine. Since it would be fully graphical and use the analogy of a directory structure, it would bring many people into the high-level programming arena to contribute code.
This isn't the first time the idea has been brought up. It was discussed once before on AROS-Exec.
Want to make the browser aspect kind of like a datatype for directory structures and other hierarchical data formats. (XML, anyone?) Maybe we could even make the new Wanderer like a Multiview and Workbench rolled into one program. Of course this should be a longer-term goal than ABI 1.0 so it would be a worthy goal for AROS 2.0.
For the long term solution, I'd suggest making AROS extensions to workbench.library and icon.library which multiple apps can register with, use and get notifications. If remember correctly this should already be the case or the basics should be available in workbench.library. See RegisterWorkbench()/UnregisterWorkbench(); appicon support seems not available. App developers should be able to give users a workbench like experience on their own screens (for example open a drawer and show the icons of only PNG files and let the user drag it over to a document they're working on) as well as allowing a system wide workbench functions to operate on multiple public screens, or give the user the freedom to have multiple "workbench" programs running at the same time to decide what they like best, if they so choose.
The commodore examples for AppMenu, AppIcon, AppWindow are available in the Aminet archive http://aminet.net/dev/misc/AmigaMail.lha
uncompress the lzh file in the downloaded lha archive and look in the am_Jul91/AppWorkbench directory.
While generally in favour of trying to implement things in a generic way - while working on wanderer I came to the conclusion that it would be pointless/overkill.
- It will likely only be ever fully used by Wanderer (and perhaps workbook). It makes no sense for existing Workbench replacements to have their internals reworked just to be able to use these specific extensions.
- It would mean backporting Wanderer to amigaos/other also needs the special workbench.library.
- It already has had some hard coded wanderer specific and workbook specific changes. It would be easier to maintain these in patch functions (imho)
- The existing functions only expose the appicon/menu objects themselves so the "handler" has no way to communicate to the applications themselves with the need to invent more aros specific functions. Even the implemented code is incomplete (it lacks the ability to inform the handler a new object is added for instance). It would be easier to maintain handler specific implementations of this stuff imho (since it is very much tied to the workings of the handler in question)
- How WorkbenchControlA will operate is also undefined.
... + a few other reasons.
Examples[edit | edit source]
References[edit | edit source]
struct AppIcon * AddAppIcon( ULONG id, ULONG userdata, STRPTR text, struct MsgPort * msgport, BPTR lock, struct DiskObject * diskobj, Tag tag1, ... ) __stackparm; struct AppMenuItem * AddAppMenuItem( ULONG id, ULONG userdata, STRPTR text, struct MsgPort * msgport, Tag tag1, ... ) __stackparm; struct AppWindow * AddAppWindow( ULONG id, ULONG userdata, struct Window * window, struct MsgPort * msgport, Tag tag1, ... ) __stackparm; struct AppWindowDropZone * AddAppWindowDropZone( struct AppWindow * aw, ULONG id, ULONG userdata, Tag tag1, ... ) __stackparm; BOOL CloseWorkbenchObject( STRPTR name, Tag tag1, ... ) __stackparm; BOOL MakeWorkbenchObjectVisible( STRPTR name, Tag tag1, ... ) __stackparm; BOOL OpenWorkbenchObject( STRPTR name, Tag tag1, ... ) __stackparm; BOOL WorkbenchControl( STRPTR name, Tag tag1, ... ) __stackparm;
struct AppWindow *AddAppWindowA(ULONG id, ULONG userdata, struct Window *window, struct MsgPort *msgport, struct TagItem *taglist) BOOL RemoveAppWindow(struct AppWindow *appWindow) struct AppIcon *AddAppIconA(ULONG id, ULONG userdata, char *text, struct MsgPort *msgport, BPTR lock, struct DiskObject *diskobj, struct TagItem *taglist) BOOL RemoveAppIcon(struct AppIcon *appIcon) struct AppMenuItem *AddAppMenuItemA(ULONG id, ULONG userdata, APTR text, struct MsgPort *msgport, struct TagItem *taglist) BOOL RemoveAppMenuItem(struct AppMenuItem *appMenuItem) BOOL WBInfo(BPTR lock, CONST_STRPTR name, struct Screen *screen) BOOL OpenWorkbenchObjectA(STRPTR name, struct TagItem *tags) BOOL CloseWorkbenchObjectA(STRPTR name, struct TagItem *tags) BOOL WorkbenchControlA(STRPTR name, struct TagItem *tags) struct AppWindowDropZone *AddAppWindowDropZoneA(struct AppWindow *aw, ULONG id, ULONG userdata, struct TagItem *tags) BOOL RemoveAppWindowDropZone(struct AppWindow *aw, struct AppWindowDropZone *dropZone) BOOL ChangeWorkbenchSelectionA(STRPTR name, struct Hook *hook, struct TagItem *tags) BOOL MakeWorkbenchObjectVisibleA(STRPTR name, struct TagItem *tags) BOOL RegisterWorkbench(struct MsgPort *messageport) BOOL UnregisterWorkbench(struct MsgPort *messageport) BOOL UpdateWorkbenchObjectA(STRPTR name, LONG type, struct TagItem *tags) BOOL SendAppWindowMessage(struct Window * win, ULONG numfiles, char ** files, UWORD class, WORD mousex, WORD mousey, ULONG seconds, ULONG micros) struct DiskObject *GetNextAppIcon(struct DiskObject *lastdiskobj, char* text)