KDE-CVS-Digest for September 12, 2003

Saturday, 13 September 2003  |  Dkite

In this week's CVS digest: KJSEmbed, the KDE JavaScript implementation now supports event handlers. KDevelop adds support for code completion databases. Kexi now has a PostgreSQL driver. Kopete integrates with KAddressBook for IM contacts. The KWin rewrite continues with an added window decoration API. Plus many bugfixes throughout.

Comments:

great work - tetra - 2003-09-13

congratulations, an other nice cvs-digest thanks

ksvg - anon - 2003-09-13

great that it's finally done.. woot.

FanMail! - kidcat - 2003-09-13

Thank you *so* much guys! It is really great to read about all the exiting new stuff.. but even more exiting to read about all the bugfixes ;-) I am especially pleased that kpovmodeler is being worked on.. not to mention ksvg! So... *big* kudos to the 181 developers who made this weeks improvements a reality! [insert huge applause here] /kidcat __ Those who can: develop Those who can't: give moral/finacial support

Re: FanMail! - cies - 2003-09-14

>Those who can: develop >Those who can't: give moral/finacial support There's a lot more to do for "those who can't". http://kde.org/support/ suggests: <snip from http://kde.org/support/> Contributing: [ Artwork & Icons | Enterprise Reports | Usability Studies ] Participating: [ KDE News | KDE Traffic | Promotion | Bug Hunting | Documentation | Translation ] </ snip> But I got some more suggestion for "those who can't": 1. use 2. interrest oneself 3. implement 4. learn to develop Do you have got more suggestions; please put them in this thread! >ksvg! Indeed this will rock! A lot of kapps will benefit from this -- not you mention the eyecandy that it will bring forward. Hopefully karbon14 will get a boost up after ksvg stabelizes (sorry i'm in the: learn to develop (4) catagorie, i can't do it myself).

Re: FanMail! - Eric Laffoon - 2003-09-14

> Those who can: develop > Those who can't: give moral/finacial support :-) That's cute. It made me smile. Don't forget... Those who couldn't but now can (that would be me) somehow seem to end up doing all of the above and more Those who can't do C++ can do XML language support, templates, artwork, web work, translations, CVS digests... Not to be critical, because short phrases can never be comprehensive and I really like yours! As much as Quanta consumes me I wish I could do more, but I like to eat too much. ;-)

Kwin rewrite? - Adi - 2003-09-13

I never knew about this. What is the main reason it is being rewritten? Speed? Features? Both? Oh and it's great news KDevelop now has code completion, that's an essential feature for me. Also, I think that KDE should have fewer planned features for 0.1 releases, it just takes too long, 3.2, shouldn't take more than 7 months IMO and it will most likely be ready in early 2004. Now a 1.0 release that's a true feature release and that should take about a year IMO. Ia lso want to know why KDE no longer has long freeze periods, I think it would be less buggy if it did, last year, the Alpha did not have 5,000 bugs like this one has. Anyway, if all the feautres in the 3.2 releae plan are accomplished and 3.2 gets at least below 2,500 bugs, 3.2 is looking like an amazing release! Thanks KDE developers and Derek!

Re: Kwin rewrite? - Derek Kite - 2003-09-13

Compliance with standards. http://www.freedesktop.org/standards/wm-spec/ Derek

Re: Kwin rewrite? - anon - 2003-09-13

> it just takes too long, 3.2, shouldn't take more than 7 months IMO and it will most likely be ready in early 2004. 3.2 will be out in early december most likely. 3.1 was horribly delayed in order to stabalize a little bit buggy RC and beta releases. 3.2 alpha1, in relation, is MUCH more stable already.

Re: Kwin rewrite? - Tim Jansen - 2003-09-13

>>Ia lso want to know why KDE no longer has long freeze periods, I think it would be less buggy if it did, last year, << Unlikely, the last time KDE had a very long feature freeze (3.0? 3.1? cant remember) this just caused people to start dozens of branches all over the repository so they could work on new stuff. Most people fix bugs because they annoy them, not because they are in a feature freeze. If the software is reasonably stable they will just go on and extend it, because then features become more important than extra-reliability.

