We have a location for it now as well: Randa, Switzerland. If that name sounds familiar, that's because we held Tokamak III there. It's so beautiful, we just had to go back. Ok, and having Mario offer to host it along with two other sprints helps. (Mario is a superhero of developer springs; I think that KDE e.V. should sponsor a superhero costume for him: Sprint Man! But no capes!) Mario being in Zürich is also a bonus, as it will make it easy for me to collaborate with him on logistics starting in March. The sprint is currently scheduled to take place on the first week of June.
There is the usual sprint planning wiki page for it and the number of people who have already signaled interest is great. I want to see a good mix of kdelibs hackers, packagers, developers and our key partners such as Qt devs there.
What is the goal of this sprint? To lay down a near-future practical roadmap that covers the next 2 or so years of development for kdelibs, kde-runtime and our engagement of the platform ecosystem around us. Getting down to work will also be important, so that we can leave not only with plans but also something to show for it all, even if it is just early steps, in the source code.
The participants will ultimately end up driving the actual topics and direction, let alone the conclusions, but here are the points likely to be hot at this sprint:
- Modular, Baby! Did you know Solid only depend on QtCore? What other dependency chains can we streamline? How can downstream packaging strategies shift to reflect these changes so more app developers can take advantage of this progress?
- Mission: Platform Profiles In 2010, we began the work of creating target platform profiles, particularly to differentiate mobile, tablet and desktop usage of the libraries. We have a lot more knowledge of the internal and external needs after this early effort, and need to take it to a compelling milestone.
- The Orphans of 4.0. Some areas of kdelibs did not get the API and design love they deserved, and other libraries got, leading up to 4.0. KIO is one such library. We need concrete plans for them.
- Embracing and Extending Qt Ok, that's a phrase that's most often associated with nefarious plots to do nasty, predatory things to other people's technologies. In this case it's completely friendly, however. We have a number of open questions regarding the role of KDE's libraries and Qt, how to best roll in things like QtQuick effectively without it feeling like a tack-on, how to identify and limit duplication between Qt and KDE libraries, etc. There are many opportunities here to broaden our reach, gift more app devs with ever better tools and help make Qt rock harder. (Relevant to recent bits of news: I've already invited dconf-qt devs to join us for this part.)
If that doesn't sound exciting and challenging to you, you probably aren't a library developer. ;) To me, however, it gives me that feeling I get when at the top of a roller coaster hill: excitement mixed with a little stomach churn. It's going to be an amazing ride.
To get involved, please add your name to the wiki page. If you have already added it, please make sure that it contains approximately how much it will cost to get you there so that I can do up a budget for KDE e.V. to take under consideration. I do need to start adding more meat to the bones of that wiki page as well, and will do so over the next few weeks. I'll keep you all posted.
Oh, and we need a kick ass logo for the event, too. Preferably with a George Clooney reference in it. Ok, maybe not. We do need a logo, though. ;)
7 comments:
I think another orphan of KDE 4.0 is the shortcut system. My understanding is that it is basically the same as in KDE 3.5, and it certainly hasn't undergone any major updates. I wrote an article on the issue a while back:
http://neverendingo.blogspot.com/2010/11/matter-of-control-state-of-input-device.html
KIO is a very interesting example that could be modernized.
It was very ahead when it came out, but nowadays I think an approach like gvfs is much better, by transparently using FUSE to mount remote filesystems to a directory, allowing all applications to benefit from it -- otherwise you get a rather confusing picture of different levels of functionality if you use a mix of kde and non-kde apps.
It also allows any app to access remote files without the file having to be fully transfered.
Basically, something like "always use KioFuse, and transparently mount stuff when you type fish:// or other kio into any KDE app" would be awesome.
@IAnjo: before KIO gets "modernized" there are other things that need to be done first.
btw, you can access files without transfering them in their entirety with KIO since 4.0. we do also need to keep portability in mind. something that works on Linux but nowhere else isn't a plausible solution.
ok, that said .. the first issue with KIO is that it is both a development framework that provides network transparent data layer _and_ it is a platform target with policy, including user interface, included. it's awesome that with KIO you get, for free, "are you sure you want to overwrite this file" dialogs and job reporting integration. but that stuff needs to be broken out into a platform target library and the network transparency bits (e.g. the slave infrastructure itself) put in a separate lib.
no newfangled design is going to mean very much until we first get that straightened out, i'm afraid :)
"btw, you can access files without transfering them in their entirety with KIO since 4.0"
But can any application do that? Or just KDE ones?
Part of the work KIO does is interesting because it is most useful when it can be extended to all applications.
As for portability, I think most OS's where KDE runs do support fuse (linux, bsd, mac, mobile linux). The odd ones out are ms stuff (but it would be an interesting discussion with great flamewar potential: should KDE give up having KIO on windows to have a better KIO everywhere else? -- I can see the headlines already).
But yeah, you are right, if KIO still combines GUI and network stuff, it would probably need to be split anyway to work as a fuse backend.
Thanks for your answer, btw!
There are other issues with KIO as well. My main issue is its file transfer system, both copying and moving, is broken in a bunch of ways.
For one thing, it must read through all the files and directories first, then it creates all the directories, then it does the file transfer. This means it has to go through every directory three times, and every file twice. This makes it much, much, much slower.
It doesn't even check for conflicts while it is processing the files the first time, conflicts aren't reported until after the actual transfer starts, so an error in first file will not show up until a significant fraction of the way through the transfer.
Further, the initial processing slows down over time and eventually totally locks if you try to transfer a large number of files. This is before a single byte has been transferred.
And it does not handle errors gracefully. Even a simple file name conflict blocks the entire transfer, meaning you cannot start a transfer and go do something else, or go to bed, you have to keep watching it, even if it takes hours. It can't block the files that are in conflict while continuing to transfer files that aren't.
Yet another is if you are doing a transfer, such as in dolphin, and the program crashes, the transfer just hangs indefinitely. It does not even provide any indication there was a problem, it just stops dead in its tracks.
On the wiki page it said that nuno was doing the logo; I also added mine, I hope that is alright.
Post a Comment