In this week's KDE Commit-Digest: Continued work in Plasma, particularly in the clock visualisations. Kalzium uses the GetHotNewStuff framework to download new molecules for its 3d viewer, plus speed optimisations for the rendering of these molecules. The start of fullscreen support in the Gwenview image viewer. Work begins on a WebKit-based KPart. A KControl module is created to allow for easy manipulation of KWin "Composite" settings. Continued work on the OpenChange Akonadi resource which enables interoperability with Exchange servers. Statistics plugin for a graphical representation of connection speeds in KTorrent. Improved handling of HDR imagery in Krita. Branch created for the integration of Solid-based connection management and notification in Konqueror.
Comments
My question was more focussing on the question why the Intel drivers are marked as "no idea" and why there is a commentary implying thy would not work - because they should work for AIGLX in contrast to ATI's fglrx drivers.
So first, was Intel hardware tested at all? And second, if tested and failed, why did it fail?
I think that the reason is very simple: the author doesn't own an intel based card, so he cannot comment for sure. Anyway I suppose it should work just like compiz and beryl do.
From reading the link, and seeing the "no idea" comment for Intel cards I think the explenation is simple. My guess would be that the developer writing it simpply does not have acces to a Intel card to test on, hence he has no idea if it works and how to set it up correctly.
Something that be of interest was an article [1] I read yesterday. It did a comparison of the various graf cards in common usuage WRT beryl, compiz etc. For me, it is something to look at when I decide I need another computer.
ne...
[1] http://www.phoronix.com/scan.php?page=article&item=730&num=1
Make KDE4's desktop a sandbox/playground with plasmoids being the "toys"!
I commented this on the Plasmoid video on youtube:
It would be cool if you could resize and rotate the plasmoids interactively.
What if, say, when you hover your mouse on top of a plasmoid for a few seconds, some buttons, "hallos", would appear around it. One would allow you to resize the plasmoid when you dragged it, another would allow you to rotate it.
Yeah, I'm hinting for a playground and sandbox aproach to the desktop in KDE4!
[Perhaps that's even your original intention]
This is nothing new, Squeak's Morphs have that ability.
It would also allow you guys to test users reaction to this kind of interface, where the things you can Do to an object, are Around that object.
There are a few projects which implement this type of interface.
Sophie book (www.sophieproject.org) doesn't have a conventional formatting bar. Instead, you select a text/image/video/etc., and after some milliseconds, apropriate buttons for it appear on it's border, say for resizing an image, or for text, a formatting button expands into a miniwindow for configuration, to choose a different size and text font.
The other interface system [like this] appears in Squeak's Morphic system.
Here's a short intro on how it looks and works:
http://static.squeak.org/tutorials/morphic-tutorial-1.html
I had the same squeak-style-assosiation while reading your first sentence.
actually as squeaker its quite logical to treat plasmaoids as a kind of "squeak-morph" using "halos". [1]
Beside the Squeak [2] halo-paradigm in 2D - I suggest the authors of plasmoids to have look at the 3-D paradigm in Croquet [3].
Maybe you'll find some nice options for plasmaoids here - especially when think of handling such a plasmaoid in a kind of 3D (or maybe more a 2.5-D) on your desktop (see the SuperKaramba screenshot on the digest-article)...
[1] http://squeakland.org/school/drive_a_car/html/Drivecar12.html
[2] http://www.squeak.org/
[3] http://www.opencroquet.org
What I like most about this, is that mr. Seigo (and probably others?) is actually *designing* software rather than just starting to write, make things look cool as quickly as possible (with bad design and code) and finally ending up with something that doesn't look as cool as it could have been and isn't extensible at all, therefore making it a drain to keep it up to date and to add new features.
Many open source authors work that way. Personally I'm really happy to see that's finally about to change for a big and important project such as KDE.
Please don't listen to the whiners with their shortsighted visions. These very same people will kiss your feet on their bare knees once they see what the outcome of all this great work will be.
I know I will.
No (assuming you mean by designing more than giving it some thoughts before coding)
You can only design a program if you know all ins and outs in front, like with an administration system. People trying to design other programs likely end up with a bloaded, unnecessary complex, constraining application.
Above all, its OSS written by volunteers, making something work and adding features and refactor(*) is fun. Designing is boring.
(*) this is the part you missed
If you look at project like plasma/phonon etc, they basically do refactor common practice in KDE3, which is a good thing. However, being core libraries, their is certainly a risk of adding constrains on future development, simply because nobody knows how things are developing in front. Combined with all the cool stuff of Qt4, which every developer want to use of course, we should all be very alert that we not constrain ourself for KDE4.x (x > 0). This is the big risk of designing, looks cool on paper sucks in reality.
I think that we should be reminded that plasmoids will take the place of applets and desktop widgets in KDE 4. From my understanding, when plasma is finished, you will be able to drag your digital clock off of a panel and onto your desktop and it will become a clock widget, or you can drag your battery status desktop widget onto your panel and it will become a small battery meter beside your taskbar, and vice versa.
This seamlessness and consistency in and of itself will revolutionize our desktops. This feature will make KDE make so much sense and be so easy to use. This is why a clock plasmoid is so important, but is also why I am not too pleased about the porting of superkaramba to KDE 4.
Unification is a beautiful thing. If superkaramba continues to thrive in the KDE 4, users who love their plasmoids and want to find more will discover that some of the desktop widgets available on the web won't work unless they install a new package called "superkaramba", but that the new desklets which they install won't be integrated with their desktop as well as the plasmoids, causing confusion and destroying the purpose of plasma.
I'd much rather see some good guides created which explain how to convert superkaramba themes into plasmoids with full functionality.
"From my understanding, when plasma is finished, you will be able to drag your digital clock off of a panel and onto your desktop and it will become a clock widget, or you can drag your battery status desktop widget onto your panel and it will become a small battery meter beside your taskbar, and vice versa."
Is this correct?
If yes then WOW! :D I like it :)
Yes.
As I know there will be no real difference between Panel and Desktop area, when Raptor Menu is Completed, you could have it even on your Desktop.
Agreed on all of the above (including the superkaramba concerns); I've been giddy since I first heard of Plasma. And heck, KDE4 gives me so much else to be giddy about, too! Who needs a daily newspaper when you can have the KDE svn commit log? :)
One thing in particular that I'm really enthusiastic about are extenders; they seem like such a clean way to offer a wealth of information to users (see http://plasma.kde.org/cms/1069). If the implementation ends up looking as clean as the mock-up on that page, I'm going to be one very, very happy chappy!
I have exams coming up soon, but once those are over, you can be sure that I'll be hacking away at plasmoids; what more fun way could there be to start on KDE development? :P
Clocks in Plasma (KDE Commit-Digest Issue 60)
http://www.youtube.com/watch?v=Ti2GTO0KBqE&eurl=
Seems like konstruct is broken.
I've downloaded it, unpacked and cd into konstruct/meta/everything and did a make all. Eventually it'll try to find pkg-info on download.kde.org, which isn't there. If I get that manually it'll continue for a bit more and then die on some other package which isn't there either (first it's libxslt, then libxml2).
Has anyone else tried building from konstruct lately?
Also, is there a konstruct of KDE4? It would be sweet if I could build and run that without messing up my current desktop. Then I could really get into filing bugs or helping out in some other way.
Oscar
I understand that plasma will really be interesting when animation and detaching/reattaching is added as core components. I hope the animation system is modelled after flash's since it is very usable and powerful.
If plasma has the equivelent to movie clips (embeddable SVG?) and the ability to morph/animate the movie clips along paths and expose all of the APIs through kross, it would probably be enough to make plasma a Killer Feature. I'm guessing that plasmoid developers could build their own animation systems like people adopted flash's scene graph and added their own animation APIs during flashMX.
I'm guessing that each plasmoid will need a library and heirarchical scene graph of instances+paths to achive this goal. Having a designer for plasmoids would be nice too (but not 100% necessary).
Great progress so far!!
Ben
Quoting from the story on Plasma:
"and speaking of widgets, work on widgets and geometry management of them is progressing as well. much of our work is likely to be superceded by work currently happening at Trolltech for either Qt 4.4 or 4.5, but we need basic support for layouts and widgets for KDE 4.0 (which uses Qt 4.3)."
So it would be favorable to use the most recent Qt release which is 4.4./4.5, but because KDE 4.0 uses Qt 4.3 that's not happening? If the functionality is already included in Qt itself, then KDE is duplicating work, and wasting time, no?
I don't know exactly how KDE development works, but my guess is that KDE settled on Qt 4.3 for KDE 4.0 because they can't keep upgrading the Qt version because then they would keep upgrading, confusing and slowing down development? And as soon as development of the next minor release starts, KDE 4.1, the latest Qt version will be used?
Concerning SuperKaramba, I thought that SuperKaramba would be ditched, and be merged into Plasma? In the story I read that SuperKaramba will continue to exist because they don't want to loose all the work done on SuperKaramba applets so they need backwards compatibility. And they want to use it to fill the period of time when applets for Plasma aren't plentiful yet.
But I wonder, shouldn't it be relatively easy to port a SuperKaramba applet to Plasma? Is the advantage really worth the possible disadvantages, such as developing time being spent on SuperKaramba and not Plasma, duplication of work, and dividing the community between Plasma and SuperKaramba, when the goal is in the end that everyone uses Plasma and not SuperKaramba? I mean, what's the rationale behind this?
The latest Qt release is Qt 4.3 Release Candidate, final release is scheduled for early June 2007.
http://trolltech.com/company/newsroom/announcements/press.2007-05-08.667...
I Think that nobody will not create Karamba when KDE 4.0 is release, just when KDE 4.0 Comes, there will not many Plasmoids, so exisiting Karambas could help.there will be no Divide.
Its also a way to keep Karamba's alive.lots of job is done on Karambas, think about Aero/IO, LiquidWeather and ...
Eh am i seeing here the debian syndrome ?, where absolute democracy can block some hard decision to be made. But this is free software; you can't oblige someone to code as you like if he works for free
I hope I am wrong
The Solid homepage (http://solid.kde.org/cms/1002) says that big parts of it are completed. But how about the necessary backends, esp. for Microsoft® Windows® (as my family members have to use it for some programs and devices)? Is there work going on it, or is Windows® support even scheduled for 10/23/2007?
Thanks in advance.
Annotation: Microsoft® and Windows® are registered trademarks of the Microsoft® Corporation.
Hi
I Think its the KDE-Windows groups TODO.You should ask them on Mailing list if you are really intrested.
A question: when it webkit becomes a kpart will it then also be possible to use all the other Mac OSX functions? Does KDE interoperate with GNUstep?
WebKit is a HTML renderer (it started off as a fork from KHTML). It is platform independent; it works for GTK+ (used in some Nokia devices in fact), and it seems Qt hooks already exist too (but they need to be extended to take full power of KDElibs). It means nothing with regard to MacOSX toolkit compatibilities.