>> Comment and vote here: >> https://bugs.kde.org/show_bug.cgi?id=162368 > > Thanks for finding this bug report. My issues have been already mentioned in comment #3 > and James Richard Tyrer is working on it. So I'm curious about the new version of the > clock plasmoid. > Even if someone already mentioned it, comment and mention your support. Thanks. >> >> Your input and research is very much needed there. Thanks! >> >>> � � �And regarding vertical panels you have to multiply this issue by 3, as >>> � � �you can see in the nice screenshots in the second bug report) >>> � � �And sorry, but whenever I see this over dimensioned KDE4 battery plasmoid >>> � � �I have to laugh. It's so big but it's only able to show _5 different states_! >>> � � �That leads actually to this problem that you cannot distinguish between 38% >>> � � �and 62%, because both states are represented by 2 bars. Well, I would be >>> � � �interested in this difference, especially when the battery runs low. >>> � � �I will never understand why some developers love to hide useful information. >>> >>> � � �But to see the differences to KDE3, let's compare the KDE4 battery plasmoid >>> � � �with KLaptop. KLaptop uses only 1/4 of the icon size, but is able to represent >>> � � �_81 different battery states_ (in 5x16 pixels)! The trick is to use not only >>> � � �a vertical progress bar but another the horizontal progress bar in each pixel >>> � � �row. When I saw this for the first time (some years ago) I was fascinated by >>> � � �this brilliant idea and thought: Yeah, that's one of the reasons I'm using >>> � � �KDE! >>> > > I've filed a bug addressing the super-size battery plasmoid without useful information: > https://bugs.kde.org/show_bug.cgi?id=205707 > > You're welcome to post comments or vote for it. > While I agree with your assessment of the situation, you are lucky that the bug was a dupe. Your sarcasm would have been the end of the bug, fixed or not. Please, continue filing bugs but don't use sarcasm. You might want to see this bug regarding the size of the plasmoid as well: https://bugs.kde.org/show_bug.cgi?id=167132 >> Can you check that against other tree views in KDE and either confirm >> that this is inconsistent with the rest of KDE, or that all of KDE >> needs to be improved here. Thanks! > > Hm, I couldn't find another KDE application with a tree so fast. Sorry. > Kmail and Dolphin have tree views. >>> * moving the slider between the tree and the current settings does not work. >>> �But in some cases it would be necessary. >>> >> >> I do not understand, could you be more specific? Thanks. > > Ah, sorry. I meant the splitter between the tree and the current settings, marked > in this screenshot with "Drag here": > http://stefan.endrullis.de/kde/system-settings-drag.png > That is an interesting issue. I have no problem dragging the splitter to widen the treeview. Can you check if the splitter in other apps does not work for you (kmail, dolphin)? > As long as it is not needed I don't want to have a horizontal scrollbar in the > tree. That's why I would try to use the splitter to resize the tree. > I agree, I would even prefer to see lines wrap than a horizontal scrollbar appearing! I filed this: https://bugs.kde.org/show_bug.cgi?id=205780 If you want to attach your second screenshot there, it would be great. >>> But also apparently minor issues like the navigation in trees are important >>> for. Fast keyword work was always one of the key features of KDE3, I think. >>> Sadly in KDE4 the possibility of keyboard navigation was completely ignored. >>> Just try to save a screenhot in ksnapshot by using only the keyboard. You >>> can navigate to a directory and press ENTER. Instead of changing into this >>> directory, ksnapshot thinks you want to enter the dir AND save the file >>> afterwards. Strange implementation! I would never expect both actions at the >>> same time. >> >> Please write a "this is what I did, this is what I expected, this is >> what happened" format, I'll verify and file it. but make sure that you >> are on KDE 4.3 first, as it is a bit different than KDE 4.2. Thanks! > > Open ksnapshot and create a screenshot. Press "Save As", click on "Home", and > click on the background of the directory list. Now you can do a quick keyboard > navigation. Enter the directory name in which you want to change. Then press > ENTER. Normally one would expect that you only change into this directory when > pressing ENTER. But the open dialog does not only change into the directory, > but saves also the file in this dir afterwards. This is unintuitive. If the > cursor / focus is in the directory list ENTER should only be used for the > navigation in the directory tree. Only when I changed to the filename input > field (by pressing TAB) and press ENTER I would expect the file to get saved. > You are 100% right. I am plagiarizing your reproduction instructions here: http://bugs.kde.org/show_bug.cgi?id=205781 Thanks, Stefan. You really have an eye for details, please keep me update with them of file them! But just remember when filing that the devs demand a very factual style, please don't give them a reason to evade the bug with sarcasm. Have a great week! -- Dotan Cohen http://what-is-what.com http://gibberish.co.il
