[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kfm-devel
Subject:    Re: bug in khtmlw
From:       Stephan Kulow <coolo () itm ! mu-luebeck ! de>
Date:       1997-07-30 15:25:18
[Download RAW message or body]

weis@stud.uni-frankfurt.de wrote:
> 
> Hi,
> 
> On Wed, 30 Jul 1997, Stephan Kulow wrote:
> 
> > Martin Jones wrote:
> > >
> > > weis@stud.uni-frankfurt.de wrote:
> > > >
> > > > This is my fault. Sorry :-)
> > > >
> > >
> > > There is nothing wrong with if ( !url.isNull() && url[0] != 0 )
> > > but if ( !url.isEmpty() ) is shorter and does the same thing :-)
> > >
> > Are you sure, that it works? You must know, since days now, I run kfm
> > only in a gdb session and a SIGSEV stoped kfm exactly in this line.
> > Since the url object is defined, it could only be the reference to the
> > data, that is missing. I don't want to blame somebody ;), but I think,
> > this should be discussed, so we can learn for the next time!
> >
> > BTW: I've tried yesterday to add working references to kfm. I think, it
> > works now, but I needed hours for this, since the code of kfm is not
> > very
> > well documented and the khtmlw is also not very understandable for me.
> > kdehelp is using KHTMLWidget (the README recommend this), but kfm uses
> > KHTMLView, because (I found this in CHANGES), the view cares about
> > frames.
> > So I think, my anchor patch works only for single frame documents, since
> > I
> > added only a
> > bool KHTMLView::gotoAnchor(const char* anchor)
> > {
> >    return view->gotoAnchor(anchor);
> > }
> > in KHTMLView. This works, but I couldn't find out, which frame this view
> > (a KHTMLWidget) is. So I really expect troubles with frames, but I
> > hadn't
> > the time to find this out yesterday.
> >
> > I will try some stuff today, but if you have tips for me, I would like
> > to
> > hear some.
> 
> I dont see where to get trouble. References can not refere to other
> frames. So if a KHTMLView handles its references in a nice manner,
> you are almost done. Almost because the HRef object may have
> a target identifier. In this case you have to use a find
> function ( dont remember the correct name ), to get the
> matching KHTMLView widget ( matching the target ). Then you have to
> tell this KHTMLWidget what to do.
> 
I've tried frames today for the first time. This is very buggy, as far
as I've experienced. 
First I've tried a homepage of the guy sitting next to me and found,
that
relative links do not work. He has something like this:

<frameset rows="20%,80%">
<frame src="head.htm" scrolling=yes>
<frameset cols="25%,75%">
<frame src="link.htm" scrolling=yes>
<frame src="body.htm" scrolling=yes name="alles">
</frameset>
</frameset>

the file is frame.htm. It works, if you look at them via file:/, but if
you use http:/, it will end in a url, like /~jaehn/frame.htm/head.htm
and a Forbidden message by the server.

The other thing I've noticed with frames, was that a frame gets black
after loading. In the above example, I replaced body.htm with 
file:/home/kulow/prod/qt-1.2/html/qmenubar.html and this page is loaded,
but is painted black after this. If I scroll after that, I get the begin
and the end again white, but the middle stays black. I don't know, what
happens here. If I copy the qmenubar.html file to qmenu.html in my
current
directory and replace the file: URL with "qmenu.html", this doesn't
happen!

And to repeat myself: the file selecting should be disabled in HTML
modus. 
It annoys me that much :)

BTW: I have some seg faults in HTMLImage from time to time, but I
couldn't
resolve it until now.

HTH, Stephan

-- 
Stephan Kulow (coolo@kde.org)
Student der Informatik (NF: MedizinInformatik)
Medizinische Uni zu Luebeck

[prev in list] [next in list] [prev in thread] [next in thread]