Summary: | More clever usage of window borders - scrollbars - fitt's law | ||
---|---|---|---|
Product: | [Unmaintained] kmail | Reporter: | Maurizio Colucci <maurizio.colucci> |
Component: | general | Assignee: | kdepim bugs <kdepim-bugs> |
Status: | RESOLVED DUPLICATE | ||
Severity: | wishlist | CC: | gablistas, oded |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Maurizio Colucci
2005-03-07 13:09:55 UTC
IIRC kwin supports showing a window without border. >
> ------- Additional Comments From christian.loose hamburg de 2005-03-07 15:03 -------
> IIRC kwin supports showing a window without border.
>
to Christian: you misread. The bug is not about kwin. It is about kmail not
having the scrollbar along the window edge.
I don't think that every application should define their own windows behavior. We have kdelibs to define a consistent, KDE-wide behavior. We also have a style guide (HIG or whatever). You can add a wish to genereally support that feature in KDE. It would be usefull for maximized windows only, anyway. I don't think that there is a problem with KDE in general - several KDE applications I tried exhibit the required behavior: for example, open kwrite with a large enough file, maximize it and try to access the scrollbar - you can see that its flat against the right side of the window w/o any space and just throwing the mouse to the right allows you to catch the scroll bar, which is a "Good Thing(tm)". Interface Design 101. KMail OTOH have an annoying space between the scrollbars and the right most side of the window (and left most in RTL mode I guess). I think its because of the more complicated widget set used, but this should be fixed - whether its in KDE-libs or in KMail I cannot say. Andreas Gungl wrote: > I don't think that every application should define their own windows > behavior. We have kdelibs to define a consistent, KDE-wide behavior. This is not something that can be enforced via code (in kdelibs or qt). You can't prevent the programmer from putting the scrollbar where he likes. In qt you have total freedom about the widget hierarchy. So this must be decided separately for each application, ponderating the pros and cons. > We also have a style guide (HIG or whatever). That's true, this should be added to the HIG. Does someone know how to pos a wish for the HIG? In response to request #4: I can't reproduce with KWrite (KDE 3.4.1, only default settings, Keramik theme etc.). Putting the mouse to the right side of the screen gives the resize cursor on a blue line, same as in KMail. There is no visual difference for me. I think the solution to the problem is two fold first, KDE (kwin) should not show the window borders for windows that are maximized. This is already done if you uncheck "allow maximized windows to be moved and resized" in the "moving windows" KCM module (can't figure out how to get to it using kcmshell, but you can right click the title bar of any window and choose "configure windows behavior" to get to it). Once that done, kwrite behaves as in comment #4, which I believe is how things should be done (at least Apple engineers think so, and they are usually right in these things). The second issue is that most applications featuring scroll bars - kmail notably, but weirdly enough also kate(*) should have the scroll bars flushed against the side of the window where possible, so that when "allow maximized windows to be moved and resized" is unchecked - for this specific reason - then it should work. This is an application specific issue, and as proven by kwrite is not a kwin or kdelibs issue. (I've opened bug #117718 about the same problem with kate). (*)which is weird because kwrite is a kate wrapper and have *less* chrome around the editor. To me it's incredible that this problem is present in almost all of the main KDE apps (and other applications not written for KDE, but mainstream anyway). I've counted only 6 applications following the desired behaviour in a total of 39; only 15% of all. I think that there must be some kind of "default UI layout" provided by the development tools used by most developers (QtDesigner, KDevelop, don't know) that is leading to this results. Perhaps that's where attention should be paid for a long term solution. Besides that, talking with developers to make them concious of the problem could be an effective short term solution to the problem also. This is the list I've compiled with applications that to my knowledge conform (or not) with the Fitt's law (ideally this list could be expanded by others to include more programs that are known to have the problem): KDE APPLICATIONS CONFORMING: - KGeography - KHexEdit - Krita (perhaps all other KOffice applications too, I don't have them installed) - KWrite NOT CONFORMING: - amaroK - Ark - Kaffeine - KAlarm - KArchiver - KArm - Kat - Kate - KDE Help Center - Kdenlive - kdissert - KGhostView (this one does something really strange) - KIso - Klamav (seems designed that way) - KMyMoney (seems designed that way) - Konqueror - Konsole - Kontact - Krecipes - Kreettingkard - Krusader - KTorrent - Kuickshow - Kxmame - KXStitch - Quanta Plus - Rosegarden - TaskJuggler IDE (pre 2.2.0) - Tellico NOT KDE APPLICATIONS CONFORMING: - Firefox - GnuCash NOT CONFORMING: - Gimp - OpenOffice.org 1.x (I don't know about OOo 2.0). - Planner - Scribus Thanks for listening! |