4.3.3 bugs

[James Tyrer]

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.

I have been told by the moderator of this list that I have bugs because
my distro is Linux From Scratch [my tag line says 'mostly' because I
started by installing enough of Fedora to get it to boot and I still
have a few RPMs installed).  I do not think that that is the case, but
still I would like to have someone with KDE-4.3.x installed from
binaries to confirm that they have the same problem.

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

[Andrew Mason-9]

Sure, just forward the list and i'll see what i can confirm. I have
kde 4.3.3 from binary on kubuntu and also from source on slackware 13.
Andrew

On Sat, Nov 7, 2009 at 3:12 PM, James Tyrer <jrtyrer@...> 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.
>
> I have been told by the moderator of this list that I have bugs because
> my distro is Linux From Scratch [my tag line says 'mostly' because I
> started by installing enough of Fedora to get it to boot and I still
> have a few RPMs installed).  I do not think that that is the case, but
> still I would like to have someone with KDE-4.3.x installed from
> binaries to confirm that they have the same problem.
>
> --
> 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.
>

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

[Rick Miles-2]

On Saturday 07 November 2009 15:42:46 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.
>
> I have been told by the moderator of this list that I have bugs because
> my distro is Linux From Scratch [my tag line says 'mostly' because I
> started by installing enough of Fedora to get it to boot and I still
> have a few RPMs installed).  I do not think that that is the case, but
> still I would like to have someone with KDE-4.3.x installed from
> binaries to confirm that they have the same problem.
>

Which binaries, whose compile? I have Slackware's KDE-4.3.2 installed. Unlike some
of the more "popular" distros Slackware is built vanilla with no changes/patching
of upstream source unless absolutely necesary.
--
Cheers,

Rick Miles

Written on Sweetmorn, the 19th of The Aftermath, 3175
http://turtlespond.net
http://rickmiles.com.au

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

Rick Miles posted on Sat, 07 Nov 2009 19:32:05 +1100 as excerpted:

> On Saturday 07 November 2009 15:42:46 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.
>>
>> I have been told by the moderator of this list that I have bugs because
>> my distro is Linux From Scratch [my tag line says 'mostly' because I
>> started by installing enough of Fedora to get it to boot and I still
>> have a few RPMs installed).  I do not think that that is the case, but
>> still I would like to have someone with KDE-4.3.x installed from
>> binaries to confirm that they have the same problem.

Well, even if it is, the source tarballs are the only thing kde ships
directly -- they rely on the various distributions to provide their own
compatible binpkgs.  Thus, if it's a bug because due to compiling and
installing from source, it's far more directly a kde bug than if it's due
to some change the distribution made themselves.

So such from-source bugs very much belong on the kde lists, if anything
does.  It could in fact be persuasively argued, were one to wish to, that
it's the binary distribution folks who need to find the their own
distribution lists to posts their bugs on.

But I think it rather better policy to say come-one, come-all, if it's a
problem involving kde, post here, and we'll try to help.  Perhaps we can,
perhaps we can't, but we'll try, which is after all the case with any
such lists or forums one might post to, distribution, upstream DE, or
upstream individual package, where such individual forums/lists exist.

> Which binaries, whose compile? I have Slackware's KDE-4.3.2 installed.
> Unlike some of the more "popular" distros Slackware is built vanilla
> with no changes/patching of upstream source unless absolutely necesary.

So yeah, post the bugs, and we'll see what happens.  Several have said
that, now.

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

[James Tyrer]

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.

1. Auto completion doesn't work in Konqueror (and other places).

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.

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.

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

Using the same test case as #2, click the "Root" entry in the place
list.  Nothing happens.  Look at the treeview window; "Root" is missing
from the top.

4. Some Konqueror KPart toolbars have the wrong names.

Not exactly sure if this is a bug but no denigration allowed:

"Search Toolbar <search bar>" should be named "Main Toolbar <search bar>".

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

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.

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

[Anne Wilson-5]

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

> 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

