Wednesday, June 15, 2011

Do Gremlins Find Mint Tasty?

In my two most recent posts I mentioned upgrading Linux Mint (to "Katya", version 11) and then tweaking it. The upgrade created one or two adventures, notably a loss of the ability to reorder the application buttons in the GNOME panel by dragging them. Editing GNOME panel properties such as its size, or whether it automatically expands, would restore the drag option, but no fix that I found survived the end of a session.

That changed on my office PC, for reasons unknown to me, after a routine application of updates.  I'm not sure which update did what, but suddenly the ability to drag buttons is back. The fix came at a bit of a cost, though.  The first time I logged in at the console after the upgrade (which I did remotely), I found that buttons dragged (good news) and windows minimized and maximized (not news), but that I could neither resize nor move windows (bad news!).  Neither could I switch to any of the other workspaces I have set up. (Workspace Switcher is set for four workspaces.)

A little desperate Googling failed to find any report of the same problem but did lead me, indirectly, to the fix.  In Control Center > CompizConfig Settings Manager > Window Management, Move Window and Resize Window had somehow become deselected and needed to be turned back on.  Similarly, under Desktop the Desktop Wall control had to be turned on.  I have no idea what turned them off -- moving, resizing and switching workspaces all worked the last time I was in the office -- but I assume it was something in the update.  At least the fix was easy.

Meanwhile, I got a new machine at home and configured it to dual-boot Windows 7 (which came preinstalled) and Mint 11.  This time I used the 64-bit version of Mint (my laptop and office PC run the 32-bit version).  Whether due to my choice of the 64-bit version or because it was a clean install (not inheriting any settings from an earlier installation), button dragging worked from the outset on the home machine (once I made a change I will discuss momentarily), and so far there have been no sudden behavioral changes regarding windows.

That one change I made is  rather important, though.  When first installed, the 64-bit version did not create buttons for windows.  If you minimized a window, it simply disappeared (though the app was still running), with no obvious way to recover it.  Dragging buttons was not an issue, since there were no buttons.  I can't picture working in an environment where minimized windows can be reopened.  With a little digging, I discovered that the Window List (the container for the buttons) was not installed on the GNOME panel.  It was easy to install it (right-click the panel, select "Add to Panel..." and then choose it from the menu).  Positioning it was a bit trickier.  You position it the same way you position any applet on the panel: right-click, choose "Move", slide it where you want it and then right-click again and choose "Lock to Panel".  The problem is that the Window List itself is invisible, with neither drawn boundaries nor a distinct background color; so you have to grope for it (right-click where you think it might be and see what context menu you get).  At least that's fixed now (unless another update brings a new gremlin with it).

3 comments:

  1. Another small bit of dopiness: On the two 32-bit machines (PC and laptop), Mint Menu does not display icons. They're present if you go to edit the menu, but when you click the Menu button to access the menu, no icons (or, more precisely, little tiny squares where icons should be). The 64-bit machine displays menu icons as expected. I figured out the problem today, with help from a web post. If you right click the menu button, select Preferences, and then look at the Applications, Favorites, Places and System tabs, you find on the 32-bit machines that the icon sizes are set to 3 pixels in one case and 2 pixels in the other cases. Boosting those settings to double-digit numbers cures the problem. I found appropriate settings at the bottom of http://forums.linuxmint.com/viewtopic.php?f=141&t=62092.

    ReplyDelete
  2. The weirdness continues: I just now booted my home PC (Katya 64-bit) and the window decorations (minimize/maximize/close) were gone. Thinking this was a bug introduced by the latest updates (done this morning), I checked the Compiz configuration settings in Control Center ... and Window Decorations were turned on. So Compiz was just ignoring them? Anyway, turning of decorations, closing Control Center, then going back and turning them on again fixed the problem.

    No show-stoppers so far, but Mint 11 is proving a whole lot buggier than any previous version of Mint that I used.

    ReplyDelete
  3. I think I might (stress "might") have an answer to the Window Decorations problem. The default key bindings for Compiz include binding alt+space to "Window Menu". Alt+space is an easy accidental hit for fumble-fingered me, and it appears that, at least in some programs, if I type alt-space it causes decorations to turn off (globally), without changing the window decoration setting in the Compiz manager. (Some programs grab alt+space before it gets to Compiz.)

    So I went into the CompizConfig Settings Manager, clicked General Options, picked the Key bindings tab, disabled the keyboard binding for Window Menu, and alt+space no longer hammers the window decorations. Only time will tell if that was in truth the source of the random misadventures with decorations.

    ReplyDelete

Due to intermittent spamming, comments are being moderated. If this is your first time commenting on the blog, please read the Ground Rules for Comments. In particular, if you want to ask an operations research-related question not relevant to this post, consider asking it on Operations Research Stack Exchange.