KDE Commit-Digest for 28th January 2007

Monday, 29 January 2007  |  Dallen

In this week's KDE Commit-Digest: KGoldRunner begins the transition to a scalable graphics interface. Okular gains support for DjVu metadata, and investigates the use of threaded text extraction in order to prevent interface freezes. Continued improvement in the font KControl configuration module. More 3D and contemporary effects in the kwin_composite branch. Multiple, discriminatory language spellchecking develops in Sonnet. Improved support for BMP and ZIP files in Strigi. Import of user documentation for Mailody. Optimisations in the Dolphin filemanager. An important stage in the replacement of KDesktop elements with KRunner is completed. KTorrent makes exploratory moves towards a KDE 4 port. KSirc, an IRC client, is removed from KDE SVN.

Comments:

Kwin effects - Patcito - 2007-01-29

> Effects can now request windows to be subdivided into multiple quads. is that expose like? > Adding WavyWindows effect which makes all windows wavy. Meant to demonstrate possibilities of vertex transforming and for cool screenshots ;-) kool! I guess it's a matter of a couple of weeks before we get the whole cube thing :) I 'd love to get the skydome though like in beryl. Anyway, thanx A LOT for all the hard work.

Re: Kwin effects - Eike Hein - 2007-01-29

>> Effects can now request windows to be subdivided into multiple quads. > is that expose like? No. It means that an effect plugin can request that the rectangle of an individual window can be subdivided internally, adding new vertices within, which can then be controlled (i.e. moved) by the effect, for example to give a window the appearance of wobbling. Note that kwin_composite already has an Exposé-like effect, however.

Re: Kwin effects - Lubos Lunak - 2007-01-29

It can be seen in the (very) last video from http://www.kdedevelopers.org/node/2651 . Expose-like effect is the first one.

And the weekly Thank you! goes to: - F3 - 2007-01-29

Danny :)

Diff link broken for new files - S Page - 2007-01-29

I mentioned this before but didn't see an acknowledgement. If you click the _Diff_ link for a new file, ViewCVS.py generates an error. E.g. for "script to help porting in the kinstance-redesign branch", _Diff_ is a link to http://websvn.kde.org/trunk/KDE/kdesdk/scripts/qt4/convert-kinstance.pl?r1=625898&r2=625899 But this new file didn't exist in r1=625898, so you get a 400 Bad Request error, "Invalid path(s) or revision(s) passed to diff" It would be nice if the digest detected that a file is new, for example, provided _View new file_ instead of _Diff_. Many, many thanks for the commit-digest!

Re: Diff link broken for new files - Danny Allen - 2007-01-29

I'll fix it during the code cleanup and enhancements I plan to do over the next few days. Thanks, Danny

kcmfontinst - thanks! - logixoul - 2007-01-29

The face lift kcmfontinst got is awesome! I've been hating that interface from day one. Thank you Craig.

Re: kcmfontinst - thanks! - Craig - 2007-01-29

Hmm... Well something's wrong on your system. The 'A' column should not be visible in that mode - this column is used to indicate if a font is enabled or not. The installer now has 2 modes - basic installation (as shown in your screenshot), and font management (which will allow fonts to be enabled/disabled, and the creation of font groups). Also, its now fontinst (not kcmfontinst).

okular speed? - Lee - 2007-01-29

It seems like okular is taking on a similar amount of plugin views that konqueror had with its kparts (for pdf, html, images, etc.), if not more. Although I like konqueror's features a lot, it was always a little too slow for actually browsing and managing files with, and I suspect part of it was due to all that kparts overhead. Dolphin is much faster, at least. This raises a few questions, for me: Is okular intended to be a refactoring of konqueror so that konqueror will be faster, or is konqueror still going to be a viewer too? Also, how fast will okular be, if I just want to view a PDF, or a PNG file? Do all the extra formats (or even just the generic format layer) add much overhead? Will it be as fast as KPDF, for example? How generic is the interface for all these things? If okular can view PDFs and scientific image formats and eBooks, won't some of the toolbar buttons/menu entries/etc be duplicated, unnecessary, or confusingly labelled? Finally... what's wrong with just using libraries to keep most of the common code in, and having different front ends for different viewers, like a PDF viewer, an eBook viewer, etc.?

Re: okular speed? - Robert Knight - 2007-01-29

> Although I like konqueror's features a lot, it was always a little too slow > for actually browsing and managing files with, and I suspect part of it was > due to all that kparts overhead When you say "faster", are you referring primarily to startup, speed of changing from one folder to another, speed of loading folder contents, speed of file operations ( renaming, moving etc. )?

