In this week's KDE-CVS-Digest: The LDAP kio-slave is improved with TSL and SSL for secure connections and SASL for authentication. KDEPIM has a new certificate manager. Work proceeds apace on the khtml XML parser and xpath libraries. Plus a large number of bug fixes in Kopete.
Dot Categories:
Comments
" most people don't learn the kcontrol layout even after using KDE for >1 year."
That's because the layout changes with every release. I've been using KDE since -- was that 1.1, or 1.12, or even earlier? A bloody long time, anyway, and everytime I have to retrain my reflexes to a new kcontrol layout. Not that that's special with KDE, OS X does it, too -- and perhaps Windows, I wouldn't know. My advice would be: don't mess with menu structures, kcontrol layout, kicker contents and whatever more there is until you've got real, hard data, from observing people working, instead of asking people about what they think they do -- that's silly --.
Don't mess with what's familiar -- it's familarity that breeds usability, it's changes, no matter how well intentioned, that breeds user anger. And that's from actual obersvation. You should hear and see my daughers reactions when their system is changed from under their feet. They are 8, 8 and 10, and can find their way in KControl just fine, until the order is changed once again. And my wife's opinion on some 'usability' changes between 3.1 and 3.2 is unprintable.
Anyway, I'm off trying to hack affine transforms into Krita using QWMatrix now. And a Kubelka-Monk based watercolour paint colour strategy.
i agree that changing kcontrol's layout over and over again is horrid. which is why we aren't going to do it for 3.3 =)
as for "real hard data", some are collecting just that. not everything requires it, but a lot of things do. it's fun that some think all changes are random or purely the opinions of people. =)
the flip side with "familiarity breeds usability" is that some things just aren't very given to breeding familiarity because they are too convoluted or used to rarely to do so. we're also going have a lot more users in 2-3 years than we do today. it would be nice to give those people something more usable than what we have today.
not random poking, as you note, but purposeful and measured. we still probably won't get absolutely everything perfectly right, but we can get closer.
prefmenu is much better for browsing and finding what you need because you don't need innumerable tree/icon clicks. Instead you just browse the menu and you get a quick bird's eye view of everything.
I definitely think this is more userfriendly.
Right on Aaron. If I can still get to the Konsole, what's the bother? I can still add it to my desktop or kicker or whatever. I don't use it too often, but when I need it, it is there.
I think it makes sense to try and make KDE as usable as possible from a default install. I know some people will hate this, but it is necessary. I agree.
What I do not agree with is the way in which the Gnome and Ximian people in particular have tried to promote scientific usability at every turn, using what the people at Apple have done as a benchmark. There is absolutely nothing wrong with that, but it isn't quite that simple. Many people out there in the business world respect Macs totally, and will respect the Gnome and Ximian Desktops themselves, but they won't be able to use them. Windows is used for a multitude of different things out there, and trying to force 'usability' at every turn is just not practical, although you should follow the guidelines. Microsoft seem to have understood this over the years.
A correct balance needs to be struck and I'm sure KDE will do it.
The problem is that scientific usability is what Microsoft does as well. So does Apple and Sun for GNOME. It makes apps much more usable and friendly. Also, impressions are determine to a large extent how users perceive the userfriendliness of a desktop. For an extreme example, Imagine if your desktop came with the whole desktop littered with icons for every app. Most users want it empty, and then they add what ever they want on the dektop by themselves. That is increasing usability.
MS and Apple do indeed practice "scientific" usability... and does microsoft or apple have their terminal app on the panel by default? nope =)
Yes they do practice scientific 'usability', but Microsoft have learned to put a degree of flexibility into this because of the multitude of uses that Windows is put to and the number of people that use it. However, do Microsoft shove the Command Prompt into your face? No. They put it with all the other 'not-very-used-but-important-stuff' under Accessories. I think that's a strong hint.
What they don't do is dictate a HIG strongly to application developers (although there are good guidelines and a HIG is no bad idea - KDE should formulate one over time, perhaps with the backing of Trolltech?) which they have to follow, otherwise their applications look completely out of place. A desktop like this looks sanitised to users, and this is something many just cannot stomach. Apple has a minority desktop share and a lot of loyal Mac enthusiasts, so they can get away with this. This is something Ximian and others around Gnome will have to learn over time, and promoting the joys of a HIG-compliance utopia gets you nowhere.
The trouble is, a HIG really doesn't do that much. For the majority of tasks, the KDE style guides are more than ample. That covers manuals and general good practices, but leaves room enough so that the application doesn't have to spend twice as long in development to become compliant.
A more worrying thing is to have a rigidly enforced HIG which in itself causes applications to jump through hoops to be compliant; that will cause conceptual breakage of the application, which is far worse for the user.
Moreover, the Gnome HIG deals with all sorts of issues, such as the height of taskbars, margins and fine tuning of objects, as well as dialog construction and other things, which KDE doesn't need to worry about, because they are all inherited, from KDE base or from QT itself.
Worst of all, if application developers feel too constrained, they start trying to make themselves *unique* in other ways than their little UI tweaks, and that can be problematic. At the moment, applications tend to learn from others, interact nicely and develop unofficial guidelines from iterative improvement with competitors. I do fear that a tight HIG would force more dichotemy and break this situation.
In short, guidelines good, HIG bad :)
"The trouble is, a HIG really doesn't do that much. For the majority of tasks, the KDE style guides are more than ample. That covers manuals and general good practices, but leaves room enough so that the application doesn't have to spend twice as long in development to become compliant."
Yep, I agree with that.
"A more worrying thing is to have a rigidly enforced HIG which in itself causes applications to jump through hoops to be compliant; that will cause conceptual breakage of the application, which is far worse for the user."
I agree again. No developer wants to have to follow a rigid set of rules to get an application looking OK, especially if it is rapidly developed. They would want some easy too follow guidelines that don't give them too much overhead though.
"Moreover, the Gnome HIG deals with all sorts of issues, such as the height of taskbars, margins and fine tuning of objects, as well as dialog construction and other things, which KDE doesn't need to worry about, because they are all inherited, from KDE base or from QT itself."
This is definitely true.
"Worst of all, if application developers feel too constrained, they start trying to make themselves *unique* in other ways than their little UI tweaks, and that can be problematic. At the moment, applications tend to learn from others, interact nicely and develop unofficial guidelines from iterative improvement with competitors. I do fear that a tight HIG would force more dichotemy and break this situation."
Yep.
"In short, guidelines good, HIG bad :)"
Yep.
'scientific usability'.
That's just another way of saying I'm right, you are wrong. I haven't heard the kde usability people talk this way, which makes me think they might do the right thing.
Derek
"That's just another way of saying I'm right, you are wrong."
Not sure what you mean by that. Perhaps I worded it wrongly. A very rigid HIG is just a bad idea, especially for developers. People will want guidelines though.
" haven't heard the kde usability people talk this way, which makes me think they might do the right thing."
Neither have I, and I think they will.
I think you got my point. In usability there is at best a good compromise, at worst an imposition of ones way of working on someone else. To call one way scientific is to shut down debate.
I'm quite surprised at the feelings in this discussion. Somehow these things touch what people care deeply about. Or we're all raving lunatics. Or both.
Derek
"To call one way scientific is to shut down debate."
Yes, wrong choice of words. Couldn't think of any other way of saying it when I was quickly tapping away.
"I'm quite surprised at the feelings in this discussion. Somehow these things touch what people care deeply about. Or we're all raving lunatics. Or both."
Possibly. I wasn't coming out with harsh feelings in this discussion, just what I know to be true as a developer and why I think KDE is actually heading in the right direction.
I'm a power user and I'll just add Konsole to where I feel I will need it. It ain't hard. I don't understand the feelings over that.
This discussion has included several times the sensible point that a console
is an essential tool for many (the more experienced) users of systems on which KDE runs. The reply from a developer points out how easy it is to add
a console icon to the toolbar, and states that some users are uncomfortable
with the console, hence its removal from the default configuration.
The important point here -- made by an earlier contributor but ignored by the
developer -- is that
IT IS ALMOST ENTIRELY THE PEOPLE WHO OFTEN WANT A CONSOLE, WANT
SENSIBLE NAMES FOR DIRECTORIES, ETC. WHO WILL BE USING A DEFAULT KDE.
Practically anyone not happy with a console will be using KDE as `adapted'
by the likes of RedHat, Mandrake etc. These distributions make huge changes
to kde layout, colours, icons, menus, toolbar and so on. They are well able
to add or remove what icons they consider most suited to their users.
On the other hand, the typical unix-user who likes KDE will compile betas
and RC versions, and update regularly to new releases. Indeed, I venture
to say that anyone using a true default KDE will be moderately conversant with
the underlying system, and would find a console on the toolbar to be
desirable. So it is ridiculous that these users should be forced into making
changes, however simple, every time they install a new version, while users
who want the changes are sheltered behind a distributor's changes anyway!
The same point applies to many other "simplifying" changes that have
undermined KDE's excellence in the latest release -- LET DISTRIBUTORS
MAKE CHANGES TO SUIT NOVICE USERS.
___________________
Finally: there exist a plethora of oversimplified, poor-utility GUI desktops,
such as those for macintosh (one mouse button, miles to travel to the menus),
microsfot `windows' ("you can't change this name", explorer crashed, etc) and
GNOME with its similar tendency to simplifying things for new users rather
than allowing someone who is willing to learn a little to end up with a
really efficient system that offers many options at once (and could therefore
appear overcomplex for the first time). But people who use such a system a
lot appreciate these more complex options that allow quick and powerful
control.
For the reason given above about default users of KDE, please keep KDE
powerful, and don't drag it into the pit of friendly-to-first-time-users,
simple menus and so on.
Either keep it good, and let others change it, OR allow various configurations
(default: complex) that let users select the styl on first login, as is
already done with colours, window style etc.
The problem is that every distributions define what a user is and needs. So you get many many KDE variants and it is getting more and more a nightmare to support.
So KDE needs to do some basic work. (The variants will still happen nevertheless.)
Have a nice day!
Get serious. There are few distributions compared to the number of users.
The distributions have to do the leg work customization once at the source and then all their users will benefit.
The thousands of users downloading KDE on the other hand are all inconvenienced for no good reason. There are many more users inconvenienced than distribution developers.
Basically you are favoring the corporates over your own users. That isn't good and frankly doesn't bode well for KDE.
I must say that I have some problems to understand this answer, especially the part that users of distributions would not be supposed to be our users.
I would prefer that the distributions keep their finger away from modifying KDE. Because for a user whatever he has in front of him is KDE, independently how much it has been modified. And such a user does not understand that we answer him something like: "Well, that is not KDE, it was modified, so I cannot answer you."
Have a nice day!
You have no control over what the distributions do. They will modify KDE whether you like it or not. Look at Red Hat. Look at Lindows. You have to accept that.
So why not cater to your actual users, the people who download KDE and use it? As I've said the distributors only have to customise KDE once for all their users.
I think it's a very simple argument, logical and easy to understand.
all KDE users are "our" users (assuming you contribute to KDE, Mr. Anonymous; and if not they aren't YOUR users at all). i think that's a very simple argument that is logical and easy to understand.
as such, i agree with your other point that we need to cater to our actual users. and no, those aren't just corporate users. they are home users and hobbyist users, too. people who install debian or gentoo. people who install SUSE and Mandrake. people who use it on Solaris and FreeBSD.
the real disconnect here between you and me on this issue is our definition of KDE's target market. you seem to think that the primary target market is you and i: power user, programming UNIX geeks. and as you can see i don't agree with that. why not? because reality says most people who use KDE are not power users, programmers or UNIX geeks.
i'd like to serve the real user population as KDE's primary target group. i don't think this has to come at the expense of you and i, but we need to stop being selfish for a few minutes here and think of everyone else who uses KDE.
your whining about how it's going to take you 5 seconds longer to put konsole on kicker so it is where you like it, just so we can impose on the other 95% of our users it pretty sad.
"i'd like to serve the real user population as KDE's primary target group. i don't think this has to come at the expense of you and i, but we need to stop being selfish for a few minutes here and think of everyone else who uses KDE."
Sorry Aaron, but I see it the other way around in this case.
I doubt your data (5%? come on), and your resoning. Optimizing KDE for your "real user population" doesn't mean ignoring everyone else. It's not like anyones trying to impose a geeky configuration to everyone else. It's just the konsole. I'd be much more happy to get rid of stuff like "KDE-Temporary Folders" which I just mentioned some time ago in the usability mailing list.
J.A.
well, konsole is Geek. i'm not sure how else to say it.
and the temp folders entry appears in the file dialog, not the panel. the two are completely separate issues, which may not be apparent to the casual reader given how you phrased it. we _can_ do both things ;)
speaking of the file dialog, it has been changing slowly over the last few releases. items were removed from the side bar and from the toolbar. things were rearranged and made more consistent with the rest of kde. we're now using medium sized icons with better spacing in CVS. maybe we'll even have no Temp Files item in 3.3 ;-)
Yes konsole is geek. And I think it is important to keep it.
IMO the number of people using it should be enough, sorry but I 5% doesn't sound right. There is more to it than that though. Our sys admin, FVWM2 hardcore geek, when helping people (using kde) just clicks the konsole and works from there. Having a terminal as accessible as possible means linux/*nix users can get away without being familiar with the environment. It's a common feature, a kind of consistency in our world. No matter where you go you can take that for granted.
I also think you may be to positive about the current state of linux (et al).
How many clueless newbies end up using a terminal when asking for help in irc? Gui solutions depend on the environment your using, (possibly modified by your distro) and eventually distro specific tools. Command line has more chances of working everywhere, also sometimes it's simply easier to give them a command to copy paste. (Think turning off/on a firewall, yes an average user might need to do it).
J.A.
P.S. About the Temp Folder, you're right, not only did I phrased it bad, I'm also mixing independent matters... never mind...
Hi people:
There's a solution for the complexity vs powerfull thing. Maybe KDE could have the option to hide some menu options, toolbars and/or toolbar buttons.
The user could easily show/hide that options at will (and if you use one many times, maybe it could be shown by default). Moreover, as you've already mentioned, it could be something more to configure in the first-time login (default: all options/essential options).
What do you think people?
Yes , Edulix, a very good idea; I have wanted something like this since KDE began its dumbing-down excersize.
a good idea? hahaha... no, this is a stupid idea. go do some research about user levels sometime and then report back. not only does it not work, it's an excuse to not fix our usability. and here's a shocker: power users need usable systems, too. not every Windows and MacOS user is a computer newbie/weenie, many are vastly more qualified to claim computer expertise than you probably are. yet they use these other OSes because they are more coherent and easier to use.
btw, you say KDE has begun a dumbing-down excercise. i find that highly offensive.
what, exactly, has been dumbed down? which functionality has been removed or changes such that KDE is less capable, exactly?
and how does making something elegant make it dumb? i always thought that clunky, inconsistent and poorly thought out things were "dumb" and that sleek well designed things were "smart". then again, maybe the world's best engineers have had it wrong all along and we should be making everything unnecessarily complex.
maybe the house to my door really ought to take 20 minutes for me to open and require a manual.
then again, maybe using a computer that takes months to learn and never master which is baroque with challenging "interfaces" doesn't make you a superior human, just one that gets less done in the day.
Elaborate, please; why `does it not work'? KDE already has oodles of config options that are established on first login, such as whether it should have general behaviour like "unix, kde-own-brand, mac" etc., colours and decorations in the style of solaris, kde, and so on.
Variation of menu levels and contents, or even some terminology, would certainly be _more_ complex than these, but what evidence do you suggest as a proper demonstration of this idea's not working? To quote your style, "what exactly will be the problem?". A FUD-style insinuation that something is impossible, and that this is well known, is not really very credible in the absence of any discussion and links to results of rational research on a project similar to KDE.
Your claim that such user options imply something left unfixed is ridiculous:
Some users are happy to spend a small amount of time to learn efficient and concise options that may not be immediately obvious on first sight. Some are familiar with standard user commands on the systems on which KDE runs. For these a desktop environment that is not obvious to the novice from another system/GUI will be more efficient than the simplified version --- such simplifications often in effect make menu levels deeper or replace concise letter codes and patterns with wordy menus.
If for some reason KDE must extend itself to users from many other experiences and without the care to invest a little effort in learning something that soon pays for itself, then it at least shouldn't lose its charm of efficiency to its experienced users. Either give a choice of user settings, or, if this is too hard, leave the dumbing down to distributors who are aiming at a particular user base.
"One size fits all" is simply not reasonable when dealing with an interface for a wide range of user needs/backgrounds/experiences/tastes.
I suggested a distinction between users familiar with the unixish systems on which KDE runs -- the type of user for whom KDE was originally written -- and those who are familiar only with the other desktops (inferior in many respects of utility to an experienced user) which KDE recently has begun to try to mimic (e.g. the stupid and now corrected "log in as a different user", "New Folder" as a filename, "Advanced" properties, etc.).
I don't see why you took this tangent of how "not every Windows and MacOS user is a computer newbie". Perhaps you took `novice users' as meaning novices to all computers -- or perhaps to novice users of a drug or something else wildly unrelated. Rereading my posting it is clear that it refers to those who are novices to KDE, or perhaps to the unix environment in general.
A dumbing-down excersize -- highly offensive! Well, yes, it annoys me too. though perhaps offensive is not the first word I would choose for it.
An example of a recent (3.2.0) depredation on KDE is the changing of the permissions dialogue in konqueror:
The original version was a sensible grid allowing obvious selection of any combination of the full set of permissions. This has the further advantage of being really clear at the first glance to someone who has a bit of experience with it, as the pattern of checked boxes is very memorable and resembles closely the single-row output of the ls -l command.
The new version has three drop-down menus to drop-down and select on, each of which has several words that one needs to analyse (instead of the really concise r w x), plus a choice of whether a file is [presumably means "is desired to be"] executable. It _still_ doesn't give as many possibilities as the simple 3x3 boxes, and of course doesn't show special bits.
The original version is still there, hiding behind that absurd misnomer "advanced", which has popped up all over the new KDE in places where "further", "more" or "rather basic but we thought another menu level would be jolly" would make a lot more sense.
So, of course it is still possible to use the permissions interface as before, but one is made to take an extra step each time or to rely on the limited scope and slow human-interaction speed of the new dialogue.
These sorts of reductions in long-term speed and scope for a possible saving in initial learning time, together with the word "advanced" for something that isn't, are a classic example of dumbing-down.
"> maybe the house to my door ..." What?
But if this means what it must, then I should point out that in the case you try to analogise (presumably an element of KDE that requires from some users a little thought or the manual/help-button on first use) the better house-door situation to choose for your analogy would be one where a minute is required to read and understand a perhaps non-obvious system, but this system then can be used with much improved utility for years to come (e.g. the permissions thing, above).
It is indeed a modern folly to want everything immediately with no effort, and the consequence to efficiency over a long time is often a reduction.
Of course there may be some cases where a changed interface is an improvement for all users: it just happens that the various changes complained about here are NOT in this category. Please don't succumb to this silly demand, but keep KDE _powerful_ (as it claims to be in its blurb).
"and how does making something elegant make it dumb?"
In itself, it doesn't (what a surprise). But this is a rather strange question for you to ask if you imagine it to have any relevance to the current thread!
The fact is, changes such as the permissions dialogue and "advanced" buttons have _not_ made anything elegant -- they have simply made it ugly, clunky, less effective, and .... dumb (in that Germanic and American sense in which it is meant in the phrase "dumbing down").
Some other changes such as sub-menus for the create-new option in konqueror _do_ seem more elegant and just as efficient and clear, and therefore are good.
Spending development work on making things like khtml render properly (i.e. catch up with Safari peoples' help and with gecko) or kword be reliable (else adapt OpenOffice rather than reinventing the wheel again) would surely be much more worthwhile to practically all users than pseudo-simplifying interface aspects that can so much more easily be messed up by distributors if they want them that way.
Finally, I _do_ appreciate the work that has gone into KDE; it is still for many uses much the best of all the many desktops I have met.
So thank you for your work; my complaints/suggestions are intended to prevent a barrage of complaints of "it's too difficult" causing the destruction of clear, unix-like and sensible KDE components in the absence of any noise from the other side of the argument.
And I don't just disbelieve you about the impossibility of different user modes, I am simply interested in what real reasons there are against the idea.
i'm just going to reply to the bit about user levels. actually, i'm just going to link to me replying to others asking about levels ;-)
http://lists.kde.org/?l=kde-usability&m=99616536430498&w=
http://lists.kde.org/?l=kde-usability&m=101408630928215&w=2
OK, thanks for the links. It is a good point that a set of a few generalised levels will surely give a lot of users things they didn't want. And a mere "old unix-style" versus "graphics only" would certainly have this potential problem even if it would solve the currently disputed problems with names permissions and konsole buttons.
I shall suggest, lower down the list, a modification.
Totally agree. Unfortunately Aaron basically just said he's going to totally ignore arguments not in favor of his position. Apparently only the ones that agree with his position are logical enough. :P
that isn't what i said at all. if you were to actually follow threads on the mailing lists that i'm involved in you will notice a couple things:
1) i don't only agree with what agrees with me; which is to say i often arrive at different conclusions than that which i started with. your accusations that i'm unreasonable are borne of ignorance. i can excuse ignorance, but i can't excuse you drawing conclusions based on it.
2) i am usually the first to ask for corroberatory evidence when positions are taken, and i'm often the first to provide it as well. as i'm doing with Konqueror's web browsing toolbar layout, for instance. have you submitted your data yet? no? then you have nothing to complain about.
3) i only ignore arguments that have no basis. or would you rather that i listen to lunatics and morons instead of consider the well informed conclusions by people who bother to educate themselves and put some effort into it?
however, i must agree that picking on me is fun, isn't it? ;-)
Here are the things I notice:
1. I never previously saw a post from anyone on the dot (and yes, I don't sit on the devel lists so I don't know what goes on in those) complaining about how hard kde is to use and how having the konsole button confuses them. But I do now see some support for putting it back now it is removed.
2. Same with directories/folders argument.
3. Same with the permissions dialogue.
Nathaniel Taylor's suggestion of a customisation at first login seems excellent to me.
Are you an old-school UNIX user?
If yes, add konsole to the kicker, use directory instead of folder and make the file permissions dialogue behave sensibly.
If not, remove konsole from kicker, use windows terminology and make whatever other "simplifications" you want to make.
If KDE really does want to cater for everyone, then I think it is fair to assume at least two different customisation levels for user knowledge.
What do people think of this suggestion? Is it a possible way forward throught these disagreements? (and no, before anyojne suggests it, I don't have time to help code it up.)
Cheers,
Paul
user levels don't work, but i do think that we can provide means to cater to more than one audience simultaneously through a more intelligent interface. and no, i don't mean switching the order of widgets in a control panel or removing options or even just giving up =)
people willing to help gather information on Real World usage, design and implement interfaces and use-driven concepts are more than welcome, indeed *encouraged* to subscribe to the kde-usability list and start participating.
Aaron,
Are you talking about some interface which learns how the user works?
Paul
Like I have time to subscribe to another list when I can't read much of the ones I'm on. I already don't get enough work done, so I hope I can trust bright guys like you to do the right thing. I know you're willing to take the heat, you know I respect you and we both know that we usually have similar opinions. So I'm just going to say a simple thing by way of reference. We need to be careful what we assume the average user won't want because it can have a way of coming back unexpectedly.
For instance... people complained about the size of installed distros and many distros began not installing development packages (include files) unless you selected "developer install". This was on the assumption that most people don't compile their programs... which is true. However I get frequent questions from users who want to know what "X includes not found" or some other error means. In fact for a lot of users this becomes "passive lock in" because even though they have RPMs on a CD they can install to make it work they won't realize that or make that basic effort.
While it's true that it's not that hard to execute a few clicks for users to open a console, like the install issue we're operating on the theory of either apathy or ignorance (not in a bad way) reducing the likelihood. As I've said before, to help a user it is often most reliable and straight forward to tell them to open a console and give them the commands to execute because they can get confused navigating files. It's hard to get confused copying and pasting.
All of us that love the konsole now most likely discovered it at some time when we did not know it and possibly had little concept of it's power and elegance. By making this move we drive our user base in really a revisionist direction on the assumption that the use of this screen space is substantially annoying or useless. Note how much feedback this has generated.
I can't help but note that if you're talking 32 x 32 icons that's 1024 pixels out of 480,000 pixels on the minimum 800x600 screen. That's 4% of a panel and 0.2% of a screen. Amazing... this is the biggest thing in KDE this week. It reminds me of the saying you can tell the size of a man by the size of a thing that makes him angry. (Often referencing a golf ball.) In any case, if I were to believe the 5% of users argument it still beats 4% of the panel in my book, not to mention whether the total number of console users grows or shrinks. At one time I didn't understand the gear shift on a car... fortunately it was not moved to the trunk to save space. We should encourage exploration here.
That's my 0.2 cents ;-)
In the light of the above links about user levels failing because of a user's possibly very different abilities/needs in different areas: Good point -- a small number of hardwired user-settings could cause much trouble.
So, why not:
** offer initial options of a (perhaps strongly marked) default -- KDE's currently favoured configuration -- and others such as very-GUI, unix-keen etc.
** make initial settings of toolbar, possibly terminology, menu depth and style, styles of various dialogues, based on the answer to this option
NEW**** have a kcontrol submenu that allows aspects not easily reverted manually (e.g. konsole _is_ easy just to change) to be changed so that having selected the global configuration supposedly closest to his/her needs a user can fine-tune the KDE behaviour. Things in this menu should be various dialogue styles, un-nesting of "advanced" options, terminology, etc.
The advantages:
-- Presence of the fine controls in kcontrol allows a far wider user base to have a final system they really like; this is not conveniently possible now, as we can't change things like "advanced" nesting and dialogue style except in the source code.
-- Presence of initial coarse settings (unix-style, very-GUI etc) reduce greatly the average time taken per user in getting the system as desired, since many aspects are then correct with one click.
-- There is still no cause for the claim that anything would be hidden/unuseable ; if an option appears as missing, the relevant control to change the style of that component can readily be found.
-- KDE will finally be properly configurable in every way. Being able to set one's preferred style of _every_ significant type of menu or dialogue in kcontrol would take it well on the way to configurability
-- Nobody who doens't like the new options need even look at them or do anything other than agree on the default KDE settings. So these people are better off than now, while many others benefit.
And,
-- If two peoples' setups are so different they can't use each others' desktops, why a problem? Users should have their own settings as best suits them. So, please don't reject on grounds of splintered KDE - it is much more important that every user should not have to be bugged by hated styles of menus and so on that that every menu should be the same for all users.
-- This suggested system is not very different from the initial "unix, kde, mac" options currently used - these also set fine controls to preset patterns. It just adds menu/dialogue configurability.
Please comment/modify/tear-up-with-more-points/implement(!)
I do not care either way, but I wonder if this argument even happening in...any other language other than English!
Tim Vail
Some languages already did it that way before the decision was taken, some followed the decision soon after. But it's up to the translators.
First I am advised that the way that pop-up windows interact with tabbed browsing is a deliberate design. If you don't like this, please vote for my bug:
http://bugs.kde.org/show_bug.cgi?id=73361
You also might want to read some of the developer comments there.
The QA Team is starting. There appears to be an organized effort for PIM:
http://kde.ground.cz/tiki-index.php?page=Quality+Team+KDE+PIM
Some of this is at odds with the way that I have been told that developers work, so to start with, we can see how large the problem is.
It has come to my attention that the anti-TQM ideas are also embedded in the page titled: "A KDE Bug's Life Cycle":
http://bugs.kde.org/bug_status.html
Specifically, bugs need to be confirmed on the current release and they should not be considered to be fixed until this is confirmed on the next stable release.
So, I direct your attention to:
RESOLVED / VERIFIED / CLOSED
The bug has been fixed in the KDE CVS and the fix will be part of the next KDE release.
Does this indicate simply optimism or also ignorance? In any case it needs to be changed.
Also:
Priority
This field describes the importance and order in which a bug should be fixed. This field is utilized by the programmers/engineers to prioritize their work to be done.
The logic of this totally escapes me. Getting back to the WIKI:
The job of a Bug List Maintainer would be to review incoming reports, to try to reproduce the bugs, to gather missing information, to identify duplicates and to keep track of development in order to keep the bug list in sync with the actual development.
Absolutely correct! It should then be obvious that the "Bug List Maintainer*, not the Developer should determine the priority of bugs. How should we do this -- how should it be determined who is a Bug List Maintainer and which one is assigned to a bug? Will constructive anarchy work, or is some organization needed?
Someone posted that TQM had to be forced on people. Possibly, but the question is whether after it is forced on them that they ever want to go back to working without it?
But, first, we need to have some QA. And, to have TQM we have to have some method, it isn't sufficient just to say that everyone is responsible to test their own work since at the present time they don't do it and some of them don't even underand that they need to.
--
JRT
If you do not like the texts then please bug Bugzilla (http://bugzilla.org/).
Be careful that some of the texts were already changed in newer versions of Bugzilla, as it can be seen on Mozilla's:
http://bugzilla.mozilla.org/bug_status.html
Have a nice day!
I think that Nicolas' point is that BugZilla doesn't say the same thing:
http://bugzilla.mozilla.org/bug_status.html:
RESOLVED
A resolution has been taken, and it is awaiting verification by QA. From here bugs are either re-opened and become REOPENED, or are marked VERIFIED.
VERIFIED
QA has looked at the bug and the resolution and agrees that the appropriate resolution has been taken. Any zombie bugs who choose to walk the earth again must do so by becoming REOPENED.
I was proceding on the assumption that the KDE version of that web page was different because it had been changed.
--
JRT
No, it looks like being adapted because the version on bugs.kde.org is grossly outdated as you could easily see when checking the CVS entry. In general you should worry more about how people work regardless of some written "rules" barely anyone ever read instead thinking that "rules" and not thoughts somehow controls how people behave.
That being said you do have a point that all documentation on bugs.kde.org are not adapted at all, are rather quite misleading like in your case and thus shouldn't be linked to to begin with. Considering that I wanted to tackle it a year ago but didn't get to do so for whatever reasons you can blame me for this.
I don't want to blame you for this. Stuff on my to do list isn't getting done either.
My problem with it is that I was criticized for using my professional judgment in trying to maintain bugs -- I was told that I needed to follow the page which you say is somewhat outdated. I thought that a bug with over 100 votes was somewhat important so I raised the priority 1 step from Normal to High. My bad :-(
When you get around to it, do please consider the QA issues. Specifically, that a bug should not be considered fixed just because it currently works in HEAD. As the Mozilla page indicates, it is only fixed when a stable release is released that has if fixed.
--
JRT
I consider the status, votes, priority and severity fields as being independent from each other. Votes are popularity driven and a good way to show interested parties which issues are "burning" for the audience. Severity is completely technical and should reflect the, well, technical severity of the issue. Priority is a tool for developers to set how soon which issue should be tackled. Status is in my opinion the only part which should be handled also by a QA team, there is the currently barely used item VERIFIED which should be used for verifying that issues are solved for real on the user's level, and the amount of UNCONFIRMED issues need to be reduced as well.
Issues should continue to be marked FIXED when they happen to work in HEAD since otherwise you would need to go through all open issues at once whenever HEAD is being branched for a release, and we already don't have the manpower to handle the current amount wrt the UNCONFIRMED issues. Bugs FIXED in HEAD but not backported ideally should be mentioned as such though.
The description of RESOLVED/VERIFIED/CLOSED differ compared to the default in older and current Bugzilla versions because the text was actually adapted to how it's used by the KDE project (having no QA department in opposite to Mozilla) - so it's not outdated.
It was adapted to the few changes done to bugzilla in the week when bugzilla had been adapted as bug tracking tool for KDE. But it retained the rule set feeling from the original bugzilla page, and as such it's grossly misleading since it doesn't reflect how KDE's bug tracker is actually used and had been used since those adaptions had been done. Anyway I pledge to update it accordingly soon.