C-6, Gnome Question

Home » CentOS » C-6, Gnome Question
CentOS 18 Comments

Hi all!

Using the default Gnome desktop on CentOS-6, I keep having difficulty getting the mouse pointer to lineup exactly on the edge/corner of a window when I want to resize the window. It seems that you have to have it on a line exactly one pixel in width, and I’m finding it increasingly hard to do (who, me? getting old? nah!)

Wondering if there is a gnome setting somewhere among the myriad settings that could be used to configure the accuracy with which the mouse pointer must be placed so one can grab edges of things. I’ve dug thru the settings in the Gnome configuration editor, but so far nothing leaps out at me.

Can anyone offer advice?


18 thoughts on - C-6, Gnome Question

  • I’m also getting old, but I don’t have the problem on C-6 at all.

    Have you gone into System->Preferences->Mouse and changed some of the doohickeys there? I don’t recall anything related to your problem, but it may be related to Acceleration or Sensitivity? I’ve set my Sensitivity to about 1/3rd off of low and acceleration to mid-range. There’s an alternative if, like me, you prefer KB anyway – . It’s drawback is it’s not as fine-grained though. But for me it’s really faster anyway.

    HTH, Bill

  • Bill:

    Thanks for the reply.

    I’ve got acceleration all the way to the slow end, sensitivity all the way to the low end, drag and drop threshold all the way to the small end, and I’ve tried them all at other settings, too, to no avail.

    trying to grab the edge of a window feels like the grabbable region is only one pixel (or maybe one “mickey”) wide and it’s still hard nto place the pointer right on it. I may be getting old, but I don’t have any palsy/tremor problems.

  • Well, that’s the limit of my offerings. I’m still trying to find the thing I used back in C5(?) that raised the panels when the mouse hovered over it for X seconds. With C6 I can’t find it anymore and it switches way too fast.

    I recall some folks mentioning something like “gnome-config” or similar and I figure that’ll be my next attempt. I looked to see if there was anything in the drop-downs from “System” to see if anything else jumped out. I didn’t see anything about border widths. There’s a “Desktop Effects” that I don’t know if that has any effect on your problem:
    System->Preferences->Desktop Effects. Has some text in it about 3D
    hardware acelleration.

    You know wht? I’m thinking it’s something to do with the mouse driver. Usb mouse? ISTR some “jerkiness” in that human interface stuff in the past.

    One other (likely?) difference that may be making my unit better behaved. I have gpm installed so that I can C&P on text-based standard terminals (console tty). I’ve noticed that when X or Gnome starts up it seems aware.

    You might want to try installing gpm, have it start up on boot and see if that helps. Not a true solution, but may be a work around until the true solution is found.

    HTH, Bill

  • I presume you’re talking about panels with “Autohide” set. If you have the GUI gconf-editor installed, it’s under apps/panel/global/panel_show_delay. You can also set it from the command line:

    gconftool-2 –type int –set /apps/panel/global/panel_show_delay 500

    (The default is 300, unit is milliseconds).

  • I think Fred is talking about modifying a theme in the sense of customising it.

    To Fred: I’m not aware of a toolkit for the purpose. People just hack the gtkrc or xml files which comprise a theme. There are lots of examples under /usr/share/themes/.

  • ah, thanks!

    I found the way, as described above, to choose a different border style, which solves my immediate problem, But I’ll go take a look at your suggestion, too.


  • I forgot to mention the “begin resize” keyboard shortcut, which is Alt-F8 by default. If you press that key combination, and then move the mouse towards a window edge or corner, the window will be resized in the corresponding direction. No need to find the narrow window border with your mouse.

  • LoL! I just found it while trying to find out where another distasteful C6.6 update effect was started.

    In a nutshell, after I would terminate Firefox as part of my normal log off process, there would be another instance of Firefox left hanging around with a ppid of 1 (so it’s daemonized”, or as I prefer
    “demonized” ;-)) and using all the CPU it could get (97%-99% of a 6 core AMD in my desktop) while no Firefox windows were open. Figuring it might be saving stuff I checked back many minutes later on many days and cycles and it was always there. Moreover, when normally using Firefox I’d seen 103%, 104% CPU usage etc.

    I commented out the entries that start it in Xclients and made a patch. If I see no ill effects I’ll leave it in place, otherwise back to digging as to why it’s there.

    I’ll tell ya, those folks keep going the way they are and every Windows box on the planet will be able to run circles around many of these Linux distros.


  • Thanks! My terminalogy was likely not correct. I was refering to the …
    “windows” for applications, which I’ve been calling “panels” (because they are within my virtual windows).

    The … task bar(?) works just fine with autohide. As Fred correctly divined, it was in one of the drop-downs under preferences. But I’ll bet you know the CL for that too. Since I’m an old CLI guy that prefers that method, I’ll be hunting starting from your hint.

    Thanks for taking the time! It helps a lot.


  • I commonly also find a “stray” firefox running after stopping firefox, and it isn’t using a window either. it’s a nuisance because, when there’s a firefox update and it wants to restart the browser, it can’t because there’s that darn “stray” one hanging around.

    like you, I have no idea where it comes from or why it’s there, nor what it’s doing, either.

    please let me know how it goes, I may want to investigate doing the same.



  • Oh. I’ve always kept auto-raise turned off. I frequently have multiple overlapping windows open, and sometimes raising the one I’m typing into would hide something I need to see. (Yes, the part I’m typing into is visible.)

    In Gnome they’re called “panels.” Right-click in one and you’ll see, “Add to Panel,” “Delete This Panel,” etc. No, I don’t know the CLI path for the window auto-raise delay. Heck, I only found the one I posted by searching for it in the gconf-editor GUI. I don’t use that stuff anywhere near often enough to remember it, just that it’s in there, somewhere.

  • I’ve traditionally done that, too. but 2 or 3 years ago I decided to try it, with a 1 second delay, and found I (mostly) like it. Odd.

  • I sent a post with a patch, but forget to mention good results and mentioned on the abort.

    Using top, Firefox CPU utilization has dropped back into normal ranges with my activity, number of open tabs, number of java stuff started, …

    Seems to hover in the 7% – 30% range and I’m having fewer “interminable delays” when refreshing, switching work spaces, etc.


  • BTW, for Fred et al, plugin-containers is another hog. Don’t know the cause and haven’t found a good sustainable solution. Turning off plugins seems to help, reducing open windows in FF or tabs, … But nothing seems permanent. there.

    ATM top has 109.8% CPU and I’m not doing anything out of the ordinary, which often doesn’t have this level of CPU usage but also often has this level.

    Label me stumped. Bill