In this week's KDE Commit-Digest: Configuration and layout work in Plasma. A whole load of Plasma backports from trunk to the KDE 4.0 branch (for KDE 4.0.2). Plasma applets begin to be ported to use WebKit from Qt 4.4. Color blindness simulation for KMag. Work on support for button form fields, and support for encrypted ODF documents in Okular. More developments in the porting and maintanence of Kooka. Remote KABC resource and an Akonadi to KCal bridge in Akonadi. UPnp integration in Kopete. A rewritten upload plugin for KDevPlatform (used in Quanta and KDevelop). Continued work on a new projection framework in Marble. Undo/Redo work using a "piece table" in Okteta. Optimisations in Kalzium, Amarok, and KGet. A KControl module for configuring imaplib resources in Mailody, and a module for managing emoticon themes in KDE. Start of work on Puck, a tool to convert the Plasma XML user interface format into C++ code. Experiments with a KDE 4 version of Kommander. A branch of KDEPrint to experiment with refactoring and porting to Qt 4.4 (for KDE 4.1). Decibel and the Plasma "Luna" and "Trash" applets move to kdereview. KSystemLog moves into kdeadmin. Import of Smoke and Ruby Plasma bindings. KDE 3.5.9 and KOffice 1.9.95.3 (KOffice 2 Alpha 6) are tagged for release. Read the rest of the Digest here.
Comments
kdeprint isn't dead, it was replaced with QPrinter for KDE 4.0 and they are working on fixing the feature regressions for 4.1. And maybe add some more features. ;)
Yes, this is an issue with the print system and not Okular.
Under KDE3 we had KDEPrint which supported n-up printing using postscript pre-filtering. With the switch to fully Qt based printing this was a feature we lost as it is not currently supported by Qt 4.3.
For 4.1 I plan to re-introduce this on *nix platforms by using Cups based n-up, if Qt doesn't end up supporting it directly in Qt4.4. Sorry lpr users, but it really is time to join the 21st century :-)
Under Mac and Windows, the native print driver and dialog are used so it depends on if the manufacturer supports it.
I'll try post on the planet tonight about the printing changes in Qt 4.4.
Great - thanks for all your efforts (from a user with no printers whatsoever ;)) and for keeping us up to date!
Thank you so much for your hard work!
It is already a massive improvement over qt 4.3.
Just a minor thing, will there be pictures in the dialog later on? Sorry if it seems a little trivial, but I loved the fact that the KDE3 dialog had pretty pictures for collated pages and icons on all the buttons :)
P.S. I tried to post the above in your blog, but the captcha doesn't work at all.
Not my hard work, I've mostly just been patiently waiting for 4.4 to get finalised to see what the trolls are providing, while poking around the old code to see what can be salvaged. If you want to thank someone, drop the trolls a note :-)
As for the cute pictures, I'm not sure what qt will provide in their stuff, but anything I add on I'll try get good graphcs for from the artists.
Just a small correction, the upload plugin is inside Quanta's source tree and is not part of the KDevelop Platform. Its something specific for web development.
"KIO-GIObridge is an optional adapter for KIO to use the new GIO/GVFS (the successor of GNOME-VFS) to handle the protocols mentioned above."
I think this is really cool. There is no reason why KDE and GNOME should use different implementations of the same remote protocols.
I always wanted to make it possible for KDE and GNOME applications to share the same file dialogs, for consistency's sake. Qt's support for GLib makes it almost possible - but it probably wouldn't work when opening/saving non-local files. But the KIO-GIObridge should really help here.
Check out gtk-engines-qt which allows gtk apps to mimic qt styles and widgets. I shudder at the thought of using Firefox with the GTK file dialog.
Ehm? I don't think gtk-engines-qt changes the file dialog at all. It still the same old horrible Gnome dialog (just with a KDE look-and-feel)! If you know of a way to really change it to the KDE dialog, please let me know because it's the only major gripe I have with Firefox. (And no, Konqui just doesn't do it for me, sorry ;) )
There's KGTK, but it doesn't work with all apps, IIRC it doesn't work with Firefox.
I've looked at its kde-apps.org page: the author says it works with Firefox 1.5, but not 1.0. I don't know if it works with Firefox 2 or 3.
For me, it works fine with FF 2.
Yes, gtk would definatly benefit from a file dialog that didn't look like utter shit.
Mostly I don't have a problem with the look of the gtk file dialog, just it's pookiness.
Like in firefox, when downloading a file and wanting to open a file in a certain application. From reading a flamewar that erupted when the breadcrub navigation was added, I'm aware that you can hit ctrl-l to get an editable location bar. When I do that to be able to type "/usr/bin/kpdf" or whatever, I get to "/us" before the app attempts to lookup what I am trying to type and freezes. By the time it comes back I've already typed the remaining r/ so I end up with "/us/r/" where I then have to delete it. This continues until I get to /usr/bin/ where the app freezes for about 40 seconds while it attempts to enumerate all the possible applications. Once I hit "k" for the kpdf, the process starts over. Once I have gotten to the point of being able to type "kpd" it trys to auto fill in the rest of the name while I am trying. So I end up with "/usr/bin/kpdff" I then have to go back in and edit the name once more while the app freezes trying to look up more stuff in /usr/bin. Basically it is pretty frustrating and not a pleasant experience.
This ended up sounding like quite a rant, but my point was intended to say thanks KDE devs! I like the existing file browser. It does the right thing and lets me save or open things without getting in the way.
That behaviour is pretty annoying. I've not noticed it recently but when it used to get me I discovered you could pretty much get past it by simply typing the first letters of the dirs. For example /usr/bin/kpdf needs to be entered as /u/b/k...
Frustrating to say the least :)
Just use KGTK:
KGtk (Use KDE Dialogs in Gtk Apps)
http://www.kde-apps.org/content/show.php?content=36077
I was wondering, things have been somewhat quiet for the last week in the planetkde and also it seems the number of commits is not what it has been lately. Is there something happening or is it just random ? This is my curiosity as a kde4 enthusiast, not me trying to start a quarrel :)
Actually, my previous post is a bit misleading about the number of commits now I read it again. I don't know where I saw the numbers I saw before. I guess I'm still sleepy, stupid me ... :D But it's nice to wake up and find the digest is there :D
> Stephan Kulow committed changes in /trunk/KDE/kdegames:
> removing calculation and napoleon's tomb - both are too much games of luck
> with too complex rules
I was wondering why Napoleon's Tomb had vanished for the last few opensuse releases.
Does that mean Tomb is gone for good? I love that game.
Each 2nd. KDE-update breaks the file associations with Kaffeine and sets Noatun as the default player. It's something as trivial as annoying! (in opensuse).
That's a configuration issue, where newer versions of the default file overwrite the customized users' file. Imho wrong. I hope someone can fix this the right way
(eg it should work based on individual entries, not whole files - so if you did configure a certain setting, it keeps your setting, and uses the default from the system settings for all other settings. So user config files only contain the changed settings, not all settings)
I just read this: http://polishlinux.org/kde/kde-41-visual-changelog-rev-777000/
"KDE 4.1 will be what everyone expected 4.0 to be a fully functional revolutionary Linux desktop. I took a look at the revision 777000 of this desktop environment and what you get is a visual changelog describing the current progress in terms of look and feel and the features."
Nvm the above paragraph, I just included it for completeness sake.
I'm really impressed with KDE 4.1 development so far.
It seems that KDE is really on track to deliver everything Aaron Seigo promised it would in the keynote.
Thank you to everyone involved with the project. You guys are doing a great job.
lets keep a low profile on kde 4.1 and not hype it to death.
I see your point.
Yet I think hype is what attracts new developers.
Especially for the next few weeks, when submissions for Google's Summer of Code are due. Let's hope we'll get many volunteers. :)
I'm still not impressed.
Some basic features as double click for desktop icons, moving plasmoids in panel, hide inactive icons in dock and much more are missing.
And for the plasmoids, I've plaiyed a little, and so far did not saw anything that KDE3 could not do.
BUT the hope is the last one to die ;)
As distros start rolling out KDE4, I think it would be great if there was a uniform graphical package manager that worked across the divide of packaging systems, a la KPackage. It would be great to have a manager that matched the features and clean design of Synaptic (not to detract from the competence that is found in Adept) and the only differences across distros would be the backend used. Would it be possible to have a system like Phonon is for sound engines, where each distro writes a backend (Ubuntu & Debian's deb, Fedora, opensuse, Mandriva, PCLinuxOS & a billion others' rpm, all the other exotic ones) that links up to the same interface? Or is this what PackageKit already intends to accomplish?
It would be wonderful if there was co-operation between the various KDE distros on one Oxygen-designed and HIG-compliant manager that would make app installation even easier than now. This would reduce duplication of effort and free up individual distro developer time to polish up some other features. Of course, this is all idealistic stuff that would probably hit roadblocks in the real world, but the free software movement is all about dreaming and working towards better stuff right? :)
there's already such a project aiming to reach this goal.. packagekit... the only thing that's missing is a KDE4 GUI. Atm there exists a QT and Gtk+ GUI. Some major distros like Fedora are already thinking about including packagekit in their next major releases.
Thanks for the info. I've heard of packagekit, but it still seems gnome-centric - none of the screenshots on their site show a qt or kde interface. But I guess all it needs is time, so fingers crossed!
http://lists.freedesktop.org/archives/packagekit/2007-October/000750.html
>Optionally, read the "button" form fields from poppler.
>Enable the support for them only if the poppler version is recent enough (atm, git master of around 9 hours ago).
Cool, Okular clearly is pretty up-to-date ;-)
Is KDE going to be at this years Google Summer of Code again?
http://developers.slashdot.org/developers/08/02/26/0134235.shtml
I'm very curious. Looking forward to the results.. :)
*bump*
Who needs that? What comes next? Why not switch over to GTK and other Gnome technologies alltogether?! This would make us so unbelievably compatible and attractive for 3rd party applications, as they wouldn't have to decide between to frameworks! Just take Gnome, put a few new icons and wallpaper on top: thats the new KDE 5! Giving up identity? But we are compatible! Hell yea!
(I know, this is carried to extremes)
I do understand what you're on about. DCOP was a much superior IPC system, but we changed to DBUS to have compatibility with The Foot. Now many KDE distros have to support glib which is slower than qtcore, and our awesome KIO technology will ultimately be pushed aside for someone else's copy. Isn't it silly for them to recreate our technologies and then us having to adopt their version? As non-native stuff, performance is likely to suffer. It's like NIH syndrome in reverse. The worst thing is that it's fine for us to have gtk+ technology thrust upon us, but when opensuse 11 plans to use qt for the installer, some gnomes are up in arms. How sad.
> DCOP was a much superior IPC system, but we changed to DBUS to have compatibility with The Foot
While it would have been possible to continue using DCOP and probably enhancing it, the change made sense on its own since we also needed it for communication with system services.
Since D-Bus replaces DCOP as the technology behind KDE's inter-application communications, I am quite sure that KDE uses it way more pervasively than any other desktop or set of applications.
It's carried to such a ridiculous extreme that it has destroyed whatever point you were trying to make - assuming you were indeed trying to make one.
Well, maybe... Indeed I was trying to make a point here. I'm just concerned about the direction all this is heading. What comes next? They develop a successor for bonobo and we throw out KParts? Are we adopting Gnome base technologies one by one for the sake of the holy compatibility and sacred 3rd parties? Where will that lead us in the long run? It is indeed to fear that Gnome centric distros like Novell or RedHat will activly use these things, making the KDE Desktop as such redundant. If this would be a mutual process, like say the adopt Phonon or Solid, however it seems more a oneway street ...
> Are we adopting Gnome base technologies one by one for the sake of the holy compatibility and sacred 3rd parties?
KDE does not adopt technologies for such reasons.
However, when there is a need for a certain functionality, any candidate which matches our requirements in quality, stability and portability will be considered before starting from scratch.
If a replacement candidate for a technology we are currently maintaining ourselves emerges, it still has to fullfill our requirements to be even considered for adoption.
In some cases considerations such as compatibility with the current solution will also have an impact on the descision regarding adoption, e.g. the KDE3 software stack is using D-Bus for external communication and DCOP for established interaction patterns.
As KDE users it is probably not as visible to you when others adopt our achievements since from your point of view there is no change to your environment.
Please don't forget that people need applications too. Locking out 50% of the apps by insisting on desktop-individuality in areas like the file-system-layer seems a bit foolish. I would question the undertaking as a whole, if thats the only point of having multiple desktops. Reminds me of the different rail-gauges in Russia and Western Europe - just a few centimeters apart, but a total disaster in "compatibility".
I'm not quite sure what this is about, but I'm all for compatibility.
Either way, you guys are doing great.
All the rants mean - including mine. That KDE is gaining more interest among the pulic. The higher the adoption rate, the higher the controversy. ]:-)
Controversy sparks interest!
Keep up the good work guys. Every time I get frustrated at some of the Windows XP machines that I have to maintain, I see a glimmer of hope in KDE 4. I can't wait for the light at the end of the tunnel in KDE 4.1. Very soon I'll be able to take Windows XP off some of these computers and will be able to send users on their merry way with a distro based on KDE 4.1 :)
Other Linux based systems I have to convince people to use. With KDE 4 people are practically beating down my door to put it on their systems. It's hard to have to tell them, that they'll have to wait for 4.1. (I'm actually waiting for the next gen distros to support it out-of-the-box for my sake. I like simple deployment ]:-) but psst, it's a secret.) The compiz fusion style effects sure help spark interest as well. (most users don't understand the difference between compiz fusion and Kwin. I don't want to bother to explain it to them, with KDE 4 I don't have to, as 4.1 will have cool Kwin effects. Yay! )
Be careful about setting up 4.1 as The Second Coming. It should have plenty of improvements over 4.0, certainly (as 4.2 will in turn have over 4.1), but is such a large amount of work that it will doubtless introduce its own share of bugs, and many features may end up being dropped due to lack of manpower.
Please do keep in mind that this is nf2's pet project, and there is no reason to believe it will ever be part of KDE proper.
If you can write an app that uses KIO, and can then run on top of GIO as well without modification, or you can write an app that uses GIO and nothing else, wouldn't you prefer to write it for KIO?
I think that is also part of the rational behind porting KDE4 to Windows, that then developers would rather develop for KDE4 and have their apps run on multiple systems without modification, than write them only for Windows.