LinuxQuestions.org has just
the results of its 2002 LinuxQuestions.org Members Choice Award
Winners. KDE took first place in the category
Desktop Environment of the Year with 59.14% of the votes.
KDE applications also did very well in virtually every other GUI category.
Congratulations to the many talented and dedicated developers whose
achievements have been recognized.
Web Development Editor of the Year
Second place (47.65%)
Bluefish took first place
Mail Client of the Year
Second place (26.76%)
Evolution took first place from KMail this year with 35.55%
Office Suite of the Year
Second place (10.16%)
OpenOffice was the big winner
Browser of the Year
Third place (15.61%)
Mozilla was the big winner; Galeon snuck into second
Word Processor of the Year
Third place (11.26%)
swriter (OpenOffice) and AbiWord took first and second
Speadsheet of the Year
Third place (10.55%)
scalc (OpenOffice) and Gnumeric took first and second
Editor of the Year
Fifth place (7.51%)
CLI editors were the big winners: Vim, Emacs, vi and pico
KDE's API has been stable since 3.0, and not moving a lot since 2.0
The only "you will have to rewrite it" move was the 1->2 (but it happened twice ;-)
GNOME's api sucks. Sorry I can't understand how people use that.
Because a) there is a large number of people, especially on Unix, who don't know C++ well enough or don't like it and b) there is more literature for Gtk
Agreed. I've done a bit of gnome hacking simply because I know and understand C but not C++. Objects in C are wierd at first, and rather verbose, but just for adding the odd feature here and there it isn't so bad.....
Ideally of course we'd all be using python or some other high level language, rather than C or C++, but we really need a good object model first. CORBA could be it I think, but Bonobo still has too many rough edges and I don't think KDE would accept it :( We need something like MS COM though.....
CORBA is simply so incredibly complicated compared to DCOP in KDE code that no one who ever used DCOP wants to go back.
Yeah, I know it's complicated :(
Still, iirc DCOP is more an IPC/scripting interface, for instance I wouldn't want to write an XML parser component using it. CORBA can do inproc in a language neutral fashion as well.
IIRC at least in HEAD DCOP can be used in-process as well (Kontact does it).
Are there any docs/emails on that? If not, I'll go hunting through CVSweb tomorrow.
I was under the impression DCOP didn't do objects or garbage collection or anything like that though, it was just an end-to-end messaging system.
CORBA is complicated for the same reasons C++ is. C++ gives a programmer advanced features and because of this it's more complicated. The same goes for CORBA. CORBA is a very advanced, mature architecture, which also means is complicated. But if you would load DCOP with the same features CORBA has, you would reach the same complexity.
But the result of C++'s complexity is very different. C++'s features make it easier for me to implement stuff, compared to C. There's less to type, more things get done automatically (especially oo and memory management).
But CORBA's complexity makes it harder, compared to DCOP. It's much more difficult to write a CORBA server and to use it from command line tools.
There may be cases where CORBA would make my life easier with its capabilities, but I have never encountered such a situation on the desktop.
And what about when GNOME switches to Mono? Are you going to whine that you understand C and can't hack GNOME anymore?
The beauty of Qt is that you don't need a bible of documentation on it. Go to trolltech's website and you have more than enough documentation. I highly doubt that GTK documentation is any better than this. The last time I looked it was incredibly hideous.
Your reason that people don't understand C++ is something of crock given the incredibly complicated and messy OO C code that GNOME uses!
The problem is not learning Qt or Gtk. There are a lot of people who know or prefer C, and it seems like they rather stick to C and learn a complicated library that makes their lives miserable (:-) than learning C++ and using a simple library.
I can understand that somewhat, since I used Gtk for a while because of my lack of C++ experience.
Learning enough C++ to write a Qt app is at most a month-long project.
All you need is:
a) classes, with overloading
b) casts (the new kind)
d) STL containers, if you wanna be fancy (not really needed, if you stick to Qt classes)
Of course C++ has a bazillion other things, but this is all you REALLY need. You will be writing in some sort of C+ in no time, and even that crippled language is incredibly easier in the long run than using GTK+'s objects in C.
I'd say (c) needs to be qualified with "using ", too. No need to know how to write one to use one, really. And certainly no need to be able to implement STL or Boost :-)
Oh, yeah, just "using templates" is what I meant :-)
BTW: I barely know any more C++ that this!
And, here is the winning point: if you want to develop GNOME apps, you have to learn all that anyway.
Oh, sure, it is not the same. The difference is that when you write GNOME apps, you have to do classes without the C++ syntactic sugar. When you use glib containers, you do template containers without the STL syntactic sugar, and so on.
So, what is easier, learning a few language extensions (really, it is not even much syntax): you have <>, you have the keywords class, public, private, protected (FORGET ABOUT THEM, make everything public, if it is not a library, noone cares), const... not much else. Maybe smart pointers to make life easier, but you could still do it the C way if you like pain.
No, this is not a month, this is two weeks learning, TOPS.
Sure, you will then have to learn when and how to apply your new knowledge, but the same is true on the GNOME side.
Say yes to syntax sugar, say no to square pegs in round holes!
 And with function pointers
 And with void*
