KDE-CVS-Digest for September 26, 2003

In this week's CVS digest:
Quanta's visual editor makes progress.
KHTML gets text selection optimizations and immediate repaint from Safari.
Kontact, KMail and
KAddressBook get work on settings, time cards, drag and drop. Plus many bug fixes.

Dot Categories: 

Comments

by Rayiner Hashem (not verified)

Glad these changes made it in. Text selection was always a blotch on KHTML's otherwise excellent performance.

The change to make the background fill the leading space came as a surprise to me. I always thought this was weird, but its been in KHTML so long I thought it was a feature, not a bug!

by Spy Hunter (not verified)

Wow, text selection is fixed? Awesome! It's such a simple thing, but it really puts people off. They think Konqueror is slow, when it is really pretty fast and the text selection just wasn't optimized well. Now all we need is for it to tint images the "selection" color when they should be selected.

by AC (not verified)

they are in HEAD (for a while)

by Spy Hunter (not verified)

Wow. The KDE developers must be psychic ;-)

by Steffen (not verified)

Finally, one of the things I disliked most has been fixed! :-)

by AC (not verified)

Yeah, the text selections are a LOT faster in very recent head. The only thing still missing is updating the selection as you scroll down a page, which can help performance.

For example, goto bugs.kde.org, click on something that will give you a large table with a lot of rows, like "The Mosted Hated Bugs". Put the window at the top of the screen, and start dragging from the top of the page to the bottom, making sure that the mouse pointer is at the bottom of your screen as you drag. Before you hit the bottom of the page, let go off the mouse pointer and watch it lag as it updates the selection. You hav e do this test correctly, or khtml will update it halfway through. Mozilla doesn't have this problem because it updates the selection piece by piece when scrolling. Opera 7.2 also doesn't have this problem, as it periodically updates the selection (every few seconds)

by cbcbcb (not verified)

does that mean this bug is fixed:
http://bugs.kde.org/show_bug.cgi?id=61533

by huru (not verified)

How about copying text from a table where there is multiple cells in one row? in 3.1.4 when the copied text from each cell is pasted on it's own row.. sometimes with extra newlines while for example pasting from IE is much more nicer, the text is pasted to same line separating the cells with spaces. This is one of the most irritating features imo and will be hopefully looked upon some day :)

by ac (not verified)

IMHO the titlebars of most window decorations are too high/big.
The "Laptop"-decoration rules because it does not look so bloated-up.

I think a good measure for the ideal titlebar height would be the height of
the menubar ("File","Edit",etc)

Anything bigger looks unbalanced.

Styles like plastik take a good approache because the make the high congigurable.
IMO however even the smallest size in plastik is still too high (by 1 or 2 pixels, not more)

Very often, the detail makes it!

by poephoofd (not verified)

A good measure is the height of the titlebar text, anything else than that is an ugly hack.

by ac (not verified)

> A good measure is the height of the titlebar text, anything else than that is an ugly hack.

It should have the height of the menubar, where the standard font size
fits well inside.
If the font it bigger, the titlebar should get bigger aswell

by ac (not verified)

> A good measure is the height of the titlebar text, anything else than that is an ugly hack.

I notice that for mosr decocations the titlebar is much higher than the actual
text...
They are 2 big, 2 or 3 pixels less would make it look much more sexy

by AC (not verified)

For usability and accessiblity reasons, it should depend on the font size.

by Tukla Ratte (not verified)

Funny. I think the Laptop titlebar looks too cramped. That's why I never used it, even on my 800x600 dpi laptop.

I also don't understand what so many people see in the Plastik theme. I think it's pretty bland.

Different strokes, I suppose....

The kde-3.2 is really getting there... :-)

But as there is intention (?) to move the rest of X11-specific code to use Qt instead (so that the whole kde system could be compiled on top of Qt-Embedded on fbdev-variations) could/should the DRI/DRM-specific stuff to be imported to the Qt to enable full blown OpenGL/SVG accelleration via GPU(s) to leave more idle cycles for processor to waste on worthless eye-candy? ;-)

by Richard Moore (not verified)

