|
| This Week... |
|
KTorrent supports the creation of trackerless torrents, with work beginning on a web-based management GUI. Support for browsing the SHOUTcast webradio listings in Amarok. Work starts on a new Planner Summary plugin for Kontact. KDissert is renamed Semantik. Maps of more countries added to KGeography. Version 2 of Kallery, a web image gallery creator, is imported into KDE SVN. Qt3 and KDE 3 Java bindings are removed from KDE SVN, superceded by the developments of Qt Jambi.
|
The defining issue of the week concerns the migration of the Okular application from its playground/graphics/ developmental home back into the kdegraphics/ module, which is currently occupied by KPDF (from which Okular spawned) and the recently renamed Ligature in KDE 3.5.
As a matter of course, Pino Toscano, a key Okular developer, wrote a standard request/notification of the move to the kde-core-devel mailing list. However, it was not to be a simple and uncontested proposition, as the 80-message long thread of replies surely indicates.
|
Wilfried Huss, the lead developer of Ligature, replies:
|
So what would this mean for Ligature (formally known as Kviewshell)?
If I remember correctly there has been made a decision, that no applications that are duplicating functionality will be allowed in the core modules. And we are definitely not interested in moving Ligature to Extragear.
|
|
Albert Astals Cid, another key Okular developer, questions this assertion:
|
|
I don't remember such strong decision although i agree some people have expressed this opinion, but for me, in a world where not all solutions are perfect, i prefer to have two quite good solutions so that in case one fails maybe the other works.
|
|
I'll allow Aaron Seigo the role of diplomatic mediator:
|
from a user's POV, it seems that ligature is very much like kpdf 3.5 and okular is very much like an improved version of kpdf. the feature overlap is pretty much 100%, with okular having a superset of them.
both improve on kpdf with things like a "real" text selection tool, overview and facing page layouts, support for multiple file formats, etc ...
ligature has a few nice little advantages: the "read page" nav feature is nice as its scrolling sidebar thumbnails.
okular has a well integrated inline search, has additional configurability for DRM bits and memory usage (to name a few), supports more file formats (numerically and in terms of common desktop relevance), supports reviews (and apparently annotations and what not, as seen at akademy though my build from svn doesn't have those features?), has a "download books from the internet" feature using ghns that simply rocks and has a handful of new UI features ... the UI does need more polishing, but that's not surprising given its in-high-development state.
ligature supports G3 fax and djvu files which okular doesn't, but then okular supports ODT and a number of other interesting formats. if you do a lot of djvu or fax viewing ligature may be more useful. i find okular's format selection more relevant to my usage, but ymmv.
after having used both, i have to say that it would be rather odd to provide both apps by default on a desktop installation due to function overlap.
i can see the following options:- the two teams agree to work on one codebase
- do the same thing we did with cd burners and put them all into KEG and let user demand sort it out
- have the release maintenance team pick one for inclusion with kde4's default set of applications and move the other into KEG
- leave them both where they are because we can't decide and look a bit foolish all over again for having obvious duplication in apps
it seems the first one is an outside chance; the last option would be a shame. the second option is the easy decision though perhaps the third option is better for our users.
i agree with Allen that this is a "nice" job for the new TWG.
|
|
This specific issue reopens many historic 'oversights' attributed to KDE, including the infamous 'duplication of functionality across similar applications', and the 'defined scope of the desktop'.
The proposal and formation more than a year ago of a set of 'working groups' within the organisation of KDE to make decisions such as these reflects the growing maturity of the project - the strength of the Technical Working Group (TWG) should ensure that a difficult (but very much correct) decision is made for the future diverse userbase of the KDE 4 desktop.
|
|
| Statistics |
|
| Contents |
|
|
Bug Fixes |
Features |
Optimise |
Security |
Other |
|
Accessibility |
 |
![[*]](/images/standard/features) |
|
|
|
|
Development Tools |
![[*]](/images/standard/bugfixes) |
|
|
|
![[*]](/images/standard/other) |
|
Educational |
|
|
|
|
|
|
Graphics |
|
|
|
|
|
|
KDE-Base |
|
|
|
|
|
|
KDE-PIM |
|
|
|
|
|
|
Office |
|
|
![[*]](/images/standard/optimise) |
|
|
|
Konqueror |
|
|
|
|
|
|
Multimedia |
|
|
|
![[*]](/images/standard/security) |
|
|
Networking Tools |
|
|
|
|
|
|
User Interface |
|
|
|
|
|
|
Utilities |
|
|
|
|
|
|
Games |
|
|
|
|
|
|
Other |
|
|
|
|
|
|
|
Bug Fixes |
|
|
|
|
|
KDE-Base |
|
Alexander Neundorf committed a change to /branches/KDE/3.5/kdelibs/kio/kio/kfileitem.cpp:
|
fix #15876: if a file name contains a newline, the newline was displayed in the status bar, which m
with this patch all newlines are replaced with a space in the status bar info, so
this doesn't happen anymore. Maybe it could also be replaced by "
" or "\n" or ...
Maybe this could even be moved to KStringHandler cPixelSqueeze ?
Does this still exist in KDE4 or has it been replaced by some Qt function ? |
|
|
|
|
|
|
Maks Orlovich committed changes in /branches/KDE/3.5/kdelibs/kjs:
|
Fix Unicode support in RegExp handling, and also be more robust vs. embedded nulls.
Fixes problems with some cyrillic characters in gmail (#116512)
Makes google calendar somewhat work, though not fully (part #135445)
Also fixes #135246, #101398 |
|
|
|
|
|
|
KDE-PIM |
|
Tom Albers committed changes in /trunk/playground/pim/mailody/src:
|
|
Explicitly delete all message when user chooses to resync a mailbox. This prevents old messages staying alive when the server reuses the same uids. Also caught a crash because the threadTo map did not remove deleted messages, so on a resync it would want to assign an item to a parent which was deleted because of the sync. |
|
|
|
|
|
|
Multimedia |
|
Michael Pyne committed a change to /branches/KDE/3.5/kdemultimedia/juk/jukservicemenu.desktop:
|
Fix the broken "Add to JuK Collection" service menu action for KDE 3.5.
I'm not sure that it ever worked since it's calling a function in the Player interface that doesn't exist, and to my knowledge never existed. In the process I changed it to pass all files to the dcop command line instead of calling dcop one by one for each file. |
|
| | | |