> 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

> 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>".
>
> "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 understand the purpose of these comments.  Are you arguing with
developers' decisions?  Or are you saying that these names cause problems for
you?

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

Anne
--
KDE Community Working Group
New to KDE4? - get help from http://userbase.kde.org


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

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.

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

On Thursday 12 Nov 2009 7:32:46 am James Tyrer wrote:

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

Works for me too!

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

Unless we are talking of completely different things it works just fine here
too. The tree view does indeed show me hidden files if i ask it to. And i am
able to select ~/.kde/Autostart without typing in.

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

As i said i am able to select it in here. Did you miss seeing the option to
show hidden files? Right click in the treeview and you should see the option.
--
Cheers!
Kishore
___________________________________________________
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.

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.

[James Tyrer]

Duncan wrote:

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

I need to upgrade Xorg.  However, I am using PS/2 connected mouse and
keyboard.  Can I use xf86-input-evdev with non-USB input devices?

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

I didn't even look for a context menu. :-(  So, I guess that this is a
HIG/usability issue.  Wouldn't it be better to have a toolbar, menubar,
or icon? -- like in the KFile dialog.

> 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.
>
Like the wrench icon in the KFile dialog.  That also makes it a
consistency issue.

Also, now that I found the context menu, I find another serious
usability bug/issue.  It has: "Delete" (which I understand that you
like) despite the fact that I have not checked the box for: "Show
'Delete' command" in File Management -> General.

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

This would be acceptable in TRUNK or a development branch, but not in
the release branch.

> Now I 100% support the oft-repeated freedomware mantra, release
> early, release often, and kde CANNOT be faulted for that!

I do fault them for that.  The current quality assurance process sucks.

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

Agreed.  Release early and often but I think that those that write code
should have the personal responsibility to do some basic TQM on their
own work (I do).

> 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.
>
Actually, this is more egregious since it appears to be a design error.
  One of my instructors in engineering college had a bromide that he
borrowed from carpentry: 'Design twice and code once'.

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

I am saying that people should review their own work.  I think that
people will find what enterprises (not including MicroSoft :-D) have
found, which is that preventing defects from the start takes much less
time in the long run than finding and fixing them later.

> 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).
>
I learned software *engineering* in college.  I know no other way but to
make sure that the code that I write works before it leaves my machine.
  People must be responsible to see that their code works.  What we have
now is that people write code, don't even check to see that it compiles,
commits it, and they wait for bug reports to see if it works.  I
exaggerate to make my point.  Basically, you are saying that unless
developers can be sloppy, that they will not continue to work for the
project.  Well I do not find that acceptable.  Excellence requires that
people take pride in their work.  People that take pride in their work
will not do sloppy work -- it really is that simple.

> 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!
>
That is not a good software engineering methodology.  But, you are not
totally wrong.  Yes, if you are working on a block of code and working
on that code breaks other things, yes that should be committed to TRUNK
as long as everything still compiles.  But, to partially do a job in the
hopes that someone will finish it, is not acceptable.

> Now once the code is committed and the basic functionality working,
> it's time to polish things.

I have to tell you that it is my belief that hacking is not a good
software engineering methodology.  I have to disagree with you here.  If
you commit something with design defects, it isn't about polishing
things.  Parts of the code will then have to be redone.

> 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.
>
The problem is that KDE is not experimental software.  What we have is
what I would call a development branch, which is fine.  The development
branch should release early and often so that more people can test it if
developers aren't willing to test their own work.

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

No, we still have more basic issues.  Things which simply do not work
and these appear to be either design defects or due to a failure to use
the basic development process.

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

Yes.

> Get it in the hands of as many users willing to test as possible.

Yes.

> Get them reportng bugs.

Yes.

> Just don't call it full release quality yet.

Yes, call it (KDE-4.3.3) KDE4-0.8.3.  Nobody will complain if version
0.8.3 still has problems.

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