There are places where X11 specific code is needed as there is no Qt equivalent. One example is ksnapshot where I query the X11 window hierarchy. There are also things that will never get accepted by the Trolls into Qt because they can't be done in a cross platform way. So the short answer to your question is no.

Rich.

Oh, then I just misundestood the item on the KDE 3.2 feature plan that has a line: 'Make kdelibs compile (and run) without dependencies on X11, for example useful for qt/embedded or qt/mac. Holger Schroeder ' on the Libraries TODO list.

Maybe that means that the kdelibs will be "embeddable" but not all separate programs?!?

It would just be so clean and much simpler to be able to dump all other UI libraries (like Xlib/gtk+/whatever) while retaining functionality provided by the base kde...

by Richard Moore (not verified)

You sort of misunderstood, but sort of didn't. What's happening is that these parts of the code won't be available for non-X11 platforms. This will mean some loss of functionality.

I don't think dumping X11 is a good idea at all, but being usable on a Mac etc. is reasonable.

Rich.

Yeah, replacing the whole Xlib with something equal is a huge task, but isn't Qt-Embedded already have the most of the needed windowing system inplace?

Could there be a "info page" to let people know what parts of the kde would be dropped incase using just kdelibs/qt-embedded API?

>>Yeah, replacing the whole Xlib with something equal is a huge task, but isn't Qt-Embedded already have the most of the needed windowing system inplace?<<

What would Qt/E buy you? It has almost exactly the same (old | outdated | unflexible) rendering model as X11. If you want to replace it, at least vote for something that can compete with Quartz or GDI+....

by em (not verified)

> The first [discussion about licenses] was about a file that is part of KMail.
> A license was added to the file, since there was none.

AFAIK nowhere in copyright law is the file designated as the minimum unit that must have an explicit license. Compare with functions: we don't demand an explicit license header for every function. If a function doesn't have an explicit license, the file license is assumed to apply. Just the same, if a file doesn't have an explicit license, we should be able to assume safely that the project license applies.

It's good to care about licenses, but let's not go overboard.

by Derek Kite (not verified)

If the license is changed, or a license added (which one, bsd? GPL? Artistic? all are in KDE) the authors need to give permission. Very simple in theory, but tough in a project where many contribute and are never seen again.

Derek

by em (not verified)

> If the license is changed, or a license added (which one, bsd? GPL? Artistic?
> all are in KDE)

Easy. Let me quote Ingo Klöcker from your own digest:

"AFAIK KMail was started as GPL (which version?) application. And since the license was never changed all files which belong to KMail are of course GPL licensed."

So the GPL meets nicely the concept of "project license" I was talking about.

> the authors need to give permission.

Only if you see the addition of the explicit license header as a license change. IMO it would be more of a clarification, so no, I don't think the authors would need to give permission.

by Derek Kite (not verified)

I don't disagree. However the issue isn't whether it makes sense, but if a judge would agree. Copyright is established in law, hence lawyers and judges are the ones who decide what stands. And no, it doesn't make sense.

Derek ( who believes the only ones who really benefit from all this is the lawyers )

by em (not verified)

I'm trying to argue from the point of view of a copyright lawyer.

Anyway, the chances of this ending up in a court of law seem negligible to me.

by Spy Hunter (not verified)

Trying to argue from the point of view of a copyright lawyer is pointless. The law is so non-obvious and has so many nooks and crannies that unless you _are_ a copyright lawyer, you will probably get it wrong.

The KDE project cannot afford to take chances with licensing issues. More than anything else, licensing issues have the ability to destroy KDE. What if someone had at one point copied commercial code into this file with no license? Then next year there could be a new case just like SCO's, only targeting KDE instead of the Linux kernel. If the license is in every file, it gives KDE better legal ground to stand on. That's just the way copyright law works. I think everyone agrees that it is stupid. But you can't ignore it, becuase the threat of stupid litigation hindering the KDE project is too high.

by em (not verified)

> Trying to argue from the point of view of a copyright lawyer is pointless.
> The law is so non-obvious and has so many nooks and crannies that unless you
> _are_ a copyright lawyer, you will probably get it wrong.

