tag inside table 
(stripped from http://www.gentoo.org/doc/build.html ))
From: owner at bugs.kde.org (Stephan Kulow)
To: Vadim Plessky 

Your report has been marked as closed by one of the developers, namely
Dirk Mueller .

This problem has already been identified and fixed in the current CVS
version. If the fix is urgent for you, please consider upgrading to current
CVS version or the upcoming next stable release. Thank you for your valuable
feedback.

If you are pretty sure that something went wrong, 
please contact Dirk Mueller  directly.
-------------------------------------------------------------

|  Regards,
|
|  Koos Vriezen

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/




From koos.vriezen at xs4all.nl  Thu Jul 11 17:25:59 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Thu, 11 Jul 2002 18:25:59 +0200 (CEST)
Subject: KJS crash (Was: how Windows browsers encode URL [Re: why the %
 cruft?])
In-Reply-To: 
References: 
Message-ID: 



On Thu, 11 Jul 2002, Harri Porten wrote:

> On Wed, 10 Jul 2002, Waldo Bastian wrote:
>
> > > > Selecting http://chat.tapuz.co.il/newchat/main.asp and then clicking on
> > > > one of the links at the bottom (e.g. the one that starts with 30) causes
> > > > a KJS crash here.
> > >
> > > Here, nothing happens. I do see a Java exception
> >
> > The crash seems to be related to me not having Java enabled.
>
> I don't have a JVM installed. But I don't get any crash (3.0 branch). Some
> JS debug/errors, though:
>
> khtml (jscript): Window::get found dynamic property 'ChangeRoom'
> khtml (jscript): Window::get found dynamic property 'ready'
> KJS: WARNING: Failed function call attempt on: undefined : Undefined
> (0x8277ee0), line 6
> KJS: Was property 'switchRoom'
> KJS: of: [object APPLET] : HTMLAppletElement (0x81d6940)
>
> Your crash is most likely attributable to the JS implementation of
> HTMLAppletElement then.

#5  
#6  KJavaApplet::appletId (this=0xffffffff) at kjavaapplet.cpp:191
#7  0x417adbe5 in KJS::HTMLElement::toString (this=0x8434c80,
exec=0xbfffe05c)
    at kjs_html.cpp:1844
#8  0x418a82db in KJS::Value::toString ()

Interesting this pointer :). Anyway, it's fixed.

Koos





From koos.vriezen at xs4all.nl  Thu Jul 11 17:37:49 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Thu, 11 Jul 2002 18:37:49 +0200 (CEST)
Subject: KJS crash (Was: how Windows browsers encode URL [Re: why the %
 cruft?])
In-Reply-To: <200207110129.19796.hetz@kde.org>
References: <200207110129.19796.hetz@kde.org>
Message-ID: 

On Thu, 11 Jul 2002, Hetz Ben Hamo wrote:

> > in the Java console. But no chat?, no crash, no nothing.
>
> If you tried the URL that Waldo posted - then yes, no chat because it doesn't
> know whats your nick and what room do u want to start chatting - I know, dumb
> thing, but the chat is based on a user/pass mechanism, so thats why you don't
> see anything...
>
> Try the URL I gave prior to Waldo's replies. I do have some focus problems
> randomly (suddenly I cannot type anything inside the chat) but I cannot find
> a way to reproduce this..

That's weird, you get two editboxes with blinking cursors. A html form
element and a Java TextField. This looks like a problem with the recent
embedding change.
Well let's pass this one once again, Till?

Regards,

Koos




From demos23 at gmx.net  Thu Jul 11 14:20:34 2002
From: demos23 at gmx.net (World Class)
Date: Thu, 11 Jul 2002 10:20:34 -0300
Subject: Capacitaci�n en Idiomas
Message-ID: 

An HTML attachment was scrubbed...
URL: 

From bastian at kde.org  Fri Jul 12 01:46:27 2002
From: bastian at kde.org (Waldo Bastian)
Date: Thu, 11 Jul 2002 17:46:27 -0700
Subject: how Windows browsers encode URL [Re: why the % cruft?]
In-Reply-To: <200207110005.06004.hetz@kde.org>
References: <200207081353.03199.hetz@kde.org> <200207101315.19493.bastian@kde.org> <200207110005.06004.hetz@kde.org>
Message-ID: <200207111746.27336.bastian@kde.org>

On Wednesday 10 July 2002 02:05 pm, Hetz Ben Hamo wrote:
> I did - here it is again:
>
> http://chat.tapuz.co.il/newchat/main.asp?regUser=no&shower=1&room=30%20ôìåñ
>%20àéëåúé&nick=fasdfasd This URL lets you go into a Java hebrew based chat.
>
> With MSIE (and suprisingly Netscape 4.x) - the gybrish stuff is being feed
> into the server as parameters which room.
>
> the fasdfasd stuff is my test to put a nick name. if I put a hebrew nick
> the chat java client will get it as "????????" in konqueror. Actually if
> you'll try this URL on konqueror with Java enabled, you'll get into the
> chat to a room named "30 ????? ??????" - the ? should be of course hebrew
> letters ;)

The problem seems to be related to the fact that the javascript construct 
"location.href = ...." fails to pass on the encoding.

E.g. there is:
KURL KHTMLPart::completeURL( const QString &url )
{
  if ( !d->m_doc ) return url;

  if (d->m_decoder)
    return KURL(d->m_doc->completeURL(url), d->m_decoder->codec()->mibEnum());

  return KURL( d->m_doc->completeURL( url ) );
}
which correctly informs KURL about the encoding but which is too late because 
m_doc->completeURL() has already ruined it.

In order to do it right, m_doc should know about the codec so that 
m_doc->completeURL( url ) can do the right thing itself. Can I add that?

The other option is to change all occurences of:
       KHTMLPart* p = Window::retrieveActive(exec)->m_part;
        if ( p )
          url = p->htmlDocument().completeURL(str).string();

in khtml/ecma into something like:
       KHTMLPart* p = Window::retrieveActive(exec)->m_part;
        if ( p )
          url = p->completeURL(str);

And then change KHTMLPart::completeURL() to:

  if (d->m_decoder)
    return KURL(d->m_doc->baseURL(), url, d->m_decoder->codec()->mibEnum());

But then everyone else who still uses htmDocument().completeURL() will run 
into similar problems.

(And after that the only thing needed is a patch for KURL so that KURL::url() 
returns ascii-only URLs)

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com




From till at snafu.de  Fri Jul 12 02:11:18 2002
From: till at snafu.de (Till Krech)
Date: Fri, 12 Jul 2002 03:11:18 +0200
Subject: KJS crash (Was: how Windows browsers encode URL [Re: why the % cruft?])
In-Reply-To: 
References: 
Message-ID: <200207120311.18565.till@snafu.de>

Hi,
On Thursday 11 July 2002 18:37, Koos Vriezen wrote:
> On Thu, 11 Jul 2002, Hetz Ben Hamo wrote:
> > > in the Java console. But no chat?, no crash, no nothing.
> >
> > If you tried the URL that Waldo posted - then yes, no chat because it
> > doesn't know whats your nick and what room do u want to start chatting -
> > I know, dumb thing, but the chat is based on a user/pass mechanism, so
> > thats why you don't see anything...
> >
> > Try the URL I gave prior to Waldo's replies. I do have some focus
> > problems randomly (suddenly I cannot type anything inside the chat) but I
> > cannot find a way to reproduce this..
>
> That's weird, you get two editboxes with blinking cursors. A html form
> element and a Java TextField. This looks like a problem with the recent
> embedding change.
> Well let's pass this one once again, Till?
hmm, will have a look during the weekend. Did this ever work before ?
If I only new what is written there ;)
regards, till
>
> Regards,
>
> Koos

-- 
SuSE Linux 8.0 (i386) 2.4.18-64GB-SMP
KDE: 3.0.6 (KDE 3.1 alpha1)
Qt: 3.0.4




From till at snafu.de  Fri Jul 12 02:22:10 2002
From: till at snafu.de (Till Krech)
Date: Fri, 12 Jul 2002 03:22:10 +0200
Subject: KJS crash (Was: how Windows browsers encode URL [Re: why the % cruft?])
In-Reply-To: <200207120311.18565.till@snafu.de>
References:  <200207120311.18565.till@snafu.de>
Message-ID: <200207120322.10235.till@snafu.de>

s/new/knew/
-- 
SuSE Linux 8.0 (i386) 2.4.18-64GB-SMP
KDE: 3.0.6 (KDE 3.1 alpha1)
Qt: 3.0.4




From toshitaka at kde.gr.jp  Fri Jul 12 04:54:08 2002
From: toshitaka at kde.gr.jp (Toshitaka Fujioka)
Date: Fri, 12 Jul 2002 12:54:08 +0900
Subject: how Windows browsers encode URL [Re: why the % cruft?]
In-Reply-To: <200207101752.28969.lucy-ples@mtu-net.ru>
References: <200207081353.03199.hetz@kde.org> <200207101229.38764.toshitaka@kde.gr.jp> <200207101752.28969.lucy-ples@mtu-net.ru>
Message-ID: <200207121254.08938.toshitaka@kde.gr.jp>

On Wednesday 10 July 2002 22:52, Vadim Plessky wrote:
[snip]
> P.S. do you have similar solution for IMAP folder names?

Hmm, I have a only one account of IMAP with my company. But I can't access
this account with KMail. I can access only with Lotus notes.

Therefore I can't test this problem, sorry.
-- 
Toshitaka Fujioka
http://www.kde.org                The K Desktop Environment Project
                                                    fujioka at kde.org
http://www.kde.gr.jp               Japan KDE User's Group
                                                    toshitaka at kde.gr.jp

-- A journey of a thousand miles must begin with a single step.  Lao-zi --  



From david at mandrakesoft.com  Fri Jul 12 11:24:48 2002
From: david at mandrakesoft.com (David Faure)
Date: Fri, 12 Jul 2002 12:24:48 +0200
Subject: how Windows browsers encode URL [Re: why the % cruft?]
In-Reply-To: <200207111746.27336.bastian@kde.org>
References: <200207081353.03199.hetz@kde.org> <200207110005.06004.hetz@kde.org> <200207111746.27336.bastian@kde.org>
Message-ID: <200207121224.48524.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 12 July 2002 02:46, Waldo Bastian wrote:
> In order to do it right, m_doc should know about the codec so that 
> m_doc->completeURL( url ) can do the right thing itself. Can I add that?

Fun. I remember adding a codec int to that method in the past, to fix
a similar problem, and then dropping this idea..... I can't remember why, though.
(I do think it's a correct fix though).

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2-beta2 is out! http://dot.kde.org/1025176121/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Lq5w72KcVAmwbhARAl42AJ0f9N5XKCXgVUGhvbfeZoldKaxRswCfacx0
Hvof+jPYrVnIgsYnJn7T/84=
=zaGv
-----END PGP SIGNATURE-----




From lars at trolltech.com  Fri Jul 12 11:37:19 2002
From: lars at trolltech.com (Lars Knoll)
Date: Fri, 12 Jul 2002 12:37:19 +0200
Subject: how Windows browsers encode URL [Re: why the % cruft?]
In-Reply-To: <200207111746.27336.bastian@kde.org>
References: <200207081353.03199.hetz@kde.org> <200207110005.06004.hetz@kde.org> <200207111746.27336.bastian@kde.org>
Message-ID: <200207121237.19879.lars@trolltech.com>


> On Wednesday 10 July 2002 02:05 pm, Hetz Ben Hamo wrote:
> > I did - here it is again:
> >
> > http://chat.tapuz.co.il/newchat/main.asp?regUser=no&shower=1&room=30%20ôì
> >åñ %20àéëåúé&nick=fasdfasd This URL lets you go into a Java hebrew based
> > chat.
> >
> > With MSIE (and suprisingly Netscape 4.x) - the gybrish stuff is being
> > feed into the server as parameters which room.
> >
> > the fasdfasd stuff is my test to put a nick name. if I put a hebrew nick
> > the chat java client will get it as "????????" in konqueror. Actually if
> > you'll try this URL on konqueror with Java enabled, you'll get into the
> > chat to a room named "30 ????? ??????" - the ? should be of course hebrew
> > letters ;)
>
> The problem seems to be related to the fact that the javascript construct
> "location.href = ...." fails to pass on the encoding.
>
> E.g. there is:
> KURL KHTMLPart::completeURL( const QString &url )
> {
>   if ( !d->m_doc ) return url;
>
>   if (d->m_decoder)
>     return KURL(d->m_doc->completeURL(url),
> d->m_decoder->codec()->mibEnum());
>
>   return KURL( d->m_doc->completeURL( url ) );
> }
> which correctly informs KURL about the encoding but which is too late
> because m_doc->completeURL() has already ruined it.

Hmmm... why does KURL loose information at all? To me the fundamental flaw 
seems to be that KURL can do lossy conversions earlier than needed. 

So putting a Unicode URL into KURL, then setting the encoding to latin1, and 
afterwards to eg. utf8 should not result in any operation that looses data.

All strings in KURL should be stored in Unicode, and the conversion should 
only be done in the end to avoid exactly these problems. In that case you 
wouldn't loose anything when constructing a url, and could then set the 
encoding whenever you want. This might be difficult because of some inlined 
methods in KURL, but IMO that's how the class should behave.

Cheers,
Lars




From koos.vriezen at xs4all.nl  Fri Jul 12 12:05:30 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 12 Jul 2002 13:05:30 +0200 (CEST)
Subject: KJS crash (Was: how Windows browsers encode URL [Re: why the %
 cruft?])
In-Reply-To: <200207120311.18565.till@snafu.de>
References: <200207120311.18565.till@snafu.de>
Message-ID: 

On Fri, 12 Jul 2002, Till Krech wrote:

> On Thursday 11 July 2002 18:37, Koos Vriezen wrote:
> >
> > That's weird, you get two editboxes with blinking cursors. A html form
> > element and a Java TextField. This looks like a problem with the recent
> > embedding change.
> >
> hmm, will have a look during the weekend. Did this ever work before ?

Can't be fully for more than a few weeks, uses JS <-> Java a lot.

Koos




From bruggie at bruggie.dnsalias.org  Fri Jul 12 14:48:11 2002
From: bruggie at bruggie.dnsalias.org (Otto Bruggeman)
Date: Fri, 12 Jul 2002 15:48:11 +0200 (CEST)
Subject: More fun with auto scrolling
In-Reply-To: 
References: 
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 11 Jul 2002, Koos Vriezen wrote:
> On Thu, 11 Jul 2002, Dirk Mueller wrote:
>
> > On Don, 11 Jul 2002, Koos Vriezen wrote:
> >
> > > I found that scrolling is smoother if not for each pixel line a
> > > renderer()->print is called, but fill the whole paintbuffer and copy each
> > > time a line out of it. This is not perfect, it will mess up the view a bit
> > > (eg. when increasing font sizes) but its quite harmless.
> >
> > Hmm, I'd like to separate these two parts. can you commit the auto scroller
> > stuff already ? The paintbuffer-caching is a long term TODO but I never got
> > around yet.
> >
> > (being a new feature and all that.. ).
>
> Ok, curious to see how much hate-mail this will trigger :). Also, there
> should at least be a config option for this.
>
> Koos

Hehe, here is one :)

Please allow for even slower autoscrolling, especially on really wide
pages with a small font. Besides not all people are speedreaders (the
default speed is really too fast for my taste, especially on pages not in
dutch) :)

But it is a nice feature though that i wanted to code myself one day,
thank you for taking it off my todo list :)

Otto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE9Lt4hDc93sltYd+ERAmEkAJ9T55zR/S8Y3N0MkR/0MM2U/dtVDwCaAzgt
S75hfm1CG9t9LOAjC6e754w=
=hK+F
-----END PGP SIGNATURE-----





From koos.vriezen at xs4all.nl  Fri Jul 12 15:10:23 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 12 Jul 2002 16:10:23 +0200 (CEST)
Subject: More fun with auto scrolling
In-Reply-To: 
References: 
Message-ID: 

On Fri, 12 Jul 2002, Otto Bruggeman wrote:
> > Ok, curious to see how much hate-mail this will trigger :). Also, there
> > should at least be a config option for this.
> >
> > Koos
>
> Hehe, here is one :)

Yes, I'm really pissed now :)

> Please allow for even slower autoscrolling, especially on really wide
> pages with a small font. Besides not all people are speedreaders (the
> default speed is really too fast for my taste, especially on pages not in
> dutch) :)
>
> But it is a nice feature though that i wanted to code myself one day,
> thank you for taking it off my todo list :)

It's now 1 pixel/30ms, going up to 10px/30ms. Maybe decreasing the timer
interval from 1px/60ms to 1px/10ms is a better solution. Will try that.
What do you thing of always starting auto scrolling, maybe only start with
the shift key down? Or, ...?

Thanks,

Koos




From germain at ebooksfrance.com  Fri Jul 12 15:34:38 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Fri, 12 Jul 2002 15:34:38 +0100
Subject: More fun with auto scrolling
In-Reply-To: 
References: 
Message-ID: <200207121534.38224.germain@ebooksfrance.com>

Le Vendredi 12 Juillet 2002 15:10, Koos Vriezen a écrit :
> What do you thing of always starting auto scrolling, maybe only start with
> the shift key down? Or, ...?

Oh yes, please, definetly, having it triggered by shift-down would be perfect 
and won't break old habits (I personnally love normal scrolling :/)...

I think it's a far better solution than 
yet-another-config-checkbox-you-won't-find-anyway...

Cheers,
G.
>
> Thanks,
>
> Koos




From bruggie at bruggie.dnsalias.org  Fri Jul 12 16:14:03 2002
From: bruggie at bruggie.dnsalias.org (Otto Bruggeman)
Date: Fri, 12 Jul 2002 17:14:03 +0200 (CEST)
Subject: More fun with auto scrolling
In-Reply-To: <200207121534.38224.germain@ebooksfrance.com>
References: <200207121534.38224.germain@ebooksfrance.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 12 Jul 2002, Germain Garand wrote:
> Le Vendredi 12 Juillet 2002 15:10, Koos Vriezen a écrit :
> > What do you thing of always starting auto scrolling, maybe only start with
> > the shift key down? Or, ...?
>
> Oh yes, please, definetly, having it triggered by shift-down would be perfect
> and won't break old habits (I personnally love normal scrolling :/)...
>
> I think it's a far better solution than
> yet-another-config-checkbox-you-won't-find-anyway...
>
> Cheers,
> G.

Yeah i agree as well, shift down sounds more reasonable to me.
Oh and about the timer thingy yeah that might be a better idea. and
increase the minimum to 1px/100ms (about a second per line with a
smallish font), if people want it scroll faster they have to tap the down
key a few more times :)

Otto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE9LvJBDc93sltYd+ERAiIUAJ9JQmjFMzdmDJXT7OzDt4B9YwcWRwCeI4vB
iw4UlhuXj8tCKH7KLaQgI6o=
=PvH2
-----END PGP SIGNATURE-----





From bruggie at bruggie.dnsalias.org  Fri Jul 12 16:14:03 2002
From: bruggie at bruggie.dnsalias.org (Otto Bruggeman)
Date: Fri, 12 Jul 2002 17:14:03 +0200 (CEST)
Subject: More fun with auto scrolling
In-Reply-To: <200207121534.38224.germain@ebooksfrance.com>
References: <200207121534.38224.germain@ebooksfrance.com>
Message-ID: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 12 Jul 2002, Germain Garand wrote:
> Le Vendredi 12 Juillet 2002 15:10, Koos Vriezen a écrit :
> > What do you thing of always starting auto scrolling, maybe only start with
> > the shift key down? Or, ...?
>
> Oh yes, please, definetly, having it triggered by shift-down would be perfect
> and won't break old habits (I personnally love normal scrolling :/)...
>
> I think it's a far better solution than
> yet-another-config-checkbox-you-won't-find-anyway...
>
> Cheers,
> G.

Yeah i agree as well, shift down sounds more reasonable to me.
Oh and about the timer thingy yeah that might be a better idea. and
increase the minimum to 1px/100ms (about a second per line with a
smallish font), if people want it scroll faster they have to tap the down
key a few more times :)

Otto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: Made with pgp4pine 1.76

iD8DBQE9LvJBDc93sltYd+ERAiIUAJ9JQmjFMzdmDJXT7OzDt4B9YwcWRwCeI4vB
iw4UlhuXj8tCKH7KLaQgI6o=
=PvH2
-----END PGP SIGNATURE-----





From koos.vriezen at xs4all.nl  Fri Jul 12 16:57:21 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 12 Jul 2002 17:57:21 +0200 (CEST)
Subject: More fun with auto scrolling
In-Reply-To: 
References: 
Message-ID: 

> On Fri, 12 Jul 2002, Germain Garand wrote:
> > Le Vendredi 12 Juillet 2002 15:10, Koos Vriezen a �crit :
> > > What do you thing of always starting auto scrolling, maybe only start with
> > > the shift key down? Or, ...?
> >
> > Oh yes, please, definetly, having it triggered by shift-down would be perfect
> > and won't break old habits (I personnally love normal scrolling :/)...
> >
> > I think it's a far better solution than
> > yet-another-config-checkbox-you-won't-find-anyway...
> >
> > Cheers,
> > G.
>
> Yeah i agree as well, shift down sounds more reasonable to me.
> Oh and about the timer thingy yeah that might be a better idea. and
> increase the minimum to 1px/100ms (about a second per line with a
> smallish font), if people want it scroll faster they have to tap the down
> key a few more times :)

Ok, attached a patch that does:
- Only enable/accelerate/decelerate auto scrolling when shift key is down
- Changed scrolling velocity by changing interval and pixel/scroll
  These timings {100, 1}, {50, 1}, {30,1}, {20,1}, {10,1}, {10,2}, {10,3}
  are used ({interval, pixel}).

I do think though, intervals bigger than 30 are ugly.

Please test.

Koos
-------------- next part --------------
Index: khtmlview.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/khtmlview.cpp,v
retrieving revision 1.476
diff -u -3 -p -r1.476 khtmlview.cpp

--- khtmlview.cpp	2002/07/11 06:15:26	1.476
+++ khtmlview.cpp	2002/07/12 15:49:24
@@ -177,6 +177,7 @@ public:
 
     int repaintTimerId;
     int scrollTimerId;
+    int scrollTiming;
     int scrollBy;
     bool complete;
     bool firstRelayout;
@@ -622,7 +623,8 @@ void KHTMLView::keyPressEvent( QKeyEvent
     }
 
     int offs = (clipper()->height() < 30) ? clipper()->height() : 30;
