And there is also quickstarter from TSK on Os4depot.
Edit: It all depends on what you call a start bar. Winbar.docky is meant to manage all opened windows whilst taking as less space as possible to fit it in a dock, but you can put it in its own dock and extend its size to the screen width as well.
I don't think so. An AppWindow doesn't need to have an AppIcon (and vice versa). Also not every program does have an AppIcon.
In eg. Simplemail you can choose when you want to have an AppIcon: Never, Iconified or Always. And it changes its AppIcon depending on the state and emails. This is done with removing the old AppIcon and add a new one.
Actually, for window.class instances at least it would be possible to use tag WINDOW_Icon, but I don't know a simple way of detecting if an Intution window is an object of this class.
Would it be possible to add an option to sort the bars it time order rather than by name? That is, in the order (in time) that they were added to the workbench. That way the latest window that was added to the workbench is always last in the list.
Is it possible to retrieve any type of identification from a window, such as what program it belonged to, name of process or somesuch? If there's some way to do that then it could be possible to configure a database of icons that would be displayed on the bar. Currently it's very hard to identify the different bars so any type of visual identification would help.
If the program is registered with application.library it should be possible to retreive its icon relatively easily. IIRC TSK already did that in one of its numerous useful tools on OS4Depot but can't remember which.
Show a thumbnail when mouse pointer is on a bar (like in Winblows/Linux) ?
Yes, I'd like to add that feature, would be cool, as well as icons for window.class windows (when I resume working on winbar.docky).
@orgin
Quote:
Would it be possible to add an option to sort the bars it time order rather than by name
What a bizarre idea ! No, just joking , yes this can be done but it's not as straightforward as showing it alphabetically sorted.
As for the info about the window, there used to be OwnerOfMem() function in Exec that could have provided an alternative way of obtaining the parent process (maybe...), but it no longer works in OS4.1. So IMHO the best that can be done is showing a thumbnail of the appicon for ReAction windows.
50.7 (19/05/09) - Small icons are now displayed in buttons for which the program "owning" the window can be guessed - Added an option to sort windows by opening order instead of alphabetical order - Added new preferences for colors and scrolling speed (horizontal and vertical) - Fixed bugs in layout
Thanks! Well, I finally use the Window structure to retrieve a pointer on the task listening to the IntuiMessages (through the window user port). It's probably the way AmiStart does its job too. It works quite well with a lot of programs, but obviously if the GUI handling is deferred to a sub-process, it won't.
Hmm, very unstable here. After a reboot I get a DSI error when it loads. "Task Winbar.docky (Notify)".
Unable to retrieve a crash log, grim stops working, non functional input buttons. Even my receiving null modem terminal freezes up until I restart the a1. After turning off the A1 I get this output:
I'm having the same stability problems here after rebooting. Though for me I can get rid of the problems if I delete the config information (winbar-docky.xml) from ENVARC:. However, the crashes return after saving the configuration (not just in the winbardocky but in AmiDock itself).
Well, I finally use the Window structure to retrieve a pointer on the task listening to the IntuiMessages (through the window user port). It's probably the way AmiStart does its job too. It works quite well with a lot of programs, but obviously if the GUI handling is deferred to a sub-process, it won't.
Do you handle the case where UserPort can be NULL (WA_IDCMP set to 0)? Also it might be a good idea to check that (mp_Flags & PF_ACTION) == PA_SIGNAL. If it's PA_SOFTINT mp_SigTask will be of type (struct Interrupt *) and if it's PA_IGNORE the contents of mp_SigTask are undefined.
The UserPort is checked against NULL, but I didn't know about mp_SigTask possibly being an interrupt, so I will fix this, thanks for the tip. However, this is probably not the reason of the crash, since the pointer is used as a key to search the list of processes.
@PEB If you delete the default preferences (winbar-docky.xml), the crash at reboot doesn't occur ?
@orgin Thanks for the crash log (the funniest I've seen...). The bug possibly happens when IntuitionBase is locked, hence the big mess. Strange that I don't get it on my machine. As for the automatic detection of changed titles, I'll look into it.
If you delete the default preferences (winbar-docky.xml), the crash at reboot doesn't occur?
No, its not quite that simple. The crash seems to occur only when the "Auto-adjust size" is set for "Width only" or "Yes" ("No" and "Height only" work fine). The "winbar-docky.xml" file needs to be deleted if one of those problem settings were saved to as default.