Version: (using KDE 4.2.4) OS: Linux Installed from: Mandriva RPMs With maximized windows of any program like KWrite, Konqueror or Firefox: when throwing the mouse pointer to the right edge of the display to use the scroll bar, I want to scroll by clicking my mouse. But the scroll bar is not activated as the mouse must first be moved a little to the left. Very annoying! Scrolling a maximized window should work when the mouse pointer is at/over the right edge of the display. Gnome, Windows XP,Vista and Windows 7 don't have this annoying behaviour. I make this a bug report and not a feature request as I find the lacking of this functionality that is so practical a real crime. Hope you can fix this soon. Will that be 4.3 or 4.4? Regards
I wasn't able to reproduce in Firefox. I was able to reproduce in Konqueror. So I think this is either an issue in the used style or an issue in Qt. It's definately not a kwin bug as that is behaviour inside the windows and not in any way controlled by a window manager. As I have no idea where it belongs I reassign to unassigned kde bugs.
- make sure you're not allowing max'd windows to be move/resizable (at least the oxygen (default) deco honors this setting) -> use another deco - Qt allow styles to set the Scrollbar inside (oxygen -the default style- does so) or out of the frame. If it's set inside, there's a margin -> use another style - Other toolkits may behave different (and there's nothing kwin or KDE could do about that) check the two first items and please post an update here (so we can close or redirect the bug in case)
I'm in holiday now, I will be back in two weeks. I did try two styles (oxygen and Mandriva's ia-Ora), both suffer from this annoyance. I'll inform Mandriva to compile their packages to set the Scrollbar out of the frame. When I'm back home I'll test it, try another style and post an update.
i don't know anything about mandriva, but to me (screenshots from) "laOra" looks like a Gtk+ theme. about oxygen: either i hacked it myself or they changed it meanwhile (or kstyle did or QWindowsStyle did - don't know ;-P ) but it works "right" here and now (notice that as mentioned this has /no/ impact on non Qt apps like e.g. Firefox -3.5 has no padding here- or OOo -i don't know- and this is the wrong bugtracker to fix them)
It's not the widget style but the window decoration that's guilty: with window decoration laOra Qt/KDE applications and Firefox 3.0.13 suffer from this scroll bar margin. If I change it to decoration Plastik or Oxygen the problem is gone. OpenOffice.org 3.0.1 on the other hand always has a scroll bar margin regardless of the window decoration setting of KDE. I'll make a bug report at Mandriva bugzilla: https://qa.mandriva.com/
Bug reported at https://qa.mandriva.com/show_bug.cgi?id=52903
FYI and to avoid confusion @mandriva in KDE tech speech the - "Window decoration" refers to what impacts the look of the window titlebar (kcmshell4 kwindecoration) - "Widget style" refers to what impacts the look of the window content (kcmshell4 style) many styles (including oxygen & plastik) ship alongside a matching deco The Toolkit (Qt/Gtk+) is a software framework that (in our case and aside more features) operates and eases out the X11 API The FF toolkit is XUL (which itself uses Gtk+ but styles indirectly) Konqueror and all other KDE apps use Qt OpenOffice uses UNO (on top of Java, Sun product) Things get more complex as there are several wrapping widget styles to unify the look of apps - but not necessarly the feel (gtk-qt makes Gtk+ apps look like Qt ones, Qt ships the Gtk style and OOo has wrappers for both) This is similar to FF styling an indirect use and has glitches on the disjunct aspects of the toolkits. That said: It is /very/ unlikely that the "Window decoration" i.e. the "Titlebar style" has any impact on the scrollbar behaviour, but the "Widget styles" of the "Qt Toolkit" /have/ the explicit task to set this.
i'm terribly sorry, drop that. i recalled (but not re-read) the bug as scrollbar positioning on mmb click. The "Window decoration" can accidently have a frame on max'd windows although the user chose to disallow moving max'd windows. This can be considered a bug in the Window decoration.