4.3.3 bugs

[James Tyrer]

Duncan wrote:
> 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.
> 
Well, I first note that this is only an issue when using KDE-4.  It
worked with KDE-3 and it works in Firefox.  And, it works when using the
history list with the location in Konqueror.  So, there probably is a
KDE-4 problem with X11 and the issue could be in X11.  X11 has been in a 
state of flux.  Now that 7.5 has been released, perhaps things will be 
resolved.  Are you using xorg-server-1.7.1 yet?

Specifically, it could be a problem with: "xf86-input-mouse".  But I 
upgraded to 1.5.0 and it didn't help.

>>> 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
> 
Wonder exactly what she is saying works.  Or, is this her usual attitude
that there are no problems?

> 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.
> 
Well, could you temporarily put ~/.kde4 and ~/.kde4/Autostart
directories on your system so that you can try it?

> So as I said, while I can confirm that it doesn't show hidden in the 
> list,

I presume that you mean the treeview window.  But AW says that it
works.  How can that be? :-P

> and I believe that's by design,

Yes, but it would appear that that is a design error since, as my
example shows, you do need to be able to use 'hidden' (.*) files in the
treeview window.  The best solution would be to have it possible to turn 
them on and off like in the KFiles dialog.

> 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
>> 
Again I wonder what "works here".  The compulsive 'it works' answer is
not even in the same context as the question.

>>> Using the same test case as #2, click the "Root" entry in the 
>>> Places list.  Nothing happens.

>> It lists all directories under /
>> 
*IT* listed all the directories under "/" before I clicked the "Root"
entry in the Places list.

>>> Look at the treeview window; "Root" is missing from the top.
>>> 
>> Don't know what you mean by that
> 
I mean that there is no "folder-red" icon at the top of the tree.

> 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.
> 
You have to wonder though if the developers ever used it.  It appears to
me that it should not be necessary to report things such as this as bugs
-- that very basic quality assurance (TQM) would find such flaws (which
are actually design errors) before the product is kicked out the door.

>>> 4.	Some Konqueror KPart toolbars have the wrong names.
>>> 
>> No idea what that means
>> 
It means that the the names do not conform to the scheme for naming them.

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

I think is in "konq-plugins".

> 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!)
> 
Somewhat useful if you can't remember the abbreviations for the
different searches.

> 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?

I suppose that AW, in her strange super PC world, might think that a 
developer made a decision not to follow the established scheme for 
naming the toolbars and that that was simply a decision rather than an 
error.  Or, is it possible that the developer in question didn't 
understand the scheme?

Note for the record that an example of arguing with a developers 
decision would be to say that I don't think that "Start new session" 
should have been removed from the DeskTop context menu.  That is a 
decision, not an error.  Failing to follow the established scheme is an 
error!

>> Or are you saying that these names cause problems for you?
> 
To be clear, I am saying that who ever did this, got it WRONG!

> 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.
> 
Some of these issues should have been caught before anything was ever 
released (or even committed to the repository).  It is becoming obvious 
that the KDE project is in need of a quality assurance plan.  The fact 
that there is a list: "kde-quality" which had a different purpose and 
now has almost no traffic speaks volumes.  Basic TQM should catch such 
rough edges.

>>> 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 have not had any other issues lately except for the Konqueror HTML 
Toolbar.

It is possible that this issue has finally been fixed.  It is hard to 
confirm.

<SNIP>

It would appear that if AW's attitude is typical of developers when it 
come to bugs that it should be no surprise that KDE has a quality 
control problem.  Personally, I can't see how quality control could be 
as bad as it is, and then I read one of her posts and it becomes easy to 
see what the problem is:  KDE is not Ford (at Ford, "quality is job 
one") but the antithesis of Ford.

I thank you and Dotan, and now Dale, for your efforts to improve KDE 
quality.  But, I don't think that we are going to establish much on this 
list and it appears that filing bugs doesn't seem to do a lot of good 
either -- you often meet with the AW attitude that the bug doesn't 
exist, is a feature request, or you have to keep reopening it when it is 
incorrectly closed (before it is fixed).  Might I suggest that you join 
the: "kde-quality" list and try to start a quality control team.  You 
don't really need to be programmers to do that.  I couldn't write a 
whole KDE app, but I know a lot about programming and software engineering.

-- 
James Tyrer

Linux (mostly) From Scratch
___________________________________________________
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.