4.3.3 bugs

[Duncan]

James Tyrer posted on Wed, 11 Nov 2009 19:02:46 -0700 as excerpted:

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

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

>> As with Anne, this definitely works for me.

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

I'm on xorg-server-1.7.1, yes.  But you could have something with the 
input driver.  I've been using the xf86-input-evdev driver (2.3.0 
currently) for some months now.  It's nice to be able to use the same 
driver for both mouse and keyboard, for one thing.  The switchover to hal-
autodetect was a bit rough, especially for keyboard as I had to figure 
out how to tell hal to use the correct "inet/media" keyboard instead of 
the default 101-key and that's not the friendliest thing in the world to 
try to configure, but before that, I had it set in xorg.conf, with
Option "AllowEmptyInput" "no" set in the serverflags section as well, so 
it wouldn't ignore the xorg.conf settings.  That worked fine.

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

Based on kishore's post, I checked the context menu in the tree view, and 
sure enough, there was a view hidden dirs checkbox.  After checking it, I 
saw the .kde and .kde4 symlinks along with others.  So that seems to work 
as intended.

The bug would then lie in the the discoverability of said option.  Unless 
one happens to secondary-button click in the treeview, there's no 
indication that a hidden-files option exists.  That could befuddle the 
newbie, and even for folks as experienced as both you and I are, it is 
non-obvious enough we had to have it pointed out.  There should be an 
options icon or something, somewhere, probably beside the new-folder 
button, for toggling hidden-files-view.

As with some of the others, not a big issue, but certainly a UI finish 
and polish issue.  I'd certainly suggest checking to see if a bug is 
filed on this, and filing one if necessary, as it's the type of bug 
Ubuntu's 1000 papercuts project (for example) would tackle, not that 
significant in itself and should be quite easy to fix, but would be very 
nice to have a visually discoverable hidden-files-view-button by 4.4.  
(Maybe it's already fixed in the 4.4 branch and they just can't add it to 
4.3?)

>>>> 3.	Select Folder dialog won't go to the "Root" place.

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

Oh, they use it.  It's just that we're seeing the "live" development 
process in progress, before a normal product (freedomware or not) would 
under normal conditions be claimed to be ready for ordinary people.

Now I 100% support the oft-repeated freedomware mantra, release early, 
release often, and kde CANNOT be faulted for that!  (In fact, they've 
done an exceedingly good job in that regard!)  What they /can/ be faulted 
for, and what I /do/ fault them for, is claiming the current state is 
release quality, appropriate for the ordinary user to install and use in 
the course of ordinary daily business mission-critical work.  It's 
getting close, but as you say and as I've repeated as well, this sort of 
bug shouldn't be present (at least not in quantity) in something deemed 
to be release quality, as kde4 has been claimed to be since 4.2, way 
before it even improved to /this/ state.

> Some of these issues should have been caught before anything was ever
> released (or even committed to the repository).

I'll disagree with that.  The repo commit is simply the result of an 
international team of people with widely differing native languages and 
cultures and thus reasonably differing interpretations of API 
documentation and etc, working on the same project, committing "'round 
the clock" as the saying goes.  Keep in mind it's a volunteer team, and 
paid developer policies such as buddy review of every bit of code before 
commit simply don't work in the freedomware world.  It'd slow development 
to a stand-still, and wring sufficient joy out of the process that people 
would quickly find other tasks taking the time they had been volunteering 
on kde (or almost any other freedomware project you happen to be looking 
at).

The attitude, and I believe it's correct, is either don't break the tree 
or where it needs breaking, do so with a commitment to help fixing it 
back to working condition.  But for individual devs particularly on non-
core projects such as kget and konqueror add-ons, there's a reasonably 
liberal view on what can be committed, with the attitude favoring getting 
the code in there and working, where others can work on it later if 
necessary.  And I believe that's the CORRECT attitude, commit-wise!

Now once the code is committed and the basic functionality working, it's 
time to polish things.  That's where we're at in this regard, here.  
Thus, we get to "release".  As above, I'm 100% behind the freedomware 
mantra "release early, release often", and kde CANNOT be rightly faulted 
in that regard.

Where they /can/ be faulted, however (and again), is in claiming this 
stuff's ready for normal use.  At least it's reasonably functional, now, 
and we're dealing with finish and polish issues.  That's basic rc 
quality, tho as of the 4.3 series I'd call kde4 as a whole rc quality 
just yet, but certainly late beta.  Get the code out there.  Get it in 
the hands of as many users willing to test as possible.  Get them 
reportng bugs.  Just don't call it full release quality yet.  That's the 
only place kde4 has fallen down, IMO.  I've absolutely no issues with the 
code as it is presented today, provided it's not claimed to be general 
release quality yet.  That they ARE making that claim, and what's worse, 
that they were making it with 4.2, simply stretches their credibility 
beyond the breaking point.  How now are they to be trusted in any /other/ 
claims they make?  Of course the other place they've fallen down is in 
pulling support for what actually /was/ release quality by now, the kde3 
series, and that AFTER making a very public claim that it would be 
supported as long as there were users.  But given that they claim kde4 is 
ready for the masses, and indeed, that it was ready with 4.2, when there 
were still clear issues with broken functionality... given that, I 
suppose the position on ending kde3 support is at least understandable.

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

It could be argued that the QA plan is in accord with the "release early, 
release often" mantra of freedomware, that they are doing just that, and 
relying on their faithful beta testers to report the issues so they can 
be fixed.  I haven't a problem with that at all... as long as there's 
some sort of truth in labeling, the bit that seems to be missing, in this 
case.

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