Hyperion Entertainment Message Boards

@Trixie

I confirm too for NetDock tray docky

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).

@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 ?

@all
Javier to president:

@Javier :
It works finally ?

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

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).

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).

It works, but as soon as I drag&drop an icon over its docky -> system freezes.
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!!!

@javierdl

Code: Select all

 picObject = IIntuition->NewObject(NULL, "bitmap.image",
                                     BITMAP_SourceFile, keymapflag,
                                    TAG_DONE);

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.

trixie wrote:@javierdl

Code: Select all

 picObject = IIntuition->NewObject(NULL, "bitmap.image",
                                     BITMAP_SourceFile, keymapflag,
                                    TAG_DONE);

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.

Can't remember if I tried with/without such tag, will test it again and post here results.

EDIT1: tried with/without Screen tag and no difference it shows a pink rectangle instead of the image/flag (when using bitmap.image).