I think it seems that way because a docky != broker. If you want something to respond to keystrokes and hang in the background then a broker makes the most sense. I don't understand why you are still messing around with a docky.. for some silly flag? We can find a better solution once the commodity is finished.trixie wrote:BTW, such things would be so much easier if AmiDock (a commodity itself) was able to pass CX events on to its dockies! This way a docky that wants to intercept input events would not have to setup its own broker. Currently it's just a waste of system resources.
we need inbuild keymap switcher as commoditie
Re: we need inbuild keymap switcher as commoditie
ExecSG Team Lead
Re: we need inbuild keymap switcher as commoditie
@ssolie
No particular reason As I can't code at the moment, I'm just gathering information and points of view, that's all.I don't understand why you are still messing around with a docky..
Fair enough. It'll be a commodity then, and let's see where it takes us.for some silly flag? We can find a better solution once the commodity is finished.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
- salass00
- AmigaOS Core Developer
- Posts: 530
- Joined: Sat Jun 18, 2011 3:12 pm
- Location: Finland
- Contact:
Re: we need inbuild keymap switcher as commoditie
If you're not making a docky you could optionally use Ringhio to notify the user that the keymap has been switched.trixie wrote: Fair enough. It'll be a commodity then, and let's see where it takes us.
Re: we need inbuild keymap switcher as commoditie
@All
1). Docky can be grouped in the dock, so users can make tray-kind docks or whatever which is very usefull. They may group it as they wish, and put where they wish. And so they can move all the dockies at one time as one group, and no need to fancy regroup every single thing when it different commodities.
2). With docky you have no need to deal where to place visual things, its already in the dock. While when it will be commoditie with visual things, you will have needs to place it manually somewhere, somehow group and can be able to move it together with all that dock where you have another tray-kind dockies.
3). Flags is not silly. Its prove to be good as visual output, not only on one os, but on all the popular oses (i.e. win32, unixes, morphos and whatever else i see which have keymaps, all the time have visual note like this, so its quite understandable). How else you will note user which language currently set, if not by flags or by some strippend language-name words, like ENG|RUS|GR| and co ? Does not matter in general what need to be render to the docky, "silly flags", or words. Ideally there should be preference where use can choice flags or words. But it should be noted on screen all the time which language is set currently.
4). Making it commoditie only, its just like some oldschool way as we do on os3, and then have bunch of them, which not grouped normally visually, which just all different from each others and have no one single rule of how visuals and mouse handling done. While with dockyies its all understandable and kind of the same. Users can change the size of the visual things by just using scale stuff in the amidock prefs and co.
And something else which i don't remember from top of head.
1). Docky can be grouped in the dock, so users can make tray-kind docks or whatever which is very usefull. They may group it as they wish, and put where they wish. And so they can move all the dockies at one time as one group, and no need to fancy regroup every single thing when it different commodities.
2). With docky you have no need to deal where to place visual things, its already in the dock. While when it will be commoditie with visual things, you will have needs to place it manually somewhere, somehow group and can be able to move it together with all that dock where you have another tray-kind dockies.
3). Flags is not silly. Its prove to be good as visual output, not only on one os, but on all the popular oses (i.e. win32, unixes, morphos and whatever else i see which have keymaps, all the time have visual note like this, so its quite understandable). How else you will note user which language currently set, if not by flags or by some strippend language-name words, like ENG|RUS|GR| and co ? Does not matter in general what need to be render to the docky, "silly flags", or words. Ideally there should be preference where use can choice flags or words. But it should be noted on screen all the time which language is set currently.
4). Making it commoditie only, its just like some oldschool way as we do on os3, and then have bunch of them, which not grouped normally visually, which just all different from each others and have no one single rule of how visuals and mouse handling done. While with dockyies its all understandable and kind of the same. Users can change the size of the visual things by just using scale stuff in the amidock prefs and co.
And something else which i don't remember from top of head.
Re: we need inbuild keymap switcher as commoditie
@ salass00
But then I would have to register the program as an application as well, wouldn't I? To be able to use the Notify() function.you could optionally use Ringhio to notify the user that the keymap has been switched.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
- salass00
- AmigaOS Core Developer
- Posts: 530
- Joined: Sat Jun 18, 2011 3:12 pm
- Location: Finland
- Contact:
Re: we need inbuild keymap switcher as commoditie
Why would that be a problem?trixie wrote: But then I would have to register the program as an application as well, wouldn't I? To be able to use the Notify() function.
Re: we need inbuild keymap switcher as commoditie
@salass00
Not a problem per se, it's just IMHO unnecessary to register a program with two different system frameworks only to be able to use a single feature. As for Nofify(), it should have really been made part of Intuition Library, not Application Library. As the Ringhio message box is in fact a GUI element (much like a requester), it belongs in a library that handles GUIs, and that is Intuition. It is plain stupid that programs that are not really applications - like commodity brokers or plugins - should need to either register with Application Library, or create an ARexx interface only to display a Ringhio message.
Not a problem per se, it's just IMHO unnecessary to register a program with two different system frameworks only to be able to use a single feature. As for Nofify(), it should have really been made part of Intuition Library, not Application Library. As the Ringhio message box is in fact a GUI element (much like a requester), it belongs in a library that handles GUIs, and that is Intuition. It is plain stupid that programs that are not really applications - like commodity brokers or plugins - should need to either register with Application Library, or create an ARexx interface only to display a Ringhio message.
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
-
- Posts: 314
- Joined: Mon May 14, 2012 10:26 pm
- Location: 日本千葉県松戸市 / Matsudo City, Chiba, Japan
- Contact:
Re: we need inbuild keymap switcher as commoditie
I have started writing up a new docky as part of perception and just have the library committed for now...
If you want to expand that with a set of routines needed in the perception library?
i am occasionally experimenting with how to buffer or count keyboard input so that I can post-edit any string for a UTF8 encoding as an option
Does any of this help?
If you want to expand that with a set of routines needed in the perception library?
i am occasionally experimenting with how to buffer or count keyboard input so that I can post-edit any string for a UTF8 encoding as an option
Does any of this help?
Re: we need inbuild keymap switcher as commoditie
@all
I annoy Javier to make a fancy docky (as he have already experience with), and we pretty close now. If only someone will help us with that: viewtopic.php?f=26&t=2018. In general now only to render fancy flags on place of my .icon image, do actual switching when we choice language from menu and some reorganize between LBM/RMB handlers so menu will spawns via LBM without those "docky/remove/etc". Later, if all will ok, commodity broker can be added to handle key-combos => everyone happy. But for beginning even like this it will be more than enough (and fancy fancy flags !)
I annoy Javier to make a fancy docky (as he have already experience with), and we pretty close now. If only someone will help us with that: viewtopic.php?f=26&t=2018. In general now only to render fancy flags on place of my .icon image, do actual switching when we choice language from menu and some reorganize between LBM/RMB handlers so menu will spawns via LBM without those "docky/remove/etc". Later, if all will ok, commodity broker can be added to handle key-combos => everyone happy. But for beginning even like this it will be more than enough (and fancy fancy flags !)
- Attachments
-
- screen (1).jpg (13.98 KiB) Viewed 9689 times
-
- screen2.jpg (43.63 KiB) Viewed 9689 times
Re: we need inbuild keymap switcher as commoditie
@kas1e
Good. We all know that when it comes to coaxing people into doing something, there's no one better than youI annoy Javier to make a fancy docky (as he have already experience with), and we pretty close now.)
The Rear Window blog
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition
AmigaOne X5000 @ 2GHz / 4GB RAM / Radeon RX 560 / ESI Juli@ / AmigaOS 4.1 Final Edition
SAM440ep-flex @ 667MHz / 1GB RAM / Radeon 9250 / AmigaOS 4.1 Final Edition