ealm

Agreed. The IM and Akregator integration would be really usable, but not the music thing. - Mar 19 2006

what a strange bug. the post I reply to was amde by xsos, but appears to be from my account. forum bug... - Sep 09 2004

Hello i will remove it as soon as posible - Sep 09 2004

Awesome wallpaper for an awesome distro ;)

I'd recommend you to take a look at the Linspire wallpaper contest over at deviantART!
http://news.deviantart.com/article/15965/ - Sep 09 2004

A CAD app is badly needed for KDE. That's one of those applications missing today.

Good luck! - Jan 16 2004

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! - Jul 09 2002

"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. - Jul 02 2002

nice link I gave you :) haha

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

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 - Jul 02 2002

...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? - Jul 02 2002

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. - Jul 02 2002

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 - Jul 02 2002

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? - Jul 02 2002

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? - Jul 02 2002

..hur har du f - Jul 01 2002