KDE-CVS-Digest for July 11, 2003

Saturday, 12 July 2003  |  Dkite

In this week's digest: The KDE Kolab client nears release. Klaviatura, a simple proof-of-concept on-screen keyboard is added to kdenonbeta demonstrating the possibilities of QAccessible and DCOP. The KDevelop CVS service is improved. Kivio gets loads of new stencils. Konqueror can now create a bookmark folder from open tabs, and can now open pages in a new tab (as opposed to a new window) when invoked from other applications. The Yahoo and Jabber IM protocols are improved in Kopete. KGPG is moved into the official KDE Utilities package. And more. Enjoy.

Comments:

First post, yeahhh...:) - Paulo Dias - 2003-07-12

Thanks for another digest... Can't wait for kde 3.2 :) best regards...

Thanks, merci, Vielen Dank, grazie... - Nicolas Christener - 2003-07-12

it's the piece of chocolate every Saturday. You are my hero ;)

Kolab client - Arend jr. - 2003-07-12

Note that KDE Kolab client 1.0.0 is available as of today :)

Re: Kolab client - TomL - 2003-07-13

Which tar file should we get? Theres kdenetwork-kolab and kdepim-kolab. Do we need both or just one? Thanks.

Re: Kolab client - Arend jr. - 2003-07-13

You'll need both.

Gnome feature - Dashboard - rjw - 2003-07-12

Those old Gnomers have been working on a very nifty feature: http://www.nat.org/dashboard/ This is a "desktop integration" strategy. All your apps send "clues" on a message bus ( eg DCOP) about what you are doing. Eg web pages you go to, conversations on IRC / IM, email you write/read, newsgroup messages you read, sms messages on your bluetooth phone. The next stage lets clues get chained - in an rdf triple kind of way .. listeners can inject new clues. Eg addressbook associates an IM contact with a person. Then other listeners associate the person with other conversations you've had, emails you've sent, photos you've conscientiously tagged, files that've been indexed, bugs in bugzilla, weblogs, news, etc etc. All of these clues are then filtered for relevance, and displayed in a neat vertical bar ( an html widget infact) along side the desktop. This is the "dashboard". Could be autohidey, or a completely different gui.. Anyway, this leads to a great usability feature, the dashboard seems to sense what you are trying to do, and shows a lot of contextual information. Eg talk about a bug on IRC, get a link come up in the dashboard.. The main driver behind this feature is Nat Freidman , Ximian CEO - he reckons it'll be in OSX and Longhorn before too long. KDE needs to be there too. KDE probably needs to get working on a similar feature so it can be in KDE 3.3. Somekind of interoperability with the Gnome one would be brill. This is going to be a killer feature in Gnome, and its a big enough feature and "Wow" factor to sway a lot of people towards Gnome. Really. Gnome is approaching KDE in polish, it'd be stupid to make people choose between a great feature like this and the goodness that is KDE.

Re: Gnome feature - Dashboard - Derek Kite - 2003-07-12

Reading over the whole thing, interesting, but a couple of issues come up. First is how much of it is doing on the desktop what should be done on a server? Google is powerful because they have almost limitless hardware and bandwidth to search. This is typical microsoft, making the client the center, simply because that is what they sell and control. It seems that it is a way to display lots of information. On the navigation sidebar in konqueror, one can display things like rss feeds, weather, etc. And it has a history of all the websites you have visited. There is so much information there it becomes useless. It could have some context added to each link, and a search, etc. But why, when you can go (and I do regularly) gg:whateverIforgot and it is there. Since google is so efficient, how many people even use bookmarks? Sorry lypanov. The IM notifications are simply having in one place what is done individually. The link to the addressbook data is neat, but again lots of information. Essentially having all your incoming messages send notifications to the same place. Like having Kopete integrated into Kontact. After the first 5 or 6, you get lost in a flood of information. Now if something like this could be configurable, maybe. But Nat says explicitly no configuration. So now I depend on my stupid machine to figure out what I want to see? One good idea is the cvs tie in. One could watch cvs commits as they happen, and have easy access to the changes, as they happen. Wouldn't that have a better server-side solution? Something like the kde-commits irc channel, or kde-cvs mailing list? Derek

Re: Gnome feature - Dashboard - rjw - 2003-07-12

