KDE-CVS-Digest for February 6, 2004

Saturday, 7 February 2004  |  Dkite

In this week's KDE-CVS-Digest: KStars now has constellation lines. Gwenview is now a KPart, for embedded use in Konqueror. Plus many bug fixes and improvements in KMail and Konqueror.

Comments:

Thank you! - MK - 2004-02-07

Thanks YOU for providing every week a lot of information about what's going in KDE CVS. You're doing this for more than a year now and it was and still is always nice to read. In particular the "One year ago" section is a good thing and makes me smile sometimes. The importance of the KDE-CVS-Digest can not be overestimated, thanks a lot for "feeding" the hungry crowd every week :-)

UNIX Focus Policy - James Richard Tyrer - 2004-02-07

Why are the two UNIX window focus policies: Focus Under Mouse Focus Strictly Under Mouse considered to be: "unreasonable focus policies"??? If the developers don't want to support these then they should be dropped. But, I don't see the point in denigrating them. I think that I could probably learn to live with: Focus Follows Mouse although I don't understand the exact differences. -- JRT

Re: UNIX Focus Policy - Anno - 2004-02-07

The difference between the policies is: Focus Strictly Under Mouse: The focus is on the window under the mouse. If no window is under the mouse, now indow has the focus. Focus Under Mouse: The focus is on the window under the mouse. If the mouse moves outside of any window, the window that last had the focus keeps it until a new window gets the focus (by virtue of the mouse moving over it). Focus Under Mouse is okay for me, the strict version I consider unusable. Chaq'un a son façon, however.

Re: UNIX Focus Policy - Lubos Lunak - 2004-02-07

The difference between focus follows mouse and focus (strictly) under mouse is that the sooner one honours explicit requests to activate a window, while the latter ones stubbornly keep the window under mouse active not matter what (I think it's actually explained in the settings dialog). Therefore even things like clicking on taskbar entries or Alt+F2 don't activate the windows, and that's probably why it's called unreasonable (although other reasons for this name are not impossible, creating some features or fixing bugs with these policies is a pain, my commit is an example of that).

Re: UNIX Focus Policy - James Richard Tyrer - 2004-02-07

I am quite familiar with the difference between: "Focus Under Mouse" and: "Focus Strictly Under Mouse", the very slight difference. However, I am not certain that I understand the difference between: "Focus Under Mouse" and: "Focus Follows Mouse". The documentation appears to be wrong in: help:/kcontrol/windowmanagement/index.html and the "Whats This" [?] offers no explanation except to make what I believe are inappropriate statements denigrating the two UNIX policies. This, IMO, has been further confounded by the fact that up until this release KWin had bugs. Now, it appears to work correctly (I can now use Focus Follows Mouse without problems but I do prefer the strict focus). I think that we could drop the two UNIX policies. But, I would like to see: "Focus Strictly Follows Mouse" added if we did that. -- JRT

Re: UNIX Focus Policy - Lubos Lunak - 2004-02-07

> However, I am not certain that I understand the difference between: "Focus Under Mouse" and: "Focus Follows Mouse". Read more carefully, I just explained it to you. You're right that the documentation doesn't explain it correctly; the what's-this is correct though, it just doesn't stress the difference as explicitly as I did (actively moving mouse onto window activates - vs - window under mouse is active). Trust me, I'd love to drop the unreasonable focus policies. But my self-preservation instict disagrees ;). And guessing from your description, I think you'd actually be one of those demanding my head.

Re: UNIX Focus Policy - James Richard Tyrer - 2004-02-07

Sorry, very dense sometimes. I can't see any difference between: "Focus Under Mouse" and: "Focus Follows Mouse" when I move the mouse pointer from one open window to another. The only difference that I can observe is that new windows always get focus (and are raised) in: "Focus Follows Mouse" and they need to have the mouse pointer moved into them first with: "Focus Under Mouse". Or, is this a bug in 3.2 since 3.1.5 didn't work that way? > I think you'd actually be one of those demanding my head. I used to be in that camp, but that was because of bugs with "Focus Follows Mouse" in previous KWin versions. Windows would come to the top when I moved the mouse into them (it didn't matter that: "Auto Raise" wasn't checked -- it still did it) or windows would disaper under other ones without being asked. I don't like that. But now I am OK with "Focus Follows Mouse" in 3.2 except that I would prefer to also have the 'strict' version of it available -- if the mouse wasn't in a window, no window would have focus. If that were added, this "hard core" UNIX person would signoff on killing the old UNIX focus policies. -- JRT

Re: UNIX Focus Policy - Lubos Lunak - 2004-02-08

I'm a click-to-focus person, so I might be wrong, but: AFAIK the fact that focus under mouse always keeps the window under mouse active while focus follows mouse allows explicit activation of other windows is the only difference. I don't think it worked differently in 3.1.5, and I don't remember doing anything with it. If you think there's something wrong with the current KWin, ->bugs.kde.org please.

KStars pics... - OI - 2004-02-07

So which one of those 2 photos is the KStars image, and which one is the real one??

Re: KStars pics... - Vic - 2004-02-07

Right click and look at the filenames :)

