The Quanta Plus development team is currently churning out more code than at any time in its history. So to keep you in the loop, theQuanta Plus site has been revamped, we've put up some new screenshots and implemented new site
features such as a publicly accessibledeveloper todo list.
So what's new with Quanta? Well, we've released 3.0 PR2, so you're encouraged to check it out for yourself! You'll find auto-completion for HTML and tag attributes, PHP
built-in function auto-completion, a revised document structure tree that recurses
PHP structures and embedded HTML, and more. One exciting bit of work in
progress is the ability to set different DTDs as well as offer tagging functionality
in the form of pseudo DTDs to script languages. There are other fixes and enhancements and
more on the way. We're also appealing to the community to help us flesh out the
templates as well as other tagging and scripting languages. You only need to be a web
developer to help here. Check out thefull story (page2, page3, page4, page5) in ourNews and Articles
section. Exciting things are happening.

Hi all. If anyone experiences a problem starting Quanta after the install that starts with a message saying "A toolbar with the same name already exists. Please rename the loaded toolbar." and ends with a crash a fix is on the way. This is caused because you have on old quantaui.rc which contains the standard toolbars. If you are adventurous you can go edit them out (or possibly delete and reinstall) or you can wait probably less than 8-12 hours for a patch and a new PR2A release to be posted. In addition to the fix which is in CVS we are looking to apply several other fixes which speed Quanta up, reduce the huge number of files for PHP function auto-completion and fix the sort order in the trees without slowing it down. We thought we would just get everything at once.

Our 3.0 final may be delayed by a week or so to be sure we bang on it a little more. ;-)

I wanted to thank our developers and especially Andras Mantia and Robert Nickel for their extra efforts helping me get this release out the door. Also thanks all those of you who have sent us appreciative emails (not that I need more email ;-)) and espcially those who have contributed code and financial donations. I'm not only very proud of our team and the program but I think we have some very classy users too. You guys rock!

Thanks Eric, and thanks for every users/supporter of us. We constantly try to improve and get a quality software out. This is why it is necessary a new release so soon. We don't want to disappoint You, and to driving you mad with some crazy bugs. ;-)

That is rather annoying, but almost to be expected with a lot of apps today. The thing that keeps me from using Quanta as opposed to Bluefish is the lack of as many xhtml options as the latter provides. It's just so much easier to set things up right in Bluefish's html preferences pane.

> The thing that keeps me from using Quanta as opposed to Bluefish is the lack of as many xhtml options as the latter provides.

You know I have to admit I haven't looked at Bluefish since the days of Quanta 1.0. So I don't even know if it has a document structure tree, loadable toolbars, programmable actions, templates, loadable DTDs, auto-completion, integrated script processing with any language that runs in the shell, advanced project options of any of the other things I depend on Quanta for. I know it doesn't have DCOP, kio, khtml, KDE's great file dialogs and a lot more. In a few weeks we will have a bunch more things like Active DTD parsing for auto-complete, code completion for local PHP classes and functions, and full DTD switching which removes vestiges of HTML for XML docs not to mention a very cool scriptable dialog builder called kommander...

Effectively for 3.0 adding XHTML support begins with opening an XHTML document which means you have autocomplete for XHTML provided your DTD is pointed to can can be read. Further support only requires a more in depth description.rc file, tag files for dialogs and any toobar files. None of which requires anything more than a basic understanding of XML. I'm thinking you're going to get some benefits from the total package...

So the only question really is why I haven't heard from you asking to do XHTML tag files or some part, if this is what is keeping you from using Quanta.

I would just really like to ask people to actually read what we're doing now instead of basing their opinions on where we were six months ago. Quanta has several people putting full time effort into making it a killer app and three dozen people on the developer mailing list of which a dozen contribute code. If you blink you will be discussing yesterdays's news.

I know some people just don't read up or download before dispensing opinions... but I can dream. ;-)

