aKademy Team Announces International Lineup

Saturday, 24 July 2004  |  Ateam

The aKademy Team is proud to announce the schedules for the KDE Community World Summit 2004, code-named "aKademy", taking place in Ludwigsburg, Germany from August 21st to 29th. Featuring speakers from IBM, Novell, SUSE, Conectiva, Trolltech, HP and many community hackers and activists, it promises to be a highlight of the Free Software calendar. Boasting an extensive program of talks, demos, tutorials, workshops, presentations, and joint coding activities, as well as plenty of opportunities to discuss such significant issues as usability and the future of Qt4/KDE4, you really can't afford to miss it. Whether you're a first-time user or a guru developer, register now to avoid disappointment. You can read the full announcement here, and find out more at the aKademy web site.

Comments:

Schedule Overview according to Slashdot - anonymous coward - 2004-07-24

Here is an overview of what's goin' on at aKademy. You may say, these KDE-ers are crazy, trying to organize a full 9-day event, but here are the schedules: DevConf -- the Developers' and Contributors' Conference: http://conference2004.kde.org/sched-devconf.php Tutorials -- Fifteen One-Day Tutorials for IT Professionals with world class instructors: http://conference2004.kde.org/tutorials.php CodeMarathon -- the 5++ day, 24 hours Coding Marathon and Hackfest of KDE enthusiasts: http://conference2004.kde.org/sched-marathon.php AccessForum -- the First Unix Accessibility Forum: http://accessibility.kde.org/forum/program.php UsabLab -- the Usability Forum with integrated Usability Lab: http://conference2004.kde.org/usabilityforum/usability_akademy.html UserConf -- the KDE and Linux Users' and Administrators' Conference: http://conference2004.kde.org/sched-userconf.php

Re: Schedule Overview according to Slashdot - Anonymous - 2004-07-24

According to Slashdot? Oh please, don't copy the whole conference web site to here.

Sun Microsystems also participating - Harald Fernengel - 2004-07-24

I just confirmation that Peter Korn from Sun Microsystems will be able to attend and hold a speech about accessibility. Peter has experience with accessibility for over ten years, I am really looking forward to his presentation.

Please focus on substance and not style - minty - 2004-07-26

Dear Summit Gatherers. I stronly urge you to focus on making KDE better by making what is there more reliable, and useful. To be honest if you want to make KDE better, I would urge you to take things out of KDE, rather then add more beta software. Please resist the temptation to add more fluff and eye candy. An ounce of meaningful documentation would do more good then a hundred megabytes of new code. But let me end on a positive note, and say how wonderful KDE really is and to thank the volunteers who have given to it. I only want to see KDE get more usefull, and worry that KDE will soon cave in from its own weight and complexity

Re: Please focus on substance and not style - Datschge - 2004-07-26

> I stronly urge you to focus on making KDE better by making what is there more reliable, and useful. Which is already happening with each release. > To be honest if you want to make KDE better, I would urge you to take things out of KDE, rather then add more beta software. So we start spending time discussing what should be taken out instead just improving what's there? Nah, you should rather set up your very own KDE installation instead telling developers what not to care about. > An ounce of meaningful documentation would do more good then a hundred megabytes of new code. Very true, and I'm sure you already contributed your share of it already. =)

Re: Please focus on substance and not style - anonymous coward - 2004-07-26

Datschge, are you going to attend aKademy?

Re: Please focus on substance and not style - Datschge - 2004-07-26

I intend to.

Re: Please focus on substance and not style - JohnFlux - 2004-07-26

Hi, I'm a newbie kde developer. I just wanted to add to what you are saying. Sometimes people don't realise it, but adding 'fluff' can quite often be a way of cleaning up and making everything nice. Just a quick example - I'm working on adding a way to link konversation (irc client) to the contact addressbook. This is added 'fluff', but in doing so I'm talking with the kopete developer, and comming up with standard ways to store the ircnick, and solidfying the underneath. For example the kaddressbook has no function to pass the irc nick, and get back a pointer to the addressbook. This needs to be added, which means the kabc interface gets better. Anyway, my point is is that the fluff that you see is often the tip of the iceburg of refactoring and solifying the underlying code. It's just that all you see are the cosmetics.