Perhaps, but when people say adding a license header would require the permission of all contributors to that file they're trying to argue from the point of view of a copyright lawyer too, aren't they?

> What if someone had at one point copied commercial code into this file with
> no license?

Since I believe the file authors already licensed the file under the GPL by contributing it to a GPL project and not specifying a different license, I don't think the license header would make any difference here. Please note that this is the same reasoning that allows people to contribute patches without adding an explicit license to each.

> Then next year there could be a new case just like SCO's, only targeting KDE
> instead of the Linux kernel.

a) SCO's case, at the moment, consists exclusively of a breach-of-contrat suit against IBM; everything else has been a smokescreen to spread FUD against Linux; b) SCO's case doesn't seem to be going to well for SCO at the moment, does it?; c) It has been widely acknowledged that all the Linux maintainers had to do was to remove the possibly infringing lines the moment they were notified of them (as they did) and they would be legally safe and d) the Linux kernel source files don't usually contain explicit licenses.

I think I have made my opinion clear by now so I'll stop repeating myself.

by Roberto Alsina (not verified)

Licenses have no defaults. In order for a thing I write to have a license, I have to say what that license is.

And no, just because it is contributed to a GPLd project, that's not enough. What if the author has no intention of making it GPL, but some incompatible-in-binary license? In that case, the source may be ok, but it can't be included in the project.

In short: when you contribute to a project, put a license header in the code,
when you write code, put a license header in it.

by em (not verified)

> In short: when you contribute to a project, put a license header in the code,
> when you write code, put a license header in it.

Go tell the n00bs at linux-kernel they're doing it wrong then.

by Roberto Alsina (not verified)

Dude, you should look up what the appeal at authority fallacy is, and then come back.

by leo (not verified)

Doh. Guys at linux-kernel are experts programmers. But are they experts lawyers?

by Spy Hunter (not verified)

No, we're not trying to argue what a copyright lawyer might argue. We have asked actual copyright lawyers, and what they say is that we should put the license in every file. I don't see how you can argue with that. It doesn't matter how "reasonable" it might seem, or what the merits of SCO's current case are, or how rediculous a lawsuit against KDE might also seem. We must follow even the stupid laws or risk being targeted for stupid lawsuits.

by Mike (not verified)

Reading about all those improvents in the visual editing part of Quanta I wonder:
At work we have to use a content management system which works with
M$-Word-HTML files. As you probably know Word saves and opens "special" HTML files
which include additions Microsoft-Tags and Attributes which make it possible to
keep aditional editing information usually not saved in HTML. This way a file looks
the same again when reopened in Word. These tags don't influence the HTML display
in a browser though. Now my question: Will Kafka allow me to edit those files without
destroying this information? For example, if I change the width of a table column will
Kafka keep additional unknown attributes within the TD-tag?
That would be really wonderful because this is why I still need Windows at work most
of the time.

by Andras Mantia (not verified)

Altough I'm not the one who is actively working on VPL, but I can say that our goal is to provide such an implementation, that the user's own code doesn't get destroyed once it's edited in visual mode. Just like in case of normal editing it isn't destroyed either.

Andras

by Mike (not verified)

Thanks for your answer (and for you work on Quanta of course)
I'm waiting unpatiently... ;-)

by Eric Laffoon (not verified)

Far be it from me to argue with my good friend here, but as neither of us work with eevil software this may not be entirely clear.

First of all I know that FlunkPage uses additional non HTML extentions. I'm not aware of exactly what additional information Wurd pukes out, however I suspect it's part of the base document file. FP also uses additional directories to store extra info. If it exists as XML or comments it's pretty safe and if it's extra tag attributes it probably is safe... but I'm not sure that will mean things will work as you expect.

Here is what is done by Kafka in Quanta. It will write information to only what is relevent that you add or edit within a node. This means that the rest of your hodge podge HTML from Wurd will be just as it was before... a best guess mess, but one that your company knows and loves. This is fundementally different from all other visual web editors which will happily reformat the document and munch your nice W3C compliant carefully laid out markup into a DTD schizophrenic mess if you edit one letter and save it.

