OSNews

I'm afraid it's my fault, I've started to infect others with that stupid spelling mistake ;-)

thats the beauty of open source. even if the features gets officially put in, anyone can add them on their own.

with proprietary stuff its wait and pray, with open source one can either wait, or go do it yourself...

I'm starting to learn C++ programming tomorrow so I can customize KDE features.

So where do I go to get started? Will one of those "learn C++ in 24 hours" books do?

How long you figure before I can start submitting patches? Couple weeks?

> So where do I go to get started?

once you get far enough along with your c++, there are great tutorials that come with Qt itself and then there is techbase.kde.org for kde stuff on top of that.

can't wait to see your patches when they appear =)

You may want to start with a Qt specific book rather than a generic C++ one. I've heard good things about this one:
http://www.nostarch.com/frameset.php?startat=qt4

Techbase also has some good tutorials and examples to walk through for some more KDE specific code.
http://techbase.kde.org/Development/Tutorials

I'd recommend using C++ GUI Programming with Qt 4 by Jasmin Blanchette and Mark Summerfield.

Their examples got me up to speed, and I still keep it at arm's length from my computer at all times.

Also, I'd recommend against buying a generic C++ book, because C++ is a _very_ complex language, because there are lots of things that Qt makes easier (even for console applications) than using plain c++, so for a beginner, I'd say jump directly to qt.

(Disclaimer: all my homegrown c++ apps use Qt, even if they're console ones. I can't stop using it, it feels too good =D)

I totally agree. C++ without Qt is more or less terrible. I made several attempts to learn C++ from a pure C++ book and the examples are just incredibly tedious to work through. Start with Qt, and you won't have to suffer through the crap that is plain C++. It really is a completely different beast.

Unfortunately, a lot of people have been scared off by C++ because they used it without a good class library like Qt.

Actually one of the reasons why I started visiting programming courses on university - beside my boring and unfulfilling BA study... - is that I also wanted to improve programs I use regularly - not to forget I like to fiddle about problems. And after all why not give something back when you've taken so much?

Though this semester we are only using C with only so little libaries and man that sucks. I know a little C++ (made it nearly through hat learn C++ in 20 days book in the summer) and that's a lot more comfortable.

Reading so much positive things about Qt (on planetkde e.g.) makes me curious.

I won't have time in the next months though.

Go to #c++ on irc.freenode.net. They will explain to you why "learn C++ in 24 months" is somewhat more realistic ;-)

Damn, so I will not be able to fork KDE in January if I don't like the new design?
But seriously, 24 months seems kind of long.

this looks like top quality sarcasm, but given the serious responses i start to having some doubts..

But how many actually do?

There's all this talk about open-source and how "anyone can just add/fix this!", but in reality, everyone waits for the devs of the actual software to do that.

If the original devs/maintainers aren't the ones doing the fixing/adding, either the original software has to be forked and re-released, or everyone has to wait around until they approve a patch and release a new version themselves.

Well, we're quite a few sitting here and there, patching the life out of firestarter to keep it working with the newest kernels - all because development has come to a halt and no response from devs. So we do it ourselves.

Of course most people will wait for somebody else to do things - it's so much easier. But open source _does_ give you the option to do things. The fact most people don't want to is completely irrelevant. The important thing is that those of us who cares have the option to do so. And we have. Great, ain't it?

> If the original devs/maintainers aren't the ones
> doing the fixing/adding, either the original
> software has to be forked and re-released, or
> everyone has to wait around until they approve a
> patch and release a new version themselves.

that's not particularly how it works. patches get submitted and are picked up based on their merit. it really doesn't matter where they come from. nor does patches submitted lead to having to wait longer for releases.

please consider the actual history of the kde project in this regard and you'll find that your assessment is just a chicken little scenario.

At least, you can hire them (or anyone else who want to). No legal barrier as proprietary software.

> Let's hope that the KDE devs
..
> let's also hope that

let's not hope, let's do. you can help by providing specific feedback with specific solutions.

And that on my birthday! Cool .

http://youtube.com/watch?v=yj6cbM-h8xg

