Klarälvdalens Datakonsult AB has released the first beta version of
KD Executor 2.0, our tool for testing and automation. KD Executor is a record and playback tool for Qt and KDE
applications. In addition, it contains a test environment which uses
this record and playback tool for testing Qt and KDE applications. We
are proud to release a free version (free as in beer, not as in speech) of this tool to the KDE community.
Why free as in beer and not free as in speech?
Klarälvdalens Datakonsult AB has always been very dedicated to Open Source
Software development, all of our employees are involved in KDE development,
and most have a record of open source involvement in the order of magnitude
of 10 years.
Much of our software is dual-licensed under the GPL and a commercial
license, and therefore it has been a great worry for us that we have
so far not been able to make KD Executor available under GPL.
We have reached the conclusion that this is likely never going to
happen, as this would make it very difficult, if not impossible, for
us to sell any commercial licenses, but fortunately we have found a
way to still make it available to our fellow KDE programmers.
To use it you need to set a license key (the version will expire in three
months at which time the final 2.0 version should be released; that
version will not be time-bombed).
To use this key, put the following lines in your .zshrc or equivalent
export KDABEvalKey=69e9ec5ff9e9689c
KD Executor mailing lists
Those of you with an interest may wish to join the mailing list dedicated to KD Executor discussions.
Comments
Well, the "unspoken assumption" you mention is actually part of the meaning of the word "gift" at least where I live (Germany). Words (luckily) seems not to be watered down that much here, so for instance one isn't allowed to make ridiculous offers like "buy two, get one for free". "Gift" with the purpose of getting hidden gains to the donor are called "Nepp" which is a very negative term (closest translation would be "rip-off").
Also while discussing about "gifts" even with the extended range of meanings the term apparent has in English people should keep in mind that KD Executor is meant as a tool easing the testing of apps during development, so the whole "clueless children are lurked into a trap" freedom-rip-off case doesn't apply, neither are normal users a target nor does this app add a hard dependency without which a project would die.
The only valid issue I see is what's going to happen to KD Executor in the theoretical case of bankruptcy of KDAB, David Faure mentioned above they'll look at this issue and I trust them to find a good solution for that as well.
Hi Eric,
very well said. I think there is nothing much to add. You are doing a great job explaining the background and have the authority.
That said, you likely agree that nonetheless, either Trolltech themselves or KDE will come up with something like the too anyway.
Everybody would have to admire the easy reproducing of bug reports and integration into KDE. Somebody in the community will want to replace it with something free sooner or later anyway.
And that said, thank you for the tool. It's a help NOW.
Yours, Kay
It says exactly why it will not be GPLed, because you cannot sell GPL software for the software itself (not the support). Since anyone with the first GPL copy is free to release it and give it to others. It doesn't make sense commercially.
I think the anti-commertionasim attitude in the "open" source community is immature at best. Remember that those people working in the company need to pay their bills and support their family, GPL doesn't give them that.
The only (or main) method to generate income from a GPL software is from support/training contracts. To suggest some company can sell a GPL software for the software itself is a complete joke.
For some people, to suggest some company can sell software for the software itself (open or closed) is a complete joke. That people see pure software companies as an anachronism.
And it's also entirely unethical, of course :)
To be blunt: I couldn't care less if it's open source. If it is useful I will use it. If someone writes something that does the job decently that is open source then I might switch.
The problem with GPL-ing a tool like this is that people would use the GPL version and not pay. It's not like a library where it is linked into the distributed code, so there is no way to prevent people ripping you off.
...and to be blunt: "Value your freedom, or you will lose it, teaches history. ``Don't bother us with politics,'' respond those who don't want to learn." (RMS, http://www.gnu.org/philosophy/linux-gnu-freedom.html).
Yeah, but I don't think open-ness of code is a moral issue. It's nice sure, but hardly essential. I use the GPL and LGPL because they're convenient, not because I agree with RMS and philosophy.
...and to add something to it: "Value your friends, or you will lose them".
You are either from outside anyway or you have no idea how misplaced you sound by stating this kind of quotes.
How does this compare to Squish (http://www.froglogic.com/squish)? Do they compete or complement each other?
I've had similar functionality for a while now. I started implementing the
event trail record/playback functionality back in 2001, or maybe earlier.
It is rather easy to trail-enable each Qt application. Basically all you
have to do is inherit QApplication and override the notify(..) function.
There you can watch for events that are directly generated by the user,
such as mouse moves & clicks, keyboard presses, window resizing,
wacom tablet events, etc... The events that are directly generated can
be saved to a file. Later, the application can be rerun and play back the
saved events, thereby reproducing a crash or whatever. I use this all the
time in the program I am working on.
Check it out if you care (Please don't kill my DSL line)
http://www.aragog.com/~paul/homedir/cxx/bernstein/the_trail.hxx
http://www.aragog.com/~paul/homedir/cxx/bernstein/the_trail.cxx
Paul.
This looks interesting, I'll check it out.
Guys, if you don't believe in the GPL, at least have the guts to say so. No one's convinced by this "we wanted to, but just couldn't" approach. Everyone releasing Free software weighs the pros and cons. The difference is that some of us aren't as self-motivated as others.
I'd like to remind you that KDAB provides two of its commercial components, KDChart and KDGantt, as GPL libraries.
For libraries it's quite doable, to release them as GPL, and sell it for commercial application developers. Everyone wins.
But for an application? If KD Executor was GPL, we wouldn't sell it at all anymore. The GPL doesn't make any difference between "using the tool for free software" and "using the tool for commercial apps"...
So don't give me "you don't believe in the GPL" or "self-motivated" arguments.
Apparently you are one of the few people who work on free software all day, all week and doesn't care about eating and paying your rent? Yeah right.
It's quite funny to see someone question the self-motivation (related to KDE) of Kalle (president of kde-e.v., kde developer since the very beginning)
and his employees (we're all KDE developers!).
Well, I think that saying that a company like Klarälvdalens Datakonsult doesn't respect the GPL, given their track record of KDE development, is rather crap to be honest. Software has to be funded and has to have a working business model - whether through a community effort or through a licensing type approach.
For this reason I hope that Trolltech never LGPLs Qt for any reason whatsoever. They could think about a small developer addition, but if I'm developing my own proprietary software I want to make sure Qt continues to be really actively developed.
The problem with testing GUI apps isn't in being able to push the buttons automatically. It's that there are an almost infinite number of possible combinations of button presses. Recording a particular sequence of presses solves very little of this issue. You either need to push every available button in every possible window in a random manner, or you need to release it to a large audience with random intentions.
I agree that it'd be a lot of effort to cover a GUI app thoroughly
using those automated tests. I colleague of mine has a similar
problem testing a web app.
But I still think it is a useful tool:
- It ensures that the normal functionality is in order.
Grave errors will pop up early.
- Every time a bug from bugs.kde.org is fixed a new test could
be created to "prove" it and to make sure it stays fixed.
- It's probably helpful during debugging if a bug is reproducible
but requires a lot of steps to do so.
When I see flamewars like this I'm none too happy about the future of free and proprietary software. We aren't going to see free software absolutely everywhere and proprietary software developers must realise that they do not have a divine right to sell software. If there is demand for a free version, there will be one, no question about that. Software does need to be funded, whether that is with money or with spare time and hard work. It isn't free, but people only ever see the money.
I'm rather disappointed that people cannot use a bit of software without thinking that there is some massive conspiracy theory, and it doesn't make me hopeful of the future. Do we want software companies to write proprietary software on KDE, as an extension to the great free software we have?
No.
Of course we do.
Would you rather they keep developing software on Windows?
I'm happy everytime I see a new commercial product for KDE. It proves KDE is a good desktop, and good development framework.
### I'm happy everytime I see a new commercial product for KDE. It ###
### proves KDE is a good desktop, and good development framework. ###
I fully agree.
Regarding "aKaDEmy", I am thinking of even including a special section/track
into the 2nd weekend ("User and Administrator Confernce") sessions and the
related Call for Papers to highlight such "ISV" commercial product developments
using Qt and/or KDE. There are lots and lots of them, we just need to get a few
to showcase their products during the event with a presentation to make the
public more aware of it. It would also help to present Linux in general as
a viable desktop system.
I hope there will be some submissions covering this aspect once the CfP is
out. I hope each of you who has personal contacts to ISV Qt/KDE developers
will appruach them in person and point them to the CfP....
Well I can tell you that I would love to see more proprietary software written with Qt and for KDE. Qt is a fantastic development toolkit, and hopefully, with all the great freedesktop stuff like QtGTK etc, and a way of making Java apps fit in we will have development options in KDE for more than just Qt.
"Would you rather they keep developing software on Windows?"
I develop on Windows, and frankly, I'm looking to see the back of it at any point in the future. When Longhorn comes around we are going to see many companies faced with a difficult decision about where they go, and they are going to be forced into that decision. It isn't going to be pretty, and it isn't going to do the IT industry any favours but it needs to happen. I hope there will be great free software alternatives with the ability for sustainable and sensible proprietary software to thrive.
I think KDAB has done a great thing by presenting KD Executor as a gift for OSS. I know that the tool is proprietary, yet as long as it is used to make OSS I would not mind. The most important goal is to improve OSS like KDE, hwo you get there is less significant.
I also think we can trust KDAB. As David Faure has said over and over again, the company is composed of KDE developers, there is no reason for them to act against KDE. Event he president of KDAB is the president fo KDE e.V. so there is nothing to worry about yet. My only concern is about the future, what if the company goes out of business, what if it has an ownership or so many more people are hired that only a minority is composed of KDE developers. These are the fears everyone has when there is a commercial entity. Therefore, I STRONGELY SUGGEST that if KDAB wants OSS to stop being reluctant on using their tools simpyl because KDAB is a proprietary company they should make a pact which states that OSS will ALWAYS have free acess to KD Executor even if ownership changes. Also, if the company goes out of business, KD Executor needs to be released as OSS. (LGPL, GPL, BSD?) I am aware that this would mean that the president of KDAB would be signing a pact with himself and much of KDAB would be signing the pact with themselves, yet this is the only way to be able to fully use KD Executor and maybe even establish a framework on it with no worries.
Or maybe the easiest thing to do is just to release KD Executor under a dual license as Trolltech has done for Qt. GPL for OSS and proprietary for proprietary software. If the company goes out fo business or changes ownership in the distant future, there would still be the GPL version. THIS IS THE PROVEN METHOD TO WORK and BEST FOR BOTH WORLDS. KDAB will get much more publicity, testing and widespread use of their tools while KDE developers will get better tools to make KDE releaseas of even higher quality.
THAN YOU AGAIN!
> Or maybe the easiest thing to do is just to release KD Executor
> under a dual license as Trolltech has done for Qt.
> GPL for OSS and proprietary for proprietary software.
I'm afraid that model doesn't work here.
There's an essential difference between Qt and KD Executor:
Qt is a library that is *linked to* when creating products.
A company needs to buy a commercial license in order to
write closed-source software (== income for TT).
KD Executor *is* a product that can be *used* without such restriction
even to auto-test closed source software (== no income for KDAB if it were GPL)
To make it more clear:
There is no such thing as a "GPL for OSS".
It's either GPL or it's not.
The GPL does not discriminate against the *use* of
GPLed tools in closed-source software development.
Imposing such an *additional restriction* would itself violate
the GPL and would thus create tons of new license problems.
A license that is the LGPL but only if the code it is used to test is open source. Or would that be relying too much on people's honesty? That would be impossible to enforce I guess...
Then that wouldn't be the LGPL. You can't add additional restrictions to the license and still call it LGPL, and by the FSF's definitions it wouldn't even be Free Software with your suggested modifications.
We have a bunh of free equine orthodontists in the house!
This thread just pissed me off. Ergo, I intend to write a tutorial on the use of this thing as soon as I come back, and evangelize its use to hell and back.
Whatever it is that this thing does ;-)
How pissed are these free equine orthodontists? Do they just get their kicks by complaining about stuff, or are they willing to put their money where the horse's mouth is? If the latter, I am willing to create (or help create) an open source testing and automation tool, if people will pay me to do so. And to avoid all "GPL is hostile to business" arguments, I would release it under the BSD license. If you're serious about your concerns, contact me off-forum.
could kdexecutor be used to automate the generation of screenshots?
i guess, it would need some sort of "break point" support or something like that
hhm...