If KDE had applied some basic TQM methods, the code would be in better
shape and, believe it or not, developers would have accomplished more
while working less.  That is why enterprises (not software) have adopted
TQM.  It actually does work.  You find the defects at the source and the
result is better quality and reduced effort.

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

Perhaps the Beta testers haven't done their job, or perhaps the bugs
reported haven't been promptly fixed.  Either way, the system hasn't
produced a product with adequate quality.  If KDE is going to regain its
damaged reputation, quality must be improved.  To do that, methodologies
must be improved.

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

[Anne Wilson-5]

On Thursday 12 November 2009 11:45:35 James Tyrer wrote:
A lot.

Can I ask one simple question.  Apart from complaining, what are you doing to
help fix any issues that arise?

Anne
--
KDE Community Working Group
New to KDE4? - get help from http://userbase.kde.org


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

[James Tyrer]

Anne Wilson wrote:
> On Thursday 12 November 2009 11:45:35 James Tyrer wrote:
> A lot.
>
> Can I ask one simple question.  Apart from complaining, what are you doing to
> help fix any issues that arise?
>
As I said in my first post to this thread.  After we discuss the
possible bugs, we will see about writing bug reports and perhaps I can
even fix some of them if people are willing to allow me to fix bugs.

As far as software engineering issues are concerned, there is little
that I can do for people that do not want help.  Still, I am here and as
long as I remain retired on disability, KDE can have the assistance of a
college trained software engineer for free.  I have suggested that like
minded people join the KDE-Quality list and the we (there) try to
organize a quality improvement effort.

I think that it would be better to say that I am analyzing the problems
rather than say that I am complaining.  Analysis is a very important
part of the engineering method.  The theory is that first you find the
fault and then you fix the fault.  It is very difficult to fix a fault
in you have not found it. :-)  We are now working on finding the faults
by analyzing the issues which I have found on my system in order to
determine whether these are KDE bugs and the to more exactly determine
the nature of the bugs.  I write good bug reports because first I
analyze the problem.  I have asked that members of the list assist me in
this effort.

You could actually be of assistance if you would provide clear and
detailed analysis rather than just saying that 'there is no problem'.

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

[Anne Wilson-5]

On Thursday 12 November 2009 12:35:51 James Tyrer wrote:

> I think that it would be better to say that I am analyzing the problems
> rather than say that I am complaining.  Analysis is a very important
> part of the engineering method.  The theory is that first you find the
> fault and then you fix the fault.  It is very difficult to fix a fault
> in you have not found it. :-)  We are now working on finding the faults
> by analyzing the issues which I have found on my system in order to
> determine whether these are KDE bugs and the to more exactly determine
> the nature of the bugs.  I write good bug reports because first I
> analyze the problem.  I have asked that members of the list assist me in
> this effort.
>

Then can I suggest that you fix on one or two problems that you feel to have

maximum impact.  The current scatter-gun approach does not lend itself to
deeper investigation.

> You could actually be of assistance if you would provide clear and
> detailed analysis rather than just saying that 'there is no problem'.
>
I never say 'there is no problem'.  I do sometimes (often?) say 'there is no
problem here' - not the same thing at all, but it does suggest that the issue
is not simply something that no-one got around to considering.  You have made
a few personal remarks such as this recently.  Please stop.  They will not
have any effect on me, so they are pointless and simply lower the tone of the
discussion.

On occasions where I have seen you to be looking at something objectively, and
I can see some evidence of the problem, I have happily joined your
investigation, as witness the recent occasion when you requested, and got, a
sample file for investigation.

Anne
--
KDE Community Working Group
New to KDE4? - get help from http://userbase.kde.org


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

James Tyrer posted on Thu, 12 Nov 2009 04:45:35 -0700 as excerpted:

>> 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.
>>
> I need to upgrade Xorg.  However, I am using PS/2 connected mouse and
> keyboard.  Can I use xf86-input-evdev with non-USB input devices?