Just not touching this information doesn't mean you are free of the proprietary two step though. That wouldn't be good lock in design. Editing in Quanta will produce W3C DTD compliant markup (where you edit) but it will leave all your proprietary stuff alone. This could possibly cause problems going back to your proprietary extentions as they may be out of sync for the document. You should know that while we will make every effort to support and exchange data with proprietary tools we will *not* attempt to replicate proprietary porcesses to do this. (It is always possible to do this with scripting if someone wants to. We support DreamWeaver templates this way.)

In fact we hope that in 2004 using Quanta in a CMS entry configuration will be far more compelling. Aside from native Linux desktops this could include live CDs, emulation and various other corporate solutions. Using Wurd does not allow you to live preview content on page with a test server. This type of thing will be possible in Quanta 3.3/4.0. In 3.2 or 3.3 it will be possible to grant permissions to directly manage abstracted content on the server while preventing content people from affecting layout or back end. This frees developer resources. These types of solutions and others are not available using a word processor, which is hardly a focused or logical tool for this.

by Nicolas Deschildre (not verified)

As long as the extra informations are written in proper SGML/XML, kafka WON'T modify what you don't edit. In others words, it only touch what you want to be touched ;-)
But i can't be sure that the file will then be properly read by Word, as i can't synchronize proprietary-specific-information, and as Eric said, we won't try.

by fault (not verified)

amarok is great for all of you xmms/winamp lovers. it feels like xmms (gets our of your way), but doesn't have the horrible usability problems that xmms has. no, I don't like jukebox-like apps :)

by notMe (not verified)

except Markey still hasn't fixed the fft! :) Markey! u hear me?

by aac (not verified)

Any work planned for this? You'd need it for kafka/design mode, but it'd be nice to have otherwise as well (like in moz)

oh yeah, the new caret browsing is uber cool. It actually navigates better than in mozilla. I find myself typing f7 a lot these days, thanks leo!

by Anonymous (not verified)

What is caret browsing?

by aac (not verified)

the act of using caret mode to browse pages.. if you have Mozilla > 1.2, just press f7 and a caret shows up in the page. you can control it with the keyboard

by Leo Savernik (not verified)

You're welcome :-)

Why does F7 work for you? For me, it doesn't, so I had to redefine it to Shift+F7. So that means caret mode works better for you than me ;-)

by not_registered (not verified)

i hate those new ones that look like ugly stupid pages with a bent corner. the dont seem to have much intrinsic meaning that relates to the type of file and look like a blurry mess when in detailed view mode (with normal size icons). stop going in the wrong direction and step back a minute. i dont mind icons conforming to a squary shape BUT get rid of the bent corner and make them actually look good. thats all i can do is critisize because i cant do any better.

by Steffen (not verified)

I think the new icons in cvs look a bit cleaner than the old ones. Would not want to switch back... :-)

by not_registered (not verified)

all the good icons that look like paper (like new on konsole) have the bent corner at the top where it should be. that new icon should be the base design for all of them.

by Pure SVG Icons (not verified)

Is there any plans to ship Crystal as a pure SVG iconset? (e.g, not providing icon sizes in the icon theme, but rather scalable like GNOME does)

by Will Stephenson (not verified)

I was playing with pure SVG icons a bit last night, and the rendered results were very variable. I just did 4 icons in Sodipodi for up, back, forward and gohome, and they would render differently in two different Konqueror runs. I don't know exactly where the problem lies, either Sodipodi's output is off, or the SVG icon renderer is not mature enough yet.

If you want to have a play with this, read the excellent icon index.theme specification at freedesktop.org.

Will

by anon (not verified)

It seems to render all of the nuvola svg icons fine.

by Rob Buis (not verified)

Hi Will,

>I was playing with pure SVG icons a bit last night, and the rendered results were >very variable. I just did 4 icons in Sodipodi for up, back, forward and gohome, >and they would render differently in two different Konqueror runs. I don't know >exactly where the problem lies, either Sodipodi's output is off, or the SVG icon >renderer is not mature enough yet.

The answer is probably, both :)
Can you send me the svgs? I may be able to fix it or at least tell you what is going wrong. Also if you can, a screenshot of how (mis)rendered they look for you would be nice...
Cheers,

Rob.