In this week's KDE Commit-Digest: Sonnet, the natural language checker, continues to develop and can now discriminate between more than 70 different languages. More work on the "konsole-split-view" branch to add split/merge functionality to the KDE 4 console. Support for filesystem labels in the "mountconfig" Guidance configuration module. Large developments in the "mailtransport" KDE-PIM work to enable code sharing between users of the common "emailing" action. Support for background text colours in Konversation. Further work in the "Papillon" MSN Messenger connection library, with support for Xtraz status and notifications in Kopete. Gradient editing tool introduced across KOffice. Better support for PDF presentation files in Okular. Improved AI in the recently-imported game KSquares. "Sublime", the new user interface library for KDevelop 4 is imported into KDE SVN. The initial code for KRunner, the KDE 4 replacement for the "Run Command" dialog, is imported into KDE SVN. The RSS Konqueror sidebar plugin is removed from KDE SVN, along with dcoprss and librss, which will both be replaced by libsyndication in KDE 4.
Comments
There are a few technical issues with this digest (namely the lack of extended statistics and revision information pages/visual changes/etc.) that I will fix Monday morning when I wake up!
Thanks for your patience,
Danny
Also, some characters are badly encoded: "Rafael Fern�ndez L�pez" instead of "Rafael Fernández López". The special characters are in ISO-8859-1, however the page is sent as UTF-8. Conversion from the original to UTF-8 is faulty.
Wow... sorry for the mess. Sorry Danny... xD
/me wonders why his name has strange characters :P
All the technical issues with this digest should now be fixed.
Danny
Thanks, Danny :)
I really really dig what is going on with the uiserver!
Wouldn't it make sense to make a plasma component to show the uiserver information? There could be a component in the panel to discretely indicate activity that would expand into a pane on the desktop containing the progress information and the interaction buttons when clicked. It could also have mouseover information.
The uiserver information is some kind of system state that could perhaps be more logically presented in this way than in a regular window. This would of course be optional so you could still have the traditional interface if you prefer or if you don't run Plasma.
> Wouldn't it make sense to make a plasma component to show
> the uiserver information?
Yes. But in order to write and display a plasma component, you need the Plasma application and libraries.
one also needs all the uiserver bits and knobbles first anyways. not to mention we need this as a backup in case the user *gasp* isn't running the plasma workspace ;)
we discussed how to handle this gracefully last week actually
I realise that you would still need the normal implementation and it makes perfect sense to start with that. Hence the last sentence in my post above. My suggestion was in no way meant as criticism of the current work.
It's great that you are already thinking about how to incorporate this component into a seamless desktop environment!
Could someone please explain to the non-C++/Qt-fluent audience here what the uiserver's basic task and role for a KDE desktop is?
The non-technical name for the uiserver makes things clearer.
This is the "KDE Task Manager". It keeps track of all the long running tasks, such as downloading files, burning CDs or fetching emails which are in progress. It provides a central place to see the progress of these tasks and in some cases control them ( pause a download or cancel a CD burn for example ).
At the moment it only shows tasks which are in progress. In the future it may also show tasks which have been completed.
Task manger is unfortunatly a very bad name for this, since users from Windows know "Task Manger" as a tool ekvivalent to KDE System Guard.
Since it keep track of the progress of running task, I think Progress Manger vould be a better description:-)
Probably is not the best name. It is not the name that will be on the kde 4 release... I think your suggestion is OK.
Since I haven't committed yet I can update it.
Thanks.
My native language is not English, but IMHO it sounds a bit weird that one wants to manage the progress, and not the process that is progressing. What do you think about "Background Task Manager"?
Thinking about it, the term "Background" could be mislead non-technical users. Maybe something like "Autonomous" would be better?
How about "progress monitor" or something then? Maybe even something like "The Progressor" :-D
Progress Monitor is okay if one can only monitor the progress but not e.g. stop the process.
"The Progressor" sounds good...
I like Task Manager.
Or maybe Task List, Job List, etc.
I like Task Manager, too, but the post by Morty on Monday 08/Jan/2007, @06:02 remains valid, though...
The Progressor sounds stupid. Progress Monitor is self-descriptive...at least much more so than "The Progressor". Sheesh.
Thanks for the explanation, Robert.
And this thingie also already had/has an incarnation that is in KDE3? Is it showing itself in the popping up progress bars once you start downloading a file or two?
"[...] to see if we can co-operate and co-ordinate, letting Mathusalem list KDE jobs, and then of course, enabling uiserver to list GNOME jobs. This is possible because Mathusalem (and GNOME) uses D-Bus too."
Yes! Finally, cooperation. As I read about KDE's great features, I often think, "What about non-KDE apps? I do use some - and they won't be able to use any of this." But this is good news. And, it's great that D-BUS is proving that it can in fact unite different desktops.
> I do use some - and they won't be able to use any of this.
Sure they can, the libraries are available for all applications to use.
There is no technical reason why an app can't use this stuff.
More important for this project should be to coordinate with the KGet developers. Since there is lots of functinality overlap between the two.
Cooperation inside of KDE is increadibly more important than possible cooperation with random non KDE projects. It's a case of having the left hand know what the right does etc.
likewise, i guess kget and ktorrent dev's should talk, as kget is rumored to get torrent support (and copying ktorrent would be a waste of time, right?).
Comunication in a project is always good, and the waste of time comment I agree completly on.
In my oppinion the simplest and correct solution is to not implement torrent support in KGet at all. Since KTorrent already does the job quite well, and more importantly torrents does not fit into the usage case of KGet. KGet should download the qued items and quit, and allowing for pausing of downloads and restarts of broken connections. Manging upploads, share ratios, trackers and seeding does not fit into this. It will only give rise to (unneccesary) more complex UI and code for no real gain.
Then again KTorrent should obviously have an option to provide progress indication using kio_uiserver.
I think bittorrent in kget will be useful only if it will be part of metalink ( http://www.metalinker.org/ ) support.
finally?
d-bus, mimetype specs, etc, etc haven't been enough for you? ;)
Danny: just wanted to say that like the "new" format (I hadn't looked at the digests for a while, so I'm not sure how old it is)
I'm really looking forward to the KDevelop developments. Depending on the project, I use either Kate, KDevelop, Visual Studio, or Eclipse for programming. Eclipse has some really nice ideas, but its C++ support is poor, and its support for embedded development is miserable, but Visual Studio and KDevelop aren't usable for my embedded work at all, so Eclipse is the only choice. Visual Studio + Cygwin offers the most efficient programming environment by far in my experience, but Windows itself is no good for development. KDevelop is the IDE I want to like the most, so I'll be watching with much anticipation to see whether v4 manages to achieve a well-integrated IDE for C++. The ideas sound promising! :)
Ellis. Could you please describe your embedded development workflow in our wiki page http://www.kdevelop.org/mediawiki/index.php/KDevelop_4_Proposals ? If you have ideas/suggestions on what features you'd wish for that, please add them also. We need to know what is needed because embedded development have never been our target.
Ok, but I'll have to give it a try again first to remember exactly which things don't function properly. Part of the problem was related to the sequence of MI commands needed for remote+embedded debugging... I'll try to look at the problems again soon and then add a suggestion to the wiki.
Thanks Ellis - 40 weeks now, since 2006-04-09 ;)
Danny
I was wondering why does KDE need a replacement for the "run command" program. I find it just perfect. What does KRunner offer to KDE than its predecesor didn't?
Well, if it runs as a separate process, maybe it can run with higher priority, giving it higher responsiveness when your system is under heavy load. Also, when kdesktop / kwin locks, you will still be able to launch programs without resorting to the command line.
yup, and kdesktop is not available for kde4, so the 'run command' of kdesktop needed to come back in some way, either glued to another process or as a seperate process
Quote from Aaron J. Seigo:
"---
the new skills of this successor include being able to have multiple consumers of the entered text each of which can offer possible matches (think: search). it will also include such things as access to servicemenus (of konqi's action context menu fame). and it already does things kdesktop fails to do such as restart reliably in the case of a crash =)"
there is no "run commmand" program in kde2/3. it's a dialog inside of kdesktop. if kdesktop is to be replaced, we need to put that dialog (and the screensaver stuff) somewhere. i don't want it as part of another app like plasma since that raises the possibility that the user can lose access to the run command feature in case something goes bad with plasma. this happens with kdesktop already when it crashes; in fact, just this past weekend someone asked on irc how to get the run command dialog in kde3 after they'd accidently killed kdesktop by clicking on it after pressing ctrl-alt-esc ;)
in addition to practical requirements (kdesktop going away) and finding a safer place for it to live, it is also getting new features.
does that answer your question?
ctrl+alt+backspace is always your friend after successfully killing kdesktop using ctrl+alt+esc.
hell, no, why not use kicker or any other running thing to restart kdesktop?!?!?
indeed, just start a konsole, open yakuake or whatever, type kdesktop & and your back online ;)
throw out the baby with the water or what
Indeed :) Thanks Aaron.
Won't that make it quite slow? Starting KColorChooser (simplest app I could think of) takes about 1 second on my system, but alt-F2 takes about half a second. Quite a difference.
Besides if plasma crashes shouldn't there be some thing running to restart it like windows does with the shell?
KDevelop 4 looks soooo promising. I hope version 3.4 will be released soon, and work on version 4 can be done with full pace. And I want to use the (big) improvements of 3.4 ;).
The KDev team did a really nice job with 3.4 - I'm confident KDevelop 4 will be the best C++ IDE on all supported platforms :)
We plan to release it together with KDE 3.5.6. The estimated date of KDE 3.5.6 is January 23rd.
Thanks! Nice to read that.
I'm looking foward to a really great release.
Ooh, that's my birthday :)
That'll be a nice birthday present!
Uhm...so they said out in '06 for sure in the IRC chan...what happened? I see the changelog is huge and it's been some time...why not release? Erm... o.O
It's really quite simple - we wants 1.4.5 to be just right, because it looks like there is concensus that it will be the last release before development starts on 2.0. This is still up for debate, of course, but so far people seem to be leaning that way. So - it is not yet released, because it MUST be perfect. :)
I saw the svn repository of the new syndication library, and it manages enclosures and podcasts. Can we hope a new akregator wich can manage enclosures (like RSSOwl, Feed'n Read, liferea... )?