-    if (_ke->state()&ShiftButton)
+    static int timings [][2] = { {100, 1}, {50, 1}, {30,1}, {20,1}, {10,1}, {10,2}, {10,3}, {0,0} };
+    if (_ke->state() & Qt::ShiftButton)
       switch(_ke->key())
         {
         case Key_Space:
@@ -631,6 +633,30 @@ void KHTMLView::keyPressEvent( QKeyEvent
             else
                 scrollBy( 0, -clipper()->height() - offs );
             break;
+
+        case Key_Down:
+        case Key_J:
+            if (!d->scrollTimerId) {
+                d->scrollTiming = 0;
+                d->scrollBy = timings[0][1];
+                scrollBy( 0, d->scrollBy );
+                d->scrollTimerId = startTimer(timings[0][0]);
+            } else if (timings[d->scrollTiming+1][0]) {
+                d->scrollBy = timings[++d->scrollTiming][1];
+                scrollBy( 0, d->scrollBy );
+                killTimer(d->scrollTimerId);
+                d->scrollTimerId = startTimer(timings[d->scrollTiming][0]);
+            }
+            break;
+
+        case Key_Up:
+        case Key_K:
+            if (d->scrollTiming) {
+                d->scrollBy = timings[--d->scrollTiming][1];
+                killTimer(d->scrollTimerId);
+                d->scrollTimerId = startTimer(timings[d->scrollTiming][0]);
+            }
+            break;
         }
     else
         switch ( _ke->key() )
@@ -639,18 +665,13 @@ void KHTMLView::keyPressEvent( QKeyEvent
         case Key_J:
             if ( d->vmode == QScrollView::AlwaysOff )
                 _ke->accept();
-            else if (_ke->isAutoRepeat()) {
+            else {
                 if (d->scrollTimerId) {
                     killTimer(d->scrollTimerId);
                     d->scrollTimerId = 0;
                 }
                 scrollBy( 0, 10 );
-            } else if (!d->scrollTimerId) {
-                d->scrollBy = 1;
-                scrollBy( 0, d->scrollBy );
-                d->scrollTimerId = startTimer(30);
-            } else if (d->scrollBy < 10)
-                d->scrollBy++;
+            }
             break;
 
         case Key_Space:
@@ -665,13 +686,13 @@ void KHTMLView::keyPressEvent( QKeyEvent
         case Key_K:
             if ( d->vmode == QScrollView::AlwaysOff )
                 _ke->accept();
-            else if (d->scrollTimerId) {
-                if (--d->scrollBy <= 0) {
+            else {
+                if (d->scrollTimerId) {
                     killTimer(d->scrollTimerId);
                     d->scrollTimerId = 0;
                 }
-            } else
                 scrollBy( 0, -10 );
+            }
             break;
 
         case Key_Prior:
@@ -1481,7 +1502,7 @@ void KHTMLView::timerEvent ( QTimerEvent
 {
 //    kdDebug() << "timer event " << e->timerId() << endl;
     if (e->timerId() == d->scrollTimerId) {
-        if (contentsY() + visibleHeight () >= contentsHeight() || d->scrollBy <= 0) {
+        if (contentsY() + visibleHeight () >= contentsHeight()) {
             kdDebug() << "timer event killing timer" << endl;
             killTimer(d->scrollTimerId);
             d->scrollTimerId = 0;

From bastian at kde.org  Fri Jul 12 20:15:13 2002
From: bastian at kde.org (Waldo Bastian)
Date: Fri, 12 Jul 2002 12:15:13 -0700
Subject: how Windows browsers encode URL [Re: why the % cruft?]
In-Reply-To: <200207121237.19879.lars@trolltech.com>
References: <200207081353.03199.hetz@kde.org> <200207111746.27336.bastian@kde.org> <200207121237.19879.lars@trolltech.com>
Message-ID: <200207121215.13919.bastian@kde.org>

On Friday 12 July 2002 03:37 am, Lars Knoll wrote:
> So putting a Unicode URL into KURL, then setting the encoding to latin1,
> and afterwards to eg. utf8 should not result in any operation that looses
> data.

I fail to see why it is so hard to set the encoding right the first time. You 
don't read HTML pages as "latin1" first and then later change the QStrings to 
correct for the fact that the encoding should have been utf8, do you?

If you set the wrong encoding then KURL::url() will return the wrong result. 
If you continue to work with those wrong results then things will not 
automagically correct themselves after you throw them into a KURL with 
another encoding set.

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com




From lars at trolltech.com  Sat Jul 13 11:48:49 2002
From: lars at trolltech.com (Lars Knoll)
Date: Sat, 13 Jul 2002 12:48:49 +0200
Subject: how Windows browsers encode URL [Re: why the % cruft?]
In-Reply-To: <200207121215.13919.bastian@kde.org>
References: <200207081353.03199.hetz@kde.org> <200207121237.19879.lars@trolltech.com> <200207121215.13919.bastian@kde.org>
Message-ID: <200207131248.49214.lars@trolltech.com>


> On Friday 12 July 2002 03:37 am, Lars Knoll wrote:
> > So putting a Unicode URL into KURL, then setting the encoding to latin1,
> > and afterwards to eg. utf8 should not result in any operation that looses
> > data.
>
> I fail to see why it is so hard to set the encoding right the first time.
> You don't read HTML pages as "latin1" first and then later change the
> QStrings to correct for the fact that the encoding should have been utf8,
> do you?
>
> If you set the wrong encoding then KURL::url() will return the wrong
> result. If you continue to work with those wrong results then things will
> not automagically correct themselves after you throw them into a KURL with
> another encoding set.

I think you misunderstand me. Sure that KURL::url() returns a wrong result 
with a wrong encoding. My point is more that we actually should never need to 
call url() before actually sending it out over the wire in a request as it 
can be an operation where we loose information. 

When constructing one URL from another, we should probably use the decoded 
variants so no information is lost. KURL should provide all means to do that, 
so you can set arbitrary unicode strings and only when sending it out as part 
of a request will it get transformed into an encoding.

Lars






From germain at ebooksfrance.com  Sat Jul 13 17:55:20 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Sat, 13 Jul 2002 17:55:20 +0100
Subject: [PATCH]  various nodeAtPoint() fixes
Message-ID: <200207131755.20637.germain@ebooksfrance.com>


Hello there, hello Dirk !

I've dived since a week into nodeAtPoint's internals to solve a number of problems
 with mouse hovering and link detection.

 I finally found 3 errors and made a patch.

As the whole method is very tense and touchy, I think it's better if I details exactly 
what my changes do :

-------------------------------

- 1°: relative coordinates change don't propagate recursively to childrens.
(I posted this last week on kfm-devel but noone replied so it's still pending)

 if (!child->isPositioned() && child->nodeAtPoint(info, _x, _y, _tx+xPos(), _ty+yPos()))

Here, it should pass tx and ty, which are exactly the same as _tx+xPos()/_ty+yPos() excepted if a relative translation occured.

 Testcase: http://www.phoenix-library.org/bug-konq-css.html
 Bug: #42681 (+ #43282)

------------------------------------------------------

- 2°: on the same line, the test for !child->isPositioned() need to be !child->isSpecial()
(I do know it was changed in r1.171, but please read on.. there is more on this later)

rationale :
----------
All specialObjects (i.e : isFloating() || isPositioned() ) are parsed only in RenderFlow::nodeAtPoint().
It first iterates over specialObjects, calling ->nodeAtPoint() on each.
When there are no more, it then inspects NORMAL children by calling the base class method on
"this".
Thus, if you just filter child->isPositioned(), all floating objects will end up beiing parsed twice.

That's no good, because when innerNode is found, nodeAtPoint() proceeds unsetting mouseInside()
for EVERY remaining node, without checking if it already parsed them.
In other words, it will cancel a previous hover on floating objects instantly.

There are quite a lot of subtle problems with hovering which are caused by this double parsing.

Now, the original !child->isSpecial() was replaced by !child->isPositioned() in revision 1.171
to force the parsing of non-RenderFlow floating objects.

So a simple solution to correct everything is :

 if (!(child->isSpecial() && isFlow()) && child->nodeAtPoint(info, _x, _y, tx, ty))

That way,  specialObjects are filtered out only if the parent inherits RenderFlow.

Here is one of my testcases for the duplicate parsing error: 
http://www.phoenix-library.org/germain/testcases/bug_khtml_hover.html
Bug: #44602             
(the bug points to a real-world page, but my testcase is a reduction of it)

And for filtering out every specialObjects vs. filtering only when this->isFlow():
http://www.phoenix-library.org/germain/testcases/khtml-absolute-rendercontainer.html
Bug: #40519
(same remark as above)
------------------------------------------

3°-innerNode() and URLElement() are sometimes differents, the former being selected before
 the later, thus avoiding mouse hover (or mouse active) on some links.

I've made a drawing to make it simpler to explain the kind of problems it causes :
http://www.phoenix-library.org/germain/testcases/intersection.jpg  (kprez rulez! :)

Div A and Div B are transparent containers for Link A and Link B (they don't appear on screen).
But Div A covers a large part of Link B.
So if you click on the (blue) covered part of Link B, nodeAtPoint() will:
- track the mouse cursor to Div A
- check that mouse is outside of Link A
- proceed to assign Div A to innerNode
- continue (unsetting mouseInside() on the way) until it reaches Link B
- assign URLElement to Link B

So Link B will have the hand cursor, but hover will only be triggered if you hover the
white, non-covered part, of Link B

Example: 
----------
http://www.w3.org/Style/CSS

Here, you can't hover "CSS Test Suites" at all, because it's totally covered by transparent containers.
"What's new" only light up when you hover on the middle region, that is : between the invisible 
containers of "Learning CSS" and "Specs".

Now the rationale behind my patch :
--------------------------------------------
- All the point of having an innerNode is "there can be only one hovered branch at a time,
 and one active container if it's a click event".
- Thus there's no point in selecting an innerNode that has no "hasHover" or "hasActive", better wait until :
  A) we encounter an URLElement (and we give it the innerNode)
or
 B) we encounter a better innerNode, with hover or active.
or
 C) we default to the root node.

This doesn't change the logic : it's just about being smarter about the choice of innerNode.

+        if (!info.innerNode() && (isRoot() || (style() && style()->hasHover()) || (info.active() && style()->hasActive())))
             info.setInnerNode(element());
[...]
                     info.setURLElement(p->element());
+                    if (!info.innerNode())
+                        info.setInnerNode(element());

I'm waiting for your comments - it would be great if at least point 1) made it's way to KDE 3.1
because it's the most obvious and the most ennoying (links inaccessibles in a lot of DHTML pages).

Cheers,

Germain







-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_object.cpp.3.patch
Type: text/x-diff
Size: 1552 bytes
Desc: not available
URL: 

From bastian at kde.org  Sat Jul 13 18:35:49 2002
From: bastian at kde.org (Waldo Bastian)
Date: Sat, 13 Jul 2002 10:35:49 -0700
Subject: how Windows browsers encode URL [Re: why the % cruft?]
In-Reply-To: <200207131248.49214.lars@trolltech.com>
References: <200207081353.03199.hetz@kde.org> <200207121215.13919.bastian@kde.org> <200207131248.49214.lars@trolltech.com>
Message-ID: <200207131035.49098.bastian@kde.org>

On Saturday 13 July 2002 03:48 am, Lars Knoll wrote:
> > On Friday 12 July 2002 03:37 am, Lars Knoll wrote:
> > > So putting a Unicode URL into KURL, then setting the encoding to
> > > latin1, and afterwards to eg. utf8 should not result in any operation
> > > that looses data.
> >
> > I fail to see why it is so hard to set the encoding right the first time.
> > You don't read HTML pages as "latin1" first and then later change the
> > QStrings to correct for the fact that the encoding should have been utf8,
> > do you?
> >
> > If you set the wrong encoding then KURL::url() will return the wrong
> > result. If you continue to work with those wrong results then things will
> > not automagically correct themselves after you throw them into a KURL
> > with another encoding set.
>
> I think you misunderstand me. Sure that KURL::url() returns a wrong result
> with a wrong encoding. My point is more that we actually should never need
> to call url() before actually sending it out over the wire in a request as
> it can be an operation where we loose information.

Tell that to khtml which converts back and forth between KURL and QString.

Take e.g. DOM::DocumentImpl: 
QString completeURL(const QString& url) 
{ return KURL(baseURL(),url,m_decoderMibEnum).url(); };

(I added the proper encoding yesterday, so now it works)

> When constructing one URL from another, we should probably use the decoded
> variants so no information is lost. KURL should provide all means to do
> that, so you can set arbitrary unicode strings and only when sending it out
> as part of a request will it get transformed into an encoding.

That's waht happens if you do:
KURL u;
u.setPath(path_str);

But if you do
url_str = textCodec->toUnicode(url_cstr);
KURL u(url_str);

it is important to preserve the original encoding of url_cstr and for that we 
need to know what it was.

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com




From david at mandrakesoft.com  Sat Jul 13 18:54:59 2002
From: david at mandrakesoft.com (David Faure)
Date: Sat, 13 Jul 2002 19:54:59 +0200
Subject: About khtml/xml/dom2_eventsimpl.cpp revision 1.22
In-Reply-To: 
References: 
Message-ID: <200207131954.59795.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 13 July 2002 12:47, you wrote:
> Hi David,
> 
> revision 1.22
> date: 2002/03/07 15:07:34;  author: faure;  state: Exp;  lines: +4 -1
> -  qKeyEvent->ignore();
> +  // Events are supposed to be accepted by default in Qt!
> +  // This line made QLineEdit's keyevents be ignored, so they were sent
> to the khtmlview
> +  // (and e.g. space would make it scroll down)
> +  //qKeyEvent->ignore();
> 
> This patch makes that the scroll keys don't work when a link has the
> focus. Shouldn't XXEdit event handles mark qKeyEvent as accepted?

Hmm, I'm no expert on the question, and I don't remember the big
picture (if I ever grasped it ;).

Anyway from the above comment: we could also state that this default 
behaviour (accepting) is correct, and that the fix would be for the link
to ignore (pass up, whatever) any keyevent it doesn't handle?

This needs more investigation, sorry I can't do it today.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2-beta2 is out! http://dot.kde.org/1025176121/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9MGlz72KcVAmwbhARAmYFAKCHifaqW8ognZsCY+Y817PdXyCJPQCdFgx/
bcHLBkTedTpnzZJvgSU0GxA=
=H+R5
-----END PGP SIGNATURE-----




From koos.vriezen at xs4all.nl  Sat Jul 13 19:07:41 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 13 Jul 2002 20:07:41 +0200 (CEST)
Subject: About khtml/xml/dom2_eventsimpl.cpp revision 1.22
In-Reply-To: <200207131954.59795.david@mandrakesoft.com>
References: <200207131954.59795.david@mandrakesoft.com>
Message-ID: 



On Sat, 13 Jul 2002, David Faure wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Saturday 13 July 2002 12:47, you wrote:
> > Hi David,
> >
> > revision 1.22
> > date: 2002/03/07 15:07:34;  author: faure;  state: Exp;  lines: +4 -1
> > -  qKeyEvent->ignore();
> > +  // Events are supposed to be accepted by default in Qt!
> > +  // This line made QLineEdit's keyevents be ignored, so they were sent
> > to the khtmlview
> > +  // (and e.g. space would make it scroll down)
> > +  //qKeyEvent->ignore();
> >
> > This patch makes that the scroll keys don't work when a link has the
> > focus. Shouldn't XXEdit event handles mark qKeyEvent as accepted?
>
> Hmm, I'm no expert on the question, and I don't remember the big
> picture (if I ever grasped it ;).

Me neither, but I've played with it a bit. Reverting version 1.22 and do a

diff -u -3 -p -r1.278 html_formimpl.cpp
--- html/html_formimpl.cpp      2002/07/05 00:34:46     1.278
+++ html/html_formimpl.cpp      2002/07/13 18:05:26
@@ -656,6 +656,7 @@ void HTMLGenericFormElementImpl::default
            evt->id()==EventImpl::KHTML_KEYUP_EVENT)
        {
            KeyEventImpl * k = static_cast(evt);
+            k->qKeyEvent->accept();
            if (k->keyVal() == QChar('\n').unicode() && m_render &&
m_render->isWidget() && k->qKeyEvent)
                QApplication::sendEvent(static_cast(m_render)->widget(), k->qKeyEvent);
        }

here seems to work.

> Anyway from the above comment: we could also state that this default
> behaviour (accepting) is correct, and that the fix would be for the link
> to ignore (pass up, whatever) any keyevent it doesn't handle?

Yes, that could probably also work...

Thanks,

Koos




From mueller at kde.org  Sat Jul 13 19:19:21 2002
From: mueller at kde.org (Dirk Mueller)
Date: Sat, 13 Jul 2002 20:19:21 +0200
Subject: [PATCH]  various nodeAtPoint() fixes
In-Reply-To: <200207131755.20637.germain@ebooksfrance.com>
References: <200207131755.20637.germain@ebooksfrance.com>
Message-ID: <20020713181921.GA30698@matrix.wg>

On Sam, 13 Jul 2002, Germain Garand wrote:

> I've dived since a week into nodeAtPoint's internals to solve a number of problems
>  with mouse hovering and link detection.

Very nice! I'm quite impressed by the precise analysis and the patch!

> 
> - 1°: relative coordinates change don't propagate recursively to childrens.
> (I posted this last week on kfm-devel but noone replied so it's still pending)

Yes, this was partly intended. I think I remember an interaction with 
absolute positioned containers in relative positioned parents. I have to 
reconstruct the testcase again, for now your change does make sense to 
me, perhaps the old reason for this code line was already fixed in an 
earlier rewrite. 


> - 2°: on the same line, the test for !child->isPositioned() need to be !child->isSpecial()
> (I do know it was changed in r1.171, but please read on.. there is more on this later)

There is another problem here.. the paint order is different than usual for 
floats, see the similiar hacks in renderflow. Therefore floats are 
"special Specialobjects" ( I really hate the name as well). 
Will think about this more. Of course you need very evil cases where the 
paint order of floats vs other elements matters, but this is already found 
on many webpages ;-)

> So Link B will have the hand cursor, but hover will only be triggered if you hover the
> white, non-covered part, of Link B
> 
> Example: 
> ----------
> http://www.w3.org/Style/CSS
> 
> Here, you can't hover "CSS Test Suites" at all, because it's totally covered by transparent containers.
> "What's new" only light up when you hover on the middle region, that is : between the invisible 
> containers of "Learning CSS" and "Specs".
> 
> Now the rationale behind my patch :
> --------------------------------------------
> - All the point of having an innerNode is "there can be only one hovered branch at a time,
>  and one active container if it's a click event".
> - Thus there's no point in selecting an innerNode that has no "hasHover" or "hasActive", better wait until :
>   A) we encounter an URLElement (and we give it the innerNode)
> or
>  B) we encounter a better innerNode, with hover or active.
> or
>  C) we default to the root node.
> 
> This doesn't change the logic : it's just about being smarter about the choice of innerNode.
> 
> +        if (!info.innerNode() && (isRoot() || (style() && style()->hasHover()) || (info.active() && style()->hasActive())))
>              info.setInnerNode(element());
> [...]
>                      info.setURLElement(p->element());
> +                    if (!info.innerNode())
> +                        info.setInnerNode(element());

I like the idea, however the implementation doesn't catch the case where an 
event listener is registered on the innermost node. 

I know your patch is emulating IE's behaviour - which is sort of flawed 
(they mainly did this for performance reasons is my bet) because there is 
nothing "special" about anchor elements in the xml / css world, unlike in 
HTML of course. 

Personally i think khtml is behaving correct in this case, although it is 
very annoying for the example page you mentioned (I've spend some hours on 
that page already)

I'll investigate this a bit more. 


Thanks for your patch, 

Dirk



From mueller at kde.org  Sat Jul 13 19:24:58 2002
From: mueller at kde.org (Dirk Mueller)
Date: Sat, 13 Jul 2002 20:24:58 +0200
Subject: About khtml/xml/dom2_eventsimpl.cpp revision 1.22
In-Reply-To: <200207131954.59795.david@mandrakesoft.com>
References:  <200207131954.59795.david@mandrakesoft.com>
Message-ID: <20020713182458.GB30698@matrix.wg>

On Sam, 13 Jul 2002, David Faure wrote:

> > This patch makes that the scroll keys don't work when a link has the
> > focus. Shouldn't XXEdit event handles mark qKeyEvent as accepted?
> 
> Hmm, I'm no expert on the question, and I don't remember the big
> picture (if I ever grasped it ;).
> 
> Anyway from the above comment: we could also state that this default 
> behaviour (accepting) is correct, and that the fix would be for the link
> to ignore (pass up, whatever) any keyevent it doesn't handle?
> 
> This needs more investigation, sorry I can't do it today.

The big picture is working around Qt bugs: Qt widgets usually only 
reimplement keydown event, not the keyup event. therefore while some 
subwidget on the page might accept (i.e. capture) a keypress event, the 
keyrelease event still arrives in the khtmlview, and has to be ignored 
there. 


-- 
Dirk (602 mails today)



From koos.vriezen at xs4all.nl  Sat Jul 13 21:35:59 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 13 Jul 2002 22:35:59 +0200 (CEST)
Subject: About khtml/xml/dom2_eventsimpl.cpp revision 1.22
In-Reply-To: <20020713182458.GB30698@matrix.wg>
References: <20020713182458.GB30698@matrix.wg>
Message-ID: 

On Sat, 13 Jul 2002, Dirk Mueller wrote:

> On Sam, 13 Jul 2002, David Faure wrote:
>
> > > This patch makes that the scroll keys don't work when a link has the
> > > focus. Shouldn't XXEdit event handles mark qKeyEvent as accepted?
> >
> > Hmm, I'm no expert on the question, and I don't remember the big
> > picture (if I ever grasped it ;).
> >
> > Anyway from the above comment: we could also state that this default
> > behaviour (accepting) is correct, and that the fix would be for the link
> > to ignore (pass up, whatever) any keyevent it doesn't handle?
> >
> > This needs more investigation, sorry I can't do it today.
>
> The big picture is working around Qt bugs: Qt widgets usually only
> reimplement keydown event, not the keyup event. therefore while some
> subwidget on the page might accept (i.e. capture) a keypress event, the
> keyrelease event still arrives in the khtmlview, and has to be ignored
> there.

Forgive me for being dumb, but you mean version 1.22 should be reverted?
And where to put the accept call, in
HTMLGenericFormElementImpl::defaultEventHandler, other places too?
HTMLAnchorElementImpl::defaultEventHandler already accepts in case of
enter.

Koos




From mueller at kde.org  Sat Jul 13 22:28:12 2002
From: mueller at kde.org (Dirk Mueller)
Date: Sat, 13 Jul 2002 23:28:12 +0200
Subject: About khtml/xml/dom2_eventsimpl.cpp revision 1.22
In-Reply-To: 
References: <20020713182458.GB30698@matrix.wg> 
Message-ID: <20020713212811.GA2631@matrix.wg>

On Sam, 13 Jul 2002, Koos Vriezen wrote:

> Forgive me for being dumb, but you mean version 1.22 should be reverted?
> And where to put the accept call, in
> HTMLGenericFormElementImpl::defaultEventHandler, other places too?
> HTMLAnchorElementImpl::defaultEventHandler already accepts in case of
> enter.

No, nothing should be reverted, because it works correctly the way it is. if 
you want it to work better, then  then make sure that 
HTMLAnchorElementImpl::defaultEventHandler  
calls setDefaultEventHandled only when it actually was able to handle 
the keypress and not all the time like it does now. 

For example it could capture space and return, and ignore the rest. 

-- 
Dirk (720 mails today)



From koos.vriezen at xs4all.nl  Sat Jul 13 23:21:06 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sun, 14 Jul 2002 00:21:06 +0200 (CEST)
Subject: About khtml/xml/dom2_eventsimpl.cpp revision 1.22
In-Reply-To: <20020713212811.GA2631@matrix.wg>
References: <20020713212811.GA2631@matrix.wg>
Message-ID: 

On Sat, 13 Jul 2002, Dirk Mueller wrote:

> No, nothing should be reverted, because it works correctly the way it is. if
> you want it to work better, then  then make sure that
> HTMLAnchorElementImpl::defaultEventHandler
> calls setDefaultEventHandled only when it actually was able to handle
> the keypress and not all the time like it does now.

No, it doesn't

--- html/html_inlineimpl.cpp    2002/03/15 22:53:08     1.109
+++ html/html_inlineimpl.cpp    2002/07/13 22:11:06
@@ -82,6 +82,8 @@ void HTMLAnchorElementImpl::defaultEvent

         if ( k ) {
             if (k->virtKeyVal() != KeyEventImpl::DOM_VK_ENTER) {
+                if (k->qKeyEvent)
+                    k->qKeyEvent->ignore();
                 HTMLElementImpl::defaultEventHandler(evt);
                 return;
             }

It just returned (NodeImpl::defaultEventHandler being empty). Adding these
two lines seems to work (as David suggested).

> For example it could capture space and return, and ignore the rest.

Space? Doesn't do anything now and it's also a scroll key.

Koos




From sam at bifrost.demon.co.uk  Sun Jul 14 14:15:58 2002
From: sam at bifrost.demon.co.uk (Samuel Penn)
Date: Sun, 14 Jul 2002 14:15:58 +0100
Subject: page-break-before
In-Reply-To: <200207121237.19879.lars@trolltech.com>
References: <200207081353.03199.hetz@kde.org> <200207111746.27336.bastian@kde.org> <200207121237.19879.lars@trolltech.com>
Message-ID: <200207141416.11598.sam@bifrost.demon.co.uk>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


Does anyone know if Konquerer/KHTML supports the various
page break tags for CSS? I'm currently trying something
like:

h1 {
    page-break-before: always;
}

or

div.section {
    page-break-after: always;
}

This doesn't behave as expected (i.e. it doesn't give a 
page break). Some print media tags are supported (since if
I have a stylesheet of media="print", the printed version
will use different colour schemes to the screen version.
However, I'm not sure whether it's my CSS at fault, or
Konqueror.

I'm using KDE 3.0, so if this support has been added since
then, then I've found a good reason to upgrade.

Cheers.

- -- 
Be seeing you,
Sam.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9MXmYf6Cy7pRwE0QRAquRAKCasJbh4LT6MNy+tLMK0XqmIo0rOgCgxX0i
djzFI1OlGgM3qdaxIgtFIBM=
=o9r3
-----END PGP SIGNATURE-----



From kudling at kde.org  Sun Jul 14 15:07:51 2002
From: kudling at kde.org (Lenny)
Date: Sun, 14 Jul 2002 16:07:51 +0200
Subject: Empty dialog pops up after pressing cancel in download dialog
Message-ID: <200207141607.51593.kudling@kde.org>

Try for example: http://www.ecs.soton.ac.uk/~cjg/AmberDB

Press "cancel" soon and after that a 100% empty dialog pops up. 

Bye
Lenny (cvs 2 days old)



From hanleyman at adelphia.net  Sun Jul 14 17:22:19 2002
From: hanleyman at adelphia.net (Doug Hanley)
Date: Sun, 14 Jul 2002 12:22:19 -0400
Subject: MMB opens in new tab
Message-ID: <200207141222.19644.hanleyman@adelphia.net>

Hi,

I was checking out the webcvs logs and I noticed that there was some sign of a 
mmb opens in new tab patch coming soon.  I'm not sure if you've already done 
this, or if you haven't started yet, but I just wanted to tell you that I 
have that feature already in my tree, so I guess I'll just show you what I 
have right here:

(this function is called in the beginning of both versions of 
slotCreateNewWindow, i'm not sure if thats correct)

void KonqMainWindow::createNewTab( const KURL &url, const KParts::URLArgs 
&args )
{
  bool unknown = false;
  KMimeType::Ptr mimeType = KMimeType::findByURL( url );
  QString mimeName = mimeType->name();
  QString mimeComment = mimeType->comment();    
  if (mimeName == "application/octet-stream") {
    unknown = true;
    mimeName = "text/html";
  }
  KonqView* newView = 0L;
  newView = m_pViewManager->addTab( mimeName, mimeComment );
  if (newView == 0L) return;
  if (unknown) new KonqRun( this, newView, url );
  else openURL( newView, url, args );
  static_cast(m_pViewManager->docContainer())->showPage( 
newView->frame() );
}

I also changed the popup tab code to something very similar to this, because 
it fixes a bug where if you open a link to an image from a webpage in a new 
tab, and the image is not a local file, it displays the image as text.  The 
sollution is kind of hacky though.

Also, I though that the options for tabs should go under a "Tabbed Browsing" 
tab in the "Web Browsing->Konqueror Browser", because tabbed browsing is used 
almost exclusively for web surfing, so this would seem the most intuitive 
choice.  I also have some code for that in my tree which I am cleaning up 
little.

So, if you've whipped up some code for this already, i would love to see it, 
so that way we can kind of pool our resources, and come up with the best 
sollution.

Thanks!

-- Doug



From adawit at kde.org  Sun Jul 14 19:27:01 2002
From: adawit at kde.org (Dawit A.)
Date: Sun, 14 Jul 2002 14:27:01 -0400
Subject: PATCH: Open With...
Message-ID: <200207141427.01882.adawit@kde.org>

Hello,

Here is a patch that changes/fixes a couple of things in the Open With... 
dialog box:

- Follow the "Open With->" format even if only one application is associated 
with a given mime-type.  I guess this is a matter of preference, but it would 
make the behavior consistent plus reduce the real-state the popup menu 
occupies.

- Make sure that separators are added properly.  Currently there were 
cuircumstances where a double/triple separators were being drawn. The
way to make sure this does not happen is to only add separators "before"
adding new menu items, never "after".  The culprit for the above problem were 
the plugins, specifically the kuick plugin.  As such, with the patch attached 
below, a plugin no longer needs to add any separator unless it specifically 
needs to separate its own items...

Regards,
Dawit A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: konq_popupmenu.diff
Type: text/x-diff
Size: 8080 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kuick.diff
Type: text/x-diff
Size: 1481 bytes
Desc: not available
URL: 

From binner at kde.org  Sun Jul 14 20:47:47 2002
From: binner at kde.org (Stephan Binner)
Date: Sun, 14 Jul 2002 21:47:47 +0200
Subject: MMB opens in new tab
Message-ID: <200207142147.47331.binner@kde.org>

Doug Hanley wrote:

> I was checking out the webcvs logs and I noticed that there was some sign of 
> a mmb opens in new tab patch coming soon.  I'm not sure if you've already 

http://webcvs.kde.org/cgi-bin/cvsweb.cgi/kdebase/konqueror/konq_mainwindow.cc.diff?r1=1.1018&r2=1.1019

This is result of yesterday night hacking (note missing mimetype, only in one 
slotCreateNewWindow) after the question for it came up on #kde irc channel.

> if you haven't started yet, but I just wanted to tell you that I have that
> feature already in my tree, so I guess I'll just show you what I have right

If something at least partly works (and doesn't break anything else) I propose 
you commit what you have more frequently to CVS. And at this state of release
it is also a good idea to list features you will implement in the KDE 3.1 
feature list so others can see what you are working on.

> Also, I though that the options for tabs should go under a "Tabbed Browsing" 
> tab in the "Web Browsing->Konqueror Browser", because tabbed browsing is
> used almost exclusively for web surfing, so this would seem the most 

I'm not happy with current position too, as it's in a different dialog than
"Right click goes back in history" which works for file-mode too. I wouldn't
say that tabbed browsing will be exclusively used for web surfing. :-)

> So, if you've whipped up some code for this already, i would love to see it, 
> so that way we can kind of pool our resources, and come up with the best 
> sollution.

See above, I guess your solution is more advanced (because you know the code).
Feel free to replace the commit. Can you comment on if you plan/work to im-
plement keyboard shortcuts to switch tabs, close query dialog, close buttons?

Bye,
   Steve



From bastian at kde.org  Sun Jul 14 21:09:05 2002
From: bastian at kde.org (Waldo Bastian)
Date: Sun, 14 Jul 2002 13:09:05 -0700
Subject: PATCH: Open With...
In-Reply-To: <200207141427.01882.adawit@kde.org>
References: <200207141427.01882.adawit@kde.org>
Message-ID: <200207141309.05377.bastian@kde.org>

On Sunday 14 July 2002 11:27 am, Dawit A. wrote:
> Hello,
>
> Here is a patch that changes/fixes a couple of things in the Open With...
> dialog box:
>
> - Follow the "Open With->" format even if only one application is
> associated with a given mime-type.  I guess this is a matter of preference,
> but it would make the behavior consistent plus reduce the real-state the
> popup menu occupies.

Yes, I think this would be a good change.

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com




From till at snafu.de  Sun Jul 14 22:33:05 2002
From: till at snafu.de (Till Krech)
Date: Sun, 14 Jul 2002 23:33:05 +0200
Subject: QXEmbed reparent patch
Message-ID: <200207142333.05330.till@snafu.de>

Hi,

I discovered a problem in QXEmbed (kdelibs/kdeui/qxembed.cpp).
QXEmbed is now also used by the java applet server and the nspluginviewer.

Problem:
http://www.shockwave.com embeds several flash movies. Although 
QXEmbed::embed() is called, the movies are not always embedded but appear in 
a toplevel window managed by the windowmanager.

I think that this is the same problem why applets are not always embedded when 
running konqi under sawfish/gnome.

The trick is, to retry to XReparentWindow the window for up to 50 times with 
slight delays (usleep(1000)) and look if it has already the required parent 
with XQueryTree.

Could you please look at the attached patch, if it solves the problem or if it 
is just a workaround. Some Xlib knowledge required.

regards, till
 
-- 
SuSE Linux 8.0 (i386) 2.4.18-64GB-SMP
KDE: 3.0.6 (KDE 3.1 alpha1)
Qt: 3.0.6-snapshot-20020712
-------------- next part --------------
A non-text attachment was scrubbed...
Name: qxembed-reparent.patch
Type: text/x-diff
Size: 3792 bytes
Desc: not available
URL: 

From staikos at kde.org  Mon Jul 15 01:10:12 2002
From: staikos at kde.org (George Staikos)
Date: Sun, 14 Jul 2002 20:10:12 -0400
Subject: QXEmbed reparent patch
In-Reply-To: <200207142333.05330.till@snafu.de>
References: <200207142333.05330.till@snafu.de>
Message-ID: <200207142010.12701.staikos@kde.org>

On July 14, 2002 17:33, Till Krech wrote:
> Hi,
>
> I discovered a problem in QXEmbed (kdelibs/kdeui/qxembed.cpp).
> QXEmbed is now also used by the java applet server and the nspluginviewer.
>
> Problem:
> http://www.shockwave.com embeds several flash movies. Although
> QXEmbed::embed() is called, the movies are not always embedded but appear
> in a toplevel window managed by the windowmanager.
>
> I think that this is the same problem why applets are not always embedded
> when running konqi under sawfish/gnome.
>
> The trick is, to retry to XReparentWindow the window for up to 50 times
> with slight delays (usleep(1000)) and look if it has already the required
> parent with XQueryTree.
>
> Could you please look at the attached patch, if it solves the problem or if
> it is just a workaround. Some Xlib knowledge required.

   What a great idea :)  I'm going to try it right now!

-- 

George Staikos




From staikos at kde.org  Mon Jul 15 01:26:52 2002
From: staikos at kde.org (George Staikos)
Date: Sun, 14 Jul 2002 20:26:52 -0400
Subject: QXEmbed reparent patch
In-Reply-To: <200207142333.05330.till@snafu.de>
References: <200207142333.05330.till@snafu.de>
Message-ID: 

On July 14, 2002 17:33, Till Krech wrote:
> Hi,
>
> I discovered a problem in QXEmbed (kdelibs/kdeui/qxembed.cpp).
> QXEmbed is now also used by the java applet server and the nspluginviewer.
>
> Problem:
> http://www.shockwave.com embeds several flash movies. Although
> QXEmbed::embed() is called, the movies are not always embedded but appear
> in a toplevel window managed by the windowmanager.
>
> I think that this is the same problem why applets are not always embedded
> when running konqi under sawfish/gnome.
>
> The trick is, to retry to XReparentWindow the window for up to 50 times
> with slight delays (usleep(1000)) and look if it has already the required
> parent with XQueryTree.
>
> Could you please look at the attached patch, if it solves the problem or if
> it is just a workaround. Some Xlib knowledge required.

  This works very well for me.  Please commit to cvs, at least until a proper 
solution can be found if this isn't the best approach.  (I dont' see anything 
wrong with it though)

-- 

George Staikos




From mueller at kde.org  Mon Jul 15 01:36:08 2002
From: mueller at kde.org (Dirk Mueller)
Date: Mon, 15 Jul 2002 02:36:08 +0200
Subject: QXEmbed reparent patch
In-Reply-To: <200207142333.05330.till@snafu.de>
References: <200207142333.05330.till@snafu.de>
Message-ID: 

On Son, 14 Jul 2002, Till Krech wrote:

> The trick is, to retry to XReparentWindow the window for up to 50 times with 
> slight delays (usleep(1000)) and look if it has already the required parent 
> with XQueryTree.

ewww.. both hardcoded usleeps and XQueryTree's are awful. XQueryTree is 
terrible slow. 

I think what you're looking for is a syncX(). 


-- 
Dirk (68 mails today)



From staikos at kde.org  Mon Jul 15 05:36:13 2002
From: staikos at kde.org (George Staikos)
Date: Mon, 15 Jul 2002 00:36:13 -0400
Subject: khtml freeze
Message-ID: <200207150036.13220.staikos@kde.org>




KHTML freezes, using a fair amount of cpu, with the following assert:

ASSERT: "m_multiple" in html_formimpl.cpp (1404)


on the url:

http://www.sofitel.com/sofitel/gb/actualite/fiches_actu/s_athenes.html


-- 

George Staikos




From hanleyman at adelphia.net  Mon Jul 15 06:27:38 2002
From: hanleyman at adelphia.net (Doug Hanley)
Date: Mon, 15 Jul 2002 01:27:38 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207142147.47331.binner@kde.org>
References: <200207142147.47331.binner@kde.org>
Message-ID: <200207150127.38369.hanleyman@adelphia.net>

On Sunday 14 July 2002 03:47 pm, Stephan Binner wrote:

> This is result of yesterday night hacking (note missing mimetype, only in
> one slotCreateNewWindow) after the question for it came up on #kde irc
> channel.

So you're saying only to do the tab code in the first slotCreateNewWindow (the 
one you changed in the cvs).

> If something at least partly works (and doesn't break anything else) I
> propose you commit what you have more frequently to CVS. And at this state
> of release it is also a good idea to list features you will implement in
> the KDE 3.1 feature list so others can see what you are working on.

Ok, I'll commit what I have now then.  And I'll write up a planned feature 
list very soon.

> See above, I guess your solution is more advanced (because you know the
> code). Feel free to replace the commit. Can you comment on if you plan/work
> to im- plement keyboard shortcuts to switch tabs, close query dialog, close
> buttons?

I made some code that allowed for the switching of tabs, but unfortunately I 
couldn't figure out how to catch keyboard events (e.g. Shift+Left/Right), so 
I couldn't finish it.  I tried KAccel, but it didn't seem to work.  If you'd 
like, I could commit the part where I add slot functions to go left and 
right, and someone else could fill in the rest.

As for the query close dialog, I have that too, but it doesn't have the "Don't 
show this in the future" check box.  Is there an easy way to do that?  
Perhaps with a static method from KMessageBox?  Or would I have to use 
KDialog?  Should I commit it anyway?

As for close buttons, that would definitely involve custom widget painting, 
something which I have absolutely no experience with, so I probably won't be 
working on that.

-- Doug



From germain at ebooksfrance.com  Mon Jul 15 07:04:53 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Mon, 15 Jul 2002 07:04:53 +0100
Subject: [PATCH]  various nodeAtPoint() fixes
In-Reply-To: <20020713181921.GA30698@matrix.wg>
References: <200207131755.20637.germain@ebooksfrance.com> <20020713181921.GA30698@matrix.wg>
Message-ID: <200207150704.53900.germain@ebooksfrance.com>

Le Samedi 13 Juillet 2002 19:19, Dirk Mueller a écrit :
[..]
> > - 1°: relative coordinates change don't propagate recursively to
> > childrens. (I posted this last week on kfm-devel but noone replied so
> > it's still pending)
>
> Yes, this was partly intended. I think I remember an interaction with
> absolute positioned containers in relative positioned parents.

I've tried to do something like that here :
http://www.phoenix-library.org/germain/testcases/bug_khtml_abs_child_in_rel_parent.html

Oddly enough, in such a case, the absolute translation is not rendered, but 
nodeAtPoint() still think the link is were it should be : in the small golden 
box.

>
> Personally i think khtml is behaving correct in this case, although it is
> very annoying for the example page you mentioned (I've spend some hours on
> that page already)
>

Frankly I think not... I've been haunted all the WE by that...

I'll elaborate, still on the http://www.w3.org/Style/CSS/ example :

When you hover the invisibly covered part of "What's New ?", the innermost 
node is indeed, formally, .

But how is it that the tree walking continues and finally elects "What's New" 
as a good candidate for the hand cursor ?
From the formal point of view, the search should stop at 
...
A striking illustration of that is when you hover "nearby" in the fixed menu. 
Should we really get "What's New"'s hand cursor ?

What I want to advocate here is : there is a need to distinguish between two 
kind of inner nodes :

- formal ones ("P" is indeed the innermost node, may it be invisible or 
opaque) [owner: innerNode] 
- visual ones ( for human sight, the innermost node is the "A" tag. If "P" was 
overriding something on "A", it would be "P") [owner: visualNode]

In fact, khtml already does this distinction with URLElement, since it can be 
different from the innerNode (too bad it's only for URLs).

I've implemented roughly such a mechanism in the attached patch,
and it looks promizing...
For instance, try comparing the behaviour on this slightly modified version :
http://www.phoenix-library.org/germain/testcases/www.w3.org/Style/CSS/          
 
Anyway, feel free to have a look or simply throw it to the overcrowded Hell of 
Lame ! ;-)

Germain
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_object.patch
Type: text/x-diff
Size: 5065 bytes
Desc: not available
URL: 

From david at mandrakesoft.com  Mon Jul 15 09:01:28 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 15 Jul 2002 10:01:28 +0200
Subject: MMB opens in new tab
In-Reply-To: <200207141222.19644.hanleyman@adelphia.net>
References: <200207141222.19644.hanleyman@adelphia.net>
Message-ID: <200207151001.28681.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 14 July 2002 18:22, Doug Hanley wrote:
>   KMimeType::Ptr mimeType = KMimeType::findByURL( url );
Ouch. That's not good at all.
This function doesn't give reliable results, in particular over HTTP.
You work around that by assuming HTML, but there is more than HTML that
one can get over HTTP. Think images, for instance.

Hmm, ok, I see you use a KonqRun if the mimetype was unknown, but....
the danger of the code that was posted here is more precisely in case
findByURL does a wrong assumption (as it does on some protocols).

Why does addTab need to know the mimetype? Can't it create an empty
tab, and let openView (directly via openURL, or via KonqRun), take care
of creating the right part into it?

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2-beta2 is out! http://dot.kde.org/1025176121/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9MoFY72KcVAmwbhARAq2WAJ9RhBfyY+q+yWR/f24bhiMQuj4DNwCdGCdw
5UNyLgqjwRYMJl4/ZWRN77I=
=FhGc
-----END PGP SIGNATURE-----




From david at mandrakesoft.com  Mon Jul 15 09:04:53 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 15 Jul 2002 10:04:53 +0200
Subject: PATCH: Open With...
In-Reply-To: <200207141427.01882.adawit@kde.org>
References: <200207141427.01882.adawit@kde.org>
Message-ID: <200207151004.54111.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 14 July 2002 20:27, Dawit A. wrote:
> - Make sure that separators are added properly.  Currently there were 
> cuircumstances where a double/triple separators were being drawn. The
> way to make sure this does not happen is to only add separators "before"
> adding new menu items, never "after".  The culprit for the above problem were 
> the plugins, specifically the kuick plugin.  As such, with the patch attached 
> below, a plugin no longer needs to add any separator unless it specifically 
> needs to separate its own items...

I don't see the point of this change. IIRC the logic was simply the other way round:
"always add separators _after_ adding new menu items, never _before_".

The kuick plugin did it wrong - isn't it simpler to fix it?

I'm afraid you might have missed some cases, this popupmenu code (particularly
the separators) is a bit touchy (since it's used in so many different ways), and has
been fixed several times already, I'm not too happy with throwing all this away.

Since you investigated the problem - can't this be fixed with the old logic?

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2-beta2 is out! http://dot.kde.org/1025176121/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9MoIm72KcVAmwbhARArO0AKCdgn8AQYS9PK1j4qbPiK+n/eVCxgCdFIvQ
3Am+jzW0PUXBnbYN+TciSFY=
=NtCQ
-----END PGP SIGNATURE-----




From david at mandrakesoft.com  Mon Jul 15 10:23:27 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 15 Jul 2002 11:23:27 +0200
Subject: Empty dialog pops up after pressing cancel in download dialog
In-Reply-To: <200207141607.51593.kudling@kde.org>
References: <200207141607.51593.kudling@kde.org>
Message-ID: <200207151123.27554.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 14 July 2002 16:07, Lenny wrote:
> Try for example: http://www.ecs.soton.ac.uk/~cjg/AmberDB
> 
> Press "cancel" soon and after that a 100% empty dialog pops up. 

Kate bug, not khtml/konq (this is a text file).
Anyway, fixed.

(tip for anyone who wants to find out where a dialog box comes from:
gdb konqueror  / bt -> tells you very precisely).

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice-1.2-beta2 is out! http://dot.kde.org/1025176121/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9MpSP72KcVAmwbhARAofzAJ9W7Myo+dzZcRyykONP0c0L5eK3fQCcCksB
fm1zyv/3oyv7VVoAeqbPgUo=
=/ktI
-----END PGP SIGNATURE-----




From lars at trolltech.com  Mon Jul 15 10:33:19 2002
From: lars at trolltech.com (Lars Knoll)
Date: Mon, 15 Jul 2002 11:33:19 +0200
Subject: page-break-before
In-Reply-To: <200207141416.11598.sam@bifrost.demon.co.uk>
References: <200207081353.03199.hetz@kde.org> <200207121237.19879.lars@trolltech.com> <200207141416.11598.sam@bifrost.demon.co.uk>
Message-ID: <200207151133.19020.lars@trolltech.com>


> Does anyone know if Konquerer/KHTML supports the various
> page break tags for CSS? I'm currently trying something
> like:
>
> h1 {
>     page-break-before: always;
> }
>
> or
>
> div.section {
>     page-break-after: always;
> }
>
> This doesn't behave as expected (i.e. it doesn't give a
> page break). Some print media tags are supported (since if

No, page-break-before and after are not implemented currently.

> I have a stylesheet of media="print", the printed version
> will use different colour schemes to the screen version.
> However, I'm not sure whether it's my CSS at fault, or
> Konqueror.

The print media type is implemented, to you can use a different style sheet 
for printing.

Cheers,
Lars

> I'm using KDE 3.0, so if this support has been added since
> then, then I've found a good reason to upgrade.




From mueller at kde.org  Mon Jul 15 10:52:04 2002
From: mueller at kde.org (Dirk Mueller)
Date: Mon, 15 Jul 2002 11:52:04 +0200
Subject: khtml freeze
In-Reply-To: <200207150036.13220.staikos@kde.org>
References: <200207150036.13220.staikos@kde.org>
Message-ID: <20020715095204.GA18297@matrix.wg>

On Mon, 15 Jul 2002, staikos George Staikos wrote:

> KHTML freezes, using a fair amount of cpu, with the following assert:
> 
> ASSERT: "m_multiple" in html_formimpl.cpp (1404)
> 
> 
> on the url:
> 
> http://www.sofitel.com/sofitel/gb/actualite/fiches_actu/s_athenes.html

I don't see any  element on that page.

   Hm I did not produce this myself, but I saw it reproduced twice in a row 
with new browser instances.  I'll find out tonight what method was used to 
trigger it.

-- 

George Staikos




From staikos at kde.org  Mon Jul 15 15:32:58 2002
From: staikos at kde.org (George Staikos)
Date: Mon, 15 Jul 2002 10:32:58 -0400
Subject: khtml freeze
In-Reply-To: <200207151005.28539.staikos@kde.org>
References: <200207150036.13220.staikos@kde.org> <20020715095204.GA18297@matrix.wg> <200207151005.28539.staikos@kde.org>
Message-ID: <200207151032.58486.staikos@kde.org>

On Monday 15 July 2002 10:05, George Staikos wrote:
> On Monday 15 July 2002 05:52, Dirk Mueller wrote:
> > On Mon, 15 Jul 2002, staikos George Staikos wrote:
> > > KHTML freezes, using a fair amount of cpu, with the following assert:
> > >
> > > ASSERT: "m_multiple" in html_formimpl.cpp (1404)
> > >
> > >
> > > on the url:
> > >
> > > http://www.sofitel.com/sofitel/gb/actualite/fiches_actu/s_athenes.html
> >
> > I don't see any s, anchors and other fontstyling element, but 
should not actually render them because the container is not %flow !?!
That sucks beyond belief !

People do style their legends, do put imgs in their legends, because they are 
allowed to do so... 

Now, I don't know how IE render them, because I have no IE here and that's not 
my reference (my reference is KHTML :), but yes Mozilla style them, Opera 
style them ... so what ?

> then search for a legend element in the DOM tree, not the rendering tree,

I do ensure that legend is unique inside it's HTMLFieldsetElementImpl, but you 
could only extract #PCDATAs from here, as innerText() do... that's not 
following the DTD either... why would they be more important than e.g. an 
image ?

G.




From germain at ebooksfrance.com  Wed Jul 24 12:56:45 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Wed, 24 Jul 2002 12:56:45 +0100
Subject: [Patch] a renderer for 
 and 
Message-ID: <200207241256.45966.germain@ebooksfrance.com>

Le Mercredi 24 Juillet 2002 09:53, Till Krech a écrit :
> Hi,
>
> well done!
> I just ask myself why the form elements were ignored before. Shouldn't any
> body content be rendered as normal when a tag is unknown in a browser ?
>
> So, your patch a) fixes a grave bug. b) adds a nice feature.
>
> I would say, it's worth committing, and should even be backported because
> without your patch the form isn't displayed at all - but I cannot decide
> about this.
> Dirk - are you here ? What do you think ?
>
> regards, till

Thanks for your nice comments Till !
I would really love to see (at least minimal : ie. non destructive) support
for fieldset make it's way back to the 3.0 serie...
For now, I'm just piling sandbags, donning asbestos,and ducking for cover, as
LEGEND is a touchy subject among purists :)

Germain

> On Wednesday 24 July 2002 04:13, Germain Garand wrote:
> > Hello there,
> >
> > I noticed a while back that HTML 4's  and  elements
> > didn't have a renderer in KHTML, so I've worked on this topic.
> > It was ennoying to sometime miss forms because they were wrapped in
> > those.
> >
> > I intended to respect HTML 4.01's DTD, so tell me if I've missed
> > something.
> >
> > Here is a testcase:
> > http://www.phoenix-library.org/germain/testcases/testfieldset.html
> >
> > And a screenshot after patch :
> > http://www.phoenix-library.org/germain/shots/konq_fieldset.png
> >
> > Cheers,
> >
> > Germain

-------------------------------------------------------




From lucy-ples at mtu-net.ru  Wed Jul 24 12:55:50 2002
From: lucy-ples at mtu-net.ru (Vadim Plessky)
Date: Wed, 24 Jul 2002 15:55:50 +0400
Subject: post this to bugzilla?
In-Reply-To: <20020724094642.GA30721@matrix.wg>
References: <200207240058.03183.hetz@kde.org> <20020724094642.GA30721@matrix.wg>
Message-ID: <200207241555.50989.lucy-ples@mtu-net.ru>

On Wednesday 24 July 2002 1:46 pm, Dirk Mueller wrote:
|  On Mit, 24 Jul 2002, Hetz Ben Hamo wrote:
|  > Should I post it in bugzilla or is this problem being taken care of?
|
|  As it has been said here already, I know about the problems. Please wait
|  till the weekend, I have no time during the week to fix this.

Dirk,

Can you please check this URL as well:
http://www.geocrawler.com/lists/3/SourceForge/2311/25/8215112/
I think layout is broken again because of tables.
(Tested with KDE 3.0.2)

|
|  Thanks,

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/




From lucy-ples at mtu-net.ru  Wed Jul 24 13:38:17 2002
From: lucy-ples at mtu-net.ru (Vadim Plessky)
Date: Wed, 24 Jul 2002 16:38:17 +0400
Subject: HTML for KMail [Re: khtml and table widths]
In-Reply-To: <200207181535.25534.klingens@kde.org>
References: <200207180958.06690.Ladislav.Strojil@seznam.cz> <200207181729.45571.lucy-ples@mtu-net.ru> <200207181535.25534.klingens@kde.org>
Message-ID: <200207241638.17351.lucy-ples@mtu-net.ru>

On Thursday 18 July 2002 5:35 pm, Martijn Klingens wrote:
|  On Thursday 18 July 2002 15:29, Vadim Plessky wrote:
|  > It seems my HTML example hasn't impressed you.
|  > ok, please take XML than!
|  > Ladislav: thanks for original KMail's HTML/CSS, I used some of those
|  > definitions in example below.
|  >
|  > [ ... ]
|  >
|  >  left { display: block; width: 4em; float: left;
|
|                           ^^^^^^^^^^^^^
|  This one won't impress me either as a replacement for a table, because
| again it cannot possibly guarantee that all elements are properly
| positioned in a 2x3 grid. Depending on translations that might break the
| layout horribly...

Checking code on one of C-Net pages, I found following JS example, which can 
do the trick if fixed layout (like width: 4em; ) is not o.k.



You can "extract" actual width of document (and its height) using DOM methods 
and/or JS bindings, and re-layout document in accordance

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/




From oever at fenk.wau.nl  Wed Jul 24 13:51:41 2002
From: oever at fenk.wau.nl (Jos van den Oever)
Date: Wed, 24 Jul 2002 14:51:41 +0200
Subject: web pages as text
Message-ID: <200207241451.41326.oever@fenk.wau.nl>

Hi all,

In the current cvs, when viewing a web page by typing the URL in the location 
bar, after viewing a text file in the embedded viewer, the web page's source 
code is shown instead of the rendered file.

This is probably due to some editing after a tab discussion a few days ago.

When this happens, you can click on the 'home' button and visit the URL again. 
Now the web page appears.

My base system is SuSE 8.0.

Best regards, Jos




From germain at ebooksfrance.com  Wed Jul 24 14:13:53 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Wed, 24 Jul 2002 14:13:53 +0100
Subject: [Patch] Re: web pages as text
In-Reply-To: <200207241451.41326.oever@fenk.wau.nl>
References: <200207241451.41326.oever@fenk.wau.nl>
Message-ID: <200207241413.53656.germain@ebooksfrance.com>

Le Mercredi 24 Juillet 2002 13:51, Jos van den Oever a écrit :
> Hi all,
>
> In the current cvs, when viewing a web page by typing the URL in the
> location bar, after viewing a text file in the embedded viewer, the web
> page's source code is shown instead of the rendered file.
>
> This is probably due to some editing after a tab discussion a few days ago.
>

No, this is a bad kpart policy. See thread "Is someone working on #41620"

 It currently says "if the part can handle the next mimetype, keep it".

Now it seems it was agreed to switch to the much better 
"if next mimetype is different, check what is the preferred viewer for the new 
mimetype, and use that"

David Faure made a patch (attached) for this just before leaving for holidays, 
but it was not applied...
Maybe someone could apply it ?

It would be good to have this for Beta 1, which is scheduled for July 28 th... 


G.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml_part.cpp.diff
Type: text/x-diff
Size: 769 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: konq_view.cc.diff
Type: text/x-diff
Size: 2432 bytes
Desc: not available
URL: 

From germain at phoenix-library.org  Wed Jul 24 17:33:30 2002
From: germain at phoenix-library.org (Germain Garand)
Date: Wed, 24 Jul 2002 17:33:30 +0100
Subject: Bug#34634 acknowledged by developer (CSS2 absolute positionning does not work when specifying top property in percent (%) (testcase))
In-Reply-To: <200207240753.45718@bilbo.math.uni-mannheim.de>
References: <200207231451.34772@bilbo.math.uni-mannheim.de> <200207240412.09805.germain@phoenix-library.org> <200207240753.45718@bilbo.math.uni-mannheim.de>
Message-ID: <200207241733.30023.germain@phoenix-library.org>

Le Mercredi 24 Juillet 2002 06:53, vous avez écrit :
> Am Mittwoch, 24. Juli 2002 05:12 schrieben Sie:
> > Le Mardi 23 Juillet 2002 14:03, vous avez écrit :
> > > I've looked at your test case, I think it is displayed correctly now.
> >
> > No it's not...
>
> Sh*t, it would have been so nice...
>
> > CSS2 "top" property expressed in percent within an absolute positioning
> > should be made relative to the viewport.
>
> So the headline should always be displayed in the middle of the window,
> regardless how much text there is in, right?
>

Right - but that is not a spec.
In fact, it's yet another objectable zone in the spec. An absolute purist 
would say KHTML behaves right, whereas all other main stream browsers made it 
relative to the viewport.

The reason for that is there is no way to specify a relative-to-the-viewport 
thing in CSS (because the notion of viewport exists only for "fixed" 
positioned elements - that is : elements that don't move when you scroll the 
page).

However, practically, web designers (and all the others as well :) need to 
have a way of specifying a position when the page displays, otherwise they 
wouldn't know if their elements are there or not.

For instance, when you say : "positioned: absolute; top: 500px" you know your 
element will be displayed 500px from top, because the document will grow to 
suit your need.
But if you say "positioned: absolute; bottom: 500px", and it's not relative to 
viewport, then it's relative to the bottom of the document, which you ignore 
- hence not absolute at all, because the document won't raise its top to fit 
your needs.

Other case : you want a string displayed plain centered (height & width) in 
your viewport.
You can't do that with plain CSS2 spec.

Conclusion : the specs are dead dumb in that respect, and there's no way the 
one who would blindly follow them would have an excuse...
Being critical regarding standards is essential because they are supposed to 
be clever than you.

That's why I like to have this bug report lying around - it's rather a 
reminder that the discussion is still open and that blood needs to flow 
somehow...

I'll re-open it :-[°

G.





From nicog at snafu.de  Wed Jul 24 21:12:40 2002
From: nicog at snafu.de (Nicolas Goutte)
Date: Wed, 24 Jul 2002 22:12:40 +0200
Subject: [PATCH] RTF: underline and other stuff
Message-ID: <200207242212.40263.nicog@snafu.de>

The patch is for the directory filters/kword/rtf/import

I have tried to fix the loading of AbiWord's test file rtftest.rtf.

Changes:
- support advanced underline modes (thick, dot, dash dot, dash dot dot.)
- support conditional hyphen
- do not generate control characters under 32 (apart TAB, LF, CR.)

While working on the underline modes, I have found a bug in KWord, which does 
not respect the dot and dash-dot modes. (Bug reported, number pending.)

I have found another bug, this time more in the filter and in the file that I 
have tested. The problem is the sequence (in a \uc1 context )
\u8164\'20
The filter does not recognised the Unicode character value and tries to 
generated a control character outside XML's valid characters. The sequence 20 
is already considered as normal text.

Have a nice day/evening/night!
-------------- next part --------------
Index: rtfimport.cpp
===================================================================
RCS file: /home/kde/koffice/filters/kword/rtf/import/rtfimport.cpp,v
retrieving revision 1.24
diff -u -r1.24 rtfimport.cpp
--- rtfimport.cpp	2002/07/23 09:11:00	1.24
+++ rtfimport.cpp	2002/07/24 19:48:54
@@ -72,6 +72,7 @@
 	PROP(	0L,		"|",		insertSymbol,		0L, 0x00b7 ),
 	PROP(	0L,		"}",		insertSymbol,		0L, '}' ),
 	PROP(	0L,		"~",		insertSymbol,		0L, 0x00a0 ),
+	PROP(	0L,		"-",		insertSymbol,		0L, 0x00ad ),
 	PROP(	0L,		"ansicpg",	setCodepage,		0L, 0 ),
 	MEMBER(	0L,		"b",		setToggleProperty,	state.format.bold, 0 ),
 	MEMBER(	"@colortbl",	"blue",		setNumericProperty,	blue, 0 ),
@@ -206,9 +207,13 @@
 	MEMBER(	0L,		"u",		insertUnicodeSymbol,	state.format.uc, 0 ),
 	MEMBER(	0L,		"uc",		setNumericProperty,	state.format.uc, 0 ),
 	MEMBER(	0L,		"ul",		setToggleProperty,	state.format.underline, 0 ),
-	MEMBER(	0L,		"uld",		setFlagProperty,	state.format.underline, true ),
+	MEMBER(	0L,		"uld",		setFlagProperty,	state.format.underlineDot, true ),
+	MEMBER(	0L,		"uldash",	setFlagProperty,	state.format.underlineDash, true ),
+	MEMBER(	0L,		"uldashd",	setFlagProperty,	state.format.underlineDashDot, true ),
+	MEMBER(	0L,		"uldashdd",	setFlagProperty,	state.format.underlineDashDotDot, true ),
 	MEMBER(	0L,		"uldb",		setFlagProperty,	state.format.underlined, true ),
 	MEMBER(	0L,		"ulnone",	setFlagProperty,	state.format.underline, false ),
+	MEMBER(	0L,		"ulth",		setFlagProperty,	state.format.underlineThick, true ),
 	MEMBER(	0L,		"ulw",		setFlagProperty,	state.format.underline, true ),
 	MEMBER(	0L,		"up",		setUpProperty,		state.format.baseline, 6 ),
 	MEMBER(	0L,		"v",		setToggleProperty,	state.format.hidden, 0 ),
@@ -716,6 +721,11 @@
     format.vertAlign	= RTFFormat::Normal;
     format.underline	= false;
     format.underlined   = false;
+    format.underlineDash       = false;
+    format.underlineThick      = false;
+    format.underlineDot        = false;
+    format.underlineDashDot    = false;
+    format.underlineDashDotDot = false;
     format.bold		= false;
     format.italic	= false;
     format.strike	= false;
@@ -948,7 +958,7 @@
     token.type = RTFTokenizer::PlainText;
     token.text = buf;
 
-    if (ch > 0)
+    if (ch > 31)
     {
 	if (ch > 0x007f)
 	{
@@ -962,6 +972,14 @@
 	}
 	*text++ = ch;
     }
+    else
+    {
+        // We have a control character, so we must check if it is XML-compactible
+        if ( ch == 9 || ch == 10 || ch == 13 )
+            *text++ = ch ;
+        else
+            kdWarning() << "RTFImport::insertUTF8: tried to insert control character " << ch << endl;
+    }
     *text++ = 0;
 
     (this->*destination.destproc)();
@@ -1787,14 +1805,48 @@
 	    node.setAttribute( "value", format.fmt.italic );
 	    node.closeNode( "ITALIC" );
 	}
-	if (!baseFormat || format.fmt.underline != baseFormat->underline || format.fmt.underlined != baseFormat->underlined)
+        if (!baseFormat || format.fmt.underline != baseFormat->underline
+            || format.fmt.underlined != baseFormat->underlined
+            || format.fmt.underlineDash != baseFormat->underlineDash
+            || format.fmt.underlineThick != baseFormat->underlineThick
+            || format.fmt.underlineDot != baseFormat->underlineDot
+            || format.fmt.underlineDashDot != baseFormat->underlineDashDot
+            || format.fmt.underlineDashDotDot != baseFormat->underlineDashDotDot )
 	{
 	    node.addNode( "UNDERLINE" );
-            QCString st;
+            QCString st,styleline;
             st.setNum(format.fmt.underline);
             if ( format.fmt.underlined )
                 st="double";
-	    node.setAttribute( "value", st );
+            else if ( format.fmt.underlineDash )
+            {
+                st="1";
+                styleline="dash";
+            }
+            else if (format.fmt.underlineThick )
+            {
+                st="single-bold";
+                styleline="solid";
+            }
+            else if (format.fmt.underlineDot )
+            {
+                st="1";
+                styleline="dot"; // ### FIXME: KWord has bug and considers it as DashDot
+            }
+            else if (format.fmt.underlineDashDot )
+            {
+                st="1";
+                styleline="dashdot"; // ### FIXME: KWord has bug mixing Dot and DashDot
+            }
+            else if (format.fmt.underlineDashDotDot )
+            {
+                st="1";
+                styleline="dashdotdot"; // ### FIXME: KWord has bug mixing Dot and DashDot
+            }
+            node.setAttribute( "value", st );
+            if ( !styleline.isEmpty() )
+                node.setAttribute( "styleline", styleline );
+
 	    node.closeNode( "UNDERLINE" );
 	}
 	if (!baseFormat || format.fmt.strike != baseFormat->strike || format.fmt.striked != baseFormat->striked)
Index: rtfimport.h
===================================================================
RCS file: /home/kde/koffice/filters/kword/rtf/import/rtfimport.h,v
retrieving revision 1.11
diff -u -r1.11 rtfimport.h
--- rtfimport.h	2002/07/23 09:11:00	1.11
+++ rtfimport.h	2002/07/24 19:48:54
@@ -133,6 +133,7 @@
     int color, bgcolor;
     int uc;
     bool underline, underlined, bold, italic, strike, striked, hidden, caps;
+    bool underlineDash, underlineThick, underlineDot, underlineDashDot, underlineDashDotDot;
 };
 
 // Style sheet entry

From nicog at snafu.de  Wed Jul 24 21:45:25 2002
From: nicog at snafu.de (Nicolas Goutte)
Date: Wed, 24 Jul 2002 22:45:25 +0200
Subject: [PATCH] RTF: underline and other stuff
In-Reply-To: <200207242212.40263.nicog@snafu.de>
References: <200207242212.40263.nicog@snafu.de>
Message-ID: <200207242245.25877.nicog@snafu.de>

Sorry, wrong list!

On Mittwoch, 24. Juli 2002 22:12, Nicolas Goutte wrote:
> The patch is for the directory filters/kword/rtf/import




From lars at trolltech.com  Thu Jul 25 07:57:34 2002
From: lars at trolltech.com (Lars Knoll)
Date: Thu, 25 Jul 2002 08:57:34 +0200
Subject: [Patch] a renderer for  and 
In-Reply-To: <200207241246.51024.germain@ebooksfrance.com>
References: <200207240313.27821.germain@ebooksfrance.com> <200207241126.20598.lars@trolltech.com> <200207241246.51024.germain@ebooksfrance.com>
Message-ID: <200207250857.34194.lars@trolltech.com>


> Le Mercredi 24 Juillet 2002 10:26, Lars Knoll a écrit :
> > I don't really like the fact, that legend get's a rendering element. I
> > think it should get "display: none" in the default stylesheet. We should
>
> Ah, I new you would say that ! :) It hurted me as well ! :)
> In fact it was my first approach, but it is not quite satisfactory, and I
> now think it's wrong ...
> Sure, this is quite a special case since the HTML DTD doesn't define LEGEND
> as either %inline or %block...
> But OTOH, it defines it as :
> 
>
> and NOT :
> 
>
> Which means, if you follow strictly the spec, that Legend must accept funny
> things such as s, s, anchors and other fontstyling element, but
> should not actually render them because the container is not %flow !?!
> That sucks beyond belief !