FYI people we are working on a zillion issues to make Quanta do all the things everyone wants it to do. It will take one person no more than a few evenings for complete XHTML support to be added and then we can package it so you can extract it, run an install script, restart Quanta and enjoy. Will that one person please email me?

I didn't say it's a bad app :) Bluefish does some of those things, but feature development seems to have slowed with the transition to GTK2. I actually downloaded Quanta PR2 on a routine dist-upgrade, but last saw PR1.

I didn't ask for the functionality because Bluefish plain gave it to me. Quanta is a high quality program, but it was simply a case of what app had what capability at the time. I've only recently come back to KDE3.x, after using Windowmaker since abandoning KDE1.x. The fact that Quanta had the benefits of KDE integration seemed largely irrelevant (indeed, I still like Galeon more than using Konq/khtml for its rendering capabilities, even if the interface seems out of place amidst my 1/2-functional Keramik style). If Quanta gained these new xhtml capabilities, then I'd probably use it for the sake of consistency, and make use of/become attached to its other obvious benefits. But frankly I didn't see the need to alert anyone of my problem as it simply wasn't much of a concern.

Users are jerks :) It's pretty impossible to read what we want, I know, but that's what happens. I didn't file a complaint because at the time I didn't care if it was fixed or not. It would have been courteous, I admit, but I'm sure some developer had heard of XHTML1.0/1.1, or Ruby tags, etc, and was aware that you lacked the necessary rc files.

Quite simply, as an Economics and Philosophy student I go with whatever works now, as long as it satisfies my political/ethical criteria ;) Tommorow I might be running Gnome2. Who knows ;)

> The fact that Quanta had the benefits of KDE integration seemed largely irrelevant

They would be if those benefits didn't extend well beyond the fact that KDE goes well with KDE. As a developer we are able to focus on just what we need with the highest level of code reuse I know of anywhere. People ask about remote file operations or request sftp... I point out kio and fish. People ask for line numbering and soft word wrap... we use the kate part and have one of two this time around. However many of the features and very cool code have yet to really solidfy in the utterly exceptional. It takes a few years to flesh out and demonstrate structural benefits to their fullest. The point is that we are able to move much faster and develop muich richer because of architectural choices. One of the coolest things coming is kommander which will make Quanta and other KDE apps user extensible to a near unlimited degree provided they make good use of DCOP.

> Users are jerks :) It's pretty impossible to read what we want, I know, but that's what happens.

Actually I get a good read from my feedback. I woudn't say users are jerks either, but if you pressed I might be willing to make an excpetion. ;-) The fact is I get an incredibly positive and grateful stream of daily email. I would have to say our user base has been some of the nicest people I've met on the web. You might want to make a note of the following...

> I'm sure some developer had heard of XHTML1.0/1.1, or Ruby tags, etc, and was aware that you lacked the necessary rc files.

Having heard of it is not the issue. Being aware that we lacked rc files is not something they would know as these ae new changes. Here's what I did. I made a determination to make a radical architectural departure from beig an HTML editor. Most users don't even do compiles but load rpms and we run 35,000 downloads with a handful of developers. Do the math. If you understand OO coding in any language you understand abstraction. We're not going to set the world on fire with C++ coders laboriously coding in the support for another language. Who knows how many users have actually expressed gratitude to me wishing they could code to contrubute. now they finally can! We are going through all the functionality of what Quanta does and making it pluggable... In other words we are making it user upgradable! Everything is being redesigned to elimiate redundancy, reduce effort, simplify processes and invite experimentation and estension.

In simple terms we no longer need to start from scratch when you want to use a new tag language or XML dialect and add Ruby instead of Perl or PHP or whatever. Traditionally these are handled by programmers compiling permutatioin after permutation. No more. Now the document will be disected, managed and merged accoring to rule sets we will make accessable for advanced users. But first of all, did you get that any markup language is supported by accessing the DTD? You have auto-complete and soon a degree of validation built in... and in the coming months this level of service will happen without a single bit of internal support being written! As for scripting languages, we pulled over 2660 PHP functions for auto-complete from the docs with a perl script today.

