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

List:       kde-kafka
Subject:    Re: Proposal concerning kafa structure
From:       Holger Freyther <freyther () kde ! org>
Date:       2001-12-10 13:03:49
[Download RAW message or body]


Am Sonntag, 9. Dezember 2001 18:01 schrieb Joseph Wenninger:
> Hi
Hi jowenn, all
> Just a view thoughts concerning the kafka structure
we talked about it on #kafka. Just a small site note if you han out at 
irc.kde.org join #kafka as well me or some one else will be there for sure.
>
>
> KafkaPart:	This is the only real part, it allows plugins for tag editting
> and should be useable in the kafka application and in other applications
> too (eg in kmail) == WYSIWYG part
yes agreed
>
> KafkaDocumentManager	This handles all opened documents, which editors
> (plugins, .... ) can work with and synchronizes access to those documents.
> plugin enabled
I think it should be plugin of KafkaPart

> (The Documents itself are not qdomdocuments, but khtmlpart documents
> (pecause of parsing not XHTML docs)
so the same as they alywas were

> KafkaViewManager	This one handles all views (wysiwyg part, editors, ......)
> and displays them. This one is a plugin itself and can be SDI,MDI, ......
> in different ways.
I think  a plugin as well. KafkaPart should provide the informations for this.
> KafkaApplication/KafkaShell this one is the parent of all above things and
> encapsulates the application's configuration
KafkaApp yes but how will KafkaShell be different?

I had some thoughts as well. No code is written and there's no really api on 
paper or such thing. Looking at the current source I think this should be 
thedesign to go. You can find it in kdenonbeta/kafka/design.dia and 
design.png.

It think KafkaPart should be a framework which does really little but provide 
much api. So kafka should know which documents are open which domtree is 
associated with which file and the current view. It should have a list of all 
dom trees and one domtree called common. It should have this TabView Sidebar 
where plugins can add theirselves. It should provide a common interface for 
plugins. I thought of a projectmanagement, and mdi/sdi manager. Kafka should 
really provide these possobilities without implementing those. The user 
should be able to choose which plugins he want to load. 
Then there will be KafkaHTMLPart and KafkaEDITORPart which provides plugin 
interfaces too. The plugins of KafkaPart are acting on the current focused 
view.
There should be also a MixedModePart having half wysiwyg like preview and 
editing but showing also the tags.

Comments for that approach. It's really a lot like the way it is today.
How do we want to get there?
1. Lets get KafkaPart working. It should provide the api hooks and the 
datastore possibilities. Get the current stuff working and a simple view 
manager. Get the sidebar going
2. get KafkaHTMLPart going with Plugins. jowenn could we coordinate with your 
propsdialog?
3. get a good SDI/mdi workspace working 
4. DocumentManager
5. more KafkaHTMLPlugins
6. ProjetMangement
7. Plain-HTML-Editor with Tag editor
8. Mixed-Mode
9-250 plugins

regards Holger
>
> Kind regards
> Joseph Wenninger
> _______________________________________________
> kde-kafka mailing list
> kde-kafka@mail.kde.org
> http://mail.kde.org/mailman/listinfo/kde-kafka

_______________________________________________
kde-kafka mailing list
kde-kafka@mail.kde.org
http://mail.kde.org/mailman/listinfo/kde-kafka
[prev in list] [next in list] [prev in thread] [next in thread]