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