Like I said, blink and you will be talking ancient history. Put another way, XHTML is no longer a support issue because in the coming weeks anybody who can write XHTML/XML/HTML can can do it right in Quanta. If you can find the DTD, define how you want parent and child relationships handled in the structure tree, descibe where on a grid you want dialog elements for dialogs and point and click some toolbars you have just brought it to the level of functionality of our current HTML. Howeever if you can find the DTD on file open you still have features with no time invested.

Like I said, blink and you will be talking ancient history.

> Quite simply, as an Economics and Philosophy student I go with whatever works now

From the economics standpoint would you rather have the C++ developers reading language docs and assembling tags and toolbars or less than 1% of users, who work in those environments, setting them up while development continues? From the philosophical viewpoint do you think it is preferable to hop through the community with the view that personal enrichment only comes from consuming or is there some profit believing in something and contributing something to it's growth... especially knowing if no one felt that way you would be stuck with the best you could buy. Because no one would care to empower you, only to find what worked. An extension of that argument is that I could buy websphere for what I have invested and continue to on Quanta. So my needs must extend far beyond simply having a tool for a task. I do hope you are not majoring in existentialism. ;-)

> as long as it satisfies my political/ethical

Hmmm? I don't want to touch that really. I am deeply convicted that our freedoms and future are going to be decided by how we allow distributions of power and wealth to affect the flow and exchange of knowledge. So I feel strongly about impacting the world around me to empower others and offer superior alternatives even if it means great personal sacrifice. To do less is to hand over the future without even a whimper. However my poilitics would surely chase you away... Then I would loose all that revenue from licensing. Damn!

> From the economics standpoint would you rather have the C++ developers
> reading language docs and assembling tags and toolbars or less than 1% of
> users, who work in those environments, setting them up while development
> continues?

Not supporting the current standard which is XHTML 1.0/1.1 is IMO a serious lack. Saying that a C++ programmer is overqualified to do it is a lame excuse. You can't seriously intend to release Quanta 3.0 without full support for XHTML 1.0. If no user steps up and adds the support then someone of the developers will have to bite into the sour apple (German saying) and add it.

As I write my webpages in XHTML I need this. But I don't have the time to add it to Quanta since I'm busy developing KMail.

> Not supporting the current standard which is XHTML 1.0/1.1 is IMO a serious lack.
> Saying that a C++ programmer is overqualified to do it is a lame excuse. You can't
> seriously intend to release Quanta 3.0 without full support for XHTML 1.0. If no
> user steps up and adds the support then someone of the developers will have to bite
> into the sour apple (German saying) and add it.

Well thanks a lot Ingo! The validity of your point seems less important than the fact that people tend to take the path of least resistance doesn't it? ;-)

I am not arguing a C++ programmer is overqualified. I'm saying that we are designing Quants so that 1) it doesn't require a C++ programmer to add a markup dialect, 2) it is no longer the best use of programmer time because it will take that programmer off a number of tasks that users also want done and 3) that a user will always have a better idea about ergonomic aspects of what they use all the time than a developer who rarely touches it.

My other point is that in order to make a superior program you need to involve large numbers of people. Our goal has been to substantially lower the threshold of entry. While your point is valid it is from a perspective of limited user development web development has more developer oriented users than other apps. By my estimates we have hundreds of thousands if not millions of Quanta users. It only takes one person to do some XML to add any markup or scripting language. The arguments you make for XHTML can be made for ColdFusion, ASP, JSP, Java, Python/Zope, Perl, DocBook and numerous XML dialects. One user out of every, say ten thousand, could bring all of this to Quanta... or we could postpone CVS integration, auto doc generation, advanced site planning tools and more for an entire point revision of KDE.

> As I write my webpages in XHTML I need this. But I don't have the time to add it to Quanta since I'm busy developing KMail.

