the future of X

Various Stuff

Source (link to git-repo or to original if based on someone elses unmodified work): Add the source-code for this project on opencode.net

0
5 .0
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.

jvoorhis,
[email protected]

ealm

18 years ago

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!

Report

brain

18 years ago

Have you ever seen the Fresco/Berlin project? i think that it's better than other, check http://www.fresco.org

Report

DRAKe

18 years ago

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?

Report

Richardve

18 years ago

Unfortunately it's a lot more complicated than you probably might think.. :(

Report

rbonthond

18 years ago

Just a thought: QT has openGL support (QGLWidget). Could it be possible to modify QT to use QGLWidget instead of X11 for drawing ?

Report

Richardve

18 years ago

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

Report

C

jvoorhis

18 years ago

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?

Report

ealm

18 years ago

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

Report

Richardve

18 years ago

[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.

Report

ealm

18 years ago

"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.

Report

ealm

18 years ago

nice link I gave you :) haha

here's the one:
http://www.gimpster.com/images/shots/972757750.jpg

Report

ealm

18 years ago

...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?

Report

Amibug

18 years ago

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.

Report

Deviant

18 years ago

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.

Report

ealm

18 years ago

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

Report

Richardve

18 years ago

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.. :/

Report

ealm

18 years ago

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?

Report

DrakingMan

18 years ago

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.

Report

Richardve

18 years ago

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.

Report

Richardve

18 years ago

Well, I really hope it is :)

Hopefully it'll be evening soon so I can finally try this stuff.. *drool* .. *wipe*

Report

oliv

18 years ago

XdirectFB is a Xserver on top of directFB:
http://www.directfb.org/xdirectfb.xml
gtk2 is working with it already...

Report

Richardve

18 years ago

That's no valid alternative (yet?) because it doesn't run using an NVIDIA card.

(well, it does, but it crashes a lot)

Report

C

jvoorhis

18 years ago

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

Report

ealm

18 years ago

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?

Report

ealm

18 years ago

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.

Report

12345678910
product-maker Base: 4 x 5.0 Ratings
Be the first to comment
File (click to download) Version Description Downloads Date Filesize DL OCS-Install MD5SUM
*Needs pling-store or ocs-url to install things
Pling
0 Affiliates
Details
license
version
updated Jul 01 2002
added Jul 01 2002
downloads 24h
0
mediaviews 24h 0
pageviews 24h 0