Re: [kde] 4.3.3 bugs

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:
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.

I'm still on 4.3.2, but..

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 suggested
completions opens, but when I try to move the mouse to select one, the
list immediately closes.

It works here. No problem

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
a bit.

2. Select Folder dialog doesn't do 'hidden' files.

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.

It works here, and always has done as far as I can remember

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
bar>".

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/text
setting.

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
Toolbar.

That does appear to be a bug.

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.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.

Relevant Pages

  • Re: [kde] 4.3.3 bugs
    ... this one's definitely a bug in the individual setup/installation. ... the root of the tree isn't even shown for it to change to. ... I don't even see a "Search Toolbar". ... that the KDE project is in need of a quality assurance plan. ...
    (KDE)
  • RE: [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1933 - 20 msgs
    ... read from multiple peoples articles that it isn't this kind of bug. ... HTTP Response Splitting and SQL injection in megabbs forum ... I don't do it out in the public lists ...
    (Full-Disclosure)
  • [Full-Disclosure] Re: Full-Disclosure digest, Vol 1 #1933 - 20 msgs
    ... read from multiple peoples articles that it isn't this kind of bug. ... > that about how bad Windows sucks from people who don't know enough about how ... I don't do it out in the public lists like ... >>because you have a bug up your bum about it and work to prove that stance. ...
    (Full-Disclosure)
  • Spam or not? Extracted from Re: php extensions compile error - another compile bug?
    ... Re: php extensions compile error - another compile bug?: ... haf been helpful while his first and only response was to chide me for NOT ... >> resourceful turn to the appropriate mailing lists. ... You are right I should have cc'd that email to the maintainer tofreebsd ports ...
    (freebsd-questions)
  • Re: This Crashes RosAsm
    ... They have posted Lists of Labels. ... I perfectely know how RosAsm works. ... I can't fix a bug that does not exist. ...
    (alt.lang.asm)