1i5t5.duncan at cox.net
Thu Nov 12 10:08:22 GMT 2009
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
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
>>>> 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
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
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.
More information about the kde