Re: Kwin rewrite? - Lubos Lunak - 2003-09-14

> I never knew about this. What is the main reason it is being rewritten? Speed? Features? Both? It's not really being rewritten (i.e. it's not all code dropped and started from scratch). I actually don't think I ever called it a rewrite. It's simply being normally developed, and it's branched in order not to get too many angry mails from people running CVS HEAD ;) - e.g. after the Nove Hrady conference, the only working window "decoration" was a thick red border with a grey square acting as the close button, and it also locked up from time to time. However, there are many places in kwin_iii that have been rewritten in order to clean it up (so cleaning up the KWin core was the reason). This in turn allows fixing many bugs (I even had kwin bug less than #20000 that simply wasn't possible to fix before), and implementing new features, both that will come in KDE3.2 and that will come later. One of the "features" should be also updating KWin's and in general KDE's support for the EWMH (a.k.a. NETWM) window manager spec, and "official" support for running KDE with other window manager than KWin. Important part of the rewrite (heh, ok, looks I called it sometimes a rewrite after all) was the new API for the decoration styles, as the old one has probably never meant to be public API (very closely coupled with all internals of KWin core, so the whole application had to stay binary compatible - acceptable for libraries, but annoying for application, as it was limiting the development). This has the unfortunate effect that old decoration styles won't work with KWin in KDE3.2, but the other possibility was limited KWin development for several KDE releases (note that the decision about kwin_iii came about a year ago, when absolutely nothing was known about KDE4). The new decorations API should be properly documented, and there should be hopefully also some porting HOWTO - decoration developers can join the kwin@kde.org mailing list if they have questions. Decorations in KDE CVS are currently being ported, and the whole branch should be merged back in CVS HEAD next week.

KWin deco preview .. GREAT - Mohasr - 2003-09-13

""Luboš Lunák committed a change to kwin_iii: kdebase/kwin Decoration previews work now, more or less."" does that mean we can preview deco in the control planel like styles? if yes then great :) I've read that kwin is bieng rewritten , right? so, will old kwin deco will work with this new version without change or should be updated ?

Re: KWin deco preview .. GREAT - Mohasr - 2003-09-13

sorry when I wrote my post the message "Kwin rewrite?" wasn't there , I'm sory if there is any duplication

Re: KWin deco preview .. GREAT - anon - 2003-09-13

> does that mean we can preview deco in the control planel like styles? if yes then great :) Yes > I've read that kwin is bieng rewritten , right? so, will old kwin deco will work with this new version without change or should be updated ? It has to be updated, but it's not a terrible amount of work and probably can be done by the author of the deco in a few hours or less. Many of the current ones in KDE have/are being updated in a matter of a few days.

Awesome - Adi - 2003-09-13

Does this mean taht it no longer shows the KDE 1 preview for styles also?!! If it doesen't than this bug should be fixed: http://bugs.kde.org/show_bug.cgi?id=32101

Re: Awesome - anon - 2003-09-14

> If it doesen't than this bug should be fixed: http://bugs.kde.org/show_bug.cgi?id=32101 It will probably this week :)

KWin + (x)kill - lalala - 2003-09-13

When an application locks up when running under GNOME2/Metacity, Metacity will automatically offer the user (after a few seconds of no activity in the app) to kill the application. I've found this to be a really handy feature. Not that I'm using lots of crashy apps, but if it happens it's good to have. Anyway, will KWin get this feature as well? (some day?)

Re: KWin + (x)kill - Anonymous - 2003-09-13

Why make this a function of the window manager? Try KDE's "Runaway Process Catcher" applet. :-)

Re: KWin + (x)kill - anon - 2003-09-13

This has been a part of KDE since KDE 2.0 afaik. It's just not enabled by default for a long time because people on slower computers used to complain that it got activitated a lot.

Re: KWin + (x)kill - lalala - 2003-09-13

Do you also know how to enable this feature? ..and isn't it time-based? Iis it just a hack like in many other places? (even Qt was doing it wrong before 3.2)

Re: KWin + (x)kill - Vincent - 2003-09-13

