we need inbuild keymap switcher as commoditie
Re: we need inbuild keymap switcher as commoditie
@Trixie
I confirm too for NetDock tray docky
I confirm too for NetDock tray docky
http://apps.amistore.net/zTools
X1000 - AmigaOS 4.1.6 / 4.1 FE
X1000 - AmigaOS 4.1.6 / 4.1 FE
- javierdlr
- Beta Tester
- Posts: 389
- Joined: Sun Jun 19, 2011 10:13 pm
- Location: Donostia (GUIPUZCOA) - Spain
- Contact:
Re: we need inbuild keymap switcher as commoditie
BTW is someone wants to test it, drop me a PM and i'll send you ASAP an almost-working beta version (source code included if you want too).
Re: we need inbuild keymap switcher as commoditie
@all
Javier right, i tested right now his latest beta of switcher : and base are done. I.e. for first keymap it read intput.prefs, and for second keymap with choice it in settings (or also can use tooltype by default). Then, we press lbm on dock image (which are rendered flag of the keymap from input.prefs by default), it spawn 2 flags related to choicen keymaps, choice any of them and keymap switch happens. So it do all the basics already, now just need some love and polishing of actual rendering in dock, making menus looks good, and then if Javier will not bored at this moment adding of commodity broker + to settings one more option to set key-combo for switch , and we are ready
Through, till we all works on this, i see limitation of amidock in terms of re-scaling when it come to re-scale not just icons, but any graphics data in the dock. Imho, amidock should have not just "icon rescale factor", or "icon min size / icon max size" , but instead some global "re-scale factor", and global "size min / size max" which will re-scale anything placed in dock. And icons, and any data in it. So , then will not matter how code do the docky look in the dock: self-rendered something, or just icon. It will be re scaled the same at one time, and then users can make any kind of docks and their looks, and does not matter what in.
Because as it now, it come to some harder and boring work for dockies makers. For example in netdock docky and in keymaps switcher docky we use hardcore 24x24 images, which for example fits fine to tray-bar kind dock, but if one want to see them bigger, or smaller, or whatever, then they can't re-scale it normally from amidock options. At least , in case with NetDock when its in minidock mode (that 24x24 image), we also have tooltype like "minidock_size=24", and there we can set any size, so data will be re-scaled internally by code of the dock. Sure, its kind of help to deal with another that 24x24 sizes, but then its come to "do some code which amidock itself should handle" , and of course, its not very friendly to setup good-looking dock, when you need to change tooltypes of dock (or even worse, when docky even didn't have such tooltypes but do some rendering to dock).
What i mean, that imho need to make one more BZ for amidock with words : "re scale not only icons size, but any graphics data which in the dock". Right ?
Javier right, i tested right now his latest beta of switcher : and base are done. I.e. for first keymap it read intput.prefs, and for second keymap with choice it in settings (or also can use tooltype by default). Then, we press lbm on dock image (which are rendered flag of the keymap from input.prefs by default), it spawn 2 flags related to choicen keymaps, choice any of them and keymap switch happens. So it do all the basics already, now just need some love and polishing of actual rendering in dock, making menus looks good, and then if Javier will not bored at this moment adding of commodity broker + to settings one more option to set key-combo for switch , and we are ready
Through, till we all works on this, i see limitation of amidock in terms of re-scaling when it come to re-scale not just icons, but any graphics data in the dock. Imho, amidock should have not just "icon rescale factor", or "icon min size / icon max size" , but instead some global "re-scale factor", and global "size min / size max" which will re-scale anything placed in dock. And icons, and any data in it. So , then will not matter how code do the docky look in the dock: self-rendered something, or just icon. It will be re scaled the same at one time, and then users can make any kind of docks and their looks, and does not matter what in.
Because as it now, it come to some harder and boring work for dockies makers. For example in netdock docky and in keymaps switcher docky we use hardcore 24x24 images, which for example fits fine to tray-bar kind dock, but if one want to see them bigger, or smaller, or whatever, then they can't re-scale it normally from amidock options. At least , in case with NetDock when its in minidock mode (that 24x24 image), we also have tooltype like "minidock_size=24", and there we can set any size, so data will be re-scaled internally by code of the dock. Sure, its kind of help to deal with another that 24x24 sizes, but then its come to "do some code which amidock itself should handle" , and of course, its not very friendly to setup good-looking dock, when you need to change tooltypes of dock (or even worse, when docky even didn't have such tooltypes but do some rendering to dock).
What i mean, that imho need to make one more BZ for amidock with words : "re scale not only icons size, but any graphics data which in the dock". Right ?
Re: we need inbuild keymap switcher as commoditie
@all
Javier to president:
Javier to president:
- Attachments
-
- keymap_switcher_almost_done.jpg (9.16 KiB) Viewed 9733 times
Re: we need inbuild keymap switcher as commoditie
@Javier :
It works finally ?
It works finally ?
http://apps.amistore.net/zTools
X1000 - AmigaOS 4.1.6 / 4.1 FE
X1000 - AmigaOS 4.1.6 / 4.1 FE
- javierdlr
- Beta Tester
- Posts: 389
- Joined: Sun Jun 19, 2011 10:13 pm
- Location: Donostia (GUIPUZCOA) - Spain
- Contact:
Re: we need inbuild keymap switcher as commoditie
Sort of I have a freeze if I drag&drop an icon over docky/flag_icon ¿:-P.
Tried to use bitmap.image to load the image flag (shows pink rectangle instead of flag image):
instead of (see image flag OK):
PS: apart obious doesn't/does work
PS2: sorry if I try to make a big NO_NO_NEVER_WILL_WORK
Tried to use bitmap.image to load the image flag (shows pink rectangle instead of flag image):
Code: Select all
picObject = IIntuition->NewObject(NULL, "bitmap.image",
BITMAP_SourceFile, keymapflag,
TAG_DONE);
Code: Select all
picObject = IDataTypes->NewDTObject(keymapflag,
PDTA_DestMode, PMODE_V43,
DTA_GroupID, GID_PICTURE,
TAG_DONE);
PS2: sorry if I try to make a big NO_NO_NEVER_WILL_WORK
Re: we need inbuild keymap switcher as commoditie
I don't understand,
With the code that I sent you, you still have pink rectangle instead of flags ?
It worked well for me (and it seems for Kas1e, too).
With the code that I sent you, you still have pink rectangle instead of flags ?
It worked well for me (and it seems for Kas1e, too).
http://apps.amistore.net/zTools
X1000 - AmigaOS 4.1.6 / 4.1 FE
X1000 - AmigaOS 4.1.6 / 4.1 FE
- javierdlr
- Beta Tester
- Posts: 389
- Joined: Sun Jun 19, 2011 10:13 pm
- Location: Donostia (GUIPUZCOA) - Spain
- Contact:
Re: we need inbuild keymap switcher as commoditie
It works, but as soon as I drag&drop an icon over its docky -> system freezes.zzd10h wrote:I don't understand,
With the code that I sent you, you still have pink rectangle instead of flags ?
It worked well for me (and it seems for Kas1e, too).
Seems if I havel 'LoadImage()' in 'DOCKYSET_RedrawNow' is the culptrit, trying to find a better "place" to load flag sorry for all the hassle and A BIG BIG THX for helping me out.
EDIT: moved to' _Screen' and not disposing image until quit/release seems solves this freeze problem!!!
Re: we need inbuild keymap switcher as commoditie
@javierdl
Out of sheer curiosity - is there a reason why you decided not to provide the screen pointer in BITMAP_Screen here? The pointer is normally required.Code: Select all
picObject = IIntuition->NewObject(NULL, "bitmap.image", BITMAP_SourceFile, keymapflag, TAG_DONE);
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
- javierdlr
- Beta Tester
- Posts: 389
- Joined: Sun Jun 19, 2011 10:13 pm
- Location: Donostia (GUIPUZCOA) - Spain
- Contact:
Re: we need inbuild keymap switcher as commoditie
Can't remember if I tried with/without such tag, will test it again and post here results.trixie wrote:@javierdl
Out of sheer curiosity - is there a reason why you decided not to provide the screen pointer in BITMAP_Screen here? The pointer is normally required.Code: Select all
picObject = IIntuition->NewObject(NULL, "bitmap.image", BITMAP_SourceFile, keymapflag, TAG_DONE);
EDIT1: tried with/without Screen tag and no difference it shows a pink rectangle instead of the image/flag (when using bitmap.image).