Re: Discussion: 2 many IDE's...donīt we want more?!

On 2/28/06, Daniel Pozmanter <drpythonbluebottle.com> wrote:
> I've been reading through the list, and there are a
lot of very good
> ideas
> being put forth.  And a few points to consider.
>
> While I know from experience and observation the
problems of starting
> from scratch, I am heavily in favor of doing so.
> What we are aiming for seems to be a functional core,
and a ui
> abstraction layer that can plug in to multiple
toolkits.  This is
> rather different from most of the editors currently out
there, and
> hence this alone merits a rewrite.  We also gain a lot
by starting
> with a simple core.  The trick is, as always, staying
simple in both
> the code and the interface.
> This is not to say that we throw code away, but rather
start with a
> clean new house, and bring the couch, tv, fridge, etc
in as needed,
> and get new appliances where applicable.  I'n sure
there are parts of
> spe, drpy, eric3, etc that we can bring aboard in bits
and/or pieces.
>
> In terms of multi language support, I'd suggest have
an architecture
> that will support this, but not being overly concerned
at first.
> However, it seems like c/c++ is a good next step on
account of
> extensions and all.  I think we should try to get this
project to a
> point where it supports python as well as eclipse
supports java.
I agree completely. We don't want the bloated side of
ecclipse but
something as flexible as eclipse or emacs is desirable.
Python could
be for the editor what lisp is for emacs.

> I think starting soon is a very good idea.  Let's pick
a *working*
> editor/ide name.   I say working because the name is
very important,
> but we need to get started.  I'd suggest hosting this
initially at
> berlios, or anyplace solid/established that supports
svn, forums,
> etc.  Perhaps the UnifiedPythonEditor project, or some
such.
> Something that does not currently show up in google,
yet is sensible,
> and direct.
I would prefer a name with not explicitly python in it. I
don't want
to waste time with choosing or debating the name. After all
this will
be the name of the core. People will be able to write their
own front
ends and name them whatever they want. I googled for pyde
and it was
taken already for another editor. As such it has a lot of
hits.
Then I thought of
pydea (still a lot of google hits)
pydeal (Python YDE for All Languages or something, this is
just an
excuse. Of course it also contains "ideal"
etc..., only 5 google
hits.)
If no one comes up with something better I'll register it.
We can move
the discussion there. I also agree to do research about
existing
frameworks. So we can move the discussion over there. All
the basic
know-how for an IDE is already there and will be brought in
by the
various IDE developpers which can be optimized. This will go
really
fast. Finding a good framework, generic parser, etc... is
more
important. To avoid the sluggyness of ecclipse the framework
should be
very lazy.

> License:  Might I humbly suggest lgpl?
I'm also for a very free license.

Stani

--
http://pythonide.stani.be
http://pythonid
e.stani.be/screenshots
htt
p://pythonide.stani.be/manual/html/manual.html

------------------------------------------------------------
---------
To unsubscribe, e-mail: wxPython-users-unsubscribelists.wxwidgets.org
For additional commands, e-mail: wxPython-users-helplists.wxwidgets.org

I've been following this discussion with interest and here
are a couple of
points I'd like to make, it seems they might be in the
background of some
posts: 

Basic principle: taken from agile development: start small
and get users in
early, then extend: 

   - determine what is the first and second
"round" of functionality
desired, create a design that will allow for extensibility

   - implement minimal set of first round functionality that
will allow
"early adopters" to use immediately, so users
can provide immediate
"testing" and feedback of the usability (avoids
stories like winamp etc)

   - for features that would take too long to create to
