Comments

> The BE release sounds like you're taking on too much/spreading development thin. You don't have enough people testing (or developers) prior to BE coming out (as posted on the list),

Okay, by this rational we've always been too thin and are thicker now than ever. ;-) We have more people developing on more things, more people per feature and substantially more people testing. Many people on our user list are running CVS and helping us a great deal by finding bugs, for which I am very thankful. The point I make where you might get the idea we are thin is how much we do with so few people. We should have more developers in a perfect world, but it isn't perfect. Because we've always had to deal with this we decided on a tactical approach that would make Quanta user extensible, but so many people are used to a "consumer" mentality that the community aspect has not taken hold yet on over 99% of users WRT Quanta and testing, developing or donating.

Our approach is that any substantial area of Quanta becomes a sub-project and gets it's own leader. Chris does XML and shares Docs with Fab, Nicolas does VPL, Marc does Kommander, Luciano does CSS and other people are doing various tasks that could move about. Andras does the parser and main project as well as fill in on whatever else needs done and so far, just directing and interfacing along with everything else, I do a very limited amount of coding. I plan to take a couple weeks "coding vacation" later this month to get more proficient prior to taking on some larger design projects.

> yet it looks like you want to release faster than kde releases...so now there are two versions? Or are there two versions? It is more than stable and cvs, right?

BE is a development version. This means a BE release will be a branch off of HEAD prior to KDE 3.2 final and from HEAD after. In all cases it will be a snapshot where we have taken several weeks of testing and withheld destabilizing commits so that it should be pretty stable and usable. It will have more functionality than prior releases but some features may be incomplete. It will be close to release stability but with some obvious bugs that should not interfere with most people's use.

As I said in our story, the decision to begin an external release schedule had to do with the rate which various tasks were reaching maturity. Our release schedule for some features is a year, but they don't start always with KDE's schedule. Other features are 1-3 months. Quanta has become a large complex application and note that Kdevelop and Koffice have not been able to make KDE release schedules. We're proud to be a part of the official release package, but a lot of what we wanted to get into 3.2 will be ready first quarter of 2004. No matter what anyone says statistical probabilities place 3.3 a year out. Going to a dual release schedule seems imperative. We are also seeing a good number of new developer interest emails and people learning Qt/KDE programming wanting to be part of our project. We hope they all become active developers and will do all we can to help them. So it's all good.

> But you are severely underestimating wysiwyg. While the candidates who are more likely to use wysiwyg won't bring you more developers, it will bring more observers, fans, and buzz. And press. And this will very likely bring more developers.

Well I don't know who you are, but it appears you're operating at a disadvantage of not having discussed my thoughts on the matter with me. ;-) Once we have reached a level that I believe we are a serious contender for professional development you can be sure that I will be promoting Quanta on KDE to the mainstream press, if they don't get to me first. BTW visual design is actually only one of three critical components that will cause this buzz. ;-)

> Is it possible to right-click(or something) in the web-page and change form parameters?

As an old OS/2 guy I want to right click everything. ;-) That is not up but will be. I'm not sure if Nicolas has the required strings reserved for that or it just goes into BE. What we do have is the attribute editor which you can see in the lower left of the screen shots. It allows you to edit the parameters of a parent tag from where the cursor is. You can also select up the parent nodes to the root node with the dropdown box. There are also buttons on it to delete a tag or delete a tag and all child tags.

Obviously this is very powerful in abilities but for some tagging situations more intuitive paradigms would be desired. Right now we're working on first steps first. There are some architectural considerations to refining the process and design we need to review. After the basic foundation is in place the extra functionality should actually be a lot easier and faster.

I'm not sure. It's really just reaching a level of adequate usability for heavy testing. I just checked the origin of background colors on a test page and it is displaying where a table data is using a class="" CSS call that sets background color.

Try switching to the error reporter tab below which will tell you to switch to the structure tree to generate the error reports. You might find bad markup confusing it. VPL really wants to see good markup. If you find that the page is good and it's just not working right you could either file a bug or join our user mailing list and post it there.