aKademy 2006 Schedule Finalised
Tuesday, 19 September 2006 | Jbrockmeier
More than 200 members of the KDE community, related projects, industry partners, and interested users will be gathering on Friday for aKademy 2006 at the Trinity College Dublin to work on the next-generation KDE 4 desktop and cross-desktop standards. See the official press release for the full announcement.
Comments:
Slight typo/error - Jucato - 2006-09-19
Looks like it's going to be a very busy and exciting week. Can't wait for it start and hear some news. :) I'd just like to point out a slight error: "The aKademy conference will also feature Human Computer Interaction (HCI) Day on Wednesday, September 26." I think it should be September 27.
Re: Slight typo/error - Jonathan Riddell - 2006-09-19
Fixed
Re: Slight typo/error - why kubuntu is a fault - 2006-09-19
kubuntu devs (how many of them are there?) have to copy gnome/gtk stuff and produce python-code. thats not how kde-development should work.. why script if "you" "could" do it right?.. kde has a good standard look n feel + artwork, kubuntu makes kde look silly & oldfahioned.. kde-apps on kubuntu are allways unstable.. u better copy directly from debian or slackware.. ur builds are broken man /part #jriddel ps: google sux too
Re: Slight typo/error - Vlad Blanton - 2006-09-19
kindly disregard the above flamepost
Re: Slight typo/error - monoman - 2006-09-19
i didnt understand the first part of this troll-post.. but as a Slackware-User, who has tested kubuntu 6.06, i must agree with him, what artwork + stability concerns..
Re: Slight typo/error - Segedunum - 2006-09-20
I wish it was a flame post, but alas, at least part of it is true unfortunately. If Kubuntu is supposed to be improving KDE as part of a desktop system then why on Earth use a new control centre written in Python?! There's just simply no reason whatsoever to do it. Why not take the bull by the horns and take KDE's own Control Centre and improve it, or take some responsibility, work with KDE's usability people (and they're pretty excellent now) and give the Control Centre the attention it needs. This would improve KDE and Kubuntu alike. Again, a new power management applet was written, in Python of course, when it is really klaptopdaemon and kpowersave that need to be either ditched or improved at the core of KDE. I have no real idea why distros go off and do their own thing without taking advantage of what's alreday in the desktop. Improve anything and everything upstream and you'll reap the rewards of having to put in less effort in maintaining your own code.
Re: Slight typo/error - Odysseus - 2006-09-20
Huh? You do realise that all the Kubuntu config tools are actually KControl modules that work in the old KControlCentre and so can be re-used by anybody (unlike say, almost every other distro on the planet)? Or that the old KCC is still available? Or that the new shell is one of the attempts to come up with a better KCC? Or that the next version is having improvments included in it from the usability guys (basic/advanced split, etc)? Or that all those hardware config modules that don't exist as part of the standard KCC are actually from an independant project called Guidance that pre-dates Kubuntu? Most of that stuff you see in Kubuntu are things that they picked up from out of the community and adapted for their use, how do you think they got there so fast? Seems to me you just have a thing about Python... John.
Re: Slight typo/error - Segedunum - 2006-09-20
"You do realise that all the Kubuntu config tools are actually KControl modules that work in the old KControlCentre and so can be re-used by anybody (unlike say, almost every other distro on the planet)?" So? YaST modules are also available on KControl, but it doesn't get away from the fact that distributors, not just Kubuntu, always go off and do their own control panel/centre whatever when it's pointless. It confuses the hell out of people when they see two control centres for no reason whatsoever. "Or that the new shell is one of the attempts to come up with a better KCC?" It would be better just to come up with an initiative to improve the existing one rather than going off on tangents and putting effort into an 'attempt' at a new control centre that will probably fall by the wayside. "Or that all those hardware config modules that don't exist as part of the standard KCC are actually from an independant project called Guidance that pre-dates Kubuntu?" So what? "Seems to me you just have a thing about Python..." No actually. There's a time and a place for Python, and developing stuff desktop infrastructure that really should be developed as a part of KDE, and will probably be succeeded by stuff in KDE, is not one of them.
Re: Slight typo/error - Robert Knight - 2006-09-21
> It would be better just to come up with an initiative to improve the > existing one rather than going off on tangents and putting effort > into an 'attempt' at a new control centre that will > probably fall by the wayside. Kubuntu's System Settings tool is in KDE's subversion repository, as are all of the "guidance" configuration modules which you refer to. It is being developed as "a part of KDE" - http://websvn.kde.org/trunk/playground/base/systemsettings/ and http://websvn.kde.org/trunk/playground/base/guidance/modules/ > It confuses the hell out of people when they see two control centres for no reason whatsoever. Under Kubuntu at least, only "System Settings" appears in the K Menu. Short of hunting around in /usr/bin, the user does not need to know or care about the existence of KControl. > There's a time and a place for Python That is a decision which falls to the people who do the work. Having spent some time debugging all sorts of interesting and mysterious crashes in KDE applications, I think it makes a lot of sense to move towards higher-level languages with automatic memory management for desktop applications which are not performance-critical. There have been suggestions that some of the new modules may be ported to C++ in the future, who knows? > It would be better just to come up with an initiative to improve > the existing one rather than going off on tangents and putting effort > into an 'attempt' at a new control centre that will probably > fall by the wayside. If you think you can do better, then launch that initiative. Trolling on the dot won't change anything.
Re: Slight typo/error - Segedunum - 2006-09-21
"There have been suggestions that some of the new modules may be ported to C++ in the future, who knows?" There's at least a large part of the point made there.
what does it all have to do with.... - Jucato - 2006-09-20
I don't get it. What does "using Python" have to do with "not helping develop/improve KDE"? To add to what Odysseus said: You do know that someone for KDE HIG is working with Kubuntu to develop System Settings, right? You do know that the power management app is being developed by a KDE dev, right? You do know that changes/improvements from Kubuntu are also sent upstream, right? You do know that some KDE devs actually prefer to use Python or Ruby, right? Really, I just don't get it...
Re: what does it all have to do with.... - Segedunum - 2006-09-20
"I don't get it. What does "using Python" have to do with "not helping develop/improve KDE"?" Python is a desktop level, Visual Basic type, language for developing desktop apps. It is not there to develop, what should be, infrastructure that should actually be a part of KDE itself. "You do know that someone for KDE HIG is working with Kubuntu to develop System Settings, right?" Excellent. It's not helping KControl get any better though, which is where this development should be taking place. Create a mock-up of a new KControl to try things out - fine. But don't start using it in a distro before KControl has been improved itself. "You do know that the power management app is being developed by a KDE dev, right?" Rrright..... It's not a part of KDE and its not doing anything to solve the problem of klaptopdaemon or kpowersave within KDE itself though. "You do know that some KDE devs actually prefer to use Python or Ruby, right?" Ruby and Python are for developing desktop level applications in the same way as using VB on Windows. They aren't there for redeveloping new versions of functionality that is, and should be, in KDE itself.
Re: what does it all have to do with.... - python_is_4_gnomes - 2006-09-20
python is easier than c++, its easier to write a lill app doing this and that.. thats ok, but kde core is written in c++ and its stable on most distros, except kubuntu.. its stable on slackware, slax, pclinuxos or centos and more.. pykde is maintained by just _1_ person.. i m not sure about the skills of jriddell.. but creating ui-files using qt-designer isnt that hard.. even a troll like me could do that.. sometimes i m not sure, whether kde is knowingly rebuild/"redesigned" to look less pretty.. just compare the gnome-build in ubuntu with the kde-build in kubuntu, its a big difference. Not only the artwork they made is $hitty.. you could copy the artwork of slax or let kde be kde.. Having not the same ressources as ubuntu isnt an excuse, but lacking skill or a good will is an excuse..
Re: what does it all have to do with.... - Odysseus - 2006-09-21
"pykde is maintained by just _1_ person.. " That's about all you need, it doesn't take much work these days to re-run SIP against a new version of KDE. And how many other FOSS projects are the same? Heck, even something as core as RPM. "but creating ui-files using qt-designer isnt that hard.. " No it isn't, which is how you do the GUI in PyQT/PyKDE, and why proto-typing in Python and implementing in C++ is possible. It's obvious you really don't know jack about it.
Re: what does it all have to do with.... - Morty - 2006-09-20
"Python is a desktop level, Visual Basic type, language for developing desktop apps. It is not there to develop, what should be, infrastructure that should actually be a part of KDE itself." I'd rather say you are seriously mistaken here, configuration utilities are things that should be developed in Python. It's one of the tasks where Python really shines, you will benefit from the flexibility and power of the language. It's about using the right tool for the job, and when it comes to system management and configuration the tool is Python. I'd rather argue for making PyQt/PyKDE a more central pice of KDE, thereby making it easier to develop and distribute this kind of tools.
Re: what does it all have to do with.... - Segedunum - 2006-09-21
"I'd rather argue for making PyQt/PyKDE a more central pice of KDE, thereby making it easier to develop and distribute this kind of tools." And therein lies the problem.
Re: what does it all have to do with.... - Morty - 2006-09-22
Rather lack of vision on your part, if you think including the right tool for handling those simple tasks in the most efficient manner to to be the problem.
Re: what does it all have to do with.... - The Badger - 2006-09-21
"Python is a desktop level, Visual Basic type, language for developing desktop apps." Whilst Python has scripting origins, it's a genuine programming language that can be used for more than desktop applications, as its community will attest. "It is not there to develop, what should be, infrastructure that should actually be a part of KDE itself." It sounds like you're drawing arbitrary boundaries to satisfy some ill-formed classification scheme you've cooked up. It's not as if the configuration modules in question have to run in interrupts or must satisfy hard real-time constraints, exactly. "Ruby and Python are for developing desktop level applications in the same way as using VB on Windows." Strange you have this idea. Most people I see using Python use it in considerably different ways than the average VB on Windows developer who, to forestall any other misconceptions, probably turns out full standalone applications rather than scripts for automating some office suite or a big C++ app with a patronising "not a real programmer" scripting hook. "They aren't there for redeveloping new versions of functionality that is, and should be, in KDE itself." The very fact that people have developed this stuff in something higher-level than C++ might suggest something about the relative attraction of maintaining that functionality in Python vs. doing/redoing it in C++, and the obvious fact that such languages can indeed be used to implement such things - thus refuting the bizarre "they aren't there" remark. Indeed, given the gazillion dlopens and other environment sniffing that goes on with many a KDE application written in C++, such languages are increasingly "there" to provide such dynamism without the fragility, such as that seen in Konqueror refusing to start for me on an increasingly frequent basis because of, you guessed it, some fragile configuration dance it does on start-up. Anyway, talk is cheap. If you or someone else don't fix up KControl, is everyone else supposed to just mock stuff up in their high-level languages and pace the hype treadmill? Or do we all just accept what passes for the real world and get on with it?
Re: what does it all have to do with.... - Segedunum - 2006-09-21
"It sounds like you're drawing arbitrary boundaries to satisfy some ill-formed classification scheme you've cooked up." Then come up with a better one. Scripting and higher level languages for core infrastructure can't just be used arbitrarily wherever people feel like it. You use these things on top. When you're talking about core infrastructure you're talking about it being used by other parts of KDE in a uniform way. "It's not as if the configuration modules in question have to run in interrupts or must satisfy hard real-time constraints, exactly." Performance is an issue, but not as big as coming up with a uniform way of doing these things within KDE so components can be reused etc. "Strange you have this idea. Most people I see using Python use it in considerably different ways than the average VB on Windows developer who..." Not entirely sure what the point is in there, but the gist seems to be that Python developers tend not to create large standalone applications. Point made. VB is more suited to that, but I don't see Microsoft developing parts of Windows in Visual Basic. I wonder why. "The very fact that people have developed this stuff in something higher-level than C++ might suggest something about the relative attraction of maintaining that functionality in Python vs. doing/redoing it in C++" Does KDE then depend on a Python or Ruby interpreter, one or the other or both? How do other KDE applications reuse the code? etc. etc. There are a variety of issues. "Anyway, talk is cheap. If you or someone else don't fix up KControl, is everyone else supposed to just mock stuff up in their high-level languages and pace the hype treadmill? Or do we all just accept what passes for the real world and get on with it?" Not entirely sure what the point is there either, but it would be somewhat more sensible for reasons outlined for those 'pacing the hype treadmill' with their 'higher level languages' to commit to KControl first rather than 'pacing the hype treadmill'. I'm just pointing this out. If people want to waste time and effort in the long run then that's fine.
Re: what does it all have to do with.... - The Badger - 2006-09-21
"Scripting and higher level languages for core infrastructure can't just be used arbitrarily wherever people feel like it. You use these things on top. When you're talking about core infrastructure you're talking about it being used by other parts of KDE in a uniform way." What you're saying is that such languages shouldn't be used if there's any chance that someone will come along and want to write a C++ program which consumes their services. However, many of those languages will quite happily interoperate with C++ programs - indeed, PyKDE goes to some lengths to permit "two way" interoperability, and there'd probably be little point to PyQt if it didn't support the same kind of thing. And it's not as if having libpython.so involved is a significant burden, given the number and size of the other shared objects typically involved. Indeed, having more stuff in Python is probably better for incremental improvements to applications, rather than having to wait for monolithic mega-updates to the KDE packages just to see one of the "bundled for convenience" applications get fixed. "Performance is an issue, but not as big as coming up with a uniform way of doing these things within KDE so components can be reused etc." Performance is an oft-cited reason for not using Python, although configuring run-levels, the X server, fstab and so on don't typically need you to have your pedal on the metal. (Must have those raster bars correctly timed, perhaps.) "Not entirely sure what the point is in there, but the gist seems to be that Python developers tend not to create large standalone applications. Point made." I don't know what basis you have to make such a point. Sure, there aren't many multi-million line Python applications, but then there are plenty of fairly accomplished Python applications out there. It isn't all quick sysadmin scripts and "hello world" demos, you know. "Does KDE then depend on a Python or Ruby interpreter, one or the other or both? How do other KDE applications reuse the code? etc. etc. There are a variety of issues." This is how we revisit the old SCons flamewar: KDE must apparently only depend on bash and an X server, and a C++ compiler for developers. The GNOME community is continually going through this debate with the result that the main desktop stuff proceeds at its own steady pace being developed in C, whilst everyone else is writing everything else in C++ (if you're really conservative), Python, Java and C#. The debate gets reignited when people see the difference in progress between the camps. Anyway, there are lots of answers to the reuse issue: various bindings interoperate pretty well at the in-process level, proper distributed computing mechanisms can offer some answers at the inter-process level, probably in a way that is no worse than KParts can offer now (and at least it wouldn't crash the component container that a KPart can easily manage to do). "Not entirely sure what the point is there either, but it would be somewhat more sensible for reasons outlined for those 'pacing the hype treadmill' with their 'higher level languages' to commit to KControl first rather than 'pacing the hype treadmill'." The point is that the people writing their stuff in Python (or whatever) aren't "pacing the hype treadmill" making mock-ups and doing fake screenshots of what the next generation of components will look like: they just get on with writing the stuff and not fretting over the fact that their language isn't cheek-to-cheek with the CPU. In open source projects, the best solution is quite often the only solution anyone ever wrote, and whilst valid reservations can sometimes draw people's attention to deficiencies in various approaches, your VB analogies suggest that you're not fully aware of what stuff like PyKDE has to offer. So it's a stretch to claim that anyone has wasted their time.
Re: Slight typo/error - sashmit - 2006-09-20
A LOT of Ubuntu-related stuff is written in Python.
Re: Slight typo/error - Bill - 2006-09-22
...as is a lot of RH stuff (like the installer, the configuration system ....), a lot of Gentoo stuff (like say, Portage), and IIRC, the new debian gui installer is a modified version of the RH installer. And those are core infrastructure for those distributions.
Re: Slight typo/error - why i think you're a moron - 2006-09-19
Before criticizing other people you should start improving yourself, above all your spelling.
Re: Slight typo/error - Odysseus - 2006-09-20
I know I shouldn't feed the trolls, but I think it's a good think to slap down blatent lies as hard as possible so no-one gets the wrong end of the stick (like passing newbs or journo's). The Kubuntu devs do NOT have to copy gnome/gtk stuff, most of their stuff is either KDE stuff from the main project or pulled in from the wider community (Guidance, KnetworkManager, Adept, etc) or written from scratch as KDE apps specifically for KDE/Kubuntu to replace a Gnome/Gtk app. For a few things, such as the Ubiquity installer, the Ubuntu architects design a common non-gui backend and leave it up to the Ubuntu/Kubuntu/Xubuntu devs to write their own native front-end to fit their desktop. Kubuntu uses Python to write desktop configuration apps because its faster to develop that way with fewer bugs. These types of apps do not need the small speed boost you would get from using C++. This is a sensible trade-off. Kubuntu keeps the standard KDE look-and-feel, with only a few simplifications to the menus and toolbars. In fact Kubuntu sticks closer to the KDE default out-of-the-box than any other distro I have seen. The Kubuntu builds are also some of the most stable I have seen, and the most up-to-date. The day that a new KDE/Amarok/Koffice release comes out, they have rock solid packages available. Kubuntu grew out of the KDE community, with jriddel and a number of other regular KDE contributors deciding they wanted KDE on Ubuntu and created the packages needed and pulled together the various community projects to make a cohesive distro. It's a tribute to the quality job they did that Ubuntu later made it an offical project and hired Jonathan to oversee things. To this day, the project is still a majority volunteer effort who do a remarkable job. John. P.S. Yes, I am a current Kubuntu user, and I do have some issues with the distro, but mostly with the underlying Ubuntu base. The few config issues I have with the KDE desktop are easily fixed by installing the provided original KDE config packages, I know of no other distro that makes it so easy, and believe me I've tried a heap of 'em.
Re: Slight typo/error - Segedunum - 2006-09-20
"The Kubuntu devs do NOT have to copy gnome/gtk stuff, most of their stuff is either KDE stuff from the main project or pulled in from the wider community (Guidance, KnetworkManager, Adept, etc)" Alas, the vast majority of this (apart from package management, obviously) is duplicating functionality already in KDE, and isn't solving the fundamental problems upstream where they should be handled. "Kubuntu uses Python to write desktop configuration apps because its faster to develop that way with fewer bugs. These types of apps do not need the small speed boost you would get from using C++." Fair enough. However, again, many of the apps created, like the Control Centre and power management applet are simply duplicating functionality that is already a part of KDE, and will continue to duplicate functionality once new parts come into KDE to solve existing problems, like Solid etc. It is doubtful that Python apps will ever be accepted as a core part of KDE, because it would essentially mean picking a scripting/desktop language, be it Ruby or Python. Python and Ruby are there for desktop level applications - not core infrastructure. What this means is that when a new KControl comes along, or a power management applet using something like Solid is put into KDE then these Python apps in Kubuntu will be redundant and a bit of a waste of time. "Kubuntu keeps the standard KDE look-and-feel, with only a few simplifications to the menus and toolbars. In fact Kubuntu sticks closer to the KDE default out-of-the-box than any other distro I have seen." Hmmmmm. Whatever. The trash bin is in the corner in the task bar, the applet tray is arranged differently, the window decorations are different from standard........ If there's something wrong with KDE then improve it within KDE. If you have to change anything from a default, then it probably means that whatever a default is in KDE it's not working.
Re: Slight typo/error - imbrandon - 2006-09-20
"Hmmmmm. Whatever. The trash bin is in the corner in the task bar, the applet tray is arranged differently, the window decorations are different from standard........ If there's something wrong with KDE then improve it within KDE. If you have to change anything from a default, then it probably means that whatever a default is in KDE it's not working." So every KDE distro should look exactly the same? <note to self> dont feed the trolls anymore .... DONT FEED THE TROLLS </end note>
Re: Slight typo/error - mikeyd - 2006-09-21
<I>So every KDE distro should look exactly the same? </I><P>Umm, yeah. Why is that self-evidently wrong as you seem to think it is?
Re: Slight typo/error - Segedunum - 2006-09-21
"So every KDE distro should look exactly the same?" When it's ultimately KDE we're talking about, then yes, why not? At least from one distro to the next people know where something is.
Re: Slight typo/error - Jonathan Dietrich - 2006-09-20
"What this means is that when a new KControl comes along, or a power management applet using something like Solid is put into KDE then these Python apps in Kubuntu will be redundant and a bit of a waste of time." No it is *not* a waste of time, because while I'm waiting for kore KDE to be updated with something that makes the python apps redundant, I am USING the python apps EVERY DAY. "Whatever. The trash bin is in the corner in the task bar, the applet tray is arranged differently, the window decorations are different from standard........ If there's something wrong with KDE then improve it within KDE. If you have to change anything from a default, then it probably means that whatever a default is in KDE it's not working." I thought that KDE *encourages* distros to personalise it.
Re: Slight typo/error - Segedunum - 2006-09-21
"No it is *not* a waste of time, because while I'm waiting for kore KDE to be updated with something that makes the python apps redundant" You've just contradicted yourself. When those Python apps get made redundant by something 'sensible' built into KDE then the code and it's work becomes pretty much useless (apart from the things you can take). Much better to use that time and effort in building something more sensible in KDE, or that can be merged directly into KDE, and using that in Kubuntu. "I thought that KDE *encourages* distros to personalise it." Personalisation, yes. Changing defaults for usability reasons, or because distros have found that they are wrong via real world usage, no. A KDE dev (can't remember who or where) talked about developers customising and changing defaults on their own, and then getting them to ask why. Is it because the defaults or wrong and should be thought through more?
Re: Slight typo/error - Jonathan Dietrich - 2006-09-22
In your comment you spoke of a replacement based on "solid"... When is solid coming? KDE4 no? Guess what? I'm using the python based stuff NOW!
Re: Slight typo/error - Nick - 2006-09-20
issues left - disregarding of upstream by ubuntu (including i18n) - ubuntu development is proprietory better work closer to debian
Re: Slight typo/error - demoKratur has no chance - 2006-09-21
kde-apps are much faster translated than kubuntu apps.. most kde-apps are available in french and german.. monohumanity to human beings that sux and doesnt work at all .. i m sure they dont even faithfully think about japanese or arabic.. and launchpad is just stupid compare the ubuntu-dev-team with gentoo-dev-team, gentoo is trying to create high-level apps, while ubuntus trying to write in a high-level-language some gui-tools.. i hope they dont try to replace sysinit with python-scripts in an "OOD"-way.. just let the other do their work or help them, for example initNG, instead of hidden fork and relaunch as a new thing (like splashy <-> usplash)