first level of documentation - minty - 2004-07-26

I would love to do some documentation, but the first layer of documentation must come from the author(s) of the program itself. I am not so much talking about user documentation but programmer documentation, for instance, are there kparts available if so then what is the interface. The same goes with dcop. It seems there is very little code reuse in KDE, every program seems to be an island with the only common denominator being the KDE/QT widget set itself. All this reinvention of the wheel doesn't necessarily lead to a better wheel, and if it did, why not share the better wheel amoungst all KDE applications. I think KDE is getting to a very polished state, and the feature list while not complete, is getting close to what users need. So I just think the KDE needs to take it to the next level, which goes beyond adding features for the sake of adding features. If I wasn't using Linux as my desktop, I'd be using a Apple computer, in fact if I could afford one I'd have it on my desk along side my Linux box. I don't think I have to say why, as their desktop really speaks for itself, just by spending ten minutes in front of it. And this kind of polish and integration is what KDE needs to rise to. Please understand that I really like KDE, and have the strongest desire to port our application to it. It is for this reason I ask the the people of the KDE to take documentation more serriously, so that as commercial software vendors start thinking of porting their application to Linux, they think of doing so with KDE in mind.

Re: first level of documentation - Lauri - 2004-07-26

So, which documentation for which app do we sign you up for? We take documentation very seriously, but it's also boring and hard work, and pretty thankless to do. The only way it can possibly get better, is for people to get involved. That's just as true for user documentation and API documentation alike. If you are frustrated having to figure out how an API works, then, submit a patch with documentation once you do. You'll get the additional satisfaction of not just figuring it out, but having saved someone else the trouble to do so, and contributing to what is, after all, an almost entirely volunteer driven project.

Re: first level of documentation - Eric Laffoon - 2004-07-27

> I would love to do some documentation, but the first layer of documentation must come from the author(s) of the program itself. I am not so much talking about user documentation but programmer documentation... Okay, so what program? Have you contacted the authors? We've been asking for people to help on this for some time and even done initial UML drawings. We have several files explaining key parts on Quanta in our source. The big difference here is that we're busy coding. Talking about coding or documenting it takes time and slows things down. People doing this and interacting with developers would be good, but saying you'd like to do it isn't actually crossing the line into action steps. At the same time full acess to the process is on our developer list. > for instance, are there kparts available if so then what is the interface. The same goes with dcop. Kparts are fairly standard libraries and locations you can easily browse and DCOP can be looked at with even more ease in kdcop. It's practically self documenting, not that it wouldn't benefit from documentation. > It seems there is very little code reuse in KDE... And here is where we cease to have a rational discussion. KDE has more reuse than any software I am aware of! The entire concept is reuse. Take for instance Quanta. It originated as a forked Kdevelop 1x with a forked Kwrite and using KHTML. Forking was the wrong way to do it and that was before I got involved too. Andras was the first developer to use the Kate part, which was actualy more reuse than originally envisioned by the developers. Quanta also use KHTML which is being enhanced to allow editing which we are using to interact with our VPL mode. Then there are all the core KDE classes and dialogs... the dialogs are obvious. Cervisa used to be a monolithic tool but now it sits on top of cvsservice and communicates via DCOP. Quanta uses cvsservice directly within the interface. All IO access is handled by KIO slaves which work across all of KDE. I could go on about the base classes, but what about KParts? Quanta can load KParts quite easily so you can run Cervisa and other programs in Quanta. You can even set up Konsole as a part. Granted different applications have evolved different ways to address plugins and components. In KDE 3.3 Quanta can now run Kate plugins and if we had time we would be interchangable with KDevelop too, but that is in the works. You also have to keep in mind that developing that level of abstraction and interaction is much more time consuming than just whipping out some code. If you're coming from another background then you have to realize that you can just join the kde-devel mailing list and ask questions to your heart's content and get answers directly from the developers. The access is extreme, but the whole process is quite different than what you're used to. It moves much faster and has to produce a lot more results with a lot less manpower. Thus the extremely high reuse.