Hyperion Entertainment Message Boards

nbache

CX_POPKEY is normally expected to do, as the name implies: Pop up the GUI.

You are right, using the CX_POPKEY tooltype would be a misuse.

@kas1e

I don't have anything against commodities, quite on the contrary: they are dead easy to make. What gives me the shivers is the top bar window "solution", which is in fact an ugly kludge. But OK, let's say we don't have a better option at the moment.

I personally was in hope to have someday new version of amidock.

I'm becoming increasingly tempted to write my own taskbar solution, perhaps one day I'll find enough time to get down to it.

later, maybe we will get that we need something like "top-bar-modules".

Please file a feature request in the OS4 zilla or wherever you report bugs and suggest new features.

But for first, just small fancy commodities (non docky) are cool to have.

All right, all right. Ask me again next week, I could even have the thing written by then.

Imagine our commodities to be a dockys .. pretty sucky.

The only problem I have with dockies is that they are underdocumented, as a result of which we have very few quality dockies to use. Otherwise I find the docky concept quite good (how AmiDock does the actual rendering is another story).

@Trixie

Please file a feature request in the OS4 zilla or wherever you report bugs and suggest new features.

Plz let's sort it there : http://forum.hyperion-entertainment.biz ... =36&t=1897
Maybe docky is not that bad way in end .. How hard will be for example to convert AlexC's digiclock to have 1:1 the same, but inside of the amidock's panel ?

And just in case you already start to works on , there is very good place from where grab images for indicator: System:Locale/Flags/Contries/. So when user will choice need it keymap, the necessary flag fill be get and updated in indicator.

I made a small mockup settings window for, quite simple, primitive, but imho good looking and understandable (icons at top bar are inside of amidock panel)


So that window will be shown when user click on that top-bar icon with flag. All Images can be taken from that System:Local/Flags/Contries when user choice a necessary keymap. The same way they should be put in "indicator", and if it will be amidock, then state of icon should be just changed depends on what current keymap is, if it will be border-less window, then the same change just for the window. Will looks and feels quite cool imho.

What i dunno now, its how to make it auto-running just by default when os is running if not as commodity with wbstartup or manual running from startup scripts .. What i mean is that "top bar modules" mean to be running at startup. But as it now its just amidock with icons which i need to click to run it. So, it should be not only in amidock , but also should be running and be in background already: and how to do that all without mess, dunno.

trixie wrote:I don't have anything against commodities, quite on the contrary: they are dead easy to make. What gives me the shivers is the top bar window "solution", which is in fact an ugly kludge. But OK, let's say we don't have a better option at the moment.

It definitely needs to be a commodity - that goes without question (it's a hotkey toggly thing, the user might want to disable/enable it easily, ergo it has to be a commodity)

It probably also needs to be a docky, to indicate which keymap is currently in use and pop up an interface, or toggle between keymaps using the mouse.

To get it in the titlebar, you could set an env-var to the current keymap being used. The WB titlebar can be configured to show env-vars. If it's just a visual thing, that will work fine. If you user wants to click on it, that's another story.

chris wrote:It definitely needs to be a commodity - that goes without question (it's a hotkey toggly thing, the user might want to disable/enable it easily, ergo it has to be a commodity)

It probably also needs to be a docky, to indicate which keymap is currently in use and pop up an interface, or toggle between keymaps using the mouse.

To get it in the titlebar, you could set an env-var to the current keymap being used. The WB titlebar can be configured to show env-vars. If it's just a visual thing, that will work fine. If you user wants to click on it, that's another story.

Sounds like an excellent plan to me. Keep it simple and leverage what is already provided by the OS.

Fancier features like flag graphics, etc. can be added later. The first version should just get the job done.

@chris

(it's a hotkey toggly thing, the user might want to disable/enable it easily, ergo it has to be a commodity). It probably also needs to be a docky /.../

And this is the daft thing about AmiDock. AmiDock itself is a commodity so it is able to process hotkey events already. Having to make a docky a commodity too only to support key-switching is plain silly. Instead, AmiDock should let dockies define their own hotkeys, process the hotkey events on its commodity input stream, and notify the respective docky when a relevant event arrives so that the docky can react to it. (Or perhaps AmiDock can already do this but as we have practically no documentation on making dockies... you know the score.)

@ssolie

chris wrote:To get it in the titlebar, you could set an env-var to the current keymap being used. The WB titlebar can be configured to show env-vars.

ssolie wrote:Sounds like an excellent plan to me.

OK, interesting, let's go down this route: the commodity will key-switch between keymaps, and each time the keymap changes, an env var is written. Will the WB screen bar update the display automatically, or do I have to do something to show the new env value? (EDIT: question answered below)

trixie wrote: OK, interesting, let's go down this route: the commodity will key-switch between keymaps, and each time the keymap changes, an env var is written. Will the WB screen bar update the display automatically, or do I have to do something to show the new env value?

I don't know the insides, but I think it's updated automatically, since it is possible to set the "Update delay" in SYS:Prefs/Workbench

@Amigo1

I don't know the insides, but I think it's updated automatically

You are right, I've just checked - the update is done automatically in the specified interval.


@ssolie

Is there a reserved global env variable for the current keymap (just like there is for language and charset)? If not, it would be a good thing to have it.

@Trixie

OK, interesting, let's go down this route: the commodity will key-switch between keymaps, and each time the keymap changes, an env var is written.

There is bunch of limitations then:

1). User can't dbl-click on that , so to have some menu spawn where he can choice by mouse keymap as well as "settings".
2). No top-bar-module look
3). for making env var writing on top bar, need to configure top-bar specially

In end of all, if top-bar will be used only for indication, then why need that top-bar with env woring at all, when it can be just border less window just the same as AlexC do with digiclock ? I mean, why then making mess for users to force them to somehow configure workbench's topbar ?

The reasons why top-bar is good, is that :

1). user can dbl-click on it (necessary)
2). it will looks nice
3). it will looks like real top-bar module if it will be used together with amidock (and later, we can write on wiki article about amidocks, and about how to write top-bar dockys, of what size they should be, and what to do to make them right)


That env thingy imho fuzz from nothing, we can indicate them by any other way, no need top bar connection then.

Why not go the route with flags (which is cool and nice) ? Even just making it as window, just like AlexC do. Why need that env stuff ?