Re: Apologies to gnome-gui if I ever said you guys were flamers...

["Jesse D. Sightler" <jsight pair com>]

-----Original Message-----
From: Dan "Effugas" Kaminsky <effugas@best.com>
To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
Date: Tuesday, August 18, 1998 9:48 PM
Subject: Re: Apologies to gnome-gui if I ever said you guys were flamers...


>
>-----Original Message-----
>From: Elliot Lee <sopwith@redhat.com>
>To: gnome-gui-list@gnome.org <gnome-gui-list@gnome.org>
>Date: Tuesday, August 18, 1998 6:31 PM
>Subject: Re: Apologies to gnome-gui if I ever said you guys were flamers...
>
>
>>I don't think anyone told you you weren't "supposed to" write proposals.
>>You are free to to write proposals.
>
>Elliot:  I'm sorry, please read slashdot, you're wrong, it's totally clear
>I'm being told not to write proposals.


Actually, that is not the case.  What they want is proof that what you are
proposing is truly a practical, consistent, and easy to use thing.  For
example, your proposal seems to jump around from one application to the next
quite frequently, and very frequently the types of "cluehunting" for each
application varies drastically between the applications.  In some cases it
even varies so widely that they two applications of your technique could not
share the same "keyword databases", and in some cases they couldn't even
share the same implementation code.

What would be better from a simplicity standpoint would be for you to split
the proposal into several proposals for those different contexts.  For
example, you could include a "editor" context that would explain the
standard database that all editors (word processors, text editors, HTML
editors, etc.) would share.  This would probably be best if it were a
complete proposal by itself.

After that you could perhaps develop a "dialog context" proposal that would
explain a generic manner in which cluehunting would work in application
dialog boxes.  The thing about this is that in many cases this "dialog
context" would not share keyword databases with other applications that also
happen to use dialogs.

I guess what I am really trying to get at is that what you have proposed is
not really a proposal at all, but a collection of ideas that would have to
be implemented in different ways for each application in order to be useful.
This gives programmers headaches.  :)  On the other hand, if you break the
problem up into successively smaller parts (and therefore separate
proposals) it is much easier on the coders.

And it should be, as breaking problems up into smaller and smaller parts is
essentially what programming is.  And until you can break your description
down to the level where you have two or three very concise and clear
descriptions of the exact process that takes place, you have not explained
adequately.

Hope some of that makes sense to ya,

--------------------
Jesse D. Sightler
http://www3.pair.com/jsight/