I believe so.  Note that you need the kernel (I'm assuming Linux) evdev
driver enabled (that was the part I missed[1]), and the devices are a bit
different, but it's possible to keep the standard kernel mouse driver
enabled as well, as I did, since gpm didn't seem to work with evdev.  But
the kernel long ago combined the pointing device input frameworks under
what originally started out as USB based HID, with the /dev/input/mice
and /dev/input/mouseN devices actually being kernel based emulation of a
standard imps mouse device(s), translating whatever you actually use into
the standard.  If you're still using /dev/psaux, you may well have some
extra upgrading to do, but that's /waaaayyy/ outdated by now.

The basic keyboard "just worked", but as I mentioned, I did have to
figure out how to setup hal to handle the extra keys on the Logitech
inet/media keyboard I have, tho even that wouldn't have been necessary
had I setup the evdev driver in xorg.conf and disabled xorg and hal's
autodetect, the "legacy" way of doing it.

....
[1] Since I run ~arch, the unstable/testing branch of Gentoo, and even
unmask packages to try before they hit ~arch sometimes, I'm often way out
in front of the documentation Gentoo prepares for stable users before the
new version goes stable, when it's a major upgrade like some of the xorgs
are.  In this case, I had been running the newer xorg-server, but with
the "legacy" xorg.conf setup, for a couple months before I got around to
tackling the new setup.  By this time, Gentoo was getting ready to
stabilize it and had a draft upgrade guide, which was the basis of most
of my upgrade research.  However, at the time, it neglected to mention
that there was an evdev kernel driver to enable as well, so I spent
several hours screwing with hal configs and wondering why nothing would
work, when it was simply a missing kernel driver!  So then while I was
doing something else for awhile, my subconscious had time to recall that
I'd seen a kernel menuconfig item for it, and sure enough, turn it on,
rebuild the kernel, reboot with the new driver, and it worked!  Obviously
I filed a bug on the Gentoo upgrade doc right away, and they added a note
about the kernel driver requirement to their docs. =:^)

That's the sort of thing I /expected/ to be doing when I upgraded to
kde4.  Unfortunately, despite all the claims about it being ready for
normal use by 4.2, that wasn't the case.  There were /waaayyy/ too many
things still broken in kde 4.2 for it to be even late beta quality then,
tho it is now.  More like alpha quality, then.  Of course, I had a bit of
a clue as I had been trying to upgrade to it since before 4.0, but it was
even worse than I expected.

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

[James Tyrer]

James Tyrer wrote:
<SNIP>
I am going to add some additional description to clarify some of this.

> 1.    Auto completion doesn't work in Konqueror (and other places)
> using the mouse.
>
> 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.
>
I note that this does work using the cursor keys.  So, it is probably
some issue with KDE (or more probably Qt) vs the Xorg mouse driver.

Does anyone else have a PS/2 mouse connection?

> 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 the place
> "Home".  The ".kde4" directory isn't listed,

I tried <Alt><.> but this has no effect.

This appears to be another bug since it does not use the standard
keyboard short cut for "Show Hidden Files".

> so enter "/." and you get a list, but I can't use the mouse to select
> from them but see #1.
>
>
So, after I select the path "/home/jrt/.kde4" using the cursor key,
nothing happens in the treeview.  Is this a bug?  Did it work
differently in KDE-3?  Should it work differently.
>

> 3.    Select Folder dialog won't go to the "Root" place.
>
> Using the same test case as #2, click the "Root" entry in the Places
> list.  Nothing happens.  Look at the treeview window; "Root" is
> missing from the top.
>
> 4.    Some Konqueror KPart toolbars have the wrong names.
>
> Not exactly sure if this is a bug but no denigration allowed:

