KDE-CVS-Digest for September 12, 2003

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.

Dot Categories: 

Comments

by tetra (not verified)

congratulations, an other nice cvs-digest

thanks

by anon (not verified)

great that it's finally done.. woot.

by kidcat (not verified)

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

by cies (not verified)

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

Contributing:
[ Artwork & Icons | Enterprise Reports | Usability Studies ]

Participating:
[ KDE News | KDE Traffic | Promotion | Bug Hunting | Documentation | Translation ]

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

by Eric Laffoon (not verified)

> 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. ;-)

by Adi (not verified)

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!

by Derek Kite (not verified)

Compliance with standards.

http://www.freedesktop.org/standards/wm-spec/

Derek

by anon (not verified)

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

by Tim Jansen (not verified)

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

by Lubos Lunak (not verified)

> 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 [email protected] 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.

by Mohasr (not verified)

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

by Mohasr (not verified)

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

by anon (not verified)

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

by Adi (not verified)

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

by anon (not verified)

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

It will probably this week :)

by lalala (not verified)

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

by Anonymous (not verified)

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

by anon (not verified)

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.

by lalala (not verified)

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)

by Vincent (not verified)

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

by Maynard (not verified)

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.

by Adi (not verified)

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

by cm (not verified)

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

by Hamish Rodda (not verified)

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

by lalala (not verified)

Yes, that's exactly what I meant :)

by TomL (not verified)

How does it compar to kghostview?

by anon (not verified)

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

by Nobody (not verified)

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

by Anonymous (not verified)

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

by Nobody (not verified)

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?

by Nobody (not verified)

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

by Paul Eggleton (not verified)

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

by Nobody (not verified)

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?

by Spy Hunter (not verified)

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.

by Mohasr (not verified)

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

by Nobody (not verified)

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.

by Thomas (not verified)

> 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++

by anonon (not verified)

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

by anon (not verified)

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

by Carlo (not verified)

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)

by optikSmoke (not verified)

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.

by Nobody (not verified)

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

by Mike (not verified)

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

by Adi (not verified)

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.

by anon (not verified)

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

by Spy Hunter (not verified)

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.

by TomL (not verified)

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.

by Asdex (not verified)

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

by Spy Hunter (not verified)

Whatever is in Debian unstable.

by Tom (not verified)

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