We need topbar plugins/modules

[kas1e]

It come from another thread, and before making a enhancement request in BZ, let's discuss it all together:

For some time we have some apps which chaotic placed on wb there and there , and the only way to have something in one place was always kind of primitive snap-shooting of icons and amidock. It works , and can be used as dock-panel for just apps launching (through there a lot of moments need to improve, and the visual output to user was always pretty primitive there), but when user do not want anything other but just few icons to launch in amidock panel at all , or he do no want panels at all and so on: for those situation screen bar modules/plugins are way to go.

As example of usual screen-bar modules can be: volume control, keymap switchers, clock, amigaamp small-navigation panel and all the usual "tray-kind" stuff, which is not fits to just "let's iconify it to WB" or "let's make it as docky".

All the oses have it of course and we not should go the same way only because "all oses have it", but because it prove to be user friendly, easy to use and just "right" thing and does not matter on what os is.

There is some examples.

WinXp:


Linux/Gnome:


MacOS:


Morphos example 1 from jPV:


Morphos example 2 from jPV:


As you can see, it is present on all oses, and even on our closest to us morphos (which prove to be usable on amiga-kind os as well). Usually there is volume controls, keymap switchers and some other stuff which i point out before. Dbl-clicking on it spawn a settings of those modules and they all holds on top bar just like commodities or so.

For example to have digi clocks on top-bar, AlexC just make a "border less window which stays on top bar", what kind of sucky, because its just one window of top of another and it didn't 'connected' to something at all. So just visual hack if that can be called like this. The same will be with all the others stuff which we want at top bar (keymap swither, volume control), then all will overwrite all together, user will need manually to move it on necessary position, i.e. : primitive, old and non-user friendly problems. With introducing top-bar modules everything will be fine in that terms.

So.. After small intro , the reasons of that thread is to discuss how to do it all from programming point of view. I.e. what and how it all should reacts on amigaos and so on.
I think currently about that (can be very wrong, because know not so many about):

1. screen bar modules can be something like commodities (i.e. the same code, the same stuff). Maybe they even can be commodities at all (so "exchange" usage and co).
2. workbench top-bar module, should have some new hook or so introduced, which will allow to insert/remove plugins from.
3. introduce new flag or so for commodities based code (if it will be commodities), with some necessary options which will says that it is screen bar module
4. they should have inbuild functionality for "remove" and "add" them from users side. So those ones who want will have them (or only those ones they want), those ones who do not want them at all, can remove them all or keep only few as well.

Let's discuss it all, and when everything will be sorted to some sort of "we need x,y,z", i can then make a feature request to os4 BZ.

[Amigo1]

I think it would be nice to have, good idea and I would welcome it. To your 4 ideas I like to add:

5) option for all or just some screenbar options/commodities to follow on other screens (like for example volume control: if I have webrowser in other screen, I not want to switch back to Workbench for change volume, or other example keyboard-switch-commodity: if I have screen open for PageStream would be very inconvenient to switch to WB if no Keyboard-shortcut defined.

[kas1e]

@Amigo1

Yep, there should be some flag in code like "Plugin_For_All_Screen, TRUE" , and then any opened screen will have the same top bar plugins, but if nothing set or FALSE, then just for WB.

[fingus]

I like the Idea!

[kas1e]

I like the Idea!

That not enough What you can add really other than you like it ?

[abalaban]

To me what you are describing can be acheived today using AmiDock's dockies... The only thing is that application programmers need to use existing features...

Of course AmiDock could be enhanced to support a new kind of dock that would only allow application dockies. That's almost what I already do: I've setup a dock which is tied to the upper right corner of my screen, this dock is transparent, stick to the background and is defined to be the one in which dockies are added.

[kas1e]

@abalaban

To me what you are describing can be acheived today using AmiDock's dockies... The only thing is that application programmers need to use existing features..

Sure, but as i point out before every other oses have top bar modules, of course together with panel, and still, they all have top-bar-tray-kind-stuff. There is many reasons for that, some of them i already describe before too:

1. some users do not want amidock at all. I mean completely do not want to have those panels. they have their problems, and will it ever fixed or not no one know.
2. even if another user is ok with loading amidock, he still will need to boring and worring about how to setup amidock, how to do all what he need, its just pretty boring and unfriendly, really.
3. Of course, topbar modules can be expanded by features later, which not avail and will not in amidock, because its just different, and purposes are different.
4. have it all connected to amidock make coding of top-bar stuff annoing => you should make app, which will only looks and feels as you want only when user will make it like this (if he ever will understand that he can do it, what no one do most of time).


I know, we can say "but well, we have some another kind of solution, why bother", but bother because it can be done better for end users, and just be fast and efficient. For sure you know that all the other on all the other oses do it not just because they have panels, but because it is right for end users to have it.

That's almost what I already do: I've setup a dock which is tied to the upper right corner of my screen, this dock is transparent, stick to the background and is defined to be the one in which dockies are added.

I.e. you tryed to mimick top-bar functionality, which we do not have. So, you also want it, but currently just make some workaround which almost looks like this , but still not.

[jaokim]

I am all for the conceptual ideas presented, but I think that instead of dissing an implemented concept and API already in use (AmiDock), it'd be wiser to suggest enhancements to AmiDock.

All points you describe are technically possible to do today with Dockies -- its only the visual and usability requirements that aren't possible.
For instance, adding the ability for a user to configure where certain applications should put their Dockies. There is already the notion of a specific application dockie, so it shouldn't be impossible.
The topbar "area" could be implemented as a default dock in AmiDock, and AmiDock would be responsible to draw it where it should be.

[kas1e]

@jaokim

We also do not know if author of amidock will works on it (but only him know the code good), and will he in interest to do all of this. Will he improve it or not at all. While new stuff can be done

The topbar "area" could be implemented as a default dock in AmiDock, and AmiDock would be responsible to draw it where it should be.

Then such amidock panel should be added by default in default os4 installation where should be added at least "volume docky" "keymap switcher docky" and "digi clock docky". Also pressing on them should not run them, but should bring a settings instead. It also should have some more visual feedback , like pressing and holding will "press it in deep of screen", not like it now, you press on icon and it just flashes and app runs.

[jaokim]

1. some users do not want amidock at all. I mean completely do not want to have those panels.

And you're sure they'd want a top level panel?

If they'd want on, they could just rmove all other AmiDocks, and only keep the top bar.

2. even if another user is ok with loading amidock, he still will need to boring and worring about how to setup amidock, how to do all what he need, its just pretty boring and unfriendly, really.

So, an enhacement request to AmiDock would be in place.

4. have it all connected to amidock make coding of top-bar stuff annoing => you should make app, which will only looks and feels as you want only when user will make it like this (if he ever will understand that he can do it, what no one do most of time).

As a a devleoper, I wouldn't want yet another decision of where to put my application's dockies (or top level bar icons), and certainly not another API.
As a user I'd like to be able to choose if I want YAM's icon in top bar, or as a normal docky. As a user I'd also not like to have top bar icons that couldn't be move to the AmiDock, and vice versa.

That's almost what I already do: I've setup a dock which is tied to the upper right corner of my screen, this dock is transparent, stick to the background and is defined to be the one in which dockies are added.

I.e. you tryed to mimick top-bar functionality, which we do not have. So, you also want it, but currently just make some workaround which almost looks like this , but still not.

Yes, i want it as well, but not as a new concept, but rather as an enhacements made to AmiDock.