Slashdot Mirror

← Back to Stories (view on slashdot.org)

The People Behind Quanta Plus

Posted by michael on from the quanta-is-nifty dept.

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)."

5 of 137 comments (clear)

  1. Next generation in bad UI design maybe by Molz · · Score: 5, Insightful

    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?
    1. Re:Next generation in bad UI design maybe by Anonymous Coward · · Score: 1, Insightful

      Ah, the bright lights of adolescence on /. Did you note that this dialog is not available for download and is for the author's personal use, given only as an example? I guess not.

      I think a basic reading primer is needed for some before they review what they know absolutely nothing about and thus are not qualified to review.

  2. Re:Nice timing.. by gnugnugnu · · Score: 2, Insightful


    Please do carefully think about the problems you had. Even if they were due to inexperience they may well provide you with an insight on how the interface could be imporved.

    Self awareness and careful analysis will allow you to do useful research in the area of Human Computer Interaction without the need for any specialised knowledge or equipment (although reading up on the on Usability and HCI should help you distill the issues you are having and help you write clear and constructive criticism).

    Good luck.

  3. The real killer app... by listen · · Score: 4, Insightful

    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.

    1. Re:The real killer app... by listen · · Score: 3, Insightful

      Is it really rational to expect people to go through a VM layer for the base case? Ie linking together two native code components? Nobody is going to do this on windows, we are going to be stuck with the elegant lump of ugliness that is COM for quite a while in win32 land.
      I've looked at mono and I use .NET on windows, and it is a nice system. Java revisited effectively, and a slightly better VM design. I wish you well, but currently I don't get how this is going to help replace shared library plugins without sacrificing a LOT of performance.
      But maybe I'm entirely mistaken and you do have a simple way for people to avoid the VM layer entirely? This would be killer if we could just use the .NET type system... those are a pain to specify...and if you could pass through marshalling etc when its unneeded that would be great.