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

List:       quanta-devel
Subject:    Re: [quanta-devel] KDE 4.0 release plan
From:       Andras Mantia <amantia () kde ! org>
Date:       2007-03-19 19:28:14
Message-ID: 200703192128.19969.amantia () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 18 March 2007, Andrew Lowe wrote:
> I sleep while the baby is screaming too, as my wife has to feed her,
> it is the older two (2 & 3years) that wake me up - one has been sick
> lately and wants to get up in the night :-(

I hope they will get better soon.

> It looks pretty stable now from the documentation... I got KDevelop
> to compile and run - with a few crashes (as expected), but otherwise
> ok...

Yeah, that is "normal". Also you probably noticed Alexander's mail. In 
any case, you should subscribe to kdevelop-devel 
(https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel) and 
ask KDevelop platform related questions there.

> I have had a good look at kdevelop plugins, they look like a bit of
> fun to implement...

I hope you understand fun in a good sense.

>  From what I understand:
>     The css editor would be independent of the quanta core plugin.
Right.

>     The css editor would live in quanta/plugins/
Yes.

>     Quanta currently calls the css editor from slotInsertCSS()
> telling it if it is pure css document, or styleblock or xmltag

Yes.

>        pure css document - calls CSSSelector class - pass the whole
> document and replace the whole document with the string returned by
> generateFormattedStyleSelection - the formated css.
>        styleblock - calls CSSSelector class - pass just the
> styleblock, replacing the whole styleblock with the string returned
> by
> generateFormattedStyleSelection - the formated css
>        xmltag - calls CSSEditor class - pass the value of the style
> attribute to csseditor (if the attribute exists) and replace with
> string returned by generateProperties -  non formatted css
>     CSSSelector uses CSSEditor to edit each element (selector).

It should be like you described.

> A big issue I see is that CSSSelector uses it's own DTD data (from
> the quanta/components/csseditor/data directory) rather then the dtep
> data. Would it be better to get the DTD data from quanta's dtep data
> so that elements can be updated in one place?
It would be better if it could reuse the quanta dtep. If there is a need 
to extended them (like information is not available in the current 
DTEP), we can do it.
As I told, the CSS Editor was developed completely by one author, partly 
independent of Quanta. Now it makes sense to integrate them more in the 
sense of coding style[*], resource usage (dtep, like you pointed out).

[*] I don't want to force a coding style except for parts that can be 
used across plugins (the interfaces), but the style should be 
consistent across the files of a plugin and would be nice to have all 
methods documented using doxygen docs. We tried to do it when we ported 
all code to the new place.

> I have tried compiling Kde Web Dev from trunk, but it does not
> compile... but I guess that is expected at the moment...

It doesn't compile, because KDevelop changed a lot. You can help with 
this part as well (to make it compile), if you want. I finally have a 
recent KDE4 version compiled (with KDevelop), so I can also look at 
this, but if you're faster, I don't mind. ;-)

> I have not had a real good look at the underlying code for the CSS
> editor/selector (just a quick browse), but it looks like a good
> project. I will make a start and see how I go...

Great!

Andras


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

[Attachment #5 (application/pgp-signature)]

_______________________________________________
quanta-devel mailing list
quanta-devel@kde.org
https://mail.kde.org/mailman/listinfo/quanta-devel


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