Ok. You;re right. But that means that we should treat the first legend as the 
one to render the "legend" of the fieldset, and all others (they should not 
exist, but we all know how web pages look...) as regular flows.

> People do style their legends, do put imgs in their legends, because they
> are allowed to do so...

Ok. Then I see your point, and basically agree with your patch.

> Now, I don't know how IE render them, because I have no IE here and that's
> not my reference (my reference is KHTML :), but yes Mozilla style them,
> Opera style them ... so what ?
>
> > then search for a legend element in the DOM tree, not the rendering tree,
>
> I do ensure that legend is unique inside it's HTMLFieldsetElementImpl, but
> you could only extract #PCDATAs from here, as innerText() do... that's not
> following the DTD either... why would they be more important than e.g. an
> image ?

Please apply your patch then :)

Cheers,
Lars




From carpdjih at sp.zrz.tu-berlin.de  Thu Jul 25 05:38:26 2002
From: carpdjih at sp.zrz.tu-berlin.de (Carsten Pfeiffer)
Date: Thu, 25 Jul 2002 06:38:26 +0200
Subject: patch for bug 27362 : put redirected URLs in history
In-Reply-To: <200207240008.02771.CP.Hennessy@iname.com>
References: <200207240008.02771.CP.Hennessy@iname.com>
Message-ID: <200207250638.26150.carpdjih@sp.zrz.tu-berlin.de>