It appears that whoever did this failed to follow the established scheme
for naming the toolbars for KParts which has first the name of the
toolbar that they add onto and then a name indicating the part enclosed
in "< >".  I have to say that I do not know if there is documentation on
this anywhere or if you simply have to figure it out for yourself as
with many things in KDE development.
>
> "Search Toolbar <search bar>" should be named "Main Toolbar <search
> bar>".
>
> "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>".
>
As established after some discussion, the real bug in #2 is that the
treeview (anybody know the correct name?) dialog has no toolbar like the
KFile dialog does.  Look at the KFile dialog, there is a wrench icon in
the upper right corner (perhaps not the best place, but there is a
toolbar and the icon is on it).

IIUC, it is a suggestion of the HIG that context menus not be cluttered
up with too many items.  IMO, the context menus on the treeview dialog
as well as the KFile dialog both have too many things on them.
Specifically, items in "Options" in the KFile dialog do not need to be
on the context menu and items in the context menu in the treeview dialog
should be moved to an "Options" menu.

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

James Tyrer posted on Sat, 14 Nov 2009 00:39:16 -0700 as excerpted:

>> 1.    Auto completion doesn't work in Konqueror (and other places)
>> using the mouse.
>>
>> 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.
>>
> I note that this does work using the cursor keys.  So, it is probably
> some issue with KDE (or more probably Qt) vs the Xorg mouse driver.
>
> Does anyone else have a PS/2 mouse connection?

I really doubt it's the physical mouse bus or how the driver reacts to
it.  More likely, it's the driver interacting with kde, or the config.  
It sounds like your xorg is significantly older than your kde at this
point.  What version of xf86-input-mouse and xorg-server are we talking,
what kernel version, and what's your kernel mouse config like -- which
kernel device do you have xorg using?

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

[James Tyrer]

Duncan wrote:

> James Tyrer posted on Sat, 14 Nov 2009 00:39:16 -0700 as excerpted:
>
>>> 1.    Auto completion doesn't work in Konqueror (and other
>>> places) using the mouse.
>>>
>>> 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.
>>>
>> I note that this does work using the cursor keys.  So, it is
>> probably some issue with KDE (or more probably Qt) vs the Xorg
>> mouse driver.
>>
>> Does anyone else have a PS/2 mouse connection?
>
> I really doubt it's the physical mouse bus or how the driver reacts
> to it.

The Kernel does use different drivers for PS/2 and USB.  Although these
should act the same, perhaps they don't.

> More likely, it's the driver interacting with kde, or the config. It
> sounds like your xorg is significantly older than your kde at this
> point.

However, it has never worked starting with 4.0.0 or probably before.

> What version of xf86-input-mouse and xorg-server are we talking,

I have server 1.6.2 and I installed version 1.5.0 of the mouse driver
recently with no change.

> what kernel version,

2.6.30.2

> and what's your kernel mouse config like -- which kernel device do
> you have xorg using?
>
xorg.conf has "/dev/input/mice".

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

James Tyrer posted on Sat, 14 Nov 2009 03:55:52 -0700 as excerpted:

> Duncan wrote:
>> James Tyrer posted on Sat, 14 Nov 2009 00:39:16 -0700 as excerpted:
>>
>>>> 1.    Auto completion doesn't work in Konqueror (and other places)
>>>> using the mouse.
>>>>
>>>> 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.
>>>>
>>> I note that this does work using the cursor keys.  So, it is probably
>>> some issue with KDE (or more probably Qt) vs the Xorg mouse driver.
>>>
>>> Does anyone else have a PS/2 mouse connection?
>>
>> I really doubt it's the physical mouse bus or how the driver reacts to
>> it.
>
> The Kernel does use different drivers for PS/2 and USB.  Although these
> should act the same, perhaps they don't.

Yes, but see below.  What I was getting at is that, if you're using the
right device which you are, the kernel is supposed to make whatever you
have look to the rest of the system like a Microsoft PS2 mouse, or an
Intellimouse, the same but for the number of buttons, AFAIK.

>> More likely, it's the driver interacting with kde, or the config. It
>> sounds like your xorg is significantly older than your kde at this
>> point.
>
> However, it has never worked starting with 4.0.0 or probably before.
>
>> What version of xf86-input-mouse and xorg-server are we talking,
>
> I have server 1.6.2 and I installed version 1.5.0 of the mouse driver
> recently with no change.