Happy Birthday, Thom!

Double congratulations then

What did you win? Wasn't it something with beers?

"Does this mean feb for proper polish?"

No, it still means 4.1 for PROPER polish.

Edited 2007-12-01 21:46

"proper".. what an ill defined word. it makes your queries and statements really difficult to respond to. =)

ok then, by proper I mean a proper release date, we can quiet clearly seen KDE 4.0 is not ready for release so you KDE devs should, so why set unrealistic dates?

> by proper I mean a proper release date

when you are ready to discuss specifics versus yet more generalities (i have no idea what a "proper release date" means to you, nor do i think you probably have the context to make such an assessment to be honest) then we can start having a productive conversation.

speaking of condescending feelings, did you ever figure that the menu designers figured what should go in a menu?

I'd hate for KDE4 to end up being compared to Vista (or Leopard, for that matter) in the arena of 'unpreparedness'. The kommunity has produced incredible work so far, no reason to believe they can't do it again.

Edited 2007-12-01 20:43

The "RC" looked and felt completely unprepared.

i know that most people on the receiving end of the release completely lacked the context needed to understand why an rc release was done. i'll be on the linux action show in the next week or two explaining a bit more about that context. perhaps you'll listen in and discover another perspective on things.

I'm sorry, but a Release Candidate is a candidate for release. KDE 4.0 "RC1" is in fact another beta, rather than a pre-release without apparent bugs.
It's OK to do pre-releases with obvious flaws. That's what pre-releases are for, but please don't call them Release Candidate.

Edited 2007-12-02 16:25

> That's what pre-releases are for, but please don't
> call them Release Candidate.

i'm sorry, what part of "[you lack] the context needed to understand why an rc release was done" was hard to understand? simply restating your position doesn't suddenly give you that missing context. seriously, tune in to the show when it's released and *then* comment on things further.

the testing cards seems to get played a lot when there is opposition voiced towards changes related to usability.

in many ways its a bit like reductio ad hitlerum for gui debates...

> testing cards seems to get played a lot

yes, it's absurd that actual data is used instead of just personal musings. maybe that's what's wrong with all the various fields in science. repeatable experimentation is such a silly idea.

</sarcasm>

seriously though, there are aesthetic issues to take into consideration, there are general usability principles to keep in mind ... and those are augmented by testing.

having people offering personal opinions on a whim really doesn't help much. it just leads to a cacophony of equally valid statements with no way to measure what makes for a good solution.

it may be more "fun" to just to sit in an armchair and expound randomly, but .. yeah .. the software stands a better chance to improve this way.

:D

while this might be true, things that shouldn't be in a menu (favorite aps/places i.e.) are put in a menu... perhaps it's done in the most optimal way to put it in a menu, but did any of the menu designers figured that these things don't belong there in the first place?

Why not?
Where's the part of the 10 commandments that says "thou shalt not put bookmarks in the Kmenu; they're fine in a bookmark menu though"?

I think allowing people to put places in their menu like regular entries is a no-brainer, and it's just a minor leap from there to having categories for all apps, favs and places.
I really don't see how having those buttons at the bottom of kickoff will confuse anyone or how it is a major hurdle to usability, because if you don't use any of the buttons apart from the "applications" button, they won't slow you down in any way.

What I don't like is the "change levels in situ" part. My resolution is 1280x1024 and the (thoroughly oversized, too many apps... =) Windows start menu uses almost all of them to display all those tools. Kickoff otoh uses just that single column. Oh, I can enlarge it until it at least doesn't waste all that vertical space, but making it wider is just a waste of pixels because it doesn't give you additional information.

Due to larger and larger displays and more and more being widescreen that's a complete waste of space.

I fear Razor's gonna be even worse. All the stuff I've seen about it talks how it keeps the distances your mouse has to travel down. WTF? Taking the mouse cursor from one corner of the screen to the other takes a fraction of a second, actually finding the menu entry you're looking for is generally much more time consuming and having to look at half a dozen menus with 5 entries is bound to be a lot slower than one larger menu (well organized, with categories the same way Dolphin can group by first letter) with 50 entries.