-----BEGIN PGP SIGNED MESSAGE-----

On Wednesday 24 July 2002 01:08, Con Hennessy wrote:

[Konqueror issues are handled on kfm-devel]

Hi,

> The bug http://bugs.kde.org/db/27/27362.html is marked as a duplicate
> and is closed. However I could not find any other bug which may be a
> duplicate of it, also the problem itself is not resolved.
>
> Basically the problem is that when a URL is actually redirected,
> this URL is never added to the history, and therefore is never
> marked as being "visited" when you go back to the original page.
> As an example following any news link from http://newshub.com/tech
> or any link from http://www.freshmeat.net/.
>
> The patch files below, are very basic :
> 1) to the class BrowserRun a slotRedirection slot is added and
>    connected with the redirection signal from the KIO::TransferJob;
> 2) to the class KonqRun the virtual method defined above (slotRedirection)
>    is redefined so that the pending URL ( i.e. the one which we are
>    being redirected from ) is confirmed and the new URL ( i.e. the
>    one we are being directed to ) is added as "pending".
>
> These changes work for me (on newshub but now I'm not completely sure
> whether they do on freshmeat ?). I am not sure if KonqRun is the right
> class to add the code for the history.

Thanks for the patch! Unfortunately, it causes a binary incompatibility in 
KParts::BrowserRun (we can't add a new virtual method). However, looking at 
BrowserRun::scanFile(), the job is assigned to KRun's m_job, so KonqRun could 
simply reimplement scanFile(), call BrowserRun::scanFile and then connect() 
to the redirected() signal.

New patch attached. Unfortunately, David Faure is on vacation at the moment, 
so it might take a little while to get his comment.

Cheers
Carsten Pfeiffer
-----BEGIN PGP SIGNATURE-----

iQEVAwUBPT+AwqWgYMJuwmZtAQH0LQf+LfJ93xyurdQzs1Y3GNlLQiIO9jo13dga
o9bxBx1UlSoiiztVeTVsSm2Sk8bMS/fXpYpIHYc3FQvHCpoE1F24JWuCMgug9Mo6
RnNdDKH/vsxHVYB0+8LW9hbjyMs7mXRfpoK6jkDz/tQufv/v8c9nsmkCcHMQDMD4
mRt9E6kPkqndG5BTYKDW0VMvHcEY+myNj/WFxGfCj6zNRGWolVDAro7CEPqLp67Z
lH2Ws0eZKs3dJaHg5X0c2ambCGwJuy7c/6ka8z2y2LSooxWt9yNNbFTH8ipbQb73
HHlLDOcFCyzD4vnf3IAB+uQK51dx+pFNaB81T9MSUU3NF0NtUdqAaQ==
=3NxD
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch
Type: text/x-diff
Size: 2030 bytes
Desc: not available
URL: 

From germain at ebooksfrance.com  Thu Jul 25 10:32:27 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Thu, 25 Jul 2002 10:32:27 +0100
Subject: [Patch] a renderer for  and 
In-Reply-To: <200207250857.34194.lars@trolltech.com>
References: <200207240313.27821.germain@ebooksfrance.com> <200207241246.51024.germain@ebooksfrance.com> <200207250857.34194.lars@trolltech.com>
Message-ID: <200207251032.27490.germain@ebooksfrance.com>

Le Jeudi 25 Juillet 2002 07:57, Lars Knoll a écrit :
> > Which means, if you follow strictly the spec, that Legend must accept
> > funny things such as s, s, anchors and other fontstyling
> > element, but should not actually render them because the container is not
> > %flow !?! That sucks beyond belief !
>
> Ok. You;re right. But that means that we should treat the first legend as
> the one to render the "legend" of the fieldset, and all others (they should
> not exist, but we all know how web pages look...) as regular flows.

Ah OK... that's also the behaviour of Mozilla, I think.
If another legend was given, I was removing the previous one, so I've corrected this - it even simplify things.
I also handle better the case were an element of the legend would be absolutely positioned  or floating (yuck!)

Updated patch attached.

>> I do ensure that legend is unique inside it's HTMLFieldsetElementImpl, but
>> you could only extract #PCDATAs from here, as innerText() do... that's not
>> following the DTD either... why would they be more important than e.g. an
>> image ?
>
>Please apply your patch then :)

Thanks ! I'll do it in a few hours then... 

Bye,
Germain



-------------- next part --------------
A non-text attachment was scrubbed...
Name: html_formimpl.diff
Type: text/x-diff
Size: 4489 bytes
Desc: not available
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_form.diff
Type: text/x-diff
Size: 7883 bytes
Desc: not available
URL: 

From market_pub at 1001trocs.com  Thu Jul 25 20:29:52 2002
From: market_pub at 1001trocs.com (market_pub at 1001trocs.com)
Date: Thu, 25 Jul 2002 21:29:52 +0200 (CEST)
Subject: Tout VENDRE/ACHETER aux ench�res en allant � l'essentiel. Nouveau
Message-ID: <200207251929.g6PJTqV98072@black.adarweb.com>

Bonjour, 
Vous avez toutes et tous quelque chose � vendre (CD, DVD, BD, livres, disques, appareils �lectro-m�nagers, ordinateurs, logiciels, collections diverses, ..... etc etc ..... ) 
Nous sommes une toute nouvelle micro entreprise, sous le r�gime de l'entreprise individuelle, et nous avons d�cid� de cr�er un nouveau service de ventes aux ench�res sur Internet. 
Il n'est pas acceptable en effet de voir ce monopole d�tenu par de tr�s grosses soci�t�s. 
Nous relevons le d�fi, pour le plus grand int�r�t de toutes et tous. 
Sur ce nouveau service, le ma�tre mot est : 
VENDRE et ACHETER en ALLANT � L'ESSENTIEL. 
Sous une interface sobre, mais d�taill�e, et � l'aide de fichiers d'aide clairs et succints, nous privil�gions 
la s�curit�, la rapidit�. 
Vous trouverez sur ce service nombre d'options classiques pour ce type de service, mais une premi�re 
en France, toute personne inscrite se voit cr�dit�e de 15,00� automatiquement (avoir sur cr�dit de commissions de vente finale). 
Ceci afin de profiter du service sans bourse d�lier, le tester, le faire conna�tre. 
Et cette offre n'est pas limit�e dans le temps. 
Nos tarifs ? 
Les plus bas du march� : 
Acheteur : AUCUN FRAIS 
Vendeur : 3,96% du prix de vente final non plafonn� 
Une photo gratuite. Pour chaque photo suppl�mentaire : 0,25� (maxi : 6 photos). 
Un forum est � votre disposition pour �changer vos id�es, point de vue, exp�riences. 
Nous faire conna�tre aussi vos suggestions. 
Vos num�ros de carte bancaire ne sont pas stock�s sur nos serveurs. 
Les paiements sont hautement s�curis�s. 
Ce site est d�clar� � la CNIL ( R�f :735319 en date du 04-01-2001). 
Nous ne pouvons que vous inciter � vous rendre sur http://www.1001trocs.com
Inscrivez vous, vendez, acheter, faites conna�tre � vos amis, contacts, parents, relations ce nouveau service. 
Les offres de partenariat seront bienvenues et �tudi�es avec le plus grand soin. 
En attendant de vous rencontrer sur www.1001trocs.com, la petite �quipe (3 personnes) de ce service vous adresse ses plus cordiales amiti�s. 

Vous �tes une soci�t�, un commerce, un groupe commercial, un groupe 
�conomique, vous pouvez annoncer sur notre site pour des tarifs comp�titifs. Vous 
�tes webmaster d'un site de moyenne et grosse importance, nous pouvons conclure 
des offres de partenariat, d'�changes de liens ou autres. Dans tous ces cas, nous 
contacter � webmaster at 1001trocs.com 

GAGNEZ UNE XBOX + jeux jusqu'au 31 ao�t 2002 

********************************************************* 
Nouveau : Service de petites annonces gratuites � votre disposition... 
********************************************************* 

********************************************************* 
WEBMAIL : AVENGER MAIL SYSTEM, la rapidit�, le s�rieux, 
la confidentialit�, toutes options pour un prix ricule : 
25 � pour deux ans ! 
********************************************************* 

Merci pour le temps pris � nous lire. 


Cordialement � toutes et tous. 

L'�quipe de 1001trocs 


Si vous avez d�j� re�u cet E-mail, veuillez recevoir nos excuses, et ne pas nous en tenir rigueur.

L'�quipe de 1001trocs.com
http://www.1001trocs.com 

Pour vous d�sinscrire, merci de vous rendre ici:
http://www.freesoft4all.com/cgi-bin/pg-mlpro.cgi?A=kfm-devel at kde.org&L=20 



From pch at valleeurope.net  Thu Jul 25 22:16:29 2002
From: pch at valleeurope.net (Patrick)
Date: Thu, 25 Jul 2002 23:16:29 +0200
Subject: smb slave
In-Reply-To: <200207232246.43096.alexander.neundorf@gmx.net>
References: <200207232246.43096.alexander.neundorf@gmx.net>
Message-ID: <200207252316.29559.pch@valleeurope.net>

On Tuesday 23 July 2002 22:46, aleXXX wrote:
[...]
> Hi Patrick,
>
> on which smb ioslave do you want to work ?
> kdebase/kioslave/smb or kdebase/kioslave/smbro ?
> What do you want to add ?
Ciao Alex,
i would like to have add something like  "clean network view"
I'm working in a large network and when i use the konqueror with lisa for 
example i get all the server without any logical sort on the other hands the 
smb protocols just show me the shared folder without any information about 
the server and also there are no indication about domain (i don't know how to 
find the  PDC or a printer..)
My idea is to @ first click have a choice on with angle i want to see my 
network(let's say for example all http, NFS, or windows domains..) the if i 
choose the smb get a different icons for servers and workstation...have a way 
to map shared folder..
About the kioslave can you explain me why we need 2 slaves? (i didn't start 
looking at code).

Patrick




From alexander.neundorf at gmx.net  Thu Jul 25 23:18:36 2002
From: alexander.neundorf at gmx.net (aleXXX)
Date: Fri, 26 Jul 2002 00:18:36 +0200
Subject: smb slave
In-Reply-To: <200207252316.29559.pch@valleeurope.net>
References: <200207232246.43096.alexander.neundorf@gmx.net> <200207252316.29559.pch@valleeurope.net>
Message-ID: <200207260018.36243.alexander.neundorf@gmx.net>

On Thursday 25 July 2002 23:16, Patrick wrote:
> On Tuesday 23 July 2002 22:46, aleXXX wrote:
> [...]
>
> > Hi Patrick,
> >
> > on which smb ioslave do you want to work ?
> > kdebase/kioslave/smb or kdebase/kioslave/smbro ?
> > What do you want to add ?
>
> Ciao Alex,
> i would like to have add something like  "clean network view"
> I'm working in a large network and when i use the konqueror with lisa for
> example i get all the server without any logical sort 

Yes, known "issue".

> on the other hands
> the smb protocols just show me the shared folder without any information
> about the server and also there are no indication about domain (i don't
> know how to find the  PDC or a printer..)

The smb ioslave (I think both) should in the meantime be able to show you the 
list of workgroups ( enter smb:/ ), so you will have grouping.
At least my smbro (it ain't anymore read-only) is able to do it, if it doesn't 
work, tell me, then it is a bug.

> My idea is to @ first click have a choice on with angle i want to see my
> network(let's say for example all http, NFS, or windows domains..) the if i
> choose the smb get a different icons for servers and workstation...have a
> way to map shared folder..

Not sure I like ot understand what you mean.

> About the kioslave can you explain me why we need 2 slaves? (i didn't start
> looking at code).

Well, depends on which ioslaves you count ;-)

If you don't use samba at all, you have the lan:/ and the fish:/ ioslave, 
works perfectly :-)
If you use everything, you have lan, http, ftp, fish and smb ioslave (maybe 
even nfs), makes 6 ioslaves.

The lan:/ ioslave is for listing hosts (creating browse lists, in 
smb-language), independent whether they have samba servers (or ftp or http 
servers) running or not.
The other ioslaves are put general "file sharing" ioslaves.
I think the decision from microsoft to mix file sharing and host browse lists 
in one protocol is bad design.

Bye
Alex




From pch at valleeurope.net  Thu Jul 25 23:51:24 2002
From: pch at valleeurope.net (Patrick)
Date: Fri, 26 Jul 2002 00:51:24 +0200
Subject: smb slave
In-Reply-To: <200207260018.36243.alexander.neundorf@gmx.net>
References: <200207232246.43096.alexander.neundorf@gmx.net> <200207252316.29559.pch@valleeurope.net> <200207260018.36243.alexander.neundorf@gmx.net>
Message-ID: <200207260051.24014.pch@valleeurope.net>

On Friday 26 July 2002 00:18, aleXXX wrote:
> > [...]
> Yes, known "issue".
>
> > on the other hands
> > the smb protocols just show me the shared folder without any information
> > about the server and also there are no indication about domain (i don't
> > know how to find the  PDC or a printer..)
>
> The smb ioslave (I think both) should in the meantime be able to show you
> the list of workgroups ( enter smb:/ ), so you will have grouping.
> At least my smbro (it ain't anymore read-only) is able to do it, if it
> doesn't work, tell me, then it is a bug.
Yes they show the workgroups but as Directory...(i understand the network 
transparency but consider workgroup PDC BDC Workstation and shared folder all 
the same on my personal option it's to much transparent..)
> > My idea is to @ first click have a choice on with angle i want to see my
> > network(let's say for example all http, NFS, or windows domains..) the if
> > i choose the smb get a different icons for servers and workstation...have
> > a way to map shared folder..
>
> Not sure I like ot understand what you mean.
>
> > About the kioslave can you explain me why we need 2 slaves? (i didn't
> > start looking at code).
>
> Well, depends on which ioslaves you count ;-)
Sorry my question was why smb and smbpro?
> The other ioslaves are put general "file sharing" ioslaves.
> I think the decision from microsoft to mix file sharing and host browse
> lists in one protocol is bad design.
maybe but as i say before we cannot consider all things folders..
there are informations associated to hosts that are diffents from 
folders....example if i right click on  a folder (that is a workgoup) all the 
actions associated are ..wrong let's say cut-past-copy...preview in ..
The propriety tab doesn't give me any right informations ex: i cannot rename a 
workgroup, nor calculate de size and i cannot change the permissions.. 
last consideration is about network printers i cannot see any printers for smb 
slave..

let me know your feeling
ciao
patrick




From david at mandrakesoft.com  Fri Jul 26 09:45:37 2002
From: david at mandrakesoft.com (David Faure)
Date: Fri, 26 Jul 2002 10:45:37 +0200
Subject: patch for bug 27362 : put redirected URLs in history
In-Reply-To: <200207250638.26150.carpdjih@sp.zrz.tu-berlin.de>
References: <200207240008.02771.CP.Hennessy@iname.com> <200207250638.26150.carpdjih@sp.zrz.tu-berlin.de>
Message-ID: <200207261045.37446.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 25 July 2002 06:38, Carsten Pfeiffer wrote:
> On Wednesday 24 July 2002 01:08, Con Hennessy wrote:
> 
> [Konqueror issues are handled on kfm-devel]
> 
> Hi,
> 
> > The bug http://bugs.kde.org/db/27/27362.html is marked as a duplicate
> > and is closed. However I could not find any other bug which may be a
> > duplicate of it, also the problem itself is not resolved.
> >
> > Basically the problem is that when a URL is actually redirected,
> > this URL is never added to the history, and therefore is never
> > marked as being "visited" when you go back to the original page.
> > As an example following any news link from http://newshub.com/tech
> > or any link from http://www.freshmeat.net/.
> >
> > The patch files below, are very basic :
> > 1) to the class BrowserRun a slotRedirection slot is added and
> >    connected with the redirection signal from the KIO::TransferJob;
> > 2) to the class KonqRun the virtual method defined above (slotRedirection)
> >    is redefined so that the pending URL ( i.e. the one which we are
> >    being redirected from ) is confirmed and the new URL ( i.e. the
> >    one we are being directed to ) is added as "pending".
> >
> > These changes work for me (on newshub but now I'm not completely sure
> > whether they do on freshmeat ?). I am not sure if KonqRun is the right
> > class to add the code for the history.
> 
> Thanks for the patch! Unfortunately, it causes a binary incompatibility in
> KParts::BrowserRun (we can't add a new virtual method). However, looking at
> BrowserRun::scanFile(), the job is assigned to KRun's m_job, so KonqRun could
> simply reimplement scanFile(), call BrowserRun::scanFile and then connect()
> to the redirected() signal.
> 
> New patch attached. Unfortunately, David Faure is on vacation at the moment,
> so it might take a little while to get his comment.

Patch looks fine to me, please commit.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9QQwx72KcVAmwbhARAmKbAJsG1zz1INiD7FJkv6vR8HL6VrTQawCghG8I
ayJuOFsGn5kGifCuuUwnrKI=
=56wG
-----END PGP SIGNATURE-----




From germain at ebooksfrance.com  Fri Jul 26 16:44:43 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Fri, 26 Jul 2002 16:44:43 +0100
Subject: Crash on "Configure toolbar" ?
Message-ID: <200207261644.43174.germain@ebooksfrance.com>


Hello,

It's been some time since I did a full recompile (poor processor here) so I'm 
not sure about it, but whenever I edit my toolbars in Konqui 
(Settings->Configure toolbars), add an item, and confirm with "Ok",
I get a crash...

Anyone else see that ?

G.




From david at mandrakesoft.com  Fri Jul 26 17:24:18 2002
From: david at mandrakesoft.com (David Faure)
Date: Fri, 26 Jul 2002 18:24:18 +0200
Subject: Is someone working on #41620 ?
In-Reply-To: <200207200437.19566.germain@ebooksfrance.com>
References: <200207181256.42400.germain@ebooksfrance.com> <200207191922.02197.david@mandrakesoft.com> <200207200437.19566.germain@ebooksfrance.com>
Message-ID: <200207261824.19961.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 20 July 2002 05:37, Germain Garand wrote:
> Works perfectly ... #43393 is gone !
Good, closing.

> [....]
> It works also very well and crushes #41620 :-)
Closing too ;)

> Though to nittpick like crazy,  the:
>  
>    kdDebug(1202) << "Giving focus to new part " << m_pPart << endl;
>     m_pMainWindow->viewManager()->setActivePart( m_pPart );
> 
> statements that follows should probably be displaced into the "else" 
> (otherwise you get a "Warning! part is already active")

Ah I see (now I understand your more recent comment by private mail)
I added a
    if ( m_pMainWindow->viewManager()->activePart() != m_pPart )
around it.

> Mhhh true... but then you'd have a hard time knowing afterward if the returned 
> pointer is a new part, the same part or an invalid pointer ?
Hmm, same part would work, no?

> Konqui's implementation seems cleaner to me: separate the trading from the 
> actual creation...
Yes. I don't feel like changing KHTML though :}

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9QXez72KcVAmwbhARAkI7AJ4yGT5CW8Q94Qx12IxfUaBTCstTvQCfbQ13
j8vN+jiMGF8uWbeKcyOnUoY=
=zIIy
-----END PGP SIGNATURE-----




From paully at myblackhole.net  Fri Jul 26 20:35:31 2002
From: paully at myblackhole.net (paul lathrop)
Date: Fri, 26 Jul 2002 12:35:31 -0700
Subject: disabling delete
Message-ID: <002801c234db$9e1120c0$0501000a@qwest.net>

Dear Friends,

How would i go about disabling delete in Konqueror file manager?

EX: when a user right clicks and Icon and selects disable this can be troublesome for us in our production environment because the user needs to call support then.

I can disable the 'right click' action in most of KDE but i am unable to in Konq - FIle manager

I am unable to track down this functionality in DCOP as  well.

Is there a way to restrict this functionality?

Thanks!

Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From david at mandrakesoft.com  Sat Jul 27 17:04:13 2002
From: david at mandrakesoft.com (David Faure)
Date: Sat, 27 Jul 2002 18:04:13 +0200
Subject: disabling delete
In-Reply-To: <002801c234db$9e1120c0$0501000a@qwest.net>
References: <002801c234db$9e1120c0$0501000a@qwest.net>
Message-ID: <200207271804.15032.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 July 2002 21:35, paul lathrop wrote:
> Dear Friends,
> 
> How would i go about disabling delete in Konqueror file manager?

Comment out the del(), trash() and shred() slots in kdebase/konqueror/iconview/konq_iconview.h
and kdebase/konqueror/listview/konq_listview.h
(well unless you want to keep trash() ;)

> EX: when a user right clicks and Icon and selects disable this can be troublesome for us in our production environment because the user needs to call support then.

You mean 'delete' instead of 'disable', right?

> I can disable the 'right click' action in most of KDE but i am unable to in Konq - FIle manager

Hmm, I thought someone added a dcop call to disable RMB. Can't find it though.
Just add a "return;" in KonqMainWindow::slotPopupMenu() (like 3359 for me)

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9QsR+72KcVAmwbhARAjgtAJ0dglSvrRLC1vHOni6OSu1MbWWLDwCeNceI
8M5SMFu9qjWlC9BwR59DEjI=
=I8Xq
-----END PGP SIGNATURE-----




From david at mandrakesoft.com  Sat Jul 27 17:09:45 2002
From: david at mandrakesoft.com (David Faure)
Date: Sat, 27 Jul 2002 18:09:45 +0200
Subject: [Patch] Add icon to 'Copy Link Location' action
In-Reply-To: <200207231610.52440.rik@kde.org>
References: <200207231610.52440.rik@kde.org>
Message-ID: <200207271809.46113.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 23 July 2002 17:10, Rik Hemsley wrote:
> I think this makes sense... it's a lot easier to find the menu item when
> it has an icon.

No objections from me.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9QsXK72KcVAmwbhARAuMqAKCLB+04n1+icv7D7UHW6KaxicaCEwCdHdvh
nApreeuvnwWD41BMI3THzas=
=SotP
-----END PGP SIGNATURE-----




From david at mandrakesoft.com  Sat Jul 27 17:11:11 2002
From: david at mandrakesoft.com (David Faure)
Date: Sat, 27 Jul 2002 18:11:11 +0200
Subject: Crash on "Configure toolbar" ?
In-Reply-To: <200207261644.43174.germain@ebooksfrance.com>
References: <200207261644.43174.germain@ebooksfrance.com>
Message-ID: <200207271811.11521.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 26 July 2002 17:44, Germain Garand wrote:
> Hello,
> 
> It's been some time since I did a full recompile (poor processor here) so I'm 
> not sure about it, but whenever I edit my toolbars in Konqui 
> (Settings->Configure toolbars), add an item, and confirm with "Ok",
> I get a crash...

Backtrace?

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9QsYf72KcVAmwbhARAsxJAKCdHRz/SYuSD9rVsqCRmdnTDiTG5gCfYOkj
R3ROWcRIZoWBbbTIraktkg4=
=tk9e
-----END PGP SIGNATURE-----




From germain at ebooksfrance.com  Sat Jul 27 17:33:05 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Sat, 27 Jul 2002 17:33:05 +0100
Subject: Crash on "Configure toolbar" ?
In-Reply-To: <200207271811.11521.david@mandrakesoft.com>
References: <200207261644.43174.germain@ebooksfrance.com> <200207271811.11521.david@mandrakesoft.com>
Message-ID: <200207271733.05467.germain@ebooksfrance.com>

Le Samedi 27 Juillet 2002 17:11, David Faure a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 26 July 2002 17:44, Germain Garand wrote:
> > Hello,
> >
> > It's been some time since I did a full recompile (poor processor here) so
> > I'm not sure about it, but whenever I edit my toolbars in Konqui
> > (Settings->Configure toolbars), add an item, and confirm with "Ok",
> > I get a crash...
>
> Backtrace?
>

Right... anyway noone confirmed so I'd better recompile the whole... I'm still 
using the previous qt-copy.

[New Thread 1024 (LWP 9656)]
0x410e4409 in wait4 () from /lib/libc.so.6
#0  0x410e4409 in wait4 () from /lib/libc.so.6
#1  0x4116398c in __check_rhosts_file () from /lib/libc.so.6
#2  0x40f72d56 in waitpid (pid=9662, stat_loc=0x0, options=0)
    at wrapsyscall.c:172
#3  0x40715ef2 in KCrash::defaultCrashHandler ()
   from /opt/kde3-dev/lib/libkdecore.so.4
#4  0x40f705bb in pthread_sighandler (signo=11, ctx=
      {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 43, __esh = 0, ds = 43, 
__dsh = 0, edi = 0, esi = 3221216912, ebp = 3221216824, esp = 3221216816, ebx 
= 1088616836, edx = 136234680, ecx = 3221215952, eax = 0, trapno = 14, err = 
4, eip = 1084941876, cs = 35, __csh = 0, eflags = 66070, esp_at_signal = 
3221216816, ss = 43, __ssh = 0, fpstate = 0xbfffdbb0, oldmask = 2147483648, 
cr2 = 116})
    at signals.c:97
#5  0x41057478 in killpg () from /lib/libc.so.6
#6  0x41300af1 in KonqCombo::setTemporary ()
   from /opt/kde3-dev/lib/konqueror.so
#7  0x41300aae in KonqCombo::setTemporary ()
   from /opt/kde3-dev/lib/konqueror.so
#8  0x412ac91f in KonqMainWindow::slotConfigureToolbars ()
   from /opt/kde3-dev/lib/konqueror.so
#9  0x412ca6f0 in KonqMainWindow::qt_invoke ()
   from /opt/kde3-dev/lib/konqueror.so
#10 0x40a1fe94 in QObject::activate_signal ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#11 0x40a1fdfe in QObject::activate_signal ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#12 0x40476755 in KAction::activated () from /opt/kde3-dev/lib/libkdeui.so.4
#13 0x40462b19 in KAction::slotActivated ()
   from /opt/kde3-dev/lib/libkdeui.so.4
#14 0x40476991 in KAction::qt_invoke () from /opt/kde3-dev/lib/libkdeui.so.4
#15 0x40a1fe94 in QObject::activate_signal ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#16 0x40cdf89d in QSignal::signal ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#17 0x40a34e97 in QSignal::activate ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#18 0x40b0b753 in QPopupMenu::mouseReleaseEvent ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#19 0x40a4e360 in QWidget::event ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#20 0x409c8603 in QApplication::internalNotify ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#21 0x409c7d53 in QApplication::notify ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#22 0x406664d9 in KApplication::notify ()
   from /opt/kde3-dev/lib/libkdecore.so.4