The gnome runaway catcher works better because it only gets activated when the close button is clicked. Last time I used the KDE runaway catcher, it didn't behave that way. It's problably easier too, if you implement it in the window manager. (The user clicked the close button but the application is still not closed (after n seconds) let's ask the user if he wants to kill it.)

Re: KWin + (x)kill - Maynard - 2003-09-13

It can be made such that if the app does close, then the dialog offering to kill it could go away. Whilst I am all for less bloat, environments like KDE are not meant for lightweight systems anymore. Why should users of heavy systems have to suffer because some people still want to use Pentium 100s. Next year I plan to get an AMD Athlon XP 3000+ and there are going to be more like me, and less with slower systems. I think it is time to move on and make things like this the default.

Re: KWin + (x)kill - Adi - 2003-09-14

I always use CTRL ALT X and click, but I can see how this XP style feature could be useful. I'm for it.

Re: KWin + (x)kill - cm - 2003-09-14

Ctrl-Alt-X doesn't do anything here. Ctrl-Alt-ESC and clicking works for me though...

Re: KWin + (x)kill - Hamish Rodda - 2003-09-14

I believe kwin_iii will have support for NETWM_PING which is what you are referring to: http://www.freedesktop.org/standards/wm-spec/1.3-onehtml/#id3224238

Re: KWin + (x)kill - lalala - 2003-09-14

Yes, that's exactly what I meant :)

Anyone have a screenie of kpdf? - TomL - 2003-09-13

How does it compar to kghostview?

Re: Anyone have a screenie of kpdf? - anon - 2003-09-13

Similiar interface, a __LOT__ faster with pdf's since it uses xpdf's engine, and not slow ass GV's./

Re: Anyone have a screenie of kpdf? - Nobody - 2003-09-13

And kpdf is cool, but is it just me or why it seems that having kpdf/kdvi/kghostview a bit redundant? And isn't there almost entire xpdf source code base on the kpdf, any idea could there be any work being done for example making uniform library used by both?!? And while being in the subject, why there is kamera and kooka as both do very similar things and having some sort of integrated software for common image input + ocr functionality? And (redundand 'yes'es, heh!) thing I would like to see is to move noatun/kaboodle/xine(plugin)/xanim(legacy or what?) out of distribution to kdenonbeta/kdeextragear(s) and move in kmplayer and possibly approaching to get kplayer to use much much more vide codec base from MPlayer. Oh well not gonna happen. :-(

Re: Anyone have a screenie of kpdf? - Anonymous - 2003-09-13

Kaboodle and aKtion (xanim) are gone. And why obey to your personal preference of MPlayer over Xine?

Re: Anyone have a screenie of kpdf? - Nobody - 2003-09-13

Just try playing less common video files like divx5, vcd or theora as support for those is somewhat... While even MPlayer-0.9x can do them, not to mention the 1.0pre1. But hopefully noatun is fixed for similar support as kaboodle were as for some strange reason some files don't play with noatun but kaboodle don't have any difficulties... Strange by any standards as I thought kaboodle were just a little brother to the noatun?

Re: Anyone have a screenie of kpdf? - Nobody - 2003-09-13

And xine's UI is way too different from all other kde system programs while kplayer is pretty standardized and of course kmplayer is just a plugin for konqueror so pretty complete replacement for kaboodle, too bad it doesn't inplement a konqueror's side kard...

xine - Paul Eggleton - 2003-09-14

The benefit of the xine architecture is that the library is separate from the interface, so you don't actually need xine-ui (which is no doubt the UI you are referring to, however it isn't the only one available) to run the xine engine. Having used the library myself, it's also very well designed and easy to use from a developer's perspective. Not only that, but it has working DVD menus and well-rounded codec support. For those reasons IMHO it makes a better choice as a base for a KDE player than MPlayer (at least until Mplayer2 comes along - however xine is here now).

Re: xine - Nobody - 2003-09-17

