Kernel Cousin KDE #41 Is Out

Wednesday, 24 July 2002 | Rkaper

Kernel Cousin KDE #41 has been published. This edition includes Konq/E updates, KOrganizer compatiblity with Exchange 2000, tabbed browsing updates for Konqueror, KDE 3.2 candidates such as fractions with KBruch and KSVG. Enjoy!

Comments:

OMG! - ac - 2002-07-24

Look at this: http://svg.kde.org/Screenshots/index.html

Re: OMG! - Q - 2002-07-25

I suspect I need a 10GHz processor to actuall be able to work with my computer with this...

Re: OMG! - dwyip - 2002-07-25

Something about those screenshots: Chinese ideographs (check out ksvg-i18n.png) all appeared as question marks. I'm assuming that that's been fixed since that shot was taken? :)

Re: OMG! - Nikolas Zimmermann - 2002-08-17

Hi guys! Those screenshot are actually quite old. We have full support of arabic, hebrew, yiddish, chinese, polish, czech, chinese, japanese (kanij)... All works :) Except top to bottom, this doesn't work. You say OMG to those screenshot? You ought to see KSVG in action.... Bye Bye Niko

Nevy OS - Benjamin Meyer - 2002-07-25

"Nevy OS, an operation system based on Qt/E with its main component being Konq/E". Can someone tell me what this is? The website is really veuge. Is it suppost to run on something like the Zaurus or a real desktop? Does it have console tools or all graphical. It talks about having an alpha, but I can't find it on its web page. What version of QT? What apps does it have? Does it have the kde libs or only Qt? Anyone?

Re: Nevy OS - My Left Foot - 2002-07-25

"Can someone tell me what this is? The website is really veuge. Is it suppost to run on something like the Zaurus or a real desktop?" So far as I can tell, it's a stripped-down Linux system mostly designed for older, slower PCs and, I guess, 'information appliances'. It uses Qt/e running on the Linux framebuffer for a GUI, avoiding the overhead of X. From the screenshots and description it appears they are not using Qtopia but rather their own basic 'program launcher' environment which also has a simple file manager built-in, I suppose not that dissimilar to some of the more advanced WMs for X like Afterstep or Enlightenment. kdelibs would be inappropriate for this system as kdelibs requires X. As it's a Linux system at heart, there's almost certainly some kind of text console available, but it's quite possible it's well hidden. As for available software, if it's using Qt/e then any sotware that runs using Qt/e only should work. Konq/e is listed as it's probably the single most important app for an environment like this - no-one is going to bother with it unless it can at least view webpages - but as you probably well know, there's a lot more Qt/e software out there. If it's using Konq/e currently then that means it's using Qt/e 2.3.x. A compact system like this makes a lot of sense for people with limited computer hardware, and this is a particular problem for developing countries like India, where this comes from. Think K6/200 with 16 or 32MB RAM or less as a target system. Even in the developed world, this configuration is still widespread, and it doesn't run most modern software very well. Linux has had a lot of success breathing new life into old machines as servers, but has been less successful at turning these into GUI machines for Mr/Mrs/Miss/Ms Average. The big X desktops are too complicated and resource-hungry. Simple X WMs are not consistent enough with the (mostly Qt or GTK) apps that will be run. Qtopia is nice, but is really aimed at handhelds and is probably still a little complicated for someone who's never used a computer before. I think NevyOS will fill quite a substantial niche that hasn't really been addressed properly (assuming they do it right, of course): a dead-simple interface with no way of breaking things, running powerful modern Qt apps well on ancient hardware. Perfect for government-sponsored 'get-everyone-online' campaigns. It could be just the thing to put Linux everywhere.

Re: Nevy OS - Michael Lehn - 2002-07-27

Same question: So where can I get it? Can I test it on my computer?

SVG icons - Janne - 2002-07-25

I guess they are nice... But why is that the every example of SVG icons I have seen (screenshots etc.) has had HUGE icons? To show off how you can scale the size? IMO huge icons look silly. I like my desktop uncluttered, and that means that the icons are like they are supposed to be: not too big.

Re: SVG icons - Carbon - 2002-07-25

Yeah, it's pretty much to show off scaling. With a static screenshot, they can't show off the other cool thing about SVG icons: animated smooth scaling.

Re: SVG icons - theorz - 2002-07-25

It could also be that many of the people who want svg icons, want them because they can get big. I only have 3 icons on my desktop, so I like the idea of being able to make them into nice big targets for my mouse.

Re: SVG icons - Mike Hearn - 2002-07-25

Mmmm, I can't wait for SVG goodness to get into Linux. But .. one question - why are the KDE team doing their own implementation? What's wrong with using the GNOME peoples implementation (other than the parts to integrate with konqueror). I'm not trying to troll, but it strikes me that SVG is a huge spec and very complex to implement. We now have 4 implementations in the OSS community (that I know of): - GNOME2: libsvg? - KSVG - Mozilla SVG - Apache Batik Surely the actual drawing the image part could be encapsulated into a library and reused. It seems an awful shame to replicate so much work over and over.

Re: SVG icons - James Richard Tyrer - 2002-07-25

Actually, KSVG does use GNOME code. libart http://www.gnome.org/~mathieu/libart/libart.html -- JRT

Re: SVG icons - My Left Foot - 2002-07-26

libart isn't *really* GNOME code though, even if it is developed in GNOME CVS. It has no dependencies on any GNOME or even GTK+ code, so it is an equal-opportunity library: everyone can use it, without bloating the code linking to someone else's toolkit. Of course it's written in C, so C coders perhaps have a slightly easier time using it, but everyone uses libraries written in C all the time anyway, so it's no real advantage. As for why there are 4 competing implementations of SVG on Linux: any full implementation of it is going to rely on one toolkit or another, as it has to draw on-screen and interact with the user. But no-one is going to be willing to bloat their code with someone else's toolkit. I guess you could build a library that knows about Xlib and can draw and receive events on its own but then you just made your life 10 times harder and need to write 5 times as much code It's a lot more complicated than with the simple bitmap image formats, where a single standard library can do nearly everything. Much of the implementation simply isn't sharable because it's toolkit specific: how to draw on the screen, how to detect input and events, oh, and the scripting: whose Javascript interpreter do you use? KJS? Mozilla's? I don't think Mozilla would be happy to have to include KJS, and vice versa. They already have their own perfectly good implementations, adding someone else's would be some fairly serious bloat. Of course, you could try and define a standard plug-in interface for interpreters and try and mangle both KJS and Mozilla to fit that, but then, that's a major refactor of some pretty fundamental code to both projects just to support SVG. It's simply easier in this case to build your own SVG implementation, and get the benefits of code reuse with your own toolkit and project. What can be shared is already being shared, at least between the GNOME and KDE implementations, and that's libart.

Re: SVG icons - David Fraser - 2002-07-30

Mozilla SVG support also currently uses libart see http://www.mozilla.org/projects/svg/

keep 'em coming! - Navindra Umanee - 2002-07-25

Still loving the summaries. Thanks for keeping them alive.