#23 0x409744b7 in QETWidget::translateMouseEvent ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#24 0x4097193f in QApplication::x11ProcessEvent ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#25 0x409705ba in QApplication::processNextEvent ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#26 0x409c99f1 in QApplication::enter_loop ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#27 0x40970518 in QApplication::exec ()
   from /home/germain/cvs/KDE/qt-copy/lib/libqt-mt.so.3
#28 0x4129bd78 in main () from /opt/kde3-dev/lib/konqueror.so
#29 0x0804cd13 in launch ()
#30 0x0804da38 in handle_launcher_request ()
#31 0x0804df12 in handle_requests ()
#32 0x0804f40b in main ()
#33 0x41045280 in __libc_start_main () from /lib/libc.so.6



From paully at myblackhole.net  Sat Jul 27 17:41:33 2002
From: paully at myblackhole.net (paul)
Date: Sat, 27 Jul 2002 09:41:33 -0700
Subject: disabling delete
In-Reply-To: <200207271804.15032.david@mandrakesoft.com>
References: <002801c234db$9e1120c0$0501000a@qwest.net> <200207271804.15032.david@mandrakesoft.com>
Message-ID: <02072709413300.01102@localhost.localdomain>

On Saturday 27 July 2002 09:04 am, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 26 July 2002 21:35, paul lathrop wrote:
> > Dear Friends,
> >
> > How would i go about disabling delete in Konqueror file manager?
>

Thank You So Much David!

I had a heck of a time trying to find this information!

_Paul



> Comment out the del(), trash() and shred() slots in
> kdebase/konqueror/iconview/konq_iconview.h and
> kdebase/konqueror/listview/konq_listview.h
> (well unless you want to keep trash() ;)
>
> > EX: when a user right clicks and Icon and selects disable this can be
> > troublesome for us in our production environment because the user needs
> > to call support then.
>
> You mean 'delete' instead of 'disable', right?
>
> > I can disable the 'right click' action in most of KDE but i am unable to
> > in Konq - FIle manager
>
> Hmm, I thought someone added a dcop call to disable RMB. Can't find it
> though. Just add a "return;" in KonqMainWindow::slotPopupMenu() (like 3359
> for me)
>
> - --
> David FAURE, david at mandrakesoft.com, faure at kde.org
> http://people.mandrakesoft.com/~david/
> Contributing to: http://www.konqueror.org/, http://www.koffice.org/
> KOffice 1.2 RC1 is slightly delayed. Stay tuned.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE9QsR+72KcVAmwbhARAjgtAJ0dglSvrRLC1vHOni6OSu1MbWWLDwCeNceI
> 8M5SMFu9qjWlC9BwR59DEjI=
> =I8Xq
> -----END PGP SIGNATURE-----



From bastian at kde.org  Sat Jul 27 19:02:15 2002
From: bastian at kde.org (Waldo Bastian)
Date: Sat, 27 Jul 2002 11:02:15 -0700
Subject: disabling delete
In-Reply-To: <200207271804.15032.david@mandrakesoft.com>
References: <002801c234db$9e1120c0$0501000a@qwest.net> <200207271804.15032.david@mandrakesoft.com>
Message-ID: <200207271102.15322.bastian@kde.org>

On Saturday 27 July 2002 09:04 am, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Friday 26 July 2002 21:35, paul lathrop wrote:
> > Dear Friends,
> >
> > How would i go about disabling delete in Konqueror file manager?
>
> Comment out the del(), trash() and shred() slots in
> kdebase/konqueror/iconview/konq_iconview.h and
> kdebase/konqueror/listview/konq_listview.h
> (well unless you want to keep trash() ;)
>
> > EX: when a user right clicks and Icon and selects disable this can be
> > troublesome for us in our production environment because the user needs
> > to call support then.
>
> You mean 'delete' instead of 'disable', right?
>
> > I can disable the 'right click' action in most of KDE but i am unable to
> > in Konq - FIle manager
>
> Hmm, I thought someone added a dcop call to disable RMB. Can't find it
> though. Just add a "return;" in KonqMainWindow::slotPopupMenu() (like 3359
> for me)

I will add some stuff so that you can disable this with the KIOSK framework 
for KDE 3.1

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com




From david at mandrakesoft.com  Sun Jul 28 02:57:55 2002
From: david at mandrakesoft.com (David Faure)
Date: Sun, 28 Jul 2002 03:57:55 +0200
Subject: MMB opens in new tab
In-Reply-To: <200207221105.13066.hanleyman@adelphia.net>
References: <200207141222.19644.hanleyman@adelphia.net> <200207191845.50264.david@mandrakesoft.com> <200207221105.13066.hanleyman@adelphia.net>
Message-ID: <200207280357.55546.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 22 July 2002 17:05, Doug Hanley wrote:
> On Friday 19 July 2002 12:45 pm, David Faure wrote:
> > A much smaller solution (less code changes) would have been to add the
> > newTab bool to the KonqOpenURLRequest struct. That's exactly what it's
> > there for: to easily add new "do this when opening this URL" data, without
> > having to change so much API. Sorry that I didn't think of mentionning this
> > earlier. I understand if you don't want to rewrite this patch yet another
> > time (but in all theory it would be cleaner to have it in
> > KonqOpenURLRequest ;-) Do whichever way you prefer.
> 
> Alright, that wasn't too hard.  Well I know you're on vacation right now (hope 
> you're enjoying it), so I guess I'll just say here's the patch, anyone have 
> any objections?  If not, I'll commit.

Very cool patch. Much cleaner. Thanks a lot.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Q0+j72KcVAmwbhARAj+zAJ91uqEmM5tmFZhRK5Rw6uqi1gTVOwCgiX37
qhVjcVOty3X+hzl7mYyIqOE=
=YgDW
-----END PGP SIGNATURE-----




From zack at kde.org  Sun Jul 28 03:46:52 2002
From: zack at kde.org (Zack Rusin)
Date: Sat, 27 Jul 2002 22:46:52 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207280357.55546.david@mandrakesoft.com>
References: <200207141222.19644.hanleyman@adelphia.net> <200207221105.13066.hanleyman@adelphia.net> <200207280357.55546.david@mandrakesoft.com>
Message-ID: <200207272246.52264.zack@kde.org>

On Saturday 27 July 2002 21:57, David Faure wrote:
> On Monday 22 July 2002 17:05, Doug Hanley wrote:
> > On Friday 19 July 2002 12:45 pm, David Faure wrote:
> > > A much smaller solution (less code changes) would have been to
> > > add the newTab bool to the KonqOpenURLRequest struct. That's
> > > exactly what it's there for: to easily add new "do this when
> > > opening this URL" data, without having to change so much API.
> > > Sorry that I didn't think of mentionning this earlier. I
> > > understand if you don't want to rewrite this patch yet another
> > > time (but in all theory it would be cleaner to have it in
> > > KonqOpenURLRequest ;-) Do whichever way you prefer.
> >
> > Alright, that wasn't too hard.  Well I know you're on vacation
> > right now (hope you're enjoying it), so I guess I'll just say
> > here's the patch, anyone have any objections?  If not, I'll commit.
>
> Very cool patch. Much cleaner. Thanks a lot.

Yeah, it's great but it still doesn't work with some mimetypes. To try 
it go over to www.kernel.org and click on one of the changelogs, in 
fact try to open any link containing a reference to a simple txt 
document in a new tab. I just compiled kdelibs and kdebase and I get an 
error box when I click on any link referencing anything else than a 
html page, the error box says 
"Could not create view for text/plain
 The diagnostics is:"
Doug do you have time to look into it or do you want me to take the 
honors? :) Oh, and as always on Saturday afternoon, I did something 
completely useless and added a custom paintEvent to KonqTabBar to add a 
custom widget to close the tabs since right clicking and picking a menu 
item was a little cumbersome. For now it looks super corny, since I 
only cared about getting the basic functionality there, so it's just a 
plain button, without anything on it (probably it'd be a good idea to 
draw there the same widget KWin draws for the close window button) and 
looks like this:
http://vortex.bd.psu.edu/~mus11/img/konq1.png
Should I add this to 3.2 features list, or does anyone think that 
there's a better/cleaner way of doing this (close button on every tab? 
close button somewhere on the frame? something even weirder than the 
last two?)

Zack Rusin

-- 
It's Like This Even the samurai have teddy bears, and even the teddy
bears get drunk.




From koos.vriezen at xs4all.nl  Sun Jul 28 14:15:15 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sun, 28 Jul 2002 15:15:15 +0200 (CEST)
Subject: Small test case for bug in renderer floats
Message-ID: 

Hi,

This is rendered wrong
  
   table cell
   some text
  

or with a div

  
   div text
div text
   some text
  

Seems the float gets an extra left offset if the height is greater than
height of surrounding text.

Regards,

Koos Vriezen




From hanleyman at adelphia.net  Sun Jul 28 16:42:45 2002
From: hanleyman at adelphia.net (Doug Hanley)
Date: Sun, 28 Jul 2002 11:42:45 -0400
Subject: MMB opens in new tab
Message-ID: <200207281142.45724.hanleyman@adelphia.net>

Zack Rusin wrote:
> Yeah, it's great but it still doesn't work with some mimetypes. To try 
> it go over to www.kernel.org and click on one of the changelogs, in 
> fact try to open any link containing a reference to a simple txt 
> document in a new tab. I just compiled kdelibs and kdebase and I get an 
> error box when I click on any link referencing anything else than a 
> html page, the error box says 
> "Could not create view for text/plain
> The diagnostics is:"

I don't get that over here, for me it works just as excpected.  Maybe its 
something else thats causing the problem.  However, I do have a build from 
about a week and a half a ago (except for konqueror which is new).

> Doug do you have time to look into it or do you want me to take the 
> honors? :) Oh, and as always on Saturday afternoon, I did something 
> completely useless and added a custom paintEvent to KonqTabBar to add a 
> custom widget to close the tabs since right clicking and picking a menu 
> item was a little cumbersome. For now it looks super corny, since I 
> only cared about getting the basic functionality there, so it's just a 
> plain button, without anything on it (probably it'd be a good idea to 
> draw there the same widget KWin draws for the close window button) and 
> looks like this:
> http://vortex.bd.psu.edu/~mus11/img/konq1.png

Great work, I think it looks really good personally!  And I think having it 
the same as KWin is a good idea too.  One question, what happens when the tab 
bar gets too wide, does it play well with those little scroll arrow thingies?

> Should I add this to 3.2 features list, or does anyone think that 
> there's a better/cleaner way of doing this (close button on every tab? 
> close button somewhere on the frame? something even weirder than the 
> last two?)

I think this is the best way to do it.  I've used it a lot on mozilla and I've 
always liked it.



From zack at kde.org  Sun Jul 28 21:07:14 2002
From: zack at kde.org (Zack Rusin)
Date: Sun, 28 Jul 2002 16:07:14 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207281142.45724.hanleyman@adelphia.net>
References: <200207281142.45724.hanleyman@adelphia.net>
Message-ID: <200207281607.15128.zack@kde.org>

On Sunday 28 July 2002 11:42, Doug Hanley wrote:
> I don't get that over here, for me it works just as excpected.  Maybe
> its something else thats causing the problem.  However, I do have a
> build from about a week and a half a ago (except for konqueror which
> is new).

I'll look into it then :)

> Great work, I think it looks really good personally!  And I think
> having it the same as KWin is a good idea too.  One question, what
> happens when the tab bar gets too wide, does it play well with those
> little scroll arrow thingies?

Well, it's repainted (the silly answer) and... looks like shit :) Here's 
the problem, arrows are drawn internally by QTabBar, they're part of a 
private pimpl_ idiom inside QTabBar and displayed inside a private 
method, this all makes it pretty much impossible to change their 
position. Which is why I'm drawing the button before them It wouldn't 
be so bad if not the way arrow buttons are drawn inside QTabBar which 
basically is simple repainting over already drawn tab - meaning the 
button is also drawn over a tab. I could draw a background over the 
part where the button is, but it would look very weird. I though that 
not drawing the tab which is underneath the button and arrows would be 
a reasonable solution but it's not, the tabbar looked very unfriendly 
(the tabs looked as if they were cut off). I'm really not sure what 
would be a good way to do this. Here's how it looks right now:
http://vortex.bd.psu.edu/~mus11/img/konq2.png
I'd appreciate it, if some UI design people/artists would come up with a 
reasonable solution. I see three (please keep in mind that in QTabBar 
the arrow buttons will _always_ be at the end of the tabbar):
1) (the long way) write our own KTabBar (not inheriting from QTabBar), 
and draw it in whatever way we like it,
2) not draw the last tab (looks horrible),
3) draw a background over the tabs and underneath the close button and 
arrow buttons,
4) solution I haven't thought about.
I looked at Mozilla - they don't have the arrow buttons, but just keep 
scaling the tabs, and Galeon - (which has close button on every tab), 
and I'm really not sure which way is the best. Any ideas?


Zack Rusin

-- 
43rd Law of Computing: Anything that can go wr
fortune: Segmentation violation -- Core dumped




From hanleyman at adelphia.net  Sun Jul 28 23:18:49 2002
From: hanleyman at adelphia.net (Doug Hanley)
Date: Sun, 28 Jul 2002 18:18:49 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207281607.15128.zack@kde.org>
References: <200207281142.45724.hanleyman@adelphia.net> <200207281607.15128.zack@kde.org>
Message-ID: <200207281818.49445.hanleyman@adelphia.net>

On Sunday 28 July 2002 04:07 pm, Zack Rusin wrote:
> On Sunday 28 July 2002 11:42, Doug Hanley wrote:
> > Great work, I think it looks really good personally!  And I think
> > having it the same as KWin is a good idea too.  One question, what
> > happens when the tab bar gets too wide, does it play well with those
> > little scroll arrow thingies?
>
> Well, it's repainted (the silly answer) and... looks like shit :) Here's
> the problem, arrows are drawn internally by QTabBar, they're part of a
> private pimpl_ idiom inside QTabBar and displayed inside a private
> method, this all makes it pretty much impossible to change their
> position. Which is why I'm drawing the button before them It wouldn't
> be so bad if not the way arrow buttons are drawn inside QTabBar which
> basically is simple repainting over already drawn tab - meaning the
> button is also drawn over a tab. I could draw a background over the
> part where the button is, but it would look very weird. I though that
> not drawing the tab which is underneath the button and arrows would be
> a reasonable solution but it's not, the tabbar looked very unfriendly
> (the tabs looked as if they were cut off). I'm really not sure what
> would be a good way to do this. Here's how it looks right now:
> http://vortex.bd.psu.edu/~mus11/img/konq2.png
> I'd appreciate it, if some UI design people/artists would come up with a
> reasonable solution. I see three (please keep in mind that in QTabBar
> the arrow buttons will _always_ be at the end of the tabbar):
> 1) (the long way) write our own KTabBar (not inheriting from QTabBar),
> and draw it in whatever way we like it,
> 2) not draw the last tab (looks horrible),
> 3) draw a background over the tabs and underneath the close button and
> arrow buttons,
> 4) solution I haven't thought about.
> I looked at Mozilla - they don't have the arrow buttons, but just keep
> scaling the tabs, and Galeon - (which has close button on every tab),
> and I'm really not sure which way is the best. Any ideas?

Haha, I went through an ordeal very similar to your's :)  In my case, I was 
able to get the close button drawn over the arrows, but that didn't help 
either.  Yeah, that whole private members thing really sucks, I'm thinking 
we're gonna have to rewrite it ourselves.  However, it will give us much more 
flexibility over the interface so it might turn out better than we think.  
Maybe we should just go ahead and get started on KTabBar or KonqTabBar, 
whatever its called... Would you be willing to put some time into that?  I 
was thinking we could make the new tab bar more like opera's too, i find 
their's to be better for internet browsing.

-- Doug Hanley



From falk.brettschneider at gmx.de  Sun Jul 28 23:34:41 2002
From: falk.brettschneider at gmx.de (F@lk Brettschneider)
Date: Mon, 29 Jul 2002 00:34:41 +0200
Subject: konqueror file preview not up-to-date
Message-ID: <3D447181.8040908@gmx.de>

Hi!
Current KDE CVS HEAD and qt-copy.
I started Konqueror, edited and saved some HTML files via Kate, 
LMB-clicked such a file in Konqueror. But the embedded HTML-preview of 
Konqueror just shows the old version, not the new one. :-( This also 
happened in KDE-3.0.0 of SuSE-8.0.
In this case it makes Konqueror's HTML preview useless.
Maybe you can check it. Not sure, but it seems to me it doesn't happen 
always. Though always today...
Thanks in advance,
F at lk





From zack at kde.org  Sun Jul 28 23:39:10 2002
From: zack at kde.org (Zack Rusin)
Date: Sun, 28 Jul 2002 18:39:10 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207281818.49445.hanleyman@adelphia.net>
References: <200207281142.45724.hanleyman@adelphia.net> <200207281607.15128.zack@kde.org> <200207281818.49445.hanleyman@adelphia.net>
Message-ID: <200207281839.10689.zack@kde.org>

On Sunday 28 July 2002 18:18, Doug Hanley wrote:
> Would you be willing to put some time into that?  

I'd love to! Using QTabBar is hardly any fun, since no matter what we do 
it's still going to be a hack.

> I was thinking we could make the new tab bar more like opera's too, i 
> find their's to be better for internet browsing.

Hmm, I don't know about that, Opera uses workspace to menage its windows 
and their tabbar is just a detachable toolbar with bunch of 'toggle 
buttons' on it. But that brings another good question, does tabbed 
browsing need necessarily QTabBar like widget or should it be be done 
with an entirely different widget? IMHO,  Mozilla is the best of all 
the tabbed browsers (Skipstone was the first one that was using it, 
wasn't it?) and would go with a solution similar to theirs. The one 
thing that I'm not sure is whether placing arrow buttons is a better 
solution than scaling tabs. What do you think?

Zack

-- 
Asking if computers can think is like asking if submarines can swim.




From falk.brettschneider at gmx.de  Sun Jul 28 23:50:23 2002
From: falk.brettschneider at gmx.de (F@lk Brettschneider)
Date: Mon, 29 Jul 2002 00:50:23 +0200
Subject: action for LMB click in Konqueror
Message-ID: <3D44752F.6070307@gmx.de>

Hi!
I think it was better if Konqueror would open the default application on 
LMB click instead of opening the file in the embedded viewer.
For instance a common user just wonders why he cannot edit the opened 
text file although he wanted to open the file for doing that. The main 
idea is why do you want to restrict the user to readonly-opening? 90% of 
the world population are used to Win32's file managers where LMB on a 
file opens the file in read-write mode.  Which is also a more 
intuitively expected behaviour during a mom-test. ;-)

Just my 2 cents
Ciao
F at lk





From falk.brettschneider at gmx.de  Sun Jul 28 23:55:51 2002
From: falk.brettschneider at gmx.de (F@lk Brettschneider)
Date: Mon, 29 Jul 2002 00:55:51 +0200
Subject: Find File in tree view of Konqueror
Message-ID: <3D447677.7030907@gmx.de>

Hi!
Please, can you add that very useful action 'Find file...' to the 
context menu of the (left-hand side located) tree view of Konqueror?
Sorry, I gave up studying the code for making a little patch since it's 
too complex for me.
Ciao
F at lk





From till at snafu.de  Mon Jul 29 00:47:26 2002
From: till at snafu.de (Till Krech)
Date: Mon, 29 Jul 2002 01:47:26 +0200
Subject: action for LMB click in Konqueror
In-Reply-To: <3D44752F.6070307@gmx.de>
References: <3D44752F.6070307@gmx.de>
Message-ID: <200207290147.26909.till@snafu.de>

Hi,

I think, this is already changed in cvs HEAD.
At least, text/plain opens in a separate kwrite here.
OTOH, there seems to an incosistency between the filemanager settings and this 
behaviour. The settings of 'Filemanager=>File Associations' for text/plain, 
Embedding are here: 'use settings for text group' and the text group says 
'show file in embedded viewer'
But the file opens in a separate viewer (kwrite).

regards, till
 
On Monday 29 July 2002 00:50, falk.brettschneider at gmx.de wrote:
> Hi!
> I think it was better if Konqueror would open the default application on
> LMB click instead of opening the file in the embedded viewer.
> For instance a common user just wonders why he cannot edit the opened
> text file although he wanted to open the file for doing that. The main
> idea is why do you want to restrict the user to readonly-opening? 90% of
> the world population are used to Win32's file managers where LMB on a
> file opens the file in read-write mode.  Which is also a more
> intuitively expected behaviour during a mom-test. ;-)
>
> Just my 2 cents
> Ciao
> F at lk

-- 
Till Krech from Berlin, Germany is happy with
SuSE Linux 8.0 (i386) 2.4.18-64GB-SMP * KDE: 3.0.6 (KDE 3.1 alpha1)
Qt: 3.0.6-snapshot-20020712 * gcc version 2.95.3 20010315 (SuSE)




From germain at ebooksfrance.com  Mon Jul 29 04:44:59 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Mon, 29 Jul 2002 04:44:59 +0100
Subject: MMB opens in new tab
In-Reply-To: <200207281142.45724.hanleyman@adelphia.net>
References: <200207281142.45724.hanleyman@adelphia.net>
Message-ID: <200207290444.59486.germain@ebooksfrance.com>

Le Dimanche 28 Juillet 2002 16:42, Doug Hanley a écrit :
> Zack Rusin wrote:
> > Yeah, it's great but it still doesn't work with some mimetypes. To try
> > it go over to www.kernel.org and click on one of the changelogs, in
> > fact try to open any link containing a reference to a simple txt
> > document in a new tab. I just compiled kdelibs and kdebase and I get an
> > error box when I click on any link referencing anything else than a
> > html page, the error box says
> > "Could not create view for text/plain
> > The diagnostics is:"
>
> I don't get that over here, for me it works just as excpected.  Maybe its
> something else thats causing the problem.  However, I do have a build from
> about a week and a half a ago (except for konqueror which is new).
>

Hi,
I've just rebuilt and I'm seeing that too..

konqueror: KonqRun::foundMimeType text/plain
konqueror: ------------- KonqViewManager::addTab starting -------------
konqueror: 1Views
konqueror: 0x81d9770
konqueror: currentView=0x81d9770
konqueror: docContainer=0x81d5064
konqueror: KonqFrame [KonqFrame pointer (0x81d4ff0) to widget KonqFrame, 
geometry=700x396+0+83] visble=1 containing view 0x81d9770 visble=1 and part 
0x82fc778 whose widget is a KHTMLView
konqueror: KonqViewManager::createView
konqueror: Trying to create view for "text/plain"
konqueror: KonqFMSettings says: don't embed this servicetype

It seems caused by the recent decision to open text/plain into kwrite by 
default...
But is it that more generally, each time the preference is to open the link in 
an external application, the Tab creation will fail ?

G.





From germain at ebooksfrance.com  Mon Jul 29 05:41:33 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Mon, 29 Jul 2002 05:41:33 +0100
Subject: action for LMB click in Konqueror
In-Reply-To: <200207290147.26909.till@snafu.de>
References: <3D44752F.6070307@gmx.de> <200207290147.26909.till@snafu.de>
Message-ID: <200207290541.33755.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 00:47, Till Krech a écrit :
> Hi,
>
> I think, this is already changed in cvs HEAD.
> At least, text/plain opens in a separate kwrite here.
> OTOH, there seems to an incosistency between the filemanager settings and
> this behaviour. The settings of 'Filemanager=>File Associations' for
> text/plain, Embedding are here: 'use settings for text group' and the text
> group says 'show file in embedded viewer'
> But the file opens in a separate viewer (kwrite).

You're right... the setting for mimetype groups is just plain ignored !

It seems that if you first mark a mimetype to be externally or internally 
viewed, apply the change, and then later switch it to "use settings for XXX 
group", then it doesn't switch and just uses whatever you choose before...

I have also a problem with application/x-shellscript => it should open either 
in kwrite or in the embedded viewer, but it simply does nothing... 

G.




From hanleyman at adelphia.net  Mon Jul 29 07:52:26 2002
From: hanleyman at adelphia.net (Doug Hanley)
Date: Mon, 29 Jul 2002 02:52:26 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207281839.10689.zack@kde.org>
References: <200207281142.45724.hanleyman@adelphia.net> <200207281818.49445.hanleyman@adelphia.net> <200207281839.10689.zack@kde.org>
Message-ID: <200207290252.26572.hanleyman@adelphia.net>

On Sunday 28 July 2002 06:39 pm, Zack Rusin wrote:
> On Sunday 28 July 2002 18:18, Doug Hanley wrote:
> > Would you be willing to put some time into that?
>
> I'd love to! Using QTabBar is hardly any fun, since no matter what we do
> it's still going to be a hack.

Yeah, I Agree.  Just one thing though... before, you said that we would create 
a new tab bar that doesn't inherit QTabBar.  The problem with that is becuase 
we must use the function QTabWidget::setTabBar( QTabBar * ) it has to inherit 
QTabBar.  Now, that raised another problem, even if we reimplement all the 
functions, we still can't access the private variables, so we would have to 
make new variables for our own use (although they would be very similar to 
the existing ones).  That would result in a slight waste of memory, but its 
very marginal and there is only one of these objects per window at most.

> > I was thinking we could make the new tab bar more like opera's too, i
> > find their's to be better for internet browsing.
>
> Hmm, I don't know about that, Opera uses workspace to menage its windows
> and their tabbar is just a detachable toolbar with bunch of 'toggle
> buttons' on it. But that brings another good question, does tabbed
> browsing need necessarily QTabBar like widget or should it be be done
> with an entirely different widget? IMHO,  Mozilla is the best of all
> the tabbed browsers (Skipstone was the first one that was using it,
> wasn't it?) and would go with a solution similar to theirs. The one
> thing that I'm not sure is whether placing arrow buttons is a better
> solution than scaling tabs. What do you think?

Hmm... You know what, I've always found those arrow things kind of annoying 
anyway.  I think we should adopt mozilla's policy and scale the tabs.  Its 
much more usable in my opinion.

So, do you want to just start with qtabbar.h and qtabbar.cpp and adjust from 
there?  I think maybe i'll start some work on that now.  One problem though, 
I'll be gone for about 3 weeks starting tuesday (I'm seeing going to see The 
Who in NYC, woohoo!), so I probably wont have much time to work on this then.
After that though, I'm ready as I'll ever be.

-- Doug Hanley




From till at snafu.de  Mon Jul 29 08:12:38 2002
From: till at snafu.de (Till Krech)
Date: Mon, 29 Jul 2002 09:12:38 +0200
Subject: action for LMB click in Konqueror
In-Reply-To: <200207290541.33755.germain@ebooksfrance.com>
References: <3D44752F.6070307@gmx.de> <200207290147.26909.till@snafu.de> <200207290541.33755.germain@ebooksfrance.com>
Message-ID: <200207290912.39108.till@snafu.de>

On Monday 29 July 2002 06:41, Germain Garand wrote:
> Le Lundi 29 Juillet 2002 00:47, Till Krech a écrit :
> > Hi,
> >
> > I think, this is already changed in cvs HEAD.
> > At least, text/plain opens in a separate kwrite here.
> > OTOH, there seems to an incosistency between the filemanager settings and
> > this behaviour. The settings of 'Filemanager=>File Associations' for
> > text/plain, Embedding are here: 'use settings for text group' and the
> > text group says 'show file in embedded viewer'
> > But the file opens in a separate viewer (kwrite).
>
> You're right... the setting for mimetype groups is just plain ignored !
>
> It seems that if you first mark a mimetype to be externally or internally
> viewed, apply the change, and then later switch it to "use settings for XXX
> group", then it doesn't switch and just uses whatever you choose before...
>
> I have also a problem with application/x-shellscript => it should open
> either in kwrite or in the embedded viewer, but it simply does nothing...

hmm, if it is executable, it executes. Not very nice because you don't see any 
output since shell scripts normally have no gui ;) Some installers or 
launchers are exceptions.
I think this is a problem. There is no visual feedback and something happens 
which you are not aware of. 
According to the file manager settings, it should open in kwrite. 

If a shell script executes, it should at least do so in a konsole window, so 
that you see the output. Even better: ask before.

Perhaps it would be good to look into an executable, if it is a native binary, 
links to libX11 and only then, execute it on click.

many of my shell scripts do nasty things like cleaning up whole directories, 
doing clean on the whole kde src tree to recompile everything etc., I would 
never like to execute them without seeing what they are doing and where they 
are doing it ($PWD).

regards, till

>
> G.

-- 
Till Krech from Berlin, Germany is happy with
SuSE Linux 8.0 (i386) 2.4.18-64GB-SMP * KDE: 3.0.6 (KDE 3.1 alpha1)
Qt: 3.0.6-snapshot-20020712 * gcc version 2.95.3 20010315 (SuSE)




From david at mandrakesoft.com  Mon Jul 29 08:23:28 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 29 Jul 2002 09:23:28 +0200
Subject: MMB opens in new tab
In-Reply-To: <200207281607.15128.zack@kde.org>
References: <200207281142.45724.hanleyman@adelphia.net> <200207281607.15128.zack@kde.org>
Message-ID: <200207290923.34592.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 28 July 2002 22:07, Zack Rusin wrote:
> 1) (the long way) write our own KTabBar (not inheriting from QTabBar), 
> and draw it in whatever way we like it,
> 2) not draw the last tab (looks horrible),
> 3) draw a background over the tabs and underneath the close button and 
> arrow buttons,
> 4) solution I haven't thought about.

