From john at geola.co.uk  Tue Feb  1 10:41:26 2005
From: john at geola.co.uk (John Tapsell)
Date: Tue, 1 Feb 2005 10:41:26 +0000
Subject: Getting the document from the cache
In-Reply-To: <20050131225227.A7A0B6B89B@smtp.zappmobile.ro>
References: <200501291106.43622.amantia@kde.org>
	<200501312243.30068.john@geola.co.uk>
	<20050131225227.A7A0B6B89B@smtp.zappmobile.ro>
Message-ID: <200502011041.26671.john@geola.co.uk>

It looks good.
One question though - what if the file is an XML file and not an html file?
I've never been clear on whether it's still rendered in KHTMLPart - I think it 
is.  I guess encoding()  will still be correct, right?

JohnFlux


On Monday 31 January 2005 22:56, Andras Mantia wrote:
> John Tapsell wrote:
> > What did you use in the end?
>
> As we discussed with David, returning a QString and using the encoding of
> the rendered document. The conversion of QDataStream->QString is with the
> help of a QTextStream and QByteArray instead of a temp file. But here is
> the diff from kde-cvs:
>
> +QString KHTMLPart::documentSource() const
> +{
> +  QString sourceStr;
> +  if ( !( m_url.isLocalFile() ) &&
> KHTMLPageCache::self()->isComplete( d->m_cacheId ) )
> +  {
> +     QByteArray sourceArray;
> +     QDataStream dataStream( sourceArray, IO_WriteOnly );
> +     KHTMLPageCache::self()->saveData( d->m_cacheId, &dataStream );
> +     QTextStream stream( sourceArray, IO_ReadOnly );
> +     stream.setCodec( QTextCodec::codecForName( encoding().latin1() ) );
> +     sourceStr = stream.read();
> +  } else
> +  {
> +    QString tmpFile;
> +    if( KIO::NetAccess::download( m_url, tmpFile, NULL ) )
> +    {
> +      QFile f( tmpFile );
> +      if ( f.open( IO_ReadOnly ) )
> +      {
> +        QTextStream stream( &f );
> +        stream.setCodec( QTextCodec::codecForName( encoding().latin1() )
> ); +        sourceStr = stream.read();
> +        f.close();
> +      }
> +      KIO::NetAccess::removeTempFile( tmpFile );
> +    }
> +  }
> +
> +  return sourceStr;
> +}
>
> Andras



From amantia at kde.org  Tue Feb  1 11:06:37 2005
From: amantia at kde.org (Andras Mantia)
Date: Tue, 01 Feb 2005 13:06:37 +0200
Subject: Getting the document from the cache
References: <200501291106.43622.amantia@kde.org>
	<200501312243.30068.john@geola.co.uk>
	<20050131225227.A7A0B6B89B@smtp.zappmobile.ro>
	<200502011041.26671.john@geola.co.uk>
Message-ID: <20050201110240.4887E6B908@smtp.zappmobile.ro>

John Tapsell wrote:

> It looks good.
> One question though - what if the file is an XML file and not an html
> file? I've never been clear on whether it's still rendered in KHTMLPart -
> I think it is.  I guess encoding()  will still be correct, right?
> 

I don't know, but I hope so. ;-)

Andras

-- 
Quanta Plus developer - http://quanta.sourceforge.net
K Desktop Environment - http://www.kde.org




From geosp at otenet.gr  Wed Feb  2 10:45:19 2005
From: geosp at otenet.gr (Spiros Georgaras)
Date: Wed, 2 Feb 2005 12:45:19 +0200
Subject: kio_mhtml: Add menu entries
Message-ID: <200502021245.19549.geosp@otenet.gr>

Hi all

The latest changes I have committed include code to display a <table> with the 
message info (From, To etc) and a <table> to display the attachments (for EML 
files only).

It would be nice to have a way to disable this. I was thinking something like 
two menu entries under View: "Show message info" and "Show attachments".

Is it possible to add such menu entries to konqueror from an ioslave?

Regards
 Spiros



From frans.englich at telia.com  Thu Feb  3 05:09:13 2005
From: frans.englich at telia.com (Frans Englich)
Date: Thu, 3 Feb 2005 05:09:13 +0000
Subject: CDATA in XHTML doesn't work
Message-ID: <200502030509.13446.frans.englich@telia.com>


Hello all,

For the attached test case I expect the text "This should be rendered.", to be 
shown. That is what Firefox 1.0 do. In Konqueror, from recent CVS, the text 
is not shown.

A bug? If so, I'll file a bug report.


Cheers,

		Frans

-------------- next part --------------
A non-text attachment was scrubbed...
Name: cdata.xhtml
Type: application/xhtml+xml
Size: 368 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050203/7e3d2189/attachment.xhtml>

From coolo at kde.org  Thu Feb  3 08:47:34 2005
From: coolo at kde.org (Stephan Kulow)
Date: Thu, 3 Feb 2005 09:47:34 +0100
Subject: CDATA in XHTML doesn't work
In-Reply-To: <200502030509.13446.frans.englich@telia.com>
References: <200502030509.13446.frans.englich@telia.com>
Message-ID: <200502030947.36271.coolo@kde.org>

Am Thursday 03 February 2005 06:09 schrieb Frans Englich:
> 
> Hello all,
> 
> For the attached test case I expect the text "This should be rendered.", to be 
> shown. That is what Firefox 1.0 do. In Konqueror, from recent CVS, the text 
> is not shown.
> 
> A bug? If so, I'll file a bug report.
Just make sure you looked for duplicates before

Greetings, Stephan



From ismail at kde.org.tr  Thu Feb  3 16:07:48 2005
From: ismail at kde.org.tr (Ismail Donmez)
Date: Thu, 3 Feb 2005 18:07:48 +0200
Subject: High CPU usage at www.iht.com
Message-ID: <200502031807.48768.ismail@kde.org.tr>

Hi,

When visiting www.iht.com with konqueror from cvs head I see cpu usage go up 
to 80% and it goes down to 60% or so and go in between those values. Here is 
the gdb backtrace I get with CTRL-C

(gdb) bt
#0  DOM::NodeImpl::focused (this=0x8649c88) at dom_nodeimpl.h:186
#1  0xb5bdea0a in khtml::CSSStyleSelector::checkOneSelector (this=0x8649c88, 
sel=0x852d338, e=0x860d0a0)
    at /opt/development/kde/kdelibs/khtml/css/cssstyleselector.cpp:1311
#2  0xb5bdcc4c in khtml::CSSStyleSelector::checkSelector (this=0x8649c88, 
selIndex=120, e=0x860d0a0)
    at /opt/development/kde/kdelibs/khtml/css/cssstyleselector.cpp:834
#3  0xb5bdb96f in khtml::CSSStyleSelector::styleForElement (this=0x8649c88, 
e=0x860d0a0)
    at /opt/development/kde/kdelibs/khtml/css/cssstyleselector.cpp:415
#4  0xb5b1136c in DOM::ElementImpl::recalcStyle (this=0x860d0a0, 
change=DOM::NodeImpl::Force)
    at /opt/development/kde/kdelibs/khtml/xml/dom_elementimpl.cpp:547
#5  0xb5b34c69 in DOM::HTMLElementImpl::recalcStyle (this=0x860d0a0, 
ch=DOM::NodeImpl::Force)
    at /opt/development/kde/kdelibs/khtml/html/html_elementimpl.cpp:262
#6  0xb5b1151e in DOM::ElementImpl::recalcStyle (this=0x86168f8, 
change=DOM::NodeImpl::Force)
    at /opt/development/kde/kdelibs/khtml/xml/dom_elementimpl.cpp:582
#7  0xb5b34c69 in DOM::HTMLElementImpl::recalcStyle (this=0x86168f8, 
ch=DOM::NodeImpl::Force)
    at /opt/development/kde/kdelibs/khtml/html/html_elementimpl.cpp:262
#8  0xb5b1151e in DOM::ElementImpl::recalcStyle (this=0x8616858, 
change=DOM::NodeImpl::Force)
    at /opt/development/kde/kdelibs/khtml/xml/dom_elementimpl.cpp:582
#9  0xb5b34c69 in DOM::HTMLElementImpl::recalcStyle (this=0x8616858, 
ch=DOM::NodeImpl::Force)
    at /opt/development/kde/kdelibs/khtml/html/html_elementimpl.cpp:262
#10 0xb5b1151e in DOM::ElementImpl::recalcStyle (this=0x8579970, 
change=DOM::NodeImpl::Force)
    at /opt/development/kde/kdelibs/khtml/xml/dom_elementimpl.cpp:582
#11 0xb5b34c69 in DOM::HTMLElementImpl::recalcStyle (this=0x8579970, 
ch=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/html/html_elementimpl.cpp:262
#12 0xb5b1151e in DOM::ElementImpl::recalcStyle (this=0x8591238, 
change=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/xml/dom_elementimpl.cpp:582
#13 0xb5b34c69 in DOM::HTMLElementImpl::recalcStyle (this=0x8591238, 
ch=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/html/html_elementimpl.cpp:262
#14 0xb5b1151e in DOM::ElementImpl::recalcStyle (this=0x8641db0, 
change=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/xml/dom_elementimpl.cpp:582
#15 0xb5b34c69 in DOM::HTMLElementImpl::recalcStyle (this=0x8641db0, 
ch=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/html/html_elementimpl.cpp:262
#16 0xb5b1151e in DOM::ElementImpl::recalcStyle (this=0x859aa80, 
change=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/xml/dom_elementimpl.cpp:582
#17 0xb5b34c69 in DOM::HTMLElementImpl::recalcStyle (this=0x859aa80, 
ch=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/html/html_elementimpl.cpp:262
#18 0xb5afc6e7 in DOM::DocumentImpl::recalcStyle (this=0x869ee78, 
change=DOM::NodeImpl::NoChange)
    at /opt/development/kde/kdelibs/khtml/xml/dom_docimpl.cpp:997
#19 0xb5afc7d3 in DOM::DocumentImpl::updateRendering (this=0x869ee78) 
at /opt/development/kde/kdelibs/khtml/xml/dom_docimpl.cpp:1026
#20 0xb5afc860 in DOM::DocumentImpl::updateDocumentsRendering () 
at /opt/development/kde/kdelibs/khtml/xml/dom_docimpl.cpp:1040
#21 0xb5c52fa5 in KJS::Window::afterScriptExecution (this=0x857fa60) 
at /opt/development/kde/kdelibs/khtml/ecma/kjs_window.cpp:990
#22 0xb5c6b6b5 in KJS::KJSProxyImpl::evaluate (this=0x85092f8, filename=
      {static null = {static null = <same as static member of an already seen 
type>, d = 0x8057388, static shared_null = 0x8057388}, d = 0x869f7a8, static 
shared_null = 0x8057388}, baseLine=1, str=@0x85b9f5c, n=@0xbfffec70, 
completion=0xbfffec00)
    at /opt/development/kde/kdelibs/khtml/ecma/kjs_proxy.cpp:166
#23 0xb5ab34d8 in KHTMLPart::executeScript (this=0x8475f60, n=@0xbfffec70, 
script=@0x85b9f5c)
    at /opt/development/kde/kdelibs/khtml/khtml_part.cpp:1161
#24 0xb5c5b812 in KJS::ScheduledAction::execute (this=0x85b9f50, 
window=0x857fa60)
    at /opt/development/kde/kdelibs/khtml/ecma/kjs_window.cpp:1784
#25 0xb5c5c70d in KJS::WindowQObject::timerEvent (this=0x86abdb8) 
at /opt/development/kde/kdelibs/khtml/ecma/kjs_window.cpp:1914
#26 0xb751b59e in QObject::event (this=0x86abdb8, e=0xbfffef40) at 
kernel/qobject.cpp:741
#27 0xb74b93f9 in QApplication::internalNotify (this=0xbffff350, 
receiver=0x86abdb8, e=0xbfffef40) at kernel/qapplication.cpp:2635
#28 0xb74b88bd in QApplication::notify (this=0xbffff350, receiver=0x86abdb8, 
e=0xbfffef40) at kernel/qapplication.cpp:2358
#29 0xb7abc50f in KApplication::notify (this=0xbffff350, receiver=0x86abdb8, 
event=0xbfffef40)
---Type <return> to continue, or q <return> to quit---
    at /opt/development/kde/kdelibs/kdecore/kapplication.cpp:549
#30 0xb7fcd57d in QApplication::sendEvent (receiver=0x86abdb8, 
event=0xbfffef40) at qapplication.h:491
#31 0xb74a7029 in QEventLoop::activateTimers (this=0x81881f0) at 
kernel/qeventloop_unix.cpp:556
#32 0xb745f969 in QEventLoop::processEvents (this=0x81881f0, flags=4) at 
kernel/qeventloop_x11.cpp:389
#33 0xb74ce3cc in QEventLoop::enterLoop (this=0x81881f0) at 
kernel/qeventloop.cpp:198
#34 0xb74ce2ea in QEventLoop::exec (this=0x81881f0) at 
kernel/qeventloop.cpp:145
#35 0xb74b9579 in QApplication::exec (this=0xbffff350) at 
kernel/qapplication.cpp:2758
#36 0xb607584d in kdemain (argc=2, argv=0x816b518) 
at /opt/development/kde/kdebase/konqueror/konq_main.cc:206
#37 0xb7222969 in kdeinitmain (argc=2, argv=0x816b518) 
at ./konqueror/kdeinit_konqueror.la.cpp:2
#38 0x0804e2da in launch (argc=2, _name=0x816b96c "konqueror", args=0x816b980 
"\001", cwd=0x0, envc=1, envs=0x816b991 "",
    reset_env=false, tty=0x0, avoid_loops=false, startup_id_str=0x8052ca7 "0") 
at /opt/development/kde/kdelibs/kinit/kinit.cpp:623
#39 0x0804f5e9 in handle_launcher_request (sock=8) 
at /opt/development/kde/kdelibs/kinit/kinit.cpp:1187
#40 0x0804fcb4 in handle_requests (waitForPid=0) 
at /opt/development/kde/kdelibs/kinit/kinit.cpp:1388
#41 0x08051178 in main (argc=2, argv=0xbffff9d4, envp=0xbffff9e0) 
at /opt/development/kde/kdelibs/kinit/kinit.cpp:1839



From mikmach at wp.pl  Thu Feb  3 16:48:42 2005
From: mikmach at wp.pl (Mikolaj Machowski)
Date: Thu, 3 Feb 2005 17:48:42 +0100
Subject: [Bug 95034] TD { min-width } style extend fixed table size.
In-Reply-To: <20050203114031.14379.qmail@ktown.kde.org>
References: <20050203114031.14379.qmail@ktown.kde.org>
Message-ID: <200502031748.42641.mikmach@wp.pl>

Forwarding and attaching patch from Marek Lotke:
>
> ------- Additional Comments From lollul wp pl  2005-02-03 12:40 -------
> Attached a patch for RenderBlock::calcMinMaxWidth that disables
> "maximizing" table cells and fixes problems seen in www.wp.pl. Of course
> it is NOT the right solution. I just can't figure out a better way. I
> hope some dev would take look at it and fix it properly.

Note: http://www.wp.pl is sending soup to Konqueror but even when
changing identification search element is moved to the right in contrary
to CSS2.1

m.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_block.diff
Type: text/x-diff
Size: 553 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050203/02777a89/attachment.diff>

From frans.englich at telia.com  Thu Feb  3 20:10:15 2005
From: frans.englich at telia.com (Frans Englich)
Date: Thu, 3 Feb 2005 20:10:15 +0000
Subject: CDATA in XHTML doesn't work
In-Reply-To: <200502030947.36271.coolo@kde.org>
References: <200502030509.13446.frans.englich@telia.com>
	<200502030947.36271.coolo@kde.org>
Message-ID: <200502032010.16134.frans.englich@telia.com>

On Thursday 03 February 2005 08:47, Stephan Kulow wrote:
> Am Thursday 03 February 2005 06:09 schrieb Frans Englich:
> > Hello all,
> >
> > For the attached test case I expect the text "This should be rendered.",
> > to be shown. That is what Firefox 1.0 do. In Konqueror, from recent CVS,
> > the text is not shown.
> >
> > A bug? If so, I'll file a bug report.
>
> Just make sure you looked for duplicates before

Right, already reported 2004/05: #82171.


Cheers,

		Frans




From knutmj at online.no  Fri Feb  4 15:44:18 2005
From: knutmj at online.no (Knut Morten Johansson)
Date: Fri, 4 Feb 2005 16:44:18 +0100
Subject: Konquerror doesn't compile
Message-ID: <200502041644.18388.knutmj@online.no>

Hi
Konquerror doesn't compile, todays CVS using automake. Se below.

Failing in konq_combo.cc , guess it has something to do with this commit:
Revision 1.52 Tue Feb 1 by binner: Show favicons and titles of websites in 
location bar autocomplete
FEATURE: 77561

Regards
Knut

konq_combo.cc: In constructor `KonqCombo::KonqCombo(QWidget*, const char*)':
konq_combo.cc:117: error: 'class KonqComboLineEdit' has no member named 
'setCompletionBox'
konq_combo.cc: In member function `virtual void 
KonqComboLineEdit::setCompletedItems(const QStringList&)':
konq_combo.cc:772: error: `setCompletionBox' undeclared (first use this 
function)
konq_combo.cc:772: error: (Each undeclared identifier is reported only once 
for each function it appears in.)
konq_combo.cc:793: error: `autoSuggest' undeclared (first use this function)
make[3]: *** [konq_combo.lo] Error 1



From ismail at kde.org.tr  Fri Feb  4 16:27:29 2005
From: ismail at kde.org.tr (Ismail Donmez)
Date: Fri, 4 Feb 2005 18:27:29 +0200
Subject: Konquerror doesn't compile
In-Reply-To: <200502041644.18388.knutmj@online.no>
References: <200502041644.18388.knutmj@online.no>
Message-ID: <200502041827.29358.ismail@kde.org.tr>

Hi,
On Friday 04 February 2005 17:44, Knut Morten Johansson wrote:
> konq_combo.cc: In constructor `KonqCombo::KonqCombo(QWidget*, const
> char*)': konq_combo.cc:117: error: 'class KonqComboLineEdit' has no member
> named 'setCompletionBox'
> konq_combo.cc: In member function `virtual void
> KonqComboLineEdit::setCompletedItems(const QStringList&)':
> konq_combo.cc:772: error: `setCompletionBox' undeclared (first use this
> function)
> konq_combo.cc:772: error: (Each undeclared identifier is reported only once
> for each function it appears in.)
> konq_combo.cc:793: error: `autoSuggest' undeclared (first use this
> function) make[3]: *** [konq_combo.lo] Error 1

Update kdelibs/kdeui .

ismail



From aseigo at kde.org  Fri Feb  4 17:09:47 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Fri, 04 Feb 2005 10:09:47 -0700
Subject: Konquerror doesn't compile
In-Reply-To: <200502041644.18388.knutmj@online.no>
References: <200502041644.18388.knutmj@online.no>
Message-ID: <200502041010.05442.aseigo@kde.org>

On Friday 04 February 2005 08:44, Knut Morten Johansson wrote:
> Konquerror doesn't compile, todays CVS using automake. Se below.

update kdelibs/kdeui ... there were changes made there as well ...

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/178a314f/attachment.sig>

From aseigo at kde.org  Fri Feb  4 18:15:00 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Fri, 04 Feb 2005 11:15:00 -0700
Subject: toolbars removus
Message-ID: <200502041115.13447.aseigo@kde.org>

happy friday everyone...

for 3.4, can the following icons be removed from konqueror's default toolbars:

File Management: cut, copy, paste, print, zooming
Web Browsing: cut, copy, paste, find, security

this is based on a study i did last year on usage of konqueror toolbars in web 
browsing mode, general usability sense and the desire to fewer of these sorts 
of articles:

http://www.ofb.biz/modules.php?name=News&file=article&sid=351&mode=&order=0&thold=0

i am not a konqueror maintainer and so don't feel i have the right to simply 
wade in and make these sorts of changes, which is why i'm writing here first. 
we can do this for 3.4 and come out looking that much better, and being that 
much nicer for our users.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/8612ff7f/attachment.sig>

From staikos at kde.org  Fri Feb  4 18:49:13 2005
From: staikos at kde.org (George Staikos)
Date: Fri, 4 Feb 2005 13:49:13 -0500
Subject: toolbars removus
In-Reply-To: <200502041115.13447.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
Message-ID: <200502041349.13217.staikos@kde.org>

On Friday 04 February 2005 13:15, Aaron J. Seigo wrote:
> happy friday everyone...
>
> for 3.4, can the following icons be removed from konqueror's default
> toolbars:
>
> File Management: cut, copy, paste, print, zooming
> Web Browsing: cut, copy, paste, find
[...]
> security 

  For the (n+2) time, no to that one.  For KDE 4 I will fully test all the 
scenarios and we can consider the concept of looking in the toolbar for 
security state to be obsolete.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From l.savernik at aon.at  Fri Feb  4 19:07:13 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 4 Feb 2005 20:07:13 +0100
Subject: toolbars removus
In-Reply-To: <200502041115.13447.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
Message-ID: <200502042007.21330.l.savernik@aon.at>

Am Freitag, 4. Februar 2005 19:15 schrieb Aaron J. Seigo:
> happy friday everyone...
>
> for 3.4, can the following icons be removed from konqueror's default
> toolbars:
>
> File Management: cut, copy, paste, print, zooming

cut: no
copy: no
paste: no

How does the noob manage his files without them?

> Web Browsing: cut, copy, paste, find, security

copy: no (one can copy selected text)

>
[...]

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/7e07c02d/attachment.sig>

From aseigo at kde.org  Fri Feb  4 19:24:32 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Fri, 04 Feb 2005 12:24:32 -0700
Subject: toolbars removus
In-Reply-To: <200502042007.21330.l.savernik@aon.at>
References: <200502041115.13447.aseigo@kde.org>
	<200502042007.21330.l.savernik@aon.at>
Message-ID: <200502041224.45548.aseigo@kde.org>

On Friday 04 February 2005 12:07, Leo Savernik wrote:
> Am Freitag, 4. Februar 2005 19:15 schrieb Aaron J. Seigo:
> > happy friday everyone...
> >
> > for 3.4, can the following icons be removed from konqueror's default
> > toolbars:
> >
> > File Management: cut, copy, paste, print, zooming
>
> cut: no
> copy: no
> paste: no
>
> How does the noob manage his files without them?

the way they've done it for a couple decades on platforms that didn't, and 
still don't, off them on the toolbar: by drag and drop, by using the edit 
menu, and as they progress the context menu and keyboard shortcuts.

this also assumes that "noobs" (ug, what a term) even follow this pattern of 
usage on a common basis. 

> > Web Browsing: cut, copy, paste, find, security
>
> copy: no (one can copy selected text)

konqueror is not an editor. <-- read that again.

should we have a toolbar with copy in KMessageBoxes because you can select 
text in them? of course not. copying text is not a primary use case of web 
browsing, and even when you do it there is the edit menu. it is not worth 
while to keep this on the toolbar, which should be reserved for the most 
common and vital application-specific actions.

just because you CAN perform an action in a given context does NOT mean that 
action belongs in the toolbar. not by a long shot.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/ecd2ae8d/attachment.sig>

From aseigo at kde.org  Fri Feb  4 19:35:08 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Fri, 04 Feb 2005 12:35:08 -0700
Subject: toolbars removus
In-Reply-To: <200502041349.13217.staikos@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041349.13217.staikos@kde.org>
Message-ID: <200502041235.11295.aseigo@kde.org>

On Friday 04 February 2005 11:49, George Staikos wrote:
>   For the (n+2) time, no to that one.  For KDE 4 I will fully test all the
> scenarios and we can consider the concept of looking in the toolbar for
> security state to be obsolete.

the scenario that matters is the default one. and in the default one we show 
the lock in 3 places, including the defacto standard location of the status 
bar, and the rather newly introduced location of the location bar. this isn't 
something that requires months, weeks or even days of deliberation: there are 
two other places in the default set up that web pages can not obscure. i 
don't think it's responsible to insist on making konqueror look foolish for 
having the same info in *3* places in the default set up when it's pretty 
obvious with nice bright lock icons and color changes in the location bar.

the security status madness in konqueror has ceased to border on fetishism and 
firmly within the realm of whips and chains at this point. to drive the point 
home, here's the message we communicate very clearly right now:

KDE: security is not optional, but usability is the last thing we care about. 
and did we mention we care about security? a lot. security.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/459f86a0/attachment.sig>

From staikos at kde.org  Fri Feb  4 19:52:32 2005
From: staikos at kde.org (George Staikos)
Date: Fri, 4 Feb 2005 14:52:32 -0500
Subject: toolbars removus
In-Reply-To: <200502041235.11295.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041349.13217.staikos@kde.org>
	<200502041235.11295.aseigo@kde.org>
Message-ID: <200502041452.32529.staikos@kde.org>

On Friday 04 February 2005 14:35, Aaron J. Seigo wrote:
> On Friday 04 February 2005 11:49, George Staikos wrote:
> >   For the (n+2) time, no to that one.  For KDE 4 I will fully test all
> > the scenarios and we can consider the concept of looking in the toolbar
> > for security state to be obsolete.
>
> the scenario that matters is the default one. and in the default one we
> show the lock in 3 places, including the defacto standard location of the
> status bar, and the rather newly introduced location of the location bar.
> this isn't something that requires months, weeks or even days of
> deliberation: there are two other places in the default set up that web
> pages can not obscure. i don't think it's responsible to insist on making
> konqueror look foolish for having the same info in *3* places in the
> default set up when it's pretty obvious with nice bright lock icons and
> color changes in the location bar.

   Ok, remove the location bar one if having it in three places is a problem?  
It's actually in four, and conceptually it needs to be in 2: the statusbar 
and the context menu.

> the security status madness in konqueror has ceased to border on fetishism
> and firmly within the realm of whips and chains at this point. to drive the
> point home, here's the message we communicate very clearly right now:
>
> KDE: security is not optional, but usability is the last thing we care
> about. and did we mention we care about security? a lot. security.

    usability is not a factor here.  We're talking 22x22 pixels on something 
that is already relatively empty space, and we're talking about a large 
number of users who have been using it for ages and expect it in to toolbar.  
I am maintainer of this stuff, and this is the way I want it.  In KDE 4 we 
will change it.  I think I need to learn these email template things in kmail 
to store this one.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From aseigo at kde.org  Fri Feb  4 20:01:07 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Fri, 04 Feb 2005 13:01:07 -0700
Subject: toolbars removus
In-Reply-To: <200502041452.32529.staikos@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041235.11295.aseigo@kde.org>
	<200502041452.32529.staikos@kde.org>
Message-ID: <200502041301.09683.aseigo@kde.org>

On Friday 04 February 2005 12:52, George Staikos wrote:
>    Ok, remove the location bar one if having it in three places is a
> problem?

except that that's probably the MOST useful place to have it. it's closely 
associated with the location address and appears only when something is 
encrypted.

> It's actually in four,  

5 if we start counting menus ;) i was referring to mutually visible locations. 
it would be like having it in 3 places in the context menu.

>     usability is not a factor here. 

*stunned silence*

> I am maintainer of this stuff, and this is the way I want it.  In
> KDE 4 we will change it.

fair enough, you're the maintainer, and this is one of the rights that come 
with the position. i tried.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/4419305f/attachment.sig>

From staikos at kde.org  Fri Feb  4 20:09:59 2005
From: staikos at kde.org (George Staikos)
Date: Fri, 4 Feb 2005 15:09:59 -0500
Subject: toolbars removus
In-Reply-To: <200502041301.09683.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041452.32529.staikos@kde.org>
	<200502041301.09683.aseigo@kde.org>
Message-ID: <200502041509.59651.staikos@kde.org>

On Friday 04 February 2005 15:01, Aaron J. Seigo wrote:
> On Friday 04 February 2005 12:52, George Staikos wrote:
> >    Ok, remove the location bar one if having it in three places is a
> > problem?
>
> except that that's probably the MOST useful place to have it. it's closely
> associated with the location address and appears only when something is
> encrypted.

  But it has conceptual problems.  It can't fully represent what is needed, 
and it makes it cumbersome to access the identity of the site to verify it.  
There was a long thread on k-c-d about some of the problems with it.

> > It's actually in four,
>
> 5 if we start counting menus ;) i was referring to mutually visible
> locations. it would be like having it in 3 places in the context menu.

  Ooops forgot about that one.

> > I am maintainer of this stuff, and this is the way I want it.  In
> > KDE 4 we will change it.
>
> fair enough, you're the maintainer, and this is one of the rights that come
> with the position. i tried.

  Thanks. :-)  I do agree it needs to be cleaned up, but just hold off for 
~1.5 months and I promise it will be done.  I need to redevelop my test cases 
to make sure what we have is fully working first.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From aseigo at kde.org  Fri Feb  4 20:14:37 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Fri, 04 Feb 2005 13:14:37 -0700
Subject: toolbars removus
In-Reply-To: <200502041509.59651.staikos@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041301.09683.aseigo@kde.org>
	<200502041509.59651.staikos@kde.org>
Message-ID: <200502041314.38344.aseigo@kde.org>

On Friday 04 February 2005 01:09, George Staikos wrote:
>   Thanks. :-)  I do agree it needs to be cleaned up, but just hold off for
> ~1.5 months and I promise it will be done.  I need to redevelop my test
> cases to make sure what we have is fully working first.

assuming this does happen in ~6week time frame, we should backport the fix to 
3.4.1 ... better 6-8 weeks (3.4.1) than 1.5 years (4.0). =)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/462e9fc6/attachment.sig>

From jason at keirstead.org  Fri Feb  4 20:16:09 2005
From: jason at keirstead.org (Jason Keirstead)
Date: Fri, 4 Feb 2005 16:16:09 -0400
Subject: toolbars removus
In-Reply-To: <200502041224.45548.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502042007.21330.l.savernik@aon.at>
	<200502041224.45548.aseigo@kde.org>
Message-ID: <200502041616.09043.jason@keirstead.org>

On Friday 04 February 2005 3:24 pm, Aaron J. Seigo wrote:
> the way they've done it for a couple decades on platforms that didn't, and
> still don't, off them on the toolbar: by drag and drop, by using the edit
> menu, and as they progress the context menu and keyboard shortcuts.
>
> this also assumes that "noobs" (ug, what a term) even follow this pattern
> of usage on a common basis.

I would really, really incline to disagree with you here Aaron. From my 
experience, the place a new user is *most likely* to lok to copy  afile is 
the "Copy" button on the toolbar. I see them do it all the time - they hit 
the Copy button, click on the other folder, and click the "Paste" button. 
(Once I show them you can drag a file over they are often amazed).

You even said it youself - your study was based on Konqueror as a web browser. 
Konqeror is also a file manager. If the toolbar buttons were saved as part of 
the view profile (so that we could remove them from web browsing only), you 
may have a case, but I really don't think you have one here for these three 
buttons - they are *very* important for a file manager.

> security

As for this one, I agree 100%... I don't need 4 different security indicators. 
And the location bar is much more visible than the toolbar icon anyway.

-- 
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
    - Sun Tzu



From l.savernik at aon.at  Fri Feb  4 20:23:25 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 4 Feb 2005 21:23:25 +0100
Subject: toolbars removus
In-Reply-To: <200502041224.45548.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502042007.21330.l.savernik@aon.at>
	<200502041224.45548.aseigo@kde.org>
Message-ID: <200502042123.34554.l.savernik@aon.at>

Am Freitag, 4. Februar 2005 20:24 schrieb Aaron J. Seigo:
> On Friday 04 February 2005 12:07, Leo Savernik wrote:
> > Am Freitag, 4. Februar 2005 19:15 schrieb Aaron J. Seigo:
> > > happy friday everyone...
> > >
> > > for 3.4, can the following icons be removed from konqueror's default
> > > toolbars:
> > >
> > > File Management: cut, copy, paste, print, zooming
> >
> > cut: no
> > copy: no
> > paste: no
> >
> > How does the noob manage his files without them?
>
> the way they've done it for a couple decades on platforms that didn't, and
> still don't, off them on the toolbar: by drag and drop, by using the edit
> menu, and as they progress the context menu and keyboard shortcuts.

IIRC even Wind*ws explorer features cut/copy/paste buttons in file management 
mode. I have never heard/read anybody complain about it, so I'm wondering why 
people always complain about konqueror's.
>
> this also assumes that "noobs" (ug, what a term) even follow this pattern
> of usage on a common basis.

My observations of inexperienced users (now using the politically correct 
term ;-) ) have shown that they quickly grasp the meaning of toolbar buttons 
and rudimentary mouse moving/clicking.

However, they virtually never get straight menues, context menues, and 
keyboard shortcuts (the latter one the most hideous/irritating one).
>
> > > Web Browsing: cut, copy, paste, find, security
> >
> > copy: no (one can copy selected text)
>
> konqueror is not an editor. <-- read that again.
>
> should we have a toolbar with copy in KMessageBoxes because you can select
> text in them? 

Cool, KMessageBox becomes a KXMLGUIClient? Sorry, just kidding...

> of course not. copying text is not a primary use case of web 
> browsing, and even when you do it there is the edit menu. it is not worth
> while to keep this on the toolbar, which should be reserved for the most
> common and vital application-specific actions.
>
> just because you CAN perform an action in a given context does NOT mean
> that action belongs in the toolbar. not by a long shot.

It's indeed true that no other browser I know of has a copy button, so I don't 
have a particularly strong feeling about keeping it.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/fa026472/attachment.sig>

From neundorf at kde.org  Fri Feb  4 20:28:02 2005
From: neundorf at kde.org (Alexander Neundorf)
Date: Fri, 4 Feb 2005 21:28:02 +0100
Subject: toolbars removus
In-Reply-To: <20050204200131.2265.qmail@ktown.kde.org>
References: <20050204200131.2265.qmail@ktown.kde.org>
Message-ID: <200502042128.03224.neundorf@kde.org>

On Friday 04 February 2005 21:01, kfm-devel-request at kde.org wrote:
> happy friday everyone...
>
> for 3.4, can the following icons be removed from konqueror's default
> toolbars:
>
> File Management: cut, copy, paste, print, zooming
> Web Browsing: cut, copy, paste, find, security
>

I'm all for it. I'm one of the users of a very simplified konqy profile and 
don't miss anything (maybe you remember).
I vote for removing. If George insists on keeping the security icon, keep this 
one and remove the others.

Bye
Alex
-- 
Work: alexander.neundorf at jenoptik.com - http://www.jenoptik-los.de
Home: neundorf at kde.org                - http://www.kde.org
      alex at neundorf.net               - http://www.neundorf.net



From ismail at kde.org.tr  Fri Feb  4 20:28:25 2005
From: ismail at kde.org.tr (Ismail Donmez)
Date: Fri, 4 Feb 2005 22:28:25 +0200
Subject: toolbars removus
In-Reply-To: <200502041301.09683.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041452.32529.staikos@kde.org>
	<200502041301.09683.aseigo@kde.org>
Message-ID: <200502042228.25467.ismail@kde.org.tr>

On Friday 04 February 2005 22:01, Aaron J. Seigo wrote:
> On Friday 04 February 2005 12:52, George Staikos wrote:
> >    Ok, remove the location bar one if having it in three places is a
> > problem?
>
> except that that's probably the MOST useful place to have it. it's closely
> associated with the location address and appears only when something is
> encrypted.

I tested this with my sister and she only noticed security when toolbar gets 
yellow. Many users tend to ignore toolbar & statusbar for this stuff.

Regards,
ismail



From manyoso at yahoo.com  Fri Feb  4 22:00:31 2005
From: manyoso at yahoo.com (Adam Treat)
Date: Fri, 4 Feb 2005 17:00:31 -0500
Subject: toolbars removus
In-Reply-To: <200502042128.03224.neundorf@kde.org>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<200502042128.03224.neundorf@kde.org>
Message-ID: <200502041700.31774.manyoso@yahoo.com>

On Friday 04 February 2005 3:28 pm, Alexander Neundorf wrote:
> On Friday 04 February 2005 21:01, kfm-devel-request at kde.org wrote:
> > happy friday everyone...
> >
> > for 3.4, can the following icons be removed from konqueror's default
> > toolbars:
> >
> > File Management: cut, copy, paste, print, zooming
> > Web Browsing: cut, copy, paste, find, security
>
> I'm all for it. I'm one of the users of a very simplified konqy profile and
> don't miss anything (maybe you remember).
> I vote for removing. If George insists on keeping the security icon, keep
> this one and remove the others.
>
> Bye
> Alex

Me too.  I hate usability discussions, but this seems a no brainer.  Other 
browsers get by just fine without cut,copy,paste,find in their toolbar.  
Besides, it is not like people who want it their can't very easily add it 
back.  I'm all for simple and clear defaults.



From jason at keirstead.org  Fri Feb  4 20:59:45 2005
From: jason at keirstead.org (Jason Keirstead)
Date: Fri, 4 Feb 2005 16:59:45 -0400
Subject: toolbars removus
In-Reply-To: <200502041700.31774.manyoso@yahoo.com>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<200502042128.03224.neundorf@kde.org>
	<200502041700.31774.manyoso@yahoo.com>
Message-ID: <200502041659.45525.jason@keirstead.org>

On Friday 04 February 2005 6:00 pm, Adam Treat wrote:
> Me too.  I hate usability discussions, but this seems a no brainer.  Other
> browsers get by just fine without cut,copy,paste,find in their toolbar.

Konqueror is not just a browser. A file manager without cut / copy/ paste 
icons is not very useable for a newcomer.

-- 
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
    - Sun Tzu



From kde at jamesots.com  Fri Feb  4 21:08:10 2005
From: kde at jamesots.com (James Ots)
Date: Fri, 4 Feb 2005 21:08:10 +0000
Subject: toolbars removus
In-Reply-To: <200502042228.25467.ismail@kde.org.tr>
References: <200502041115.13447.aseigo@kde.org>
	<200502041301.09683.aseigo@kde.org>
	<200502042228.25467.ismail@kde.org.tr>
Message-ID: <200502042108.11077.kde@jamesots.com>

On Friday 04 February 2005 20:28, Ismail Donmez wrote:
> On Friday 04 February 2005 22:01, Aaron J. Seigo wrote:
> > except that that's probably the MOST useful place to have it. it's
> > closely associated with the location address and appears only when
> > something is encrypted.
>
> I tested this with my sister and she only noticed security when toolbar
> gets yellow. Many users tend to ignore toolbar & statusbar for this stuff.

I only realised what that icon is for today, after many years of KDE use. I 
never noticed it locking and unlocking before (it's not a very big change, in 
crystal at least), and I can't remember ever clicking on it before. So I 
removed it from my toolbar - since I can see it's on the status bar anyway.

-- 
Cheers
James Ots
www.jamesots.com



From howells at kde.org  Fri Feb  4 21:56:50 2005
From: howells at kde.org (Chris Howells)
Date: Fri, 4 Feb 2005 21:56:50 +0000
Subject: toolbars removus
In-Reply-To: <200502042123.34554.l.savernik@aon.at>
References: <200502041115.13447.aseigo@kde.org>
	<200502041224.45548.aseigo@kde.org>
	<200502042123.34554.l.savernik@aon.at>
Message-ID: <200502042156.55813.howells@kde.org>

On Friday 04 February 2005 20:23, Leo Savernik wrote:
> IIRC even Wind*ws explorer features cut/copy/paste buttons in file
> management mode.

It does not.

And even if it did, are you suggesting that something is good, just because 
Windows does it?

> so I'm 
> wondering why people always complain about konqueror's.

Possibly because it's completely unobvious what they do.

-- 
Cheers, Chris Howells -- chris at chrishowells.co.uk, howells at kde.org
Web: http://www.chrishowells.co.uk, PGP ID: 0x33795A2C
KDE/Qt/C++/PHP Developer: http://www.kde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/e6a448f8/attachment.sig>

From lynch30 at marshall.edu  Fri Feb  4 22:56:47 2005
From: lynch30 at marshall.edu (Sean Lynch)
Date: Fri, 04 Feb 2005 17:56:47 -0500
Subject: toolbars removus
In-Reply-To: <200502041700.31774.manyoso@yahoo.com>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<200502042128.03224.neundorf@kde.org>
	<200502041700.31774.manyoso@yahoo.com>
Message-ID: <200502041756.47335.lynch30@marshall.edu>

On Friday 04 February 2005 05:00 pm, Adam Treat wrote:
> On Friday 04 February 2005 3:28 pm, Alexander Neundorf wrote:
> > On Friday 04 February 2005 21:01, kfm-devel-request at kde.org wrote:
> > > happy friday everyone...
> > >
> > > for 3.4, can the following icons be removed from konqueror's default
> > > toolbars:
> > >
> > > File Management: cut, copy, paste, print, zooming
> > > Web Browsing: cut, copy, paste, find, security
> >
> > I'm all for it. I'm one of the users of a very simplified konqy profile
> > and don't miss anything (maybe you remember).
> > I vote for removing. If George insists on keeping the security icon, keep
> > this one and remove the others.
> >
> > Bye
> > Alex
>
> Me too.  I hate usability discussions, but this seems a no brainer.  Other
> browsers get by just fine without cut,copy,paste,find in their toolbar.
> Besides, it is not like people who want it their can't very easily add it
> back.  I'm all for simple and clear defaults.


While I like to customize my desktop, I try not to change some things from the 
default which would make helping others harder (such as not having things in 
the same location, etc).  Ironcially, I did decide to clean up my konqueror 
toolbar recently after using KDE for about 3 years because I noticed:

1.) I've never used the options I removed in the 3 years I've used 
KDE/konqueror (options removed where cut/copy/paste, find, and security).  
Although I think Edit is a weird place for find (I guess to keep it close to 
Replace, when available in apps), I think the majority of users know to user 
control+f, and the others know its in Edit like all other programs.

2.) It made it harder to find things (yes, an extra half second, but 
considering how often a toolbar is used, it adds up).

I also decided to move the up arrow from being the first icon to the third 
(right side of back/forward instead of left).  I noticed alot of users 
complain about this to me (my wife and friend who I recently influenced to 
run linux/KDE full time).


*This is just 2 meaningless cents from a user / bug reporter.

Sean



From D.H.J.Takken at phys.uu.nl  Fri Feb  4 23:33:06 2005
From: D.H.J.Takken at phys.uu.nl (Dik Takken)
Date: Sat, 5 Feb 2005 00:33:06 +0100 (CET)
Subject: toolbars removus
In-Reply-To: <200502041115.13447.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
Message-ID: <Pine.LNX.4.62.0502050029360.654@venus.phys.uu.nl>

On Fri, 4 Feb 2005, Aaron J. Seigo wrote:

> happy friday everyone...
>
> for 3.4, can the following icons be removed from konqueror's default toolbars:
>
> File Management: cut, copy, paste, print, zooming
> Web Browsing: cut, copy, paste, find, security

Well, now that we finally might get into serving clean toolbars, could we 
also serve them with bigger icons and text beneath the icons? When a lot 
of superfluous icons are removed, we have plenty of space to do just that. 
Looks wonderfully fresh clean and organized. Attractive, maybe even...

Cheers!

Dik



From D.H.J.Takken at phys.uu.nl  Fri Feb  4 23:45:18 2005
From: D.H.J.Takken at phys.uu.nl (Dik Takken)
Date: Sat, 5 Feb 2005 00:45:18 +0100 (CET)
Subject: toolbars removus
In-Reply-To: <200502041659.45525.jason@keirstead.org>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<200502042128.03224.neundorf@kde.org>
	<200502041700.31774.manyoso@yahoo.com>
	<200502041659.45525.jason@keirstead.org>
Message-ID: <Pine.LNX.4.62.0502050040450.654@venus.phys.uu.nl>

On Fri, 4 Feb 2005, Jason Keirstead wrote:

> On Friday 04 February 2005 6:00 pm, Adam Treat wrote:
>> Me too.  I hate usability discussions, but this seems a no brainer.  Other
>> browsers get by just fine without cut,copy,paste,find in their toolbar.
>
> Konqueror is not just a browser. A file manager without cut / copy/ paste
> icons is not very useable for a newcomer.

That's why we need profile-dependent toolbars *before* we start cleaning 
up. Until that time we *need* two dozen icons to represent two dozen 
features, no matter if we need them any instant or not. Sad but true.

Dik



From D.H.J.Takken at phys.uu.nl  Fri Feb  4 23:56:36 2005
From: D.H.J.Takken at phys.uu.nl (Dik Takken)
Date: Sat, 5 Feb 2005 00:56:36 +0100 (CET)
Subject: toolbars removus
In-Reply-To: <200502041616.09043.jason@keirstead.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502042007.21330.l.savernik@aon.at>
	<200502041224.45548.aseigo@kde.org>
	<200502041616.09043.jason@keirstead.org>
Message-ID: <Pine.LNX.4.62.0502050048060.654@venus.phys.uu.nl>

On Fri, 4 Feb 2005, Jason Keirstead wrote:

> I would really, really incline to disagree with you here Aaron. From my
> experience, the place a new user is *most likely* to lok to copy  afile is
> the "Copy" button on the toolbar. I see them do it all the time - they hit
> the Copy button, click on the other folder, and click the "Paste" button.
> (Once I show them you can drag a file over they are often amazed).

I also happen to know a few inexperienced users who *never* use toolbar 
icons. It seems like they just don't notice the cut/copy/paste buttons 
because they can't stand out in the crowd of buttons on the tool bars. No 
single button can, I think. Maybe if I show them more often where the 
copy/paste buttons are they will use it. But they didn't bother looking by 
themselves anyway.


Dik



From aseigo at kde.org  Fri Feb  4 23:55:12 2005
From: aseigo at kde.org (Aaron Seigo)
Date: Fri, 4 Feb 2005 16:55:12 -0700
Subject: toolbars removus
In-Reply-To: <Pine.LNX.4.62.0502050040450.654@venus.phys.uu.nl>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<200502041659.45525.jason@keirstead.org>
	<Pine.LNX.4.62.0502050040450.654@venus.phys.uu.nl>
Message-ID: <200502041655.16465.aseigo@kde.org>

first, i really didn't mean to spawn another sprawling thread on this. i was 
looking more for the maintainers / konq core hackers to comment (thanks 
George for stepping up and doing your part in that).

On February 4, 2005 16:45, Dik Takken wrote:
> On Fri, 4 Feb 2005, Jason Keirstead wrote:
> > On Friday 04 February 2005 6:00 pm, Adam Treat wrote:
> >> Me too.  I hate usability discussions, but this seems a no brainer. 
> >> Other browsers get by just fine without cut,copy,paste,find in their
> >> toolbar.
> >
> > Konqueror is not just a browser. A file manager without cut / copy/ paste
> > icons is not very useable for a newcomer.

i call bullshit. we can discuss the reasons why elsewhere, but this statement 
simply is not generally true.

> That's why we need profile-dependent toolbars *before* we start cleaning
> up. Until that time we *need* two dozen icons to represent two dozen
> features, no matter if we need them any instant or not. Sad but true.

we've had that for some time now. XMLUIFILE=<somerc> in the profile config 
file. it's possible today.

-- 
Aaron J. Seigo
Society is Geometric
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/48d8b55b/attachment.sig>

From k1pfeifle at gmx.net  Fri Feb  4 23:47:08 2005
From: k1pfeifle at gmx.net (Kurt Pfeifle)
Date: Fri, 4 Feb 2005 23:47:08 +0000
Subject: Konqueror crashes reproducably with certain URL
Message-ID: <200502042347.08650.k1pfeifle@gmx.net>

3 hours old Konqui crashes reproducably on certain websites.
One example is here:

  http://uk.builder.com/programming/windows/0,39026618,39235857,00.htm

I've been running Konqui-the-Browser from HEAD for many weeks 
without a crash (had a few with Konqui-the-Filemanager a while
ago), but since about a week my daily builds see also daily
crashes with Konqui.

This however is the first reproducible case I found.

It is also now known as bug:98584

Cheers,
Kurt


Backtrace of crash:
-------------------
Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 15664)]
[KCrash handler]
#5  0x4159c871 in kill () from /lib/libc.so.6
#6  0x41422501 in pthread_kill () from /lib/libpthread.so.0
#7  0x4142254b in raise () from /lib/libpthread.so.0
#8  0x4159c604 in raise () from /lib/libc.so.6
#9  0x4159daac in abort () from /lib/libc.so.6
#10 0x4159599a in __assert_fail () from /lib/libc.so.6
#11 0x41f4e02e in DOM::NodeImpl::attach (this=0x87804b0)
    at /home/kdedev/src/kde/kdelibs/khtml/xml/dom_nodeimpl.cpp:859
#12 0x41f4e0bf in DOM::NodeBaseImpl::attach (this=0x87804b0)
    at /home/kdedev/src/kde/kdelibs/khtml/xml/dom_nodeimpl.cpp:1392
#13 0x41f7e88b in DOM::HTMLImageElementImpl::attach (this=0x87804b0)
    at /home/kdedev/src/kde/kdelibs/khtml/html/html_imageimpl.cpp:190
#14 0x41f6555f in khtml::KHTMLParser::insertNode (this=0x860e750, 
    n=0x87804b0, flat=true)
    at /home/kdedev/src/kde/kdelibs/khtml/html/htmlparser.cpp:329
#15 0x41f6725e in khtml::KHTMLParser::parseToken (this=0x860e750, t=0x860e624)
    at /home/kdedev/src/kde/kdelibs/khtml/html/htmlparser.cpp:279
#16 0x41f67fff in khtml::HTMLTokenizer::processToken (this=0x860e5f0)
    at /home/kdedev/src/kde/kdelibs/khtml/html/htmltokenizer.cpp:1601
#17 0x41f6c2e3 in khtml::HTMLTokenizer::parseTag (this=0x860e5f0, 
    src=@0x860e71c)
    at /home/kdedev/src/kde/kdelibs/khtml/html/htmltokenizer.cpp:1123
#18 0x41f6e03d in khtml::HTMLTokenizer::write (this=0x860e5f0, 
    str=@0x41429304, appendData=false)
    at /home/kdedev/src/kde/kdelibs/khtml/html/htmltokenizer.cpp:1301
#19 0x41f6a6bb in khtml::HTMLTokenizer::notifyFinished (this=0x860e5f0)
    at /home/kdedev/src/kde/kdelibs/khtml/html/htmltokenizer.cpp:1670
#20 0x42028299 in khtml::CachedScript::checkNotify (this=0x84c8bb8)
    at qptrdict.h:110
#21 0x4202b2e0 in khtml::CachedScript::data (this=0x84c8bb8, 
    buffer=@0x85466f4)
    at /home/kdedev/src/kde/kdelibs/khtml/misc/loader.cpp:320
#22 0x42027dab in khtml::Loader::slotFinished (this=0x84a1e98, job=0x84dbbb0)
    at /home/kdedev/src/kde/kdelibs/khtml/misc/loader.cpp:1104
#23 0x42027f73 in khtml::Loader::qt_invoke (this=0x84a1e98, _id=2, 
    _o=0xbfffdb10) at qucom_p.h:312
#24 0x40caf987 in QObject::activate_signal (this=0x84dbbb0, clist=0x84a6720, 
    o=0xbfffdb10) at kernel/qobject.cpp:2357
#25 0x4018cabc in KIO::Job::result (this=0x84dbbb0, t0=0x84dbbb0)
    at jobclasses.moc:156
#26 0x40193d9a in KIO::Job::emitResult (this=0x84dbbb0)
    at /home/kdedev/src/kde/kdelibs/kio/kio/job.cpp:217
#27 0x40193fa9 in KIO::SimpleJob::slotFinished (this=0x84dbbb0)
    at /home/kdedev/src/kde/kdelibs/kio/kio/job.cpp:536
#28 0x4019467d in KIO::TransferJob::slotFinished (this=0x84dbbb0)
    at /home/kdedev/src/kde/kdelibs/kio/kio/job.cpp:896
#29 0x40192a5b in KIO::TransferJob::qt_invoke (this=0x84dbbb0, _id=17, 
    _o=0xbfffded0) at jobclasses.moc:1050
#30 0x40caf987 in QObject::activate_signal (this=0x8538940, clist=0x84cfc80, 
    o=0xbfffded0) at kernel/qobject.cpp:2357
#31 0x40caf826 in QObject::activate_signal (this=0x8538940, signal=6)
    at kernel/qobject.cpp:2326
#32 0x40179a68 in KIO::SlaveInterface::finished (this=0x8538940)
    at qmetaobject.h:261
#33 0x4017ca09 in KIO::SlaveInterface::dispatch (this=0x8538940, _cmd=104, 
    rawdata=@0xbfffe1c0)
    at /home/kdedev/src/kde/kdelibs/kio/kio/slaveinterface.cpp:237
#34 0x4017d65d in KIO::SlaveInterface::dispatch (this=0x8538940)
    at /home/kdedev/src/kde/kdelibs/kio/kio/slaveinterface.cpp:173
#35 0x4017561e in KIO::Slave::gotInput (this=0x8538940)
    at /home/kdedev/src/kde/kdelibs/kio/kio/slave.cpp:300
#36 0x40178cac in KIO::Slave::qt_invoke (this=0x8538940, _id=4, _o=0xbfffe340)
    at slave.moc:113
#37 0x40caf987 in QObject::activate_signal (this=0x85c17e0, clist=0x85383e8, 
    o=0xbfffe340) at kernel/qobject.cpp:2357
#38 0x40cafcf9 in QObject::activate_signal (this=0x85c17e0, signal=2, 
    param=19) at kernel/qobject.cpp:2450
#39 0x410086a1 in QSocketNotifier::activated (this=0x85c17e0, t0=19)
    at .moc/debug-shared-mt/moc_qsocketnotifier.cpp:85
#40 0x40ccfb74 in QSocketNotifier::event (this=0x85c17e0, e=0xbfffe630)
    at kernel/qsocketnotifier.cpp:280
#41 0x40c4cc33 in QApplication::internalNotify (this=0xbfffec20, 
    receiver=0x85c17e0, e=0xbfffe630) at kernel/qapplication.cpp:2635
#42 0x40c4c0f0 in QApplication::notify (this=0xbfffec20, receiver=0x85c17e0, 
    e=0xbfffe630) at kernel/qapplication.cpp:2358
#43 0x40753327 in KApplication::notify (this=0xbfffec20, receiver=0x85c17e0, 
    event=0xbfffe630)
    at /home/kdedev/src/kde/kdelibs/kdecore/kapplication.cpp:549
#44 0x40be262b in QApplication::sendEvent (receiver=0x85c17e0, 
    event=0xbfffe630) at qapplication.h:491
#45 0x40c3af8a in QEventLoop::activateSocketNotifiers (this=0x81c3838)
    at kernel/qeventloop_unix.cpp:580
#46 0x40bf438a in QEventLoop::processEvents (this=0x81c3838, flags=4)
    at kernel/qeventloop_x11.cpp:383
#47 0x40c60e4e in QEventLoop::enterLoop (this=0x81c3838)
    at kernel/qeventloop.cpp:198
#48 0x40c60d6a in QEventLoop::exec (this=0x81c3838)
    at kernel/qeventloop.cpp:145
#49 0x40c4cdb3 in QApplication::exec (this=0xbfffec20)
    at kernel/qapplication.cpp:2758
#50 0x418f4e7e in kdemain (argc=3, argv=0x8199e10)
    at /home/kdedev/src/kde/kdebase/konqueror/konq_main.cc:206
#51 0x4090c990 in kdeinitmain (argc=3, argv=0x8199e10)
    at konqueror/kdeinit_konqueror.la.cpp:2
#52 0x0804e481 in launch (argc=3, _name=0x8198fb4 "konqueror", 
    args=0x8198fd4 "\001", cwd=0x0, envc=1, envs=0x8198fec "", 
    reset_env=false, tty=0x0, avoid_loops=false, 
    startup_id_str=0x8198ff0 "p15159004;1107559731;109418;24719_TIME3753135916") at /home/kdedev/src/kde/kdelibs/kinit/kinit.cpp:623
#53 0x0804ebe2 in handle_launcher_request (sock=0)
    at /home/kdedev/src/kde/kdelibs/kinit/kinit.cpp:1187
#54 0x0804f1e0 in handle_requests (waitForPid=0)
    at /home/kdedev/src/kde/kdelibs/kinit/kinit.cpp:1388
#55 0x0804f973 in main (argc=2, argv=0xbffff4e4, envp=0xbffff4f0)
    at /home/kdedev/src/kde/kdelibs/kinit/kinit.cpp:1839



From koos.vriezen at xs4all.nl  Sat Feb  5 00:18:45 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 5 Feb 2005 01:18:45 +0100
Subject: toolbars removus
In-Reply-To: <200502042156.55813.howells@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041224.45548.aseigo@kde.org>
	<200502042123.34554.l.savernik@aon.at>
	<200502042156.55813.howells@kde.org>
Message-ID: <20050205001845.GB40806@xs4all.nl>

On Fri, Feb 04, 2005 at 09:56:50PM +0000, Chris Howells wrote:
> On Friday 04 February 2005 20:23, Leo Savernik wrote:
> > IIRC even Wind*ws explorer features cut/copy/paste buttons in file
> > management mode.
> 
> It does not.
> 
> And even if it did, are you suggesting that something is good, just because 
> Windows does it?

Somehow discussions about default ends with sentiment. Why not define
first what rule we apply defining defaults.  With that respect I would
vote for what the major platform does when some functionality is
current. In case of a web browser, I think we should apply to what
IE/firefox does. Given that konqueror is more than that, a button for
home directory should be allowed.
Face it, what difference would it make for us what default it is. Goal is to
please new users and honour 'old' KDE users configurations like it was. IMHO.
So the applied rule should be IMO, what does IE/firefox show for
browsing and explorer for filemanagement. Given that konqueror is also a
filemanager during internet browsing, button(s) for that should be
considered (btw. my own preference is show/hide sidebar instead of home
button, but who cares).

Koos



From mikmach at wp.pl  Fri Feb  4 23:30:42 2005
From: mikmach at wp.pl (Mikolaj Machowski)
Date: Sat, 5 Feb 2005 00:30:42 +0100
Subject: toolbars removus
In-Reply-To: <200502042156.55813.howells@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502042123.34554.l.savernik@aon.at>
	<200502042156.55813.howells@kde.org>
Message-ID: <200502050030.43140.mikmach@wp.pl>

Dnia piątek, 4 lutego 2005 22:56, Chris Howells napisał:
> On Friday 04 February 2005 20:23, Leo Savernik wrote:
> > IIRC even Wind*ws explorer features cut/copy/paste buttons in file
> > management mode.
>
> It does not.
>
> And even if it did, are you suggesting that something is good, just
> because Windows does it?

It is good because 99% of new KDE users have Windows background and can
be accustomed to some things.

m.




From mikmach at wp.pl  Fri Feb  4 23:33:16 2005
From: mikmach at wp.pl (Mikolaj Machowski)
Date: Sat, 5 Feb 2005 00:33:16 +0100
Subject: toolbars removus
In-Reply-To: <200502041115.13447.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
Message-ID: <200502050033.16988.mikmach@wp.pl>

Dnia piątek, 4 lutego 2005 19:15, Aaron J. Seigo napisał:
> happy friday everyone...
>
> for 3.4, can the following icons be removed from konqueror's default
> toolbars:
>
> File Management: cut, copy, paste, print, zooming

cut, paste could be left. But I don't have really strong feelings about
that.

> Web Browsing: cut, copy, paste, find, security

Full ack.
BTW - Firefox has really sweet mini-toolbar for /looking ahead.

m.




From aseigo at kde.org  Sat Feb  5 00:46:56 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Fri, 04 Feb 2005 17:46:56 -0700
Subject: toolbars removus
In-Reply-To: <20050205001845.GB40806@xs4all.nl>
References: <200502041115.13447.aseigo@kde.org>
	<200502042156.55813.howells@kde.org> <20050205001845.GB40806@xs4all.nl>
Message-ID: <200502041747.04538.aseigo@kde.org>

On Friday 04 February 2005 05:18, Koos Vriezen wrote:
> Goal is
> to please new users and honour 'old' KDE users configurations like it was.

is it? or is the goal also to build a usable desktop? a mix of "familiar" and 
"better" as guided by good judgement seems more powerful a direction.

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050204/3f7c0572/attachment.sig>

From thomasmg at web.de  Sat Feb  5 14:39:09 2005
From: thomasmg at web.de (Thomas McGuire)
Date: Sat, 5 Feb 2005 14:39:09 +0000
Subject: toolbars removus
In-Reply-To: <200502041115.13447.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
Message-ID: <200502051439.09913.thomasmg@web.de>

On Friday 04 February 2005 18:15, Aaron J. Seigo wrote:
> for 3.4, can the following icons be removed from konqueror's default
> toolbars:
>
> File Management: cut, copy, paste, print, zooming
> Web Browsing: cut, copy, paste, find, security
I agree, but I would not mind if the security and copy+paste buttons 
stayed, as Leo pointed out. However I personally don't need them.

Please also remove the KGet button.
KGet is integrated in Konqueror anyway, one does not have to drag all 
files to a "drop target". And I bet 99% of all users do not use the "List 
all links" feature.

Furthermore, toolbar buttons which are in reality a dropdown menu serve no 
purpose, as one has to do two mouse clicks.
>"Whereas toolbars are designed to provide rapid access to frequently used 
>menu items, Microsoft's designers chose to use the toolbar to 
>display...menus."
http://digilander.libero.it/chiediloapippo/Engineering/iarchitect/controls.htm 
(Reading that sites generally gives the feeling KDE has indeed copied many 
bad design decisions from Microsoft)

Instead, KGet should be moved to the "Tools" menu, like all other tools. 
All the users who really want a drop target or need to list all links can 
then find it there.

Simply downloading files with KGet works without the toolbar button 
anyway, so it is not needed. 

Regards,
Thomas




From koos.vriezen at xs4all.nl  Sat Feb  5 14:02:57 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 5 Feb 2005 15:02:57 +0100
Subject: toolbars removus
In-Reply-To: <200502041747.04538.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502042156.55813.howells@kde.org>
	<20050205001845.GB40806@xs4all.nl>
	<200502041747.04538.aseigo@kde.org>
Message-ID: <20050205140257.GD40806@xs4all.nl>

On Fri, Feb 04, 2005 at 05:46:56PM -0700, Aaron J. Seigo wrote:
> On Friday 04 February 2005 05:18, Koos Vriezen wrote:
> > Goal is
> > to please new users and honour 'old' KDE users configurations like it was.
> 
> is it? or is the goal also to build a usable desktop? a mix of "familiar" and 
> "better" as guided by good judgement seems more powerful a direction.

Sure, but there has to be some rule to select the "better" cases.
Otherwise we end up with 'I use that button, so shall the rest of the
world' arguments.
(Btw, I personally liked all those useless buttons. It created enough
space for the location bar after removing them :-) ..... hey firefox has
that too. Also with a never-heard-of-mousing-questioning eyes I follow
the cut/paste button discussion for browsing mode, anyways ...)

Koos



From mikmach at wp.pl  Sat Feb  5 14:13:37 2005
From: mikmach at wp.pl (Mikolaj Machowski)
Date: Sat, 5 Feb 2005 15:13:37 +0100
Subject: toolbars removus
In-Reply-To: <Pine.LNX.4.62.0502050029360.654@venus.phys.uu.nl>
References: <200502041115.13447.aseigo@kde.org>
	<Pine.LNX.4.62.0502050029360.654@venus.phys.uu.nl>
Message-ID: <200502051513.37847.mikmach@wp.pl>

Dnia sobota, 5 lutego 2005 00:33, Dik Takken napisał:
> On Fri, 4 Feb 2005, Aaron J. Seigo wrote:
> > happy friday everyone...
> >
> > for 3.4, can the following icons be removed from konqueror's default
> > toolbars:
> >
> > File Management: cut, copy, paste, print, zooming
> > Web Browsing: cut, copy, paste, find, security
>
> Well, now that we finally might get into serving clean toolbars, could
> we also serve them with bigger icons and text beneath the icons? When a
> lot of superfluous icons are removed, we have plenty of space to do just
> that. Looks wonderfully fresh clean and organized. Attractive, maybe
> even...

Not beneath - please. When removing buttons you have more horizontal
space, not vertical.
What about something like in IE: text by more important buttons to make
them bigger?

m.





From illissius at gmail.com  Sat Feb  5 20:56:14 2005
From: illissius at gmail.com (=?ISO-8859-1?Q?G=E1bor_Lehel?=)
Date: Sat, 5 Feb 2005 21:56:14 +0100
Subject: toolbars removus
In-Reply-To: <200502051513.37847.mikmach@wp.pl>
References: <200502041115.13447.aseigo@kde.org>
	<Pine.LNX.4.62.0502050029360.654@venus.phys.uu.nl>
	<200502051513.37847.mikmach@wp.pl>
Message-ID: <9cfeadb8050205125626853588@mail.gmail.com>

While I'm indifferent wrt copy/paste buttons in file management mode
(they can be useful, but I don't use them), I'm all for removing the
rest, as well as moving 'up' to the right rather than left of
back/forwards, as someone suggested.

On Sat, 5 Feb 2005 15:13:37 +0100, Mikolaj Machowski <mikmach at wp.pl> wrote:
> Dnia sobota, 5 lutego 2005 00:33, Dik Takken napisał:
> > On Fri, 4 Feb 2005, Aaron J. Seigo wrote:
> > > happy friday everyone...
> > >
> > > for 3.4, can the following icons be removed from konqueror's default
> > > toolbars:
> > >
> > > File Management: cut, copy, paste, print, zooming
> > > Web Browsing: cut, copy, paste, find, security
> >
> > Well, now that we finally might get into serving clean toolbars, could
> > we also serve them with bigger icons and text beneath the icons? When a
> > lot of superfluous icons are removed, we have plenty of space to do just
> > that. Looks wonderfully fresh clean and organized. Attractive, maybe
> > even...
> 
> Not beneath - please. When removing buttons you have more horizontal
> space, not vertical.
> What about something like in IE: text by more important buttons to make
> them bigger?
> 
> m.
> 
> 


-- 
Work is punishment for failing to procrastinate effectively.
Mailing lists: illissius at gmail.com, everything else: illissius at elitemail.org



From l.savernik at aon.at  Sun Feb  6 19:49:10 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Sun, 6 Feb 2005 20:49:10 +0100
Subject: toolbars removus
In-Reply-To: <200502042108.11077.kde@jamesots.com>
References: <200502041115.13447.aseigo@kde.org>
	<200502042228.25467.ismail@kde.org.tr>
	<200502042108.11077.kde@jamesots.com>
Message-ID: <200502062049.15914.l.savernik@aon.at>

Am Freitag, 4. Februar 2005 22:08 schrieb James Ots:
[...]
> I only realised what that icon is for today, after many years of KDE use. I
> never noticed it locking and unlocking before (it's not a very big change,
> in crystal at least), and I can't remember ever clicking on it before. So I
> removed it from my toolbar - since I can see it's on the status bar anyway.

Under KDE Hicolor the unlocked state was significantly different from the 
locked state (bar was opened to the other side). Dunno why this has been 
changed for crystal, probably because style beats recognisability ;-)

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050206/89de8c82/attachment.sig>

From l.savernik at aon.at  Sun Feb  6 20:19:31 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Sun, 6 Feb 2005 21:19:31 +0100
Subject: toolbars removus
In-Reply-To: <200502041655.16465.aseigo@kde.org>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<Pine.LNX.4.62.0502050040450.654@venus.phys.uu.nl>
	<200502041655.16465.aseigo@kde.org>
Message-ID: <200502062119.32337.l.savernik@aon.at>

Am Samstag, 5. Februar 2005 00:55 schrieb Aaron Seigo:
> first, i really didn't mean to spawn another sprawling thread on this. i
> was looking more for the maintainers / konq core hackers to comment (thanks
> George for stepping up and doing your part in that).

Why don't we postpone this discussion to KDE 4.0 when there are plenty of 
opportunities for restructuring? The toolbars shouldn't change for every 
minor version upgrade.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050206/52564b94/attachment.sig>

From aseigo at kde.org  Sun Feb  6 21:07:41 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Sun, 06 Feb 2005 14:07:41 -0700
Subject: toolbars removus
In-Reply-To: <200502062119.32337.l.savernik@aon.at>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<200502041655.16465.aseigo@kde.org>
	<200502062119.32337.l.savernik@aon.at>
Message-ID: <200502061407.50474.aseigo@kde.org>

On Sunday 06 February 2005 01:19, Leo Savernik wrote:
> Am Samstag, 5. Februar 2005 00:55 schrieb Aaron Seigo:
> > first, i really didn't mean to spawn another sprawling thread on this. i
> > was looking more for the maintainers / konq core hackers to comment
> > (thanks George for stepping up and doing your part in that).
>
> Why don't we postpone this discussion to KDE 4.0 when there are plenty of
> opportunities for restructuring? The toolbars shouldn't change for every
> minor version upgrade.

because KDE 4 is a year and a half away, these changes are quite simple and 
obvious, the toolbars have changed already for 3.4 and i'm really tired of 
hearing people gripe (quite publicly) about this and having to agree with 
them that kde sucks in this regard. let's show some moxy here!

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050206/5309dfd0/attachment.sig>

From manyoso at yahoo.com  Sun Feb  6 21:52:59 2005
From: manyoso at yahoo.com (Adam Treat)
Date: Sun, 6 Feb 2005 16:52:59 -0500
Subject: toolbars removus
In-Reply-To: <200502062119.32337.l.savernik@aon.at>
References: <20050204200131.2265.qmail@ktown.kde.org>
	<200502041655.16465.aseigo@kde.org>
	<200502062119.32337.l.savernik@aon.at>
Message-ID: <200502061652.59988.manyoso@yahoo.com>

Let's just break up all the actions that are causing consternation into 
multiple toolbars.  Everyone who feels so put out about putting out their pet 
actions can have their own toolbar.  Finally, let's just turn off all 
toolbars by default.

...

I'm only half kidding.

On Sunday 06 February 2005 3:19 pm, Leo Savernik wrote:
> Am Samstag, 5. Februar 2005 00:55 schrieb Aaron Seigo:
> > first, i really didn't mean to spawn another sprawling thread on this. i
> > was looking more for the maintainers / konq core hackers to comment
> > (thanks George for stepping up and doing your part in that).
>
> Why don't we postpone this discussion to KDE 4.0 when there are plenty of
> opportunities for restructuring? The toolbars shouldn't change for every
> minor version upgrade.
>
> mfg
>  Leo



From faure at kde.org  Mon Feb  7 08:53:57 2005
From: faure at kde.org (David Faure)
Date: Mon, 7 Feb 2005 09:53:57 +0100
Subject: Fwd: Konqueror crash
Message-ID: <200502070953.57662.faure@kde.org>



----------  Forwarded Message  ----------

Subject: Konqueror crash
Date: Thursday 03 February 2005 09:52
From: "Robert Best" <rwbest at clix.pt>
To: David <faure at kde.org>

Hello David,
   Konqueror crashes reproducibly as follows.
Go to http://www.consumentenbond.nl/ and click on "Login" in the upper right corner.
Click on "Kies hier uw wachtwoord", Dutch for "Choose here your pass-word".
Click on "wachtwoord" at bottom of page. Crash.

I use SuSE Linux 9.2 pro.
The log follows.

Greetings from Portugal,
Robert

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 1095686656 (LWP 4527)]
[KCrash handler]
#7  0x41c64155 in khtml::CaretBoxLine::addConvertedInlineBox ()
    from /opt/kde3/lib/libkhtml.so.4
#8  0x41c640f1 in khtml::CaretBoxLine::addConvertedInlineBox ()
    from /opt/kde3/lib/libkhtml.so.4
#9  0x41c64dd8 in khtml::CaretBoxLine::constructCaretBoxLine ()
    from /opt/kde3/lib/libkhtml.so.4
#10 0x41c6883b in khtml::findCaretBoxLine () from /opt/kde3/lib/libkhtml.so.4
#11 0x41c68cb4 in KHTMLView::moveCaretTo () from /opt/kde3/lib/libkhtml.so.4
#12 0x41c69903 in KHTMLPart::khtmlMousePressEvent ()
    from /opt/kde3/lib/libkhtml.so.4
#13 0x41c41757 in KHTMLPart::customEvent () from /opt/kde3/lib/libkhtml.so.4
#14 0x40bf6aae in QObject::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#15 0x40b9385f in QApplication::internalNotify ()
    from /usr/lib/qt3/lib/libqt-mt.so.3
#16 0x40b95423 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3
#17 0x40825a91 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4
#18 0x41c735aa in KHTMLView::viewportMousePressEvent ()
    from /opt/kde3/lib/libkhtml.so.4
#19 0x41c7161d in KHTMLView::eventFilter () from /opt/kde3/lib/libkhtml.so.4
#20 0x40bf698e in QObject::activate_filters ()
    from /usr/lib/qt3/lib/libqt-mt.so.3
#21 0x40bf6a70 in QObject::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#22 0x40c2becf in QWidget::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#23 0x40cc8bea in QLineEdit::event () from /usr/lib/qt3/lib/libqt-mt.so.3
#24 0x41cf263c in khtml::LineEditWidget::event ()
    from /opt/kde3/lib/libkhtml.so.4
#25 0x40b9385f in QApplication::internalNotify ()
    from /usr/lib/qt3/lib/libqt-mt.so.3
#26 0x40b95c06 in QApplication::notify () from /usr/lib/qt3/lib/libqt-mt.so.3
#27 0x40825a91 in KApplication::notify () from /opt/kde3/lib/libkdecore.so.4
#28 0x40b30fce in QETWidget::translateMouseEvent ()
    from /usr/lib/qt3/lib/libqt-mt.so.3
#29 0x40b2fe86 in QApplication::x11ProcessEvent ()
    from /usr/lib/qt3/lib/libqt-mt.so.3
#30 0x40b40908 in QEventLoop::processEvents ()
    from /usr/lib/qt3/lib/libqt-mt.so.3
#31 0x40bab7b1 in QEventLoop::enterLoop () from /usr/lib/qt3/lib/libqt-mt.so.3
#32 0x40bab5f6 in QEventLoop::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#33 0x40b952ef in QApplication::exec () from /usr/lib/qt3/lib/libqt-mt.so.3
#34 0x41763b4c in kdemain () from /opt/kde3/lib/libkdeinit_konqueror.so
#35 0x0804e7a6 in launch ()
#36 0x0804eebc in handle_launcher_request ()
#37 0x0804f479 in handle_requests ()
#38 0x0804fc5a in main ()


-- 
http://rwbest.planetaclix.pt



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

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From kde at carewolf.com  Mon Feb  7 09:37:05 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Mon, 7 Feb 2005 10:37:05 +0100
Subject: Generated content: counters and quotes
In-Reply-To: <200501282340.32209.germain@ebooksfrance.org>
References: <200501272244.12213.kde@carewolf.com>
	<200501282340.32209.germain@ebooksfrance.org>
Message-ID: <200502071037.05281.kde@carewolf.com>

On Saturday 29 January 2005 00:40, Germain Garand wrote:
> this looks just great...
> Only thing I find questionable in your patch is the added stuff in
> RenderObject, especially the added pointer  to a cache struct.
> IMO, it should be in at least RenderBox to avoid any unnecessary bloat.
>
Technically it is because any object that has a style can have a counter-node 
attached. It also reduces the need for static_cast<RenderBox*>.

Also I am not sure RenderBox is generic enough, since any stupid type of 
element can be counted. Imagine:
:first-letter { counter-increment: firstletter 1; }
#count { content: "Number of first letters: " counter(firstletter); }

> Also, "RenderGenerated" is rather confusing... the class is much less
> generic than the name would lead one to expect...
>
The plan is to make it more generic to move handling of generated content out 
of RenderContainer. I am trying to find out what is wrong with attr() 
content, and if it needs to be made dynamic it would be created here as well. 
(attr is currently inserted as text during style-selection, but for some 
reason the inserted text is empty)

> > and agree with me that CSS2 support is not a feature but the lack of it a
> > bug  :)
>
> Of course!
>
> Have a nice holiday time,
Thanks, I did :)

`Allan



From germain at ebooksfrance.org  Mon Feb  7 11:05:14 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 7 Feb 2005 11:05:14 +0000
Subject: Generated content: counters and quotes
In-Reply-To: <200502071037.05281.kde@carewolf.com>
References: <200501272244.12213.kde@carewolf.com>
	<200501282340.32209.germain@ebooksfrance.org>
	<200502071037.05281.kde@carewolf.com>
Message-ID: <200502071105.14629.germain@ebooksfrance.org>

Le lundi 07 Février 2005 09:37, Allan Sandfeld Jensen a écrit :
> On Saturday 29 January 2005 00:40, Germain Garand wrote:
> > this looks just great...
> > Only thing I find questionable in your patch is the added stuff in
> > RenderObject, especially the added pointer  to a cache struct.
> > IMO, it should be in at least RenderBox to avoid any unnecessary bloat.
>
> Technically it is because any object that has a style can have a
> counter-node attached. It also reduces the need for
> static_cast<RenderBox*>.
>

ah, I was rather thinking virtuals with asserts in RenderObject, but it might 
indeed be seen as another kind of bloat :)

> Also I am not sure RenderBox is generic enough, since any stupid type of
>
> element can be counted. Imagine:
> :first-letter { counter-increment: firstletter 1; }
>
> #count { content: "Number of first letters: " counter(firstletter); }
>

well, my assumption is: you can only select full blown element nodes from CSS, 
so how could those selectors apply to anything Object or Text?

> > Also, "RenderGenerated" is rather confusing... the class is much less
> > generic than the name would lead one to expect...
>
> The plan is to make it more generic to move handling of generated content
> out of RenderContainer. I am trying to find out what is wrong with attr()
> content, and if it needs to be made dynamic it would be created here as
> well. (attr is currently inserted as text during style-selection, but for
> some reason the inserted text is empty)
>

OK... it's not like it bother much anyway :)

Greetings,
Germain



From berk at upnet.ru  Mon Feb  7 12:35:07 2005
From: berk at upnet.ru (Stanislav Karchebny)
Date: Mon, 7 Feb 2005 17:35:07 +0500
Subject: toolbars removus
In-Reply-To: <200502041509.59651.staikos@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502041301.09683.aseigo@kde.org>
	<200502041509.59651.staikos@kde.org>
Message-ID: <200502071735.19053.berk@upnet.ru>

On Saturday 05 February 2005 01:09, George Staikos wrote:

>   Thanks. :-)  I do agree it needs to be cleaned up, but just hold off for
> ~1.5 months and I promise it will be done.  I need to redevelop my test
> cases to make sure what we have is fully working first.

Just keep in mind: I for myself would rather see it in the location bar than 
anywhere else.. Its much handier there (you can stick a context menu or 
whatever there to give access to site certificates etc, as these are very 
seldom actions).

-- 
keep in touch. berkus.

Roey on #kde-devel: when I hear best of breed I tune out--it's too much a 
buzzword. What I carry between my legs is best of breed. And like KDE, just 
because it's less visible doesn't mean it gets less usage.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050207/151dee58/attachment.sig>

From tanim at phobos.astro.virginia.edu  Mon Feb  7 14:48:14 2005
From: tanim at phobos.astro.virginia.edu (Tanim Islam)
Date: Mon, 7 Feb 2005 09:48:14 -0500
Subject: konqueror infinite self-spawn
Message-ID: <200502070948.14662.tanim@phobos.astro.virginia.edu>

Hello:

I am getting the konqueror infinite self-spawning error. I don't know how to 
trace what I did to get konqueror to this state? Can anyone help? I don't 
think it's a bug, but some weird configuration mismatch.

Tanim Islam
-- 
Astronomy 109, Department of Astronomy
P. O. Box 3818, University of Virginia
Charlottesville, VA 22903
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050207/6e5d9b35/attachment.sig>

From bastian at kde.org  Mon Feb  7 15:04:09 2005
From: bastian at kde.org (Waldo Bastian)
Date: Mon, 7 Feb 2005 16:04:09 +0100
Subject: konqueror infinite self-spawn
In-Reply-To: <200502070948.14662.tanim@phobos.astro.virginia.edu>
References: <200502070948.14662.tanim@phobos.astro.virginia.edu>
Message-ID: <200502071604.12501.bastian@kde.org>

On Monday 07 February 2005 15:48, Tanim Islam wrote:
> Hello:
>
> I am getting the konqueror infinite self-spawning error. I don't know how
> to trace what I did to get konqueror to this state? Can anyone help? I
> don't think it's a bug, but some weird configuration mismatch.

Maybe you configured konqueror as external browser? That had some issues in 
KDE 3.3

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050207/730d3c92/attachment.sig>

From koos.vriezen at xs4all.nl  Mon Feb  7 21:47:14 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Mon, 7 Feb 2005 22:47:14 +0100
Subject: kdelibs/khtml/java
In-Reply-To: <200502071728.32342.paul.temple@gmx.net>
References: <20050206215102.995FC1D16F@office.kde.org>
	<200502071616.29230.paul.temple@gmx.net>
	<20050207160143.GB56623@xs4all.nl>
	<200502071728.32342.paul.temple@gmx.net>
Message-ID: <20050207214714.GG56623@xs4all.nl>

On Mon, Feb 07, 2005 at 05:28:31PM +0100, Paul Temple wrote:
> Have you done _real_ profiling yet? Is there a difference between 
> 1.4 and 5? I know from my experience with jbuilder, eclipse and 
> the likes that startup time decreased significantly with each 
> new major version.

Ok, did some profiling w/ a testkjs application.
Application compile as: g++ -o testkjsas testkjsas.cpp
Run as: time PATH=/usr/local/jdk1.5.0/bin:$PATH ./testkjsas file:///home/koos/public_html jsapplet
for a jsapplet.class inside my public_html directory
It's a matter of commenting the second argument for the console window
Results are

w/ creating a console window:
1.4
real    0m1.419s
user    0m0.001s
sys     0m0.002s

1.5
real    0m1.471s
user    0m0.003s
sys     0m0.001s

w/o creating a console window:
1.4.2_06
real    0m1.053s
user    0m0.001s
sys     0m0.001s

1.5
real    0m1.171s
user    0m0.001s
sys     0m0.002s

commenting 'console.setVisible( true );' out in Main.java:120
1.4.2_06
real    0m1.279s
user    0m0.000s
sys     0m0.004s

1.5
real    0m1.332s
user    0m0.001s
sys     0m0.001s

Note, numbers are after a few time to eliminate caching and seem to
stabalize arround these numbers. I would say that it's a major slowdown
showing a console window. Even creating w/o showing is about 20% slower.

Koos
-------------- next part --------------
#include <sys/types.h>
#include <unistd.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>

int main (int argc, char ** argv) {
    char policy[256], jar_path[256];
    int stdin_pipe[2], stdout_pipe[2];
    if (argc < 3) {
        fprintf (stderr, "usage %s <codebase> <classname>\n", argv[0]);
        return 1;
    }
    char * kdedir = getenv ("KDEDIR");
    if (!kdedir)
        kdedir = "/usr";
    snprintf (policy, sizeof (policy), "-Djava.security.policy=%s/share/apps/kjava/kjava.policy", kdedir);
    snprintf (jar_path, sizeof (jar_path), "%s/share/apps/kjava/kjava.jar", kdedir);
    char * const jvm_argv [] = {
        "java"/*, "-Dkjas.showConsole"*/, "-DUseSecurityManager=true", policy,
        "-classpath",  jar_path, "org.kde.kjas.server.Main", 0L
    };
    if (pipe (stdin_pipe) || pipe (stdout_pipe)) {
        perror ("pipe");
        return -1;
    }
    int pid = fork ();
    switch (pid) {
        case -1: // error
            break;
        case 0: { // child
            close (0);
            dup (stdin_pipe[0]);
            close (stdin_pipe[0]);
            close (stdin_pipe[1]);
            close (1);
            dup (stdout_pipe[1]);
            close (stdout_pipe[0]);
            close (stdout_pipe[1]);
            execvp (jvm_argv[0], jvm_argv);        
            return 1;
        }
        default: // parent
            close (stdin_pipe[0]);
            close (stdout_pipe[1]);
            break;
    }
    const char * cmd = "3       \0010\0"; // create context 0
    write (stdin_pipe[1], cmd, 11); // 8 + 1 (code) + 1 (contextid) + 1 (sep)
    char buf[256] = "        ";
    int buf_pos = 8;
    buf [buf_pos++] = '\003'; // create applet code
    buf [buf_pos++] = '0'; // contextid
    buf [buf_pos++] = 0; // sep
    buf [buf_pos++] = '0'; // appletid
    buf [buf_pos++] = 0; // sep
    buf [buf_pos++] = 0; // name + sep
    strcpy (buf + buf_pos, argv[2]);  // classname
    buf_pos += strlen (argv[2]);
    buf [buf_pos++] = 0; // sep
    strcpy (buf + buf_pos, argv[1]);  // baseurl
    buf_pos += strlen (argv[1]);
    buf [buf_pos++] = 0; // sep
    buf [buf_pos++] = 0; // user + sep
    buf [buf_pos++] = 0; // passwd + sep
    buf [buf_pos++] = 0; // authname + sep
    strcpy (buf + buf_pos, argv[1]);  // codebase
    buf_pos += strlen (argv[1]);
    buf [buf_pos++] = 0; // sep
    buf [buf_pos++] = 0; // jarfile + sep
    strcpy (buf + buf_pos, "300");  // width
    buf_pos += 3;
    buf [buf_pos++] = 0; // sep
    strcpy (buf + buf_pos, "200");  // height
    buf_pos += 3;
    buf [buf_pos++] = 0; // sep
    buf [buf_pos++] = 0; // title + sep
    buf [buf_pos++] = '0'; // params
    buf [buf_pos++] = 0; // sep
    char num_buf [16];
    sprintf (num_buf, "%d", buf_pos-8);
    memcpy (buf, num_buf, strlen (num_buf));
    write (stdin_pipe[1], buf, buf_pos);
    while (true) {
        char lenstr[9];
        int num_bytes = read (stdout_pipe[0], lenstr, 8);
        if (num_bytes <= 0)
            exit (1);
        while (num_bytes < 8)
            num_bytes += read (stdout_pipe[0], lenstr+num_bytes, 8 - num_bytes);
        lenstr[8] = 0;
        int msg_len = strtol (lenstr, 0L, 10);
        if (msg_len < 0 || msg_len > 255) { // sanity check
            fprintf (stderr, "corrupted response\n");
            exit (1);
        }
        char * msg = new char [msg_len];
        num_bytes = read (stdout_pipe[0], msg, msg_len);
        if (num_bytes <= 0)
            exit (1);
        while (num_bytes < msg_len)
            num_bytes+= read (stdout_pipe[0], msg+num_bytes, msg_len-num_bytes);
        if (msg[0] == 23 && msg_len > 6) {
            if (msg[6] == '1')
                fprintf (stderr, "applet created\n");
            else if (msg[6] == '2')
                fprintf (stderr, "applet instanciated\n");
            else if (msg[6] == '3') {
                fprintf (stderr, "applet initialized\n");
                exit (0);
            }
        }
        delete [] msg;
    }
    return 0;
}

From paul.temple at gmx.net  Mon Feb  7 21:59:30 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 7 Feb 2005 22:59:30 +0100
Subject: Fwd: Re: kdelibs/khtml/java
Message-ID: <200502072259.31141.paul.temple@gmx.net>

Thanks for the numbers. I'll try to execute that on my machine
later ... gotta keep that source code as I'm new to c++ and
don't know much of the apis (just a little bit kde, qt and stl).

> Note, numbers are after a few time to eliminate caching and
> seem to stabalize arround these numbers. I would say that it's
> a major slowdown showing a console window. Even creating w/o
> showing is about 20% slower.

That's why I proposed to just create the text buffer on startup
and create the console window on demand, providing the already
created buffer as an arg to the console constructor. I think the
startup time should then be almost the same as it is now when
not creating a console.



From koos.vriezen at xs4all.nl  Mon Feb  7 22:11:42 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Mon, 7 Feb 2005 23:11:42 +0100
Subject: kdelibs/khtml/java
Message-ID: <20050207221142.GA41106@xs4all.nl>

On Mon, Feb 07, 2005 at 10:57:34PM +0100, Paul Temple wrote:
> Thanks for the numbers. I'll try to execute that on my machine 
> later ... gotta keep that source code as I'm new to c++ and 
> don't know much of the apis (just a little bit kde, qt and stl).

Just standard UNIX coding, see http://docs.freebsd.org/44doc/ for all
kinds of UNIX stuff ..

> > Note, numbers are after a few time to eliminate caching and
> > seem to stabalize arround these numbers. I would say that it's
> > a major slowdown showing a console window. Even creating w/o
> > showing is about 20% slower.
> 
> That's why I proposed to just create the text buffer on startup 
> and create the console window on demand, providing the already 
> created buffer as an arg to the console constructor. I think the 
> startup time should then be almost the same as it is now when 
> not creating a console.

Yeah I suspect that too, unless that buffer gets too big of course (eg.
w/ the -Dkjas.debug=1 argument). But like stated, lazy loading is always
good programming practise.
The main raison for the slowdown is the loading of all the swing
components (I think) and, when also showing, there is the X server and kwin
communication round trips and of course font painting that will slow it
more down.

Koos



From paul.temple at gmx.net  Mon Feb  7 22:57:23 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 7 Feb 2005 23:57:23 +0100
Subject: kdelibs/khtml/java
In-Reply-To: <20050207221142.GA41106@xs4all.nl>
References: <20050207221142.GA41106@xs4all.nl>
Message-ID: <200502072357.23767.paul.temple@gmx.net>

> > That's why I proposed to just create the text buffer on
> > startup and create the console window on demand, providing
> > the already created buffer as an arg to the console
> > constructor. I think the startup time should then be almost
> > the same as it is now when not creating a console.
>
> Yeah I suspect that too, unless that buffer gets too big of
> course (eg. w/ the -Dkjas.debug=1 argument). But like stated,

I don't see a connection between the buffer size (or the growth 
of it) and startup time - unless we make the buffer size greater 
than "free physical memory". ;) The extension of the buffer, 
when it gets full, takes some time, but that's not on console 
startup. And we could limit the max. number of characters / 
lines (delete the first lines if that limit is exceeded).

There is a constructor JTextArea(javax.swing.text.Document doc), 
so we could either use a PlainDocument, or, if that's not 
efficient - don't know as I didn't use it yet -  implement our 
own Document using our own Buffer. That would be created at 
startup and would then be used when lazy creating the JTextArea.



From paul.temple at gmx.net  Tue Feb  8 00:57:23 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Tue, 8 Feb 2005 01:57:23 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
Message-ID: <200502080157.24014.paul.temple@gmx.net>

Eventually tracked down that bug and found out - from the 
comments and looking at cvs annotations - that this problem is 
known for a long, long time... Example:

--- <render_block.cpp:v 1.2 2003-04-23 mueller> ---
// We are adding another block child... if the current last child 
is an anonymous box
// then it needs to be closed.
// ### get rid of the closing thing altogether this will only 
work during initial parsing
if (lastChild() && lastChild()->isAnonymous()) {
    lastChild()->close();
}
--- </render_block.cpp> ---

In order to make the applet work, we need to call 
NodeImpl::closeRenderer() after NodeImpl::attach().

I added one such call to NodeBaseImpl::appendChild(..) and yes: 
it worked!

But as the attach() calls are spread all over that file - I think 
the methods appendChild, replaceChild, removeChild and 
insertBefore could share most of their code - we need to add the 
closeRenderer() at least to insertBefore and replaceChild.

Does anyone know if there are any side effects if we add those 
closeRenderer() lines? I'm really new to khtml and don't know 
its structure enough. I suspect this bug would have been fixed a 
long time ago if it really was that easy.



From paul.temple at gmx.net  Tue Feb  8 01:51:24 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Tue, 8 Feb 2005 02:51:24 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502080157.24014.paul.temple@gmx.net>
References: <200502080157.24014.paul.temple@gmx.net>
Message-ID: <200502080251.24985.paul.temple@gmx.net>

> In order to make the applet work, we need to call
> NodeImpl::closeRenderer() after NodeImpl::attach().

Remark: Adding an img dynamically works without my addition of 
closeRenderer(), but it also works with it. But maybe there 
should be something like
  if (nodetype == APPLET)) closeRenderer()



From binner at kde.org  Tue Feb  8 09:28:48 2005
From: binner at kde.org (Stephan Binner)
Date: Tue, 8 Feb 2005 10:28:48 +0100
Subject: KCModule: Enhanced browsing
In-Reply-To: <opsldb9we2powx5f@stahl.stuco.uni-oldenburg.de>
References: <opsldb9we2powx5f@stahl.stuco.uni-oldenburg.de>
Message-ID: <200502081028.49188.binner@kde.org>

On Saturday 29 January 2005 15:38, Stefan Nikolaus wrote:

> does the Enhanced Browsing module ever show more than one tab?

I'm not aware that I ever saw a second plugin there.

> A TabWidget with only one tab looks horrible. If more tabs are possible,
> what about removing the tab widget for those which see only one tab? 

Good idea.

Bye,
   Steve



From l.savernik at aon.at  Tue Feb  8 15:59:33 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Tue, 8 Feb 2005 16:59:33 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502080157.24014.paul.temple@gmx.net>
References: <200502080157.24014.paul.temple@gmx.net>
Message-ID: <200502081659.48347.l.savernik@aon.at>

Hello,

Am Dienstag, 8. Februar 2005 01:57 schrieb Paul Temple:
> In order to make the applet work, we need to call 
> NodeImpl::closeRenderer() after NodeImpl::attach().
> 

Actually, we want to get rid of the closeRenderer() thingy altogether.

> But as the attach() calls are spread all over that file - I think
> the methods appendChild, replaceChild, removeChild and
> insertBefore could share most of their code - we need to add the
> closeRenderer() at least to insertBefore and replaceChild.

What you're proposing is the opposite approach. Emulating the closing tag by 
closing the renderer for inserted elements.

Which way we're going to persue depends on the facts whether
- it's doable within a sensible amount of time
- it yields better performance.
>
> Does anyone know if there are any side effects if we add those
> closeRenderer() lines? 

testregression will tell you.

> I'm really new to khtml and don't know 
> its structure enough. I suspect this bug would have been fixed a
> long time ago if it really was that easy.

I suspect that, too. There have been some nasty dataloss bugs wrt to textareas 
[1]. Double check that they don't break.

mfg
 Leo

[1] http://bugs.kde.org/show_bug.cgi?id=86916
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050208/9abc2186/attachment.sig>

From paul.temple at gmx.net  Tue Feb  8 16:07:17 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Tue, 8 Feb 2005 17:07:17 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502081659.48347.l.savernik@aon.at>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502081659.48347.l.savernik@aon.at>
Message-ID: <200502081707.17458.paul.temple@gmx.net>

> What you're proposing is the opposite approach. Emulating the
> closing tag by closing the renderer for inserted elements.

I know that, but I want to fix a bug - until someone more 
familiar with khtml removes all the closing stuff, and then of 
course my patch will vanish, too. But I'm the wrong one for 
these bigger changes (yet).

> testregression will tell you.

OK, don't know yet what testgression does exactly, but I'll check 
it out...



From koos.vriezen at xs4all.nl  Tue Feb  8 16:43:47 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 8 Feb 2005 17:43:47 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502081707.17458.paul.temple@gmx.net>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502081659.48347.l.savernik@aon.at>
	<200502081707.17458.paul.temple@gmx.net>
Message-ID: <20050208164347.GA41458@xs4all.nl>

On Tue, Feb 08, 2005 at 05:07:17PM +0100, Paul Temple wrote:
> > What you're proposing is the opposite approach. Emulating the
> > closing tag by closing the renderer for inserted elements.
> 
> I know that, but I want to fix a bug - until someone more 
> familiar with khtml removes all the closing stuff, and then of 
> course my patch will vanish, too. But I'm the wrong one for 
> these bigger changes (yet).

I took a quick look, and updateWidget is also called from
HTMLObjectBaseElementImpl::recalcStyle, but I can't find a setChanged
when needWidgetUpdate is set. Maybe that could be a way to solve it ...

Koos
> > testregression will tell you.
> 
> OK, don't know yet what testgression does exactly, but I'll check 
> it out...

I guess you should look at the htmltests cvs module.

Koos



From faure at kde.org  Tue Feb  8 18:11:17 2005
From: faure at kde.org (David Faure)
Date: Tue, 8 Feb 2005 19:11:17 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <20050208164347.GA41458@xs4all.nl>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502081707.17458.paul.temple@gmx.net>
	<20050208164347.GA41458@xs4all.nl>
Message-ID: <200502081911.18051.faure@kde.org>

> I guess you should look at the htmltests cvs module.

cvs co khtmltests, to be more precise (at least  cvs co khtmltests/regression)
Then "make testregression" in kdelibs/khtml, then running it.
Which reminds me that I just noticed some regressions in tests/ecma... I'll fix those.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From staikos at kde.org  Tue Feb  8 18:24:19 2005
From: staikos at kde.org (George Staikos)
Date: Tue, 8 Feb 2005 13:24:19 -0500
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502081911.18051.faure@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<20050208164347.GA41458@xs4all.nl>
	<200502081911.18051.faure@kde.org>
Message-ID: <200502081324.19751.staikos@kde.org>

On Tuesday 08 February 2005 13:11, David Faure wrote:
> > I guess you should look at the htmltests cvs module.
>
> cvs co khtmltests, to be more precise (at least  cvs co
> khtmltests/regression) Then "make testregression" in kdelibs/khtml, then
> running it.
> Which reminds me that I just noticed some regressions in tests/ecma... I'll
> fix those.

   Is there any hope to automate runs of those?

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From paul.temple at gmx.net  Tue Feb  8 18:33:24 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Tue, 8 Feb 2005 19:33:24 +0100
Subject: khtml guru? (82243: cannot dynamically add applets...)
Message-ID: <200502081933.24735.paul.temple@gmx.net>

Who are the khtml gurus?

Does anyone of you (gurus) know where and how - directly calling 
closeRenderer or making HTMLObjectBaseElementImpl::recalcStyle 
call updateWidget, as Koos suggested? - this should be done.
I think it's really helpful to overview and understand the whole 
structure for that.

Or should I just try-and-err, until my judge "testregression" 
gives his OK?



From koos.vriezen at xs4all.nl  Tue Feb  8 18:42:01 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 8 Feb 2005 19:42:01 +0100
Subject: khtml guru? (82243: cannot dynamically add applets...)
In-Reply-To: <200502081933.24735.paul.temple@gmx.net>
References: <200502081933.24735.paul.temple@gmx.net>
Message-ID: <20050208184201.GC41458@xs4all.nl>

On Tue, Feb 08, 2005 at 07:33:24PM +0100, Paul Temple wrote:
> Who are the khtml gurus?

Not me :-)

> Does anyone of you (gurus) know where and how - directly calling 
> closeRenderer or making HTMLObjectBaseElementImpl::recalcStyle 
> call updateWidget, as Koos suggested? - this should be done.

I didn't suggest that!! I said HTMLObjectBaseElementImpl::recalcStyle
calls updateWidget too. That's different than calling it directly, note
the 'setChanged' hint.
Anyhow, what I forgot to mention is a bug a was tracing some years ago.
Applets with a long list of 
<applet ...>
  <param ...>
  <param ...>
  ....
</applet>
had sometimes trouble getting all params. It seem to depend on the
network speed. Turned out that, while parsing, a layout/repaint
triggered the updateWidget _before_ the </applet> was read in these
unpredictable cases. So if setChanged might help, make sure its not set
while parsing.

Koos

> I think it's really helpful to overview and understand the whole 
> structure for that.
 
> Or should I just try-and-err, until my judge "testregression" 
> gives his OK?



From l.savernik at aon.at  Tue Feb  8 19:05:44 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Tue, 8 Feb 2005 20:05:44 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502081324.19751.staikos@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502081911.18051.faure@kde.org>
	<200502081324.19751.staikos@kde.org>
Message-ID: <200502082005.49558.l.savernik@aon.at>

Am Dienstag, 8. Februar 2005 19:24 schrieb George Staikos:
> On Tuesday 08 February 2005 13:11, David Faure wrote:
> > > I guess you should look at the htmltests cvs module.
> >
> > cvs co khtmltests, to be more precise (at least  cvs co
> > khtmltests/regression) Then "make testregression" in kdelibs/khtml, then
> > running it.
> > Which reminds me that I just noticed some regressions in tests/ecma...
> > I'll fix those.
>
>    Is there any hope to automate runs of those?

An automated daily testregression run would be utterly cool.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050208/55217244/attachment.sig>

From paul.temple at gmx.net  Tue Feb  8 20:58:31 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Tue, 8 Feb 2005 21:58:31 +0100
Subject: khtml guru? (82243: cannot dynamically add applets...)
In-Reply-To: <20050208184201.GC41458@xs4all.nl>
References: <200502081933.24735.paul.temple@gmx.net>
	<20050208184201.GC41458@xs4all.nl>
Message-ID: <200502082158.31854.paul.temple@gmx.net>

> > Does anyone of you (gurus) know where and how - directly
> > calling closeRenderer or making
> > HTMLObjectBaseElementImpl::recalcStyle call updateWidget, as
> > Koos suggested? - this should be done.
>
> I didn't suggest that!! I said
> HTMLObjectBaseElementImpl::recalcStyle calls updateWidget too.
> That's different than calling it directly, note the
> 'setChanged' hint.

That's what I realized when reading your former mail and what I 
wanted to implicate with "making HTML... call updateWidget" - 
should have made it clearer, though.



From paul.temple at gmx.net  Wed Feb  9 03:38:30 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Wed, 9 Feb 2005 04:38:30 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502081911.18051.faure@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<20050208164347.GA41458@xs4all.nl>
	<200502081911.18051.faure@kde.org>
Message-ID: <200502090438.30679.paul.temple@gmx.net>

On Tuesday 08 February 2005 19:11, David Faure wrote:
> > I guess you should look at the htmltests cvs module.
>
> cvs co khtmltests, to be more precise (at least  cvs co
> khtmltests/regression) Then "make testregression" in
> kdelibs/khtml, then running it. Which reminds me that I just
> noticed some regressions in tests/ecma... I'll fix those.

I guess that's the same as What about 
kdelibs/khtml/test_regression.cpp when checking out kdelibs, 
isn't it? I checked out the whole kdelibs anyway...



From coolo at kde.org  Wed Feb  9 08:53:16 2005
From: coolo at kde.org (Stephan Kulow)
Date: Wed, 9 Feb 2005 09:53:16 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502081324.19751.staikos@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502081911.18051.faure@kde.org>
	<200502081324.19751.staikos@kde.org>
Message-ID: <200502090953.18361.coolo@kde.org>

Am Tuesday 08 February 2005 19:24 schrieb George Staikos:
> On Tuesday 08 February 2005 13:11, David Faure wrote:
> > > I guess you should look at the htmltests cvs module.
> >
> > cvs co khtmltests, to be more precise (at least  cvs co
> > khtmltests/regression) Then "make testregression" in kdelibs/khtml, then
> > running it.
> > Which reminds me that I just noticed some regressions in tests/ecma... I'll
> > fix those.
> 
>    Is there any hope to automate runs of those?
The run of it is not the problem. Someone also has to sort out the fixes from
the regression and that is _work_

Greetings, Stephan



From danstemporaryaccount at yahoo.ca  Tue Feb  8 17:20:08 2005
From: danstemporaryaccount at yahoo.ca (daniel)
Date: Tue, 8 Feb 2005 12:20:08 -0500
Subject: neglected security issue in konqueror?
Message-ID: <200502081220.08326.danstemporaryaccount@yahoo.ca>

http://www.shmoo.com/idn/

a friend sent me this link this morning and it seems to me to be a real 
security problem but according to the paper, this issue was raised back in 
2001 and both mozilla and all khtml projects seem to still be affected by this 
potential problem.

i posted to kde at mail.kde.org and it was reccomended that i re-post it here.  
It seems to me that given that removing a standard from a standard-compliant 
browser isn't much of an option, might i suggest a warning popup of some 
kind?  or is this kind of issue best directed to the people responsible for 
resolution of names like that mentioned at the above link.

-- 
lift up yourselves, men,
take yourselves out of the mire and hitch your hopes to the stars;
yes, rise as high as the very stars themselves.
let no man pull you down, let no man destroy your ambition,
because man is your brother;
he is not your lord.
  - marcus garvey



From rigo at w3.org  Wed Feb  9 09:48:16 2005
From: rigo at w3.org (Rigo Wenning)
Date: Wed, 9 Feb 2005 10:48:16 +0100
Subject: neglected security issue in konqueror?
In-Reply-To: <200502081220.08326.danstemporaryaccount@yahoo.ca>
References: <200502081220.08326.danstemporaryaccount@yahoo.ca>
Message-ID: <200502091048.17648.rigo@w3.org>

It's a known issue, and the Unicode consortium has already looked at it, 
see:

http://www.unicode.org/reports/tr36/tr36-1.html#international_domain_names,

Of course, quite a bit of work remains.
Disabling IDNs isn't a solution, the same way that disabling
DNS in a browser isn't a solution to solve the problem of
phishing with ASCII-based domain names.

We are generally thinking about the issues related to phishing here. 

BTW, I tried it out and Konqueror complained about the wrong certificate 
as the SSL-implementation does _not_ know about IDN's it seems and 
confused the things too and got the wrong certificate. Anyway, the 
SSL-phishing on http://www.shmoo.com/idn/ does not work with my 
konqueror. 

Best, 
-- 
Rigo Wenning            W3C/ERCIM
Staff Counsel           Privacy Activity Lead
mail:rigo at w3.org        2004, Routes des Lucioles
http://www.w3.org/      F-06902 Sophia Antipolis



Am Tuesday 08 February 2005 18:20 verlautbarte daniel :
> http://www.shmoo.com/idn/
>
> a friend sent me this link this morning and it seems to me to be a
> real security problem but according to the paper, this issue was
> raised back in 2001 and both mozilla and all khtml projects seem to
> still be affected by this potential problem.
>
> i posted to kde at mail.kde.org and it was reccomended that i re-post it
> here. It seems to me that given that removing a standard from a
> standard-compliant browser isn't much of an option, might i suggest a
> warning popup of some kind?  or is this kind of issue best directed
> to the people responsible for resolution of names like that mentioned
> at the above link.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050209/e15910c6/attachment.sig>

From bastian at kde.org  Wed Feb  9 11:49:43 2005
From: bastian at kde.org (Waldo Bastian)
Date: Wed, 9 Feb 2005 12:49:43 +0100
Subject: neglected security issue in konqueror?
In-Reply-To: <200502081220.08326.danstemporaryaccount@yahoo.ca>
References: <200502081220.08326.danstemporaryaccount@yahoo.ca>
Message-ID: <200502091249.47961.bastian@kde.org>

Yes, we are aware of this issue, thank you for your concern. See 
http://bugs.kde.org/show_bug.cgi?id=98788

Cheers,
Waldo

On Tuesday 08 February 2005 18:20, daniel wrote:
> http://www.shmoo.com/idn/
>
> a friend sent me this link this morning and it seems to me to be a real
> security problem but according to the paper, this issue was raised back in
> 2001 and both mozilla and all khtml projects seem to still be affected by
> this potential problem.
>
> i posted to kde at mail.kde.org and it was reccomended that i re-post it here.
> It seems to me that given that removing a standard from a
> standard-compliant browser isn't much of an option, might i suggest a
> warning popup of some kind?  or is this kind of issue best directed to the
> people responsible for resolution of names like that mentioned at the above
> link.

-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050209/7754cbc7/attachment.sig>

From paul.temple at gmx.net  Wed Feb  9 14:00:43 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Wed, 9 Feb 2005 15:00:43 +0100
Subject: kdelibs/khtml/java
In-Reply-To: <20050207214714.GG56623@xs4all.nl>
References: <20050206215102.995FC1D16F@office.kde.org>
	<200502071728.32342.paul.temple@gmx.net>
	<20050207214714.GG56623@xs4all.nl>
Message-ID: <200502091500.44347.paul.temple@gmx.net>

On Monday 07 February 2005 22:47, Koos Vriezen wrote:
> Ok, did some profiling w/ a testkjs application.

As I had to restart my machine today (and don't know how to 
unload java shared libs from memory) I got a chance to see, how 
long java needs to start up in konqueror when loaded "cold" (a 
plain java.awt.applet with java console enabled):
cold: ~7s
(warm: ~ 1s)

Quite a difference... Next time I reboot my machine (or someone 
tells me how to remove the java remainder off memory :) I'll try 
that without the java console.
I think the startup time will be noticeable shorter without 
console if we only start an awt applet, but propably just a 
little bit shorter, but not that much as.

And there isn't much more we can do about the cold startup time, 
is it?



From l.savernik at aon.at  Wed Feb  9 15:16:00 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Wed, 9 Feb 2005 16:16:00 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502090438.30679.paul.temple@gmx.net>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502081911.18051.faure@kde.org>
	<200502090438.30679.paul.temple@gmx.net>
Message-ID: <200502091616.08925.l.savernik@aon.at>

Am Mittwoch, 9. Februar 2005 04:38 schrieb Paul Temple:
> On Tuesday 08 February 2005 19:11, David Faure wrote:
> > > I guess you should look at the htmltests cvs module.
> >
> > cvs co khtmltests, to be more precise (at least  cvs co
> > khtmltests/regression) Then "make testregression" in
> > kdelibs/khtml, then running it. Which reminds me that I just
> > noticed some regressions in tests/ecma... I'll fix those.
>
> I guess that's the same as What about
> kdelibs/khtml/test_regression.cpp when checking out kdelibs,
> isn't it? I checked out the whole kdelibs anyway...

Not quite.
- kdelibs/khtml/testregression is the application that runs the regression 
tests, and generates respective output.
- khtmltests/regression contains all the regression testcases themselves.

In fact, you need both for regression testing.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050209/ee2ea0c7/attachment.sig>

From bastian at kde.org  Wed Feb  9 18:17:41 2005
From: bastian at kde.org (Waldo Bastian)
Date: Wed, 9 Feb 2005 19:17:41 +0100
Subject: Character encodings (UTF16)
In-Reply-To: <200502091701.37983.bastian@kde.org>
References: <200502091651.04347.amantia@kde.org>
	<200502091701.37983.bastian@kde.org>
Message-ID: <200502091917.46799.bastian@kde.org>

On Wednesday 09 February 2005 17:01, Waldo Bastian wrote:
> On Wednesday 09 February 2005 15:50, Andras Mantia wrote:
> > Hi,
> >
> >  I'm sending this to core-devel, as it affect many applications
> > including Kate (and everything using Katepart), KEdit, Konqueror and
> > maybe others. There seem to be a problem with dealing with certain
> > UTF16 encoded files. The question is whether the problem is in KDE/Qt
> > or the files in question are broken. Attached is a file that renders
> > fine in Firefox and Opera, the reporter says that it was saved in NVU,
> > while it shows up as garbage in Konqueror, Kate if opened as UTF16.  In
> > KEdit it's the same as in Kate when opened in UTF8 mode ("space" after
> > every character), while Konqueror in UTF8 mode shows the source.
> >  Does anybody know if this is a real problem (wrong handling of such
> > files) or it's a problem in the file itself? Certainly for the user it
> > looks like a real problem, especially that there are applications out
> > there that can work with the file. If I run a
> > "recode utf16LE..utf16 filename" on it, the resulted file can be opened
> > in every KDE application.
>
> I assume that the LE designation stands for "little endian" and that Qt
> defaults to "big endian". I believe one is supposed to insert a BOM (byte
> order mark) so that applications can guess correctly between utf16LE and
> utf16BE. The spaces that you see in utf8 mode are the NUL values from the
> high-bytes.
>
> I think it would be possible for konqueror to detect LE and BE by looking
> for "<NUL" versus "NUL<" and adjust accordingly. Would be easier if there
> was a separate "utf16le" codec.

Attached patch (khtml_utf16_endianness.patch) fixes Konqueror to correctly 
auto-detect the endianness.

Instead of relying on '<', it's perhaps nicer to have something slightly more 
generic approach, something like the following algorithm:

nulcount_even = number of nul's at the first 5 even positions
nulcount_odd = number of nul's at the first 5 odd positions
if (nulcount_even == 0 && nulcount_odd == 5) encoding = utf16LE;
if (nulcount_even == 5 && nulcount_odd == 0) encoding = utf16BE;

This basically relies on the fact that the first few characters in a html file 
will all be in the ASCII range.

The second patch does just that (khtml_utf16_endianness2.patch).

Please review.

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml_utf16_endianness.patch
Type: text/x-diff
Size: 2139 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050209/7780ece8/attachment.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml_utf16_endianness2.patch
Type: text/x-diff
Size: 3443 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050209/7780ece8/attachment-0001.patch>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050209/7780ece8/attachment.sig>

From thierry.blanc at gmx.ch  Wed Feb  9 19:54:34 2005
From: thierry.blanc at gmx.ch (Thierry Blanc)
Date: Wed, 09 Feb 2005 21:54:34 +0200
Subject: keywords: extensions, Mozilla archive Format, maff, konqueror, .war
Message-ID: <1107978874.6310.11.camel@localhost.localdomain>

keywords: extensions, Mozilla archive Format, maff, konqueror, .war

to whom it may concern


When trying to find a way for archiving web pages in single files I came
across the extension "Mozilla archive Format" and in Konqueror I found
the war (Web archive) format.

the probelm now is that if I browse my files in konqueror, the maff
files created with Mozilla need 3 clicks to be opened.

I would like to suggest a plug-in for konqueror to be able to open maff
files directly like the konqueror's own .war format.

In addition, a command line tool would be very nice to archive web-pages
already downloaded.

sincerely yours
Thierry Blanc

-- 
Thierry Blanc <thierry.blanc at gmx.ch>




From paul.temple at gmx.net  Wed Feb  9 21:24:42 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Wed, 9 Feb 2005 22:24:42 +0100
Subject: testregression khtml
Message-ID: <200502092224.42510.paul.temple@gmx.net>

Don't know, if it works. It already runs some minutes now, taking 
much cpu time. Yet I don't see a single PASS or FAIL in stdout 
as described in the README. In the beginning it printed some 
errors to stderr, but the last minutes nothing happens, except 
that the cpu is used by Xvfb excessively.

---------
Some of the errors on stderr:

_FontTransOpen: Unable to Parse 
address ../../khtmltests/regression/resources
Could not init font path 
element ../../khtmltests/regression/resources, removing from 
list!
Xlib:  extension "XInputExtension" missing on display ":47.0".
Failed to get list of devices
KApplication::dcopFailure
KApplication::dcopFailure
X Error: BadValue (integer parameter out of range for operation) 
2
  Major opcode:  53
  Minor opcode:  0
  Resource id:  0x8
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode:  55
  Minor opcode:  0
  Resource id:  0x20000f

< --- snap --- >

X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode:  73
  Minor opcode:  0
  Resource id:  0x20000f
QImage::scanLine: Index 0 out of range
_FontTransOpen: Unable to Parse 
address ../../khtmltests/regression/resources
Could not init font path 
element ../../khtmltests/regression/resources, removing from 
list!
KCrash: crashing... crashRecursionCounter = 2
KCrash: Application Name = lt-testregression path = <unknown> pid 
= 18569
Xlib:  extension "XInputExtension" missing on display ":47.0".
Failed to get list of devices
DCOP: register 'anonymous-18586' -> number of clients is now 1
DCOP: unregister 'anonymous-18586'
DCOP: register 'klauncher' -> number of clients is now 1
DCOP: new daemon klauncher
DCOP: register 'kded' -> number of clients is now 1
DCOP: unregister 'kded'
DCOP: register 'kded' -> number of clients is now 1
DCOP: register 'anonymous-18591' -> number of clients is now 2
Xlib:  extension "XInputExtension" missing on display ":47.0".
Failed to get list of devices
kio (KDirWatch): Can't use FAM (fam daemon not running?)
kio (KDirWatch): Available methods: Stat
DCOP: register 'kbuildsycoca' -> number of clients is now 3
kbuildsycoca running...
DCOP: register 'anonymous-18593' -> number of clients is now 4
DCOP: unregister 'anonymous-18593'
DCOP: unregister 'kbuildsycoca'
kio (KDirWatch): Added 
Dir /var/tmp/temple_non_existant/share/servicetypes 
[KDirWatch-1]
kio (KDirWatch): Global Poll Freq is now 500 msec
kio (KDirWatch):  Started Polling Timer, freq 500
kio (KDirWatch):  Setup Stat (freq 500) 
for /var/tmp/temple_non_existant/share/servicetypes
kio (KDirWatch): Added Dir /opt/kde3/share/servicetypes 
[KDirWatch-1]



From paul.temple at gmx.net  Wed Feb  9 22:13:36 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Wed, 9 Feb 2005 23:13:36 +0100
Subject: testregression khtml
In-Reply-To: <200502092224.42510.paul.temple@gmx.net>
References: <200502092224.42510.paul.temple@gmx.net>
Message-ID: <200502092313.37353.paul.temple@gmx.net>

Paul Temple wrote:
> Don't know, if it works. It already runs some minutes now,
> taking much cpu time. Yet I don't see a single PASS or FAIL in
> stdout as described in the README. In the beginning it printed
> some errors to stderr, but the last minutes nothing happens,
> except that the cpu is used by Xvfb excessively.

Didn't work. Or does it take hours before the first "PASS" or 
"FAIL"?
Anyone a hint for me?



From faure at kde.org  Wed Feb  9 22:39:12 2005
From: faure at kde.org (David Faure)
Date: Wed, 9 Feb 2005 23:39:12 +0100
Subject: testregression khtml
In-Reply-To: <200502092224.42510.paul.temple@gmx.net>
References: <200502092224.42510.paul.temple@gmx.net>
Message-ID: <200502092339.12816.faure@kde.org>

> KCrash: Application Name = lt-testregression path = <unknown> pid 

It crashed - you can't expect much after that :/

Check for a core file, or export KDE_DEBUG=1 and re-run it to get one....

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From koos.vriezen at xs4all.nl  Wed Feb  9 22:57:07 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Wed, 9 Feb 2005 23:57:07 +0100
Subject: patch to bug 82243: cannot dynamically add applets...
In-Reply-To: <200502091616.08925.l.savernik@aon.at>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502081911.18051.faure@kde.org>
	<200502090438.30679.paul.temple@gmx.net>
	<200502091616.08925.l.savernik@aon.at>
Message-ID: <20050209225707.GD41458@xs4all.nl>

On Wed, Feb 09, 2005 at 04:16:00PM +0100, Leo Savernik wrote:
> Am Mittwoch, 9. Februar 2005 04:38 schrieb Paul Temple:
> > On Tuesday 08 February 2005 19:11, David Faure wrote:
> > > > I guess you should look at the htmltests cvs module.
> > >
> > > cvs co khtmltests, to be more precise (at least  cvs co
> > > khtmltests/regression) Then "make testregression" in
> > > kdelibs/khtml, then running it. Which reminds me that I just
> > > noticed some regressions in tests/ecma... I'll fix those.
> >
> > I guess that's the same as What about
> > kdelibs/khtml/test_regression.cpp when checking out kdelibs,
> > isn't it? I checked out the whole kdelibs anyway...
> 
> Not quite.
> - kdelibs/khtml/testregression is the application that runs the regression 
> tests, and generates respective output.
> - khtmltests/regression contains all the regression testcases themselves.
> 
> In fact, you need both for regression testing.

Can you elaborate on this? Is this documented how to build an run this?
If not, how does one build and run it?

Koos



From paul.temple at gmx.net  Thu Feb 10 00:39:38 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 01:39:38 +0100
Subject: cssRules / ID selectors
Message-ID: <200502100139.38643.paul.temple@gmx.net>

In konqueror (and other browsers) you can get access to an CSS 
selector text from JS by using
  document.styleSheets[i].cssRules[j].selectorText

When using an ID selector that starts with a '#' like this
  #helloWorld { ... }
the property "document.styleSheets[i].cssRules[j].selectorText" 
returns
  *[id"helloWorld"]

However, in an earlier version konqueror returned
  /a[id"helloWorld"]

And IE and NS browsers return the plain
  #helloWorld

I should note that the following warning message (defined in 
css_base.cpp) is displayed for every ID selectors:
WARNING: Unhandled case in CSSStyleRuleImpl::selectorText : 
match=1

Now my questions: Why and when did that change and is it likely 
to change again in the future? (A web designer wants to rely on 
this... as he can with the other browsers)



From paul.temple at gmx.net  Thu Feb 10 01:02:26 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 02:02:26 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502100139.38643.paul.temple@gmx.net>
References: <200502100139.38643.paul.temple@gmx.net>
Message-ID: <200502100202.26792.paul.temple@gmx.net>

Paul Temple wrote:
> When using an ID selector that starts with a '#' like this
>   #helloWorld { ... }

Remark: When using ID selectors _not_ starting with a '#' like 
this:
  h1#helloWorld { ... }
then "document.styleSheets[i].cssRules[j].selectorText" returns
  h1[id"helloWord"]
(But the "WARNING: Unhandled case ..." is displayed here, too)

And now I somehow understand the change from "/a" to "*"...

But CSSSelector::selectorText() in css_base.cpp, which (I think) 
is responsible for that, didn't change much since v1.1 
(2003-01-13), so I don't understand how it could change. Or it 
changed, before css_base.cpp was created...

So my only remaining question is: Will it change in the future? 
(As IE and NS both use "h1#helloWorld")



From paul.temple at gmx.net  Thu Feb 10 01:22:09 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 02:22:09 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502100202.26792.paul.temple@gmx.net>
References: <200502100139.38643.paul.temple@gmx.net>
	<200502100202.26792.paul.temple@gmx.net>
Message-ID: <200502100222.09604.paul.temple@gmx.net>

Remark #2:

konqueror transforms
  CSS: h1#helloWorld:hover { ... }
to
  h1[id"helloWorld"]/a:hover

Why? Are there any rules or is this undefined and may change with 
new versions of khtml?

In NS it is, as expected: h1#helloWorld:hover



From coolo at kde.org  Thu Feb 10 08:28:37 2005
From: coolo at kde.org (Stephan Kulow)
Date: Thu, 10 Feb 2005 09:28:37 +0100
Subject: testregression khtml
In-Reply-To: <200502092224.42510.paul.temple@gmx.net>
References: <200502092224.42510.paul.temple@gmx.net>
Message-ID: <200502100928.38433.coolo@kde.org>

Am Wednesday 09 February 2005 22:24 schrieb Paul Temple:
> address ../../khtmltests/regression/resources
> Could not init font path

I think using a relative path here was a bad decision. But this might
only be one problem.

Greetings, Stephan



From paul.temple at gmx.net  Thu Feb 10 10:40:22 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 11:40:22 +0100
Subject: testregression khtml
In-Reply-To: <200502092339.12816.faure@kde.org>
References: <200502092224.42510.paul.temple@gmx.net>
	<200502092339.12816.faure@kde.org>
Message-ID: <200502101140.22923.paul.temple@gmx.net>

> It crashed - you can't expect much after that :/
>
> Check for a core file, or export KDE_DEBUG=1 and re-run it to
> get one....

did that and used an absolute path. stderr:

Xlib:  extension "XInputExtension" missing on display ":47.0".
Failed to get list of devices
KApplication::dcopFailure
KApplication::dcopFailure
X Error: BadValue (integer parameter out of range for operation) 
2
  Major opcode:  53
  Minor opcode:  0
  Resource id:  0x8
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode:  55
  Minor opcode:  0
  Resource id:  0x20000f
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode:  72
  Minor opcode:  0
  Resource id:  0x20000f
X Error: BadGC (invalid GC parameter) 13
  Major opcode:  60
  Minor opcode:  0
  Resource id:  0x200010
X Error: BadDrawable (invalid Pixmap or Window parameter) 9
  Major opcode:  73
  Minor opcode:  0
  Resource id:  0x20000f
QImage::scanLine: Index 0 out of range
Segmentation fault



From porten at froglogic.com  Thu Feb 10 10:44:24 2005
From: porten at froglogic.com (Harri Porten)
Date: Thu, 10 Feb 2005 11:44:24 +0100 (CET)
Subject: testregression khtml
In-Reply-To: <200502101140.22923.paul.temple@gmx.net>
References: <200502101140.22923.paul.temple@gmx.net>
Message-ID: <Pine.LNX.4.44.0502101143010.27363-100000@alster.froglogic.com>

On Thu, 10 Feb 2005, Paul Temple wrote:

> X Error: BadDrawable (invalid Pixmap or Window parameter) 9
>   Major opcode:  73
>   Minor opcode:  0
>   Resource id:  0x20000f
> QImage::scanLine: Index 0 out of range
> Segmentation fault

This is with Xvfb, right? My experiences with this server are not so
positive. At least my version was lacking the implementation of some
features and was unusable for more than trivial GUI apps.

Harri.




From paul.temple at gmx.net  Thu Feb 10 10:51:08 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 11:51:08 +0100
Subject: testregression khtml
In-Reply-To: <Pine.LNX.4.44.0502101143010.27363-100000@alster.froglogic.com>
References: <Pine.LNX.4.44.0502101143010.27363-100000@alster.froglogic.com>
Message-ID: <200502101151.08457.paul.temple@gmx.net>

> This is with Xvfb, right? My experiences with this server are

Yep.

> not so positive. At least my version was lacking the
> implementation of some features and was unusable for more than
> trivial GUI apps.

Do you perform the html regression test with another server?



From l.savernik at aon.at  Thu Feb 10 16:02:11 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Thu, 10 Feb 2005 17:02:11 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502100202.26792.paul.temple@gmx.net>
References: <200502100139.38643.paul.temple@gmx.net>
	<200502100202.26792.paul.temple@gmx.net>
Message-ID: <200502101702.17613.l.savernik@aon.at>

Am Donnerstag, 10. Februar 2005 02:02 schrieb Paul Temple:
> Paul Temple wrote:
> > When using an ID selector that starts with a '#' like this
> >   #helloWorld { ... }
>
> Remark: When using ID selectors _not_ starting with a '#' like
> this:
>   h1#helloWorld { ... }
> then "document.styleSheets[i].cssRules[j].selectorText" returns
>   h1[id"helloWord"]
> (But the "WARNING: Unhandled case ..." is displayed here, too)

Because it's exactly that, unhandled. Note that there's no assignment between 
the attribute and the value -> illegal CSS -> bug -> should be fixed -> will 
change in the future.
>
[...]

Will you come up with a patch?

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050210/140b659f/attachment.sig>

From paul.temple at gmx.net  Thu Feb 10 16:02:56 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 17:02:56 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502101702.17613.l.savernik@aon.at>
References: <200502100139.38643.paul.temple@gmx.net>
	<200502100202.26792.paul.temple@gmx.net>
	<200502101702.17613.l.savernik@aon.at>
Message-ID: <200502101702.56868.paul.temple@gmx.net>

Leo Savernik wrote:
> Am Donnerstag, 10. Februar 2005 02:02 schrieb Paul Temple:
> > Paul Temple wrote:
> > > When using an ID selector that starts with a '#' like this
> > >   #helloWorld { ... }
> >
> > Remark: When using ID selectors _not_ starting with a '#'
> > like this:
> >   h1#helloWorld { ... }
> > then "document.styleSheets[i].cssRules[j].selectorText"
> > returns h1[id"helloWord"]
> > (But the "WARNING: Unhandled case ..." is displayed here,
> > too)
>
> Because it's exactly that, unhandled. Note that there's no
> assignment between the attribute and the value -> illegal CSS
> -> bug -> should be fixed -> will change in the future.

What is illegal CSS? ID selectors? See
http://www.w3.org/TR/REC-CSS2/selector.html#id-selectors

Or the access to ID selectors via cssRules?

> Will you come up with a patch?

When I know more about the whys and whens, then maybe.



From l.savernik at aon.at  Thu Feb 10 16:13:47 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Thu, 10 Feb 2005 17:13:47 +0100
Subject: testregression usage mini howto
In-Reply-To: <20050209225707.GD41458@xs4all.nl>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502091616.08925.l.savernik@aon.at>
	<20050209225707.GD41458@xs4all.nl>
Message-ID: <200502101713.47742.l.savernik@aon.at>

Am Mittwoch, 9. Februar 2005 23:57 schrieb Koos Vriezen:
[...]
> > - kdelibs/khtml/testregression is the application that runs the
> > regression tests, and generates respective output.
> > - khtmltests/regression contains all the regression testcases themselves.
> >
> > In fact, you need both for regression testing.
>
> Can you elaborate on this? Is this documented how to build an run this?
> If not, how does one build and run it?
>
> Koos

Ok, here's a mini-howto on running the khtml regression tests:

Prerequisites: KDE HEAD compiles and runs.

1. From within kdelibs/khtml, issue

 make testregression

2. If necessary, update regression testsuite

 cd <testsuite-prefix>/khtmltests/regression
 cvs up

3. Run the regression tests (using the X-server you're currently running 
under, no Xvfb/Xnest hackery) with

 <prefix-to-kde-cvs-build-dir>/kdelibs/khtml/testregression 
<testsuite-prefix>/khtmltests/regression | tee <regression-logfile>

This will write errors to stderr, and the passed/failed messages into 
<regression-logfile>. The html-output is put under 
<testsuite-prefix>/khtmltests/regression/output by default.

That's it. The -o option comes in handy for directing the regression test 
output into another directly. That way you can compare the results of two 
test runs.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050210/cbfc1f9c/attachment.sig>

From coolo at kde.org  Thu Feb 10 16:29:23 2005
From: coolo at kde.org (Stephan Kulow)
Date: Thu, 10 Feb 2005 17:29:23 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502101713.47742.l.savernik@aon.at>
References: <200502080157.24014.paul.temple@gmx.net>
	<20050209225707.GD41458@xs4all.nl>
	<200502101713.47742.l.savernik@aon.at>
Message-ID: <200502101729.24639.coolo@kde.org>

Am Thursday 10 February 2005 17:13 schrieb Leo Savernik:
> 3. Run the regression tests (using the X-server you're currently running 
> under, no Xvfb/Xnest hackery) with
That's easier said than done as testregression automatically starts a 
Xvfb and sets the DISPLAY to use it :)

Greetings, Stephan



From paul.temple at gmx.net  Thu Feb 10 17:24:59 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 18:24:59 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502101702.17613.l.savernik@aon.at>
References: <200502100139.38643.paul.temple@gmx.net>
	<200502100202.26792.paul.temple@gmx.net>
	<200502101702.17613.l.savernik@aon.at>
Message-ID: <200502101824.59394.paul.temple@gmx.net>

Leo Savernik wrote:
> Because it's exactly that, unhandled. Note that there's no
> assignment between the attribute and the value -> illegal CSS
> -> bug -> should be fixed -> will change in the future.

Ah, just reread your mail... Think I misinterpreted your mail 
when first reading it (you may have noticed when reading my 
answer...;).

To be sure I understand you right this time: I could post a patch 
that makes konqueror behave just like ms and ns browsers in the 
case of id selectors (and it will be applied if the patch is 
ok). Right?



From l.savernik at aon.at  Thu Feb 10 17:35:50 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Thu, 10 Feb 2005 18:35:50 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502101702.56868.paul.temple@gmx.net>
References: <200502100139.38643.paul.temple@gmx.net>
	<200502101702.17613.l.savernik@aon.at>
	<200502101702.56868.paul.temple@gmx.net>
Message-ID: <200502101835.55932.l.savernik@aon.at>

Am Donnerstag, 10. Februar 2005 17:02 schrieb Paul Temple:
> What is illegal CSS? ID selectors? See
> http://www.w3.org/TR/REC-CSS2/selector.html#id-selectors
>
> Or the access to ID selectors via cssRules?

Sure. h1[id"helloWord"] is arguably illegal css. Though the grammar allows it, 
the semantics of such a selector is undefined.
>
[...]

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050210/90ffb779/attachment.sig>

From koos.vriezen at xs4all.nl  Thu Feb 10 18:16:50 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Thu, 10 Feb 2005 19:16:50 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502101713.47742.l.savernik@aon.at>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502091616.08925.l.savernik@aon.at>
	<20050209225707.GD41458@xs4all.nl>
	<200502101713.47742.l.savernik@aon.at>
Message-ID: <20050210181650.GB26842@xs4all.nl>

On Thu, Feb 10, 2005 at 05:13:47PM +0100, Leo Savernik wrote:
> 1. From within kdelibs/khtml, issue

Exactly what I did, but:

g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../dcop -I../kdecore -I../kio/kssl -I../kjs -I../kimgio -I./java -I../dcop -I./misc -I./dom -I./xml -I./html -I./css -I../libltdl -I../kio/kssl -I../kio/kssl -I../kdeprint -I../interfaces -I../interfaces/kregexpeditor -I../kwallet/client -I../kutils -I.. -I../dcop -I../libltdl -I../kdefx -I../kdecore -I../kdecore -I../kdeui -I../kio -I../kio/kio -I../kio/kfile -I.. -I/opt/kde-cvs/qt/include -I/usr/X11R6/include -I/opt/kde-cvs/kde3/include   -DQT_THREAD_SUPPORT  -D_REENTRANT  -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -march=pentium4 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -fno-exceptions -fno-check-new -fno-common  -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
  -DQT_NO_TRANSLATION  -c -o testregression.all_cpp.o `test -
f 'testregression.all_cpp.cpp' || echo './'`testregression.all_cpp.cpp
In file included from /opt/kde-cvs/qt/include/private/qt_x11_p.h:66,
                 from /opt/kde-cvs/qt/include/private/qfontengine_p.h:282,
                 from test_regression_fontoverload.cpp:26,
                 from testregression.all_cpp.cpp:3:
/usr/X11R6/include/X11/Xlib.h:219: error: `Font' does not name a type
/usr/X11R6/include/X11/Xlib.h:280: error: `Window' does not name a type
/usr/X11R6/include/X11/Xlib.h:334: error: `Window' does not name a type
/usr/X11R6/include/X11/Xlib.h:353: error: ISO C++ forbids declaration of `Screen' with no type
/usr/X11R6/include/X11/Xlib.h:353: error: expected `;' before '*' token
/usr/X11R6/include/X11/Xlib.h:422: error: `Window' does not name a type
/usr/X11R6/include/X11/Xlib.h:559: error: ISO C++ forbids declaration of `Screen' with no type
................ lots more .............

made me wondor if this was the thing to do. Looking now at these errors is
likely be the enable-final I always use (adding fixx11h.h include at
test_regression_fontoverload.cpp:27 unfortunately doesn't help). Ok I'll
try it when compiling w/o enable-final one day.

Thanks for your info. This should really be documented somewhere, no (eg a
testregression.readme or so)?

Koos



From l.savernik at aon.at  Thu Feb 10 19:03:40 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Thu, 10 Feb 2005 20:03:40 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502101824.59394.paul.temple@gmx.net>
References: <200502100139.38643.paul.temple@gmx.net>
	<200502101702.17613.l.savernik@aon.at>
	<200502101824.59394.paul.temple@gmx.net>
Message-ID: <200502102003.41359.l.savernik@aon.at>

Am Donnerstag, 10. Februar 2005 18:24 schrieb Paul Temple:
> To be sure I understand you right this time: I could post a patch
> that makes konqueror behave just like ms and ns browsers in the
> case of id selectors (and it will be applied if the patch is
> ok). Right?

Yes, that would be nice :-)

mfg
 Leo



From germain at ebooksfrance.org  Thu Feb 10 19:20:54 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Thu, 10 Feb 2005 19:20:54 +0000
Subject: testregression usage mini howto
In-Reply-To: <200502101729.24639.coolo@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502101713.47742.l.savernik@aon.at>
	<200502101729.24639.coolo@kde.org>
Message-ID: <200502101920.54600.germain@ebooksfrance.org>

Le jeudi 10 Février 2005 16:29, Stephan Kulow a écrit :
> Am Thursday 10 February 2005 17:13 schrieb Leo Savernik:
> > 3. Run the regression tests (using the X-server you're currently running
> > under, no Xvfb/Xnest hackery) with
>
> That's easier said than done as testregression automatically starts a
> Xvfb and sets the DISPLAY to use it :)
>

Hi Stephan, 
speaking about it... 
is it on purpose that current baseline doesn't use the Ahem font?
see e.g
http://tmp.ebooksfrance.org/~devel/khtmltests/regression/output/webcore/fast/text/whitespace/002.html-compare.html

I also have problems with testcases using serif fonts, that are not serif in 
baseline:
http://tmp.ebooksfrance.org/~devel/khtmltests/regression/output/css1/test5525d.htm-compare.html

Greetings,
Germain



From l.savernik at aon.at  Thu Feb 10 19:20:22 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Thu, 10 Feb 2005 20:20:22 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502101729.24639.coolo@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502101713.47742.l.savernik@aon.at>
	<200502101729.24639.coolo@kde.org>
Message-ID: <200502102020.23024.l.savernik@aon.at>

Am Donnerstag, 10. Februar 2005 17:29 schrieb Stephan Kulow:
> Am Thursday 10 February 2005 17:13 schrieb Leo Savernik:
> > 3. Run the regression tests (using the X-server you're currently running
> > under, no Xvfb/Xnest hackery) with
>
> That's easier said than done as testregression automatically starts a
> Xvfb and sets the DISPLAY to use it :)

Now that you mention it, I realised it, too.

And it somehow ... seems to work for me :-)

mfg
 Leo



From kde at carewolf.com  Thu Feb 10 19:41:20 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Thu, 10 Feb 2005 20:41:20 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502101713.47742.l.savernik@aon.at>
References: <200502080157.24014.paul.temple@gmx.net>
	<20050209225707.GD41458@xs4all.nl>
	<200502101713.47742.l.savernik@aon.at>
Message-ID: <200502102041.20306.kde@carewolf.com>

On Thursday 10 February 2005 17:13, Leo Savernik wrote:
>
> Ok, here's a mini-howto on running the khtml regression tests:
>
> Prerequisites: KDE HEAD compiles and runs.
>
And a recent Xorg. XFree86 will not run the recent xvfb hackery. For instance 
I can no longer run testregression because I use Debian.

`Allan



From paul.temple at gmx.net  Thu Feb 10 19:46:26 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 20:46:26 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502102041.20306.kde@carewolf.com>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502101713.47742.l.savernik@aon.at>
	<200502102041.20306.kde@carewolf.com>
Message-ID: <200502102046.26269.paul.temple@gmx.net>

> And a recent Xorg. XFree86 will not run the recent xvfb
> hackery. For instance I can no longer run testregression
> because I use Debian.

Maybe that xorg / xfree mix is the reason that testregression 
doesn't work on my machine, too... (SuSE 9.0 + SuSE xorg 
updates)



From koos.vriezen at xs4all.nl  Thu Feb 10 19:50:00 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Thu, 10 Feb 2005 20:50:00 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502102041.20306.kde@carewolf.com>
References: <200502080157.24014.paul.temple@gmx.net>
	<20050209225707.GD41458@xs4all.nl>
	<200502101713.47742.l.savernik@aon.at>
	<200502102041.20306.kde@carewolf.com>
Message-ID: <20050210195000.GC26842@xs4all.nl>

On Thu, Feb 10, 2005 at 08:41:20PM +0100, Allan Sandfeld Jensen wrote:
> On Thursday 10 February 2005 17:13, Leo Savernik wrote:
> >
> > Ok, here's a mini-howto on running the khtml regression tests:
> >
> > Prerequisites: KDE HEAD compiles and runs.
> >
> And a recent Xorg. XFree86 will not run the recent xvfb hackery. For instance 
> I can no longer run testregression because I use Debian.

That will save me a recompile of kdelibs ...

Koos



From paul.temple at gmx.net  Thu Feb 10 22:13:26 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 23:13:26 +0100
Subject: [patch] to bug 88243
Message-ID: <200502102313.26530.paul.temple@gmx.net>

After spending many hours getting familiar with khtml - I really 
miss eclipse/java, I would have been able to do the same I did 
with kdevelop/c++ in one hour instead of 30, I guess :( - I dare 
to send a patch... Thanks for all the help in this list.

I think, the check
  if (!myNode->handle()->closed())
is not necessary, as nodes that are created via ecma/dom 
(document.createElement(..)) are never closed by khtml

I did not run testregression as it does not work for me. But I 
think this patch is almost "keyhole surgery" and don't expect 
problems out of it, in contrary to my first proposal - which was 
the reason I didn't send a patch at that time... But I still 
don't know khtml enough to be sure about that.

Any objections?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 88243.patch
Type: text/x-diff
Size: 1656 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050210/d7b37d6f/attachment.patch>

From paul.temple at gmx.net  Thu Feb 10 22:17:44 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Thu, 10 Feb 2005 23:17:44 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502102313.26530.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
Message-ID: <200502102317.44503.paul.temple@gmx.net>

Please use this patch as the other one won't compile (I forgot 
some braces after copy-pasting)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 88243.patch
Type: text/x-diff
Size: 1740 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050210/4f591a8c/attachment.patch>

From koos.vriezen at xs4all.nl  Thu Feb 10 23:08:42 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 00:08:42 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502102317.44503.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502102317.44503.paul.temple@gmx.net>
Message-ID: <20050210230842.GA59712@xs4all.nl>

On Thu, Feb 10, 2005 at 11:17:44PM +0100, Paul Temple wrote:
> Please use this patch as the other one won't compile (I forgot 
> some braces after copy-pasting)

Are you sure this compiles w/o warningsss?

-    case DOMNode::AppendChild:
-      return getDOMNode(exec,node.appendChild(toNode(args[0])));
+    case DOMNode::AppendChild: {
+      Node* myNode = &(toNode(args[0]));
+      Value* gdNode = &(getDOMNode(exec,node.appendChild(*myNode)));
+      if (!myNode->handle()->closed()) myNode->handle()->close();
+      return *gdNode;
+    }

Looks to me you take an adress of a temporary with
  Node* myNode = &(toNode(args[0]));
that should be written as
  Node myNode = toNode(args[0]);
which also looks a lot less scary :-)

Koos



From paul.temple at gmx.net  Thu Feb 10 23:16:35 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 00:16:35 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050210230842.GA59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502102317.44503.paul.temple@gmx.net>
	<20050210230842.GA59712@xs4all.nl>
Message-ID: <200502110016.36093.paul.temple@gmx.net>

> Looks to me you take an adress of a temporary with
>   Node* myNode = &(toNode(args[0]));
> that should be written as
>   Node myNode = toNode(args[0]);
> which also looks a lot less scary :-)

Yes, there are warnings, but _I_ (unlike the compiler) know that 
I don't do any harm... :)

I wrote that with my little c++ knowledge... I thought that
"Node myNode" would allocate memory which was not necessary as 
this is done in "toNode(..)" anyway.

Why does 
>   Node myNode = toNode(args[0]);
look scary? Does it allocate never used memory or not?



From koos.vriezen at xs4all.nl  Thu Feb 10 23:25:28 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 00:25:28 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110016.36093.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502102317.44503.paul.temple@gmx.net>
	<20050210230842.GA59712@xs4all.nl>
	<200502110016.36093.paul.temple@gmx.net>
Message-ID: <20050210232528.GB59712@xs4all.nl>

On Fri, Feb 11, 2005 at 12:16:35AM +0100, Paul Temple wrote:
> > Looks to me you take an adress of a temporary with
> >   Node* myNode = &(toNode(args[0]));
> > that should be written as
> >   Node myNode = toNode(args[0]);
> > which also looks a lot less scary :-)
> 
> Yes, there are warnings, but _I_ (unlike the compiler) know that 
> I don't do any harm... :)

And I know that you do :-)
toNode returns a DOM::Node, that's an object. This object is immediately
destroyed after the assignment (the = operation). So you end with an
adress of an deleted object. If written as 'Node myNode = toNode' it
creates a new object with the returned object of toNode as argument
(that's the copy contructor 'Node(const Node & other)'.

Actually now that I'm thinking about this, you never should take an
address of a returned value other than that a function returns a
reference, eg 'MyObject& myfunct() { return myobject; }'

> I wrote that with my little c++ knowledge... I thought that
> "Node myNode" would allocate memory which was not necessary as 
> this is done in "toNode(..)" anyway.

Yes, but that one gets destroyed.

> Why does 
> >   Node myNode = toNode(args[0]);
> look scary? Does it allocate never used memory or not?

less scary you mean. Because of the above explaination.

Koos



From paul.temple at gmx.net  Fri Feb 11 00:00:10 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 01:00:10 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050210232528.GB59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110016.36093.paul.temple@gmx.net>
	<20050210232528.GB59712@xs4all.nl>
Message-ID: <200502110100.10644.paul.temple@gmx.net>

Koos Vriezen wrote:
> On Fri, Feb 11, 2005 at 12:16:35AM +0100, Paul Temple wrote:
> > > Looks to me you take an adress of a temporary with
> > >   Node* myNode = &(toNode(args[0]));
> > > that should be written as
> > >   Node myNode = toNode(args[0]);
> > > which also looks a lot less scary :-)
> >
> > Yes, there are warnings, but _I_ (unlike the compiler) know
> > that I don't do any harm... :)
>
> And I know that you do :-)
> toNode returns a DOM::Node, that's an object. This object is
> immediately destroyed after the assignment (the = operation).

Hm, I'll read a chapter about that - though it was totally 
different...

Attached a revised patch
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 88243.patch
Type: text/x-diff
Size: 1688 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/693cad93/attachment.patch>

From koos.vriezen at xs4all.nl  Fri Feb 11 00:06:22 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 01:06:22 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110100.10644.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110016.36093.paul.temple@gmx.net>
	<20050210232528.GB59712@xs4all.nl>
	<200502110100.10644.paul.temple@gmx.net>
Message-ID: <20050211000622.GC59712@xs4all.nl>

On Fri, Feb 11, 2005 at 01:00:10AM +0100, Paul Temple wrote:
> Koos Vriezen wrote:
> > On Fri, Feb 11, 2005 at 12:16:35AM +0100, Paul Temple wrote:
> > > > Looks to me you take an adress of a temporary with
> > > >   Node* myNode = &(toNode(args[0]));
> > > > that should be written as
> > > >   Node myNode = toNode(args[0]);
> > > > which also looks a lot less scary :-)
> > >
> > > Yes, there are warnings, but _I_ (unlike the compiler) know
> > > that I don't do any harm... :)
> >
> > And I know that you do :-)
> > toNode returns a DOM::Node, that's an object. This object is
> > immediately destroyed after the assignment (the = operation).
> 
> Hm, I'll read a chapter about that - though it was totally 
> different...

Burn it then

> Attached a revised patch

I leave that to the khtml guru's to comment. I do suspect that checking
for 'node->handle()' is one of them in case append/remove/replace fails.


Koos



From paul.temple at gmx.net  Fri Feb 11 00:13:02 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 01:13:02 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211000622.GC59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110100.10644.paul.temple@gmx.net>
	<20050211000622.GC59712@xs4all.nl>
Message-ID: <200502110113.03113.paul.temple@gmx.net>

> > Hm, I'll read a chapter about that - though it was totally
> > different...
>
> Burn it then

I wanted to say (forgot a 't') : "I will read a chapter about 
that, since I thought it was totally different than you 
explained"



From koos.vriezen at xs4all.nl  Fri Feb 11 00:56:45 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 01:56:45 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110155.12247.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110142.22851.paul.temple@gmx.net>
	<20050211005121.GD59712@xs4all.nl>
	<200502110155.12247.paul.temple@gmx.net>
Message-ID: <20050211005645.GF59712@xs4all.nl>

On Fri, Feb 11, 2005 at 01:55:12AM +0100, Paul Temple wrote:
> Koos Vriezen wrote:
> > One nitpick though, why do you declare
> >   Value gdNode = getDOMNode(exec,node.appendChild(myNode));
> > and only use it for the return. Why not
> >   return getDOMNode(exec,node.appendChild(myNode));
> > ? That saves one Value construction.
> 
> I wanted to close that thing _after_ adding it, just to be safe. 
> The khtml gurus can probably tell me if this is really 
> necessary.

Sorry my fault, this is correct. It would definitly be wrong to close it
before attaching.

Koos



From koos.vriezen at xs4all.nl  Fri Feb 11 01:08:06 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 02:08:06 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110204.38572.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110155.12247.paul.temple@gmx.net>
	<20050211005645.GF59712@xs4all.nl>
	<200502110204.38572.paul.temple@gmx.net>
Message-ID: <20050211010806.GG59712@xs4all.nl>

On Fri, Feb 11, 2005 at 02:04:38AM +0100, Paul Temple wrote:
> If David says "looks good" it means: "Go ahead and commit". 
> Right? Just want to be sure...

I certainly would. Note khtml/ecma is also known as David Faure :-)

Koos



From paul.temple at gmx.net  Fri Feb 11 00:55:12 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 01:55:12 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211005121.GD59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110142.22851.paul.temple@gmx.net>
	<20050211005121.GD59712@xs4all.nl>
Message-ID: <200502110155.12247.paul.temple@gmx.net>

Koos Vriezen wrote:
> One nitpick though, why do you declare
>   Value gdNode = getDOMNode(exec,node.appendChild(myNode));
> and only use it for the return. Why not
>   return getDOMNode(exec,node.appendChild(myNode));
> ? That saves one Value construction.

I wanted to close that thing _after_ adding it, just to be safe. 
The khtml gurus can probably tell me if this is really 
necessary.



From paul.temple at gmx.net  Fri Feb 11 00:42:22 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 01:42:22 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110133.46267.faure@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110133.46267.faure@kde.org>
Message-ID: <200502110142.22851.paul.temple@gmx.net>

David Faure wrote:
> The bug number is wrong - 88243 is "Desktop sharing fails with
> diskless X terminals".... Ah, you meant 82243.

Thanks... I'll check the number once again before committing :)

> Oh. Final patch looks good.
> As Koos said, I would check for handle() not being null
> though.

Then it's OK committing the attached patch?

C++ checks the "if (x && y)" from left to right (like Java does), 
right?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 88243.patch
Type: text/x-diff
Size: 1745 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/f5baa264/attachment.patch>

From koos.vriezen at xs4all.nl  Fri Feb 11 00:53:47 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 01:53:47 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211005121.GD59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110133.46267.faure@kde.org>
	<200502110142.22851.paul.temple@gmx.net>
	<20050211005121.GD59712@xs4all.nl>
Message-ID: <20050211005347.GE59712@xs4all.nl>

On Fri, Feb 11, 2005 at 01:51:21AM +0100, Koos Vriezen wrote:
> On Fri, Feb 11, 2005 at 01:42:22AM +0100, Paul Temple wrote:
> > David Faure wrote:
> > > The bug number is wrong - 88243 is "Desktop sharing fails with
> > > diskless X terminals".... Ah, you meant 82243.
> > 
> > Thanks... I'll check the number once again before committing :)
> > 
> > > Oh. Final patch looks good.
> > > As Koos said, I would check for handle() not being null
> > > though.
> > 
> > Then it's OK committing the attached patch?
> > 
> > C++ checks the "if (x && y)" from left to right (like Java does), 
> > right?
> 
> Yes, like java lazy from left to right.
> 
> One nitpick though, why do you declare
>   Value gdNode = getDOMNode(exec,node.appendChild(myNode));
> and only use it for the return. Why not
>   return getDOMNode(exec,node.appendChild(myNode));
> ? That saves one Value construction.

Agh, how silly of me. That does the appending of course. Ignore my
nitpick

Koos



From paul.temple at gmx.net  Fri Feb 11 01:22:36 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 02:22:36 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110207.16251.faure@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110204.38572.paul.temple@gmx.net>
	<200502110207.16251.faure@kde.org>
Message-ID: <200502110222.36277.paul.temple@gmx.net>

David Faure wrote:
> What would be good would be if you could commit a test into
> khtmltests/regressions/tests and its baseline.

This seems to be non-trivial. So many directories - I don't even 
know where to put a new test. And after stealing a glance at the 
contents of the html files it seems they need special js calls.

Is there a docu or how can I learn "khtmltest/regression"?



From paul.temple at gmx.net  Fri Feb 11 00:57:49 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 01:57:49 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211005347.GE59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211005121.GD59712@xs4all.nl>
	<20050211005347.GE59712@xs4all.nl>
Message-ID: <200502110157.49782.paul.temple@gmx.net>

Koos Vriezen wrote:
> Agh, how silly of me. That does the appending of course.

It's nice to see I'm not the only silly one... ;)



From paul.temple at gmx.net  Fri Feb 11 01:04:38 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 02:04:38 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211005645.GF59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502110155.12247.paul.temple@gmx.net>
	<20050211005645.GF59712@xs4all.nl>
Message-ID: <200502110204.38572.paul.temple@gmx.net>

If David says "looks good" it means: "Go ahead and commit". 
Right? Just want to be sure...



From faure at kde.org  Fri Feb 11 01:07:15 2005
From: faure at kde.org (David Faure)
Date: Fri, 11 Feb 2005 02:07:15 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110204.38572.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211005645.GF59712@xs4all.nl>
	<200502110204.38572.paul.temple@gmx.net>
Message-ID: <200502110207.16251.faure@kde.org>

On Friday 11 February 2005 02:04, Paul Temple wrote:
> If David says "looks good" it means: "Go ahead and commit". 
> Right? Just want to be sure...

Yes, go ahead :)

What would be good would be if you could commit a test into khtmltests/regressions/tests
and its baseline.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From paul.temple at gmx.net  Fri Feb 11 03:30:42 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 04:30:42 +0100
Subject: [patch] Re: cssRules / ID selectors
Message-ID: <200502110430.42518.paul.temple@gmx.net>

Do you agree that the lines I changed in the patch are wrong in 
the repository?

With that patch the
  E#myid
selectors work as (I guess) they should.

Still
  E#myid:xyz
won't work (=>is transformed to "E#myid/a:xyz"). If "the list" 
confirms that my patch is ok, I'll address that separately.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: idsel.patch
Type: text/x-diff
Size: 981 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/fe6b9724/attachment.patch>

From coolo at kde.org  Fri Feb 11 08:49:41 2005
From: coolo at kde.org (Stephan Kulow)
Date: Fri, 11 Feb 2005 09:49:41 +0100
Subject: testregression usage mini howto
In-Reply-To: <20050210181650.GB26842@xs4all.nl>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502101713.47742.l.savernik@aon.at>
	<20050210181650.GB26842@xs4all.nl>
Message-ID: <200502110949.43340.coolo@kde.org>

Am Thursday 10 February 2005 19:16 schrieb Koos Vriezen:
> likely be the enable-final I always use (adding fixx11h.h include at
> test_regression_fontoverload.cpp:27 unfortunately doesn't help). Ok I'll
Taking that the error happend at :26 it is likely it didn't help :)

Greetings, Stephan



From coolo at kde.org  Fri Feb 11 08:53:53 2005
From: coolo at kde.org (Stephan Kulow)
Date: Fri, 11 Feb 2005 09:53:53 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502101920.54600.germain@ebooksfrance.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502101729.24639.coolo@kde.org>
	<200502101920.54600.germain@ebooksfrance.org>
Message-ID: <200502110953.55484.coolo@kde.org>

Am Thursday 10 February 2005 20:20 schrieb Germain Garand:
 
> Hi Stephan, 
> speaking about it... 
> is it on purpose that current baseline doesn't use the Ahem font?
> see e.g
> http://tmp.ebooksfrance.org/~devel/khtmltests/regression/output/webcore/fast/text/whitespace/002.html-compare.html
Hmm, it does for the major parts. Not sure why 002 is an exceptions here. It doesn't
appear in my latest output, but my baseline is ahem less too. 

The problem I had with updating the baseline last time was that baseline and output were
reverted when I pressed the buttons, which was very weired so I stopped updating.

> 
> I also have problems with testcases using serif fonts, that are not serif in 
> baseline:
> http://tmp.ebooksfrance.org/~devel/khtmltests/regression/output/css1/test5525d.htm-compare.html
Yes, I fixed the use of "Times New Roman", so out of the sudden you see times where helvetica appears before.

Greetings, Stephan



From coolo at kde.org  Fri Feb 11 10:43:24 2005
From: coolo at kde.org (Stephan Kulow)
Date: Fri, 11 Feb 2005 11:43:24 +0100
Subject: testregression usage mini howto
In-Reply-To: <200502110953.55484.coolo@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502101920.54600.germain@ebooksfrance.org>
	<200502110953.55484.coolo@kde.org>
Message-ID: <200502111143.27107.coolo@kde.org>

Am Friday 11 February 2005 09:53 schrieb Stephan Kulow:
> Am Thursday 10 February 2005 20:20 schrieb Germain Garand:
>  
> > Hi Stephan, 
> > speaking about it... 
> > is it on purpose that current baseline doesn't use the Ahem font?
> > see e.g
> > http://tmp.ebooksfrance.org/~devel/khtmltests/regression/output/webcore/fast/text/whitespace/002.html-compare.html
> Hmm, it does for the major parts. Not sure why 002 is an exceptions here. It doesn't
> appear in my latest output, but my baseline is ahem less too. 
> 
Ah, I just skipped all of webcore in respect to Ahem as it turned out that the support for Ahem in
testregression isn't really what you would expect in a running system.

But you can see my view on the regression suite here: http://ktown.kde.org/~coolo/regression/output/
The newest changes effect e.g. css21/t100304-c43-rpl-bbx-00-d-g.html

Greetings, Stephan



From koos.vriezen at xs4all.nl  Fri Feb 11 12:29:05 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 13:29:05 +0100
Subject: intrinsic size of object (br33903)
Message-ID: <20050211122905.GJ59712@xs4all.nl>

Hi,

I stumbled against a (probably) copy/paste bug in kjas for requesting
a resize of an applet (see attachment). Other than that, code that
should perform the resize is broken too. Now quickly fixed using the
liveconnect way, which is a bit of a hack (otoh, khtml is scriptable,
so why not use it internally too?).
Anyway, some time ago Stephan add me to the CC list of br33903. So I
guess to fix this for all kinds of kparts and w/o using the liveconnect
extension, a signal in BrowserExtension is needed, where to the KHTMLPart
is connected and doing something like the javascript does. Of course I
can fix that. I something like that acceptable for khtml?

Koos
-------------- next part --------------
? .kjavaapplet.cpp.swp
? .kjavaappletviewer.cpp.swp
? .kjavaappletwidget.cpp.swp
? .kjavadownloader.cpp.swp
? .kjavaprocess.cpp.swp
? .swp
? kjas_cert.diff
? org/kde/kjas/server/.KJASSwingConsole.java.swp
Index: kjava.jar
===================================================================
RCS file: /home/kde/kdelibs/khtml/java/kjava.jar,v
retrieving revision 1.96
diff -u -3 -p -r1.96 kjava.jar
Binary files /tmp/cvs.Tw3Eza and kjava.jar differ
Index: kjavaapplet.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/java/kjavaapplet.cpp,v
retrieving revision 1.32
diff -u -3 -p -r1.32 kjavaapplet.cpp
--- kjavaapplet.cpp	9 May 2003 22:05:03 -0000	1.32
+++ kjavaapplet.cpp	11 Feb 2005 12:13:10 -0000
@@ -24,6 +24,7 @@
 
 #include <klocale.h>
 #include <kdebug.h>
+#include <kparts/browserextension.h>
 
 
 
@@ -149,8 +150,12 @@ void KJavaApplet::resizeAppletWidget( in
 {
     kdDebug(6100) << "KJavaApplet, id = " << id << ", ::resizeAppletWidget to " << width << ", " << height << endl;
 
-    if( d->UIwidget )
-        d->UIwidget->resize( width, height );
+    QStringList sl;
+    sl.push_back( QString::number( 0 ) ); // applet itself has id 0
+    sl.push_back( QString( "eval" ) );    // evaluate next script
+    sl.push_back( QString::number( KParts::LiveConnectExtension::TypeString ) );
+    sl.push_back( QString( "this.setAttribute('WIDTH',%1);this.setAttribute('HEIGHT',%2)" ).arg( width ).arg( height ) );
+    jsData( sl );
 }
 
 void KJavaApplet::setAppletName( const QString& name )
Index: org/kde/kjas/server/KJASProtocolHandler.java
===================================================================
RCS file: /home/kde/kdelibs/khtml/java/org/kde/kjas/server/KJASProtocolHandler.java,v
retrieving revision 1.57
diff -u -3 -p -r1.57 KJASProtocolHandler.java
--- org/kde/kjas/server/KJASProtocolHandler.java	30 Jan 2005 17:08:16 -0000	1.57
+++ org/kde/kjas/server/KJASProtocolHandler.java	11 Feb 2005 12:13:10 -0000
@@ -623,7 +623,7 @@ public class KJASProtocolHandler
 
         System.arraycopy( tmp_bytes, 0, bytes, index, tmp_bytes.length );
         index += tmp_bytes.length;
-        bytes[index++] = (byte) ShowStatusCode;
+        bytes[index++] = (byte) ResizeAppletCode;
         bytes[index++] = sep;
 
         tmp_bytes = contextID.getBytes();

From faure at kde.org  Fri Feb 11 13:07:24 2005
From: faure at kde.org (David Faure)
Date: Fri, 11 Feb 2005 14:07:24 +0100
Subject: intrinsic size of object (br33903)
In-Reply-To: <20050211122905.GJ59712@xs4all.nl>
References: <20050211122905.GJ59712@xs4all.nl>
Message-ID: <200502111407.25233.faure@kde.org>

On Friday 11 February 2005 13:29, Koos Vriezen wrote:
> Anyway, some time ago Stephan add me to the CC list of br33903. So I
> guess to fix this for all kinds of kparts and w/o using the liveconnect
> extension, a signal in BrowserExtension is needed, where to the KHTMLPart
> is connected and doing something like the javascript does. Of course I
> can fix that. I something like that acceptable for khtml?

I'm not following - which signal would you add to BrowserExtension?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From koos.vriezen at xs4all.nl  Fri Feb 11 13:18:22 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 14:18:22 +0100
Subject: intrinsic size of object (br33903)
In-Reply-To: <200502111407.25233.faure@kde.org>
References: <20050211122905.GJ59712@xs4all.nl>
	<200502111407.25233.faure@kde.org>
Message-ID: <20050211131822.GK59712@xs4all.nl>

On Fri, Feb 11, 2005 at 02:07:24PM +0100, David Faure wrote:
> On Friday 11 February 2005 13:29, Koos Vriezen wrote:
> > Anyway, some time ago Stephan add me to the CC list of br33903. So I
> > guess to fix this for all kinds of kparts and w/o using the liveconnect
> > extension, a signal in BrowserExtension is needed, where to the KHTMLPart
> > is connected and doing something like the javascript does. Of course I
> > can fix that. I something like that acceptable for khtml?
> 
> I'm not following - which signal would you add to BrowserExtension?

Something like we have already:
  /**
   * Ask the hosting application to resize the top level widget.
   */
  void resizeTopLevelWidget( int w, int h );

But maybe we need two, or have a bool for that, that will tell khtml the
difference between the intrinsic size and a 'normal' resize. First case
should be ignored in case the object has width/height attributes already.
Eg.
   void reizeWidget(int w, int h, bool intrinsic);

Btw, I was testing some sites w/ applets just now and www.map24.com is
completely broken. My CVS version is from 20050205, but the changes don't
seem to be in this area (khtml is uptodate of course).
Anyone aware of this brokeness, the site constantly reloads itself.

Koos




From germain at ebooksfrance.org  Fri Feb 11 14:22:35 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Fri, 11 Feb 2005 14:22:35 +0000
Subject: testregression usage mini howto
In-Reply-To: <200502110953.55484.coolo@kde.org>
References: <200502080157.24014.paul.temple@gmx.net>
	<200502101920.54600.germain@ebooksfrance.org>
	<200502110953.55484.coolo@kde.org>
Message-ID: <200502111422.35390.germain@ebooksfrance.org>

Le vendredi 11 Février 2005 08:53, Stephan Kulow a écrit :
> The problem I had with updating the baseline last time was that baseline
> and output were reverted when I pressed the buttons, which was very weired
> so I stopped updating.

yes, *very* ennoying bug ;(
flicker is also broken more often than not.

It doesn't do that when you open the testcase in a separate tab, so I guess 
it's a JS bug related to frames but I haven't been able to track it down any 
further.

Greetings,
Germain



From l.savernik at aon.at  Fri Feb 11 15:10:33 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 11 Feb 2005 16:10:33 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502110204.38572.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211005645.GF59712@xs4all.nl>
	<200502110204.38572.paul.temple@gmx.net>
Message-ID: <200502111610.40460.l.savernik@aon.at>

Am Freitag, 11. Februar 2005 02:04 schrieb Paul Temple:
> If David says "looks good" it means: "Go ahead and commit".
> Right? Just want to be sure...

*Don't!*

This must not be solved at the ecmascript level, but on the DOM level instead.

You have to fix the implementation in xml/dom_nodeimpl.cpp instead 
(NodeBaseImpl::insertBefore et. al.)

Oh! You did it already. Please revert, and apply the fix to the correct level.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/ec107917/attachment.sig>

From l.savernik at aon.at  Fri Feb 11 15:16:33 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 11 Feb 2005 16:16:33 +0100
Subject: [patch] Re: cssRules / ID selectors
In-Reply-To: <200502110430.42518.paul.temple@gmx.net>
References: <200502110430.42518.paul.temple@gmx.net>
Message-ID: <200502111616.33730.l.savernik@aon.at>

Am Freitag, 11. Februar 2005 04:30 schrieb Paul Temple:
> -    if ( cs->tag == 0xffffffff && cs->attr == ATTR_ID && cs->match ==
> CSSSelector::Exact ) 
> +    if ( cs->tag == 0xffffffff && cs->match == 
> CSSSelector::Id )

Does it still work if you write

    if ( cs->tag == 0xffffffff && cs->attr == ATTR_ID && cs->match == 
CSSSelector::Id )

?

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/4d2b013f/attachment.sig>

From l.savernik at aon.at  Fri Feb 11 16:03:42 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 11 Feb 2005 17:03:42 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502102313.26530.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
Message-ID: <200502111703.42946.l.savernik@aon.at>

Am Donnerstag, 10. Februar 2005 23:13 schrieb Paul Temple:
> I did not run testregression as it does not work for me. But I
> think this patch is almost "keyhole surgery" and don't expect
> problems out of it,

Hehe. Everybody believes that "this small fix cannot do any harm to any other 
part" of the component.

If that were true, we wouldn't need regression tests. Sadly, it isn't.

So please, try to make it running.

Can you apply the attached patch to testregression, and tell me whether 
running it with -nouse-xvfb works for you?

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml_testregression_6.diff
Type: text/x-diff
Size: 2292 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/8fdbe461/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/8fdbe461/attachment.sig>

From koos.vriezen at xs4all.nl  Fri Feb 11 16:43:21 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 17:43:21 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502111610.40460.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211005645.GF59712@xs4all.nl>
	<200502110204.38572.paul.temple@gmx.net>
	<200502111610.40460.l.savernik@aon.at>
Message-ID: <20050211164321.GL59712@xs4all.nl>

On Fri, Feb 11, 2005 at 04:10:33PM +0100, Leo Savernik wrote:
> Am Freitag, 11. Februar 2005 02:04 schrieb Paul Temple:
> > If David says "looks good" it means: "Go ahead and commit".
> > Right? Just want to be sure...
> 
> *Don't!*
> 
> This must not be solved at the ecmascript level, but on the DOM level instead.
> 
> You have to fix the implementation in xml/dom_nodeimpl.cpp instead 
> (NodeBaseImpl::insertBefore et. al.)

Can you elaborate on this (note me asking this again)? There are lots of
usages of the implementation classes by ecma, because its only used at
that place, so moving it to xml/* only makes it more complex for the
normal case, ie. when the document is being build by the parser.
So what's your reasoning, eg. why not moving the code to dom/* or leave
it as-is?

Koos

> Oh! You did it already. Please revert, and apply the fix to the correct level.
> 
> mfg
>  Leo





From l.savernik at aon.at  Fri Feb 11 17:11:05 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 11 Feb 2005 18:11:05 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211164321.GL59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111610.40460.l.savernik@aon.at>
	<20050211164321.GL59712@xs4all.nl>
Message-ID: <200502111811.16297.l.savernik@aon.at>

Am Freitag, 11. Februar 2005 17:43 schrieb Koos Vriezen:
[...]
> > This must not be solved at the ecmascript level, but on the DOM level
> > instead.
> >
> > You have to fix the implementation in xml/dom_nodeimpl.cpp instead
> > (NodeBaseImpl::insertBefore et. al.)
>
> Can you elaborate on this (note me asking this again)?

Yes.

> There are lots of 
> usages of the implementation classes by ecma, because its only used at
> that place, so moving it to xml/* only makes it more complex for the
> normal case, ie. when the document is being build by the parser.

The parser doesn't make use of any dom interface methods made for export. So 
there's no slowdown/breakage to be expected.

> So what's your reasoning, eg. why not moving the code to dom/* or leave
> it as-is?

It's about language independence. Calling the DOM interface methods must lead 
to the same result independent of any language bindings.

Implementing the tag-closing in ecma means that we get a different behaviour 
when calling Node::insertBefore in ecma-script and in C++.

This leads to

someElement.insertBefore(myApplet, someChild)

magically work in ecma script, but not in C++ (and any other language that 
binds to the C++ dom interface).

Hope this clears up any issues.

If you know of any other hackeries in ecma that actually belong to the dom 
level, please tell me.

>
[...]

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/74415da3/attachment.sig>

From koos.vriezen at xs4all.nl  Fri Feb 11 17:11:56 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 18:11:56 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502111811.16297.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111610.40460.l.savernik@aon.at>
	<20050211164321.GL59712@xs4all.nl>
	<200502111811.16297.l.savernik@aon.at>
Message-ID: <20050211171155.GM59712@xs4all.nl>

On Fri, Feb 11, 2005 at 06:11:05PM +0100, Leo Savernik wrote:
> Am Freitag, 11. Februar 2005 17:43 schrieb Koos Vriezen:
> > Can you elaborate on this (note me asking this again)?
> 
> Yes.

Thanks!

> The parser doesn't make use of any dom interface methods made for export. So 
> there's no slowdown/breakage to be expected.
> 
> > So what's your reasoning, eg. why not moving the code to dom/* or leave
> > it as-is?

[..]

> magically work in ecma script, but not in C++ (and any other language that 
> binds to the C++ dom interface).

Yes, I thought you would say that, but why move to xml/* and not dom/* ?

[..]

Koos




From l.savernik at aon.at  Fri Feb 11 18:14:32 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 11 Feb 2005 19:14:32 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211171155.GM59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111811.16297.l.savernik@aon.at>
	<20050211171155.GM59712@xs4all.nl>
Message-ID: <200502111914.39463.l.savernik@aon.at>

Am Freitag, 11. Februar 2005 18:11 schrieb Koos Vriezen:
> > magically work in ecma script, but not in C++ (and any other language
> > that binds to the C++ dom interface).
>
> Yes, I thought you would say that, but why move to xml/* and not dom/* ?

Because xml/ interferes with the renderer, and never dom/ (which resembles the 
interface only, and must stay as lightweight as possible).

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/b346e555/attachment.sig>

From koos.vriezen at xs4all.nl  Fri Feb 11 18:25:57 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 19:25:57 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502111914.39463.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111811.16297.l.savernik@aon.at>
	<20050211171155.GM59712@xs4all.nl>
	<200502111914.39463.l.savernik@aon.at>
Message-ID: <20050211182557.GN59712@xs4all.nl>

On Fri, Feb 11, 2005 at 07:14:32PM +0100, Leo Savernik wrote:
> Am Freitag, 11. Februar 2005 18:11 schrieb Koos Vriezen:
> > > magically work in ecma script, but not in C++ (and any other language
> > > that binds to the C++ dom interface).
> >
> > Yes, I thought you would say that, but why move to xml/* and not dom/* ?
> 
> Because xml/ interferes with the renderer, and never dom/ (which resembles the 
> interface only, and must stay as lightweight as possible).

and because closing the renderer interferes it. Ok, fair enough.

One other thing you mentioned was that the parser doesn't use the DOM
interface. I guess you mean the DOM api, like appendChild and such. But
grep'ing for these, do show up  alot of them, even in
ml/xml_tokenizer.cpp. Albeit for XML, looking at where it's used, does
make one feel unconfortable adding the code we're talking about in
xml/*. Eg. in XMLTokenizer::finish() there are all kinds of calls to
closeRenderer(), and the remark is:
  // Close the renderers so that they update their display correctly
  // ### this should not be necessary, but requires changes in the rendering code...

Which means that if Paul moves his code, this (and more)  should be
changed as well? If so, one could suggest this a post 3.4 thing, no?

Koos



From l.savernik at aon.at  Fri Feb 11 19:03:33 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 11 Feb 2005 20:03:33 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050211182557.GN59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111914.39463.l.savernik@aon.at>
	<20050211182557.GN59712@xs4all.nl>
Message-ID: <200502112003.35012.l.savernik@aon.at>

Am Freitag, 11. Februar 2005 19:25 schrieb Koos Vriezen:
> > Because xml/ interferes with the renderer, and never dom/ (which
> > resembles the interface only, and must stay as lightweight as possible).
>
> and because closing the renderer interferes it. Ok, fair enough.
>
> One other thing you mentioned was that the parser doesn't use the DOM
> interface. I guess you mean the DOM api, like appendChild and such. But
> grep'ing for these, do show up  alot of them, 

Mostly error handling. It shouldn't harm there.

> even in 
> ml/xml_tokenizer.cpp. Albeit for XML, looking at where it's used, does
> make one feel unconfortable adding the code we're talking about in
> xml/*. Eg. in XMLTokenizer::finish() there are all kinds of calls to
> closeRenderer(), and the remark is:
>   // Close the renderers so that they update their display correctly
>   // ### this should not be necessary, but requires changes in the
> rendering code...

Your concerns are valid. It looks like a little change, but may be way more 
invasive than it seems.
>
> Which means that if Paul moves his code, this (and more)  should be
> changed as well? If so, one could suggest this a post 3.4 thing, no?

That's why it's paramount to run the regression tests (this addresses you, 
Paul). I'm sure there'll be regressions. If they're too numerous, and/or too 
difficult to fix, we should indeed consider postponing the fix.

Alternatively, we could wait for Apple and check how they'll get rid of 
closeRenderer ;-)

mfg
 Leo

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050211/585ce1f0/attachment.sig>

From koos.vriezen at xs4all.nl  Fri Feb 11 20:47:49 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Fri, 11 Feb 2005 21:47:49 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502112003.35012.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111914.39463.l.savernik@aon.at>
	<20050211182557.GN59712@xs4all.nl>
	<200502112003.35012.l.savernik@aon.at>
Message-ID: <20050211204749.GO59712@xs4all.nl>

On Fri, Feb 11, 2005 at 08:03:33PM +0100, Leo Savernik wrote:

[..]

> Your concerns are valid. It looks like a little change, but may be way more 
> invasive than it seems.
> >
> > Which means that if Paul moves his code, this (and more)  should be
> > changed as well? If so, one could suggest this a post 3.4 thing, no?
> 
> That's why it's paramount to run the regression tests (this addresses you, 
> Paul). I'm sure there'll be regressions. If they're too numerous, and/or too 
> difficult to fix, we should indeed consider postponing the fix.
> 
> Alternatively, we could wait for Apple and check how they'll get rid of 
> closeRenderer ;-)

Maybe more of us should have a look if this is doable in short term.
If not doable and current doesn't show regression, we should leave
it as-is w/ a comment to fix it for 4.0. I very much suspect this isn't
about applets only but all objects too. Given that lots of sites have
changed their object declarations by document.write, because of the
what-was-it-called patent, I wouldn't be suprised it fixes some of the
cases where DOM is used too.

Koos





From paul.temple at gmx.net  Fri Feb 11 22:39:16 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 23:39:16 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502111914.39463.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211171155.GM59712@xs4all.nl>
	<200502111914.39463.l.savernik@aon.at>
Message-ID: <200502112339.16892.paul.temple@gmx.net>

Leo Savernik wrote:
> Am Freitag, 11. Februar 2005 18:11 schrieb Koos Vriezen:
> > > magically work in ecma script, but not in C++ (and any
> > > other language that binds to the C++ dom interface).
> >
> > Yes, I thought you would say that, but why move to xml/* and
> > not dom/* ?
>
> Because xml/ interferes with the renderer, and never dom/
> (which resembles the interface only, and must stay as
> lightweight as possible).

I'll look into that later (today or tomorrow). Just switched to a 
new machine as the backgroundlight just turned off (and 
foregroundlight is not as efficient...), so I still need some 
time to install all the japanese etc. stuff I need...

And now my system runs with XFree (not XFree / xorg mix), so I 
might have more luck with testregression...



From paul.temple at gmx.net  Fri Feb 11 22:46:30 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Fri, 11 Feb 2005 23:46:30 +0100
Subject: [patch] Re: cssRules / ID selectors
In-Reply-To: <200502111616.33730.l.savernik@aon.at>
References: <200502110430.42518.paul.temple@gmx.net>
	<200502111616.33730.l.savernik@aon.at>
Message-ID: <200502112346.30630.paul.temple@gmx.net>

Leo Savernik wrote:
> Am Freitag, 11. Februar 2005 04:30 schrieb Paul Temple:
> > -    if ( cs->tag == 0xffffffff && cs->attr == ATTR_ID &&
> > cs->match == CSSSelector::Exact )
> > +    if ( cs->tag == 0xffffffff && cs->match ==
> > CSSSelector::Id )
>
> Does it still work if you write
>
>     if ( cs->tag == 0xffffffff && cs->attr == ATTR_ID &&
> cs->match == CSSSelector::Id )

Yes, it works, though I don't yet fully understand what cs->attr 
is about.
I thought it handles attribute selectors like for instance
input[type=button]
At least later in that method it is used for that.

I'll look into that when I finished configuring my new system... 
If you have an explanation on why cs->attr is not only used for 
attribute selectors, tell me please :)



From koos.vriezen at xs4all.nl  Sat Feb 12 02:17:49 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 12 Feb 2005 03:17:49 +0100
Subject: clsid for quicktime
Message-ID: <20050212021748.GP59712@xs4all.nl>

Hi,

Attached fixed video on
http://www.apple.com/trailers/paramount/sahara/sahara_medium.html
with source of information.

Koos
-------------- next part --------------
Index: rendering/render_frames.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/rendering/render_frames.cpp,v
retrieving revision 1.193
diff -u -3 -p -r1.193 render_frames.cpp
--- rendering/render_frames.cpp	1 Feb 2005 18:51:16 -0000	1.193
+++ rendering/render_frames.cpp	12 Feb 2005 02:13:53 -0000
@@ -693,6 +693,9 @@ void RenderPartObject::updateWidget()
               else if(objbase->classId.contains(QString::fromLatin1("8AD9C840-044E-11D1-B3E9-00805F499D93")) ||
                       objbase->classId.contains(QString::fromLatin1("CAFEEFAC-0014-0000-0000-ABCDEFFEDCBA")))
                   serviceType = "application/x-java-applet";
+              // http://www.apple.com/quicktime/tools_tips/tutorials/activex.html
+              else if(objbase->classId.contains(QString::fromLatin1("02BF25D5-8C17-4B23-BC80-D3488ABDDC6B")))
+                  serviceType = "video/quicktime";
 
               else
                   kdDebug(6031) << "ActiveX classId " << objbase->classId << endl;

From coolo at kde.org  Sat Feb 12 11:11:07 2005
From: coolo at kde.org (Stephan Kulow)
Date: Sat, 12 Feb 2005 12:11:07 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502111703.42946.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111703.42946.l.savernik@aon.at>
Message-ID: <200502121211.08104.coolo@kde.org>

On Friday 11 February 2005 17:03, Leo Savernik wrote:
>
> Can you apply the attached patch to testregression, and tell me whether
> running it with -nouse-xvfb works for you?
The default seems to be -nouse, so it shouldn't matter if you give or not.
I'm fine with the patch though. I wasn't aware the use of xvfb is such 
unportable, but you have to make sure you add the font paths to ahem
yourself.

Greetings, Stephan

-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Py'guapy 평화



From molkentin at kde.org  Sat Feb 12 11:17:38 2005
From: molkentin at kde.org (Daniel Molkentin)
Date: Sat, 12 Feb 2005 12:17:38 +0100
Subject: clsid for quicktime
In-Reply-To: <20050212021748.GP59712@xs4all.nl>
References: <20050212021748.GP59712@xs4all.nl>
Message-ID: <200502121217.38790.molkentin@kde.org>

On Saturday, 12. February 2005 03:17, Koos Vriezen wrote:
> Hi,
>
> Attached fixed video on
> http://www.apple.com/trailers/paramount/sahara/sahara_medium.html
> with source of information.

I wonder if those kind of information should really be hardcoded. Any idea on 
that?

Cheers,
  Daniel




From charles at kde.org  Sat Feb 12 11:19:44 2005
From: charles at kde.org (Charles Samuels)
Date: Sat, 12 Feb 2005 11:19:44 +0000
Subject: [patch] to bug 88243
In-Reply-To: <200502121211.08104.coolo@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111703.42946.l.savernik@aon.at>
	<200502121211.08104.coolo@kde.org>
Message-ID: <200502121119.44845.charles@kde.org>

On Saturday 12 February 2005 11:11, Stephan Kulow wrote:
> On Friday 11 February 2005 17:03, Leo Savernik wrote:
> > Can you apply the attached patch to testregression, and tell me whether
> > running it with -nouse-xvfb works for you?
>
> The default seems to be -nouse, so it shouldn't matter if you give or not.
> I'm fine with the patch though. I wasn't aware the use of xvfb is such
> unportable, but you have to make sure you add the font paths to ahem
> yourself.

I don't think Xvfb is the cause.  I think the cause is that XListFonts (and 
co.) just don't like ahem.  Even in a normal X server, ahem doesn't work 
here.  It only works when you use xft (which Qt does normally).

-Charles



From koos.vriezen at xs4all.nl  Sat Feb 12 12:41:42 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 12 Feb 2005 13:41:42 +0100
Subject: clsid for quicktime
In-Reply-To: <200502121217.38790.molkentin@kde.org>
References: <20050212021748.GP59712@xs4all.nl>
	<200502121217.38790.molkentin@kde.org>
Message-ID: <20050212124142.GQ59712@xs4all.nl>

On Sat, Feb 12, 2005 at 12:17:38PM +0100, Daniel Molkentin wrote:
> On Saturday, 12. February 2005 03:17, Koos Vriezen wrote:
> > Hi,
> >
> > Attached fixed video on
> > http://www.apple.com/trailers/paramount/sahara/sahara_medium.html
> > with source of information.
> 
> I wonder if those kind of information should really be hardcoded. Any idea on 
> that?

A query for ktrader about "application/x-activex-handler" with clsid as
restriction would be nice ...

While at it, also add it for ms-video (attached) and Helge Deller
pointed at find instead of contains.

Koos
-------------- next part --------------
Index: rendering/render_frames.cpp
===================================================================
RCS file: /home/kde/kdelibs/khtml/rendering/render_frames.cpp,v
retrieving revision 1.193
diff -u -3 -p -r1.193 render_frames.cpp
--- rendering/render_frames.cpp	1 Feb 2005 18:51:16 -0000	1.193
+++ rendering/render_frames.cpp	12 Feb 2005 12:34:05 -0000
@@ -693,6 +693,13 @@ void RenderPartObject::updateWidget()
               else if(objbase->classId.contains(QString::fromLatin1("8AD9C840-044E-11D1-B3E9-00805F499D93")) ||
                       objbase->classId.contains(QString::fromLatin1("CAFEEFAC-0014-0000-0000-ABCDEFFEDCBA")))
                   serviceType = "application/x-java-applet";
+              // http://www.apple.com/quicktime/tools_tips/tutorials/activex.html
+              else if(objbase->classId.find("02BF25D5-8C17-4B23-BC80-D3488ABDDC6B") >= 0)
+                  serviceType = "video/quicktime";
+              // http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwmt/html/windows_media_player_advanced_scripting_for_cross_browser_functionality__jchc.asp
+              else if(objbase->classId.find("6BF52A52-394A-11d3-B153-00C04F79FAA6") >= 0 ||
+                      objbase->classId.find("22D6f312-B0F6-11D0-94AB-0080C74C7E95") >= 0)
+                  serviceType = "video/x-msvideo";
 
               else
                   kdDebug(6031) << "ActiveX classId " << objbase->classId << endl;

From rodda at kde.org  Sat Feb 12 12:52:50 2005
From: rodda at kde.org (Hamish Rodda)
Date: Sat, 12 Feb 2005 23:52:50 +1100
Subject: Need some help with a bug in kio_http
Message-ID: <200502122352.55515.rodda@kde.org>

Hi,

I got an interesting bug report recently.  The webdav implementation doesn't 
deal with compressed replies properly - decompression doesn't happen and thus 
the xml cannot be parsed.  The bug is 
http://bugs.kde.org/show_bug.cgi?id=98124

I started full time work this year so my time is pretty strained, but I took a 
look at the code and did a bit of debugging.  I can't understand why the data 
is not decompressed - in response to the "Content-Encoding: gzip" header the 
appropriate filter is added to the chain, and executed.

If anyone who knows the code could make a suggestion, it could help...

Cheers,
Hamish.

PS. please cc me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050212/fadaadfc/attachment.sig>

From coolo at kde.org  Sat Feb 12 15:19:26 2005
From: coolo at kde.org (Stephan Kulow)
Date: Sat, 12 Feb 2005 16:19:26 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502121119.44845.charles@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502121211.08104.coolo@kde.org>
	<200502121119.44845.charles@kde.org>
Message-ID: <200502121619.28027.coolo@kde.org>

On Saturday 12 February 2005 12:19, Charles Samuels wrote:

> I don't think Xvfb is the cause.  I think the cause is that XListFonts (and
> co.) just don't like ahem.  Even in a normal X server, ahem doesn't work
> here.  It only works when you use xft (which Qt does normally).
Did you use xset fp <path to fonts.dir>; xset fp rehash?

Greetings, Stephan

-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Py'guapy 평화



From charles at kde.org  Sat Feb 12 15:34:34 2005
From: charles at kde.org (Charles Samuels)
Date: Sat, 12 Feb 2005 15:34:34 +0000
Subject: [patch] to bug 88243
In-Reply-To: <200502121619.28027.coolo@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502121119.44845.charles@kde.org>
	<200502121619.28027.coolo@kde.org>
Message-ID: <200502121534.34577.charles@kde.org>

On Saturday 12 February 2005 3:19, Stephan Kulow wrote:
> On Saturday 12 February 2005 12:19, Charles Samuels wrote:
> > I don't think Xvfb is the cause.  I think the cause is that XListFonts
> > (and co.) just don't like ahem.  Even in a normal X server, ahem doesn't
> > work here.  It only works when you use xft (which Qt does normally).
>
> Did you use xset fp <path to fonts.dir>; xset fp rehash?

charles at pythagoras resources $ xset fp+ "$PWD"; xset fp rehash
charles at pythagoras resources $ xfontsel
X Error of failed request:  BadValue (integer parameter out of range for 
operation)
  Major opcode of failed request:  45 (X_OpenFont)
  Value in failed request:  0x3e0004a
  Serial number of failed request:  1204
  Current serial number in output stream:  1205

(Note that when xfontsel runs, I select ahem in it)

And that's on just a normal Xserver.

-Charles



From paul.temple at gmx.net  Sat Feb 12 17:08:22 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sat, 12 Feb 2005 18:08:22 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502111703.42946.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111703.42946.l.savernik@aon.at>
Message-ID: <200502121808.22810.paul.temple@gmx.net>

> Can you apply the attached patch to testregression, and tell
> me whether running it with -nouse-xvfb works for you?

./testregression -nouse-xvfb /blabla/kdecvs/khtmltests/regression
------------
lt-testregression: Unknown option '-nouse-xvfb'.
lt-testregression: Use --help to get a list of available command 
line options.
------------

./testregression /blabla/kdecvs/khtmltests/regression
------------
FAILURE (KCmdLineArgs):
Application requests for isSet("use-xvfb") but the "use-xvfb" 
option
has never been specified via addCmdLineOptions( ... )

lt-testregression: kcmdlineargs.cpp:1171: bool 
KCmdLineArgs::isSet(const char*) const: Assertion `0' failed.
Aborted
------------



From paul.temple at gmx.net  Sat Feb 12 18:18:38 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sat, 12 Feb 2005 19:18:38 +0100
Subject: error starting testkhtml
Message-ID: <200502121918.38684.paul.temple@gmx.net>

on my new system:

kdecore (KLibLoader): library libkrpmview.la not found under 
'module' but under 'lib'

If I remove that file from $KDEDIR/lib, testkhtml works. What's 
that "module" about? There is no $KDEDIR/**/module directory.



From paul.temple at gmx.net  Sat Feb 12 19:54:18 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sat, 12 Feb 2005 20:54:18 +0100
Subject: cssRules / ID selectors
In-Reply-To: <200502112346.30630.paul.temple@gmx.net>
References: <200502110430.42518.paul.temple@gmx.net>
	<200502111616.33730.l.savernik@aon.at>
	<200502112346.30630.paul.temple@gmx.net>
Message-ID: <200502122054.18945.paul.temple@gmx.net>

Is this a legal CSS selector?
    H1#xyz:hover
(combining id selector and pseudo class)

Don't find a hint on
http://www.w3.org/TR/REC-CSS2/selector.html#id-selectors

At least
    H1.special:hiver
is legal, according to above link.



From thiago.macieira at kdemail.net  Sat Feb 12 20:17:46 2005
From: thiago.macieira at kdemail.net (Thiago Macieira)
Date: Sat, 12 Feb 2005 18:17:46 -0200
Subject: cssRules / ID selectors
In-Reply-To: <200502122054.18945.paul.temple@gmx.net>
References: <200502110430.42518.paul.temple@gmx.net>
	<200502112346.30630.paul.temple@gmx.net>
	<200502122054.18945.paul.temple@gmx.net>
Message-ID: <200502121817.46411.thiago.macieira@kdemail.net>

Paul Temple wrote:
>Is this a legal CSS selector?
>    H1#xyz:hover
>(combining id selector and pseudo class)

Yes, I don't see why not.

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

2. Tó cennan his weorc gearu, ymbe se circolwyrde, wearð se cægbord and se 
leohtspeccabord, and þa mýs cómon lator. On þone dæg, he hine reste.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050212/56f5c9ba/attachment.sig>

From coolo at kde.org  Sat Feb 12 23:08:46 2005
From: coolo at kde.org (Stephan Kulow)
Date: Sun, 13 Feb 2005 00:08:46 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502121534.34577.charles@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502121619.28027.coolo@kde.org>
	<200502121534.34577.charles@kde.org>
Message-ID: <200502130008.49142.coolo@kde.org>

On Saturday 12 February 2005 16:34, Charles Samuels wrote:
> (Note that when xfontsel runs, I select ahem in it)
>
> And that's on just a normal Xserver.
s/normal/buggy/ you mean? your xfontsel test case works fine for me.
ahem doesn't look pretty in it, but I get blocks and no crashes. But perhaps
we can have a -noahem? But then we have to have a flag needsahem in
the test cases, but with -noahem you can't really test css21 and webcore
tests ;(

Greetings, Stephan

-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Py'guapy 평화



From charles at kde.org  Sun Feb 13 01:24:22 2005
From: charles at kde.org (Charles Samuels)
Date: Sun, 13 Feb 2005 01:24:22 +0000
Subject: [patch] to bug 88243
In-Reply-To: <200502130008.49142.coolo@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502121534.34577.charles@kde.org>
	<200502130008.49142.coolo@kde.org>
Message-ID: <200502130124.22193.charles@kde.org>

On Saturday 12 February 2005 11:08, Stephan Kulow wrote:
> s/normal/buggy/ you mean? your xfontsel test case works fine for me.
Yes :)

> ahem doesn't look pretty in it, but I get blocks and no crashes. But
> perhaps we can have a -noahem? But then we have to have a flag needsahem in
> the test cases, but with -noahem you can't really test css21 and webcore
> tests ;(

Either a noahem, or write that part again with Xft :(

Or I just pass my patches on to people with working ahems until debian begins 
to ship Xorg.

-Charles



From paul.temple at gmx.net  Sun Feb 13 02:41:22 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 03:41:22 +0100
Subject: [patch] cssRules / ID selectors
In-Reply-To: <200502122054.18945.paul.temple@gmx.net>
References: <200502110430.42518.paul.temple@gmx.net>
	<200502112346.30630.paul.temple@gmx.net>
	<200502122054.18945.paul.temple@gmx.net>
Message-ID: <200502130341.22842.paul.temple@gmx.net>

Here's my latest patch.

I also attached a html file so you can easily test
CSSSelector::selectorText() with any selector.
For now I don't explain what I did and why, as I assume
there are some people in this list knowing that piece of code
more than I do (even after these many, many hours of working with
it... many more hours than I thought were necessary to fix this
"small" bug). If there are questions, that are not answered by my
test results or csstest.html, I'll of course answer them... :)

These are the styles that I tested:
      .aaa { color:red; }
      body { color:red; }
      div:focus { color:red; }
      span body p div { color:red; }
      .bbb:hover { color:red; }
      input[type="button"] { color:red; }
      #eee { color:red; }
      [id="fff"] { color:red; }
      span.xxx { color:red; }
      #ggg:active { color:red; }
      table#vvv { color:red; }
      img#uuu:link { color:red; }
      p.special:hover { color:red; }
      span > p { color:red; }
      span + p { color:red; }
      span:lang(de) { color:red; }
      span[class] { color:red; }
      span[class="warning"] { color:red; }
      span[class~="warning"] { color:red; }
      span[lang|="en"] { color:red; }

These are the test results _without_ my patch (I also added 
kdDebug()
to CSSStyleRule::selectorText() ):

testkhtml: .aaa
testkhtml: body
testkhtml: div:focus
testkhtml: span body p div
testkhtml: .bbb/a:hover
testkhtml: input[type="button"]
khtml (css): WARNING: Unhandled case in 
CSSStyleRuleImpl::selectorText : match=1
testkhtml: *[id"eee"]
testkhtml: #fff
testkhtml: span.xxx[class~="xxx"]
khtml (css): WARNING: Unhandled case in 
CSSStyleRuleImpl::selectorText : match=1
testkhtml: *[id"ggg"]/a:active
khtml (css): WARNING: Unhandled case in 
CSSStyleRuleImpl::selectorText : match=1
testkhtml: table[id"vvv"]
khtml (css): WARNING: Unhandled case in 
CSSStyleRuleImpl::selectorText : match=1
testkhtml: img[id"uuu"]/a:link
testkhtml: p.special[class~="special"]/a:hover
testkhtml: span > p
testkhtml: span + p
testkhtml: span:lang(
testkhtml: span[class ""]
testkhtml: span[class="warning"]
testkhtml: span.warning[class~="warning"]
testkhtml: span[lang|="en"]

And these are the result with my patch applied:

testkhtml: .aaa
testkhtml: body
testkhtml: div:focus
testkhtml: span body p div
testkhtml: .bbb:hover
testkhtml: input[type="button"]
testkhtml: #eee
testkhtml: *[id="fff"]
testkhtml: span.xxx
testkhtml: #ggg:active
testkhtml: table#vvv
testkhtml: img#uuu:link
testkhtml: p.special:hover
testkhtml: span > p
testkhtml: span + p
testkhtml: span:lang(
testkhtml: span[class ""]
testkhtml: span[class="warning"]
testkhtml: span.warning
testkhtml: span[lang|="en"]

As you can see these selectors still don't work
      span:lang(de) { color:red; }
      span[class] { color:red; }
      span[class~="warning"] { color:red; }
but they don't work or are even worse without my patch (and for
now I don't want to put more time into selectorText() so I leaves
these cases open).

Cheers,
Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/e1110d3b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: css_base.patch
Type: text/x-diff
Size: 1406 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/e1110d3b/attachment.patch>

From coolo at kde.org  Sun Feb 13 10:16:23 2005
From: coolo at kde.org (Stephan Kulow)
Date: Sun, 13 Feb 2005 11:16:23 +0100
Subject: error starting testkhtml
In-Reply-To: <200502121918.38684.paul.temple@gmx.net>
References: <200502121918.38684.paul.temple@gmx.net>
Message-ID: <200502131116.27040.coolo@kde.org>

On Saturday 12 February 2005 19:18, Paul Temple wrote:
> on my new system:
>
> kdecore (KLibLoader): library libkrpmview.la not found under
> 'module' but under 'lib'
>
> If I remove that file from $KDEDIR/lib, testkhtml works. What's
> that "module" about? There is no $KDEDIR/**/module directory.
"module" means $KDEDIR/lib/kde3

Greetings, Stephan

-- 
Pace Peace Paix Paz Frieden Pax Pokój Friður Fred Béke 和平
Hasiti Lapé Hetep Malu Mир Wolakota Santiphap Irini Peoch
Shanti Vrede Baris Rój Mír Taika Rongo Sulh Py'guapy 평화



From paul.temple at gmx.net  Sun Feb 13 12:26:39 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 13:26:39 +0100
Subject: error starting testkhtml
In-Reply-To: <200502131116.27040.coolo@kde.org>
References: <200502121918.38684.paul.temple@gmx.net>
	<200502131116.27040.coolo@kde.org>
Message-ID: <200502131326.39784.paul.temple@gmx.net>

> "module" means $KDEDIR/lib/kde3

What are all these different directories used for? Is there a
documentation about the directories? I did not find one in
http://developer.kde.org/documentation

After manually setting (can't this be done automatically in
the script?)
    xset fp /blabla/kdecvs/khtmltests/regression/resources,/usr/X11/lib/X11/fonts/75dpi
I got one problem left:

    kio (KSycoca): WARNING: Found version 75, expecting version 78 or higher.
    kio (KSycoca): WARNING: Outdated database found
    testregression: ERROR: : couldn't create slave : Unknown protocol 'file'.
    kio (KSycoca): WARNING: Found version 75, expecting version 78 or higher.
    kio (KSycoca): WARNING: Outdated database found

I think the "slave"-error is caused by the ksycoca error, which I
guess is caused by the usage of CVS HEAD kdelibs with
my existing /home/temple/.kde from KDE 3.3.2. An
    export KDEHOME=/home/temple/.kdetest
before ./testregression ... does not help.



From paul.temple at gmx.net  Sun Feb 13 13:27:38 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 14:27:38 +0100
Subject: error starting testkhtml
In-Reply-To: <200502131326.39784.paul.temple@gmx.net>
References: <200502121918.38684.paul.temple@gmx.net>
	<200502131116.27040.coolo@kde.org>
	<200502131326.39784.paul.temple@gmx.net>
Message-ID: <200502131427.38736.paul.temple@gmx.net>

Paul Temple wrote:
> I think the "slave"-error is caused by the ksycoca error,
> which I guess is caused by the usage of CVS HEAD kdelibs with
> my existing /home/temple/.kde from KDE 3.3.2. An
>     export KDEHOME=/home/temple/.kdetest
> before ./testregression ... does not help.

Is it really necessary to 
http://developer.kde.org/build/build2ver.html
? Is this what all developers do?

I know I can get along without doing that at least for this 
khtmltest thing, as it did work before. (I try to be as lazy as 
possible with all that "infrastructure" stuff as it's already 
time consuming enough finding my way into the code... but 
probably it's not clean mixing versions, even if it is possible 
sometimes)



From paul.temple at gmx.net  Sun Feb 13 14:02:02 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 15:02:02 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502111914.39463.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211171155.GM59712@xs4all.nl>
	<200502111914.39463.l.savernik@aon.at>
Message-ID: <200502131502.02729.paul.temple@gmx.net>

Leo Savernik wrote:
> > Yes, I thought you would say that, but why move to xml/* and
> > not dom/* ?
>
> Because xml/ interferes with the renderer, and never dom/
> (which resembles the interface only, and must stay as
> lightweight as possible).

If you agree, I'll revert my last patch to ecma/kjs_dom.cpp and 
apply the attached one instead
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dom_nodeimpl.patch
Type: text/x-diff
Size: 1041 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/90d5a571/attachment.patch>

From koos.vriezen at xs4all.nl  Sun Feb 13 15:23:11 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sun, 13 Feb 2005 16:23:11 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502131502.02729.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211171155.GM59712@xs4all.nl>
	<200502111914.39463.l.savernik@aon.at>
	<200502131502.02729.paul.temple@gmx.net>
Message-ID: <20050213152310.GA52676@xs4all.nl>

On Sun, Feb 13, 2005 at 03:02:02PM +0100, Paul Temple wrote:
> Leo Savernik wrote:
> > > Yes, I thought you would say that, but why move to xml/* and
> > > not dom/* ?
> >
> > Because xml/ interferes with the renderer, and never dom/
> > (which resembles the interface only, and must stay as
> > lightweight as possible).
> 
> If you agree, I'll revert my last patch to ecma/kjs_dom.cpp and 
> apply the attached one instead

I haven't tried your patch, but if I place kdBacktrace in
HTMLObjectElementImpl::attach (called when attacked and too soon for
applet/object to create (*)) and RenderPartObject::updateWidget that
performs the object creation, I see:

(*) eg for 
  <applet NAME="myappletname" WIDTH=800 HEIGHT=150>
    <param NAME="code" VALUE="myapplet">
  </applet
  we have to wait for all params to be inserted as our child

2: /../lib/libkhtml.so.4(DOM::HTMLObjectBaseElementImpl::attach()+0x257)
3: /../lib/libkhtml.so.4(DOM::HTMLAppletElementImpl::attach()+0x10f)
4: /../lib/libkhtml.so.4(khtml::KHTMLParser::insertNode(DOM::NodeImpl*, bool)+0x17b)
5: /../lib/libkhtml.so.4(khtml::KHTMLParser::parseToken(khtml::Token*)+0x230)
6: /../lib/libkhtml.so.4(khtml::HTMLTokenizer::processToken()+0x62)
7: /../lib/libkhtml.so.4(khtml::HTMLTokenizer::parseTag(khtml::TokenizerString&)+0x3b8)
8: /../lib/libkhtml.so.4(khtml::HTMLTokenizer::write(khtml::TokenizerString const&, bool)+0x380)
9: /../lib/libkhtml.so.4(KHTMLPart::write(char const*, int)+0x165)
10: /../lib/libkhtml.so.4(KHTMLPart::slotData(KIO::Job*, QMemArray<char> const&)+0x93)

and after that

2: /../lib/libkhtml.so.4(khtml::RenderPartObject::updateWidget()+0x168)
3: /../lib/libkhtml.so.4(khtml::RenderPartObject::close()+0x4b)
4: /../lib/libkhtml.so.4(DOM::NodeImpl::closeRenderer()+0x3a)
5: /../lib/libkhtml.so.4(DOM::NodeImpl::close()+0x22)
6: /../lib/libkhtml.so.4(DOM::ElementImpl::close()+0x25)
7: /../lib/libkhtml.so.4(khtml::KHTMLParser::popOneBlock()+0x4e)
8: /../lib/libkhtml.so.4(khtml::KHTMLParser::popBlock(int)+0x68)
9: /../lib/libkhtml.so.4(khtml::KHTMLParser::processCloseTag(khtml::Token*)+0x76)
10: /../lib/libkhtml.so.4(khtml::KHTMLParser::parseToken(khtml::Token*)+0x1c4)
11: /../lib/libkhtml.so.4(khtml::HTMLTokenizer::processToken()+0x62)
12: /../lib/libkhtml.so.4(khtml::HTMLTokenizer::parseTag(khtml::TokenizerString&)+0x3b8)
13: /../lib/libkhtml.so.4(khtml::HTMLTokenizer::write(khtml::TokenizerString const&, bool)+0x380)
14: /../lib/libkhtml.so.4(KHTMLPart::write(char const*, int)+0x165)
15: /../lib/libkhtml.so.4(KHTMLPart::slotData(KIO::Job*, QMemArray<char> const&)+0x93)

Your patch will move the second backtrace to the 4 line of first one. That
will miss it the params IIRC, no? You can easy verify it.

Koos



From paul.temple at gmx.net  Sun Feb 13 16:19:45 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 17:19:45 +0100
Subject: [patch] to bug 88243
In-Reply-To: <20050213152310.GA52676@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502131502.02729.paul.temple@gmx.net>
	<20050213152310.GA52676@xs4all.nl>
Message-ID: <200502131719.46184.paul.temple@gmx.net>

Koos Vriezen wrote:
> I haven't tried your patch, but if I place kdBacktrace in
> HTMLObjectElementImpl::attach (called when attacked and too
> soon for applet/object to create (*)) and
> RenderPartObject::updateWidget that performs the object
> creation, I see:
>
> (*) eg for
>   <applet NAME="myappletname" WIDTH=800 HEIGHT=150>
>     <param NAME="code" VALUE="myapplet">
>   </applet
>   we have to wait for all params to be inserted as our child

the methods the patch extends are never called when html is 
parsed - they are called when I appendChild/insert...etc. via 
Script/DOM. JS Example:

    var node = document.createElement("applet");
    node.setAttribute('id', id);
    node.setAttribute('code', 'Test');
    node.setAttribute('width', '50'); 
    node.setAttribute('height', '50');
    myElement.appendChild(node);



From koos.vriezen at xs4all.nl  Sun Feb 13 16:45:55 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sun, 13 Feb 2005 17:45:55 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502131719.46184.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502131502.02729.paul.temple@gmx.net>
	<20050213152310.GA52676@xs4all.nl>
	<200502131719.46184.paul.temple@gmx.net>
Message-ID: <20050213164555.GA57939@xs4all.nl>

On Sun, Feb 13, 2005 at 05:19:45PM +0100, Paul Temple wrote:
> Koos Vriezen wrote:
> > I haven't tried your patch, but if I place kdBacktrace in
> > HTMLObjectElementImpl::attach (called when attacked and too
> > soon for applet/object to create (*)) and
> > RenderPartObject::updateWidget that performs the object
> > creation, I see:
> >
> > (*) eg for
> >   <applet NAME="myappletname" WIDTH=800 HEIGHT=150>
> >     <param NAME="code" VALUE="myapplet">
> >   </applet
> >   we have to wait for all params to be inserted as our child
> 
> the methods the patch extends are never called when html is 
> parsed - they are called when I appendChild/insert...etc. via 

Ah, confused by KHTMLParser::insertNode vs NodeBaseImpl::insertBefore.
Never mind then :-)

Koos



From germain at ebooksfrance.org  Sun Feb 13 16:56:33 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Sun, 13 Feb 2005 16:56:33 +0000
Subject: [patch] to bug 88243
In-Reply-To: <20050211182557.GN59712@xs4all.nl>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111914.39463.l.savernik@aon.at>
	<20050211182557.GN59712@xs4all.nl>
Message-ID: <200502131656.33677.germain@ebooksfrance.org>

Le vendredi 11 Février 2005 18:25, Koos Vriezen a écrit :
> On Fri, Feb 11, 2005 at 07:14:32PM +0100, Leo Savernik wrote:
> > Am Freitag, 11. Februar 2005 18:11 schrieb Koos Vriezen:
> > > > magically work in ecma script, but not in C++ (and any other language
> > > > that binds to the C++ dom interface).
> > >
> > > Yes, I thought you would say that, but why move to xml/* and not dom/*
> > > ?
> >
> > Because xml/ interferes with the renderer, and never dom/ (which
> > resembles the interface only, and must stay as lightweight as possible).
>
> and because closing the renderer interferes it. Ok, fair enough.
>

Hi, sorry to intervene that late, but the way I see it, we are only closing a 
node here, not a node's renderer.
That nodeimpl::close would actually close the renderer is not of our concern.

So I rather agree with Koos, that the fix should go in dom/*.

Doing that from xml/* will only get the parser to prematurely close nodes 
while they have children still to be appended.

Greetings,
Germain



From paul.temple at gmx.net  Sun Feb 13 16:36:36 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 17:36:36 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502131656.33677.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211182557.GN59712@xs4all.nl>
	<200502131656.33677.germain@ebooksfrance.org>
Message-ID: <200502131736.36359.paul.temple@gmx.net>

Germain Garand wrote:
> > > > Yes, I thought you would say that, but why move to xml/*
> > > > and not dom/* ?
> > >
> > > Because xml/ interferes with the renderer, and never dom/
> > > (which resembles the interface only, and must stay as
> > > lightweight as possible).
> >
> > and because closing the renderer interferes it. Ok, fair
> > enough.
>
> Hi, sorry to intervene that late, but the way I see it, we are
> only closing a node here, not a node's renderer.
> That nodeimpl::close would actually close the renderer is not
> of our concern.
>
> So I rather agree with Koos, that the fix should go in dom/*.
>
> Doing that from xml/* will only get the parser to prematurely
> close nodes while they have children still to be appended.

Doing that in xml - s. today's patch - does not affect the 
parsing process. And parsing <applet>...</applet> already works 
fine, only adding applets via DOM/Script does not work, as 
close / closeRenderer is never called in that case.



From l.savernik at aon.at  Sun Feb 13 17:31:41 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Sun, 13 Feb 2005 18:31:41 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502121808.22810.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502111703.42946.l.savernik@aon.at>
	<200502121808.22810.paul.temple@gmx.net>
Message-ID: <200502131831.42977.l.savernik@aon.at>

Am Samstag, 12. Februar 2005 18:08 schrieb Paul Temple:
> > Can you apply the attached patch to testregression, and tell
> > me whether running it with -nouse-xvfb works for you?
[...]
> FAILURE (KCmdLineArgs):
> Application requests for isSet("use-xvfb") but the "use-xvfb"
> option
[...]

Sorry, I forgot to mention that my patch is untested. Waldo has committed a 
seemingly correct version by now, maybe you should try that one.

mfg
 Leo



From germain at ebooksfrance.org  Sun Feb 13 17:40:25 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Sun, 13 Feb 2005 17:40:25 +0000
Subject: [patch] to bug 88243
In-Reply-To: <200502131736.36359.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502131656.33677.germain@ebooksfrance.org>
	<200502131736.36359.paul.temple@gmx.net>
Message-ID: <200502131740.25620.germain@ebooksfrance.org>

Le dimanche 13 Février 2005 16:36, Paul Temple a écrit :
> Germain Garand wrote:
> > > > > Yes, I thought you would say that, but why move to xml/*
> > > > > and not dom/* ?
> > > >
> > > > Because xml/ interferes with the renderer, and never dom/
> > > > (which resembles the interface only, and must stay as
> > > > lightweight as possible).
> > >
> > > and because closing the renderer interferes it. Ok, fair
> > > enough.
> >
> > Hi, sorry to intervene that late, but the way I see it, we are
> > only closing a node here, not a node's renderer.
> > That nodeimpl::close would actually close the renderer is not
> > of our concern.
> >
> > So I rather agree with Koos, that the fix should go in dom/*.
> >
> > Doing that from xml/* will only get the parser to prematurely
> > close nodes while they have children still to be appended.
>
> Doing that in xml - s. today's patch - does not affect the
> parsing process. And parsing <applet>...</applet> already works
> fine, only adding applets via DOM/Script does not work, as
> close / closeRenderer is never called in that case.

mmh, right the parser uses the faster addChild... 
append/replace are used in some places, but from what I can see it's fine to 
close the node automatically in those cases.

It looks OK then indeed.
Could you please add a note in the .h making clear that 
replace/insert/appendChild will close the node, contrarily to addChild?

Greetings,
Germain



From l.savernik at aon.at  Sun Feb 13 17:54:18 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Sun, 13 Feb 2005 18:54:18 +0100
Subject: [patch] to bug 88243
In-Reply-To: <200502131656.33677.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<20050211182557.GN59712@xs4all.nl>
	<200502131656.33677.germain@ebooksfrance.org>
Message-ID: <200502131854.18901.l.savernik@aon.at>

Am Sonntag, 13. Februar 2005 17:56 schrieb Germain Garand:
> [Closing nodes] from xml/* will only get the parser to prematurely close 
nodes
> while they have children still to be appended.

The normal parsing flow doesn't make use of insertBefore. Maybe I'm 
overlooking something, but I don't see the problem you describe here.

You're right that HEAD's renderer is closed prematurely. But as it hasn't got 
any renderer, it does no harm.

We have to correctly handle that close() thingy after KDE 3.4.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/6951546c/attachment.sig>

From paul.temple at gmx.net  Sun Feb 13 17:53:45 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 18:53:45 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502131740.25620.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502131736.36359.paul.temple@gmx.net>
	<200502131740.25620.germain@ebooksfrance.org>
Message-ID: <200502131853.45905.paul.temple@gmx.net>

Germain Garand wrote:
> mmh, right the parser uses the faster addChild...
> append/replace are used in some places, but from what I can
> see it's fine to close the node automatically in those cases.

I can use closeRenderer() instead of close(), that fixes bug 
82243, too. Is that better? And if so, should I adjust the
    if (newChild->closed())
?



From koos.vriezen at xs4all.nl  Sun Feb 13 18:39:03 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sun, 13 Feb 2005 19:39:03 +0100
Subject: Variations on theme redirection_anchor (was: kdelibs/khtml)
Message-ID: <20050213183903.GB57939@xs4all.nl>

Hi,

Two more regression tests for redirecting to same url. As was pointed
out in the thread in this regression test, there should be a reload if
one sets location.href=same-url and that fails ATM (see
redirection_anchor2.html).

Koos

From: David Faure <faure at kde.org>
To: kde-cvs at kde.org
Date: Sun, 13 Feb 2005 11:26:02 +0100 (CET)
Cc: khtml-cvs at kde.org
Subject: kdelibs/khtml

CVS commit by faure: 

No reload should happen when redirecting to sameurl#anchor via Javascript or
META refresh. This happened due to the setRedirectedRequest(true), which
wasn't necessary for the webmin tree.cgi fix - setRedirectedRequest is called
by KonqRun for that one.
The other redirectedRequest check was used for adding cross-domain, I simply
moved that code from urlSelected to slotRedirect.

Waldo: please check but AFAICS this keeps the same cross-domain logic as before.

Testcases in tests/ecma/redirection* (but no testcase for the webmin issue since
it needs a HTTP redirect)


  M +9 -0      ChangeLog   1.375
  M +19 -25    khtml_part.cpp   1.1090



_______________________________________________
Khtml-cvs mailing list
Khtml-cvs at kde.org
https://mail.kde.org/mailman/listinfo/khtml-cvs

----- End forwarded message -----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/bd0da20f/attachment.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/bd0da20f/attachment-0001.html>

From koos.vriezen at xs4all.nl  Sun Feb 13 19:09:01 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sun, 13 Feb 2005 20:09:01 +0100
Subject: Variations on theme redirection_anchor (was: kdelibs/khtml)
In-Reply-To: <20050213183903.GB57939@xs4all.nl>
References: <20050213183903.GB57939@xs4all.nl>
Message-ID: <20050213190901.GC57939@xs4all.nl>

On Sun, Feb 13, 2005 at 07:39:03PM +0100, Koos Vriezen wrote:
> Hi,
> 
> Two more regression tests for redirecting to same url. As was pointed
> out in the thread in this regression test, there should be a reload if
> one sets location.href=same-url and that fails ATM (see
> redirection_anchor2.html).

Sorry, a better one for redirection_anchor2.html
Had to dig deep in my brain, but it was something w/ a site that set a
cookie and then reloaded itself. But more importantly, NS/IE do the the
same.

Koos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/01ff827d/attachment.html>

From l.savernik at aon.at  Sun Feb 13 20:24:46 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Sun, 13 Feb 2005 21:24:46 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502131853.45905.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502131740.25620.germain@ebooksfrance.org>
	<200502131853.45905.paul.temple@gmx.net>
Message-ID: <200502132124.54980.l.savernik@aon.at>

Am Sonntag, 13. Februar 2005 18:53 schrieb Paul Temple:
> Germain Garand wrote:
> > mmh, right the parser uses the faster addChild...
> > append/replace are used in some places, but from what I can
> > see it's fine to close the node automatically in those cases.
>
> I can use closeRenderer() instead of close(), that fixes bug
> 82243, too. Is that better? And if so, should I adjust the
>     if (newChild->closed())
> ?

close() calls closeRenderer() implicitly, so either should work.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050213/25280c86/attachment.sig>

From germain at ebooksfrance.org  Sun Feb 13 20:29:40 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Sun, 13 Feb 2005 20:29:40 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502131853.45905.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502131740.25620.germain@ebooksfrance.org>
	<200502131853.45905.paul.temple@gmx.net>
Message-ID: <200502132029.41139.germain@ebooksfrance.org>

Le dimanche 13 Février 2005 17:53, Paul Temple a écrit :
> Germain Garand wrote:
> > mmh, right the parser uses the faster addChild...
> > append/replace are used in some places, but from what I can
> > see it's fine to close the node automatically in those cases.
>
> I can use closeRenderer() instead of close(), that fixes bug
> 82243, too. Is that better? And if so, should I adjust the
>     if (newChild->closed())
> ?

errm, no I don't think it's better... nor could I argue either way.
Better is ordinarily the enemy of "good enough" :)

Greetings,
Germain



From paul.temple at gmx.net  Sun Feb 13 20:34:04 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 21:34:04 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502132029.41139.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502131853.45905.paul.temple@gmx.net>
	<200502132029.41139.germain@ebooksfrance.org>
Message-ID: <200502132134.05206.paul.temple@gmx.net>

Germain Garand wrote:
> > I can use closeRenderer() instead of close(), that fixes bug
> > 82243, too. Is that better? And if so, should I adjust the
> >     if (newChild->closed())
> > ?
>
> errm, no I don't think it's better... nor could I argue either
> way. Better is ordinarily the enemy of "good enough" :)

I don't know khtml well, but thought as closeRenderer() does not 
set
    m_closed = true;
you could still add elements to that node afterwards, which was 
the point you argued (though we don't have that parser problem, 
as parser only calls addChild()).



From germain at ebooksfrance.org  Sun Feb 13 22:17:11 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Sun, 13 Feb 2005 22:17:11 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502132134.05206.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502132029.41139.germain@ebooksfrance.org>
	<200502132134.05206.paul.temple@gmx.net>
Message-ID: <200502132217.11933.germain@ebooksfrance.org>

Le dimanche 13 Février 2005 20:34, Paul Temple a écrit :
> I don't know khtml well, but thought as closeRenderer() does not
> set
>     m_closed = true;
> you could still add elements to that node afterwards, which was
> the point you argued (though we don't have that parser problem,
> as parser only calls addChild()).

I think you can always add nodes, even on closed ones. Closing only makes 
sense while parsing a document or a document fragment, so that you don't 
uselessly apply a hierarchy dependent selector on an unfinished hierarchy 
(e.g last-child).

For dynamically added nodes, it's irrelevant, and the structure is supposedly 
built from the inner node before being inserted so it's probably a good idea 
to close them anyway.

Greetings,
Germain



From paul.temple at gmx.net  Sun Feb 13 22:20:00 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Sun, 13 Feb 2005 23:20:00 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502132217.11933.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502132134.05206.paul.temple@gmx.net>
	<200502132217.11933.germain@ebooksfrance.org>
Message-ID: <200502132320.01193.paul.temple@gmx.net>

Germain Garand wrote:
> Le dimanche 13 Février 2005 20:34, Paul Temple a écrit :
> > I don't know khtml well, but thought as closeRenderer() does
> > not set
> >     m_closed = true;
> > you could still add elements to that node afterwards, which
> > was the point you argued (though we don't have that parser
> > problem, as parser only calls addChild()).
>
> I think you can always add nodes, even on closed ones. Closing
> only makes sense while parsing a document or a document
> fragment, so that you don't uselessly apply a hierarchy
> dependent selector on an unfinished hierarchy (e.g
> last-child).
>
> For dynamically added nodes, it's irrelevant, and the
> structure is supposedly built from the inner node before being
> inserted so it's probably a good idea to close them anyway.

Then I'll apply that patch as is, OK?



From germain at ebooksfrance.org  Sun Feb 13 22:27:28 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Sun, 13 Feb 2005 22:27:28 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502132320.01193.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502132217.11933.germain@ebooksfrance.org>
	<200502132320.01193.paul.temple@gmx.net>
Message-ID: <200502132227.28350.germain@ebooksfrance.org>

Le dimanche 13 Février 2005 22:20, Paul Temple a écrit :
> Then I'll apply that patch as is, OK?

yes, please.



From lynch30 at marshall.edu  Sun Feb 13 22:40:06 2005
From: lynch30 at marshall.edu (Sean Lynch)
Date: Sun, 13 Feb 2005 17:40:06 -0500
Subject: Crash after recent compile
Message-ID: <200502131740.06812.lynch30@marshall.edu>

I updated my CVS and compiled today and now when I visit one of my school's 
site, I get a crash with this backtrace.

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 1105164416 (LWP 18953)]
[KCrash handler]
#7  0x4274af51 in khtml::RenderFlow::repaint (this=0x8fe5f70, immediate=false)
    at render_flow.h:63
#8  0x4273d809 in khtml::RenderObject::repaintDuringLayout (this=)
    at render_object.cpp:1303
#9  0x4272b024 in khtml::RenderBlock::layoutInlineChildren (this=)
    at bidi.cpp:1286
#10 0x42732685 in khtml::RenderBlock::layoutBlock (this=)
    at render_block.cpp:529
#11 0x4275ce0b in khtml::RenderTableCell::layout (this=0x8fe5ee4)
    at render_table.cpp:1889
#12 0x4275d293 in khtml::RenderTableRow::layout (this=)
    at render_table.cpp:1800
#13 0x427445dd in khtml::RenderContainer::layout (this=)
    at render_object.h:377
#14 0x427619cc in khtml::RenderTable::layout (this=0x8895790)
    at render_table.cpp:284
#15 0x427309e2 in khtml::RenderBlock::layoutBlockChildren (this=0x8893ba8, 
    relayoutChildren=false) at render_object.h:377
#16 0x4273285e in khtml::RenderBlock::layoutBlock (this=)
    at render_block.cpp:531
#17 0x42732b8e in khtml::RenderBlock::layout (this=0x8893ba8)
    at render_block.cpp:435
#18 0x427309e2 in khtml::RenderBlock::layoutBlockChildren (this=0x8893b30, 
    relayoutChildren=false) at render_object.h:377
#19 0x4273285e in khtml::RenderBlock::layoutBlock (this=)
    at render_block.cpp:531
#20 0x42732b8e in khtml::RenderBlock::layout (this=0x8893b30)
    at render_block.cpp:435
#21 0x427309e2 in khtml::RenderBlock::layoutBlockChildren (this=0x8893ab8, 
    relayoutChildren=false) at render_object.h:377
#22 0x4273285e in khtml::RenderBlock::layoutBlock (this=)
    at render_block.cpp:531
#23 0x42732b8e in khtml::RenderBlock::layout (this=0x8893ab8)
    at render_block.cpp:435
#24 0x427804de in khtml::RenderBody::layout (this=) at render_body.cpp:93
#25 0x427309e2 in khtml::RenderBlock::layoutBlockChildren (this=0x88939e4, 
    relayoutChildren=false) at render_object.h:377
#26 0x4273285e in khtml::RenderBlock::layoutBlock (this=)
    at render_block.cpp:531
#27 0x42732b8e in khtml::RenderBlock::layout (this=0x88939e4)
    at render_block.cpp:435
#28 0x427309e2 in khtml::RenderBlock::layoutBlockChildren (this=0x88938d0, 
    relayoutChildren=false) at render_object.h:377
#29 0x4273285e in khtml::RenderBlock::layoutBlock (this=)
    at render_block.cpp:531
#30 0x42732b8e in khtml::RenderBlock::layout (this=0x88938d0)
    at render_block.cpp:435
#31 0x4277a459 in khtml::RenderCanvas::layout (this=) at render_canvas.cpp:160
#32 0x4267fe78 in KHTMLView::layout (this=) at khtmlview.cpp:773
#33 0x42680812 in KHTMLView::timerEvent (this=0x87db480, e=0x8e56ba8)
    at khtmlview.cpp:2954
#34 0x40c343be in QObject::event () from /opt/qt/lib/libqt-mt.so.3
#35 0x40c6d6e2 in QWidget::event () from /opt/qt/lib/libqt-mt.so.3
#36 0x40bca7b4 in QApplication::internalNotify ()
   from /opt/qt/lib/libqt-mt.so.3
#37 0x40bcc44f in QApplication::notify () from /opt/qt/lib/libqt-mt.so.3
#38 0x40754397 in KApplication::notify (this=0xbfffd9c0, receiver=0x87db480, 
    event=0xbfffd3e0) at kapplication.cpp:549
#39 0x40bbe652 in QEventLoop::activateTimers () from /opt/qt/lib/libqt-mt.so.3
#40 0x40b74cb4 in QEventLoop::processEvents () from /opt/qt/lib/libqt-mt.so.3
#41 0x40be3f7a in QEventLoop::enterLoop () from /opt/qt/lib/libqt-mt.so.3
#42 0x40be3dd4 in QEventLoop::exec () from /opt/qt/lib/libqt-mt.so.3
#43 0x40bcc340 in QApplication::exec () from /opt/qt/lib/libqt-mt.so.3
#44 0x42128e1e in kdemain (argc=2, argv=0x8068418) at konq_main.cc:206
#45 0x4090c980 in kdeinitmain (argc=2, argv=0x8068418) at konqueror_dummy.cc:2
#46 0x0804e471 in launch (argc=2, _name=0x81252d4 "konqueror", 
    args=0x81252e7 "\001", cwd=0x0, envc=1, envs=0x81252f8 "", 
    reset_env=false, tty=0x0, avoid_loops=false, 
    startup_id_str=0x81252fc "linux;1108333469;874174;30704_TIME632545")
    at kinit.cpp:625
#47 0x0804ebd2 in handle_launcher_request (sock=149253032) at kinit.cpp:1189
#48 0x0804f1d0 in handle_requests (waitForPid=0) at kinit.cpp:1392
#49 0x0804f963 in main (argc=2, argv=0xbfffe2c4, envp=0xbfffe2d0)
    at kinit.cpp:1848

Sean



From paul.temple at gmx.net  Sun Feb 13 23:06:05 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 14 Feb 2005 00:06:05 +0100
Subject: [patch] cssRules / ID selectors
In-Reply-To: <200502130341.22842.paul.temple@gmx.net>
References: <200502110430.42518.paul.temple@gmx.net>
	<200502122054.18945.paul.temple@gmx.net>
	<200502130341.22842.paul.temple@gmx.net>
Message-ID: <200502140006.05333.paul.temple@gmx.net>

Paul Temple wrote:
> Here's my latest patch.
> ...

Any objections?



From kde at carewolf.com  Sun Feb 13 23:08:15 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Mon, 14 Feb 2005 00:08:15 +0100
Subject: Generated content, CR patch
Message-ID: <200502140008.17117.kde@carewolf.com>

Hi everyone

I've finally fixed the last regressions, handled the last corner cases and 
cleaned the code. So here is the latest implementation of generated content; 
please test and review it for immediate commit.

It closes wish #59507 and bug #96084, and as far as I know completes our 
implementation of CSS 2.1 for regular media.

`Allan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: counter.patch.zip
Type: application/x-zip
Size: 17793 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/11f26f59/attachment.bin>

From germain at ebooksfrance.org  Mon Feb 14 13:32:37 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 14 Feb 2005 13:32:37 +0000
Subject: Crash after recent compile
In-Reply-To: <200502131740.06812.lynch30@marshall.edu>
References: <200502131740.06812.lynch30@marshall.edu>
Message-ID: <200502141332.37395.germain@ebooksfrance.org>

Le dimanche 13 Février 2005 22:40, Sean Lynch a écrit :
> I updated my CVS and compiled today and now when I visit one of my school's
> site, I get a crash with this backtrace.
>

Please file a bug report (providing an URL, or better: a testcase).

Greetings,
Germain




From mikelima at cirulla.net  Mon Feb 14 14:12:48 2005
From: mikelima at cirulla.net (Luciano Montanaro)
Date: Mon, 14 Feb 2005 15:12:48 +0100
Subject: missing include
Message-ID: <200502141512.48244.mikelima@cirulla.net>

While trying to port konqueror-embedded to current khtml codebase,
I have found that html_formimpl.cpp needs the definition of QDir, without  
including the qdir.h file. 

I'd like to apply the simple patch in the attachment, but since we are in a 
freeze...

Is it alright to commit that?

Luciano


-- 
Luciano Montanaro 

Any sufficiently advanced technology is indistinguishable from a yo-yo
                                                          - Enoch Root
-------------- next part --------------
A non-text attachment was scrubbed...
Name: html_formimpl.cpp.patch
Type: text/x-diff
Size: 235 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/c5324643/attachment.patch>

From l.savernik at aon.at  Mon Feb 14 14:53:14 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 15:53:14 +0100
Subject: Crash after recent compile
In-Reply-To: <200502131740.06812.lynch30@marshall.edu>
References: <200502131740.06812.lynch30@marshall.edu>
Message-ID: <200502141553.21875.l.savernik@aon.at>

Am Sonntag, 13. Februar 2005 23:40 schrieb Sean Lynch:
> I updated my CVS and compiled today and now when I visit one of my school's
> site, I get a crash with this backtrace.
>
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> [Thread debugging using libthread_db enabled]
> [New Thread 1105164416 (LWP 18953)]
> [KCrash handler]
> #7  0x4274af51 in khtml::RenderFlow::repaint (this=0x8fe5f70,
> immediate=false) at render_flow.h:63
[...]

There's indeed a problem. It affects other pages, too. I'm already 
investigating.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/35d1dddc/attachment.sig>

From lynch30 at marshall.edu  Mon Feb 14 14:50:01 2005
From: lynch30 at marshall.edu (Sean Michael Lynch)
Date: Mon, 14 Feb 2005 09:50:01 -0500 (EST)
Subject: Crash after recent compile
Message-ID: <6707097.1108392601398.JavaMail.lynch30@marshall.edu>

Turns out most all pages were crashing it.  I went ahead and did a 
clean compile but still crashes.  I noticed someone on kde-devel having 
the same problem.  I'm actually at work right now so won't be able to 
test/etc.

Sean


Germain Garand wrote:


>Le dimanche 13 Février 2005 22:40, Sean Lynch a écrit :
>> I updated my CVS and compiled today and now when I visit one of my 
school's
>> site, I get a crash with this backtrace.
>>
>
>Please file a bug report (providing an URL, or better: a testcase).
>
>Greetings,
>Germain
>
>



From l.savernik at aon.at  Mon Feb 14 14:57:00 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 15:57:00 +0100
Subject: [patch] cssRules / ID selectors
In-Reply-To: <200502130341.22842.paul.temple@gmx.net>
References: <200502110430.42518.paul.temple@gmx.net>
	<200502122054.18945.paul.temple@gmx.net>
	<200502130341.22842.paul.temple@gmx.net>
Message-ID: <200502141557.01084.l.savernik@aon.at>

Am Sonntag, 13. Februar 2005 03:41 schrieb Paul Temple:
> I also attached a html file so you can easily test
> CSSSelector::selectorText() with any selector.
> For now I don't explain what I did and why, as I assume
> there are some people in this list knowing that piece of code
> more than I do (even after these many, many hours of working with
> it... many more hours than I thought were necessary to fix this
> "small" bug).

Yes, this is khtml in its full beauty and gore ;-)

> Any objections?
> 

None from my side. If testregression gives you green light, feel free to 
commit.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/f849e6f6/attachment.sig>

From germain at ebooksfrance.org  Mon Feb 14 15:50:49 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 14 Feb 2005 15:50:49 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502132320.01193.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502132217.11933.germain@ebooksfrance.org>
	<200502132320.01193.paul.temple@gmx.net>
Message-ID: <200502141550.49452.germain@ebooksfrance.org>

Le dimanche 13 Février 2005 22:20, Paul Temple a écrit :
>
> Then I'll apply that patch as is, OK?

it turns out it crashes on css1 tests. e.g 
    khtmltests/regression/tests/css1/test11.htm

lt-testregression: dom_nodeimpl.cpp:842: void DOM::NodeImpl::closeRenderer(): 
Assertion `!m_rendererNeedsClose' failed.

which most probably means closeRenderer() is called several times.

Greetings,
Germain



From staikos at kde.org  Mon Feb 14 15:54:37 2005
From: staikos at kde.org (George Staikos)
Date: Mon, 14 Feb 2005 10:54:37 -0500
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502141550.49452.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502132320.01193.paul.temple@gmx.net>
	<200502141550.49452.germain@ebooksfrance.org>
Message-ID: <200502141054.38149.staikos@kde.org>

On Monday 14 February 2005 10:50, Germain Garand wrote:
> Le dimanche 13 Février 2005 22:20, Paul Temple a écrit :
> > Then I'll apply that patch as is, OK?
>
> it turns out it crashes on css1 tests. e.g
>     khtmltests/regression/tests/css1/test11.htm
>
> lt-testregression: dom_nodeimpl.cpp:842: void
> DOM::NodeImpl::closeRenderer(): Assertion `!m_rendererNeedsClose' failed.
>
> which most probably means closeRenderer() is called several times.

  i'm hitting this all over the place too.


-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/



From germain at ebooksfrance.org  Mon Feb 14 16:38:42 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 14 Feb 2005 16:38:42 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502141054.38149.staikos@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502141550.49452.germain@ebooksfrance.org>
	<200502141054.38149.staikos@kde.org>
Message-ID: <200502141638.43131.germain@ebooksfrance.org>

Le lundi 14 Février 2005 15:54, George Staikos a écrit :
>   i'm hitting this all over the place too.

should be fixed by now.

Germain



From l.savernik at aon.at  Mon Feb 14 17:04:04 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 18:04:04 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502141550.49452.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502132320.01193.paul.temple@gmx.net>
	<200502141550.49452.germain@ebooksfrance.org>
Message-ID: <200502141804.04959.l.savernik@aon.at>

Am Montag, 14. Februar 2005 16:50 schrieb Germain Garand:
> Le dimanche 13 Février 2005 22:20, Paul Temple a écrit :
> > Then I'll apply that patch as is, OK?
>
> it turns out it crashes on css1 tests. e.g
>     khtmltests/regression/tests/css1/test11.htm
>
> lt-testregression: dom_nodeimpl.cpp:842: void
> DOM::NodeImpl::closeRenderer(): Assertion `!m_rendererNeedsClose' failed.
>
> which most probably means closeRenderer() is called several times.
>

Then we should move it to the dom-api, as suggested earlier. As close is a 
method of NodeImpl, and not of the renderer, there's no necessity for direct 
interference with the renderer, and hence it doesn't pollute the interface 
(as I initially assumed).

Paul, how comes that that testregression didn't crash for you in 
css1/test11.htm?

Nonetheless, I hope you wouldn't mind moving the closing to dom/dom_node.cpp. 
This should alleviate all the problems we've seen so far.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/533b20bd/attachment.sig>

From l.savernik at aon.at  Mon Feb 14 17:06:32 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 18:06:32 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502141804.04959.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502141550.49452.germain@ebooksfrance.org>
	<200502141804.04959.l.savernik@aon.at>
Message-ID: <200502141806.33392.l.savernik@aon.at>

Am Montag, 14. Februar 2005 18:04 schrieb Leo Savernik:
[...]
> Nonetheless, I hope you wouldn't mind moving the closing to
> dom/dom_node.cpp. This should alleviate all the problems we've seen so far.

Forget it. Germain was faster ;-)
>



From paul.temple at gmx.net  Mon Feb 14 20:17:11 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 14 Feb 2005 21:17:11 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502141638.43131.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502141054.38149.staikos@kde.org>
	<200502141638.43131.germain@ebooksfrance.org>
Message-ID: <200502142117.11792.paul.temple@gmx.net>

Germain Garand wrote:
> Le lundi 14 Février 2005 15:54, George Staikos a écrit :
> >   i'm hitting this all over the place too.
>
> should be fixed by now.

Thanks! I must get testregression running...



From l.savernik at aon.at  Mon Feb 14 20:23:45 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 21:23:45 +0100
Subject: [patch] testregression: ecma =?iso-8859-1?q?testf=E4lle?= ignorieren
Message-ID: <200502142123.47004.l.savernik@aon.at>

Hallo,

Der folgende Patch ignoriert neben domts/** auch ecma/**, wenn die ECMAScript 
Tests ausgeschaltet sind.

Ok?

Grüße
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml_testregression_7.diff
Type: text/x-diff
Size: 734 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/ebb392b7/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/ebb392b7/attachment.sig>

From binner at kde.org  Mon Feb 14 20:23:56 2005
From: binner at kde.org (Stephan Binner)
Date: Mon, 14 Feb 2005 21:23:56 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502141638.43131.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502141054.38149.staikos@kde.org>
	<200502141638.43131.germain@ebooksfrance.org>
Message-ID: <200502142123.57557.binner@kde.org>

On Monday 14 February 2005 17:38, Germain Garand wrote:

> >   i'm hitting this all over the place too.
> should be fixed by now.

It's not fixed. Try http://linuxtoday.com, or http://distrowatch.com.

Bye,
   Steve



From binner at kde.org  Mon Feb 14 20:49:39 2005
From: binner at kde.org (Stephan Binner)
Date: Mon, 14 Feb 2005 21:49:39 +0100
Subject: Another Serious khtml Regression
Message-ID: <200502142149.41722.binner@kde.org>

Hello,

khtml is really pre-Alpha quality currently, eg http://kde-apps.org:

[KCrash handler]
#5  0x41f7298b in khtml::RenderFlow::repaint (this=0x8c95e28, immediate=false)
    at /usr/src/kde-3.4/kdelibs/khtml/rendering/render_flow.cpp:231
#6  0x41f67119 in khtml::RenderObject::repaintDuringLayout (this=0x8c95e28)
    at /usr/src/kde-3.4/kdelibs/khtml/rendering/render_object.cpp:1303
#7  0x41f48c46 in khtml::RenderBlock::layoutInlineChildren (this=0x8c95db0, 
    relayoutChildren=true)
    at /usr/src/kde-3.4/kdelibs/khtml/rendering/bidi.cpp:1286
#8  0x41f4df6c in khtml::RenderBlock::layoutBlock (this=0x8c95db0, 
    relayoutChildren=true)
    at /usr/src/kde-3.4/kdelibs/khtml/rendering/render_block.cpp:529

Are khtml commits not anymore reviewed and regression-tested!?

Bye,
   Steve



From germain at ebooksfrance.org  Mon Feb 14 21:12:29 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 14 Feb 2005 21:12:29 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142117.11792.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502141638.43131.germain@ebooksfrance.org>
	<200502142117.11792.paul.temple@gmx.net>
Message-ID: <200502142112.30010.germain@ebooksfrance.org>

Le lundi 14 Février 2005 20:17, Paul Temple a écrit :
> Germain Garand wrote:
> > Le lundi 14 Février 2005 15:54, George Staikos a écrit :
> > >   i'm hitting this all over the place too.
> >
> > should be fixed by now.
>
> Thanks! I must get testregression running...

no problem, but I kind of expected you had... ;(

Greetings,
Germain



From paul.temple at gmx.net  Mon Feb 14 21:13:12 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 14 Feb 2005 22:13:12 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142123.57557.binner@kde.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502141638.43131.germain@ebooksfrance.org>
	<200502142123.57557.binner@kde.org>
Message-ID: <200502142213.12650.paul.temple@gmx.net>

Stephan Binner wrote:
> On Monday 14 February 2005 17:38, Germain Garand wrote:
> > >   i'm hitting this all over the place too.
> >
> > should be fixed by now.
>
> It's not fixed. Try http://linuxtoday.com, or
> http://distrowatch.com.

Shouldn't we better move the "close" fix back into ecma/ ? Then 
we would get that js bug fixed for 3.4 without affecting the 
rest of khtml, as it seems to cause trouble now (though I don't 
know if Stephan's bug is caused by that change).
And the whole close / closeRenderer code should be rewritten 
anyway (as many comments in the code suggest), so why bother 
changing all that code when the whole thing (and therefore all 
the code we add/change now) is to be changed anyway?



From germain at ebooksfrance.org  Mon Feb 14 21:32:27 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 14 Feb 2005 21:32:27 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142213.12650.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142123.57557.binner@kde.org>
	<200502142213.12650.paul.temple@gmx.net>
Message-ID: <200502142132.28152.germain@ebooksfrance.org>

Le lundi 14 Février 2005 21:13, Paul Temple a écrit :
> Stephan Binner wrote:
> > On Monday 14 February 2005 17:38, Germain Garand wrote:
> > > >   i'm hitting this all over the place too.
> > >
> > > should be fixed by now.
> >
> > It's not fixed. Try http://linuxtoday.com, or
> > http://distrowatch.com.
>
> Shouldn't we better move the "close" fix back into ecma/ ? Then
> we would get that js bug fixed for 3.4 without affecting the
> rest of khtml, as it seems to cause trouble now (though I don't
> know if Stephan's bug is caused by that change).
> And the whole close / closeRenderer code should be rewritten
> anyway (as many comments in the code suggest), so why bother
> changing all that code when the whole thing (and therefore all
> the code we add/change now) is to be changed anyway?

the best for now is to move it to dom/node* as we hesitated to do. It's safe, 
and it's language neutral... would you have time to take care of that?
(and then revert also my 'fixing' commit)

Greetings,
Germain



From l.savernik at aon.at  Mon Feb 14 21:46:22 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 22:46:22 +0100
Subject: [patch] testregression: ecma =?iso-8859-1?q?testf=E4lle?=
	ignorieren
In-Reply-To: <200502142123.47004.l.savernik@aon.at>
References: <200502142123.47004.l.savernik@aon.at>
Message-ID: <200502142246.24158.l.savernik@aon.at>

Am Montag, 14. Februar 2005 21:23 schrieb Leo Savernik:
> Hallo,
>
> Der folgende Patch ignoriert neben domts/** auch ecma/**, wenn die
> ECMAScript Tests ausgeschaltet sind.

Oops, this should have been sent as private mail :-(. Sorry for noise.



From l.savernik at aon.at  Mon Feb 14 21:50:51 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 22:50:51 +0100
Subject: Another Serious khtml Regression
In-Reply-To: <200502142149.41722.binner@kde.org>
References: <200502142149.41722.binner@kde.org>
Message-ID: <200502142250.53584.l.savernik@aon.at>

Am Montag, 14. Februar 2005 21:49 schrieb Stephan Binner:
> Hello,
>
> khtml is really pre-Alpha quality currently, eg http://kde-apps.org:
>
[...]

I'm at it!

> Are khtml commits not anymore reviewed and regression-tested!?

They are, but this case hasn't been caught by any testcase.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/85063a58/attachment.sig>

From l.savernik at aon.at  Mon Feb 14 21:51:55 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 22:51:55 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142132.28152.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142213.12650.paul.temple@gmx.net>
	<200502142132.28152.germain@ebooksfrance.org>
Message-ID: <200502142251.56739.l.savernik@aon.at>

Am Montag, 14. Februar 2005 22:32 schrieb Germain Garand:
> the best for now is to move it to dom/node* as we hesitated to do. It's
> safe, and it's language neutral... would you have time to take care of
> that? (and then revert also my 'fixing' commit)

I agree.



From paul.temple at gmx.net  Mon Feb 14 22:05:00 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 14 Feb 2005 23:05:00 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142112.30010.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142117.11792.paul.temple@gmx.net>
	<200502142112.30010.germain@ebooksfrance.org>
Message-ID: <200502142305.00877.paul.temple@gmx.net>

Germain Garand wrote:
> > Thanks! I must get testregression running...
>
> no problem, but I kind of expected you had... ;(

It runs now, but I have many FAILS. So I'm not sure if it really 
works properly. I undid my last commit to xml/dom_nodeimpl.cpp, 
but that does not remove the FAILs.

I post the first lines that are printed when I call
./testregression --noxvfb /blabla/kdecvs/khtmltests/regression
Maybe someone can tell me what's wrong with it (I assume all 
tests should PASS).

KApplication::dcopFailure
KApplication::dcopFailure
FAIL: basics/33940.html [RENDER]
PASS: basics/33940.html [PAINT]
PASS: basics/borders.html [RENDER]
PASS: basics/borders.html [PAINT]
PASS: basics/font-001.html [RENDER]
PASS: basics/font-001.html [PAINT]
FAIL: basics/font-002.html [RENDER]
PASS: basics/font-002.html [PAINT]
FAIL: basics/font-003.html [RENDER]
testregression: pixel (206, 13) is different #0000ff #52507b
FAIL: basics/font-003.html [PAINT]
PASS: basics/font-004.html [RENDER]
PASS: basics/font-004.html [PAINT]
PASS: basics/font-005.html [RENDER]
PASS: basics/font-005.html [PAINT]
PASS: basics/font-006.html [RENDER]
PASS: basics/font-006.html [PAINT]
PASS: basics/font-007.html [RENDER]
kio (KIOJob): error 
11 /blabla/kdecvs/khtmltests/regression/tests/basics/arrow.gif
FAIL: basics/font-008.html [RENDER]
testregression: pixel (19, 41) is different #0000ff #52507b
FAIL: basics/font-008.html [PAINT]
PASS: basics/font-009.html [RENDER]
PASS: basics/font-009.html [PAINT]
PASS: basics/font-010.html [RENDER]
PASS: basics/font-010.html [PAINT]
PASS: basics/innerhtml-68034.html [PAINT]
FAIL: basics/justify-002.html [RENDER]
testregression: pixel (401, 13) is different #0000ff #52507b
FAIL: basics/justify-002.html [PAINT]
FAIL: basics/justify-003.html [RENDER]
PASS: basics/justify-003.html [PAINT]
PASS: basics/justify.html [RENDER]
PASS: basics/justify.html [PAINT]
PASS: basics/layout.html [DOM]
FAIL: basics/layout.html [RENDER]
PASS: basics/layout.html [PAINT]
PASS: basics/layout2.html [DOM]
FAIL: basics/layout2.html [RENDER]

...



From paul.temple at gmx.net  Mon Feb 14 22:16:53 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 14 Feb 2005 23:16:53 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142132.28152.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142213.12650.paul.temple@gmx.net>
	<200502142132.28152.germain@ebooksfrance.org>
Message-ID: <200502142316.53373.paul.temple@gmx.net>

Germain Garand wrote:
> the best for now is to move it to dom/node* as we hesitated to
> do. It's safe, and it's language neutral... would you have
> time to take care of that? (and then revert also my 'fixing'
> commit)

By "it's safe" you mean that it isn't called by the parser, 
right?

This patch does the job for me... OK to apply that and undo your 
commits (html/html_tableimpl.cpp and xml/xml_tokenizer.cpp) and 
of course my commit (xml/dom_nodeimpl.cpp)?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dom_node.patch
Type: text/x-diff
Size: 1135 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/441d8825/attachment.patch>

From l.savernik at aon.at  Mon Feb 14 22:21:55 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 23:21:55 +0100
Subject: Another Serious khtml Regression
In-Reply-To: <200502142250.53584.l.savernik@aon.at>
References: <200502142149.41722.binner@kde.org>
	<200502142250.53584.l.savernik@aon.at>
Message-ID: <200502142321.55839.l.savernik@aon.at>

Am Montag, 14. Februar 2005 22:50 schrieb Leo Savernik:
> > khtml is really pre-Alpha quality currently, eg http://kde-apps.org:
>
> [...]
>
> I'm at it!

Should be fixed now.



From l.savernik at aon.at  Mon Feb 14 22:27:06 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Mon, 14 Feb 2005 23:27:06 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142305.00877.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142112.30010.germain@ebooksfrance.org>
	<200502142305.00877.paul.temple@gmx.net>
Message-ID: <200502142327.07229.l.savernik@aon.at>

Am Montag, 14. Februar 2005 23:05 schrieb Paul Temple:
> Germain Garand wrote:
> > > Thanks! I must get testregression running...
> >
> > no problem, but I kind of expected you had... ;(
>
> It runs now, but I have many FAILS. So I'm not sure if it really
> works properly. I undid my last commit to xml/dom_nodeimpl.cpp,
> but that does not remove the FAILs.
>
[...]

This is irrelevant. Only the FAILs you have caused must be fixed.

I use testregression like this:

Before I implement the changes, I update the regression testsuite, and run 
testregression, saving the output in a log.

Then I implement the changes, and run testregression again, saving the output 
in another log.

Then I'll diff -u oldlog newlog.

If there are any differences, they may have been caused by your changes and 
must be investigated.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050214/ff68514b/attachment.sig>

From paul.temple at gmx.net  Mon Feb 14 22:54:28 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Mon, 14 Feb 2005 23:54:28 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142327.07229.l.savernik@aon.at>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142305.00877.paul.temple@gmx.net>
	<200502142327.07229.l.savernik@aon.at>
Message-ID: <200502142354.28519.paul.temple@gmx.net>

Leo Savernik wrote:
> Before I implement the changes, I update the regression
> testsuite, and run testregression, saving the output in a log.
>
> Then I implement the changes, and run testregression again,
> saving the output in another log.
>
> Then I'll diff -u oldlog newlog.
>
> If there are any differences, they may have been caused by
> your changes and must be investigated.

Hm, but then I won't find a regression if it occurs in a test 
that also failed without my changes - and there are MANY failed 
tests. Even after undoing all my local changes ;)

Do you only compare stdout before / after?
As there are quite some
    testregression: pixel (25, 45) is different #ffffff #000083
and similar printed to stderr

There are so many FAILs... is this just temporary? If not, what 
are the regression tests good for?



From germain at ebooksfrance.org  Tue Feb 15 00:42:26 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Tue, 15 Feb 2005 00:42:26 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142305.00877.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142112.30010.germain@ebooksfrance.org>
	<200502142305.00877.paul.temple@gmx.net>
Message-ID: <200502150042.26878.germain@ebooksfrance.org>

Le lundi 14 Février 2005 22:05, Paul Temple a écrit :
> Germain Garand wrote:
> > > Thanks! I must get testregression running...
> >
> > no problem, but I kind of expected you had... ;(
>
> It runs now, but I have many FAILS. So I'm not sure if it really
> works properly. I undid my last commit to xml/dom_nodeimpl.cpp,
> but that does not remove the FAILs.
>
> I post the first lines that are printed when I call
> ./testregression --noxvfb /blabla/kdecvs/khtmltests/regression
> Maybe someone can tell me what's wrong with it (I assume all
> tests should PASS).
>

it's not as straight forward as this...
testregression does its best to create an environment as reliable and stable 
as possible, but there might still be differences causing (mostly) [Paint] 
changes (such as font differences essentially) from baseline... 
here probably also the fact that you are using an ordinary X server, with 
different depth/extension/whatever (baseline was generated with Xvfb) will 
come into play.

Other differences are indeed temporary changes that have not been reviewed or 
not been checked in yet.

You can visually evaluate the changes by pointing your browser to 
khtmltests/regression/output/index.html afterward.

So: either you can match most of baseline, or, if that is definetly too far 
away, you may generate a local baseline _before_ any patch as follow:

cd /home/foo/khtmltests
cp -R regression regression_local
$KHTML/testregression -html -g  /home/foo/khtmltests/regression_local

then apply your patch, and check any difference against your baseline:

$KHTML/testregression -html /home/cvs/khtmltests/regression_local

Time consuming, but definitive.

Greetings,
Germain





From germain at ebooksfrance.org  Tue Feb 15 02:23:18 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Tue, 15 Feb 2005 02:23:18 +0000
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502142316.53373.paul.temple@gmx.net>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142132.28152.germain@ebooksfrance.org>
	<200502142316.53373.paul.temple@gmx.net>
Message-ID: <200502150223.19231.germain@ebooksfrance.org>

Le lundi 14 Février 2005 22:16, Paul Temple a écrit :
> Germain Garand wrote:
> > the best for now is to move it to dom/node* as we hesitated to
> > do. It's safe, and it's language neutral... would you have
> > time to take care of that? (and then revert also my 'fixing'
> > commit)
>
> By "it's safe" you mean that it isn't called by the parser,
> right?

yes, it doesn't change the behaviour of methods used internally, so it's as 
safe as can be (i.e as safe as your previous ecma commit)

>
> This patch does the job for me... OK to apply that and undo your
> commits (html/html_tableimpl.cpp and xml/xml_tokenizer.cpp) and
> of course my commit (xml/dom_nodeimpl.cpp)?

it's fine - I even regression tested it that time :)

Greetings,
Germain



From lynch30 at marshall.edu  Tue Feb 15 04:07:23 2005
From: lynch30 at marshall.edu (Sean Lynch)
Date: Mon, 14 Feb 2005 23:07:23 -0500
Subject: Crash after recent compile
In-Reply-To: <200502141553.21875.l.savernik@aon.at>
References: <200502131740.06812.lynch30@marshall.edu>
	<200502141553.21875.l.savernik@aon.at>
Message-ID: <200502142307.23769.lynch30@marshall.edu>

On Monday 14 February 2005 09:53 am, Leo Savernik wrote:
> Am Sonntag, 13. Februar 2005 23:40 schrieb Sean Lynch:
> > I updated my CVS and compiled today and now when I visit one of my
> > school's site, I get a crash with this backtrace.
> >
> > Using host libthread_db library "/lib/tls/libthread_db.so.1".
> > [Thread debugging using libthread_db enabled]
> > [New Thread 1105164416 (LWP 18953)]
> > [KCrash handler]
> > #7  0x4274af51 in khtml::RenderFlow::repaint (this=0x8fe5f70,
> > immediate=false) at render_flow.h:63
>
> [...]
>
> There's indeed a problem. It affects other pages, too. I'm already
> investigating.
>
> mfg
>  Leo

The fixes you posted seems to have fixed all bug 1 page, 
http://sourceforge.net/project/showfiles.php?group_id=97296.  Visiting here 
produces the following backtrace...

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 1105164416 (LWP 20334)]
[KCrash handler]
#7  0xffffe410 in ?? ()
#8  0xbfffc6f0 in ?? ()
#9  0x00000006 in ?? ()
#10 0x00004f6e in ?? ()
#11 0x415c17a1 in raise () from /lib/tls/libc.so.6
#12 0x415c2f79 in abort () from /lib/tls/libc.so.6
#13 0x415bafe3 in __assert_fail () from /lib/tls/libc.so.6
#14 0x42805283 in DOM::NodeImpl::closeRenderer (this=) at dom_nodeimpl.cpp:844
#15 0x428052ad in DOM::NodeImpl::close (this=0x859d2c0)
    at dom_nodeimpl.cpp:831
#16 0x4280a5ae in DOM::ElementImpl::close (this=) at dom_elementimpl.cpp:502
#17 0x4281c034 in khtml::KHTMLParser::popOneBlock (this=)
    at htmlparser.cpp:1204
#18 0x4281c885 in khtml::KHTMLParser::insertNode (this=0x833ba18, n=)
    at htmlparser.cpp:525
#19 0x4281e3de in khtml::KHTMLParser::parseToken (this=0x833ba18, t=0x84632d4)
    at htmlparser.cpp:279
#20 0x4281f17f in khtml::HTMLTokenizer::processToken (this=)
    at htmltokenizer.cpp:1605
#21 0x42822bc3 in khtml::HTMLTokenizer::parseTag (this=0x84632a0, 
    src=@0x84633cc) at htmltokenizer.cpp:1124
#22 0x4282492d in khtml::HTMLTokenizer::write (this=)
    at htmltokenizer.cpp:1305
#23 0x427c0e6f in KHTMLPart::write (this=0x8463180, 
    str=0x856b6b0 "marginwidth=\"0\" marginheight=\"0\" link=\"#003399\" 
vlink=\"#003399\" alink=\"#003399\">\n\n<!-- begin OSTG navbar -->\n<table 
width=\"100%\" border=\"0\" cellpadding=\"2\" cellspacing=\"0\" 
\nbgcolor=\"#444444\" style=\"bo"..., len=) at stringit.h:115
#24 0x427c22de in KHTMLPart::slotData (this=0x8463180, kio_job=0x8443588, 
    data=@0xbfffd3f0) at qmemarray.h:64
#25 0x427cb8a7 in KHTMLPart::qt_invoke (this=0x8463180, _id=) at qucom_p.h:312
#26 0x40c339af in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3
#27 0x4018e7d9 in KIO::TransferJob::data (this=) at jobclasses.moc:972
#28 0x40190304 in KIO::TransferJob::slotData (this=0x8443588, 
    _data=@0xbfffd3f0) at job.cpp:858
#29 0x401958aa in KIO::TransferJob::qt_invoke (this=0x8443588, _id=)
    at qucom_p.h:312
#30 0x40c339af in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3
#31 0x4017d1cc in KIO::SlaveInterface::data (this=) at slaveinterface.moc:194
#32 0x4018013b in KIO::SlaveInterface::dispatch (this=0x85bfd28, _cmd=100, 
    rawdata=@0xbfffd3f0) at slaveinterface.cpp:228
#33 0x40180c1d in KIO::SlaveInterface::dispatch (this=)
    at slaveinterface.cpp:173
#34 0x40178bde in KIO::Slave::gotInput (this=) at slave.cpp:300
#35 0x4017c26c in KIO::Slave::qt_invoke (this=) at slave.moc:113
#36 0x40c339af in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3
#37 0x40c33ff2 in QObject::activate_signal () from /opt/qt/lib/libqt-mt.so.3
#38 0x40faa528 in QSocketNotifier::activated () from /opt/qt/lib/libqt-mt.so.3
#39 0x40c53e31 in QSocketNotifier::event () from /opt/qt/lib/libqt-mt.so.3
#40 0x40bca7b4 in QApplication::internalNotify ()
   from /opt/qt/lib/libqt-mt.so.3
#41 0x40bcc44f in QApplication::notify () from /opt/qt/lib/libqt-mt.so.3
#42 0x40754397 in KApplication::notify (this=0xbfffdec0, receiver=0x8411fc0, 
    event=0xbfffd8e0) at kapplication.cpp:549
#43 0x40bbe03b in QEventLoop::activateSocketNotifiers ()
   from /opt/qt/lib/libqt-mt.so.3
#44 0x40b74c91 in QEventLoop::processEvents () from /opt/qt/lib/libqt-mt.so.3
#45 0x40be3f7a in QEventLoop::enterLoop () from /opt/qt/lib/libqt-mt.so.3
#46 0x40be3dd4 in QEventLoop::exec () from /opt/qt/lib/libqt-mt.so.3
#47 0x40bcc340 in QApplication::exec () from /opt/qt/lib/libqt-mt.so.3
#48 0x42128e1e in kdemain (argc=4, argv=0x80e3e00) at konq_main.cc:206
#49 0x4090c980 in kdeinitmain (argc=4, argv=0x80e3e00) at konqueror_dummy.cc:2
#50 0x0804e471 in launch (argc=4, _name=0x8124b44 "konqueror", 
    args=0x8124b79 "/home/cvsuser", cwd=0x8124b79 "/home/cvsuser", envc=68, 
    envs=0x8125398 "", reset_env=true, tty=0x0, avoid_loops=false, 
    startup_id_str=0x812539c "linux;1108439687;881090;20318_TIME0")
    at kinit.cpp:625
#51 0x0804ebd2 in handle_launcher_request (sock=0) at kinit.cpp:1189
#52 0x0804f201 in handle_requests (waitForPid=0) at kinit.cpp:1382
#53 0x0804f963 in main (argc=2, argv=0xbfffe7c4, envp=0xbfffe7d0)
    at kinit.cpp:1848

Also, I believe your overflow fixed the mouseovers at 
http://forums.ocia.net/viewforum.php?f=17, although I noticed the mouseover 
hotzone only seems to be the height of the link, not the column (the old 
mouseover prior would only hight the amount of the column/cell which which 
the font was tall.  Thus was...

---------------------------------------------------          \
No mouseover effect                               |           \
---------------------------------------------------             \
Link - Mouseover effect                           |              >----- 1 Row
---------------------------------------------------             /
No mouseover effect                               |           /
---------------------------------------------------           /



-Sean



From lynch30 at marshall.edu  Tue Feb 15 04:19:08 2005
From: lynch30 at marshall.edu (Sean Lynch)
Date: Mon, 14 Feb 2005 23:19:08 -0500
Subject: Crash after recent compile
In-Reply-To: <200502142307.23769.lynch30@marshall.edu>
References: <200502131740.06812.lynch30@marshall.edu>
	<200502141553.21875.l.savernik@aon.at>
	<200502142307.23769.lynch30@marshall.edu>
Message-ID: <200502142319.08498.lynch30@marshall.edu>

These URLs also crash konq (didn't as of a few days ago).  They come from a 
list of broken sites I keep around, checking from time to time on khtml 
updates, so you will probably notice something broken on them once they stop 
crashing.

http://www.zend.com/manual/features.file-upload.php
http://ut2004.gameamp.com/recorded_game/viewMaps/36.php
http://www.downloads.jolt.co.uk/
http://iso-top.info/

-Sean


> On Monday 14 February 2005 09:53 am, Leo Savernik wrote:
> > Am Sonntag, 13. Februar 2005 23:40 schrieb Sean Lynch:
> > > I updated my CVS and compiled today and now when I visit one of my
> > > school's site, I get a crash with this backtrace.
> > >
> > > Using host libthread_db library "/lib/tls/libthread_db.so.1".
> > > [Thread debugging using libthread_db enabled]
> > > [New Thread 1105164416 (LWP 18953)]
> > > [KCrash handler]
> > > #7  0x4274af51 in khtml::RenderFlow::repaint (this=0x8fe5f70,
> > > immediate=false) at render_flow.h:63
> >
> > [...]
> >
> > There's indeed a problem. It affects other pages, too. I'm already
> > investigating.
> >
> > mfg
> >  Leo
>
> The fixes you posted seems to have fixed all bug 1 page,
> http://sourceforge.net/project/showfiles.php?group_id=97296.  Visiting here
> produces the following backtrace...
>
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> [Thread debugging using libthread_db enabled]
> [New Thread 1105164416 (LWP 20334)]
> [KCrash handler]
> #7  0xffffe410 in ?? ()
> #8  0xbfffc6f0 in ?? ()
> #9  0x00000006 in ?? ()
> #10 0x00004f6e in ?? ()
> #11 0x415c17a1 in raise () from /lib/tls/libc.so.6
> #12 0x415c2f79 in abort () from /lib/tls/libc.so.6
> #13 0x415bafe3 in __assert_fail () from /lib/tls/libc.so.6
> #14 0x42805283 in DOM::NodeImpl::closeRenderer (this=) at
> dom_nodeimpl.cpp:844 #15 0x428052ad in DOM::NodeImpl::close
> (this=0x859d2c0)
>     at dom_nodeimpl.cpp:831
> #16 0x4280a5ae in DOM::ElementImpl::close (this=) at
> dom_elementimpl.cpp:502 #17 0x4281c034 in khtml::KHTMLParser::popOneBlock
> (this=)
>     at htmlparser.cpp:1204
> #18 0x4281c885 in khtml::KHTMLParser::insertNode (this=0x833ba18, n=)
>     at htmlparser.cpp:525
> #19 0x4281e3de in khtml::KHTMLParser::parseToken (this=0x833ba18,
> t=0x84632d4) at htmlparser.cpp:279
> #20 0x4281f17f in khtml::HTMLTokenizer::processToken (this=)
>     at htmltokenizer.cpp:1605
> #21 0x42822bc3 in khtml::HTMLTokenizer::parseTag (this=0x84632a0,
>     src=@0x84633cc) at htmltokenizer.cpp:1124
> #22 0x4282492d in khtml::HTMLTokenizer::write (this=)
>     at htmltokenizer.cpp:1305
> #23 0x427c0e6f in KHTMLPart::write (this=0x8463180,
>     str=0x856b6b0 "marginwidth=\"0\" marginheight=\"0\" link=\"#003399\"
> vlink=\"#003399\" alink=\"#003399\">\n\n<!-- begin OSTG navbar -->\n<table
> width=\"100%\" border=\"0\" cellpadding=\"2\" cellspacing=\"0\"
> \nbgcolor=\"#444444\" style=\"bo"..., len=) at stringit.h:115
> #24 0x427c22de in KHTMLPart::slotData (this=0x8463180, kio_job=0x8443588,
>     data=@0xbfffd3f0) at qmemarray.h:64
> #25 0x427cb8a7 in KHTMLPart::qt_invoke (this=0x8463180, _id=) at
> qucom_p.h:312 #26 0x40c339af in QObject::activate_signal () from
> /opt/qt/lib/libqt-mt.so.3 #27 0x4018e7d9 in KIO::TransferJob::data (this=)
> at jobclasses.moc:972 #28 0x40190304 in KIO::TransferJob::slotData
> (this=0x8443588,
>     _data=@0xbfffd3f0) at job.cpp:858
> #29 0x401958aa in KIO::TransferJob::qt_invoke (this=0x8443588, _id=)
>     at qucom_p.h:312
> #30 0x40c339af in QObject::activate_signal () from
> /opt/qt/lib/libqt-mt.so.3 #31 0x4017d1cc in KIO::SlaveInterface::data
> (this=) at slaveinterface.moc:194 #32 0x4018013b in
> KIO::SlaveInterface::dispatch (this=0x85bfd28, _cmd=100,
> rawdata=@0xbfffd3f0) at slaveinterface.cpp:228
> #33 0x40180c1d in KIO::SlaveInterface::dispatch (this=)
>     at slaveinterface.cpp:173
> #34 0x40178bde in KIO::Slave::gotInput (this=) at slave.cpp:300
> #35 0x4017c26c in KIO::Slave::qt_invoke (this=) at slave.moc:113
> #36 0x40c339af in QObject::activate_signal () from
> /opt/qt/lib/libqt-mt.so.3 #37 0x40c33ff2 in QObject::activate_signal ()
> from /opt/qt/lib/libqt-mt.so.3 #38 0x40faa528 in QSocketNotifier::activated
> () from /opt/qt/lib/libqt-mt.so.3 #39 0x40c53e31 in QSocketNotifier::event
> () from /opt/qt/lib/libqt-mt.so.3 #40 0x40bca7b4 in
> QApplication::internalNotify ()
>    from /opt/qt/lib/libqt-mt.so.3
> #41 0x40bcc44f in QApplication::notify () from /opt/qt/lib/libqt-mt.so.3
> #42 0x40754397 in KApplication::notify (this=0xbfffdec0,
> receiver=0x8411fc0, event=0xbfffd8e0) at kapplication.cpp:549
> #43 0x40bbe03b in QEventLoop::activateSocketNotifiers ()
>    from /opt/qt/lib/libqt-mt.so.3
> #44 0x40b74c91 in QEventLoop::processEvents () from
> /opt/qt/lib/libqt-mt.so.3 #45 0x40be3f7a in QEventLoop::enterLoop () from
> /opt/qt/lib/libqt-mt.so.3 #46 0x40be3dd4 in QEventLoop::exec () from
> /opt/qt/lib/libqt-mt.so.3 #47 0x40bcc340 in QApplication::exec () from
> /opt/qt/lib/libqt-mt.so.3 #48 0x42128e1e in kdemain (argc=4,
> argv=0x80e3e00) at konq_main.cc:206 #49 0x4090c980 in kdeinitmain (argc=4,
> argv=0x80e3e00) at konqueror_dummy.cc:2 #50 0x0804e471 in launch (argc=4,
> _name=0x8124b44 "konqueror",
>     args=0x8124b79 "/home/cvsuser", cwd=0x8124b79 "/home/cvsuser", envc=68,
>     envs=0x8125398 "", reset_env=true, tty=0x0, avoid_loops=false,
>     startup_id_str=0x812539c "linux;1108439687;881090;20318_TIME0")
>     at kinit.cpp:625
> #51 0x0804ebd2 in handle_launcher_request (sock=0) at kinit.cpp:1189
> #52 0x0804f201 in handle_requests (waitForPid=0) at kinit.cpp:1382
> #53 0x0804f963 in main (argc=2, argv=0xbfffe7c4, envp=0xbfffe7d0)
>     at kinit.cpp:1848
>
> Also, I believe your overflow fixed the mouseovers at
> http://forums.ocia.net/viewforum.php?f=17, although I noticed the mouseover
> hotzone only seems to be the height of the link, not the column (the old
> mouseover prior would only hight the amount of the column/cell which which
> the font was tall.  Thus was...
>
> ---------------------------------------------------          \
> No mouseover effect                               |           \
> ---------------------------------------------------             \
> Link - Mouseover effect                           |              >----- 1
> Row ---------------------------------------------------             /
> No mouseover effect                               |           /
> ---------------------------------------------------           /
>
>
>
> -Sean



From lynch30 at marshall.edu  Tue Feb 15 06:14:47 2005
From: lynch30 at marshall.edu (Sean Lynch)
Date: Tue, 15 Feb 2005 01:14:47 -0500
Subject: Crash after recent compile
In-Reply-To: <200502142319.08498.lynch30@marshall.edu>
References: <200502131740.06812.lynch30@marshall.edu>
	<200502142307.23769.lynch30@marshall.edu>
	<200502142319.08498.lynch30@marshall.edu>
Message-ID: <200502150114.47947.lynch30@marshall.edu>

Excuse the noise, seems my cvs mirror was farther behind than I thought.  No 
more crashing after another update.  The mouseover suggestion at the bottom 
still applies though.

Sean

On Monday 14 February 2005 11:19 pm, Sean Lynch wrote:
> These URLs also crash konq (didn't as of a few days ago).  They come from a
> list of broken sites I keep around, checking from time to time on khtml
> updates, so you will probably notice something broken on them once they
> stop crashing.
>
> http://www.zend.com/manual/features.file-upload.php
> http://ut2004.gameamp.com/recorded_game/viewMaps/36.php
> http://www.downloads.jolt.co.uk/
> http://iso-top.info/
>
> -Sean
>
> > On Monday 14 February 2005 09:53 am, Leo Savernik wrote:
> > > Am Sonntag, 13. Februar 2005 23:40 schrieb Sean Lynch:
> > > > I updated my CVS and compiled today and now when I visit one of my
> > > > school's site, I get a crash with this backtrace.
> > > >
> > > > Using host libthread_db library "/lib/tls/libthread_db.so.1".
> > > > [Thread debugging using libthread_db enabled]
> > > > [New Thread 1105164416 (LWP 18953)]
> > > > [KCrash handler]
> > > > #7  0x4274af51 in khtml::RenderFlow::repaint (this=0x8fe5f70,
> > > > immediate=false) at render_flow.h:63
> > >
> > > [...]
> > >
> > > There's indeed a problem. It affects other pages, too. I'm already
> > > investigating.
> > >
> > > mfg
> > >  Leo
> >
> > The fixes you posted seems to have fixed all bug 1 page,
> > http://sourceforge.net/project/showfiles.php?group_id=97296.  Visiting
> > here produces the following backtrace...
> >
> > Using host libthread_db library "/lib/tls/libthread_db.so.1".
> > [Thread debugging using libthread_db enabled]
> > [New Thread 1105164416 (LWP 20334)]
> > [KCrash handler]
> > #7  0xffffe410 in ?? ()
> > #8  0xbfffc6f0 in ?? ()
> > #9  0x00000006 in ?? ()
> > #10 0x00004f6e in ?? ()
> > #11 0x415c17a1 in raise () from /lib/tls/libc.so.6
> > #12 0x415c2f79 in abort () from /lib/tls/libc.so.6
> > #13 0x415bafe3 in __assert_fail () from /lib/tls/libc.so.6
> > #14 0x42805283 in DOM::NodeImpl::closeRenderer (this=) at
> > dom_nodeimpl.cpp:844 #15 0x428052ad in DOM::NodeImpl::close
> > (this=0x859d2c0)
> >     at dom_nodeimpl.cpp:831
> > #16 0x4280a5ae in DOM::ElementImpl::close (this=) at
> > dom_elementimpl.cpp:502 #17 0x4281c034 in khtml::KHTMLParser::popOneBlock
> > (this=)
> >     at htmlparser.cpp:1204
> > #18 0x4281c885 in khtml::KHTMLParser::insertNode (this=0x833ba18, n=)
> >     at htmlparser.cpp:525
> > #19 0x4281e3de in khtml::KHTMLParser::parseToken (this=0x833ba18,
> > t=0x84632d4) at htmlparser.cpp:279
> > #20 0x4281f17f in khtml::HTMLTokenizer::processToken (this=)
> >     at htmltokenizer.cpp:1605
> > #21 0x42822bc3 in khtml::HTMLTokenizer::parseTag (this=0x84632a0,
> >     src=@0x84633cc) at htmltokenizer.cpp:1124
> > #22 0x4282492d in khtml::HTMLTokenizer::write (this=)
> >     at htmltokenizer.cpp:1305
> > #23 0x427c0e6f in KHTMLPart::write (this=0x8463180,
> >     str=0x856b6b0 "marginwidth=\"0\" marginheight=\"0\" link=\"#003399\"
> > vlink=\"#003399\" alink=\"#003399\">\n\n<!-- begin OSTG navbar
> > -->\n<table width=\"100%\" border=\"0\" cellpadding=\"2\"
> > cellspacing=\"0\"
> > \nbgcolor=\"#444444\" style=\"bo"..., len=) at stringit.h:115
> > #24 0x427c22de in KHTMLPart::slotData (this=0x8463180, kio_job=0x8443588,
> >     data=@0xbfffd3f0) at qmemarray.h:64
> > #25 0x427cb8a7 in KHTMLPart::qt_invoke (this=0x8463180, _id=) at
> > qucom_p.h:312 #26 0x40c339af in QObject::activate_signal () from
> > /opt/qt/lib/libqt-mt.so.3 #27 0x4018e7d9 in KIO::TransferJob::data
> > (this=) at jobclasses.moc:972 #28 0x40190304 in
> > KIO::TransferJob::slotData (this=0x8443588,
> >     _data=@0xbfffd3f0) at job.cpp:858
> > #29 0x401958aa in KIO::TransferJob::qt_invoke (this=0x8443588, _id=)
> >     at qucom_p.h:312
> > #30 0x40c339af in QObject::activate_signal () from
> > /opt/qt/lib/libqt-mt.so.3 #31 0x4017d1cc in KIO::SlaveInterface::data
> > (this=) at slaveinterface.moc:194 #32 0x4018013b in
> > KIO::SlaveInterface::dispatch (this=0x85bfd28, _cmd=100,
> > rawdata=@0xbfffd3f0) at slaveinterface.cpp:228
> > #33 0x40180c1d in KIO::SlaveInterface::dispatch (this=)
> >     at slaveinterface.cpp:173
> > #34 0x40178bde in KIO::Slave::gotInput (this=) at slave.cpp:300
> > #35 0x4017c26c in KIO::Slave::qt_invoke (this=) at slave.moc:113
> > #36 0x40c339af in QObject::activate_signal () from
> > /opt/qt/lib/libqt-mt.so.3 #37 0x40c33ff2 in QObject::activate_signal ()
> > from /opt/qt/lib/libqt-mt.so.3 #38 0x40faa528 in
> > QSocketNotifier::activated () from /opt/qt/lib/libqt-mt.so.3 #39
> > 0x40c53e31 in QSocketNotifier::event () from /opt/qt/lib/libqt-mt.so.3
> > #40 0x40bca7b4 in
> > QApplication::internalNotify ()
> >    from /opt/qt/lib/libqt-mt.so.3
> > #41 0x40bcc44f in QApplication::notify () from /opt/qt/lib/libqt-mt.so.3
> > #42 0x40754397 in KApplication::notify (this=0xbfffdec0,
> > receiver=0x8411fc0, event=0xbfffd8e0) at kapplication.cpp:549
> > #43 0x40bbe03b in QEventLoop::activateSocketNotifiers ()
> >    from /opt/qt/lib/libqt-mt.so.3
> > #44 0x40b74c91 in QEventLoop::processEvents () from
> > /opt/qt/lib/libqt-mt.so.3 #45 0x40be3f7a in QEventLoop::enterLoop () from
> > /opt/qt/lib/libqt-mt.so.3 #46 0x40be3dd4 in QEventLoop::exec () from
> > /opt/qt/lib/libqt-mt.so.3 #47 0x40bcc340 in QApplication::exec () from
> > /opt/qt/lib/libqt-mt.so.3 #48 0x42128e1e in kdemain (argc=4,
> > argv=0x80e3e00) at konq_main.cc:206 #49 0x4090c980 in kdeinitmain
> > (argc=4, argv=0x80e3e00) at konqueror_dummy.cc:2 #50 0x0804e471 in launch
> > (argc=4, _name=0x8124b44 "konqueror",
> >     args=0x8124b79 "/home/cvsuser", cwd=0x8124b79 "/home/cvsuser",
> > envc=68, envs=0x8125398 "", reset_env=true, tty=0x0, avoid_loops=false,
> > startup_id_str=0x812539c "linux;1108439687;881090;20318_TIME0") at
> > kinit.cpp:625
> > #51 0x0804ebd2 in handle_launcher_request (sock=0) at kinit.cpp:1189
> > #52 0x0804f201 in handle_requests (waitForPid=0) at kinit.cpp:1382
> > #53 0x0804f963 in main (argc=2, argv=0xbfffe7c4, envp=0xbfffe7d0)
> >     at kinit.cpp:1848
> >
> > Also, I believe your overflow fixed the mouseovers at
> > http://forums.ocia.net/viewforum.php?f=17, although I noticed the
> > mouseover hotzone only seems to be the height of the link, not the column
> > (the old mouseover prior would only hight the amount of the column/cell
> > which which the font was tall.  Thus was...
> >
> > ---------------------------------------------------          \
> > No mouseover effect                               |           \
> > ---------------------------------------------------             \
> > Link - Mouseover effect                           |              >----- 1
> > Row ---------------------------------------------------             /
> > No mouseover effect                               |           /
> > ---------------------------------------------------           /
> >
> >
> >
> > -Sean



From binner at kde.org  Tue Feb 15 09:28:51 2005
From: binner at kde.org (Stephan Binner)
Date: Tue, 15 Feb 2005 10:28:51 +0100
Subject: Another Serious khtml Regression
In-Reply-To: <200502142321.55839.l.savernik@aon.at>
References: <200502142149.41722.binner@kde.org>
	<200502142250.53584.l.savernik@aon.at>
	<200502142321.55839.l.savernik@aon.at>
Message-ID: <200502151028.52434.binner@kde.org>

On Monday 14 February 2005 23:21, Leo Savernik wrote:

> > > khtml is really pre-Alpha quality currently, eg http://kde-apps.org:
> Should be fixed now.

Fix that and the second closeRenderer commit it seems to be stable again. :-)

Thanks,
      Steve



From faure at kde.org  Tue Feb 15 14:01:52 2005
From: faure at kde.org (David Faure)
Date: Tue, 15 Feb 2005 15:01:52 +0100
Subject: missing include
In-Reply-To: <200502141512.48244.mikelima@cirulla.net>
References: <200502141512.48244.mikelima@cirulla.net>
Message-ID: <200502151501.52972.faure@kde.org>

On Monday 14 February 2005 15:12, Luciano Montanaro wrote:
> While trying to port konqueror-embedded to current khtml codebase,
> I have found that html_formimpl.cpp needs the definition of QDir, without  
> including the qdir.h file. 
> 
> I'd like to apply the simple patch in the attachment, but since we are in a 
> freeze...
> 
> Is it alright to commit that?

Yes.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




From faure at kde.org  Tue Feb 15 14:05:53 2005
From: faure at kde.org (David Faure)
Date: Tue, 15 Feb 2005 15:05:53 +0100
Subject: intrinsic size of object (br33903)
In-Reply-To: <20050211131822.GK59712@xs4all.nl>
References: <20050211122905.GJ59712@xs4all.nl>
	<200502111407.25233.faure@kde.org>
	<20050211131822.GK59712@xs4all.nl>
Message-ID: <200502151505.53436.faure@kde.org>

On Friday 11 February 2005 14:18, Koos Vriezen wrote:
> On Fri, Feb 11, 2005 at 02:07:24PM +0100, David Faure wrote:
> > On Friday 11 February 2005 13:29, Koos Vriezen wrote:
> > > Anyway, some time ago Stephan add me to the CC list of br33903. So I
> > > guess to fix this for all kinds of kparts and w/o using the liveconnect
> > > extension, a signal in BrowserExtension is needed, where to the KHTMLPart
> > > is connected and doing something like the javascript does. Of course I
> > > can fix that. I something like that acceptable for khtml?
> > 
> > I'm not following - which signal would you add to BrowserExtension?
> 
> Something like we have already:
>   /**
>    * Ask the hosting application to resize the top level widget.
>    */
>   void resizeTopLevelWidget( int w, int h );
> 
> But maybe we need two, or have a bool for that, that will tell khtml the
> difference between the intrinsic size and a 'normal' resize. First case
> should be ignored in case the object has width/height attributes already.
> Eg.
>    void reizeWidget(int w, int h, bool intrinsic);

This is about a part (e.g. java?) that is embedded into KHTMLPart, right?

This looks sensible then, although I'm thinking another way to do it
might be (just thinking out loud) : widget()->resize(),
caught by an event filter in the "hosting" part (here khtmlpart)?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




From faure at kde.org  Tue Feb 15 14:13:45 2005
From: faure at kde.org (David Faure)
Date: Tue, 15 Feb 2005 15:13:45 +0100
Subject: toolbars removus
In-Reply-To: <200502041115.13447.aseigo@kde.org>
References: <200502041115.13447.aseigo@kde.org>
Message-ID: <200502151513.46426.faure@kde.org>

On Friday 04 February 2005 19:15, Aaron J. Seigo wrote:
> happy friday everyone...
> 
> for 3.4, can the following icons be removed from konqueror's default toolbars:
> 
> File Management: cut, copy, paste, print, zooming
> Web Browsing: cut, copy, paste, find, security

I'm OK with removing cut/copy/paste from the toolbar, that's easy and indeed
everyone I know uses either the keyboard shortcuts or the Edit menu.

George is against the removal of the security icon, let's postpone that.
I'm against the removal of zooming in file management - this must be
*the* toolbar icons I use personally, I can't believe I'm the only one.

I'm also not convinced about the idea of making the toolbar icons per-profile,
given that this hasn't been much tested yet, AFAIK. And given that we have
no guarantee that the right profile is used at the right time (what if I go to $HOME
after viewing a webpage?). And that there are more profiles than those two. etc.
It would also make the toolbar flicker more when switching between a
file-management tab and a webbrowsing tab.

Anyway, to move forward, let's deal with the cut/copy/paste buttons:
is it still time to remove them for KDE-3.4?

Given that it invalidates any documentation screenshot, I'm not sure...
(cc'ing documentation writer)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




From faure at kde.org  Tue Feb 15 13:57:43 2005
From: faure at kde.org (David Faure)
Date: Tue, 15 Feb 2005 14:57:43 +0100
Subject: Variations on theme redirection_anchor (was: kdelibs/khtml)
In-Reply-To: <20050213183903.GB57939@xs4all.nl>
References: <20050213183903.GB57939@xs4all.nl>
Message-ID: <200502151457.43450.faure@kde.org>

On Sunday 13 February 2005 19:39, Koos Vriezen wrote:
> Hi,
> 
> Two more regression tests for redirecting to same url. As was pointed
> out in the thread in this regression test, there should be a reload if
> one sets location.href=same-url and that fails ATM (see
> redirection_anchor2.html).

This is cancelled by our private discussion, right? Konq and Mozilla behave
just the same on redirection_anchor2.html, so I see no bug there.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).




From aseigo at kde.org  Tue Feb 15 16:24:29 2005
From: aseigo at kde.org (Aaron J. Seigo)
Date: Tue, 15 Feb 2005 09:24:29 -0700
Subject: toolbars removus
In-Reply-To: <200502151513.46426.faure@kde.org>
References: <200502041115.13447.aseigo@kde.org>
	<200502151513.46426.faure@kde.org>
Message-ID: <200502150924.59444.aseigo@kde.org>

On Tuesday 15 February 2005 07:13, David Faure wrote:
> I'm OK with removing cut/copy/paste from the toolbar, that's easy and
> indeed everyone I know uses either the keyboard shortcuts or the Edit menu.

sweet! thanks david =) 

> George is against the removal of the security icon, let's postpone that.

yep, that much had been decided.

> I'm against the removal of zooming in file management - this must be
> *the* toolbar icons I use personally, I can't believe I'm the only one.

no, you're probably not the only one, but we should be optimizing for the 
common case, not crazy people like you and me ;) the zoom icons do that much 
in file management, though i too love the zoom ... ok, i'll do a file 
management toolbar study as i did for web browsing in 2004 and figure out 
exactly which buttons get used.

> I'm also not convinced about the idea of making the toolbar icons
> per-profile, given that this hasn't been much tested yet, AFAIK. And given
> that we have no guarantee that the right profile is used at the right time
> (what if I go to $HOME after viewing a webpage?).

i don't think this would be a huge problem, however it might be something to 
look at for KDE4: how to make XMLUI better for applications that swap their 
rc files during runtime.

> And that there are more 
> profiles than those two. etc

we just need to optimize for the common cases. better usability for the 
profiles used 99% of the time by 99% of the people is good enough.

> . It would also make the toolbar flicker more 
> when switching between a file-management tab and a webbrowsing tab.

hrm.. the flicker would be annoying, yes. we'll need to come up with a 
solution for this in kde4, IMO. perhaps making profiles per-window rather 
than per-tab? anyways, a discussion for later ... looks like we've at least 
identified some of the place that XMLUI could be better in 4.0

> Anyway, to move forward, let's deal with the cut/copy/paste buttons:
> is it still time to remove them for KDE-3.4?
>
> Given that it invalidates any documentation screenshot, I'm not sure...
> (cc'ing documentation writer)

docs aren't frozen until the 22nd =)

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050215/772f5465/attachment.sig>

From koos.vriezen at xs4all.nl  Tue Feb 15 16:51:13 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 15 Feb 2005 17:51:13 +0100
Subject: intrinsic size of object (br33903)
In-Reply-To: <200502151505.53436.faure@kde.org>
References: <20050211122905.GJ59712@xs4all.nl>
	<200502111407.25233.faure@kde.org>
	<20050211131822.GK59712@xs4all.nl>
	<200502151505.53436.faure@kde.org>
Message-ID: <20050215165113.GH57939@xs4all.nl>

On Tue, Feb 15, 2005 at 03:05:53PM +0100, David Faure wrote:
> On Friday 11 February 2005 14:18, Koos Vriezen wrote:
> > On Fri, Feb 11, 2005 at 02:07:24PM +0100, David Faure wrote:
> > > On Friday 11 February 2005 13:29, Koos Vriezen wrote:
> > > > Anyway, some time ago Stephan add me to the CC list of br33903. So I
> > > > guess to fix this for all kinds of kparts and w/o using the liveconnect
> > > > extension, a signal in BrowserExtension is needed, where to the KHTMLPart
> > > > is connected and doing something like the javascript does. Of course I
> > > > can fix that. I something like that acceptable for khtml?
> > > 
> > > I'm not following - which signal would you add to BrowserExtension?
> > 
> > Something like we have already:
> >   /**
> >    * Ask the hosting application to resize the top level widget.
> >    */
> >   void resizeTopLevelWidget( int w, int h );
> > 
> > But maybe we need two, or have a bool for that, that will tell khtml the
> > difference between the intrinsic size and a 'normal' resize. First case
> > should be ignored in case the object has width/height attributes already.
> > Eg.
> >    void reizeWidget(int w, int h, bool intrinsic);
> 
> This is about a part (e.g. java?) that is embedded into KHTMLPart, right?
> 
> This looks sensible then, although I'm thinking another way to do it
> might be (just thinking out loud) : widget()->resize(),
> caught by an event filter in the "hosting" part (here khtmlpart)?

For '<object type="image/png"></object>' yes, but how does the imagepart
knows about '<object type="image/png" WIDTH=50 HEIGHT=100></object>' or
should the khtmlpart resize it back again. But then there is no way to
have a forced resize, eg. an applet may perform a resize when needed.

Koos



From koos.vriezen at xs4all.nl  Tue Feb 15 16:53:16 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Tue, 15 Feb 2005 17:53:16 +0100
Subject: Variations on theme redirection_anchor (was: kdelibs/khtml)
In-Reply-To: <200502151457.43450.faure@kde.org>
References: <20050213183903.GB57939@xs4all.nl>
	<200502151457.43450.faure@kde.org>
Message-ID: <20050215165313.GI57939@xs4all.nl>

On Tue, Feb 15, 2005 at 02:57:43PM +0100, David Faure wrote:
> On Sunday 13 February 2005 19:39, Koos Vriezen wrote:
> > Hi,
> > 
> > Two more regression tests for redirecting to same url. As was pointed
> > out in the thread in this regression test, there should be a reload if
> > one sets location.href=same-url and that fails ATM (see
> > redirection_anchor2.html).
> 
> This is cancelled by our private discussion, right? Konq and Mozilla behave
> just the same on redirection_anchor2.html, so I see no bug there.

yes

Koos



From mikelima at cirulla.net  Tue Feb 15 17:19:29 2005
From: mikelima at cirulla.net (Luciano Montanaro)
Date: Tue, 15 Feb 2005 18:19:29 +0100
Subject: KCursor strangeness
Message-ID: <200502151819.30176.mikelima@cirulla.net>

I'm proceeding with the kdenox syncronization.

I've found a few places in khtmlview.cpp

where KCursor::SizeViewCursor and similar are used instead of 
KCursor::sizeViewCursor().

Since KCursor inherits Qt, this goes unnoticed.

I am not sure how long this interface is going to stay around, since theming 
can be applied to X11 (and thus Qt) cursors anyway.

Meanwhile, I think the attached patch should be applied.

OK?

Luciano

-- 
Luciano Montanaro 

Any sufficiently advanced technology is indistinguishable from a yo-yo
                                                          - Enoch Root
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtmlview.cpp.patch
Type: text/x-diff
Size: 1910 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050215/426c0027/attachment.patch>

From l.savernik at aon.at  Tue Feb 15 17:34:00 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Tue, 15 Feb 2005 18:34:00 +0100
Subject: [patch] to bug 82243 (not 88243)
In-Reply-To: <200502150042.26878.germain@ebooksfrance.org>
References: <200502102313.26530.paul.temple@gmx.net>
	<200502142305.00877.paul.temple@gmx.net>
	<200502150042.26878.germain@ebooksfrance.org>
Message-ID: <200502151834.01728.l.savernik@aon.at>

Am Dienstag, 15. Februar 2005 01:42 schrieb Germain Garand:
> So: either you can match most of baseline, or, if that is definetly too far
> away, you may generate a local baseline _before_ any patch as follow:
>
> cd /home/foo/khtmltests
> cp -R regression regression_local
> $KHTML/testregression -html -g  /home/foo/khtmltests/regression_local
>
> then apply your patch, and check any difference against your baseline:
>
> $KHTML/testregression -html /home/cvs/khtmltests/regression_local
>
> Time consuming, but definitive.

Wow, that's the über-scrutinized way to do it ;-)

mfg
 Leo



From l.savernik at aon.at  Tue Feb 15 18:19:31 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Tue, 15 Feb 2005 19:19:31 +0100
Subject: Crash after recent compile
In-Reply-To: <200502142307.23769.lynch30@marshall.edu>
References: <200502131740.06812.lynch30@marshall.edu>
	<200502141553.21875.l.savernik@aon.at>
	<200502142307.23769.lynch30@marshall.edu>
Message-ID: <200502151919.49076.l.savernik@aon.at>

Am Dienstag, 15. Februar 2005 05:07 schrieb Sean Lynch:
> > There's indeed a problem. It affects other pages, too. I'm already
> > investigating.
> >
> > mfg
> >  Leo
>
> The fixes you posted seems to have fixed all bug 1 page,
> http://sourceforge.net/project/showfiles.php?group_id=97296.  Visiting here
> produces the following backtrace...
>
[...]
> #14 0x42805283 in DOM::NodeImpl::closeRenderer (this=) at
> dom_nodeimpl.cpp:844

This was fixed by Germain, not by me.

> Also, I believe your overflow fixed the mouseovers at 
> http://forums.ocia.net/viewforum.php?f=17, although I noticed the mouseover 
> hotzone only seems to be the height of the link, not the column (the old 
> mouseover prior would only hight the amount of the column/cell which which 
> the font was tall. [...]

Fixed by attached patch. Must still regression test.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: render_table_1.diff
Type: text/x-diff
Size: 1861 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050215/7c783b0f/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050215/7c783b0f/attachment.sig>

From paul.temple at gmx.net  Tue Feb 15 19:44:47 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Tue, 15 Feb 2005 20:44:47 +0100
Subject: clean environment
Message-ID: <200502152044.48413.paul.temple@gmx.net>

In order to be able to do reliable regression tests I'm trying to
create a clean, separate kde cvs version as described on
http://developer.kde.org/build/build2ver.html
(but I don't want to compile the unnecessary modules)

I set the environment variables, compiled qt-copy, compiled
and installed arts, kdebase and kdelibs without problems.

"make testregression" in kdelibs/khtml does not work, though.
Can anyone give me a hint how to solve that?

> make testregression
/bin/sh ../libtool --silent --tag=CXX --mode=link g++  -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -O2 -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -fno-exceptions -fno-check-new -fno-common  -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION    -o testregression  test_regression.o test_regression_fontoverload.o libkhtml.la
test_regression.o(.text+0x18f): In function `PartMonitor::finishTimers()':
: undefined reference to `KJS::Window::retrieveWindow(KParts::ReadOnlyPart*)'
test_regression.o(.text+0x1c0): In function `PartMonitor::finishTimers()':
: undefined reference to `KJS::WindowQObject::hasTimers() const'
test_regression.o(.text+0x219): In function `PartMonitor::partCompleted()':
: undefined reference to `khtml::RenderWidget::flushWidgetResizes()'
test_regression.o(.text+0x6bd): In function `RegTestFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x768): In function `RegTestFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x8f7): In function `RegTestFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0xa60): In function `RegTestFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x159e): In function `KHTMLPartObject::get(KJS::ExecState*, KJS::Identifier const&) const':
: undefined reference to `KJS::getDOMNode(KJS::ExecState*, DOM::Node const&)'
test_regression.o(.text+0x15e1): In function `KHTMLPartObject::get(KJS::ExecState*, KJS::Identifier const&) const':
: undefined reference to `KJS::Window::retrieveWindow(KParts::ReadOnlyPart*)'
test_regression.o(.text+0x176d): In function `KHTMLPartFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x1976): In function `KHTMLPartFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x19e6): In function `KHTMLPartFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x1b0f): In function `KHTMLPartFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x1f26): In function `KHTMLPartFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0x1f70): more undefined references to `KJS::UString::qstring() const' follow
test_regression.o(.text+0x3269): In function `main':
: undefined reference to `khtml::Cache::clear()'
test_regression.o(.text+0x326e): In function `main':
: undefined reference to `khtml::CSSStyleSelector::clear()'
test_regression.o(.text+0x3273): In function `main':
: undefined reference to `khtml::RenderStyle::cleanup()'
test_regression.o(.text+0x5084): In function `RegressionTest::runTests(QString, bool, int)':
: undefined reference to `khtml::Cache::init()'
test_regression.o(.text+0x606b): In function `RegressionTest::dumpRenderTree(QTextStream&, KHTMLPart*)':
: undefined reference to `khtml::RenderLayer::dump(QTextStream&, QString const&)'
test_regression.o(.text+0x6479): In function `RegressionTest::renderToImage()':
: undefined reference to `khtml::RenderLayer::paint(QPainter*, QRect const&, bool)'
test_regression.o(.text+0xa2ae): In function `RegressionTest::testStaticFile(QString const&)':
: undefined reference to `KJS::UString::UString[in-charge](QString const&)'
test_regression.o(.text+0xa806): In function `RegressionTest::testStaticFile(QString const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0xa8b4): In function `RegressionTest::testStaticFile(QString const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0xa96a): In function `RegressionTest::testStaticFile(QString const&)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0xaa7c): In function `RegressionTest::evalJS(KJS::ScriptInterpreter&, QString const&, bool)':
: undefined reference to `KJS::UString::UString[in-charge](QString const&)'
test_regression.o(.text+0xad54): In function `RegressionTest::evalJS(KJS::ScriptInterpreter&, QString const&, bool)':
: undefined reference to `KJS::UString::qstring() const'
test_regression.o(.text+0xaef1): In function `RegressionTest::testJSFile(QString const&)':
: undefined reference to `KJS::ScriptInterpreter::ScriptInterpreter[in-charge](KJS::Object const&, khtml::ChildFrame*)'
test_regression.o(.text+0xb504): In function `RegressionTest::testJSFile(QString const&)':
: undefined reference to `KJS::ScriptInterpreter::~ScriptInterpreter [in-charge]()'
collect2: ld returned 1 exit status
make: *** [testregression] Error 1



From kde at carewolf.com  Tue Feb 15 19:56:51 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Tue, 15 Feb 2005 20:56:51 +0100
Subject: clean environment
In-Reply-To: <200502152044.48413.paul.temple@gmx.net>
References: <200502152044.48413.paul.temple@gmx.net>
Message-ID: <200502152056.52057.kde@carewolf.com>

On Tuesday 15 February 2005 20:44, Paul Temple wrote:
> In order to be able to do reliable regression tests I'm trying to
> create a clean, separate kde cvs version as described on
> http://developer.kde.org/build/build2ver.html
> (but I don't want to compile the unnecessary modules)
>
> I set the environment variables, compiled qt-copy, compiled
> and installed arts, kdebase and kdelibs without problems.
>
> "make testregression" in kdelibs/khtml does not work, though.
> Can anyone give me a hint how to solve that?
>
You need --enable-debug

`Allan



From paul.temple at gmx.net  Tue Feb 15 20:15:26 2005
From: paul.temple at gmx.net (Paul Temple)
Date: Tue, 15 Feb 2005 21:15:26 +0100
Subject: clean environment
In-Reply-To: <200502152056.52057.kde@carewolf.com>
References: <200502152044.48413.paul.temple@gmx.net>
	<200502152056.52057.kde@carewolf.com>
Message-ID: <200502152115.26993.paul.temple@gmx.net>

Allan Sandfeld Jensen wrote:
> > "make testregression" in kdelibs/khtml does not work,
> > though. Can anyone give me a hint how to solve that?
>
> You need --enable-debug

Thank you very much! Finally everything seems to work... Setting 
up the environment can be quite frustrating... :( I just want to 
code! But of course I also see the importance of regression 
tests.



From l.savernik at aon.at  Tue Feb 15 21:15:33 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Tue, 15 Feb 2005 22:15:33 +0100
Subject: Generated content: counters and quotes
In-Reply-To: <200502071037.05281.kde@carewolf.com>
References: <200501272244.12213.kde@carewolf.com>
	<200501282340.32209.germain@ebooksfrance.org>
	<200502071037.05281.kde@carewolf.com>
Message-ID: <200502152215.42610.l.savernik@aon.at>

Am Montag, 7. Februar 2005 10:37 schrieb Allan Sandfeld Jensen:
> On Saturday 29 January 2005 00:40, Germain Garand wrote:
> > this looks just great...
> > Only thing I find questionable in your patch is the added stuff in
> > RenderObject, especially the added pointer  to a cache struct.
> > IMO, it should be in at least RenderBox to avoid any unnecessary bloat.
>
> Technically it is because any object that has a style can have a
> counter-node attached. It also reduces the need for
> static_cast<RenderBox*>.

After you having committed your counter-patch (no pun intended ;-) ), I want 
to warm up this old thread.

You state that every render object may have a counter attached. Point taken. 
However, nearly no actual render object *does* have a counter. Hence this 
additional pointer amounts to a lot waste of space on large documents. 
Therefore, I propose to move the counter lists to a QPtrDict within 
DocumentImpl, and reference it from there. The memory and runtime overhead of 
the dict should be negligible compared to the memory overhead of an 
additional member in RenderObject.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050215/e5b6008f/attachment.sig>

From kde at carewolf.com  Tue Feb 15 21:47:45 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Tue, 15 Feb 2005 22:47:45 +0100
Subject: Generated content: counters and quotes
In-Reply-To: <200502152215.42610.l.savernik@aon.at>
References: <200501272244.12213.kde@carewolf.com>
	<200502071037.05281.kde@carewolf.com>
	<200502152215.42610.l.savernik@aon.at>
Message-ID: <200502152247.45352.kde@carewolf.com>

On Tuesday 15 February 2005 22:15, Leo Savernik wrote:
> After you having committed your counter-patch (no pun intended ;-) ), I
> want to warm up this old thread.
>
> You state that every render object may have a counter attached. Point
> taken. However, nearly no actual render object *does* have a counter. Hence
> this additional pointer amounts to a lot waste of space on large documents.
> Therefore, I propose to move the counter lists to a QPtrDict within
> DocumentImpl, and reference it from there. The memory and runtime overhead
> of the dict should be negligible compared to the memory overhead of an
> additional member in RenderObject.
>
Sounds interesting. Notice however that all lists and list-items now have a 
counter attached.

With a global structure we really just need a fast way to lookup:
name*render-node -> counter-node

`Allan



From lynch30 at marshall.edu  Wed Feb 16 02:20:08 2005
From: lynch30 at marshall.edu (Sean Lynch)
Date: Tue, 15 Feb 2005 21:20:08 -0500
Subject: Crash after recent compile
In-Reply-To: <200502151919.49076.l.savernik@aon.at>
References: <200502131740.06812.lynch30@marshall.edu>
	<200502142307.23769.lynch30@marshall.edu>
	<200502151919.49076.l.savernik@aon.at>
Message-ID: <200502152120.08550.lynch30@marshall.edu>

On Tuesday 15 February 2005 01:19 pm, Leo Savernik wrote:
> Am Dienstag, 15. Februar 2005 05:07 schrieb Sean Lynch:
> > > There's indeed a problem. It affects other pages, too. I'm already
> > > investigating.
> > >
> > > mfg
> > >  Leo
> >
> > The fixes you posted seems to have fixed all bug 1 page,
> > http://sourceforge.net/project/showfiles.php?group_id=97296.  Visiting
> > here produces the following backtrace...
>
> [...]
>
> > #14 0x42805283 in DOM::NodeImpl::closeRenderer (this=) at
> > dom_nodeimpl.cpp:844
>
> This was fixed by Germain, not by me.
>
> > Also, I believe your overflow fixed the mouseovers at
> > http://forums.ocia.net/viewforum.php?f=17, although I noticed the
> > mouseover hotzone only seems to be the height of the link, not the column
> > (the old mouseover prior would only hight the amount of the column/cell
> > which which the font was tall. [...]
>
> Fixed by attached patch. Must still regression test.
>
> mfg
>  Leo

Thank you.  Patch worked as expected.

Sean



From l.savernik at aon.at  Wed Feb 16 18:14:13 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Wed, 16 Feb 2005 19:14:13 +0100
Subject: Generated content: counters and quotes
In-Reply-To: <200502152247.45352.kde@carewolf.com>
References: <200501272244.12213.kde@carewolf.com>
	<200502152215.42610.l.savernik@aon.at>
	<200502152247.45352.kde@carewolf.com>
Message-ID: <200502161914.22850.l.savernik@aon.at>

Am Dienstag, 15. Februar 2005 22:47 schrieb Allan Sandfeld Jensen:
> > additional member in RenderObject.
>
> Sounds interesting. Notice however that all lists and list-items now have a
> counter attached.

Yeah, but only estimated 2% of all render objects will be actual list items. 
That means, in a document containing 100000 render objects, we incur a space 
overhead of 400000 bytes. With a hashmap, we only use space for the purported 
2% of counter-attached nodes, we only have 2000 bytes over (+ overhead of the 
hashmap structures which we occur only once).
>
> With a global structure we really just need a fast way to lookup:
> name*render-node -> counter-node

QPtrDict is a hashmap, so it's O(1). There should be a convenience method that 
allows accessing an associated counter node like

xmlDocImpl()->attachedCounterNode(this)

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050216/63c355ff/attachment.sig>

From bastian at kde.org  Wed Feb 16 18:40:00 2005
From: bastian at kde.org (Waldo Bastian)
Date: Wed, 16 Feb 2005 19:40:00 +0100
Subject: Generated content: counters and quotes
In-Reply-To: <200502161914.22850.l.savernik@aon.at>
References: <200501272244.12213.kde@carewolf.com>
	<200502152247.45352.kde@carewolf.com>
	<200502161914.22850.l.savernik@aon.at>
Message-ID: <200502161940.04912.bastian@kde.org>

On Wednesday 16 February 2005 19:14, Leo Savernik wrote:
> Am Dienstag, 15. Februar 2005 22:47 schrieb Allan Sandfeld Jensen:
> > > additional member in RenderObject.
> >
> > Sounds interesting. Notice however that all lists and list-items now have
> > a counter attached.
>
> Yeah, but only estimated 2% of all render objects will be actual list
> items. That means, in a document containing 100000 render objects, we incur
> a space overhead of 400000 bytes. With a hashmap, we only use space for the
> purported 2% of counter-attached nodes, we only have 2000 bytes over (+
> overhead of the hashmap structures which we occur only once).
>
> > With a global structure we really just need a fast way to lookup:
> > name*render-node -> counter-node
>
> QPtrDict is a hashmap, so it's O(1). There should be a convenience method
> that allows accessing an associated counter node like
>
> xmlDocImpl()->attachedCounterNode(this)

Assuming your hash map is big enough, if it's too small it becomes O(n) again.

Also note that the overhead of doing a lookup in a QPtrDict is larger than 
doing a variable lookup, so I hope you don't want to do the lookup for each 
of the 100000 render objects in the above example. Maybe you have a bit free 
in RenderObject to record whether a node has a counter or not.

Cheers,
Waldo
-- 
bastian at kde.org   |   Free Novell Linux Desktop 9 Evaluation Download
bastian at suse.com  |   http://www.novell.com/products/desktop/eval.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050216/8d189632/attachment.sig>

From kde at carewolf.com  Wed Feb 16 23:33:41 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Thu, 17 Feb 2005 00:33:41 +0100
Subject: Generated content: counters and quotes
In-Reply-To: <200502161940.04912.bastian@kde.org>
References: <200501272244.12213.kde@carewolf.com>
	<200502161914.22850.l.savernik@aon.at>
	<200502161940.04912.bastian@kde.org>
Message-ID: <200502170033.41498.kde@carewolf.com>

On Wednesday 16 February 2005 19:40, Waldo Bastian wrote:
> On Wednesday 16 February 2005 19:14, Leo Savernik wrote:
> > Am Dienstag, 15. Februar 2005 22:47 schrieb Allan Sandfeld Jensen:
> > > > additional member in RenderObject.
> > >
> > > Sounds interesting. Notice however that all lists and list-items now
> > > have a counter attached.
> >
> > Yeah, but only estimated 2% of all render objects will be actual list
> > items. That means, in a document containing 100000 render objects, we
> > incur a space overhead of 400000 bytes. With a hashmap, we only use space
> > for the purported 2% of counter-attached nodes, we only have 2000 bytes
> > over (+ overhead of the hashmap structures which we occur only once).
> >
> > > With a global structure we really just need a fast way to lookup:
> > > name*render-node -> counter-node
> >
> > QPtrDict is a hashmap, so it's O(1). There should be a convenience method
> > that allows accessing an associated counter node like
> >
> > xmlDocImpl()->attachedCounterNode(this)
>
> Assuming your hash map is big enough, if it's too small it becomes O(n)
> again.
>
> Also note that the overhead of doing a lookup in a QPtrDict is larger than
> doing a variable lookup, so I hope you don't want to do the lookup for each
> of the 100000 render objects in the above example. Maybe you have a bit
> free in RenderObject to record whether a node has a counter or not.
>
One bit is not enough. A node can have any number of counters with different 
names. In reality though, only siblings and parents to nodes with counters 
are scanned for counters. All nodes with children with counters, contain an 
empty counter-increment 0 for that counter, so that a sub-tree will always 
contain a subset of the counters of its parents.

Or in other words, it will not be a problem, since the nodes scanned are 
already minimal.

I am more interested in an elegant solution with a key-pair 
(RenderObject*,QString). Apparently QPtrDict uses pointers as keys and not 
values which makes QPair impractical.

`Allan




From frans.englich at telia.com  Sat Feb 19 17:30:58 2005
From: frans.englich at telia.com (Frans Englich)
Date: Sat, 19 Feb 2005 17:30:58 +0000
Subject: [PATCH] KDOM/Namespace.h
Message-ID: <200502191730.58734.frans.englich@telia.com>


Hello,

As more XML implementations starts to pop up, it requires members for holding 
their namespaces. One approach is what is the current trend: putting the 
namespace at the implementation.

However, I find that inconsistent(or rather, could lead to inconsistency), and 
I neither see namespaces as bound to a certain functionality, often code 
mixes different namespaces. That's why I would like to put all namespaces in 
one, consistent, and centralized place, which the attached patch does, 
similarly to some Java and Python libraries.

I have a C++ question too. Assuming it is of no interest to use the classic 
abilities of a class(instantiation, function members, etc), why couldn't the 
Namespace class instead be a namespace(e.g a namespace inside namespace KDOM) 
as the attached file is? I don't know what a C++ namespace becomes in the 
resulting object file, but I suspect simply an altered symbol name. Perhaps 
whether a namespace or a class should be used to house namespace members is a 
matter of performance -- feel free to enlighten me.


Cheers,

		Frans
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Namespace.h
Type: text/x-c++hdr
Size: 2775 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050219/93dcae98/attachment.h>

From frans.englich at telia.com  Sun Feb 20 18:29:56 2005
From: frans.englich at telia.com (Frans Englich)
Date: Sun, 20 Feb 2005 18:29:56 +0000
Subject: Handling errors: DOMError, DOMObject, DOMLocator
Message-ID: <200502201829.56903.frans.englich@telia.com>


Hello,

Many XML applications needs to do error reporting with the physical file as 
background. E.g, they reach a certain point and need to report something that 
was wrong on a certain line.

DOMError and DOMLocator exists, and after having read the DOM 3 core spec, I 
still don't understand how I should use them. When I've found an error, how 
do I create a DOMError, and how do I "pass it on" to the host code(somehow 
the DOMImplementation since it should test it against DOMErrorHandler)?

I'm also wondering about the DOMObject member of DOMError, which currently is 
commented out. AFAICT, the DOMObject is supposed to be a base class which 
data specific to the DOMError object is cast to. How is this supposed to be 
solved? Should all classes inherit from DOMObject? :)

In short: how do one do error reporting?


Cheers,

		Frans




From rwlbuis at xs4all.nl  Sun Feb 20 20:14:15 2005
From: rwlbuis at xs4all.nl (Rob Buis)
Date: Sun, 20 Feb 2005 21:14:15 +0100
Subject: Handling errors: DOMError, DOMObject, DOMLocator
In-Reply-To: <200502201829.56903.frans.englich@telia.com>
References: <200502201829.56903.frans.englich@telia.com>
Message-ID: <20050220201415.GA3673@xs4all.nl>

Hi Frans,

On Sun, Feb 20, 2005 at 06:29:56PM +0000, Frans Englich wrote:
> 
> Hello,
> 
> Many XML applications needs to do error reporting with the physical file as 
> background. E.g, they reach a certain point and need to report something that 
> was wrong on a certain line.
> 
> DOMError and DOMLocator exists, and after having read the DOM 3 core spec, I 
> still don't understand how I should use them. When I've found an error, how 
> do I create a DOMError, and how do I "pass it on" to the host code(somehow 
> the DOMImplementation since it should test it against DOMErrorHandler)?

Well, the configuration in the document seems to store the current
error handler. So you can override that to get to your host code.
 
> I'm also wondering about the DOMObject member of DOMError, which currently is 
> commented out. AFAICT, the DOMObject is supposed to be a base class which 
> data specific to the DOMError object is cast to. How is this supposed to be 
> solved? Should all classes inherit from DOMObject? :)

I am not sure about that one. Seems like a void * kind of thing, or
a generic placeholder. We'll probably find out how to represent them
when we know why they are used/need them :)

> In short: how do one do error reporting?

Have a look at my commit introducing DOMErrorHandler.
To make it possible from user code, maybe I'll implement 
DOMConfiguration soon...
Cheers,

Rob.



From airplays55 at yahoo.com  Sun Feb 20 21:15:05 2005
From: airplays55 at yahoo.com (airplays55 at yahoo.com)
Date: Sun, 20 Feb 2005 13:15:05 -0800 (PST)
Subject: How to associate filetype in konqueror
Message-ID: <20050220211505.71118.qmail@web53602.mail.yahoo.com>

I've written a perl songplayer program that I want to
use when I click on a link to a midi file in
konqueror.

I've gone into file associations and updated the
mimetype audio/x-midi (for filename pattern *.mid)
with the command /path/to/play.pl %u. But when
clicking on a midi link (that I put on my localhost to
eliminate delay), the cursor acts busy for awhile and
the task bar shows "play.pl" with the rotating
hourglass and nothing happens.

My program is an X program that displays a playlist
window, and I never see it appear.  What am I doing
wrong?



		
__________________________________ 
Do you Yahoo!? 
Read only the mail you want - Yahoo! Mail SpamGuard. 
http://promotions.yahoo.com/new_mail 



From faure at kde.org  Mon Feb 21 17:27:46 2005
From: faure at kde.org (David Faure)
Date: Mon, 21 Feb 2005 18:27:46 +0100
Subject: How to associate filetype in konqueror
In-Reply-To: <20050220211505.71118.qmail@web53602.mail.yahoo.com>
References: <20050220211505.71118.qmail@web53602.mail.yahoo.com>
Message-ID: <200502211827.46402.faure@kde.org>

On Sunday 20 February 2005 22:15, airplays55 at yahoo.com wrote:
> I've written a perl songplayer program that I want to
> use when I click on a link to a midi file in
> konqueror.
> 
> I've gone into file associations and updated the
> mimetype audio/x-midi (for filename pattern *.mid)
> with the command /path/to/play.pl %u. But when
> clicking on a midi link (that I put on my localhost to
> eliminate delay), the cursor acts busy for awhile and
> the task bar shows "play.pl" with the rotating
> hourglass and nothing happens.
> 
> My program is an X program that displays a playlist
> window, and I never see it appear.  What am I doing
> wrong?

Answered in private mail already...

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From kde at carewolf.com  Wed Feb 23 10:27:36 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Wed, 23 Feb 2005 11:27:36 +0100
Subject: Update for konqueror website
Message-ID: <200502231127.36627.kde@carewolf.com>

Hello

To mark the upcomming 3.4 release, I've updated our claims on the Konqueror 
website, but since I don't have enough karma, I wan't you to review and 
commit it for me.

`Allan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: update.diff
Type: text/x-diff
Size: 9577 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050223/3a223772/attachment.diff>

From faure at kde.org  Wed Feb 23 12:16:00 2005
From: faure at kde.org (David Faure)
Date: Wed, 23 Feb 2005 13:16:00 +0100
Subject: Update for konqueror website
In-Reply-To: <200502231127.36627.kde@carewolf.com>
References: <200502231127.36627.kde@carewolf.com>
Message-ID: <200502231316.01226.faure@kde.org>

On Wednesday 23 February 2005 11:27, Allan Sandfeld Jensen wrote:
> Hello
> 
> To mark the upcomming 3.4 release, I've updated our claims on the Konqueror 
> website, but since I don't have enough karma, I wan't you to review and 
> commit it for me.

Applied, thanks.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From mikmach at wp.pl  Wed Feb 23 10:38:54 2005
From: mikmach at wp.pl (Mikolaj Machowski)
Date: Wed, 23 Feb 2005 11:38:54 +0100
Subject: Update for konqueror website
In-Reply-To: <200502231127.36627.kde@carewolf.com>
References: <200502231127.36627.kde@carewolf.com>
Message-ID: <200502231138.54983.mikmach@wp.pl>

Dnia środa, 23 lutego 2005 11:27, Allan Sandfeld Jensen napisał:
> Hello
>
> To mark the upcomming 3.4 release, I've updated our claims on the
> Konqueror website, but since I don't have enough karma, I wan't you to
> review and commit it for me.
>
Isn't Opera supporting counters?

Not tested it personally but I was discussing counters few months ago on
pl.comp.www and they said Opera was the only browser (at the moment)
supporting them.

m.




From kde at carewolf.com  Wed Feb 23 13:31:19 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Wed, 23 Feb 2005 14:31:19 +0100
Subject: Update for konqueror website
In-Reply-To: <200502231138.54983.mikmach@wp.pl>
References: <200502231127.36627.kde@carewolf.com>
	<200502231138.54983.mikmach@wp.pl>
Message-ID: <200502231431.20430.kde@carewolf.com>

On Wednesday 23 February 2005 11:38, Mikolaj Machowski wrote:
> Dnia środa, 23 lutego 2005 11:27, Allan Sandfeld Jensen napisał:
> > Hello
> >
> > To mark the upcomming 3.4 release, I've updated our claims on the
> > Konqueror website, but since I don't have enough karma, I wan't you to
> > review and commit it for me.
>
> Isn't Opera supporting counters?
>
> Not tested it personally but I was discussing counters few months ago on
> pl.comp.www and they said Opera was the only browser (at the moment)
> supporting them.

I think it does. Which is why I wrote "one of the only", it could be specified 
though. There are a few other errors I've discovered, so I writing an update 
more, which also cleans the FAQ.

`Allan



From jason at keirstead.org  Wed Feb 23 14:23:17 2005
From: jason at keirstead.org (Jason Keirstead)
Date: Wed, 23 Feb 2005 10:23:17 -0400
Subject: Update for konqueror website
In-Reply-To: <200502231127.36627.kde@carewolf.com>
References: <200502231127.36627.kde@carewolf.com>
Message-ID: <200502231023.17366.jason@keirstead.org>

On Wednesday 23 February 2005 6:27 am, Allan Sandfeld Jensen wrote:
> Hello
>
> To mark the upcomming 3.4 release, I've updated our claims on the Konqueror
> website, but since I don't have enough karma, I wan't you to review and
> commit it for me.

Might also want ot update the "about:" screenshot too.

-- 
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
    - Sun Tzu



From kde at carewolf.com  Wed Feb 23 15:27:43 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Wed, 23 Feb 2005 16:27:43 +0100
Subject: Update for konqueror website
In-Reply-To: <200502231023.17366.jason@keirstead.org>
References: <200502231127.36627.kde@carewolf.com>
	<200502231023.17366.jason@keirstead.org>
Message-ID: <200502231627.43216.kde@carewolf.com>

On Wednesday 23 February 2005 15:23, Jason Keirstead wrote:
> On Wednesday 23 February 2005 6:27 am, Allan Sandfeld Jensen wrote:
> > Hello
> >
> > To mark the upcomming 3.4 release, I've updated our claims on the
> > Konqueror website, but since I don't have enough karma, I wan't you to
> > review and commit it for me.
>
> Might also want ot update the "about:" screenshot too.

That would require breaking the string-freeze.

`Allan



From jason at keirstead.org  Wed Feb 23 15:36:17 2005
From: jason at keirstead.org (Jason Keirstead)
Date: Wed, 23 Feb 2005 11:36:17 -0400
Subject: Update for konqueror website
In-Reply-To: <200502231627.43216.kde@carewolf.com>
References: <200502231127.36627.kde@carewolf.com>
	<200502231023.17366.jason@keirstead.org>
	<200502231627.43216.kde@carewolf.com>
Message-ID: <200502231136.17989.jason@keirstead.org>

On Wednesday 23 February 2005 11:27 am, Allan Sandfeld Jensen wrote:
> That would require breaking the string-freeze.

Huh?

Why would changing an image break a string freeze? And since when is the 
website in a string freeze?

-- 
If you wait by the river long enough, eventually
you will see the bodies of all your enemies float by.
    - Sun Tzu



From yansanmo at iquebec.com  Wed Feb 23 16:15:20 2005
From: yansanmo at iquebec.com (Yan Morin)
Date: Wed, 23 Feb 2005 11:15:20 -0500
Subject: Update for konqueror website
In-Reply-To: <200502231136.17989.jason@keirstead.org>
References: <200502231127.36627.kde@carewolf.com>	<200502231023.17366.jason@keirstead.org>	<200502231627.43216.kde@carewolf.com>
	<200502231136.17989.jason@keirstead.org>
Message-ID: <421CAC18.2010305@iquebec.com>

Jason Keirstead a écrit :
> On Wednesday 23 February 2005 11:27 am, Allan Sandfeld Jensen wrote:
> 
>>That would require breaking the string-freeze.
> 
> 
> Huh?
> 
> Why would changing an image break a string freeze? And since when is the 
> website in a string freeze?
> 
Will be a HTML4.01 compliance list and DOM compliance list like the CSS one?
I know by example that frame, rule inside table wasn't supported like
0 value inside colspan/rowspan by example.
Could a little paragraph about XHTML (application/xhtml+xml) could be 
good too?

And since when is empty-cells working?

-- 
Yan Morin
http://yansanmo.no-ip.org:8080/



From kde at carewolf.com  Wed Feb 23 16:21:00 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Wed, 23 Feb 2005 17:21:00 +0100
Subject: Update for konqueror website
In-Reply-To: <200502231136.17989.jason@keirstead.org>
References: <200502231127.36627.kde@carewolf.com>
	<200502231627.43216.kde@carewolf.com>
	<200502231136.17989.jason@keirstead.org>
Message-ID: <200502231721.00762.kde@carewolf.com>

On Wednesday 23 February 2005 16:36, Jason Keirstead wrote:
> On Wednesday 23 February 2005 11:27 am, Allan Sandfeld Jensen wrote:
> > That would require breaking the string-freeze.
>
> Huh?
>
> Why would changing an image break a string freeze? And since when is the
> website in a string freeze?

Sorry, I didn't read it properly. Yes the about screenshot should be updated 
as well. In fact most of the screenshots should be updated to reflect new 
look.

I was refering the about: screen inside konqueror. The specifications there 
are as outdated as those on the homepage was.

`Allan



From kde at carewolf.com  Wed Feb 23 16:25:52 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Wed, 23 Feb 2005 17:25:52 +0100
Subject: Update for konqueror website
In-Reply-To: <421CAC18.2010305@iquebec.com>
References: <200502231127.36627.kde@carewolf.com>
	<200502231136.17989.jason@keirstead.org>
	<421CAC18.2010305@iquebec.com>
Message-ID: <200502231725.53091.kde@carewolf.com>

On Wednesday 23 February 2005 17:15, Yan Morin wrote:
> Jason Keirstead a écrit :
> > On Wednesday 23 February 2005 11:27 am, Allan Sandfeld Jensen wrote:
> >>That would require breaking the string-freeze.
> >
> > Huh?
> >
> > Why would changing an image break a string freeze? And since when is the
> > website in a string freeze?
>
> Will be a HTML4.01 compliance list and DOM compliance list like the CSS
> one? I know by example that frame, rule inside table wasn't supported like
> 0 value inside colspan/rowspan by example.
Please make or start a list. I am most familiar with CSS standards and so much 
all the properties of HTML 4.01.

> Could a little paragraph about XHTML (application/xhtml+xml) could be
> good too?
Yes. We should note we handle it (poorly).

> And since when is empty-cells working?
Dunno. I checked a test that indicated it worked. If you know something that 
doesn't, please correct me and open a bug for it on bugs.kde.org.

`Allan




From l.savernik at aon.at  Wed Feb 23 18:46:41 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Wed, 23 Feb 2005 19:46:41 +0100
Subject: Update for konqueror website
In-Reply-To: <200502231725.53091.kde@carewolf.com>
References: <200502231127.36627.kde@carewolf.com>
	<421CAC18.2010305@iquebec.com>
	<200502231725.53091.kde@carewolf.com>
Message-ID: <200502231946.48217.l.savernik@aon.at>

Am Mittwoch, 23. Februar 2005 17:25 schrieb Allan Sandfeld Jensen:
> > And since when is empty-cells working?
>
> Dunno. I checked a test that indicated it worked. If you know something
> that doesn't, please correct me and open a bug for it on bugs.kde.org.

empty-cells works partially since border-collapse. It doesn't collapse the row 
if all cells are empty, though.

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050223/99e2613c/attachment.sig>

From l.savernik at aon.at  Wed Feb 23 21:41:29 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Wed, 23 Feb 2005 22:41:29 +0100
Subject: crash looking at #99797
Message-ID: <200502232241.36331.l.savernik@aon.at>

Hello,

When loading bug 99797 at bugs.kde.org, konqueror cvs crashes. Can anybody 
reproduce this?

Steps to reproduce:
1. Load bugs.kde.org/99797
2. (If it doesn't crash) scroll the page and/or select text

Interestingly, seemingly no other bug report at bko makes konqueror crash.

Bt attached, it is really strange. Valgrind produces a SIGALARM
-------------- next part --------------
[New Thread 1024 (LWP 26347)]
[KCrash handler]
#6  0x40d30d11 in QApplication::palette (w=0x84dedac)
    at kernel/qapplication.cpp:1816
#7  0x41ba40da in khtml::RenderText::paint (this=0x85b8ba4, pI=@0xbfffe268, 
    tx=29, ty=150)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_text.cpp:922
#8  0x41b8c74c in khtml::RenderInline::paint (this=0x85b8520, i=@0xbfffe268, 
    _tx=29, _ty=150)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_inline.cpp:265
#9  0x41b87a70 in khtml::RenderBlock::paintObject (this=0x85b8584, 
    pI=@0xbfffe268, _tx=29, _ty=150, shouldPaintOutline=true)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1307
#10 0x41b878a1 in khtml::RenderBlock::paint (this=0x85b8584, pI=@0xbfffe268, 
    _tx=29, _ty=150)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1263
#11 0x41b87a70 in khtml::RenderBlock::paintObject (this=0x83e5ef4, 
    pI=@0xbfffe268, _tx=29, _ty=117, shouldPaintOutline=true)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1307
#12 0x41b878a1 in khtml::RenderBlock::paint (this=0x83e5ef4, pI=@0xbfffe268, 
    _tx=29, _ty=117)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1263
#13 0x41b87a70 in khtml::RenderBlock::paintObject (this=0x83e5dfc, 
    pI=@0xbfffe268, _tx=0, _ty=95, shouldPaintOutline=true)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1307
#14 0x41b878a1 in khtml::RenderBlock::paint (this=0x83e5dfc, pI=@0xbfffe268, 
    _tx=0, _ty=95)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1263
#15 0x41b87a70 in khtml::RenderBlock::paintObject (this=0x83e55e0, 
    pI=@0xbfffe268, _tx=0, _ty=0, shouldPaintOutline=true)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1307
#16 0x41b878a1 in khtml::RenderBlock::paint (this=0x83e55e0, pI=@0xbfffe268, 
    _tx=0, _ty=0)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1263
#17 0x41b87a70 in khtml::RenderBlock::paintObject (this=0x83e5508, 
    pI=@0xbfffe268, _tx=0, _ty=0, shouldPaintOutline=true)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1307
#18 0x41b878a1 in khtml::RenderBlock::paint (this=0x83e5508, pI=@0xbfffe268, 
    _tx=0, _ty=0)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_block.cpp:1263
#19 0x41ba7f30 in khtml::RenderLayer::paintLayer (this=0x83e5584, 
    rootLayer=0x83e54ac, p=0x84ded88, paintDirtyRect=@0xbfffe458, 
    selectionOnly=false)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_layer.cpp:791
#20 0x41ba8082 in khtml::RenderLayer::paintLayer (this=0x83e54ac, 
    rootLayer=0x83e54ac, p=0x84ded88, paintDirtyRect=@0xbfffe458, 
    selectionOnly=false)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_layer.cpp:810
#21 0x41ba7a50 in khtml::RenderLayer::paint (this=0x83e54ac, p=0x84ded88, 
    damageRect=@0xbfffe458, selectionOnly=false)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/rendering/render_layer.cpp:693
#22 0x41adf575 in KHTMLView::drawContents (this=0x84dd260, p=0xbfffe540, ex=0, 
    ey=0, ew=815, eh=474)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/khtmlview.cpp:685
#23 0x40e88d9d in QScrollView::drawContentsOffset (this=0x84dd260, 
    p=0xbfffe540, offsetx=-2000, offsety=-3320, clipx=0, clipy=0, clipw=815, 
    cliph=474) at widgets/qscrollview.cpp:2334
#24 0x40e87377 in QScrollView::viewportPaintEvent (this=0x84dd260, 
    pe=0xbfffeae8) at widgets/qscrollview.cpp:1696
#25 0x40e86aee in QScrollView::eventFilter (this=0x84dd260, obj=0x84de7a8, 
    e=0xbfffeae8) at widgets/qscrollview.cpp:1490
#26 0x41ae4614 in KHTMLView::eventFilter (this=0x84dd260, o=0x84de7a8, 
    e=0xbfffeae8)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/khtmlview.cpp:1904
#27 0x40d7e78e in QObject::activate_filters (this=0x84de7a8, e=0xbfffeae8)
    at kernel/qobject.cpp:902
#28 0x40d7e5a5 in QObject::event (this=0x84de7a8, e=0xbfffeae8)
    at kernel/qobject.cpp:735
#29 0x40db19d8 in QWidget::event (this=0x84de7a8, e=0xbfffeae8)
    at kernel/qwidget.cpp:4650
#30 0x40d32a55 in QApplication::internalNotify (this=0xbffff3b4, 
    receiver=0x84de7a8, e=0xbfffeae8) at kernel/qapplication.cpp:2618
#31 0x40d324a2 in QApplication::notify (this=0xbffff3b4, receiver=0x84de7a8, 
    e=0xbfffeae8) at kernel/qapplication.cpp:2506
#32 0x40863b0a in KApplication::notify (this=0xbffff3b4, receiver=0x84de7a8, 
    event=0xbfffeae8)
    at /leo/projekte/Fremde/kde/src/kdelibs/kdecore/kapplication.cpp:549
#33 0x4117cd64 in QApplication::sendEvent (receiver=0x84de7a8, 
    event=0xbfffeae8) at .moc/debug-shared-mt/../../kernel/qapplication.h:491
#34 0x40d03a69 in QWidget::repaint (this=0x84de7a8, x=2000, y=3320, w=815, 
    h=474, erase=true) at kernel/qwidget_x11.cpp:1576
#35 0x40e88d1c in QScrollView::repaintContents (this=0x84dd260, x=2000, 
    y=3320, w=815, h=474, erase=true) at widgets/qscrollview.cpp:2318
#36 0x40e88b30 in QScrollView::repaintContents (this=0x84dd260, r=@0xbfffec28, 
    erase=true) at widgets/qscrollview.cpp:2260
#37 0x41ae9f9f in KHTMLView::timerEvent (this=0x84dd260, e=0xbfffef48)
    at /leo/projekte/Fremde/kde/src/kdelibs/khtml/khtmlview.cpp:3022
#38 0x40d7e5f5 in QObject::event (this=0x84dd260, e=0xbfffef48)
    at kernel/qobject.cpp:741
#39 0x40db19d8 in QWidget::event (this=0x84dd260, e=0xbfffef48)
    at kernel/qwidget.cpp:4650
#40 0x40d32a55 in QApplication::internalNotify (this=0xbffff3b4, 
    receiver=0x84dd260, e=0xbfffef48) at kernel/qapplication.cpp:2618
#41 0x40d324a2 in QApplication::notify (this=0xbffff3b4, receiver=0x84dd260, 
    e=0xbfffef48) at kernel/qapplication.cpp:2506
#42 0x40863b0a in KApplication::notify (this=0xbffff3b4, receiver=0x84dd260, 
    event=0xbfffef48)
    at /leo/projekte/Fremde/kde/src/kdelibs/kdecore/kapplication.cpp:549
#43 0x4117cd64 in QApplication::sendEvent (receiver=0x84dd260, 
    event=0xbfffef48) at .moc/debug-shared-mt/../../kernel/qapplication.h:491
#44 0x40d2389a in QEventLoop::activateTimers (this=0x80f5060)
    at kernel/qeventloop_unix.cpp:558
#45 0x40ce2f3a in QEventLoop::processEvents (this=0x80f5060, flags=4)
    at kernel/qeventloop_x11.cpp:389
#46 0x40d42fd0 in QEventLoop::enterLoop (this=0x80f5060)
    at kernel/qeventloop.cpp:198
#47 0x40d42ef5 in QEventLoop::exec (this=0x80f5060)
    at kernel/qeventloop.cpp:145
#48 0x40d32c55 in QApplication::exec (this=0xbffff3b4)
    at kernel/qapplication.cpp:2741
#49 0x4005d946 in kdemain (argc=2, argv=0xbffff514)
    at /leo/projekte/Fremde/kde/src/kdebase/konqueror/konq_main.cc:206
#50 0x804877a in main (argc=2, argv=0xbffff514) at konqueror.la.cc:2
#51 0x41573baf in __libc_start_main () from /lib/libc.so.6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050223/6f3f7232/attachment.sig>

From coolo at kde.org  Thu Feb 24 14:47:02 2005
From: coolo at kde.org (Stephan Kulow)
Date: Thu, 24 Feb 2005 15:47:02 +0100
Subject: crash looking at #99797
In-Reply-To: <200502232241.36331.l.savernik@aon.at>
References: <200502232241.36331.l.savernik@aon.at>
Message-ID: <200502241547.03198.coolo@kde.org>

Am Wednesday 23 February 2005 22:41 schrieb Leo Savernik:
>   at /leo/projekte/Fremde/kde
Come on - it's time you move it to /leo/projekte/Unsere/kde ;)

Greetings, Stephan




From ott-list at thaigate.nii.ac.jp  Fri Feb 25 05:38:42 2005
From: ott-list at thaigate.nii.ac.jp (Pattara Kiatisevi)
Date: Fri, 25 Feb 2005 14:38:42 +0900
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
Message-ID: <200502251438.42974.ott-list@thaigate.nii.ac.jp>

Hello,

Regarding the Thai word break patch in KHTML, after testing longer 
there were some intermittent crashes. I updated the patch (basically 
add khtml::init_thaibreaks() in rendering/break_lines.cpp) and have 
tested it for about 3 weeks. So far so good, no crash. Would you  
have a look and if no problem please add to the CVS?

Cheers,
Pattara


-------------- next part --------------
A non-text attachment was scrubbed...
Name: fix-crash-bug-from-3.3.1.diff
Type: text/x-diff
Size: 4621 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050225/cade8edd/attachment.diff>

From l.savernik at aon.at  Fri Feb 25 16:51:29 2005
From: l.savernik at aon.at (Leo Savernik)
Date: Fri, 25 Feb 2005 17:51:29 +0100
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
In-Reply-To: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
References: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
Message-ID: <200502251751.42346.l.savernik@aon.at>

Am Freitag, 25. Februar 2005 06:38 schrieb Pattara Kiatisevi:
> Hello,
>
> Regarding the Thai word break patch in KHTML, after testing longer
> there were some intermittent crashes. I updated the patch (basically
> add khtml::init_thaibreaks() in rendering/break_lines.cpp) and have
> tested it for about 3 weeks. So far so good, no crash. Would you
> have a look and if no problem please add to the CVS?

Your patch will make khtml load libthai unconditionally, even if no thai text 
is ever encountered. libthai should only be loaded on demand (except if 
directly linked against it, of course).
>
[...]

mfg
 Leo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20050225/b3e79726/attachment.sig>

From germain at ebooksfrance.org  Fri Feb 25 17:17:42 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Fri, 25 Feb 2005 17:17:42 +0000
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
In-Reply-To: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
References: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
Message-ID: <200502251717.43150.germain@ebooksfrance.org>

Le vendredi 25 Février 2005 05:38, Pattara Kiatisevi a écrit :
> Hello,
>
> Regarding the Thai word break patch in KHTML, after testing longer
> there were some intermittent crashes.

where does it crash and why? any backtrace?
I've got the same concerns than Leo /wrt your patch.

Greetings,
Germain



From frans.englich at telia.com  Fri Feb 25 21:38:31 2005
From: frans.englich at telia.com (Frans Englich)
Date: Fri, 25 Feb 2005 21:38:31 +0000
Subject: Handling errors: DOMError, DOMObject, DOMLocator
In-Reply-To: <20050220201415.GA3673@xs4all.nl>
References: <200502201829.56903.frans.englich@telia.com>
	<20050220201415.GA3673@xs4all.nl>
Message-ID: <200502252138.31664.frans.englich@telia.com>

On Sunday 20 February 2005 20:14, Rob Buis wrote:
> Hi Frans,
>
> On Sun, Feb 20, 2005 at 06:29:56PM +0000, Frans Englich wrote:
> > Hello,
> >
> > Many XML applications needs to do error reporting with the physical file
> > as background. E.g, they reach a certain point and need to report
> > something that was wrong on a certain line.
> >
> > DOMError and DOMLocator exists, and after having read the DOM 3 core
> > spec, I still don't understand how I should use them. When I've found an
> > error, how do I create a DOMError, and how do I "pass it on" to the host
> > code(somehow the DOMImplementation since it should test it against
> > DOMErrorHandler)?
>
> Well, the configuration in the document seems to store the current
> error handler. So you can override that to get to your host code.
>
> > I'm also wondering about the DOMObject member of DOMError, which
> > currently is commented out. AFAICT, the DOMObject is supposed to be a
> > base class which data specific to the DOMError object is cast to. How is
> > this supposed to be solved? Should all classes inherit from DOMObject? :)
>
> I am not sure about that one. Seems like a void * kind of thing, or
> a generic placeholder. We'll probably find out how to represent them
> when we know why they are used/need them :)
>
> > In short: how do one do error reporting?
>
> Have a look at my commit introducing DOMErrorHandler.
> To make it possible from user code, maybe I'll implement
> DOMConfiguration soon...

Ok, then I'll use a dummy DOMErrorHandler for now. Another thing which needs 
consideration(AFAICT) is how to create DOMLocators from Nodes. E.g, many 
implementations needs to do error reporting while pointing to a certain line 
and column.

libxml2 keeps a line number member in their node struct, and KDOM's document 
builder could perhaps do the same? This would be non-DOM, since DOM doesn't 
provide a mechanism for deriving line/column number from a Node, AFAICT.

> To make it possible from user code, maybe I'll implement
> DOMConfiguration soon...

(It will be interesting to see what data type DOMConfiguration::getParameter 
will return since there's no common base class. Also, it looks like 
KDOM::Parser should not inherit/provide an DOMErrorHandler, but instead call 
the handler retrievable via DOMConfiguration, when available.)


Cheers,

		Frans



From koos.vriezen at xs4all.nl  Sat Feb 26 15:04:27 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 26 Feb 2005 16:04:27 +0100
Subject: Allowing "javascript:xxx" frames
Message-ID: <20050226150426.GB89426@xs4all.nl>

Hi,

Consider this testcase, both as local file and non-local (eg. cp to
public_html and http://localhost/~me/testcase.html) and see the
differences:
 <html>
  <frameset cols="25%,75%" >
   <frame src="javascript:'<HTML></HTML>'" name="toc">
   <frame src="javascript:'<HTML></HTML>'" name="body">
  </frameset>
 </html>

Most likely it's some accessing restriction. But it doesn't print a
warning, so maybe someone on this list can tell where this is blocked.
I don't think it should, no?

Koos



From koos.vriezen at xs4all.nl  Sat Feb 26 17:23:21 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sat, 26 Feb 2005 18:23:21 +0100
Subject: Allowing "javascript:xxx" frames
In-Reply-To: <20050226150426.GB89426@xs4all.nl>
References: <20050226150426.GB89426@xs4all.nl>
Message-ID: <20050226172321.GC89426@xs4all.nl>

On Sat, Feb 26, 2005 at 04:04:27PM +0100, Koos Vriezen wrote:
> Hi,
> 
> Consider this testcase, both as local file and non-local (eg. cp to
> public_html and http://localhost/~me/testcase.html) and see the
> differences:
>  <html>
>   <frameset cols="25%,75%" >
>    <frame src="javascript:'<HTML></HTML>'" name="toc">
>    <frame src="javascript:'<HTML></HTML>'" name="body">
>   </frameset>
>  </html>
> 
> Most likely it's some accessing restriction. But it doesn't print a
> warning, so maybe someone on this list can tell where this is blocked.

Never mind, couldn't resist looking myself anyways :-). So it's in
xml/dom_docimpl.cpp:2130:
  if ( !kapp || !kapp->authorizeURLAction("redirect", w->part()->url(), newURL) )
      return false;

I've been looking where this should be handled, javascript urls, and I
can imagine each element has to decide for itself if it should run the
script engine for an attribute or not. However, in case of SRC, some
attributes may have to be evaluated always.
You khtml developers have to find the right place for it, because I can
only guess.

Anyhow, this q&d patch makes it work for me:

diff -u -3 -p -r1.203 html_baseimpl.cpp
--- html/html_baseimpl.cpp      21 Dec 2004 15:31:18 -0000      1.203
+++ html/html_baseimpl.cpp      26 Feb 2005 17:18:03 -0000
@@ -237,13 +237,20 @@ NodeImpl::Id HTMLFrameElementImpl::id()
 {
     return ID_FRAME;
 }
-
+#include <qvariant.h>
 void HTMLFrameElementImpl::parseAttribute(AttributeImpl *attr)
 {
     switch(attr->id())
     {
-    case ATTR_SRC:
-        setLocation(khtml::parseURL(attr->val()));
+    case ATTR_SRC: {
+        QString v = DOMString(attr->val()).string();
+        if (v.startsWith(QString::fromLatin1("javascript:"))) {
+            KHTMLView* w = getDocument()->view();
+            if (w)
+                v = w->part()->executeScript(this, v).toString();
+        }
+        setLocation(khtml::parseURL(v));
+                   }
         break;
     case ATTR_ID:
     case ATTR_NAME:

Pages if found that work w/ this patch, and just a white screen w/o,  are
http://www.myelectronics.nl/
http://service.real.com/help/library/guides/realone/ProductionGuide/HTML/realpgd.htm?page=htmfiles/smilintr.htm%23overview

This is a regression against kde-3.3 btw.


> I don't think it should, no?
> 
> Koos



From ismail at kde.org.tr  Sun Feb 27 07:45:49 2005
From: ismail at kde.org.tr (Ismail Donmez)
Date: Sun, 27 Feb 2005 09:45:49 +0200
Subject: Konqueror crashing at exit
Message-ID: <200502270945.50481.ismail@kde.org.tr>

Latest konqueror from cvs head seems to crash at exit. Here is the backtrace :

#4  0xb77f5f0c in QGDict::unlink_ptr (this=0x70, key=0x865c398, d=0x0)
    at tools/qgdict.cpp:644
#5  0xb77f61bd in QGDict::remove_ptr (this=0x70, key=0x865c398, item=0x0)
    at tools/qgdict.cpp:705
#6  0xb59bfb55 in QPtrDict<QWidget>::remove (this=0x70, k=0x865c398)
    at qptrdict.h:66
#7  0xb59ae1c1 in KHTMLView::setWidgetVisible (this=0x84a17f8, w=0x865c398, 
    vis=false) at /opt/development/kde/kdelibs/khtml/khtmlview.cpp:2291
#8  0xb5abd61f in khtml::RenderWidget::slotWidgetDestructed (this=0x865c398)
    at /opt/development/kde/kdelibs/khtml/rendering/render_replaced.cpp:325
#9  0xb5abf2ba in khtml::RenderWidget::qt_invoke (this=0x865c398, _id=2, 
    _o=0xbfffe700) at render_replaced.moc:86
#10 0xb5ac98ae in khtml::RenderButton::qt_invoke (this=0x865c398, _id=2, 
    _o=0xbfffe700) at render_form.moc:77
#11 0xb5ac9cab in khtml::RenderRadioButton::qt_invoke (this=0x865c398, _id=2, 
    _o=0xbfffe700) at render_form.moc:245
#12 0xb751ac43 in QObject::activate_signal (this=0x864b798, clist=0x864bae8, 
    o=0xbfffe700) at kernel/qobject.cpp:2355
#13 0xb751aae5 in QObject::activate_signal (this=0x864b798, signal=0)
    at kernel/qobject.cpp:2324
#14 0xb7881288 in QObject::destroyed (this=0x864b798)
    at .moc/debug-shared-mt/moc_qobject.cpp:102
#15 0xb75176bf in ~QObject (this=0x864b798) at kernel/qobject.cpp:446
#16 0xb754eaec in ~QWidget (this=0x864b798) at kernel/qwidget.cpp:983
#17 0xb75b29f2 in ~QButton (this=0x864b798) at widgets/qbutton.cpp:409
#18 0xb78a080e in ~QRadioButton (this=0x864b798)
    at .moc/debug-shared-mt/moc_qradiobutton.cpp:49
#19 0xb754ea32 in ~QWidget (this=0x84aeee8) at kernel/qwidget.cpp:973
#20 0xb764815a in ~QClipperWidget (this=0x84aeee8)
    at widgets/qscrollview.cpp:2591
#21 0xb754ea32 in ~QWidget (this=0x84a2088) at kernel/qwidget.cpp:973
#22 0xb7648068 in ~QViewportWidget (this=0x84a2088)
    at widgets/qscrollview.cpp:631
#23 0xb764200b in ~QScrollView (this=0x84a17f8) at widgets/qscrollview.cpp:631
#24 0xb59a655b in ~KHTMLView (this=0x84a17f8)
    at /opt/development/kde/kdelibs/khtml/khtmlview.cpp:505
#25 0xb7fc09c3 in ~Part (this=0x848eb50, __vtt_parm=0xb5c2d208)
    at /opt/development/kde/kdelibs/kparts/part.cpp:159
#26 0xb7fc15fa in ~ReadOnlyPart (this=0x848eb50, __vtt_parm=0xb5c2d204)
    at /opt/development/kde/kdelibs/kparts/part.cpp:312
#27 0xb59c5356 in ~KHTMLPart (this=0x848eb50)
    at /opt/development/kde/kdelibs/khtml/khtml_part.cpp:503
#28 0xb60644b0 in ~KonqView (this=0x848e508)
    at /opt/development/kde/kdebase/konqueror/konq_view.cc:130
#29 0xb6070f76 in KonqViewManager::clear (this=0x82902a8)
    at /opt/development/kde/kdebase/konqueror/konq_viewmgr.cc:929
#30 0xb60b71a4 in KonqMainWindow::stayPreloaded (this=0x820a6f0)
    at /opt/development/kde/kdebase/konqueror/konq_mainwindow.cc:5593
#31 0xb60b4aa4 in KonqMainWindow::queryExit (this=0x820a6f0)
    at /opt/development/kde/kdebase/konqueror/konq_mainwindow.cc:5114
#32 0xb6db0f6c in KMainWindow::closeEvent (this=0x820a6f0, e=0xbfffefb0)
    at /opt/development/kde/kdelibs/kdeui/kmainwindow.cpp:651
#33 0xb60b49d0 in KonqMainWindow::closeEvent (this=0x820a6f0, e=0xbfffefb0)
    at /opt/development/kde/kdebase/konqueror/konq_mainwindow.cc:5102
#34 0xb7555480 in QWidget::event (this=0x820a6f0, e=0xbfffefb0)
    at kernel/qwidget.cpp:4792
#35 0xb761fdb3 in QMainWindow::event (this=0x820a6f0, e=0xbfffefb0)
    at widgets/qmainwindow.cpp:1686
#36 0xb60b70f1 in KonqMainWindow::event (this=0x820a6f0, e=0xbfffefb0)
    at /opt/development/kde/kdebase/konqueror/konq_mainwindow.cc:5580
#37 0xb74b63f9 in QApplication::internalNotify (this=0xbffff590, 
    receiver=0x820a6f0, e=0xbfffefb0) at kernel/qapplication.cpp:2635
#38 0xb74b602a in QApplication::notify (this=0xbffff590, receiver=0x820a6f0, 
    e=0xbfffefb0) at kernel/qapplication.cpp:2523
#39 0xb7ab979f in KApplication::notify (this=0xbffff590, receiver=0x820a6f0, 
    event=0xbfffefb0)
    at /opt/development/kde/kdelibs/kdecore/kapplication.cpp:549
#40 0xb7fcc57d in QApplication::sendEvent (receiver=0x820a6f0, 
    event=0xbfffefb0) at qapplication.h:491
#41 0xb7554700 in QWidget::close (this=0x820a6f0, alsoDelete=false)
    at kernel/qwidget.cpp:4268
#42 0xb7446296 in QETWidget::translateCloseEvent (this=0x820a6f0)
    at kernel/qapplication_x11.cpp:5778
#43 0xb7440689 in QApplication::x11ClientMessage (this=0xbffff590, 
    w=0x820a6f0, event=0xbffff300, passive_only=false)
    at kernel/qapplication_x11.cpp:3097
#44 0xb7441ae5 in QApplication::x11ProcessEvent (this=0xbffff590, 
    event=0xbffff300) at kernel/qapplication_x11.cpp:3631
#45 0xb745bea1 in QEventLoop::processEvents (this=0x8193928, flags=4)
    at kernel/qeventloop_x11.cpp:192
#46 0xb74cb3cc in QEventLoop::enterLoop (this=0x8193928)
    at kernel/qeventloop.cpp:198
#47 0xb74cb2ea in QEventLoop::exec (this=0x8193928)
    at kernel/qeventloop.cpp:145
#48 0xb74b6579 in QApplication::exec (this=0xbffff590)
    at kernel/qapplication.cpp:2758
#49 0xb6050354 in kdemain (argc=2, argv=0x816de18)
    at /opt/development/kde/kdebase/konqueror/konq_main.cc:206
#50 0xb721f969 in kdeinitmain (argc=2, argv=0x816de18)
    at ./konqueror/kdeinit_konqueror.la.cpp:2
#51 0x0804e2da in launch (argc=2, _name=0x816e214 "konqueror", 
    args=0x816e227 "\001", cwd=0x0, envc=1, envs=0x816e238 "", 
    reset_env=false, tty=0x0, avoid_loops=false, 
    startup_id_str=0x816e23c "southpark;1109490115;425774;5471_TIME172747")
    at /opt/development/kde/kdelibs/kinit/kinit.cpp:625
#52 0x0804f5e9 in handle_launcher_request (sock=8)
    at /opt/development/kde/kdelibs/kinit/kinit.cpp:1189
#53 0x0804fcb4 in handle_requests (waitForPid=0)
    at /opt/development/kde/kdelibs/kinit/kinit.cpp:1392
#54 0x08051178 in main (argc=2, argv=0xbffffc14, envp=0xbffffc20)
    at /opt/development/kde/kdelibs/kinit/kinit.cpp:1848



From ismail at kde.org.tr  Sun Feb 27 10:35:25 2005
From: ismail at kde.org.tr (Ismail Donmez)
Date: Sun, 27 Feb 2005 12:35:25 +0200
Subject: Konqueror crashing at exit
In-Reply-To: <200502270945.50481.ismail@kde.org.tr>
References: <200502270945.50481.ismail@kde.org.tr>
Message-ID: <200502271235.26231.ismail@kde.org.tr>

On Sunday 27 February 2005 09:45, Ismail Donmez wrote:
> Latest konqueror from cvs head seems to crash at exit. Here is the
> backtrace :

Dirk's latest revert seems to fix this.

Cheers,
ismail



From porten at kde.org  Sun Feb 27 13:04:18 2005
From: porten at kde.org (Harri Porten)
Date: Sun, 27 Feb 2005 14:04:18 +0100 (CET)
Subject: Invalid read in RenderWidget::setStyle()
Message-ID: <Pine.LNX.4.44.0502271401330.28375-100000@alster.froglogic.com>

Known memory issue (3.4 branch, www.kde.org)?

==12778== Invalid read of size 4
==12778==    at 0x4048481A: khtml::RenderWidget::setStyle(khtml::RenderStyle *) (/home/porten/cvs/kdelibs/khtml/rendering/render_replaced.cpp:348)
==12778==    by 0x40488F7A: khtml::RenderLineEdit::setStyle(khtml::RenderStyle *) (/home/porten/cvs/kdelibs/khtml/rendering/render_form.cpp:460)
==12778==    by 0x40436362: DOM::HTMLInputElementImpl::attach(void) (/home/porten/cvs/kdelibs/khtml/html/html_formimpl.cpp:1384)
==12778==    by 0x40412CEF: khtml::KHTMLParser::insertNode(DOM::NodeImpl *, bool) (/home/porten/cvs/kdelibs/khtml/html/htmlparser.cpp:329)
==12778==    by 0x40412B7A: khtml::KHTMLParser::parseToken(khtml::Token *) (/home/porten/cvs/kdelibs/khtml/html/htmlparser.cpp:279)
==12778==    by 0x4041BCB2: khtml::HTMLTokenizer::processToken(void) (/home/porten/cvs/kdelibs/khtml/html/htmltokenizer.cpp:1630)
==12778==    by 0x4041A8CC: khtml::HTMLTokenizer::parseTag(khtml::TokenizerString &) (/home/porten/cvs/kdelibs/khtml/html/htmltokenizer.cpp:1131)
==12778==    by 0x4041B06A: khtml::HTMLTokenizer::write(khtml::TokenizerString const &, bool) (/home/porten/cvs/kdelibs/khtml/html/htmltokenizer.cpp:1385)
==12778==    by 0x403BB028: KHTMLPart::write(char const *, int) (/home/porten/cvs/kdelibs/khtml/khtml_part.cpp:1938)
==12778==    by 0x403B976C: KHTMLPart::slotData(KIO::Job *, QMemArray<char> const &) (/home/porten/cvs/kdelibs/khtml/khtml_part.cpp:1629)
==12778==    Address 0x48864D5D is 101 bytes inside a block of size 104 alloc'd
==12778==    at 0x40027C78: __builtin_new (vg_replace_malloc.c:172)
==12778==    by 0x404BC0A0: khtml::CSSStyleSelector::applyRule(int, DOM::CSSValueImpl *) (/home/porten/cvs/kdelibs/khtml/rendering/render_style.h:112)
==12778==    by 0x404B28AC: khtml::CSSStyleSelector::styleForElement(DOM::ElementImpl *) (/home/porten/cvs/kdelibs/khtml/css/cssstyleselector.cpp:477)
==12778==    by 0x404360BC: DOM::HTMLInputElementImpl::attach(void) (/home/porten/cvs/kdelibs/khtml/html/html_formimpl.cpp:1364)
==12778==    by 0x40412CEF: khtml::KHTMLParser::insertNode(DOM::NodeImpl *, bool) (/home/porten/cvs/kdelibs/khtml/html/htmlparser.cpp:329)
==12778==    by 0x40412B7A: khtml::KHTMLParser::parseToken(khtml::Token *) (/home/porten/cvs/kdelibs/khtml/html/htmlparser.cpp:279)
==12778==    by 0x4041BCB2: khtml::HTMLTokenizer::processToken(void) (/home/porten/cvs/kdelibs/khtml/html/htmltokenizer.cpp:1630)
==12778==    by 0x4041A8CC: khtml::HTMLTokenizer::parseTag(khtml::TokenizerString &) (/home/porten/cvs/kdelibs/khtml/html/htmltokenizer.cpp:1131)
==12778==    by 0x4041B06A: khtml::HTMLTokenizer::write(khtml::TokenizerString const &, bool) (/home/porten/cvs/kdelibs/khtml/html/htmltokenizer.cpp:1385)
==12778==    by 0x403BB028: KHTMLPart::write(char const *, int) (/home/porten/cvs/kdelibs/khtml/khtml_part.cpp:1938)

Harri.




From koos.vriezen at xs4all.nl  Sun Feb 27 14:44:10 2005
From: koos.vriezen at xs4all.nl (Koos Vriezen)
Date: Sun, 27 Feb 2005 15:44:10 +0100
Subject: Allowing "javascript:xxx" frames
In-Reply-To: <20050226172321.GC89426@xs4all.nl>
References: <20050226150426.GB89426@xs4all.nl>
	<20050226172321.GC89426@xs4all.nl>
Message-ID: <20050227144410.GD89426@xs4all.nl>

On Sat, Feb 26, 2005 at 06:23:21PM +0100, Koos Vriezen wrote:
> On Sat, Feb 26, 2005 at 04:04:27PM +0100, Koos Vriezen wrote:
> > Hi,
> > 
> > Consider this testcase, both as local file and non-local (eg. cp to
> > public_html and http://localhost/~me/testcase.html) and see the
> > differences:
> >  <html>
> >   <frameset cols="25%,75%" >
> >    <frame src="javascript:'<HTML></HTML>'" name="toc">
> >    <frame src="javascript:'<HTML></HTML>'" name="body">
> >   </frameset>
> >  </html>
> > 
> > Most likely it's some accessing restriction. But it doesn't print a
> > warning, so maybe someone on this list can tell where this is blocked.
> 
> Never mind, couldn't resist looking myself anyways :-). So it's in
> xml/dom_docimpl.cpp:2130:
>   if ( !kapp || !kapp->authorizeURLAction("redirect", w->part()->url(), newURL) )
>       return false;
> 
> I've been looking where this should be handled, javascript urls, and I
> can imagine each element has to decide for itself if it should run the
> script engine for an attribute or not. However, in case of SRC, some
> attributes may have to be evaluated always.

Err, javascript urls are already handled in KHTMLPart::requestFrame and
KHTMLPart::processObjectRequest. The outcome of the script is not a new
url, but the content of the document. So there is not need for
kapp->authorizeURLAction, as we stay in the same domain as parent
document.
So a proper fix would be:

diff -u -3 -p -r1.308 dom_docimpl.cpp
--- xml/dom_docimpl.cpp 16 Feb 2005 22:16:19 -0000      1.308
+++ xml/dom_docimpl.cpp 27 Feb 2005 14:41:46 -0000
@@ -2127,7 +2127,7 @@ bool DocumentImpl::isURLAllowed(const QS
         return false;

     // do we allow this suburl ?
-    if ( !kapp || !kapp->authorizeURLAction("redirect", w->part()->url(), newURL) )
+    if ( !kapp || (newURL.protocol() != "javascript" && !kapp->authorizeURLAction("redirect", w->part()->url(), newURL)) )
         return false;

Koos

> You khtml developers have to find the right place for it, because I can
> only guess.
> 
> Anyhow, this q&d patch makes it work for me:
> 
> diff -u -3 -p -r1.203 html_baseimpl.cpp
> --- html/html_baseimpl.cpp      21 Dec 2004 15:31:18 -0000      1.203
> +++ html/html_baseimpl.cpp      26 Feb 2005 17:18:03 -0000
> @@ -237,13 +237,20 @@ NodeImpl::Id HTMLFrameElementImpl::id()
>  {
>      return ID_FRAME;
>  }
> -
> +#include <qvariant.h>
>  void HTMLFrameElementImpl::parseAttribute(AttributeImpl *attr)
>  {
>      switch(attr->id())
>      {
> -    case ATTR_SRC:
> -        setLocation(khtml::parseURL(attr->val()));
> +    case ATTR_SRC: {
> +        QString v = DOMString(attr->val()).string();
> +        if (v.startsWith(QString::fromLatin1("javascript:"))) {
> +            KHTMLView* w = getDocument()->view();
> +            if (w)
> +                v = w->part()->executeScript(this, v).toString();
> +        }
> +        setLocation(khtml::parseURL(v));
> +                   }
>          break;
>      case ATTR_ID:
>      case ATTR_NAME:
> 
> Pages if found that work w/ this patch, and just a white screen w/o,  are
> http://www.myelectronics.nl/
> http://service.real.com/help/library/guides/realone/ProductionGuide/HTML/realpgd.htm?page=htmfiles/smilintr.htm%23overview
> 
> This is a regression against kde-3.3 btw.
> 
> 
> > I don't think it should, no?
> > 
> > Koos



From yansanmo at iquebec.com  Mon Feb 28 00:01:40 2005
From: yansanmo at iquebec.com (Yan Morin)
Date: Sun, 27 Feb 2005 19:01:40 -0500
Subject: KJS: changing an input name
Message-ID: <42225F64.5060806@iquebec.com>

Could someone confirm this bug ?
http://yansanmo.no-ip.org:8080/test/kde/input_clone.htm

I clone an input form.
Change the name.
Add it to the form.
Try to access it with is new name, but it seems that Konqueror use the 
first name.


-- 
Yan Morin
http://yansanmo.no-ip.org:8080/



From faure at kde.org  Mon Feb 28 00:59:01 2005
From: faure at kde.org (David Faure)
Date: Mon, 28 Feb 2005 01:59:01 +0100
Subject: KJS: changing an input name
In-Reply-To: <42225F64.5060806@iquebec.com>
References: <42225F64.5060806@iquebec.com>
Message-ID: <200502280159.03189.faure@kde.org>

On Monday 28 February 2005 01:01, Yan Morin wrote:
> Could someone confirm this bug ?
> http://yansanmo.no-ip.org:8080/test/kde/input_clone.htm
> 
> I clone an input form.
> Change the name.
> Add it to the form.
> Try to access it with is new name, but it seems that Konqueror use the 
> first name.

Confirmed... and fixed.

--- html/html_formimpl.cpp      20 Feb 2005 17:36:46 -0000      1.421
+++ html/html_formimpl.cpp      28 Feb 2005 00:57:05 -0000
@@ -868,6 +868,7 @@ void HTMLGenericFormElementImpl::setName
 {
     if (m_name) m_name->deref();
     m_name = name.implementation();
+    setAttribute( ATTR_NAME, name );
     if (m_name) m_name->ref();
 }

Thanks for your testcases once again :)

(PS: I didn't have your email address to tell you, but I recently fixed the 
onchange problems you told me about on IRC long ago)

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From faure at kde.org  Mon Feb 28 02:10:46 2005
From: faure at kde.org (David Faure)
Date: Mon, 28 Feb 2005 03:10:46 +0100
Subject: case change again
Message-ID: <200502280310.47554.faure@kde.org>

Running testregression in forms/ showed that all DOM comparisons failed due to case
comparison - <html> became <HTML>, <script> became <SCRIPT> etc.

The weird thing is that it changed the other way round at the end of December:

revision 1.2
date: 2004/12/29 19:56:04;  author: carewolf;  state: Exp;  lines: +5 -4
1920 DOM only changes
===================================================================
RCS file: /home/kde/khtmltests/regression/baseline/forms/form_setattribute.html-dom,v
diff -b -p -u -r1.1 -r1.2
--- form_setattribute.html-dom  23 Oct 2004 10:30:48 -0000      1.1
+++ form_setattribute.html-dom  29 Dec 2004 19:56:04 -0000      1.2
@@ -1,8 +1,9 @@
 #document
-  HTML
-    SCRIPT
+  html
+    script

But now I get 

--- form_setattribute.html-dom  2005-02-11 14:03:48.000000000 +0100
+++ ../../output/forms/form_setattribute.html-dom       2005-02-28 02:28:38.864133422 +0100
@@ -1,9 +1,9 @@
 #document
-  html
-    script
+  HTML
+    SCRIPT

Any ideas? Which one is correct?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From mikmach at wp.pl  Mon Feb 28 11:27:10 2005
From: mikmach at wp.pl (Mikolaj Machowski)
Date: Mon, 28 Feb 2005 12:27:10 +0100
Subject: crash of 27 Feb snapshot (CVS-HEAD)
Message-ID: <200502281227.10241.mikmach@wp.pl>


Many tabs opened and:

Using host libthread_db library "/lib/i686/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 2254)]
[KCrash handler]
#5  0x40c66bcd in QScrollView::visibleWidth() const ()
   from /usr/lib/qt3/lib/libqt-mt.so.3
#6  0x08051a40 in ?? ()
#7  0x41d0ae78 in ?? () from /usr/local/kde/lib/libkhtml.so.4
#8  0x41b9af3a in khtml::RenderCanvas::viewRect() const ()
   from /usr/local/kde/lib/libkhtml.so.4
#9  0x41b9a85b in khtml::RenderCanvas::repaintRectangle(int, int, int, int, 
bool, bool) () from /usr/local/kde/lib/libkhtml.so.4
#10 0x41b6aa0b in khtml::RenderBox::repaintRectangle(int, int, int, int, 
bool, bool) () from /usr/local/kde/lib/libkhtml.so.4
#11 0x41b6aa0b in khtml::RenderBox::repaintRectangle(int, int, int, int, 
bool, bool) () from /usr/local/kde/lib/libkhtml.so.4
#12 0x41b6aa0b in khtml::RenderBox::repaintRectangle(int, int, int, int, 
bool, bool) () from /usr/local/kde/lib/libkhtml.so.4
#13 0x41b6aa0b in khtml::RenderBox::repaintRectangle(int, int, int, int, 
bool, bool) () from /usr/local/kde/lib/libkhtml.so.4
#14 0x41b6aa0b in khtml::RenderBox::repaintRectangle(int, int, int, int, 
bool, bool) () from /usr/local/kde/lib/libkhtml.so.4
#15 0x41b78b7f in khtml::RenderImage::setPixmap(QPixmap const&, QRect 
const&, khtml::CachedImage*) () from /usr/local/kde/lib/libkhtml.so.4
#16 0x41bdc36e in khtml::CachedImage::do_notify(QPixmap const&, QRect 
const&)
    () from /usr/local/kde/lib/libkhtml.so.4
#17 0x41bdc96b in khtml::CachedImage::movieUpdated(QRect const&) ()
   from /usr/local/kde/lib/libkhtml.so.4
#18 0x41bdd737 in khtml::CachedImage::qt_invoke(int, QUObject*) ()
   from /usr/local/kde/lib/libkhtml.so.4
#19 0x40b482a8 in QObject::activate_signal(QConnectionList*, QUObject*) ()
   from /usr/lib/qt3/lib/libqt-mt.so.3




-- 
LaTeX + Vim = http://vim-latex.sourceforge.net/
Vim Universal Templates 
	http://www.vim.org/scripts/script.php?script_id=1078
CLEWN - http://clewn.sf.net





From kde at carewolf.com  Mon Feb 28 11:42:02 2005
From: kde at carewolf.com (Allan Sandfeld Jensen)
Date: Mon, 28 Feb 2005 12:42:02 +0100
Subject: crash of 27 Feb snapshot (CVS-HEAD)
In-Reply-To: <200502281227.10241.mikmach@wp.pl>
References: <200502281227.10241.mikmach@wp.pl>
Message-ID: <200502281242.02823.kde@carewolf.com>

I've received a similar backtrace from Dominik Haumann, but this one has 
debug-info.
-------------- next part --------------

Using host libthread_db library "/lib/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 20769)]
[KCrash handler]
#5  0xb739a13c in QScrollView::clipper () from /usr/qt/3/lib/libqt-mt.so.3
#6  0xb739a16d in QScrollView::visibleHeight ()
from /usr/qt/3/lib/libqt-mt.so.3
#7  0xb66552a8 in khtml::RenderCanvas::viewRect (this=0x8450d00)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/rendering/render_canvas.cpp:627
#8  0xb66540b3 in khtml::RenderCanvas::repaintRectangle (this=0x8450d00, x=0, 
y=0, w=88, h=31, immediate=false, f=false)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/rendering/render_canvas.cpp:287
#9  0xb661cd04 in khtml::RenderBox::repaintRectangle (this=0x8450e18, x=0, 
y=0, w=88, h=31, immediate=false, f=false)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/rendering/render_box.cpp:696
#10 0xb661cd04 in khtml::RenderBox::repaintRectangle (this=0x8450ef0, x=0, 
y=0, w=88, h=31, immediate=false, f=false)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/rendering/render_box.cpp:696
#11 0xb661cd04 in khtml::RenderBox::repaintRectangle (this=0x8450f6c, x=0, 
y=0, w=88, h=31, immediate=false, f=false)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/rendering/render_box.cpp:696
#12 0xb661cd04 in khtml::RenderBox::repaintRectangle (this=0x8450fd0, x=0, 
y=0, w=88, h=31, immediate=false, f=false)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/rendering/render_box.cpp:696
#13 0xb662f1d6 in khtml::RenderImage::setPixmap (this=0x8450fd0, p=@0x84531c8, 
r=@0x84531a0, o=0x8455138)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/rendering/render_image.cpp:203
#14 0xb66933a5 in khtml::CachedImage::do_notify (this=0x8455138, p=@0x84531c8, 
r=@0x84531a0)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/misc/loader.cpp:628
#15 0xb66933ef in khtml::CachedImage::movieUpdated (this=0x8455138, 
r=@0x84531a0)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/khtml/misc/loader.cpp:639
#16 0xb66971b4 in khtml::CachedImage::qt_invoke (this=0x8455138, _id=2, 
_o=0xbfffe130) at loader.moc:99
#17 0xb72815c4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#18 0xb727882e in QMoviePrivate::areaChanged ()
from /usr/qt/3/lib/libqt-mt.so.3
#19 0xb72788f4 in QMoviePrivate::showChanges ()
from /usr/qt/3/lib/libqt-mt.so.3
#20 0xb727905a in QMoviePrivate::frameDone () from /usr/qt/3/lib/libqt-mt.so.3
#21 0xb722723b in QGIFFormat::decode () from /usr/qt/3/lib/libqt-mt.so.3
#22 0xb7227ff4 in QImageDecoder::decode () from /usr/qt/3/lib/libqt-mt.so.3
#23 0xb72790e4 in QMoviePrivate::flushBuffer ()
from /usr/qt/3/lib/libqt-mt.so.3
#24 0xb7279221 in QMoviePrivate::refresh () from /usr/qt/3/lib/libqt-mt.so.3
#25 0xb72792c8 in QMoviePrivate::qt_invoke () from /usr/qt/3/lib/libqt-mt.so.3
#26 0xb72815c4 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#27 0xb7281ce2 in QObject::activate_signal () from /usr/qt/3/lib/libqt-mt.so.3
#28 0xb75d5fa9 in QTimer::timeout () from /usr/qt/3/lib/libqt-mt.so.3
#29 0xb72a325e in QTimer::event () from /usr/qt/3/lib/libqt-mt.so.3
#30 0xb721ea1f in QApplication::internalNotify ()
from /usr/qt/3/lib/libqt-mt.so.3
#31 0xb721ebbc in QApplication::notify () from /usr/qt/3/lib/libqt-mt.so.3
#32 0xb7861fa0 in KApplication::notify (this=0xbfffebc0, receiver=0x84490d8, 
event=0xbfffe7c0)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/kdecore/kapplication.cpp:549
#33 0xb72121cc in QEventLoop::activateTimers ()
from /usr/qt/3/lib/libqt-mt.so.3
#34 0xb71cb341 in QEventLoop::processEvents () from /usr/qt/3/lib/libqt-mt.so.3
#35 0xb72350c0 in QEventLoop::enterLoop () from /usr/qt/3/lib/libqt-mt.so.3
#36 0xb7235016 in QEventLoop::exec () from /usr/qt/3/lib/libqt-mt.so.3
#37 0xb721dbcf in QApplication::exec () from /usr/qt/3/lib/libqt-mt.so.3
#38 0xb69c5e2f in kdemain (argc=2, argv=0x812ad10)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdebase/konqueror/konq_main.cc:206
#39 0x0804cd71 in launch (argc=2, _name=0x811c8cc "konqueror", 
args=0x811c8df "\001", cwd=0x0, envc=1, envs=0x811c8f0 "", 
reset_env=false, tty=0x0, avoid_loops=false, 
startup_id_str=0x811c8f4 "eriador;1109538401;97835;20707_TIME1436838664")
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/kinit/kinit.cpp:625
#40 0x0804e07c in handle_launcher_request (sock=11)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/kinit/kinit.cpp:1189
#41 0x0804e771 in handle_requests (waitForPid=0)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/kinit/kinit.cpp:1392
#42 0x0804fdba in main (argc=2, argv=0xbffff234, envp=0xbffff240)
at /home/dh/Documents/projects/cvs/kde/HEAD/kdelibs/kinit/kinit.cpp:1848

From mikmach at wp.pl  Mon Feb 28 11:59:01 2005
From: mikmach at wp.pl (Mikolaj Machowski)
Date: Mon, 28 Feb 2005 12:59:01 +0100
Subject: crash on 27Feb snapshot (CVS-HEAD)
Message-ID: <200502281259.01109.mikmach@wp.pl>


gcc3.4.3 (Mdk10.2beta)
qt3.3.3 

When closing tab:

Using host libthread_db library "/lib/i686/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread 16384 (LWP 15174)]
[KCrash handler]
#5  0x40e1fde8 in QGDict::unlink_ptr(void*, void*) ()
   from /usr/lib/qt3/lib/libqt-mt.so.3


m.
-- 
LaTeX + Vim = http://vim-latex.sourceforge.net/
Vim Universal Templates 
	http://www.vim.org/scripts/script.php?script_id=1078
CLEWN - http://clewn.sf.net





From faure at kde.org  Mon Feb 28 15:13:36 2005
From: faure at kde.org (David Faure)
Date: Mon, 28 Feb 2005 16:13:36 +0100
Subject: crash on 27Feb snapshot (CVS-HEAD)
In-Reply-To: <200502281259.01109.mikmach@wp.pl>
References: <200502281259.01109.mikmach@wp.pl>
Message-ID: <200502281613.37418.faure@kde.org>

On Monday 28 February 2005 12:59, Mikolaj Machowski wrote:
> 
> gcc3.4.3 (Mdk10.2beta)
> qt3.3.3 
> 
> When closing tab:
> 
> Using host libthread_db library "/lib/i686/libthread_db.so.1".
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 15174)]
> [KCrash handler]
> #5  0x40e1fde8 in QGDict::unlink_ptr(void*, void*) ()
>    from /usr/lib/qt3/lib/libqt-mt.so.3

That's not a valid backtrace, unfortunately. Try recompiling kdelibs with --enable-debug=full?

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From faure at kde.org  Mon Feb 28 16:01:06 2005
From: faure at kde.org (David Faure)
Date: Mon, 28 Feb 2005 17:01:06 +0100
Subject: Fwd: Congratulations, Konqueror is great !
Message-ID: <200502281701.06619.faure@kde.org>

Another fan mail :)

----------  Forwarded Message  ----------

Subject: Congratulations, Konqueror is great !
Date: Sunday 27 February 2005 13:07
From: Demigaucher <demigaucher at wanadoo.fr>
To: faure at kde.org

Hi,

As a new Linux user (Mandrake with KDE), I'm discovering the astonishing possibilities
of Konqueror. Congratulations, this is really a GREAT GREAT achievement ! 

The list of collaborators being too long, could please transmit this congratulations message
to all the persons involved in the writing of this magnificent tool ?

Thanks and best regards
Demigaucher, hardware engineer


Nouvel usager de Linux (Mandrake, avec KDE) je decouvre les stupéfiantes
possibilités de Konqueror. Félicitations, c'est vraiment une GRANDE, GRANDE réalisation.

La liste des collaborateurs étant trop longue, pouvez-vous transmettre ce message
de félicitations à toutes les personnes concernées par l'écriture de ce magnifique
outil ?

Merci et meilleures salutations
Demigaucher, ingénieur matériel



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

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From ott-list at thaigate.nii.ac.jp  Mon Feb 28 16:41:33 2005
From: ott-list at thaigate.nii.ac.jp (Otto Pattara)
Date: Tue, 1 Mar 2005 01:41:33 +0900
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
In-Reply-To: <200502251717.43150.germain@ebooksfrance.org>
References: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
	<200502251717.43150.germain@ebooksfrance.org>
Message-ID: <200503010141.33635.ott-list@thaigate.nii.ac.jp>

On 2005 February 26 Saturday 02:17, Germain Garand wrote:
> Le vendredi 25 Février 2005 05:38, Pattara Kiatisevi a écrit :
> > Hello,
> >
> > Regarding the Thai word break patch in KHTML, after testing

The backtrace seemed not very informative to me (maybe I need to 
enable debugging somehow (?) when compiling KHTML). 

I put some printf in libthai and found that sometimes the input 
parameter for array size (cache->allocated, in KHTML code) is 
incredibly large or the  cache->wbrpos array is 0x0. So I suspected 
there might be something funny about initialization of this "cache" 
structure. By looking at the code I don't see any mysterious point so 
I made a fix as in the patch.

I will fix the patch to load libthai only in case of viewing Thai web 
pages.

Cheers,
Pattara

> > longer there were some intermittent crashes.
>
> where does it crash and why? any backtrace?
> I've got the same concerns than Leo /wrt your patch.
>
> Greetings,
> Germain



From ismail at kde.org.tr  Mon Feb 28 16:53:02 2005
From: ismail at kde.org.tr (Ismail Donmez)
Date: Mon, 28 Feb 2005 18:53:02 +0200
Subject: crash on 27Feb snapshot (CVS-HEAD)
In-Reply-To: <200502281259.01109.mikmach@wp.pl>
References: <200502281259.01109.mikmach@wp.pl>
Message-ID: <200502281853.02372.ismail@kde.org.tr>

On Monday 28 February 2005 13:59, Mikolaj Machowski wrote:
> gcc3.4.3 (Mdk10.2beta)
> qt3.3.3
>
> When closing tab:
>
> Using host libthread_db library "/lib/i686/libthread_db.so.1".
> [Thread debugging using libthread_db enabled]
> [New Thread 16384 (LWP 15174)]
> [KCrash handler]
> #5  0x40e1fde8 in QGDict::unlink_ptr(void*, void*) ()
>    from /usr/lib/qt3/lib/libqt-mt.so.3
>
>
> m.

cvs up kdelibs/khtml . Dirk's latest revert to khtml_part.cpp fixed this one.

ismail



From germain at ebooksfrance.org  Mon Feb 28 17:24:24 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 28 Feb 2005 17:24:24 +0000
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
In-Reply-To: <200503010141.33635.ott-list@thaigate.nii.ac.jp>
References: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
	<200502251717.43150.germain@ebooksfrance.org>
	<200503010141.33635.ott-list@thaigate.nii.ac.jp>
Message-ID: <200502281724.24673.germain@ebooksfrance.org>

Le lundi 28 Février 2005 16:41, Otto Pattara a écrit :
> On 2005 February 26 Saturday 02:17, Germain Garand wrote:
> > Le vendredi 25 Février 2005 05:38, Pattara Kiatisevi a écrit :
> > > Hello,
> > >
> > > Regarding the Thai word break patch in KHTML, after testing
>
> The backtrace seemed not very informative to me (maybe I need to
> enable debugging somehow (?) when compiling KHTML).
>
> I put some printf in libthai and found that sometimes the input
> parameter for array size (cache->allocated, in KHTML code) is
> incredibly large or the  cache->wbrpos array is 0x0. So I suspected
> there might be something funny about initialization of this "cache"
> structure. By looking at the code I don't see any mysterious point so
> I made a fix as in the patch.

Oh I see...  there is no proper initialization for th_brk. 
So then the only needed change should be:
- static th_brk_def th_brk;
+ static th_brk_def th_brk = 0;

no?

Greetings,
Germain



From faure at kde.org  Mon Feb 28 17:20:58 2005
From: faure at kde.org (David Faure)
Date: Mon, 28 Feb 2005 18:20:58 +0100
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
In-Reply-To: <200502281724.24673.germain@ebooksfrance.org>
References: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
	<200503010141.33635.ott-list@thaigate.nii.ac.jp>
	<200502281724.24673.germain@ebooksfrance.org>
Message-ID: <200502281820.58499.faure@kde.org>

On Monday 28 February 2005 18:24, Germain Garand wrote:
> Le lundi 28 Février 2005 16:41, Otto Pattara a écrit :
> > On 2005 February 26 Saturday 02:17, Germain Garand wrote:
> > > Le vendredi 25 Février 2005 05:38, Pattara Kiatisevi a écrit :
> > > > Hello,
> > > >
> > > > Regarding the Thai word break patch in KHTML, after testing
> >
> > The backtrace seemed not very informative to me (maybe I need to
> > enable debugging somehow (?) when compiling KHTML).
> >
> > I put some printf in libthai and found that sometimes the input
> > parameter for array size (cache->allocated, in KHTML code) is
> > incredibly large or the  cache->wbrpos array is 0x0. So I suspected
> > there might be something funny about initialization of this "cache"
> > structure. By looking at the code I don't see any mysterious point so
> > I made a fix as in the patch.
> 
> Oh I see...  there is no proper initialization for th_brk. 
> So then the only needed change should be:
> - static th_brk_def th_brk;
> + static th_brk_def th_brk = 0;

AFAIK file-static data is initialized to 0 automatically.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).



From germain at ebooksfrance.org  Mon Feb 28 19:09:43 2005
From: germain at ebooksfrance.org (Germain Garand)
Date: Mon, 28 Feb 2005 19:09:43 +0000
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
In-Reply-To: <200502281820.58499.faure@kde.org>
References: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
	<200502281724.24673.germain@ebooksfrance.org>
	<200502281820.58499.faure@kde.org>
Message-ID: <200502281909.43805.germain@ebooksfrance.org>

Le lundi 28 Février 2005 17:20, David Faure a écrit :
> On Monday 28 February 2005 18:24, Germain Garand wrote:
> > Oh I see...  there is no proper initialization for th_brk.
> > So then the only needed change should be:
> > - static th_brk_def th_brk;
> > + static th_brk_def th_brk = 0;
>
> AFAIK file-static data is initialized to 0 automatically.

ah, I didn't know that... but initialization of statics would only happens 
once, when a library is dynamically loaded, no?

some times ago we had a bug in the arena allocator, where if the last part was 
unloaded and KHTMLFactory destroyed, static variables remain, so next time a 
KHTMLPart was created, statics were not reinitialized.

This would explain (what looks like) invalid reads on the cache structure...

    void cleanup_thaibreaks()
    {
        delete cache;
+        cache = 0;
    }

Germain



From faure at kde.org  Mon Feb 28 19:12:07 2005
From: faure at kde.org (David Faure)
Date: Mon, 28 Feb 2005 20:12:07 +0100
Subject: Patch: fix intermittent crash in KHTML Thai Word Break
In-Reply-To: <200502281909.43805.germain@ebooksfrance.org>
References: <200502251438.42974.ott-list@thaigate.nii.ac.jp>
	<200502281820.58499.faure@kde.org>
	<200502281909.43805.germain@ebooksfrance.org>
Message-ID: <200502282012.07929.faure@kde.org>

On Monday 28 February 2005 20:09, Germain Garand wrote:
> Le lundi 28 Février 2005 17:20, David Faure a écrit :
> > On Monday 28 February 2005 18:24, Germain Garand wrote:
> > > Oh I see...  there is no proper initialization for th_brk.
> > > So then the only needed change should be:
> > > - static th_brk_def th_brk;
> > > + static th_brk_def th_brk = 0;
> >
> > AFAIK file-static data is initialized to 0 automatically.
> 
> ah, I didn't know that... but initialization of statics would only happens 
> once, when a library is dynamically loaded, no?
Right.

> some times ago we had a bug in the arena allocator, where if the last part was 
> unloaded and KHTMLFactory destroyed, static variables remain, so next time a 
> KHTMLPart was created, statics were not reinitialized.
Yes so the initialization should be done in some ctor - not in the above line.

> This would explain (what looks like) invalid reads on the cache structure...
> 
>     void cleanup_thaibreaks()
>     {
>         delete cache;
> +        cache = 0;
>     }

That looks correct.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).