Re: modal dialogs etc.

[Jody Goldberg <jgoldberg home com>]

On Fri, Oct 05, 2001 at 03:55:06PM +0100, Nick Lamb wrote:
> Yes, it sucks, yes I've explained before that modality is not the Unix
> way, I was told it's not getting fixed NOW because although no-one
> on the Gnumeric project is afraid of inserting massive overkill like a
> complete remotable object system with CORBA to draw graphs, they are
> scared like small children of asynchronous interaction with the user,
> so most things will remain modal at least until Gnumeric 1.0 is finally
> branched from HEAD.

Ouch ! That stings.  It made me drop my teddy bear and run crying
like 'a small child' to my mommy.

I'll address several points here.

1) Gnumeric's dialogs are quickly transitioning to pseudo modal.
   We do not want full fledged modal dialogs.  They are indefensibly
   broken.  Having a fully modal dialog in one workbook disables
   editing in another.  However, there are very good reasons for
   disabling arbitrary operations on a workbook while it is being
   edited.  It boils down to a question of complexity.  If every
   operation can occur simultaneously the number of potential
   interactions is huge and very difficult to debug.  Over time some
   operations can become non-modal, but the cost of implementation
   is much higher and the added benefit relatively small.

2) The core of Gnumeric is small and clean.  The prospect of
   writing a full fledged graphing module and maintaing that code
   is uninviting.  Other people are working on that, lets not
   reinvent things.  CORBA is not trivial, but it is a reasonable
   tool for combining multiple applications.  The amount of code
   required is small, localised, and it is maintainable.  What are
   the alternatives.
    - Link in more shared libraries.  Frankly we have enough
      complaints already from people having trouble building/running
      Gnumeric that can't get the right set of libs.  Look at how
      many people complain about Gnucash.  They did the right thing
      and reused code, and are still pilloried. Allowing the graphs
      to be in a distinct process if desired makes life easier.

    - pipes to another app.  Sure, lets invent yet another
      rpc/activation mechanism.

3) 'modality is not the Unix way'
    Gnumeric has little if any interest in an arbitrary 'way'.  For
    every zealot with one belief there is another with opposing
    views.  Our goal is to produce a spreadsheet that can be used in
    production.  To produce it very fast, and with minimal resources.
    To quote from the HACKING file

           When writing Gnumeric our priorities are
                1) Correctness.
                2) Maintainable & Documented
                3) Modular and well designed
                and a distant
                4) Fast

    Note that there is no mention of adhering to 'a way' in there.
    Once you start tacking on extra requirements like Completeness
    resources are strained.  If I can use a design pattern that
    replaces a factorial problem with something linear I will use it
    in a heartbeat.  Later when there are more resources we can
    address the possibility of doing the extra work.

> the Gnumeric project is afraid 
...
> they are scared like small children
...
> we have to wait for whatever those who do have resources dedicated
> to Gnumeric decide to give us.
Civility is a virtue.  Please watch your tone.  Feel free to
contribute and you'll get more of a say in our priorities.