"[Plasma] works quite well already, although it crashes from time to time and then my plasmoid settings are not saved."
periodic saving will be implemented, though possibly after 4.0, depending on how a few other items go. i don't want to repeat the mess we had in kicker where applets would sync() various different files (2 or more per applet in some cases) on every possible change. that's not nice on the disk.
we now share one config file per corona, so this opens the possibility of one global sync(). what's missing is a way for applets to tell plasma that they would like a sync to be done. unfortunately the KConfig classes provide no notification on local change nor do they even provide a way to tell if the config is dirty (that's part of the private API only). so we need to provide a way for plasma plugins of various ilk to request a config saving. then plasma can schedule one (probably with a short delay in case several requests are made in a short timeframe, something that is fairly typical in various situations).
as for crashes, please send backtraces of such events. =)
"If I log out and log back in plasmoids lose there rotation setting."
known issue; the rotation is saved but the restore code is broken currently. my bad.
"The panel is not configurable yet and I have problems removing applets therefore."
will be addressed soon.
"KNewsticker, which is actually in extragear stresses my CPU quite much here, since the animation seems to be completely done (I can remember the same issue with the KDE3 applet) without graphics acceleration.
it has nothing to do with acceleration or not and everything to do with the fact that QGraphicsView's clipping implementation is currently quite simplistic to the point of naivety. this causes massive amounts of unnecessary repainting when clipping objects (among other things, such as some interesting event propagation issues). fortunately Andreas knows all about these issues and is working on them. by kde 4.1 we should have a better behaved clipping implementation, if not sooner.
"I am also a bit confused since plasmoids claim that OpenGL shaders are not supported here. It is right that Intel chipsets (at least <965) have no hardware accelerated shaders, but I can at least render stuff, e.g. Google Maps, Nexuiz, VDrift here, even if they perform badly. So in my opinion that should be configurable, since small OpenGL animations would work.
if you don't have shaders, and the applet uses shaders, there's not much that can be done except rewrite the applet to not use shaders. Plasma::GlApplet does not require shaders itself, but some applets, such as the bluemarble 3d globe (no relation to marble, the kde4 mapping widget, btw) do. so you can use OpenGL applets on your system .. just not the ones requiring more advanced hardware and/or drivers.
hope that clears a few things up.
24 comments:
Dear Aaron,
I have a simple question, that has maybe been already asked before, so excuse me if it's the case.
At the beginning, I though that configuring Plasma with the top-right zone was for beta version, development... but not final version.
Can you please tell me if it will be removed? I mean, a simple right click on the desktop and an option "Configure Plasma" would look nicer.
Thanks.
"if you don't have shaders, and the applet uses shaders, there's not much that can be done except rewrite the applet to not use shaders."
Due to the closed, non-free nature of the current crop of graphics drivers, might it be a good idea to write each applet with non-shading in mind? I'd rather that plasma look good AND not eat my CPU, rather than look better, or force me to use non-free drivers (which I admittedly do sometimes, but playing devil's advocate here).
Thank you for your hard work, Aaron and the whole of KDE.
Comments are now allowed, sorry, I've missed that when testing KBlogger.
Thanks for your reply!
Cheers,
duns_s
I have a small question concerning Plasma : does is handles virtual desktops ?? (I didn't found it)
It is the last thing that prevents me from using kde4 daily...
Thanks for all the work you are doing !
lefty.crupps: I might be wrong but AFAIK my Blue Marble applet is the only one using shaders ATM, so you won't miss much if you don't have/use them. Certainly it doesn't affect the whole Plasma.
About Blue Marble, it was meant to be more of a test/demo than something actually useful, so I don't plan to make a non-shader version of it.
First I'd like to say I'm happy to see how much kde4 has improved in the last month, since I've been in the army (it's obligatory for 9 months here ...). Second, I have to agree with temet. The plasma configuration option on the top right is not a very good looking idea in my opinion. I don't want an annoying area somewhere on my desktop when I have a nice wallpaper and nicely arranged applets on it. And finally, I'd like to ask if there will be a y-axis rotation for plasmoids implemented. Since the z-axis rotation has been implemented I would guess it's not so difficult to do and also I believe it could be a very ergonomic and beautiful way to fit more things in one screen.
I'm wondering the same thing as houba. In particular I love mousewheel over desktop switching desktops.
Also, what's the key combination that brings the desktop widgets to the top?
a bit offtopic: but why is kwin opengl compositing so slow compared to compiz?
i use nvidia, and compiz is blazing fast compared to kwin opengl compositing.
Hi, Aaron.
Just re-doing my previous comment to get on-toppic only (I will post the off-topic part in private at your kde e-mail, if you don't find it too intrusive) and getting some first things (as introducing myself and, specially, some necessary though short congratulations I missed doing) first ;-)
I'm Janz, a Brazilian KDE good fan from a long time and trying to get on my way of helping it more effectively. I have to congratulate and thank you guys for what kde4 is and is becoming. Just great! Plasma, Phonon, Solid, Kross and way more are real good stuff, giving us a real consistent desktop as well as its apps!
Well, I have an Intel 950 (or maybe 945) graphics card in my notebook, where I'm testing svn's kde4 on kubuntu Gutsy (according to Techbase's kdesvn-build instructions).
I can't avoid to see that, in a general way, kde4's effects are not that fluid, like if they were missing frames in the middle (as when, to mention the slowest ones, opening/closing a menu or - the worst - window minimize/restore), making me to feel them a bit heavy, even to drag a window. It's not that they're unsable (actually, I'm usign kde4 as my day-by-day desktop) but just annoying a bit (by constantly stop me to take me wondering if it's heavy).
I thought my driver wasn't good enough but this week I received my Kubuntu and Ubuntu CDs (both Gutsy) from Canonical and, testing Ubuntu (what there's a good time I don't do) on Live CD, I've got impressed on how fluid its (Compiz) animations were. And, if I'm not wrong, all (default) graphic effects were there (I tested the basics, opening/closing windows and menus, minimize/restore, desktop switching, alt+tab and alike, and maybe some more else). And they (look like) weighted nothing (I checked no pc resources, this is just feeling - what is, at least in the end, the most important).
I think they can't be *directly* compared but have you guys already made some comparative tests like these (maybe to see what they do good and kde4 don't - yet - and get some inspiration on that)? There're some performance interesting difference there ...
I'd like to know if you (or somebody else) get the same in this comparison. Thanks.
"a bit offtopic: but why is kwin opengl compositing so slow compared to compiz?"
kwin_composite has had a fraction of the manpower applied for a fraction of the time and has had a fraction of the end-user testing that Compiz Fusion has had.
> periodic saving will be implemented
I hope by that you don't really mean _periodic_ saving. I don't want to see my disk spinning instead sleeping, just because of Plasma doesn't write changed configuration data, exacly when I chose to change the configuration of some Plasma applet, but every N seconds instead. Do it, when there are configuration changes and - pretty please - don't flush the data to disk, but let the filesystem do its job. This is minor configuration data and if there is a problem and some file should not be synced to disk, this is no drama.
@anonymous: "kwin_composite has had a fraction of the manpower applied for a fraction of the time and has had a fraction of the end-user testing that Compiz Fusion has had."
then why is slow compared to compiz?
i mean, please don't take this wrong, i'm just trying to give a constructive comment because i love kde, and i want it to succeed and i know it will succeed, i believe in kde4 and i like the progress i'm seeing every day in SVN, i think kde4 is great and i love it, but i just think that kwin-opengl-composite still needs some more work or at least some optimization work compared to the speed of compiz.
some things are just slow when i have opengl-composite enabled in kwin, if i keep pressed left-click in the mouse and i select all the desktop it feels laggy, if i scale or move plasmoids, it feels laggy... if i try to run a opengl game with kwin-opengl-composite enabled it feels really laggy... this doesn't happen if i disable "desktop effects" or turn off composite in X, it doesn't happen when i try with compiz too, so i guess kwin-opengl-composite still needs some more optimization work.
kde4/plasma is looking great/sexier all the time and i'm using it every day and i'm loving it so keep up the excellent work and i hope to see more optimization work in kwin-opengl-composite in the future :-)
@temete: "I though that configuring Plasma with the top-right zone was for beta version, development... but not final version."
no, you're thinking of the old flickery widget thing with all the debug related buttons in the top left that disappeared a couple months agon.
"Can you please tell me if it will be removed? I mean, a simple right click on the desktop and an option "Configure Plasma" would look nicer."
right clicking is:
a) difficult on a cluttered space
b) not discoverable for new users
c) "tricky" with a touch screen and a stylus (think about it)
hover interfaces are:
a) discoverable
b) easy
and if you are concerned about it getting in the way, you probably have tried clicking on something behind it ... because clicks go right "through"
i know it's different, and i know that every thing that is done different gets complaints. which is sad, because it leaves in the situation of ignoring people (and getting accused of ignoring people, dealing with constant bickering at me, etc) and allowing innovation or listening to people (and avoiding the annoyances) but killing innovation.
so .. yeah, it sucks. i can't really win either way, but if i make the "right" decisions you benefit. pretty shitty way for it to all shake out, isn't it?
@lefty.crupps: "might it be a good idea to write each applet with non-shading in mind?"
well, patches welcome but remember that you're complaining about exactly one, non-essential applet that actually uses shaders for a good reason.
@houba: "does is handles virtual desktops"
you mean a pager? of course. there's a rather nice pager, in fact. virtual desktops themselves is up to the window manager, of course. plasma can only offer ways to interact with them (pagers)
@anonymous mark I: "I'd like to ask if there will be a y-axis rotation for plasmoids implemented. Since the z-axis rotation has been implemented"
you want to skew the applets too? heh. i hardly see the point of the current rotation.
@anonymous mark II: "I love mousewheel over desktop switching desktops."
this works on the pager, though currently not on the default background. i'm of two minds on whether that's a good feature to add or not, tbh.
@all the people asking about kwin slowness: it's already been answered by someone else, but i'll just lend my support to their answer. kwin composite is very new and has just a couple people working on it. compiz has had a few years and a lot of manpower put into it. for kwin to have gotten this far so quickly with so few hands is amazing.
and how about we go and compare window management quality between kwin and compiz? or desktop integration? because kwin comes out ahead there by quite a ways.
@anonymous mark $WHATEVER: "I hope by that you don't really mean _periodic_ saving. "
if you read the whole text you'll find a description of how it will work, which answers your question.
"Do it, when there are configuration changes and - "
like i said, please read the whole article. it's all detailed in there.
"pretty please - don't flush the data to disk, but let the filesystem do its job."
that's kconfig's job.
Telling me that I should actually read what you wrote isn't nice, when you come with verbal plasmoids like
"one config file per corona"
Anyone who isn't into Plasma doesn't even know what a "corona" in this context should be. ;)
I'm pretty sure you're right that the problem is kconfig, but I don't know, if we'd agree on a proper solution.
I'm of course aware that you're working towards a release...
> that's kconfig's job.
Yes and no. I read a discussion on either kde-core or kde-devel on that topic not too long ago. It was something KDE 3.5/Konqueror/Bookmarks related I think. In this thread it was mentioned that kconfig was part of the problem (and some people even insisted that flushing is the right behaviour to not lose _any_ data - even though this is not correct, because hard drives are not transactional and when the data is in the harddisk cache, while you pull the power cable, it is lost despite flushing).
So, if kconfig hasn't been improved to be parameterized to distinct between important and unimportant data, it sucks as in KDE 3.5. That's my opinion, I'm afraid. ;)
Of course the next problem is to disagree about what is important data and what isn't. But instead telling each other on a mailing list what everyone thinks what is important data, it would be better to have some configuration file/facility to let distributors or even users decide, what data should be flushed and what data isn't worth an unscheduled disk access.
you're quoting the wrong bit there with the "one file per corona". here's the relevant bit:
"what's missing is a way for applets to tell plasma that they would like a sync to be done. .. then plasma can schedule one (probably with a short delay in case several requests are made in a short timeframe, something that is fairly typical in various situations)."
see? =) now back to your comment:
"> that's kconfig's job.
Yes and no."
well yes, it is. until kconfig offers come facilities for this, there is nothing plasma can or will do about it. i'm not going to add hacks to plasma to try and do what kconfig's job is. particularly when kconfig is what does the final fsync.
the best plasma can do is avoid calling sync() as few times as possible. that's what i'm doing. right now we call sync *once* on exit, but that's not really enough. so here's a way to improve it without killing performance. iow, plasma is doing what it can and should.
since the topic here is plasma, that's the perspective i answered from.
"it sucks as in KDE 3.5."
maybe in that one way. of course, an improved API, group safety, nested groups and multiple back end support are all ways it sucks a hell of a lot less than in 2.x-3.x .. just to keep some perspective here.
"it would be better to have some configuration file/facility to let distributors or even users decide"
would that configuration file be important enough to fsync on every sync()? ;) kidding, but seriously, it seems a bit overkill and it would mean one more set of configuration to read and manage for every app.
i can see a small set (e.g. size of one) of configuration options that allows one to set if all configs should be sync'd every sync(), based on what the app says or only on kconfig dtor. that should probably be enough variance without geting too crazy. what do you think?
Aaron, concerning the top-right zone for configuring plasma. I agree on the fact that you see it much more easily than a right click. But don't forget that all users won't be newbies and even major part will be KDE 3.5 users at the begining.
I have no icon on my background (and I'm certainly not the only one), if there's no possibility to hide this zone, I have to say that I will never use KDE 4! I have used KDE 1, 2 and 3... very happy. But I pay attention to the look of my desk and can't let this disfigure (hope it's right in English) my background!
And my feeling about the mouse wheel on background to change desktop is that I'm using it every day...
PS : sorry for the negative aspect of this comment, I do really love most of KDE 4 features... but don't forget the small features for "old users"...
> just to keep some perspective here.
Granted. I didn't mean to sound balanced. :)
>i can see a small set (e.g. size of one) of configuration options that allows one to set if all configs should be sync'd every sync(), based on what the app says or only on kconfig dtor. that should probably be enough variance without geting too crazy. what do you think?
To be clear: I didn't mean any user visible (speak: GUI) configuration option. Of course such a facility or even assuring provide the values to check a plain file against would be a bit of overhead on the development side. I'm just not fine with flushing trivial configuration data and I'm sure not to be alone with it. On the other hand there will be always people who disagree on that topic.
I'm not that into KDE development, but to answer your question: Assumed kconfig dtor is called on application termination - strong words - I'd loathe it. Think about shutting down your system taking ages just because a sleeping disk is spinning up to write some configuration data, not to mention being low on battery and loosing all changed configuration data of all open apps. Delaying writing of configuration data is painful in case of an application crashing as well. So, if my assumption of what you mean is correct, this is not an option
> I will never use KDE 4
your call.
> sorry for the negative aspect of this
> comment, I do really love most of KDE 4
> features... but don't forget the small
> features for "old users"
obviously all those features aren't that interesting then if one innocuous item in the top corner of the desktop that really, honestly doesn't get in the way is enough to trump them all.
ocd much?
> assumption of what you mean is correct,
no. read what i wrote again.
hi aseigo
i just wanted to say that you are doing an amazing work with plasma and kde4, and many people in my country admires your work and your attitude.
keep up your excellent work and rock on ;-)
There is some confusion. Intel hardware has shaders. i945 has pixel shaders, while i965 IIRC has pixel and vertex shaders.
The desktop toolbox i think is a very good feature. I use it all the time. I find it easier than right clicking and I have a two button mouse.
Also, not everyone uses Multiple Desktops. Therefore desktop switching by mouse wheel is kind of annoying. I don't use more than one desktop because I get confused on where everything is (call me a windows guy if your must) Also, I feel that using extra cpu power to switch between them is pointless because one desktop can do everything that 4 can.
On my XFCE machine i am constantly scrolling on the desktop by accident when a window is small. This gets annoying because I'm working, and then all of a sudden my work is gone and i have to figure out where it went. It takes time and extra energy that is unnecessary. And seeing as how many people like myself rest their mouse off to the side of the screen to minimize visual distraction (inside of whitespace...which in a small windows is usually a window in the background or the desktop) the potential to accidentally scroll on the desktop is high, especially when using a touch pad with a vertical scroll area.
All of these features being suggested would work for some though, so they might be able to be implemented VIA configuration options (ex: turning off the desktop toolbox) later on in the plasma development cycle, but my belief is that at the moment all they do is risk breaking things that already work.
If everybody wants to see a rock solid plasma then everybody has to realize that every new feature that gets added hurts that possibility. At this point in the game developers should be focusing on stability, especially considering the release date is a little over a month away. I think they're doing a pretty good job at that so far, in fact plasma today is very stable, but there have been previous times where I've logged in, and because of a new feature plasma would crash often.
Temet: you'd refuse to use kde4 because of that one little icon in the corner?
...
well, your loss.
(I have a feeling some random bored developer is going to make it hide-able within a week or two anyways. always seems to happen. plasma's changing so fast, people keep having to find new things to complain about)
I agree that mouse wheel switching is annoying for people that don't use virtual desktops. I'm just asking if there will be an option. Kind of like how it's off by default in KDE 3.5, but able to be turned on in the Multiple Desktops module of KControl.
I have no issue with my favourite features not being default, I'd just like them to be available to those that want it.
Also, I understand it's not a priority, and I can wait. I just wanted to make sure it wasn't overlooked or forgotten.
Post a Comment