You'll have it and of course I don't expect you to divert from KMail to set it up. You see I want you to keep working on KMail as I'm not up to speed on it so I will make sure XHTML is there. See? this is my prinicple at work. ;-)

> Anyway, thanks for a wonderful program!

You're welcome. I hope soon it is just exactly what you wanted. (Of course as the old American saying goes "if you want something done right you've got to do it yourself" so don't think I won't accept patches if you don't think we get the XHTML support right. ;-))

Look. I like Quanta. I realise its benefits. My political/ethical ideals led me to a GNU/BSD solution. Between Bluefish and Quanta, I chose the one with the features I wanted. That's all there is.

I understand the benefits of OO and abstration, obviously. It's an interpretation of specialisation of labour for an economist-thinking person like me. I understand your concern that i'm just a mooching user, but frankly I'm an HTML hobbyist. I could learn to do what you ask of me, but I have more pressing schoolwork to do.

The only 'time-economical' thing I could do is alert a developer, which I did in my initial posting, though I admitedly chose the wrong forum, and was a little late in doing so.

I'm sorry if I've offended you. I do like Quanta, if it matters for anything. I just don't understand why you're upset. Quanta plain doesn't support the current standard, and I can't adequately aid it in doing so. While it has obvious advantages, they just don't pertain to my needs. Since, structurally, it doesn't take long to support new features, I'll probably be using it in a couple weeks anyways.

> I understand the benefits of OO and abstration, obviously. It's an interpretation of specialisation of labour for an economist-thinking person like me. I understand your concern that i'm just a mooching user, but frankly I'm an HTML hobbyist. I could learn to do what you ask of me, but I have more pressing schoolwork to do.

No problem. I understand this posture.

> The only 'time-economical' thing I could do is alert a developer, which I did in my initial posting, though I admitedly chose the wrong forum, and was a little late in doing so.

Nobody's perfect. We knew it was missing though. We just had the same contraints. Not enough time.

> I'm sorry if I've offended you. I do like Quanta, if it matters for anything. I just don't understand why you're upset.

No offense and I'm not upset. I'm simply responding to what you said. Sorry if you took it wrong. Actually you brought up some very good points by way of apparent assumptions. Logically not everyone can be deeply involved in all the things they interface with to the degree that they would be as passionate as I am on this topic. I am deeply involved and I did considerable research and pondered long and hard on our course of action. It's human nature to want to fall into repetative patterns and evaluate things based on comfortable paradigms that may not best serve us. I frequently have to repeat over and over again things like kio means we have all io slaves automatically and such. I expect to have to repeat that Quanta is actually moving toward strong user extensibility and that we need to ask the tiniest percentage of users to step up.

Why should I expect anyone to know that or even to grasp the implications the first time it zings by? The bottom line is that I have to look to introduce this mindset regarding Quanta to the community that throughthis design paradigm shift we can leverage a much larger development effort and provide a richer and more diverse tool.

I apologize if you misinterpreted what I was saying or were any way offended. Your posts were a perfect vehicle to bring out the key points we are addressing. Thanks.

> Since, structurally, it doesn't take long to support new features, I'll probably be using it in a couple weeks anyways.

That'd be my guess. then it's up to our developers and contributing users to convince you that I might have actually had a pretty good idea to make a tool that easily shaped to fit your needs. Who knows? Maybe some day you will actually cheer for a program.

> And hopefully kate part for 3.2 will have dyn. word wrap, too ;)
>(started a branch for that, hope this time it works, think that is now the 6th try or more ;)

Oh man! What do you want for Christmas dude? Do you have any idea how many emails I get asking for this? I may finally be able to open my email withut saying "not again". ;-) I'm glad this is your baby BTW.

One other cool thing I noted was that Quanta now has code folding in KDE 3.1 beta but I've only seen it work for C++ so far. I'm assuming since we parse our document into nodes currently for our structure tree it may not be too hard to feed that information in and fold... but I haven't had much time to look at the code more than a glance.