That said, I'll probably keep using Alt+F2, so what do I care?


EDIT: Let me add that I don't think the article was particularily condescending. It didn't belittle those of a different opinion.
It explained that they had to replace kicker and had to make a choice between keeping the old style menu that was kind of a mess, coming up with something new while -as the delay proves- they were already short on time, or use a design Novell spend a lot of money on and that unlike all possible competitor got actual usability testing and did well in that. Which one would you choose in that case if you try to look at it objectivly?
It also mentions that plasma will make it easy to do a relatively primitive menu like the old one (primitive in the sense that it's static with no bling) or other alternatives and in fact there are already a number of those in development.
KDE's motto's always been "he who codes decides" and SuSE had the code =)

Edited 2007-12-01 22:37

The part about wasting space by having just a single column was spot on.
But you should have said the 10 Kommandments ;-)

the kickoff menu discussion is ended with: "there's been thoroughly user testing"

Guess I can skip reading this one then. That horse is so dead. [joke]Besides, I already know why they made each and every change: to annoy me personally[/joke].

thats the beauty of open source. even if the features gets officially put in, anyone can add them on their own.

But how many actually do?

I used to. I had a patchset for Konqueror I maintained for personal use from about 3.3 on that corrected several behaviors I wasn't enamored with. People actually do that sort of thing. I also did it with Litestep back in the day. I don't think I'll be continuing though. Better things to do with my time. The whole job and responsibilities thing.

If anyone wonders, at least one of the behaviors addressed by my Konqi patches was brought up in a bug report, and ignored like I would have expected. One other I remember was a deliberate design decision. Perpetually maintaining patches as the underlying codebase changes gets old. Probably almost everyone is just going to deal with how things are.

So yeah, some people actually do that stuff but if my experience means anything (and it does for me) it doesn't last long. In my case I'm starting to look elsewhere.

*meandering slightly off topic. Not entirely, but one can ignore the following*

It's not just the little things I don't feel like patching anymore. It's that other people also have that "jobs and responsibilities" thing I mentioned earlier. I'm sick of wondering whether software I use frequently is going to get ported over, or further maintained at all. My latest example is Klibido (binary newsreader): basically unmaintained for a year. Relying on volunteer labor keeps leaving me up a creek. In contrast, I'm fairly certain Unison (on OSX) isn't going anywhere.

I love the principles of free software and I used Linux exclusively for about 4 years. I'm not dropping it now but I just don't feel so strongly about expending time and effort and passion getting it working like I'd prefer, or even just working, and KDE4 hasn't helped. That's my thing though not theirs. Hah I'm giving the "it's not you it's me" speech. It feels like a breakup in a way.

Ironically I'm typing this from Konqueror.

Edited 2007-12-02 01:42

There are two different concepts here. You claim to be supporting proprietary software but what your arguments actually support is commercial software.

For example, MySQL is free software maintained by a company; as long as that company is doing well, it's not going anywhere. I suppose you mean the same with Unison: as long as it's profitable, you'll be able to use it. Let's not ignore the possibility of these companies going out of business.

Non-commercial software can stop being maintained when the developer loses interest. That applies to both free software and proprietary as well, and it can happen as non-commercial is often done as a hobby (there are other categories though, like academic, etc).

In both cases, the difference is that free software can be picked up by anyone interested, which is not the case for proprietary software. If Unison's developer goes out of business, you're screwed and will have to stop using it eventually. If the maintainer of Klibido loses interest, you're only screwed if nobody else steps up to the plate, and it could be anybody really. It's not uncommon to see free software changing maintainers.

> my Konqi patches was brought up in a bug report,

do you have a br#?

> and ignored like I would have expected

the implication that bugs as a generality get ignored is overly broad and not ime correct. there are two types of bugs that get ignored: those filed against products which are over-reported on already given the # of people working on it (khtml comes to mind) and those that are simply filed poorly.

> I'm fairly certain Unison (on OSX) isn't going
> anywhere.