Re: KStars pics... - MK - 2004-02-07

just look at the noise. The one that looks too perfect is made with KStars :-)

OT: autohide - me - 2004-02-07

just a question (i did not follow kde in the last years): is it possible, to autohide apps, not only panels? i am quite happy with this fvwm-feature. for example, if i point my cursor on the top of my desktop, a large terminal comes down. very cool for me. and the focussing really kicks ass in fvwm, was there any progress in the last releases?

Re: OT: autohide - Lubos Lunak - 2004-02-07

No, the default window manager doesn't have this feature. But you can try running KDE with FVWM (http://ktown.kde.org/~seli/kdewm/ - FVWM should have the necessary support for the WM spec as well, and I'll be happy to add it to the page if you try it out).

Re: OT: autohide - me - 2004-02-07

thanks, everything seems to work fine, except for the autohide feature :((

Re: OT: autohide - Lubos Lunak - 2004-02-08

Mind mailing me some details (which version, how much you tested it, problems) about how FVWM works in KDE, so I could add it to the page? WMs have to be used for real in order to test them, and I have already enough fun with the default one.

My favorite! - Turd Ferguson - 2004-02-07

Matt Rogers committed a change to kdenetwork/kopete/protocols/oscar Fix bug 74197. Use 16 for a maximum password length Refer to Bug 74197 - password dialog only accepts 8 chars Diffs: 1, 2, 3, 4 This is about time! This is what prevented me from using Kopete previously.

Re: My favorite! - Matt Rogers - 2004-02-08

hehe, scary that something that I committed is somebody's favorite commit. ;) Glad you like it though. :)

incredible - djay - 2004-02-07

I was thinking yesterday about that while using gwenview. The application was so fast ans so close to konqueror in look & feel that I was wondering why it wasnt included in konqui. And pop! kde devs are so fast AND expert telepaths!!

CVS Digest Script - john - 2004-02-08

Derek, The CVS Digest is so well organized - is there a particular cvs log script that you use to generate it? I would like to implement a similar report for our CVS projects. thks.

Re: CVS Digest Script - Derek Kite - 2004-02-08

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/www/areas/cvs-digest/tools/ Its a rather miserable perl script which is incomprehensible even to me who wrote the damn thing. Right now it depends on the mailings that the kde cvs server does when there is a commit, so I don't think it would translate to another project. Stay tuned, I'm working on something better. Famous last words. Send me an email if you would like to know what's in the pipe. I am actually getting something done on it right now. Derek

Re: CVS Digest Script - Niels - 2004-02-08

Why not make an interview with yourself? I'd read it!

question - some chap - 2004-02-08

Anyone know if/when (now that SuSE is in control of the Novell desktop) Evolution will be ported to KDE? I presume it will be, since Novell is going with KDE it only makes sense that they will want to make Evolution a native KDE app. I'm hoping it's soon... I hate having to have gnome installed just for a few apps (the biggest being Evolution).

Re: question - Anonymous - 2004-02-08

Why do you prefer Evolution to Kontact?

Re: question - Thilo - 2004-02-08

Since there is Kontact now, I would be very surprised if Evolution was ported to KDE. Nevertheless, I wouldn't mind :-) On the other hand, I have no problems with Gnome-apps being installed on my systems ... Thilo

Re: question - ac - 2004-02-08

I personally only want the ximian connector to be released under GPL, and then be integrated into KMail/Kontact. That would definately rock.

Re: question - Anonymous - 2004-02-08

There is already work done for Exchange support in Kontact.

Re: question - jmk - 2004-02-09

How could i try it?

Re: question - Maynard - 2004-02-08

Porting Evolution to KDE is probably not going to be done. Its unnecessary and a waste of resources. Whoever gave you the idea that they are going to just drop GNOME completely anyway, because that is what yu seem to suggest. Novell is not only going with KDE, at least there is nothing to suggest that. Besides, I believe a lot of Evolution development is taking place in GNOME CVS right now, so it would be foolhardy to think they will make a CVS port. KDE has Kontact anyway. They do not need Evolution.

Re: question - Arend jr. - 2004-02-08

I agree with you here, it's very unlikely Evolution would be ported. However, it would be nice to see if Evolution gets optional KDE support using the QtGTK stuff, getting KDE print and file dialogs perhaps.

Re: question - Thomas - 2004-02-08

> Evolution with KDE/QT widgets? Quoi? I feel _much_ more comfortable with my kmail / korganizer combo (now in kontact). Have tried Evolution a year ago. It was not really bad, but far from being a nice PIM application. Imho, I think the modular structure of kontact is more foresighted than the all-in-one approach of evolution.

KDE 3.2 question - OI - 2004-02-08

I just installed the KDE3.2 rpm:s on Suse 9.0 Really great work by the KDE-team, apps, features, everything. Quite impressive that I can download all this for free. :-) Anyone knows how to get rid of the grey ugly background behind the kde splash screen? Is it possible to have the login background left?

Actually, we got constellation *boundaries* - LMCBoy - 2004-02-09

Hey, Just a clarification; we've had constellation *lines* for a very long time. We now have added official IAU constellation *boundaries*. As the CVS digest shows, we did also improve the way the constellation lines are implemented, however. Anyway, don't mean to complain, we're always happy to get a mention in the digest, Derek! ;)

Trying not to be a license troll... - anonymous - 2004-02-09

Now that it is possible to create KDE applications using GTK (through various bridging technologies), is possible to create applications for KDE that aren't GPL (without paying Trolltech)? My guess is no, since I imagine the code that bridges the event loops and the theme engine eventually links back to QT somehow. Am I right here? Note: Sorry that this is offtopic - I really don't even care about the issue that much myself. But I can't sleep and for some reason the question is bugging me, so I thought I'd get a second opinion here.

Re: Trying not to be a license troll... - André Somers - 2004-02-09

My guess is: no. At least, I hope not to be honest. Why would you _want_ to create non-GPL applications and not pay Trolltech for the excellent toolkit they provide that makes it all possible? Note that you can still ask a fee for GPL programs, it's not like it's impossible to create commercial GPL applications. Note that you can allready create GTK programs, and since they run in KDE too, I think you can get quite close, especially with stuff like FUSE available.

Re: Trying not to be a license troll... - Michael - 2004-02-09

in principle I think you are right with the non-GPL applications. But I cannot do GPL applications for Windows and Linux using QT, cause the noncommercial-licence forbids to make money of a program, unlike the GPL, which explicitely allows me to do so! The real problem with QT is not being restricted to the GPL but being restricted to Linux/MacOSX when doing GPL programs.

Re: Trying not to be a license troll... - Datschge - 2004-02-09

KDE doesn't consist only of GPL applications, far from it, see http://tinyurl.com/39epy . Using the Qt/X11's QPL you can choose any license you want as long as you include the software's source code. If you don't care to contribute (either by offering source code or by paying the Qt developers) you are very welcome to look elsewhere.

Re: Trying not to be a license troll... - anonymous - 2004-02-10

Just to clarify I'm not someone who is interested in not paying Trolltech, but I have seen a lot of license trolls about KDE. I was wondering whether we are close to having a way for them to keep their precious LGPL'ness or commercialness by allowing GTK apps to access parts of KDE. Besides, it is a bit of a stretch to call a GTK app that is using KDE desktop libraries (such as IOSlaves, dialogs, theming) a QT derivative. The only thing that makes this so is multiple levels of linking though non-GPL'd (usually LGPL, BSD, or other) KDE libraries to the GPL'd QT. If I started doing UI code for KDE, I'd personally use QT since from all accounts it is easier to work with and leads to faster development times. But for those who dislike QT licensing for whatever reason, I'd think having the option to do GTK-KDE apps without QT licensing restrictions would maybe give them no more reason to troll KDE. They'd have to make up some other imaginary problem, as this slight problem (or non-problem, depending who you ask) would no longer exist.