Re: [PATCH 6/6] Docks menu bottom extra space
On 05/04/2013 11:30, BALATON Zoltan wrote: > On Thu, 4 Apr 2013, Rodolfo García Peñas wrote: >> Remove the "+ 2" is ok, but I think we should thing in change >> the things to re-use the same functions. > > You can think of that but that's beyond fixing this bug. > >> Anyway, if we remove the "+ 2" (line 3222), the problem with the >> Clip (probably Dock) is gone. But, the menu is hidden, you must >> move the mouse down to see it (you cannot see nothing). > > That's how it works if Scroll off screen menus option is turned on > for app icons too and that's how it's supposed to work. > >> In my patch, the menu is moved up 20 pixels, then, the first >> menú entry is painted in the screen and you know that the menu is >> there, partially hidden, but there. > > While this may seem like a good idea it isn't necessarily so > because the rationale behind the scroll off screen menus feature is > that menus should behave the same independent of screen position > (to allow to build "muscle memory" and know that a certain down > move will activate the same menu item everywhere instead of having > to find it and aim at it constantly). Thus when using this option > you're supposed to know the menu is there and don't need visual > clues for that. (That said the current implementation is not > perfect because the menu scrolls up too fast so it's still not the > same amount of downward move to select menu entries as elswhere on > the screen but that's probably another bug. Maybe the menu is now > scrolled if the pointer is at the screen edge but should only be > scrolled for downward move events instead. I didn't check if this > theory is true though.) > > Regards, BALATON Zoltan Eh! Don't be lazy. Write the patch :-) Saludos! kix -- ||// //\\// Rodolfo "kix" Garcia ||\\// //\\ http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 6/6] Docks menu bottom extra space
On Thu, 4 Apr 2013, Rodolfo García Peñas wrote: Remove the "+ 2" is ok, but I think we should thing in change the things to re-use the same functions. You can think of that but that's beyond fixing this bug. Anyway, if we remove the "+ 2" (line 3222), the problem with the Clip (probably Dock) is gone. But, the menu is hidden, you must move the mouse down to see it (you cannot see nothing). That's how it works if Scroll off screen menus option is turned on for app icons too and that's how it's supposed to work. In my patch, the menu is moved up 20 pixels, then, the first menú entry is painted in the screen and you know that the menu is there, partially hidden, but there. While this may seem like a good idea it isn't necessarily so because the rationale behind the scroll off screen menus feature is that menus should behave the same independent of screen position (to allow to build "muscle memory" and know that a certain down move will activate the same menu item everywhere instead of having to find it and aim at it constantly). Thus when using this option you're supposed to know the menu is there and don't need visual clues for that. (That said the current implementation is not perfect because the menu scrolls up too fast so it's still not the same amount of downward move to select menu entries as elswhere on the screen but that's probably another bug. Maybe the menu is now scrolled if the pointer is at the screen edge but should only be scrolled for downward move events instead. I didn't check if this theory is true though.) Regards, BALATON Zoltan
Re: [PATCH 6/6] Docks menu bottom extra space
On Thu, 04 Apr 2013, BALATON Zoltan escribió:
> On Thu, 4 Apr 2013, Rodolfo García Peñas wrote:
> >dock.c:
> >8<--
> > wMenuMapAt(dock->menu, x_pos, event->xbutton.y_root + 2, False);
> >8<--
>
> So this is where the two pixel gap comes from. It may work with
> Scroll off screen menus turned on if the + 2 is simply removed but I
> don't want to recompile to try this now. Annyone wants to test?
In line 3222:
8<--
if (dock->type == WM_CLIP) {
/*x_pos = event->xbutton.x_root+2; */
x_pos = event->xbutton.x_root - dock->menu->frame->core->width
/ 2 - 1;
if (x_pos < 0) {
x_pos = 0;
} else if (x_pos + dock->menu->frame->core->width >
scr->scr_width - 2) {
x_pos = scr->scr_width - dock->menu->frame->core->width
- 4;
}
} else {
x_pos = dock->on_right_side ? scr->scr_width -
dock->menu->frame->core->width - 3 : 0;
}
wMenuMapAt(dock->menu, x_pos, event->xbutton.y_root + 2, False);
8<--
or line 3761:
8<--
xpos = event->xbutton.x_root - wsMenu->frame->core->width / 2 - 1;
if (xpos < 0) {
xpos = 0;
} else if (xpos + wsMenu->frame->core->width > scr->scr_width - 2) {
xpos = scr->scr_width - wsMenu->frame->core->width - 4;
}
wMenuMapAt(wsMenu, xpos, event->xbutton.y_root + 2, False);
8<--
Remove the "+ 2" is ok, but I think we should thing in change the things to
re-use the same functions.
Anyway, if we remove the "+ 2" (line 3222), the problem with the Clip (probably
Dock) is gone. But, the menu is hidden, you must move the mouse down to see it
(you cannot see nothing). In my patch, the menu is moved up 20 pixels, then,
the first menú entry is painted in the screen and you know that the menu is
there, partially hidden, but there.
kix
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 6/6] Docks menu bottom extra space
On Thu, 4 Apr 2013, Rodolfo García Peñas wrote: dock.c: 8<-- wMenuMapAt(dock->menu, x_pos, event->xbutton.y_root + 2, False); 8<-- So this is where the two pixel gap comes from. It may work with Scroll off screen menus turned on if the + 2 is simply removed but I don't want to recompile to try this now. Annyone wants to test? Regards, BALATON Zoltan
Re: [PATCH 6/6] Docks menu bottom extra space
On Thu, 04 Apr 2013, BALATON Zoltan escribió:
> On Thu, 4 Apr 2013, Daniel Déchelotte wrote:
> >>Before this patch, if the Dock/Clip is in the screen bottom, and clip
> >>to
> >>show the menu in the bottom area, the menu is hidden outside the
> >>screen.
> >
> >Sorry for chiming in without fully understanding the bug and the
> >fix, but IIUC, wMenuMapAt() is given the "preferred" (x,y)
> >coordinates where to display the menu. Then it is responsible for
> >overriding them if the menu would appear off-screen and if asked
> >by the user's preferences. IOW, the logic of "we are too close to
> >the border, let's move a bit" should happen in wMenuMapAt, and
> >only if the appropriate preference is set. No?
>
> As someone who uses the "appropriate preference" (Scroll off screen
> menus is on) tried it and seems that it works all right for app
> icons at the bottom of the screen but for docked app icons the menus
> are indeed inaccessible if the pointer is within two pixels of the
> bottom of the screen. These two pixels seem to also exist when menus
> are displayed elsewhere: App icon menus are open with the pointer
> touching their top (moving down one pixel selects the first menu
> item) while for docked/clipped appicons there's a two pixel gap
> between the pointer and the menu (only the third pixel down will
> select the menu). This might be something to do with this bug but I
> don't know where does it come from.
>
> Regards,
> BALATON Zoltan
The main problem is that appicon has their own code to calculate the x_pos and
the y_pos to show the menu. docks has their own code to to the same,...
appicon.c:openApplicationMenu(...)
8<--
x -= menu->frame->core->width / 2;
if (x + menu->frame->core->width > scr->scr_width)
x = scr->scr_width - menu->frame->core->width;
if (x < 0)
x = 0;
/* set client data */
for (i = 0; i < menu->entry_no; i++)
menu->entries[i]->clientdata = wapp;
wMenuMapAt(menu, x, y, False);
8<--
dock.c:
8<--
if (dock->type == WM_CLIP) {
/*x_pos = event->xbutton.x_root+2; */
x_pos = event->xbutton.x_root - dock->menu->frame->core->width
/ 2 - 1;
if (x_pos < 0) {
x_pos = 0;
} else if (x_pos + dock->menu->frame->core->width >
scr->scr_width - 2) {
x_pos = scr->scr_width - dock->menu->frame->core->width
- 4;
}
} else {
x_pos = dock->on_right_side ? scr->scr_width -
dock->menu->frame->core->width - 3 : 0;
}
wMenuMapAt(dock->menu, x_pos, event->xbutton.y_root + 2, False);
8<--
I wrote a patch here to change the WM_DOCK behavior, why the x_pos is 0 or the
screen width minus the dock size?? We can use the clicked point too. Anyway,
IMO, we should use the same functions to show the menu, for docks, appicons,...
kix
--
||// //\\// Rodolfo "kix" Garcia
||\\// //\\ http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: [PATCH 6/6] Docks menu bottom extra space
On Thu, 4 Apr 2013, Daniel Déchelotte wrote: Before this patch, if the Dock/Clip is in the screen bottom, and clip to show the menu in the bottom area, the menu is hidden outside the screen. Sorry for chiming in without fully understanding the bug and the fix, but IIUC, wMenuMapAt() is given the "preferred" (x,y) coordinates where to display the menu. Then it is responsible for overriding them if the menu would appear off-screen and if asked by the user's preferences. IOW, the logic of "we are too close to the border, let's move a bit" should happen in wMenuMapAt, and only if the appropriate preference is set. No? As someone who uses the "appropriate preference" (Scroll off screen menus is on) tried it and seems that it works all right for app icons at the bottom of the screen but for docked app icons the menus are indeed inaccessible if the pointer is within two pixels of the bottom of the screen. These two pixels seem to also exist when menus are displayed elsewhere: App icon menus are open with the pointer touching their top (moving down one pixel selects the first menu item) while for docked/clipped appicons there's a two pixel gap between the pointer and the menu (only the third pixel down will select the menu). This might be something to do with this bug but I don't know where does it come from. Regards, BALATON Zoltan
Re: [PATCH 6/6] Docks menu bottom extra space
- Mail original - > From: "Rodolfo García Peñas (kix)" > > This patch includes check that is enough extra space below the > clicked > point and the bottom of the screen, to show the Dock menu. > > Before this patch, if the Dock/Clip is in the screen bottom, and clip > to > show the menu in the bottom area, the menu is hidden outside the > screen. Sorry for chiming in without fully understanding the bug and the fix, but IIUC, wMenuMapAt() is given the "preferred" (x,y) coordinates where to display the menu. Then it is responsible for overriding them if the menu would appear off-screen and if asked by the user's preferences. IOW, the logic of "we are too close to the border, let's move a bit" should happen in wMenuMapAt, and only if the appropriate preference is set. No? -- Daniel > --- > src/dock.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/src/dock.c b/src/dock.c > index 0140bd1..5d56528 100644 > --- a/src/dock.c > +++ b/src/dock.c > @@ -61,6 +61,8 @@ > #define CLIP_IDLE 0 > #define CLIP_FORWARD 2 > > +#define BORDER_SPACE 10 > + > / Global variables / > extern Cursor wCursor[WCUR_LAST]; > extern WPreferences wPreferences; > @@ -3070,7 +3072,7 @@ static void openDockMenu(WDock *dock, WAppIcon > *aicon, XEvent *event) > WMenuEntry *entry; > WApplication *wapp = NULL; > int index = 0; > - int x_pos; > + int x_pos, y_pos; > int n_selected; > int appIsRunning = aicon->running && aicon->icon && > aicon->icon->owner; > > @@ -3219,7 +3221,12 @@ static void openDockMenu(WDock *dock, WAppIcon > *aicon, XEvent *event) > x_pos = dock->on_right_side ? scr->scr_width - > dock->menu->frame->core->width - 3 : 0; > } > > - wMenuMapAt(dock->menu, x_pos, event->xbutton.y_root + 2, False); > + /* If the menu is near of the screen's bottom, move it up 20px */ > + y_pos = event->xbutton.y_root; > + if (y_pos >= scr->scr_height - BORDER_SPACE) > + y_pos = y_pos - (2 * BORDER_SPACE); > + > + wMenuMapAt(dock->menu, x_pos, y_pos, False); > > /* allow drag select */ > event->xany.send_event = True; > -- > 1.7.10.4 > > > -- > To unsubscribe, send mail to > wmaker-dev-unsubscr...@lists.windowmaker.org. > -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
[PATCH 6/6] Docks menu bottom extra space
From: "Rodolfo García Peñas (kix)" This patch includes check that is enough extra space below the clicked point and the bottom of the screen, to show the Dock menu. Before this patch, if the Dock/Clip is in the screen bottom, and clip to show the menu in the bottom area, the menu is hidden outside the screen. --- src/dock.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/src/dock.c b/src/dock.c index 0140bd1..5d56528 100644 --- a/src/dock.c +++ b/src/dock.c @@ -61,6 +61,8 @@ #define CLIP_IDLE 0 #define CLIP_FORWARD 2 +#define BORDER_SPACE 10 + / Global variables / extern Cursor wCursor[WCUR_LAST]; extern WPreferences wPreferences; @@ -3070,7 +3072,7 @@ static void openDockMenu(WDock *dock, WAppIcon *aicon, XEvent *event) WMenuEntry *entry; WApplication *wapp = NULL; int index = 0; - int x_pos; + int x_pos, y_pos; int n_selected; int appIsRunning = aicon->running && aicon->icon && aicon->icon->owner; @@ -3219,7 +3221,12 @@ static void openDockMenu(WDock *dock, WAppIcon *aicon, XEvent *event) x_pos = dock->on_right_side ? scr->scr_width - dock->menu->frame->core->width - 3 : 0; } - wMenuMapAt(dock->menu, x_pos, event->xbutton.y_root + 2, False); + /* If the menu is near of the screen's bottom, move it up 20px */ + y_pos = event->xbutton.y_root; + if (y_pos >= scr->scr_height - BORDER_SPACE) + y_pos = y_pos - (2 * BORDER_SPACE); + + wMenuMapAt(dock->menu, x_pos, y_pos, False); /* allow drag select */ event->xany.send_event = True; -- 1.7.10.4 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
