Interesting discussion. A few ideas that have been recurring in my
search for (and, unlikely, creation of) holy grail of IDE, and have
been mentioned in this and other pyxides threads:
1. Functionality before GUI: the GUI should come second to the
application's functionality. Build the objects that provide
functionality, then create a nice GUI atop it. This has the
advantage that: A. different GUI can be built (or GUI can evolve
more than if the GUI influenced the encapsulation of
functionality); B. regression testing can be maximized to
maintain robustness throughout evolution; C. scripting the
application will be available almost "out of the box", allowing
for macros;
2. Modularized functionality: define the "services" that should be
available in IDE, THEN define an interface for each service, THEN
build components that satisfy those interfaces, THEN build the
glue that binds the services into an application. Implementations
of services can then easily be swapped in an out. E.g. a service
might be "provide documentation for a function": there are many
ways to do this, e.g. load the file and parse it yourself, or
import the file and get the __doc__, etc, each method has pros
and
cons and different users may prefer different ones. Each service
is like an input-process-output black box that the application
calls upon at the right time (e.g., when the user enters "("
after
some letters).
3. Modularized GUI: the GUI should be broken down into independent
pieces that communicate via pubsub-type messaging. This allows
for
more configurability, disabling unused/unwanted portions of GUI
to
keep things simple, etc. E.g. a "show function documentation for
a
function" GUI component would take the output of the "provide
documentation for a function" service (received e.g. via a
message) and show it in a pop-up box. Someone else could decide
to
create a different implementation of this GUI component which,
instead of a pop-up box, is a separate panel, and the user could
swap the default for this one.
4. Configurable menu/toolbar: the problem with many IDE's that
provide extension points is that the UI does not define where the
plugin's UI should go. E.g. I have seen editors/IDE where all
plugin menu items go in one "tools" menu. This rapidly becomes
unusable: plugins don't know about each other so they use names
that are sometimes similar and you end up not knowing what menu
item corresponds to which plugin, or the ordering of menu items
is
awkward/non-existent. When adding a plugin (which would provide
one or more services according to pre-defined interface), the
user
should be able to change the default menu items (name and
location
in menu hierarchy) that will be added for that plugin.
The major benefit of above is that it would allow progressive
implementation, and allow all contributors to provide something "their
way". It's really a pitty that so many IDE's exist isn't it: some are
very good, but they each miss something that the others provide or
have different bugs that are annoying, mostly because any given
developer has a finite amount of time to implement so much
functionality. So the goal must be to provide an architecture that
allows developers to combine efforts.
I'll see if I can go over the interface of a few IDE/editors and give
concrete examples of the above, that should show whether any of it
makes sense in practice :)
Oliver
[EMAIL PROTECTED] wrote:
>
>> However, in a little of the discussion I've since seen, I think the
>> problem is that a lot of folks want some pieces of what Emacs gives
>> them, but we all want different pieces.
>>
>
> Yes. I think of the problem as providing 'beans' for other people to
> use. Maybe pida has found a way to package those beans?
>
On Jan 2, 1:00 pm, Christopher Barker <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > This is intended as reply to Robin Dunn's excellent post:
>
> I loved that post -- it's almost as if he scanned my brain when writing it.
>
> However, in a little of the discussion I've since seen, I think the
> problem is that a lot of folks want some pieces of what Emacs gives
> them, but we all want different pieces.
>
> ...