xorg-server 1.6.2 isn't /that/ old, either.  I'm not sure without
looking, for the mouse driver.

>> what kernel version,
>
> 2.6.30.2

OK, that's new enough it shouldn't be the problem.

>> and what's your kernel mouse config like -- which kernel device do you
>> have xorg using?
>>
> xorg.conf has "/dev/input/mice".

/dev/input/mice is a kernel "emulated" mouse.  It takes whatever it sees
and emulates a ps2 Microsoft Explorer mouse with it.  That's why I'm
saying it shouldn't matter.

What mouse type are you telling xorg to use, and is it set to use the
xorg.conf setting or hal (with server 1.6 and possibly 1.5, IDR ATM, it
would ignore the xorg.conf setting and use hal, unless you set a
serverflag telling it not to.  I don't have time ATM to look at the
details, but the xorg.conf manpage has them I believe.)

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

[James Tyrer]

Duncan wrote:

> James Tyrer posted on Sat, 14 Nov 2009 03:55:52 -0700 as excerpted:
>
>> Duncan wrote:
>>> James Tyrer posted on Sat, 14 Nov 2009 00:39:16 -0700 as
>>> excerpted:
>>>
>>>>> 1.    Auto completion doesn't work in Konqueror (and other
>>>>> places) using the mouse.
>>>>>
>>>>> 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.
>>>>>
>>>> I note that this does work using the cursor keys.  So, it is
>>>> probably some issue with KDE (or more probably Qt) vs the Xorg
>>>> mouse driver.
>>>>
>>>> Does anyone else have a PS/2 mouse connection?
>>> I really doubt it's the physical mouse bus or how the driver
>>> reacts to it.
>> The Kernel does use different drivers for PS/2 and USB.  Although
>> these should act the same, perhaps they don't.
>
> Yes, but see below.  What I was getting at is that, if you're using
> the right device which you are, the kernel is supposed to make
> whatever you have look to the rest of the system like a Microsoft PS2
> mouse, or an Intellimouse, the same but for the number of buttons,
> AFAIK.
>
>>> More likely, it's the driver interacting with kde, or the config.
>>> It sounds like your xorg is significantly older than your kde at
>>> this point.
>> However, it has never worked starting with 4.0.0 or probably
>> before.
>>
>>> What version of xf86-input-mouse and xorg-server are we talking,
>> I have server 1.6.2 and I installed version 1.5.0 of the mouse
>> driver recently with no change.
>
> xorg-server 1.6.2 isn't /that/ old, either.  I'm not sure without
> looking, for the mouse driver.
>
>>> what kernel version,
>> 2.6.30.2
>
> OK, that's new enough it shouldn't be the problem.
>
>>> and what's your kernel mouse config like -- which kernel device
>>> do you have xorg using?
>>>
>> xorg.conf has "/dev/input/mice".
>
> /dev/input/mice is a kernel "emulated" mouse.  It takes whatever it
> sees and emulates a ps2 Microsoft Explorer mouse with it.  That's why
> I'm saying it shouldn't matter.
>

Some documentation suggests using: "/dev/input/mouse0".  Does this make
a difference?

> What mouse type are you telling xorg to use,

     Driver "mouse"
     Option      "Protocol" "IMPS/2"
     Option "Device" "/dev/input/mice"

> and is it

Pronoun reference please.  Is what set?

> set to use the xorg.conf setting or hal (with server 1.6
> and possibly 1.5, IDR ATM, it would ignore the xorg.conf setting and
> use hal, unless you set a serverflag telling it not to.  I don't have
> time ATM to look at the details, but the xorg.conf manpage has them I
> believe.)
>
I do not have:

        Option "AutoAddDevices"
        Option "AutoEnableDevices"

in my xorg.conf file.  IIUC, they are both true by default.

The man pages are not really adequate documentation. :-|

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