In this week's KDE Commit-Digest: A KPhotoAlbum developer sprint leads to various developments, including a new viewer and support for image "stacks". Initial lyrics support and a new "Albums" applet in Amarok 2.0. Support for export to OpenDocument text and HTML formats for certain file types in Okular. More functionality in the Plasma "Engine Explorer", an application for data engine development. More work on the "grouping taskbar" and "Weather" applet for Plasma, and new features in the wallpaper configuration dialog. A new Plasma wallpaper plugin, "Mandelbrot fractal viewer" based on Eigen. Lots of new settings across KWin-Composite effects. Start of code for a "Plasma loader" in Raptor. Experiments with using Jabber to propose/find network games in KSirK. Support for subprojects with CMake, and a generic "Source Formatter" plugin (with multiple backends) in KDevelop 4. Start of an OpenSync plugin for Akonadi. An Akonadi "server configuration" KControl module, intended for use in KDE System Settings. Support for adding files through command-line arguments in Ark. "Instant search" is implemented in KCharSelect. More work on a new IRC implementation, and improved Kiosk support in Kopete. NEPOMUK query service, and kosdwidget move to kdereview. Import of "LokaRest", an experimental framework to access RESTful web services. A new application, kReMail, is added to playground/pim. Import of "deKorator" KWin window decoration engine to playground/artwork, and a KDE4 port of Kvkbd into playground/utils. KColorEdit 2.0 is released. Read the rest of the Digest here.
Comments
Dragon works for sound files as well.
Yep and we plan on improving the audio-playing experience in future releases.
There are also longterm plans to make Amarok 2 work well as a one-off player.
does anybody know the duration on a full kde(from svn) compilation? Please mention the RAM size, CPU power, cores .etc.. i want to compile KDE but im scared of the duration(a couple of years ago i compiled KDevelop... it took 8 hours(it think it compiled every it needed))
If you have Intel Core Duo and use "make -j3" (three jobs at once), and have 1 GB of RAM, and are using your distros packages for the basic stuff (including Qt 4.4) then you can get a basic KDE trunk (kdesupport+kdelibs+kdepimlibs+kdebase) up&running in less than 2 hours. Additional modules (kdegraphics, kdesdk, kdeedu...) don't take very long to compile.
Worth mentioning as well is that the two hours is for the initial install.
Keeping it updated is usually 5 or 10 minutes and if you use kdesvn-build it can be completely unmanned.
I often had big problems with just doing an update "svn up; cmakekde". Compilation or linking did fail. I had to sweep the whole build-directory and do a clean initial making to get it run again.
And also if it works it takes here minimum 30 minutes I think.
On a Core 1 Duo with 2x1.8 GHz, 2 GB memory, I remember that compilation of the 4.0.2 tag (with all default modules) took about 3 to 3.5 hours.
I do not have numbers for newer versions as I'm using kdesvn-build, and am also compiling qt-copy and some playground modules (which you probably do not want to do).
I do not know the exact time, only that it really takes looooong here (I guess 6-8 hours or so) to compile KDE4 with the following packages:
kdesupport \
KDE/kdelibs \
KDE/kdepimlibs \
KDE/kdebase \
KDE/kdeadmin \
KDE/kdeartwork \
KDE/kdemultimedia \
KDE/kdepim \
KDE/kdesdk \
KDE/kdegames \
KDE/kdegraphics \
KDE/kdenetwork \
KDE/kdeedu \
KDE/kdeutils \
My system:
single core AMD Athlon(tm) XP 2200+ (1800 MHz) with 786MB RAM, but a nicely fast harddisk (what is fast for my motherboard).
The point is that compilation stresses not only the hard disk, but also the CPU and memory. KDE requires Qt and a big bunch of other libs, and loading these structures into memory takes quite some time.
amarok 1.x has two modes, "playlist mode" and "player window mode" ..i have been following amarok 2 from svn and i honestly have no idea where you guys are going with it ..but i guess i will have an idea when its more matured ..
there is one thing i always wonder though ..will there be "player windows" ..i can only see a playlist window ..
No, there will be no "player window". That would be very XMMS'ish and old fashioned. Yikes :)
However, such a widget could be easily implemented as a Plasmoid. I fully expect someone to whip up such a Plasmoid sooner or later.
Just a quick question: is any work being done on the KDE 4.x printing infrastructure? I mean, before we had KDEPrint since KDE 2.2, but this was dropped in the 3.x ---> 4.x transition. Any hope for a 4.x version of KDEPrint, eventually?
I'm asking because I do have to print from time to time (ok, more often than that), and a good, high-level printing infrastructure that does not force me to be a über-geek to get what I want on paper is, well, important to me.
Yes, I'm old enough to remember the days of lpr being *the* printing infrastructure of *nix (that and getting my OS on a 125MB tape... or having to string up a DEC-Writer II to the PDP-11 so that we could work... (sorry, having a flashback, here)) and I don't have that sort of patience anymore.
Cheers.
AC
i remember lpr as well, though not quite as far back as you do =) and yeah .. it was the definition of annoying. well, sendmail.cf was the definition of annoying, lpr just liked to compete ;) anyways ...
kprinter ..
there are 3 parts to printing: the UI for printing from an application, managing print jobs once they are in the print system and configuring printers.
printing from an app UI is now handled mostly by Qt and seems to be working pretty well for me these days. there was also a SoC project to bring a new level of usability to printing in FOSS and they implemented both a Qt and a Gtk+ version of their design; they presented on it at Akademy. hopefully we'll see it in Qt/KDE someday soon.
we have a new printer configuration tool courtesy of Jonathan Riddel. it's written in python and pretty straightforward.
for managing print jobs ... i'm honestly not sure what we have there right now. i probably should, though, shouldn't i? =P
(Maybe I should call myself 'aging coward', considering I'm old enough to remember the days punch cards and batch processing? Ah, dealing with the finer points of IEBPTPCH... Hmm...(flashback in progress))
Thanks for the reply A-man :-)
So if I understand you correctly, we lost KDEPrint in the KDE3 to KDE4 migration, but some of its functionality more or less came back, the only missing bit being print job management?
What about adding printers (and their associated drivers)? Is it as apparently clean & usable in KDE4 as it was with KDEPrint (KDE3)?
Not quite off-topic, but if these rumors of HP building its own Linux distro are true, I'd suggest they work instead at adding a polished, full-featured and usable by non-geek printing infrastructure to KDE4. Since printing (and other "little details" of the sorts) appears to be too boring for hackers to work on, maybe a company with a paid staff, working on a project dictated by marketing (can't think of a better way of saying it) might be the only way to go in regards to printing.
AC
I would hate to rely on hardware manufaturers for producing printing guis. We would then have the horror of completely divergent interfaces for different printers, hideous uis and branding everywhere...and... the horror of half a dozen systray icons just to manage a printer just like windows users get to enjoy.
I am not talking about various manufacturers writing their own GUIs for their own printers only. I am talking about HP (in this case) writing the KDE4 version of KDEPrint, about them writing a generic end-user-centric printing infrastructure.
This instead of writing their own Linux distro, which I fear would add nothing to the mix and be just another Linspire/Xandros/whatever.
AC
http://techbase.kde.org/Schedules/KDE4/4.2_Feature_Plan#kdelibs
Seems like John Layt is working on "Reintroducing KDEPrint in some form, depending on what Qt offers". Obviously making use of Qt when we can is a good idea...
Aaron already mentioned current progress (we've got everything basically licked except a Job Manager).
Big thanks for the constant effort by Danny to make it a joy to read and to stay informed. I love those digest reads!
Gnome folks should learn from it :) this is why i prefer KDE. NOT because KDE is better or worse but because the guys BEHIND KDE seem to be very very much in touch with the users.
Of course thanks to the KDE dev guys. I think the KDE 4 move was rather painful actually - at least for me - but finally it seems to be spearheading in a good direction with a proper pace.
The extender shown in the video was pretty difficult to read (not only because of the bad font), so I tryed to do it better in a mockup.
I also "fixed" it's frame. The current plasmaoid style has a to strange shininess look to be the default. Please, keep things easy to recognize for the brain!
Hmm, no attachment, here's a link: http://img137.imageshack.us/my.php?image=extendermockuphu2.png
fwiw, i agree =)
this is all done with svg's so should be easy to get something much nicer in. just requires some artist help.
you should get in touch with Rob Scheepmaker and give him a hand with the styling; he can do the C++ parts, and maybe you can do the svg parts =)
you can find all of us on plasma-devel at kde dot org.
I agree with you about the text presentation: the way your mockup presents is information is much clearer and I'll be working on that. I also like your progress bar, which is a great improvement over the disk usage plasmoid's meter svg, which I just used because I needed something to use, and looks was not my number one priority. And indeed, I could add some more margins to make it a lot clearer.
I don't agree about the draghandle though. The current one fits quite good in the default oxygen plasma theme (actually, it's the same element that's being used as background for the plasma tabbar). It looks more consistent then the one from your mock, imho. What's also a point is that often, not the whole area can be used as draghandle, simply because the widget that's there accepts mouse events itself. The calender for clocks for example, clicking there interacts with the calender, not the extender item. In this kuiserver case I was thinking about making the directory names clickable to open the containing directories.
But of course, we're quite some time away from 4.2, so things can still be improved. You obviously have some feeling for design, so why not join us on IRC or the mailing list and help out? :) And: you've got that progress bar as svg? Because I would be really interested in that.
Mmmh, I agree with "anon", the default style it'stoo shiny and glossy, and your progress bar is plain ugly :) The mockup is just gorgeus IMHO, much more clear and easy to understand at first sight. "anon", please join the plasma artist team starting with the extender implementation :)
And Rob, anyway great work!
It took a very very long time until someone started to develop this plugin. Ok, now the development has started, but i hope that we can see some success in near future. I think that this plugin won't be that big, though development should take only a few days :D
See you in the gentoo portage tree ;)
Thanks Danny!
Hi Rob Scheepmaker
About the icon "return to source", I think it should just be a "back" icon(like a webpage), since most users will understand this.
//ac
Thanks for you suggestion, but Pinheiro has already created a nice icon recently which I will be using. It fits better with the plasma theme then the default back icon. The idea is that hovering this icon shows a small bar inside the applet, where the detached item will go to, so it is very discoverable.
The last update for KDE 4.1 (opensuse 11, factory) broke my KDE badly. I see the splash screen when I log in, but after that only the customized cursor and a background similar to a chess board. Since everything is blocked, I need to switch runlevels through SSH.... I hope someone fixes this soon!
Maybe you want to install your display driver again?
Add this repo:
http://download.opensuse.org/repositories/KDE:Qt/openSUSE_11.0
http://lists.opensuse.org/opensuse-kde/2008-09/msg00052.html