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
Why need to get the whole interface rendered in SVG for KDE4
What does it buy you beside a huge performance loss?
Moving from a Raster(bitmap) based GUI to a vector(line) based Interface provides a couple of benefits:
Resolution independance
- specifying GUI sizes in points, mm or inches rather than pixels makes it easier to map the windowing system on higher resolution devices. Comparing this with dot-matrix printers which started out with output resolutions of 75 to 140 dpi pixels were relevant, but now they are around 2000 dpi pixels seem rather redundant. Screen technology can follow suit as soon as windowing technologies start using vector graphics. Vector graphics = sharper,cleaner output at higher device resolutions.
Example: My laptop runs at 130dpi, and my PDA at 140dpi - they take a little getting used to with small fonts, though I have increased all the font sizes, but not all applications play ball (it's a bit of a kludge).
- Anti-Aliasing and ClearType technologies can be applied with very little extra effort to components of the system that were traditionally only used for vector based text.
The move is being made elsewhere
- We all like being sheep, and copying other people, so I have included some examples of some guys and gals to copy:
Microsoft - the new Avalon vector-based(Direct3D accelerated) GUI of longhorn
http://weblogs.asp.net/pleloup/archive/2003/10/30/34676.aspx
Macromedia's Cold Fusion - A lightweight vector based GUI
Apples OSX (Aqua?) Interface - Based on Adobes PDF (based on Postscript) (OpenGL accelerated), as opposed to SVG (based on Postscript)
Ability to take advantage of some SVG features that we didn't think of back when X11 was invented:
- different color models HSV, CMYK, RGBA (A=Alpha channel - see PNG)
- rendering windows in 3D (donning a virtual headset and having a video screen 360x360 degrees- ever thought that 2048x1600 res screen was a bit cramped)
- http://www.apple.com/macosx/features/expose/ - hey cool!
If you are afraid of incurring a performance impact you'll always have twm
Actually, the catalog that changed this week was the "deep sky" NGC/IC catalog, not the stellar catalog. We already dealt with the license issues of our stellar catalog months ago :).
Anyway, the issue was, I obtained a really complete version of the NGC/IC catalog from the ngcic project webpage, but it was licensed (like a *lot* of scientific data) as "free for non-commercial use". I contacted the author to try to work out an arrangement, explaining the requirements of the GPL, and he said "of course you can use it, KStars is non-commercial". He was a bit confused as to why I was bothering to ask.
Anyway, I followed up, and asked explicitly if I could relicense it under the GPL, but he never replied. So I added it to KStars with a notice that if someone wanted to use the catalog commercially, they should contact the author first. This is not DFSG compatible, since it technically constitutes a usage restriction. For this reason, we started a "kstars_debian" branch with only capital-F-Free data, and gave this branch a less complete version of the NGC/IC catalog that I compiled myself from several public-domain sources.
However, I was then informed that it wasn't just Debian objecting to "free for non-commercial use" stuff, KDE can't accept that either. So now HEAD uses the lame Free version of the catalog as well.
It's kind of weird. The better catalog can't be used because it restricts against commercial use. The catalog we are using is GPL'd, so technically, a company could harvest it and try to sell it to people, as long as they kept it GPL'd. This is something that no company is going to do, since their first customer would be free to give it away to everyone else. So the end result is the same.
Anyway, look for a downloadable version of the better catalog on our website after 3.2 is released, if you can handle the burden of having a file on your system that you can't try to make money from...
------------------------------------------------------------------------------------------------------
It's kind of weird. The better catalog can't be used because it restricts against commercial use. The catalog we are using is GPL'd, so technically, a company could harvest it and try to sell it to people, as long as they kept it GPL'd. This is something that no company is going to do, since their first customer would be free to give it away to everyone else. So the end result is the same.
--------------------------------------------------------------------------------------------------------
Common sense with "free" software fanatics is useless.
Well, I disagree. No one was being fanatical, they just can't afford to make exceptions. When I was told about the KDE rules, I happily complied. My point was, it's unfortunate that we have to ship an inferior catalog to guard against what is (IMHO) a remote possibility. But I do not disagree with the need of it in general.
Hi,
could you possibly tell us how to help supporting the relicensing or do you think it is impossible to achieve? I think a good resource for humanity is wasted if not used. With GPL they still had the option to sell for use under other licences but GPL.
They should instead of "non-commercial" say ""non-commercial except GPL".
Yours, Kay
Imagine that a bunch of people want to distribute Kstars at a price, to pay for costs. Or that a scientific magazine wants to put it in its CD. If kstars had the non-free catalogue, it would prohibit them do to this.
Kde (with Kstars) wouldn't be distributed by RedHat, Suse, Mandrake, etc, who all sell (distribute, make money of) kde. Having such an exception in one of its package would make this impossible.
Why would any sane company charge money for a GPL software , except for the costs of packaging or shipping maybe?
The only way to get money from a GPL software is through 'services' or 'subscriptions' or in any form dervied from that. It's a big joke to suggest you can make money from a GPL software from the software itself.
IIRC, KStars shipped with similar non-free for commercial use catalogs before and all distributions shipped KDE without a problem. When you put KStars on a CD and charge for it, you're not charging for KStars itself (if you are, then you're insane) but you're charging for the medium and the costs associated with it, therefore, you're not 'commercilizing' KStars and the whole argument falls apart.
The FSF used to charge $1000 for a copy of "the GNU system", and it didn't even boot. They offered paper tape, too.
So yes, many charge for copies of GPL software. Hell, *I* charge for copies of BSD software.
"a big joke to suggest you can make money from a GPL software from the software itself."
No, that's no joke. A joke is putting words on other people's mouths. I never said anything you said i said, nor will I say more even if it needed saying.
>Imagine that a bunch of people want to distribute Kstars at a price, to pay for costs. Or that a scientific magazine wants to put it in its CD.
Neither situation makes KStars commercial software, so the use of "free for non-commercial use" data is still OK, IMHO. Same goes for commercial Linux distributions; just because they sell a CD with my program on it doesn't make my program commercial software. Linux distros sell convenience and support.
The only situation we have to worry about is someone harvesting the catalog from KStars and incorporating it in their own commercial software. KDE policy is that we do not want to prevent people from trying to do this, even though the Free version of the catalog is protected by the GPL, making commercialization of it nearly impossible anyway, IMHO. So, I have to ship an inferior catalog to allow for the possibility that someone may want to sell it, even though no sane company would try (why would anyone buy a KStars catalog when it can be download for free?)
How about putting a menu option that would go off and download the catalog for you?
Catalogs == good. Any plans for the Abell or Hickson catalogs?
Great work on kstars, by the way!
-- Stephen
We're plannning on this, and also a startup wizard which will ask if you want to install "extra" data the first time you run it. Other apps in Edu need it as well, so we'll likely make a common widget, or use KNewStuff from PIM. Have to wait for feature thaw, though.
Great!
-- Stephen
I do't really understand is this really the simple act of selecting text or something more. I never thought Konqueror was very slow when selecting text.
Anyway, I'm very happy about the recent changes in KDE and especially the focus on bug squashing.
I also want to know up to what version fo safari have changes to KHTML been made or are they just from all over?
Either way, Konqueror's rendering engine seems to be approaching Gecko quickly.
> Either way, Konqueror's rendering engine seems to be approaching Gecko quickly.
It doesn't deserve this harsh form of criticism. ;-)
As to selecting text, selecting in Konquerors HTML view looked different than in widgets. It no longer will and that's a big deal for consistency. For those like you and me used to it, we probably will notice only the absence.
The speed I cannot find a problem either, maybe in complex layouts. But until I can correctly paste tables with layout into e.g. KWord, I won't do that much anyway.
Yours, Kay
I totally agree that Konq has become very good at rendering pages.
Hell, when I compiled the latest CVS, I couldn't believe that Konq rendered ESPN well.
However, there is an area of Konq which I believe to be slow... CSS.
For those doubters, please use Gecko-based browsers and hit
http://www.enlightenment.org
Notice how the background image is smooth when scrolling down the page?
Now please try it with Konq, and notice how it's choppy? (or is it just my Thinkpad?).
I know it's nitpickin', but thought I'd mention.
Also, mouse-over menus at http://www.cnnsi.com
Mouse-over effects are rather slow (choppy) compared to IE on Windows.
Please excuse me if I'm the only one encountering these lags.
That's because you shouldn't be looking at alternate projects ;p
Yeah, I notice taht too, but very slightly.
No I have also noticed css mouse-over slow downs. It is mostly when you have a bunch of text displayed on the screen though. Check out http://sycophant.org, then click on a topic, then open an article, when you move up and down the menu on the left you can see a great deal of slow down.
smeat!
Okay, this is just great, I've been trying to get an account to comment on kdedevelopers.org for 3 days since it makes you register now. Unfortunately, no amtter what I do it will NOT work :((( I've tried 3 e-maila dresses and trust me, my e-mail is NOT THE PROBLEM, it's the website! It won't send me my password and when I say I forgot my password it also won't send me my password! I've tried everything, if you can't make registering actually work,a t elast don't force us to register.
I registered a few days ago and it worked without problems. Perhaps you should try to contact geiseri at yahoo dot com who is AFAIK responsible for the site.
try getting an account through drupal.
I should first note that I am only talking about bugs which resulted from a programing error. I realize that there are other types of bugs ... -- some which require major redesign.
What does it mean that a bug is fixed?
I received the automatically generated e-mail advising me that Bug 48747 had been:
RESOLVED
FIXED
But, the bug in KDE 3.1.x has NOT been fixed -- it is still the same after an update.
I think that this is a corporate culture issue. Perhaps it shows the rather low position occupied by:
1. The users.
2. The current release.
Yes, it is the same problem as with commercial software. What it means is that the bug will be fixed in the NEXT release.
I would like to again strongly disagree with this. This is not the way to do it.
If this type of bug was reported as being in the current release then it should be fixed in the current branch (which might not be the release it was reported in), not in a future release. It should start out as a patch to the current branch and then be ported to future releases and HEAD.
I suggest this as a modest first step in changing the culture to be more oriented towards fixing bugs.
--
JRT
Maybe I don't get it.. but don't bugs get always squashed in head first? And then there may be a backport to the latest stable branch..? At least that's how it's done with the linux kernel.
I am not 100% famailar with how the Kernel is developed. But, you should first consider that it has a much longer release cycle and that bugs in the current release branch are fixed. But, in any case, perhaps ultil we release KDE-3.1.20 we shouldn't use the Kernel development cycle as the model for KDE.
--
JRT
Sorry, I don't think this is the way how things work. Developers mainly work on the HEAD branch. Bugs are fixed here and later are backported to BRANCH. As the probability of the new release of BRANCH goes low (like now when the release cycle for 3.2 has started) developers are really busy working on HEAD and only critical bugfixes are backported. You should know that it's not fun at all to maintain two or more branches and many people don't do it at all. Thankfully there are some developers who cared about backporting, but from the commit logs I see that they are also very busy with HEAD right now. And this is normal.
And don't forget that some bugs are easy to be fixed in HEAD (may not even apply), but are hard or close to impossible to backport. For example imagine that Quanta parses incorrectly a HTML document in BRANCH. I most probably won't fix it as the parser is rewritten in HEAD and if it's working there sincerly I don't care about the BRANCH as it would stole from me maybe several hours to fix. Hours that I could use to fix bugs in HEAD or implement new features. And that is more fun. ;-)
Sorry for dissapointing you.
Andras
If you have complaints about how we handle our bug reports for free for you, then maybe you can take over maintenance of our ~9000 bugs and wishes. Bugs cannot be left open forever simply because there exists a release that does not contain the fix. It is a maintenance nightmare and developers will spend more time closing bugs than they will actually fixing them. It's a big waste of everyone's time, and in the end, I think we'll all just give up on bugzilla. We do this for free, and this is how we have chosen to deal with things. We are open to constructive suggestions on how we can manage our time more effectively. We are not open to complaints that we do not do enough for user. Everything in KDE is done for ourselves (as users, yes we use KDE too) and for our users.
KDE is getting close to 3.2 beta. Development of 3.1.x is basically done, with only critical bugs being backported. If you want 3.1.x to be developed for your own personal needs, perhaps you should consider a support contract with one of the several KDE related businesses. Even better, you could join the KDE team and contribute to it yourself. You could even contribute to bugzilla if you have better ideas for how to manage bugs too.
Suggesting to KDE developers how we should change our behaviour to better suit people who use our software for free is one of the most pompous and presumptuous acts I can imagine. You have a right to have that attitude with a company that you pay to develop software for you. You don't have that right with OpenSource.
> Suggesting to KDE developers how we should change our behaviour to better suit people who use our software for free is one of the most pompous and presumptuous acts I can imagine. You have a right to have that attitude with a company that you pay to develop software for you. You don't have that right with OpenSource.
Well said, considering most KDE Developers are working on their own time.
> Well said ... .
> Suggesting to KDE developers how we should change our behaviour to better suit
> people who use our software ... . [sic]
To me this statement is the height of arrogance. It is the canonical expression of the "arrogant developer syndrome".
--
JRT
It is the height of arrogance to suggest that you have any expectations at all with FREE software.
NO WARRANTY
15. BECAUSE THE LIBRARY IS LICENSED FREE OF CHARGE, THERE IS NO
WARRANTY FOR THE LIBRARY, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR
OTHER PARTIES PROVIDE THE LIBRARY "AS IS" WITHOUT WARRANTY OF ANY
KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE
LIBRARY IS WITH YOU. SHOULD THE LIBRARY PROVE DEFECTIVE, YOU ASSUME
THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
We have use of this software because someone at great cost of time and resources decided to make it available to us. I expect that the individual developers would have the maturity to manage their time and resources to benefit themselves. If I benefit, it is purely incidental. And if I want more than someone else is willing to GIVE? Isn't that the height of arrogance? The license that you agree to is that you bear the cost of the fix.
Derek
HELLO! Ever read a Micro$oft software license?
They say the same things! No warranty at all.
--
JRT
Yes, but they say it after you've shelled out your $300 and opened the shrink-wrapped box, thus making it unreturnable.
And your point is?
Have you ever thought that maybe your suggestions are essentially the same as saying "you give me 20 hrs each week. What I really want is 40"?
Derek
No, I never thought that.
What I do think is that Tom Petters' and Edwards Deming's ideas are good ones.
That using them in software developement would result in more being acomplished with less effort and that the results would be higher quality.
If we set those ideals as the goal, do you disagree with it?
I have to conclude that many of the arrogant an condecening remarks are from people that did not read and/or did not understand what I said.
You need to learn to think outside of the box.
Now, you may have legitimate disagreement with the methods of achieving these goals but ... .
--
JRT
> To me this statement is the height of arrogance.
> It is the canonical expression of the "arrogant developer syndrome".
How is that arrogant? Would you do everything other people whine about when this is someones hobby? Some people in this project work hard on fixing bugs in both HEAD and BRANCH and those are really admirable. However, we have at several occasions pointed out this is not, cannot and will never be normal just because of the way contributional software works. FOSS does NOT exclude the option to pay people to fix your bugs, but you can't expect voluntary contributors to roll out the red carpet before and sweep behind you. Would you? This has been pointed out to you so many times and you still don't seem to understand. Why is it so hard? FOSS is _not_ your personal cockaigne, it's what people contribute, and contributors... you get the idea, don't you?
Cheers,
Daniel
OH! Goody, a semantics discussion.
You can call it what you will.
The M-W dictionary defines 'arrogant':
1. exaggerating or disposed to exaggerate one's own worth or importance in an overbearing manner
2. proceeding from or characterized by arrogance
and 'arrogance':
a feeling or an impression of superiority manifested in an overbearing manner or presumptuous claims
Or you can call it something else if you want, but that doesn't change what it is and what is is isn't good.
OTOH, you posting is not really arrogant, I find it condescending.
--
JRT
> OTOH, you posting is not really arrogant, I find it condescending.
Quite remarkable scentence Mr. "I am an professional you inapt idiots" Tyrer, isn't it?
You must have totally misunderstood what I previously said -- perhaps intentionally.
I did not intend to denigrate anyone.
What I was saying was that I did not appreciate the condescending treatment I received from self taught hackers.
So to rephrase your statement, I am Mr:
'I am a professional engineer, you shouldn't treat me like a know-nothing newbie.'
Hope that that clears things up. Sorry for any misunderstanding.
--
JRT
"Cockaigne"?
Hey, I learned a new word today!
Stop feeding the troll. Ignore him and he'll go away, or get a clue, eventually.
We don't have the resources to do this. If you want to fund a small team of people (6-12 people) to work full time in backporting bugs, then go ahead, I think we'd all appreciate it :)
Still wondering why KDE developers don't listen to you? Because of your behavior shown in past and present (like http://marc.theaimsgroup.com/?l=kde-cafe&m=106473157227245&w=2). Accusing others of arrogance and disqualification don't increase your chances to be considered as valuable KDE user (user because you still failed to bring in any active development effort).
> Still wondering why KDE developers don't listen to you?
No, I don't wonder anymore. I know -- it is due to arrogance.
> Accusing others of arrogance ... .
The three messages in the kde-cafe link demonstrate this arrogance.
Ra's ipso liquid; the thing speaks for itself.
> ( ... you still failed to bring in any active development effort).
Perhaps I misunderstood, but I was lead to believe that my help in fixing bugs would not be welcome because I would be submitting patches to the current release branch.
I *have* found solutions to several bugs, but it appears that nobody (hardly anybody actually) is interested. I'm not really clear about the reasons for this, but I did what others do, I found solutions to the bugs that bothered me the most.
Note: I posted to kde-cafe because I thought that it would be better to continue this discussion there.
--
JRT
Applying patches to the branch and not to HEAD makes the bug tracking problem worse, not better. Then we mark a bug fixed and it returns, or we have to leave bugs open until HEAD becomes "stable" and then reiterate through all the bugs all over again. Supply patches against the branch, but also check out the code for HEAD and do the merge of the patch there. Send both patches - as part of a bugzilla report, not a post to a mailing list that will certainly be lost - and they will certainly be accepted if they are correct.
> Applying patches to the branch and not to HEAD makes the bug tracking problem
> worse, not better
Hmmmm ... Does/would this really change things.
A bug is marked as closed when a patch is posted but not really fixed till the patch is applied to the CVS tree. Perhaps an additional status marker should be added to Bugzilla to indicate that the patch had been applied. But, this doesn't change -- it is the same whether you make the patch for the current BRANCH or for HEAD. The only issue is that it may take some tweaking to apply the patch for the BRANCH to HEAD.
In any case, bugs have a habit of returning on HEAD because it is not stable. This should not happen with a patch to the *stable* branch.
> Send both patches - as part of a bugzilla report, not a post to a mailing list
> that will certainly be lost - and they will certainly be accepted if they are
> correct.
Duh! I post my patches to Bugzilla. I only post them on the mailing list for possible discussion; usually a short while before I post them to Bugzilla. But, you are still saying that if I only post a patch for BRANCH that it isn't acceptable.
--
JRT
No, bugs return in HEAD because a patch gets applied to BRANCH and not to HEAD, or because the patch is rebroken in HEAD. You are welcome to post whatever patches you like as long as they pass moderation on the list. If you want a developer to apply it, you either have to provide a patch for HEAD as well, or you have to hope that the developer will forward port for you. They don't live to serve you though, and if they don't have time to forward port it, then it has to wait. File a report and one day it will be solved.
Getting back to your previous posting. I thought about this a while and it appears that you may have stumbled onto something.
Bugs that are marked as fixed because they are fixed in HEAD should be left open as you said -- then need to be left open till a stable BRANCH with the bug fix is released. Otherwise, there is no assurance that the bug is actually fixed -- that it will not regress.
> No, bugs return in HEAD ... .
You can, if you wish, believe that there is no regression in software development but I don't think that anyone will believe that.
--
JRT
It's a futile attempt trying to encourage most KDE developers to close bugs. Or trying to encourage a development process that isn't "entirely feature centric". You'd be dissappointed and flamed to oblivion. Only some weeks ago I reported a bug. The response I got was "It doesn't happen here on KDE-CVS". Yeah, I guess if I was using KDE-CVS I wouldn't have reported the bug.
Some developers are responsible enough to fix the bugs. Others just ask for a backtrace and tell you "it doesn't happen here on KDE-CVS". Fix!. Forget it. You either need to use KDE-CVS, bear with the bug or use the next major release of KDE, 6 months later or so.
The question is why release your work for public consumption if you are not willing to be responsible for it, maintan it, or you don't care for the productivity of the users who are using and testing it? Oh, just watch the flood of responsive that follow this. They'll all be in the form of "put up or shut up", "hire a development team", "they work for free", "you don't contribute so keep quiet", "you don't know how open source works", etc. Have I missed any?
Hi,
you are still free to use more professional products. When did you e.g. last time had a backport for an other desktop you used? I mean some of those rich companies must be very eager to listen to you.
Not?!
Now what... just because those people try to make something fun to use means they have to be your slaves?
Yours, Kay