not displayed > > > > Thanks. > > Any ideas on whether this is a known bug? I looked around bugzilla, but > > couldn't find any bugs that match this. > > this doesn't really ring a bell to me... but it's definetly an HTML parser > bug and I naturally tend to avoid those ;/ > > you might want to fill a new bug report to increase the odds of this > getting fixed soon. The bug's reported as #122884 (http://bugs.kde.org/show_bug.cgi?id=122884) Thanks for your help and thanks in advance to anyone who can take a closer look at this. -- Jani-Matti Hätinen From faure at kde.org Wed Mar 1 10:34:00 2006 From: faure at kde.org (David Faure) Date: Wed, 1 Mar 2006 11:34:00 +0100 Subject: AW: AW: AW: making fallback access keys configurable In-Reply-To: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> Message-ID: <200603011134.00820.faure@kde.org> On Wednesday 01 March 2006 00:50, Tobias Anton wrote: > So let's try to > separate the bug from the feature: How and why exactly does it disturb you? > Maybe if triggering the accesskey would be restricted to certain sensible > special cases? Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, when I release Ctrl above the kmail reader window, I get the access keys popping up. Very annoying. I do believe the shortcut should be changed, because Ctrl is a modifier, not a key that is supposed to do something by itself. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From ivor at ivor.org Wed Mar 1 11:19:56 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Wed, 01 Mar 2006 11:19:56 +0000 Subject: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603011134.00820.faure@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011134.00820.faure@kde.org> Message-ID: <4405835C.8060800@ivor.org> David Faure wrote: > On Wednesday 01 March 2006 00:50, Tobias Anton wrote: >> So let's try to >> separate the bug from the feature: How and why exactly does it disturb you? >> Maybe if triggering the accesskey would be restricted to certain sensible >> special cases? > > Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, > when I release Ctrl above the kmail reader window, I get the access keys > popping up. Very annoying. I do believe the shortcut should be changed, > because Ctrl is a modifier, not a key that is supposed to do something by itself. > Perhaps we need something similar to the windows XP access keys activation? You know when you hold down Ctrl for 8 seconds and it turns on sticky keys? double ctrl-click? For Kde4 do we need some sort accessibility keys applet that can control these enhancements centrally? Or is one planned? Personally I'm a fan of the ctrl- activated tooltips use them quite often on badly designed websites when I can't actually see where the links are! :) Cheers, -- Ivor http://www.ivor.it From ivor at ivor.org Wed Mar 1 11:24:00 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Wed, 01 Mar 2006 11:24:00 +0000 Subject: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603011134.00820.faure@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011134.00820.faure@kde.org> Message-ID: <44058450.6080402@ivor.org> David Faure wrote: > On Wednesday 01 March 2006 00:50, Tobias Anton wrote: >> So let's try to >> separate the bug from the feature: How and why exactly does it disturb you? >> Maybe if triggering the accesskey would be restricted to certain sensible >> special cases? > > Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, > when I release Ctrl above the kmail reader window, I get the access keys > popping up. Very annoying. I do believe the shortcut should be changed, > because Ctrl is a modifier, not a key that is supposed to do something by itself. > Perhaps we need something similar to the windows XP access keys activation? You know when you hold down Ctrl for 8 seconds and it turns on sticky keys? double ctrl-click? For Kde4 do we need some sort accessibility keys applet that can control these enhancements centrally? Or is one planned? Personally I'm a fan of the ctrl- activated tooltips use them quite often on badly designed websites when I can't actually see where the links are! :) Cheers, -- Ivor http://www.ivor.it From klingens at kde.org Wed Mar 1 11:47:51 2006 From: klingens at kde.org (Martijn Klingens) Date: Wed, 1 Mar 2006 12:47:51 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603011134.00820.faure@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011134.00820.faure@kde.org> Message-ID: <200603011247.52502.klingens@kde.org> On Wednesday 01 March 2006 11:34, David Faure wrote: > Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, > when I release Ctrl above the kmail reader window, I get the access keys > popping up. Very annoying. I do believe the shortcut should be changed, > because Ctrl is a modifier, not a key that is supposed to do something by > itself. The problem is not so much the ctrl-key itself, it's more the fact that KHTML responds to key-up rather than key-press. If my screen in blanked (screensaver) and I press ctrl to unblank I always end up with access keys in Kontact or Konq. That particular ctrl-press wasn't meant for Konq or Kontact and thus shouldn't be processed by it either. -- Martijn From koos.vriezen at xs4all.nl Wed Mar 1 13:14:39 2006 From: koos.vriezen at xs4all.nl (Koos Vriezen) Date: Wed, 1 Mar 2006 14:14:39 +0100 Subject: Flash using Gnash for KDE = Klash Message-ID: <20060301131439.GI90960@xs4all.nl> Hi, AFAICS there isn't a plugin for konqueror using Gnash for flash, so I created one. It's now located at www.xs4all.nl/~jjvrieze/klash-0.0.1.tar.bz2 with even a debian directory. Read the README for building the gnash thing. Please give some comments (hopefully not that it's already there). It should be rather stable, though plain and simple. Please note that Gnash uses openGL and hardly works w/ remote X clients. Koos From frans.englich at telia.com Wed Mar 1 13:31:06 2006 From: frans.englich at telia.com (Frans Englich) Date: Wed, 1 Mar 2006 13:31:06 +0000 Subject: kdom and khtml integration In-Reply-To: <20060226232159.GA50130@xs4all.nl> References: <20060226232159.GA50130@xs4all.nl> Message-ID: <200603011331.06153.frans.englich@telia.com> On Sunday 26 February 2006 23:21, Rob Buis wrote: > Good evening khtml hackers :-) > Came to think of another thing: I don't think KDOM as it is now is suitable for kdelibs inclusion. css/, core/ and events/ quite thoroughly spews compiler warnings and that isn't very correct. It is also avoided in kdelibs, so it would lower kdelibs quality. Likewise, there are admirable efforts for improving the Doxygen in kdelibs. KDOMBinder does currently at best generate no doxygen but regularly outputs invalid. I think it should be fixed, since otherwise it would lower kdelibs quality. But that's just my personal view on how things should be, of course. Cheers, Frans From faure at kde.org Wed Mar 1 13:22:35 2006 From: faure at kde.org (David Faure) Date: Wed, 1 Mar 2006 14:22:35 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603011247.52502.klingens@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011134.00820.faure@kde.org> <200603011247.52502.klingens@kde.org> Message-ID: <200603011422.35714.faure@kde.org> On Wednesday 01 March 2006 12:47, Martijn Klingens wrote: > The problem is not so much the ctrl-key itself, it's more the fact that KHTML > responds to key-up rather than key-press. Well this would give the same symptoms. If I want to do Ctrl+F2, I have to press Ctrl first, and this would activate access keys in khtml/kmail, when in fact I simply want to go to the 2nd desktop. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From l.lunak at suse.cz Wed Mar 1 13:31:11 2006 From: l.lunak at suse.cz (Lubos Lunak) Date: Wed, 1 Mar 2006 14:31:11 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603011247.52502.klingens@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011134.00820.faure@kde.org> <200603011247.52502.klingens@kde.org> Message-ID: <200603011431.11712.l.lunak@suse.cz> On Wednesday 01 March 2006 12:47, Martijn Klingens wrote: > On Wednesday 01 March 2006 11:34, David Faure wrote: > > Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, > > when I release Ctrl above the kmail reader window, I get the access keys > > popping up. Very annoying. I do believe the shortcut should be changed, > > because Ctrl is a modifier, not a key that is supposed to do something by > > itself. Yes, but it seems we can't do this right now because of string freeze. > The problem is not so much the ctrl-key itself, it's more the fact that > KHTML responds to key-up rather than key-press. > > If my screen in blanked (screensaver) and I press ctrl to unblank I always > end up with access keys in Kontact or Konq. That particular ctrl-press > wasn't meant for Konq or Kontact and thus shouldn't be processed by it > either. The code actually seems to check for a press followed by a release. I cannot reproduce your screensaver problem at all. Which of course doesn't mean there still aren't enough other ways to trigger it accidentally. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ From klingens at kde.org Wed Mar 1 13:33:22 2006 From: klingens at kde.org (Martijn Klingens) Date: Wed, 1 Mar 2006 14:33:22 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603011422.35714.faure@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011247.52502.klingens@kde.org> <200603011422.35714.faure@kde.org> Message-ID: <200603011433.23176.klingens@kde.org> On Wednesday 01 March 2006 14:22, David Faure wrote: > On Wednesday 01 March 2006 12:47, Martijn Klingens wrote: > > The problem is not so much the ctrl-key itself, it's more the fact that > > KHTML responds to key-up rather than key-press. > > Well this would give the same symptoms. > If I want to do Ctrl+F2, I have to press Ctrl first, and this would > activate access keys in khtml/kmail, when in fact I simply want to go to > the 2nd desktop. I said key press, not key down :) I.e., both the key-down and the key-up arrived at the application. If you get only one of them, but not both, you do nothing. -- Martijn From klingens at kde.org Wed Mar 1 13:42:08 2006 From: klingens at kde.org (Martijn Klingens) Date: Wed, 1 Mar 2006 14:42:08 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603011431.11712.l.lunak@suse.cz> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011247.52502.klingens@kde.org> <200603011431.11712.l.lunak@suse.cz> Message-ID: <200603011442.08327.klingens@kde.org> On Wednesday 01 March 2006 14:31, Lubos Lunak wrote: > The code actually seems to check for a press followed by a release. I > cannot reproduce your screensaver problem at all. Which of course doesn't > mean there still aren't enough other ways to trigger it accidentally. I have it regularly for months now. I set the screen saver to simply blank the screen and by default no locking. Hitting ctrl to unblank with Kontact having focus (and the KMail part active) triggers access keys popups. Not all the time though, it seems that even though KMail ought to be focusless, it has some vague notion of focus, where it only triggers this if the KHTML part has "focus". It's the same with '/' for quicksearch btw, if that key works in kmail the ctrl key also triggers access keys. Until about a month ago I was running Suse 9.1 with selfcompiled debug builds of 3.5 branch, but I had the problem long before the 3.5 release already. Currently I'm using Suse 10 with the 3.5.2 supplementary rpms, same problem. I'm using the 4-modifier keyboard scheme, and I told kxkb to map the menu key to Compose (but don't use it for different keyboard layouts), in case that's relevant. -- Martijn From faure at kde.org Wed Mar 1 14:22:25 2006 From: faure at kde.org (David Faure) Date: Wed, 1 Mar 2006 15:22:25 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603011433.23176.klingens@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011422.35714.faure@kde.org> <200603011433.23176.klingens@kde.org> Message-ID: <200603011522.25421.faure@kde.org> On Wednesday 01 March 2006 14:33, Martijn Klingens wrote: > On Wednesday 01 March 2006 14:22, David Faure wrote: > > On Wednesday 01 March 2006 12:47, Martijn Klingens wrote: > > > The problem is not so much the ctrl-key itself, it's more the fact that > > > KHTML responds to key-up rather than key-press. > > > > Well this would give the same symptoms. > > If I want to do Ctrl+F2, I have to press Ctrl first, and this would > > activate access keys in khtml/kmail, when in fact I simply want to go to > > the 2nd desktop. > > I said key press, not key down :) I.e., both the key-down and the key-up > arrived at the application. If you get only one of them, but not both, you do > nothing. Nope, still wouldn't work. I can do Ctrl+F1+F2+releaseCtrl, and then khtml received both the keydown and the keyup. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From klingens at kde.org Wed Mar 1 14:52:20 2006 From: klingens at kde.org (Martijn Klingens) Date: Wed, 1 Mar 2006 15:52:20 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603011522.25421.faure@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011433.23176.klingens@kde.org> <200603011522.25421.faure@kde.org> Message-ID: <200603011552.20895.klingens@kde.org> On Wednesday 01 March 2006 15:22, David Faure wrote: > > I said key press, not key down :) I.e., both the key-down and the key-up > > arrived at the application. If you get only one of them, but not both, > > you do nothing. > > Nope, still wouldn't work. I can do Ctrl+F1+F2+releaseCtrl, and then khtml > received both the keydown and the keyup. Hmm, seems like I didn't read your reply close enough, that's a different use case. Nevermind :) -- Martijn From tobias at ke.informatik.tu-darmstadt.de Wed Mar 1 15:59:01 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Wed, 1 Mar 2006 16:59:01 +0100 Subject: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603011134.00820.faure@kde.org> References: <200603011134.00820.faure@kde.org> Message-ID: <000f01c63d49$20b8d990$1601a8c0@Terroristencamp> You could as well be of the opinion that ctrl is just a key as every other and should be treated as such. Unfortunately, too much key handling is hardcoded in QT, making it hard to impossible to change certain behaviours. I think the idea behind the usage pattern "press ctrl once to make shortcuts appear, press it again to make them disappear" initially was to use ctrl like a modifier, i.e. "show shortcuts as long as ctrl is pressed", but then it became obvious that holding down ctrl while reading the accesskeys is very inconvenient. To keep that paradigm, yet removing the annoyance, a possible solution could thus be: - show the accesskey tooltips on Ctrl press - hide accesskey tooltips on Ctrl release if any other UI event had occurred since the corresponding Ctrl press. - otherwise, show tooltips until any key or mouse button changes status. Unfortunately, this will not work properly if the window manager dispatches all UI events between the ctrl-down and the following ctrl-up to another application. I think this is exactly what happens in your case, but most probably there is a solution for that, too. Particularly, I am thinking of something like the X11 window leave events, but I'm not too deep into the details of X11 event handling. Cheers Tobias -----Ursprüngliche Nachricht----- Von: David Faure [mailto:faure at kde.org] Gesendet: Mittwoch, 1. März 2006 11:34 An: kfm-devel at kde.org Betreff: Re: AW: AW: AW: making fallback access keys configurable On Wednesday 01 March 2006 00:50, Tobias Anton wrote: > So let's try to > separate the bug from the feature: How and why exactly does it disturb you? > Maybe if triggering the accesskey would be restricted to certain sensible > special cases? Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, when I release Ctrl above the kmail reader window, I get the access keys popping up. Very annoying. I do believe the shortcut should be changed, because Ctrl is a modifier, not a key that is supposed to do something by itself. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From zimmermann at kde.org Wed Mar 1 15:21:38 2006 From: zimmermann at kde.org (Nikolas Zimmermann) Date: Wed, 1 Mar 2006 16:21:38 +0100 Subject: kdom and khtml integration In-Reply-To: <200603011331.06153.frans.englich@telia.com> References: <20060226232159.GA50130@xs4all.nl> <200603011331.06153.frans.englich@telia.com> Message-ID: <200603011621.39345.zimmermann@kde.org> On Wednesday 01 March 2006 14:31, Frans Englich wrote: > On Sunday 26 February 2006 23:21, Rob Buis wrote: > > Good evening khtml hackers :-) > > Came to think of another thing: > > I don't think KDOM as it is now is suitable for kdelibs inclusion. css/, > core/ and events/ quite thoroughly spews compiler warnings and that isn't > very correct. It is also avoided in kdelibs, so it would lower kdelibs > quality. > > Likewise, there are admirable efforts for improving the Doxygen in kdelibs. > KDOMBinder does currently at best generate no doxygen but regularly outputs > invalid. I think it should be fixed, since otherwise it would lower kdelibs > quality. > > But that's just my personal view on how things should be, of course. > > > Cheers, > > Frans Hi Frans, you may have misunderstood something. There won't be a KDOM in kdelibs at all - we will integrate within khtml. That means we won't port all-in-one-shot, but in little manageable pieces. That includes regression testing, regression testing, regression testing. I for sure wouldn't want to introduce new warnings/errors/bugs. I'm not seeing your point. I want constructive discussions, mails like these don't help at all. And yes, I'm a bit angry. Bye Bye Niko From faure at kde.org Wed Mar 1 16:25:04 2006 From: faure at kde.org (David Faure) Date: Wed, 1 Mar 2006 17:25:04 +0100 Subject: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <000f01c63d49$20b8d990$1601a8c0@Terroristencamp> References: <000f01c63d49$20b8d990$1601a8c0@Terroristencamp> Message-ID: <200603011725.05988.faure@kde.org> On Wednesday 01 March 2006 16:59, Tobias Anton wrote: > You could as well be of the opinion that ctrl is just a key as every other > and should be treated as such. Yeah let's redefine the meaning of keyboard keys ;-)))) Sorry, but this makes no sense to me. Alt, Shift and Ctrl are modifiers, and have always been. > Unfortunately, too much key handling is > hardcoded in QT, making it hard to impossible to change certain behaviours. Phew :) > I think the idea behind the usage pattern "press ctrl once to make shortcuts > appear, press it again to make them disappear" initially was to use ctrl > like a modifier, i.e. "show shortcuts as long as ctrl is pressed", but then > it became obvious that holding down ctrl while reading the accesskeys is > very inconvenient. To keep that paradigm, yet removing the annoyance, a > possible solution could thus be: ... to use another key? ;) > - show the accesskey tooltips on Ctrl press > - hide accesskey tooltips on Ctrl release if any other UI event had occurred > since the corresponding Ctrl press. > - otherwise, show tooltips until any key or mouse button changes status. > > Unfortunately, this will not work properly if the window manager dispatches > all UI events between the ctrl-down and the following ctrl-up to another > application. I think this is exactly what happens in your case, but most > probably there is a solution for that, too. Particularly, I am thinking of > something like the X11 window leave events, but I'm not too deep into the > details of X11 event handling. I don't think khtml should grab the keyboard when I press Ctrl (since that would make Ctrl+F2 completely not-effective). -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From aseigo at kde.org Wed Mar 1 17:48:56 2006 From: aseigo at kde.org (Aaron J. Seigo) Date: Wed, 1 Mar 2006 10:48:56 -0700 Subject: AW: AW: AW: making fallback access keys configurable In-Reply-To: <4405835C.8060800@ivor.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011134.00820.faure@kde.org> <4405835C.8060800@ivor.org> Message-ID: <200603011049.09097.aseigo@kde.org> On Wednesday 01 March 2006 04:19, Ivor Hewitt wrote: > Perhaps we need something similar to the windows XP access keys > activation? You know when you hold down Ctrl for 8 seconds and it turns > on sticky keys? > double ctrl-click? we already have this for sticky/bounce/dead/etc keys... > For Kde4 do we need some sort accessibility keys applet that can control > these enhancements centrally? Or is one planned? we already have one. -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From aseigo at kde.org Wed Mar 1 17:53:13 2006 From: aseigo at kde.org (Aaron J. Seigo) Date: Wed, 1 Mar 2006 10:53:13 -0700 Subject: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <000f01c63d49$20b8d990$1601a8c0@Terroristencamp> References: <000f01c63d49$20b8d990$1601a8c0@Terroristencamp> Message-ID: <200603011053.14258.aseigo@kde.org> On Wednesday 01 March 2006 08:59, Tobias Anton wrote: > accesskeys is very inconvenient. To keep that paradigm, yet removing the > annoyance, a possible solution could thus be: > - show the accesskey tooltips on Ctrl press > - hide accesskey tooltips on Ctrl release if any other UI event had > occurred since the corresponding Ctrl press. > - otherwise, show tooltips until any key or mouse button changes status. which would break CTRL+Key_O == open. and having "other UI events" change the state of an explicitly requested mode on a user is generally very frustrating for users due to "loss of control". when the user says "i want $WHATEVER" the program should generally do that until instructed otherwise. oddly, right now we have the opposite problem where the program is entering a mode when people don't want it to resulting in a similar "loss of control" situation. -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zack at kde.org Wed Mar 1 20:30:48 2006 From: zack at kde.org (Zack Rusin) Date: Wed, 1 Mar 2006 21:30:48 +0100 Subject: kdom and khtml integration In-Reply-To: <20060226232159.GA50130@xs4all.nl> References: <20060226232159.GA50130@xs4all.nl> Message-ID: <200603012130.48699.zack@kde.org> On Monday 27 February 2006 00:21, Rob Buis wrote: > We've now reached a state where we > actually need integration of at least ksvg & khtml to support fancy > things like CDF (ie. xhtml in svg or the other way round). Excellent. I think pretty much everything has been addressed here so let me just add comments about one particular point: > 5. Merge in a subset of kcanvas into khtml/rendering. Trolltech has a working copy of a new canvas (QGraphicsView) that will be a part of 4.2 release. It's pretty impressive and with its clear model/view separation it would be rather simple to intergrate it. At this point I'm wondering what benefits does KCanvas offer that offloading maintaining of this chunk to Trolltech wouldn't offset. Zack -- There is no such thing as good luck. There is only misfortune and its occasional absence. From rwlbuis at xs4all.nl Wed Mar 1 21:11:36 2006 From: rwlbuis at xs4all.nl (Rob Buis) Date: Wed, 1 Mar 2006 22:11:36 +0100 Subject: kdom and khtml integration In-Reply-To: <200603012130.48699.zack@kde.org> References: <20060226232159.GA50130@xs4all.nl> <200603012130.48699.zack@kde.org> Message-ID: <20060301211136.GA50469@xs4all.nl> Hi Zack, On Wed, Mar 01, 2006 at 09:30:48PM +0100, Zack Rusin wrote: > On Monday 27 February 2006 00:21, Rob Buis wrote: > > We've now reached a state where we > > actually need integration of at least ksvg & khtml to support fancy > > things like CDF (ie. xhtml in svg or the other way round). > > Excellent. I think pretty much everything has been addressed here so let > me just add comments about one particular point: > > > 5. Merge in a subset of kcanvas into khtml/rendering. > > Trolltech has a working copy of a new canvas (QGraphicsView) that will > be a part of 4.2 release. It's pretty impressive and with its clear That is great to know! I am sure there will be lots of interest for such a canvas. > model/view separation it would be rather simple to intergrate it. At > this point I'm wondering what benefits does KCanvas offer that > offloading maintaining of this chunk to Trolltech wouldn't offset. My choice of words was a bit misleading, sorry. What I meant was merging/integrating in the sense that Apple has chosen to do, ie. take some canvas concepts such as rendering backend abstraction (for example quartz for them, qt4 for us) and integrate it with the render objects. This way they have RenderPath, RenderContainer, RenderSVGText, RenderSVGImage which uses right now (kcanvas) KRenderingDevice and paint servers to do the actual painting (using the backend mentioned above). Also the paint servers know about khtml RenderStyle, so this canvas implementation is not generic anymore but tied to khtml. I hope this clears up any confusion I caused :} Cheers, Rob. From ivor at ivor.org Wed Mar 1 21:59:55 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Wed, 1 Mar 2006 21:59:55 +0000 Subject: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603011049.09097.aseigo@kde.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <4405835C.8060800@ivor.org> <200603011049.09097.aseigo@kde.org> Message-ID: <200603012159.55882.ivor@ivor.org> On Wednesday 01 March 2006 17:48, Aaron J. Seigo wrote: > On Wednesday 01 March 2006 04:19, Ivor Hewitt wrote: > > Perhaps we need something similar to the windows XP access keys > > activation? You know when you hold down Ctrl for 8 seconds and it turns > > on sticky keys? > > double ctrl-click? > > we already have this for sticky/bounce/dead/etc keys... > Do we? The automatic activation I mean? (plays with modifier keys for a bit, hmm, think I need to read the manual. :) Hmm, ok I think we are talking about two slightly different things! I was referring to the way accesibility keys get activated, not the actual behaviour of the keys. > > For Kde4 do we need some sort accessibility keys applet that can control > > these enhancements centrally? Or is one planned? > > we already have one. > Ah, I know there's the control panel config, I didn't know there was an easy to get to applet like the windows applet.... (roots around for a bit) ok I can't find it. Cheers, -- Ivor Hewitt. From tim-ri at wanadoo.fr Wed Mar 1 22:26:49 2006 From: tim-ri at wanadoo.fr (Tim Ri) Date: Wed, 1 Mar 2006 23:26:49 +0100 Subject: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603011725.05988.faure@kde.org> References: <000f01c63d49$20b8d990$1601a8c0@Terroristencamp> <200603011725.05988.faure@kde.org> Message-ID: <200603012326.49375.tim-ri@wanadoo.fr> On Wednesday 01 March 2006 17:25, David Faure wrote: > On Wednesday 01 March 2006 16:59, Tobias Anton wrote: > > You could as well be of the opinion that ctrl is just a key as every > > other and should be treated as such. > > Yeah let's redefine the meaning of keyboard keys ;-)))) > Sorry, but this makes no sense to me. > Alt, Shift and Ctrl are modifiers, and have always been. > Alt is more than a modifier, it also activates the menu. From aseigo at kde.org Thu Mar 2 00:00:43 2006 From: aseigo at kde.org (Aaron J. Seigo) Date: Wed, 1 Mar 2006 17:00:43 -0700 Subject: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603012159.55882.ivor@ivor.org> References: <012401c63cc1$e0d94d50$1601a8c0@Terroristencamp> <200603011049.09097.aseigo@kde.org> <200603012159.55882.ivor@ivor.org> Message-ID: <200603011700.44297.aseigo@kde.org> On Wednesday 01 March 2006 14:59, Ivor Hewitt wrote:ss > Hmm, ok I think we are talking about two slightly different things! I was > referring to the way accesibility keys get activated, not the actual > behaviour of the keys. yes. and we turn it off by default so it doesn't annoy people. but you can turn it on in the accessibility control panel. > > > For Kde4 do we need some sort accessibility keys applet that can > > > control these enhancements centrally? Or is one planned? > > > > we already have one. > > Ah, I know there's the control panel config, I didn't know there was an > easy to get to applet like the windows applet.... (roots around for a bit) > ok I can't find it. do you have the kde accessibility module installed? -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivor at ivor.org Thu Mar 2 08:10:02 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Thu, 2 Mar 2006 08:10:02 +0000 Subject: connection keep-alive Message-ID: <200603020810.03637.ivor@ivor.org> Lo, Looking into a slowdown report for "http://www.linx.net".. (takes 1.30s to load in konq, 9s to load in firefox) The site contains a large number of small images and the site has everything as https. The reason for the slowdown was that konqueror was tearing down the https connection for every single image. The reason for this was that the server was returning an HTTP/1.0 header which contained "Connection: keep-alive" The current logic in the http kioslave ignores this header unless the server returns an http1.1 response. The attached patch moves the connection keep alive check out of this clause.... however, can anyone comment on this logic? What is the reason for having this set of header checks disabled for non http1.1 responses? Cheers, -- Ivor Hewitt. -------------- next part -------------- A non-text attachment was scrubbed... Name: keep-alive.diff Type: text/x-diff Size: 1530 bytes Desc: not available URL: From i_am_the_true_bugman at yahoo.com.au Thu Mar 2 08:00:28 2006 From: i_am_the_true_bugman at yahoo.com.au (Edward d'Auvergne) Date: Thu, 2 Mar 2006 19:00:28 +1100 Subject: File attribute preservation on copy as default request (especially for digital cameras!) Message-ID: <7f080ed10603020000u78ef722al@mail.gmail.com> I would like to request that when files are copied within konqueror that the file attributes, specifically the date and time of the file, are preserved. For certain operations such as copying photographs from digital cameras, files flash media, etc, this feature as a default would be greatly appreciated. While digital photographs have the date in the exif tag, movies generally do not have embedded dates. The feature would also be useful as you can see the true date of the images in file listings within Konqueror. An option when dragging and dropping files called 'Sync Here' under the normal 'Move Here', 'Copy Here', and 'Link Here' options, which replicates the copy operation but preserves the file date, would be a good replacement if preserving attributes on copy is considered a bad idea. Thanks, Edward From ismail at uludag.org.tr Thu Mar 2 09:01:33 2006 From: ismail at uludag.org.tr (Ismail Donmez) Date: Thu, 2 Mar 2006 11:01:33 +0200 Subject: File attribute preservation on copy as default request (especially for digital cameras!) In-Reply-To: <7f080ed10603020000u78ef722al@mail.gmail.com> References: <7f080ed10603020000u78ef722al@mail.gmail.com> Message-ID: <200603021102.06552.ismail@uludag.org.tr> Perşembe 2 Mart 2006 10:00 tarihinde, Edward d'Auvergne şunları yazmıştı: > I would like to request that when files are copied within konqueror > that the file attributes, specifically the date and time of the file, > are preserved. David Faure already fixed this on SVN some days ago so it will be in KDE 3.5.2 and KDE4. /ismail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From tobias at ke.informatik.tu-darmstadt.de Thu Mar 2 08:51:37 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Thu, 2 Mar 2006 09:51:37 +0100 Subject: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603011725.05988.faure@kde.org> References: <200603011725.05988.faure@kde.org> Message-ID: <007901c63dd6$96b667b0$1601a8c0@Terroristencamp> > On Wednesday 01 March 2006 16:59, Tobias Anton wrote: > > You could as well be of the opinion that ctrl is just a > key as every other and should be treated as such. > > Yeah let's redefine the meaning of keyboard keys ;-)))) > Sorry, but this makes no sense to me. > Alt, Shift and Ctrl are modifiers, and have always been. >From a user's perspective, there's nothing wrong with visualizing accesskeys when the modifier is active and neither with a sticky setting for the visualization. > > it became obvious that holding down ctrl while reading the accesskeys is > > very inconvenient. To keep that paradigm, yet removing the annoyance, a > > possible solution could thus be: > ... to use another key? ;) The reason why I intentionally avoided this proposal is to avoid disturbing users that have already adapted. > I don't think khtml should grab the keyboard when I press Ctrl > (since that would make Ctrl+F2 completely not-effective). Certainly. But is there another to get hold of at least one of the events between the Ctrl-down and Ctrl-up (i.e. one of F1-down, F1-up, F2-down, F2-up)? Cheers Tobias From tobias at ke.informatik.tu-darmstadt.de Thu Mar 2 08:51:38 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Thu, 2 Mar 2006 09:51:38 +0100 Subject: AW: making fallback access keys configurable In-Reply-To: <200603011247.52502.klingens@kde.org> References: <200603011247.52502.klingens@kde.org> Message-ID: <007a01c63dd6$974169a0$1601a8c0@Terroristencamp> So what sequence of events arrives at the currently focused window if the screensaver is shut off? Is it a single Ctrl release? -----Ursprüngliche Nachricht----- Von: Martijn Klingens [mailto:klingens at kde.org] Gesendet: Mittwoch, 1. März 2006 12:48 An: kfm-devel at kde.org Betreff: Re: making fallback access keys configurable On Wednesday 01 March 2006 11:34, David Faure wrote: > Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, > when I release Ctrl above the kmail reader window, I get the access keys > popping up. Very annoying. I do believe the shortcut should be changed, > because Ctrl is a modifier, not a key that is supposed to do something by > itself. The problem is not so much the ctrl-key itself, it's more the fact that KHTML responds to key-up rather than key-press. If my screen in blanked (screensaver) and I press ctrl to unblank I always end up with access keys in Kontact or Konq. That particular ctrl-press wasn't meant for Konq or Kontact and thus shouldn't be processed by it either. -- Martijn From tobias.anton at web.de Thu Mar 2 09:15:57 2006 From: tobias.anton at web.de (Tobias Anton) Date: Thu, 2 Mar 2006 10:15:57 +0100 Subject: load images delayed Message-ID: <007f01c63dd9$eaf30330$1601a8c0@Terroristencamp> Am Sonntag, 26. Februar 2006 21:40 schrieb Koos Vriezen: > On Fri, Feb 24, 2006 at 11:46:47PM +0100, Mikolaj Machowski wrote: > > Dnia piątek, 24 lutego 2006 15:44, Tobias Anton napisał: > > > Hello, > > > > > > attached is a patch that modifies KHTML's image loading behaviour: image > > > loading is deferred until the main document is loaded completely. It is > > > merely a proof-of-concept, designed for integration into conqueror > > > embedded and I don't aim at getting this very patch into the KDE > > > repository, but I'd like to have it reviewed and discussed. > > > > Didn't test it but it is interesting patch. Could be used in > > main branch - switch behaviour according to speed of > > connection (even on dial-up). If we only had a reliable way to determine the network speed... > An additional heuristic might be to also account for image sizes (could > be scaled of course). Eg. for smaller than 32x32+1, load them earlier. This patch minimizes the number of bytes read before the page is fully readable, what happens after that is less important. Anyway, I'm not sure whether that heuristics is desirable at all. I'd even say load images ordered by ascending distance to the current viewport's center... > > Though in KDE there is also the KIO cache .. It might be interesting to load images from the KIO cache in advance, right. Is there a function that indicates the caching status for a URL? Tobias -- Tobias Anton -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 1999 bytes Desc: not available URL: From klingens at kde.org Thu Mar 2 09:52:18 2006 From: klingens at kde.org (Martijn Klingens) Date: Thu, 2 Mar 2006 10:52:18 +0100 Subject: making fallback access keys configurable In-Reply-To: <007a01c63dd6$974169a0$1601a8c0@Terroristencamp> References: <007a01c63dd6$974169a0$1601a8c0@Terroristencamp> Message-ID: <200603021052.19036.klingens@kde.org> On Thursday 02 March 2006 09:51, Tobias Anton wrote: > So what sequence of events arrives at the currently focused window if the > screensaver is shut off? Is it a single Ctrl release? I guess so. I don't know the screensaver's internals, so if it decides to check for keypresses without actually eating them it might also get other events passing through, but that sounds unlikely. > -----Ursprüngliche Nachricht----- > Von: Martijn Klingens [mailto:klingens at kde.org] > Gesendet: Mittwoch, 1. März 2006 12:48 > An: kfm-devel at kde.org > Betreff: Re: making fallback access keys configurable > > On Wednesday 01 March 2006 11:34, David Faure wrote: > > Almost every time I use Ctrl+F2 Ctrl+F1 to switch desktops and back, > > when I release Ctrl above the kmail reader window, I get the access keys > > popping up. Very annoying. I do believe the shortcut should be changed, > > because Ctrl is a modifier, not a key that is supposed to do something by > > itself. > > The problem is not so much the ctrl-key itself, it's more the fact that > KHTML > responds to key-up rather than key-press. > > If my screen in blanked (screensaver) and I press ctrl to unblank I always > end > up with access keys in Kontact or Konq. That particular ctrl-press wasn't > meant for Konq or Kontact and thus shouldn't be processed by it either. -- Martijn From faure at kde.org Thu Mar 2 10:16:16 2006 From: faure at kde.org (David Faure) Date: Thu, 2 Mar 2006 11:16:16 +0100 Subject: File attribute preservation on copy as default request (especially for digital cameras!) In-Reply-To: <7f080ed10603020000u78ef722al@mail.gmail.com> References: <7f080ed10603020000u78ef722al@mail.gmail.com> Message-ID: <200603021116.17166.faure@kde.org> On Thursday 02 March 2006 09:00, Edward d'Auvergne wrote: > I would like to request that when files are copied within konqueror > that the file attributes, specifically the date and time of the file, > are preserved. For certain operations such as copying photographs > from digital cameras, files flash media, etc, this feature as a > default would be greatly appreciated. As Ismail said I just fixed this for directories and for file:<->system: and it will now be possible to fix it for other protocols, but it should already work for file: -> file: copies. Which protocols were you using to make those copies? -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From faure at kde.org Thu Mar 2 10:19:08 2006 From: faure at kde.org (David Faure) Date: Thu, 2 Mar 2006 11:19:08 +0100 Subject: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <007901c63dd6$96b667b0$1601a8c0@Terroristencamp> References: <007901c63dd6$96b667b0$1601a8c0@Terroristencamp> Message-ID: <200603021119.08434.faure@kde.org> On Thursday 02 March 2006 09:51, Tobias Anton wrote: > > > On Wednesday 01 March 2006 16:59, Tobias Anton wrote: > > > You could as well be of the opinion that ctrl is just a > > key as every other and should be treated as such. > > > > Yeah let's redefine the meaning of keyboard keys ;-)))) > > Sorry, but this makes no sense to me. > > Alt, Shift and Ctrl are modifiers, and have always been. > > > >From a user's perspective, there's nothing wrong with visualizing accesskeys > when the modifier is active and neither with a sticky setting for the > visualization. I would agree, *if* the only purpose for pressing Ctrl was to activate accesskeys. Just like Alt press+release activates the menu, because Alt is only used for menu accelerators. But that's not the case with Ctrl! When I press Ctrl it could be for any number of reasons, not necessarily to activate access keys. > > > it became obvious that holding down ctrl while reading the accesskeys is > > > very inconvenient. To keep that paradigm, yet removing the annoyance, a > > > possible solution could thus be: > > ... to use another key? ;) > > The reason why I intentionally avoided this proposal is to avoid disturbing > users that have already adapted. If they learned a shortcut they can learn another one - one that doesn't get in the way of everyone else... > > I don't think khtml should grab the keyboard when I press Ctrl > > (since that would make Ctrl+F2 completely not-effective). > > Certainly. But is there another to get hold of at least one of the events > between the Ctrl-down and Ctrl-up (i.e. one of F1-down, F1-up, F2-down, > F2-up)? Not that I know of. The window manager gets those events, not your application. Well you get a windowDeactivated event, but this is all a special case, there are tons of other things that people can do with Ctrl+something. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From mikelima at cirulla.net Thu Mar 2 10:29:26 2006 From: mikelima at cirulla.net (Luciano Montanaro) Date: Thu, 2 Mar 2006 11:29:26 +0100 Subject: Alt? In-Reply-To: <200603021119.08434.faure@kde.org> References: <007901c63dd6$96b667b0$1601a8c0@Terroristencamp> <200603021119.08434.faure@kde.org> Message-ID: <200603021129.26414.mikelima@cirulla.net> On Thursday 02 March 2006 11:19, David Faure wrote: > Just like Alt press+release activates the menu, because Alt > is only used for menu accelerators. Uh? Does it really?... It does not work here for me - maybe it's due to my "top-level" menu settings? Actually, I've just found pressing alt works on the pc across the desk on the computer of one of my colleagues. Luciano -- Luciano Montanaro // \\ // \x/ www.cirulla.net From tobias at ke.informatik.tu-darmstadt.de Thu Mar 2 11:52:41 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Thu, 2 Mar 2006 12:52:41 +0100 Subject: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603011053.14258.aseigo@kde.org> References: <200603011053.14258.aseigo@kde.org> Message-ID: <00a701c63def$cf683930$1601a8c0@Terroristencamp> > which would break CTRL+Key_O == open. Indeed, this kind of argument will hold for whatever modifier we assign to the fallback accesskeys. But it can only be avoided by assigning a higher priority to the menubar's actions and further by avoiding to use existing shortcuts as fallback accesskeys. Is this possible at all, i.e. can we determine whether a given shortcut is available? > and having "other UI events" change the state of an > explicitly requested mode on a user is generally very > frustrating for users due to "loss of control". Right. Only when pressing ctrl and releasing it _immediately_ afterwards, the mode should be entered. The idea of using the absence of other UI events to detect immediacy still seems valid to me. Any check less strict would potentially lead to annoyances again. From tobias at ke.informatik.tu-darmstadt.de Thu Mar 2 11:52:09 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Thu, 2 Mar 2006 12:52:09 +0100 Subject: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603021119.08434.faure@kde.org> References: <200603021119.08434.faure@kde.org> Message-ID: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> > When I press Ctrl it could be for any number of reasons, > not necessarily to activate access keys. This is reflected by my proposal. > If they learned a shortcut they can learn another one - Wrong answer. If they learned a shortcut they will most probably refuse to learn another but rather switch the desktop system. Unnecessary removal of established usage patterns is plain poor software quality. Ever heard of the "fragility of user trust"? > one that doesn't get in the way of everyone else... The functionality need not get in the way of anyone. We could reach a state of unintrusiveness without changing the modifier, but you don't seem to believe that. Why don't you? Which other modifier would you propose? There are only 8 combinations of three modifiers, all of which are in use at my machine. > Well you get a windowDeactivated event, but this is all a special case, > there are tons of other things that people can do with Ctrl+something. Just as every case is and just as they can do with every other key combination. It is a perfectly clean solution to enter the accesskeys mode as a reaction to ctrl being pressed as a key*, as long as the KHTMLView is focused and unless the fallback accesskeys supersede any application-specific shortcuts. Long ago, I had a similar discussion when I wanted to use Ctrl+Tab in KHTML, which was not possible then because it collided with non-configurable key bindings of KWin. The argument was: "The keyboard combination is taken, we can't simply reassign it". Now exactly this argument holds here, too, and I don't understand why you don't second this if your annoyance is taken care of. In a perfect world, eve Tobias *= in contrast to "as a modifier", which can be detected by the immediacy of ctrl-press and -release From l.lunak at suse.cz Thu Mar 2 12:45:00 2006 From: l.lunak at suse.cz (Lubos Lunak) Date: Thu, 2 Mar 2006 13:45:00 +0100 Subject: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> Message-ID: <200603021345.00371.l.lunak@suse.cz> On Thursday 02 March 2006 12:52, Tobias Anton wrote: > > When I press Ctrl it could be for any number of reasons, > > not necessarily to activate access keys. > > This is reflected by my proposal. > > > If they learned a shortcut they can learn another one - > > Wrong answer. If they learned a shortcut they will most probably refuse to > learn another but rather switch the desktop system. Unnecessary removal of > established usage patterns is plain poor software quality. Ever heard of > the "fragility of user trust"? Yeah, switching one desktop environment is certainly simpler than switching one shortcut. Since we've done this already several times in the past one kinda has to wonder how come we still have users. > > one that doesn't get in the way of everyone else... > > The functionality need not get in the way of anyone. We could reach a state > of unintrusiveness without changing the modifier, but you don't seem to > believe that. Why don't you? Which other modifier would you propose? There > are only 8 combinations of three modifiers, all of which are in use at my > machine. No other modifier. Modifiers are so often used keys that using them for something else than just being modifiers is asking for trouble. I'm quite sure we have some some bugreports about the Alt-alone-activates-menubar feature (I'm so glad it doesn't work with standalone menubar for some reason so it doesn't get in my way), and don't get me started on the Win-key-alone-activates-KMenu feature. > > Well you get a windowDeactivated event, but this is all a special case, > > there are tons of other things that people can do with Ctrl+something. > > Just as every case is and just as they can do with every other key > combination. Not true. If F12 is assigned to mean "activate accesskeys" in Konqueror, then the only single thing people can do with F12 in Konqueror is to activate accesskeys. > > It is a perfectly clean solution to enter the accesskeys mode as a reaction > to ctrl being pressed as a key*, as long as the KHTMLView is focused and > unless the fallback accesskeys supersede any application-specific > shortcuts. > > Long ago, I had a similar discussion when I wanted to use Ctrl+Tab in > KHTML, which was not possible then because it collided with > non-configurable key bindings of KWin. The argument was: "The keyboard > combination is taken, we can't simply reassign it". Now exactly this > argument holds here, too, and I don't understand why you don't second this > if your annoyance is taken care of. s/non-configurable/default/ . And I silently removed Ctrl+Tab from KWin's defaults some time ago and it seems nobody has noticed (or complained, at least). So much for never changing shortcuts. Removing Ctrl+Tab from KWin's defaults has more benefits that loses and IMHO that's also the case of the Ctrl alone shortcut for accesskeys. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ From klingens at kde.org Thu Mar 2 14:12:19 2006 From: klingens at kde.org (Martijn Klingens) Date: Thu, 2 Mar 2006 15:12:19 +0100 Subject: KWin key bindings (Re: making fallback access keys configurable) In-Reply-To: <200603021345.00371.l.lunak@suse.cz> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> <200603021345.00371.l.lunak@suse.cz> Message-ID: <200603021512.19531.klingens@kde.org> On Thursday 02 March 2006 13:45, Lubos Lunak wrote: > and don't get me started on the Win-key-alone-activates-KMenu feature. Well, the alternative that you introduced (meta-menu) has never worked for me though. Likewise meta-scroll lock for locking the desktop has never worked. Eventually I assigned alt-f1 to the KMenu one and borrowed meta-l from Windows for desktop locking. Until I reinstalled my laptop a couple of weeks ago I thought it to be my setup, but now I still have the problem, so I should probably report a bug on that. > s/non-configurable/default/ . And I silently removed Ctrl+Tab from KWin's > defaults some time ago and it seems nobody has noticed (or complained, at > least). So much for never changing shortcuts. Removing Ctrl+Tab from KWin's > defaults has more benefits that loses and IMHO that's also the case of the > Ctrl alone shortcut for accesskeys. What's the equivalent of ctrl-tab in the 4-modified keyboard scheme? meta-tab used to cycle through all desktops (show a popup like alt-tab does too) and still does here at work with KDE 3.4. With KDE 3.5 at home I can't for the life of me get that behaviour back. The kcontrol module has a couple of actions regarding desktop switching, but none I tried seem to be the good old KDE 3.4-version. -- Martijn From aseigo at kde.org Thu Mar 2 14:33:04 2006 From: aseigo at kde.org (Aaron J. Seigo) Date: Thu, 2 Mar 2006 07:33:04 -0700 Subject: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> Message-ID: <200603020733.05082.aseigo@kde.org> On Thursday 02 March 2006 04:52, Tobias Anton wrote: > Wrong answer. If they learned a shortcut they will most probably refuse to > learn another but rather switch the desktop system. Unnecessary removal of versus the people who switch or, worse, never use our software because the current state usability. =) -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tobias at ke.informatik.tu-darmstadt.de Thu Mar 2 15:17:38 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Thu, 2 Mar 2006 16:17:38 +0100 Subject: AW: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603021345.00371.l.lunak@suse.cz> References: <200603021345.00371.l.lunak@suse.cz> Message-ID: <00c201c63e0c$832c5c50$1601a8c0@Terroristencamp> > Yeah, switching one desktop environment is certainly > simpler than switching one shortcut. Unless you are willing to take the time browsing the millions of config options of KControl each time you updated KDE, the Windows CD might be nearer at hand than the official KDE's user interface design guide. Those changes that go into a few releases and are removed again later are especially unwelcome in corporate environments, where for example many people work with the same preinstalled configuration. Let a person-hour cost 50$, then a KDE update on an installtion for 100 people can quickly cost as much as 15.000$, if the people complain for one hour, dig KControl for another and finally get curious and start playing with screensaver settings for yet another hour, only because a default setting was changed without notice. If this happens two or three times, the company will perhaps decide to stop updating KDE or even switching to a more settled desktop environment, i.e. where the expected rate of backward-incompatible behavioural changes is lower. For example in Windows, most user interface concepts exist unmodified since 1995, and if one was changed, it was always done in a backward-compatible manner. > Since we've done this already several times in the past one > kinda has to wonder how come we still have users. Maybe we haven't been bold enough up to now. And, do you know how many users we actually did lose because of that? > No other modifier. Modifiers are so often used keys that using them > for something else than just being modifiers is asking for trouble. Come on. I have made a specific proposal. Your argument, however, involves just a general rule of thumb that IMO is not even applicable here. Please be precise: What problems do you see if the implementation would allow to use the system as described? How would you do it and why would it be better? Tobias From l.savernik at aon.at Thu Mar 2 17:12:06 2006 From: l.savernik at aon.at (Leo Savernik) Date: Thu, 2 Mar 2006 18:12:06 +0100 Subject: load images delayed In-Reply-To: <007f01c63dd9$eaf30330$1601a8c0@Terroristencamp> References: <007f01c63dd9$eaf30330$1601a8c0@Terroristencamp> Message-ID: <200603021812.07476.l.savernik@aon.at> Am Donnerstag, 2. März 2006 10:15 schrieb Tobias Anton: > This patch minimizes the number of bytes read before the > page is fully readable, what happens after that is less important. Doesn't http-pipelining achieve the very same effect for free? Though I don't know whether http-pipelining (a) does work at all, (b) is properly supported by enough servers to make a difference. mfg Leo From l.lunak at suse.cz Thu Mar 2 17:12:38 2006 From: l.lunak at suse.cz (Lubos Lunak) Date: Thu, 2 Mar 2006 18:12:38 +0100 Subject: KWin key bindings (Re: making fallback access keys configurable) In-Reply-To: <200603021512.19531.klingens@kde.org> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> <200603021345.00371.l.lunak@suse.cz> <200603021512.19531.klingens@kde.org> Message-ID: <200603021812.38545.l.lunak@suse.cz> On Thursday 02 March 2006 15:12, Martijn Klingens wrote: > On Thursday 02 March 2006 13:45, Lubos Lunak wrote: > > and don't get me started on the Win-key-alone-activates-KMenu feature. > > Well, the alternative that you introduced (meta-menu) has never worked for > me though. Likewise meta-scroll lock for locking the desktop has never > worked. Eventually I assigned alt-f1 to the KMenu one and borrowed meta-l > from Windows for desktop locking. No idea what you're talking about. Maybe the yet another bug in the KAccel stuff. > > s/non-configurable/default/ . And I silently removed Ctrl+Tab from > > KWin's defaults some time ago and it seems nobody has noticed (or > > complained, at least). So much for never changing shortcuts. Removing > > Ctrl+Tab from KWin's defaults has more benefits that loses and IMHO > > that's also the case of the Ctrl alone shortcut for accesskeys. > > What's the equivalent of ctrl-tab in the 4-modified keyboard scheme? > meta-tab used to cycle through all desktops (show a popup like alt-tab does > too) and still does here at work with KDE 3.4. With KDE 3.5 at home I can't > for the life of me get that behaviour back. The kcontrol module has a > couple of actions regarding desktop switching, but none I tried seem to be > the good old KDE 3.4-version. The only thing I can remember WRT changing shortcuts was dumping Ctrl+Tab from the default 3-modifiers scheme. -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ From l.lunak at suse.cz Thu Mar 2 17:36:18 2006 From: l.lunak at suse.cz (Lubos Lunak) Date: Thu, 2 Mar 2006 18:36:18 +0100 Subject: AW: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <00c201c63e0c$832c5c50$1601a8c0@Terroristencamp> References: <00c201c63e0c$832c5c50$1601a8c0@Terroristencamp> Message-ID: <200603021836.19039.l.lunak@suse.cz> On Thursday 02 March 2006 16:17, Tobias Anton wrote: > > Yeah, switching one desktop environment is certainly > > simpler than switching one shortcut. > > Unless you are willing to take the time browsing the millions of config > options of KControl each time you updated KDE, the Windows CD might be > nearer at hand than the official KDE's user interface design guide. > > Those changes that go into a few releases and are removed again later are > especially unwelcome in corporate environments, where for example many > people work with the same preinstalled configuration. Let a person-hour > cost 50$, then a KDE update on an installtion for 100 people can quickly > cost as much as 15.000$, if the people complain for one hour, dig KControl > for another and finally get curious and start playing with screensaver > settings for yet another hour, only because a default setting was changed > without notice. > > If this happens two or three times, the company will perhaps decide to stop > updating KDE or even switching to a more settled desktop environment, i.e. > where the expected rate of backward-incompatible behavioural changes is > lower. For example in Windows, most user interface concepts exist > unmodified since 1995, and if one was changed, it was always done in a > backward-compatible manner. Right. So let's stop fixing KDE, that'll actually help us twice to be a true competitor to Windows. > > Since we've done this already several times in the past one > > kinda has to wonder how come we still have users. > > Maybe we haven't been bold enough up to now. And, do you know how many > users we actually did lose because of that? No. But I'd bet it was less then the number of people we lost because we left some things broken. Changing something that doesn't quite work to something that works better is called fixing. If something changes as a result of that then it's unfortunate but life sucks (life and especially backwards compatibility). > > No other modifier. Modifiers are so often used keys that using them > > for something else than just being modifiers is asking for trouble. > > Come on. I have made a specific proposal. Your argument, however, involves > just a general rule of thumb that IMO is not even applicable here. Please > be precise: What problems do you see if the implementation would allow to > use the system as described? How would you do it and why would it be > better? Reasons for sticking with Ctrl: - some people are used to it - easy to trigger - easy to discover - ... ? Reasons against sticking with Ctrl (and for using a normal shortcut): - way too easy to trigger - it probably can be made to really react only to Ctrl-down, Ctrl-up , but people often do even that without intention - have you never pressed Ctrl because it was a "safe" key to press or simply because you accidentally did? - way too easy to discover - follow your $15000 example, just use "I get these strange yellow things" as the complaint instead - inconsistent with everything else - do we use something like this anywhere else? Even the shift+arrows scrolling feature that when activated uses shift alone is triggered by "normal" shortcuts shift+up/down - needs additional code that has its own problems - e.g. #118740 - I have no idea how to fix that one with KHTML doing its own Ctrl handling Reasons against using a normal shortcut: - not as easy to discover - it seems to be kind of a poweruser feature anyway, and has anybody already complained about it being difficult in FF or IE? - some people are used to Ctrl - I wonder how many such people actually are there, also move a bit up for the poweruser argument - not as easy to trigger - not really - companies will lose $15000 - ... ? -- Lubos Lunak KDE developer --------------------------------------------------------------------- SuSE CR, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org Drahobejlova 27 tel: +420 2 9654 2373 190 00 Praha 9 fax: +420 2 9654 2374 Czech Republic http://www.suse.cz/ From faure at kde.org Thu Mar 2 18:45:52 2006 From: faure at kde.org (David Faure) Date: Thu, 2 Mar 2006 19:45:52 +0100 Subject: making fallback access keys configurable In-Reply-To: <200603021836.19039.l.lunak@suse.cz> References: <00c201c63e0c$832c5c50$1601a8c0@Terroristencamp> <200603021836.19039.l.lunak@suse.cz> Message-ID: <200603021945.53129.faure@kde.org> On Thursday 02 March 2006 18:36, Lubos Lunak wrote: > Reasons against sticking with Ctrl (and for using a normal shortcut): [...] > Reasons against using a normal shortcut: [...] Thanks Lubos. I completely agree. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From ivor at ivor.org Thu Mar 2 19:36:21 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Thu, 2 Mar 2006 19:36:21 +0000 Subject: connection keep-alive In-Reply-To: <200603020810.03637.ivor@ivor.org> References: <200603020810.03637.ivor@ivor.org> Message-ID: <200603021936.22238.ivor@ivor.org> On Thursday 02 March 2006 08:10, Ivor Hewitt wrote: > > The attached patch moves the connection keep alive check out of this > clause.... however, can anyone comment on this logic? What is the reason > for having this set of header checks disabled for non http1.1 responses? > According to RFC2068 the connection keep-alive token is permitted in an http1.0 header. If no-one can recall why this response was disallowed for a 1.0 header then I'll commit moving it out of the check. Regards, -- Ivor Hewitt. From klingens at kde.org Thu Mar 2 19:48:17 2006 From: klingens at kde.org (Martijn Klingens) Date: Thu, 2 Mar 2006 20:48:17 +0100 Subject: KWin key bindings (Re: making fallback access keys configurable) In-Reply-To: <200603021812.38545.l.lunak@suse.cz> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> <200603021512.19531.klingens@kde.org> <200603021812.38545.l.lunak@suse.cz> Message-ID: <200603022048.18554.klingens@kde.org> I have to withdraw this. Both issues are broken at work on Suse 9.2, and they used to be broken on my laptop when it was still running 9.1. Seems like my upgrade to Suse 10 two weeks ago fixed these issues, sorry for crying wolf :/ Martijn On Thursday 02 March 2006 18:12, Lubos Lunak wrote: > On Thursday 02 March 2006 15:12, Martijn Klingens wrote: > > On Thursday 02 March 2006 13:45, Lubos Lunak wrote: > > > and don't get me started on the Win-key-alone-activates-KMenu feature. > > > > Well, the alternative that you introduced (meta-menu) has never worked > > for me though. Likewise meta-scroll lock for locking the desktop has > > never worked. Eventually I assigned alt-f1 to the KMenu one and borrowed > > meta-l from Windows for desktop locking. > > No idea what you're talking about. Maybe the yet another bug in the KAccel > stuff. > > > > s/non-configurable/default/ . And I silently removed Ctrl+Tab from > > > KWin's defaults some time ago and it seems nobody has noticed (or > > > complained, at least). So much for never changing shortcuts. Removing > > > Ctrl+Tab from KWin's defaults has more benefits that loses and IMHO > > > that's also the case of the Ctrl alone shortcut for accesskeys. > > > > What's the equivalent of ctrl-tab in the 4-modified keyboard scheme? > > meta-tab used to cycle through all desktops (show a popup like alt-tab > > does too) and still does here at work with KDE 3.4. With KDE 3.5 at home > > I can't for the life of me get that behaviour back. The kcontrol module > > has a couple of actions regarding desktop switching, but none I tried > > seem to be the good old KDE 3.4-version. > > The only thing I can remember WRT changing shortcuts was dumping Ctrl+Tab > from the default 3-modifiers scheme. From klingens at kde.org Thu Mar 2 19:55:25 2006 From: klingens at kde.org (Martijn Klingens) Date: Thu, 2 Mar 2006 20:55:25 +0100 Subject: connection keep-alive In-Reply-To: <200603021936.22238.ivor@ivor.org> References: <200603020810.03637.ivor@ivor.org> <200603021936.22238.ivor@ivor.org> Message-ID: <200603022055.25519.klingens@kde.org> On Thursday 02 March 2006 20:36, Ivor Hewitt wrote: > On Thursday 02 March 2006 08:10, Ivor Hewitt wrote: > > The attached patch moves the connection keep alive check out of this > > clause.... however, can anyone comment on this logic? What is the reason > > for having this set of header checks disabled for non http1.1 responses? > > According to RFC2068 the connection keep-alive token is permitted in an > http1.0 header. If no-one can recall why this response was disallowed for a > 1.0 header then I'll commit moving it out of the check. I looked up the thread on NTLM proxies I started at the end of December, which is also about Connection: headers, but that seems to be at the client's end, not at the server. You may want to reread it to double-check though. Apart from that, Dawit Alemayehu is the kio-http guru, and he's in the US timezone, give him at least 24 hours to respond, and even that is quite fast. 48 hours might be more polite. -- Martijn From charles at kde.org Thu Mar 2 20:43:34 2006 From: charles at kde.org (Charles Samuels) Date: Thu, 2 Mar 2006 20:43:34 +0000 Subject: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603020733.05082.aseigo@kde.org> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> <200603020733.05082.aseigo@kde.org> Message-ID: <200603022043.35226.charles@kde.org> Aaron J. Seigo wrote, on Thursday 2006 March 02 2:33 pm: > On Thursday 02 March 2006 04:52, Tobias Anton wrote: > > Wrong answer. If they learned a shortcut they will most probably refuse > > to learn another but rather switch the desktop system. Unnecessary > > removal of > > versus the people who switch or, worse, never use our software because the > current state usability. =) We've removed plenty of little things users have gotten used to that don't affect usability. This one definitely does, so where does the sudden refusal to do something about it come from? How many people actually use access keys in konqueror anyway? I certainly never have. Except by accident. cs P.S., Tobias Anton uses outlook. I propose a witchhunt. :) From aseigo at kde.org Thu Mar 2 21:33:05 2006 From: aseigo at kde.org (Aaron J. Seigo) Date: Thu, 2 Mar 2006 14:33:05 -0700 Subject: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603022043.35226.charles@kde.org> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> <200603020733.05082.aseigo@kde.org> <200603022043.35226.charles@kde.org> Message-ID: <200603021433.05939.aseigo@kde.org> On Thursday 02 March 2006 13:43, Charles Samuels wrote: > refusal to do something about it come from? it happens to me whenever i infringe upon someone's pet behaviour. which is, given the range of people's taste, just about everything i end up changing in the UI. ;) i completely understand where it comes from; i wish i knew how to move us beyond this knee-jerk stop-energy thing we do. it really hurts the software. > P.S., Tobias Anton uses outlook. I propose a witchhunt. :) heh. i really ought to hack my kmail someday to support "user agents" so i can switch on the fly to piss people off randomly. "what the fuck?! aseigo uses Mail.app?!" ;) -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivor at ivor.org Thu Mar 2 22:15:25 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Thu, 2 Mar 2006 22:15:25 +0000 Subject: making fallback access keys configurable In-Reply-To: <200602271500.03532.aseigo@kde.org> References: <200602271500.03532.aseigo@kde.org> Message-ID: <200603022215.26402.ivor@ivor.org> On Monday 27 February 2006 22:00, Aaron J. Seigo wrote: > hi all... > > i'm sure you've hit CTRL in konqi and seen the billion access keys popup up > all over the page. better yet is when it happens in kmail ;) > > attached is a patch that disables fallback keys by default, but makes them > configurable. i'd like to commit this for 3.5.2 as well as to trunk/ > > in future i think it would make sense to add this into the accessibility > world of kde much as we do with slow keys, etc .... An alternative idea to make the feature less annoying attached... This makes the activation of access keys require a double control tap. The logic is that if you find access keys annoying you'll now be pleased that when you tap control you don't get a post-it blizzard. On the other hand if you wanted the access keys to appear your reaction to them not appearing would be to tap the key a few times. (although I think having an option to completely disable the feature is also required). Cheers, tap. tap tap. tap. -- Ivor Hewitt. -------------- next part -------------- A non-text attachment was scrubbed... Name: accesskeys-tappety-tap-tap.diff Type: text/x-diff Size: 1785 bytes Desc: not available URL: From ogoffart at kde.org Thu Mar 2 22:31:01 2006 From: ogoffart at kde.org (Olivier Goffart) Date: Thu, 2 Mar 2006 23:31:01 +0100 Subject: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603021119.08434.faure@kde.org> References: <007901c63dd6$96b667b0$1601a8c0@Terroristencamp> <200603021119.08434.faure@kde.org> Message-ID: <200603022331.07078.ogoffart@kde.org> Le Jeudi 2 Mars 2006 11:19, David Faure a écrit : > On Thursday 02 March 2006 09:51, Tobias Anton wrote: > I would agree, *if* the only purpose for pressing Ctrl was to activate > accesskeys. Just like Alt press+release activates the menu, because Alt is > only used for menu accelerators. But that's not the case with Ctrl! When I > press Ctrl it could be for any number of reasons, not necessarily to > activate access keys. Back to the source: (why the ctrl key has been used) https://bugs.kde.org/show_bug.cgi?id=83053 comments 4,8,9,10 In summary, it has been suggested to first use a normal key, but it has been judged counter-intuitive. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From maksim at kde.org Thu Mar 2 22:38:49 2006 From: maksim at kde.org (Maks Orlovich) Date: Thu, 2 Mar 2006 17:38:49 -0500 Subject: AW: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603021836.19039.l.lunak@suse.cz> References: <00c201c63e0c$832c5c50$1601a8c0@Terroristencamp> <200603021836.19039.l.lunak@suse.cz> Message-ID: <200603021738.49399.maksim@kde.org> > - not as easy to discover - it seems to be kind of a poweruser feature > anyway, and has anybody already complained about it being difficult in FF > or IE? Hmm. I would like to say that hard-to-discover shortcuts are a general problem we have (especially for non-normal shortcuts, such as modifier keys, etc.), but I don't actually have anything to offer in terms of a solution. Should I CC usability people and pray they can come up with something clever for 4.0'ish? ;-) -Maks From charles at kde.org Thu Mar 2 22:35:49 2006 From: charles at kde.org (Charles Samuels) Date: Thu, 2 Mar 2006 22:35:49 +0000 Subject: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603021433.05939.aseigo@kde.org> References: <00a601c63def$cee65f00$1601a8c0@Terroristencamp> <200603022043.35226.charles@kde.org> <200603021433.05939.aseigo@kde.org> Message-ID: <200603022235.52747.charles@kde.org> Aaron J. Seigo wrote, on Thursday 2006 March 02 9:33 pm: > On Thursday 02 March 2006 13:43, Charles Samuels wrote: > > refusal to do something about it come from? > > it happens to me whenever i infringe upon someone's pet behaviour. which > is, given the range of people's taste, just about everything i end up > changing in the UI. ;) i completely understand where it comes from; i wish > i knew how to move us beyond this knee-jerk stop-energy thing we do. it > really hurts the software. Well, there's a point on changing someone's pet behavior. I agree that's not a good thing. But I think we mostly agree that using ctrl to bring up a bunch of annoying little yellow things just plain poor behavior. We should find a compromise. Perhaps a good one is to make the yellow things only visible while ctrl is being held down? > > > P.S., Tobias Anton uses outlook. I propose a witchhunt. :) > > heh. i really ought to hack my kmail someday to support "user agents" so i > can switch on the fly to piss people off randomly. "what the fuck?! aseigo > uses Mail.app?!" ;) They'd still be able to tell that you use KMail because all of your emails conform to standards and don't do really annoying things... like adding a million "AW"s to the subject line, Tobias. ;) cs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From mueller at kde.org Fri Mar 3 09:23:30 2006 From: mueller at kde.org (Dirk Mueller) Date: Fri, 3 Mar 2006 10:23:30 +0100 Subject: kdom and khtml integration In-Reply-To: <20060226232159.GA50130@xs4all.nl> References: <20060226232159.GA50130@xs4all.nl> Message-ID: <200603031023.31389.mueller@kde.org> On Monday, 27. February 2006 00:21, Rob Buis wrote: > 1. Split up to more files, like kdom/ksvg & WebCore does, > for example dom_nodeimpl.h -> NodeImpl.h. AKA the C++ disease ;) > 2. Consider merging webkit datastructures like AtomicString/QualifiedName > and ElementFactory. This is optional ofcourse, however we have good > experiences with this functionality in kdom. Yes, I agree with that. > 7. Consider renaming khtml to kxml, to reflect the improved xml > capabilities. Then we can as well go with "webkit" as a name ;) Honestly, I fail to see which problems you saw with the modularisation? Perhaps then it would be easier to decide. Right now I don't think that "avoiding a couple more virtual functions" would be a ground you base the start of spaghetti code (see Safari) on. -- Dirk//\ From ojschmidt at kde.org Fri Mar 3 10:16:35 2006 From: ojschmidt at kde.org (Olaf Jan Schmidt) Date: Fri, 3 Mar 2006 11:16:35 +0100 Subject: making fallback access keys configurable In-Reply-To: <200602281143.58202.l.lunak@suse.cz> References: <200602271500.03532.aseigo@kde.org> <200602281143.58202.l.lunak@suse.cz> Message-ID: <200603031116.36063.ojschmidt@kde.org> Hi! We are currently repeating a discussion we had on the kde-hci list close before the release of KDE 3.5. I will summarise the outcome: * The accesskey feature itself cannot be removed or turned into a hidden configuration option without breaking the string freeze (the "HTML 4.01 built-in" would have to be changed to "HTML 4.01 partially supported"). * The fallback keys are a very nice accessibility feature, even if the accessibility team did not request it. When we discussed this last, I consented to removing it before the 3.5 release if the usability team suggests so. They did not have a consensus on it. I don't think it is a good idea to silently remove or hide it now in a minor release after users have got used to it. * Requiring the user to press the Ctrl key twice, or to hold down the key for a longer time, would clash with the accessibility keyboard settings. This is especially true if combined with a timeout. Remember that severely impaired users are among those who use accesskeys, and they are typically much slower in handling the keyboard. * To avoid usability problems, it would be best to replace Ctrl with some other shortcut, e.g. F8. It is easy to make this change for KDE4, when we will address the keyboard navigation in KDE altogether. * Changing the shortcut within in a minor release or a dot release only makes sense if we find a way to make accesskey users aware of the change. The usability team found no solution for this when we discussed it last time. * It seems that the resistance to the accesskeys partly comes from some bugs in the implementation that I personally have difficulties reproducing. I also don't want to take maintainership for every accessibility-related feature or bug in KDE. I am already short of time writing proper accessibility guidelines for developers, which makes more sense long-term than trying to fix accessibility problems myself while other developers open new ones all the time. Olaf -- Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards accessibility networker, Protestant theology student and webmaster of http://accessibility.kde.org/ and http://www.amen-online.de/ From Bill.Haneman at Sun.COM Fri Mar 3 10:43:19 2006 From: Bill.Haneman at Sun.COM (Bill Haneman) Date: Fri, 03 Mar 2006 10:43:19 +0000 Subject: making fallback access keys configurable In-Reply-To: <200603031116.36063.ojschmidt@kde.org> References: <200602271500.03532.aseigo@kde.org> <200602281143.58202.l.lunak@suse.cz> <200603031116.36063.ojschmidt@kde.org> Message-ID: <1141382599.7571.9.camel@linux.site> Hi Olaf/All: Having worked on keyboard navigation issues for Gnome, mozilla, etc. for the past 5 years, I agree with your points, except for the suggestion about F8. Using function keys as modifiers is a very bad idea, and poor from an accessibility standpoint. A 'standard' modifier should be used, consistent with the rest of the desktop. I would suggest 'Alt' except for the fact that it would clash with menu keynav. "Control" seems like the best of the available solutions, even if it is not ideal. Bill On Fri, 2006-03-03 at 10:16, Olaf Jan Schmidt wrote: > Hi! > > We are currently repeating a discussion we had on the kde-hci list close > before the release of KDE 3.5. > > I will summarise the outcome: > > * The accesskey feature itself cannot be removed or turned into a hidden > configuration option without breaking the string freeze (the "HTML 4.01 > built-in" would have to be changed to "HTML 4.01 partially supported"). > > * The fallback keys are a very nice accessibility feature, even if the > accessibility team did not request it. When we discussed this last, I > consented to removing it before the 3.5 release if the usability team > suggests so. They did not have a consensus on it. I don't think it is a good > idea to silently remove or hide it now in a minor release after users have > got used to it. > > * Requiring the user to press the Ctrl key twice, or to hold down the key for > a longer time, would clash with the accessibility keyboard settings. This is > especially true if combined with a timeout. Remember that severely impaired > users are among those who use accesskeys, and they are typically much slower > in handling the keyboard. > > * To avoid usability problems, it would be best to replace Ctrl with some > other shortcut, e.g. F8. It is easy to make this change for KDE4, when we > will address the keyboard navigation in KDE altogether. > > * Changing the shortcut within in a minor release or a dot release only makes > sense if we find a way to make accesskey users aware of the change. The > usability team found no solution for this when we discussed it last time. > > * It seems that the resistance to the accesskeys partly comes from some bugs > in the implementation that I personally have difficulties reproducing. I also > don't want to take maintainership for every accessibility-related feature or > bug in KDE. I am already short of time writing proper accessibility > guidelines for developers, which makes more sense long-term than trying to > fix accessibility problems myself while other developers open new ones all > the time. > > Olaf > > -- > Olaf Jan Schmidt, KDE Accessibility co-maintainer, open standards > accessibility networker, Protestant theology student and webmaster of > http://accessibility.kde.org/ and http://www.amen-online.de/ > _______________________________________________ > kde-accessibility mailing list > kde-accessibility at kde.org > https://mail.kde.org/mailman/listinfo/kde-accessibility From i_am_the_true_bugman at yahoo.com.au Fri Mar 3 03:49:25 2006 From: i_am_the_true_bugman at yahoo.com.au (Edward dAuvergne) Date: Fri, 3 Mar 2006 14:49:25 +1100 (EST) Subject: File attribute preservation on copy as default request (especially for digital cameras!) In-Reply-To: <200603021116.17166.faure@kde.org> References: <200603021116.17166.faure@kde.org> Message-ID: <20060303034925.30936.qmail@web90202.mail.scd.yahoo.com> David Faure wrote: On Thursday 02 March 2006 09:00, Edward d'Auvergne wrote: > I would like to request that when files are copied within konqueror > that the file attributes, specifically the date and time of the file, > are preserved. For certain operations such as copying photographs > from digital cameras, files flash media, etc, this feature as a > default would be greatly appreciated. As Ismail said I just fixed this for directories and for file:<->system: and it will now be possible to fix it for other protocols, but it should already work for file: -> file: copies. Which protocols were you using to make those copies? The issue comes from a few people I've introduced to GNU/Linux and are downloading from digital cameras and transferring files between machines using USB keys. I therefore don't exactly remember the protocols used. For the keys and an Olympus camera I think it's file: to file:, but for a Canon camera I think it is usb: to file: rather than camera: to file: (I could be wrong). --------------------------------- Do you Yahoo!? Find a local business fast with Yahoo! Local Search -------------- next part -------------- An HTML attachment was scrubbed... URL: From lie at eecg.toronto.edu Thu Mar 2 15:55:01 2006 From: lie at eecg.toronto.edu (David Lie) Date: Thu, 02 Mar 2006 10:55:01 -0500 Subject: Statically linked Konqueror Message-ID: <44071555.4040801@eecg.toronto.edu> Hello: I was wondering how one would build a completely statically linked version of konqueror that will run on Linux. I noticed there are ways to build a static konqueror for a palmtop environment, but I don't seem to be able to do the same for a standard UNIX environment. I'm not subscribed to the mailing list, so please send a copy to my e-mail address at lie at eecg.toronto.edu. Thanks. David From gunnar at schmi-dt.de Fri Mar 3 11:04:47 2006 From: gunnar at schmi-dt.de (Gunnar Schmi Dt) Date: Fri, 3 Mar 2006 12:04:47 +0100 Subject: making fallback access keys configurable In-Reply-To: <1141382599.7571.9.camel@linux.site> References: <200602271500.03532.aseigo@kde.org> <200603031116.36063.ojschmidt@kde.org> <1141382599.7571.9.camel@linux.site> Message-ID: <200603031204.55222.gunnar@schmi-dt.de> Hello Bill, On Friday 03 March 2006 11:43, Bill Haneman wrote: > Hi Olaf/All: > > Having worked on keyboard navigation issues for Gnome, mozilla, etc. for > the past 5 years, I agree with your points, except for the suggestion > about F8. Using function keys as modifiers is a very bad idea, and poor > from an accessibility standpoint. A 'standard' modifier should be used, > consistent with the rest of the desktop. > [...] To my knowledge are talking about a keyboard shortcut for turning on the access keys. Once they are turned on, you see the a number of tooltips which describe the keys you need to press in order to use one of the access keys. In other words, for activating the access key "a" you have to: 1. Press and release "Control" (possibly multiple times if sticky keys is enabled). After that, the tooltips are visible. 2. Type "a". The access key is activated and the tooltips disappear. If we switch to some other shortcut (let us say F8) you have to: 1. Type F8. After that, the tooltips are visible. 2. Type "a". The access key is activated and the tooltips disappear. Can you please explain why you would prefer to use a modifier key? Gunnar Schmi Dt -- Member of KDE's Technical Working Group Co-maintainer of the KDE Accessibility Project Maintainer of the kdeaccessibility package http://accessibility.kde.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ kde-accessibility mailing list kde-accessibility at kde.org https://mail.kde.org/mailman/listinfo/kde-accessibility From charles at kde.org Sat Mar 4 00:06:02 2006 From: charles at kde.org (Charles Samuels) Date: Sat, 4 Mar 2006 00:06:02 +0000 Subject: khtml/ecma/kjs_window Message-ID: <200603040006.09199.charles@kde.org> Is there any reason that in kjs_window.cpp the constructors for ScheduledAction are marked: // KDE 4: Make those parameters const ... & These aren't installed headers, so why wasn't that just done? thanks cs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tobias at ke.informatik.tu-darmstadt.de Fri Mar 3 11:39:26 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Fri, 3 Mar 2006 12:39:26 +0100 Subject: AW: AW: AW: AW: AW: AW: AW: making fallback access keys configurable In-Reply-To: <200603022043.35226.charles@kde.org> References: <200603022043.35226.charles@kde.org> Message-ID: <012a01c63eb7$3383a2c0$1601a8c0@Terroristencamp> Hey! I've been using KMail for a long time, until the IOSlave started dying on me during message transfer because KMail couldn't cope with one folder containing > 400.000 mails (which was kde-cvs and bugs-dist, btw.) and thus became too slow sorting in the incoming messages, resulting in the timeout. ATM I'm testing how many emails Outlook can take until it barfs ;-) Cheers Tobias -----Ursprüngliche Nachricht----- Von: Charles Samuels [mailto:charles at kde.org] Gesendet: Donnerstag, 2. Mلrz 2006 21:44 An: kfm-devel at kde.org Betreff: Re: AW: AW: AW: AW: AW: AW: making fallback access keys configurable Aaron J. Seigo wrote, on Thursday 2006 March 02 2:33 pm: > On Thursday 02 March 2006 04:52, Tobias Anton wrote: > > Wrong answer. If they learned a shortcut they will most probably refuse > > to learn another but rather switch the desktop system. Unnecessary > > removal of > > versus the people who switch or, worse, never use our software because the > current state usability. =) We've removed plenty of little things users have gotten used to that don't affect usability. This one definitely does, so where does the sudden refusal to do something about it come from? How many people actually use access keys in konqueror anyway? I certainly never have. Except by accident. cs P.S., Tobias Anton uses outlook. I propose a witchhunt. :) From tobias at ke.informatik.tu-darmstadt.de Fri Mar 3 11:39:26 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Fri, 3 Mar 2006 12:39:26 +0100 Subject: AW: load images delayed In-Reply-To: <200603021812.07476.l.savernik@aon.at> References: <200603021812.07476.l.savernik@aon.at> Message-ID: <012b01c63eb7$33ae8350$1601a8c0@Terroristencamp> Hi Leo, good question! If the client maintains only one simultaneous connection to one host, this will do, independently of whether pipelining or keep-alive are used. I also already had a look at the situation of pipelining. AFAIK and AFAICS pipelining is not supported by kio_http, a wishlist item with >130 votes. I already asked waldo how much work it would be but got no anwer until now. But also with pipelining, we'd have to use multiple simultaneous connections for the scenario described in coolo's posting (3MB html with important image content on top). I don't like this scenario altogether, but it seems I would have to account for that before committing a patch, so I stick with my version as a patch for konq-e, where large informative images inside extremely large html pages are not an issue anyway. Cheers Tobias -----Ursprüngliche Nachricht----- Von: Leo Savernik [mailto:l.savernik at aon.at] Gesendet: Donnerstag, 2. März 2006 18:12 An: kfm-devel at kde.org Betreff: Re: load images delayed Am Donnerstag, 2. März 2006 10:15 schrieb Tobias Anton: > This patch minimizes the number of bytes read before the > page is fully readable, what happens after that is less important. Doesn't http-pipelining achieve the very same effect for free? Though I don't know whether http-pipelining (a) does work at all, (b) is properly supported by enough servers to make a difference. mfg Leo From tobias at ke.informatik.tu-darmstadt.de Fri Mar 3 11:39:26 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Fri, 3 Mar 2006 12:39:26 +0100 Subject: Outlook sucks [Was: AW: AW: AW: AW: AW: AW: AW: making fallback access keys configurable] In-Reply-To: <200603022235.52747.charles@kde.org> References: <200603022235.52747.charles@kde.org> Message-ID: <012901c63eb7$334fc180$1601a8c0@Terroristencamp> > They'd still be able to tell that you use KMail > because all of your emails conform to standards > and don't do really annoying things... like adding > a million "AW"s to the subject line, Tobias. ;) Yeah, really very annoying :) KMail's notion of language sucks differently, though: http://anton.dnsalias.org/public/images/kmail-config.png Cheers Tobias From thiago at kde.org Fri Mar 3 11:42:45 2006 From: thiago at kde.org (Thiago Macieira) Date: Fri, 3 Mar 2006 12:42:45 +0100 Subject: Statically linked Konqueror In-Reply-To: <44071555.4040801@eecg.toronto.edu> References: <44071555.4040801@eecg.toronto.edu> Message-ID: <200603031242.46185.thiago@kde.org> David Lie wrote: >I was wondering how one would build a completely statically linked >version of konqueror You wouldn't. That's not possible. If you want to do that, you will have to hack the code yourself. Konq/e is a special version of Konqueror that is designed to work on embedded systems. The normal Konqueror version relies on being able to dynamically load KParts (which are ELF shared objects). And the KDE build system does not allow you to create statically-linked libraries either. >that will run on Linux. I noticed there are ways >to build a static konqueror for a palmtop environment, but I don't seem >to be able to do the same for a standard UNIX environment. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 3. Ac seo woruld wearð geborod, swá se Scieppend cwæð "Gewurde Unix" and wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From faure at kde.org Fri Mar 3 12:32:23 2006 From: faure at kde.org (David Faure) Date: Fri, 3 Mar 2006 13:32:23 +0100 Subject: Outlook sucks [Was: AW: AW: AW: AW: AW: AW: AW: making fallback access keys configurable] In-Reply-To: <012901c63eb7$334fc180$1601a8c0@Terroristencamp> References: <012901c63eb7$334fc180$1601a8c0@Terroristencamp> Message-ID: <200603031332.23659.faure@kde.org> On Friday 03 March 2006 12:39, Tobias Anton wrote: > > They'd still be able to tell that you use KMail > > because all of your emails conform to standards > > and don't do really annoying things... like adding > > a million "AW"s to the subject line, Tobias. ;) > > Yeah, really very annoying :) > KMail's notion of language sucks differently, though: > > http://anton.dnsalias.org/public/images/kmail-config.png This is advanced crypto configuration coming from (autogenerated from) gnupg; why would you care about it? In any case it's not in kmail's hands. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From Bill.Haneman at Sun.COM Fri Mar 3 13:35:32 2006 From: Bill.Haneman at Sun.COM (Bill Haneman) Date: Fri, 03 Mar 2006 13:35:32 +0000 Subject: making fallback access keys configurable In-Reply-To: References: <200602271500.03532.aseigo@kde.org> <200603031116.36063.ojschmidt@kde.org> <1141382599.7571.9.camel@linux.site> <200603031204.55222.gunnar@schmi-dt.de> Message-ID: <1141392932.7128.16.camel@linux.site> Will, I fully agree. To clarify my earlier comment, the reason I implied that F8 was being suggested as a "modifier" here is twofold. One, I assumed (perhaps wrongly) that in the absence of StickyKeys, the Control key (which is normally understood to be a modifier key) was resulting in the access keys appearing only while Control was pressed down. If the Control key is being used as a "toggle", i.e. "press/release" of control turns Access Keys on and off, then I would suggest that this violates the usual user expectation of how modifier keys like Control, Alt, and Shift work, and therefore is a dubious idea. If Control for access keys act in the normal "modifier" way, i.e. access keys were only displayed and active while Control is held down, then a Sticky Keys user can still use them; how many key presses it takes depends on the implementation details of AccessKeys. Careful implementation could ensure that StickyKeys users could make use of these keys with only two keystrokes (but perhaps that implementation-detail discussion should be taken offline; email me if you want to discuss). If on the other hand, you want Access Keys to be a "toggled state" for all users, using something other than a modifier key makes sense. The concern I would have about using something like F8 is that, as Will suggests, ease of reaching the keys has important accessibility implications. In such a case, it might be preferable to keep the toggled state on _after_ an access key has been pressed, to reduce the keystroke count required for users who make frequent use of such keys. But again, as Will says, we need to bring clinicians into this discussion, which probably means going outside the developer mailing lists :-) regards Bill On Fri, 2006-03-03 at 13:18, Willie Walker wrote: > I'm not sure I understand the overall goals here, but as one of the > original authors of the AccessX functionality, I'd like to offer the > suggestion that things such as this should be passed by the domain > experts (e.g., occupational therapists and actual users of the > technology) before being decided. > > For example, things like the shift key were chosen because of their > size and location on the keyboard (and later became useful because > of their global availability across multiple styles of keyboards, > including laptops). > > As for who can provide this domain expertise, I'd suggest Mark > Novak, who is another author of the AccessX functionality and one who > is well in-tune with the OT side of things. The end conclusion might > be the same, but at least we will be comforted that the decision > was made with the blessing of the domain experts. > > Will > > > On Mar 3, 2006, at 6:04 AM, Gunnar Schmi Dt wrote: > > > Hello Bill, > > > > On Friday 03 March 2006 11:43, Bill Haneman wrote: > >> Hi Olaf/All: > >> > >> Having worked on keyboard navigation issues for Gnome, mozilla, > >> etc. for > >> the past 5 years, I agree with your points, except for the suggestion > >> about F8. Using function keys as modifiers is a very bad idea, > >> and poor > >> from an accessibility standpoint. A 'standard' modifier should be > >> used, > >> consistent with the rest of the desktop. > >> [...] > > > > To my knowledge are talking about a keyboard shortcut for turning > > on the > > access keys. Once they are turned on, you see the a number of tooltips > > which describe the keys you need to press in order to use one of the > > access keys. > > > > In other words, for activating the access key "a" you have to: > > 1. Press and release "Control" (possibly multiple times if sticky > > keys is > > enabled). After that, the tooltips are visible. > > 2. Type "a". The access key is activated and the tooltips disappear. > > > > If we switch to some other shortcut (let us say F8) you have to: > > 1. Type F8. After that, the tooltips are visible. > > 2. Type "a". The access key is activated and the tooltips disappear. > > > > Can you please explain why you would prefer to use a modifier key? > > > > Gunnar Schmi Dt > > -- > > Member of KDE's Technical Working Group > > Co-maintainer of the KDE Accessibility Project > > Maintainer of the kdeaccessibility package > > http://accessibility.kde.org/ > > _______________________________________________ > > kde-accessibility mailing list > > kde-accessibility at kde.org > > https://mail.kde.org/mailman/listinfo/kde-accessibility > From William.Walker at Sun.COM Fri Mar 3 13:18:51 2006 From: William.Walker at Sun.COM (Willie Walker) Date: Fri, 03 Mar 2006 08:18:51 -0500 Subject: making fallback access keys configurable In-Reply-To: <200603031204.55222.gunnar@schmi-dt.de> References: <200602271500.03532.aseigo@kde.org> <200603031116.36063.ojschmidt@kde.org> <1141382599.7571.9.camel@linux.site> <200603031204.55222.gunnar@schmi-dt.de> Message-ID: I'm not sure I understand the overall goals here, but as one of the original authors of the AccessX functionality, I'd like to offer the suggestion that things such as this should be passed by the domain experts (e.g., occupational therapists and actual users of the technology) before being decided. For example, things like the shift key were chosen because of their size and location on the keyboard (and later became useful because of their global availability across multiple styles of keyboards, including laptops). As for who can provide this domain expertise, I'd suggest Mark Novak, who is another author of the AccessX functionality and one who is well in-tune with the OT side of things. The end conclusion might be the same, but at least we will be comforted that the decision was made with the blessing of the domain experts. Will On Mar 3, 2006, at 6:04 AM, Gunnar Schmi Dt wrote: > Hello Bill, > > On Friday 03 March 2006 11:43, Bill Haneman wrote: >> Hi Olaf/All: >> >> Having worked on keyboard navigation issues for Gnome, mozilla, >> etc. for >> the past 5 years, I agree with your points, except for the suggestion >> about F8. Using function keys as modifiers is a very bad idea, >> and poor >> from an accessibility standpoint. A 'standard' modifier should be >> used, >> consistent with the rest of the desktop. >> [...] > > To my knowledge are talking about a keyboard shortcut for turning > on the > access keys. Once they are turned on, you see the a number of tooltips > which describe the keys you need to press in order to use one of the > access keys. > > In other words, for activating the access key "a" you have to: > 1. Press and release "Control" (possibly multiple times if sticky > keys is > enabled). After that, the tooltips are visible. > 2. Type "a". The access key is activated and the tooltips disappear. > > If we switch to some other shortcut (let us say F8) you have to: > 1. Type F8. After that, the tooltips are visible. > 2. Type "a". The access key is activated and the tooltips disappear. > > Can you please explain why you would prefer to use a modifier key? > > Gunnar Schmi Dt > -- > Member of KDE's Technical Working Group > Co-maintainer of the KDE Accessibility Project > Maintainer of the kdeaccessibility package > http://accessibility.kde.org/ > _______________________________________________ > kde-accessibility mailing list > kde-accessibility at kde.org > https://mail.kde.org/mailman/listinfo/kde-accessibility From maksim at kde.org Fri Mar 3 14:41:37 2006 From: maksim at kde.org (Maks Orlovich) Date: Fri, 3 Mar 2006 09:41:37 -0500 Subject: kdom and khtml integration In-Reply-To: <200603031023.31389.mueller@kde.org> References: <20060226232159.GA50130@xs4all.nl> <200603031023.31389.mueller@kde.org> Message-ID: <200603030941.37396.maksim@kde.org> > > 2. Consider merging webkit datastructures like AtomicString/QualifiedName > > and ElementFactory. This is optional ofcourse, however we have good > > experiences with this functionality in kdom. > > Yes, I agree with that. Could you perhaps elaborate on the advantages? I am quite concerned about loosing all the nice switches. > > > 7. Consider renaming khtml to kxml, to reflect the improved xml > > capabilities. > > Then we can as well go with "webkit" as a name ;) > > Honestly, I fail to see which problems you saw with the modularisation? > Perhaps then it would be easier to decide. Right now I don't think that > "avoiding a couple more virtual functions" would be a ground you base the > start of spaghetti code (see Safari) on. Well, one issue I talked about with Niko is that we definitely do not want to guarantee BC in impl classes. So if it's modular, we'll have to do some sort of thing where ksvg version is paired to the khtml version. From ivor at ivor.org Fri Mar 3 14:57:13 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Fri, 3 Mar 2006 14:57:13 +0000 Subject: making fallback access keys configurable In-Reply-To: <200603031116.36063.ojschmidt@kde.org> References: <200602271500.03532.aseigo@kde.org> <200602281143.58202.l.lunak@suse.cz> <200603031116.36063.ojschmidt@kde.org> Message-ID: <200603031457.14297.ivor@ivor.org> On Friday 03 March 2006 10:16, Olaf Jan Schmidt wrote: > * Requiring the user to press the Ctrl key twice, or to hold down the key > for a longer time, would clash with the accessibility keyboard settings. > This is especially true if combined with a timeout. Remember that severely > impaired users are among those who use accesskeys, and they are typically > much slower in handling the keyboard. > I was simply showing the double ctrl-key idea as a concept to see if those who were addicted to the access key feature thought it a worthwhile/useable change. I was hoping some people might actually try it. The intention was to actually have a working example of an alternative rather than simply a 30 mail argument of "I like it" "I hate it posts". You are correct it would/could clash with accessibility settings, however there's no reason it couldn't be modified to have behaviour that takes those settings into account. On the other hand I'm not going to spend several hours writing a complete solution that takes accessibility settings into account if noone likes the idea. Regards, -- Ivor Hewitt. From tobias at ke.informatik.tu-darmstadt.de Fri Mar 3 15:11:30 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Fri, 3 Mar 2006 16:11:30 +0100 Subject: AW: Statically linked Konqueror In-Reply-To: <200603031242.46185.thiago@kde.org> References: <200603031242.46185.thiago@kde.org> Message-ID: <000101c63ed4$d20f1330$50a25382@Terroristencamp> Though it is also possible to run konq/e under X11. So basically, konq/e is what you're looking for. Checkout the kdenox module and subscribe to konq-e at kde.org to get involved. Tobias -----Ursprüngliche Nachricht----- Von: Thiago Macieira [mailto:thiago at kde.org] Gesendet: Freitag, 3. März 2006 12:43 An: kfm-devel at kde.org Cc: David Lie Betreff: Re: Statically linked Konqueror David Lie wrote: >I was wondering how one would build a completely statically linked >version of konqueror You wouldn't. That's not possible. If you want to do that, you will have to hack the code yourself. Konq/e is a special version of Konqueror that is designed to work on embedded systems. The normal Konqueror version relies on being able to dynamically load KParts (which are ELF shared objects). And the KDE build system does not allow you to create statically-linked libraries either. >that will run on Linux. I noticed there are ways >to build a static konqueror for a palmtop environment, but I don't seem >to be able to do the same for a standard UNIX environment. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 3. Ac seo woruld wearð geborod, swá se Scieppend cwæð "Gewurde Unix" and wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung. From tobias at ke.informatik.tu-darmstadt.de Fri Mar 3 15:11:30 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Fri, 3 Mar 2006 16:11:30 +0100 Subject: AW: [Kde-accessibility] making fallback access keys configurable In-Reply-To: <1141392932.7128.16.camel@linux.site> References: <1141392932.7128.16.camel@linux.site> Message-ID: <000001c63ed4$d1f067a0$50a25382@Terroristencamp> > If the Control key is being used as a "toggle", > i.e. "press/release" of control turns Access Keys > on and off, then I would suggest that this [...] > is a dubious idea. The "toggle" variant was only introduced to work around collisions with Ctrl+o, Ctrl+C, Ctrl+X, Ctrl+V, Ctrl+S and the like. Tobias From rhkramer at gmail.com Fri Mar 3 20:15:21 2006 From: rhkramer at gmail.com (Randy Kramer) Date: Fri, 3 Mar 2006 15:15:21 -0500 Subject: Is this a list to talk about khtml? Is it *the* list? Message-ID: <200603031515.22090.rhkramer@gmail.com> I want to use khtml (for rendering html, probably without all the bells and whistles of konqueror), but I have some questions, and not sure where I should post them. Just as an example, I want to send an HTML "stream" to khtml to be rendered (as opposed to having khtml load a URL (local or remote)). Randy Kramer (Unless I missed something, there is no separate khtml mailing list, nor a bugzilla category--khtml seems to be addressed as a subset of various other applications, like konqueror, kmail, ...) From sebastien.raveau at epita.fr Fri Mar 3 22:47:01 2006 From: sebastien.raveau at epita.fr (Sebastien Raveau) Date: Fri, 3 Mar 2006 23:47:01 +0100 Subject: Is this a list to talk about khtml? Is it *the* list? In-Reply-To: <200603031515.22090.rhkramer@gmail.com> References: <200603031515.22090.rhkramer@gmail.com> Message-ID: <200603032347.18528.sebastien.raveau@epita.fr> Hi Randy, Yes, this is *the* list :) On Friday 03 March 2006 21:15, Randy Kramer wrote: > Just as an example, I want to send an HTML "stream" to khtml to be rendered > (as opposed to having khtml load a URL (local or remote)). This can be done with KHTMLPart::write() as you can see on: http://developer.kde.org/documentation/library/cvs-api/kdelibs-apidocs/khtml/html/classKHTMLPart.html#a50 or with ReadOnlyPart::openStream() and then ReadOnlyPart::openURL() as on: http://developer.kde.org/documentation/library/cvs-api/kdelibs-apidocs/kparts/html/classKParts_1_1ReadOnlyPart.html#a9 and of course don't forget to ReadOnlyPart::closeStream() Good Luck / Have Fun! -- Sébastien Raveau computer and network security student head of the hawKeye network monitor project http://hawkeye.sourceforge.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From klingens at kde.org Fri Mar 3 21:10:00 2006 From: klingens at kde.org (Martijn Klingens) Date: Fri, 3 Mar 2006 22:10:00 +0100 Subject: Fwd: khtml window corruption Message-ID: <200603032210.01404.klingens@kde.org> Is anyone still reading the khtml-devel list? This mail has been unanswered for a week. While common on some lists I'm a bit surprised to see this happening here. -- Martijn -------------- next part -------------- An embedded message was scrubbed... From: Waldo Bastian Subject: Fwd: khtml window corruption Date: Fri, 24 Feb 2006 21:31:32 +0100 Size: 6734 URL: From ismail at uludag.org.tr Fri Mar 3 21:15:30 2006 From: ismail at uludag.org.tr (Ismail Donmez) Date: Fri, 3 Mar 2006 23:15:30 +0200 Subject: Fwd: khtml window corruption In-Reply-To: <200603032210.01404.klingens@kde.org> References: <200603032210.01404.klingens@kde.org> Message-ID: <200603032315.31605.ismail@uludag.org.tr> Cuma 3 Mart 2006 23:10 tarihinde, Martijn Klingens şunları yazmıştı: > Is anyone still reading the khtml-devel list? This mail has been unanswered > for a week. While common on some lists I'm a bit surprised to see this > happening here. Tried with python mktest > test.html and scrolling test.html in Konqueror works fine. I would suspect gfx driver in this case. /ismail -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From ivor at ivor.org Fri Mar 3 21:18:54 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Fri, 3 Mar 2006 21:18:54 +0000 Subject: Fwd: khtml window corruption In-Reply-To: <200603032210.01404.klingens@kde.org> References: <200603032210.01404.klingens@kde.org> Message-ID: <200603032118.54471.ivor@ivor.org> On Friday 03 March 2006 21:10, Martijn Klingens wrote: > Is anyone still reading the khtml-devel list? This mail has been unanswered > for a week. While common on some lists I'm a bit surprised to see this > happening here. > there's a khtml-devel list? heh. -- Ivor Hewitt. From ismail at uludag.org.tr Fri Mar 3 21:22:01 2006 From: ismail at uludag.org.tr (Ismail Donmez) Date: Fri, 3 Mar 2006 23:22:01 +0200 Subject: Fwd: khtml window corruption In-Reply-To: <200603032118.54471.ivor@ivor.org> References: <200603032210.01404.klingens@kde.org> <200603032118.54471.ivor@ivor.org> Message-ID: <200603032322.01453.ismail@uludag.org.tr> Cuma 3 Mart 2006 23:18 tarihinde, Ivor Hewitt şunları yazmıştı: > On Friday 03 March 2006 21:10, Martijn Klingens wrote: > > Is anyone still reading the khtml-devel list? This mail has been > > unanswered for a week. While common on some lists I'm a bit surprised to > > see this happening here. > > there's a khtml-devel list? heh. Once upon a time created for WebCore<->Khtml collobration... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From charles at kde.org Sat Mar 4 00:50:42 2006 From: charles at kde.org (Charles Samuels) Date: Sat, 4 Mar 2006 00:50:42 +0000 Subject: PATCH: javascript setTimeout over midnight bug Message-ID: <200603040050.46281.charles@kde.org> The attached patch to 3.5 branch fixes a buggle in which timeouts occur much sooner than they should if timeout goes over midnight. Steps to reproduce: - set your system clock to 23:55 - load test.html - click the link - observe the timeout occur immediately instead of after 10 minutes. Since most patches here are ignored, I'll commit it after 24 hours if I don't hear anything :) It'd be wise for someone working against trunk to apply it there as well (it should more or less cleanly) cs -------------- next part -------------- A non-text attachment was scrubbed... Name: khtml-ecma-timeout-midnight.diff Type: text/x-diff Size: 6261 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From porten at froglogic.com Sat Mar 4 07:55:06 2006 From: porten at froglogic.com (Harri Porten) Date: Sat, 4 Mar 2006 08:55:06 +0100 (CET) Subject: PATCH: javascript setTimeout over midnight bug In-Reply-To: <200603040050.46281.charles@kde.org> References: <200603040050.46281.charles@kde.org> Message-ID: Hi! On Sat, 4 Mar 2006, Charles Samuels wrote: > The attached patch to 3.5 branch fixes a buggle in which timeouts occur much > sooner than they should if timeout goes over midnight. Have you considered using QDateTime as a member variable instead of seperate QDate and QTime? For some calculations you might need to pick them apart with date() and time() again. But at least the class already has e.g. an operator<() made for you. Harri. From faure at kde.org Sat Mar 4 09:19:46 2006 From: faure at kde.org (David Faure) Date: Sat, 4 Mar 2006 10:19:46 +0100 Subject: PATCH: javascript setTimeout over midnight bug In-Reply-To: <200603040050.46281.charles@kde.org> References: <200603040050.46281.charles@kde.org> Message-ID: <200603041019.46785.faure@kde.org> On Saturday 04 March 2006 01:50, Charles Samuels wrote: > > The attached patch to 3.5 branch fixes a buggle in which timeouts occur much > sooner than they should if timeout goes over midnight. Ah, thanks; I was wondering why my banking site said "you took too much time to type your password" when I loaded it at 23:59 :) -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From maksim at cs.cornell.edu Sat Mar 4 16:28:16 2006 From: maksim at cs.cornell.edu (Maks Orlovich) Date: Sat, 4 Mar 2006 11:28:16 -0500 Subject: PATCH: javascript setTimeout over midnight bug In-Reply-To: <200603040050.46281.charles@kde.org> References: <200603040050.46281.charles@kde.org> Message-ID: <200603041128.16375.maksim@cs.cornell.edu> working against trunk to apply it there as well > (it should more or less cleanly) Can't comment on the patch (I avoid date/time handling), but I am gonna ask people to NOT forward-port. I do a periodic merges of all the 3.5 branch changes, and manually merged individual patches just lead to merge conflicts, and so it is lots of wasted work. From rhkramer at gmail.com Sat Mar 4 14:17:36 2006 From: rhkramer at gmail.com (Randy Kramer) Date: Sat, 4 Mar 2006 09:17:36 -0500 Subject: Is this a list to talk about khtml? Is it *the* list? In-Reply-To: <200603032347.18528.sebastien.raveau@epita.fr> References: <200603031515.22090.rhkramer@gmail.com> <200603032347.18528.sebastien.raveau@epita.fr> Message-ID: <200603040917.37395.rhkramer@gmail.com> On Friday 03 March 2006 05:47 pm, Sebastien Raveau wrote: > Yes, this is *the* list :) Sebastien, Wonderful--thanks! > On Friday 03 March 2006 21:15, Randy Kramer wrote: > > Just as an example, I want to send an HTML "stream" to khtml to be > > rendered (as opposed to having khtml load a URL (local or remote)). > > This can be done with KHTMLPart::write() as you can see on: > http://developer.kde.org/documentation/library/cvs-api/kdelibs-apidocs/khtm >l/html/classKHTMLPart.html#a50 or with ReadOnlyPart::openStream() and then > ReadOnlyPart::openURL() as on: > http://developer.kde.org/documentation/library/cvs-api/kdelibs-apidocs/kpar >ts/html/classKParts_1_1ReadOnlyPart.html#a9 and of course don't forget to > ReadOnlyPart::closeStream() > Good Luck / Have Fun! Thanks! I'll look at those at least a little before I start asking more questions. I don't know if I should warn everybody in advance--I've never programmed in C++ (or C) (nor Ruby--see below). My tentative hope/plan is that I'll be able to learn how to start a "standalone" instance of khtml, and then "control" it (i.e., send it HTML for rendering, clear it, send it more HTML, etc.) via QtRuby. (Or, maybe I'll use dcop from the CLI.) I'll explain more about what I'm trying to accomplish in a future post. Randy Kramer From charles at kde.org Sat Mar 4 17:22:22 2006 From: charles at kde.org (Charles Samuels) Date: Sat, 4 Mar 2006 17:22:22 +0000 Subject: PATCH: javascript setTimeout over midnight bug In-Reply-To: References: Message-ID: <200603041722.24705.charles@kde.org> Harri Porten wrote, on Saturday 2006 March 04 7:55 am: > Have you considered using QDateTime as a member variable instead of > seperate QDate and QTime? For some calculations you might need to pick > them apart with date() and time() again. But at least the class already > has e.g. an operator<() made for you. I had, but also its behavior with regards to milliseconds is undocumented. To my dismay, this wasn't fixed, or even documented in Qt4, either :( cs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From charles at kde.org Sat Mar 4 17:22:41 2006 From: charles at kde.org (Charles Samuels) Date: Sat, 4 Mar 2006 17:22:41 +0000 Subject: PATCH: javascript setTimeout over midnight bug In-Reply-To: <200603041019.46785.faure@kde.org> References: <200603040050.46281.charles@kde.org> <200603041019.46785.faure@kde.org> Message-ID: <200603041722.43527.charles@kde.org> David Faure wrote, on Saturday 2006 March 04 9:19 am: > Ah, thanks; I was wondering why my banking site said "you took too much > time to type your password" when I loaded it at 23:59 :) Join the club :) cs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From f_edemar at linux.se Sat Mar 4 10:24:02 2006 From: f_edemar at linux.se (Fredrik Edemar) Date: Sat, 4 Mar 2006 11:24:02 +0100 Subject: [PATH] remove file sharing from popup menu Message-ID: <200603041124.02611.f_edemar@linux.se> Hi all, this patch removes the file sharing item from the popup menu. The dialog can be reached in the property dialog too, so don't see the point with having it in the popup menu. I would like to commit this to the 3.5 branch and trunk. Any comments? -- Kind regards Fredrik Edemar -------------- next part -------------- A non-text attachment was scrubbed... Name: konqueror.diff Type: text/x-diff Size: 1007 bytes Desc: not available URL: From patrol at sinus.cz Sun Mar 5 13:34:48 2006 From: patrol at sinus.cz (Pavel Troller) Date: Sun, 5 Mar 2006 14:34:48 +0100 Subject: Today's SVN 3.5 branch khtml compile problem Message-ID: <20060305133448.GA24102@tangens.sinus.cz> Hi! The latest update in khtml causes the following problem with compilation: make[1]: Entering directory `/usr/src/kde3/kdelibs/khtml/dom' if /bin/sh ../../libtool --silent --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../dcop -I../../kdecore -I../../kio/kssl -I../../kjs -I../../kimgio -I../../kio -I../../dcop -I../../khtml -I../.. -I../../dcop -I../../libltdl -I../../kdefx -I../../kdecore -I../../kdecore -I../../kdeui -I../../kio -I../../kio/kio -I../../kio/kfile -I../.. -I/opt/qt3.2/include -I/opt/X11/include -I/opt/kde3.5/include -I/opt/sound/include -I/opt/samba/include -I/opt/aspell/include -I/opt/fontconfig/include -I/opt/alsa/include -I/opt/cups/include -DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -O2 -O2 -march=i586 -mcpu=i586 -fomit-frame-pointer -fforce-mem -fforce-addr -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -fexceptions -MT libkhtmldom_la.all_cpp.lo -MD -MP -MF ".deps/libkhtmldom_la.all_cpp.Tpo" -c -o libkhtmldom_la.all_cpp.lo libkhtmldom_la.all_cpp.cpp; \ then mv -f ".deps/libkhtmldom_la.all_cpp.Tpo" ".deps/libkhtmldom_la.all_cpp.Plo"; else rm -f ".deps/libkhtmldom_la.all_cpp.Tpo"; exit 1; fi In file included from html_table.cpp:29, from libkhtmldom_la.all_cpp.cpp:24: ../../khtml/html/html_tableimpl.h: In member function `ChildType* DOM::ChildHolder::get(const DOM::ElementImpl*) const [with ChildType = DOM::HTMLTableCaptionElementImpl, int ChildId = 16]': ../../khtml/html/html_tableimpl.h:134: instantiated from here ../../khtml/html/html_tableimpl.h:77: error: invalid static_cast from type ` DOM::NodeImpl*' to type `DOM::HTMLTableCaptionElementImpl*' ../../khtml/html/html_tableimpl.h: In member function `ChildType* DOM::ChildHolder::get(const DOM::ElementImpl*) const [with ChildType = DOM::HTMLTableSectionElementImpl, int ChildId = 94]': ../../khtml/html/html_tableimpl.h:137: instantiated from here ../../khtml/html/html_tableimpl.h:77: error: invalid static_cast from type ` DOM::NodeImpl*' to type `DOM::HTMLTableSectionElementImpl*' ../../khtml/html/html_tableimpl.h: In member function `ChildType* DOM::ChildHolder::get(const DOM::ElementImpl*) const [with ChildType = DOM::HTMLTableSectionElementImpl, int ChildId = 92]': ../../khtml/html/html_tableimpl.h:140: instantiated from here ../../khtml/html/html_tableimpl.h:77: error: invalid static_cast from type ` DOM::NodeImpl*' to type `DOM::HTMLTableSectionElementImpl*' ../../khtml/html/html_tableimpl.h: In member function `ChildType* DOM::ChildHolder::get(const DOM::ElementImpl*) const [with ChildType = DOM::HTMLTableSectionElementImpl, int ChildId = 89]': ../../khtml/html/html_tableimpl.h:191: instantiated from here ../../khtml/html/html_tableimpl.h:77: error: invalid static_cast from type ` DOM::NodeImpl*' to type `DOM::HTMLTableSectionElementImpl*' make[1]: *** [libkhtmldom_la.all_cpp.lo] Error 1 make[1]: Leaving directory `/usr/src/kde3/kdelibs/khtml/dom' With regards, Pavel Troller From maksim at cs.cornell.edu Sun Mar 5 14:15:52 2006 From: maksim at cs.cornell.edu (Maks Orlovich) Date: Sun, 5 Mar 2006 09:15:52 -0500 Subject: Today's SVN 3.5 branch khtml compile problem In-Reply-To: <20060305133448.GA24102@tangens.sinus.cz> References: <20060305133448.GA24102@tangens.sinus.cz> Message-ID: <200603050915.52977.maksim@cs.cornell.edu> On Sunday 05 March 2006 08:34, Pavel Troller wrote: > Hi! > The latest update in khtml causes the following problem with compilation: Ugh. What gcc is that? And does it help if you change the static_cast on line 77 to reinterpret_cast? Also, what's line 24 of libkhtmldom_la.all_cpp.cpp? From thiago at kde.org Sun Mar 5 14:38:24 2006 From: thiago at kde.org (Thiago Macieira) Date: Sun, 5 Mar 2006 15:38:24 +0100 Subject: Today's SVN 3.5 branch khtml compile problem In-Reply-To: <200603050915.52977.maksim@cs.cornell.edu> References: <20060305133448.GA24102@tangens.sinus.cz> <200603050915.52977.maksim@cs.cornell.edu> Message-ID: <200603051538.24589.thiago@kde.org> Maks Orlovich wrote: >Also, what's line 24 of libkhtmldom_la.all_cpp.cpp? #include "html_table.cpp" -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 5. Swa he géanhwearf tó timbran, and hwonne he cóm, lá! Unix cwæð "Hello, World". Ǽfre ǽghwilc wæs glæd and seo woruld wæs fréo. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From patrol at sinus.cz Sun Mar 5 15:48:15 2006 From: patrol at sinus.cz (Pavel Troller) Date: Sun, 5 Mar 2006 16:48:15 +0100 Subject: Today's SVN 3.5 branch khtml compile problem In-Reply-To: <200603050915.52977.maksim@cs.cornell.edu> References: <20060305133448.GA24102@tangens.sinus.cz> <200603050915.52977.maksim@cs.cornell.edu> Message-ID: <20060305154815.GA15706@tangens.sinus.cz> > On Sunday 05 March 2006 08:34, Pavel Troller wrote: > > Hi! > > The latest update in khtml causes the following problem with compilation: > > Ugh. What gcc is that? And does it help if you change the static_cast on line > 77 to reinterpret_cast? Hi! It's gcc-3.3.3 . And changing to reinterpret_cast causes khtml to compile and even to run cleanly :-). Thanks! With regards, Pavel Troller > > Also, what's line 24 of libkhtmldom_la.all_cpp.cpp? From amantia at kde.org Sun Mar 5 16:04:44 2006 From: amantia at kde.org (Andras Mantia) Date: Sun, 05 Mar 2006 18:04:44 +0200 Subject: kdom and khtml integration References: <20060226232159.GA50130@xs4all.nl> <200603011331.06153.frans.englich@telia.com> <200603011621.39345.zimmermann@kde.org> Message-ID: <20060305160522.D17F7405EB@smtp.zappmobile.ro> Nikolas Zimmermann wrote: > There won't be a KDOM > in kdelibs at all - we will integrate within khtml. So there will not be any DOM implementation that can be used by other apps and it will be integrated the same way as the current DOM implementation is with KHTML? Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From moura at kdewebdev.org Sun Mar 5 16:29:20 2006 From: moura at kdewebdev.org (Paulo Moura Guedes) Date: Sun, 5 Mar 2006 16:29:20 +0000 Subject: kdom and khtml integration In-Reply-To: <20060305160522.D17F7405EB@smtp.zappmobile.ro> References: <20060226232159.GA50130@xs4all.nl> <200603011621.39345.zimmermann@kde.org> <20060305160522.D17F7405EB@smtp.zappmobile.ro> Message-ID: <200603051629.20302.moura@kdewebdev.org> On Sunday 05 March 2006 16:04, Andras Mantia wrote: > Nikolas Zimmermann wrote: > > There won't be a KDOM > > in kdelibs at all - we will integrate within khtml. > > So there will not be any DOM implementation that can be used by other apps > and it will be integrated the same way as the current DOM implementation is > with KHTML? I have the feeling that WYSIWYG applications in KDE won't be available in the near future because: 1. The base infrastructure doesn't exist and it's not probable it would soon. 2. It's not designed having WYSIWYG editing in mind, aka extension points. Paulo From zimmermann at kde.org Sun Mar 5 16:41:51 2006 From: zimmermann at kde.org (Nikolas Zimmermann) Date: Sun, 5 Mar 2006 17:41:51 +0100 Subject: kdom and khtml integration In-Reply-To: <20060305160522.D17F7405EB@smtp.zappmobile.ro> References: <20060226232159.GA50130@xs4all.nl> <200603011621.39345.zimmermann@kde.org> <20060305160522.D17F7405EB@smtp.zappmobile.ro> Message-ID: <200603051741.51723.zimmermann@kde.org> On Sunday 05 March 2006 17:04, Andras Mantia wrote: > Nikolas Zimmermann wrote: > > There won't be a KDOM > > in kdelibs at all - we will integrate within khtml. > > So there will not be any DOM implementation that can be used by other apps > and it will be integrated the same way as the current DOM implementation is > with KHTML? > > Andras Hi Andras, that's not correct this way :-) We will offer new interfaces (basically stuff like KDOMParser/KDOMDocumentBuilder) to build DOM trees ie. from some remote url or local file (KIO), from in-memory buffers etc. That means, you don't need to have a KHTMLPart loaded at all, but can directly use the "future khtml" (after the kdom integration) to just use the DOM stuff (for example: w/o any rendering involved) After my last exam Monday, I want to start working on these things ASAP, so I can actually show code which demonstrates how the new "khtml" should/will work in future. Hope that clarifies the situation a bit. :-) Bye Bye Niko From frans.englich at telia.com Sun Mar 5 16:41:53 2006 From: frans.englich at telia.com (Frans Englich) Date: Sun, 5 Mar 2006 16:41:53 +0000 Subject: kdom and khtml integration In-Reply-To: <200603030941.37396.maksim@kde.org> References: <20060226232159.GA50130@xs4all.nl> <200603031023.31389.mueller@kde.org> <200603030941.37396.maksim@kde.org> Message-ID: <200603051641.54078.frans.englich@telia.com> On Friday 03 March 2006 14:41, Maks Orlovich wrote: > > > 2. Consider merging webkit datastructures like > > > AtomicString/QualifiedName and ElementFactory. This is optional > > > ofcourse, however we have good experiences with this functionality in > > > kdom. > > > > Yes, I agree with that. > > Could you perhaps elaborate on the advantages? I am quite concerned about > loosing all the nice switches. > > > > 7. Consider renaming khtml to kxml, to reflect the improved xml > > > capabilities. > > > > Then we can as well go with "webkit" as a name ;) > > > > Honestly, I fail to see which problems you saw with the modularisation? > > Perhaps then it would be easier to decide. Right now I don't think that > > "avoiding a couple more virtual functions" would be a ground you base the > > start of spaghetti code (see Safari) on. > > Well, one issue I talked about with Niko is that we definitely do not want > to guarantee BC in impl classes. So if it's modular, we'll have to do some > sort of thing where ksvg version is paired to the khtml version. I agree that BC is problematic. But I don't see how building a monolithic library removes the requirement because Quanta needs the tree to be BC, for example. I am close to a solution, and that's to add an interface/implementation separation in the DOM sense(not in the bindings sense). See "part two" of this mail: http://mail.kde.org/pipermail/ksvg-devel/2006-February/000403.html Cheers, Frans From amantia at kde.org Sun Mar 5 16:54:58 2006 From: amantia at kde.org (Andras Mantia) Date: Sun, 05 Mar 2006 18:54:58 +0200 Subject: kdom and khtml integration References: <20060226232159.GA50130@xs4all.nl> <200603011621.39345.zimmermann@kde.org> <20060305160522.D17F7405EB@smtp.zappmobile.ro> <200603051741.51723.zimmermann@kde.org> Message-ID: <20060305170040.A0AD93CD83@smtp.zappmobile.ro> Nikolas Zimmermann wrote: > On Sunday 05 March 2006 17:04, Andras Mantia wrote: >> Nikolas Zimmermann wrote: >> > There won't be a KDOM >> > in kdelibs at all - we will integrate within khtml. >> >> So there will not be any DOM implementation that can be used by other >> apps and it will be integrated the same way as the current DOM >> implementation is with KHTML? >> >> Andras > > Hi Andras, > > that's not correct this way :-) We will offer new interfaces (basically > stuff like KDOMParser/KDOMDocumentBuilder) to build DOM trees > ie. from some remote url or local file (KIO), from in-memory buffers etc. > > That means, you don't need to have a KHTMLPart loaded at all, but > can directly use the "future khtml" (after the kdom integration) > to just use the DOM stuff (for example: w/o any rendering involved) > > After my last exam Monday, I want to start working on these things > ASAP, so I can actually show code which demonstrates how the > new "khtml" should/will work in future. > > Hope that clarifies the situation a bit. :-) A little. In short, we want to have in Quanta a common DOM tree for source and VPL (WYSIWYG) mode. Right now we have our own tree and there is the KHTML DOM tree. This requires intensive synchronization between the two whenever the document is modified in source or VPL mode. With KDOM we wanted to solve this problem, and can you tell me if this will be possible? What I was thinking is: - parse the document with our own parser and create a KDOM based tree - the KDOM tree nodes must be extensible (they should be able to hold extra information) - KHTML should be able to render directly this KDOM tree (for VPL mode) - it should be possible to modify the tree from code, without regenerating from scratch Now if all the above will be possible even with this monolithic design, I'm fine with it. Like Paulo said, we just want to have a KHTML and the underlying DOM tree which will make developing WYSIWYG application easier, without requiring extensive and ugly hacks. Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From faure at kde.org Sun Mar 5 19:15:22 2006 From: faure at kde.org (David Faure) Date: Sun, 5 Mar 2006 20:15:22 +0100 Subject: [PATH] remove file sharing from popup menu In-Reply-To: <200603041124.02611.f_edemar@linux.se> References: <200603041124.02611.f_edemar@linux.se> Message-ID: <200603052015.22634.faure@kde.org> On Saturday 04 March 2006 11:24, Fredrik Edemar wrote: > Hi all, > > this patch removes the file sharing item from the popup menu. The dialog can > be reached in the property dialog too, so don't see the point with having it > in the popup menu. I would like to commit this to the 3.5 branch and trunk. > Any comments? Personnally I don't mind; I think it was added there to mimic Windows (right, Laurent?) -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From frans.englich at telia.com Sun Mar 5 20:28:30 2006 From: frans.englich at telia.com (Frans Englich) Date: Sun, 5 Mar 2006 20:28:30 +0000 Subject: kdom and khtml integration In-Reply-To: <200603011621.39345.zimmermann@kde.org> References: <20060226232159.GA50130@xs4all.nl> <200603011331.06153.frans.englich@telia.com> <200603011621.39345.zimmermann@kde.org> Message-ID: <200603052028.30514.frans.englich@telia.com> On Wednesday 01 March 2006 15:21, Nikolas Zimmermann wrote: > On Wednesday 01 March 2006 14:31, Frans Englich wrote: > > On Sunday 26 February 2006 23:21, Rob Buis wrote: > > > Good evening khtml hackers :-) > > > > Came to think of another thing: > > > > I don't think KDOM as it is now is suitable for kdelibs inclusion. css/, > > core/ and events/ quite thoroughly spews compiler warnings and that isn't > > very correct. It is also avoided in kdelibs, so it would lower kdelibs > > quality. > > > > Likewise, there are admirable efforts for improving the Doxygen in > > kdelibs. KDOMBinder does currently at best generate no doxygen but > > regularly outputs invalid. I think it should be fixed, since otherwise it > > would lower kdelibs quality. > > > > But that's just my personal view on how things should be, of course. > > > > > > Cheers, > > > > Frans > > Hi Frans, > > you may have misunderstood something. There won't be a KDOM > in kdelibs at all - we will integrate within khtml. I am bewildered by what you write. I've now three or four times tried to make us take a close look at this monolitihic vs modularized issue. I've not objected to anything, all I've said is let's discuss this, let's analyze this, let's bring in all our different views, requirements and competences on this. This is pretty much all I know: the reason to build a monotlithic library is a performance gain which outruns that all other applications that doesn't need SVG/HTML rendering gets increased startup time for no reason and an increased memory consumption that scales linearly with document size for no reason. I haven't seen an analysis concluding why all other solutions apart from building a monolithic library fail. I'm saying that we should analyze and discuss it, such that there is substance when you use the word "we". All my alarm bells go off when I hear that modularization is sacrifized in the name of performance. Especially when the motiviation is vague and that many interesting alternatives exists. The trend in kdelibs is to build specialized, modularized libraries and I want khtml/kdom to follow that, not go in the opposite direction. It is a long step from "we think here is a significant negative performance impact" to concluding that the best solution is a decision on the library level. If one wants to avoid call dispatching in a hot code path there are many solutions which works without sacrifizing modularization. It also scares me to discuss performance without numbers, especially with the complex systems in KDOM/KHTML and that little is exported and therefore inter procedural optimizations can be quite effective. Couldn't you describe exactly what problematic areas you think exist, and why the various modularized approaches fail, according to your opinion? I think many would appreciate if you did that. > That means we won't > port all-in-one-shot, but in little manageable pieces. That includes > regression testing, regression testing, regression testing. I for > sure wouldn't want to introduce new warnings/errors/bugs. > > I'm not seeing your point. I want constructive discussions, > mails like these don't help at all. We see it different ways; I find the mail constructive. The second KDOMBinder generates broken documentation since it was deployed. Warnings in KDOM have been cleaned up, but afterwards introduced again. That suggests it have had low priority. I find it constructive to identify problems, to say "this and this must be better", and to build a goal that must be reached. Sure, it sounds a bit depressive since it "says no" and pulls the break. But all is fine, "I sure wouldn't want to introduce new warnings/errors/bugs" is all that's needed to know this has the necessary focus. I would also like to see KDOM(and khtml) to compile with stricter options: -Wold-style-cast and -pedantic. I do that for my areas in KDOM(about 40% of the code), but it would be cool to see it in all code. > And yes, I'm a bit angry. Cheers, Frans From zimmermann at kde.org Sun Mar 5 21:10:51 2006 From: zimmermann at kde.org (Nikolas Zimmermann) Date: Sun, 5 Mar 2006 22:10:51 +0100 Subject: kdom and khtml integration In-Reply-To: <200603052028.30514.frans.englich@telia.com> References: <20060226232159.GA50130@xs4all.nl> <200603011621.39345.zimmermann@kde.org> <200603052028.30514.frans.englich@telia.com> Message-ID: <200603052210.51856.zimmermann@kde.org> Hi, > > you may have misunderstood something. There won't be a KDOM > > in kdelibs at all - we will integrate within khtml. > > I am bewildered by what you write. I've now three or four times tried to > make us take a close look at this monolitihic vs modularized issue. I've > not objected to anything, all I've said is let's discuss this, let's > analyze this, let's bring in all our different views, requirements and > competences on this. I've spent the last months (!) evaluating several possible solutions with Eric, Maciej, Maksim etc. - you want to discuss stuff, we already discussed in _length_ for ages. > This is pretty much all I know: the reason to build a monotlithic library > is a performance gain which outruns that all other applications that > doesn't need SVG/HTML rendering gets increased startup time for no reason > and an increased memory consumption that scales linearly with document size > for no reason. I haven't seen an analysis concluding why all other > solutions apart from building a monolithic library fail. [...] > Couldn't you describe exactly what problematic areas you think exist, and > why the various modularized approaches fail, according to your opinion? I > think many would appreciate if you did that. I'm really too exhausted to describe it to you again, as I've tried it at least 3+ times. I have numerous of reasons for this step. You don't really think I drop year's of work (kdom, ksvg2, etc..) for no reason, do you? I just do not want to spend time discussing things with you (with mostly: no results!!!) where I already discussed these things for ages with other ppl. One last word on that topic: Rob & me write a mail to kfm-devel, that we want to integrate with khtml. The feedback was quite nice & constructive. And all you do is trying to force us into the "integrated" vs. "modularized" discussion, where we already decided to go the "integrated" way. Sorry that you didn't notice, that we have had these discussions on #ksvg since quite some months. - - A big sorry to all kfm-devel readers, to disturb your time with such "private fights" - that was the last comment from me on that topic. Bye Bye Niko From zimmermann at kde.org Sun Mar 5 21:16:08 2006 From: zimmermann at kde.org (Nikolas Zimmermann) Date: Sun, 5 Mar 2006 22:16:08 +0100 Subject: kdom and khtml integration In-Reply-To: <20060305170040.A0AD93CD83@smtp.zappmobile.ro> References: <20060226232159.GA50130@xs4all.nl> <200603051741.51723.zimmermann@kde.org> <20060305170040.A0AD93CD83@smtp.zappmobile.ro> Message-ID: <200603052216.09182.zimmermann@kde.org> Hi Andras, > A little. In short, we want to have in Quanta a common DOM tree for source > and VPL (WYSIWYG) mode. Right now we have our own tree and there is the > KHTML DOM tree. This requires intensive synchronization between the two > whenever the document is modified in source or VPL mode. With KDOM we > wanted to solve this problem, and can you tell me if this will be possible? > What I was thinking is: > - parse the document with our own parser and create a KDOM based tree Hm, you probably need to parse additional stuff like PHP etc? Can you elaborate a bit more, how you reuse khtml's parsing/tokenizing in Quanta? (do you use it at all? or do you build two completely seperated trees) > - the KDOM tree nodes must be extensible (they should be able to hold extra > information) That will definately be possible, just like the NodeImpl contains pointers to the RenderObject, we can also supply nodes with "UserData". > - KHTML should be able to render directly this KDOM tree (for VPL mode) If you want _one_ tree, then you need to let the html parsing/tokenizing create the tree. A custom parser can't help there? > - it should be possible to modify the tree from code, without regenerating > from scratch That is definately possible. > Now if all the above will be possible even with this monolithic design, I'm > fine with it. Like Paulo said, we just want to have a KHTML and the > underlying DOM tree which will make developing WYSIWYG application easier, > without requiring extensive and ugly hacks. Well the monolithic design doesn't mean at all that "kdom is gone". It just lives in a new directory called "khtml", and it's main benefits will still be existing. At least that's our plan. :-) I'll promise to check out Quanta code myself after tomorrow (last exam!). That should help my understanding of your problems a lot :-) Bye Bye Niko From amantia at kde.org Sun Mar 5 21:32:57 2006 From: amantia at kde.org (Andras Mantia) Date: Sun, 05 Mar 2006 23:32:57 +0200 Subject: kdom and khtml integration References: <20060226232159.GA50130@xs4all.nl> <200603051741.51723.zimmermann@kde.org> <20060305170040.A0AD93CD83@smtp.zappmobile.ro> <200603052216.09182.zimmermann@kde.org> Message-ID: <20060305213234.531033CD50@smtp.zappmobile.ro> Hi, Nikolas Zimmermann wrote: >> What I was thinking is: >> - parse the document with our own parser and create a KDOM based tree > Hm, you probably need to parse additional stuff like PHP etc? Can you > elaborate a bit more, how you reuse khtml's parsing/tokenizing in Quanta? > (do you use it at all? or do you build two completely seperated trees) Right now we use two trees, but we want to have only one. The parser will be in Quanta, we will not reuse from KHTML, partly because we parse other things, not only HTML, and partly because most of the time we parse a document it is NOT valid HTML. From KDOM/KHTML we need a way to build the tree from our parser and that this tree should be understandable by KHTML, even if it has nodes with extra information or nodes with not HTML information (those should be ignored, like the nodes for PHP code). >> - the KDOM tree nodes must be extensible (they should be able to hold >> extra information) > That will definately be possible, just like the NodeImpl contains pointers > to the RenderObject, we can also supply nodes with "UserData". Yes, this is needed, as - for example - we need some kind of information about the position of the node in the document itself. >> - KHTML should be able to render directly this KDOM tree (for VPL mode) > If you want _one_ tree, then you need to let the html parsing/tokenizing > create the tree. A custom parser can't help there? I think it is the only solution. :-) Just that all methods needed to build the KDOM tree from an external parser should be public. > I'll promise to check out Quanta code myself after tomorrow (last exam!). > That should help my understanding of your problems a lot :-) Well, I'm not sure it will help a lot, as it was created without KHTML integration in mind (just like KHTML was created without WYSIWYG mode in mind), but this is what we want to change - on both sides. We plan to start on the new parser really soon, you might be interested in the code at that time. Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From maksim at cs.cornell.edu Sun Mar 5 23:23:29 2006 From: maksim at cs.cornell.edu (Maks Orlovich) Date: Sun, 5 Mar 2006 18:23:29 -0500 Subject: kdom and khtml integration In-Reply-To: <200603052216.09182.zimmermann@kde.org> References: <20060226232159.GA50130@xs4all.nl> <20060305170040.A0AD93CD83@smtp.zappmobile.ro> <200603052216.09182.zimmermann@kde.org> Message-ID: <200603051823.29806.maksim@cs.cornell.edu> On Sunday 05 March 2006 16:16, Nikolas Zimmermann wrote: > Hi Andras, > > > A little. In short, we want to have in Quanta a common DOM tree for > > source and VPL (WYSIWYG) mode. Right now we have our own tree and there > > is the KHTML DOM tree. This requires intensive synchronization between > > the two whenever the document is modified in source or VPL mode. With > > KDOM we wanted to solve this problem, and can you tell me if this will be > > possible? > > > > What I was thinking is: > > - parse the document with our own parser and create a KDOM based tree > > Hm, you probably need to parse additional stuff like PHP etc? Can you > elaborate a bit more, how you reuse khtml's parsing/tokenizing in Quanta? > (do you use it at all? or do you build two completely seperated trees) > > > - the KDOM tree nodes must be extensible (they should be able to hold > > extra information) > > That will definately be possible, just like the NodeImpl contains pointers > to the RenderObject, we can also supply nodes with "UserData". That's not trivial. Adding pointers to NodeImpl will introduce considerable bloat and is not to be taken lightly. We could probably abuse the ListenerList pointer somehow, though, by making it a chain of optional stuff or such. Would take some thinking to get the abstraction right, but seems doable. Inheritting off internal types is of course simply -impossible- if we want freedom to change them. > > > - KHTML should be able to render directly this KDOM tree (for VPL mode) > > If you want _one_ tree, then you need to let the html parsing/tokenizing > create the tree. A custom parser can't help there? Well, I guess it may be nice if one could magically animate for rendering/attach a custom-built tree. Not sure how hard it is to wire, and I guess you probably know more about all the evil roundtrips via part/view than me. From lmontel at mandriva.com Sun Mar 5 19:29:32 2006 From: lmontel at mandriva.com (Laurent Montel) Date: Sun, 5 Mar 2006 20:29:32 +0100 Subject: [PATH] remove file sharing from popup menu In-Reply-To: <200603052015.22634.faure@kde.org> References: <200603041124.02611.f_edemar@linux.se> <200603052015.22634.faure@kde.org> Message-ID: <200603052029.32441.lmontel@mandriva.com> On Sunday 05 March 2006 20:15, David Faure wrote: > On Saturday 04 March 2006 11:24, Fredrik Edemar wrote: > > Hi all, > > > > this patch removes the file sharing item from the popup menu. The dialog > > can be reached in the property dialog too, so don't see the point with > > having it in the popup menu. I would like to commit this to the 3.5 > > branch and trunk. Any comments? > > Personnally I don't mind; I think it was added there to mimic Windows > (right, Laurent?) Yes for mimic Windows. What is the problem with this entry ? I think that it's more easy to "right click" and sharing directory as "right click" -> properties -> "share" tab. For a newbi I think that it's more easy. From amantia at kde.org Mon Mar 6 08:44:59 2006 From: amantia at kde.org (Andras Mantia) Date: Mon, 6 Mar 2006 10:44:59 +0200 Subject: Frame loading bug Message-ID: <200603061044.59684.amantia@kde.org> Hi, Since KDE 3.5.x there is a regression (http://bugs.kde.org/show_bug.cgi?id=106748) regarding loading of frames when the source is specified with javascript. With the below document (also attached) read_m.html will replace the ENTIRE document, not only the read_m frame. The bug prevents me to deploy Konqueror in a library as it makes a well known web mail service unusable. I would happily fix the bug, but I'm lost. You can find my findings in the bug report, but I don't know how to move forward as I don't know much about KHTML, not talking about KJS. Can someone with more knowledge look at it? I believe this is an easy to solve bug for the one who knows the internals, but I'm sure that at least they have an idea about what is going on. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: framebug.tar.bz2 Type: application/x-tbz Size: 484 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From frans.englich at telia.com Mon Mar 6 14:03:22 2006 From: frans.englich at telia.com (Frans Englich) Date: Mon, 6 Mar 2006 14:03:22 +0000 Subject: kdom and khtml integration In-Reply-To: <200603052216.09182.zimmermann@kde.org> References: <20060226232159.GA50130@xs4all.nl> <20060305170040.A0AD93CD83@smtp.zappmobile.ro> <200603052216.09182.zimmermann@kde.org> Message-ID: <200603061403.22946.frans.englich@telia.com> On Sunday 05 March 2006 21:16, Nikolas Zimmermann wrote: [...] > > - the KDOM tree nodes must be extensible (they should be able to hold > > extra information) > > That will definately be possible, just like the NodeImpl contains pointers > to the RenderObject, we can also supply nodes with "UserData". I don't think DOMUserData will work for that. It's a feature exposed to ECMAScript applications meaning that if a script is loaded which exercises that particular feature of DOM 3 Core, Quanta blows up. Quanta isn't a DOM application, it is a DOM "environment", as I see it. There have been 3-4 threads on quanta-devel about KDOM integration. From my understanding, Quanta wants to sub-class the tree and add data and function members. That is, to exercise a classic object oriented approach. Cheers, Frans From frans.englich at telia.com Mon Mar 6 14:12:00 2006 From: frans.englich at telia.com (Frans Englich) Date: Mon, 6 Mar 2006 14:12:00 +0000 Subject: kdom and khtml integration In-Reply-To: <20060305213234.531033CD50@smtp.zappmobile.ro> References: <20060226232159.GA50130@xs4all.nl> <200603052216.09182.zimmermann@kde.org> <20060305213234.531033CD50@smtp.zappmobile.ro> Message-ID: <200603061412.00918.frans.englich@telia.com> On Sunday 05 March 2006 21:32, Andras Mantia wrote: [...] > >> - the KDOM tree nodes must be extensible (they should be able to hold > >> extra information) > > > > That will definately be possible, just like the NodeImpl contains > > pointers to the RenderObject, we can also supply nodes with "UserData". > > Yes, this is needed, as - for example - we need some kind of information > about the position of the node in the document itself. This particular need will be taken care of by KDOM out of the box, due to that DOM 3 Core supplies this feature. I will probably look at it at /some point/, due to it being close to my work(XQuery/XSL-T). I think it will be implemented by a dictionary in DocumentImpl, mapping 'NodeImpl *' to DOMLocator instances. So, Quanta doesn't need to implement at what file, line, and column a certain node occurs. However, you still need an extension mechanism for your other stuff, of course. Cheers, Frans From moura at kdewebdev.org Mon Mar 6 21:30:49 2006 From: moura at kdewebdev.org (Paulo Moura Guedes) Date: Mon, 6 Mar 2006 21:30:49 +0000 Subject: kdom and khtml integration In-Reply-To: <200603051823.29806.maksim@cs.cornell.edu> References: <20060226232159.GA50130@xs4all.nl> <200603052216.09182.zimmermann@kde.org> <200603051823.29806.maksim@cs.cornell.edu> Message-ID: <200603062130.49180.moura@kdewebdev.org> On Sunday 05 March 2006 23:23, Maks Orlovich wrote: > > > - KHTML should be able to render directly this KDOM tree (for VPL mode) > > > > If you want _one_ tree, then you need to let the html parsing/tokenizing > > create the tree. A custom parser can't help there? > > Well, I guess it may be nice if one could magically animate for > rendering/attach a custom-built tree. Not sure how hard it is to wire, and > I guess you probably know more about all the evil roundtrips via part/view > than me. Not sure about what you mean, but such a WYSIWYG editor would need to draw custom content on the canvas. AFAIK, this is internal functionality not available to external apps, as expected for the purpose KHTML was designed (this is the extensions points I mentioned in the other thread). I would like to discuss that a little and hear KHTML developers opinion. Thanks, Paulo From l.savernik at aon.at Mon Mar 6 23:28:32 2006 From: l.savernik at aon.at (Leo Savernik) Date: Tue, 7 Mar 2006 00:28:32 +0100 Subject: kdom and khtml integration In-Reply-To: <200603062130.49180.moura@kdewebdev.org> References: <20060226232159.GA50130@xs4all.nl> <200603051823.29806.maksim@cs.cornell.edu> <200603062130.49180.moura@kdewebdev.org> Message-ID: <200603070028.34053.l.savernik@aon.at> Am Montag, 6. März 2006 22:30 schrieb Paulo Moura Guedes: > > Well, I guess it may be nice if one could magically animate for > > rendering/attach a custom-built tree. Not sure how hard it is to wire, > > and I guess you probably know more about all the evil roundtrips via > > part/view than me. > > Not sure about what you mean, but such a WYSIWYG editor would need to draw > custom content on the canvas. > AFAIK, this is internal functionality not available to external apps, as > expected for the purpose KHTML was designed (this is the extensions points > I mentioned in the other thread). > I would like to discuss that a little and hear KHTML developers opinion. As far as I've understood, Quanta needs two types of interfaces. First a means to inject a custom DOM-tree into khtml which is in turn laid out and rendered by it. Second, a means to get extents and style information about rendered objects exceeding what can be determined currently by the public DOM api. I'd like to know which kind of information VPL needed from the khtml renderer to work effectively. If the information is not too specific, it should be possible to design a stable api that satisfies both khtml's need for internal api flexibility and efficiency, and VPL's or any other consumer's need to interact with the rendered content. mfg Leo From fedemar at gmail.com Mon Mar 6 10:13:18 2006 From: fedemar at gmail.com (Fredrik Edemar) Date: Mon, 6 Mar 2006 11:13:18 +0100 Subject: [PATH] remove file sharing from popup menu In-Reply-To: References: <200603041124.02611.f_edemar@linux.se> <200603052015.22634.faure@kde.org> <200603052029.32441.lmontel@mandriva.com> Message-ID: Doesn't Windows XP put it in the property window only? It is already many entries in the popup menu and this one is accessable from two places, so in IMHO the entry is unncessary. 2006/3/6, Fredrik Edemar : > Doesn't Windows XP put it in the property window only? > It is already many entries in the popup menu and this one is > accessable from two places, so in IMHO the entry is unncessary. > > 2006/3/5, Laurent Montel : > > On Sunday 05 March 2006 20:15, David Faure wrote: > > > On Saturday 04 March 2006 11:24, Fredrik Edemar wrote: > > > > Hi all, > > > > > > > > this patch removes the file sharing item from the popup menu. The dialog > > > > can be reached in the property dialog too, so don't see the point with > > > > having it in the popup menu. I would like to commit this to the 3.5 > > > > branch and trunk. Any comments? > > > > > > Personnally I don't mind; I think it was added there to mimic Windows > > > (right, Laurent?) > > > > Yes for mimic Windows. > > What is the problem with this entry ? > > I think that it's more easy to "right click" and sharing directory as "right > > click" -> properties -> "share" tab. > > For a newbi I think that it's more easy. > > > > > From zander32 at gmail.com Mon Mar 6 23:29:33 2006 From: zander32 at gmail.com (Thomas Zander) Date: Tue, 7 Mar 2006 12:29:33 +1300 Subject: [Kde-hci] making fallback access keys configurable Message-ID: On Saturday 04 March 2006 02:35, Bill Haneman wrote: > To clarify my earlier comment, the reason I implied that F8 was being > suggested as a "modifier" here is twofold. One, I assumed (perhaps > wrongly) that in the absence of StickyKeys, the Control key (which is > normally understood to be a modifier key) was resulting in the access > keys appearing only while Control was pressed down. If the Control key > is being used as a "toggle", i.e. "press/release" of control turns > Access Keys on and off, then I would suggest that this violates the > usual user expectation of how modifier keys like Control, Alt, and > Shift work, and therefore is a dubious idea. This is indeed the core of the usability problem; as I explained here some time ago; http://www.kdedevelopers.org/node/1569 It would be great if _all_ *nix applications/environments would follow one standard, but if its a bad standard (from a usability POV) I will surely advice the hci group to use a better one. Using F8 already seems better. -- Thomas Zander From amantia at kde.org Tue Mar 7 19:46:35 2006 From: amantia at kde.org (Andras Mantia) Date: Tue, 7 Mar 2006 21:46:35 +0200 Subject: [PATCH] Do not resolve symlinks when clicking on them Message-ID: <200603072146.35872.amantia@kde.org> Hi, I expect this to be a controversial patch, but it is needed to achieve consistency within Konqueror itself. The problem is described in http://bugs.kde.org/123230 . The reason why I changed here and not in the sidebar is because it would be still inconsistent, as the user could enter the directory by typing the path in the location bar. I have no idea why the symlink resolving was needed, maybe it was useful when running applications, but KFileItem::run anyway uses the destination, not the link. Andras -- Quanta Plus developer - http://quanta.kdewebdev.org K Desktop Environment - http://www.kde.org -------------- next part -------------- A non-text attachment was scrubbed... Name: konq_dirpart.diff Type: text/x-diff Size: 633 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From germain at ebooksfrance.org Wed Mar 8 22:03:50 2006 From: germain at ebooksfrance.org (Germain Garand) Date: Wed, 8 Mar 2006 23:03:50 +0100 Subject: [patch] resource leakage in KJS Message-ID: <200603082303.50384.germain@ebooksfrance.org> Dear KJS hackers, I was investigating some compulsive CPU hogging building up over time and found out KJS::Debugger::attach doesn't check if an interpreter is already in its list. Apparently, it would happily add it over and over, after iterating the whole list of already attached interpreters. When inline statements are repeteadly evaluated the effect rapidly becomes quite bad - and IIUC the pollution seems process wide. So does attached patch looks OK or should that be fixed elsewhere? Greetings, Germain -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-diff Size: 521 bytes Desc: not available URL: From porten at froglogic.com Thu Mar 9 06:25:22 2006 From: porten at froglogic.com (Harri Porten) Date: Thu, 9 Mar 2006 07:25:22 +0100 (CET) Subject: [patch] resource leakage in KJS In-Reply-To: <200603082303.50384.germain@ebooksfrance.org> References: <200603082303.50384.germain@ebooksfrance.org> Message-ID: yOn Wed, 8 Mar 2006, Germain Garand wrote: > When inline statements are repeteadly evaluated the effect rapidly becomes > quite bad - and IIUC the pollution seems process wide. > > So does attached patch looks OK or should that be fixed elsewhere? Looks good. But could be simplified to use if (ai->interp == interp) return; instead of break'ing first, no? Harri. From amantia at kde.org Thu Mar 9 06:33:52 2006 From: amantia at kde.org (Andras Mantia) Date: Thu, 09 Mar 2006 08:33:52 +0200 Subject: [PATCH] Do not resolve symlinks when clicking on them References: <200603072146.35872.amantia@kde.org> Message-ID: <20060309063331.70DCA3F3A6@smtp.zappmobile.ro> Andras Mantia wrote: > Hi, > > I expect this to be a controversial patch, but it is needed to achieve > consistency within Konqueror itself. The problem is described in > http://bugs.kde.org/123230 . The reason why I changed here and not in > the sidebar is because it would be still inconsistent, as the user > could enter the directory by typing the path in the location bar. > I have no idea why the symlink resolving was needed, maybe it was > useful when running applications, but KFileItem::run anyway uses the > destination, not the link. > > Andras > In case there are no objections, I will commit the fix on Monday, so it will be in 3.5.2. Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From germain at ebooksfrance.org Thu Mar 9 08:47:25 2006 From: germain at ebooksfrance.org (Germain Garand) Date: Thu, 9 Mar 2006 09:47:25 +0100 Subject: [patch] resource leakage in KJS In-Reply-To: References: Message-ID: <200603090947.26129.germain@ebooksfrance.org> Le Jeudi 09 Mars 2006 07:25, Harri Porten a écrit : > yOn Wed, 8 Mar 2006, Germain Garand wrote: > > When inline statements are repeteadly evaluated the effect rapidly > > becomes quite bad - and IIUC the pollution seems process wide. > > > > So does attached patch looks OK or should that be fixed elsewhere? > > Looks good. But could be simplified to use > > if (ai->interp == interp) > return; > > instead of break'ing first, no? sure, I wrote it so because some people dislike return statements in the middle of flow, but if you don't care I definetly don't. BTW, I had a quick look at the new JSCore way, and it doesn't look immune to that problem either... but as its not iterating anymore, I don't know what's the best way to fix it. I'd say: iterating again ;( Germain From eva.brucherseifer at basyskom.de Thu Mar 9 10:05:46 2006 From: eva.brucherseifer at basyskom.de (Eva Brucherseifer) Date: Thu, 9 Mar 2006 11:05:46 +0100 Subject: configure.in.in in kjs Message-ID: <200603091105.49551.eva.brucherseifer@basyskom.de> Hi, kjs can use the pcre library, but there seems to be a problem with the configure.in.in file in the kjs directory. In order to check for pcre configure.in.in contains the following lines: --------------------------------------- if test "$with_pcre" = "yes"; then KDE_FIND_PATH(pcre-config, PCRE_CONFIG, [${exec_prefix}/bin ${prefix}/bin], [PCRE_CONFIG="" ]) if test -n "$PCRE_CONFIG" && $PCRE_CONFIG --libs >/dev/null 2>&1; then LIBPCRE=`$PCRE_CONFIG --libs-posix | sed -e "s,-L/usr/lib ,,"` PCRECFLAGS=`$PCRE_CONFIG --cflags` else LIBPCRE="-lpcre -lpcreposix" PCRECFLAGS= fi AC_CACHE_VAL(ac_cv_have_pcreposix, [ ac_save_libs="$LIBS" LIBS="$LIBPCRE" ac_CPPFLAGS_save="$CPPFLAGS" CPPFLAGS="$CPPFLAGS $PCRECFLAGS $all_includes" ac_LDFLAGS_save="$LDFLAGS" LDFLAGS="$LDFLAGS $all_libraries" AC_TRY_LINK( [#include ], [regfree(0);], [ac_cv_have_pcreposix="yes"], [ac_cv_have_pcreposix="no"] ) LIBS="$ac_save_libs" LDFLAGS="$ac_LDFLAGS_save" CPPFLAGS="$ac_CPPFLAGS_save" ]) if test "$ac_cv_have_pcreposix" = "yes"; then AC_DEFINE(HAVE_PCREPOSIX, 1, [Define if you have pcreposix libraries and header files.]) else AC_MSG_ERROR([You're missing libpcre. Download libpcre from http://www.pcre.org or find a binary package for your platform. Alternatively, you can specify --disable-pcre, but some web pages - using regular expressions in Javascript code - will not work correctly, the regexp support being quite limited if libpcre isn't present.]) fi fi ]) AC_CHECK_PCREPOSIX AC_SUBST(LIBPCRE) AC_SUBST(PCRECFLAGS) --------------------------------------- This works perfectly on common desktop installations, as libpcre and libpcreposix are located in /usr/lib/ Please note the line LIBPCRE=`$PCRE_CONFIG --libs-posix | sed -e "s,-L/usr/lib ,,"` If you crosscompile Konqueror/Embedded for an embedded target, the libs are usually installed in other directories and here comes the problem. pcre-config returns something like this: LIBPCRE = -L/home/luckas/svn-slimfast/phone-oe-arm/oe-build/tmp/staging/arm-linux/lib -lpcreposix -lpcre Unlike -L/usr/lib the -L term is not removed from the LIBPCRE variable and this make the library path term end up in the dependencies: LIB_KJSHTML = $(top_builddir)/konq-embed/kdesrc/khtml/ecma/libkjs_html_i.la $(top_builddir)/konq-embed/kdesrc/kjs/libkjs.la $(LIBPCRE) konqueror_DEPENDENCIES = $(LIB_KJSHTML) $(LIB_KHTML) $(LIB_ADDONS) konqueror$(EXEEXT): $(konqueror_OBJECTS) $(konqueror_DEPENDENCIES) Which doesn't work: make[5]: *** No rule to make target `-L/home/luckas/svn-slimfast/phone-oe-arm/oe-build/tmp/staging/arm-linux/lib', needed by `konqueror'. Stop. We did a quick fix by removing pcre-config, so that the fallback is used: LIBPCRE = -lpcre -lpcreposix As I am no expert in configure scripts, maybe someone else wants to have a look at this? BTW - in Suse pcreposix is part of pcre-devel instead of pcre, isn't it strange, that KDE software uses software from devel packages? Greetings, eva -- Eva Brucherseifer General Manager basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642 eva.brucherseifer at basyskom.de | www.basyskom.de From faure at kde.org Thu Mar 9 11:08:21 2006 From: faure at kde.org (David Faure) Date: Thu, 9 Mar 2006 12:08:21 +0100 Subject: [PATCH] Do not resolve symlinks when clicking on them In-Reply-To: <200603072146.35872.amantia@kde.org> References: <200603072146.35872.amantia@kde.org> Message-ID: <200603091208.22083.faure@kde.org> On Tuesday 07 March 2006 20:46, Andras Mantia wrote: > Hi, > > I expect this to be a controversial patch, but it is needed to achieve > consistency within Konqueror itself. The problem is described in > http://bugs.kde.org/123230 . The reason why I changed here and not in > the sidebar is because it would be still inconsistent, as the user > could enter the directory by typing the path in the location bar. > I have no idea why the symlink resolving was needed, maybe it was > useful when running applications, but KFileItem::run anyway uses the > destination, not the link. Well if you follow the comment and read KFileItem::run you can see that: // When clicking on a link to e.g. $HOME from the desktop, we want to open $HOME Imagine you have a link to your home on the desktop called "MyHome", when clicking on it you don't want to see "/home/user/Desktop/MyHome/" in konqueror, but /home/user. So how do we solve this? In one case a symlink is used to hide the actual location of a directory (/mnt) and in the other case the actual location (home) *is* where we want to go, the symlink is just a convenient way to go there. Do we need a desktop-specific hack (making symlink-resolution happen only if the link is on the desktop), or does someone have a better idea? -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From faure at kde.org Thu Mar 9 11:33:27 2006 From: faure at kde.org (David Faure) Date: Thu, 9 Mar 2006 12:33:27 +0100 Subject: [PATCH] Do not resolve symlinks when clicking on them In-Reply-To: <200603091208.22083.faure@kde.org> References: <200603072146.35872.amantia@kde.org> <200603091208.22083.faure@kde.org> Message-ID: <200603091233.27843.faure@kde.org> On Thursday 09 March 2006 12:08, David Faure wrote: > making symlink-resolution happen only if the link is on the desktop ... is done in the attached patches. Of course when going to ~/Desktop/ in konqueror, then clicking on a link to $HOME leads to /home/dfaure/Desktop/myhome, but I guess that's fine, it gives a consistent behavior in konqueror, and another one on the desktop (not the first time...) -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). -------------- next part -------------- A non-text attachment was scrubbed... Name: kfileitem.cpp.diff Type: text/x-diff Size: 967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: libkonq.diff Type: text/x-diff Size: 1524 bytes Desc: not available URL: From ivor at ivor.org Thu Mar 9 12:46:29 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Thu, 9 Mar 2006 12:46:29 +0000 Subject: connection keep-alive In-Reply-To: <200603022055.25519.klingens@kde.org> References: <200603020810.03637.ivor@ivor.org> <200603021936.22238.ivor@ivor.org> <200603022055.25519.klingens@kde.org> Message-ID: <200603091246.29766.ivor@ivor.org> On Thursday 02 March 2006 19:55, Martijn Klingens wrote: > On Thursday 02 March 2006 20:36, Ivor Hewitt wrote: > > On Thursday 02 March 2006 08:10, Ivor Hewitt wrote: > > > The attached patch moves the connection keep alive check out of this > > > clause.... however, can anyone comment on this logic? What is the > > > reason for having this set of header checks disabled for non http1.1 > > > responses? > > > > According to RFC2068 the connection keep-alive token is permitted in an > > http1.0 header. If no-one can recall why this response was disallowed for > > a 1.0 header then I'll commit moving it out of the check. > > I looked up the thread on NTLM proxies I started at the end of December, > which is also about Connection: headers, but that seems to be at the > client's end, not at the server. You may want to reread it to double-check > though. > > Apart from that, Dawit Alemayehu is the kio-http guru, and > he's in the US timezone, give him at least 24 hours to respond, and even > that is quite fast. 48 hours might be more polite. > Ok mailed Dawit directly, but got a bounce message. I'll commit if no-one objects. -- Ivor Hewitt. From eva.brucherseifer at basyskom.de Thu Mar 9 19:19:09 2006 From: eva.brucherseifer at basyskom.de (Eva Brucherseifer) Date: Thu, 9 Mar 2006 20:19:09 +0100 Subject: disappearing frames Message-ID: <200603092019.10389.eva.brucherseifer@basyskom.de> Hi everybody, when using Konq/E on a very small display (small height), there is a problem which also appears with the desktop version of Konqueror. So I hope you can give me some input no how to tackle the problem: Go to this webpage: https://www.dresdner-privat.de reduce the height of konqueror, until minheight => at this point the frame is totally gone and there is no way to scroll down. As the window on our device is always small, it is never possible to scroll. Is it possible to somehow set a min height to the frame? Or to the khtml widget? The first option would be better of course. Cheers, eva -- Eva Brucherseifer General Manager basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642 eva.brucherseifer at basyskom.de | www.basyskom.de From amantia at kde.org Fri Mar 10 05:58:35 2006 From: amantia at kde.org (Andras Mantia) Date: Fri, 10 Mar 2006 07:58:35 +0200 Subject: [PATCH] Do not resolve symlinks when clicking on them References: <200603072146.35872.amantia@kde.org> <200603091208.22083.faure@kde.org> <200603091233.27843.faure@kde.org> Message-ID: <20060310055814.69AA63E834@smtp.zappmobile.ro> David Faure wrote: > On Thursday 09 March 2006 12:08, David Faure wrote: >> making symlink-resolution happen only if the link is on the desktop > ... is done in the attached patches. > > Of course when going to ~/Desktop/ in konqueror, then clicking on a link > to $HOME leads to /home/dfaure/Desktop/myhome, but I guess that's fine, it > gives a consistent behavior in konqueror, and another one on the desktop > (not the first time...) > As I wrote in the bug report, I tested and like this version. From my point of view, you can commit the changes. Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From germain at ebooksfrance.org Fri Mar 10 12:37:59 2006 From: germain at ebooksfrance.org (Germain Garand) Date: Fri, 10 Mar 2006 13:37:59 +0100 Subject: disappearing frames In-Reply-To: <200603092019.10389.eva.brucherseifer@basyskom.de> References: <200603092019.10389.eva.brucherseifer@basyskom.de> Message-ID: <200603101337.59891.germain@ebooksfrance.org> Le Jeudi 09 Mars 2006 20:19, Eva Brucherseifer a écrit : > Hi everybody, > > when using Konq/E on a very small display (small height), there is a > problem which also appears with the desktop version of Konqueror. So I hope > you can give me some input no how to tackle the problem: > > Go to this webpage: > https://www.dresdner-privat.de > reduce the height of konqueror, until minheight > => at this point the frame is totally gone and there is no way to scroll > down. > > As the window on our device is always small, it is never possible to > scroll. > > Is it possible to somehow set a min height to the frame? Or to the khtml > widget? The first option would be better of course. > mmh, it would seem to me that what you want is having a minimum size on an entire frameset, no? (because a root frameset is always sized to the viewport dimension anyway, so you would not be able to scroll). If so, all you need is to patch RenderFrameSet::layout()'s first lines either to set m_height = max(your-hardcoded-minimum-height, viewportHeight), or to honour a css specified setting from the default stylesheet through a call to calcHeight(), but that might allow too much... so you should restrain m_height again afterward, e.g calcHeight; m_height = kMax(m_height, theViewportHeight) also, you should probably fix khtmlview to allow srollbars on framesets... I think we turn them off always in this case. Greetings, Germain From ivor at ivor.org Sat Mar 11 10:36:14 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Sat, 11 Mar 2006 10:36:14 +0000 Subject: Google search payment Message-ID: <200603111036.15559.ivor@ivor.org> http://slashdot.org/article.pl?sid=06/03/11/0539245 Does KDE eV have such an arrangement? -- Ivor Hewitt. From thiago at kde.org Sat Mar 11 12:16:51 2006 From: thiago at kde.org (Thiago Macieira) Date: Sat, 11 Mar 2006 13:16:51 +0100 Subject: Google search payment In-Reply-To: <200603111036.15559.ivor@ivor.org> References: <200603111036.15559.ivor@ivor.org> Message-ID: <200603111316.51819.thiago@kde.org> Ivor Hewitt wrote: >http://slashdot.org/article.pl?sid=06/03/11/0539245 > >Does KDE eV have such an arrangement? No. We're looking into it. But far more interesting would be if Google stopped blacklisting Konqueror. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 1. On frumscafte, hwonne time_t wæs náht, se scieppend þone circolwyrde wundorcræftlíge cennede and seo eorðe wæs idel and hit wæs gód. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From kde at carewolf.com Sat Mar 11 16:34:40 2006 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 11 Mar 2006 17:34:40 +0100 Subject: content-disposition in HTTP headers Message-ID: <200603111734.40803.kde@carewolf.com> Hi It doesn't seems like Konqueror is honoring content-disposition:attachment in HTTP. Though the bug http://bugs.kde.org/show_bug.cgi?id=31662 has been closed. I think maybe the bug regressed after closing http://bugs.kde.org/show_bug.cgi?id=33769, since we do not parse the filename and type separately. The following patch implements separate passing of the content-disposition type and filename, and uses the type to decide on embedding in konq_run. Is it a problem that I rename the meta-data name in the http kioslave? Should I instead keep the filename as content-disposition and put the type under a new name? `Allan -------------- next part -------------- A non-text attachment was scrubbed... Name: content-disposition.diff Type: text/x-diff Size: 4904 bytes Desc: not available URL: From D.H.J.Takken at phys.uu.nl Sat Mar 11 17:45:38 2006 From: D.H.J.Takken at phys.uu.nl (Dik Takken) Date: Sat, 11 Mar 2006 18:45:38 +0100 (CET) Subject: Konqueror makes FAM / Gamin go nuts Message-ID: Hi, Until just a few weeks ago, I used FAM for file access notification. The problem with FAM was that when you were watching a directory with files that change very quickly, FAM could go nuts and start consuming all available CPU. Another nasty thing was that FAM was running as root, so users could not kill it in case of emergency. I recently heard about Gamin, the replacement for FAM that can use INotify of recent kernels. Unfortunately the problem of high CPU consumption returned. Now it happens from time to time that Gamin starts consuming lots of CPU for no clear reason whatsoever. The strange thing is that even a Konqueror window that displays a static set of files can trigger nuttyness in Gamin. I draw this conclusion from the fact that the madness stops when I close a konqueror window with static files in it, and the fact that I configured Konqueror to use one independent process for every window. Another observation: Killing Gamin does not always help. A new Gamin process is started, which happily continues wasting CPU. It only stops when the right Konqueror window is closed. How can I investigate what is going on? Is this a known problem? Using KDE 3.5.1 by the way. Cheers, Dik From amantia at kde.org Sat Mar 11 19:23:41 2006 From: amantia at kde.org (Andras Mantia) Date: Sat, 11 Mar 2006 21:23:41 +0200 Subject: Google search payment References: <200603111036.15559.ivor@ivor.org> <200603111316.51819.thiago@kde.org> Message-ID: <20060311192345.D47C23FE42@smtp.zappmobile.ro> Thiago Macieira wrote: > But far more interesting would be if Google stopped blacklisting > Konqueror. I know I will sound stupid here: but what features of Google are not working due to this backlist? Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From ismail at pardus.org.tr Sat Mar 11 19:24:21 2006 From: ismail at pardus.org.tr (Ismail Donmez) Date: Sat, 11 Mar 2006 21:24:21 +0200 Subject: Google search payment In-Reply-To: <20060311192345.D47C23FE42@smtp.zappmobile.ro> References: <200603111036.15559.ivor@ivor.org> <200603111316.51819.thiago@kde.org> <20060311192345.D47C23FE42@smtp.zappmobile.ro> Message-ID: <200603112124.27649.ismail@pardus.org.tr> Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: > Thiago Macieira wrote: > > But far more interesting would be if Google stopped blacklisting > > Konqueror. > > I know I will sound stupid here: but what features of Google are not > working due to this backlist? Non-ascii search. -- An eye for eye will make the whole world blind -- Gandhi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From amantia at kde.org Sat Mar 11 19:32:41 2006 From: amantia at kde.org (Andras Mantia) Date: Sat, 11 Mar 2006 21:32:41 +0200 Subject: Google search payment References: <200603111036.15559.ivor@ivor.org> <200603111316.51819.thiago@kde.org> <20060311192345.D47C23FE42@smtp.zappmobile.ro> <200603112124.27649.ismail@pardus.org.tr> Message-ID: <20060311193242.9A1D63FA34@smtp.zappmobile.ro> Ismail Donmez wrote: > Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: >> Thiago Macieira wrote: >> > But far more interesting would be if Google stopped blacklisting >> > Konqueror. >> >> I know I will sound stupid here: but what features of Google are not >> working due to this backlist? > > Non-ascii search. Thanks. Altough the Hungarian (and Romanian) alphabet has non-ascii characters, I never realized this problem. Well, maybe I mostly search for English texts... Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From ismail at pardus.org.tr Sat Mar 11 19:43:14 2006 From: ismail at pardus.org.tr (Ismail Donmez) Date: Sat, 11 Mar 2006 21:43:14 +0200 Subject: Google search payment In-Reply-To: <20060311193242.9A1D63FA34@smtp.zappmobile.ro> References: <200603111036.15559.ivor@ivor.org> <200603112124.27649.ismail@pardus.org.tr> <20060311193242.9A1D63FA34@smtp.zappmobile.ro> Message-ID: <200603112143.15453.ismail@pardus.org.tr> Cumartesi 11 Mart 2006 21:32 tarihinde, Andras Mantia şunları yazmıştı: > Ismail Donmez wrote: > > Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: > >> Thiago Macieira wrote: > >> > But far more interesting would be if Google stopped blacklisting > >> > Konqueror. > >> > >> I know I will sound stupid here: but what features of Google are not > >> working due to this backlist? > > > > Non-ascii search. > > Thanks. Altough the Hungarian (and Romanian) alphabet has non-ascii > characters, I never realized this problem. Well, maybe I mostly search for > English texts... Go to www.google.com.tr and search for €uro , now change your UA to Safari and do the same. Regards, ismail -- An eye for eye will make the whole world blind -- Gandhi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From frans.englich at telia.com Sat Mar 11 19:59:55 2006 From: frans.englich at telia.com (Frans Englich) Date: Sat, 11 Mar 2006 19:59:55 +0000 Subject: Google search payment In-Reply-To: <200603112124.27649.ismail@pardus.org.tr> References: <200603111036.15559.ivor@ivor.org> <20060311192345.D47C23FE42@smtp.zappmobile.ro> <200603112124.27649.ismail@pardus.org.tr> Message-ID: <200603111959.55284.frans.englich@telia.com> On Saturday 11 March 2006 19:24, Ismail Donmez wote: > Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: > > Thiago Macieira wrote: > > > But far more interesting would be if Google stopped blacklisting > > > Konqueror. > > > > I know I will sound stupid here: but what features of Google are not > > working due to this backlist? > > Non-ascii search. Sorry for my incompetence in this matter, but why does Google treat Konqueror in that way? Perhaps it's not backlisting, but a Google bug? Cheers, Frans From ismail at pardus.org.tr Sat Mar 11 19:50:01 2006 From: ismail at pardus.org.tr (Ismail Donmez) Date: Sat, 11 Mar 2006 21:50:01 +0200 Subject: Google search payment In-Reply-To: <200603111959.55284.frans.englich@telia.com> References: <200603111036.15559.ivor@ivor.org> <200603112124.27649.ismail@pardus.org.tr> <200603111959.55284.frans.englich@telia.com> Message-ID: <200603112150.01753.ismail@pardus.org.tr> Cumartesi 11 Mart 2006 21:59 tarihinde, Frans Englich şunları yazmıştı: > On Saturday 11 March 2006 19:24, Ismail Donmez wote: > > Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: > > > Thiago Macieira wrote: > > > > But far more interesting would be if Google stopped blacklisting > > > > Konqueror. > > > > > > I know I will sound stupid here: but what features of Google are not > > > working due to this backlist? > > > > Non-ascii search. > > Sorry for my incompetence in this matter, but why does Google treat > Konqueror in that way? Perhaps it's not backlisting, but a Google bug? It works if you change UA to Safari so they are blacklisting us. /ismail -- An eye for eye will make the whole world blind -- Gandhi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From frans.englich at telia.com Sat Mar 11 20:14:30 2006 From: frans.englich at telia.com (Frans Englich) Date: Sat, 11 Mar 2006 20:14:30 +0000 Subject: Google search payment In-Reply-To: <200603112150.01753.ismail@pardus.org.tr> References: <200603111036.15559.ivor@ivor.org> <200603111959.55284.frans.englich@telia.com> <200603112150.01753.ismail@pardus.org.tr> Message-ID: <200603112014.30857.frans.englich@telia.com> On Saturday 11 March 2006 19:50, Ismail Donmez wrote: > Cumartesi 11 Mart 2006 21:59 tarihinde, Frans Englich şunları yazmıştı: > > On Saturday 11 March 2006 19:24, Ismail Donmez wote: > > > Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: > > > > Thiago Macieira wrote: > > > > > But far more interesting would be if Google stopped blacklisting > > > > > Konqueror. > > > > > > > > I know I will sound stupid here: but what features of Google are not > > > > working due to this backlist? > > > > > > Non-ascii search. > > > > Sorry for my incompetence in this matter, but why does Google treat > > Konqueror in that way? Perhaps it's not backlisting, but a Google bug? > > It works if you change UA to Safari so they are blacklisting us. Has anyone tried doing something about it? Someone should contact Google and get insight why it is so, what can be done about it and so forth. Sounds like a KDE e.V matter. And if nothing else works /after/ a diplomatic approach have been attempted, blog about it(talk about censorship, controlling the market, etc, etc), and try to get a slashdot post out of it. Pressure on Google, in other words. Cheers, Frans From amantia at kde.org Sat Mar 11 21:08:37 2006 From: amantia at kde.org (Andras Mantia) Date: Sat, 11 Mar 2006 23:08:37 +0200 Subject: Google search payment References: <200603111036.15559.ivor@ivor.org> <200603112124.27649.ismail@pardus.org.tr> <20060311193242.9A1D63FA34@smtp.zappmobile.ro> <200603112143.15453.ismail@pardus.org.tr> Message-ID: <20060311210838.A541F40627@smtp.zappmobile.ro> Ismail Donmez wrote: > Cumartesi 11 Mart 2006 21:32 tarihinde, Andras Mantia şunları yazmıştı: >> Ismail Donmez wrote: >> > Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: >> >> Thiago Macieira wrote: >> >> > But far more interesting would be if Google stopped blacklisting >> >> > Konqueror. >> >> >> >> I know I will sound stupid here: but what features of Google are not >> >> working due to this backlist? >> > >> > Non-ascii search. >> >> Thanks. Altough the Hungarian (and Romanian) alphabet has non-ascii >> characters, I never realized this problem. Well, maybe I mostly search >> for English texts... > > Go to www.google.com.tr and search for €uro , now change your UA to Safari > and do the same. I did (copy/paste the text you wrote here) and I get the same result (and the same in Firefox as well). It ignores the € sign. The difference is in the search field inserts €uro for Konqueror (with both UA) and €uro in Firefox. Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From ismail at pardus.org.tr Sat Mar 11 21:24:43 2006 From: ismail at pardus.org.tr (Ismail Donmez) Date: Sat, 11 Mar 2006 23:24:43 +0200 Subject: Google search payment In-Reply-To: <20060311210838.A541F40627@smtp.zappmobile.ro> References: <200603111036.15559.ivor@ivor.org> <200603112143.15453.ismail@pardus.org.tr> <20060311210838.A541F40627@smtp.zappmobile.ro> Message-ID: <200603112324.43603.ismail@pardus.org.tr> Cumartesi 11 Mart 2006 23:08 tarihinde, Andras Mantia şunları yazmıştı: > Ismail Donmez wrote: > > Cumartesi 11 Mart 2006 21:32 tarihinde, Andras Mantia şunları yazmıştı: > >> Ismail Donmez wrote: > >> > Cumartesi 11 Mart 2006 21:23 tarihinde, Andras Mantia şunları yazmıştı: > >> >> Thiago Macieira wrote: > >> >> > But far more interesting would be if Google stopped blacklisting > >> >> > Konqueror. > >> >> > >> >> I know I will sound stupid here: but what features of Google are not > >> >> working due to this backlist? > >> > > >> > Non-ascii search. > >> > >> Thanks. Altough the Hungarian (and Romanian) alphabet has non-ascii > >> characters, I never realized this problem. Well, maybe I mostly search > >> for English texts... > > > > Go to www.google.com.tr and search for €uro , now change your UA to > > Safari and do the same. > > I did (copy/paste the text you wrote here) and I get the same result (and > the same in Firefox as well). It ignores the € sign. The difference is in > the search field inserts €uro for Konqueror (with both UA) and > €uro in Firefox. well I was talking about text field, sorry I wasn't clear. but it makes a usual guy think konqueror is buggy but its not. /ismail -- An eye for eye will make the whole world blind -- Gandhi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From amantia at kde.org Sat Mar 11 21:35:07 2006 From: amantia at kde.org (Andras Mantia) Date: Sat, 11 Mar 2006 23:35:07 +0200 Subject: Google search payment References: <200603111036.15559.ivor@ivor.org> <200603112143.15453.ismail@pardus.org.tr> <20060311210838.A541F40627@smtp.zappmobile.ro> <200603112324.43603.ismail@pardus.org.tr> Message-ID: <20060311213509.6ABE33E80B@smtp.zappmobile.ro> Ismail Donmez wrote: > well I was talking about text field, sorry I wasn't clear. but it makes a > usual guy think konqueror is buggy but its not. > Ok, but the text field for me was the same even if I change the user agent. I saw "Was" because now I see the difference. Andras -- Quanta Plus developer - http://quanta.sourceforge.net K Desktop Environment - http://www.kde.org From aseigo at kde.org Sat Mar 11 21:39:16 2006 From: aseigo at kde.org (Aaron J. Seigo) Date: Sat, 11 Mar 2006 14:39:16 -0700 Subject: Google search payment In-Reply-To: <200603112014.30857.frans.englich@telia.com> References: <200603111036.15559.ivor@ivor.org> <200603112150.01753.ismail@pardus.org.tr> <200603112014.30857.frans.englich@telia.com> Message-ID: <200603111439.17109.aseigo@kde.org> On Saturday 11 March 2006 13:14, Frans Englich wrote: > Has anyone tried doing something about it? yes, it's being worked on. such things take time and contrary to popular opinion in the geek circles ;) , google -is- a for-profit company and despite their love affair with open source still has all sorts of management structures and justification requirements that we have slowly wend our way through .... users of google giving them (polite) feedback on the matter would probably help of course -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 Full time KDE developer sponsored by Trolltech (http://www.trolltech.com) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ivor at ivor.org Sun Mar 12 08:32:13 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Sun, 12 Mar 2006 08:32:13 +0000 Subject: Apple radar Message-ID: <200603120832.13703.ivor@ivor.org> Hi, Can anyone with Apple radar access drop me a mail with details of what's in:- rdar://problem/4132581 ...and is there a testcase in there. Many thanks, -- Ivor Hewitt. From knutmj at online.no Sat Mar 11 22:07:31 2006 From: knutmj at online.no (Knut Morten Johansson) Date: Sat, 11 Mar 2006 23:07:31 +0100 Subject: Konqueror 3.5 branch is crashy Message-ID: <200603112307.31348.knutmj@online.no> Hi After a uppgrade of SVN 3.5 branch Konqueror has started to crash very frequently, nearly constantly on some sites. My previous update the 7th was stable, but yesterdays(10th) and succesive updates today are really bad. For instance linuxtoday.com are bad, it makes Konqueror crash fast. Strangely it looks more like it's about leaving a page not entering which causes the crashes. Going from LT to other sites makes it crash, reloads too. But it's not quite 100%, its more like 95. Browsing through LT pages makes it chras in 2-3 jumps. Backtrace below. Regards Knut Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1095654304 (LWP 14740)] [KCrash handler] #9 0x41b0bff9 in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #10 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #11 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #12 0x41b3b5a8 in DOM::HTMLFontElementImpl::~HTMLFontElementImpl () from /opt/lib/libkhtml.so.4 #13 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #14 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #15 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #16 0x41b39f97 in DOM::HTMLGenericElementImpl::~HTMLGenericElementImpl () from /opt/lib/libkhtml.so.4 #17 0x41b37f88 in DOM::HTMLDivElementImpl::~HTMLDivElementImpl () from /opt/lib/libkhtml.so.4 #18 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #19 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #20 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #21 0x41b600a8 in DOM::HTMLTableCellElementImpl::~HTMLTableCellElementImpl () from /opt/lib/libkhtml.so.4 #22 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #23 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #24 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #25 0x41b609a8 in DOM::HTMLTableRowElementImpl::~HTMLTableRowElementImpl () from /opt/lib/libkhtml.so.4 #26 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #27 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #28 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #29 0x41b5f388 in DOM::HTMLTableSectionElementImpl::~HTMLTableSectionElementImpl () from /opt/lib/libkhtml.so.4 #30 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #31 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #32 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #33 0x41b5ca48 in DOM::HTMLTableElementImpl::~HTMLTableElementImpl () from /opt/lib/libkhtml.so.4 #34 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #35 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #36 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #37 0x41b39ff8 in DOM::HTMLGenericElementImpl::~HTMLGenericElementImpl () from /opt/lib/libkhtml.so.4 #38 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #39 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #40 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #41 0x41b39ff8 in DOM::HTMLGenericElementImpl::~HTMLGenericElementImpl () from /opt/lib/libkhtml.so.4 #42 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #43 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #44 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #45 0x41b600a8 in DOM::HTMLTableCellElementImpl::~HTMLTableCellElementImpl () from /opt/lib/libkhtml.so.4 #46 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #47 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #48 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #49 0x41b609a8 in DOM::HTMLTableRowElementImpl::~HTMLTableRowElementImpl () from /opt/lib/libkhtml.so.4 #50 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #51 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #52 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #53 0x41b5f388 in DOM::HTMLTableSectionElementImpl::~HTMLTableSectionElementImpl () from /opt/lib/libkhtml.so.4 #54 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #55 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #56 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #57 0x41b5ca48 in DOM::HTMLTableElementImpl::~HTMLTableElementImpl () from /opt/lib/libkhtml.so.4 #58 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #59 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #60 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #61 0x41b39f97 in DOM::HTMLGenericElementImpl::~HTMLGenericElementImpl () from /opt/lib/libkhtml.so.4 #62 0x41b37f88 in DOM::HTMLDivElementImpl::~HTMLDivElementImpl () from /opt/lib/libkhtml.so.4 #63 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #64 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #65 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #66 0x41b3efaa in DOM::HTMLBodyElementImpl::~HTMLBodyElementImpl () from /opt/lib/libkhtml.so.4 #67 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #68 0x41b12b2e in DOM::ElementImpl::~ElementImpl () from /opt/lib/libkhtml.so.4 #69 0x41b38207 in DOM::HTMLElementImpl::~HTMLElementImpl () from /opt/lib/libkhtml.so.4 #70 0x41b42488 in DOM::HTMLHtmlElementImpl::~HTMLHtmlElementImpl () from /opt/lib/libkhtml.so.4 #71 0x41b0bffc in DOM::NodeBaseImpl::~NodeBaseImpl () from /opt/lib/libkhtml.so.4 #72 0x41b0573e in DOM::DocumentImpl::~DocumentImpl () from /opt/lib/libkhtml.so.4 #73 0x41b3e0c9 in DOM::HTMLDocumentImpl::~HTMLDocumentImpl () from /opt/lib/libkhtml.so.4 #74 0x41abeb1a in KHTMLPart::clear () from /opt/lib/libkhtml.so.4 #75 0x41abf03a in KHTMLPart::begin () from /opt/lib/libkhtml.so.4 #76 0x41ab1072 in KHTMLPart::slotData () from /opt/lib/libkhtml.so.4 #77 0x41ad13e0 in KHTMLPart::qt_invoke () from /opt/lib/libkhtml.so.4 #78 0x40c4d150 in QObject::activate_signal () from /opt/lib/qt/lib/libqt-mt.so.3 #79 0x4019812b in KIO::TransferJob::data () from /opt/lib/libkio.so.4 #80 0x4019818d in KIO::TransferJob::slotData () from /opt/lib/libkio.so.4 #81 0x40199e66 in KIO::TransferJob::qt_invoke () from /opt/lib/libkio.so.4 #82 0x40c4d150 in QObject::activate_signal () from /opt/lib/qt/lib/libqt-mt.so.3 #83 0x40181814 in KIO::SlaveInterface::data () from /opt/lib/libkio.so.4 #84 0x4018563a in KIO::SlaveInterface::dispatch () from /opt/lib/libkio.so.4 #85 0x40183acd in KIO::SlaveInterface::dispatch () from /opt/lib/libkio.so.4 #86 0x4017dcfe in KIO::Slave::gotInput () from /opt/lib/libkio.so.4 #87 0x4017ebec in KIO::Slave::qt_invoke () from /opt/lib/libkio.so.4 #88 0x40c4d150 in QObject::activate_signal () from /opt/lib/qt/lib/libqt-mt.so.3 #89 0x40c4d6b7 in QObject::activate_signal () from /opt/lib/qt/lib/libqt-mt.so.3 #90 0x40f718c8 in QSocketNotifier::activated () from /opt/lib/qt/lib/libqt-mt.so.3 #91 0x40c67aa1 in QSocketNotifier::event () from /opt/lib/qt/lib/libqt-mt.so.3 #92 0x40becef4 in QApplication::internalNotify () from /opt/lib/qt/lib/libqt-mt.so.3 #93 0x40bed0dd in QApplication::notify () from /opt/lib/qt/lib/libqt-mt.so.3 #94 0x4078e113 in KApplication::notify () from /opt/lib/libkdecore.so.4 #95 0x40be0f0c in QEventLoop::activateSocketNotifiers () from /opt/lib/qt/lib/libqt-mt.so.3 #96 0x40b9bb80 in QEventLoop::processEvents () from /opt/lib/qt/lib/libqt-mt.so.3 #97 0x40c020cc in QEventLoop::enterLoop () from /opt/lib/qt/lib/libqt-mt.so.3 #98 0x40c02024 in QEventLoop::exec () from /opt/lib/qt/lib/libqt-mt.so.3 #99 0x40bec120 in QApplication::exec () from /opt/lib/qt/lib/libqt-mt.so.3 #100 0x41641c12 in kdemain () from /opt/lib/libkdeinit_konqueror.so #101 0x415d38e0 in kdeinitmain () from /opt/lib/kde3/konqueror.so #102 0x0804e20b in launch () #103 0x0804e9a6 in handle_launcher_request () #104 0x0804ef08 in handle_requests () #105 0x0804f68d in main () From patrol at sinus.cz Sun Mar 12 10:22:15 2006 From: patrol at sinus.cz (Pavel Troller) Date: Sun, 12 Mar 2006 11:22:15 +0100 Subject: Konqueror 3.5 branch is crashy In-Reply-To: <200603112307.31348.knutmj@online.no> References: <200603112307.31348.knutmj@online.no> Message-ID: <20060312102215.GA23120@tangens.sinus.cz> > Hi > > After a uppgrade of SVN 3.5 branch Konqueror has started to crash very > frequently, nearly constantly on some sites. > > My previous update the 7th was stable, but yesterdays(10th) and succesive > updates today are really bad. For instance linuxtoday.com are bad, it makes > Konqueror crash fast. Strangely it looks more like it's about leaving a page > not entering which causes the crashes. Going from LT to other sites makes it > crash, reloads too. But it's not quite 100%, its more like 95. Browsing > through LT pages makes it chras in 2-3 jumps. Backtrace below. > > Regards > Knut > Hi! The same appears here. I'm glad that I'm not only one. There are Czech pages which make konq crash with about 25% probability on pressing the Back button or reloading the page. It crashes very quickly - no rendering attempt occurs yet. I cannot supply the backtrace (no debug) but the symptoms are very close to yours so I think it's the same. Observed from yesterday's update. A week old konq/khtml was stable as a rock. With regards, Pavel Troller From lucardus at onlinehome.de Sun Mar 12 12:48:34 2006 From: lucardus at onlinehome.de (Stephan Johach) Date: Sun, 12 Mar 2006 13:48:34 +0100 Subject: Konqueror 3.5 branch is crashy In-Reply-To: <20060312102215.GA23120@tangens.sinus.cz> References: <200603112307.31348.knutmj@online.no> <20060312102215.GA23120@tangens.sinus.cz> Message-ID: <200603121348.34487.lucardus@onlinehome.de> Am Sonntag, 12. März 2006 11:22 schrieb Pavel Troller: > The same appears here. I'm glad that I'm not only one. There are Czech > pages which make konq crash with about 25% probability on pressing the Back > button or reloading the page. It crashes very quickly - no rendering > attempt occurs yet. I cannot supply the backtrace (no debug) but the > symptoms are very close to yours so I think it's the same. > Observed from yesterday's update. A week old konq/khtml was stable as a > rock. With regards, Pavel Troller Same here. I already filed a bug report yesterday. https://bugs.kde.org/show_bug.cgi?id=123433 I did a complete rebuild of kdelibs/kdebase. But going to linuxtoday.com and pressing the back button triggers the crash. I am not good at exploring valgrind output but even valgrind seems to assert when hitting the back button. See the attachment of my bugreport. I seems to me this is a real show stopper bug. Stephan From ivor at ivor.org Sun Mar 12 12:50:26 2006 From: ivor at ivor.org (Ivor Hewitt) Date: Sun, 12 Mar 2006 12:50:26 +0000 Subject: Konqueror 3.5 branch is crashy In-Reply-To: <200603121348.34487.lucardus@onlinehome.de> References: <200603112307.31348.knutmj@online.no> <20060312102215.GA23120@tangens.sinus.cz> <200603121348.34487.lucardus@onlinehome.de> Message-ID: <200603121250.29085.ivor@ivor.org> On Sunday 12 March 2006 12:48, Stephan Johach wrote: > Am Sonntag, 12. März 2006 11:22 schrieb Pavel Troller: > > The same appears here. I'm glad that I'm not only one. There are Czech > > pages which make konq crash with about 25% probability on pressing the > > Back button or reloading the page. It crashes very quickly - no rendering > > attempt occurs yet. I cannot supply the backtrace (no debug) but the > > symptoms are very close to yours so I think it's the same. > > Observed from yesterday's update. A week old konq/khtml was stable as a > > rock. With regards, Pavel Troller > > Same here. I already filed a bug report yesterday. > > https://bugs.kde.org/show_bug.cgi?id=123433 > > I did a complete rebuild of kdelibs/kdebase. But going to > linuxtoday.com and pressing the back button triggers the crash. > > I am not good at exploring valgrind output but even valgrind seems > to assert when hitting the back button. See the attachment of my > bugreport. I seems to me this is a real show stopper bug. > I'm in the middle of a huge rework of that code at the moment so I'll investigate. -- Ivor Hewitt. From maksim at kde.org Sun Mar 12 14:41:48 2006 From: maksim at kde.org (Maks Orlovich) Date: Sun, 12 Mar 2006 09:41:48 -0500 Subject: Google search payment In-Reply-To: <20060311210838.A541F40627@smtp.zappmobile.ro> References: <200603111036.15559.ivor@ivor.org> <200603112143.15453.ismail@pardus.org.tr> <20060311210838.A541F40627@smtp.zappmobile.ro> Message-ID: <200603120941.48846.maksim@kde.org> > I did (copy/paste the text you wrote here) and I get the same result (and > the same in Firefox as well). It ignores the € sign. The difference is in > the search field inserts €uro for Konqueror (with both UA) and > €uro in Firefox. That's not the only difference. If you try to test e.g. for Russian text, google will say "The summary for this Russian page contains characters that cannot be correctly displayed in this language/character set." in place of summaries. From maksim at kde.org Sun Mar 12 14:44:30 2006 From: maksim at kde.org (Maks Orlovich) Date: Sun, 12 Mar 2006 09:44:30 -0500 Subject: Konqueror 3.5 branch is crashy In-Reply-To: <200603112307.31348.knutmj@online.no> References: <200603112307.31348.knutmj@online.no> Message-ID: <200603120944.30118.maksim@kde.org> On Saturday 11 March 2006 17:07, Knut Morten Johansson wrote: > Hi > > After a uppgrade of SVN 3.5 branch Konqueror has started to crash very > frequently, nearly constantly on some sites. Hi. I committed what sould be a fix. Please test. Thanks a lot for this report. From D.H.J.Takken at phys.uu.nl Sun Mar 12 15:55:33 2006 From: D.H.J.Takken at phys.uu.nl (Dik Takken) Date: Sun, 12 Mar 2006 16:55:33 +0100 (CET) Subject: Konqueror makes FAM / Gamin go nuts In-Reply-To: References: Message-ID: Ok, I did some more investigation, and I found that Konq is not the only process that can drive Gamin to insanity. Kile can do it too. Maybe any KDE application that watches files can cause problems?? I also found that when Gamin goes nuts, .xsession-errors contains lots and lots of these messages: end from FAM server connection invalid length 24902 invalid length 24902 invalid length 24902 invalid length 24902 end from FAM server connection invalid length 24902 invalid length 24902 invalid length 24902 invalid length 24902 What process is producing these messages? On Sat, 11 Mar 2006, Dik Takken wrote: > Hi, > > Until just a few weeks ago, I used FAM for file access notification. The > problem with FAM was that when you were watching a directory with files that > change very quickly, FAM could go nuts and start consuming all available CPU. > Another nasty thing was that FAM was running as root, so users could not kill > it in case of emergency. > > I recently heard about Gamin, the replacement for FAM that can use INotify of > recent kernels. Unfortunately the problem of high CPU consumption returned. > Now it happens from time to time that Gamin starts consuming lots of CPU for > no clear reason whatsoever. The strange thing is that even a Konqueror window > that displays a static set of files can trigger nuttyness in Gamin. I draw > this conclusion from the fact that the madness stops when I close a konqueror > window with static files in it, and the fact that I configured Konqueror to > use one independent process for every window. > > Another observation: Killing Gamin does not always help. A new Gamin process > is started, which happily continues wasting CPU. It only stops when the right > Konqueror window is closed. > > How can I investigate what is going on? Is this a known problem? > > Using KDE 3.5.1 by the way. > > Cheers, > > Dik > ----------------------------------------------------------------- From lucardus at onlinehome.de Sun Mar 12 16:13:06 2006 From: lucardus at onlinehome.de (Stephan Johach) Date: Sun, 12 Mar 2006 17:13:06 +0100 Subject: Konqueror 3.5 branch is crashy In-Reply-To: <200603120944.30118.maksim@kde.org> References: <200603112307.31348.knutmj@online.no> <200603120944.30118.maksim@kde.org> Message-ID: <200603121713.07087.lucardus@onlinehome.de> Am Sonntag, 12. März 2006 15:44 schrieb Maks Orlovich: > On Saturday 11 March 2006 17:07, Knut Morten Johansson wrote: > > Hi > > > > After a uppgrade of SVN 3.5 branch Konqueror has started to crash very > > frequently, nearly constantly on some sites. > > Hi. I committed what sould be a fix. Please test. Thanks a lot for this > report. The memory corruption seems to have vanished now but there's one more valgrind output which looks suspicious. --17770-- Reading syms from /usr/X11R6/lib/X11/locale/lib/common/xomGeneric.so.2 (0x7745000) ==17770== Conditional jump or move depends on uninitialised value(s) ==17770== at 0x6D18143: KHTMLPart::clear() (in /opt/kde-3.5/lib/libkhtml.so.4.2.0) ==17770== by 0x6D1B284: KHTMLPart::begin(KURL const&, int, int) (in /opt/kde-3.5/lib/libkhtml.so.4.2.0) ==17770== by 0x6D18EA5: KHTMLPart::slotData(KIO::Job*, QMemArray const&) (in /opt/kde-3.5/lib/libkhtml.so.4.2.0) ==17770== by 0x6D3C73A: KHTMLPart::qt_invoke(int, QUObject*) (in /opt/kde-3.5/lib/libkhtml.so.4.2.0) ==17770== by 0x4EB035B: QObject::activate_signal(QConnectionList*, QUObject*) (in /opt/qt-3.3.3/lib/libqt-mt.so.3.3.3) ==17770== by 0x43B52C3: KIO::TransferJob::data(KIO::Job*, QMemArray const&) (in /opt/kde-3.5/lib/libkio.so.4.2.0) ==17770== by 0x439D1B2: KIO::TransferJob::slotData(QMemArray const&) (in /opt/kde-3.5/lib/libkio.so.4.2.0) ==17770== by 0x43B5813: KIO::TransferJob::qt_invoke(int, QUObject*) (in /opt/kde-3.5/lib/libkio.so.4.2.0) ==17770== by 0x4EB035B: QObject::activate_signal(QConnectionList*, QUObject*) (in /opt/qt-3.3.3/lib/libqt-mt.so.3.3.3) ==17770== by 0x438AAC9: KIO::SlaveInterface::data(QMemArray const&) (in /opt/kde-3.5/lib/libkio.so.4.2.0) ==17770== by 0x4386F65: KIO::SlaveInterface::dispatch(int, QMemArray const&) (in /opt/kde-3.5/lib/libkio.so.4.2.0) ==17770== by 0x4386C9F: KIO::SlaveInterface::dispatch() (in /opt/kde-3.5/lib/libkio.so.4.2.0) From lucardus at onlinehome.de Sun Mar 12 16:21:34 2006 From: lucardus at onlinehome.de (Stephan Johach) Date: Sun, 12 Mar 2006 17:21:34 +0100 Subject: Konqueror 3.5 branch is crashy In-Reply-To: <200603121713.07087.lucardus@onlinehome.de> References: <200603112307.31348.knutmj@online.no> <200603120944.30118.maksim@kde.org> <200603121713.07087.lucardus@onlinehome.de> Message-ID: <200603121721.34216.lucardus@onlinehome.de> Am Sonntag, 12. März 2006 17:13 schrieb Stephan Johach: > Am Sonntag, 12. März 2006 15:44 schrieb Maks Orlovich: One question. Is it due to missing debug symbols that there's only the function in the output of valgrind but not the relevant line? If so I' ll probably forgot to set --enable-debug=full. Will do if you have problems to detect the exact line. Stephan From patrol at sinus.cz Sun Mar 12 21:16:16 2006 From: patrol at sinus.cz (Pavel Troller) Date: Sun, 12 Mar 2006 22:16:16 +0100 Subject: Konqueror 3.5 branch is crashy In-Reply-To: <200603120944.30118.maksim@kde.org> References: <200603112307.31348.knutmj@online.no> <200603120944.30118.maksim@kde.org> Message-ID: <20060312211616.GA28785@tangens.sinus.cz> > On Saturday 11 March 2006 17:07, Knut Morten Johansson wrote: > > Hi > > > > After a uppgrade of SVN 3.5 branch Konqueror has started to crash very > > frequently, nearly constantly on some sites. > > Hi. I committed what sould be a fix. Please test. Thanks a lot for this > report. Hi! I just updated kdelibs and tested on the pages which were crashing. No crash observed even with extensive using of Back button and page reloading. It looks that the fix really works :-). With regards, Pavel Troller From kevin.krammer at gmx.at Sun Mar 12 21:38:08 2006 From: kevin.krammer at gmx.at (Kevin Krammer) Date: Sun, 12 Mar 2006 22:38:08 +0100 Subject: Flash using Gnash for KDE = Klash In-Reply-To: <20060301131439.GI90960@xs4all.nl> References: <20060301131439.GI90960@xs4all.nl> Message-ID: <200603122238.08873.kevin.krammer@gmx.at> On Wednesday 01 March 2006 14:14, Koos Vriezen wrote: > Hi, > > AFAICS there isn't a plugin for konqueror using Gnash for flash, so I > created one. It's now located at > www.xs4all.nl/~jjvrieze/klash-0.0.1.tar.bz2 with even a debian > directory. Read the README for building the gnash thing. > > Please give some comments (hopefully not that it's already there). > It should be rather stable, though plain and simple. Please note that > Gnash uses openGL and hardly works w/ remote X clients. It seems to be in gnash's CVS now as well. Is this the latest version? Using the attached patch should make it compilable with --disable-plugin --enable-klash For testing I removed the Adobe/Macromedia plugin completely and used the userfriendly.org animation archive as a source for flash. Klash plugin gets loaded flawlessly but playback flickers a lot. In the second animation, where Steff is fighting gladiator-like in an arena, I can see him being drawn with white shirt and tie before the armor is drawn over it on every move he makes. (gnash standalone works visually but has no sound) Cheers, Kevin -- Kevin Krammer Qt/KDE Developer, Debian User Moderator: www.mrunix.de (German), www.qtcentre.org -------------- next part -------------- A non-text attachment was scrubbed... Name: gnash.diff Type: text/x-diff Size: 2244 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From hausmann at kde.org Sun Mar 12 21:34:50 2006 From: hausmann at kde.org (Simon Hausmann) Date: Sun, 12 Mar 2006 22:34:50 +0100 Subject: patch: khtml text selection with complex text Message-ID: <200603122234.50714.hausmann@kde.org> Hi, text selection with complex text is currently broken in khtml, because khtml draws the selected text as a separate string, breaking it apart at invalid positions. You can see that easily on web sites with arabic text for example. The only solution to that problem is unfortunately to draw the run of text that is part of the beginning or the end of the selection twice, once unselected and once selected with a clip rectangle set. The clipping is necessary as there may be valid cursor positions inside a ligature. Attached is my attempt at implementing this. Would be cool if somebody could comment on the patch, or perhaps even approve it :) Thanks, Simon -------------- next part -------------- Index: render_text.cpp =================================================================== --- render_text.cpp (revision 517934) +++ render_text.cpp (working copy) @@ -140,10 +140,29 @@ p->setPen(hc); //kdDebug( 6040 ) << "textRun::painting(" << QConstString(text->str->s + m_start, m_len).string().left(30) << ") at(" << m_x+tx << "/" << m_y+ty << ")" << endl; + + p->save(); + + int visualSelectionStart = f->width(text->str->s, text->str->l, m_start, startPos); + int visualSelectionEnd = f->width(text->str->s, text->str->l, m_start, endPos); + int visualSelectionWidth = visualSelectionEnd - visualSelectionStart; + if (m_reversed) { + visualSelectionStart = f->width(text->str->s, text->str->l, m_start, m_len) - visualSelectionEnd; + } + + QRect selectionRect(m_x + tx + visualSelectionStart, m_y + ty, visualSelectionWidth, height()); + QRegion r(selectionRect); + if (p->hasClipping()) + r &= p->clipRegion(QPainter::CoordPainter); + p->setClipRegion(r, QPainter::CoordPainter); + p->fillRect(selectionRect, hbg); + f->drawText(p, m_x + tx, m_y + ty + m_baseline, text->str->s, text->str->l, - m_start, m_len, m_toAdd, - m_reversed ? QPainter::RTL : QPainter::LTR, - startPos, endPos, hbg, m_y + ty, height(), deco); + m_start, m_len, m_toAdd, + m_reversed ? QPainter::RTL : QPainter::LTR, + -1, -1, hbg, m_y + ty, height(), deco); + + p->restore(); } void InlineTextBox::paintDecoration( QPainter *pt, const Font *f, int _tx, int _ty, int deco) @@ -923,54 +942,13 @@ #endif if (s->m_len > 0 && pI.phase != PaintActionSelection) { - if (!haveSelection) { - //kdDebug( 6040 ) << "RenderObject::paintObject(" << QConstString(str->s + s->m_start, s->m_len).string() << ") at(" << s->m_x+tx << "/" << s->m_y+ty << ")" << endl; -#ifndef APPLE_CHANGES - if (_style->textShadow()) - s->paintShadow(pI.p, font, tx, ty, _style->textShadow()); -#endif + //kdDebug( 6040 ) << "RenderObject::paintObject(" << QConstString(str->s + s->m_start, s->m_len).string() << ") at(" << s->m_x+tx << "/" << s->m_y+ty << ")" << endl; + if (_style->textShadow()) + s->paintShadow(pI.p, font, tx, ty, _style->textShadow()); // kdDebug(6040) << QConstString(str->s + s->m_start, s->m_len).string().left(40) << endl; - font->drawText(pI.p, s->m_x + tx, s->m_y + ty + s->m_baseline, str->s, str->l, s->m_start, s->m_len, - s->m_toAdd, s->m_reversed ? QPainter::RTL : QPainter::LTR); - } - else { - int offset = s->m_start; - int sPos = kMax( startPos - offset, 0 ); - int ePos = kMin( endPos - offset, int( s->m_len ) ); -// selected text is always separate in konqueror -#ifdef APPLE_CHANGES - if (paintSelectedTextSeparately) { -#endif -#ifndef APPLE_CHANGES - if (_style->textShadow()) - s->paintShadow(pI.p, font, tx, ty, _style->textShadow()); -#endif - if (sPos >= ePos) - font->drawText(pI.p, s->m_x + tx, s->m_y + ty + s->m_baseline, - str->s, str->l, s->m_start, s->m_len, - s->m_toAdd, s->m_reversed ? QPainter::RTL : QPainter::LTR); - else { - if (sPos-1 >= 0) - font->drawText(pI.p, s->m_x + tx, s->m_y + ty + s->m_baseline, - str->s, str->l, s->m_start, s->m_len, - s->m_toAdd, s->m_reversed ? QPainter::RTL : QPainter::LTR, 0, sPos); - if (ePos < s->m_len) - font->drawText(pI.p, s->m_x + tx, s->m_y + ty + s->m_baseline, - str->s, str->l, s->m_start, s->m_len, - s->m_toAdd, s->m_reversed ? QPainter::RTL : QPainter::LTR, ePos, s->m_len); - } -#ifdef APPLE_CHANGES - } - - if ( sPos < ePos ) { - if (selectionColor != p->pen().color()) - p->setPen(selectionColor); - - font->drawText(pI.p, s->m_x + tx, s->m_y + ty + s->m_baseline, str->s, - str->l, s->m_start, s->m_len, - s->m_toAdd, s->m_reversed ? QPainter::RTL : QPainter::LTR, sPos, ePos); - } -#endif + if (!haveSelection || startPos != s->m_start || endPos != s->m_start + s->m_len) { + font->drawText(pI.p, s->m_x + tx, s->m_y + ty + s->m_baseline, str->s, str->l, s->m_start, s->m_len, + s->m_toAdd, s->m_reversed ? QPainter::RTL : QPainter::LTR); } } From emanuele at valinor.it Sun Mar 12 22:03:58 2006 From: emanuele at valinor.it (Emanuele Tamponi) Date: Sun, 12 Mar 2006 23:03:58 +0100 Subject: Flash using Gnash for KDE = Klash In-Reply-To: <200603122238.08873.kevin.krammer@gmx.at> References: <20060301131439.GI90960@xs4all.nl> <200603122238.08873.kevin.krammer@gmx.at> Message-ID: <200603122303.58841.emanuele@valinor.it> I've just compiled and installed klash but Flash videos are rendered outside the page, in "popup" windows... I used the package linked in the post Alle Sunday 12 March 2006 22:38, Kevin Krammer ha scritto: > On Wednesday 01 March 2006 14:14, Koos Vriezen wrote: > > Hi, > > > > AFAICS there isn't a plugin for konqueror using Gnash for flash, so I > > created one. It's now located at > > www.xs4all.nl/~jjvrieze/klash-0.0.1.tar.bz2 with even a debian > > directory. Read the README for building the gnash thing. > > > > Please give some comments (hopefully not that it's already there). > > It should be rather stable, though plain and simple. Please note that > > Gnash uses openGL and hardly works w/ remote X clients. From knutmj at online.no Sun Mar 12 21:01:05 2006 From: knutmj at online.no (Knut Morten Johansson) Date: Sun, 12 Mar 2006 22:01:05 +0100 Subject: Konqueror 3.5 branch is crashy Message-ID: <200603122201.05932.knutmj@online.no> On Sunday 12 March 2006 14:44, Maks Orlovich wrote: >On Saturday 11 March 2006 17:07, Knut Morten Johansson wrote: >> Hi >> >> After a uppgrade of SVN 3.5 branch Konqueror has started to crash very > >frequently, nearly constantly on some sites. > >Hi. I committed what sould be a fix. Please test. Hi. I have not observed any crashes after updating, browsing the same sites. So for me I'd say the fix works, thanks. Regards Knut BTW: The crashing made me give the crashes plugin a real workout, that's one increadible nice feature:-) From rhkramer at gmail.com Mon Mar 13 14:48:24 2006 From: rhkramer at gmail.com (Randy Kramer) Date: Mon, 13 Mar 2006 09:48:24 -0500 Subject: RFE for khtml--where to file? (Vertical alignment of last page when paging with pageup/pagedown) Message-ID: <200603130948.26167.rhkramer@gmail.com> I want to submit an RFE for khtml (at least, I think that's what it should be applied to--I'll describe the request below)--it seems that there is no "major category" for khtml in kde's bugzilla (or did I miss something?), but instead there are khtml sub-categories under things like konqueror, quanta (iirc), kfm(??), kmail, and probably others. The RFE is (for me) most directly applicable to konqueror and for an application I'd like to build which I think (based on my limited knowledge at this point) will use the khtml part without konqueror--should I file it under the khtml sub-category for konqueror or is there some better place? (Aside: I also want the same behavior in kmail.) One reason I ask is that bug 93196 (http://bugs.kde.org/show_bug.cgi?id=93196), which *could* be an alternate solution to my problem, was closed as invalid, presumably because it was filed against the wrong component (kdelib instead of khtml). I'd like to make sure I get the request in the right place. (Over on bug 76082 there is some speculation about other reasons bug 93196 might have been closed.) The request is this (I want to make this as concise and clear as possible--suggestions welcome): Title: Make khtml pageup/pagedown vertical alignment the same for the last page as all other pages of a long web page. Description: In most cases, when you use pageup/pagedown to "scroll" through a long web page, after each pagedown (except the last) the text is vertically aligned so that the last line or two from the previous page are repeated as the 1st line or two of the next page (and the next line to read is the 2nd or third line), in other words there is some overlap. This makes it easy for your eyes to find where you left off and resume reading. (And, if you had a lapse of attention while paging, there is some context on the page to help you remember what you were reading.) (I'm guessing that the overlap is a certain number of pixels, and thus the number of lines of text repeated depends on the size of the font?) I may file other RFEs related to this one: * I'd prefer that the overlap be a certain number of lines rather than a certain number of pixels (I'd vote for two). Because the overlap appears to be expressed in pixels, sometimes the overlap includes partial lines of text, in other words, you don't see the full height of the characters/glyphs(??). * at least one webpage/URL that I've seen recently didn't work as described, instead a line of text was missed--it wasn't visible at the bottom of one page nor at the top of the next--I had to scroll up "manually" to find the missing line--I'll include that URL when I submit the RFE or a separate bug On the last page, this does not happen, the page is aligned so that the end of the "text" is at the bottom of the screen, and the last line from the previous page is somewhere on the page, but not at a consistent location. My request is that the behavior on the last page be changed so that the next line to read is 2nd or 3rd from the top, just like all the other pages. Of course, in that case the last page will not fill the entire frame, and a decision would have to be made about how to render the bottom of that last page. I can imagine a number of alternatives, but I'm not sure that I know enough at this point to say that any of them would be unacceptable--maybe the developer that works on this wants to propose what is the best and/or easiest solution to see if there are any immediate or obvious objections. Some of the approaches I can think of: * just fill out the remainder of the page with white space * like above, but add a horizontal rule to mark the actual end of the page * vertically shrink the frame to enclose just the remaining text on the page (this does not sound so good to me, but I wouldn't think it's the easiest, either, so hopefully it won't be considered) * ??? There are other things I might mention in the RFE, but they may confuse the issue: * I note that the two different methods of paging through a long document (pageup/pagedown vs. clicking above or below the elevator on the vertical scrollbar) behave slightly differently--the pageup/pagedown approach repeats (as described) the last line (or two) of the previous page at the top of the next page, while the click above or below the elevator bar seems to move precisely a page, with no repeat of lines of text from the previous page. I'm not sure there is a reason for this difference in behavior, but nor do I have any problem with it--I prefer to use the pageup/pagedown method of scrolling (in most cases), and will be happy if this RFE is applied to the pageup/pagedown method of scrolling. * I've mentioned pageup but have been focusing on pagedown--without getting into detail, pageup should move back in a manner similar to the way pagedown moves forward (i.e., leaving a line or two of overlap on each pageup). But, for the first page, I don't know if there is any need to align the text so precisely as I'd like when downloading to the last page--at first thought it seems that: * when you are paging backward (towards the top of the document) you are not serially reading, but instead skimming backward to find something * that it makes little or no sense to page so that the beginning of the web page starts partway down the page with leading whitespace I'll experiment with that some more before filing the RFE. Thanks, Randy Kramer From kde at carewolf.com Mon Mar 13 15:45:21 2006 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 13 Mar 2006 16:45:21 +0100 Subject: content-disposition in HTTP headers In-Reply-To: <200603111734.40803.kde@carewolf.com> References: <200603111734.40803.kde@carewolf.com> Message-ID: <200603131645.22174.kde@carewolf.com> Ok. Further testing showed that content-disposition: attachment is indeed not honoured, but my patch didn't fix it either. I've reopened bug #31662 (http://bugs.kde.org/show_bug.cgi?id=31662) The attached patch is updated and fixes the bug as far as I can tell, and should be safe for KDE 3.5.2. content-disposition headers are still not cached though. Regards `Allan -------------- next part -------------- A non-text attachment was scrubbed... Name: contentdisposition.diff Type: text/x-diff Size: 9851 bytes Desc: not available URL: From rob-sW7atkIuDv7Hxnf+QNSuNQ at public.gmane.org Mon Mar 13 16:29:24 2006 From: rob-sW7atkIuDv7Hxnf+QNSuNQ at public.gmane.org (Rob Savoye) Date: Mon, 13 Mar 2006 09:29:24 -0700 Subject: Flash using Gnash for KDE = Klash In-Reply-To: <200603122238.08873.kevin.krammer-RbZlAiThDcE@public.gmane.org> References: <20060301131439.GI90960@xs4all.nl> <200603122238.08873.kevin.krammer@gmx.at> Message-ID: <44159DE4.6000805@welcomehome.org> Kevin Krammer wrote: > It seems to be in gnash's CVS now as well. Is this the latest version? Yes, it was contributed. This is the same code, but I merged the configure/build stuff into the existing support so it'd fit into Gnash better. > Klash plugin gets loaded flawlessly but playback flickers a lot. In the second > animation, where Steff is fighting gladiator-like in an arena, I can see him > being drawn with white shirt and tie before the armor is drawn over it on > every move he makes. Needless to say, while Gnash plays many Flash movies, it doesn't do all of them correctly. I haven't seen the flickering, but I'm mostly deep in debugging the real plugin, and have mostly been using the MozPlugger support in Firefox otherwise. > (gnash standalone works visually but has no sound) Sound is being worked on. There was minimal sound support, but it's being rewritten to work more the way it's supposed to. There are also unfortunately issues with the legalities of MP3 support. - rob - From bero-9zdaV+82baBg9hUCZPvPmw at public.gmane.org Mon Mar 13 18:41:03 2006 From: bero-9zdaV+82baBg9hUCZPvPmw at public.gmane.org (Bernhard Rosenkraenzer) Date: Mon, 13 Mar 2006 19:41:03 +0100 Subject: Flash using Gnash for KDE = Klash In-Reply-To: <44159DE4.6000805-sW7atkIuDv7Hxnf+QNSuNQ@public.gmane.org> References: <20060301131439.GI90960@xs4all.nl> <200603122238.08873.kevin.krammer@gmx.at> <44159DE4.6000805@welcomehome.org> Message-ID: <200603131941.04065.bero@arklinux.org> On Monday, 13. March 2006 17:29, Rob Savoye wrote: > Sound is being worked on. There was minimal sound support, but it's > being rewritten to work more the way it's supposed to. There are also > unfortunately issues with the legalities of MP3 support. That can be "fixed" by using ffmpeg (or a similar library) to decode it -- since the ffmpeg API is the same for any codec, it's the user's "fault" if he enabled mp3 support in ffmpeg, given ffmpeg was, of course, invoked only to decode Ogg/Vorbis and raw audio. Regards, bero From tomasgroth-KK7TH6PgNEI at public.gmane.org Mon Mar 13 18:58:43 2006 From: tomasgroth-KK7TH6PgNEI at public.gmane.org (Tomas Groth) Date: Mon, 13 Mar 2006 19:58:43 +0100 (CET) Subject: Flash using Gnash for KDE = Klash In-Reply-To: <200603131941.04065.bero-9zdaV+82baBg9hUCZPvPmw@public.gmane.org> References: <200603131941.04065.bero@arklinux.org> Message-ID: <20060313185843.26367.qmail@web34711.mail.mud.yahoo.com> --- Bernhard Rosenkraenzer skrev: > On Monday, 13. March 2006 17:29, Rob Savoye wrote: > > Sound is being worked on. There was minimal sound support, but it's > > being rewritten to work more the way it's supposed to. There are also > > unfortunately issues with the legalities of MP3 support. > > That can be "fixed" by using ffmpeg (or a similar library) to decode it -- > since the ffmpeg API is the same for any codec, it's the user's "fault" if he > > enabled mp3 support in ffmpeg, given ffmpeg was, of course, invoked only to > decode Ogg/Vorbis and raw audio. > We've choosen to use gstreamer (0.10) for the new "system" instead, since there is a legal mp3-decoding plugin available for free. Hopefully the new sound-system will be finish in a not so distant future, but i'm having a few issues with gstreamer... cheers, Tomas From koos.vriezen at xs4all.nl Mon Mar 13 19:20:01 2006 From: koos.vriezen at xs4all.nl (Koos Vriezen) Date: Mon, 13 Mar 2006 20:20:01 +0100 Subject: Flash using Gnash for KDE = Klash In-Reply-To: <200603122303.58841.emanuele@valinor.it> References: <20060301131439.GI90960@xs4all.nl> <200603122238.08873.kevin.krammer@gmx.at> <200603122303.58841.emanuele@valinor.it> Message-ID: <20060313192001.GC86364@xs4all.nl> On Sun, Mar 12, 2006 at 11:03:58PM +0100, Emanuele Tamponi wrote: > I've just compiled and installed klash but Flash videos are rendered outside > the page, in "popup" windows... I used the package linked in the post You need a recent, like newer than my posting, gnash CVS checkout. Koos > Alle Sunday 12 March 2006 22:38, Kevin Krammer ha scritto: > > On Wednesday 01 March 2006 14:14, Koos Vriezen wrote: > > > Hi, > > > > > > AFAICS there isn't a plugin for konqueror using Gnash for flash, so I > > > created one. It's now located at > > > www.xs4all.nl/~jjvrieze/klash-0.0.1.tar.bz2 with even a debian > > > directory. Read the README for building the gnash thing. > > > > > > Please give some comments (hopefully not that it's already there). > > > It should be rather stable, though plain and simple. Please note that > > > Gnash uses openGL and hardly works w/ remote X clients. From koos.vriezen at xs4all.nl Mon Mar 13 19:31:36 2006 From: koos.vriezen at xs4all.nl (Koos Vriezen) Date: Mon, 13 Mar 2006 20:31:36 +0100 Subject: Flash using Gnash for KDE = Klash In-Reply-To: <200603122238.08873.kevin.krammer@gmx.at> References: <20060301131439.GI90960@xs4all.nl> <200603122238.08873.kevin.krammer@gmx.at> Message-ID: <20060313193136.GD86364@xs4all.nl> On Sun, Mar 12, 2006 at 10:38:08PM +0100, Kevin Krammer wrote: > On Wednesday 01 March 2006 14:14, Koos Vriezen wrote: > > Hi, > > > > AFAICS there isn't a plugin for konqueror using Gnash for flash, so I > > created one. It's now located at > > www.xs4all.nl/~jjvrieze/klash-0.0.1.tar.bz2 with even a debian > > directory. Read the README for building the gnash thing. > > > > Please give some comments (hopefully not that it's already there). > > It should be rather stable, though plain and simple. Please note that > > Gnash uses openGL and hardly works w/ remote X clients. > > It seems to be in gnash's CVS now as well. Is this the latest version? Yes, Rob Savoye was kind enough to include it in the gnash sources. > Using the attached patch should make it compilable with --disable-plugin > --enable-klash Thanks, I'll send it to Rob (I'm still in the middle of the GNU paper work ..) > For testing I removed the Adobe/Macromedia plugin completely and used the > userfriendly.org animation archive as a source for flash. > > Klash plugin gets loaded flawlessly but playback flickers a lot. In the second > animation, where Steff is fighting gladiator-like in an arena, I can see him > being drawn with white shirt and tie before the armor is drawn over it on > every move he makes. > > (gnash standalone works visually but has no sound) I don't follow you, do you mean that gnash standalone performs better than the plugin, or is this a general gnash remark? I already noticed that gnash performs quite bad on X servers with poor opengl support, even the ati driver can use 100% CPU, whereas the fglrx driver hardly uses any (likewise nvidia's one). Btw. 3D figures that visibly get dressed might actually be a selling point :-) Koos From kevin.krammer at gmx.at Mon Mar 13 20:18:10 2006 From: kevin.krammer at gmx.at (Kevin Krammer) Date: Mon, 13 Mar 2006 21:18:10 +0100 Subject: [Gnash] Re: Flash using Gnash for KDE = Klash In-Reply-To: <44159DE4.6000805@welcomehome.org> References: <20060301131439.GI90960@xs4all.nl> <200603122238.08873.kevin.krammer@gmx.at> <44159DE4.6000805@welcomehome.org> Message-ID: <200603132118.15791.kevin.krammer@gmx.at> On Monday 13 March 2006 17:29, Rob Savoye wrote: > Kevin Krammer wrote: > > It seems to be in gnash's CVS now as well. Is this the latest version? > > Yes, it was contributed. This is the same code, but I merged the > configure/build stuff into the existing support so it'd fit into Gnash > better. > > > Klash plugin gets loaded flawlessly but playback flickers a lot. In the > > second animation, where Steff is fighting gladiator-like in an arena, I > > can see him being drawn with white shirt and tie before the armor is > > drawn over it on every move he makes. > > Needless to say, while Gnash plays many Flash movies, it doesn't do > all of them correctly. I haven't seen the flickering, but I'm mostly > deep in debugging the real plugin, and have mostly been using the > MozPlugger support in Firefox otherwise. Sorry, this is a misunderstanding. I meant that gnash when invoked directly is playing the movie without any problem, when embedded in Konqueror it shows the mentioned symptoms. I verified it with a flash file on disk, i.e. opening the swf file in Konqueror filemanager mode vs. gnash from commandline. > > (gnash standalone works visually but has no sound) > > Sound is being worked on. There was minimal sound support, but it's > being rewritten to work more the way it's supposed to. There are also > unfortunately issues with the legalities of MP3 support. No problem, I was just reporting an observation. It could have been a setup problem or something like that. Cheers, Kevin -- Kevin Krammer Qt/KDE Developer, Debian User Moderator: www.mrunix.de (German), www.qtcentre.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From faure at kde.org Mon Mar 13 22:31:46 2006 From: faure at kde.org (David Faure) Date: Mon, 13 Mar 2006 23:31:46 +0100 Subject: content-disposition in HTTP headers In-Reply-To: <200603131645.22174.kde@carewolf.com> References: <200603111734.40803.kde@carewolf.com> <200603131645.22174.kde@carewolf.com> Message-ID: <200603132331.46697.faure@kde.org> On Monday 13 March 2006 16:45, Allan Sandfeld Jensen wrote: > Ok. Further testing showed that content-disposition: attachment is indeed not > honoured, but my patch didn't fix it either. I've reopened bug #31662 > (http://bugs.kde.org/show_bug.cgi?id=31662) > > The attached patch is updated and fixes the bug as far as I can tell, and > should be safe for KDE 3.5.2. Thanks for the patch. Looks fine over all. I'm not sure I understand this part though: + if (!tryEmbed) // try now + m_bFinished = m_pMainWindow->openView( mimeType, m_strURL, m_pView, m_req ); To me tryEmbed==false means "don't try embedding", so why is this trying to embed? ;) This is for the case where the server asks to save, and the user chose "Open" instead? In that case I think it should be done a bit earlier, like --- konq_run.cc (revision 503943) +++ konq_run.cc (working copy) @@ -107,6 +107,8 @@ void KonqRun::foundMimeType( const QStri if ( res == KParts::BrowserRun::Delayed ) return; m_bFinished = ( res == KParts::BrowserRun::Handled ); + if ( !m_bFinished && !tryEmbed ) + m_bFinished = m_pMainWindow->openView( mimeType, m_strURL, m_pView, m_req ); } // make Konqueror think there was an error, in order to stop the spinning wheel Smaller comments: + bool serverSuggestsSave() const { return contentDisposition() == "attachment"; }; should be + bool serverSuggestsSave() const { return contentDisposition() == QString::fromLatin1("attachment"); } in case someone compiles with the no-ascii-cast flag (and trailing ";" was removed too). I'm happy to see that the "reserved for later use" int flags in BrowserRun::askEmbedOrSave was useful; don't forget to adjust the API docs for it though. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From l.savernik at aon.at Tue Mar 14 13:57:06 2006 From: l.savernik at aon.at (Leo Savernik) Date: Tue, 14 Mar 2006 14:57:06 +0100 Subject: patch: khtml text selection with complex text In-Reply-To: <200603122234.50714.hausmann@kde.org> References: <200603122234.50714.hausmann@kde.org> Message-ID: <200603141457.06880.l.savernik@aon.at> Am Sonntag, 12. März 2006 22:34 schrieb Simon Hausmann: > Hi, > > text selection with complex text is currently broken in khtml, because > khtml draws the selected text as a separate string, breaking it apart at > invalid positions. You can see that easily on web sites with arabic text > for example. The only solution to that problem is unfortunately to draw the > run of text that is part of the beginning or the end of the selection > twice, once unselected and once selected with a clip rectangle set. The > clipping is necessary as there may be valid cursor positions inside a > ligature. Thanks for tackling it :-) I've had that on my todo list but never come around implementing it. > > Attached is my attempt at implementing this. Would be cool if somebody > could comment on the patch, or perhaps even approve it :) > I've reviewed it. It is generally ok, yet I'm missing some cheap optimisation: - In InlineTextBox::paintSelection, don't do visual clipping unless necessary (i. e. startPos!=m_start || endPos!=m_start+m_len) Furthermore ensure that your patch doesn't cause a regression of bug http://bugs.kde.org/show_bug.cgi?id=90422 If scrolling starts to be very slow either with or without selected text (best watched with Ctrl+A), the regression is back. mfg Leo From mikmach at wp.pl Tue Mar 14 21:08:30 2006 From: mikmach at wp.pl (Mikolaj Machowski) Date: Tue, 14 Mar 2006 22:08:30 +0100 Subject: RFE for khtml--where to file? (Vertical alignment of last page when paging with pageup/pagedown) In-Reply-To: <200603130948.26167.rhkramer@gmail.com> References: <200603130948.26167.rhkramer@gmail.com> Message-ID: <200603142208.30466.mikmach@wp.pl> Dnia poniedziałek, 13 marca 2006 15:48, Randy Kramer napisał: > > One reason I ask is that bug 93196 > (http://bugs.kde.org/show_bug.cgi?id=93196), which *could* be an > alternate solution to my problem, was closed as invalid, presumably > because it was filed against the wrong component (kdelib instead of > khtml). I'd like to make sure I get the request in the right place. > (Over on bug 76082 there is some speculation about other reasons bug > 93196 might have been closed.) Better place for question would be usability list, but I will answer here: IMO it is bad solution. Web authors often depend and design to specific dimensions of page. Of course many things in KDE are built around "power for the user" principle - and this is Good Thing(tm) - but this is going too far. Better solution (and probably easier) would be line vanishing after few seconds. And this could/should be KDE wide solution (KPDF/oKular, KWord, Kate(?), KDVI, etc.). m. From christian.weber at tu-berlin.de Tue Mar 14 09:18:32 2006 From: christian.weber at tu-berlin.de (Christian Weber) Date: Tue, 14 Mar 2006 10:18:32 +0100 Subject: Copy & Paste in the same folder Message-ID: <200603141018.32612.christian.weber@tu-berlin.de> Copying & Pasting a file in the same folder produces an error: "The source and destination are the same file". It would be more user-friendly to offer a "suggest new name" dialog just as when copying to a different folder where a file of the same name already exists. From aakhter at gmail.com Tue Mar 14 18:41:05 2006 From: aakhter at gmail.com (Aamer Akhter) Date: Tue, 14 Mar 2006 13:41:05 -0500 Subject: telnet: handler in konqueror Message-ID: <7cf4fa750603141041l6bb68dew4e2804778599a33@mail.gmail.com> (please copy me directly, as I am not subscribed to the alias) Hello, I'm using konqueror and trying to use the telnet: URL handler to launch telnte via xterm but konqueror is using Konsole. Is there a way to make xterm the default handler? Regards, -- Aamer Akhter / aakhter at gmail.com From thiago at kde.org Wed Mar 15 11:00:07 2006 From: thiago at kde.org (Thiago Macieira) Date: Wed, 15 Mar 2006 12:00:07 +0100 Subject: telnet: handler in konqueror In-Reply-To: <7cf4fa750603141041l6bb68dew4e2804778599a33@mail.gmail.com> References: <7cf4fa750603141041l6bb68dew4e2804778599a33@mail.gmail.com> Message-ID: <200603151200.07724.thiago@kde.org> Aamer Akhter wrote: >(please copy me directly, as I am not subscribed to the alias) > >Hello, > >I'm using konqueror and trying to use the telnet: URL handler to >launch telnte via xterm but konqueror is using Konsole. Is there a way >to make xterm the default handler? No. ktelnetservice hardcodes "konsole". It should be modified to use the default KDE terminal emulator component. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 5. Swa he géanhwearf tó timbran, and hwonne he cóm, lá! Unix cwæð "Hello, World". Ǽfre ǽghwilc wæs glæd and seo woruld wæs fréo. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From kevin.krammer at gmx.at Wed Mar 15 12:39:34 2006 From: kevin.krammer at gmx.at (Kevin Krammer) Date: Wed, 15 Mar 2006 13:39:34 +0100 Subject: telnet: handler in konqueror In-Reply-To: <200603151200.07724.thiago@kde.org> References: <7cf4fa750603141041l6bb68dew4e2804778599a33@mail.gmail.com> <200603151200.07724.thiago@kde.org> Message-ID: <200603151339.35167.kevin.krammer@gmx.at> On Wednesday 15 March 2006 12:00, Thiago Macieira wrote: > Aamer Akhter wrote: > >(please copy me directly, as I am not subscribed to the alias) > > > >Hello, > > > >I'm using konqueror and trying to use the telnet: URL handler to > >launch telnte via xterm but konqueror is using Konsole. Is there a way > >to make xterm the default handler? > > No. > > ktelnetservice hardcodes "konsole". It should be modified to use the > default KDE terminal emulator component. As a workaround, wouldn't it be possible to write a script like this? #!/bin/sh cd $1 xterm and use it in a telnet.protocol file like this [Protocol] exec=xtermservice %f protocol=telnet input=none output=none helper=true listing= reading=false writing=false makedir=false deleting=false Cheers, Kevin -- Kevin Krammer Qt/KDE Developer, Debian User Moderator: www.mrunix.de (German), www.qtcentre.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From thiago at kde.org Wed Mar 15 14:51:24 2006 From: thiago at kde.org (Thiago Macieira) Date: Wed, 15 Mar 2006 15:51:24 +0100 Subject: telnet: handler in konqueror In-Reply-To: <200603151339.35167.kevin.krammer@gmx.at> References: <7cf4fa750603141041l6bb68dew4e2804778599a33@mail.gmail.com> <200603151200.07724.thiago@kde.org> <200603151339.35167.kevin.krammer@gmx.at> Message-ID: <200603151551.33630.thiago@kde.org> Kevin Krammer wrote: >On Wednesday 15 March 2006 12:00, Thiago Macieira wrote: >> Aamer Akhter wrote: >> >(please copy me directly, as I am not subscribed to the alias) >> > >> >Hello, >> > >> >I'm using konqueror and trying to use the telnet: URL handler to >> >launch telnte via xterm but konqueror is using Konsole. Is there a >> > way to make xterm the default handler? >> >> No. >> >> ktelnetservice hardcodes "konsole". It should be modified to use the >> default KDE terminal emulator component. > >As a workaround, wouldn't it be possible to write a script like this? > >#!/bin/sh >cd $1 >xterm > >and use it in a telnet.protocol file like this > > >[Protocol] >exec=xtermservice %f I would not try to experiment what KIO does when it sees an %f for a telnet:// URL. In theory, it should *download* the URL and pass the filename to the service. Which doesn't make sense. No, the proper solution is to fix ktelnetservice. As a workaround, you can write your own ktelnetservice replacement, but you need to use %u. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 5. Swa he géanhwearf tó timbran, and hwonne he cóm, lá! Unix cwæð "Hello, World". Ǽfre ǽghwilc wæs glæd and seo woruld wæs fréo. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From kevin.krammer at gmx.at Wed Mar 15 18:05:04 2006 From: kevin.krammer at gmx.at (Kevin Krammer) Date: Wed, 15 Mar 2006 19:05:04 +0100 Subject: telnet: handler in konqueror In-Reply-To: <200603151551.33630.thiago@kde.org> References: <7cf4fa750603141041l6bb68dew4e2804778599a33@mail.gmail.com> <200603151339.35167.kevin.krammer@gmx.at> <200603151551.33630.thiago@kde.org> Message-ID: <200603151905.14144.kevin.krammer@gmx.at> On Wednesday 15 March 2006 15:51, Thiago Macieira wrote: > I would not try to experiment what KIO does when it sees an %f for a > telnet:// URL. In theory, it should *download* the URL and pass the > filename to the service. > > Which doesn't make sense. > > No, the proper solution is to fix ktelnetservice. As a workaround, you can > write your own ktelnetservice replacement, but you need to use %u. Right, I have no idea what I have been thinking at the time of posting the suggestion. A replacement script would have to take the URL, process it into host and port and use them to call telnet in xterm. How on earth did I come up with %f? Cheers, Kevin -- Kevin Krammer Qt/KDE Developer, Debian User Moderator: www.mrunix.de (German), www.qtcentre.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From lexhider at internode.on.net Thu Mar 16 09:15:10 2006 From: lexhider at internode.on.net (Lex Hider) Date: Thu, 16 Mar 2006 20:15:10 +1100 Subject: bug:108423 Ctrl-ENTER no longer opens links in new tab. Message-ID: <200603162015.10951.lexhider@internode.on.net> Hi, I've noticed that Ctrl-ENTER no longer opens the selected link in a new tab. This is a feature that I find useful. Was this a feature that was deliberately removed, or is this a bug? Lex. From sngeorgaras at otenet.gr Fri Mar 17 17:45:43 2006 From: sngeorgaras at otenet.gr (Spiros Georgaras) Date: Fri, 17 Mar 2006 19:45:43 +0200 Subject: Trunk branch compilation error (kdelibs) Message-ID: <200603171945.43256.sngeorgaras@otenet.gr> Hi all The last couple of days (or more) I have been trying to build the trunk branch. I have compiled qt and atrs, but when trying to compile kdelibs I get $ make -f Makefile.cvs This Makefile is only for the SVN repository *** YOU'RE USING UNSERMAKE 0.4. *** Creating acinclude.m4 make[2]: Entering directory `/home/kde-dev/kde-source/kdelibs' make[2]: Nothing to be done for `acinclude.m4'. make[2]: Leaving directory `/home/kde-dev/kde-source/kdelibs' *** Creating list of subdirectories *** Creating Makefile.am *** Creating configure.files *** Creating configure.in *** Creating aclocal.m4 *** Creating configure *** Creating config.h template *** Creating Makefile templates ['-rm -f $(top_builddir)/config.h $(top_builddir)/stamp-h1'] ['-rm -f $(top_builddir)/kdemacros.h $(top_builddir)/stamp-h2'] Traceback (most recent call last): File "", line 1, in ? File "__init__.py", line 1303, in ? File "__init__.py", line 1010, in main File "__init__.py", line 96, in create_makefiles File "amfile.py", line 329, in set_configure_headers File "amfile.py", line 88, in insertTarget File "amfile.py", line 61, in addTarget File "target.py", line 86, in merge two targets named 'distclean-hdr-top' define rules! make[1]: *** [cvs] Error 1 make: *** [all] Error 2 Now I know this could happen, beeing the unstable branch and all, but since this is not something new, I thought I should ask... BTW I think this is not the right list to post this message, but I don't know where I should do it, and I wouldn't want to subscribe to the wrong list... Sorry about that Regards Spiros From landemaine at gmail.com Fri Mar 17 19:01:11 2006 From: landemaine at gmail.com (Charles A. Landemaine) Date: Fri, 17 Mar 2006 16:01:11 -0300 Subject: Enhancing Konqueror Message-ID: Hello, here's a list of features I suggest could be added to Konqueror: - A Wand: Click a wand icon, and Konqueror auto-fills for you the form with your login and password and submits the form automatically (pretty neat) - A Google/Wikipedia search field next to the location bar such as in Opera or Firefox. - Make the .html handled by default by Konqueror so that when you click a link, the page doesn't load in Kate. - A Session-saver: You can save the current session with the open tabs, and re-open these tabs later on. Also you can auto-save current session on exit so that if you close Konqueror and re-open it, you don't loose the last pages you visited - Use more cache memory: When you hit "Back" or "Forward", Konqueror doesn't need to reload the pages. Just reload from cache, and it becomes as fast as Opera. - Close tab button should be on the tab (on the right), and not in the corner, it's more convenient - Web site icon should be on the tab on the right - New tab button - Open new windows in new tabs - Default smart pop up blocker - Authorized pop ups open in new window - Home URL should be blank - Mouse gestures like Opera (I'm missing them so much) - Activate previous used tab when closing the current tab - Disable "Focus Window" in JS - Web shortcuts: add 'g' for Google, add also 'pbi' to look for applications on the PBIDir - Use cache whenever possible - Dock the download manager into Konqueror (having the download manager poping up is extremely annoying). - Toggle on/off style-sheet for current page - Switch user-agent for current page (for web sites that reject Konqueror) - Support for AJAX version of Gmail: http://mail.google.com/mail/?nocheckbrowser Thank you. From staikos at kde.org Fri Mar 17 19:12:35 2006 From: staikos at kde.org (George Staikos) Date: Fri, 17 Mar 2006 14:12:35 -0500 Subject: Enhancing Konqueror In-Reply-To: References: Message-ID: <200603171412.36134.staikos@kde.org> I think you may be pleased to hear that virtually everything in your list already exists in Konqueror. :-) On Friday 17 March 2006 14:01, Charles A. Landemaine wrote: > Hello, here's a list of features I suggest could be added to Konqueror: > > - A Wand: Click a wand icon, and Konqueror auto-fills for you the > form with your login and password and submits the form automatically > (pretty neat) > > - A Google/Wikipedia search field next to the location bar such as in > Opera or Firefox. > > - Make the .html handled by default by Konqueror so that when you > click a link, the page doesn't load in Kate. > > - A Session-saver: You can save the current session with the open > tabs, and re-open these tabs later on. Also you can auto-save current > session on exit so that if you close Konqueror and re-open it, you > don't loose the last pages you visited > > - Use more cache memory: When you hit "Back" or "Forward", Konqueror > doesn't need to reload the pages. Just reload from cache, and it > becomes as fast as Opera. > > - Close tab button should be on the tab (on the right), and not in > the corner, it's more convenient > > - Web site icon should be on the tab on the right > > - New tab button > > - Open new windows in new tabs > > - Default smart pop up blocker > > - Authorized pop ups open in new window > > - Home URL should be blank > > - Mouse gestures like Opera (I'm missing them so much) > > - Activate previous used tab when closing the current tab > > - Disable "Focus Window" in JS > > - Web shortcuts: add 'g' for Google, add also 'pbi' to look for > applications on the PBIDir > > - Use cache whenever possible > > - Dock the download manager into Konqueror (having the download > manager poping up is extremely annoying). > > - Toggle on/off style-sheet for current page > > - Switch user-agent for current page (for web sites that reject Konqueror) > > - Support for AJAX version of Gmail: > http://mail.google.com/mail/?nocheckbrowser > > > Thank you. -- George Staikos KDE Developer http://www.kde.org/ Staikos Computing Services Inc. http://www.staikos.net/ From landemaine at gmail.com Fri Mar 17 19:26:29 2006 From: landemaine at gmail.com (Charles A. Landemaine) Date: Fri, 17 Mar 2006 16:26:29 -0300 Subject: Enhancing Konqueror In-Reply-To: References: <200603171412.36134.staikos@kde.org> Message-ID: On 3/17/06, Charles A. Landemaine wrote: > On 3/17/06, George Staikos wrote: > > I think you may be pleased to hear that virtually everything in your list > > already exists in Konqueror. :-) Really? I mean on default installation... I'm using the lastest stable version. -- Charles A. Landemaine. From pinaraf at robertlan.eu.org Fri Mar 17 21:48:45 2006 From: pinaraf at robertlan.eu.org (Pierre D.) Date: Fri, 17 Mar 2006 22:48:45 +0100 Subject: Enhancing Konqueror In-Reply-To: References: Message-ID: <200603172248.46688.pinaraf@robertlan.eu.org> Le Vendredi 17 Mars 2006 20:01, Charles A. Landemaine a écrit : > Hello, Hi I'm not a KDE developer, and I'm not sure for the KDE version where the features were added... > here's a list of features I suggest could be added to Konqueror: > > - A Wand: Click a wand icon, and Konqueror auto-fills for you the > form with your login and password and submits the form automatically > (pretty neat) Since KDE 3.2, using kwallet, by default. > > - A Google/Wikipedia search field next to the location bar such as in > Opera or Firefox. Useless (use the web shortcuts in the adress bar : gg, wp...), but available since KDE 3.4, by default. > > - Make the .html handled by default by Konqueror so that when you > click a link, the page doesn't load in Kate. ? Since KDE ... 2 ? by default. > > - A Session-saver: You can save the current session with the open > tabs, and re-open these tabs later on. Also you can auto-save current > session on exit so that if you close Konqueror and re-open it, you > don't loose the last pages you visited Don't know > > - Use more cache memory: When you hit "Back" or "Forward", Konqueror > doesn't need to reload the pages. Just reload from cache, and it > becomes as fast as Opera. It's not that easy. > > - Close tab button should be on the tab (on the right), and not in > the corner, it's more convenient Why ? It takes more room... > > - Web site icon should be on the tab on the right Why ? It's illogical: icons are on the left in any KDE app, why does konqueror needs a different behaviour ? > > - New tab button I don't know > - Open new windows in new tabs Available since KDE 3.3 > - Default smart pop up blocker Since KDE 3.5 > - Authorized pop ups open in new window Same as above ? > - Home URL should be blank It's only your settings ! > - Mouse gestures like Opera (I'm missing them so much) Available in ANY KDE app since KDE 3.2. Look at khotkeys. by default. > - Activate previous used tab when closing the current tab Since KDE 3.4 > - Disable "Focus Window" in JS I don't know > - Web shortcuts: add 'g' for Google, add also 'pbi' to look for > applications on the PBIDir Since before KDE 3.3, by default. > - Use cache whenever possible Configurable since before KDE 3.1, by default. > - Dock the download manager into Konqueror (having the download > manager poping up is extremely annoying). Not available > - Toggle on/off style-sheet for current page I don't know > - Switch user-agent for current page (for web sites that reject Konqueror) Available since KDE 3.2, by default. > - Support for AJAX version of Gmail: > http://mail.google.com/mail/?nocheckbrowser Available since KDE 3.4 (or 3.5 ?) Only switch user agent to mozilla, and insult google BTW... From pinaraf at robertlan.eu.org Fri Mar 17 21:53:04 2006 From: pinaraf at robertlan.eu.org (Pierre D.) Date: Fri, 17 Mar 2006 22:53:04 +0100 Subject: Enhancing Konqueror In-Reply-To: <200603172248.46688.pinaraf@robertlan.eu.org> References: <200603172248.46688.pinaraf@robertlan.eu.org> Message-ID: <200603172253.04394.pinaraf@robertlan.eu.org> Le Vendredi 17 Mars 2006 22:48, Pierre D. a écrit : > > - Dock the download manager into Konqueror (having the download > > manager poping up is extremely annoying). > > Not available Sorry, I think KGet does what you mean... I believed you meant KGet is poping up... From landemaine at gmail.com Fri Mar 17 22:16:26 2006 From: landemaine at gmail.com (Charles A. Landemaine) Date: Fri, 17 Mar 2006 19:16:26 -0300 Subject: Enhancing Konqueror In-Reply-To: <200603172248.46688.pinaraf@robertlan.eu.org> References: <200603172248.46688.pinaraf@robertlan.eu.org> Message-ID: None of these options are default. I'm using KDE 3.5.1. > > - A Wand: Click a wand icon, and Konqueror auto-fills for you the > > form with your login and password and submits the form automatically > > (pretty neat) > Since KDE 3.2, using kwallet, by default. Kwallet is an external password manager. I mean an icon that you click and Konqueror would fill out the form + submit the information for you automatically (A whole lot different and faster). > > - A Google/Wikipedia search field next to the location bar such as in > > Opera or Firefox. > Useless (use the web shortcuts in the adress bar : gg, wp...), but available > since KDE 3.4, by default. Only you and me know about these shortcuts, but regular users will find more useful and intuitive a search field. I personnally never use shortcuts to search on Google, I use the search field. > > - Make the .html handled by default by Konqueror so that when you > > click a link, the page doesn't load in Kate. > ? > Since KDE ... 2 ? by default. I'm using FreeBSD/KDE, and new pages open in Kate (Not cool at all!). I had to tweak the options to have Konqueror handle .html MIME type as default. > > - A Session-saver: You can save the current session with the open > > tabs, and re-open these tabs later on. Also you can auto-save current > > session on exit so that if you close Konqueror and re-open it, you > > don't loose the last pages you visited > Don't know At least it already works as long as you don't close Konqueror when you log out from KDE. When you come back, your tabs are still open in Konqueror. But when you close Konqueror, you shouldn't loose them. > > - Use more cache memory: When you hit "Back" or "Forward", Konqueror > > doesn't need to reload the pages. Just reload from cache, and it > > becomes as fast as Opera. > It's not that easy. This is of utmost importance. Only IE and Konqueror still reload the page when you hit the "Back" button. > > - Close tab button should be on the tab (on the right), and not in > > the corner, it's more convenient > Why ? It takes more room... Because the tab is highlighted, and it's easier to find it and close it. Moving the mouse to the upper-right corner is a pain. > > - Web site icon should be on the tab on the right > Why ? It's illogical: icons are on the left in any KDE app, why does konqueror > needs a different behaviour ? I'm talking about the web site icon, not the application icon. > > - New tab button > I don't know Because most people don't know about the Ctrl-T shortcut, or aren't comfortable with it. Opera has it. > > - Open new windows in new tabs > Available since KDE 3.3 Nope, unless you define it in the settings. Here it opens new windows in a new Konqueror window. > > - Default smart pop up blocker > Since KDE 3.5 There is still a plethora of popups that Konqueror doesn't block. > > - Home URL should be blank > It's only your settings ! Since the beginning I'm referring to default settings. > > - Mouse gestures like Opera (I'm missing them so much) > Available in ANY KDE app since KDE 3.2. Look at khotkeys. by default. Please give me the link to a tutorial to learn how to use mouse gestures in Konqueror to go back, forward, reload, open a new tab, etc... > > - Activate previous used tab when closing the current tab > Since KDE 3.4 Not working here on a fresh installation. > > - Web shortcuts: add 'g' for Google, add also 'pbi' to look for > > applications on the PBIDir > Since before KDE 3.3, by default. The "g" shortcut doesn't work here. > > - Use cache whenever possible > Configurable since before KDE 3.1, by default. Talking about default settings. > > - Dock the download manager into Konqueror (having the download > > manager poping up is extremely annoying). > Not available This was my point. > > - Switch user-agent for current page (for web sites that reject Konqueror) > Available since KDE 3.2, by default. How do I do it (beside in settings) ? > > - Support for AJAX version of Gmail: > > http://mail.google.com/mail/?nocheckbrowser > Available since KDE 3.4 (or 3.5 ?) > Only switch user agent to mozilla, and insult google BTW... Ok, I tried one more time. I'm using Konqueror 3.5.1. The AJAX version of Gmail does appear when identified as Mozilla, without the notorious Gmail warning on top, but clicking the links doesn't work at all. Can't read any e-mail. -- Charles A. Landemaine. From mikmach at wp.pl Fri Mar 17 21:11:15 2006 From: mikmach at wp.pl (Mikolaj Machowski) Date: Fri, 17 Mar 2006 22:11:15 +0100 Subject: Enhancing Konqueror In-Reply-To: References: Message-ID: <200603172211.15315.mikmach@wp.pl> Dnia piątek, 17 marca 2006 20:01, Charles A. Landemaine napisał: > Hello, here's a list of features I suggest could be added to Konqueror: > > - A Wand: Click a wand icon, and Konqueror auto-fills for you the > form with your login and password and submits the form automatically > (pretty neat) Use KWallet. The only thing missing is auto-submit of forms. > > - A Google/Wikipedia search field next to the location bar such as in > Opera or Firefox. It is (not sure if default). BTW - web shortcuts are much, much more comfortable. > - Make the .html handled by default by Konqueror so that when you > click a link, the page doesn't load in Kate. Isn't it default? > - A Session-saver: You can save the current session with the open > tabs, and re-open these tabs later on. Also you can auto-save current > session on exit so that if you close Konqueror and re-open it, you > don't loose the last pages you visited Yeah. Theoretically it exists but only with specific cache settings, should be independent. > - Use more cache memory: When you hit "Back" or "Forward", Konqueror > doesn't need to reload the pages. Just reload from cache, and it > becomes as fast as Opera. > > - Close tab button should be on the tab (on the right), and not in > the corner, it's more convenient You can have it on the tab. > - Web site icon should be on the tab on the right Two icons (close and icon) is too much for one tab. > - New tab button It is (on the left side of tab row). > - Open new windows in new tabs Present in Konq. > > - Default smart pop up blocker See above. > - Authorized pop ups open in new window See above. > - Home URL should be blank Not. > - Mouse gestures like Opera (I'm missing them so much) Khotkeys is the keyword. > - Activate previous used tab when closing the current tab Present in Konq. > - Disable "Focus Window" in JS Not sure. > - Web shortcuts: add 'g' for Google, add also 'pbi' to look for > applications on the PBIDir There is gg default for Google afair (I changed it long time ago for g, gg for groups and gi for images). > - Use cache whenever possible Ugh. As default setting it makes no sense. Most people use web for checking information, loading news.yahoo.com from cache could cause funny efects. OTOH if Konq could separate loading of graphics (a la Opera) and text... > - Dock the download manager into Konqueror (having the download > manager poping up is extremely annoying). Huh? Put KGet into tray and you will see only unobtrusive passive popups. > - Toggle on/off style-sheet for current page > > - Switch user-agent for current page (for web sites that reject > Konqueror) Kde-addons. > - Support for AJAX version of Gmail: > http://mail.google.com/mail/?nocheckbrowser AFAIK in big part it is Google problem. *They* are rejecting Konq. m. From landemaine at gmail.com Sat Mar 18 12:35:34 2006 From: landemaine at gmail.com (Charles A. Landemaine) Date: Sat, 18 Mar 2006 09:35:34 -0300 Subject: Enhancing Konqueror In-Reply-To: <200603172211.15315.mikmach@wp.pl> References: <200603172211.15315.mikmach@wp.pl> Message-ID: On 3/17/06, Mikolaj Machowski wrote: > Dnia piątek, 17 marca 2006 20:01, Charles A. Landemaine napisał: > > Hello, here's a list of features I suggest could be added to Konqueror: > > > > - A Wand: Click a wand icon, and Konqueror auto-fills for you the > > form with your login and password and submits the form automatically > > (pretty neat) > > Use KWallet. The only thing missing is auto-submit of forms. And this is exactly the "submit" feature that is missing. Also I don't know if Kwallet manages 2+ passwords per form (ie: the wife's password, the husband's password, etc...) the way Opera does. > > - A Google/Wikipedia search field next to the location bar such as in > > Opera or Firefox. > > It is (not sure if default). BTW - web shortcuts are much, much more > comfortable. There is no search field on Konqueror 3.5.1. Regular users don't use shortcuts because they don't know about them. > > - Make the .html handled by default by Konqueror so that when you > > click a link, the page doesn't load in Kate. > > Isn't it default? Not on a fresh install with 3.5.1 on FreeBSD. > > - A Session-saver: You can save the current session with the open > > tabs, and re-open these tabs later on. Also you can auto-save current > > session on exit so that if you close Konqueror and re-open it, you > > don't loose the last pages you visited > > Yeah. Theoretically it exists but only with specific cache settings, > should be independent. Actually it works fine as long as you don't close Konqueror (just log out / log in to KDE). If you happen to close Konqueror you loose your open tabs. > > - Use more cache memory: When you hit "Back" or "Forward", Konqueror > > doesn't need to reload the pages. Just reload from cache, and it > > becomes as fast as Opera. > > > > - Close tab button should be on the tab (on the right), and not in > > the corner, it's more convenient > > You can have it on the tab. Yes, but I mean in the default settings, on a fresh install without having to tweak the settings. > > - Web site icon should be on the tab on the right > > Two icons (close and icon) is too much for one tab. No, Opera does it nicely, and it doesn't take much room. > > - New tab button > > It is (on the left side of tab row). I don't have it. > > - Open new windows in new tabs > > Present in Konq. Yes, but I mean in the default settings, on a fresh install without having to tweak the settings. > > - Default smart pop up blocker Konqueror opens advertising popups on a fresh install. > > - Mouse gestures like Opera (I'm missing them so much) > > Khotkeys is the keyword. It doesn't work on a default installation like Opera (you need to download it). > > - Activate previous used tab when closing the current tab > > Present in Konq. I retried here, and this is not working. > > - Disable "Focus Window" in JS > > Not sure. This is because for instance you open a web site that is loading and is taking time to download. Then you decide to open Yahoo News to read news. So, you're reading an article, and all of the sudden, the first web site pops up, your article disappears because the 1st web site has a JS focus. This is very annoying. Gmail does it when the page is loaded on other browsers for instance. I disabled it in Opera. > > - Use cache whenever possible > > Ugh. As default setting it makes no sense. Most people use web for > checking information, loading news.yahoo.com from cache could cause > funny efects. OTOH if Konq could separate loading of graphics (a la > Opera) and text... Opera does it the right way. I don't know how they do it, but there is probably an algorythm, because on news web sites, the cache works partially (you don't have to hit F5, but on regular sites, the full cache works and the browser is very fast as it reloads from cache. > > - Switch user-agent for current page (for web sites that reject > > Konqueror) > > Kde-addons. I mean a simple way to do it, such as a menu entry like in Opera or Firefox. > > - Support for AJAX version of Gmail: > > http://mail.google.com/mail/?nocheckbrowser > > AFAIK in big part it is Google problem. *They* are rejecting Konq. You're true, but Google also rejects Opera, still the Opera team works actively to support Gmail's whims. And Opera identifies as IE when connecting to Gmail. -- Charles A. Landemaine. From hank at millerfarm.com Sat Mar 18 13:16:57 2006 From: hank at millerfarm.com (Henry Miller) Date: Sat, 18 Mar 2006 07:16:57 -0600 Subject: Enhancing Konqueror In-Reply-To: References: <200603172211.15315.mikmach@wp.pl> Message-ID: <200603180716.58991.hank@millerfarm.com> On Saturday 18 March 2006 06:35, Charles A. Landemaine wrote: > > Use KWallet. The only thing missing is auto-submit of forms. > > And this is exactly the "submit" feature that is missing. Also I don't > know if Kwallet manages 2+ passwords per form (ie: the wife's > password, the husband's password, etc...) the way Opera does. KDE only runs on multi-user systems. This is likely to continue in the future (Both Microsoft Windows and Mac OSX support multiple users, just that few people use that ability). You and your wife should not use the same login to your computer. This way there is no finger pointing when/if someone makes a mistake and deletes important files. User groups/ACLs if you need to share files between the two of you. Yes it is a little more work to do things right, but once you get used to it, it is easy enough and it solves a lot of problems. From klingens at kde.org Sat Mar 18 13:57:00 2006 From: klingens at kde.org (Martijn Klingens) Date: Sat, 18 Mar 2006 14:57:00 +0100 Subject: Enhancing Konqueror In-Reply-To: References: <200603172211.15315.mikmach@wp.pl> Message-ID: <200603181457.00707.klingens@kde.org> On Saturday 18 March 2006 13:35, Charles A. Landemaine wrote: > > > - A Google/Wikipedia search field next to the location bar such as in > > > Opera or Firefox. > > > > It is (not sure if default). BTW - web shortcuts are much, much more > > comfortable. > > There is no search field on Konqueror 3.5.1. Regular users don't use > shortcuts because they don't know about them. You're missing the Search Bar plugin from kde-addons, or it is disabled. Check Settings->Configure Extensions. On a Suse 10 installation it is enabled by default. > > > - Make the .html handled by default by Konqueror so that when you > > > click a link, the page doesn't load in Kate. > > > > Isn't it default? > > Not on a fresh install with 3.5.1 on FreeBSD. Is this only on a particular website? Sounds like the web server tells Konq that the mime type is text/plain, which is obviously honoured by finding the appropriate text rather than html viewer. > > > - A Session-saver: You can save the current session with the open > > > tabs, and re-open these tabs later on. Also you can auto-save current > > > session on exit so that if you close Konqueror and re-open it, you > > > don't loose the last pages you visited > > > > Yeah. Theoretically it exists but only with specific cache settings, > > should be independent. > > Actually it works fine as long as you don't close Konqueror (just log > out / log in to KDE). If you happen to close Konqueror you loose your > open tabs. You can use Save->View Profile to create a new profile based on your preference, or overwrite the Web Browsing profile. > > > - Close tab button should be on the tab (on the right), and not in > > > the corner, it's more convenient > > > > You can have it on the tab. > > Yes, but I mean in the default settings, on a fresh install without > having to tweak the settings. From a usability standpoint this is a very bad feature. It works awesome for power users, but the usability tests I have seen for most other users indicate that users are far too likely to accidentally hit the close button when not intended. For power users it's indeed very nice, but I guess you agree that it would make for a very poor default. > > > - Switch user-agent for current page (for web sites that reject > > > Konqueror) > > > > Kde-addons. > > I mean a simple way to do it, such as a menu entry like in Opera or > Firefox. kde-addons ;-) Install the plugin and go to Tools->Change Browser Identification. It's enabled automatically as soon as you install the plugin. If your distribution doesn't install them I would complain that their default install is too much stripped down ;-) -- Martijn From cmueller at gmx.de Sat Mar 18 13:57:22 2006 From: cmueller at gmx.de (Christian Mueller) Date: Sat, 18 Mar 2006 14:57:22 +0100 Subject: Enhancing Konqueror In-Reply-To: <200603180716.58991.hank@millerfarm.com> References: <200603180716.58991.hank@millerfarm.com> Message-ID: <200603181457.23200.cmueller@gmx.de> Am Samstag, 18. März 2006 14:16 schrieb Henry Miller: > On Saturday 18 March 2006 06:35, Charles A. Landemaine wrote: > > > > Use KWallet. The only thing missing is auto-submit of forms. > > > > And this is exactly the "submit" feature that is missing. Also I don't > > know if Kwallet manages 2+ passwords per form (ie: the wife's > > password, the husband's password, etc...) the way Opera does. > > KDE only runs on multi-user systems. This is likely to continue in the > future (Both Microsoft Windows and Mac OSX support multiple users, just that > few people use that ability). That doesn't makes this feature request completely useless. I have two use cases from my own recent use where it would have been useful to have. - I only have one user account on my personal machine. Yet I have to log into my DSL provider's login area as two different persons because I also manage my father's DSL account (who doesn't have or need an account on my personal machine as he lives in a different city). Creating one just to store his password would be overkill and even if I did it would be inconvenient. - At work, I'd like to try out logins into web pages as several different users who have different configurations / privileges, for test purposes. Using separate Linux accounts for them is not manageable. Of course, it would add to the code and UI complexity of Konqi and KWallet. I haven't posted a feature request because I don't think it's a too common requirement. Christian. From klingens at kde.org Sat Mar 18 16:46:58 2006 From: klingens at kde.org (Martijn Klingens) Date: Sat, 18 Mar 2006 17:46:58 +0100 Subject: Enhancing Konqueror In-Reply-To: <200603181457.23200.cmueller@gmx.de> References: <200603180716.58991.hank@millerfarm.com> <200603181457.23200.cmueller@gmx.de> Message-ID: <200603181746.59257.klingens@kde.org> On Saturday 18 March 2006 14:57, Christian Mueller wrote: > That doesn't makes this feature request completely useless. > I have two use cases from my own recent use where it would have been > useful to have. > > [...] Another one: at work I have to log in to the support website for one of our suppliers, and depending on where I want to go I have to use one of three user names. > Of course, it would add to the code and UI complexity of Konqi and KWallet. > I haven't posted a feature request because I don't think it's a too common > requirement. Firefox handles it very nicely, by filling in the last used, and remembering the others. If you start typing you get a completion popup and if you select one of the other entries it uses the password for that entry. So from a GUI point of view it doesn't add much complexity, but code-wise it's of course a lot more work. -- Martijn From rigo at w3.org Sat Mar 18 17:12:01 2006 From: rigo at w3.org (Rigo Wenning) Date: Sat, 18 Mar 2006 18:12:01 +0100 Subject: Enhancing Konqueror In-Reply-To: <200603171412.36134.staikos@kde.org> References: <200603171412.36134.staikos@kde.org> Message-ID: <200603181812.05681@rigo> It shows that the menu-structure and accessibility of all those features can be improved (right click, interactive session management like in Kate etc) So the right answer from the power-users would have been to tell how to activate the things. :) I for myself use not many of the features asked here, but I use some of the more powerful extensions, mainly fish. And yes, I had also the deja-vu that George had ;) Best, Rigo Am Friday 17 March 2006 20:12, sprach George Staikos: > I think you may be pleased to hear that virtually everything in your list > already exists in Konqueror. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From koos.vriezen at xs4all.nl Sat Mar 18 23:12:13 2006 From: koos.vriezen at xs4all.nl (Koos Vriezen) Date: Sun, 19 Mar 2006 00:12:13 +0100 Subject: [Gnash] Re: Flash using Gnash for KDE = Klash In-Reply-To: <200603132118.15791.kevin.krammer@gmx.at> References: <20060301131439.GI90960@xs4all.nl> <200603122238.08873.kevin.krammer@gmx.at> <44159DE4.6000805@welcomehome.org> <200603132118.15791.kevin.krammer@gmx.at> Message-ID: <20060318231212.GA35637@xs4all.nl> On Mon, Mar 13, 2006 at 09:18:10PM +0100, Kevin Krammer wrote: > On Monday 13 March 2006 17:29, Rob Savoye wrote: > > Kevin Krammer wrote: > > > It seems to be in gnash's CVS now as well. Is this the latest version? > > > > Yes, it was contributed. This is the same code, but I merged the > > configure/build stuff into the existing support so it'd fit into Gnash > > better. > > > > > Klash plugin gets loaded flawlessly but playback flickers a lot. In the > > > second animation, where Steff is fighting gladiator-like in an arena, I > > > can see him being drawn with white shirt and tie before the armor is > > > drawn over it on every move he makes. > > > > Needless to say, while Gnash plays many Flash movies, it doesn't do > > all of them correctly. I haven't seen the flickering, but I'm mostly > > deep in debugging the real plugin, and have mostly been using the > > MozPlugger support in Firefox otherwise. > > Sorry, this is a misunderstanding. > I meant that gnash when invoked directly is playing the movie without any > problem, when embedded in Konqueror it shows the mentioned symptoms. > > I verified it with a flash file on disk, i.e. opening the swf file in > Konqueror filemanager mode vs. gnash from commandline. Found only one hint in http://osdl.sourceforge.net/OSDL/OSDL-0.3/src/doc/web/main/documentation/rendering/SDL-hints.html The SDL_WINDOWID only works properly under Linux/GTK Klash uses the winid from XCreateSimpleWindow (that will be embedded in QXEmbed). I guess I should set that one up some more? Koos From kevin.krammer at gmx.at Sat Mar 18 23:56:20 2006 From: kevin.krammer at gmx.at (Kevin Krammer) Date: Sun, 19 Mar 2006 00:56:20 +0100 Subject: Enhancing Konqueror In-Reply-To: References: <200603172211.15315.mikmach@wp.pl> Message-ID: <200603190056.26465.kevin.krammer@gmx.at> On Saturday 18 March 2006 13:35, Charles A. Landemaine wrote: > On 3/17/06, Mikolaj Machowski wrote: > > > - Mouse gestures like Opera (I'm missing them so much) > > > > Khotkeys is the keyword. > > It doesn't work on a default installation like Opera (you need to download > it). I am not sure I understand this correctly, but you are saying you have a KDE installation where Opera is installed by default but khotkeys is not? Or rather that you think it is bad that KDE can do mouse gestures out of the box while it would be better to have it in a separate package like Opera? > > > - Switch user-agent for current page (for web sites that reject > > > Konqueror) > > > > Kde-addons. > > I mean a simple way to do it, such as a menu entry like in Opera or > Firefox. Here I have it under Tools->User Agent (translated back from German localization) Cheers, Kevin -- Kevin Krammer Qt/KDE Developer, Debian User Moderator: www.mrunix.de (German), www.qtcentre.org -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From zimmermann at kde.org Tue Mar 21 01:24:00 2006 From: zimmermann at kde.org (Nikolas Zimmermann) Date: Tue, 21 Mar 2006 02:24:00 +0100 Subject: CSS bug Message-ID: <200603210224.02057.zimmermann@kde.org> Good morning khtml crew, while integrating svg css properties in khtml, I found a pretty serious css bug affecting kdelibs trunk & 3.5 branch (as found out by Charles Samuels, thanks for that). The full story: DocumentImpl::attach() causes a CSSStyleSelector to be created, whose constructor calls CSSStyleSelector::init(). If the 's_defaultStyle' object isn't available it'll be created through CSSStyleSelector::loadDefaultStyle(). s_defaultSheet & s_quirksSheet (& s_svgSheet on my hdd) are created with a null CSSStyleSheetImpl ptr. That means the resulting sheets will have m_doc = 0. Now the default stylesheet loading proceeds, and as soon as we hit html4.css which contains @namespace "http://www.w3.org/1999/xhtml"; the problem occours: css/parser.cpp (generated by parser.y) executes this stuff upon @namespace: CSSParser *p = static_cast(parser); if (p->styleElement && p->styleElement->isCSSStyleSheet()) static_cast(p->styleElement)->addNamespace(p, domString($3), domString($4)); Please see the addNamespace function below (with added dbg statements). void CSSStyleSheetImpl::addNamespace(CSSParser* p, const DOM::DOMString& prefix, const DOM::DOMString& uri) { int exceptioncode = 0; if (uri.isEmpty()) return; kDebug() << " prefix: " << prefix << " uri: " << uri << " m_namespaces: " << m_namespaces << " m_doc: " << m_doc << endl; m_namespaces = new CSSNamespace(prefix, uri, m_namespaces); if (prefix.isEmpty()) p->defaultNamespace = m_doc->getId(NodeImpl::NamespaceId, uri.implementation(), false, false, &exceptioncode); } After adding this kDebug() statement to the addNamespace() function, you'll notice following output: khtml (css): @namespace: http://www.w3.org/1999/xhtml testkhtml: prefix: uri: http://www.w3.org/1999/xhtml m_namespaces: (nil) m_doc: (nil) prefix.isEmpty() returns true, and m_doc is nil. Somehow it doesn't crash and "works". No idea why. I noticed this behaviour after I added s_svgSheet + loading code to CSSStyleSelector::loadDefaultStyle -> it crashed, because of m_doc == 0. Adding a Q_ASSERT(m_doc != 0) in the if(prefix.isEmpty()) branch will have the result, that you can not load any files anymore :-) Even more scary is that it's in since quite a long time: Modified Fri May 20 15:44:37 2005 UTC (10 months ago) by carewolf Merge/port/implement XHTML namespace selectors, and a few other XHTML improvements. WebKit handles this completely different, so I tried to come up with a solution for our current codebase, included in the attached patch. (It is created against kdelibs trunk, but also applies against 3.5 branch) I assured that the created default style sheets got a valid m_doc param. The newly added asserts (Q_ASSERT(m_doc != 0);) aren't hit anymore (at least not while running testregression). No new regressions are introduced, my svg sheet loading works as expected now, though as this is a hot code path I'd like to have more input & opinions on the patch. Bye Bye Niko P.S. If I overlooked something stupid, I have an excuse: loooong working day! -------------- next part -------------- A non-text attachment was scrubbed... Name: khtml-possible-css-fix.diff Type: text/x-diff Size: 4133 bytes Desc: not available URL: From germain at ebooksfrance.org Tue Mar 21 08:39:05 2006 From: germain at ebooksfrance.org (Germain Garand) Date: Tue, 21 Mar 2006 09:39:05 +0100 Subject: CSS bug In-Reply-To: <200603210224.02057.zimmermann@kde.org> References: <200603210224.02057.zimmermann@kde.org> Message-ID: <200603210939.05696.germain@ebooksfrance.org> Le Mardi 21 Mars 2006 02:24, Nikolas Zimmermann a écrit : > prefix.isEmpty() returns true, and m_doc is nil. > Somehow it doesn't crash and "works". No idea why. Amazing... obviously, that could only work for the XHTML namespace, which has a special short code path in getId and never actually uses any member variables. > No new regressions are introduced, my svg sheet loading works as > expected now, though as this is a hot code path I'd like to have > more input & opinions on the patch. not *that* hot I trust :) Germain From zimmermann at kde.org Tue Mar 21 08:48:17 2006 From: zimmermann at kde.org (Nikolas Zimmermann) Date: Tue, 21 Mar 2006 09:48:17 +0100 Subject: CSS bug In-Reply-To: <200603210939.05696.germain@ebooksfrance.org> References: <200603210224.02057.zimmermann@kde.org> <200603210939.05696.germain@ebooksfrance.org> Message-ID: <200603210948.18580.zimmermann@kde.org> On Tuesday 21 March 2006 09:39, Germain Garand wrote: > Le Mardi 21 Mars 2006 02:24, Nikolas Zimmermann a écrit : > > prefix.isEmpty() returns true, and m_doc is nil. > > Somehow it doesn't crash and "works". No idea why. > > Amazing... obviously, that could only work for the XHTML namespace, which > has a special short code path in getId and never actually uses any member > variables. Aha, that's the trick :-) So you'd say the attached patch should go in? (both 3.5 & trunk?) > > No new regressions are introduced, my svg sheet loading works as > > expected now, though as this is a hot code path I'd like to have > > more input & opinions on the patch. > > not *that* hot I trust :) > > Germain Well here: hot != used often, but used for every html file :-) Bye Bye Niko From germain at ebooksfrance.org Tue Mar 21 10:55:24 2006 From: germain at ebooksfrance.org (Germain Garand) Date: Tue, 21 Mar 2006 11:55:24 +0100 Subject: CSS bug In-Reply-To: <200603210948.18580.zimmermann@kde.org> References: <200603210224.02057.zimmermann@kde.org> <200603210939.05696.germain@ebooksfrance.org> <200603210948.18580.zimmermann@kde.org> Message-ID: <200603211155.25211.germain@ebooksfrance.org> Le Mardi 21 Mars 2006 09:48, Nikolas Zimmermann a écrit : > So you'd say the attached patch should go in? (both 3.5 & trunk?) > yes I would. From wildfox at kde.org Tue Mar 21 11:07:22 2006 From: wildfox at kde.org (Nikolas Zimmermann) Date: Tue, 21 Mar 2006 11:07:22 +0000 Subject: KDE/kdelibs/khtml/css Message-ID: <1142939242.702394.9736.nullmailer@svn.kde.org> SVN commit 520948 by wildfox: Committing my khtml-possible-css-fix.diff, fixing the @namespace collector to not crash on every namespace != xhtml. This fixes at least my svg sheet loading stuff. No new regressions introduced. Reviewed (at least) by Germain. CCMAIL: kfm-devel at kde.org M +8 -2 css_stylesheetimpl.cpp M +7 -7 cssstyleselector.cpp M +2 -2 cssstyleselector.h --- trunk/KDE/kdelibs/khtml/css/css_stylesheetimpl.cpp #520947:520948 @@ -216,10 +216,13 @@ m_namespaces = new CSSNamespace(prefix, uri, m_namespaces); - if (prefix.isEmpty()) + if (prefix.isEmpty()) { + Q_ASSERT(m_doc != 0); + // Set the default namespace on the parser so that selectors that omit namespace info will // be able to pick it up easily. p->defaultNamespace = m_doc->getId(NodeImpl::NamespaceId, uri.implementation(), false, false, &exceptioncode); + } } void CSSStyleSheetImpl::determineNamespace(quint32& id, const DOM::DOMString& prefix) @@ -236,9 +239,12 @@ else { int exceptioncode = 0; CSSNamespace* ns = m_namespaces->namespaceForPrefix(prefix); - if (ns) + if (ns) { + Q_ASSERT(m_doc != 0); + // Look up the id for this namespace URI. id = makeId(m_doc->getId(NodeImpl::NamespaceId, ns->uri().implementation(), false, false, &exceptioncode), localNamePart(id)); + } } } --- trunk/KDE/kdelibs/khtml/css/cssstyleselector.cpp #520947:520948 @@ -194,7 +194,7 @@ { KHTMLView* view = doc->view(); - init(view ? view->part()->settings() : 0); + init(view ? view->part()->settings() : 0, doc); strictParsing = _strictParsing; m_medium = view ? view->mediaType() : QString("all"); @@ -252,7 +252,7 @@ CSSStyleSelector::CSSStyleSelector( CSSStyleSheetImpl *sheet ) { - init(0L); + init(0L, 0L); KHTMLView *view = sheet->doc()->view(); m_medium = view ? view->mediaType() : "screen"; @@ -261,7 +261,7 @@ authorStyle->append( sheet, m_medium ); } -void CSSStyleSelector::init(const KHTMLSettings* _settings) +void CSSStyleSelector::init(const KHTMLSettings* _settings, DocumentImpl* doc) { element = 0; settings = _settings; @@ -270,7 +270,7 @@ pseudoProps = (CSSOrderedProperty **)malloc(128*sizeof(CSSOrderedProperty *)); propsToApplySize = 128; pseudoPropsSize = 128; - if(!s_defaultStyle) loadDefaultStyle(settings); + if(!s_defaultStyle) loadDefaultStyle(settings, doc); defaultStyle = s_defaultStyle; defaultPrintStyle = s_defaultPrintStyle; @@ -294,7 +294,7 @@ authorStyle->append( sheet, m_medium ); } -void CSSStyleSelector::loadDefaultStyle(const KHTMLSettings *s) +void CSSStyleSelector::loadDefaultStyle(const KHTMLSettings *s, DocumentImpl *doc) { if(s_defaultStyle) return; @@ -313,7 +313,7 @@ style += s->settingsToCSS(); DOMString str(style); - s_defaultSheet = new DOM::CSSStyleSheetImpl((DOM::CSSStyleSheetImpl * ) 0); + s_defaultSheet = new DOM::CSSStyleSheetImpl(doc); s_defaultSheet->parseString( str ); // Collect only strict-mode rules. @@ -336,7 +336,7 @@ QString style = QLatin1String( file.data() ); DOMString str(style); - s_quirksSheet = new DOM::CSSStyleSheetImpl((DOM::CSSStyleSheetImpl * ) 0); + s_quirksSheet = new DOM::CSSStyleSheetImpl(doc); s_quirksSheet->parseString( str ); // Collect only quirks-mode rules. --- trunk/KDE/kdelibs/khtml/css/cssstyleselector.h #520947:520948 @@ -126,7 +126,7 @@ KHTML_EXPORT static void clear(); static void reparseConfiguration(); - static void loadDefaultStyle(const KHTMLSettings *s = 0); + static void loadDefaultStyle(const KHTMLSettings *s, DOM::DocumentImpl *doc); RenderStyle *styleForElement(DOM::ElementImpl *e); @@ -184,7 +184,7 @@ public: private: - void init(const KHTMLSettings* settings); + void init(const KHTMLSettings* settings, DOM::DocumentImpl* doc); void mapBackgroundAttachment(BackgroundLayer* layer, DOM::CSSValueImpl* value); void mapBackgroundImage(BackgroundLayer* layer, DOM::CSSValueImpl* value); From faure at kde.org Tue Mar 21 17:13:47 2006 From: faure at kde.org (David Faure) Date: Tue, 21 Mar 2006 18:13:47 +0100 Subject: Trunk branch compilation error (kdelibs) In-Reply-To: <200603171945.43256.sngeorgaras@otenet.gr> References: <200603171945.43256.sngeorgaras@otenet.gr> Message-ID: <200603211813.47888.faure@kde.org> On Friday 17 March 2006 18:45, Spiros Georgaras wrote: > two targets named 'distclean-hdr-top' define rules! Update unsermake. -- David Faure, faure at kde.org, sponsored by Trolltech to work on KDE, Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org). From tyrerj at acm.org Tue Mar 21 20:14:00 2006 From: tyrerj at acm.org (James Richard Tyrer) Date: Tue, 21 Mar 2006 13:14:00 -0700 Subject: [RFC] Icons for: Tab functions Message-ID: <44205E88.8050000@acm.org> I found that we do not have a: "tab_close_other" this is needed if both "Close Tab" & Close Other Tab" are on a toolbar. It is important that they be easy to distinguish from each other even at 16x16 pixels. I also noticed that we have an icon: "tab_new_bg" (at least in KDEClassic) but it is not being used. I have made revised and new icons: tab_close tab_close_other tab_new tab_new_bg for both HiColor (KDEClassic) and CryatalSVG. These are available here: http://home.earthlink.net/~tyrerj/kde/pics/Tab-Pics.tar.bz2 I also notice that we currently have only 16x16 icons for these 4 functions (and some others). This is OK for menu use but if they are placed on toolbars, we also need 22x22 and 32x32. Perhaps we also need SVG. I will also be posting two patches (KDELibs & KDEBase) to use the "tab_close_other" and "tab_new_bg" as soon as I finish testing them (later today if they work OK). -- JRT From tyrerj at acm.org Wed Mar 22 07:43:38 2006 From: tyrerj at acm.org (James Richard Tyrer) Date: Wed, 22 Mar 2006 00:43:38 -0700 Subject: [RFC] Icons for: Tab functions In-Reply-To: <44205E88.8050000@acm.org> References: <44205E88.8050000@acm.org> Message-ID: <4421002A.4090605@acm.org> James Richard Tyrer wrote: > I found that we do not have a: "tab_close_other" this is needed if both > "Close Tab" & Close Other Tab" are on a toolbar. It is important that > they be easy to distinguish from each other even at 16x16 pixels. > > I also noticed that we have an icon: "tab_new_bg" (at least in > KDEClassic) but it is not being used. > > I have made revised and new icons: > > tab_close > tab_close_other > tab_new > tab_new_bg > > for both HiColor (KDEClassic) and CryatalSVG. > > These are available here: > > http://home.earthlink.net/~tyrerj/kde/pics/Tab-Pics.tar.bz2 > > I also notice that we currently have only 16x16 icons for these 4 > functions (and some others). This is OK for menu use but if they are > placed on toolbars, we also need 22x22 and 32x32. Perhaps we also need > SVG. > > I will also be posting two patches (KDELibs & KDEBase) to use the > "tab_close_other" and "tab_new_bg" as soon as I finish testing them > (later today if they work OK). > Well it is still today in MST (GMT-7). I applied the two patches to KDE-3.5 branch and they compiled and worked. First the kde base patch changes the icon for "Close Other Tabs" to the new icon "tab_close_other". Then there are three places where you can right click and choose to open in a new tab: on a link: "Open in New Tab" on a bookmark: "Open in New Tab" in a frame: "Frame -> Open in New Tab" and also where you can open a bookmark folder in tabs: on a bookmark folder: "Open Folder in Tabs" In these places either "tab_new" or "tab_new_bg" will be displayed depending on whether you have configured Konqueror to open the new tabs in the foreground or the background. -- JRT -------------- next part -------------- A non-text attachment was scrubbed... Name: tab-kdelibs00.patch Type: text/x-patch Size: 1272 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: tab-kdebase01.patch Type: text/x-patch Size: 5145 bytes Desc: not available URL: From charles at kde.org Wed Mar 22 17:58:20 2006 From: charles at kde.org (Charles Samuels) Date: Wed, 22 Mar 2006 17:58:20 +0000 Subject: :first-letter and :before in CSS2 Message-ID: <200603221758.24043.charles@kde.org> Is :first-letter supposed to match text created by :before { content: } ? If the standard doesn't say so explicitly, and arguably: According to http://www.w3.org/TR/CSS21/selector.html#first-letter "The first letter of a table-cell or inline-block cannot be the first letter of an ancestor element" Implies that

First letter

implies that it wouldn't match. Can I assume that it doesn't match because it'd be easier to implement? :) cs -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From germain at ebooksfrance.org Wed Mar 22 20:28:30 2006 From: germain at ebooksfrance.org (Germain Garand) Date: Wed, 22 Mar 2006 21:28:30 +0100 Subject: :first-letter and :before in CSS2 In-Reply-To: <200603221758.24043.charles@kde.org> References: <200603221758.24043.charles@kde.org> Message-ID: <200603222128.30707.germain@ebooksfrance.org> Le Mercredi 22 Mars 2006 18:58, Charles Samuels a écrit : > Is :first-letter supposed to match text created by :before { content: } ? > > If the standard doesn't say so explicitly, and arguably: > > According to http://www.w3.org/TR/CSS21/selector.html#first-letter > "The first letter of a table-cell or inline-block cannot be the first > letter of an ancestor element" > > Implies that

First letter

implies that it > wouldn't match. if the span is default style here, it's an inline flow, not an inline-block, so it would match (:before elements inherit the display property) > > Can I assume that it doesn't match because it'd be easier to implement? :) > no, it's really supposed to match... 5.12.3 has an example of that (which is in the regression suite). But it works fine in current KHTML, AFAIK? Germain From charles at kde.org Wed Mar 22 20:30:49 2006 From: charles at kde.org (Charles Samuels) Date: Wed, 22 Mar 2006 20:30:49 +0000 Subject: :first-letter and :before in CSS2 In-Reply-To: <200603222128.30707.germain@ebooksfrance.org> References: <200603221758.24043.charles@kde.org> <200603222128.30707.germain@ebooksfrance.org> Message-ID: <200603222030.52040.charles@kde.org> Germain Garand wrote, on Wednesday 2006 March 22 8:28 pm: > no, it's really supposed to match... 5.12.3 has an example of that (which > is in the regression suite). Ok > But it works fine in current KHTML, AFAIK? Not in all cases actually, but I'll work on such a patch tomorrow. Namely related to counters and such. Why it doesn't work is pretty obvious, the solution, not so much. thanks, charles -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From kde at carewolf.com Thu Mar 23 14:20:51 2006 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 23 Mar 2006 15:20:51 +0100 Subject: CSS on dynamic DOM Message-ID: <200603231520.52362.kde@carewolf.com> Hi all Here's a patch to implement correct CSS on dynamic DOM. I am not yet sure it handles all corner-cases, but it handles at lot and all the attached test-cases. Regards `Allan -------------- next part -------------- A non-text attachment was scrubbed... Name: dynamic-dom-css.diff Type: text/x-diff Size: 21680 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From eva.brucherseifer at basyskom.de Thu Mar 23 14:31:56 2006 From: eva.brucherseifer at basyskom.de (Eva Brucherseifer) Date: Thu, 23 Mar 2006 15:31:56 +0100 Subject: Javascript and konq crash In-Reply-To: <4421C1C5.8020605@seiner.com> References: <4421C1C5.8020605@seiner.com> Message-ID: <200603231532.01099.eva.brucherseifer@basyskom.de> Hi Yan, we experience the same problem over here, but for us so far only on the arm platform. Symptoms are the same. We were able to get the backtrace below. On which platform are you testing? I also studied the ScopeChain and ScopeChainNode classe, but can't find anything wrong. Very strange is only that KJS::ScopeChain::mark is called several times, so it seems that the ScopeChain contains other ScopeChains. I also tried the current trunk version of scope_chain.h/cc, but same result. I've CCed the kfm-devel list maybe some kjs guru's there have some ideas? Greetings, eva ---------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x0031f51c in KJS::ScopeChain::mark () (gdb) bt 0 0x0031f51c in KJS::ScopeChain::mark () 0000001 0x0031fdd0 in KJS::ScopeChain::mark () 0000002 0x00320174 in KJS::ScopeChain::mark () 0000003 0x00324f1c in kjs_dtoa () 0000004 0x002b5b04 in KJS::UString::from () 0000005 0x00319fc0 in KJS::NumberNode::streamTo () 0000006 0x003199d8 in KJS::SourceStream::operator<< () 0000007 0x0031abe0 in KJS::MultNode::streamTo () 0000008 0x003199d8 in KJS::SourceStream::operator<< () 0000009 0x0031a6cc in KJS::ArgumentListNode::streamTo () 0000010 0x003199d8 in KJS::SourceStream::operator<< () 0000011 0x0031a774 in KJS::ArgumentsNode::streamTo () 0000012 0x003199d8 in KJS::SourceStream::operator<< () 0000013 0x0031a848 in KJS::FunctionCallNode::streamTo () 0000014 0x003199d8 in KJS::SourceStream::operator<< () 0000015 0x0031b524 in KJS::AssignExprNode::streamTo () 0000016 0x003199d8 in KJS::SourceStream::operator<< () 0000017 0x0031b574 in KJS::VarDeclNode::streamTo () 0000018 0x003199d8 in KJS::SourceStream::operator<< () 0000019 0x0031b5ac in KJS::VarDeclListNode::streamTo () 0000020 0x003199d8 in KJS::SourceStream::operator<< () 0000021 0x0031b664 in KJS::VarStatementNode::streamTo () 0000022 0x003199d8 in KJS::SourceStream::operator<< () 0000023 0x0031c84c in KJS::SourceElementsNode::streamTo () 0000024 0x003199d8 in KJS::SourceStream::operator<< () 0000025 0x0031b6f8 in KJS::BlockNode::streamTo () 0000026 0x00319e84 in KJS::Node::toCode () 0000027 0x002f5da0 in KJS::Parser::parse () 0000028 0x002fa7a8 in KJS::InterpreterImp::evaluate () 0000029 0x00316d3c in KJS::Interpreter::evaluate () 0000030 0x00239454 in KJS::KJSProxyImpl::evaluate () 0000031 0x0037da18 in KHTMLPart::executeScript () 0000032 0x0042c930 in khtml::HTMLTokenizer::scriptExecution () 33 0x0042c5bc in khtml::HTMLTokenizer::scriptHandler () 34 0x0042bc68 in khtml::HTMLTokenizer::parseSpecial () 35 0x00431194 in khtml::HTMLTokenizer::parseTag () 36 0x00431d68 in khtml::HTMLTokenizer::write () 37 0x00386130 in KHTMLPart::write () 38 0x00383378 in KHTMLPart::slotData () 39 0x001879ac in KIO::TransferJob::data () 40 0x00183444 in KIO::TransferJob::filteredData () 41 0x00183620 in KIO::TransferJob::receiveData () 42 0x4016ba58 in KIO::SlaveInterface::data () from /usr/lib/libkonqe.0 43 0x40168a90 in KIO::SlaveInterface::dispatch () from /usr/lib/libkonqe.0 44 0x401683f8 in KIO::SlaveInterface::dispatch () from /usr/lib/libkonqe.0 45 0x0018fe5c in KIO::Slave::slotDispatch () 46 0x40438a40 in QObject::activate_signal () from /opt/Qtopia/lib/libqte-mt.so.2 47 0x40467a78 in QSocketNotifier::event () from /opt/Qtopia/lib/libqte-mt.so.2 48 0x403f628c in QApplication::notify () from /opt/Qtopia/lib/libqte-mt.so.2 49 0x403a3390 in QApplication::processNextEvent () from /opt/Qtopia/lib/libqte-mt.so.2 50 0x403f3944 in QApplication::enter_loop () from /opt/Qtopia/lib/libqte-mt.so.2 51 0x40399124 in QApplication::exec () from /opt/Qtopia/lib/libqte-mt.so.2 52 0x0014b1bc in main () Am Mittwoch, 22. März 2006 22:29 schrieb yan seiner: > I've worked my way through a number of issues with konq.... > > But this one has me stumped. > > Konq runs javascript fine, except that once in a while it crashes. > > It crashes as follows: > > 70 root R 11M 68 99.9 41.6 konqueror > 71 root S 5104 70 0.0 17.8 konqueror > > Once process goes into what seems to be an infinite loop, consuming 100% > of CPU resources. After some 20 or 30 seconds, during which nothing is > logged, konqueror suddenly and quitely goes away. > > Nothing is in the log files, there is no kernel oops, nothing. > > It appears to be triggered by something in the javascript, but I have no > idea what that might be. > > Is there any way to enable javascript debugging? > > Thanks, > > --Yan > _______________________________________________ > konq-e mailing list > konq-e at kde.org > https://mail.kde.org/mailman/listinfo/konq-e -- Eva Brucherseifer General Manager basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642 eva.brucherseifer at basyskom.de | www.basyskom.de From tobias at ke.informatik.tu-darmstadt.de Thu Mar 23 16:25:01 2006 From: tobias at ke.informatik.tu-darmstadt.de (Tobias Anton) Date: Thu, 23 Mar 2006 17:25:01 +0100 Subject: AW: Javascript and konq crash In-Reply-To: <200603231532.01099.eva.brucherseifer@basyskom.de> References: <200603231532.01099.eva.brucherseifer@basyskom.de> Message-ID: <022401c64e96$67525df0$50a25382@kepler> Hi, this is due to the implementation of Object::mark() calling _scope->mark again. The attached patch fixes this, however I can't test it right now. Cheers Tobias -----Ursprüngliche Nachricht----- Von: Eva Brucherseifer [mailto:eva.brucherseifer at basyskom.de] Gesendet: Donnerstag, 23. März 2006 15:32 An: For discussion of Konqueror/Embedded; kfm-devel at kde.org Betreff: Re: Javascript and konq crash Hi Yan, we experience the same problem over here, but for us so far only on the arm platform. Symptoms are the same. We were able to get the backtrace below. On which platform are you testing? I also studied the ScopeChain and ScopeChainNode classe, but can't find anything wrong. Very strange is only that KJS::ScopeChain::mark is called several times, so it seems that the ScopeChain contains other ScopeChains. I also tried the current trunk version of scope_chain.h/cc, but same result. I've CCed the kfm-devel list maybe some kjs guru's there have some ideas? Greetings, eva ---------------------------------- Program received signal SIGSEGV, Segmentation fault. 0x0031f51c in KJS::ScopeChain::mark () (gdb) bt 0 0x0031f51c in KJS::ScopeChain::mark () 0000001 0x0031fdd0 in KJS::ScopeChain::mark () 0000002 0x00320174 in KJS::ScopeChain::mark () 0000003 0x00324f1c in kjs_dtoa () 0000004 0x002b5b04 in KJS::UString::from () 0000005 0x00319fc0 in KJS::NumberNode::streamTo () 0000006 0x003199d8 in KJS::SourceStream::operator<< () 0000007 0x0031abe0 in KJS::MultNode::streamTo () 0000008 0x003199d8 in KJS::SourceStream::operator<< () 0000009 0x0031a6cc in KJS::ArgumentListNode::streamTo () 0000010 0x003199d8 in KJS::SourceStream::operator<< () 0000011 0x0031a774 in KJS::ArgumentsNode::streamTo () 0000012 0x003199d8 in KJS::SourceStream::operator<< () 0000013 0x0031a848 in KJS::FunctionCallNode::streamTo () 0000014 0x003199d8 in KJS::SourceStream::operator<< () 0000015 0x0031b524 in KJS::AssignExprNode::streamTo () 0000016 0x003199d8 in KJS::SourceStream::operator<< () 0000017 0x0031b574 in KJS::VarDeclNode::streamTo () 0000018 0x003199d8 in KJS::SourceStream::operator<< () 0000019 0x0031b5ac in KJS::VarDeclListNode::streamTo () 0000020 0x003199d8 in KJS::SourceStream::operator<< () 0000021 0x0031b664 in KJS::VarStatementNode::streamTo () 0000022 0x003199d8 in KJS::SourceStream::operator<< () 0000023 0x0031c84c in KJS::SourceElementsNode::streamTo () 0000024 0x003199d8 in KJS::SourceStream::operator<< () 0000025 0x0031b6f8 in KJS::BlockNode::streamTo () 0000026 0x00319e84 in KJS::Node::toCode () 0000027 0x002f5da0 in KJS::Parser::parse () 0000028 0x002fa7a8 in KJS::InterpreterImp::evaluate () 0000029 0x00316d3c in KJS::Interpreter::evaluate () 0000030 0x00239454 in KJS::KJSProxyImpl::evaluate () 0000031 0x0037da18 in KHTMLPart::executeScript () 0000032 0x0042c930 in khtml::HTMLTokenizer::scriptExecution () 33 0x0042c5bc in khtml::HTMLTokenizer::scriptHandler () 34 0x0042bc68 in khtml::HTMLTokenizer::parseSpecial () 35 0x00431194 in khtml::HTMLTokenizer::parseTag () 36 0x00431d68 in khtml::HTMLTokenizer::write () 37 0x00386130 in KHTMLPart::write () 38 0x00383378 in KHTMLPart::slotData () 39 0x001879ac in KIO::TransferJob::data () 40 0x00183444 in KIO::TransferJob::filteredData () 41 0x00183620 in KIO::TransferJob::receiveData () 42 0x4016ba58 in KIO::SlaveInterface::data () from /usr/lib/libkonqe.0 43 0x40168a90 in KIO::SlaveInterface::dispatch () from /usr/lib/libkonqe.0 44 0x401683f8 in KIO::SlaveInterface::dispatch () from /usr/lib/libkonqe.0 45 0x0018fe5c in KIO::Slave::slotDispatch () 46 0x40438a40 in QObject::activate_signal () from /opt/Qtopia/lib/libqte-mt.so.2 47 0x40467a78 in QSocketNotifier::event () from /opt/Qtopia/lib/libqte-mt.so.2 48 0x403f628c in QApplication::notify () from /opt/Qtopia/lib/libqte-mt.so.2 49 0x403a3390 in QApplication::processNextEvent () from /opt/Qtopia/lib/libqte-mt.so.2 50 0x403f3944 in QApplication::enter_loop () from /opt/Qtopia/lib/libqte-mt.so.2 51 0x40399124 in QApplication::exec () from /opt/Qtopia/lib/libqte-mt.so.2 52 0x0014b1bc in main () Am Mittwoch, 22. März 2006 22:29 schrieb yan seiner: > I've worked my way through a number of issues with konq.... > > But this one has me stumped. > > Konq runs javascript fine, except that once in a while it crashes. > > It crashes as follows: > > 70 root R 11M 68 99.9 41.6 konqueror > 71 root S 5104 70 0.0 17.8 konqueror > > Once process goes into what seems to be an infinite loop, consuming 100% > of CPU resources. After some 20 or 30 seconds, during which nothing is > logged, konqueror suddenly and quitely goes away. > > Nothing is in the log files, there is no kernel oops, nothing. > > It appears to be triggered by something in the javascript, but I have no > idea what that might be. > > Is there any way to enable javascript debugging? > > Thanks, > > --Yan > _______________________________________________ > konq-e mailing list > konq-e at kde.org > https://mail.kde.org/mailman/listinfo/konq-e -- Eva Brucherseifer General Manager basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642 eva.brucherseifer at basyskom.de | www.basyskom.de -------------- next part -------------- A non-text attachment was scrubbed... Name: kjs-recursion.diff Type: application/octet-stream Size: 1187 bytes Desc: not available URL: From mo85 at cornell.edu Thu Mar 23 17:05:46 2006 From: mo85 at cornell.edu (Maksim Orlovich) Date: Thu, 23 Mar 2006 12:05:46 -0500 (EST) Subject: CSS on dynamic DOM In-Reply-To: <200603231520.52362.kde@carewolf.com> References: <200603231520.52362.kde@carewolf.com> Message-ID: <2684.67.138.15.192.1143133546.squirrel@webmail.cornell.edu> > Hi all > > Here's a patch to implement correct CSS on dynamic DOM. I am not yet sure > it > handles all corner-cases, but it handles at lot and all the attached > test-cases. A couple comments w/o having access to source tree and net at once, e.g. w/o being able to test it (and please keep in mind I've been working a bit on making selector matching more efficient): 0. This is very nice to see, great work overall. 1. Why do you need attribute dependencies? 2. in ElementImpl::attributeChanged you -Force- a recalc for id/classname. That's super-duper expensive. I guess the reason is that you skip the attribute dependency stuff for id/classname, so this is really a disguised #1. 3. Worse, in ElementImpl::attributeChanged you call restyleDependent which forces a recalcStyle immediately. Any reason not to rely on proper lazy restyling to get it right? Right now you may be recomputing stuff over and over again while a node is being yanked around. -Maks From mo85 at cornell.edu Thu Mar 23 17:11:07 2006 From: mo85 at cornell.edu (Maksim Orlovich) Date: Thu, 23 Mar 2006 12:11:07 -0500 (EST) Subject: Javascript and konq crash In-Reply-To: <200603231532.01099.eva.brucherseifer@basyskom.de> References: <4421C1C5.8020605@seiner.com> <200603231532.01099.eva.brucherseifer@basyskom.de> Message-ID: <2708.67.138.15.192.1143133867.squirrel@webmail.cornell.edu> > Hi Yan, > > we experience the same problem over here, but for us so far only on the > arm > platform. Symptoms are the same. We were able to get the backtrace below. > On > which platform are you testing? Hi Eva. This backtrace looks partly bogus: kjs_dtoa does not call ScopeChain::mark, but the frames below look sane. More likely you are hitting a portability problem in the dtoa.cpp code, which has tons of evil platform-specific stuff. From sebastien.raveau at epita.fr Thu Mar 23 19:51:47 2006 From: sebastien.raveau at epita.fr (Sebastien Raveau) Date: Thu, 23 Mar 2006 20:51:47 +0100 Subject: [PATCH] making sure onLoad actions were processed before emitting the completed() signal Message-ID: <200603232051.50985.sebastien.raveau@epita.fr> Hi all! Here's a patch (coded by David Faure right after I enounced the problem on #khtml, I have to say :) to make sure onLoad actions were processed before emitting the completed() signal. The problem with the current version of KHTML is that on webpages such as http://www.darty.com/webapp/wcs/stores/servlet/DartyHomepageView?storeId=10001 which contains the completed() signal will be emitted indeed once all the objects requested by the page's HTML code are loaded, but _before_ the onLoad javascript is executed. I tested this simple patch and it works perfectly for me... Can somebody please do a final review and commit it? Best regards, -- Sébastien Raveau computer and network security student head of the hawKeye network monitor project http://hawkeye.sourceforge.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: khtml_part_onload_completed.diff Type: text/x-diff Size: 889 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From eva.brucherseifer at basyskom.de Sat Mar 25 12:24:09 2006 From: eva.brucherseifer at basyskom.de (Eva Brucherseifer) Date: Sat, 25 Mar 2006 13:24:09 +0100 Subject: Fwd: Re: Javascript and konq crash Message-ID: <200603251324.11370.eva.brucherseifer@basyskom.de> Hi konq & kjs people, maybe you can have a look at it and help Yan out? I already mailed another mail about the problem some days ago. How about the current code from trunk? Does it make sense to try code from there instead? Or kdelibs 3.5.2? Right now we are using kdelibs 3.5.1 (tag). (Yan: kjs people are subscribed to kfm-devel, not to konq-e) Greetings, eva ---------- Weitergeleitete Nachricht ---------- Subject: Re: Javascript and konq crash Date: Samstag, 25. März 2006 01:16 From: yan seiner To: For discussion of Konqueror/Embedded Luciano Montanaro wrote: >On Friday 24 March 2006 14:26, Yan Seiner wrote: >>Eva Brucherseifer wrote: >>>Hi Yan, >>> >>>can you have a look at it? We are pretty busy with fixing other stuff... >>> >>>Greetings, >>>eva >> >>OK, I've looked at it.... It's a scary mess. >> >>In your javascript that fails, are you calling any floating point? >>sin/cos? log? >> >>The code that fails for us uses a good bit of floating point.... It >>would be good to confirm that suspicion.... > >The dtoa code is really quite intricated. >It seem to be called from a single point in kjs, in ustring. >Perhaps for testing purposes another conversion method (with sprintf or a >stringstream) could be used. If that works, the problem is indeed in dtoa. > >Luciano OK, some testing.... Floating point in Javascript on ARM seems to be badly broken - document.getElementById("xa"+idx).value = depth * 100 / document.getElementById("ha"+idx).value; which should be 0.5 * 100 / 3 = 16.66667 - and in fact shows up as 16.6667 in Firefox on x86 - shows up as -0.0003 just before konq crashes.... The big question is where is it broken? Can the kjs folks look at it? I can tarball the code I am using if that will help.... But for now I am going to walk around and clear my head.... --Yan _______________________________________________ konq-e mailing list konq-e at kde.org https://mail.kde.org/mailman/listinfo/konq-e ------------------------------------------------------- -- Eva Brucherseifer General Manager basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642 eva.brucherseifer at basyskom.de | www.basyskom.de From porten at froglogic.com Sat Mar 25 19:41:22 2006 From: porten at froglogic.com (Harri Porten) Date: Sat, 25 Mar 2006 20:41:22 +0100 (CET) Subject: Fwd: Re: Javascript and konq crash In-Reply-To: <200603251324.11370.eva.brucherseifer@basyskom.de> References: <200603251324.11370.eva.brucherseifer@basyskom.de> Message-ID: On Sat, 25 Mar 2006, Eva Brucherseifer wrote: >> The dtoa code is really quite intricated. >> It seem to be called from a single point in kjs, in ustring. >> Perhaps for testing purposes another conversion method (with sprintf or a >> stringstream) could be used. If that works, the problem is indeed in dtoa. The dtoa code was added by Apple as it makes some floating point operations work the way they are specified in the standard. It looks like it was taken from a rather ancient library though so it's not necessary portable to today's hardware. Had to fix something for the Alpha architecture already. It should indeed by safe to just circumvent the calls into the library routines and do simple conversions. They regressions should be neglectable. Just study older versions of KJS to see how it was done. Harri. From moura at kdewebdev.org Sun Mar 26 16:55:42 2006 From: moura at kdewebdev.org (Paulo Moura Guedes) Date: Sun, 26 Mar 2006 16:55:42 +0100 Subject: kdom and khtml integration In-Reply-To: <200603070028.34053.l.savernik@aon.at> References: <20060226232159.GA50130@xs4all.nl> <200603062130.49180.moura@kdewebdev.org> <200603070028.34053.l.savernik@aon.at> Message-ID: <200603261655.43240.moura@kdewebdev.org> On Monday 06 March 2006 23:28, Leo Savernik wrote: > Am Montag, 6. März 2006 22:30 schrieb Paulo Moura Guedes: > > > Well, I guess it may be nice if one could magically animate for > > > rendering/attach a custom-built tree. Not sure how hard it is to wire, > > > and I guess you probably know more about all the evil roundtrips via > > > part/view than me. > > > > Not sure about what you mean, but such a WYSIWYG editor would need to > > draw custom content on the canvas. > > AFAIK, this is internal functionality not available to external apps, as > > expected for the purpose KHTML was designed (this is the extensions > > points I mentioned in the other thread). > > I would like to discuss that a little and hear KHTML developers opinion. > > As far as I've understood, Quanta needs two types of interfaces. First a > means to inject a custom DOM-tree into khtml which is in turn laid out and > rendered by it. Second, a means to get extents and style information about > rendered objects exceeding what can be determined currently by the public > DOM api. > > I'd like to know which kind of information VPL needed from the khtml > renderer to work effectively. VPL needs to work like an editor and the editors today have to draw custom stuff on the screen that gives information or can be clicked or dragged to perform some action. So it's not just about showing the page content. An example of this can be seen with NVU or Mozilla composer (you can run it from the browser window) that draws a border with squares around the pictures so one can resize them. I wonder how can this be possible with KHTML. Paulo > If the information is not too specific, it > should be possible to design a stable api that satisfies both khtml's need > for internal api flexibility and efficiency, and VPL's or any other > consumer's need to interact with the rendered content. From kde at carewolf.com Sun Mar 26 20:50:02 2006 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 26 Mar 2006 21:50:02 +0200 Subject: CSS on dynamic DOM In-Reply-To: <2684.67.138.15.192.1143133546.squirrel@webmail.cornell.edu> References: <200603231520.52362.kde@carewolf.com> <2684.67.138.15.192.1143133546.squirrel@webmail.cornell.edu> Message-ID: <200603262150.03115.kde@carewolf.com> On Thursday 23 March 2006 18:05, Maksim Orlovich wrote: > A couple comments w/o having access to source tree and net at once, e.g. > w/o being able to test it (and please keep in mind I've been working a bit > on making selector matching more efficient): > > 0. This is very nice to see, great work overall. > 1. Why do you need attribute dependencies? Because attributes change, and CSS can depend on them. The d2c test is a test of this. > 2. in ElementImpl::attributeChanged you -Force- a recalc for id/classname. > That's super-duper expensive. I guess the reason is that you skip the > attribute dependency stuff for id/classname, so this is really a disguised > #1. I think this is already done somewhere else. I just need to find it and disable it. Id and Class are some really significant attributes to change. In the neighbourhood of replacing the item, so I think a restyle is okay. > 3. Worse, in ElementImpl::attributeChanged you call restyleDependent which > forces a recalcStyle immediately. Any reason not to rely on proper lazy > restyling to get it right? Right now you may be recomputing stuff over and > over again while a node is being yanked around. > The code is not finished. I just wanted some comments, because it might be a little expensive, and not something any of the big browser does right. We also need some lazyness to avoid multiple restyles, because restyles are recurse and both the child and parent might have dependencies. I've already improved the code a little so the dynamicDomRestyler now also handles the restyles on close() needed for :last-child selectors. This removes the three ugly bools in elementImpl and thereby saves 32 bytes per Element. `Allan From mo85 at cornell.edu Sun Mar 26 22:53:22 2006 From: mo85 at cornell.edu (Maksim Orlovich) Date: Sun, 26 Mar 2006 16:53:22 -0500 (EST) Subject: CSS on dynamic DOM In-Reply-To: <200603262150.03115.kde@carewolf.com> References: <200603231520.52362.kde@carewolf.com> <2684.67.138.15.192.1143133546.squirrel@webmail.cornell.edu> <200603262150.03115.kde@carewolf.com> Message-ID: <2802.67.138.15.248.1143410002.squirrel@webmail.cornell.edu> > On Thursday 23 March 2006 18:05, Maksim Orlovich wrote: >> A couple comments w/o having access to source tree and net at once, e.g. >> w/o being able to test it (and please keep in mind I've been working a >> bit >> on making selector matching more efficient): >> >> 0. This is very nice to see, great work overall. >> 1. Why do you need attribute dependencies? > Because attributes change, and CSS can depend on them. The d2c test is a > test > of this. I know that. I just mistakenly thought that we did setChanged() on attribute changes. Which, of course, we don't, excepty for ID and name on HTML elements. (See HTMLElementImpl::parseAttribute --- may want to remove it). > >> 2. in ElementImpl::attributeChanged you -Force- a recalc for >> id/classname. >> That's super-duper expensive. I guess the reason is that you skip the >> attribute dependency stuff for id/classname, so this is really a >> disguised >> #1. > I think this is already done somewhere else. I just need to find it and > disable it. See the above stuff. > Id and Class are some really significant attributes to change. > In > the neighbourhood of replacing the item, so I think a restyle is okay. > >> 3. Worse, in ElementImpl::attributeChanged you call restyleDependent >> which >> forces a recalcStyle immediately. Any reason not to rely on proper lazy >> restyling to get it right? Right now you may be recomputing stuff over >> and >> over again while a node is being yanked around. >> > The code is not finished. I just wanted some comments, because it might be > a > little expensive, and not something any of the big browser does right. Let me rephrase my viewpoint, now I understand the attribute thing: why not just call setChanged on nodes the dependency is on, and let lazy styling take care of doing recalcStyle just once on the whole affected mess? If there is a risk of circularity, the changed bit can work like a mark bit just as well. And yes, performance is a concern, especially since I am not sure Q*Dict is fast enough --- don't forget to give them some decent size, BTW. (There are also ways of engineering e.g. resetDependencies to be very quick, which may or may not be needed..) But there can be an upside: may be the new system can be used for descendant selectors as well, removing the horrid forcing-Force path, that's super-expensive? > I've already improved the code a little so the dynamicDomRestyler now also > handles the restyles on close() needed for :last-child selectors. This > removes the three ugly bools in elementImpl and thereby saves 32 bytes per > Element. Great. From yan at seiner.com Mon Mar 27 16:16:17 2006 From: yan at seiner.com (Yan Seiner) Date: Mon, 27 Mar 2006 07:16:17 -0800 Subject: Fwd: Re: Javascript and konq crash In-Reply-To: References: <200603251324.11370.eva.brucherseifer@basyskom.de> Message-ID: <442801C1.1090801@seiner.com> Harri Porten wrote: >On Sat, 25 Mar 2006, Eva Brucherseifer wrote: > > > >>>The dtoa code is really quite intricated. >>>It seem to be called from a single point in kjs, in ustring. >>>Perhaps for testing purposes another conversion method (with sprintf or a >>>stringstream) could be used. If that works, the problem is indeed in dtoa. >>> >>> > >The dtoa code was added by Apple as it makes some floating point >operations work the way they are specified in the standard. It looks like >it was taken from a rather ancient library though so it's not necessary >portable to today's hardware. Had to fix something for the Alpha >architecture already. > >It should indeed by safe to just circumvent the calls into the library >routines and do simple conversions. They regressions should be >neglectable. Just study older versions of KJS to see how it was done. > > Harri: Thanks for the pointer.... I am a complete newcomer to KDE / kfm development.... Where and how do I find earlier versions of KJS? I am assuming there is a CVS/SVN/??? archive somewhere, along with a versioning guide? And how far back do I need to go? Thanks, --Yan From porten at froglogic.com Mon Mar 27 17:01:34 2006 From: porten at froglogic.com (Harri Porten) Date: Mon, 27 Mar 2006 18:01:34 +0200 (CEST) Subject: Fwd: Re: Javascript and konq crash In-Reply-To: <442801C1.1090801@seiner.com> References: <200603251324.11370.eva.brucherseifer@basyskom.de> <442801C1.1090801@seiner.com> Message-ID: On Mon, 27 Mar 2006, Yan Seiner wrote: > Thanks for the pointer.... I am a complete newcomer to KDE / kfm > development.... > > Where and how do I find earlier versions of KJS? I am assuming there is a > CVS/SVN/??? archive somewhere, along with a versioning guide? And how far > back do I need to go? Yes. You'll find instructions here: http://developer.kde.org/source/anonsvn.html This one still uses the old-style conversion: http://websvn.kde.org/trunk/kdelibs/kjs/ustring.cpp?rev=199142&view=markup Harri. From bob_rossi at cox.net Wed Mar 29 20:01:03 2006 From: bob_rossi at cox.net (Bob Rossi) Date: Wed, 29 Mar 2006 14:01:03 -0500 Subject: KHTML Message-ID: <20060329190103.GD3969@brasko.net> Hi, I would like to know if it's possible to integrate KHTML into 3rd party proprietary applications? We have already bought the license from Trolltech. Also, what KDE libraries are required to run KHTML? Thanks, Bob Rossi From neundorf at kde.org Wed Mar 29 20:33:06 2006 From: neundorf at kde.org (Alexander Neundorf) Date: Wed, 29 Mar 2006 21:33:06 +0200 Subject: KHTML In-Reply-To: <20060329190103.GD3969@brasko.net> References: <20060329190103.GD3969@brasko.net> Message-ID: <200603292133.07397.neundorf@kde.org> On Wednesday 29 March 2006 21:01, Bob Rossi wrote: > Hi, > > I would like to know if it's possible to integrate KHTML into 3rd party > proprietary applications? We have already bought the license from > Trolltech. Yes. The KDE libraries are licensed under the LPGL, so you can link to them from proprietary applications (as long as you have a commercial license for Qt). > Also, what KDE libraries are required to run KHTML? I'm not the best person to answer this, but I think kdecore, kparts and probably kio. Bye Alex -- Work: alexander.neundorf AT jenoptik.com - http://www.jenoptik-los.de Home: neundorf AT kde.org - http://www.kde.org alex AT neundorf.net - http://www.neundorf.net From ceriel at gmail.com Tue Mar 28 16:56:00 2006 From: ceriel at gmail.com (Ceriel Nosforit) Date: Tue, 28 Mar 2006 18:56:00 +0300 Subject: Minor implementation flaw in View Filter Message-ID: Heya, I set the View Filter in a folder to only show MP3s, cut-pasted all the MP3s to a different folder and then returned to the first one. It appeared to be empty due to the filter, and when I went to unset it from MP3-only I discovered that the option was gone. Apparently upon finding no MP3s in the folder, Konqueror forgot to add the option to the View Filter. I just moved an MP3 back to the folder, unset the MP3 filter and then moved the file back again. No biggie, but I doubt that's "working as designed". TYFYT, HAND, Nosforit -------------- next part -------------- An HTML attachment was scrubbed... URL: From eva.brucherseifer at basyskom.de Thu Mar 30 16:02:03 2006 From: eva.brucherseifer at basyskom.de (Eva Brucherseifer) Date: Thu, 30 Mar 2006 17:02:03 +0200 Subject: Fwd: Re: Javascript and konq crash In-Reply-To: References: <200603251324.11370.eva.brucherseifer@basyskom.de> <442801C1.1090801@seiner.com> Message-ID: <200603301702.08565.eva.brucherseifer@basyskom.de> Hi, I've created the attached patch, which at least doesn't break anything visible to me: - it uses UString::from(double) from the cvs version below - I also tried to come up with replacements for the other usages of kjs_dtoa. I am not sure it is correct though. The conversion code didn't exist at all before kjs_dtoa was introduced. - kjs_strtod was replace by strtod Maybe someone with more insight into kjs can have a look? Thanks, eva Am Montag, 27. März 2006 18:01 schrieb Harri Porten: > On Mon, 27 Mar 2006, Yan Seiner wrote: > > Thanks for the pointer.... I am a complete newcomer to KDE / kfm > > development.... > > > > Where and how do I find earlier versions of KJS? I am assuming there is > > a CVS/SVN/??? archive somewhere, along with a versioning guide? And how > > far back do I need to go? > > Yes. You'll find instructions here: > > http://developer.kde.org/source/anonsvn.html > > This one still uses the old-style conversion: > > > http://websvn.kde.org/trunk/kdelibs/kjs/ustring.cpp?rev=199142&view=markup > > Harri. > _______________________________________________ > konq-e mailing list > konq-e at kde.org > https://mail.kde.org/mailman/listinfo/konq-e -- Eva Brucherseifer General Manager basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel: +49 6151 3969-961 | Fax: -736 | Mobile: +49 170 5533642 eva.brucherseifer at basyskom.de | www.basyskom.de -------------- next part -------------- A non-text attachment was scrubbed... Name: kjs_dtoa_arm.patch Type: text/x-diff Size: 3610 bytes Desc: not available URL: -------------- next part -------------- _______________________________________________ konq-e mailing list konq-e at kde.org https://mail.kde.org/mailman/listinfo/konq-e From l.savernik at aon.at Thu Mar 30 18:42:46 2006 From: l.savernik at aon.at (Leo Savernik) Date: Thu, 30 Mar 2006 19:42:46 +0200 Subject: KHTML In-Reply-To: <200603292133.07397.neundorf@kde.org> References: <20060329190103.GD3969@brasko.net> <200603292133.07397.neundorf@kde.org> Message-ID: <200603301942.47569.l.savernik@aon.at> Am Mittwoch, 29. März 2006 21:33 schrieb Alexander Neundorf: > > Also, what KDE libraries are required to run KHTML? > > I'm not the best person to answer this, but I think kdecore, kparts and > probably kio. kjs mfg Leo From ismail at pardus.org.tr Fri Mar 31 13:47:11 2006 From: ismail at pardus.org.tr (Ismail Donmez) Date: Fri, 31 Mar 2006 15:47:11 +0300 Subject: Two possible problems in khtml Message-ID: <200603311547.12034.ismail@pardus.org.tr> Hi, Someone in #khtml told us that he run a statistical code checker against khtml source code ( not full khtml he told but only limited parts ), and it show up two obvious bugs. First is dom2_traversalimpl.cpp line starting 588 : ======================================================= if( _tempCurrent ) { _result = isAccepted( _tempCurrent ); switch ( _result ) { [..] } // now the case if we don't have previous sibling else { _tempCurrent = _tempCurrent->parentNode(); <-- _tempCurrent is NULL so this is a null pointer referece. Looking at similar functions I think it should be : _tempCurrent = n->parentNode(); ======================================================= Second is css_valueimpl.cpp starting line 804 : ======================================================= khtml::DocLoader *docLoader = 0; const StyleBaseImpl *root = style; while (root->parent()) root = root->parent(); if (root->isCSSStyleSheet()) docLoader = static_cast(root)->docLoader(); m_image = docLoader->requestImage(url); <-- docLoader can be NULL ======================================================= Also the guy told me he can process rest of the khtml if someone can send him gcc -E output which doesn't contain any external reference ( references to outside headers etc ). I don't know how to do this, if someone can do this I can give the contact details in private. Regards, ismail -- If at first you don't succeed, redefine success. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From frans.englich at telia.com Fri Mar 31 15:04:50 2006 From: frans.englich at telia.com (Frans Englich) Date: Fri, 31 Mar 2006 14:04:50 +0000 Subject: Two possible problems in khtml In-Reply-To: <200603311547.12034.ismail@pardus.org.tr> References: <200603311547.12034.ismail@pardus.org.tr> Message-ID: <200603311404.50388.frans.englich@telia.com> On Friday 31 March 2006 12:47, Ismail Donmez wrote: > Hi, > > Someone in #khtml told us that he run a statistical code checker against > khtml source code What tool did he use? I've found it quite hard to find open source C++ checkers. I bet he has a license to one of the proprietrary ones. [...] > Also the guy told me he can process rest of the khtml if someone can send > him gcc -E output which doesn't contain any external reference ( references > to outside headers etc ). I don't know how to do this, if someone can do > this I can give the contact details in private. I would love to give it a run on KDOM's XQuery/XPath code(those 30 000 loc surely has its bugs), but I would as well need a solution for how to properly invoke with -E. Cheers, Frans From ismail at pardus.org.tr Fri Mar 31 14:53:05 2006 From: ismail at pardus.org.tr (Ismail Donmez) Date: Fri, 31 Mar 2006 16:53:05 +0300 Subject: Two possible problems in khtml In-Reply-To: <200603311404.50388.frans.englich@telia.com> References: <200603311547.12034.ismail@pardus.org.tr> <200603311404.50388.frans.englich@telia.com> Message-ID: <200603311653.08143.ismail@pardus.org.tr> Cuma 31 Mart 2006 17:04 tarihinde, Frans Englich şunları yazmıştı: > On Friday 31 March 2006 12:47, Ismail Donmez wrote: > > Hi, > > > > Someone in #khtml told us that he run a statistical code checker against > > khtml source code > > What tool did he use? I've found it quite hard to find open source C++ > checkers. I bet he has a license to one of the proprietrary ones. Something from IBM, which doesn't let them use the tool on other computers but he told me IBM said its ok if the check source code of other programs. > > > Also the guy told me he can process rest of the khtml if someone can send > > him gcc -E output which doesn't contain any external reference ( > > references to outside headers etc ). I don't know how to do this, if > > someone can do this I can give the contact details in private. > > I would love to give it a run on KDOM's XQuery/XPath code(those 30 000 loc > surely has its bugs), but I would as well need a solution for how to > properly invoke with -E. Well the guy is only interested in khtml and krita ( He said he only checked those ) . But if you find a way I would send them to him along with khtml. Regards, ismail -- If at first you don't succeed, redefine success. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From coolo at kde.org Fri Mar 31 15:07:13 2006 From: coolo at kde.org (Stephan Kulow) Date: Fri, 31 Mar 2006 16:07:13 +0200 Subject: Two possible problems in khtml In-Reply-To: <200603311547.12034.ismail@pardus.org.tr> References: <200603311547.12034.ismail@pardus.org.tr> Message-ID: <200603311607.16180.coolo@kde.org> Am Freitag, 31. März 2006 14:47 schrieb Ismail Donmez: > Also the guy told me he can process rest of the khtml if someone can send > him gcc -E output which doesn't contain any external reference ( references > to outside headers etc ). I don't know how to do this, if someone can do > this I can give the contact details in private. small howto: cd /khtml unsermake clean unsermake -i CXX="g++ -E" compile tar cjf forthatguy.tar.bz2 `find . -name "*.o"` coolo at portia#khtml>ls -lh forthatguy.tar.bz2 -rw-r--r-- 1 coolo suse 13M 2006-03-31 16:06 forthatguy.tar.bz2 Greetings, Stephan From ismail at pardus.org.tr Fri Mar 31 16:09:57 2006 From: ismail at pardus.org.tr (Ismail Donmez) Date: Fri, 31 Mar 2006 18:09:57 +0300 Subject: Two possible problems in khtml In-Reply-To: <200603311607.16180.coolo@kde.org> References: <200603311547.12034.ismail@pardus.org.tr> <200603311607.16180.coolo@kde.org> Message-ID: <200603311810.02545.ismail@pardus.org.tr> Cuma 31 Mart 2006 17:07 tarihinde şunları yazmıştınız: > Am Freitag, 31. März 2006 14:47 schrieb Ismail Donmez: > > Also the guy told me he can process rest of the khtml if someone can send > > him gcc -E output which doesn't contain any external reference ( > > references to outside headers etc ). I don't know how to do this, if > > someone can do this I can give the contact details in private. > > small howto: > > cd /khtml > unsermake clean > unsermake -i CXX="g++ -E" compile > tar cjf forthatguy.tar.bz2 `find . -name "*.o"` > > coolo at portia#khtml>ls -lh forthatguy.tar.bz2 > -rw-r--r-- 1 coolo suse 13M 2006-03-31 16:06 forthatguy.tar.bz2 Thanks Stephan! I uploaded processed current khtml SVN to http://cekirdek.pardus.org.tr/~ismail/tmp/khtml-processed.tar.bz2 . I am gonna send that too. Regards, ismail -- If at first you don't succeed, redefine success. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From agateau at dental-on-line.fr Fri Mar 31 18:04:07 2006 From: agateau at dental-on-line.fr (=?utf-8?q?Aur=C3=A9lien_G=C3=A2teau?=) Date: Fri, 31 Mar 2006 19:04:07 +0200 Subject: [PATCH] IE compatibility for Date.parse Message-ID: <200603311904.07217.agateau@dental-on-line.fr> Hello, I'm a bit ashamed of this patch, but it seems that quite a lot of broken Javascript code fail on Date.parse(txt) when txt is in the 'xx/xx/xxxx' format (dd/mm/yyyy in France, mm/dd/yyyy elsewhere). Real life example is the bank website of one of my customers: http://www.bfcoi.com/ I can't provide a link to the bad page because it's a cash transfer form, but the Javascript is here: http://www.bfcoi.com/onlinebanking/date.js The offending function is fmtDate(pDate). (In case it changes, I attach a copy of it to this message.) The patch is for KDE 3.4.3, but seems to apply on the 3.5 branch too (untested). The attached dateparse.html file contains some Javascript to test various values. Here is the output, on different browsers: Konqueror 3.4.3 --------------- Mar 30 2006 1 143 669 600 000 30/03/2006 NaN 03/30/2006 1 143 669 600 000 24/55/2006 NaN 70/55/2006 NaN 00/00/2006 NaN 01/452/2006 1 175 032 800 000 Firefox 1.0.4 ------------- Mar 30 2006 1 143 669 600 000 30/03/2006 1 212 444 000 000 03/30/2006 1 143 669 600 000 24/55/2006 1 201 129 200 000 70/55/2006 NaN 00/00/2006 NaN 01/452/2006 NaN Firefox 1.5 / IE 6.0 / Konqueror 3.4.3 with patch ------------------------------------------------- Mar 30 2006 1 143 669 600 000 30/03/2006 1 212 444 000 000 03/30/2006 1 143 669 600 000 24/55/2006 1 201 129 200 000 70/55/2006 315 097 200 000 00/00/2006 1 133 305 200 000 01/452/2006 1 175 032 800 000 PS: Please CC me. -- Aurélien Gâteau - agateau at dental-on-line.fr Dental-on-line 23 rue du Départ 75014 PARIS - FRANCE -------------- next part -------------- A non-text attachment was scrubbed... Name: kdelibs_kjs-date_parse_ie_compatibility-kde3.4.diff Type: text/x-diff Size: 855 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: date.js Type: application/x-javascript Size: 1747 bytes Desc: not available URL: From porten at froglogic.com Fri Mar 31 19:04:49 2006 From: porten at froglogic.com (Harri Porten) Date: Fri, 31 Mar 2006 20:04:49 +0200 (CEST) Subject: [PATCH] IE compatibility for Date.parse In-Reply-To: <200603311904.07217.agateau@dental-on-line.fr> References: <200603311904.07217.agateau@dental-on-line.fr> Message-ID: Hi! On Fri, 31 Mar 2006, Aur�lien G�teau wrote: > I'm a bit ashamed of this patch, but it seems that quite a lot of broken > Javascript code fail on Date.parse(txt) when txt is in the 'xx/xx/xxxx' > format (dd/mm/yyyy in France, mm/dd/yyyy elsewhere). > Real life example is the bank website of one of my customers: > http://www.bfcoi.com/ Add logic to detect more broken cases is usually fine. One just has to take care not to break other cases. Did you execute the Date.js tests (to be found in the khtmltests module, there are more in the Mozilla test suite) to make sure that nothing breaks? Harri. From porten at froglogic.com Fri Mar 31 19:05:02 2006 From: porten at froglogic.com (Harri Porten) Date: Fri, 31 Mar 2006 20:05:02 +0200 (CEST) Subject: [PATCH] IE compatibility for Date.parse In-Reply-To: <200603311904.07217.agateau@dental-on-line.fr> References: <200603311904.07217.agateau@dental-on-line.fr> Message-ID: Hi! On Fri, 31 Mar 2006, Aur�lien G�teau wrote: > I'm a bit ashamed of this patch, but it seems that quite a lot of broken > Javascript code fail on Date.parse(txt) when txt is in the 'xx/xx/xxxx' > format (dd/mm/yyyy in France, mm/dd/yyyy elsewhere). > Real life example is the bank website of one of my customers: > http://www.bfcoi.com/ Add logic to detect more broken cases is usually fine. One just has to take care not to break other cases. Did you execute the Date.js tests (to be found in the khtmltests module, there are more in the Mozilla test suite) to make sure that nothing breaks? Harri.