if you want to test the wordwrap stuff, check out kdelibs/kate with TAG: wordwrap

it is binary compatible to the normal kate part HEAD (only added a menu item to enable/disable wordwrap ;)

Would be nice to get it tested out. It still has many bugs (atm it wraps in words, too, but that is just because I was to lazy to change that atm and other bugs are much worser)

Should be ready for 3.2.

About the folding stuff:
The folding is just done by the highlighting xml file. You just must insert there some folding statements to allow to fold contextes, look at the c++ xml file, should be rather easy for php, too ;) Only to fold html we would need some explizite tag lists to fold.

Plans to have a WYSIWYG mode are, but don't hold your breath now. There are other priorities for us at this moment. Of course developers who take care of making a WYSIWYG mode for Quanta are really welcome.

First off Jono was an incredible driving force on Kafaka and I suspected he would be missed when he left. Kafka had some different aims and was largely geared to be a newbie WYSIWYG editor as I understood it in my conversations. I can't speak to kafka particulars very well.

As for WYSIWYG mode Andras has already answered. I'll make some additions. Some users want it... some want it not to happen. There are valid reasons for both. WYSIWYG has been traditionally a real hack job. The coding underneath was the designers best guess at how they wanted to do things and it would be "hard wired" to how the tagging was set up. This causes lots of aesthetic problems with your code and makes adding DTDs a near redesign. In short WYSIWYG traditionally is a mess which leaves you with static pages that require 5-15% of the work to be done by hand anyway for finely tuned sites.

Our approach to DTDs and our parse tree is laying the groundwork for validation as you go features and rule based code formating based on defined nodes and relationships. Eventually when we are ready to add WYSIWYG we will have other options because of our founations. These will include feeding the markup to the WYSIWYG view while managing the server side scripting seperately or even being able to edit markup elements in dynamic content. In addition you will be able to completely define how markup is handled through the rule definitions or have other options being able to extract stuctures, edit them and re-insert them in the doucment.

Once you look at all the potential issues it is clear this is no simple task to do right. However when we are foundationally ready to preserve your work and extend the paradigm of WYSIWYG to dynamic page design we will begin work on it. Andras is right. We could use a few more developers for this. The point is I would not count on it for KDE 3.2. It would be great if it could be on track the middle of next year. I can't say right now. All I can say is when we do it you will agree it is the best implementation. It will not be a cutsie "paint a page" program but a serious developer tool that newbies can leave the defaults settings on and be happy. Coders will be able to use it more like a QT Designer for web pages to make them more efficient with the GUI elements of dynamic pages. ;-)

Hi Adam, I've had at least one person offering to help with ASP.NET but from your post I have to assume those are not Mono. I'm the guy to ask. The short answer is yes. the long answer is let's talk about it. I will either look to hook this up with someone expressing a developer interest to us in this area or help you and your people to easily implement it.

The point again is that Quanta 3.0 will be completely user extensible for tagging and scripting languages with no more than some XML editing. In some cases the majority of this can be generated from docs with a Perl script. (That's how we went from 3 tags for PHP to over 2,660 in one day.) At this time this will get you document structure tree nodes, auto-completion and tag dialogs. In the future more benefits will be realized from the same or less effort.

That is awesome Eric. I have to say, I think you have a killer app on your hands. Like I said, I use Quanta right now for designing pages and it is fantastic.

The ASP.NET support will come, I'm sure. Either I will provide it or another eager developer will get to it eventually. There is some real excitement among the Ximian/Mono folks over the implementation of ASP.NET.

I would also strongly advocate for the WYSIWYG support. With a good WYSIWYG I believe you will have quite a large web developer interest on your hands :-)

Joseph from the Kate team is working on providing DCOP bindings for Qt# and Quanta uses Kate so perhaps Quanta will have support for C# plugins soon... The future is wide open :-)