MPlayer can be compiled as lib-only, but the point were that mplayer support much more video codecs that xine don't even plan to support yet on their todo-list, like theora/divx-5.02 (sure they acclaim divx-5.02 and newer are supported, but those files just don't work). And as kmplayer (were to replace kaboodle?) is already in the kdeextragear2, why not bump it to the release as it doesn't waste too much space anyway... And just if there were kplayer then the whole noatun/xine stuff could be replaced. Why wait if the mplayer and companions might replace 'em in future kde?

Re: Anyone have a screenie of kpdf? - Spy Hunter - 2003-09-13

It is not redundant. A library would be nice, but it doesn't exist yet, and there's no reason to make us keep using slow, ugly GhostScript PDF translation when KPDF is sitting right there for us. In fact it will be much better to have both I think. KPDF is so much better for viewing PDFs that most people will be much happier with it. I think after the release we will probably see many happy comments exclaiming about how much better pdf viewing is in KDE 3.2. For those people who need to view .ps files, though KGhostView will always be necessary. KGV is still much better than any free Windows .ps viewer.

Re: Anyone have a screenie of kpdf? - Mohasr - 2003-09-13

why not just merge kpdf\kgs\kdvi into one powerfull app to view .pdf , .ps , .dvi ? I think they are similar sounds as if we have a viewer for .png and one for .gif and another for .jpg isn't pdf ps div are documents that are plateform independent just as pics songs mp3's ? this is just my own opinion

Re: Anyone have a screenie of kpdf? - Nobody - 2003-09-14

Yes I have been using the kpdf for a while myself (from CVS) and it really is a cool piece of software compared to having xpdf just for PDFs to bloat the dependency hell. But the point were that why are those own separate programs, I bet those are overlapping code that could be wiped off if kpdf/kghostview/kdvi would be a single application. The library scenario is of course way off to the future, but that singularity would be for KDE's benefit as IMO there are too many separate programs for very similar tasks.

Re: Anyone have a screenie of kpdf? - Thomas - 2003-09-14

> But the point were that why are those own separate programs, > I bet those are overlapping code that could be wiped off if > kpdf/kghostview/kdvi would be a single application. My guess is, that all these apps you mentioned are based on kviewshell hence all _do_ have a sort of a common codebase... though it may not be the biggest part of code that's shared among them. I am not a coder so don't rely on me... You could still take a look at it here: http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdegraphics/kdvi/ http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdegraphics/kpdf/kpdf/ http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdegraphics/kghostview/ Well, to be honest I did not find any includes referring to kviewshell in kpdf, but as I said I've no experience with reading c++

Re: Anyone have a screenie of kpdf? - anonon - 2003-09-14

>why there is kamera and kooka as both do very similar things kamera and kooka? You've lost me.. Kamera is a digital camera ioslave, Kooka is a SANE/OCR frontend. Apart from dealing with "images" they are not very similar. Or did I misunderstand something?

Re: Anyone have a screenie of kpdf? - anon - 2003-09-14

> And isn't there almost entire xpdf source code base on the kpdf, any idea could there be any work being done for example making uniform library used by both?!? I'm sure it could be done, but it'd be hard. The GNOME folks do the same thing with gpdf in gnome 2.4.

Re: Anyone have a screenie of kpdf? - Carlo - 2003-09-14

Yes, but Acrobat Reader ist still a bit faster and the Font-Rendering is better. (xpdf 2.02.1 compared to acroread 5.0.8)

Re: Anyone have a screenie of kpdf? - optikSmoke - 2003-09-14

Indeed, acroread is quite good. So, here's what I want to know: does KPDF have the table of contents sidebar thing like acroread? That's the main reason I use it, it makes navigating pdf's much better than in xpdf or kghostview.

Re: Anyone have a screenie of kpdf? - Nobody - 2003-09-14

Hopefully printing is fixed on kpdf/kghostview as atleast old versions can't seem to know how to scale the rendered document to correct size to the printer?!?

Re: Anyone have a screenie of kpdf? - Mike - 2003-09-14

KPDF may be a lot faster than GV but its not near as good at accurately rendering things. See below Adobe Reader 6: http://homepages.ihug.co.nz/~midgedog/pdf/ad6.png KGhostView: http://homepages.ihug.co.nz/~midgedog/pdf/kgv.png KPDF: http://homepages.ihug.co.nz/~midgedog/pdf/kpdf.png

