Page 2 of 2
Posted: 24 Nov 2007 18:04
by admin
j_c_hallgren wrote:Sound like a job for either a config option or INI tweak! That way, you can take your choice...ok, so it may be more complicated, but given as to the totally different ways we use the product, it may be best solution.
Yes, probably true. But not easy to phrase without raising confusion. So I rather make it a tweak. So what should be the default/factory position for those key-triggered menus:
(1) at mouse cursor?
(2) at tree corner?
Posted: 24 Nov 2007 18:08
by RalphM
Why don't you leave the factory default the way it was so far?
The users wishing to have it at tree corner will happily adapt the tweak, me thinks.
Posted: 24 Nov 2007 18:14
by jacky
admin wrote:So what should be the default/factory position for those key-triggered menus:
(1) at mouse cursor?
(2) at tree corner?
at mouse cursor. Just because I like it that way
Also, it's the standard default behavior I believe (hit the ctxt menu key if you got one for instance, and it will be at cursor position) as well as the XY "default", at least up until now.
Posted: 24 Nov 2007 18:16
by bergfex
RalphM wrote:Why don't you leave the factory default the way it was so far?
The users wishing to have it at tree corner will happily adapt the tweak, me thinks.
Sounds like the best solution to me.
Posted: 24 Nov 2007 18:50
by admin
jacky wrote:admin wrote:So what should be the default/factory position for those key-triggered menus:
(1) at mouse cursor?
(2) at tree corner?
at mouse cursor. Just because I like it that way
Also, it's the standard default behavior I believe (hit the ctxt menu key if you got one for instance, and it will be at cursor position) as well as the XY "default", at least up until now.
No, not here. Right here in IE for example it is "at tree". Same in OE, in Firefox, everywhere. i did not find one app (apart from XY) where it is at mouse cursor!

Posted: 24 Nov 2007 18:51
by admin
bergfex wrote:RalphM wrote:Why don't you leave the factory default the way it was so far?
The users wishing to have it at tree corner will happily adapt the tweak, me thinks.
Sounds like the best solution to me.
Yep.
PS: not long ago I went pro mouse:
Code: Select all
v6.10.0072 - 2007-08-02 17:41
* Menu Go | Hotlist... (Ctrl+H): now the hotlist pops up at the
current mouse position. Smoother workflow...
Posted: 24 Nov 2007 19:26
by jacky
admin wrote:No, not here. Right here in IE for example it is "at tree". Same in OE, in Firefox, everywhere. i did not find one app (apart from XY) where it is at mouse cursor!

Yeah, I meant in XY

Others app tend to behave differently : some "at tree", so on top-left corner, others uses the position a whatever item is selected (when it applies), other at text cursor position, and other again use mouse position (PSP).
Either way, I find mouse position to be the easiest/quickest way to be used, at least according to my workflow... and now everyone's got a choice!
Posted: 25 Nov 2007 06:46
by Gandolf
jacky wrote:... and now everyone's got a choice!
Except, unfortunately, the very menu I wanted - the context menu - is still at the mouse position.
The behaviour for this in files managers does seem to be that the context menu is positioned at the selected item (if available). Even the dreaded WE positions it at the selected item.
Posted: 25 Nov 2007 09:46
by bergfex
Gandolf wrote:Except, unfortunately, the very menu I wanted - the context menu - is still at the mouse position.
The behaviour for this in files managers does seem to be that the context menu is positioned at the selected item (if available). Even the dreaded WE positions it at the selected item.
Yes, even Xplorer² (which opens the other menus at the mouse cursor position, as said before) handles it that way.
If I wouldn't use the mouse but the keyboard to open the context menu, I also would prefer it to open at the selected item position.
But Don said in his post, that the implementation would become too complex, so I don't know...
Posted: 25 Nov 2007 09:52
by admin
bergfex wrote:Gandolf wrote:Except, unfortunately, the very menu I wanted - the context menu - is still at the mouse position.
The behaviour for this in files managers does seem to be that the context menu is positioned at the selected item (if available). Even the dreaded WE positions it at the selected item.
Yes, even Xplorer² (which opens the other menus at the mouse cursor position, as said before) handles it that way.
If I wouldn't use the mouse but the keyboard to open the context menu, I also would prefer it to open at the selected item position.
But Don said in his post, that the implementation would become to complex, so I don't know...
Okay okay... now you are playing with my programmer's pride... I'll add it...

Posted: 25 Nov 2007 10:16
by bergfex
admin wrote:Okay okay... now you are playing with my programmer's pride
I would never dare to do such things.
admin wrote:... I'll add it...

As it really seems to be an important thing for all the keyboard oriented users, I think it's worth the effort.
Posted: 25 Nov 2007 13:11
by Gandolf
admin wrote:... now you are playing with my programmer's pride... I'll add it...

admin wrote:... INI tweak PopupMenusAtSelection got an additional effect: If set to 1 then the context menu of Tree, Catalog, and List items is positioned at the selected/focused item (if the menu is triggered by key)...
Excellent, thank you. I knew you could do it, just needed the right persuasion.
Posted: 25 Nov 2007 13:16
by admin
Gandolf wrote:admin wrote:... now you are playing with my programmer's pride... I'll add it...

admin wrote:... INI tweak PopupMenusAtSelection got an additional effect: If set to 1 then the context menu of Tree, Catalog, and List items is positioned at the selected/focused item (if the menu is triggered by key)...
Excellent, thank you. I knew you could do it, just needed the right persuasion.
Well, I'm running on a hunter-gatherer psyche like most of us: I only move when I'm hungry or something else is hungry for me.