> I would also strongly advocate for the WYSIWYG support. With a good WYSIWYG I believe you will have quite a large web developer interest on your hands :-)

I guess you read the other responses... WYSIWYG will come. However we are approaching it from a code perspective rather than a "you only want to point and click because you don't know anything" perspective. I have not heard anyone describe the architectural steps we're taking. With sufficient community involvement Quanta has the opportunity to become a juggernaught of an application that does anything and everything related to web work so well it would be hard to offer a proprietary alternative. That's my goal. Because of that it has to have whatever you use available to plug in.

> Joseph from the Kate team is working on providing DCOP bindings for Qt# and Quanta uses Kate so perhaps Quanta will have support for C# plugins soon... The future is wide open :-)

Our goals for 3.1 and 3.2 include the most extensive DCOP implementation imaginable. The reason for this is the supplemental application one of our developers, Marc Britton, is working on called Kommander. What it does is builds dialogs in a stripped down QT Designer with special widgets (essentially prepped KDE widgets) which runs from the ui file via an executor program. It will speak DCOP and also allow for any scripting language that runs in your shell. You may not even be aware Quanta has this scripting capability but you will find it in the configure actions menu. We took the inspiration for this from Kaptain, which builds dialogs from grammers. I used Kaptain to creat custom dialogs for PHP classes to enable me to handle complex 500-700 line data management classes building objects and method statements with point and click simplicity.

While Quanta 3.1 (possibly 3.0) should provide auto-completion for your linked local libraries and classes from the file you are working on the addition of the dialog builder will be nice too, allowing you to structure tasks with tabbed dialogs or create wizards and exchange information and insturctions in real time via DCOP.

Our goal is nothing less than pushing the strengths of good design decsions, KDE and OSS to the point where it becomes a tool of choice among serious developers. I think Mono's ASP.NET would be a very logical part of that puzzle. I'm looking forward trying it out.

Ok, after fully reading the posts above I've come to a new perspective on my question.

Eric, let me say that I would hope Quanta supports Mono's ASP.NET in the future. I use Quanta for creation of my personel pages as well as maintaining http://qtcsharp.sf.net.

With that said, I don't know if I'll have the time to contribute this XML dialect to Quanta anytime soon. I am simply to busy with other OS/FS projects including Qt#, KDE# and Mono. I will try, but I can't promise any time right now.

I'm no programmer, so I don't know how hard it is to adapt konqueror's layout engine for rendering pages in Quanta in WYSIWYG mode. It seems to me that konqueror has a very good idea about the structure of the page it lays out (It needs to, since it fulfills quite a large part of DOM/XHTML specs.) For editing the source directly, all I really want is syntax highlighting. Everything else is not very important. However, for WYSIWYG mode, my wishes are more complicated to fulfill.
I have to admit that my assumption on what HTML- WYSIWYG should look like is very much based on Macromedia Dreamweaver. That's because DW works *extremely* well, is professional, and very intuitive. I'm sorry to say that as much as I'd love to move my PC to 100% Linux, I simply can't, as long as there is nothing that comes even close to Dreamweaver.

> I'm no programmer, so I don't know how hard it is to adapt konqueror's layout engine for rendering pages in Quanta in WYSIWYG mode.

I don't think this is the answer at all. There are other options to leverage code I'd like to explore but I'm not discussing them until it's time.

> For editing the source directly, all I really want is syntax highlighting. Everything else is not very important.

Then I would expect you're probably working with static HTML from a visual perspective. As I said it's very different. Because of the decisions made years ago with legacy tools they are at a distinct disadvantage. It is like comparing GUI to the command line. Most of the time a GUI may seem more productive... then you see someone who takes a programatic course of action on the command line who somehow doesn't have to do 60-80% of what you keep pointing and clicking at. So which is better? Neither! That's the key and one cornerstone to the undoing of these page drawing models. Quanta has been around a few years and just gotten serious about being a competitor in the last few months. It will take a little time for the product to mature to demonstrate the advantages of our approach.

