Kernel Cousin KDE #42 Is Out

Thursday, 1 August 2002  |  Aheimburg

Kernel Cousin KDE #42 has hit the virtual shelves. Juergen Appel talks about KOffice filter improvements, a Lyrics plugin for Noatun, a new Kivio developer, a transparent Kicker (1,2,3), voice synthesization and much more.

Comments:

transparent kicker - me - 2002-08-01

the guy who did this kicker-hack said that there won't be real transparency until X supports it (makes sense to me :). I once heard that the mighty keith packard is working on a transparency server for X (He's also written a paper about it). Is that right? If yes, does anyone know anything about its current status? Another question, a little weird maybe... It seems other operating systems are working towards using 3d-features for window-management, so that moving, resizing and making transparent and other things need less cpu and work smoother (windows will probably do so in their next version, I think it was called longhorn, not sure). Has anyone thought about doing that for linux/x/qt/kde? How hard would it be to do that? thanks!

Re: transparent kicker - Stof - 2002-08-01

It would be really nice if there is a "kernel cousin XFree86" or something. I can't really tell what the status of XFree86's development is just by reading the mailing lists.

Re: transparent kicker - isNaN - 2002-08-02

This is a really great idea! I really wish that someone would do this (im not qualified, ok?)

Re: transparent kicker - Psiren - 2002-08-01

I believe Enlightenment was destined to use 3D hardware. Not sure if thats still the case though, especially since Raster seems to think desktops on Linux are a waste of time.

Re: transparent kicker - joe - 2002-08-01

Windows has been using the graphic card's hardware for accelerating the drawing speed for ages, at least since Windows 3.1 - at least 2D stuff like a hardware-accelerated mousecursor or moving rectangles (read: windows) around the desktop. Guess why Matrox' Mystique and Millenium cards were/are so popular.

Re: transparent kicker - Capit Igloo - 2002-08-01

hum, that story about transparency server for X is very old .See that discussion(12/29/2001): http://www.kde-look.org/news/news.php?id=22 for example, but I can find very much old. I'm afraid that's just vaporware :((

Re: transparent kicker - disillusioned linux user - 2002-08-02

That's right. Transparency server IS vaporware :( Keith Packard even wrote a paper about that 2 years ago (http://www.xfree86.org/~keithp/talks/KeithPackardAls2000/index.html), but where are the results ? Actually, XFree86 is totally obsolete. That's why Windows will win at the end, unless the major distributions switch to a less obsolete system like DirectFB.

Re: transparent kicker - Aaron J. Seigo - 2002-08-03

those are some strong assertions, unfortunately you were light on the supporting information. i've been to the directFB site, but they too are light on details. for those of us who are interested, can you provide a link to a point-by-point comparison between XFree86 and DirectFB when it comes to the following issues: speed, memory, hardware support (video cards, mice, etc), operating system support, network support, legacy application support, difficulty of porting from X11 to DirectFB (assuming there is any), etc...? can you also describe why XFree86 is "totally obsolete"? (again in technical terms as i'm not really interested in sycophantic rhetoric) can you also back your assertion as to how the current usage of XFree86 will cause MS Windows to "win" in the end? thanks...

Re: transparent kicker - Sad Eagle - 2002-08-03

I'd also suggest the following: security; does DirectFB require all apps to run as root? Or does it require all apps to have direct access to H/W (which provides a potential plenty of local DoS possibilities?)

Re: transparent kicker - Stof - 2002-08-03

> can you also back your assertion as to how the current usage of XFree86 will > cause MS Windows to "win" in the end? It won't. Windows didn't lose in the first place. ;-)

Re: transparent kicker - Zack Rusin - 2002-08-04

