KDE 4.10.0 - Unable to minimize anything, Dual Screen Problems

[dmeyer]

Changing KDE 4.x to 4.x+1 is always a hassle. At least this time KDE didn't wreck nepomuk, my search database, akonadi or one of the many other configurations I have set up. Honestly KDE 4.10 is the least painless upgrade I have ever had.

[dmeyer]

Bonus points: The minimize animations are busted again. I'm sure it will be fixed by 4.10.1 like it is every generation of kde releases.

[Arran]

Just one more question: I realised, the menu bar has been transformed into a small black ruler right on top of the screen, outside the actual app. I did not find, how to get back the customary Menue Bar just on top of the app. This is very bizarre for large monitors, when you have more than one app running in various windows. I am sure, there is a way to bring the menu back where it should be (for me). This position may be right for small screen, but my 1600 vertical x 1200 horizonal has enough space to accommodate these 4 millimeter for a convenient menue bar.

[GreyGeek]

UPDATE: When I booted up this morning my wallpaper had reverted to the install default and my two desktop plasmoids, YaWP and Units, were gone. I reinstalled them. Other than that, all appears to be working well. The Plasma Network Manager is a pleasant surprise, it is working faultlessly.

Did I mention that 4.10 is FAST?

[bamyasi]

Pardon my ignorance but what is "menu bar"?

[oshunluvr]

Only problem I've noticed is the default LightDM background doesn't fit on my dual-monitors properly. Not much of a complaint....

[benny_fletch]

Pardon my ignorance but what is "menu bar"?

Not sure of other people's definitions, but a menu bar is what is seen in these screenshots:
http://support.apple.com/kb/HT2473

The menu bar is something apple made popular, the application's menu bar was always on the top of the screen regardless if the application was maximized or not. This is something you can enabled in KDE.

[oshunluvr]

In KDE they're called "Panels" and you can have as many as you want configured how you want - unlike Apple.

[benny_fletch]

In KDE they're called "Panels" and you can have as many as you want configured how you want - unlike Apple.

In my opinion panels are a different animal. I was referring to the option in KDE 3.x that would allow you to use a mac like menu bar. I haven't looked into it since, I do not require that feature.

[SteveRiley]

So since we're kinda rambling about menu bars...

Divorcing the menu from its window and repositioning the menu at the top of the screen has always struck me as weird. It doesn't actually save vertical space, since the number of rows of pixels occupied by the menu are still, well, occupied by the menu -- just in a different spot. A top-of-screen menu bar increases the amount of distance you have to scoot your mouse. And what hapens when a small window lies in front of a large window, and you move your mouse up to the menu bar? Will simply passing over the larger window cause the menu bar to switch to that window's context, which would be enormously aggravating? Or does the menu bar change only after a window is clicked?

[SteveRiley]

Oh, and for how many people does Ctrl+Alt+L fail to lock the desktop? On my Quantal box, upgraded to 4.10, this key combination no longer functions. But it does on my Raring box. And speaking of unlock, on the Raring box, the first keystroke on a locked screen is no longer passed to the password dialog box. It's as if the keystroke is interpreted only to mean "wake up." So I've begun typing the first character of my password two times. That's gonna mess me up in the head, I just know it.

[Arran]

Well, Steve Riley described my feelings best. The KDE-forum has given the right answer. please see the attachment. And I am glad to have found the correct term for this feature.

[james147]

So since we're kinda rambling about menu bars...

Divorcing the menu from its window and repositioning the menu at the top of the screen has always struck me as weird. It doesn't actually save vertical space, since the number of rows of pixels occupied by the menu are still, well, occupied by the menu -- just in a different spot. A top-of-screen menu bar increases the amount of distance you have to scoot your mouse. And what hapens when a small window lies in front of a large window, and you move your mouse up to the menu bar? Will simply passing over the larger window cause the menu bar to switch to that window's context, which would be enormously aggravating? Or does the menu bar change only after a window is clicked?

It displays the menu for the currently active window (the one with focus) so completely breaks down as you described when you use focus follows mouse. And I agree, I have never seen it as a useful feature, except on my netbook (or small screens) where I can integrate the menubar with the panel and since all windows are maximized anyway it is basically only moving it a small distance from where it was originally.

[ScottyK]

I had the same issue as ScottyK when upgrading to 4.10 on my laptop (12.04). The culprit was kmahjongg-data, but after using apt-get -f install command to install it everything ironed itself out. I'm going to hold off upgrading my desktop until I test the new KDE to see if it is worth the trouble.

I quick question regarding 4.10, does this mean that Precise will be getting dot updates as well?

An update just came across that included kmahjongg-data. I wonder if the broken dependency is now fixed?

Also, how long do you think it will be until 4.10.0 is available in the standard (non-backport) repos?

[bamyasi]

Well, Steve Riley described my feelings best. The KDE-forum has given the right answer. please see the attachment. And I am glad to have found the correct term for this feature.

Oh, now I see. Obviously, since I've never used this feature I can't tell how bad (or good) it works in KDE 4.10. In fact, just like others mentioned, this is my top hated element of Mac OS X's interface, so I definitely would not miss it even if its support is broken in 4.10.