> ...there is nothing that comes even close to Dreamweaver.

2003-09-11 - s/Dreamweaver/Quanta/

All of us using Linux believe that there is among other things an inherently better design which can be traced back to a different approach to problem solving, development and core motivations. We know that operating systems are becoming commodity software because free ones perform better than what you pay for in many circumstances. We know that the office suite is next and eventually all shrink wrap software will, by logical extension, become commodity products. Otherwise we are uneducated or insincere about the nature of open source and the key advantages it brings that are compelling to continually grow the developer pool.

I am simply looking to help drive this as a program to meet my needs, keep windows off my disk and spearhead the transition that helps to insure free exhcange of information remains free for our children. I'd rather spend several times the cost of Dreamweaver every month than accept the moral revulsion I feel about having any involvement with the worst corporate criminals I've ever seen, Macromedia of course accepted.

I'm not going to use anything but Quanta because it's my baby. Because it has a huge user base I could not let it die. I also can't stand the thought that anybody else might have a better, more capable or more productive tool so my path is pretty much set. Rich Moore once told me we would need at least 9 months good development to be competative with the top windows offerings. I'm discounting the last three as getting started and giving us 12.

I've spent the last two years contemplating our feature set and planning for WYSIWYG. I'm betting that when we unveil it, it will not be quite like anybody else's... and that Dreamweaver will be losing ground fast in the features department and unable to keep pace.

Personally, I would prefer that Quanta Developers put off adding a WYSIWYG editor as long as possible. Eric is right, there are things of higher priority. I would rather they find and fix all the bugs, and then go on adding features on the hand coding end than focus on the WYSIWYG area. Secondly, as someone stated, it IS a hack job, and in most cases, even the best WYSIWYG editor makes pages slower than hand written ones. For those that try to compare Quanta to Macromedia Dreamweaver - well you show your ignorance on the topic of HTML editors, because if anything, Quanta would be closer to Macromedia Homesite - another "real" HTML editor and not a WYSIWYG one. People should understand that they are 2, distinctly different types of HTML editors, and comparing the 2 would be like comparing C++ to Delphi...

Thanks for your vote of confidence Chris. You're right about holding off for more reasons than you may realize. As far as bug fixing goes I always like to think we just fixed the last of them. ;-) I can dream. There are a lot more features to add too. However I do most of my pages from PHP classes, functions, include files, data lookups and such. I usually abstract my content from my layout too so that I can take an XML file and plug it in for content while we can change the look and layout of the site by loading new structure files, artwork and style sheets. How the hell am I supposed to do this with WYSIWYG and how do I keep it from slowing me down and murdering my API?

Personally I agree with many programmeers that drawing a web site pretty much is a delusional procedure of painting a static layout integrated into your content which is a maintenence hassle. Of course I guess the pros can bill as much as 80% of the first year cost of a web site to maintenence and profit by it but I'd rather spend time on creative projects. Unless I can address issues of real programmers I don't even want to begin WYSIWYG. I happen to believe I can do it in a way that takes the most efficient path through both worlds so that a well educated Quanta user simply smokes those using other tools.

> Quanta would be closer to Macromedia Homesite - another "real" HTML editor and not a WYSIWYG one.

Actually the sooner people turn that around to say Homesite is closer to Quanta and then follow up with "actually Quanta blows it away" the happier I am. I hear this and that about it all the time and then explain features that Quanta has that they don't even know about along with how to do what they say they wished it did. Clearly I need to do some tutorials. BTW Quanta is no longer an HTML editor either. HTML is being stripped from Quanta and only returned as a plugin. Soon you will be able to get "DTD packs" which inlcude the DTD, definition.rc, tag files, toolbars, menu items and some base templates. You could choose to use Quanta for KDE DocBook and XML and never even have HTML capabilities in it.

