On Sun, Aug 07, 2005 at 08:19:33PM +0200, Viktor Griph wrote: > On Sun, 7 Aug 2005, Dominik Vogt wrote: > >On Sun, Aug 07, 2005 at 02:21:24PM +0200, Dominik Vogt wrote: > >>On Sun, Aug 07, 2005 at 12:44:26PM +0200, Viktor Griph wrote: > >>>On Sun, 7 Aug 2005, Dominik Vogt wrote: > >>[snip] > >>>>>Could someone with cvs wrilte-access apply this patch? > >>>> > >>>>I'd first like to understand what the patch does exactly. Please > >>>>elaborate on how the new feature works. > >>>This is a menufeel patch. It allows for selecting a menu item with a > >>>mouse > >>>wheel as follows: > >>> > >>>When the Menustyle Scroll is not Off the use of button 4 and 5 > >>>(Mousewheel > >>>up and down) no longer acts as clicks on the menu, but triggers menu > >>>scrolling. Menu scrolling is done i three possible ways: On - Positive > >>>order, menu moving; Inverted - Negative order, menu moving; Pointer > >>>Positive order, Pointer moving. > >>> > >>>When the menu is about to scroll it will find the next selectable item in > >>>the direction of the scroll, and if is On or Inverted (moving menu) the > >>>Menu window will be moved vertically so that the the new item is > >>>vertically centered under the pointer. If the scroll argument is Pointer > >>>the Pointer will wrap vertically to the center of the next item. > >>> > >>>The special case where the menu would have been placed partly outside of > >>>the screen is treated differently depending on the value of > >>>ScrollOffPage. > >>>If ScrollOffPage is true the menu will be allowed to leave the screen. If > >>>not the menu will stop at the edge and Pointer scroll will be used. > >> > >>Sounds interesting. I fear there may be many nasty side effects > >>with the existing menu code - not because the patch is bad but > >>because the menu code is very touchy. I need something to play > >>with (I don't have a mouse wheel). > > > >I've mapped the scroll action to button 3 and shift + button 3 to > >test the code. Some comments: > > > >1) Scrolling the menu off page looks like a useable feature, but: > > > > * Scroll the menu off the screen. > > * Switch to using the cursor keys. > > --> You can't get the menu back on screen > > > > Using the keys should bring it back. > > I've taken care of that in the current candidate > > >2) I'm not particularly fond of the "Scroll On" behaviour because > > it is a mix of scrolling and warping the pointer. I'd remove > > this part. > > Are you sure that is "Scroll On" bahhaviour, and not "ScrollOffPage Off" > behaviour? I've changed ScrollOffPage to default to On as that probably is > the most useful way, and not combines pointer wrapping with menu > scrolling. (Unless trigged from the keyboard, where the pointer always > will wrap to the horizontal center of the menu)
Erm, whatever. You understood what I meant. :-) > >3) I see this whole feature as an extension of the meneShortcuts() > > function. Although it is triggered by the mouse, the behaviour > > is very similar to the keyboard shortcuts. Merging the code > > into menuShortcuts() should not be difficult. > > > > I suggest to translate the button event to a keycode/modifier > > at the start of the menuShortcuts() function. > > Sounds logical. I created my functiion mainly based on menuShortcuts since > it seemed to do similar things, that I wanted to do. I've now merged the > code into menuShortcurs by adding the action SA_SCROLL. I've also in the > same time bound the scrolling to NumPad -/+ as Up/Down. > > > > >4) The "Scroll Pointer" behaviour should be the hard-coded default > > for all menus. > done > > > > >5) I'm not happy about the naming of the "Scroll" argument. "on" > > and "off" should also allow all aliases that the > > parse_toggle_argument() function allows. But that can wait > > until the patch is finalized because the syntax will probably > > change a bit. > I was quite unsure on how to handle the styles when I started. Maybe it > would be better to follow the more common (for menu styles) way of having > more styles that override each others. The reason why I decided not to do > so was the fact that I ended up with two groups, and thought that would be > more confusing. I've left these as they are in this candidate. I don't know yet either. Let's finish the feature first, then worry about the interface. > New updated candidate-patch attached. Yo're fast :-) I won't get around testing the new patch until Thursday, though. [snip] Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED]
signature.asc
Description: Digital signature
