Gedit text area has small gap between edge of text area and edge of window

Bug #206837 reported by Alex Willmer
44
This bug affects 4 people
Affects Status Importance Assigned to Milestone
GTK+
Expired
Wishlist
One Hundred Papercuts
Triaged
Low
Unassigned
gtk+2.0 (Ubuntu)
Triaged
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gedit

Ubuntu Hardy beta, gedit 2.22.0-0ubuntu1

There is a 1 pixel gap between the edge of the window and the edge of the text edit area. When maximised and the scroll bar is present one can't reach the scrollbar by hitting the screen edge with the pointer. A similar gap exists on the left, but is not as critical.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your bug report. That's known upstream, http://bugzilla.gnome.org/show_bug.cgi?id=123408

Changed in gedit:
assignee: nobody → desktop-bugs
importance: Undecided → Low
status: New → Triaged
Revision history for this message
Blake (blakecmartin) wrote :

Could you provide a bit more information? I'm unable to reproduce this bug. I've added enough text to display both scrollbars and both of them are visible/accessible to me.

Revision history for this message
Alex Willmer (alex-moreati) wrote :

As the upstream report refers to, Fitts law is the name for the principal violated. The upstream report also refers to the tab container as being a trigger. I can confirm this for Gnome Terminal - without tabs (a single term) the scroll bar is at screen edge when maximised, with 2 tabs the 1 pixel gap appears. Gedit always shows the tab control, even with only one document open. Hence the border is always there.

Attached is a screen shot to illustrate the problem.

Changed in gtk:
status: Unknown → Confirmed
Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Wow... There's no upstream activity since May...

Curiously, Nautilus is affected only when you use tabs.

Revision history for this message
Alex Willmer (alex-moreati) wrote :

The ptoblem is actually with the tab control of GTK, so it shows up in Gedit, Pidgin, Nautilus and several others. Firefox doesn't exhibit it, I believe because they don't contain controls in the tab panels, but merely use the tabs as a signal to switch by other means.

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

There's a patch in the upstream bug which claims to fix the issue. Could somebody take a look into it, please?

https://bugzilla.gnome.org/attachment.cgi?id=110329

Revision history for this message
Sebastien Bacher (seb128) wrote :

karmic is frozen now and it's not the right moment to work on such changes

Revision history for this message
Ricardo Pérez López (ricardo) wrote :

Well, wait until Karmic release, then. Maybe it could be apropiate for lucid or even karmic-updates.

Omer Akram (om26er)
Changed in hundredpapercuts:
importance: Undecided → Low
status: New → Triaged
Revision history for this message
William Manley (willmanley) wrote :

Just a thought. One method to solve the symptom, if not the root cause, would be to have metacity/compiz maximise applications to two pixels beyond the left hand edge of the screen. Alternately, and to similar effect would be to restrict the mouse pointer to not go all the way to the left edge, but get stopped 2 pixels from the edge.

It's a hack but it would ease the annoyance of this bug.

Revision history for this message
William Manley (willmanley) wrote :

In fact I've given it a go and it works OK. I use xrandr --fb to adjust the screen size. I've made this 3 pixels less wide than my actual screen resolution (1021x768) and the mouse pointer will now not go to the left most 3 pixels of my monitor. The missing pixels show up as black but metacity still maximises my applications to the monitor size (1024x768).

I use:
xrandr --fb 1021x768

It's not pretty and will not last beyond a reboot or adding an external monitor, but it doesn't seem to break anything.

Vish (vish)
Changed in hundredpapercuts:
milestone: none → maverick-round-7-notifications+gtk
Changed in gtk:
importance: Unknown → Wishlist
Changed in hundredpapercuts:
assignee: nobody → Papercuts Ninja (papercuts-ninja)
Revision history for this message
positivek (anonyhole) wrote :

I think this is a duplicate (or replicate) of bug 25529. Yet it seems that https://bugzilla.gnome.org/show_bug.cgi?id=123408 is a potential root of the problems.

It seems that various users are reporting the same issue with several Gtk(?) apps.

Revision history for this message
Marcus Haslam (marcus-haslam) wrote : Re: [Bug 206837] Re: Gedit text area has small gap between edge of text area and edge of window

I'm out of the office until 1st August.

On 14 Apr 2011, at 22:01, positivek <email address hidden> wrote:

> I think this is a duplicate (or replicate) of bug 25529.  Yet it seems
> that https://bugzilla.gnome.org/show_bug.cgi?id=123408 is a potential
> root of the problems.
>
> It seems that various users are reporting the same issue with several
> Gtk(?) apps.
>
> --
> You received this bug notification because you are a member of
> Papercutters, which is subscribed to One Hundred Paper Cuts.
> https://bugs.launchpad.net/bugs/206837
>
> Title:
>  Gedit text area has small gap between edge of text area and edge of
>  window
>
> Status in GTK+ GUI Toolkit:
>  Confirmed
> Status in One Hundred Paper Cuts:
>  Triaged
> Status in “gtk+2.0” package in Ubuntu:
>  Triaged
>
> Bug description:
>  Binary package hint: gedit
>
>  Ubuntu Hardy beta, gedit 2.22.0-0ubuntu1
>
>  There is a 1 pixel gap between the edge of the window and the edge of
>  the text edit area. When maximised and the scroll bar is present one
>  can't reach the scrollbar by hitting the screen edge with the
> pointer.
>  A similar gap exists on the left, but is not as critical.

Revision history for this message
positivek (anonyhole) wrote :

Almost there...

On Xfce4.8... and Gedit 3.2.3, I cannot GRAB or DRAG the scrollbar. However, on a mouse button down along the right edge of the screen on a maximized Gedit window, the app will PageUp / PageDown depending on where I click (mouse down).

But the standard, expected full control of the scrollbar (i.e. drag) is not there.

On a long document, try scrolling to the bottom so it cannot page down. Now bring the mouse to the right edge, but somewhere along the drag handle. Expected: Holding down mouse will cause drag handle to change color (e.g. darken) and allow dragging. Actual: Drag handle does not change color, and no dragging is initiated.

(Running Xubuntu 11.10 Oneiric)

Revision history for this message
positivek (anonyhole) wrote :

I should add to comment 13 that MIDDLE mouse click/drag works as expected and consistent with other apps: scrollbar is taken to the mouse position and drags as long as middle mouse button is held down.

Changed in hundredpapercuts:
milestone: maverick-round-7-notifications+gtk → quantal-2-productivity
Changed in hundredpapercuts:
milestone: quantal-2-productivity → raring-gtk
Changed in hundredpapercuts:
milestone: raring-gtk → papercuts-s-gtk
Revision history for this message
positivek (anonyhole) wrote :

Gedit 3.6.2, maximized, at the right edge:
* right mouse button acts as old middle mouse button: It brings the scroll bar slider handle to it instantly and you can scroll up and down by holding down the RMB and moving it. Works fine and mostly as expected.
* middle mouse button does nothing (but it can be used to grab the slider when away from the very edge of screen).
* left mouse button will initiate a pagedown when clicked anywhere below the top edge of the slider handle. It will pageup when clicked above the top edge of the slider handle. Holding it down will initiate multiple page movements in the direction of the first paging, until released.

On the whole, the mouse behavior seems workable again.

Changed in hundredpapercuts:
assignee: Papercuts Ninjas (papercuts-ninja) → nobody
Changed in gtk:
status: Confirmed → Incomplete
Changed in gtk:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.