[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:       Andrew Lowe <andrew.lowe () manildra ! com ! au>
Date:       2007-03-18 10:02:56
Message-ID: 45FD0E50.1020701 () manildra ! com ! au
[Download RAW message or body]

Andras Mantia wrote:

>Hi,
>
>On Friday 16 March 2007, Andrew Lowe wrote:
>  
>
>>Andras,
>>Things are starting to quieten down in my house (baby number 3 is now
>>9 weeks old and sleeping much better)...
>>    
>>
>
>I know the feeling, altough I can sleep quite well with a screaming 
>baby. ;)
>
>  
>
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 :-(

>>From what I understand KDevelop rewrite was causing code to be very
>>unstable and writing the Quanta plugins would have been pretty much
>>impossible due to a moving target?
>>    
>>
>
>Not impossible, but there was a time when things were so broken, that we 
>abandoned the porting and started to write a new parser instead.
>
>  
>
>>Has this changed - is KDevelop at 
>>a pretty stable state, or are they still making major changes?
>>    
>>
>
>They should be more stable now, but I cannot really comment as I didn't 
>follow the commits lately (13000 unread mails from kde-commits list...)
>  
>
It looks pretty stable now from the documentation... I got KDevelop to 
compile and run - with a few crashes (as expected), but otherwise ok...

>  
>
>>I guess I am saying I would like to help, but need some guidence as
>>to what you want me to do, and how to do it...
>>
>>I will look into what I can do on the CSS editor over the weekend and
>>let you know what I think I can do.  I take it the existing code all
>>lives at: kdewebdev/quanta/components/csseditor/ and you want it to
>>become a plugin for KDevelop?
>>    
>>
>
>Porting the CSS Editor is something that I think can be done relatively 
>independently from the rest of Quanta. Actually that part was 
>completely written by one developer, and I don't really know the code. 
>The only real connection to the Quanta "core" is 
>QuantaApp::slotInsertCSS() (in the old code, of course), which finds 
>what part of the document should be passed to the CSS editor.
>The idea would be to make a KDevelop plugin which has an interface where 
>you can invoke the editor with a text as an argument. Altough written 
>for KDevelop 3, the DESIGN file from kdewebdev/quanta (from turnk 
>version) desribes how this plugin based development is done, and for 
>example the tagdialogs plugin (and the lib/tagdialogsif.* files) can 
>give you an idea how communication between different plugins can be 
>implemented. Has the "core" of Quanta itself is a plugin, such 
>communication will be needed.
>
>And yes, the css editor lies in the part you mentioned. As it was never 
>ported to the plugin infrastructure, it means that it must be also 
>converted to use Qt and KDE4 classes.
>
>Andras
>
>  
>
I have had a good look at kdevelop plugins, they look like a bit of fun 
to implement...

 From what I understand:
    The css editor would be independent of the quanta core plugin.
    The css editor would live in quanta/plugins/
    Quanta currently calls the css editor from slotInsertCSS() telling 
it if it is pure css document, or styleblock or xmltag
       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).

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?

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

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...

Thanks..

-- 
Andrew Lowe
    System Administrator & Programmer
        Information Technology
            Manildra Group

Email:   andrew.lowe@manildra.com.au
Phone:   02 4423 8270
Mobile:  04 1323 8270
Fax:     02 4421 7760 

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

Configure | About | News | Add a list | Sponsored by KoreLogic