In this week's KDE Commit-Digest: 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.
Dot Categories:
Comments
I see a lot of development in kopete, and just get sad. :(
Because none of this is coming to the current KDE3 version, and KDE4 is probally still a year away.
This makes me just want that google port talk to Linux ASAP :-P
Just a me too. Got used svn up'ing ot every day, and lately all developement it's just on kde 4 so i can get the new stuff ...
I think exactly the opposite...
It's a shame that still so much work goes into 3.5. If all commits went into 4.0, we would get kde 4.0 much faster.
There are much nicer Jabber clients out there other than Kopete. If you like Qt you can try Psi or Jabbin (fork from Psi's dev branch supporting Jingle). If Qt is not requirement you should definitely try Gajim.
Wow, is it just me or does the Oxygen icon set look really professional? The visual diffs for the icons have become the first thing that I look at each week. Honestly, I'm consistently blown away.
As a request would it be possible to do a step by step walk though on how one of the new icons was created. If such a document already exists could someone post a link. Thanks.
Keep up the great work, the team should be proud.
They really look good big, but I'm still have to see how they will work on the desktop with 22x22, 16x16 and 32x32 toolbars, you know, not everbody have a giant monitor with a high powred video board to get 3000x2000 resolution :)
For now, I'm just using Human (from Ubuntu) themes on my KDE because they work well on small sizes.
but I'm still have to see how they will work on the desktop with 22x22, 16x16 and 32x32 toolbars,
Ditto.
They'll probably have to redo most of the icons to fit them into smaller sizes.
I'm using the oxygen icons right now and they work fine.
No doubt that they work, but do they look good? Or will KDE hunt it's users with them ;-)
Theses are working fine because we are testing every size when we are making them. I've a little script that make that for me (16x16 to 512x512). And if an idea doesn't work well on small size, it's rejected. And if it need adjustement, a specific SVG is done for 16x16 and 22x22.
Second point, we are already using the Oxygen style on our KDE 3.5 to test it in "real life", to see what we need to change.
Thanks for this reply, your work, and no offence...
No offence, this is a legitime (and usually) ask. I'm just trying to explain how we are working with my poor english (its explain the missing humour and diplomacy) ;)
I am no native speaker, too. Again, thank you. Oxygen definitely rocks!
Good to know that you are working for small icons too. I'm very happy with it. Keep the good work and thank you :)
The Ubuntu Tangerine theme and the Tango theme have some good icons, too. I suggest adapting as many of those icons as possible (ie. make them shinier) but focus on creating new icons that don't already exist in Tangerine and Tango.
> They really look good big, but I'm still have to see how
> they will work on the desktop with 22x22, 16x16 and 32x32
> toolbars
Yeah, I hope that, too. That's the main reason I don't use Crystal because the icons on quickstart bars and in the taskbar are mainly a blurry blue something and are hard to distinguish. Look at Quanta, Kontact, KJobviewer and Konqueror e.g..
I like the trick of Gnome/Human/Tango/Firefox icons: a dark outline with a bright line next to it. These icons look very sharp at low resolutions.
Plasma seems still to exist only in /dev/imagination
When will we see KDE4? Is there a roadmap? How can we help?
But from the plasma roadmap the development is finished. The next phase is integrating into KDE.
The roadmap is just that, a roadmap. Nothing is available from Plasma yet
Please, pretty please with sugar on top, make a new clean start with KDE4 and remove all duplicate apps from the default modules.
According to my reading of the Okular / ligature discussion there is already a policy of not having two applications which provide the same functionality in the same module. Which applications were you thinking of?
I'm not quite sure what you mean by 'default modules'. The only required parts for a KDE desktop are kdelibs,kdepimlibs (KDE 4 only) and kdebase. After that it is up to the distributions to decide what to ship.
I'm hazy on the timelines here. I know Okular was a SoC Project (which year?) forked off kpdf and developed in Playground until it was considered mature enough. So where did Ligature spring from and when? If it too was a fork of kpdf or kghostview, was it was developed in trunk instead of playground (and if so how was that ever allowed?), or did it just get imported to trunk before okular requested?
This one has been brewing for a while, it's a shame that 2 such excellent developers can't find the common ground they need to at least build a common back-end. Document viewing is a core task for kdegraphics, like file dialogs and print and scanning services, that shouldn't be duplicated, but there might be room for different front-ends in keg designed to perform different tasks (view only versus edit/annote).
John.
P.S. Please tell me that kedit/kwrite/kate will finally get merged into 1 basic and 1 advanced editor using the same text widget????
Ligature is the new name for the well known and loved KViewShell. It is NOT a fork of KPDF or something like that. The discussion on them merging/cooperating/whatever seems to popping up each time one of them is mentioned. I really don't see how discussing this from the outside again and again is going to help. The effort might better be spend doing something more productive, like translating stuff, triaging bug reports, testing, writing code, donating, etc.
KWrite and Kate already *ARE* exactly what you ask for. Just KEdit is a left over that has been kept around in KDE3 for its RTL writing capabilities. I understand that that has already been implemented in KDE4, so yes, KEdit will disapear.
> Ligature is the new name for the well known and loved KViewShell.
LOL. Loved? Many distro's don't even install it by default (like kubuntu)
In its 3.5.5 incarnation it can only show formats that are so rarely used that you can be sure 99% of the KDE using public never used the app.
I use it quite frequently for DVI files. It's also much faster than KPFD/Okular, so I prefer it.
BTW: you do know that 86,7% of all statistics is made up, don't you? I feel your 99% falls in the same category...
Kedit will die ?
It would make me sad, because Kedit is so much faster than Kate and Kwrite !
If I have a .txt to read, it's in Kedit.
If I have to work on a text file, that's whith Kate.
For me Kwrite is useless, because too slow, whith to much feature in order to just read a text, and just not as good as Kate for editing. But some people like it.
If Kedit die, make Kwrite much more faster to start, or even Kate.
There will always be fast text viewers around. Here's one for example:
http://kde-apps.org/content/show.php?content=41031&PHPSESSID=ba143c2e5c5...
don't worry, kwrite will be faster in KDE 4, as will all KDE 4 apps ;-)
agreed.
Why does it bother you so much? Do you think those developers would otherwise automaticly be working on something else in KDE? Think again.
A bit of competition isn't bad. It can trigger nice developments and new ideas. These sometimes need a bit of time to mature, so you need to give developers some leaway to play around and try things their way before having to negotiate each change with a bunch of other developers. This duplication might seem a waste of effort, but I tend to disagree.
Would you claim linux is a duplication of windows? Or GNOME of KDE? Neither would I.
> Why does it bother you so much?
In contrary to what you imply in your reply, the poster was pointing out he was worried about duplication in the kde-release. Not the generic duplication of effort.
As you should know, KDE aims to be a usable and complete set of software. And having 2 apps that have the same target usergroup in its release is just a no-go.
Since when is choice a no-go in KDE land?
How does including some duplicated pieces of software make KDE less complete or usable?
As another in this thread pointed out, distributions make their own choices on what to include anyway. It is my understanding that KDE does not distribute packages for distributions but leaves the packaging to them. Why not /let/ them make the choice if do they that already? Why does KDE have to choose?
Because there's a difference between giving distributors a choice, and forcing them to make that choice entirely.
Having alternative apps for a similar purpose is a good thing.
Shipping BOTH apps by default is a bad thing. Distributors should have a choice to customize KDE, not be forced to: KDE should be sane by default even if the distributor doesn't have the ressources or the will to do that job for us (think Slackware). And shipping two similar apps for the same purpose by default is simply not sane.
At this point, it looks like Ligature is going to go, seeing as it seems focused on the most esoteric formats that aren't in common mainstream use (yes, I do know about DVI; yes, I have been known to use it personally; no, I don't think that justifies shipping a DVI viewer by default, sorry). And that's a freaking pity, because Ligature is a good app. If only developers could let go of their freaking egos... :(
Ideally, the battling of egos would stop right now, and one of the two apps moved as a backend to the other. (Wilfried, dear: Ligature would probably have to be the one going, for the reasons Aaron brought up. I wish I could find a way to put it more nicely -- it's not that Ligature is a bad app; it's more a matter of scope and focus, really.)
Second best solution is to move both to KEG and let the users clamor for what they need. And here's a hint: rightly or wrongly, they're already clamoring for oKular, be it only because the formats it supports are in MUCH broader use.
Mind, I know that merging an app into another is hard and not just any kind of developer has the talent to do it right. However, I didn't think it was above you, Wilfried. Am I wrong in this?
now i'm no developer, but from a users point of view, and having seen and used both okular and ligature in their current state (kde4) - i'd rather use ligature as backend for okular's UI... okular has a better (more complete and usable) UI, but its 10 times slower than ligature. text selection drags behind the mouse on a 2 ghz processor, and once selected, there is no way to copy the text so it's useless anyway. at least this works nicely in ligature...
i think we can talk about this for ages, and it won't help. the authors won't work together, and most likely the Technical Work Group will have to choose one app to be included in KDE. And as aaron prefers Okular, i think that's what it's going to be...
i do remember a ligature developer who said something like he thought it was rather stupid to allow a summer of code project to add to KPDF all those features already mostly available in kviewshell, but hey, it did happen, and now we have two apps duplicating each other. let's hope the competition makes em both better, not worse.
> text selection drags behind the mouse on a 2 ghz processor
I improved a bit its performances last week.
> and once selected, there is no way to copy the text so it's useless anyway. at
> least this works nicely in ligature...
And you think noone is already working on that? Come on...
> i do remember a ligature developer who said something like he thought it was
> rather stupid to allow a summer of code project to add to KPDF all those
> features already mostly available in kviewshell,
Well, when Piotr started to develop okular, kviewshell as the ligature you know was started too.
supestoned: I know you love ligature and you would like to see okular burning in the hell flames, but hey, if you have _constructive_ comments about okular, they are welcome.
But your current way of discussing is more flaming.
well, actually i like 'em both. and i really like the work on okular's annotations, i've been trying it for some time now. and of course somebody is working on the text selection. but i oppose the things Aaron said, when stating Ligature is more like kpdf, while okular is ahead. i think okular and ligature are both more or less equal. that's a bad thing if you have to choose one, and maybe a good thing in the sense of competition.
btw, what's nice about all this is that the KDE desktop environment has two PDF (etc) viewers which are both way ahead of the competition ;-)
about constructive comments about okular, well, thanx for speeding up the text selection... i just tried it, and it doesn't lag behind the cursor, so you did great.
ok, lets try to be constructive. what about the following: would you like to write a joint statement about this whole situation with the ligature guys?
tell everybody what you both think about:
- duplication of apps in KDE: a good or a bad thing?
(so: not about having several apps for one thing, that's not bad, that's darwinism in free software. but what about shipping both with KDE-graphics by default? maybe: why would we need both?)
- technically, how do okular and ligature compare? you guys are the developers. you must be able to find out which one is ahead where. maybe, more can be shared. maybe you can help the TWG making a decision here ;-)
- what are the future plans? not just being better as the other one, right? how see okular/ligature the competition, and how are you guys going to be better?
try to make it a JOINT statement. see you both agree on it, not just answer the questions seperately...
just an idea. it'll bring you guys together to create something, could be a start of something beautiful. or you'll guys see how to differentiate okular and ligature, so users can use the both for differend purpose... ???
> when stating Ligature is more like kpdf,
compare kpdf and kviewshell in 3.5. then compare ligature to that same kpdf. which has adopted the features of the other? it seems a bit obvious to me, really =)
> while okular is ahead.
given that okular has added additional features since 3.5's kpdf version, has gained supported for multiple file formats and has a devel team with positive energy i stand by my statement here.
that said, okular is missing adding/removing pages from files and the nicer smooth scrolling of okular. somewhat minor features, but useful ones.
i think both could be further along if everyone worked together, however, as they aren't really working on unique apps but working on virtual carbon copies of the same one.
> > i do remember a ligature developer who said something like he thought it was
> > rather stupid to allow a summer of code project to add to KPDF all those
> > features already mostly available in kviewshell,
> Well, when Piotr started to develop okular, kviewshell as the ligature you know was started too.
Actually kviewshell started as a fork of KGhostview on May 12, 2000. The initial
author was Matthias Hoelzer-Kluepfel. You can check this by consulting the SVN logs.
> supestoned: I know you love ligature and you would like to see okular burning in
> the hell flames, but hey, if you have _constructive_ comments about okular, they
> are welcome.
> But your current way of discussing is more flaming.
Mentioning concrete problems of an application _is_ constructive.
Greetings,
Wilfried Huss
> Mentioning concrete problems of an application _is_ constructive.
Every statement like "foobar does not work, please fix ASAP" can never be costructive.
Instead, statements like "i tried using foobar this and that way, but it does not work. the problem(s) i noticed are bla and blabla." are _way more_ constructive.
What do you do if someone files a bug report for any of your maintained application, writing stuff like "foobar does not work, please fix ASAP"?
Ok, duplication is the wrong word, but to reply to question. Although I'm a KDE fan, I'm happy that Gnome exists as well. I wouldn't like if a distro installs KDE and Gnome at the same time. It should be only one. Life is about choice, it's time to choose unique and default applications that are shipped with KDE4. (e.g. default universal document viewer)
I hope that at least in version KDE4 the file dialogue key scroll bug will be solved. I mean the jumping selection you can easily reproduce when you open the dialogue and browse real world files.
What you can do to is to report it to http://bugs.kde.org, if not already reported.
It is already submitted. I have too noticed it alot.
Same here. I'm surprised this bug has lasted for so long already.
I look into KDE Commit-Digest since a long time and i can't see fresh news about Digikam project. No commit, no activity, no report... sound like a dead project? What the Digikam 0.8 future ?
Digikam is one of the most active projects :)
Digest covers only small part of KDE development activity. If you want a good coverage of particular project you should subscribe to related mailing lists.
Digikam 0.9 is planned as Christmas gift and it will be one of the best photo management apps in the world - including commercial programs.
I'm really looking forward to the new release, it looks amazingly cool!
I just hope my new Nikon D80 will be supported. I can see that DCRAW supports it, but it isn't mentioned on the gphoto2 site.
With 0.9.0 release digiKam include dcraw 8.41 source code in core. There is no external dcraw depency. It's the same for RAW converter kipi-plugin.
For a lot of technical reasons, this is mandatory. We have a lots of bug reprot depending of different dcraw version used by users witch are completly uncompatible (problem with dcraw command line options in fact)
Of course, dcraw will be updated in digiKam core in the future. I have also planed to do a shared dcraw interface between digiKam core and kipi-plugins witch will reduce duplicate code and simplify developement.
Gilles Caulier
Can the devels PLEASE speed up showfoto?
Digikam 0.8.x was so much faster...now it's so SLOW...
I need gqview speed going from 3 mb JPEG to 3 mb JPEG. Speed baby!
same problem here, Digikam 0.9 is so slow when showing photos with showFoto that I organize my albums with digikam, but use the feh image viewer for doing slideshows.
Digikam 0.8 was much faster.