In this week's KDE Commit-Digest: User-visible functionality added in Plasma. Support for animated SVG images in SuperKaramba. Kanagram becomes the latest application to adopt a scalable, SVG-based interface. Initial code imported, as a statement of intention, to support interaction with Exchange servers and the Akonadi PIM data store. Small, incremental improvements in KTorrent. A new round of Coverity fixes, particularly in KOffice and Amarok. Work on loading ODF shapes through Flake in KOffice. KDevelop gets improved support for .ui (user interface layout) files. Branches of KMail, KPPP, Konversation and Kopete created to enable the integration of Solid-based connection management and notification. KDE 3.5.7 is tagged for release early next week.
Comments
Any idea where to find it?
I found that with google:
http://www.kdedevelopers.org/node/984
but no code.
The original client called "Knowledge" seems dead to me although this is not reflected on the wikipedia page (http://de.wikipedia.org/wiki/Benutzer:Danimo/Knowledge).
But see http://woc.fslab.de/woc/wiki
This is the university project that Daniel Molkentin has been involved with.
(The mailing list mentioned there is in German though.)
This is a bad thing! I really like it and propose it for all kde apps
I love it too - it was a classic "wow" moment when I first encountered it, circa KDE 3.3.
However, the reasoning behind the removal is timer wakeups, which are hefty culprits in processor (and therefore energy) usage, especially on laptops.
A decision therefore needs to be made on the balance of power usage vs. eye candy, saving the planet vs. saving our eyeballs :)
It would be nice for these eye candy features to follow a KDE-wide setting though, one which could be dynamically manipulated by Solid power controls.
Danny
Yes, a power safe/feature slide sounds like a good idea to me, uses Solid in a good way I'd think. A KDE to have such power saving feature scheme somewhere? Or is this too vague a feature?
This could be an Optional feature that is turned off by default...??
> I really like it and propose it for all kde apps
It was an absolutely ghastly hack however, and in its current state it causes Kopete to wake up every 30ms ( that is > 33 times per second ) just to pretend that the scroll bar is being pressed.
That has quite an impact on the power usage of mobile PCs, and even on non-mobile PCs it will have an impact on the performance of other applications.
So unless a proper implementation is forthcoming, it was decided to remove it.
Pity, but I can understand those reasons. I wonder, though, if we will ever see smooth scrolling (not the automatic scroll as in Kopete) in KDE. It's more usable as you can follow content with your eyes, and it looks better as well. Besides a suse hack to have smooth scrolling in Konqi, I haven't seen it much.
Though the Domino style has smooth scrolling on all scrollbars, so it must be possible...
Personally, smooth scrolling in Konqueror is the one of many thing I disabled. Maybe it's just me, but I feel uncomfortable (giddy) looking at it for a prolonged time.
Hmm, it was actually one of the things I really loved. Each time I move the mousewheel over the scrollbars it makes me itch, because it still scrolls with fixed steps there.
Well, I have seen the Domino style for Kde3.5 which implements smooth scrolling for ALL apps. Interestingly, it did not work with Kopete at all where both smooth scrolling implementations produced conflicts (not scrollable at all).
I'd rather like to see the Domino technology (and not only the smooth scrolling feature) in the KDE4 style base class to enable it for all apps....
The Kopete smooth scrolling is far better than Dominos.
Yurgh. Couldn't stand it (and quickly disabled it). I'd much rather instantly scroll to where I want to go. Smooth scroll felt floaty and imprecise, and the small amount of time it took to get up to speed and then slow back down to a stop when scrolling irked me to no end.
Completely agree. Maybe it would be ok if it was faster or used a more sensible interpolation function, but currently it just makes scrolling more tedious.
Another nod of agreement from this corner. Any small benefit gained from being able to trace the scrolling content with my eyes more easily was negated by the time wasted in waiting for the smooth scrolling to do its thing.
Furthermore, I find the step size is generally small enough for losing track of content to be a non-issue, but I dare say this varies from person to person.
All that said, however, if a proper smooth scrolling implementation came about, and was strictly *optional* (even if it was enabled by default), I don't see how this would be anything but the best of both worlds. Sometimes you *can* please everybody... or almost everybody. :P
Personaly, I use a laptop and usualy don't get a moose whith a scrollweel, so this was realy usefull
But I have to agree that when you have the scrollweel, this thing is more anoying than good.
First of all, congratulations to all plasma developers for the first mentioning in commit-digest ! This may finally calm down all that angry unbelieving trolls ;)
I've taken a look at plasma source and wiki pages and still have one question about plasma design: why this rewriting of standard QT QWidgets is necessarily ? Rewritten copy will deffinitely have less functionality than the original one and will possibly have small differences in behavior that will annoy both programmers and users. Yes, QGraphicsView is really great, but according to several blog posts on the planetkde you still can use QWidgets on it. There is some issues with scaling, but in current implementation plasma widgets are drawn using KStyle which is resolution dependant and still has the same problems with scaling.
Just my thoughts, it'll be great if someone could clarify this here or on the wiki. And again thanks for all your wonderful work !
you said you read the blogs about it, probably referring to the ones by andreas at trolltech. if so, they answered your questions. it's not just about resolution independence, but stacking orders, graphical effects and other transformations.
and hopefully we won't need our own copies of these things for long.
> deffinitely have less functionality than the original one
pushbuttons and checkboxes aren't that hard to do. it's not like we're going to be implementing treewidgets and what not.
> and will possibly have small differences in behavior that
> will annoy both programmers and users
given that this isn't meant to be used to write full applications, i highly doubt that. these are simple analogs that are good enough to appear like they belong and fit and are familiar to the user. i doubt most users will even notice and given what applets tend to do, i doubt developers will even care.
it's also temporary; we'll probably be able to replace all this code with qt 4.4 or 4.5, depending on schedules at Trolltech.
> you said you read the blogs about it, probably referring to the ones by
> andreas at trolltech. if so, they answered your questions
I've just reread Andreas' blogs and yes, now the answer is more clear for me.
> it's also temporary; we'll probably be able to replace all this code with qt
> 4.4 or 4.5, depending on schedules at Trolltech
It's quite good, I'm looking forward to see how Trolltech will solve this !
Thanks a lot for you reply !
And one more question: will the plasma widgets support stylesheets (which can be quite tasty for applets) ?
> will the plasma widgets support stylesheets
i'm really not sure at this point. right now they don't, and i'm not sure that's a bad thing. conversely, i'm nearly positive it's not worth the effort for kde 4.0 if we're going to get it for free in qt 4.4 / kde 4.1.
Nitpick: The C and C++ mimetype icons look like they say "exit 0;" at the bottom, instead of "return 0;" or "exit(0);"
http://commit-digest.org/issues/2007-05-20/moreinfo/665814/#visual
Am I crazy?
It should also say 'int main(......' and being pedantic 'return EXIT_SUCCESS;'
return 0 and return EXIT_SUCCESS mean the same thing in C (although I suppose they may signal different "successes", whatever that might mean).
void main, though, is just plain bad.
yes, but ur observation is accurate none the less
GOOD WORK!!!...
Plasma and other module like change radically, but how about KDE Control Center? i never hear that KDE control center will change...., hope the next KDE 4, KDE control center will change radically too..
given that kcontrol doesn't even work (e.g. list and load control panels) right now, i wouldn't be surprised if exactly that happened.
if it weren't for the horribly 3rd level deep nesting mess that results from our current array of panels, i'd happily suggest system settings at this point. it could use some love and improvement, but it's not a bad place to start =)
Are there any drafts of what is wanted for KControlCenter or how the new version should look like?
Earlier there were proposals of a KDE registry? Elektra seems to be dead, right?
I really hope we will see some cleanups in the wallpaper field. The Enlightenment project shows how to make a good impressions with high-res visuals.
Please no registry imbecility in KDE. Thank you.
KControlCenter does need to be better organized though. Like getting rid of tabs and instead having more than two levels in the tree on the left. Would be a vast improvement IMHO.
Yeash, perfect, a 5 levels nested tree! so to reach your option you have to click-click-click-click-etc-etc
I think that the best approach is the OSX/Kubuntu one, although it needs some cleanup (and some configuration panels could even disappear)
Tee Hee!
Invariably the configuration panels missing in Kubuntu are the ones I needed to get to.
apt-get install kcontrol provided the fix.
Please please please don't force me to edit configuration files. It has already happened once in KDE. And not with something trivial. Anyone who thinks googling something a number of times to first find what the developers call the thing, then the way to change it is easier than clicking on a few buttons to get to a nested configuration pane should try it a few times.
Derek
And what are these panels missing in Kubuntu?? Really, I didn't even noticed something was missing (and I'm asking seriously, I'm curious now :)
I've noticed. Confused me for ages. I can't remember what they took out but they definitely didn't have all the modules kconfig does (or at least they didn't in the last version).
Agreed. Taking out panels is not the solution. It's just Murphy's law. Other than that, the layout in Kubuntu is rather nice-looking.
What should be more strongly emphasised in both the regular control panel and in the Kubuntu one is search. It already works really well, and could work even better if a conscious effort was done to add more (hidden) key words to the panels.
(Search works less well in the Kubuntu case, because the dimming of icons that don't match the search terms is way too subtle. I have about a 50% chance of guessing whether an icon is dimmed from looking at it, and I don't even have any disabilities. From an accessibility standpoint the search feature is useless in the Kubuntu panel.)
personally I hate the kubuntu thing.
I suppose it is more usable, though, for everyone except me. :)
It's not only you, we are at least two.
I dislike the way it works, but the worst thing by far is the removal of options. Hunting removed settings I know should be there, are beyond annoying.
KRunner in KDE 4 searches through control panel modules pretty nicely. I use it so frequently when I'm writing my KDE 4 articles that I pretty much forget that the Control Centre is borken. Really - I just type 'fonts' into the run dialog, and one of the results is sure to be that config module. Pretty Slick.
I can't find the option to disable the annoying bouncing cursor for example. :(
(To be honest I haven't really looked for it. I searched for "feedback" once but it returned 0 results)
> Yeash, perfect, a 5 levels nested tree! so to reach your option you have to click-click-click-click-etc-etc
Yes, the exact same number of clicks you make to get to the same screen today, be it two, three, four, or five.
Actually two or three normally. Anything beyond that is for very advanced or expert stuff.
Only the interface is more consistent, and with less clutter, because tabs are visually much messier than nodes of a tree.
But improving the logical grouping, presentation and consistency of all settings is what matters the most. It takes a lot of care and thought.
As always, what is the easiest to use is not the easiest to implement.
>the logical grouping, presentation and consistency of all settings is what matters the most
Exactly, if it's two or ten clicks/levels does not matter as long as it's presented in a logical and consistent way. Force all kinds of tricks to minimize levels or number of clicks is just silly, if a increasing the number of levels would give you a more logical interface.
Better to make the most consistent and logical interface possible without imposing such artificial rules. Let the workflow and data decide.
i kind of hope that kcontrol could become a lightweight app with mainly KHTML wiget enabling the editing of system setting though a webinterface (maybe spiced up with some small kparts for stuff that will not fit in a webinterface).
popups should be forbidden.
webinterfaces are more 'scrollable', could easily allow 3rd-party/cross-platform extensions, allows wizard style configuration (like for network connections), a little themeability, etc. etc. etc.
these setting-web-pages would have to be written in a dynamic programming language (ruby, python, KJS). yet they have to hook onto the KDE translation framework.
am i saying something ridiculous? (sorry)
_cies.
Well, it sounds nice, but we currently have a framework for configuration, the config modules (you can invoke a simple config shell with the commandline tool 'kcmshell', try it). So we're only talking about how and where to present these modules, NOT the layout and configuration itself (which depends on the modules).
You can easilly have extensions to this, just introduce a new kcm module.
Themability is KDE-wide, we DON't want applications to theme themselves (have a look at Kopete in this regard, it is, like every KDE app, very flexible, but DOESN't have any useless Kopete-specific skinnable stuff). Of course icons etc are OK.
regarding themeability i thought more of a kopete-style like theme then a widget-style like theme.
anyway it was just an idea.
_c.
Marble / Digest quote:
"Don't expect wonders though - you won't be able to spot your house any time soon. However as you might have noticed, that's not Marble's ultimate goal :-) See the FAQ in the docs for more info."
What are you talking about? One day soon KDE will launch their own GPL3 satelites and we will have fully controlled support for this too! ;) Gotta support your KDE Mars users too! KDE universal!
first konqi in space? ;)
Please, please, please... variables or other mechanism to redraw karamba
only when changes happens, i.e.: for amarok music cover image, but also
background images or icons needing to be redrawed too often and also text.
Actually SuperKaramba is using Much more CPU power than kopete smoothscroll.
Currently, yes, but that's mostly due to the horrible way it's transparancy works. I'm pretty confident that the KDE 4 plasma way will be much more efficient...
Transparency in trunk is already a lot better and thus loads of repaints are no longer needed. Which naturally means its a lot smoother and less power hungry.
This also shows a really good reason why it takes longer than the patience of some people in the audience to create this thing. We need to work on general graphics features before its useful to build a beautiful plasma and thus it takes longer before there is something visible.
Plasma just is an appartment flat building that is started 10 stories underground and thus takes a bit of time before it starts to look like something real is happening.
Thanks for the wait! It will be worth it :)
Redrawing is still a problem with SuperKaramba. Unfortunately the problem is a bit more complex. Redrawing a meter only when the sensor data is changed is a good idea, but unfortunately reading the sensor value takes almost the same amout of time than the drawing. So half of the time of the update process is already wasted with updating sensors.
Authors of system monitor themes tend to refresh the themes quite often, meaning that sensor values will often change, like the cpu load changed from 1 to 2%. And this means that we have to redraw very often.
We also have the problem that some themes force to redraw the widget to dofor animations. Unfortunately the way animations needed to be done in former SK versions doesn't work very well with the QGV, meaning we have to redraw even more in this situation.
On the positive side fake transparency is gone now, so bigger themes should be much faster now. The move to QGV introduced some performance problems but also gives us the opportunity to do some nice eye-candy in the future and perhaps even integration into Plasma.
If you have more comments, wishes or bugs feel free to join us at #superkaramba at irc.freenode.org
Thanks for that detailed and professional answer.
p.s. SK rocks :)
[i]On the positive side fake transparency is gone now, so bigger themes should be much faster now. The move to QGV introduced some performance problems but also gives us the opportunity to do some nice eye-candy in the future and perhaps even integration into Plasma.[/i]
I thought SK would practically BE Plasma?!? Can you explain the relationship between these two?