> People should understand that they are 2, distinctly different types of HTML editors

Actually I kind of enjoy pointing out what is new. ;-) You're fundementally right about the differences... but the third and new animal, which Quanta is has a new definition. It is a markup and scripting editor targeted at electronic presentation media, primarily web based. Since HTML 4.01 is the last specification coming from the W3C and XHTML is what follows then we can say that HTML is in fact a dead language. It's deprication is a matter of course... and therefore because Quanta is by nature DTD agnostic and is being designed to adapt more and more functionality from a DTD or XML schema then we can make another statement. There are two kinds of web editing tools. Those that revolve around dead language technology and Quanta which is being designed to instantly adapt to whatever technology is next.

I'm sure there are a lot of people who may think I'm a bit strange. But it occured to me an open source focus on static application of a dead language was a very bad course for us... and an open source foundation that empowered and enticed developers to lead the bleeding edge would be very good for us... Us being the open source oriented web developer. My goal is to make a tool that adapts so blindingly fast that you will play with and master what's new way before everyone else. Combined with our extensibility goals we become the one thing no proprietary vendor dares to strive for... a tool where updates appear before developers can even plan them. M$ may have the browser market and Apache the server market... what stands between them is the development environment. If Quanta on KDE can become incredibly compelling how many crummy broken web sites do you think you will see in a few years?

Think about it. We can't take the lead by always following. And we can't do WYSIWYG until we can do it in such a way that it does a lot more than draw HTML. There are two ways to do things... right or over. ;-)

Well I walked away from html over a year ago, and went the path of computer programming. I'm sure you can tell by my ignorance of all the latests technology in web building. :-) I didn't get any deeper into it than HTML, then CSS, then basic Java Script - so I'm a bit ignorant on topics such as XHTML and others. I'm always open to new knowledge though lol

As far as I know there is no IE for Linux, so your question is rather theoretically, but you can do this and it should work.

1.Install and configure "wine".
2.make a script which launches iexplorer through wine (and passes the parameters to it).
3a. create an action in quanta which launches this action and passes the file name to it or
3b. name the above script to netscape and translate the netscape style arguments to ie style ones
4. Put this action on a toolbar and save the toolbar
5. You should see the current file in IE (if wine does not crash)

If you own Solaris, it's even easier, as there is a IE for Solaris. Don't know about other
unixes.

I'm a web developer and I NEVER had any problem with compatibility. In fact, I always design my websites using the HTML norm, verifying them on konqueror and, when I've finished, I test them on Mozilla and IE. Believe me or not, I have never had to change anything in my HTML code for it to work on the three navigators. I really believe that it's not that hard to make a perfect website without taking care of which navigator will be used to watch it.

One can certainly hope, at least that it is not as overly complex as some.

I have used a number of scripts that enable consistent behavior. You test for browser type and adjust accordingly. However rather than use old techniques I usually just use DOM which Konqi uses nicely. Danny Goodman's Javascipt Bible is also handy her to identify what you want to use and abstract your browser operatons to standardized commands. I have used Javascript and DHTML and done just fine knowing what I was using would work for IE because I read books that specified what each browser would or would not do. Like I said it's gotten better with DOM. Anyway I always just called a windows bound friend when it was done to make sure the small bit of code that handles IE specific stuff wasn't broken and I got no bug reports. It's not really that big of a deal unless you are trying to do with Javascript what, in my opinion, would be probably better done with PHP.

Yes I do. But I admit that I use few JS and DHTML. And, if that's your point, I also admit that I had some (little) problems with JS and DHTML. Sometimes JS/DHTML code doesn't work on Mozilla whereas it works fine on IE and Konqueror. Compatibility between Konqueror (3.0.x) and IE are really rare for me. That's why I think that testing only konqueror is enough for HTML but testing Mozilla too should be enough for JS and DHTML. Of course it depends on how complex your JS/DHTML code is. Some times you just won't be able to make fully compatible code at all :(