If it helps: QTella has close button on tabs .... maybe you want to look at
how they do it?   (qtella.sourceforge.net)

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RO1072KcVAmwbhARAuybAJwLAX3o/0JaI2EXOugQC5lKv5OzRQCgl+ia
xJRXzy7bNbs7Y8lWYQhYUtg=
=+CN+
-----END PGP SIGNATURE-----




From david at mandrakesoft.com  Mon Jul 29 08:28:17 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 29 Jul 2002 09:28:17 +0200
Subject: action for LMB click in Konqueror
In-Reply-To: <200207290541.33755.germain@ebooksfrance.com>
References: <3D44752F.6070307@gmx.de> <200207290147.26909.till@snafu.de> <200207290541.33755.germain@ebooksfrance.com>
Message-ID: <200207290928.20290.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 29 July 2002 06:41, Germain Garand wrote:
> Le Lundi 29 Juillet 2002 00:47, Till Krech a écrit :
> > Hi,
> >
> > I think, this is already changed in cvs HEAD.
> > At least, text/plain opens in a separate kwrite here.
> > OTOH, there seems to an incosistency between the filemanager settings and
> > this behaviour. The settings of 'Filemanager=>File Associations' for
> > text/plain, Embedding are here: 'use settings for text group' and the text
> > group says 'show file in embedded viewer'
> > But the file opens in a separate viewer (kwrite).
> 
> You're right... the setting for mimetype groups is just plain ignored !
> 
> It seems that if you first mark a mimetype to be externally or internally 
> viewed, apply the change, and then later switch it to "use settings for XXX 
> group", then it doesn't switch and just uses whatever you choose before...

I forgot to update the kcontrol file associations module after changing the defaults.
Thanks for noticing, fixed (please re-test).

> I have also a problem with application/x-shellscript => it should open either 
> in kwrite or in the embedded viewer, but it simply does nothing... 

Err, clicking on a shell script executes it ...

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RO6T72KcVAmwbhARAvO0AJ93vF29zCrD+mMmM8hmFRrfMdELmgCfQtQX
6H8i3rp65vsrEx6+vVQYvnI=
=yevw
-----END PGP SIGNATURE-----




From david at mandrakesoft.com  Mon Jul 29 08:32:15 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 29 Jul 2002 09:32:15 +0200
Subject: MMB opens in new tab
In-Reply-To: <200207290444.59486.germain@ebooksfrance.com>
References: <200207281142.45724.hanleyman@adelphia.net> <200207290444.59486.germain@ebooksfrance.com>
Message-ID: <200207290932.19065.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 29 July 2002 05:44, Germain Garand wrote:
> Hi,
> I've just rebuilt and I'm seeing that too..
> 
> konqueror: KonqRun::foundMimeType text/plain
> konqueror: ------------- KonqViewManager::addTab starting -------------
> konqueror: 1Views
> konqueror: 0x81d9770
> konqueror: currentView=0x81d9770
> konqueror: docContainer=0x81d5064
> konqueror: KonqFrame [KonqFrame pointer (0x81d4ff0) to widget KonqFrame, 
> geometry=700x396+0+83] visble=1 containing view 0x81d9770 visble=1 and part 
> 0x82fc778 whose widget is a KHTMLView
> konqueror: KonqViewManager::createView
> konqueror: Trying to create view for "text/plain"
> konqueror: KonqFMSettings says: don't embed this servicetype

Seems wrong, that addTab would query the embedding settings, it should always embed ;)

Question to Doug: why does addTab() have a bool forceAutoEmbed parameter?
I think it should always pass true to createView, instead of that bool, so that
embedding always happens.

(if anyone wants to test: I'm talking about KonqViewManager::addTab, the createView()
call on line 366 in konq_viewmgr.cc)

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RO+C72KcVAmwbhARAp8xAKCM93CV5z6NSAWb9EEIni1xNJkvegCfXwdV
xraFC4zBbs/kAHj3J4RkcKM=
=kqSQ
-----END PGP SIGNATURE-----




From lucy-ples at mtu-net.ru  Mon Jul 29 11:08:39 2002
From: lucy-ples at mtu-net.ru (Vadim Plessky)
Date: Mon, 29 Jul 2002 14:08:39 +0400
Subject: Small test case for bug in renderer floats
In-Reply-To: 
References: 
Message-ID: <200207291408.39267.lucy-ples@mtu-net.ru>

On Sunday 28 July 2002 5:15 pm, Koos Vriezen wrote:
|  Hi,
|
|  This is rendered wrong
|    
|     table cell
|     some text
|    
|
|  or with a div
|
|    
|     div text
div text
|     some text
|    
|
|  Seems the float gets an extra left offset if the height is greater than
|  height of surrounding text.

Hi, 
I can't understand what do you mean here.
Pls check attached testcase - both  and  render (almost) 
identically.

BTW: you forgot to close  in your example

|
|  Regards,
|
|  Koos Vriezen

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From koos.vriezen at xs4all.nl  Mon Jul 29 11:43:47 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Mon, 29 Jul 2002 12:43:47 +0200 (CEST)
Subject: Small test case for bug in renderer floats
In-Reply-To: <200207291408.39267.lucy-ples@mtu-net.ru>
References: <200207291408.39267.lucy-ples@mtu-net.ru>
Message-ID: 

On Mon, 29 Jul 2002, Vadim Plessky wrote:
> On Sunday 28 July 2002 5:15 pm, Koos Vriezen wrote:
> |
> |  This is rendered wrong
> |    
> |     
table cell
> |     some text
> |    
> |
> |  or with a div
> |
> |    
> |     div text
div text
> |     some text
> |    
> |
> |  Seems the float gets an extra left offset if the height is greater than
> |  height of surrounding text.
>
> I can't understand what do you mean here.

I mean, if you test one of the above test cases, you see the 'some text'
text starts on top of the last letter of 'table cell' or 'div text' text
(depending which test case).
If I turn on DEBUG_LAYOUT/FLOAT_DEBUG/BOX_DEBUG, I see that the float is
rendered twice, one correct and one with an xoffset of 10 too much.
If you extend the height of surrounding text, eg. add '
more text..'
after 'some text', its rendered correctly.

> Pls check attached testcase - both  and  render (almost)
> identically.

So what?

> BTW: you forgot to close  in your example

IMO those close tags are optional, see
http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.2.5


Regards,

Koos Vriezen




From lucy-ples at mtu-net.ru  Mon Jul 29 14:28:59 2002
From: lucy-ples at mtu-net.ru (Vadim Plessky)
Date: Mon, 29 Jul 2002 17:28:59 +0400
Subject: Small test case for bug in renderer floats
In-Reply-To: 
References: 
Message-ID: <200207291728.59994.lucy-ples@mtu-net.ru>

On Monday 29 July 2002 2:43 pm, Koos Vriezen wrote:
|  On Mon, 29 Jul 2002, Vadim Plessky wrote:
|  > On Sunday 28 July 2002 5:15 pm, Koos Vriezen wrote:
|  > |  This is rendered wrong
|  > |    
|  > |     
table cell
|  > |     some text
|  > |    
|  > |
|  > |  or with a div
|  > |
|  > |    
|  > |     div text
div text
|  > |     some text
|  > |    
|  > |
|  > |  Seems the float gets an extra left offset if the height is greater
|  > | than height of surrounding text.
|  >
|  > I can't understand what do you mean here.
|
|  I mean, if you test one of the above test cases, you see the 'some text'
|  text starts on top of the last letter of 'table cell' or 'div text' text
|  (depending which test case).
|  If I turn on DEBUG_LAYOUT/FLOAT_DEBUG/BOX_DEBUG, I see that the float is
|  rendered twice, one correct and one with an xoffset of 10 too much.
|  If you extend the height of surrounding text, eg. add '
more text..'
|  after 'some text', its rendered correctly.

ok, now I see.
This testcase demonstrates that problem is with floating div's offset from 
left border of 


div text
div 
text
some text


Compare rendering with Mozilla and you will see some difference :-)
// thanks to dashed border around body

and, BTW, problem is related not to the amount of text outside floating DIV, 
but to the heigh tof body.
See another testcase:


div text
div 
text
some text 
 more text blah blah 
 more more more text


And now when we have detailed descriptiuon for the bug, I can tell you that I 
filed bug report aganst this problem 21.04.2002, Bug#41403
CSS1: incorrect rendering for { float:right } block (misplaced right border) 
[testcase])
You can follow your bug's status at http://bugs.kde.org/db/41/41403.html

|
|  > Pls check attached testcase - both  and  render (almost)
|  > identically.
|
|  So what?

I had impresion that you compare differences of using 
 and  with 
CSS property 'float: left'
And prepared testcase which demonstares that rendering is identical (that's 
was not visible from your testcase)

|
|  > BTW: you forgot to close  in your example
|
|  IMO those close tags are optional, see
|  http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.2.5
|

They may be optional, but if you write testcase, it's better to use 
well-written HTML. I would prefer XHTML 1.0/1.1 over HTML x.y, validated by 
W3C Validator (in case you compare output with, say, Mozilla; rendering by MS 
IE is different story)

|
|  Regards,
|
|  Koos Vriezen

Kind Regards,
-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/




From hanleyman at adelphia.net  Mon Jul 29 15:03:10 2002
From: hanleyman at adelphia.net (Doug Hanley)
Date: Mon, 29 Jul 2002 10:03:10 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207290932.19065.david@mandrakesoft.com>
References: <200207281142.45724.hanleyman@adelphia.net> <200207290444.59486.germain@ebooksfrance.com> <200207290932.19065.david@mandrakesoft.com>
Message-ID: <200207291003.10287.hanleyman@adelphia.net>

On Monday 29 July 2002 03:32 am, David Faure wrote:
> Question to Doug: why does addTab() have a bool forceAutoEmbed parameter?
> I think it should always pass true to createView, instead of that bool, so
> that embedding always happens.

Yes, I agree it should.  I guess I just sort of missed that.  I think when I 
integrated forceAutoEmbed into my tab code I wasn't really sure what it was, 
but now I do and I see that a new tab should behave much like a new window in 
that respect.  I suggest you change it in the CVS.

> (if anyone wants to test: I'm talking about KonqViewManager::addTab, the
> createView() call on line 366 in konq_viewmgr.cc)

I'll test it too.

-- Doug Hanley



From germain at ebooksfrance.com  Mon Jul 29 15:05:16 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Mon, 29 Jul 2002 15:05:16 +0100
Subject: action for LMB click in Konqueror
In-Reply-To: <200207290912.39108.till@snafu.de>
References: <3D44752F.6070307@gmx.de> <200207290541.33755.germain@ebooksfrance.com> <200207290912.39108.till@snafu.de>
Message-ID: <200207291505.16830.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 08:12, Till Krech a écrit :
> On Monday 29 July 2002 06:41, Germain Garand wrote:
> > Le Lundi 29 Juillet 2002 00:47, Till Krech a écrit :
> > > Hi,
> > >
> > > I think, this is already changed in cvs HEAD.
> > > At least, text/plain opens in a separate kwrite here.
> > > OTOH, there seems to an incosistency between the filemanager settings
> > > and this behaviour. The settings of 'Filemanager=>File Associations'
> > > for text/plain, Embedding are here: 'use settings for text group' and
> > > the text group says 'show file in embedded viewer'
> > > But the file opens in a separate viewer (kwrite).
> >
> > You're right... the setting for mimetype groups is just plain ignored !
> >
> > It seems that if you first mark a mimetype to be externally or internally
> > viewed, apply the change, and then later switch it to "use settings for
> > XXX group", then it doesn't switch and just uses whatever you choose
> > before...
> >
> > I have also a problem with application/x-shellscript => it should open
> > either in kwrite or in the embedded viewer, but it simply does nothing...
>
> hmm, if it is executable, it executes. Not very nice because you don't see
> any output since shell scripts normally have no gui ;) Some installers or
> launchers are exceptions.

Damn... how dangerous ! After half an hour playing with this, I'd better check 
my datas :(((

Now, wait a minute, among all the shellscripts I tested, only one was actually 
executable, and all gave the same result...
Though my settings are : LMB action: open in Kwrite...

And Is one suppposed to check the +x property of a shell script before even 
thinking about clicking on it ?

> I think this is a problem. There is no visual feedback and something
> happens which you are not aware of.
> According to the file manager settings, it should open in kwrite.
>
> If a shell script executes, it should at least do so in a konsole window,
> so that you see the output. Even better: ask before.

Yes !!! I didn't even thought a second a shell script could execute on click ! 
*strucking horror*

>
> Perhaps it would be good to look into an executable, if it is a native
> binary, links to libX11 and only then, execute it on click.
>

Sounds good ... or if it's not linked to X11, prompt a confirmation dialog... 

> many of my shell scripts do nasty things like cleaning up whole
> directories, doing clean on the whole kde src tree to recompile everything
> etc., I would never like to execute them without seeing what they are doing
> and where they are doing it ($PWD).
>
> regards, till
>
> > G.




From germain at ebooksfrance.com  Mon Jul 29 15:10:21 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Mon, 29 Jul 2002 15:10:21 +0100
Subject: action for LMB click in Konqueror
In-Reply-To: <200207290928.20290.david@mandrakesoft.com>
References: <3D44752F.6070307@gmx.de> <200207290541.33755.germain@ebooksfrance.com> <200207290928.20290.david@mandrakesoft.com>
Message-ID: <200207291510.21978.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 08:28, David Faure a écrit :
> > It seems that if you first mark a mimetype to be externally or internally
> > viewed, apply the change, and then later switch it to "use settings for
> > XXX group", then it doesn't switch and just uses whatever you choose
> > before...
>
> I forgot to update the kcontrol file associations module after changing the
> defaults. Thanks for noticing, fixed (please re-test).
>

I will ASAP !

> > I have also a problem with application/x-shellscript => it should open
> > either in kwrite or in the embedded viewer, but it simply does nothing...
>
> Err, clicking on a shell script executes it ...
>

That is IMHO, very bad policy... unless my KFM settings displays /usr/bin/sh 
as the preferred application in "General", I see no good reason why a shell 
script (which is rather, intrinsically, a document...) should run by itself ?

G.


> - --
> David FAURE, david at mandrakesoft.com, faure at kde.org
> http://people.mandrakesoft.com/~david/
> Contributing to: http://www.konqueror.org/, http://www.koffice.org/
> KOffice 1.2 RC1 is slightly delayed. Stay tuned.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.6 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
>
> iD8DBQE9RO6T72KcVAmwbhARAvO0AJ93vF29zCrD+mMmM8hmFRrfMdELmgCfQtQX
> 6H8i3rp65vsrEx6+vVQYvnI=
> =yevw
> -----END PGP SIGNATURE-----




From neil at qualityassistant.com  Mon Jul 29 15:08:28 2002
From: neil at qualityassistant.com (Neil Stevens)
Date: Mon, 29 Jul 2002 07:08:28 -0700
Subject: action for LMB click in Konqueror
In-Reply-To: <200207290912.39108.till@snafu.de>
References: <3D44752F.6070307@gmx.de> <200207290541.33755.germain@ebooksfrance.com> <200207290912.39108.till@snafu.de>
Message-ID: <200207290708.36325.neil@qualityassistant.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday July 29, 2002 12:12, Till Krech wrote:
> Perhaps it would be good to look into an executable, if it is a native
> binary, links to libX11 and only then, execute it on click.

That won't work for the not-uncommon case of a script that runs some 
graphical program.

- -- 
Neil Stevens - neil at qualityassistant.com
"I always cheer up immensely if an attack is particularly wounding
because I think, well, if they attack one personally, it means they
have not a single political argument left." - Margaret Thatcher
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RUxkf7mnligQOmERAhiHAJ9DNFX4GZHlKFsQ5b6hBO1QfqoAiwCfW36D
lqTMpq3ognMqJg5F2JGfNno=
=7uRM
-----END PGP SIGNATURE-----




From david at mandrakesoft.com  Mon Jul 29 15:19:11 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 29 Jul 2002 16:19:11 +0200
Subject: action for LMB click in Konqueror
In-Reply-To: <200207291510.21978.germain@ebooksfrance.com>
References: <3D44752F.6070307@gmx.de> <200207290928.20290.david@mandrakesoft.com> <200207291510.21978.germain@ebooksfrance.com>
Message-ID: <200207291619.11848.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 29 July 2002 16:10, Germain Garand wrote:
> Le Lundi 29 Juillet 2002 08:28, David Faure a écrit :
> > Err, clicking on a shell script executes it ...
> >
> 
> That is IMHO, very bad policy... unless my KFM settings displays /usr/bin/sh 
> as the preferred application in "General", I see no good reason why a shell 
> script (which is rather, intrinsically, a document...) should run by itself ?

Well, what happens when clicking on an executable? (in any desktop you can
think of, including Mac and Windows?) 

shellscripts are only one kind of executables.

(the other mail about the +x bit sounds like a bug though. We detect the
application/x-shellscript from the content, and then test for that...
I suggest testing for the file permissions in kdelibs/kio/kio/krun.cpp:86
(sorry, no time for doing all the changes people talk about, so I just give hints ;)

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RU7f72KcVAmwbhARAvZqAJ96xaafUgUNjrtuC9YkHLpGe/sF1gCeInsu
tIA+tzqy6nTmZe3s3KV1kqM=
=s93i
-----END PGP SIGNATURE-----




From hetz at kde.org  Mon Jul 29 15:31:51 2002
From: hetz at kde.org (Hetz Ben Hamo)
Date: Mon, 29 Jul 2002 17:31:51 +0300
Subject: style sheet problems?
Message-ID: <200207291731.52220.hetz@kde.org>

Hi,

Over the last few days I have seen a weird look at a page I'm using regulary 
to read the news. URL: http://news.walla.co.il (user agent should be set to 
MSIE)

Here are 2 screenshots:

http://witch.dyndns.org:8001/kong.png - thats how it looks today with 
konqueror (compiled yesterday - problem appears already few days)

http://witch.dyndns.org:8001/galeon.png - thats how it should look and thats 
how it was looking at konqueror few weeks ago - galeon/mozilla & konqueror 
rendered the same page exactly with the same look.

Thanks,
Hetz



From david at mandrakesoft.com  Mon Jul 29 15:59:33 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 29 Jul 2002 16:59:33 +0200
Subject: Find File in tree view of Konqueror
In-Reply-To: <3D447677.7030907@gmx.de>
References: <3D447677.7030907@gmx.de>
Message-ID: <200207291659.34030.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 29 July 2002 00:55, falk.brettschneider at gmx.de wrote:
> Hi!
> Please, can you add that very useful action 'Find file...' to the 
> context menu of the (left-hand side located) tree view of Konqueror?
> Sorry, I gave up studying the code for making a little patch since it's 
> too complex for me.

Can't see a relation between the sidebar directory tree, and "find file".
I don't see why we should clutter the popupmenu with it - it's in the menus already.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RVhV72KcVAmwbhARAo2lAJ9qSNBnSsnoD36JJ/FG24PT2GF4WgCfdFRr
2Q0DyG+raOuJ8+NQAAMiSUA=
=fudz
-----END PGP SIGNATURE-----




From hetz at kde.org  Mon Jul 29 15:59:28 2002
From: hetz at kde.org (Hetz Ben Hamo)
Date: Mon, 29 Jul 2002 17:59:28 +0300
Subject: konq. crash
Message-ID: <200207291759.28279.hetz@kde.org>

Hi,

Here are the steps to reproduce a konq. crash:

go here: 
http://gamespot.com/gamespot/filters/products/media/0,11100,561527,00.html - 
this will take you to Dead or Alive Xtreme Beach Volleyball section in 
gamespot

Now - click on any link from the "streams" section - a popup window will ask 
you for user/pass or a registration

click the "sign up now" link - konq. crashes..

Backtrace:

[New Thread 1024 (LWP 1845)]
0x420b4859 in wait4 () from /lib/i686/libc.so.6
#0  0x420b4859 in wait4 () from /lib/i686/libc.so.6
#1  0x4213030c in __DTOR_END__ () from /lib/i686/libc.so.6
#2  0x40fc8ca3 in waitpid () from /lib/i686/libpthread.so.0
#3  0x405af549 in KCrash::defaultCrashHandler ()
   from /opt/kde3/lib/libkdecore.so.4
#4  0x40fc6f75 in pthread_sighandler () from /lib/i686/libpthread.so.0
#5  
#6  0x4162de59 in KonqMainWindow::closeEvent () from 
/opt/kde3/lib/konqueror.so
#7  0x409890be in QWidget::event () from /usr/local/qt-copy/lib/libqt-mt.so.3
#8  0x40a3876e in QMainWindow::event ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#9  0x408f5c38 in QApplication::internalNotify ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#10 0x408f5993 in QApplication::notify ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#11 0x4053528a in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4
#12 0x40988760 in QWidget::close () from /usr/local/qt-copy/lib/libqt-mt.so.3
#13 0x416473c4 in KonqViewManager::removePart ()
   from /opt/kde3/lib/konqueror.so
#14 0x4002c9c7 in KParts::Part::~Part () from /opt/kde3/lib/libkparts.so.2
#15 0x4002d328 in KParts::ReadOnlyPart::~ReadOnlyPart ()
   from /opt/kde3/lib/libkparts.so.2
#16 0x41a79a3f in KHTMLPart::~KHTMLPart () from /opt/kde3/lib/libkhtml.so.4
#17 0x4221167e in KJS::WindowQObject::timeoutClose ()
   from /opt/kde3/lib/kde3/kjs_html.so
#18 0x42216361 in KJS::WindowQObject::qt_invoke ()
   from /opt/kde3/lib/kde3/kjs_html.so
#19 0x4094e0fe in QObject::activate_signal ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#20 0x40c4d3c8 in QSignal::signal () from /usr/local/qt-copy/lib/libqt-mt.so.3
#21 0x40967774 in QSignal::activate ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#22 0x409701ae in QSingleShotTimer::event ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#23 0x408f5c38 in QApplication::internalNotify ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#24 0x408f5993 in QApplication::notify ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#25 0x4053528a in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4
#26 0x408931e2 in qt_activate_timers ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#27 0x40890ace in QApplication::processNextEvent ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#28 0x408f759c in QApplication::enter_loop ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#29 0x4089065c in QApplication::exec ()
   from /usr/local/qt-copy/lib/libqt-mt.so.3
#30 0x4160f089 in main () from /opt/kde3/lib/konqueror.so
#31 0x0804c9e8 in launch ()
#32 0x0804d6a3 in handle_launcher_request ()
#33 0x0804db52 in handle_requests ()
#34 0x0804eafe in main ()
#35 0x42017589 in __libc_start_main () from /lib/i686/libc.so.6

Hetz



From zack at kde.org  Mon Jul 29 21:07:17 2002
From: zack at kde.org (Zack Rusin)
Date: Mon, 29 Jul 2002 16:07:17 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207290252.26572.hanleyman@adelphia.net>
References: <200207281142.45724.hanleyman@adelphia.net> <200207281839.10689.zack@kde.org> <200207290252.26572.hanleyman@adelphia.net>
Message-ID: <200207291607.17731.zack@kde.org>

On Monday 29 July 2002 02:52, Doug Hanley wrote:
> On Sunday 28 July 2002 06:39 pm, Zack Rusin wrote:
> > On Sunday 28 July 2002 18:18, Doug Hanley wrote:
> > > Would you be willing to put some time into that?
> >
> > I'd love to! Using QTabBar is hardly any fun, since no matter what
> > we do it's still going to be a hack.
>
> Yeah, I Agree.  Just one thing though... before, you said that we
> would create a new tab bar that doesn't inherit QTabBar.  The problem
> with that is becuase we must use the function QTabWidget::setTabBar(
> QTabBar * ) it has to inherit QTabBar.  Now, that raised another
> problem, even if we reimplement all the functions, we still can't
> access the private variables, so we would have to make new variables
> for our own use (although they would be very similar to the existing
> ones).  That would result in a slight waste of memory, but its very
> marginal and there is only one of these objects per window at most.

Well, I though about writing our QTabWidget, it's not exactly a 
complicated widget, it only places the tabbar somewhere in the window. 
I have to say I don't really like the idea of inheriting QTabBar, what 
we'll have is a widget that 'behaves-like' QTabBar but not 'IS-A' 
QTabBar, meaning we don't really have a valid ground to be inheriting 
from QTabBar, especially that in this or other way we have to replace 
basically _all_ methods in QTabBar in order to prevent it from calling 
private updateArrowButtons. Not only that we will still get messed up 
behavior from tooltips - the class handling tooltips in tabbar is 
internal to it and their placement could be all wrong if we decide to 
remove the arrow buttons.

> Hmm... You know what, I've always found those arrow things kind of
> annoying anyway.  I think we should adopt mozilla's policy and scale
> the tabs.  Its much more usable in my opinion.

Yes, I like this behavior more too, but it will cause problems if we 
inherit from QTabBar.

> So, do you want to just start with qtabbar.h and qtabbar.cpp and
> adjust from there?  I think maybe i'll start some work on that now. 

Let's divide, one of us takes TabBar the other TabWidget and we'll 
connect.

> One problem though, I'll be gone for about 3 weeks starting tuesday
> (I'm seeing going to see The Who in NYC, woohoo!), so I probably wont
> have much time to work on this then. After that though, I'm ready as
> I'll ever be.

Oh, cool, email me privately when you'll come to NYC. I lived there for 
a long time, now I live in Phily but come to NYC every two weeks or so, 
to see my friends. Maybe we could meet.

Zack

-- 
Give me ambiguity or give me something else.




From zack at kde.org  Mon Jul 29 21:15:46 2002
From: zack at kde.org (Zack Rusin)
Date: Mon, 29 Jul 2002 16:15:46 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207290923.34592.david@mandrakesoft.com>
References: <200207281142.45724.hanleyman@adelphia.net> <200207281607.15128.zack@kde.org> <200207290923.34592.david@mandrakesoft.com>
Message-ID: <200207291615.46409.zack@kde.org>

On Monday 29 July 2002 03:23, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sunday 28 July 2002 22:07, Zack Rusin wrote:
> > 1) (the long way) write our own KTabBar (not inheriting from
> > QTabBar), and draw it in whatever way we like it,
> > 2) not draw the last tab (looks horrible),
> > 3) draw a background over the tabs and underneath the close button
> > and arrow buttons,
> > 4) solution I haven't thought about.
>
> If it helps: QTella has close button on tabs .... maybe you want to
> look at how they do it?   (qtella.sourceforge.net)

It does? Are you sure? I'm using QTella (to share family pictures of 
course, and not, god forbid, download music) and haven't seen any close 
buttons on their tabs. Their tabbar inherits QTabBar and reimplements 
only mousePressEvent so I don't see how they could have those buttons 
drawn on it. To be honest this wouldn't be so hard to implement. We 
would have to reimplement paint(QTab ...), mouseClickedEvent and 
mouseMoveEvent inside KonqTabBar and that be it. The question is 
whether close buttons on tabs are better than a close button at the end 
of the tabbar. Of course by writing our own TabBar we could make it 
customizable, which I guess would be the 'right way' of doing this.

Zack

-- 
Failure is not an option. (It comes bundled with Windows.)




From david at mandrakesoft.com  Mon Jul 29 21:26:03 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 29 Jul 2002 22:26:03 +0200
Subject: MMB opens in new tab
In-Reply-To: <200207291615.46409.zack@kde.org>
References: <200207281142.45724.hanleyman@adelphia.net> <200207290923.34592.david@mandrakesoft.com> <200207291615.46409.zack@kde.org>
Message-ID: <200207292226.03707.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 29 July 2002 22:15, Zack Rusin wrote:
> It does? Are you sure? I'm using QTella (to share family pictures of 
> course, and not, god forbid, download music) and haven't seen any close 
> buttons on their tabs.

Go to the "Search" tab, there enter 2 or 3 searches. Each one creates a tab,
with a close button on it.

QTella 0.5.3.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RaTb72KcVAmwbhARAuDTAKCc5598kkL+M8M1mKwjtO9rkV3QMgCeI1WX
I2VIjgxz96PSiIe2FPUcBtg=
=ogGO
-----END PGP SIGNATURE-----




From germain at ebooksfrance.com  Mon Jul 29 21:40:22 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Mon, 29 Jul 2002 21:40:22 +0100
Subject: action for LMB click in Konqueror
In-Reply-To: <200207291619.11848.david@mandrakesoft.com>
References: <3D44752F.6070307@gmx.de> <200207291510.21978.germain@ebooksfrance.com> <200207291619.11848.david@mandrakesoft.com>
Message-ID: <200207292140.22569.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 15:19, David Faure a écrit :
> > That is IMHO, very bad policy... unless my KFM settings displays
> > /usr/bin/sh as the preferred application in "General", I see no good
> > reason why a shell script (which is rather, intrinsically, a document...)
> > should run by itself ?
>
> Well, what happens when clicking on an executable? (in any desktop you can
> think of, including Mac and Windows?)
>
> shellscripts are only one kind of executables.

You mean : if they have the +x mode ?
The problem is their dual nature turn them into Shröninger's Cat objects...
One might not know when one click them wether they are executables or not..

For the moment, the code only checks the service type to see if it belong to 
the "might be" executable category, but it knows nothing about the actual 
status of the file.
There are some hacks to specifically allow x-shellscript to run, but it does 
not solve the overall problem of isTextExecutable( services).

