In this week's KDE Commit-Digest: Support for "undo closed windows" in Konqueror. GetHotNewStuff support for Plasma themes. Konsole, Konqueror, and Kate session selection added in Plasma applet form. New Plasmoids: "Generic Folder View", "System Command", KNotify-based "Popups", "Quick Launch", and to display data from Kalzium. Digikam now uses Phonon for video and audio previews, with improved use of Phonon in Dragon Player. Start of NEPOMUK support in Gwenview. A NEPOMUK "Social Query Daemon" for viewing storages across a network, and work on tagging GUI's for NEPOMUK using Dolphin. Work on services and queries, with the removal of the engine system (now using Phonon only) in Amarok 2. Continued development in Konsole. Various functional improvements in KTurtle. Support for synonyms in Parley. Support for custom themes in KNetWalk. A system tray application for Akonadi. Initial implementation of a remote desktops dock widget for KRDC. Work on the "reports" functionality of Kexi. Several long-awaited improvements in KCron. KDiamond moves from kdereview to kdegames. KAgenda moves to playground. Initial import of Palapeli, a jigsaw puzzle game. Read the rest of the Digest here.
Comments
Another great digest Danny. For me the articles with the screenshots are the most interesting anyway. I enjoyed reading about KOrganizer, WorldClock and KSysguard. With the worldclock plasmoid, will it also be possible to combine it with the panel clock and calendar view to match the feature in the latest release of GNOME? I must say that this worldclock already looks more detailed and prettier than theirs :) (thanks marble!)
And the clouds are actually the real clouds covering the world!
Woah - seriously?
yeah, afaik these are real clouds provides by nasa...
NASA make clouds, now? ;)
Anyway - cool, that's a really neat feature :)
Yes, but they don't get updated yet (right now you need to delete them manually still. But we'll fix that before 4.1.
Just to get this straight: The data that is placed on the server gets updated all the time (we are basically using the same data that XPlanet does which has realtime clouds as well). However right now Marble only fetches it once. So if you want an updated cloudcover you need to delete the cloud data that marble has fetched by hand. We'll add some mechanism that does this automatically later, so you'll be able to have real time clouds that update automatically for KDE 4.1
Are the dark and lit regions also displayed correctly wrt. the seasons? In the screenshot it looks like both the north and south pole are lit at the same time...
Basically: yes. But the light zones are a little bigger than the dark zones of the earth due to light dispersion in the atmosphere.
Remember that exactly now is the mid point between winter and summer all over the world. So it's dawn at the north pole and dusk at the south pole.
Yes, they are displayed correctly wrt the seasons.
The rather "boring" situation that you see on the plasmoid screenshot is due to the fact that we just had the equinox where spring started. At that time both poles are somewhat lit by the sun at the same time. But yes, it looks a bit as if both poles are lit a bit too much at the same time. I've just checked it back and it seems to be due to the shading in the textures.
For a different point of time that might appeal more to you you might want to have a look at the first screenshots here:
http://www.kdedevelopers.org/node/3275
Neat, though I'm not sure it makes the clock more usable.
Good work Danny!!!
Now the only thing missing, is a button for the window-Decoration, to reach this function faster. And of cource, an option for kwins window-specific settings, to enable an automatic logging *hinthint*
First add "above all" button to Oxygen ;]
indeed , johnflux ftw ! :)
Thanks Danny :)
Few highlights for me:
- Looks like To-Do module of Kontact will be usable after all, at the moment (3.5.9) it is :/ especially in contrast with the rest of it
- Gilles again on top with work on digiKam (and it feels testing new features)
- Konsole and catching of key events - more refinement is :)
- as always KHTML developers shine :)
- and final proof we need more mini-kdevelopers: and also the youtube miniature thingy because my daughter says so ;)
Yes,
I'm again on top commiter this week (:=)))
In fact both digiKam branches are in active developpement: KDE3 (0.9.4) and KDE4 (0.10.0). There are a huge changes in KDE3 which are backported automatically in KDE4. It's a big work to code, test, and valid...
About KDE4, I plan to review all new features implemented by me and Marcel (and there are a lots (:=))). I will post a new entry in my blog this week...
Gilles Caulier
Rocking! Digikam is one of my favourite applications. Thanks for getting it where it is. Keep up the good work, i'm already looking forward to the KDE4 port.
Is the digikam version for KDE4 already usable? I mean, can I loose photos or data with it, or is this unlikely? I can live with missing functionality and the occasional crash - you're getting used to this with KDE4 ;))). But it would be great to switch to a native KDE4 app for photo management.
Digikam, Amarok and k3b are my favorite apps, and unfortunately all those are not out for KDE4 yet.
We have planed to release 0.10.0 for septemeber, if all is fine.
Regression tests take a while. I wouldn't provide a "stable" release full of bug.
Like you can see, porting a Qt3/KDE3 application like digiKam, K3b or Amarok to Qt4/KDE4 is not a simple task. All must be re-tested, some parts re-written, because changes in API are huge. The advantages is to review all old codes and to make factorization, re-writting, simplifications and improvements.
digiKam still in alpha. Do not use it in production yet, at least until first 0.10.0 release candidate.
There is also kipi-plugins and all shared libraries where we have working hard me and Marcel to port in native QT4/KDE4 :
- libkdcraw (including now 16 bits color depth auto-gamma/auto white balance)
- libexiv2 (including now full XMP metadata support)
- libkipi (partially re-written and cleaned).
- 7 kipi-plugins fully ported bu me (SendImages, RAWConverter, JPEGLossLess, FlashExport, TimeAdjust, MetadataEdit, and AcquireImage).
I can post here few screenshots of digiKam for KDE4 in action:
http://digikam3rdparty.free.fr/Screenshots/newsearchwindow.png
==> the new Search tool make by Marcel. It's not yet complete, but it's planed to finalize this interface for beta1. Like you can see, a big work have been done to make a clean interface without any database-sql requests. It's more users friendly. Note than Database schema have been re-written and improved to include severals photo metadata informations. For ex, GPS info are now stored in DB: all read-only files can be geo-localized.
http://digikam3rdparty.free.fr/Screenshots/thumbbarwithpreviewmode.png
http://digikam3rdparty.free.fr/Screenshots/FullColorThemeSupport/thumbba...
==> In digiKam for KDE4, thumbnail kio-slave is diseapears. All thumbs are now generated using multi-threading (another part implemented by Marcel)
If you have already played with Showfoto, you have certainly seen a thumbbar. KDE3 implementation use kioslave without memory cache mechanism. It's slow.
The new one is more faster and can be included as well everywhere in digiKam without to decrease performance. I have included thumbbar in Image Editor (F4) and in AlbumGUI with preview mode (F3). A same cache is used everywhere.
http://digikam3rdparty.free.fr/Screenshots/digikam_for_KDE4_with_XMP_met...
http://digikam3rdparty.free.fr/Screenshots/MetadataEditor/
==> in KDE4, XMP is supported everywhere. I have improved the MetadataEditor kipi-plugin in this way and re-writted all dialog pages to be more user friendly, and to be homogenous with others tools available under MAcOS-X or Win32.
http://digikam3rdparty.free.fr/Screenshots/digikamKDE4_under_MACOSX.png
==> Gutavo Boiko, have ported several code in digiKam to compile fine in native under MACOS-X.
http://digikam3rdparty.free.fr/Screenshots/newkipiimagecollectionselecto...
==> With KDE4, I have fixed libkipi to become a pure image collection interface: no widget, no dialogs, no translation. All gui components must be re-implemented in kipi-host using the right model/view implementation. For digiKam, I have already implemented all. The advantage is really visible here: the treeview used for all phisical/virtual albums in digiKam can be used as well with all kipi-plugins (KDE3 only provide a flat albums list, not really suitable).
http://digikam3rdparty.free.fr/Screenshots/gpstracklisteditor.png
==> In KDE4, I have implemented a new tool to edit GPS track list of several images at the same time. This tool use Googlemaps, but there is a plan to use marble if necessary, especialy when users do not have a network access.
http://digikam3rdparty.free.fr/Screenshots/digikamKDE4_15.png
==> With KDE4, multiple root album path is supported, including removable medias and network repositories. Now, there is no problem to use digiKam with a NFS server to host your images.
http://digikam3rdparty.free.fr/Screenshots/FullColorThemeSupport/digikam...
http://digikam3rdparty.free.fr/Screenshots/FullColorThemeSupport/fullcol...
==> Full color theme interface: this is also implemented in KDE3. Now color schemes are applied everywhere in GUI. With black themes (my preferred), digiKam sound like a pro-software (:=)))...
http://digikam3rdparty.free.fr/Screenshots/RAW16bitsAutogamma
==> This is a very important feature : auto-gamma and auto-white balance with all RAW file format using 16 bits color depth ! Before, 16 bits color depth support nequire to use color management to have a suitable image in editor. Without CM, you have a black hole image... This is duing a limitation from dcraw which do not provide an homogenous interface between 8 bits and 16 bits color depth workflow.
With these screenshots, you can compare a same RAW image decoded:
- On the left by dcraw in 8 bits color depth and converted to PNG. Auto-gamma and auto white balance is performed automatically by dcraw.
- On the middle by digiKam in 16 bits color depth using libkdcraw with a dedicaced auto-gamma and auto-WB performed in digiKam core.
- On the right by the LightZone (:=)))... Like you can see, digiKam is not too bad!
digiKam is now able to play with all RAW images in 16 bits color depth without to use a complex Color Management settings: RAW pictures can be handled like JPEG file in your workflow. This way is used by LightZone for ex, and it's a very productive and fast. Note than it's also implemented in KDE3...
And i would remember to all than digiKam have been the first suitable opensource photo-management program which support 16 bits color depth pictures as well ! Gimp, f-spot do not support it ! Cinepaint can do it, but seriously, who will use it to play with pictures ? Of course we have krita now to work with layers... digiKam+krita == the perfect photo suite (:=)))
It's time now fpr me to close this file and to return in underground hacking-world...
Gilles Caulier
An obvious question for KDE4:
What about Windows port?
In theory, a Windows port must compile, but personnaly i have not yet tried... I'm too busy with current Linux implementation to finalize.
All contributions are welcome to report compilation problems under Windows...
Gilles Caulier
Yep, digikam is great and has improved hugely over the last year or so. Thanks Giles (+ the other developers)
Thank you for all your hard work, DigiKam Team, really :)
Btw, maybe you can c/c all that and make a new post in your blog, I think a lot of people are waiting to read that
kde 4.1 looks very good indeed. The ONLY things that bothers me at the moment is the taskbar, or better, the rendering of the tasks in the taskbar. I think currently it looks a little bit ugly. i would also like a option that the tasks are listed on two rows not only when the panel is full, but from the beginning. In short, i would like to have a taskbar that can be configured that it more or less looks exactly like in kde 3.5.9.
For the rest, great work!
+1
The way it is now is probably the most sane default, but I'd like the option to change it.
http://bugs.kde.org/show_bug.cgi?id=160156
^Vote for the wishlist item, if you'd like. That'll be more... impactful than just sitting here and discussing Plasma improvemnts by ourselves on the Dot.
You can already have the items in two rows. Unfortunately you need to set the panel to be really thick ~40px in order to get two rows.
Why would you want smaller buttons? Those provide less space for text, so they're harder to read, and they're also harder to hit with the mouse. KDE3 actually had a problem that those buttons started in the upper row (for bottom panels), so the first set of buttons didn't make good use of Fitt's Law because the buttons didn't touch the screen edges while there was empty space below them ...
They can be made more beautiful though. But since new artwork has yet to be done for Plasma, I wouldn't try to judge it right now ...
Agreed! Why does anyone want to remove the new feature?
Though:
If someone wants to implement (many users demand it) it I would recommend not no waste the new code with too many new options, but to implement a second taskbar plasmoid with 3.5 looknfeel....
agreed :D
Agree. This "bug" is just the typical "I'm used to this and I don't want to change even if the new way is better". Please stop a moment nad think "Why do I want to have a two rows taskbar even if I have only, say, 3 entries?".
The answer is only one: "Because I'm used to it, since Windows first and KDE3 then forced it on me."
Or maybe personal aesthetic preference?
And it's a wishlist item, not a bug.
It's worth trying out new things...
Either way, thank you for improving it!!!
KDE looked stale until 4.0 arrived.
Can't wait to see the final version.
Is this the same as the good and old kicker applet that placed small (instead of big) application icons in the panel?
If not, can someone pelase provide a screenshot? :D
it seems to be the plasma equivalent
That's what I think.
If so, one less complain from my part about KDE4 series :)
Yes, it's the Plasma-equivalent of the good old kicker-quicklaunch =)
It will show n items in n rows in the taskbar and the rest in a Plasma::Dialog :)
Lukas
KSysguard with process monitor support is great. Sysinternals' Process Monitor is always with me when debugging Windows applications.
I'm having a feeling drawing is a bit slower with QT 4 on my 1.4Ghz laptop with Intel 855GM video chipset. It's like every move/redraw has slightly more latency than KDE 3.5.9.
Is that most because of debug-enabled binaries, or the fact that Intel 855GM has bad X.Org driver/performance?
I dont know, but maybe someone else does (?)
I've written a bunch of blogs about it. It seems Qt4 relies more on acceleration for drawing, and as many (if not most) drivers suck, things get slower.
(KSysguard maintainer) I've never used the SysInternals process monitor stuff. I'm very interested to hear from users what they would like in ksysguard / task manager. What features do you like and use from the SysInternals tool etc?
JohnFlux
Perhaps there could be a level of Akonadi integration in World Clock, each contact managed by Akonadi could be given a GPS coordinate (or city location) which would make the contact show up as a dot on World Clock. When the dot is clicked on that persons information pops up and provides a drop down of methods to contact them via Email, voip, IRC etc (through the default application).
You could then extend this to groups of people (potentially filtered by time) so you can contact them on mass e.g. confrence call amongst developers.
Maybe this is outside the scope of a plasma applet or a world clock but I believe that it might be a useful way to contact people.
Looks awesome. Though, do you think, that green on blue is a wise idea?
I don't believe I've ever seen much report in any of the digests about the KDE 4 ports to Mac and Windows.
I tried the KDE 4 Installer for Windows, and the very first time I ran it, it allowed me to download Amarok, except that version of Amarok was quite broken and I couldn't get it to play a single song. I was hoping there might be a newer version, but the installer can't find any download for Amarok at all anymore.
The other games and apps I've tried so far seem to work reasonably well, except one thing that is sorely lacking is integration into the Start menu.
I'm curious how the porting is going.
- start menu not yet
-amarok when i tried to build the collection, it still don't work, to be honest even in linux it did not worked for me the last time ( when i was home using my opensuse box, now i am stuck with windows in work for two months).
-can't try konqueror as the option the configure proxy still crash.
-the kde games works perfectly well,
I am also using openSuse 10.3. I got Amorok to work with the KDE version 4.0.66 which seems to be even more stable and functional than 4.0.2. Amarok is looking really pretty but it isn't as stable as the KDE 3.5 version.
The developers are working very fast. At this pace I am beginning to wonder what 4.1 will be like. I am really impressed :)
> -can't try konqueror as the option the configure proxy still crash.
this is fixed in svn and will be available in the 4.0.68 release
hihi thanks,
me marking my bug report as fixed, neaaaaaaaaaaaaaaat
"Amarok was quite broken and I couldn't get it to play a single song" actually it play sounds, but no way to configure proxy in kde application, bad