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

List:       kde-kafka
Subject:    IRC results
From:       Emmanuel Touzery <manu () minds ! cs ! may ! ie>
Date:       2000-11-01 21:20:17
[Download RAW message or body]

Hi!

	Here is the IRC chat, for the absents ;o)

*** zander has joined #kafka
<GW> maybe we should discuss without jono
<zander> sure
<zander> some1 wrote an agenda ;)
<GW> we need a timetable for development
<zander> First think I wanted to say is that we need better copyright
statements in the source files. A copyright owned by "the Kafka team" is
not a legal copyright (since there is no person or copany named as such)
<GW> yeah
<GW> ok
<zander> are we alone?
<manu> well i'm there
<manu> just listening for now
<GW> we will completely rewrite the code
<zander> ok. I think we sould just copy the statements from the KDE
sources. Looks good to me.
<zander> GW: why will we rewrite the code?
<GW> hmm jono and schimmi had a dicsussion and they decided to build new
code...
<zander> I think that desicion was based on fear of copyright, which I
countered with (among a irc chat) an email. After which they agreed that
using the old stuff was fine. Let me find an url for you.
<GW> hmm ok that is possible
<GW> the next thing we have to do is work management... who works on which
code ?
<zander> http://lists.kde.org/?l=kde-kafka&m=97285150625334&w=2 (and
following)
<GW> what should we create first to get a good code basic for building all
things on
<zander> Because this is still a OSS project, the question should be; who
wants to work on what code ;)
<zander> Makes the question, what needs to be worked on. Answer; read the
emails schimmy sent.
<GW> ;) ok
<zander> http://lists.kde.org/?l=kde-kafka&m=97281022601171&w=2
<zander> and http://lists.kde.org/?l=kde-kafka&m=97283435730519&w=2
<zander> agreed ?
<GW> hmm so what is to do next ?
<zander> CODE
<GW> I dont know what I should code
<manu> There's something that's bothering me about the design
<manu> what should we do about stylesheets?
<manu> because there's a way of changing the look of a whole set of files
thru them
<manu> do you want do let it go now and do a plugin later on or?
<GW> I think these things should come later because first we need a basic
structure we can work with
<manu> hmm i guess we can do HTML generation later on (now that i look
it's only T6 on the post)
<GW> T2: experimental gui
<GW> - mainwindow with widgets similar to the "old" kafka
<GW> T3: framework
<GW> - basic implementation of KafkaDoc, KafkaView, KafkaMainWindow
<GW> T4: experimental khtmledit implementation
<GW> - testing framework
<GW> - getting used to khtml internals
<GW> - just view current document until now
<GW> T5: kwrite view
<GW> - testing framework
<GW> T6: DOM/HTML handling
<GW> - creation of HTML from the DOM
<GW> - enhancing khtml parser/tokenizer to be lossless
<GW> T7: prepare for editing
<GW> - create KafkaAction classes
<GW> - try out manipulating the DOM
<GW> - try out alternative for KafkaDOMAction implementations
<GW> T8: module/plugin architecture
<GW> T9: stabilize framework
<manu> yeah i saw that
<GW> This is schimmis timetable
<manu> (after my comment :o( )
<GW> How can we split the work ?
<zander> about stylesheers, they have DOM elements, meaning that they will
be used perfectly. Creating/changing them in an external file means
opening that external file. Simple. Maybe provide a plugin to do that
_even_ better
<manu> yeah i mean something graphical
<manu> but you're right we have the time for this
<GW> We include all khtml libs in our project and change them to our
needs, right ?
<manu> i'd like to provide a new function in khtml that would be able to
access khtml's private stuff
<manu> and just do what we want
<manu> but what i say is worthless since i haven't looked at the code yet
:o(
<GW> HeHe I dont know much of the code too
<manu> what we do not want: code duplication
<manu> what the khtml people do not want: making too much stuff public
<GW> manu: some things are impossible with using the libs when they have
no extensions for kafka
<manu> the answer: something new in khtml (just creation of the DOM tree
with the things we want to keep)
<manu> no?
<GW> manu: we take the libs change them and include them in kafka
<manu> GW: i know, that's why i say we should first add smthing to khtml
<manu> that's code duplication don't you think so?
<GW> Then we dont need complicated function calls to the dom 
<GW> It would be more easier
<manu> i don't think that khtml providing just a function more for
generating a more detailled dom tree is bad
<manu> ??
<manu> we'll work on the dom right?
<zander> just, back. GW. We should avoid cloning KHtml stuff at all
times!!!
<manu> i agree
<zander> so we dont take the libs and change them.
<GW> argh but the implemenation between khtml and kafka isnt very clean
and fast
<GW> There are a lot of problems when we work around with khtml hacks
<zander> And in 5 months you can start coding all over because khtml will
have all these neat fearures kafka won;t have.
<manu> i don't get the pb here: we use the DOM tree generated by khml
right? we don't like the DOM tree khtml gives us... MANY PEOPLE would
maybe like having another one. let's add it in khtml
<GW> There are other problems ... not only the dom tree
<GW> A) loading a html page into the editor, changing it, writing it back
into 
<GW> html must to be absolutely lossless. This means that a small change
like 
<GW> correcting a typo without changing the structure may only result in a
small 
<GW> change in the html file. All formatting, comments and so on has to be 
<GW> preserved.
<GW> B) editing must be interactive and intiutive. This means that
drag'n'drop, 
<GW> wysiwyg editing of positions and dimension (i.e. of images, tables,
divs) is 
<GW> possible
<manu> that's what i'm talking about (point A)
<GW> This is from the Open Issues post from schimmi
<manu> now i realize i have a very important question: ARE WE TO USE KHTML
FOR RENDERING???
<GW> B is a big problem ... A isnt so important because that we could
solve
<GW> manu: yes
<GW> thats the problem. object like tables, images, divs, iframe and so on
must be 
<GW> markable/selectable. A selection rectangle has to be drawn.
<manu> i'm not sure we should use khtml for rendering
<manu> it sounds like a big code duplication not to do so
<manu> but is it even possible?
<GW> hmm the current code is a big hack into khtml... all things are calls
to khtml code
<manu> for me the bulk of khtml is in the parsing, not the rendering [once
again I NEVER LOOKED AT THE CODE]
<zander> SOrry I am not following this very closely, some call came in.
Let me reassure you that we have the full cooporation of the khtml people.
For about 8 months there are hooks living in khtml special for us. It will
be possible..
<manu> is the rendering so complex?
<schimmi> manu: it is
<manu> for me the difficulty is in the parsing (?)
<GW> zander: some things arent possible or are too slow 
<zander> Hi! schimmi
<zander> GW: such as.
<schimmi> hi thomas
<manu> hi
<schimmi> hi
<GW> manu: parsing does khtml for us
<manu> yes. but it throws things to /dev/null
<manu> that's something
<manu> and then we have to take care about rendering
<manu> maybe we should focus on one of these things and then the second
no?
<GW> zander: read the open issues mail from schimmi
<manu> or are these things problems only for me [and then just ignore and
proceed, i'll catch you later on]?
<GW> manu: of course not
<manu> so let's focus on the things that khtml loses for us (comments,
scripts, ...) to start and then we'll go on ok??
<zander> ok.
*** schimmi has quit IRC (Ping timeout for
schimmi[newton.heim6.tu-clausthal.de])
<zander> I think I gave a good solution there in an email some time ago.
<GW> ok then we have to write the tokenizer
<zander> We add a plugin system to khtml.
<manu> modifying khtml then?
<zander> Then we add a plugin like 'space' to the html tokenizer.
<manu> sounds good to me
<zander> etc.
<manu> just let's not screw their job:
<zander> manu: yes that changes khtml, but we do that in the acutal khtml
sources, with the cooporation of the khtml people
<manu> should be an additional fuction that uses their code
<manu> we don't want to slow down khtml
<manu> zander: you and I want the same thing i'm ok
<GW> hmm how does this plugin system work ?
<zander> That will not be a problem.
<manu> zander: I sign; maybe i was not clear but that's what i want
<GW> you include the system in khtml and add some plugins for kafka... how
can the plugins use the khtml code and how do they work together with
kafka
<manu> we provide a fuction in khtml that create DOM nodes with the
correct discriminer. Then kafka loads the corresponding plugin
<manu> [discriminer: type of node]
<manu> the original post from zander is at
http://lists.kde.org/?l=kde-kafka&m=97258464312220&w=2
<GW> and the plugin does what ? parsing the code ?
*** schimmi has joined #kafka
<manu> the plugin allows you to type Javascript code with a cool
interface, say
<manu> things like that
<zander> Allow me.
<zander> KHTML uses a parser. This parser first creates tokens from the
linear list of text of a html file.
<zander> A we extend the tokenizer to recognice some extra tokens and
therefor force those extra tokens to become part of the DOM.
<zander> To implement this the khtml code issues a class, which I will
name 
  'plugin-base' for this example.
<zander> Kafka (using the headers and the libraries) will derive from this
class implementing things like a method that
<zander> selects on which string the token reacts. So ' ' will be used for
a cleartext token, '<?php' for ...
<zander> These extra classes we write will be registered in the KHtml code
that is used while Kafka is running, only our application will register
that, so no slowdown to Konqueror (for example)
<zander> Did I forget anything?
<GW> hmm ok that sounds good
<manu> sounds ok to me.
<zander> This way we keep forwards compatible to khtml, which means that
extra features in khtml will become extra featurs in kafka.
<GW> who is able to write that ?
* zander runs
<GW> hmm
<manu> i'm not operational until some time.. i need to parse a lot of code
:o(
<GW> hmm is there a DOM and khtml documentation
<GW> or should we ask a khtml developer if he could write some code for us
to bring a plugin system on
<manu> DOM: see w3.org
<manu> KHTML: there is one online but incomplete AFAIK
<manu> you can generate it thru kdoc though i never did that myself
<zander> I think this solution will have to be typed and submitted to Lars
which will guide the programmer in the right direction. Other help can
come from Kafka members AND kde-devel mailing lists. It is not that anyone
trying will HAVE to do this.
<zander> I think it is something that will take some time, yes, but that
person 
  will have the best change to guide the further direction Kafka will
make. Simply because he knows a lot about the code structures.
<GW> whats about the drag & drop interaction things...
<manu> if nobody wants it, i'll take it but i'm afraid of the time i may
take to achieve it :o(((
<manu> GW: let's do one thing at a time no?
<zander> GW: thats not even on the todo list yet ;)
<GW> I look into the future
<manu> yeah but the present already seems messy to me ;o)
<zander> manu: Great. Please just make a design and submit it if you feel
you need feedback. I don't have the time to code, but I certainly will try
my best to help this work!
<GW> I think we need direct contact with the kthml developers
<manu> zander: i definitely will need feedback. I'll look at the code
tomorrow (I hope), and i'll let you know ASAP if i discover i'm not up to
this
<manu> GW: definitely, since we are tampering with their code ;o)
<zander> No.
<manu> well we don't want them to write code for us
<GW> manu: lets submit to the khtml mailinglist
<manu> but they want to know what we do with their code i guess
<manu> GW: let's wait a little bit
<zander> First discuss thing with Lars, he is German. Schimmy did that
allready in large part, so discuss that with him aswell.
*** zander has quit IRC (cheers!)
<manu> hum..
<manu> GW: are you ok not to submit to khtml mailing-list YET?
<GW> manu: ok
<manu> sounds right to me!
<manu> shall we go forward to the GUI thing?
<GW> yes
<manu> ok
<manu> just an idea i just had
<manu> may be ridiculous
<manu> if we add x,y to the DOM elements as attributes
<manu> but say the khtml guys are not going to add that to theirs
<manu> just for us
<manu> the rendering should be ok no?
<manu> because i'm afraid using their code for the rendering will get the
graphics code too complicated
*** stephan has joined #kafka
<stephan> hi, anyone here?
<manu> on the other hand maybe doing the rendering all by ourselves is bad
<manu> hi
<stephan> ergebnis des kafka treffens?
<manu> i'm not german
<stephan> sorry....
<manu> but there are some germans out there
<stephan> what's the kafka meeting result?
<manu> but since a few minutes i have the feeling i'm alone
<manu> well last time i checked it was not supposed to be over
<manu> but...
<manu> ok
<manu> we took the zander idea to guarantee that the code will be written
back unchanged
<manu> and to assign special nodes to a particular plugin
<manu> i'm supposed to take care of this (hum)
<stephan> for PHP tags and so on?
<manu> yup
<manu> the GUI issues have not been discutted yet
<stephan> ok, so this middle layer will be left out...
<manu> sounds like it will be done later on
<manu> yeah
<manu> kafka should only work on the DOM generated by khtml
<manu> whatever it is
<manu> so let's enhance KHTML
<stephan> ok, good
<manu> that was the point
<manu> i'm afraid about the GUI issues
<manu> but it's true that it's not the priority right now
<manu> ah, BTW: jono was not there
<stephan> are there enough developers?
<manu> so maybe all of this is not completely official
<manu> ???
<stephan> if schimmi and zander were there it will do, or not?
<manu> i think i should post the whole discussion on the mailing-list
<manu> i'll do it
<stephan> yes would be nice..since i haven't been a home since last friday
<manu> ok
*** [vmlinuz]AWAY has joined #kafka
<[vmlinuz]AWAY> lo all
<[vmlinuz]AWAY> sorry I could not make the 7pm meeting...I had a bit of a
situation with work over here :-(


Well it's not over but that's the first part

--
truth is like a blanket that lets your feet cold.
        --from Dead poets society

_______________________________________________
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]