Re: okular speed? - superstoned - 2007-01-29

none of the above has anything to do with the kparts, right? konqueror's speed with filebrowsing had nothing to do with kparts or the fact it could view eg pictures or wordfiles. konqueror wouldn't be a nanosecond faster if it didn't have the ability to view wordfiles or be a webbrowser, sorry.

Re: okular speed? - Lee - 2007-01-31

Well, dolphin is much faster, and the primary difference is that it doesn't support kparts etc. I don't know for a fact that Konqi is slow because of kparts, and I'm not saying that. I'm asking if the move towards okular is an attempt to fix konqi's speed, or if the speed issue has even been looked at in okular (ie, if it'll repeat the same mistake, without even realising it until it's too late).

Re: okular speed? - Morty - 2007-01-31

Okular is a document viewer, and has nothing to do with Konqueror. So there is no move, and it will not have any effect on Konqueror. Other than Okular providing Konqueror with kparts for viewing different kinds of documents, like pdf.

Re: okular speed? - Lee - 2007-01-31

I'm referring to what feels like "overhead" -- things like actually loading the app, loading/displaying widgets on toolbars, etc. Not things like moving files, or listing dirs, as they're not TOO bad, and I suspect any issues there would be due to lower-level stuff like the filesystem or KIO.

magic solution - eMPe - 2007-02-03

*get more RAM*

Re: magic solution - Lee - 2007-02-15

I have more ram, but I'm using it for other things, thanks.

Re: okular speed? - eMPe - 2007-02-03

I'm sorry to say you have absolutly no clue what you're talking about. However, fear not the slowdown of kde, it will not be.

Re: okular speed? - Lee - 2007-02-15

Please control your emotions. I'm just asking a question.

About Gwenview - Shamaz - 2007-01-29

I'm very happy to see the move of Gwenview to kdegraphics :). With kde4, I see several applications changing their names. Many are removing the "K" in the name. I have no problem with a "K" in the name. But the "G" of Gwenview... makes me think of Gnome :\. So IMHO, in this particular case, a renaming might be needed. Anyway, thank you Aurelien for continuing the maintainership of Gwenview.

Re: About Gwenview - superstoned - 2007-01-29

nah, gwenview is pretty well known, and if it gets its gui update, it'll be a perfect KDE app. what's wrong with a G in the name, then?

Re: About Gwenview - gerd - 2007-02-02

The problem is the "view" because it is English but KDE has to safeguard langauge neutrality. Gwen seems to be a personal name.

ktorrent and all p2p - a.c. - 2007-01-29

I really wish that the p2p's would split apart the client from the server. It would be nice to place the server on a different machine that is on the network. In fact, with the proper arch, a server could handle multiple protocols. Then the client part could be moved into a KIO along with the recent background progress meter that was shown.

Re: ktorrent and all p2p - Diederik van der Boor - 2007-01-29

Well mldonkey does this.. It's has a KMldonkey front end too.

Re: ktorrent and all p2p - Morty - 2007-01-29

And the same for giFt, and the KDE frontend is named Apollon. All that said, the mess that is mldonkey is a particular good example of why this is not a good idea. I'd say keep the applications simple and stable, whitout the unnecessary complexity and overhead of a server client architecture. Centralized progress information can be done via the new KJobs progress monitoring regardless.

Re: ktorrent and all p2p - Ben Morris - 2007-01-30

Great thought MLDonkey is, and KDE-ish thought it can be with KMLDonkey, its bittorrent support is not very nice at all right now. It's slower than normal clients, starting torrents is a little odd, and it doesn't seem able to look for a sensible port (i.e. if you are running Democracy or something and the specified port isn't available, it just doesn't start and you have to check the logs to see why). AFAIK, bittorrent support is still being improved though. However, daemon and client isn't very kde-ish. The best way to split ktorrent would probably be to work on minimising memory usage of GUI-related stuff while ktorrent is in the tray.

Re: ktorrent and all p2p - fish - 2007-01-30

Museek has it as well. I let the core run on my server and connect to it with the GUI on my laptop. Genius! ;)

Welcome back ... - Mohasr - 2007-01-29

... Thomas Lübking :-) any screenshots/mockups for the underconstructing KDE4's new shiny skin ?

Nice to see the progress week after week. - kollum - 2007-01-30

Thanks Danny for the dommit digest. And thans to the KDE devs who make the content of this digest :) Nice to see the Sonnet langage auto detection works, and to have Gwenview continued in KDE4.