>
> (the other mail about the +x bit sounds like a bug though. We detect the
> application/x-shellscript from the content, and then test for that...
> I suggest testing for the file permissions in kdelibs/kio/kio/krun.cpp:86
> (sorry, no time for doing all the changes people talk about, so I just give
> hints ;)

I didn't had much time today, but I'll work on a patch... may I ?

G.




From zack at kde.org  Mon Jul 29 21:42:19 2002
From: zack at kde.org (Zack Rusin)
Date: Mon, 29 Jul 2002 16:42:19 -0400
Subject: MMB opens in new tab
In-Reply-To: <200207292226.03707.david@mandrakesoft.com>
References: <200207281142.45724.hanleyman@adelphia.net> <200207291615.46409.zack@kde.org> <200207292226.03707.david@mandrakesoft.com>
Message-ID: <200207291642.19293.zack@kde.org>

On Monday 29 July 2002 16:26, David Faure wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 29 July 2002 22:15, Zack Rusin wrote:
> > It does? Are you sure? I'm using QTella (to share family pictures
> > of course, and not, god forbid, download music) and haven't seen
> > any close buttons on their tabs.
>
> Go to the "Search" tab, there enter 2 or 3 searches. Each one creates
> a tab, with a close button on it.

That's just a static pixmap, we could add those but would have to 
eliminate favicons from the tabs.

Zack

-- 
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James




From koos.vriezen at xs4all.nl  Mon Jul 29 21:44:03 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Mon, 29 Jul 2002 22:44:03 +0200 (CEST)
Subject: Small test case for bug in renderer floats
In-Reply-To: <200207291728.59994.lucy-ples@mtu-net.ru>
References: <200207291728.59994.lucy-ples@mtu-net.ru>
Message-ID: 

On Mon, 29 Jul 2002, Vadim Plessky wrote:

> On Monday 29 July 2002 2:43 pm, Koos Vriezen wrote:
> |  On Mon, 29 Jul 2002, Vadim Plessky wrote:
> |  > On Sunday 28 July 2002 5:15 pm, Koos Vriezen wrote:
> |  > |  This is rendered wrong
> |  > |    
> |  > |     div text
div text
> |  > |     some text
> |  > |    
> |  > |
> |  > |  Seems the float gets an extra left offset if the height is greater
> |  > | than height of surrounding text.
>
> and, BTW, problem is related not to the amount of text outside floating DIV,
> but to the heigh tof body.

Exactly and I think I found the cause. The test in
RenderFlow::layoutBlockChildren of RenderHtml
'if ( child->hasOverhangingFloats() )', where
hasOverhangingFloats() is defined as 'floatBottom() > m_height', succeeds
in this case. The child being the body.
Next it calls RenderFlow::addOverHangingFloats with
child, -child->xPos(), -child->yPos() and true for flow, xoff, offset and
child resp.
A new special is created with 'special->left' is set to 'r->left - xoff'
(becomes +10). The test 'if (flow != parent())' succeeds and
'special->left += flow->marginLeft()' is executed (becomes +20).
The next test 'if ( !child )' fails, but has no effect, since the if
clause 'special->left -= marginLeft()' does nothing for a RenderHtml.

Not sure what goes wrong here, but this makes the float be indented by the
body margin twice. First guess would be call
RenderFlow::addOverHangingFloats with child, 0, -child->yPos() and true.
Also helps for http://www.linuxplanet.com/linuxplanet/reviews/4315/1
reported by Hetz Ben Hamo on 18 July to this list.

> |
> |  > BTW: you forgot to close  in your example
> |
> |  IMO those close tags are optional, see
> |  http://www.w3.org/TR/1999/REC-html401-19991224/struct/tables.html#h-11.2.5
> |
>
> They may be optional, but if you write testcase, it's better to use
> well-written HTML. I would prefer XHTML 1.0/1.1 over HTML x.y, validated by
> W3C Validator (in case you compare output with, say, Mozilla; rendering by MS
> IE is different story)

Will try to remember it the next time.

Koos






From david at mandrakesoft.com  Mon Jul 29 21:51:31 2002
From: david at mandrakesoft.com (David Faure)
Date: Mon, 29 Jul 2002 22:51:31 +0200
Subject: action for LMB click in Konqueror
In-Reply-To: <200207292140.22569.germain@ebooksfrance.com>
References: <3D44752F.6070307@gmx.de> <200207291619.11848.david@mandrakesoft.com> <200207292140.22569.germain@ebooksfrance.com>
Message-ID: <200207292251.31528.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 29 July 2002 22:40, Germain Garand wrote:
> Le Lundi 29 Juillet 2002 15:19, David Faure a écrit :
> > > That is IMHO, very bad policy... unless my KFM settings displays
> > > /usr/bin/sh as the preferred application in "General", I see no good
> > > reason why a shell script (which is rather, intrinsically, a document...)
> > > should run by itself ?
> >
> > Well, what happens when clicking on an executable? (in any desktop you can
> > think of, including Mac and Windows?)
> >
> > shellscripts are only one kind of executables.
> 
> You mean : if they have the +x mode ?
Yes (you're right).

> The problem is their dual nature turn them into Shröninger's Cat objects...
> One might not know when one click them wether they are executables or not..
Right... maybe we need a different icon for "executable shellscript"
and "non-executable shellscript" ?

> For the moment, the code only checks the service type to see if it belong to 
> the "might be" executable category, but it knows nothing about the actual 
> status of the file.
> There are some hacks to specifically allow x-shellscript to run, but it does 
> not solve the overall problem of isTextExecutable( services).
>
> > (the other mail about the +x bit sounds like a bug though. We detect the
> > application/x-shellscript from the content, and then test for that...
> > I suggest testing for the file permissions in kdelibs/kio/kio/krun.cpp:86
> > (sorry, no time for doing all the changes people talk about, so I just give
> > hints ;)
> 
> I didn't had much time today, but I'll work on a patch... may I ?

Sure ;-) 

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RarT72KcVAmwbhARAnYJAJ9X8VwI+ViwzJBjhxXvtYSXu6M3RACfdihO
knP6Om4Lz3Lu9cqeQR1UIxo=
=V7GC
-----END PGP SIGNATURE-----




From germain at ebooksfrance.com  Mon Jul 29 22:32:34 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Mon, 29 Jul 2002 22:32:34 +0100
Subject: action for LMB click in Konqueror
In-Reply-To: <200207290928.20290.david@mandrakesoft.com>
References: <3D44752F.6070307@gmx.de> <200207290541.33755.germain@ebooksfrance.com> <200207290928.20290.david@mandrakesoft.com>
Message-ID: <200207292232.34367.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 08:28, David Faure a écrit :
> > It seems that if you first mark a mimetype to be externally or internally
> > viewed, apply the change, and then later switch it to "use settings for
> > XXX group", then it doesn't switch and just uses whatever you choose
> > before...
>
> I forgot to update the kcontrol file associations module after changing the
> defaults. Thanks for noticing, fixed (please re-test).

I've just rebuilt kcontrol but as far as I can see, the "use settings for XXX 
group"  checkbox still seems to do nothing.

Try this in kcontrol/file associations :
- set "text/plain" to "Show file in embedded.."
- apply
- set root "text" group to "Show file in separate.."
- apply
-set "text/plain" to "use settings for 'text' group"
- try to view a text file in konqui.

For me it still displays as embedded.




From hetz at kde.org  Mon Jul 29 23:50:15 2002
From: hetz at kde.org (Hetz Ben Hamo)
Date: Tue, 30 Jul 2002 01:50:15 +0300
Subject: smooth scrolling comment
Message-ID: <200207300150.15375.hetz@kde.org>

Hi,

I just noticied that if I press SHIFT and down arrow - the page is smooth 
scrolling downwards..

I got 2 questions:

1. In order to stop the scrolling - only the up key stops. Why not any key? 
I'm pretty sure end user would be pissed to find that they can't stop smooth 
scrolling unless they find that arrow up stops it.

2. Is there going to be also a smooth scrolling upwards and sideways please? 
it will help a lot with large tables..

Thanks,
Hetz



From coolo at kde.org  Tue Jul 30 09:26:13 2002
From: coolo at kde.org (Stephan Kulow)
Date: Tue, 30 Jul 2002 10:26:13 +0200
Subject: SIGPIPE in kio_http
Message-ID: <200207301026.17310.coolo@kde.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi!

Since quite some time I get more "Connection to host is broken"
than I used to when I fill forms. It seems to me that the slave requests
the server to leave the connection alive, but can't handle the fact that
the server closes it after some time. When I need some time to fill out 
the form, I get the error message and can nothing but go back and resubmit
til it works.

To me it seems, the http slave should handle the fact that sendBody
gets a EPIPE in write in reopening the connection and not simply giving
an error to the user. But I have no idea how to fix that best in http.cc
or slavebase

Greetings, Stephan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9Rk2pwFSBhlBjoJYRAjTXAJ9EIPgYz1LBVCnysshaU3hVLdQVLQCgtx0a
RsfFz5bovW3H51kTO097sLk=
=Y2Bj
-----END PGP SIGNATURE-----




From cap at capsi.com  Tue Jul 30 09:44:45 2002
From: cap at capsi.com (Rob Kaper)
Date: Tue, 30 Jul 2002 10:44:45 +0200
Subject: SIGPIPE in kio_http
In-Reply-To: <200207301026.17310.coolo@kde.org>; from coolo@kde.org on Tue, Jul 30, 2002 at 10:26:13AM +0200
References: <200207301026.17310.coolo@kde.org>
Message-ID: <20020730104445.A10015@capsi.com>

On Tue, Jul 30, 2002 at 10:26:13AM +0200, Stephan Kulow wrote:
> Since quite some time I get more "Connection to host is broken"
> than I used to when I fill forms. It seems to me that the slave requests
> the server to leave the connection alive, but can't handle the fact that
> the server closes it after some time. When I need some time to fill out 
> the form, I get the error message and can nothing but go back and resubmit
> til it works.
> 
> To me it seems, the http slave should handle the fact that sendBody
> gets a EPIPE in write in reopening the connection and not simply giving
> an error to the user. But I have no idea how to fix that best in http.cc
> or slavebase

Oh, I'm not the only one. This seems to happen at some sites more than
others.. it seems to happen a lot more frequently at MSDN and also at
kdenews.unixcode.org. At first I thought it was a problem with the site but
then it also happened at more sites (some camera reviews on dpreview.com for
example).

Sorry, a testcase would be nicer, but at least I can reproduce with these
sites (although it might take a couple of posts).

Rob
-- 
Rob Kaper     | Gimme some love, gimme some skin,
cap at capsi.com | if we ain't got that then we ain't got much
www.capsi.com | and we ain't got nothing, nothing! -- "Nothing" by A



From koos.vriezen at xs4all.nl  Tue Jul 30 13:32:22 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 30 Jul 2002 14:32:22 +0200 (CEST)
Subject: Small test case for bug in renderer floats
In-Reply-To: 
References: 
Message-ID: 

On Mon, 29 Jul 2002, Koos Vriezen wrote:

> > On Monday 29 July 2002 2:43 pm, Koos Vriezen wrote:
> > |  > |  This is rendered wrong
> > |  > |    
> > |  > |     div text
div text
> > |  > |     some text
> > |  > |    

> Not sure what goes wrong here, but this makes the float be indented by the
> body margin twice. First guess would be call
> RenderFlow::addOverHangingFloats with child, 0, -child->yPos() and true.
> Also helps for http://www.linuxplanet.com/linuxplanet/reviews/4315/1
> reported by Hetz Ben Hamo on 18 July to this list.

This is the patch I used.

diff -u -3 -p -r1.277 render_flow.cpp
--- rendering/render_flow.cpp   2002/07/16 19:50:14     1.277
+++ rendering/render_flow.cpp   2002/07/30 12:24:27
@@ -452,7 +452,7 @@ void RenderFlow::layoutBlockChildren( bo

        if ( child->hasOverhangingFloats() ) {
            // need to add the float to our special objects
-           addOverHangingFloats( static_cast(child), -child->xPos(), -child->yPos(), true );
+           addOverHangingFloats( static_cast(child), 0, -child->yPos(), true );
        }

         child = child->nextSibling();

It also fixes Bug#41403, that is the alignment with the body right border.
But is it correct that a RenderHtml can have a special? Now you have a
float that has a height greater than that of the body.

Koos




From coolo at kde.org  Tue Jul 30 13:07:01 2002
From: coolo at kde.org (Stephan Kulow)
Date: Tue, 30 Jul 2002 14:07:01 +0200
Subject: SIGPIPE in kio_http
In-Reply-To: <20020730104445.A10015@capsi.com>
References: <200207301026.17310.coolo@kde.org> <20020730104445.A10015@capsi.com>
Message-ID: <200207301407.02226.coolo@kde.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 30 July 2002 10:44, Rob Kaper wrote:
> On Tue, Jul 30, 2002 at 10:26:13AM +0200, Stephan Kulow wrote:
> > Since quite some time I get more "Connection to host is broken"
> > than I used to when I fill forms. It seems to me that the slave requests
> > the server to leave the connection alive, but can't handle the fact that
> > the server closes it after some time. When I need some time to fill out
> > the form, I get the error message and can nothing but go back and
> > resubmit til it works.
> >
> > To me it seems, the http slave should handle the fact that sendBody
> > gets a EPIPE in write in reopening the connection and not simply giving
> > an error to the user. But I have no idea how to fix that best in http.cc
> > or slavebase
>
> Oh, I'm not the only one. This seems to happen at some sites more than
> others.. it seems to happen a lot more frequently at MSDN and also at
> kdenews.unixcode.org. At first I thought it was a problem with the site but
> then it also happened at more sites (some camera reviews on dpreview.com
> for example).
>
> Sorry, a testcase would be nicer, but at least I can reproduce with these
> sites (although it might take a couple of posts).
>
For me it's very easily reproducable using forms that POST. Open the form,
wait say 5 seconds and press submit - bang

Greetings, Stephan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9RoFlwFSBhlBjoJYRAnmbAJ9AeIOPxL/ffXFHBfi+SGjmxJh5nwCgo6j1
tW60Pc8+AVqF0PmGhDHnqm0=
=0Yzz
-----END PGP SIGNATURE-----





From lucy-ples at mtu-net.ru  Tue Jul 30 14:10:23 2002
From: lucy-ples at mtu-net.ru (Vadim Plessky)
Date: Tue, 30 Jul 2002 17:10:23 +0400
Subject: Small test case for bug in renderer floats
In-Reply-To: 
References: 
Message-ID: <200207301710.23855.lucy-ples@mtu-net.ru>

On Tuesday 30 July 2002 4:32 pm, Koos Vriezen wrote:
|  On Mon, 29 Jul 2002, Koos Vriezen wrote:
|  >
|  > Not sure what goes wrong here, but this makes the float be indented by
|  > the body margin twice. First guess would be call
|  > RenderFlow::addOverHangingFloats with child, 0, -child->yPos() and true.
|  > Also helps for http://www.linuxplanet.com/linuxplanet/reviews/4315/1
|  > reported by Hetz Ben Hamo on 18 July to this list.
|
|  This is the patch I used.
|
|  diff -u -3 -p -r1.277 render_flow.cpp
|  --- rendering/render_flow.cpp   2002/07/16 19:50:14     1.277
|  +++ rendering/render_flow.cpp   2002/07/30 12:24:27
|  @@ -452,7 +452,7 @@ void RenderFlow::layoutBlockChildren( bo
|
|          if ( child->hasOverhangingFloats() ) {
|              // need to add the float to our special objects
|  -           addOverHangingFloats( static_cast(child),
| -child->xPos(), -child->yPos(), true ); +           addOverHangingFloats(
| static_cast(child), 0, -child->yPos(), true ); }
|
|           child = child->nextSibling();
|
|  It also fixes Bug#41403, that is the alignment with the body right border.
|  But is it correct that a RenderHtml can have a special? Now you have a
|  float that has a height greater than that of the body.

I think that  element should be auto-expanded in case some child element 
is bigger than it.
Situation with absolutely (and relatively) positioned elements, plus with 
'float', is not so clear.
IIRC W3C CSS2 specification says nothing about it...
May be, you should ask on  mailing list what is corrected/expected 
behaviour?

|
|  Koos

-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/




From cap at capsi.com  Tue Jul 30 14:12:36 2002
From: cap at capsi.com (Rob Kaper)
Date: Tue, 30 Jul 2002 15:12:36 +0200
Subject: SIGPIPE in kio_http
In-Reply-To: <200207301407.02226.coolo@kde.org>; from coolo@kde.org on Tue, Jul 30, 2002 at 02:07:01PM +0200
References: <200207301026.17310.coolo@kde.org> <20020730104445.A10015@capsi.com> <200207301407.02226.coolo@kde.org>
Message-ID: <20020730151236.A15020@capsi.com>

On Tue, Jul 30, 2002 at 02:07:01PM +0200, Stephan Kulow wrote:
> For me it's very easily reproducable using forms that POST. Open the form,
> wait say 5 seconds and press submit - bang

Well, most of the KDEnews actions are posts (reply buton, login button, vote
button).. and I believe the navigation on dpreview.com also worked like
that. It does not happen on *all* POST forms though, I've seen plenty that
work fine.

Rob
-- 
Rob Kaper     | Gimme some love, gimme some skin,
cap at capsi.com | if we ain't got that then we ain't got much
www.capsi.com | and we ain't got nothing, nothing! -- "Nothing" by A



From Ladislav.Strojil at seznam.cz  Tue Jul 30 14:48:26 2002
From: Ladislav.Strojil at seznam.cz (Ladislav Strojil)
Date: Tue, 30 Jul 2002 15:48:26 +0200
Subject: SIGPIPE in kio_http
In-Reply-To: <20020730151236.A15020@capsi.com>
References: <200207301026.17310.coolo@kde.org> <200207301407.02226.coolo@kde.org> <20020730151236.A15020@capsi.com>
Message-ID: <200207301548.27453.Ladislav.Strojil@seznam.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 30 July 2002 15:12, Rob Kaper wrote:
> On Tue, Jul 30, 2002 at 02:07:01PM +0200, Stephan Kulow wrote:
> > For me it's very easily reproducable using forms that POST. Open the
> > form, wait say 5 seconds and press submit - bang
>
> Well, most of the KDEnews actions are posts (reply buton, login button,
> vote button).. and I believe the navigation on dpreview.com also worked
> like that. It does not happen on *all* POST forms though, I've seen plenty
> that work fine.

It happens here too (CVS few days old).

The form is as simple as this:

        
                
                        

                        

                        

                        

                        

                        

                        

                        
                

        


Nothing unsual.

Cheers,
Lada

- -- 
    ~       Ladislav Strojil, MFF UK
  ' v '               
 //   \\              
/(     )\    Powered by Penguin.
  ^ ' ^
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9RpkqTnMZPFqq4nwRAtFUAJ9NuXjdybk5cYNVdzFnZCJgWNz+QgCgsKBD
bme+heYZ0jrJ7bEnxnmHwZ8=
=FMAx
-----END PGP SIGNATURE-----




From germain at ebooksfrance.com  Tue Jul 30 16:36:15 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Tue, 30 Jul 2002 16:36:15 +0100
Subject: action for LMB click in Konqueror
In-Reply-To: <200207292251.31528.david@mandrakesoft.com>
References: <3D44752F.6070307@gmx.de> <200207292140.22569.germain@ebooksfrance.com> <200207292251.31528.david@mandrakesoft.com>
Message-ID: <200207301636.15645.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 21:51, David Faure a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 29 July 2002 22:40, Germain Garand wrote:
> > Le Lundi 29 Juillet 2002 15:19, David Faure a écrit :
> > > > That is IMHO, very bad policy... unless my KFM settings displays
> > > > /usr/bin/sh as the preferred application in "General", I see no good
> > > > reason why a shell script (which is rather, intrinsically, a
> > > > document...) should run by itself ?
> > >
> > > Well, what happens when clicking on an executable? (in any desktop you
> > > can think of, including Mac and Windows?)
> > >
> > > shellscripts are only one kind of executables.
> >
> > You mean : if they have the +x mode ?
>
> Yes (you're right).
>
> > The problem is their dual nature turn them into Shröninger's Cat
> > objects... One might not know when one click them wether they are
> > executables or not..
>
> Right... maybe we need a different icon for "executable shellscript"
> and "non-executable shellscript" ?

That would be good, but wouldn't it be better to have a way to visually 
identify all +x file ? (e.g : a small x in a corner, in the same way symlink 
arrow does)

Because a +x perl, python, ruby, whatever script should also be executed, if 
the goal is to be consistent... 

Now I really need some advices : I've got a fix that says :
if( file is local && service type starts with  "application/x-" && the file 
has mode +x )
{execute through shell}
else{ use trader offers if any}

That works great... but there is ONE problem, always the same : Microsoft...

What if a user left click on an application/x-msword on a sucking filesystem 
that does not support +x ? (that is : with all files set to +x... like on a 
e.g: FAT32)

Only possibilities I see to avoid that is :
1) hardcode all relevant "application/x-XXXX" that are really executable 
(that's what was done with application/x-shellscript)
No need to say this one sucks.

2) have a KMessageBoxWrapper prompt for execution for all "application/x-" 
that are not mere "application/x-executable" (maybe with a "never show this 
again")... and use offers if the answer is "no".
May be ennoying. Or let "never show this again" identifier be constructed 
dynamically with servicetype so that it's fine grained ? Then add checkboxes 
in application/x-... ?

What do you think ?

G.





From koos.vriezen at xs4all.nl  Tue Jul 30 17:34:19 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 30 Jul 2002 18:34:19 +0200 (CEST)
Subject: SIGPIPE in kio_http
In-Reply-To: <200207301407.02226.coolo@kde.org>
References: <200207301407.02226.coolo@kde.org>
Message-ID: 

On Tue, 30 Jul 2002, Stephan Kulow wrote:

> For me it's very easily reproducable using forms that POST. Open the form,
> wait say 5 seconds and press submit - bang

Must be a keepalive connection that closes the socket after a few seconds.

Koos




From koos.vriezen at xs4all.nl  Tue Jul 30 17:36:46 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 30 Jul 2002 18:36:46 +0200 (CEST)
Subject: Small test case for bug in renderer floats
In-Reply-To: <200207301710.23855.lucy-ples@mtu-net.ru>
References: <200207301710.23855.lucy-ples@mtu-net.ru>
Message-ID: 

On Tue, 30 Jul 2002, Vadim Plessky wrote:

> On Tuesday 30 July 2002 4:32 pm, Koos Vriezen wrote:
> |
> |  It also fixes Bug#41403, that is the alignment with the body right border.
> |  But is it correct that a RenderHtml can have a special? Now you have a
> |  float that has a height greater than that of the body.
>
> I think that  element should be auto-expanded in case some child element
> is bigger than it.
> Situation with absolutely (and relatively) positioned elements, plus with
> 'float', is not so clear.
> IIRC W3C CSS2 specification says nothing about it...
> May be, you should ask on  mailing list what is corrected/expected
> behaviour?

OTOH Mozilla also renders the float height greater than the body height.
Can't be that wrong after all.

Koos




From koos.vriezen at xs4all.nl  Tue Jul 30 17:44:22 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 30 Jul 2002 18:44:22 +0200 (CEST)
Subject: smooth scrolling comment
In-Reply-To: <200207300150.15375.hetz@kde.org>
References: <200207300150.15375.hetz@kde.org>
Message-ID: 

On Tue, 30 Jul 2002, Hetz Ben Hamo wrote:

> 1. In order to stop the scrolling - only the up key stops. Why not any key?
> I'm pretty sure end user would be pissed to find that they can't stop smooth
> scrolling unless they find that arrow up stops it.

That wouldn't be to difficult to implement. Personaly I like the
combination of auto scrolling and PgUp/PgDown to quickly scan news sites.
But for other, non-scrolling keys, yes why not.

> 2. Is there going to be also a smooth scrolling upwards and sideways please?
> it will help a lot with large tables..

Scrolling up, wouldn't be hard to implement. Scrolling right/left needs
imo some changes in paintBuffer, an extra vertical or rotation by
drawPixmap. However the usefulness, compared to scrolling down, is a lot
less.

Koos




From bastian at kde.org  Tue Jul 30 19:57:55 2002
From: bastian at kde.org (Waldo Bastian)
Date: Tue, 30 Jul 2002 11:57:55 -0700
Subject: SIGPIPE in kio_http
In-Reply-To: <200207301026.17310.coolo@kde.org>
References: <200207301026.17310.coolo@kde.org>
Message-ID: <200207301157.55440.bastian@kde.org>

On Tuesday 30 July 2002 01:26 am, Stephan Kulow wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi!
>
> Since quite some time I get more "Connection to host is broken"
> than I used to when I fill forms. It seems to me that the slave requests
> the server to leave the connection alive, but can't handle the fact that
> the server closes it after some time. When I need some time to fill out
> the form, I get the error message and can nothing but go back and resubmit
> til it works.
>
> To me it seems, the http slave should handle the fact that sendBody
> gets a EPIPE in write in reopening the connection and not simply giving
> an error to the user. But I have no idea how to fix that best in http.cc
> or slavebase

Remarkable. We aren't suppoed to use persistent connections at all for 
anything but GET requests. 

*check*

Oh.. I see.. the check is done _after_ the request, instead of before the 
request. *duh*

Does this patch help?

Cheers,
Waldo
-- 
bastian at kde.org  |   SuSE Labs KDE Developer  |  bastian at suse.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: http.patch
Type: text/x-diff
Size: 1131 bytes
Desc: not available
URL: 

From falk.brettschneider at gmx.de  Tue Jul 30 21:21:36 2002
From: falk.brettschneider at gmx.de (F@lk Brettschneider)
Date: Tue, 30 Jul 2002 22:21:36 +0200
Subject: Find File in tree view of Konqueror
References: <3D447677.7030907@gmx.de> <200207291659.34030.david@mandrakesoft.com>
Message-ID: <3D46F550.7060201@gmx.de>

David Faure wrote:

>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On Monday 29 July 2002 00:55, falk.brettschneider at gmx.de wrote:
>
>>Hi!
>>Please, can you add that very useful action 'Find file...' to the 
>>context menu of the (left-hand side located) tree view of Konqueror?
>>Sorry, I gave up studying the code for making a little patch since it's 
>>too complex for me.
>>
>
>Can't see a relation between the sidebar directory tree, and "find file".
>I don't see why we should clutter the popupmenu with it - it's in the menus already.
>
Usually, in MSExplorer, I open a certain subdir in the tree, open the 
context menu and select 'Find file'. Then the preselected dir in the 
Find dialog will be that certain selected one. In my opinion very 
convinient.

Ciao
F at lk





From germain at ebooksfrance.com  Tue Jul 30 21:50:14 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Tue, 30 Jul 2002 21:50:14 +0100
Subject: Find File in tree view of Konqueror
In-Reply-To: <200207291659.34030.david@mandrakesoft.com>
References: <3D447677.7030907@gmx.de> <200207291659.34030.david@mandrakesoft.com>
Message-ID: <200207302150.14426.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 15:59, David Faure a écrit :
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Monday 29 July 2002 00:55, falk.brettschneider at gmx.de wrote:
> > Hi!
> > Please, can you add that very useful action 'Find file...' to the
> > context menu of the (left-hand side located) tree view of Konqueror?
> > Sorry, I gave up studying the code for making a little patch since it's
> > too complex for me.
>
> Can't see a relation between the sidebar directory tree, and "find file".
> I don't see why we should clutter the popupmenu with it - it's in the menus
> already.

Speaking about "Find file...", does it work correctly in CVS ?

here I got : 
konqueror: Trying to create view for "Konqueror/FindPart"
konqueror: KonqFMSettings says: don't embed this servicetype

and a dialog :
"Can't create the find part, check your installation"

G.
(I swore I didn't hack my kcontrol, yet :o)




From germain at ebooksfrance.com  Wed Jul 31 00:41:38 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Wed, 31 Jul 2002 00:41:38 +0100
Subject: [Patch] Re: Find File in tree view of Konqueror
In-Reply-To: <200207302150.14426.germain@ebooksfrance.com>
References: <3D447677.7030907@gmx.de> <200207291659.34030.david@mandrakesoft.com> <200207302150.14426.germain@ebooksfrance.com>
Message-ID: <200207310041.38622.germain@ebooksfrance.com>

Le Mardi 30 Juillet 2002 21:50, Germain Garand a écrit :

> konqueror: Trying to create view for "Konqueror/FindPart"
> konqueror: KonqFMSettings says: don't embed this servicetype
>
> and a dialog :
> "Can't create the find part, check your installation"

Ok, it's because of the default LMB action change
(a.k.a "don't embed anything, Windows users love to edit temp files")

Patch attached.

G.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: konq_settings.cc.diff
Type: text/x-diff
Size: 1189 bytes
Desc: not available
URL: 

From adawit at kde.org  Wed Jul 31 01:27:50 2002
From: adawit at kde.org (Dawit A.)
Date: Tue, 30 Jul 2002 20:27:50 -0400
Subject: SIGPIPE in kio_http
In-Reply-To: <200207301157.55440.bastian@kde.org>
References: <200207301026.17310.coolo@kde.org> <200207301157.55440.bastian@kde.org>
Message-ID: <200207302027.50479.adawit@kde.org>

On Tuesday 30 July 2002 14:57, Waldo Bastian wrote:
> On Tuesday 30 July 2002 01:26 am, Stephan Kulow wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Hi!
> >
> > Since quite some time I get more "Connection to host is broken"
> > than I used to when I fill forms. It seems to me that the slave requests
> > the server to leave the connection alive, but can't handle the fact that
> > the server closes it after some time. When I need some time to fill out
> > the form, I get the error message and can nothing but go back and
> > resubmit til it works.
> >
> > To me it seems, the http slave should handle the fact that sendBody
> > gets a EPIPE in write in reopening the connection and not simply giving
> > an error to the user. But I have no idea how to fix that best in http.cc
> > or slavebase
>
> Remarkable. We aren't suppoed to use persistent connections at all for
> anything but GET requests.
>
> *check*
>
> Oh.. I see.. the check is done _after_ the request, instead of before the
> request. *duh*
>
> Does this patch help?

Even if it does not, that is the "correct" thing to do anyways. You should go 
ahead and commit it just the same.

Regards,
Dawit A.




From number1 at kde.org  Wed Jul 31 03:24:58 2002
From: number1 at kde.org (Christian A =?iso-8859-1?q?Str=F8mmen?= [Number1/NumeroUno])
Date: Wed, 31 Jul 2002 04:24:58 +0200
Subject: Devices
Message-ID: <200207310424.58445.number1@kde.org>

Two quick questions;

1) How come I can't see devices (floppy, hard disc etc) in the sidebar?
2) Why (when clicked on) do devices open up a new konqueror window instead of 
just using the one they're clicked on in?

I'm trying to make myself a "start dir" for konqueror here, but because of the 
two things above I've been forced to use symlinks as both the device files 
created by konqueror and "Link to location" won't act the way that would seem 
"normal"

-- 
\ Christian A Strømmen /
\ Number1/NumeroUno @ Undernet - Email: number1 at kde.org number1 at realityx.net /
\ Web: www.realityx.net - Cell: +47 911 43 948 /
 Live your life by your dreams,
  not by the limits of reality...



From jowenn at kde.org  Wed Jul 31 09:02:13 2002
From: jowenn at kde.org (Joseph Wenninger)
Date: Wed, 31 Jul 2002 08:02:13 +0000
Subject: Devices
In-Reply-To: <200207310424.58445.number1@kde.org>
References: <200207310424.58445.number1@kde.org>
Message-ID: <200207310802.13449.jowenn@kde.org>

Hi

On Wednesday 31 July 2002 02:24, Christian A Strømmen \[Number1/NumeroUno\] 
wrote:
> Two quick questions;
>
> 1) How come I can't see devices (floppy, hard disc etc) in the sidebar?
> 2) Why (when clicked on) do devices open up a new konqueror window instead
> of just using the one they're cliI'm trying to make myself a "start dir" for 
konqueror here, but because of the 
two things above I've been forced to use symlinks as both the device files 
created by konqueror and "Link to location" won't act the way that would seem 
"normal"
cked on in?
>
> I'm trying to make myself a "start dir" for konqueror here, but because of
> the two things above I've been forced to use symlinks as both the device
> files created by konqueror and "Link to location" won't act the way that
> would seem "normal"

Are you using linux? For all other systems I disabled the devices:/ slave for 
now, since I don't know enough about those. (eg device node names, fstab/mtab 
replacements, ...)