satisfy above goals,
create an abstraction layer (doesn't need to be complex,
often it's just one
class that defines an interface), and plug in an existing
component (e.g.
for a debugger, winpdb or whatever it's called); then when
things have
stabilized start designing the "in house"
replacement and discard the first
generation component; note that the goal of the temporary
measure is to
satisfy immediate needs for a given functionality, not to
provide all
desired functionality

   - don't try to design the universe; the more
"all-encompassing" something
is, the higher the level of abstraction must be, the more
abstract the UI
becomes, and more difficult it is to learn to use the
application. Example:
Eclipse; it's so generic it becomes difficult to learn.
Also, the more you
try to pack in a bag, the more bloated the bag, the harder
it is to carry
and to put more in, etc. Also, our seasons tires tend not to
be as good as
summer tires and winter tires separately (people who live in
places where
there is snow will relate 

Oliver


> -----Original Message-----
> From: SPE Stani's Python Editor
[mailto:spe.stani.begmail.com] 
> Sent: February 28, 2006 4:06 AM
> To: Daniel Pozmanter
> Cc: franz.steinhaeuslergmx.at; limodou; Josiah
Carlson; 
> Kevin Altis; riaane.co.za; kaworu; Ed Leafe; Matt Fryer; 
> wxPython-userslists.wxwidgets.org; Detlev Offenbach;
Michael 
> McLay; kbkshore.net; noamraphgmail.com; Paul McNett
> Subject: [wxPython-users] Re: Discussion: 2 many 
> IDE's...donīt we want more?!
> 
> On 2/28/06, Daniel Pozmanter <drpythonbluebottle.com> wrote:
> > I've been reading through the list, and there are
a lot of 
> very good 
> > ideas being put forth.  And a few points to
consider.
> >
> > While I know from experience and observation the
problems 
> of starting 
> > from scratch, I am heavily in favor of doing so.
> > What we are aiming for seems to be a functional
core, and a ui 
> > abstraction layer that can plug in to multiple
toolkits.  This is 
> > rather different from most of the editors
currently out there, and 
> > hence this alone merits a rewrite.  We also gain a
lot by starting 
> > with a simple core.  The trick is, as always,
staying 
> simple in both 
> > the code and the interface.
> > This is not to say that we throw code away, but
rather start with a 
> > clean new house, and bring the couch, tv, fridge,
etc in as needed, 
> > and get new appliances where applicable.  I'n
sure there 
> are parts of 
> > spe, drpy, eric3, etc that we can bring aboard in
bits 
> and/or pieces.
> >
> > In terms of multi language support, I'd suggest
have an 
> architecture 
> > that will support this, but not being overly
concerned at first.
> > However, it seems like c/c++ is a good next step
on account of 
> > extensions and all.  I think we should try to get
this project to a 
> > point where it supports python as well as eclipse
supports java.
> I agree completely. We don't want the bloated side of 
> ecclipse but something as flexible as eclipse or emacs
is 
> desirable. Python could be for the editor what lisp is
for emacs.
> 
> > I think starting soon is a very good idea.  Let's
pick a *working*
> > editor/ide name.   I say working because the name
is very important,
> > but we need to get started.  I'd suggest hosting
this initially at 
> > berlios, or anyplace solid/established that
supports svn, 
> forums, etc.  
> > Perhaps the UnifiedPythonEditor project, or some
such.
> > Something that does not currently show up in
google, yet is 
> sensible, 
> > and direct.
> I would prefer a name with not explicitly python in it.
I 
> don't want to waste time with choosing or debating the
name. 
> After all this will be the name of the core. People
will be 
> able to write their own front ends and name them
whatever 
> they want. I googled for pyde and it was taken already
for 
> another editor. As such it has a lot of hits.
> Then I thought of
> pydea (still a lot of google hits)
> pydeal (Python YDE for All Languages or something, this
is 
> just an excuse. Of course it also contains
"ideal" etc..., 
> only 5 google
> hits.)
> If no one comes up with something better I'll register
it. We 
> can move the discussion there. I also agree to do
research 
> about existing frameworks. So we can move the
discussion over 
> there. All the basic know-how for an IDE is already
there and 
> will be brought in by the various IDE developpers which
can 
> be optimized. This will go really fast. Finding a good 
> framework, generic parser, etc... is more important. To
avoid 
> the sluggyness of ecclipse the framework should be very
lazy.
> 
> > License:  Might I humbly suggest lgpl?
> I'm also for a very free license.
> 
> Stani
> 
> --
> http://pythonide.stani.be
> http://pythonid
e.stani.be/screenshots
> htt
p://pythonide.stani.be/manual/html/manual.html
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: wxPython-users-unsubscribelists.wxwidgets.org
> For additional commands, e-mail: 
> wxPython-users-helplists.wxwidgets.org
> 
> 
> 



------------------------------------------------------------
---------
To unsubscribe, e-mail: wxPython-users-unsubscribelists.wxwidgets.org
For additional commands, e-mail: wxPython-users-helplists.wxwidgets.org