'Re: Some points'

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

List:       kde-kafka
Subject:    Re: Some points
From:       Jono Bacon <f9808590 () wlv ! ac ! uk>
Date:       2000-11-29 22:46:57
[Download RAW message or body]

On Wednesday 29 November 2000 15:01, you wrote:
> On Tuesday 28 November 2000 23:29, Jono Bacon wrote:
> > Hello all,
> >
> > I have just been chatting with Tronical in #kde, and he was saying that
> > we could use the KHTML events (not the KHTMLView) directly which would
> > remove the restriction of not being able to edit framesets with KHTMLView
> > (I am not exactly sure why, but he says that is the case).
> >
> > Looking through the docs for HTMLPart I can see the event methods which
> > are in khtml_event.h in the libs. they are:
> >
> > 	DrawContentsEvent()
> > 	MouseDoubleClickEvent()
> > 	MouseEvent()
> > 	MouseMoveEvent()
> > 	MousePressEvent()
> > 	MouseReleaseEvent()
> >
> > There is also some interesting methods such as DOM::Node  innerNode ()
> > const which gets the node that the mouse is over.
>
> i already do my DOM Tests using this events since i thought we will use it.
> DOM::Node also contains a method calls getRect() which returns the rect
> around the object, so you can draw a selection border quite simply.
>
> just give KafkaEditView a DOM:Node element which holds the selected Node.
>
> But i fear there will be some problems with text, since text is formated by
> it's parent nodes so we have to handle that a different way.

I see...so we are agreed on using the KHTMLPart event methods then. :-)

> > He was also saying that the KHTMLEditorView (equivilent of KafkaEditView
> > in the current code) was used for displaying the cursor if he remembered
> > correctly.
> >
> > This technique seems like it could work quite well as it would give us
> > the advantage over editing framsets, although how this is an advantage I
> > am not totally sure on. The plan before was the reimplement the
> > QScrollView methods that KHTMLView inherits to trap events...but this
> > could be done directly with KHTMLPart events.
> >
> > Anyone else have comments on these ideas?
> >
> > Also...somethingI felt I should mention...a lot of this KHTML stuff is
> > new to me, and I took over Kafka as it was not being maintained, and I
> > felt it was worthy of a maintainer (even ifI was not quite so experienced
> > as the previous maintainer). As a lot of this is new to me...it is taking
> > a little bit longer to code.
> >
> > To speed up the development of Kafka, and also to speed up the learning
> > of the new material for everyone, we need to attack these concepts that
> > are new as a group. I have been reading the old code to pick relevent
> > parts out and applying them where necceccery as it was a group desicion
> > to remove the old code. We now have a fresh codebase in which Kafka can
> > grow, but I am getting the impression that I am the only one working on
> > this. Now, I don't want to push people into working on Kafka, but I would
> > like to urge as many of you as possible to get involved and write some
> > code if you can. One developer writing code is not as productive as 3 or
> > 4 developers writing code, so I would like to urge as many of you to help
> > in these emryonic stages of Kafka as possible.
> >
> > I realise of course that not everyone can help as they have other
> > projects to deal with (such as Thomas with KOffice), and input from these
> > people is as important and valid as ever, so I don't wish to make people
> > think that if they don't code they cannot participate - all I am wanting
> > to do is to encourage as many of you to help write code as possible.
> > Let's make it happen. :-)
> >
> > 	Jono
>
> I am quite unexperienced working together with others, but should there be
> something like a rough draft of the software design (class structure, UML
> diagramms etc). Or is there something compareable i have missed?

Well I sent a draft of what needs to be done. The current classes are like 
this:

	KafkaApp - deals with app init stuff
	KafkaView - deals with the view
	KafkaEditPart - deals with the editor part that sits in the view (the view 
which is created using KafkaView)
	KafkaViewPart - the view of the editing part (inherits KHTMLView)

We currently have no KafkaDoc which needs to be implemented. ;-)

What we need to do is the implement the selection code into the KafkaEdit and 
KafkaView classes. It is those classes where the bulk of the processing will 
be done. Please feel free to ask any specfic questions on the list, or 
propose ideas. Do not feel held back at coding, and if this does not clarify 
things...I can provide you with mor einformation if you need it.

	Jono

-- 
Jono Bacon - [vmlinuz] - jono@kde.org
KDE/Qt Developer - Kafka Maintainer

_______________________________________________
Kde-kafka mailing list
Kde-kafka@master.kde.org
http://master.kde.org/mailman/listinfo/kde-kafka

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