Description: lately there have been sufficient complaints about the limitations of XFree86, especially lack of transparency or inability to add shadows, etc.
i would like to propose the creation of an X module that could provide transparency and possibly layers to XFree86. it should be written in C so that bindings could be created for any language. i would love to see kstyles and gtk+ themes that take advantage of such a module.
if you're a C coder and would like to work on some 'rockstar code,' please give some feedback, and a project could be started.
Maybe a bit off-topic but...
I just recently find out that Rasterman and another guy is working on Evas2, which is a rewrite of Evas that will be faster more feature-rich and also have DirectFB support!
Hi!
I gave a little idea, have You ever seen cursor shadow avaible for nVIDIA GeForce graphics cards users? Maybe it is possible to do something like that using hardware acceleration of GeForce for menus and windows?
I've been searching a bit for screenshots of E17, and altough the shots on the following page are just plain ugly, they do show some nice alpha blended menus.. :)
(now let's hope that they're really dynamic and not static)
http://www.gimpster.com/linux/oldshots.php
especially this one:
file:/home/ealm/Desktop/972757750.jpg
but as you see it's only elements drawn by evas that get alpha blended... so if ie the QCanvas developer agreed to implement evas routines (or rewrites of them) in QCanvas, what we would get alpha-blended is window borders, menus etc... and all apps written with the NEW QCanvas classes.
The pros are that evas is a very fast canvas, and it will do magic to the gfx abilities of KDE, not only the new stuff like alpha, HW-accel (which is a biggie) etc, but also simple painting routines are handled very fast the evas way. Currently KDEs canvas is pretty boring, it's lacking features and speed in comparison to the Gnome canvas, and even more evas of course...
this is one part of KDE that definately needs more focus, maybe someone could try to talk mosfet into this? :)
As you see my suggestion is approaching this problem on the canvas level, and not as a X module which I think would be pretty stupid - then you would need to have the QCanvas take advantage of the functions in the X module anyway in order to provide K apps with the functions, double work and bloated design IMO...
Just my .2
[quote][i]
but as you see it's only elements drawn by evas that get alpha blended... so if ie the QCanvas developer agreed to implement evas routines (or rewrites of them) in QCanvas, what we would get alpha-blended is window borders, menus etc... and all apps written with the NEW QCanvas classes.
[/i][/quote]
But who's going to do that? ;)
[quote][i]
maybe someone could try to talk mosfet into this? :)
[/i][/quote]
Have you already heard about the $200.000 for the new running-Linux-on-the-XBOX project?
Would be nice if some rich person could fund this project too :P
I would definitely help when I got payed..
(sorry, for free is not doable because I can't live without eating and drinking)
[quote][i]
and not as a X module which I think would be pretty stupid
[/i][/quote]
I totally agree.
"But who's going to do that? ;)"
Well... if we don't want to fork and build a replacement canvas for KDE, we better talk the QCanvas guy/girl(s) into this.
No matter what the approach will be we need to get the approval from the KDE team.
We just need to find good arguments and a proposal of HOW to implement this stuff.
the evas solution does sound very enticing. however, i'm not so sure Trolltech will care enough about us to implement anything.
this wouldn't require fork(QT), now, would it?
...what approach you decide to take, the big question that remains is, will the KDE developers care about you?
Instead of starting a project to code this, my suggestion is to start a lobbying project :)
Why not draw a good prototype design and write down a proposal, with benefits and facts.
Hopefully the K developers will agree, if they do they will for sure do it in a different way anyway ;)
Anyone feeling motivated to do a web page?
What do you other people say?
Its all too easy to propose a plan and get support for it. But who is actually going to write it? I havent heard a single post on this thread of someone actually offering to contribute directly to this 'project'.
The X developers, especially Keith Packard know what you all want. KDE developers know what you want. And steps have been taken (Xrender) to create this. However 'eye candy' as much as I like it, is superficial, trivial and imho should be low priority considering some of the far more important work that needs to be done.
I think that you shouldnt try and annoy the developers with a lobby/petition. It would just put more pressure on them and they do such an awesome job now. Also both projects already have bug/wishlists as long as the bible.
Whatever the final solution is, I think Gnome and KDE should work together on this common need. Its important to avoid duplication of work/effort, which im sure will be considerable, and far more than some of you think.
your proposal goes like this:
"i would like to propose the creation of an X module that could provide transparency and possibly layers to XFree86. it should be written in C so that bindings could be created for any language."
this is from http://enlightenment.org/pages/htmlized/evas/ :
"Evas is a solution to a problem, that at the time had no other solution. The problem was that we needed a rendering abstraction layer for X11 that allows for alpha blending, anti-aliasing and image manipulation on a structured, rather than immediate-mode level. One that would also optimise the display of such structured objects and also allow for hardware on existing and future machines to accelerate this rendering without requiring the CPU to do all the work."
...and yes, it even supports layers with *real* translucency
cheers
Since I'm not running Linux right now (sorry, I'm forced to run Winshit for some apps), is there anyone who can take a screenshot of this Evas demo?
And this Evas stuff sounds all great, but is it ready for daily use?
Guess not.. :/
guess what, it is!
Evas, even though it's actively developed, has been quite stable and feature-rich for a year now. there are very good tutorials on evas programming as well (which is quite simple). you find it all on http://enlightenment.org.
Another BIG minus with the FB approach is that we would loose X's networking abilities. Even though most home users wont care about that this is a critical part in getting KDE and Linux onto the Workstations and into company desktops. We wouldn't wanna cripple KDEs usability down by this, would we?
FB has no network ability?!? then that thing after completion, is a total crap.
so... whoever is doing FB developement... better add that to your TODO or the end result of your coding would be a lemon like a certain high-cost rempant OS.
this is just the sort of thing i hoped to instigate.
evas seems to promise a lot, but it still won't prevent an app from having to play 'catch-up' with its window decoration. X is heavy.
a framebuffer would be an excellent solution if it were reasonable to port to it. another solution to the framebuffer problem would be to port the framebuffer to KDE by partially implementing the X API for the KDE processes. that would be a nice compromise. and people could still use X apps much like OS X users do.
only problem: some framebuffers do not offer good hardware acceleration
jvoorhis
evas seems to promise a lot, but it still won't prevent an app from having to play 'catch-up' with its window decoration. X is heavy.
true, but with evas we could already be alot closer to the goal... all the features would be there, then it's *just* a matter of tweaking X for performance, which is gonna happend anyway in X development. IMO X is alot better today than 2 years ago, and it seems like 4.3 will include quite alot of promising new features. Ie goodies like XFT2.
By taking the evas approach we could have an Quartz feature-like KDE desktop in a not too distant future.
"porting the framebuffer to KDE by partially implementing the X API for the KDE processes" otoh, seems like a hell lot of work to me. You expect you can write an abstraction layer XF-FB? don't think so...
maybe you could run XF in rootless, but I don't see the point with that?
Ratings & Comments
39 Comments
Maybe a bit off-topic but... I just recently find out that Rasterman and another guy is working on Evas2, which is a rewrite of Evas that will be faster more feature-rich and also have DirectFB support!
Have you ever seen the Fresco/Berlin project? i think that it's better than other, check http://www.fresco.org
Hi! I gave a little idea, have You ever seen cursor shadow avaible for nVIDIA GeForce graphics cards users? Maybe it is possible to do something like that using hardware acceleration of GeForce for menus and windows?
Unfortunately it's a lot more complicated than you probably might think.. :(
Just a thought: QT has openGL support (QGLWidget). Could it be possible to modify QT to use QGLWidget instead of X11 for drawing ?
I've been searching a bit for screenshots of E17, and altough the shots on the following page are just plain ugly, they do show some nice alpha blended menus.. :) (now let's hope that they're really dynamic and not static) http://www.gimpster.com/linux/oldshots.php
especially this one: file:/home/ealm/Desktop/972757750.jpg but as you see it's only elements drawn by evas that get alpha blended... so if ie the QCanvas developer agreed to implement evas routines (or rewrites of them) in QCanvas, what we would get alpha-blended is window borders, menus etc... and all apps written with the NEW QCanvas classes. The pros are that evas is a very fast canvas, and it will do magic to the gfx abilities of KDE, not only the new stuff like alpha, HW-accel (which is a biggie) etc, but also simple painting routines are handled very fast the evas way. Currently KDEs canvas is pretty boring, it's lacking features and speed in comparison to the Gnome canvas, and even more evas of course... this is one part of KDE that definately needs more focus, maybe someone could try to talk mosfet into this? :) As you see my suggestion is approaching this problem on the canvas level, and not as a X module which I think would be pretty stupid - then you would need to have the QCanvas take advantage of the functions in the X module anyway in order to provide K apps with the functions, double work and bloated design IMO... Just my .2
nice link I gave you :) haha here's the one: http://www.gimpster.com/images/shots/972757750.jpg
[quote][i] but as you see it's only elements drawn by evas that get alpha blended... so if ie the QCanvas developer agreed to implement evas routines (or rewrites of them) in QCanvas, what we would get alpha-blended is window borders, menus etc... and all apps written with the NEW QCanvas classes. [/i][/quote] But who's going to do that? ;) [quote][i] maybe someone could try to talk mosfet into this? :) [/i][/quote] Have you already heard about the $200.000 for the new running-Linux-on-the-XBOX project? Would be nice if some rich person could fund this project too :P I would definitely help when I got payed.. (sorry, for free is not doable because I can't live without eating and drinking) [quote][i] and not as a X module which I think would be pretty stupid [/i][/quote] I totally agree.
"But who's going to do that? ;)" Well... if we don't want to fork and build a replacement canvas for KDE, we better talk the QCanvas guy/girl(s) into this. No matter what the approach will be we need to get the approval from the KDE team. We just need to find good arguments and a proposal of HOW to implement this stuff.
the evas solution does sound very enticing. however, i'm not so sure Trolltech will care enough about us to implement anything. this wouldn't require fork(QT), now, would it?
...what approach you decide to take, the big question that remains is, will the KDE developers care about you? Instead of starting a project to code this, my suggestion is to start a lobbying project :) Why not draw a good prototype design and write down a proposal, with benefits and facts. Hopefully the K developers will agree, if they do they will for sure do it in a different way anyway ;) Anyone feeling motivated to do a web page? What do you other people say?
Yes. A web page petition with a detailed description of what we want done, and our proposal on how to do it. That would be great.
Its all too easy to propose a plan and get support for it. But who is actually going to write it? I havent heard a single post on this thread of someone actually offering to contribute directly to this 'project'. The X developers, especially Keith Packard know what you all want. KDE developers know what you want. And steps have been taken (Xrender) to create this. However 'eye candy' as much as I like it, is superficial, trivial and imho should be low priority considering some of the far more important work that needs to be done. I think that you shouldnt try and annoy the developers with a lobby/petition. It would just put more pressure on them and they do such an awesome job now. Also both projects already have bug/wishlists as long as the bible. Whatever the final solution is, I think Gnome and KDE should work together on this common need. Its important to avoid duplication of work/effort, which im sure will be considerable, and far more than some of you think.
your proposal goes like this: "i would like to propose the creation of an X module that could provide transparency and possibly layers to XFree86. it should be written in C so that bindings could be created for any language." this is from http://enlightenment.org/pages/htmlized/evas/ : "Evas is a solution to a problem, that at the time had no other solution. The problem was that we needed a rendering abstraction layer for X11 that allows for alpha blending, anti-aliasing and image manipulation on a structured, rather than immediate-mode level. One that would also optimise the display of such structured objects and also allow for hardware on existing and future machines to accelerate this rendering without requiring the CPU to do all the work." ...and yes, it even supports layers with *real* translucency cheers
Since I'm not running Linux right now (sorry, I'm forced to run Winshit for some apps), is there anyone who can take a screenshot of this Evas demo? And this Evas stuff sounds all great, but is it ready for daily use? Guess not.. :/
guess what, it is! Evas, even though it's actively developed, has been quite stable and feature-rich for a year now. there are very good tutorials on evas programming as well (which is quite simple). you find it all on http://enlightenment.org. Another BIG minus with the FB approach is that we would loose X's networking abilities. Even though most home users wont care about that this is a critical part in getting KDE and Linux onto the Workstations and into company desktops. We wouldn't wanna cripple KDEs usability down by this, would we?
Well, I really hope it is :) Hopefully it'll be evening soon so I can finally try this stuff.. *drool* .. *wipe*
FB has no network ability?!? then that thing after completion, is a total crap. so... whoever is doing FB developement... better add that to your TODO or the end result of your coding would be a lemon like a certain high-cost rempant OS.
90% of the 'normal' users wouldn't ever use that network crap.. Including me. It's nice to have, but imho it's useless for normal desktops.
XdirectFB is a Xserver on top of directFB: http://www.directfb.org/xdirectfb.xml gtk2 is working with it already...
That's no valid alternative (yet?) because it doesn't run using an NVIDIA card. (well, it does, but it crashes a lot)
this is just the sort of thing i hoped to instigate. evas seems to promise a lot, but it still won't prevent an app from having to play 'catch-up' with its window decoration. X is heavy. a framebuffer would be an excellent solution if it were reasonable to port to it. another solution to the framebuffer problem would be to port the framebuffer to KDE by partially implementing the X API for the KDE processes. that would be a nice compromise. and people could still use X apps much like OS X users do. only problem: some framebuffers do not offer good hardware acceleration jvoorhis
evas seems to promise a lot, but it still won't prevent an app from having to play 'catch-up' with its window decoration. X is heavy. true, but with evas we could already be alot closer to the goal... all the features would be there, then it's *just* a matter of tweaking X for performance, which is gonna happend anyway in X development. IMO X is alot better today than 2 years ago, and it seems like 4.3 will include quite alot of promising new features. Ie goodies like XFT2. By taking the evas approach we could have an Quartz feature-like KDE desktop in a not too distant future. "porting the framebuffer to KDE by partially implementing the X API for the KDE processes" otoh, seems like a hell lot of work to me. You expect you can write an abstraction layer XF-FB? don't think so... maybe you could run XF in rootless, but I don't see the point with that?
If I get this right that "catch-up" problem wont last with evas though... evas can draw it's own primitives so you don't need X for this.