The point is, that sooner or later some guy will actually use all of C++'s features -which is a good thing in itself- which will make the code uncomprehendible by your 2-weeks old C++ hacker.
Just take a look at the STL sourcecode and compare the implementation of queues, lists with glib's lists and queues.
And no, I don't prefer C myself. But claiming that C++ is simple is ridicilous. Just compare the Stroustrup C++ book with any C book. Surely, C++ is more powerful, but that power brings its problems as well.
a) This guy is a beginner but he is not stupid. He will learn more C++ eventually, so this is just a window of problem. And as you say, "sooner or later", and later is not a problem.
b) If he is the main author of the app he is working on, this is really not a problem, because most code is written by him
c) Even if the app is developed by a group, usually contributions have locality.
d) I see KDE code every day. Most apps ARE written with very basic C++
e) Set policy. Mozilla did ;-)
f) Use QList if STL is too hard
g) Comparing books is stupid. C++ has more syntax, and more features. But those features and syntax fall in two categories:
* Those who make things easier
* Those who don't
The first are worth learning, the others aren't. On C, you have no features of the first kind, and you have to do it in your own code, which is why many C libraries have small APIs but are hard to use.
In short: you can't have it both ways. Either C++ makes life easier and it is worth learning, or it doesn't and it isn't. If so, then C is worse, since you could trim C++ to fit C.
Well, the GIMP and GAIM are just really big updates. The Gimp introduces new tools, new colour abilities, new artwork, totally revamped text handling, new scripting etc..... they also aren't GNOME apps, they just use GTK+ and parts of its HIG, but not for instance GConf or gnome-vfs.
I can't wait for GIMP 1.4 :) I use the unstable series and they really kick ass! Gaim is starting to look nice also, I was going to try kopete because I never liked the Gaim UI, but read about instability and i couldn't be bothered installing everything needed. Now it looks like a lot of those ui problems are cleared up, so that's another app that I hope will go stable soon :)
Just a little on abiword.
* It's *not* just a port to GNOME2/GTK2. It's a massive feature addition as well in current cvs, such as tables, footnotes etc. The basic GTK2 was done by Dom in something like a week or so (of course with some bugs, but anyway).
* abiword is not really a "pure" GNOME application. It would probably be easier to use qt since it's based on C++ and to my understanding they are currently using the C libs for the *nix version.
As for the "I thought that most of those important applications would be "2.x"-released rather soon after the GNOME 2.0 release" I tend to agree, but the fact was that abiword e.g. just released it's 1.0 and was (and still is) in a haevy development phase with feature editions.
A couple of comments about evolution
It may do a lot of other things beside email, BUT as a gui mail client I have not come across anything else as good in terms of features and most importantly capacity.
It is the only client I have tried (sylpheed, balsa, netscape, mozilla) that can actually handle my 300-400mb mailbox
Also I cant live without vfolders
Hehe Ex GNOME user, nice try.
In first case I wonder why so many GNOME people are spending there time on here convincing KDE users how much more mature GNOME is. Must be due the fact that none of the GNOME related pages such as http://www.gnomedesktop.org/ and http://www.gnomesupport.org/ are reachable for various weeks now. Anyways I as programmer like to point out some roof to basement things that GNOME has made.
- They ported GNOME from 1.4 to 2.0 and THEN they invented the HIG. In my opinion it would have made more sense to came up with the HIG first and have the apps ported using the during the development phase and not months after the first official GNOME 2.0 release came out. No offense but every GNOME application looks differently than others none of them look close to the other.
- Some would argue that GNOME 2.x was written from scratch only for the sake to argue. This is not true most of the libraries and utilities are simple ports to make them operateable under GNOME 2.x. If so then why are there 5 different Toolbars inside GNOME yet ? They are soon being replaced with LibEGG Toolbar and the old code are pointing to the new one through Wrappers. If it was build up from scratch then such stuff never made it inside GNOME 2.x here a source of proof.
- Some would argue that GNOME 2.x was in a development cycle for 6 Months only but that isn't true either GNOME 2.x was overdue for over 1.5 years. I must admit that GNOME 2.x was a heavy change from 1.x and I would be a fool to say something else but definately not written within 6 months. It took more time.
- GNOME still has no serious way doing normal sound without having the pain in the ass getting GStreamer up which is still under development and far away from being implemented in ALL parts of GNOME and far from being stable from everydays use.
There are various good ideas in GNOME no doubt but for the past 3.5-4.0 years that I am using GNOME it really matured into something strange. It was good at the beginning of development phase and good competitor to KDE during these days looking similar in function and operation. But 2.0 shot the bird with reversed buttons and gconf and make me smack my head against the wall because they still make the same mistakes over and over again, now backed by RedHat, Sun and Ximian everything isn't anymore as it used to be. Something went better, something not. But as other people wrote already. Why should I wait another 4.0 years until GNOME is getting stable and usable when I can use a good integrated and pleasing desktop such as KDE today ? And I like to say and write this without feeling sad for my opinion since it is my opinion. Instead simplifying GNOME with the removal of Preferences and have them stored in GConf-Keys they only reached the opposite. I have now all the pain going through GConf keys configuring the hell out of my system than it was before with the Control Center and all preferences correctly organized and well structured listed in it. GConf only added another source of complexity there. There is so much to complain about it simply outweights the whole issue therefore it's better to use the better plattform and I like to do this without getting blamed for my decision. As someone else pointed out here GTK+ 2.x has good documentation. This is simply not true. Stuff as GTKTree are neither really correctly explained in either the tutorial nor in the reference manual. Many functioncalls are not explained and so on. Same is valid for many GNOME library calls, you as developer don't know which functions are DEPRECATED, which functions soon are being replaced. Which methods of programming are not common anymore and what functions are meant to do. For everyone who need a proof for this now go to developer.gnome.org and make yourself confortable with it. it's not that I as capable programmer would not like to help but help how if the API and stuff is only known to a handful of people "The family". Without knowing the API, no documentations, no resources for fresh docs you as developer easily come into the risk developing a new application where you spent much time into it and motivation and then find out that things are not being suggested to do it that way.
This isn't meant to be an offense, just my personal opinion since I know various people on here namely comming from the GNOME plattform. Instead advocating GNOME which is your good right, you should also look under the hood of the car. Things will for sure change. No doubt GNOME will sure become better but when ?
I hope you people accept this as a valid comment made by someone and as nothing else. If you find I'm wrong then please reply and argue as a man and not as a whimp.
Those pages are accessible just fine. Looks like you got yourself banned.
No, these pages are not reachable for many of us. Sometimes they work sometimes not. It's already addressed to Stro who runs these pages and is likely an ISP issue. This has nothing to do with banning since a bunch of people are affected to it.
No, Galaxy is right, I can't connect to either http://www.gnomedesktop.org/ or http://www.gnomesupport.org/, both of them time out here. It seems at least the largest German ISP T-Online as well as the French ISP Wanadoo (which I'm using right now) are affected. Maybe both sites went US-only about a month ago?
> none of the GNOME related pages such as http://www.gnomedesktop.org/ and http://www.gnomesupport.org/ are reachable for various weeks now.
That's the same server. I can tell you that it's running and available but e.g. not from Germany's biggest ISP T-Online while no problem with other German ISPs exists.
Heh, this is really suckage. Some people I know of are ssh tunneling from t-offline onto these pages.
Do you know an address where one can complain to technical stuff? [email protected]?
Dunno, try 'host t-online.de' and look the information it outputs then you see the technical contact. Write an email to them.
sorry my bad :)
I have to agree on the state of GNOME documentation. It seems like only a handful of people know which functions are deprecated or not, and they are not letting the rest of us know.
Hey have you seen how many votes have been there on these polls? I have no idea who was asked but I dont think that around 500 is a number which is supposed to be significant... no wonder suse and kde weren't that strong...
I'm willing to bet that >50% of the votes were posted using Internet Explorer. And no, I'm not talking about browser spoofing either.
I've been looking for a site with just these types of polls but, have had little luck finding them. I even thought about building my own and including public access Webalyzer pages with it but, the problem is the same as with Linux Questions, how do you generate enough votes for it to be meaningful.
Ideally, Slashdot would be the perfect place for such polls. But, they don't seem interested in these types of polls, rejecting them as fast as I can submit them. Funny thing is that it is just these types of polls that initiate the religious flame wars that generate lots of posts and make Slashdot interesting.
I made some comments on this poll when Bluefish was included in the editor category and Quanta was not. (Nor was Kate as I recall) The pollster changed things around to make a web editor category, and I guess Bluefish already had a few votes. A few weeks later I thought it would not be right if I didn't cast my vote... but to do so I had to sign up and give my information to LinuxQuestions. Know what? I didn't feel like I wanted to. I'm sure they're helping people there with questions but I didn't want to give out my personal information to do a survey... and I didn't have any questions. I guess I was not alone because there were only about 10 votes total in the web editor category. I have several hundred people on maiing lists. I'm sure had I encouraged them to vote Quanta would have stormed to first place...
I'm happy knowing the kind of response we get on Quanta like over 30,000 downloads of a version on sourceforge before it was included in distros giving us a top 10 berth in over 50,000 projects at the time. As KDE is the most popular desktop by any standard Quanta is now part of that. Moreover to my knowledge we are the only one that manages a parsing engine that allows for DTD neutral quick tag and script dialect adoption and blinding speed performance on huge files.
We've put a lot more into our base architecture so we could be ready for our next hurdle... the first professional web tool on Linux with WYSIWYG. Once we are further along with our technical review we will post our plans there.
So while we were narrowly edged by an editor with a decent feature set we have been working to give Quanta the agility and development ease and accessability to enable our users to help us extend it. We have never really wanted to compete with Bluefish. We want to dominate when compared to Homesite and Dreamweaver. This is the year we do it. If you're a Quanta user you can help too.
Eric Laffoon - Quanta+ Team Leader
Mailing list - http://mail.kde.org/mailman/listinfo/quanta
You mean like Netscape Composer? Where you just write text and paste images?
That would be great. Try to beat composer please.
WYSIWYG == What You See Is What You Get
I really like the style of Dreamweaver where you can switch between a code/WYSIWYG view whenever/wherever you want. If Quanta could do that nicely it would be awesome. :)
> I really like the style of Dreamweaver where you can switch between a code/WYSIWYG view whenever/wherever you want. If Quanta could do that nicely it would be awesome. :)
Does Dreamweaver provide WYSIWYG services to dynamically constricted HTML? Does it debug XSLT and web services? Does it do DockBook or other SGML?
I don't use Dreamweaver so I don't know what I might have missed but for the most part these applications are dealing with lots of legacy hard coding. Our objective with Quanta is to manage whatever you want to edit with minimal setup for the dialect as well as manage PHP and other back end scripting with a focus on making advanced usage easier.
Obviously we are not going to ever block out the editor. WYSIWYG is only an added convenience for layout and content management. The ability to switch will of course be able to track the location in the document from source, pre-processed source and rendered.
In fact given the complexities of the subject and the shortcomings of other approaches we have not ruled out other alternate and useful supporting views that might prove beneficial in a production environment.
> Try to beat composer please.
Oh come on... don't make me snort coffee out my nose. If you've looked into Quanta you know it's first rate. If you've read any of my posts on this subject you'd know we will never do WYSIWYG until we know we can do a lot better than what has been done before because everything I've ever seen left a lot to be desired.
Quanta is no longer an HTML tool... it's a DTD agnostic markup and script tool... therefore we can't do the composer route without going backwards to the dark ages... and obviously we can't hack things up. Have a look at Quanta... why do you suppose we have gone to DTD specific markup and a multi DTD capable document tree with extensively parsed documents? ;-)
When Quanta does WYSIWYG it will be writing markup according to the rules you set and specifically for your DTD. It will also be offering these benefits to programatic approachs too so it is not just a way to make dead languages easier. ;-)
Quanta has never been about being another web tool... it has always been about being the best.
I've tried quanta (2 and 3) and regularly have a look at it, but it seems it is still unusable for me. It looks like an editor to create html 2.0 or 3.0, but definitely not html4/xhtml documents. For instance, there is a button instead or a one ( has been "discouraged" for more than 5 years - same for versus ). Also, I could not find how to create a page of xhtml in Quanta with the "wizard".
With respect to ease of use, Bluefish deserves its first place. I haven't voted, as I didn't know there was such a vote, but clearly would have voted for Bluefish.
Maybe next year with quanta 3.2 it will be first. But at present not.
Yes, Quanta still shows up some old/deprecated tags in it's default
HTML toolbars, but with the current infrastructure it's just a matter
of XML writing and point&click to correct this. And it can be done
even by any users. The keywords are DTD definition/tag files;
user toolbars and actions. For the problem you bringed up the solution
is quite easy: create a new (tag) action for and in the
Configure Action dialog, put it on the Standard toolbar instead of
B and I and enjoy it. You can save the new "Standard" toolbar, or e.g e-mail
to me so I will include in a new release.
It's quite easy to do it.
And I think the power of Quanta is configurability. :-) (And we progress in
BTW, the Quick Start wizard is an old one, and will be replaced (soon).
I have to salute Andras here because he has been working his ass off day in and day out with rarely a day off to bring Quanta from the rather lame HTML 3.2 editor that it was to where it is now. In particular, making Quanta so incredibly user configurable has been a lot of work that seems largely ignored by people seemingly in a "consumer mindset". Spending several months making Quanta function with user configurable DTDs (has anyone else seen an editor that parses the DTD of the document, handles compound DTDs and adapts toolbars and auto-completion?) including the rather difficult task of writing the rule set to make scripting languages like PHP adhere to psuedo DTDs so that they could be defined in the same way for the same benefits has been remarkably unheralded. (Java or Perl could be added now with XML configuration and an rc file) Spending another couple months squishing bugs, tuning for cpu usage and making the parser thousands of times faster than it was may get little notice. In fact it may get ignored and over-shadowed by other "more exciting" features in 3.2.
During this time I was interacting in the design phase and scrambling my ass off in the months my business income is lowest and costs are highest to make sure I honored my sponsorship commitment. Of course someone would notice one of the things we had not done, and in classic style instead of sending us an email telling us to wake up and get our face off the keyboard and fix it... or better yet sending us a fix... wait until it could be delievered as an illustration of our shortcomings in what is essentially an unfinished conversion for some time. Of course the poster is right, and I am duly shamed.
I think Andras deserves some real kudos for doing all he does, responding immediately to bug reports and even having diplomatic skills too. Clearly we are now both in agreement that our recent work redesigning configurable actions now needs to be followed by a tutorial so that people will know what can be done from the settings menu. Maybe then we can finally get a few web developers who will help us advance the user configurable aspects of Quanta so we don't have to take a few months off the core coding like scoping PHP variables in auto-complete and the tree or a WYSIWYG plugin.
If I could ask one thing of users it is this. The next time you read about Linux and KDE as an open source community and perhaps swell with pride over over community accomplishments ask yourself how you feel about your standing in the community. The next time you find something that needs done in a piece of open source software remember that you are that community. You cannot imagine how much greater the victory is when you know you've played a part in it and we've gone out of our way to make that really easy for our user base. We need more web developers on our applicaton development team!
> a DTD agnostic markup and script tool...etc
Ok this all sounds really cool. :-)
> When Quanta does WYSIWYG it will be writing markup
Hey, I thought for a moment you guys were going to make a cut and paste thing...
You're not planning on using xcschema instead of DTD:s?
Ooooh, WYSIWYG, that?s what I?m dreamin` of :-)
WYSIWYG? You're kidding, right? I thought that you guys had more of a clue about web development than that.
A graphical editor for web pages is one thing, but please don't advertise it as WYSIWYG, because that is _impossible_ for a website.
> WYSIWYG? You're kidding, right? I thought that you guys had more of a clue about web development than that.
Well consider that it's our number one most requested feature and the one obsticle to getting noticed and compared with the big boys... I would think anyone with a clue would realize that no matter how good your web development tool is, until you can draw pretty pictures with it a lot of people are still going to be in game-land.
> A graphical editor for web pages is one thing, but please don't advertise it as WYSIWYG, because that is _impossible_ for a website.
Since Quanta has always had a GUI (Graphical User Interface) it's always been a graphical editor for web pages. Is WYSIWYG impossible? Let's see. I would agree that every implementation I've seen has had real problems but I can also tell you why, what shortcuts the developers took, the assumptions, the obvious marketing interventions and the fact that they were really just targeting the lowest common denominator of human laziness and stupidity because their customers really didn't care what actually ended up happening underneath the page...
Given that a markup page is both written and rendered then by definition WYSIWYG cannot be impossible unless you want to argue semantics and point out that you don't actually see the cursor in the final display page.
There has been a lot of general stupidity about WYSIWYG from software companies like M$ making FlunkPage that hacks your source to hell and doesn't validate, not to mention needs proprietary extentions to work, to developers who take no responsiblity for the integrity of what they produce. Let's not assume that exists here. Okay?
Bottom line: I want WYSIWYG (and I'm going to call it that for the same reason you call your OS Linux, it's easy and people understand it even if it's semantically inacurate) because I want to be able to:
1) Speed up my layout and content entry
2) Be able to provide a custom configured Quanta on a Knoppix CD to any web client so they can use it for content editing providing me ready XML files.
3) Finally stop getting pestered about how totally rad and cool it would be if we had WYISYWG so people could draw a web page because tags confuse them. ;-)
Quanta's application will not hide what is going on and will encourage people to still learn what's happening.
Is WYSIWYG impossible?
WYSIWYG stands for "What You See Is What You Get". The only thing that is possible on the www without a significant step backwards is "What You See May Be What You Get Under Some Circumstances, And God Only Knows What Everybody Else Gets".
The final rendering of a website depends on a hell of a lot of different things, very few of which can be influenced by the developer. Christ, in some cases, the "see" bit is completely irrelevent.
I wasn't arguing semantics. I just don't want you to lead newbies down the wrong path. "Graphical editor" is okay. "WYSIWYG" is not. Many newbies assume what they are seeing is what everybody else sees. This is one of the biggest mistakes they can make, and calling a graphical editor a WYSIWYG editor only encourages it, even if you know the difference.
I wasn't assuming that the graphical editor component would produce broken code, I'd consider that to be the bare minimum to avoid making Quanta the laughing stock Frontpage is.
I do think that there is a strong possibility of dropping meaningful markup when you add the graphical editor component though. When somebody hits the "italics" button, how will you know whether they meant "this should be in italics because I'm emphasising something", "this should be in italics because it's a quote", or "this should be in italics because it's a ship name"? Each of these has a separate way of marking things up, , , and , respectively. If you don't use the right one, you are subverting HTML's goal of meaningful markup and prolonging the wait for useful applications of the Semantic Web.
"Quanta's application will not hide what is going on and will encourage people to still learn what's happening."
Good. But calling it a WYSIWYG editor is in direct opposition to this statement. Most people who talk about WYSIWYG editors without qualifying it are clueless about web development, which is why I was so disappointed to see somebody from the Quanta team do so.
> WYSIWYG stands for "What You See Is What You Get". The only thing that is possible on the www without a significant step backwards is "What You See May Be What You Get Under Some Circumstances, And God Only Knows What Everybody Else Gets".
> I do think that there is a strong possibility of dropping meaningful markup when you add the graphical editor component though. When somebody hits the "italics" button, how will you know whether they meant "this should be in italics because I'm emphasising something", "this should be in italics because it's a quote", or "this should be in italics because it's a ship name"? Each of these has a separate way of marking things up, , , and , respectively. If you don't use the right one, you are subverting HTML's goal of meaningful markup and prolonging the wait for useful applications of the Semantic Web
So your point is based on assumptions? And you were just arguing against a term because people may have falacious assumptions about it. Shame on you. ;-)
First off we intend to have it rule base to assist the user under certain structural conditions or to set a preference where, as you know people as people just decide to be lazy and bad... and we can't beat them over the head. We can only offer them a better way. Beyond that it would mean that when you were tagging as in your example we would have two viable options...
1) Offer the tag from a list with tooltips for proper application.
2) Advance our parser to a level where it would be able to offer semantic breakdowns and allow user configuration of the correct tagging for the syntactic element.
> > "Quanta's application will not hide what is going on and will encourage people to still learn what's happening."
> Good. But calling it a WYSIWYG editor is in direct opposition to this statement. Most people who talk about WYSIWYG editors without qualifying it are clueless about web development, which is why I was so disappointed to see somebody from the Quanta team do so.
Most people? There we go with that assumption again. I came up from the code, not the picture. I understand and detest the problems inherent with tratiional WYSIWYG and I personally think none of them have gotten it right. Key to that is that I am unaware of any web development tool that is both DTD agnostic and has an advanced parsing engine driving it's operation. As I've said before, I would like Quanta to be the first application to do WYSIWYG right.
It would also be very nice if I could edit the html code in the treeview, where the (DOM ?) tree is displayed. E.g. select a subtree and copy it somewhere else, delete it, move it and so on.
> It would also be very nice if I could edit the html code in the treeview, where the (DOM ?) tree is displayed. E.g. select a subtree and copy it somewhere else, delete it, move it and so on.
It's on the do list. One problem is resolving heirachies with tables and such. However you can actually just about do it right now...
1) RMB on element, select tag area
2) Cut selected text
3) LMB on new location in tree - cursor follows
4) Visually confirm location WRT tags and paste
Not bad for lacking the full feature huh? ;-)