I'm not the original poster but I'm probably the person who should answer in the first place so if you don't mind I'll reply answering some of your and others questions about DirectFB - 1) speed - the short answer DirectFB wins since all operations are performed directly on the framebuffer device (you need a kernel compiled with a framebuffer device support) 2) hardware support - now here's the problem: 1 should give DirectFB an edge as far as all drawing operations go, but the hardware support is very poor and drivers are available for a very limited set of cards, all others use a vesa driver and it just doesn't work all that well (read as - it's slow) 3) operating system support - DirectFB is developed mainly by developers working for a company specializing in video related technologies working on linux, so I could imagine os support is somewhat limited, 4) network support - it renders through framebuffer, so no not really 5) legacy application support - zero (well unless you want to count one image viewer) 6) difficulty of porting from X11 to DirectFB - trivial and impossible at the same time. This is a great question and also the reason why DirectFB isn't used anywhere right now. All applications working under X11 can work on DirectFB thanks to XDirectFB. So the transition isn't the problem (assuming you have a supported video card and the chances for that are very slim). We can switch at any point and get transparency. But what then? You login, everything is painfully slow, you make two or three windows transparent, take a screenshot to show your friends and logout. Transparency in itself is useless, having multiple transparent windows opened doesn't make you more productive. What would be required to make DirectFB work is a native toolkit (think Aqua) that is capable of using the power of the underlying system. Oh, and no I don't mean Gtk+-FB which is a straight Gtk+ port to a DirectFB. I'm talking about a fully native toolkit - one that isn't limited by capabilities of other graphics api's. A toolkit that makes vector manipulations on windows trivial. And here's our problem - we just can't take Qt and port it to DirectFB - it wouldn't give us anything. All those comments about how DirectFB is the savior are simply not true, they're just naive. One of my biggest problems with DirectFB (which I think was also one of the questions) is that all applications have to be run as root. To use the power of DirectFB a completely redesigned toolkit is required. Then and only then one could see effects similar to the ones Quarts/Aqua give on Mac OS X. So, switching to DirectFB would be a waste of time for us (unless we'll all agree that we do want to sacrifice speed and stability of our systems for transparent windows). We would have to design a completely new toolkit and base a new desktop environment on it. Everything that at this point is available through DirectFB would be possible through extensions in XFree86 (and other X11R6 conforming Xservers in fact). People thought AA fonts would be impossible in X11 because of the way XFontStruct was handled within, Keith proved them wrong with XRender extension. We can prove them wrong again (it's just that the whole 'getting money to buy food' and 'not enough companies willing to pay to work fulltime on stuff that won't bring them profits' presents a little time problem :) )

Re: transparent kicker - Stof - 2002-08-04

> 1) speed - the short answer DirectFB wins since all operations are performed > directly on the framebuffer device (you need a kernel compiled with a > framebuffer device support) Is this an issue at all? I mean, how much time does it take for a 1 Ghz CPU to transfer a few bytes to the X server through a socket? (pixmaps are transferred using shared memory) Nobody runs KDE on a 486.

Re: transparent kicker - Zack Rusin - 2002-08-04

1) Open a window. 2) Click on a frame. 3) Do a quick drag accross your viewport. How fluent was it?

Re: transparent kicker - Aaron J. Seigo - 2002-08-04

about as fluent as Rain Man in danger of missing Wopner. =P and not all of us run (or will be running in the near future) KDE on 1GHz processors with half a gig of RAM. many still have and use 266MHz - 400Mhz systems.

Re: transparent kicker - Stof - 2002-08-09

This is not because X is slow, this is because of the communication between the client and the window manager (or something like that; I read it a while ago). Start Opera or QT Designer or any window-in-window app. Drag the title bar of the windows inside the window, and behold how smooth that goes! And my CPU monitor tells me it didn't take a lot of CPU power. X is not slow.

Re: transparent kicker - Stof - 2002-08-09

Oh BTW, this was tested on my old Pentium 233 with 48 MB RAM, a half year ago, on XFree86 3.3.6.

Re: transparent kicker - Zack Rusin - 2002-08-10

