Here's the details. Andras and I were discussing it over the last few weeks. Around a week ago I got an email from Nicolas Deschildre in France that he was working on the old Kafka part and was thinking the whole thing was going to be way too much work. He wanted to know if we were interested in making it a plugin for quanta. Not long before this Adam Treat had expressed interest in helping on a WYSIWYG part for Quanta. We all opened discussion on the developer list. Our conclusion so far is that it can be done in a way that meets our standards.

Our approach to this will be entirely different in many ways to what has been done in the past. Even in WYSIWYG mode we will still be entering text into the editor with an editing rule set for handling various things like indention or selecting the right W3C recommended tag for for an element, etc... This will all be managed by our parser and tied to underlying DTDs and will probably incorporate additional features in the structure tree. Additional ui elements besides our standard dialogs are under discussion but we will likely be running a consistent interface along with the additional power that Kommander will add.

WYSIWYG mode editing views are likely to be quite configurable allowing for additional information to be conveyed to the edit window and to be able to easily select and edit elements as well as descend quickly to the editor in the current cursor location or click to edit a PHP or Javascript element. We will work to make it easy to preview dynamic pages... this can already be done with projects but we want to be sure people understand that a certain degree of PHP WYSIWYG HTML editing is at least in the discussion phase.

Addtional exploration is being done of conversion and rendering of XML and SGML elements like visual DocBook editing and more. These elements may lag the initial release. Clearly what we are aiming for is another mode of editing that will be true to the underlying markup and productive in ways other tools have not managed to this date.

DON'T ASK WHEN!

What I can't answer now, along with a lot of specifics, is when this might be ready, or for that matter if it might be ready enough to release a partial version with one release and a feature complete one later. Can this show up with KDE 3.2? I don't know. Would we like it to? If we can get it ready, of course. Will we see a feature complete version in KDE 3.3? Almost certainly.

Remember, now that we are part of the official KDE packages we cannot release any new strings in the ui that need to be translated unless the ui is complete in the freeze time frame. Our next window is KDE 3.2. Outside of this you can run CVS or we could release a preview. It will also be available of course in the betas of 3.2. If you would like to preview it in quanta you will have wait. It is being brought to a base level of readiness in the kdenonbeta CVS module and then will be moved to Quanta's CVS for integration and further development. We'll let people know when it is there.

...

The reason is that the Kafka code will be put into Quanta CVS any day now as it's reaching a point where we can begin the interaction.

...

I have long felt that if KDE and Linux in general were left with simple HTML editors the required hacking and kluging of a decent tool for the modern age would prove to be a relative nightmare. Worse it would condemn professional developers to work under Windows or look at IBM tools and be limited to Java applications and such. A lot can be done with basic markup and PHP. I decided I was not going to be the guy who presided over the project who made web development on KDE a joke!

When Andras came on we discussed the reality of how quickly things change and how long programs take to develop. We were of one mind that Quanta needed to be divorced from HTML and become a DTD driven tool. We also wanted to manage a number of things through our parser. In fact I had driven the parser based design that Dmitry wrote originally. Our requirements have grown. Andras spent substantial time making this fast and flexible so it adapts to DTDs.

This is the foundation, or at least part of it. We needed to add templates, custom dialog engines and more so that when we launched WYSIWYG it was completely unlike any previous tool. Other tools try to make decisions for you and you have very little to say about what they are actually doing. They also have very little respect for W3C standards, hack up your layout and rewrite everything and try to shield you from any real knowledge of what you're doing. Quanta has been in preperation for the last several years to do just the opposite.

So when Nicolas approached me about the Kafka part he was looking at the scale of what he expected it would take to develop a full tool. I first explained to him exactly what we wanted to accomplish... because it is important to me that he was on board with something very special and not just a visual tool. When we began to discuss it Nicolas was even more impressed because all the things he thought he would have to do he didn't. The Kafka part will essentially manage a visual editing mode that will feed back to our parser and be fed into our editor via rule sets and respecting the DTD. The only thing beyond editing is that it will pass back and forth special information on nodes and node pointers. Everything else is done by Quanta.

There is no doubt this will make web page development easy for those newbies who wish to stick with the defaults, but it will also extend power to professional level developers that they have not had in the past. It will also make for a customizable tool for content entry. You could set up a custom layout and put it on a Knoppix disk that you could give to a client who could edit content visually that is ready to plug in to your web application. In fact as we grow this it will be able to work with much more than HTML. Our objective is to be able to create a conversion layer to support any DTD including XML and DocBook. Of course all of this is in early stages of speculating how it can best be done.

Obviously developers beyond Nicolas, Adam, Marc and Andras on this will be very welcome. If KDE 3.2 ends up being delayed from mid to late year as it appears it will we may be able to release a satisfactory version. Also we will need to talk with the khtml developers about interface issues as currently we are depending on internal interfaces. Dirk Mueller has been some help already.

Starting from today Quanta has a new feature: abbreviations (or code filler feature). :-) It is a commonly found feature in other IDE's, it's there in Gideon, in HomeSite (as I heared, as I never saw HomeSite), it was in Borland IDE's, and now it is in Quanta. You can create abbreviation templates, like "js", and use CTRL+J to expand it to

<script language="JavaScript">
</script>

and the cursor will be in the place where there is the first |. The only difference between Quanta and the other editors is that abbreviations are specific for a DTD. In this case you can have the same template, but the result will be different, depending on which dtd you are working on. As an example, you can define "b" to be "<b></b>" in HTML and "bool" in PHP. Inside <? ?> it will expand to bool, outside them to <b></b>. They can be edited via a GUI in Settings->Configure Quanta->Abbreviations.

Right now there are no default abbreviations file for the DTD's, but you are free to send the created ones. They are located in $KDEHOME/share/apps/quanta/tags/DTD_NAME/abbreviations.

Of course, you need Quanta CVS HEAD to use this feature. ;-) I hope you will enjoy it.