In this week's CVS-Digest: Disconnected IMAP fixed in KMail. KHTML now supports jng image format. KDevelop has a Subversion plugin. KDE has global settings for mouse gestures. Kopete has new "Away" and plugin configuration dialogs. KControl has a new style configuration dialog. Plus many bugfixes in KMail and KHTML.
Dot Categories:
Comments
Derek
It's very very important! Please merge the kroupware-branch!
Thanks!
Agreed. I would be stuck with a patched KDE 3.1 as well if the Kroupware branch won't be included in KDE 3.2.
As always an interesting read.
Bug 61617 - tabs resize (shrink) when clicked on while loading
Ah! I _almost_ got used to it ;-)
But nice to know that it's gone. Come to think of it - it's been quite
annoying...
BTW (OT):
For quite some time now I'm trying to figure out why Noatun interrupts
playing a song for a second or so after half a minute of playing. After that
it plays the song till the end without any further interruption. XMMS via
Arts doesn't do that. I played with the Arts settings anyway, tried
hdparm -d1 /dev/hda
but to no avail. This occurs on all PCs I've installed KDE, at work
as well as at home. Is it a know bug (couldn't find any) or have I overlooked
some setting? I'm using KDE 3.1.2
Hooray! They fixed the khtml bug with the dashed lines around visited links not being erased correctly! I love reading about my "pet peeve" bugs being swatted :-)
I spotted this:
> Added very basic support for , much like , as a generic block element.
Is it really worth supporting obsolete, proprietary elements like that? As far as I know, the only other browser to implement elements is Netscape 4.x. It's an buggy anachronism that's probably better off forgotten about.
Yeah, this could just bloat the engine, nobody uses those anymore since 99% of people's browsers are incompatible with them. But, hey its still better to have a wider support.
I'm not really concerned with bloat of that nature, I'm more concerned with the KDE maintainers:
a) Having to know about the element type in the first place,
b) Having to figure out how to treat them,
c) Having to find/write testcases to check that things work properly, and
d) Having to maintain the code in the future.
Remember, just because one developer implemented it, it doesn't mean that other KHTML developers know all about the element type. When a bug report comes in about it or they need to modify the code for some other reason, the work has to go through the small number of developers that know about this odd element type, rather than the large number of developers that know about proper HTML.
It's a maintenance burden that offers virtually no benefit (how many websites rely on these element types, considering only Netscape 4.x supports it? Not many, I'd bet).
Hi,
I guess Apple did it. And if so, why not?
Yours, Kay
I think I was pretty clear on why not: it takes up developer resources for no gain.
So somebody did it for fun.
Go ahead, demand punishment, demand removal, how do you qualify to?
Yours, Kay
Er, *what*? I said I don't think it's a good idea. I didn't say that somebody should be punished and I'm not demanding anything. All other things being equal, the less code in an application, the better. I qualify to judge whether it's a good idea or not as I am very familiar with HTML and common HTML user-agents.
> Er, *what*? I said I don't think it's a good idea.
Actually you said a little more than that, or at least very emphatically.
> I didn't say that somebody should be punished and I'm not demanding anything.
So this isn't a demand, just a rant? ;-)
> All other things being equal, the less code in an application, the better.
Then I guess all other things weren't equal. FWIW it was David Faure who put it in. He's not exactly a developer one would suggest is wandering around searching for a clue. He was a key architect on konqueror and kword and kparts are his baby. He also has been sponsored full time or half time on KDE for years.
> I qualify to judge whether it's a good idea or not as I am very familiar with HTML and common HTML user-agents.
...and that means exactly what? You don't qualify to judge because you are in no position to mediate. You qualify to have an opinion based on some information which is a different matter entirely. As the saying goes, "everybody has an opinion...". In a general context your opinion might have some value, if David has sought it. However if you read the commit it says he did it so that the release manager could view one of his favorite sites. Now... knowing what open source is, if developers who in fact do take responsibility for the code can't have some indulgence that facilitates their using that code in thier day to day development because a user who is not actually doing the development doesn't think it's a good idea... well... why bother. (Besides, this does support more sites that users who have no idea what W3C compliance means are asking for. Are we taking a stand against that because it's not W3C?)
So that explains the tone in response to the tone of your post. I'm not going to argue whether an obscure tag should be supported just as you should not argue whether respected developers will be able to maintain thier application. You're certainly free to say you think it's hooey, but it would be nice to eventually come down to some support for the developers being able to enjoy their code too.
> Actually you said a little more than that,
I explained my reasoning, sure.
> or at least very emphatically.
The only emphatic bit I see is:
"It's an buggy anachronism that's probably better off forgotten about."
...and that's in relation to the element, so I can hardly see why people should be upset on behalf of the KHTML developers, and I don't see how I could be mistaken for calling for punishment or demanding anything.
> So this isn't a demand, just a rant? ;-)
Yes :)
> > All other things being equal, the less code in an application, the better.
>
> Then I guess all other things weren't equal. FWIW it was David Faure who put it in. He's not exactly a developer one would suggest is wandering around searching for a clue.
Of course not. But that doesn't mean he isn't immune to bad decisions or necessarily well-informed about the various usage patterns of every element he comes across either.
> > I qualify to judge whether it's a good idea or not as I am very familiar with HTML and common HTML user-agents.
>
> ...and that means exactly what?
It means that I know what I'm talking about when I say things like:
"As far as I know, the only other browser to implement elements is Netscape 4.x. It's an buggy anachronism that's probably better off forgotten about."
> You don't qualify to judge because you are in no position to mediate. You qualify to have an opinion based on some information which is a different matter entirely.
So you are saying I overstepped my bounds when I assumed it was meant to be a proper implementation rather than a special-case workaround for one of the developers?
> However if you read the commit it says he did it so that the release manager could view one of his favorite sites.
Wouldn't it have been better to fix the website in question? It would help the website, and it would mean *zero* code to maintain for KHTML.
> (Besides, this does support more sites that users who have no idea what W3C compliance means are asking for. Are we taking a stand against that because it's not W3C?)
That's the second time somebody has mistaken my position as being a W3C cheerleader. Will you read what I wrote please? The issue is that any website relying on layers will only work in Netscape 4.x [1], and, consequently, it's so rare to find a website relying on layers that it's hard to justify implementing it. Furthermore, as it's not part of any standard, and there are already standard ways of doing it, the number of websites I expect to use layers in the future hovers somewhere between zero and one.
So yeah, if the release manager wants some code in to handle a website he likes, who am I to argue? But you can't seriously tell me that the problem was fixed in the right place, can you?
[1] If Bugzilla entries are anything to go by, they sniff for Mozilla to serve it better code. I don't have time to look into it now, but it seems to me that all they'd have to do is update their sniffing code to check for Konqueror as well (it's a horrible implementation anyway, but extending it to one more browser is the least intrusive fix).
According to , Mozilla doesn't do *any* special-case handling for layers. It's possible the partial implementation of and confused the sniffer, and so ripping out instead of putting in would have fixed the problem and brought KHTML closer to Mozilla behaviour.
> (how many websites rely on these element types, considering only Netscape 4.x supports it? Not many, I'd bet).
Using that argument, we should remove support for the w3c dom too, eh?
No because the DOM might be used in the future, this si unlikely to be used in the future.
> Using that argument, we should remove support for the w3c dom too, eh?
No. Did you read my argument?
a) Knowing about the element type is a lot more probable since it is a standard element type,
b) Developers already know how to treat them since they are defined in a public specification,
c) Testcases for the HTML/XHTML specifications are already available,
d) developers already have to maintain standard HTML code, and
e) lots of websites already use the DOM - virtually no websites use the element.
Basically, any argument for supporting the element doesn't have a leg to stand on, and comparing it to the DOM is ludicrous.
the new titles in kcontrol for each of the subsections are good in theory. however the icons are a blurred mess... will this mean svg icons are around the corner? ;P
I need to create 22x22 versions for some of those icons. They are currently scaled up from the 16x16 version and hence the blur.
I use kmail from kde cvs of 10th october and it freezes while checking my spammassassin filters even though the it dod. is that a known bug or is it just me? maybe it's been already fix.
thanx
pat
sorry I meant it freezes but it doesn't crash, i just have to wait a couple douzen of seconds before it gets back to normal, the filters works great though :)
Just use spamc instead of spamassassin.
It's caused by KMail executing filters in the same thread as the GUI. I had this problem about a year ago. Work is being done to rectify this I think, though I don't know when it will be completed.
Right now...
-------------------------------
Date: Today 21:17:21
CVS commit by tilladam:
Add Mirko's threadweaver to libkdepim until after 3.2 when it will likely
go into kdecore so we can use it in kmail for async filtering and async
gpg operations.
-------------------------------
Note this is just the lib, but the kmail implementation will follow soon. Thanks to Mirko, Don, Till and the others
Cheers,
Daniel
Ooooh sweet :)
Thank you so very much!
this is why I like kde so much :)
Does anyone know how to set up the gestures, so that one can close a tab with a gesture?
Closing tabs can be done through the older hotkeys, but only with keyboard shortcuts. Would be nice if that interface provided a way for providing gestures instead of keyboard shortcuts.
Yeah, I wish there was a Gesture->DCOP Call action in khotkeys2.. but you can do it with a Gesture->Keyboard action in khotkeys2 in recent CVS. Just make sure the window contains "Konqueror" or whatever other browser you use (keyboard input works with non-KDE apps as well)
But there is a gesture->dcop action, the question is, what dcop action is needed to close the active konqueror tab in the active konqueror window. I couldn't do it.
You can create Gesture->DCOP action if you choose the generic type and create it yourself. Also, there is kdebase/khotkeys/khotkeysrc, if you use that as your config file, you'll get demonstrated most of the features. I guess creating gesture for closing a tab based on the demo gestures that are there shouldn't be difficult.
May I see a screenshot of the new style dialog?
It's just a "Configure..." button beside the style combobox which opens a small options dialog window.
Ceebx has just released a new version of his Plastick style: http://www.kde-look.org/content/show.php?content=7559
One of my pet peeves regarding every KDE style is that there is no cool animated progress bar. Is there some way to have an animated progress bar in Plastick, like in Keramik (with patch) and OS X?
Something just like this: http://www.kde-look.org/content/show.php?content=6345
BTW: Did the above project make it into Keramik CVS, and if it didn't do you know why not? I really think it should.
Plastik rocks!
if only I could have a deb for unstable :-(
It's already in unstable.
Hmm, Keramik as of the latest CVS update (last night) has animated progress bars.
COOL! I didn't think it did since the project on looky said it wasn't in CVS yet. What about Plastick, I haven't tried the CVS version.
Nope.
I'm using Konqueror 3.1.4 on KDE 3.1.4. My konqueror window
is over 800 pixels wide. Yet this web page, hosted at KDE,
renders wider than the browser. If I want to read a line of
text, I have to scroll the window sideways. That makes
Konqueror effectively unusable. Despite claims to the
contrary, this bug was not fixed in KDE 3.1.4. The sad
thing is, KDE developers simply don't care about this
problem.
Umm, ok, I _could_ try to match the tone of your posting but I
rather prefer not to. Though I'm not a developer:
Please go to bugs.kde.org and look how many open bugs are listed there.
Then go look at the bugs most voted for.
Now imagine someone would post a message like you for everyone
imprtant bug which is posted there. And there are a lots of bugs over
there. I don't want to write that old: "Go fix it yourself" stuff
because I consider that equally stupid. But a bit more understanding
for unfixed bugs would definitively help here. I'm not saying that you
shouldn't campaing for "your" bugs here or that you shouldn't say out loud
what bothers you about KDE. But to claim that KDE developers "don't care"
is just that - a claim. The difference to M$ is here: You paid no money
for KDE you get it all for free. There is no one you can blame for it
if sth. works not as expected. And if you consider all that - honestly -
KDE as a whole is a pretty good piece of software isn't it? So if you
think this bug is so bad that you can't use Konq without it being fixed
- so well - you can tell is here - you can be annoyed - you can use Mozilla
for the time being - but please don't claim that developers are not
interested in fixing ANY bug which just isn't true. Otherwise KDE wouldn't
be where it is now.
Don't know if that's correct english... but: Don't cast pearls before swine...
Anyway.. meanwhile I set the size of my konqu window to < 800 px in width and the line-length and page-width were correctly re-adjusted. It just resulted in a lot of word-wrapping like it's supposed to do... (KDE 3.1.3)... So what is this all about?
please dont feed the troll
Well, perhaps you are right. But I decided to post anyway but to
post an answer that not leads into endless discussions and sth. which
might be good to read for a wider audience because we all can sometimes be annoyed by bugs... He can reply whatever he wants now, I'm outta here...
What URL? What distribution? What package? Nobody is going to help you without some additional informations as it's no general problem.
Developers do care. It's fixed in the CVS.
I'm a user, I can't begin to tell you how good using KDE makes me feel. It's good kit, looks amazing, adds KStars, (don't know what it's supposed to be for but I enjoy playing with it) - it mystifies me when people moan.
FTIW
Subversion looks nice.. im glad KDevelop is now compatible :)
/kidcat
I tried to compile kio_svn against the current debian svn-libs today to try out the svn support.
It didn't work.
Seems that kio_svn does not support subversion 0.31 (=current) yet.
Unfortunatly I was unable to find any hints on which svn-Version should work.
--
killefiz
But as usual Subversion is not GPL, but has a BSD-like license...
How about supporting also GPL'ed revision control system like GNU's arch [http://www.gnu.org/software/gnu-arch/]?
Maybe a feature for kde-3.3?