Wow, very impressive, now who would've thought... Now if DirectFB or Quartz people knew what you know it would've saved them a lot of work. Go on their lists and tell them that they can use X11 since you checked it and MDI applications don't flicker in X11 while draging their child windows. And I'm sure you know what happens underneath because you wouldn't be posting this, right? First of all no one said that 'X is slow' it's something you made up to strenghten your argument. Now, I'm sure you know that the fact of MDI application not flickering during movement of their child windows is due to the fact that X interaction with those windows is limited to redrawing the contents of the parent window. In the same sense that Emacs doesn't flicker while you're writting letters, MDI application windows don't flicker when you drag windows inside of them. Menaging windows is a completely different animals, X11 queues request from WM and sends them few at a time. These queues slow down processing of data when all request are coming from the local machine. In that sense DirectFB model of rendering to FB directly beats X11 hands down. And yes X11 is slower then Quartz, DirectFB or Windows GDI (or whatever it's called), and yes it will become an issue once we'd like to do any of the effects Aqua does. It doesn't mean that we couldn't solve them (Rasterman did without even touching X11) but it sure as hell will be an issue sooner or later.

Re: transparent kicker - Stof - 2002-08-03

Lack of transparency doesn't make a windowing system fail! Transparency/translucent windows/shadows are only *eyecandy*. If you just want something productive (which is what 90% of the users want), then X is sufficient.

Re: transparent kicker - Bosson - 2004-05-21

And 640k memory is more than we ever need...

Re: transparent kicker - Bosson - 2004-05-21

Seriously, X11 needs a lot more to survive as holistic window-manager: * Serious event compressions and priorities (at least for redraw) * Backstore and optional save-under that works (perhaps as a cache?) * Transparency!!! (as more than save-under) This can be done using direct-fb and then implementing X11 on top, plus som extra extensions.

Re: transparent kicker - lupinar - 2002-08-01

I like the idea of opengl (or something using hardware 3d) for desktop rendering, it seems much more future orientated than the project using the frame buffer. Projects like berlin had this right but its lack of backward compatibility and developer support is a problem. Would it be possible for a new version of X to exist that does this? Maybe call it X12, dump older the stuff from x that is not commonly used, and add the new stuff to it. Try for being compatible with something like 80% of the present apps. Personally having features like real transparency, xrender, color management, a new font setup, and better hardware acceleration would outweigh the temporary loss of compatibility. Since this is open source the apps people use the most will be updated fairly quickly. The way I see it, as long as it is clear what the new standard will be people will follow it. The transition from kde1 to kde2 was not easy, many programs got left behind, but in the end we are better off for it.

Re: transparent kicker - Lenny - 2002-08-02

I cannot understand the backward compatibility complains whenever a new windowing system i discussed. Look at MacOSX: you can run XFree86 or any other X-Server there and the windows behave like native/local apps.

Re: transparent kicker - Stof - 2002-08-03

Then what about games? Using OpenGL for rendering your desktop eats away precious video memory.

Re: transparent kicker - Rajan Rishyakaran - 2002-08-05

I can only think of one graphics server that does use OpenGL: Quartz Extreme. Unless while playing games you constantly move windows, iconify them, maximize them, close them etc., you shouldn't have a problem.

Fresco - Rajan Rishyakaran - 2002-08-05

The reason why Fresco doesn't make it easy for X11 apps to run on Fresco is that Fresco wants to get rid of one of the most major problems with X Window System - lack of consistency between application. "What do you mean by lack of consistency?" Open GIMP, open Kontour, compare the look. And the UI itself. Besides, we are fighting for the desktop, if we were really interested in X11 apps, why not just clone Windows in the first place. You get more apps that way. Most Fresco guys agree with should just go down the Mac OS X route, using XDarwin to load X11 apps. Maybe we would make something that works like Classic to run X11 apps. There probably be someone to write an implementation of Qt on Fresco as soon as some developers work on Moscow and get sufficient amount of classes and widgets. KDE Libs would be harder, since Fresco pushes CORBA, plus it relies on many X11 stuff.

Re: transparent kicker - Spark - 2002-08-01

Probably I'm rather looking at DirectFB because they seem to make more progress unfortunatly. See this screenshot for drooling: http://directfb.org/screenshots/XDirectFB-MultiApp.png They already have a XDirectFB server which allows for such things as transparency. Their multi application core will allow you to run native DirectFB apps (which could already be basically every Gtk app as Gdk has DirectFB as an optional target) besides a XDirectFB server to load "legacy" X applications. Meanwhile you could just use XDirectFB as a X replacement, this is still a bit buggy though and you won't gain a lot from this besides inactive windows beeing translucent and a cool cursor. This would look like this: http://directfb.org/screenshots/XDirectFB-Rootless.png The biggest problem with DirectFB though is of course hardware support. Matrox works pretty well but I couldn't RIVA driver to work with my Geforce 4 yet so I have to use VESA and that's pretty slow and I have to use a low resolution.

Re: transparent kicker - theorz - 2002-08-02

To me directfb + xdirectfb is what we should have been using 5 years ago. Today we should be switching from the old directfb to one that uses the 3d hardware for acceleration. With macosx using opengl for the gui now, and windows longhorn to do it as well 2d acceleration's days are numbered. DirectFBGL looks like a step in the right direction, but once it is working well they should start moving the basic drawing functions (Rectangle filling/drawing, Triangle filling/drawing, Line drawing, ...) to use it as well.

Re: transparent kicker - Spark - 2002-08-02

One step after another. :) Longhorn won't come out before 2005 (and as we all know software release dates, probably later). It's not that we are close to seeing the end of 2D acceleration. Currently there wouldn't be much gain, even with fast cards. Sure there would be a gain with a fast Geforce 4 but it wouldn't allow for completely new fast interfaces and for current interfaces 2D acceleration is already pretty fast (like the Windows 2000 GUI, IMO it's very fast). So having DirectFB be alive and kicking in the next few years (biggest problem beeing compatibility to FreeBSD, etc) would already be awesome.

Re: transparent kicker - montz - 2002-08-02

well... as I understand it, 2D acceleration is not very advanced and for making cool transparency effects the 3D hardware would be more suitable. Check Evas for openGL accelerated 2D graphics. btw. can you say antialias!!!! :) Of course if someone will not blow the idea, by adding too much vector objects and useless stuff like lights, bumpmapping. But maybe by the time it will be done, we all will be running atleast GeForce5 and simple stuff like that would not ruin our fps :) "Hey i just overclocked my GeForce, my windowmanager is running more smoothly now - i can kill my windows faster than ever"

