4.3.3 bugs

[Duncan]

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.