if we ignore all the successfully maintained mainstream free software and all the abandonware in the proprietary world, i could perhaps agree. i just don't like ignoring reality like that, though.

Let me give you an anecdote that really hits me where I live:

I do software engineering for environmental modeling. A typical year will see me writing upward of 100K lines of (mostly open source) environmental modeling code. That puts me on a variety of systems from IBM, HP, Sun, SGI, and others, many of which run some UNIX variant and not Linux. My desktop *is* Linux. I want a common programmer's editor across all of these platforms, and don't really want to have to deal with Emacs. That pretty much means "NEdit" is my only choice.

KDE klipper's non-standard behavior pretty much breaks NEdit, whether I'm running it locally or running it remotely and displaying back to my desktop. You can search the NEdit developer archives and see just how many times we have complained about this behavior, even quoting chapter and verse from the X11 standards to the klipper maintainers, and either been ignored or told, "We don't care; we'll do it our way anyway."

And for that matter, kdbg's lack of support for Fortran is an obstacle as well (and RedHat's announcement that they're EOL'ing ddd because of OpenMotif, without providing any viable alternative, does not endear me to them, either!)

This -- condescending! -- attitude does not endear me to some of the KDE developers. Particularly since I'd otherwise greatly prefer KDE to Gnome or other alternatives.

FWIW.

Why are you running klipper if you don't like it? It's completely optional. For most people it works just fine, and goes a long way to fixing the broken linux copy/paste support (like being able to paste content from an app that is no longer running), but if you don't want it, just right click on the icon and choose quit. Not so hard. I haven't heard of any other apps being broken by klipper, so I suspect NEdit isn't completely blameless here.



What the heck. So you're missing a feature, and the devs consider it low-priority. How is that condescending? There's just limited manpower.. not every feature can get done.

Well, for me, Klipper is great - the X11 copy behaviour sucks, and klipper goes a long way to fix it. The fact that it doesn't always works perfectly I can live with - until the X11 protocol gets fixed.

If you can tell me of another tool which does what Klipper does (have a clipboard history, and keep stuff in memory even after the app is closed) please do so, if not, fix X11 or Nedit, not Klipper.