Re: transparent kicker - tofu - 2002-08-02

QT embedded isn't running with directFB?

Re: transparent kicker - Spark - 2002-08-02

AFAIK no, it's running directly on the Linux FB but not using DirectFB. I think it could be ported though. I remember a message to the DirectFB list from someone with a @trolltech.com email but who knows. :)

Re: transparent kicker - Janne - 2002-08-02

This is an interesting paper to read: http://www.opengl.org/developers/code/features/siggraph2002_bof/sg2002bof_apple.pdf

Re: transparent kicker - Zack Rusin - 2002-08-04

Thanks, very interesting.

filter for latex - Rithvik - 2002-08-01

A filter for latex would be great for me. Lyx is great for writing docs, but kword would give me better control for finetuning the final. looks like it is planned. Looking forward to it.

Kivio improvements - Biz - 2002-08-01

Hello, I don't know if this is being planned, but what would be really nice in kivio is the ability to rotate and scale stencils. Well, you can kinda scale now, but I was thinking of a more formal approach than just grabbing a stencil handle and dragging. One where the user can specify exact sizes. Another feature that would be nice in the long run would be the ability to embed flow charts. For example, save an entire flow chart as an individual stencil so it could be used in other flow charts. Then have the ability to click on that stencil and have the underlying flow chart pop up. This would make logic and data flow diagrams really easy to do. Lastly, I thought the undo-redo stuff for kivio was done in the HEAD CVS. Cheers, Jesse

Re: Kivio improvements - Morty - 2002-08-02

>Another feature that would be nice in the long run would be the ability to embed flow charts. For example, save an entire flow chart as an individual >stencil so it could be used in other flow charts. Then have the ability to > click on that stencil and have the underlying flow chart pop up. This > would make logic and data flow diagrams really easy to do. I have alvays thougt this to be a great idea, but why stop there. Make it possible to embed anything, like cliking on a stencile you get some design description in a KWord dokument, another pops upp a class definition .h file in a kate part etc. Make it so you can embed both external files be it kivio files or whatever or truly embed them in the kvio dokument zip file. This I think will make Kivio a extremly good design/dukumentation tool, and outshine the other charting programs. And besides most of the embeding stuff already exist in KOffice:)

KOffice XML formats - Eron Lloyd - 2002-08-02

