Re: [kde] 4.3.3 bugs
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Date: Wed, 11 Nov 2009 16:47:08 +0000 (UTC)
Anne Wilson posted on Wed, 11 Nov 2009 11:43:25 +0000 as excerpted:
On Wednesday 11 November 2009 11:08:50 James Tyrer wrote:
James Tyrer wrote:I'm still on 4.3.2, but..
Well, KDE-4.3.3 has escaped and I have a long list of little things
that don't work correctly. I would appreciate the assistance of
users on this list to try to see that they are actually bugs in KDE,
see that they are reported, and possibly fix some of them.
Well, lets see. I went though my notes again and found that some
issues had been resolved.
1. Auto completion doesn't work in Konqueror (and other places).Not sure what you mean here, but in Konqueror if I start a url I'm
offered a list of sites already visited.
This is very frustrating since as you type, the list of suggestedIt works here. No problem
completions opens, but when I try to move the mouse to select one, the
list immediately closes.
I'm on 4.3.3 and have been for a few days anyyway, now...
As with Anne, this definitely works for me. I hadn't noticed anything
strange but just tried it to be sure, and it does work. So this one's
definitely a bug in the individual setup/installation. That should help
2. Select Folder dialog doesn't do 'hidden' files.It works here, and always has done as far as I can remember
Best place to test this is in System Settings: General -> About Me::
Paths. Try to set the Autostart Path. So, you start at Home. The
".kde4" directory isn't listed, so enter "/." and you get a list, but I
can't use the mouse to select from them but see #1. IAC, you wind up
having to type the whole path.
My setup is such that I can't confirm this one either way, here. I can
confirm that I don't see .* aka "hidden" files, but as I don't normally
like "hidden" configs, the .kde, .kde4, and (unhidden) kde homedir
entires all three ultimately symlink to the same (unhidden) kde4 dir.
I've likely also changed the default for that entry, I'm not sure, but
it's presently pointed at the unhidden ~/kde/* path variant.
So as I said, while I can confirm that it doesn't show hidden in the
list, and I believe that's by design, due to my non-default setup, I'm
long since past the point at which I might have ever been able to confirm
the behavior when the path is at the default, containing the hidden dir.
3. Select Folder dialog won't go to the "Root" place.It works here
Using the same test case as #2, click the "Root" entry in the place
list. Nothing happens.
It lists all directories under /
Look at the treeview window; "Root" is missing from the top.Don't know what you mean by that
I think you missed his point, which took me a moment to grasp as well.
If you click on any of the other entries in "Places", the directory
selected in the treeview changes to point at that location. If you click
on the "Root" entry, it doesn't, nor could it do so, because the root of
the tree isn't even shown for it to change to.
IOW, /usr and /home (among others) are shown, but / itself doesn't appear
in the tree, even tho it's an icon in places. Clicking on any other of
the icons changes the selected subdir in the tree to that location, but
since the / entry itself doesn't show in the tree, the behavior when
clicking on the "root" place breaks the rule, because there's no "root"
place in the tree for it to go to.
That's definitely a UI inconsistency. It looks to me like it's a bug due
to two different people implementing two different bits, with different
assumptions about the behavior of the filesystem tree widget. The one
who implemented the tree display itself decided there was no reason to
show the / entry itself, only its contents, while the one implementing
the behavior when a "Places" icon is clicked assumed that every "Place"
corresponded to an entry in the filesystem tree -- it does, only the top
"/" entry is missing due to implementation.
4. Some Konqueror KPart toolbars have the wrong names.No idea what that means
Not exactly sure if this is a bug but no denigration allowed:
"Search Toolbar <search bar>" should be named "Main Toolbar <search
Hmmm... I don't even see a "Search Toolbar". It could be that I don't
have that component installed. Which is fine with me, as that's the way
I prefer it. I don't need a search bar, as krunner (using the web
shortcuts extension) or konqueror's location bar works just fine for
that. Or I just go to the site (google, wikipedia, lwn, bing if you're
so inclined, whatever) and google from there. (Yes, I /did/ just use the
term "google" in it's generic sense!)
So "n/a" on that one.
"mainToolBar <khtml_kget>" has +/- the correct name but it appears that
the name from the code slipped through. It should really be names
"Main Toolbar <khtml_kget>".
I don't have kget installed (I did but decided I didn't need it so
unmerged it), so "n/a" on that one too.
I don't understand the purpose of these comments. Are you arguing with
developers' decisions? Or are you saying that these names cause
problems for you?
It's a simple UI consistency issue. Following the pattern evident in
naming the others, "Main Toolbar <khtml_kget>", or better yet, kill the
"khtml", simply "Main Toolbar <kget>", would be expected. The
"CamelCase" "mainToolBar <khtml_kget>" would appear to be the name as
exposed in the API (for the application programmer, not the general
user), but wouldn't be considered particularly "user friendly", and thus
normally wouldn't be exposed in the UI to the general user in that form.
So it's just that, a simple UI consistency issue. Not a big
functionality issue, but just one little element that wouldn't be exposed
to the user in that form, in a nicely polished "non-beta/non-rc" general
release product. That it's still there in this form is thus just one
indication of many that kde4 remains an "rc-quality" (at best) product,
at this point.
That we're getting to the point where we're focusing on this degree of
polish as the bigger issues are to a large degree solved, DOES indicate
that kde4 is very close to "there", but never-the-less it remains a bit
of roughness that really should be attended to.
5. Konqueror Extra ToolBar still doesn't use the global icon/textThat does appear to be a bug.
This only happens if you use icons only for your toolbars and have
selected it in System Settings: General -> Appearance::Style::Fine
Tuning. Text position of toolbar elements = Icons Only.
When you first enable the Extra Toolbar in Konqueror, it will not
follow this setting like the other toolbars do. It will also show
text. For me, this problem keeps popping up when I configure the Extra
Hmm... I cannot confirm this one. However, I believe that's due to a
bigger bug I've had for awhile, here. Several kde apps, konqueror and
kmail among them, don't properly take toolbar configuration changes. I
can make the changes and hit apply, or OK, and I know the change gets
registered in the config because when I open up the toolbar config dialog
again, it remembers the changes I made, but that's not what shows on the
toolbar. The toolbar continues to display the default icon set,
regardless of what I configure it for.
So my konqueror extra toolbar does seem to be using my global icons-only
setting, but due to the bug I described above, I can't change the icons
that actually appear.
I suspect that might be a Gentoo bug, however. Either that or it could
be a bug related to my specific config, maybe due to the fact that my
$KDETMPDIR isn't on the same partition as /home (my tmpdirs are on a
tmpfs, this would matter if for instance the config file is placed in the
tmpdir, with a rename operation done to rename it over-top of the
previous config). I've yet to find the time to try to trace it down. I
just know it has never worked as it should.
Dale, I know you're on Gentoo. If you read this can you confirm whether
you can change the icons on your konqueror toolbars or not?
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
This message is from the kde mailing list.
Account management: https://mail.kde.org/mailman/listinfo/kde.
More info: http://www.kde.org/faq.html.
- Re: [kde] 4.3.3 bugs
- From: James Tyrer
- Re: [kde] 4.3.3 bugs
- Prev by Date: Re: [kde-linux] KDE 4. Trying to get it working like I need it to.
- Next by Date: Re: [kde-linux] KDE 4. Trying to get it working like I need it to.
- Previous by thread: Re: [kde] 4.3.3 bugs
- Next by thread: Re: [kde] 4.3.3 bugs