From a quick google, it seems that nedit tries to set the clipboard to empty. That is what causes the problems. That is not standard behaviour for clipboard use. (At least, I've not seen any other app do that).

It sound like the nedit developers should fix that problem, or you should simply configure klipper and untick "Prevent empty clipboard".

Problem solved.

Sorry, but most science is based on empirical and repeatable experiments. You are right in that such experiments can't tell us what the most usable interface would look like, but they can certainly can identify differences between certain approaches.

As for saying that the test result only apply to test the actual test subjects, there have been studies on this. Read any book of Jacob Nielsen or some other auther dealing with usability engineering and they will tell you that you can get very good and repeatable results, with less than 20 test subject.

There are also a lot more sophisticated ways to measure usability on test subjects than just doing a survey. You can use eye movenent tracking to see what part of ths screen that first catches their attention, you can use EEG to see what parts of their brains that are active in different stages of interaction with the system.

All of these methods may be a bit too expensive to most open source developers, but there are also cheaper ways one example is the "thinking aloud protocol" method where you ask the test subject to describe how he thinks when he is using the interface, when he reaches something difficult he will have a hard time both talking and concentrate on what he is doing, and as a result he stops talking, and you have identified a problem.

You can also apply usability technology to help you before you build your system. E.g. you can use "Card sorting" to see how people relate different concepts.

However, you are right in that the answer to the quesiton which system is the most usable usually is "It depens". More specifically, it depends on the intended user and the intended use. What's usable to Linus Torwalds doing programming, is not necessariluy so for the average accountant performing his work tasks.

To some extent you can remedy this by configurability, but then, you have the problem of chosing sane defaults. Geneally such default should be aimed at the least skilled users that you expect to use the system, as they are the least least likely to be able to configure things.

Usability is even more complex than the usability goons like thom would have you believe. Not only do users not know what they want nor how to express it (thus invalidating what they say), the usability goons who do their studies are also a point of failure in their design and interpretation of experiments. If this is obvious to you, stop reading.

Part of the problem is that usability goons are usually computer scientists rather than biologists, so they try to fit everything into a math equation which doesn't completely represent physical reality. The other part of the problem is that usability is a young science that is sometimes practiced poorly by young and inexperienced people, thus leading to the ridicule you see above.

The Novell study in question (that redesigned the Microsoft Start menu) isn't a guaranteed universal optimality. That is another problem that makes a usability person a goon. They do a study and think they've hit upon the word of God. Well, get 999 other teams of people from around the world from different backgrounds to design what they think is the best PC user interface, and you're going to get some different words from God. And hey, some them might not even copy the Microsoft Start menu!

For your information: I've modded you down for generally insulting usability people by calling them "goons".

For your information: I've modded you up because even though OSNews comment scores are meaningless to me, I know YOU care, so maybe I've made your day.

Actually, I doubt that most usability people have computer science background, most usability people I have come across in my work have informatics, or psycology background.

As I see it, the biggest problem, at least in the FOSS world, is that coders have a very hard time accepting that people that can't write a single line of C++ actually can give valuable input to their projects.

As for the results from the Novell studies on the start menu they were quite predictable, and I actually expect that you will get similar results if you test on randomly selected accountants, lawyers, nurces and doctors, and other people that have a work outside the field of computer science, system development, or system administration.

First of all, most of them will be used to that kind of interface from Microsoft, Not having to learn something new and being able to resue old knowledge is part (but not all parts) of usability. Second, we can see how people behave on the web as its complexity have increased over the years.

In the beginning of the web age people used tree structues (e.g. that of yahoo) to manually navigate to the right page. Today the web is more complex and we see another behaviour. People google for the info they need and then they bookmark what they find useful.

As the operating environment of the desktop gets more complex (e.g having more programs) it gets harder and harder to make a cognitive map of the system or in ohter words, just like in the web case, the tree structure gets to big to grasp, and a search and bookmark strategy becomes much more natural.

Most usability people will also tell you that if you got a menu with more than six or so menu intems, people starts to read the menus instead of relying on motoric memory to select tha right choice. This reading process is much more time consuming. This is one of the reasons why the old K-Menu was far from optimal, especially as most users will never use all the programs that was/is installed in it.

There are of course other factors that may lead to other conclusions. E.g. if you run your tests on a slow machine where the Novell menu appers too slow, may appear very stressful to the user. But in general I would think that the Novell studies will be repeatable.

This is not the same thing as sayin everything should be done the Microsoft way, but for better of for worse Microsoft have done a lot to define the users expectations of a computer desktop.

> usability goons

poor form. really.

> users not know what they want
> nor how to express it (thus invalidating
> what they say)

apparently you don't understand how this works then. users are put through tasks, observed, recorded and then the results are interpreted, based partly on the user's feedback but also on interpreting that feedback and the context of their actual actions. it's not a direct user feedback channel. we already have those: bug trackers, mailing lists and irc; there's a reason we are augmenting that with actual testing.

> also a point of failure in their design and
> interpretation of experiments

of course, as is any experimenter with relation to the experiment. however, this does not mean that every usability tester is the cause of a failure, anymore than the fact that a physicist conducting a physics experiment is a possible point of failure means all physics experiments are therefore no good.

this is, of course, why we have peer review. which implies actually reviewing the experiment. not hand waving generalities where you insult others and elevate yourself.

> a guaranteed universal optimality

obviously. that's why increasing the data set often helps. however, standing on the side and going "woah! the collective results of an experiment that was repeated across a representative cross section of users leads to a given conclusion, but that may not be the only conclusion!" without providing your own test data is not helpful. the way the scientific method works is by presenting new data, not saying that there might be more data therefore the current data sets should be ignored.

> to design what they think

yes, i'm sure we'd get variety. that'd be awesome, and something i've allowed for in plasma. however, if you think usability is about "designing what person X thinks", then you've missed the point.

I like everything you've said except the part where I don't know how this works

I've found usability to be a poorly practiced science. That was the impetus and message of the rant. The rest is just hot air.