How old is your konqueror ? david fixed a problem with neelessly opening a new 
window when an url get's invoked from the sidebar ?

Do you see those devices when you enter the url in konqy? If not your fs tab 
is wrong, or you are not using linux

Kind regards
Joseph Wenninger




From david at mandrakesoft.com  Wed Jul 31 08:50:32 2002
From: david at mandrakesoft.com (David Faure)
Date: Wed, 31 Jul 2002 09:50:32 +0200
Subject: [Patch] Re: Find File in tree view of Konqueror
In-Reply-To: <200207310041.38622.germain@ebooksfrance.com>
References: <3D447677.7030907@gmx.de> <200207302150.14426.germain@ebooksfrance.com> <200207310041.38622.germain@ebooksfrance.com>
Message-ID: <200207310950.32976.david@mandrakesoft.com>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 31 July 2002 01:41, Germain Garand wrote:
> Le Mardi 30 Juillet 2002 21:50, Germain Garand a écrit :
> 
> > konqueror: Trying to create view for "Konqueror/FindPart"
> > konqueror: KonqFMSettings says: don't embed this servicetype
> >
> > and a dialog :
> > "Can't create the find part, check your installation"
> 
> Ok, it's because of the default LMB action change
> (a.k.a "don't embed anything, Windows users love to edit temp files")
> 
> Patch attached.

Thanks. Please apply.

- -- 
David FAURE, david at mandrakesoft.com, faure at kde.org
http://people.mandrakesoft.com/~david/
Contributing to: http://www.konqueror.org/, http://www.koffice.org/
KOffice 1.2 RC1 is slightly delayed. Stay tuned.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9R5bI72KcVAmwbhARAueBAKCrfWAMI7hDsqIDW074zNSBgCIhVwCfcJl1
qO4IzINkV/IVA3KRsaRWF5U=
=4gVR
-----END PGP SIGNATURE-----




From coolo at kde.org  Wed Jul 31 09:35:15 2002
From: coolo at kde.org (Stephan Kulow)
Date: Wed, 31 Jul 2002 10:35:15 +0200
Subject: SIGPIPE in kio_http
In-Reply-To: <200207302027.50479.adawit@kde.org>
References: <200207301026.17310.coolo@kde.org> <200207301157.55440.bastian@kde.org> <200207302027.50479.adawit@kde.org>
Message-ID: <200207311035.16006.coolo@kde.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 31 July 2002 02:27, Dawit A. wrote:
> On Tuesday 30 July 2002 14:57, Waldo Bastian wrote:
> > On Tuesday 30 July 2002 01:26 am, Stephan Kulow wrote:
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA1
> > >
> > > Hi!
> > >
> > > Since quite some time I get more "Connection to host is broken"
> > > than I used to when I fill forms. It seems to me that the slave
> > > requests the server to leave the connection alive, but can't handle the
> > > fact that the server closes it after some time. When I need some time
> > > to fill out the form, I get the error message and can nothing but go
> > > back and resubmit til it works.
> > >
> > > To me it seems, the http slave should handle the fact that sendBody
> > > gets a EPIPE in write in reopening the connection and not simply giving
> > > an error to the user. But I have no idea how to fix that best in
> > > http.cc or slavebase
> >
> > Remarkable. We aren't suppoed to use persistent connections at all for
> > anything but GET requests.
> >
> > *check*
> >
> > Oh.. I see.. the check is done _after_ the request, instead of before the
> > request. *duh*
> >
> > Does this patch help?
>
> Even if it does not, that is the "correct" thing to do anyways. You should
> go ahead and commit it just the same.
>
But it did, so I commit :)

Greetings, Stephan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE9R6FDwFSBhlBjoJYRAnSaAJwIGFu26sA2juX9c6xrVljZZBg0SwCdEL5c
UihDJ5q2V27pB8Ym2kKbo5M=
=Lk9c
-----END PGP SIGNATURE-----




From lucy-ples at mtu-net.ru  Wed Jul 31 12:37:30 2002
From: lucy-ples at mtu-net.ru (Vadim Plessky)
Date: Wed, 31 Jul 2002 15:37:30 +0400
Subject: Poll on LinuxJournal - voting will end August 12, 2002
Message-ID: <32675.292742397$1028115369@news.gmane.org>


"Linux Journal, ..., is pleased to announce that voting in the 2002 Readers' 
Choice poll is officially underway. Make your vote count as you tell us your 
favorite distribution, development tools, LJ column and much more."

http://www.linuxjournal.com/rc2002/

Voting Topics:
* Favorite Desktop Environment
* Favorite Text Editor (they do not include KWrite or Kate, I voted for Other/ 
KWrite)
* Favorite Word Processor (KWord is here!)
* Favorite Office Suite (KOffice is listed, too)
* Favorite E-mail Client (KMail)
* Favorite Web Browser (Konqueror is here!)
* Favorite Development Tool (KDevelop?)
* Favorite Audio Tool (Noatun is *not* listed!)

As voting will end August 12, 2002 - it's time to fire your favourite browser 
and vote for favourite apps!

Cheers, and sorry for cross-posting and partial off-topic. 
Too many topics, and not everyone subscribed to , 
mailing list where you always on-topic!
-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/




From l.savernik at aon.at  Wed Jul 31 12:50:00 2002
From: l.savernik at aon.at (Leo Savernik)
Date: Wed, 31 Jul 2002 13:50:00 +0200
Subject: [PATCH] for bug#45742: border-color:transparent not honoured
Message-ID: <200207311350.00088.l.savernik@aon.at>

Hello,

May I direct the attention of a core KHTML developer to the patch for bug 
45742? It inhibits the rendering of transparent borders (but reserves the 
space). Please review the patch and commit/reject it.

The cause why I'm explicitly mentioning that patch in kfm-devel and not simply 
waiting for it being discovered in konq-bugs is that it might bitrot away and 
not useable/applicable to the future sources any more.

Patch:
http://lists.kde.org/?l=konq-bugs&m=102760777106032&q=p3

mfg
	Leo




From lucy-ples at mtu-net.ru  Wed Jul 31 13:39:16 2002
From: lucy-ples at mtu-net.ru (Vadim Plessky)
Date: Wed, 31 Jul 2002 16:39:16 +0400
Subject: JavaScript's "Same Origin Policy" (XWT Foundation Security Advisory)
Message-ID: <200207311639.16220.lucy-ples@mtu-net.ru>


I am wondering wether Konqueror is vulnerable to this security flaw?
If not - I think we should announce that Konq is safe against this flaw.

// It seesm Mozilla project was notified about this flaw, and Konqueror's tem 
- not. Not very fair!

***
XWT Foundation Security Advisory

Adam Megacz 
http://www.xwt.org/sop.txt
29-Jul-2002 [Public Release]

______________________________________________________________________________
Abstract

The following exploit constitutes a security flaw in JavaScript's
"Same Origin Policy" (SOP) [1]. Please note that this is *not* the
IE-specific flaw reported in Februrary [2].

The exploit allows an attacker to use any JavaScript-enabled web
browser behind a firewall to retrive content from (HTTP GET) and
interact with (HTTP  POST) any HTTP server behind the
firewall. If the client in use is Microsoft Internet Explorer 5.0+,
Mozilla, or Netscape 6.2+, the attacker can also make calls to SOAP or
XML-RPC web services deployed behind the firewall.

...

01-Jul    Advisory updated; SOAP/XML-RPC also vulnerable if client is
          Microsoft Internet Explorer.

                  Microsoft Notified: secure at microsoft.com
          Apache Foundation Notified: security at apache.org
            Mozilla Project Notified: security at mozilla.org
                       CERT Notified: cert at cert.org


-- 

Vadim Plessky
http://kde2.newmail.ru  (English)
33 Window Decorations and 6 Widget Styles for KDE
http://kde2.newmail.ru/kde_themes.html
KDE mini-Themes
http://kde2.newmail.ru/themes/




From koos.vriezen at xs4all.nl  Wed Jul 31 13:53:39 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Wed, 31 Jul 2002 14:53:39 +0200 (CEST)
Subject: JavaScript's "Same Origin Policy" (XWT Foundation Security
 Advisory)
In-Reply-To: <200207311639.16220.lucy-ples@mtu-net.ru>
References: <200207311639.16220.lucy-ples@mtu-net.ru>
Message-ID: 

On Wed, 31 Jul 2002, Vadim Plessky wrote:

> ______________________________________________________________________________
> Abstract
>
> The following exploit constitutes a security flaw in JavaScript's
> "Same Origin Policy" (SOP) [1]. Please note that this is *not* the
> IE-specific flaw reported in Februrary [2].
>
> The exploit allows an attacker to use any JavaScript-enabled web
> browser behind a firewall to retrive content from (HTTP GET) and
> interact with (HTTP  POST) any HTTP server behind the
> firewall. If the client in use is Microsoft Internet Explorer 5.0+,
> Mozilla, or Netscape 6.2+, the attacker can also make calls to SOAP or
> XML-RPC web services deployed behind the firewall.

Is this really a JS flaw, or is there something with the DNS lookup wrong?
IMHO a DNS server should never respond with a private ip address, after
forwarding a request to a non-private DNS server.
Don't know if I can configure bind that way...

Regards,

Koos Vriezen




From hetz at kde.org  Wed Jul 31 15:10:16 2002
From: hetz at kde.org (Hetz Ben Hamo)
Date: Wed, 31 Jul 2002 17:10:16 +0300
Subject: Tabbed Browsing usability issue
Message-ID: <47475.6071846516$1028124711@news.gmane.org>

Hi People,

I've seen something in tabbed browsing which I think is IMHO a wrong thing...

When clicking "Open a New Tab" to open a URL in a new tabbed inside Konqueror, 
the first part of the data is received (html, jpg, etc) and then the tabbed 
window is open..

Thats wrong. Why? pretty simple. Lets say a user is clicking on a 
"slashdotted" web site - since the site is slashdotted - he won't see any new 
tab until something is received or a time-out occures. Since the end user 
doesn't know about that - he will keep clicking to open a new tab - and by 
the time something will come up - he'll have tons of new tabs in Konqueror.

My suggestion - open a new tab first, and then get the data.

Speaking of tabbed browsing - there's still no keyboard shortcuts to switch 
between the tabbed windows in Konqueror unfortunately, which means - a mouse 
is a must here, and it's not comfortible at all..

Just my $.02

Thanks,
Hetz



From koos.vriezen at xs4all.nl  Wed Jul 31 16:09:29 2002
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Wed, 31 Jul 2002 17:09:29 +0200 (CEST)
Subject: smooth scrolling comment
In-Reply-To: 
References: 
Message-ID: 

On Tue, 30 Jul 2002, Koos Vriezen wrote:

> On Tue, 30 Jul 2002, Hetz Ben Hamo wrote:
>
> > 1. In order to stop the scrolling - only the up key stops. Why not any key?
> > I'm pretty sure end user would be pissed to find that they can't stop smooth
> > scrolling unless they find that arrow up stops it.
>
> That wouldn't be to difficult to implement. Personaly I like the
> combination of auto scrolling and PgUp/PgDown to quickly scan news sites.
> But for other, non-scrolling keys, yes why not.
>
> > 2. Is there going to be also a smooth scrolling upwards and sideways please?
> > it will help a lot with large tables..
>
> Scrolling up, wouldn't be hard to implement. Scrolling right/left needs
> imo some changes in paintBuffer, an extra vertical or rotation by
> drawPixmap. However the usefulness, compared to scrolling down, is a lot
> less.

Well for completing this auto scroller thing, here a patch that does the
above.
I've added a 10 by visualHeight vertical paintBuffer for smooth horizontal
scrolling. Besides that, the patch is quite boring.

Regards,

Koos Vriezen
-------------- next part --------------
Index: khtmlview.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/khtmlview.cpp,v
retrieving revision 1.478
diff -u -3 -p -r1.478 khtmlview.cpp
--- khtmlview.cpp	2002/07/30 15:36:48	1.478
+++ khtmlview.cpp	2002/07/31 15:10:24
@@ -60,6 +60,10 @@
 
 #define PAINT_BUFFER_HEIGHT 128
 
+#define NEWSCROLLTIMER(x)                                \
+{   kdDebug() << "timer event killing timer" << endl;    \
+    killTimer(d->scrollTimerId); d->scrollTimerId = (x); }
+
 using namespace DOM;
 using namespace khtml;
 class KHTMLToolTip;
@@ -94,6 +98,7 @@ public:
         reset();
         tp=0;
         paintBuffer=0;
+        vertPaintBuffer=0;
         formCompletions=0;
         prevScrollbarVisible = true;
 	timerId = 0;
@@ -107,6 +112,7 @@ public:
         delete formCompletions;
         delete tp; tp = 0;
         delete paintBuffer; paintBuffer =0;
+        delete vertPaintBuffer;
         if (underMouse)
 	    underMouse->deref();
 	delete tooltip;
@@ -149,6 +155,7 @@ public:
 
     QPainter *tp;
     QPixmap  *paintBuffer;
+    QPixmap  *vertPaintBuffer;
     NodeImpl *underMouse;
 
     // the node that was selected when enter was pressed
@@ -179,6 +186,7 @@ public:
     int scrollTimerId;
     int scrollTiming;
     int scrollBy;
+    enum { ScrollLeft, ScrollRight, ScrollUp, ScrollDown } scrollDirection;
     bool complete;
     bool firstRelayout;
     bool layoutSchedulingEnabled;
@@ -249,6 +257,8 @@ KHTMLView::~KHTMLView()
 void KHTMLView::init()
 {
     if(!d->paintBuffer) d->paintBuffer = new QPixmap(PAINT_BUFFER_HEIGHT, PAINT_BUFFER_HEIGHT);
+    if(!d->vertPaintBuffer) 
+        d->vertPaintBuffer = new QPixmap(10, PAINT_BUFFER_HEIGHT);
     if(!d->tp) d->tp = new QPainter();
 
     setFocusPolicy(QWidget::StrongFocus);
@@ -327,28 +337,40 @@ void KHTMLView::drawContents( QPainter *
     if(!m_part->xmlDocImpl() || !m_part->xmlDocImpl()->renderer()) {
         p->fillRect(ex, ey, ew, eh, palette().normal().brush(QColorGroup::Base));
         return;
+    }
+    if (eh > PAINT_BUFFER_HEIGHT && ew <= 10) {
+        if ( d->vertPaintBuffer->height() < visibleHeight() )
+            d->vertPaintBuffer->resize(10, visibleHeight());
+        d->tp->begin(d->vertPaintBuffer);
+        d->tp->translate(-ex, -ey);
+        d->tp->fillRect(ex, ey, ew, eh, palette().normal().brush(QColorGroup::Base));
+        m_part->xmlDocImpl()->renderer()->print(d->tp, ex, ey, ew, eh, 0, 0);
+        d->tp->end();
+        p->drawPixmap(ex, ey, *d->vertPaintBuffer, 0, 0, ew, eh);
     }
-    if ( d->paintBuffer->width() < visibleWidth() )
-        d->paintBuffer->resize(visibleWidth(),PAINT_BUFFER_HEIGHT);
+    else {
+        if ( d->paintBuffer->width() < visibleWidth() )
+            d->paintBuffer->resize(visibleWidth(),PAINT_BUFFER_HEIGHT);
 
-    int py=0;
-    while (py < eh) {
-        int ph = eh-py < PAINT_BUFFER_HEIGHT ? eh-py : PAINT_BUFFER_HEIGHT;
-        d->tp->begin(d->paintBuffer);
-        d->tp->translate(-ex, -ey-py);
-        d->tp->fillRect(ex, ey+py, ew, ph, palette().normal().brush(QColorGroup::Base));
-        m_part->xmlDocImpl()->renderer()->print(d->tp, ex, ey+py, ew, ph, 0, 0);
+        int py=0;
+        while (py < eh) {
+            int ph = eh-py < PAINT_BUFFER_HEIGHT ? eh-py : PAINT_BUFFER_HEIGHT;
+            d->tp->begin(d->paintBuffer);
+            d->tp->translate(-ex, -ey-py);
+            d->tp->fillRect(ex, ey+py, ew, ph, palette().normal().brush(QColorGroup::Base));
+            m_part->xmlDocImpl()->renderer()->print(d->tp, ex, ey+py, ew, ph, 0, 0);
 #ifdef BOX_DEBUG
-        if (m_part->xmlDocImpl()->focusNode())
-        {
-            d->tp->setBrush(Qt::NoBrush);
-            d->tp->drawRect(m_part->xmlDocImpl()->focusNode()->getRect());
-        }
+            if (m_part->xmlDocImpl()->focusNode())
+            {
+                d->tp->setBrush(Qt::NoBrush);
+                d->tp->drawRect(m_part->xmlDocImpl()->focusNode()->getRect());
+            }
 #endif
-        d->tp->end();
+            d->tp->end();
 
-        p->drawPixmap(ex, ey+py, *d->paintBuffer, 0, 0, ew, ph);
-        py += PAINT_BUFFER_HEIGHT;
+            p->drawPixmap(ex, ey+py, *d->paintBuffer, 0, 0, ew, ph);
+            py += PAINT_BUFFER_HEIGHT;
+        }
     }
     khtml::DrawContentsEvent event( p, ex, ey, ew, eh );
     QApplication::sendEvent( m_part, &event );
@@ -623,7 +645,9 @@ void KHTMLView::keyPressEvent( QKeyEvent
     }
 
     int offs = (clipper()->height() < 30) ? clipper()->height() : 30;
-    static int timings [][2] = { {100,1}, {50,1}, {30,1}, {20,1}, {20,2}, {20,4}, {20,6}, {0,0} };
+    static const struct { int msec, pixels; } timings [] = { 
+        {100,1}, {50,1}, {30,1}, {20,1}, {20,2}, {20,4}, {20,6}, {0,0} 
+    };
     if (_ke->state() & Qt::ShiftButton)
       switch(_ke->key())
         {
@@ -636,31 +660,89 @@ void KHTMLView::keyPressEvent( QKeyEvent
 
         case Key_Down:
         case Key_J:
-            if (!d->scrollTimerId) {
+            if (!d->scrollTimerId || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollLeft || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollRight) {
                 d->scrollTiming = 2;
-                d->scrollBy = timings[d->scrollTiming][1];
+                d->scrollBy = timings[d->scrollTiming].pixels;
+                d->scrollDirection = KHTMLViewPrivate::ScrollDown;
                 scrollBy( 0, d->scrollBy );
-                d->scrollTimerId = startTimer(timings[d->scrollTiming][0]);
-            } else if (timings[d->scrollTiming+1][0]) {
-                d->scrollBy = timings[++d->scrollTiming][1];
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollDown && 
+                    timings[d->scrollTiming+1].msec) {
+                d->scrollBy = timings[++d->scrollTiming].pixels;
                 scrollBy( 0, d->scrollBy );
-                killTimer(d->scrollTimerId);
-                d->scrollTimerId = startTimer(timings[d->scrollTiming][0]);
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollUp) {
+                if (d->scrollTiming)
+                    d->scrollBy = timings[--d->scrollTiming].pixels;
+                else
+                    d->scrollDirection = KHTMLViewPrivate::ScrollDown;
             }
+            NEWSCROLLTIMER(startTimer(timings[d->scrollTiming].msec));
             break;
 
         case Key_Up:
         case Key_K:
-            if (d->scrollTimerId)
-                if (d->scrollTiming) {
-                    d->scrollBy = timings[--d->scrollTiming][1];
-                    killTimer(d->scrollTimerId);
-                    d->scrollTimerId = startTimer(timings[d->scrollTiming][0]);
-                } else {
-                    killTimer(d->scrollTimerId);
-                    d->scrollTimerId = 0;
-                }
+            if (!d->scrollTimerId || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollLeft || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollRight) {
+                d->scrollTiming = 2;
+                d->scrollBy = timings[d->scrollTiming].pixels;
+                d->scrollDirection = KHTMLViewPrivate::ScrollUp;
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollUp && 
+                    timings[d->scrollTiming+1].msec) {
+                d->scrollBy = timings[++d->scrollTiming].pixels;
+                scrollBy( 0, -d->scrollBy );
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollDown) {
+                if (d->scrollTiming)
+                    d->scrollBy = timings[--d->scrollTiming].pixels;
+                else
+                    d->scrollDirection = KHTMLViewPrivate::ScrollUp;
+            }
+            NEWSCROLLTIMER(startTimer(timings[d->scrollTiming].msec));
+            break;
+
+        case Key_Left:
+        case Key_H:
+            if (!d->scrollTimerId || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollUp || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollDown) {
+                d->scrollTiming = 2;
+                d->scrollBy = timings[d->scrollTiming].pixels;
+                d->scrollDirection = KHTMLViewPrivate::ScrollLeft;
+                scrollBy( -d->scrollBy, 0 );
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollLeft && 
+                    timings[d->scrollTiming+1].msec) {
+                d->scrollBy = timings[++d->scrollTiming].pixels;
+                scrollBy( -d->scrollBy, 0 );
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollRight) {
+                if (d->scrollTiming)
+                    d->scrollBy = timings[--d->scrollTiming].pixels;
+                else
+                    d->scrollDirection = KHTMLViewPrivate::ScrollLeft;
+            }
+            NEWSCROLLTIMER(startTimer(timings[d->scrollTiming].msec));
+            break;
 
+        case Key_Right:
+        case Key_L:
+            if (!d->scrollTimerId || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollUp || 
+                d->scrollDirection == KHTMLViewPrivate::ScrollDown) {
+                d->scrollTiming = 2;
+                d->scrollBy = timings[d->scrollTiming].pixels;
+                d->scrollDirection = KHTMLViewPrivate::ScrollRight;
+                scrollBy( d->scrollBy, 0 );
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollRight && 
+                    timings[d->scrollTiming+1].msec) {
+                d->scrollBy = timings[++d->scrollTiming].pixels;
+                scrollBy( d->scrollBy, 0 );
+            } else if (d->scrollDirection == KHTMLViewPrivate::ScrollLeft) {
+                if (d->scrollTiming)
+                    d->scrollBy = timings[--d->scrollTiming].pixels;
+                else
+                    d->scrollDirection = KHTMLViewPrivate::ScrollRight;
+            }
+            NEWSCROLLTIMER(startTimer(timings[d->scrollTiming].msec));
             break;
         }
     else
@@ -692,10 +774,8 @@ void KHTMLView::keyPressEvent( QKeyEvent
             if ( d->vmode == QScrollView::AlwaysOff )
                 _ke->accept();
             else {
-                if (d->scrollTimerId) {
-                    killTimer(d->scrollTimerId);
-                    d->scrollTimerId = 0;
-                }
+                if (d->scrollTimerId)
+                    NEWSCROLLTIMER(0);
                 scrollBy( 0, -10 );
             }
             break;
@@ -710,15 +790,21 @@ void KHTMLView::keyPressEvent( QKeyEvent
         case Key_L:
             if ( d->hmode == QScrollView::AlwaysOff )
                 _ke->accept();
-            else
+            else {
+                if (d->scrollTimerId)
+                    NEWSCROLLTIMER(0);
                 scrollBy( 10, 0 );
+            }
             break;
         case Key_Left:
         case Key_H:
             if ( d->hmode == QScrollView::AlwaysOff )
                 _ke->accept();
-            else
+            else {
+                if (d->scrollTimerId)
+                    NEWSCROLLTIMER(0);
                 scrollBy( -10, 0 );
+            }
             break;
         case Key_Enter:
         case Key_Return:
@@ -744,7 +830,15 @@ void KHTMLView::keyPressEvent( QKeyEvent
             else
                 setContentsPos( 0, contentsHeight() - visibleHeight() );
             break;
+        case Key_Shift:
+            // what are you doing here?
+	    _ke->ignore();
+            return;
         default:
+            if (d->scrollTimerId) {
+                killTimer(d->scrollTimerId);
+                d->scrollTimerId = 0;
+            }
 	    _ke->ignore();
             return;
         }
@@ -1512,12 +1606,32 @@ void KHTMLView::timerEvent ( QTimerEvent
 {
 //    kdDebug() << "timer event " << e->timerId() << endl;
     if (e->timerId() == d->scrollTimerId) {
-        if (contentsY() + visibleHeight () >= contentsHeight()) {
-            kdDebug() << "timer event killing timer" << endl;
-            killTimer(d->scrollTimerId);
-            d->scrollTimerId = 0;
-        } else
-            scrollBy( 0, d->scrollBy );
+        switch (d->scrollDirection) {
+            case KHTMLViewPrivate::ScrollDown:
+                if (contentsY() + visibleHeight () >= contentsHeight())
+                    NEWSCROLLTIMER(0)
+                else
+                    scrollBy( 0, d->scrollBy );
+                break;
+            case KHTMLViewPrivate::ScrollUp:
+                if (contentsY() <= 0)
+                    NEWSCROLLTIMER(0)
+                else
+                    scrollBy( 0, -d->scrollBy );
+                break;
+            case KHTMLViewPrivate::ScrollRight:
+                if (contentsX() + visibleWidth () >= contentsWidth())
+                    NEWSCROLLTIMER(0)
+                else
+                    scrollBy( d->scrollBy, 0 );
+                break;
+            case KHTMLViewPrivate::ScrollLeft:
+                if (contentsX() <= 0)
+                    NEWSCROLLTIMER(0)
+                else
+                    scrollBy( -d->scrollBy, 0 );
+                break;
+        }
         return;
     }
     if (e->timerId()==d->timerId)

From germain at ebooksfrance.com  Wed Jul 31 17:36:18 2002
From: germain at ebooksfrance.com (Germain Garand)
Date: Wed, 31 Jul 2002 17:36:18 +0100
Subject: action for LMB click in Konqueror
In-Reply-To: <200207292232.34367.germain@ebooksfrance.com>
References: <3D44752F.6070307@gmx.de> <200207290928.20290.david@mandrakesoft.com> <200207292232.34367.germain@ebooksfrance.com>
Message-ID: <200207311736.18931.germain@ebooksfrance.com>

Le Lundi 29 Juillet 2002 22:32, Germain Garand a écrit :
> Le Lundi 29 Juillet 2002 08:28, David Faure a écrit :
> > > It seems that if you first mark a mimetype to be externally or
> > > internally viewed, apply the change, and then later switch it to "use
> > > settings for XXX group", then it doesn't switch and just uses whatever
> > > you choose before...
> >
> > I forgot to update the kcontrol file associations module after changing
> > the defaults. Thanks for noticing, fixed (please re-test).
>
> I've just rebuilt kcontrol but as far as I can see, the "use settings for
> XXX group"  checkbox still seems to do nothing.

Just to close this one.
I had a different KDEHOME than the one finally elected by KDE; it seems it 
messed '.desktop' file monitoring. Hence the bad mimetype refreshing.

Cheers,
G.




