In this week's episode of LugRadio KDE developer Aaron Seigo discusses usability, freedesktop.org, groupware and Get Hot New Stuff. Start 28 minutes in to hear him debate with England's most famous non-KDE users.
The Lug radio guys seem to be pretty one sided, but Aaron came across well (much better than the interviewer, it has to be said). One thing he didn't mention however, is that most of the commonly used freedesktop standards are based on KDE specifications and implementations in the first place. For example:
- The .desktop files (based KDE's .kdelnk specification)
- The system tray protocol (based on KDE's tray protocol)
- DBUS, based on DCOP
Others developed elsewhere have been in use in KDE for years:
- XBEL (used since KDE 2.1)
- XDnD (used since KDE 2.0 IIRC)
It should however be noted, that just because a proposal is on freedesktop.org doesn't make it a standard, or even a good idea. There are (and should be) both good and bad ideas there, and the desktops can vote with their feet.
(Note, I know I've posted almost the same thing on OSNews - they posted the same story).
Thanks a lot for the topo.
The site is prettily hit right now. So no avail. This is one of those situations where speach2text would be a wonderful tool to have. What do you say? You're quite experimented with text2speach. Do you think that just dividing 1 by all the variables presented in festival would give the inverse code? ;-)
Well, the typical tts program sounds like a dalek, and the typical stt program requires you to talk like one.
I'd say yes :)
And they're rude, trying to interrupt Aaron multiple time (not mentioning stopping the interview so early ....)
Bah.... frustrating :)
nah, i don't they were being rude.. it's just the format of the show really: a big open chat. like a night at the pub. only more sober.
No I don't think so either. Yer, OK everyone thinks that they're pro-Gnome, and they are, but you should have heard the interview they did with Miguel de Icaza a few weeks ago. They didn't exactly give him an easy ride - especially the Python guy! When he came up with the 10 most popular Mono apps on OSNews thing they pretty much laughed at him!
all very good points Richard ... unfortunately there was only so much time and we covered a lot of topical ground so it wasn't possible to fully examine any of the topics really; just the nature of the format... thank goodness for web forums.
wait. did i REALLY just say that? ;)
I don't suppose anyone has a mirror? :)
I've uploaded a copy to a high-bandwidth server, for the greater good..
Perfect. Thank you.
Is there a transcript available?
I think we can assume no.
The interview was ok, it's great to hear Aaron's thoughts on these things, but the more I listen to this episode, the lower my opinion is of these guys.
They think KDE 4 should be rewritten from scratch? C'mon.. I thought these guys had jobs as developers. They should know better.
KDE will be forked? Eh? By who? I haven't heard of any actual developers being that dissatisfied with the project.
Kolab is bad because it interoperates well with KDE? What kind of inane complaint is that? I'd rather complain about the lack of marketing for Kolab.
On the other hand, they admitted some of their complaints about KDE were born from bias or based on old versions, so that's a start.
Thanks for the interview!
> Kolab is bad because it interoperates well with KDE? What kind of inane
> complaint is that?
It's kind like how Microsoft application interoperate with only Microsoft applications.
Sorry for spreading any FUD.
Okay, for a start, only one of us works as a developer.
Secondly, we were just discussing the ideas of whether it's a good idea for KDE to be rewritten, or forked, or whatever.
Thirdly, we never said Kolab is bad because it interoperates well with KDE. We said it may not have had the publicity it deserves because it hasn't been marketed well and perhaps because it *only* interoperates well with KDE (which may be a misunderstanding on our part).
It was great to get Aaron on the show. We are all Gnome guys, it's true, but at least two of us started out as KDE users. We don't give anyone an easy ride - we see our job as asking the questions that Linux/open source users want to have asked. Aaron made a great contribution - thanks Aaron.
hey Matthew =)
re: Kolab.. yeah, i sent an email to Jono about that. and a million other things. heh ;)
it's not easy (impossible?) to keep up on top of everything and get all things accurate. i mean, that's why shows like LUG Radio exist, right? if everyone knew everything and we all agreed perfectly on all things.... what a boring life! ;)
and yeah, i enjoyed being on the show. great fun. hope to do it again sometime. thanks for the opportunity to be a part of it all =)
Fair enough. Sorry, I get riled easily :D
Thanks for the show.
they also discuss rewriting gnome in an interpreted language. no need to take offence.
they bash eachother aswel, have you heard their ongoing ubuntu vs fedora topics
You did a great job. You sounded reasonable and professional. The questions asked were so ridiculous that one wonders how you contained the laughter.
1) Should KDE be re-written from scratch?
Other questions were of the "when did you stop beating your wife kind?" and you were very good at exposing the bias in those questions and in a tactful and professional way.
Ps: Somebody should go back and listen to Nat Friedmann on lugradio. He comes across sounding "like" a valley girl -an 80s concoction of silliness and bad hairdo that was "like totally" silly.
Yes, he really did a great job handling some of their more "interesting" questions. Starting from scratch for KDE 4... I guess they're just used to the GTK way of doing things.
And thanks for the amaroK shout-out. :P
We've never interviewed Nat Friedman :)
Nat Freidman was interviewed on the Linux Link's 'Tech Show.' Which you can listen to at http://www.thelinuxlink.net/tllts/
They also have interviews with Doc Searls, and some others.
I listened to Aaron's interview with great interest, and I thought he came across very well. Even the lugradio presenters were impressed judging from their comments afterwards. Great stuff!
Re the Nat Friedman LLTS interview: I'm listening to it now and I'd have to say I don't think you're being very fair. He sounds like a smart guy, and some of the ideas he talks about are quite interesting (eg. text messaging interface to your appointments - probably not a brand new idea, but a simple and potentially very useful one).
uses GTK2... is goddam slow an has a size of !110 MB! (unstripped)...
Honestly, I was hoping Adobe uses Qt for a new release of their reader for Linux... Now it's GTK2
The new Kpdf is great, I won't need acroread for most pdfs. But more and more pdfs are made to fill out forms (this will eventually gain even more importance when there will be more "e-government")
I was wondering, why there's no discussion about this on kde lists... I'd really like to hear some opinions about Adobe using GTK2 despite they're obviously already owning a license of Qt.
as i understand the situation, Adobe has only one developer who works full time on the Linux/UNIX PDF reader. this is completely word-of-mouth, but from people that i generally trust, and given market share of Linux/UNIX desktops this makes sense. so the choice of toolkit was probably down to "what does Fred know the best and feel most comfortable with?" (i don't know if his name really is Fred, "he" might be Lisa for all i know =P )
however, i wouldn't blame the speed and size on Gtk+ alone. if you look at the app, the developer uses Gtk+ for things like menus, utility dialogs and (presumably) event handling. but everything else is hand-rolled. he doesn't really use many of the Gtk+ controls in the actual application itself.
i'm not sure why they chose this route. perhaps they simply "ported" the old Motif code over hoping to slowly transition it to something less ugly and as time goes on. perhaps the developer is simply a control freak and believes they can do everything better themselves. perhaps Adobe's internal development tools have some strange requirements. who knows.
in any case, this goes a long way to explaining the huge size of the app.
yes, i do think that this will result in Adobe's PDF reader declining in usage on Linux as the open source alternatives improve. KPDF has forms on its TODO list, and i do agree that its an important feature. as the Free readers move to a common library (the IMO ill-named "poplar") this should hopefully help distribute the efforts needed for form support.
an Open and Free PDF reader is quite important to have. i would urge as many of us who use KPDF to rally behind those working on it and give them support in any way we can.
Poplar... wtf did they do, take Popular and remove a vowel?
ah right, a popular culture reference as opposed to the tree. hopefully users won't be faced with figuring out what libpoppler is due to using package managers (though somehow i'm not overly convinced that will be the case enough of the time), but as a developer i have to say i'm really unimpressed at having to carry about a huge wealth of naming knowledge in my head.
the more obscure our naming, the higher the barrier to entry and discovery. for libraries that will be shared between many projects, this is really only more true IMO.
if you've ever heard military folk speak to each other, their unending use of acronyms makes it rather difficult to keep up. this sort of obscurity is not great when you actually want people to understand. like new developers.
libxml2? good name! taglib? decent name! lame? umm.... poppler? wtf?!
how about libpdf? or even libxpdf if libpdf is too generic?
Well I think mostly people won't have to worry about it so much since it will either be included in a download, or be a dependancy of the package.
I agree though. If I want to find the pdf lib, I'd search the package names for "pdf" and not "poppler".
Actually, this reminds me of the k-naming disaster. It's getting better (amaroK is fine for example), but it sure is annoying in menus when every app starts with a K, defeating the whole point of using the keyboard to start an app quickly (by hitting the first letter of its name).
> I'd search the package names for "pdf" and not "poppler
and apparently i would've looked for the homonym "poplar". and i even visited it's home page a few days ago -=P
cool names are fun, but quickly get in the way.
KMenu defaults to showing "description (app name)" so your example of not being able to use a keyboard for access the apps due to too many names starting with K is non sense unless you changed the option or are using a distro which did so for whatever reason.
Do any of the OSS pdf readers work on Windows (and linux)? I am doing some contracting for a company that is placing equipment in airliner cockpits. One of the items will contain pdf manuals for the jet. Apparently, the adobe reader was rejected as too buggy on windows, let alone Linux. Oh, kind of cool, they are switching to Linux from Windows to be able place equipment in the cockpit.
if they are using Linux, why do you need the PDF reader on Windows? or are they still using Windows now and moving to Linux in the future?
this system will run both linux and windows at the same time (think x-term). The manuals can be on either system. Far better to have an app that runs on both.
One of the reasons any company like Adobe uses outdated components, rolls their own software and put everything into one package is simply because they cannot be sure what system their software will be installed on. It's the moving target thing. They just simply do not want to support an application that won't run properly when a desktop environment moves on in six months. That's something that hasn't been addressed at all with open source desktop environments.
if you are using a library like Gtk+ or Qt, then by all means compile it in statically or provide your own forked-and-branded build with your software. bundling your own libraries to avoid platform movement is no reason to reinvent toolbar widgets.
moreover, it's really not a big deal to say, "Requires version X of lib Y or better", especially if that library has sane binary and functionality compatibility policies (allowing newer versions to be installed)
> That's something that hasn't been addressed at all with open source desktop
KDE carries binary compat policies for its libraries that do address this issue. KDE 3.x is approaching its 3rd "birthday". if you can't manage to track a 3 year time span (which will likely end up being 4 years before KDE4 is out, and even long before KDE3.x compat libs are uncommon; look at how long SUSE has bundled KDE2 compat libs), there's something very wrong.
the real problems with compatibility lies further down the stack and lie primarily at the feet of OS vendors.
You should know better than I that libraries like Qt and GTK cannot be statically compiled because they are just too big.
Or maybe that's why the Acrobat Reader binary is bigger than 100 Mb. :D
Anyway, I don't really consider this an issue nomore, since desktop environment tend to release major breaking versions slower and slower. I guess re-compiling every ~1.5yrs is enough to keep up.
Skype offers various options.http://skype.com/products/skype/linux/
Notice the statically compiled version is only 8MB. (3 MB larger than the dynamic one)
> libraries like Qt and GTK cannot be statically compiled because they are just too big.
Statically linked Opera is ~5MB. The real problem with static linking is that you can't upgrade the library to get bugfixes or new functionality.
"libraries like Qt and GTK cannot be statically compiled because they are just too big"
Not so. When you do a static linkage (with a semi-intelligent linker) and strip your binaries afterwards, you only end up with those functions that you actually use. So if your Qt app isn't using QTextEdit (for example), then it won't be included. Adobe's problem is that it's NOT statically linked (at least not the version I have).
There is another feature that I feel is important as well. It would be nice if KPDF could create pdf's, especially from a scanner. Adobe's pdf writer does this and it's very convenient. I use it to make electronic copies of all my important documents, and being able to scan directly into the pdf writer makes archiving my documents a breeze. As it stands now, to make a pdf in linux (at least what I have figured out so far) entails scanning to an image, importing into Kword (or Scribus, etc.), and then printing to pdf. This is a bit cumbersome.
Where would I go to make a feature request for KPDF?
> It would be nice if KPDF could create pdf's, especially from a scanner.
scan into kooka, the KDE scanner program (it's in kdegraphics), then print directly from it to PDF. no importing necessary.
> Where would I go to make a feature request for KPDF?
> scan into kooka, the KDE scanner program (it's in kdegraphics), then print directly from it to PDF. no importing necessary.
Thanks Aaron. I guess I never thought to check if I could print directly from kooka. That should simplify things. I'll see how easy it is to make multi-page pdf's.
I still will make a feature request. I think it would be nice integrated into KPDF. As it scans a page, it can just prompt for the next page until you end it.
Btw, awesome job on the interview.
There is http://bugs.kde.org/show_bug.cgi?id=90060 already. It's a bit more though - since kooka can use ocr tools, it would be cool if the ocr result would be included. Something similar is also on the kpdf todo-list btw.
Thanks uddw. Parts of that request confused me a little, but here is the relevant excerpt for me:
"This could make kooka a great tool to archive document. Then there could be a shortcut to scan, ocr, export-as-pdf a document in one run. It could also ask the user if he/she wants to append more pages."
This is EXACTLY what I was getting at. Whether it's done in kooka or kpdf isn't so important I guess. I thought it made sense for kpdf since it is a pdf tool/viewer.
Vote for it ;)
KPDF is a pdf viewer not a editing tool.
I understand that it's a viewer. My request is that it add pdf creation functionality as well. Whether they add that functionality is one thing, but I don't think the attitude should be that since it's a viewer at this point one should not request more. After all, I thought that's what the wish list was for.
> as i understand the situation, Adobe has only one developer who works full time on the Linux/UNIX PDF reader
I think the case is just: they default to what ever the market leader (redhat) defaults to.