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

List:       quanta
Subject:    Re: [Quanta] wysiwyg
From:       Andrew <andrew () 1dtv ! com>
Date:       2008-02-18 22:44:37
Message-ID: 47BA0A55.3090803 () 1dtv ! com
[Download RAW message or body]

Eric Laffoon wrote:
> On Monday 18 February 2008 12:46:55 am Andrew wrote:
>   
>> Hi. Totally new to Quanta. Looking for a wysiwyg page editor to use on
>> linux. Tried Nvu / Komposer but not too happy about the code it
>> generates, and can't get on with Amaya at all. Quanta looks nice, but
>> when I insert an image it totally loses the plot! The page looks ok on
>> preview, but in vpl mode either the image does not show at all, or the
>> rest of the page after the image does not show. Is there something
>> simple I'm likely to be doing wrong?! I'm running ubuntu 7 with gnome.
>>
>>     
>
> First of all, the reason we set out to do VPL instead of WYSIWYG is because 
> the reality of web design is what you see is never what somebody else gets. 
> It's always different unless it's in fixed format CSS and they have the same 
> fonts, screen resolution, etc... Visual Page Layout started out with another 
> idea, that if you edit a paragraph that paragraph is edited and the rest of 
> the document is not munched and trashed like loading it in a word processor 
> that does HTML.
>
> Nvu launched after VPL saying it was first, until someone must have pointed 
> out the truth. They initially had virtually no DTD information, and later 
> decided to declare a fixed DTD, which last I looked they did a poor job 
> adhering to. Quanta's VPL adheres to your DTD as that is how it generated 
> tags, just like in text mode. Try split mode if you want to learn to edit and 
> see what it does.
>
> Anyway as many people note VPL is not really ready for production use, and 
> it's also not maintained currently. Here's why...
>
> 1) VPL is dependent on hooks in KTML. Initially it was coded building all this 
> without those hooks and it was a nightmare that could never accomplish 
> certain things. So we started over. This theoretical advantage tied VPL 
> closely to your version of kdelibs.
>
> 2) The KHTML developers also decided to scrap their first attempt. This is 
> insanely complex code. So we had to rework our code to a new API... again...
>
> 3) We had the Apple Webkit debacle where KHTML developers complained about how 
> they didn't expose their CVS and the bulk code they exposed was impossible to 
> integrate. Apple saw the problem and relented, but left us with a big 
> question. They had just what we needed to enable a great VPL mode in there, 
> but would those changed ever be integrated as they were so difficult to 
> extract we might as well start over.
>
> 4) KDE4 development moved to first port and then enhance code, and as we share 
> a development platform now with KDevelop we were not near ready to look at 
> this, and we have no maintainer for VPL because...
>
> 5) Developer burn out has eaten two VPL maintainers. One did VPL as a project 
> for his degree his last year of college. He still codes with our project, but 
> is too burned out on all the headaches of VPL to start back.
>
> It is not a matter of whether we want to support visual design done right. It 
> is a matter of how we proceed, do we count on certain things getting into 
> KHTML or not and how do we attract a developer. I'm resigned to this being 
> such a tedious and demanding project that it requires a sponsored developer. 
> I will NOT assign it to Andras and burn out our key developer for the whole 
> project. Ironically it would take 10-20 users offering monthly what they 
> would pay for shareware or 5-10 users offering yearly what they would pay for 
> commercial packages. Outside of a few key large sponsors that is more than 
> what we currently recieve for the whole project. I am entirely uncomfortable 
> sponsoring someone one month, oweing them the next and letting them go after 
> that and paying out of pocket while asking them to keep their calendar open 
> in case some users actually want this later.
>
> One thing to keep in mind here is that I have a track record of delivering 
> what I say I will... although we could conjecture what I said about VPL, I 
> don't recall saying it was going to be ready for production use yet, but as 
> you can see our failures there were not for lack of trying.  It is going to 
> take another effort. Sadly without a maintainer, and I don't have time or 
> funds to do it myself, Quanta4 will debut without VPL. I am hoping to begin 
> looking into this project in 6 months time as I am too busy and can't fund it 
> personally now. 
>
> I am moving ahead with other new design ideas including object templates, and 
> this is where a visual mode makes sense to me... I want to be able to take a 
> PHP include and see what it would look like in the page and edit text, CSS 
> and loops in visual mode. This is where visual design is usable to me and my 
> long term objective is to make a truly usuable visual design mode that can 
> handle not just simple HTML but DTDs and can process linked parse trees of 
> what goes to the server and the HTML it renders back. 
>
> We have no interest in copying what I think has been lame, but we want to 
> offer our users something original and productive. I just don't have time and 
> resources (funds to sponsor or volunteer team members) to do it all.
>
>
>   
Thanks for all the feedback, I wish you all the very best with it.
_______________________________________________
Quanta mailing list
Quanta@mail.kde.org
https://mail.kde.org/mailman/listinfo/quanta
[prev in list] [next in list] [prev in thread] [next in thread]