Re: Anyone have a screenie of kpdf? - Adi - 2003-09-14

KDE should have only one, I mean come on 2 pdf viewers, this is getting ridiculous and besides none of them even stand up to Acrobat Reader 6. KGhoStView is the best on Linux it should jsut be expanded and include xpdf support, no need makinga separate app just for that.

Re: Anyone have a screenie of kpdf? - anon - 2003-09-14

Both kghostview and kpdf are implemented as kparts, and this, the apps "kghostview" and "kpdf" are pretty much small wrappers.

Re: Anyone have a screenie of kpdf? - Spy Hunter - 2003-09-14

I have had far more compatibility problems with KGhostView than with xpdf. My pet peeve is the detection of "landscape" or "portrait" mode. Half the time when I find a pdf on Google it is wrong, which makes it impossible to view the document. xpdf always gets it right.

Re: Anyone have a screenie of kpdf? - TomL - 2003-09-14

Exactly! I have the same nit to pick about kghostview. There are a fair number of pdf's that I have to use xpdf with, just because kghostview can't get it right. That's why I'm looking forward to kpdf. xpdf also seems faster.

Re: Anyone have a screenie of kpdf? - Asdex - 2003-09-14

Which Ghostscript version? I use 7.0.5 and it works well.

Re: Anyone have a screenie of kpdf? - Spy Hunter - 2003-09-15

Whatever is in Debian unstable.

Can we edit PDFs yet? - Tom - 2003-09-14

Two features I'd love to see are: * the ability to select text in a PDF, so you can quickly copy+paste text out of them (I get really fed up of typing out quotations from PDF papers when working!) * the ability to edit PDFs in place. This could either just be a matter of letting the user change some text, or anything so far as making KWord really good at working with PDFs so you don't just make your document and export it, and keep the source file along side the PDF How possible are these two, out of interest? I know, I should file a bug, but at the moment I'm still thinking about the ideas...

Re: Can we edit PDFs yet? - Paul Eggleton - 2003-09-14

Yes, I would like to see #1 fixed as well. FYI: http://bugs.kde.org/show_bug.cgi?id=11823

voice notifications - LC - 2003-09-13

Did voice notifications with ttsd are planned ? I mean : in Mac OS style, when a message box pops up...

RPM Wizard - OI - 2003-09-14

Has anyone seen this great app? Why can't it be included in the standard KDe release?

Re: RPM Wizard - Adi - 2003-09-14

just checked it out. It's pretty cool, I think the main reason it's not included is because distros often give the suer an app like this, it would be cool if it was in utilities.

Re: RPM Wizard - None - 2003-09-14

Not everybody uses *shudder* RPM distro's..

Re: RPM Wizard - kidcat - 2003-09-15

Not everyone uses packages at all. Im ok with RPM Wizard in KDE.. under the following conditions: 1: The name is changed to Install Wizard (or whatever). 2: It gets support for the Debian way of doing things. 3: It gets support for any other major system that im just not aware of. :P 4: It gets support for the one and only .tar.[gz/bz2]. /kidcat

Re: RPM Wizard - Jan - 2003-09-14

Idea is great. BUT: I'm using SuSE 8.2. Quite an un-geeky distro. Now the RPM Wizard page says: Install python, rpm-python, and so on. rpm-python is not available for SuSE, you have to compile it for yourself. Now, is this a joke or what? An installation utility which is so difficult to install that you have learned so much about Linux installations that you don't need it anymore once it's installed? An interesting way to develop a software solution I supposed. What comes next? A calculator which requires you to enter all numbers by entering their square roots? You can do it all by head once you've figured out how to use that.

Konqueror - Mike - 2003-09-14

Im running the latest CVS debian debs. Konqueror seems to slow the whole system down to a crawl when downloading largish images. I will post a bug report if other people are seeing the same effect. here is the url: http://www.swrt.com/cpimages/441769.jpg Mozilla had no problem with the same image. ~Mike

