If you like KDE Traffic, please consider making a donation to the KDE project. Visit http://www.kde.org/support/ for details.
Welcome to KDE Traffic!
This has been an interesting week for KDE. With both KOffice (now in RC2) and KDE very close to a release, people are starting to discuss future plans. A new theme manager is being worked on for KDE 3.3, and, similarly, lots of other things.
The "Conquering the Enterprise Desktop" or "KDE in UserLinux" or whatever else (a name wasn't chosen yet, it seems) project was also one important topic of the week, having generated lots of discussion regarding KDE itself as well as integration of non-KDE applications and technologies into it.
By the way, our editor Peter Rockai is part of that project, being developing an APT frontend for KDE called Kapture and also a Debconf frontend. He asks me to forward his apologies for not being able to work on KDE Traffic this week, he was a bit overwhelmed with his work on these apps.
I hope you like this issue!
One of the most interesting proposals of the week was the creation of a
"Quality Team" (the name hasn't been agreed on yet) for KDE. According to its
creator, the main idea is to create a
community based quality team of non-developers, that would focus on the whole of
individual modules of applications, working orthogonally to developers,
documenters, users and testers, instead of the specific of the whole. In other
words think of acting upon the whole of Kontact instead of acting upon the
whatsthis of KDE project. The key idea is attracting people in a way thats both
interesting to them and more useful to KDE project. This would be the basis of a
community oriented (instead of company oriented) effort of improving this
experience.
The idea has been wonderfully accepted to the date, even though some people were worried about a clash in the roles of the application maintainer and of the quality team (the "janitors"). Waldo Bastian clarified this point:
I think the most important skill a Janitor must have is communications skills. You can know a lot about an application without needing to know how to write code, you can do a lot of bug management without needing to know how to debug the actual problem, you can make useful suggestions for icons without actually being able to draw.
KDE is a very large project, as a developer it is impossible to be subscribed and follow all mailinglists. A janitor can play an important role here by shielding developers, bug fixers and artists from a lot of the noise on many of the mailinglists and feeding these people the useful bits of information.
Take for example a mailinglist such as kde@kde.org. A lot of questions about a specific application could be easily answered by the janitor for that application. When it becomes clear that an application has a bug or an important missing feature, the janitor can then file a bugreport on bugs.kde.org and raise its priority. The developer could pay extra extension to such bugreports because (s)he knows that it is a real issue and that the janitor has already made sure that all relevant information is available.
Ideally, a Janitor would be in an excellent position to write documentation for the application or, lacking writing skills, assist a documentation writer. A Janitor would also be in a great position to maintain a FAQ.
The focus on a single application is crucial here, because maintaining a FAQ for all of KDE does not seem to work very well, probably because it is just too much work. By limiting the focus on a single application, chances of success become much greater.
A critical success factor for this all is the ability of the Janitor to work together with the maintainer/developers of the application, as already mentioned in the paper by Carlos, the Janitor must be able to make the work of the developers/doc-writers/debuggers/artists more pleasant, otherwise it will not work.
Another critical success factor might be the name ;-) People might not be lining up to become "Janitor" :-)
Some people still think that the only way you can help KDE is being either a developer or a translator. This excludes lots of people who are willing to help but don't have programming skills nor can/want to be a translator. This project would offer a way of stimulating people to contribute to KDE, and that's nice.
We've chatted a little with the creator of this proposal, Carlos Leonhard Woelz:
Tell us a little about you.
Carlos: I am a trader by trade (how's that!). I work in an investment bank here in Brazil, where I am responsible for the international trade desk. I trade mostly Emerging Markets Debt, but also American equities and treasuries, and major currencies.
I am also a Quanta Plus financial contributor, and I have been for the last eight months.
I believe that open source in general and free software in particular, is one of the most leveraged ways to reduce poverty and increase development around the world. It has the same effect as a massive tax cut. The lower the income in a given country, the greater the effect of open source in that economy. So I was looking for things to do personally, to help. I don't in any way work with free software (or web development).
Could you explain in a few words what is your proposal?
Carlos: It's the creation of a Janitor/Training role in the project, with work groups to deal with individual applications, to do non development stuff (there is tons of stuff to to) and to _care_ for that individual app. I thinks the effort of teaching this individuals the ways of open source pays out. And the idea is to create a community that is reasonable auto-sufficient to do real work quickly, decreasing the time-to-produce from new non-developers contributors.
When/Why did you have the idea for it?
Carlos: I started looking inside Gnu/Linux/KDE only a year ago. I went trough a long process of learning, from the installing, to the basics of the CLI, compiling and preparing the build environment, learning how translations are done, the bugzilla system, all that wonderful jungle of acronyms, read a bit about user interface. I had some really stupid questions to ask, and felt too shy to ask them. Now, I am starting to learn the basic of programming, but this is only to understand things better and be able to to more. During this whole period, I was allways eager to help, but had very few resources. One of the things that helped me was Aaron's whatsthis tutorial (context help writing tutorial).
And I started writing whatsthis for kdelibs and kdebase it had the advantage of teach me that specializing is good, and makes you productive faster. For instance, I wrote the whatsthis for Konsole kcm. To do that I lost hours reading Konsole and general Unix terminal documentation. Because I had so little background. And to write the next one, for Konqueror, I had no use for all of that, and so on.
I also read some papers over open source process, that gave me some insight: KDE under the microscope.
The idea of the importance of caring for defined application instead of finding some things to do here and there comes from my management experience. People love to follow the result of their work. And you find your way in the community faster if you focus.
What are your expectations regarding it? (i.e, do you believe it will be accepted and work?, Do you see incentive from the community to make your proposal into something real?)
Carlos: I don't have high expectations. My proposal may be a little naive. There are far more experienced people in the dynamics of free software on the list to comment, and I am waiting for that.
If you always wanted to help KDE, but didn't know what to do, this proposal may be just what you were waiting for. It is not yet fully implemented, but we hope it will be in a near future, even though Carlos is not very optimist.
Currently, a guide for helping is being written ("Quick Guide to Contribute to KDE") and after that a pilot program will start.
The original paper, containing the full proposal, can be found at http://lists.kde.org/?l=kde-usability&m=107187409020725&w=2.
Integration of non-KDE applications into a KDE-based environment was the subject of the week. Many interesting things are being done in this area, and also much discussion. An interesting thread started when Ralf Nolden posted the following message:
if someone missed the point about the current events of the last weeks: Our job is now to correct any impression KDE is making to the outside world that if someone would want to use KDE, he would be tied to one toolkit and one development environment.
We have to make clear that we do have the power and the force, together with our technologies, to be an *integrative* factor, not one that needs to create its own application set just because we beleive that it's the right solution in the long run. Here, we have to think short term while we can still preserve projects like KOffice to be developed _over time_ to become a speedy and functional replacement of OpenOffice. Until then things like KOffice are _research_ projects, alternatives to test our technologies like Kparts.
The keyword is: create mindshare by code that KDE can integrate:
OpenOffice.org Mozilla GTK/ other toolkits based applications
into KDE as seamless as possible. We cannot deny reality the right to dictate us that sometimes we have to do things that we do not always like to do. To cite Michael Gorbatchev: He who comes late gets punished by life. It should be our way to realize that people tend to think of us as the everything-has-to-be-KDE-or-we-won't-use-it crowd and that we have to do a good job right now to make sure this impression gets corrected and we are the driving factor with regard to uniting both our goal to provide a HIG based, easy to use desktop with a bunch of useful apps that is _at the same time_ *the* desktop that is able to run and integrate any application out there.
One way to do that is to make those apps use our filedialog and printdialog (printing does work in most cases, filedialog is a research project people should look at and maybe make proposals how to change gtk to call the kde file dialog, patches welcome for demo.
Alex Neundorf is working on the OOo/gtk side, so please contact him if you want to be of help, he really needs hands helping him with this particular project.
The other way is to check out the cool things that are happening at freedesktop.org which is in particular the organization that will support us with any integrative work, may it be themes, styles, settings and new features in X.
The above message was followed by a plethora of replies. Ralf's propositions were well received, and some ideas were brought up. Lauris Kaplinski pointed out that Sodipodi already had working KDE integration and Alexander Neundorf stated that he is working on delivering KDE's ioslaves support for all Linux applications. There are also people working on Mozilla and OpenOffice.org integration.
There are interesting threads regarding integration of non-KDE apps in a KDE environment happening at the kde-debian mailing list. As the archives for that list are not public (yet), these are not covered here.
Aaron J. Seigo posted to kde-core-devel saying:
hi all...
so, with 3.2 approaching, here's a bit of a list for default setting changes i'd like to make.. the format of the list is (sorry, no fancy XML ;):
[Component]
new setting (current setting)
notes / rational
i'd like yays or nays on each before i go mad making patches =)
Launch Feedback:
bouncy icon (flashy icon)
KDesktop
text shadow on desktop icon text (no text shadow)
a good set of shadow defaults is needed i think. the current one is not all that nice looking IMHO
Styles:
Icons on buttons. (no icons on buttons)
the button icons now look very nice and would help blend better with other common X11 apps i've heard the "makes things slower" argument, and truthfully i can't see a different even on a PPro 266.
KEdit:
Soft line wrapping (no wrap)
Later on, he added one more item:
Konqueror
add Ctrl+R as a shortcut to Reload ... F5 would remain, Ctrl+R would simply be an alternative default shortcut.
this is the shortcut in Mozilla, and is also supported by IE
Aaron's ideas were well received. Other changes were also proposed. Stephan Binner proposed:
I agree to all your suggestions, and have three additional changes in mind:
Change default menu item format to "Description (Name)". The GenericName descriptions are almost complete, and missing ones can be added fast. Default "Network Information Window"'s system tray icon setting to off. KDE still defaults to non-anti-aliasable fonts and anti-alias is not default? It needs a KPersonalizer run to set anti-aliased fonts. :-(
Also I can't sign the "KDE cannot change default style with every release" and would like more space between menu items and visible toolbar spacers.
Following Binner's post, Lukas Tinkl proposed changing the default style to
Plastik. As every other time this was proposed in the past, a lot of discussion
happened. Stephan Kulow put an end in it nicely: I don't get the discussion. The theme won't change. Or are you going
to update screenshots in 52 languages?
On another sub-thread, Kulow proposed getting rid of the "Network Information Window", and David Faure disabled it. The thread isn't over yet, and recent discussion concern wheter double-clicking its title bar should shade (current behaviour) or maximize a window.
Ralf Nolden proposed the creation of an editor where one would be able to choose which programs to load at KDE startup:
Just to pick up some more suggestions and ideas - one thing that bugs most people is that they think KDE is one big chunk of stuff, AKA bloatware. While most of this behavior depends on our defaults in startkde, I think it would be good to offer people an editor where they can choose which programs to start at kde startup. Of course, that would require reading in a user-dependent startkde file if it exists, otherwise use the system default.
That way admins of large installations can determine the KDE startup a lot better and can even replace the windowmanager easier (you could do that with a combo box which one to choose for instance). I found out that many admins don't know how KDE is started and that it is way easier than they think it works to change KDE's startup; on the other hand users are very picky as well if they don't want to change system wide files but just make their own startup of KDE.
Seen from that perspective, the startkde script is a really outdated system where we should think of something that is easy to customize even for mom and dad as well as the sysadmins that have to do their settings, maybe even over ldap.
Any suggestions, ideas?
Waldo Bastian suggested using environment variables and adding documentation about them to the sysadmin documentation area of kde.org. Lubos Lunak stated that the startkde script might be the wrong place to look at. Aaron J. Seigo said that such an editor was already in his plans:
I have two small utils on my post-3.2 TODO:
an autostart editor. no, the Autostart item in Konqueror is not good enough: it only shows the user's directory and it's a bit of a mystery to average users as to how to manage it. a servicemenu manager (and editor?). it should be possible to turn these things on and off by the user. this will require some changes to the servicemenu loading as well.
Adriaan de Groot proposed:
We (as in KDE) managed to get KTuberling translated. I think that's a pretty impressive achievement, finding kids in 50-odd language to say things like "ear". Wouldn't it be neat to collect "welcome to KDE" or something like that as well, from a bunch of developers in different languages? Then you could conceivably find out what coolo sounds like, or how to welcome someone (to KDE) in Mandarin Chinese.
Mark Bucciarelli proposed adding they to apps' about box, but the idea was proven to be not pratical, since it would dramatically increase the size of KDE packages. Later, Adriaan stated that the thread was deviating too much from his proposal, and made it clear that he intended to put the sounds on the web, not inside the KDE packages. Casey Allen Shobe offered webspace to host the files.
Stephan Kulow told us that finding out what he sounds out is [...] not too hard. Just play ktuberling in german :)