Table Of Contents
|1.||13 Aug 2003 - 26 Aug 2003||(21 posts)||kdatepicker Today button|
|2.||13 Aug 2003 - 2 Sep 2003||(7 posts)||iCalendar object comments|
|3.||18 Aug 2003 - 21 Aug 2003||(2 posts)||Caret Navigation|
|4.||18 Aug 2003 - 25 Aug 2003||(53 posts)||Autorun|
|5.||19 Aug 2003 - 22 Aug 2003||(18 posts)||KDE Integration of OpenOffice|
|6.||19 Aug 2003 - 27 Aug 2003||(6 posts)||Convert kio_tar to use SubURLs|
|7.||20 Aug 2003 - 22 Aug 2003||(8 posts)||KAutoConfig tutorial|
|8.||21 Aug 2003 - 22 Aug 2003||(2 posts)||RSS Summary page|
|9.||21 Aug 2003||(1 post)||Laptop volume control support|
|10.||21 Aug 2003 - 27 Aug 2003||(31 posts)||Software patent protest participation|
|11.||22 Aug 2003 - 2 Sep 2003||(2 posts)||karm/korganizer integration|
|12.||23 Aug 2003 - 24 Aug 2003||(5 posts)||Devices kicker applet|
|13.||24 Aug 2003||(3 posts)||KDevelop XUL Support|
|14.||25 Aug 2003||(5 posts)||DCOP provate extension|
|15.||26 Aug 2003 - 27 Aug 2003||(8 posts)||KDE Theme Manager|
Sorry this one has taken so long. There should be a great deal of news to cover in this one, and I'll try to be more timely in the future. I've been doing a lot of kde application hacking lately, and I guess it's just a matter of keeping my priorities straight :-) Anyway, on with the news, and I'll try to scrounge up a treat at the end to make up for the irregularity.
Mailing List Stats For This Week
We looked at 1012 posts in 4298K.
There were 290 different contributors. 158 posted more than once. 0 posted last week too.
The top posters of the week were:
1. kdatepicker Today button
13 Aug 2003 - 26 Aug 2003 (21 posts) Archive Link: "[Patch] #48264: added a Today button in kdatepicker"
People: Reinhold Kainhofer, Aaron Seigo, Martin Koller, Stephan Kulow
And in our first installment, Martin Koller provided a patch that adds a "Today" button to the bottom area of the datepicker, and asked someone to commit if it was OK. Stephan Kulow responded that is wasn't ok, that it looked bad in the kicker while it may look good in korganizer. He suggested an API call to enable the button, but leave it off by default. Reinhold Kainhofer responded that he disagrees with Stephan - that the clock applet is the only place where it doesn't make sense. He seconded the suggestion to add the flag, but make it enabled by default.
Crz, meanwhile, was off somewhere else having his cup of coffee.
Martin Koller, of course, agreed with Reinhold, but provided a patch that moved the button to the left side of the input field. He also mentioned another bug that he found.
Aaron Seigo responded that the button looked like a label to him. Andrew Somers said that he thought it was just a matter of widget style. Martin agreed. He also suggested changing from the button to a combobox. Aaron agreed, agreed, agreed, agreed, and agreed. Martin prepared a new patch, and broke BC, to which Aaron promptly objected. The rest of the discussion was on ways to deal with this.
2. iCalendar object comments
13 Aug 2003 - 2 Sep 2003 (7 posts) Archive Link: "[PATCH] iCalendar object comments"
People: Mark Bucciarelli, Cornelius Schumacher
Mark Bucciarelli wrote:
The attached patch adds the ability to read and write comments with iCalendar objects. The COMMENT attribute can be applied to a JOURNAL, TODO, EVENT, TIMEZONE, and FREEBUSY object. The COMMENT tag can appear zero to many times.
I put it the comment attribute in incident base code, but I'm not sure if this is the right place. An ALARM is the one iCal object that does not allow a COMMENT attribute.
Not sure how to implement this restriction, however. It seems stupid to duplicate the code in each of the five objects that do support comments just because one subclass of incidenceBase doesn't. Suggestions are welcome.
By the way, this is how I have KArm currently storing comments. I'll back that out to use the DESCRIPTION attribute until I hear whether this patch gets in or not.
Michael Fair responded that the VALARM subclass might just remove the comments again. Cornelius Schumacher said it's just fine to put it where it is. The convo left with the patch not being applied, though it isn't clear if this was by design or just by happenstance.
3. Caret Navigation
18 Aug 2003 - 21 Aug 2003 (2 posts) Archive Link: "[Patch] quite complete caret navigation"
People: Leo Savernik
Leo Savernik had a lot to say about his patch:
Caret navigation is quite complete now in terms of what the user expects. A fat explanation for a fat patch.
The patch provides the following functionality:
There's still no means to activate caret mode by GUI, but I think I'll add an action soon so that independent people can test it.
All caret related changes are encapsuled in
blocks. Defining this will simply not compile caret mode in (however, I haven't yet tested it).
A detailed explanation of the changes follows:
For navigation purposes, the whole document is treated as a linear list of lines. Each line itself is composed of one to many inline boxes containing the actual characters/objects.
As SGML-documents are represented by trees, the line representation is created ad hoc by the aid of several classes.
Represents the whole document as a linear list of lines. It has iterators to the first line, last line, beginning (before first line), and end (beyond last line) documents and tries to somewhat resemble STL semantics.
Iterates through the lines of a LinearDocument object.
As not every line is necessarily editable, this iterator only delivers those lines which are deemed to be editable/navigable. Works otherwise just like LineIterator and is comparable to it.
Iterates through the inline boxes of a line.
Analogically to EditableLineIterator, this iterator only regards those boxes that are editable/navigable.
This iterator iterates through all leaf-node characters of the document, effectively treating it as a linear stream. Non-character elements are treated as whitespaces.
Btw, these classes are *private*. And it will stay that way. I have yet to come up with a sensible persistent public API for customizing navigation, but that's far into the future. The explanations are here for the people who review the patch (which will be as many as for my last patch, that is: zero ;-) ).
Though the suck factor of navigation has become very low, there are still the following known bugs (to the hundreds of not yet known):
None that I know of.
During the development I had some crashes in the new code, but I think I sorted them all out. There were *no* crashes in the old code ever, so everything not relying on navigation should continue working reliably.
In the course of implementation I had to fix some bugs which were tolerable for a read-only browser, but are inacceptable for caret navigation:
#46224 and dupes (but not #50683, must be investigated separately): x-range mismatches with justified text
I'll commit these changes soon, this time really, I promise.
See patch: http://bugs.kde.org/attachment.cgi?id=2269&action=view
Meanwhile, crz was still sipping his cup of coffee. Oops, there he goes to put it in the microwave, it must be getting cold!
18 Aug 2003 - 25 Aug 2003 (53 posts) Archive Link: "autorun?!"
People: Gav Wood
Gav Wood started this postfest with a question about autorun, he wanted to know whether there is an autorun program that's in the main distribution. Henrique Pinto agreed, and came up with a few ideas. David Johnson said that automounters belong to the underlying system, and that maybe the best option would be to create something that use the available facilities, but that aside, he suggested that a KDED module was probably the best way to go. Most important to him was that the user should be able to turn it off.
Gav then posted that he actually wrote something he thinks would be useful, and committed it into kdenonbeta.
The discussion then turned to whether or not this was appropriate to begin with, and appears to have settled on some kind of dialog box to allow the user to choose the behavior he or she finds appropriate. The exact implementation, however, was up for a great deal of debate, and not much more appears to have been accomplished. Except, of course, for crz making good headway on his coffee.
But wait! In a thread named "New KDE Infrastructure", Gav once again stirred the pot (to the rapturous delight of crz) with the following:
KDE Autorun is, as the name suggests, infrastructure for providing KDE with notification of when the user inserts a removable medium.
Currently only CDs and DVDs are supported, however it is envisaged that Autorun could easily be extended to provide support for Zip disks etc, and perhaps other media such as USB drives.
As my machine is based on the Linux kernel, I cannot code a *BSD/other Unix variant, however there is a minimal amount of platform-dependant code, and it is located in one file. One of the design goals was ease of cross platform use (any BSD coders out there who want to help with cross-platform-ising Autorun, please get in touch).
For those people who dislike the idea of their computer responding automatically to a disc insertion, it can all be turned off with absolutely no performance hit at all with one simple checkbox.
The main design goal was however desktop integration; it is *not* yet another tool to blindly execute a command on insertion of a music disc. It is hioghly configurable from the kcmshell and through judicious use of MIME types and service offers, will not only detect a content disc but initially provide the user with a dynamic menu detailing possible actions. This menu is populated according to MIME type handlers installed on the system and as such even non KDE programs can incredibly easily add themselves to this menu. Autorun can easily be configured to always do only one type of action (including nothing) for a particular disc type.
On entry of a data disc, Autorun can be configured to automatically mount it, to execute a "autorun.desktop" file accordingly, to open up a konqueror window on it, or even to open up a konsole in the relevant directory.
For those of you that like screenshots, here's a couple:
If you fancy taking a proper look at it, KDE Autorun can be found in cvs in the directory kdenonbeta/kdeautorun.
As far as features go, I consider it basically finished. My future plans for it as mentioned in the current TODO include further integration with kmountwatcher (it already uses it fundamentally) and devices:/. Stuff like automatically going to cddb on insertion of an audio CD and giving the CD name to devices:/.
I've had some good feedback from users and I think this would make a really useful addition to KDE; comments?
And other than a little feedback, that appears to be the end of it.
5. KDE Integration of OpenOffice
19 Aug 2003 - 22 Aug 2003 (18 posts) Archive Link: "KDE Integration of OpenOffice"
People: Willi Richert
Willi Richert asked about integration of OpenOffice with KDE. Jan Holesovsky responded that there was such an effort under way, named cuckoo. There were collective cries of ooo and ahh from the crowd. Except for crz, whose mouth was unfortunately full of coffee, and in the process of doing a spit take got it all over Stefan Binner, after which there was a huge fight, with Jan shouting over the ruckus "But what about cuckoo?"
Ten points to whomever figures out what part of that was made up.
Jan did decide to try to draft a proposal for there to be a kde/OOo integration incubator project on OOo, after complaining a bit about how bereaucratic the process was. Hey, we're pulling for you. And when in doubt, remember: Quando omni flunkus moritati.
6. Convert kio_tar to use SubURLs
19 Aug 2003 - 27 Aug 2003 (6 posts) Archive Link: "Convert kio_tar to use SubURLs"
People: Waldo Bastian, David Faure
Laurence Anderson atatched a patch to kdebase th change over to using suburls for archives, in other words, instead of tar:/home/me/archive.tar, file:/home/me/archive.tar#tar:/, and proceeded to enumerate the benefits. David Faure had some criticisms regarding the way that downloads would sometimes happen - downloading twice for one access. Waldo Bastian suggested some kind of intelligent caching. Laurence said he was going to postpone committing it because he's got a few problems with it. Crz really didn't care, because there sure was a lot of coffee to drink.
7. KAutoConfig tutorial
20 Aug 2003 - 22 Aug 2003 (8 posts) Archive Link: "KAutoConfig tutorial"
People: Benjamin Meyer
Benjamin Meyer wrote that he was improving the KAutoConfigDialog tutorial before adding it to developer.kde.org, and asked for feedback. A bunch of developers, in typical KDE developer style, had a bunch of criticisms, which Benjamin mostly agreed to and changed. Crz, however, oh look, the coffee appears to be ready to make its second appearance! Look at him go!
8. RSS Summary page
21 Aug 2003 - 22 Aug 2003 (2 posts) Archive Link: "RSS Summary page"
People: Tobias Koenig
Timo Nentwig asked if Kontact would have an RSS summary page like Evolution. Tobias Koenig said it's already in HEAD.
9. Laptop volume control support
21 Aug 2003 (1 post) Archive Link: "Support for your volumn Up/Down and mute keys"
Willi Reichert started that he had attached a patch for kmilo's on screen functionality, to change column/mute state using dcop calls to kmix. As there was no reaction, crz rushed back to his coffee and patted Willi on the back. Looks like everything came out ok!
10. Software patent protest participation
21 Aug 2003 - 27 Aug 2003 (31 posts) Archive Link: "Software patent protest, could kde participate?"
People: Christophe Devriese, Neil Stevens, David Faure, Dirk Mueller, Christoph Cullman, Aaron Seigo, Benjamin Meyer, Charles Samuels, Russell Miller, Carsten Pfeiffer, Guillaume Laurent, Rob Kaper, Stephan Kulow
Christophe Devriese started off quite a firestorm that ended up with an article on newsforge and several projects being removed from the KDE project (through no fault of his own, I stress) when he said:
The FFII is organizing an online demonstration against software patents. We want you to replace the title page of your project's site with a protest page against software patents (for examples see below) on August 27th. If you don't want to block access to your site you can for example put a small link on the protest page as seen in one of the examples.
The idea is that with software patents many sites running on/serving possibly patent infringing software (read: most free software) have to go offline sooner or later. So why not demonstrate this effect before it's too late?
As I implied, this touched off quite a firestorm, which in quite general terms pitted Rob Kaper and Neil Stevens against the rest of the contributors to the thread. (There were quite a few nuances to the discussion that make this a very general and probably somewhat inaccurate statement). On Aug 25, Stephan Kulow agreed to put a redirect in place.
The thread appeared to die, until it was taken up again in a separate thread which I'll also cover here, titled "Re:www", which was a carry over from a kde-cvs commit, where Neil Stevens asked, "So KDE CVS is now officially a platform for polotical protest?" Aaron Seigo and Christoph Cullman, who appears to have made the commit, stood by their positions, with Christoph stating that he probably should have run it by the other two kde.org maintainers, but that he believes there was no issue with his actions.
Neil Stevens replied that in his view the website was defaced, and around this time made the controversial commits that were covered in the cvs-digest. Several people tried to explain to Neil the difference between what he did and what the community as a whole tried to accomplish, but with no success. The thread then appeared to die yet again.
In yet ANOTHER thread, entitled "Reversions", Neil said:
I have been asked to revert a credit I added to four applications, but no reason to do so. That's not what KDE CVS commit policy says, though:
Don't abuse your CVS account to push in changes with which other developers disagree.
If there are disagreements over code changes, these should be resolved by discussing them on the mailing lists or in private, not by forcing code on others by simply committing the changes to CVS.
However, two admins have abused their status by threatening removal of CVS account instead of obeying the policy and discussing the changes.
Does the policy just not apply to Dirk Mueller and David Faure?
David Faure responded:
Yes, well, for those who don't read kde-cvs, here is the "credit" that Neil added to "his" apps:
s_aboutData->addCredit("United States Army", I18N_NOOP("Preserving the freedom that made this software possible"));
The status of maintainer of an application (within the KDE CVS) DOES NOT give you all possible rights with it. The above is against the KDE policy of no politics (and no, the www.kde.org front page has nothing to do with such politics), therefore YOU are the one who doesn't comply with the established KDE policies. You will not manage to make your case here, you have no case. Just random noise and provocation, as usual. Don't you have anything better to +do?
> [...] these should be resolved by discussing them on the mailing lists [...]
That's exactly what's happening - note how your account is still active - so stop talking about power abuse.
(*) will the next version also "rm -rf $HOME/*" on startup, since you seem to think you have all rights about what you do in your app?
Neil responded that he is perfectly agreeable to reverting both his commit and Christoph's. David responded that what Christophe did was something the majority of KDE contributors agreed with, and that there was precedent when someone tried to do the exact same thing by crediting "old europe", which was also removed, and that action would be taken if the reverts were not done.
Guillaume Laurent commented that the translators would probably have a field day with such commits anyway.
It rather degenerated from there...
So Neil did his remove, and life went on. In a thread called "Kaboodle", Charles Samuels was trying to figure out what can replace it. The concensus was that nothing really could, so he recommended it be readded under new management. Most agreed. Carsten Pfeiffer agreed to maintain kaboodle and hayes in cvs.
Benjamin Meyer, being the opportunistic guy that he is ;-) begged with sugar on top to put kinkatta in place of kit until kopete was moved. No one agreed with this, but this did act as a catalyst to finally move kopete to kdenetwork. The peasants rejoiced, and crz even toasted with his coffee.(ed. [Russell Miller]
This was a hard one to cover for several reasons. First off, I had to decide whether I was even going to cover it in the first place, considering the highly volatile nature of this discussion. Derek, by covering this in the CVS-digest, kind of forced my hand (kudos to Derek, by the way).
So with the decision of whether to cover it out of the way, the next decision was how. It's no secret that I considered Neil's actions to be very out of line, but it's also my responsibility to try to cover this in a fair manner. I hope I succeeded. The lines were really blurred here between what made something a flame and just heated discussion.
I hope I did these threads justice. It wasn't easy. Not everyone will like how I covered it. Fine. If someone who was directly involved cares to take serious issue with something here, and I agree, I will take steps to rectify the situation.)
11. karm/korganizer integration
22 Aug 2003 - 2 Sep 2003 (2 posts) Archive Link: "more on the karm/korganizer integration"
People: Tomas Popisec, Mark Bucciarelli
Tomas Popisec said:
While Mark was furiously hacking at karm with his sore back I wasn't idle and instead was visiting Prague and ... doing a little bit of hacking too.
The result is:
A KListView subclass that has a context menu that pops up when clicking the RMB inside the header and presents you all the columns which you can hide or show.
I did this because I want to have all the nice korganizer-todo properties inside karm (and vice-versa), but I also want people to be able to configure what todo properties they see so that it won't clobber their screen.
A new subclass of QListViewItem that integrates a QCheckListItem with Karm's running clock.
I did this because the Karm fraction loves being able to double click on a task and having the task start/stop running and the Konqueror fraction loves being able to double click a todo and be able to edit its properties and click the checkbox and be done with a task.
The idea is here again to eventually integrate korganizer and karm.
So I've integrated the checkbox with the clock:
You can find an illustrated example here:
Please speak up if you think this is a really bad idea. Otherwise I'd like to proceed and commit this to CVS so people can play with it. The next step would be merging of korganizer's todo list classes with karms and moving them to llibkdepim (and of course integrating Mark's huge patch)
Mark Bucciarelli asked why keep the GUIs the same, and wondering how to display completed tasks in karm. He suggested that tomas wait. Hmm, it looks like our friend crz is slowly draining his coffee. Good on you, crz.
12. Devices kicker applet
23 Aug 2003 - 24 Aug 2003 (5 posts) Archive Link: "Introducting and Devices Kicker Applet"
People: Kevin Ottens, Aaron Seigo
Kevin Ottens said:
I've made an applet for kicker that allow to have your devices easily reachable. I find easier to have them in kicker than on the desktop.
Aaron Seigo was uncharacteristically effusive in his praise for this applet, and suggested Kevin import it into KDE. It was unknown whether he did or not. Crz suggested a coffee:/ kicker applet, but that was politely turned down.
13. KDevelop XUL Support
24 Aug 2003 (3 posts) Archive Link: "XUL suppo rt in KDevelop"
People: Zack Rusin, Chris Howells
Zack Rusin announced thusly:
yesterday George asked me to do a kaxul (in kdenonbeta) presentation with him today. I figured that having the Mozilla XUL rendered with native KDE/Qt widget is not impressive enough, so yesterday I checked out the KDevelop for the first time ever (I'm a huge Emacs fan :) ). And spent some time with it. The outcome: first C++ and XUL IDE ever created. I'm attaching the tarball of the stuff needed to get a working XUL dev. environment. The code completion is currently wrong, I'll fix it later today, but it should show the top level tags as classes, single tags as variable and soon the commands as methods. It depends on KaXul with which you get thumbnail preview for the files you are working on, the general (big) preview of the XUL interface you are working on. I just wanted to know what's the opinion on that and whether I should put it somewhere. I mean it might be way too big advantage for the Mozilla project to get an actual modern IDE that can be used for the whole Mozilla ;)
It is very freaky stuff and I acknowledge that. The bottom line is and I think George and I proved it again this time, there's nothing that impossible in KDE :)
Chris Howells asked for a screenshot. Zack obliged. Crz sipped.
14. DCOP provate extension
25 Aug 2003 (5 posts) Archive Link: "DCOP private Extension (k_dcop_private:)"
People: Martin Konold
Martin Konold said:
Our current DCOP implementation basically lets you decide which parts of your application are exposed to every other application via DCOP.
By using k_dcop: everything within the scope of this declaration is exposed to everyone.
By exposing the functionality via DCOP actually this interface becomes part of the API of the desktop and shall remain compatible and be maintained for rather long times.
The situation is not as bad as with libraries but still an author cannot be sure if any 3rd party is relying on the DCOP interface.
The result of this is that it is often no good idea to offer unstable interfaces via DCOP.
On the other hand it is oftern very useful to expose unstable APIs in order to allow for DCOP based applications like Kontact. Having a rich DCOP interface also allows for easier unit testing and automatic regression testing.
Make exposing functionality via dcop possible while hiding it from normal dcop clients.
This boils down to a concept like the oo public, protected, private and friend declarations.
After some discussion today at the Kolab meeting and consulting with Ian Geiser, Alex, Ingo and many others we saw that something should be available to be able to expose e.g. kmail functionality without haveing to fear that people not familar with the status of the API will use it.
The simple solution to the needs could be to add the following two new macros:
k_dcop_public: This is supposed to be a synonym for k_dcop:
k_dcop_private: This is is to tell the dcop idl compiler to _not_ publish the functions +but still making them fully accessable if the caller happens to know them.
I propose to consider to ask for some assistance by the build system so that developers wishing to use k_dcop_private: can use Alex new dcop idl compiler instead of the old yacc stuff.
Somewhen in the future (probably after 3.2) we can phase out the old dcop idl compiler and fully switch to Alex's new implementation so there will be no permant need for keeping two dcop idl compilers.
I think the proposed simple solution is a rather save approach. Basically not too much bad things should happen. All current applications which wish not to make active use of the new feature are not affected.
Applications like kmail/kroupware and kontact who desperately are in need of this feature can risk to use the new dcop idl compiler and therefore prevent innocent users from using the private API while allowing others kdepim developers to closely coordinate.
No changes to the dcop protocol nor the dcop server are required.
And all were happy. Except for crz, who was starting to reach the bottom of his cup of coffee and was looking a little sad.
15. KDE Theme Manager
26 Aug 2003 - 27 Aug 2003 (8 posts) Archive Link: "KDE Theme Manager"
People: Aaron Seigo
Aaron Seigo wrote stating that he would like to see the Theme Manager removed, as it's outdated, unstable, poorly maintained, and a hindrance. Everyone agreed, some with extreme prejudice. Benoit Walter wrote to say he was working on something to replace it. Most seemed to like it. Crz was really scraggling for that last dreg.
Shipping prices on spaghetti sauce haven't gone down any, so I think I will share with you a nice recipe (uga take note!) that I made up one day. I call it chinese style spaghetti. It's quick, and it's very tasty.
Boil up some spaghetti. In another pan, saute some mushrooms and maybe onions in lots and lots of butter. Prepare the spaghetti as directed on the package. Once the spaghetti is done and the mushrooms are sauteed nicely, mix them together in the frying pan with liberal amounts of soy sauce. Saute it nicely until the spaghetti is just a little crisp and the soy sauce is all over everything. Serve.
For those of you who don't like to eat, how about A site all about urban legends? (http://snopes.com) .
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.