I think more people would use KOffice if it used the same XML formats that OpenOffice.org uses internally (not just an import/export filter). I'd MUCH rather use KOffice (as I think it is more enjoyable to use than OOo) to store my files, but having compatibility with other platforms is a must in most environments. I know there were some big debates on this, but I doubt it is something that will go away any time soon. I'd rather see energy focused on 100% OpenOffice.org/StarOffice compatibility than 70% Word/40% WordPerfect, etc. I cannot offer C++ skills to do this, but with enough interest from others, I would be willing to donate some $$$. I think this a worthy cause. Any thoughts? Cheers, Eron

Re: KOffice XML formats - Aaron J. Seigo - 2002-08-03

the german gov is funding research into a common XML-based word processor file format. if they are successful (the process is still ongoing) we can most likely expect to see it implemented in the major open source word processors, possibly with some of that work also being sponsered. this is some ways off yet, but if things work out it should be an even better solution than picking one format as a defacto "standard" based on popularity of the software alone.

Re: KOffice XML formats - Eron Lloyd - 2002-08-04

Hmm...I'm a bit skeptical that the German govt. could come up with a better solution than hundreds of hackers, most with extensive background in office application development, in developing an XML format for documents. Besides, if what you said was true, it would only just cover word processing files, whereas OpenOffice.org has a impressively comprehensive XML solution for word processing, spreadsheets, presentations, and illustrations. All things that could map to the KOffice equivalent. And if such a solution from a third party came about, great. But as of now, the spec is there, it's proven in the field, so could be used right away (we all know how long govt. research can take). Thanks for the info, tho'... P.S.: is the KOffice XML formats documented anywhere? I'd like to compare the two. Eron

Re: KOffice XML formats - David Faure - 2002-08-07

The German governement isn't actually designing a file format. Rather laying out the grounds so that one can be designed, if possible by the KOffice/Abi/OO developers. But most open-source developers don't do things that others want for free ;) Yes the KOffice XML format is documented. See e.g. http://www.koffice.org/DTD/kword-1.2.dtd I do agree though that the openoffice XML looks very nice, and I'm among the ones who support the idea of moving to that file format in the future, as the native one. But that's a big change, and lots of work... Volunteers?

Re: KOffice XML formats - Guido - 2003-01-23

;-) Do not worry, Eron, it is not Gerhard Schroeder and Joschka Fischer who are working on this standard format. They hired professionals to do the job, because they are rather busy doing other stuff. I believe a professional computer engineer is at least as able as a hacker for defining standards. In fact, defining standards is a job that is more suitable to an engineer than to a hacker, I think. But some people are both, why not?...

Re: KOffice XML formats - Eron Lloyd - 2003-01-23

Wow, this is quite an old thread! :-) I'm not concerned about *who* is working on it, just the fact that a high-quality specification already exists, in the form of the OpenOffice XML formats, so Germany doesn't have to re-invent the wheel. They could just move the entire German govt. to this format and help to fund its further development. Also, OASIS several months ago initiated a coalition to do just this, with Sun Microsystems and Corel already on board. Check it out here: http://www.oasis-open.org/news/oasis_news_11_20_02.shtml Cheers, Eron

Re: KOffice XML formats - Guido - 2003-01-24

It is an old thread, indeed. I found it while I was looking for information about compatibility between OOo and KOffice. And That's also when I learned about this project of Germany. Before, I thought they were simply moving to OOo. Well, let's hope they will co-work with the coallition you're talking about. After all, having one (open) standard is what we all want, isn't it? Best regards, Guido.

Re: KOffice XML formats - Lance - 2004-07-29

I didn't even find it and I found it old. Thank you google.

Re: KOffice XML formats - Nicolas Goutte - 2004-07-30

Instead of answering to the old thread, perhaps I should have answered only to your post. :-) Were you searching something specific? If the answer is not somewhere on http://www.koffice.org , perhaps I could still help you nevertheless. Have a nice day!

Re: KOffice XML formats - Nicolas Goutte - 2004-07-29

If I remember well, one of the wishes of the German Goverment was a storability of 60 years. That is not something that you can get out of a hat like a rabbit. (You do not only need to store but also to think how you are going to read in 60 years. 60 years ago digital computers were in infancy.) Have a nice day!

Re: KOffice XML formats - Nicolas Goutte - 2004-07-29

There is the OASIS open office specification and that is what we, in KOffice, are heading too. Have a nice day!