You really need to try it. From Nats blog: <i> Pretty nifty. Obviously we're gonna have to start developing some better clue relevance/match quality functions to stop the dashboard from being such a cluttered mess. And we'll need a configuration system of some kind so people can enable the backends they like and disable the ones they don't like. I plan to start focusing heavily on UI in a couple weeks. </i> So I think everyone knows it needs filtering / polishing. Re: the navigation sidebar - I agree, I never use it. I don't think thats because Google is so good though, I think its because its a bit rubbish. - It looks clunky at the side of the browser, feels like its taking up a lot of space ( for some reason a separate window ala kicker etc doesn't feel like this...dunno why). I do use bookmarks, however... Reasons its not google: Its "proactive". Its looking for your stuff before you know you need it. Its not explicitly activated. It "knows" a lot more about what *you* think than google does. Its not limited to the web. Its not so susceptible to privacy worriers like google toolbar. Its just a completely different experience than a search engine... Also, I've always preferred at least nominally client side solutions. I mean, I prefer kmail to hotmail, and knode to gmanes web interface or google groups... Rob

Re: Gnome feature - Dashboard - Mortimer - 2003-12-28

I'm not sure that you really ubderstood the aim of this tool. It's not to trigger your attention on events: like incoming messages. Because IM or mail apps already do this. It's not to provide a central search place, nor another bookmark system. the aim is to provide information regarding your actual work context: - Documents relevant to what you are writting, - web-pages relative to the document you're reading, - personnal information on who you are speaking to, - etc... Dashboard should not display you all the information accessible, but all the one needed. Currently, the filtering method is not really developped: Dashboard is not a mature software but it's still useful. If you want some more information on this kind of tools, see: http://www.research.ibm.com/journal/sj/393/part2/rhodes.html

Re: Gnome feature - Dashboard - Aaron J. Seigo - 2003-07-12

i've seen something extremely simliar to this on another OS... was it plan9? can't remember exactly at the moment. it was basically a command line version of dashboard. yes, i think there are some good possibilities with this concept. there are also challenges with it, though most are of the sort that get less relevant with time and hardware. however, i would ask, since you feel this is such a great feature and a must-have: what are you doing about it? note that i don't mean that question in an "in your face!" or a "shut the hell up, you whiney little be-otch!" manner. it's an honest, open, and IMHO valid question.

Re: Gnome feature - Dashboard - rjw - 2003-07-13

I would like to spend some of my copious spare time on this. But it really needs some cooperation or it turns into a management nightmare - ie maintaining patches for a whole band of other apps.... And my spare time is anything but copious :-(

Re: Gnome feature - Dashboard - Datschge - 2003-07-13

I think regarding KDE a Dashboard alike system could be started by requiring KDE apps having a specific set of DCOP commands which are needed by any Dashboard alike system but incidentally might be useful in other situations as well (accessibility as mentioned etc.). Any idea how that could look like?

Re: Gnome feature - Dashboard - Aaron J. Seigo - 2003-07-14

i think that would be the wrong way around for this concept. not only would most apps find such a mandatory interface less than useful, it wouldn't really save much, if any, work for the app developers. personally, i'd implement it by writing an app that had some sort of a UI for display (HTML sounds a bit expensive from the perspective of desktop real estate, personally) and that had a DCOP interface for accepting hints. to distribute hints, it would emit DCOP signals that interested processes could listen for. they would then register their answers by DCOP'ing the sender of the signal. you may even want to add a plugin system to the main app so as to enable an easy way to add hint translation techniques. this would allow loose coupling and a quick path to development.

Re: Gnome feature - Dashboard - Aaron J. Seigo - 2003-07-14

you don't have to maintain patches for a lots of apps. just implement the core application and have perhaps a test app, or just improve one KDE app as a proof-of-concept. if it is shown that it's working and usable, it will get adopted via the natural processes. just create the dashboard bit, and you'll likely get help with the rest.

Re: Gnome feature - Dashboard - Datschge - 2003-07-12

If nothing else something like this within KDE could become a nice tool for increasing accessibility in conjunction with tools like dasher and klaviatura. But I seriously doubt that something like this will be widely used in OSX or Windows soon. OSX generally has a more application centric approach, and Longhorn won't appear in the next year(s). When do Ximian and/or Gnome intend to include Dashboard as part of their stable desktop version (so we can see the public response)?

A nice way to get monitored - Anton Velev - 2003-07-13

>This is a "desktop integration" strategy. All your apps send "clues" on a >message bus ( eg DCOP) about what you are doing. Eg web pages you go to, >conversations on IRC / IM, email you write/read, newsgroup messages you read, >sms messages on your bluetooth phone. I would say that all this is a very "smart" way to get your self monitored and hacked by an alien "listener" app. I would not likely use this "feature" for a security reasons.

Re: A nice way to get monitored - Anonymous - 2003-07-13

since it will use DCOP (in KDE, anyways) you can "hack" and "monitor" everybody even today -- all apps are DCOP-enabled anyways.

Re: A nice way to get monitored - rjw - 2003-07-13

wtf? This is all local. If someone can intercept stuff on your local machine, you are very likely screwed anyway.. If an "alien" app can get on your box, you have a lot more to worry about than people knowing what you are looking for. That is why this stuff should be done client side - so that no big brother accusations can be made... like Google is getting right now.

Do it all with superkaramba - karumba! - 2003-07-14

Do it all with superkaramba!!! I'm sure it would work ...

Re: Do it all with superkaramba - J Mac - 2003-09-01

What is karamba? Superkaramba? I have been looking for a clear cut answer and have yet to find one...

Re: Do it all with superkaramba - Datschge - 2003-09-01

It's a dynamic multi-purpose extension to the desktop layer. Ie. you can add static and dynamic content as well as script programs resembling the behavior of eg. OS X's zoom bar etc. The problem in the end is that there can't be any real clear cut answer since the possibilities are unlimited. =P

Yeah - Ale - 2003-07-12

This si very intersting and the GNOME camp definitely isn't behind with 2.3 branch its mostly a matter of prefference.

Ugh. Stupid me - Derek Kite - 2003-07-12

I didn't upload to the server. What you saw was a draft. Final version should be there now. Building html tables manually screws with your brain. Derek

Re: Ugh. Stupid me - Datschge - 2003-07-12

Nice. ;) I think you can put the statistics as an own section right after the table of content. Having some basic bugs.kde.org statistics like numbers of open bugs/wishes, opened/closed bugs/wishes within that week and the one product with the most positive opened/closed ratio would be nice. =)

