The People Behind Quanta Plus
anonymous writes "In this fascinating interview, Eric Laffoon and Andras Mantia give us a glimpse into the world of the Quanta Plus project. Read on for everything from tantalising references to Kommander, billed by Eric to be part of the foundations for the next generation desktop and user experience, to details of future plans for Quanta VPL (Visual Page Layout)."
Koffeemaker - for KDE hot drinks
Kondom - for KDE developer safesex
Kommode - for taking a KDE Krap
I mean, good god, look at the layout of the tabs in that dialog for Kommander. Most of the other shots don't get much better.
Is it too much to ask these guys to put down the source code for 5 minutes and skim a chapter or two in an HCI book?
Can I Play With Madness?
Shouldn't it be, "Kuanta"?
I use vim for all my work, be it writing c/java code, shell scripts, html/xml , emails . basically everything that requires using keyboard for extended amount of time.
Over the years i have tried various IDEs and WYSWYG editors and gave up on them after some time to fall back to my trusted VIM.
Most of them are too bloated and takes ages just to start up. Plus you need a special directory structure and so on so forth.
Quanta plus is very fast, the pre-view actually works , and very intutive piece of s/w.
for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
This has already been discussed, look better and here. Thats the beauty of opensource. It gets better.
(Please browse at -1 to read this comment.)
Just moment ago I finished putting together a 50 page annual report - I decided at the very beginning of the project to give Quanta a shot; I knew I was in for a lot of copy and paste, I've been working with vi for ages and had a feeling that I may be able to save time by taking this on using Quanta.
End result? There's little doubt that it saved me time; probably 8 hours in total. Not bad. There were some annoyances as with all software of this type, and most of it can probably be chalked up to my inexperience with this software package; tags being auto-closed when I didn't want them to and vice-versa, strange text colouring, etc. Then there were some quirks like when some tags auto-closed they also moved the display up a couple of lines; so if I wanted to paste with my middle button right after having a tag auto-complete it would end up somewhere else. Stuff for me to R{more of}TFM and submit bug reports, but bottom-line is that I was quite pleased, it kept me organized and saved me some time. I'll certainly use this for future [applicable] projects and provide the community-feedback these guys deserve. Well done, check it if you haven't already!
. .
-- "Naughty little whispers of Gideon." ."
-- "A playful spank of KwikDisk."
-- "A lingering yet mournful longing for the world that DCOP would bring, yet knowing it shall never be. .
---
Believe me, I'm as surprised by my comment as you are.
would be intra and interapp scripting that is consistent and based on a real component model.
There are tons of bloody component models, why can't one be agreed upon? Because they all seem to suck.
* KParts is not robust - its basically standard C++ linkage with a funner preprocessor. Also GPL bound. And I'm a GPL fan, but this is too restrictive.
* Bonobo is ridiculously overweight and doesn't seem even half sensible. The CORBA C binding? You have got to be kidding me. It is an absolute mess if you wanted to define a new interface and actually use it from a C program without wanting to gouge your eyes out with POAs and BOAs and excremental error checking. So you have to wrap it up in a GObject - ie you may as well forget defining an interface. And CORBA is fugly in any language.
* XPCOM - dunno, only used by mozilla atm... uses lots of ugly random numbers (UUIDs). Seems like a clone of MSCOM
* UNO - OpenOffices COM clone...
Either we pick one or really try to find an optimum. Hopefully ban the use of random numbers in source files (UUIDS), use domain strings instead.
Hopefully freedesktop.org or someone will try to standardise here - atm it is horrible.
You should be able to
* write a widget component and use it in a GTK, QT, Tk etc program.
* write a theme component and use it to control the look of any of these toolkits. - hopefully a better solution than duplicating or triplicating theme plugins.
* the whole ole shebang
* write non gui components and mix languages.
MS have had this working in a very ugly (on the source and implementation level) way for *ages*. Some of it is due to the level of control they exert, but we need to catch up.
This would be especially good because if we had a reasonable C mapping, people wouldn't be forced to use C to write infrastructure. Which isn't everybodys cup of tea.
None of this is new or clever, its just something that annoys me every now and then that no progress is being made.
Yeah yeah, I know, "show me the code" etc, etc.