After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 73074 - Applets should be triggerable by clicking on the screen edges
Applets should be triggerable by clicking on the screen edges
Status: RESOLVED FIXED
Product: gnome-panel
Classification: Other
Component: panel
2.3.x
Other All
: High enhancement
: ---
Assigned To: Panel Maintainers
Panel Maintainers
: 72796 83617 92895 97259 97419 (view as bug list)
Depends on:
Blocks: 55491 73072
 
 
Reported: 2002-03-01 03:43 UTC by Seth Nickell
Modified: 2015-03-24 13:00 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Seth Nickell 2002-03-01 03:43:44 UTC
Currently applets don't have a mechanism for expanding their event region.
This means that, for example, the menu applet can't be triggered when the
user mouses to the extreme top of the screen, and similarly with the
tasklist. We want to allow this behavior somehow.
Comment 1 Luis Villa 2002-03-02 06:33:37 UTC
Calling this API is a /bit/ of a stretch but I presume it would
require an API change of some sort.
Comment 2 Seth Nickell 2002-03-03 00:51:12 UTC
Yes, but it'd be a "non-public" API, i.e. not one in the official
platform.
Comment 3 Gregory Merchan 2002-03-12 05:10:42 UTC
Does the panel still have the padding option? If so and if it is
kept, then there need to be a UI decision for whether such added
(and, IMO, worthless) padding should be anything other than like
panel free space. (I.e., should it be like the blank area that in
GNOME 1.4 would allow movement of the panel or a right-click menu.)

If the edge can be padded and the padding should act like the
applet instead of free space, then this should be a trivial matter
of sending events to the appropriate applet.

If there is no padding, then the applet writer should be taking the
necessary steps to extend the event receiving region. For the
panel-menu applet in gnome-applets, this should merely require
adding to gtk_rc_parse_string circa line 185:
  GtkMenuBar::internal_padding = 0
  xthickness = 0
  ythickness = 0

Of course, that wouldn't be necessary if Gtk didn't add so many
dead pixels to the menubar.
Comment 4 msaavedra 2002-04-02 22:36:45 UTC
Could this be fixed by reinstating the "Make buttons flush with panel
edge" option from Gnome1.x ? Note that this is very similar to bug
72796 . Perhaps one of them should be marked as a duplicate?
Comment 5 Mark McLoughlin 2002-04-10 11:33:34 UTC
*** Bug 72796 has been marked as a duplicate of this bug. ***
Comment 6 Luis Villa 2002-04-26 00:50:43 UTC
I'm going to mark this as a high priority enhancement so that when we
do look at enhancements again immediately post-2.0 this will get
looked at hard.
Comment 7 Mark McLoughlin 2002-06-03 23:31:17 UTC
*** Bug 83617 has been marked as a duplicate of this bug. ***
Comment 8 Mark McLoughlin 2002-09-11 01:31:53 UTC
*** Bug 92895 has been marked as a duplicate of this bug. ***
Comment 9 Shane O'Connor 2002-10-09 10:09:01 UTC
I know 72796 is a dup but here are some comments I added

"i'm not seeing this in sun's build11 - cvs oct 1st. i created an edge
panel and added the window list applet - i don't see any padding
between applet and panel edges - will attach a screenshot - can you
tell me if i am correct in my assessment or is the bug something else
(steps to reproduce with expected result at each step would be cool)"

I've added a screenshot to 72796 showing the window list applet on the
edge panel.

Can I get some more specific details on what bug is & how to recreate
- I'm not sure exatly where that is - I've tried activating the
Applications menu and can do this by clicking in very top left corner
of menu panel. 
Comment 10 msaavedra 2002-10-09 10:44:51 UTC
Shane,
Note that this bug does not affect the menu panel. If you look
carefully at the task list from the menu panel, you can see that the
tasklist is flush with the edge of the screen.  On your bottom edge
panel, though, there are 2 extra pixels separating the tasklist from
the screen edge. This can be verified by opening you screen cap in the
Gimp and zooming in on the bottom panel.

Here is another way to test: try to click on a task on the menu panel
when the mouse is moved all the way to the top of the screen. It works
fine. Then try to click on a task on the edge panel when the mouse is
all the way on the bottom of the screen. Nothing happens.

It's good to see someone looking into this, by the way. For a high
priority bug, this has gotten surprisingly little attention.
Comment 11 Mark McLoughlin 2002-10-30 23:37:04 UTC
*** Bug 97259 has been marked as a duplicate of this bug. ***
Comment 12 Mark McLoughlin 2002-11-05 04:00:16 UTC
*** Bug 97419 has been marked as a duplicate of this bug. ***
Comment 13 Mark McLoughlin 2003-01-12 04:39:49 UTC
This really should be done now that the menu panel has been replaced
by an edge panel with a menubar and a window menu.
Comment 14 Seth Nickell 2003-01-12 04:52:37 UTC
Yes please, I really don't want any more regressions in this
particular area. :-)
Comment 15 Mark McLoughlin 2003-01-12 05:19:45 UTC
Sure - I agree - but I'd prefer to have the regression than have the
special cased menu panel still around.
Comment 16 Seth Nickell 2003-01-12 20:28:03 UTC
From a usability standpoint I'd rather have the special-cased panel... :)
Comment 17 Mark McLoughlin 2003-01-12 20:46:25 UTC
I thought a special-cased panel was one of the most confusing things
"from a usability standpoint"  .... ?
Comment 18 Seth Nickell 2003-01-12 21:54:30 UTC
Only if you customize the panels, but that's a comparatively obscure
operation. That is to say, yes the special cased menu panel was
confusing but it was only confusing if you tried to do something that
most of the people who would find it confusing wouldn't try to do.
Eventually we'd like for everyone to be able to customize panel
layout, but for now its even hidden in a right click menu where many
many people won't even see it.

By contrast, having the menus follow Fitt's law affects almost
everyone's efficiency. Its a subtle thing but it makes a pretty big
difference (most people don't notice it, because its not the sort of
thing people notice, but if you watch how fast Mac users access menus
vs. versions of Windows where the start menu is broken this way, the
difference is substantial). Actually, probably even more important is
getting the task list to the very edge in terms of frequency of use.
Comment 19 Seth Nickell 2003-02-15 13:00:15 UTC
I would not want GNOME 2.4 released until this is fixed.
Comment 20 Mark McLoughlin 2003-04-10 04:50:25 UTC
Right, this is perfectly possible to do with gnome-panel HEAD (as
proven by the fact that I got the pager to do this right). Each applet
that doesn't do it just needs a bit of work.

We need bugs opened against individual applets that don't work
properly on HEAD.