Description: I started to work on this today to give an example, but man, more involved than I thought. I propose a complete rewrite of the desktop background code. Currently you can select to display and image and optionally have a gradient of some kind overlayed on it. This works for most people, but I like more control.
How about this. The desktop is actually composed of layers, much like an image in the gimp or so. There are different layer types. For example, there could be an image layer type. Here you select the image, or wallpaper, and then some other items like scaling types, position offsets, alpha blend. Then there could be another type gradient. Here you get your usual gradient options. It would be super damn cool if the gradient editor was like the gimp gradient editor. Ok, so now we have a list of layers. The backend code then loops through the layers one by one to generate a flat image to use as the background.
Another twist on this, which I think is the coolest, is plugins. I know it seems kinda overkill for a desktop background, but that allows for people to extend the options for the background very easily. Just have a few hooks. The GUI code for the options could be stored in the plugin. There could be an wallpaper loop pluging, image plugin, gradient plugin, coolGradient plugin, and so on...
The settings could be moved from the kdesktop to kbackground or something like that to avoid the clutter of the kdesktop configuration file.
I think this would be a great boost for KDE that the end user sees. This is something that windows does not have, gnome does not have... I do know that I have seen this kind of configurability in a Linux system at one time, but that was long ago and I have not seen it since.
Instead of doing a re-write. How about doing an extend. Meaning that KDE has the option to run a program as the background of your desktop(s) (In KControl==Background the advanced option) Right now that is limited to pretty much things like xearth or xfishtank but it is capable of running anything (Try it with mplayer a looped movie. *grin*). Seems to me that this would be easier to code. Allow greater flexability in language (whatever you are comfortable using) and since it is "standalone" then you won't be limited by co-ordination with other parts of the desktop.
Sure,
you could do this. But then what would be different that just making the image in the gimp and then using that as a wallpaper. It would work, but it would lack integration.
And that is what the KDesktop is about, integration.
Justace
I guess that's the same thing as (super)karamba, just implemented more low-level. Perhaps you can make (super)karamba to completely replace wallpapers?
I think that this would better be solved by a rewrite of the KDE code. I had not thought of using karamba to do this but after thinking about it, and not knowing that much about karamba I would say it would be better in KDE core.
Not trying to say anything bad about karamba, I use it and like it. A solution for this in karamba would seem to be nothing but a hack to me.
Justace
This is a great idea :D
If this gets implemented into KDE later on, you can definetly bet on getting a beer (tea, or whatever's your poison) from me!!
I just see one little "problem" - how much resources will this eat? ...I mean, I'm constantly running 6 desktops and have different backgrounds on each ...and now I try to imagine what would happen then to my resources when I put like 4 or 5 nifty effects on each background - that would be 6 background images (maybe even more, if i combine different images), with cca. 28 effects.
Keep up the good work ...can't wait to see the end result
Time,
Yhea, that is always the enemy. I think that this would require a complete rewrite of the background code. If I had a month off I could probably work on it. As it is right now, I am getting ready to graduate. So my time is being devoted to writing papers and my other job. So, in short, I do not have the time to write this right now, although I would love to.
Also, as for your other concern, The images could be flattened and then cached. So essentially you only have one image for each background, it is not like they get rendered each time you go to the window. Dynamic content, like a web page or something, needs to be run as a separate program. So this would only be for the static portions of the background.
Justace
One real quick example that I should have placed in the text was this...
You find a cool background, but you want your company logo on your desktop also. So you select two layers. The bottom layer would be the cool background. The second layer would be the logo with the offset of the logo set such that the logo would appear in the lower right hand side of your desktop. You could then have some fun with it and set the alpha on your logo to like 60%, then you would see through it.
Okay, I don't mean to beat on your idea because I really do love innovations, and I hate it when people are close-minded about new ides when it comes to program development, but...what you are describing is essentially the GIMP itself. When a component becomes as complicated as you are describing, you have to ask yourself, "would it be better to write this as a separate program?" To me the answer would be yes, and the GIMP *is* that separate program. Rather than reinvent the wheel, create your ultra-nifty background in the GIMP and then flatten it and import it as your background :)
P.S. It's 3AM, I'm about to go to bed, and my coherency level is very low....dunno if any of what I said makes any sense
I understand your concerns on the overlap of features between this proposed idea and the gimp. However, there it one thing you are missing, ease of use. The intro user will have a hard time using the gimp. It is not a super hard package to use, but it does take some time in a graphics program to understand. This feature would also not be nearly as heavy as the gimp.
Ratings & Comments
11 Comments
just wanted to know how things are comming on :] oh, btw, did you graduate well?
Instead of doing a re-write. How about doing an extend. Meaning that KDE has the option to run a program as the background of your desktop(s) (In KControl==Background the advanced option) Right now that is limited to pretty much things like xearth or xfishtank but it is capable of running anything (Try it with mplayer a looped movie. *grin*). Seems to me that this would be easier to code. Allow greater flexability in language (whatever you are comfortable using) and since it is "standalone" then you won't be limited by co-ordination with other parts of the desktop.
Sure, you could do this. But then what would be different that just making the image in the gimp and then using that as a wallpaper. It would work, but it would lack integration. And that is what the KDesktop is about, integration. Justace
I like the idea, although I'm scared for heavy cpu/mem use ;-) but more flexibillity is always nice, so I'd vote for.
I guess that's the same thing as (super)karamba, just implemented more low-level. Perhaps you can make (super)karamba to completely replace wallpapers?
I think that this would better be solved by a rewrite of the KDE code. I had not thought of using karamba to do this but after thinking about it, and not knowing that much about karamba I would say it would be better in KDE core. Not trying to say anything bad about karamba, I use it and like it. A solution for this in karamba would seem to be nothing but a hack to me. Justace
This is a great idea :D If this gets implemented into KDE later on, you can definetly bet on getting a beer (tea, or whatever's your poison) from me!! I just see one little "problem" - how much resources will this eat? ...I mean, I'm constantly running 6 desktops and have different backgrounds on each ...and now I try to imagine what would happen then to my resources when I put like 4 or 5 nifty effects on each background - that would be 6 background images (maybe even more, if i combine different images), with cca. 28 effects. Keep up the good work ...can't wait to see the end result
Time, Yhea, that is always the enemy. I think that this would require a complete rewrite of the background code. If I had a month off I could probably work on it. As it is right now, I am getting ready to graduate. So my time is being devoted to writing papers and my other job. So, in short, I do not have the time to write this right now, although I would love to. Also, as for your other concern, The images could be flattened and then cached. So essentially you only have one image for each background, it is not like they get rendered each time you go to the window. Dynamic content, like a web page or something, needs to be run as a separate program. So this would only be for the static portions of the background. Justace
One real quick example that I should have placed in the text was this... You find a cool background, but you want your company logo on your desktop also. So you select two layers. The bottom layer would be the cool background. The second layer would be the logo with the offset of the logo set such that the logo would appear in the lower right hand side of your desktop. You could then have some fun with it and set the alpha on your logo to like 60%, then you would see through it.
Okay, I don't mean to beat on your idea because I really do love innovations, and I hate it when people are close-minded about new ides when it comes to program development, but...what you are describing is essentially the GIMP itself. When a component becomes as complicated as you are describing, you have to ask yourself, "would it be better to write this as a separate program?" To me the answer would be yes, and the GIMP *is* that separate program. Rather than reinvent the wheel, create your ultra-nifty background in the GIMP and then flatten it and import it as your background :) P.S. It's 3AM, I'm about to go to bed, and my coherency level is very low....dunno if any of what I said makes any sense
I understand your concerns on the overlap of features between this proposed idea and the gimp. However, there it one thing you are missing, ease of use. The intro user will have a hard time using the gimp. It is not a super hard package to use, but it does take some time in a graphics program to understand. This feature would also not be nearly as heavy as the gimp.