Re: Konqueror - Shift - 2003-09-14

Same problem for me :(

Re: Konqueror - kzk - 2003-09-14

me too. the version is 3.1.90(CVS >= 20030827) on the control center

Re: Konqueror - Steffen - 2003-09-14

I'm experiencing the same problem. :-(

Re: Konqueror - Gerry - 2003-09-14

I'm using the latest downloads form SuSE - early September version(4th - 92 at the end of the version?), it took about 10-15 seconds on broadband to download the picture - seemed reasonable to me

Re: Konqueror - anon - 2003-09-14

Same problem.. I made a 6000x6000 jpeg with GIMP that was filled completely black with a few lines drawn in the middle (~750k). gqview took 3 seconds to load it - using /tmp/test.jpg xv took 4 seconds to load it - using /tmp/test.jpg kuickshow took 7 seconds to load it - using /tmp/test.jpg konq-HEAD took 24 seconds to load it - using /tmp/test.jpg konq-HEAD took 49 seconds to load it - using http://localhost/test.jpg MozillaFirebird took 4 seconds to load it - using /tmp/test.jpg MozillaFirebird took 5 seconds to load it - using http://localhost/test.jpg opera 6.12 took 3 seconds to load it - using /tmp/test.jpg opera 6.12 took 3 seconds to load it - using http://localhost/test.jpg

Well it looks like - Adi - 2003-09-14

KOnqueror's constipated on mine too.

Re: Konqueror - name - 2003-09-14

> I will post a bug report if other people are seeing the same effect. Please do so. I have seen this problem many times with kde 3.1.

Re: Konqueror - anon - 2003-09-15

Please vote for bug 39693 (http://bugs.kde.org/show_bug.cgi?id=39693) All of the large image hangs/crashes/takes a long time in konq have been duplicates of this bug.

Re: Konqueror - Jelmer - 2003-09-15

I voted for this bug. However, I would also like to ask people to vote for bug http://bugs.kde.org/show_bug.cgi?id=52026. This has been bugging me for ages now, but somehow no-one else seems to notice it (and I'm sure it happens on different systems).

Re: Konqueror - Jan Jitse - 2003-09-14

I compiled a version of kdelibs and kdebase today, and the picture loads within 2 seconds here.

Re: Konqueror - Spy Hunter - 2003-09-15

I think Konqueror has always had this problem. Please, file a bug!

Re: Konqueror - Yubaba - 2003-09-15

ARGH !! yes, same problem with KDE 3.1.3 actually i thought, my PC was freezing ! ;)

Kexi? - thefrog - 2003-09-15

Who invented this awfull programm name? Sounds like a vacuum cleaner to me .. regards thefrog

Re: Kexi? - Lucijan Busch - 2003-09-16

sorry, ever been in a situation where you really want to start development and don't want to take to much time on thinking about a name? ok here the explenation: it needs a k. k... it is/was planed a smaller form of ms access we have the suffix 'i' therefor k...i access is like a toungh braker k.xi and a keks is a cookie in german (at least austrian) kexi lucijan

Re: Kexi? - 138 - 2003-09-16

>and a keks is a cookie in german (at least austrian) Really? Because keksi is a cookie in finnish, and if you would write it with an x (kexi) ,and you could if you were a teenager :), it would still be pronounsed same way as keksi.

Re: Kexi? - Thomas - 2003-09-17

Don't know if it's just a legend, but if I recall it correctly the "Keks" (cookie) was introduced to the german language after a well known maker of sweets (Bahlsen, http://www.bahlsen.com/root_bahlsen_anim_en/root.html) changed the (once english) name of one of it's more popular products from "cakes" to "keks", because the germans (in the late 19th century) pronounced the original name awfully wrong. A german tongue would pronounce "keks" much like an english would pronouce "cakes" (well, nearly...) This way, the term "keks" found it's way to the german language and maybe to others as well...

Re: Kexi? - Favorit - 2003-11-23

Well, "keks" is a word meaning cake (or specifically baked cake) is the same in almost all languages, most of the slavic languages have the word "keks" (tho spelled in cyrilic mostly).