Re: Ugh. Stupid me - Derek Kite - 2003-07-12

Yes, I was thinking of that. Another is http://i18n.kde.org/stats/gui/HEAD/top10.php to give some coverage to the i18n efforts. How about top 10 lines changed. It would be different from the commits. Derek

Re: Ugh. Stupid me - Eric Laffoon - 2003-07-13

> Building html tables manually screws with your brain. That's why I use the structure tree in Quanta if I'm doing complex tables. It enables a degree of structural validation as well as the ability to select segments by node. At least one enhanced table editor should make it into 3.2. Our table wizard only helps with the initial creation now.

Hi Eric - Bob - 2003-07-14

I was wondering if you could make it so that Quanta can save bookmarks after you've closed the program and then when you reopen Quanta, not only will your MRU files be opened, but also at the last line you were at or your bookmarks will be intact.

Re: Hi Eric - Eric Laffoon - 2003-07-14

> I was wondering if you could make it so that Quanta can save bookmarks after you've closed the program and then when you reopen Quanta, not only will your MRU files be opened, but also at the last line you were at or your bookmarks will be intact. We've discussed this and we're unlikely to do it. It's got a lot of messy aspects (aside from being more work in a huge pile). For one we have to save the information somewhere and that means project files or quantarc as creating hidden files for this is a mess. Project files are also a problem if they're shared. Then there's the basic mechanism. If they're auto saved you'll end up with garbage bookmarks, as could still be the case with manual save over time. Do we expire them? Personally I don't want old bookmarks when I open a file because I close the issues I bookmark when it's open. I also write very modular code so this is easy. If we were going to save the bookmarks I'd want it to be a manual load... and that comes back to creating a bookmark file, probably in $KDEHOME/share/apps/quanta/bookmarks. Of course that raises the question of whether we have only one per file or more, which becomes moot if it's not updated by the editor on an ongoing basis for where the bookmark actually is. So the short answer is, if we get sort of bored or this suddenly looks important maybe, but don't expect it in the forseeable future.

Re: Ugh. Stupid me - ZennouRyuu - 2003-07-14

I .:HEART:. Quanta!!!!!!!!!!!!! sorry for the OT but I had to say that ^_^