I am new to Python and wxWidgets and have only recently finished my first project. I chose DrPython because it worked in the way I program, i.e, Edit and Run. Although it works quite well I find that there are a lot of bugs. They are generally not very serious but they are annoying nevertheless.

I would suggest that there should be a spcial effort to identiify and record the bugs and then make a systematic effort to solve them.

It would help when submitting patches if the CVS tree was not 8 or more months out of date. If it were kept up-to-date it would be possible to see where work was being done. Also, none of the bugs appear to be allocated to any of the developers.

Also the documentation does not appear to have been updated for the new features. I am not clear why it is thought that only experienced users need a Find and Replace feature. I don't understand what the Import All button is for.

There is a difficulty in setting up suitable options particularly since there is no context-sensitive help. For example, the first time I ran version 161 on Linux it complained that it could not find /rubbish! It would be a great help to new users if there were an install wizard to help define a basic set of preferences.

you have some good observations there cthoday.  Lots of things wrong with the DrPython project.  the good thing is, now that you know what's wrong, you know where to start helping!  That's how open-source works.  It can only be free if everyone helps.  Otherwise, you can always follow the commercial model, where you pay big $$.  How about $295 for the Wing editor instead of $00 (or suitable donation) for DrPython?

cheers
S

you have some good observations there cthoday.  Lots of things wrong with the DrPython project.  the good thing is, now that you know what's wrong, you know where to start helping!  That's how open-source works.  It can only be free if everyone helps.  Otherwise, you can always follow the commercial model, where you pay big $$.  How about $295 for the Wing editor instead of $00 (or suitable donation) for DrPython?

cheers
S

>Although it works quite well I find that there are
>a lot of bugs. They are generally not very serious
>but they are annoying nevertheless.

You are certainly right, so please report all bugs
ideally with possible fixes.

I think, Dan is very busy, and it is a pity, that
the development/make a stable release is slowed down.

I remember considering him, to recommence the cvs
repository and allow write access to cvs to other
people, because of his lack of time.

>I am not clear why it is thought that only >experienced users need a Find and Replace feature

This I don't understand; you mean the beginner and the advanced mode? If so, you are right, that means
I don't understand it either; it should be put into beginners mode also.
Anyway, I don't like the new distinction between this two modes; it was introduced in Version 161.

The import all (I never used it, but in the source comment, ther stands)
"""When the Import All button is clicked, get the path of each open file, and append it to sys.path, then import each file into the interpreter        (via ExecuteCommands)"""

It must have something to do, if you want to run
the current source file, I suspect.

Yes the documentation is also behind the schedule.

For the installation: the default option should
fit to most users;
yes a context sensitive help would be great, but
also not to less work.
You would like to do? ;)

I hope, if Dan has no time, he will open cvs;
otherwise, I fear, the project will fade away.

In answer to midtoad I would say that it would be a pity if people who use free software were discouraged to send in fault reports because they should not complain about something that is free.

On the contrary, I would suggest that users of open source software have an obligation to try to make it better. Not everyone has the time or resources to develop the software but everyone can send in fault reports and suggested improvements. The great idea behind open source is that "many eyes can squash the bugs" which individuals, however tallented, can not.

If I have learned anything from my experience of programming computers (over 45 years) it is that it is very difficult for the developer to see faults in his or her own work. Also it is very difficult to see things from the point of view of a new user.

There are quite a lot of downloads of DrPython every day but I wonder how many users give up when it does not seem to work properly.

Perhaps some of the 11 developers could undertake a *systematic* review of the source code. I have send in some patches that I hope somebody will review. I have ideas for many more patches but cannot promise when they will be ready. The most recent one involves improvements to the run command.

P.S. The latest news on the home page is dated 2005-2-10 and relates to DrPython 3.10.0!

Christopher, I certainly agree with your statement that people should be encouraged to send in bug reports.  But I'm more encouraged by the fact that you have some solutions to bring forward as well.  The lead developer on this project does not have as much time available as would like, so as users we have to help move the project forward.   I've contributed one small enhancement already. 

cheers
S

>In answer to midtoad I would say that it would be a
>pity if people who use free software were
>discouraged to send in fault reports because they
>should not complain about something that is free.

Christopher:

I don't think, this is so much the case.
It is rather, many bug reports are not answered or
commented in the last time, so this is, why
people are discouraged.

>If I have learned anything from my experience of
>programming computers (over 45 years) it is that
>it is very difficult for the developer to see
>faults in his or her own work.

This is quite true ;)
You program over 45 years? <confused> ;)

>Also it is very difficult to see things from the
>point of view of a new user.

This I share partly. People, who want to use or interested in DrPython, have background knowledge
of programming, so I think, you cannot compare
them, for example to MS-Word users.

The last version 1.61 was downloaded over 2000 times in six weeks, and from my point of view,
that is a sign of success.

>There are quite a lot of downloads of DrPython
>every day but I wonder how many users give up
>when it does not seem to work properly.

ACK.

From these 11 Developers, at least 6 or 7, I never
heard anything or cannot remember contributing
much.

So what can be done?
I don't think, anyone is interested to review the
whole sources at once;
so bit by bit, the code could be improved; especially you encounter a bug.

What I'm interested.
For example you and Stewart: Do you use/created
some scripts.
What plugins did you download and you think,
is useful and use them more often.
Did you (try to) create a new one?
What ideas do you have?

In what direction should DrPython go?
a slim editor (environment) or rather more comprehensive editor? supporting more languages.

I for me use them mainly for C++ coding in my company, if you believe it or not.
I've written a bunch of plugins and scripts
to accomodate my needs.

If Dan reads this:
maybe he will open CVS or offer some other way
to further develope DrPython.

Just my 2 Cents,

Franz

Franz, the only thing I contributed was the "File > Save a Copy" method.

About where DrPython should go, this is ultimately up to the developers, but I'm quite happy with DrPython as it sits right now.  I don't need more and more functionality.  the only thing I'd like is for it to start up quicker, but that might be due to wxPython.

for those who are interested in an alternative to DrPython, check out NewEdit, available from http://cheeseshop.python.org or http://wiki.woodpecker.org.cn/moin/NewEdit

S

>Franz, the only thing I contributed was the "File >
>Save a Copy" method.

No reproach; What I find a pity is that the common
interest in DrPython slowed down.

I also find, the functionality of the "core" DrPython is enough in the main.

Anyway there is a great potential to enrich it
with plugins.
The startup thing: Dan has examined it already
thoroughly; yes, the problem is certainly due to
wxPython and/or the scintilla stc binding.

I know newedit and I don't like it.
No reasonable documentation (except in chinese language), and I find it more or less a (not good) copy of DrPython.

Some things are solved better and the coding style
is also good.

The developer of new edit limodou is also listed
in the project members.

>So what can be done?
>I don't think, anyone is interested to review the
>whole sources at once; 
>so bit by bit, the code could be improved; >especially you encounter a bug.

I imagine that, from a computer science point of view, developing new projects is much more interesting than going over old code. There are many features that could be added to DrPython that would benefit from being developed first as separate small projects.

However, I would put in a plea for source code review:

o You can learn a lot from reading other people's code (both what to do and what not to do).

o It is often easier to see bugs in other poeople's code than in your own.

o It is very rewarding to be able to make significant improvements with little effort.

o It is a fundamental software engineering technique that, if more widely practiced, would greatly improve the quality code delivered to users.

Couple things:
I think the beginner/advanced mode needs to be rethought, or reworded.  Beginner in this case was imagined as a new comp sci student, potentially someone who has never programmed before.  Although I do wonder about keeping things TOO simple, and am more than willing to move some stuff from advanced over into beginner.

CVS does need to be updated.  I will try to do this within the week.

Systemic Review.... If I only had the time!  (Which is why this should be community rather than "lead developer" run).  Yes, this is very much needed.  Have you looked at drpython.py?  Its thousands of lines of code!  In python, no less!  There are methods that span hundres of lines and serve only to set up vast hordes of constants, or build menus.  It is beyond ugly.  It may take just a bit of work to rework all of it.

The more complaints, the better the software ;)

I have often thought about taking the core functionality of drpython as concepts, and rewriting something new.  That always seems to produce vaporware though (although enlightenment 17 is getting pretty close, and I cannot wait to play with the new set of widgets).

Reading other people's code can make you want to curl up into a fetal ball.  No.  Seriously.  I am sure there are parts of drpython that, to the uninitiated, might seem quite mad.  Possibly because those sections are indeed "quirky".

Perhaps the solution would be to let the community work on the current core, and work on drVapor privately until I get something resembling an actual product?

If I were to start from scratch, the design would be slightly better (going from a junior in college who had just learned python to a professional developer who has designed and implemented a few software products).  The question is which approach would take the least amount of time, and have the best value.

But yes, I definitely plan on opening up CVS.  (Or putting to code on some svn hosted site...)

Hi Dan,

glad to hear from you.

Thank you for offer to open CVS.

What do you mean by drVapor?

Cheers,

Hey Franz,

Very much likewise.

I think I am going to go with Eur Ing Christopher Thoday's idea and plop this up on BerliOS for svn access.

By drVapor I jokingly mean drPython 4.0.  I am writing it from scratch  (I've already started, who know how long it could take, hence the nickname).  At the moment I have menus, instead of being a large number of lines of static wx.Menu.AddYadda calls, is a small file that loads menus dynamically from menubar.xml.  I am planning on doing this for as much as possible (plugins, shortcuts, etc).  The next big task for me is figuring out how I want to do the basic interface, which has always been a headache and a messy solution in my mind, while preserving the basic layout.

Hi Dan,

these are good news.

>I am writing it from scratch...
Really; whew, lot of work (?).

For the menu stuff, E.A.Tacao maybe wrote something useful (Metamenus).

http://j.domaindlx.com/elements28/wxpython/Metamenus.html

Dan,

Just wanted to add my two cents on what I find so good about DrPython.  I've been looking for a simple IDE that gets out of my way and supports a quick edit/run/test cycle, and has good core functionality without tons of crap to learn.  Add to that the ability to easily extend and tweak almost anything using scripts or plugins... and well you have DrPython.

As far as functionality, DrPython is pretty much spot on, anything more than that and it usually just gets in the way.  Things like debugging, extra search abilities, code completion, etc work great as plugins and I hope they stay that way.

I also agree that for the most part, current DrPython developement really only needs to focus on bugs/issues and minor enhancements.  Hopefully the svn access will help with outside contributions.

Perhaps the best enhancement you can make to DrPython is like you said, easier to maintain format for plugin, shortcuts, menus and the GUI layout, so I definately think you are on the right track. 

For the GUI, the layout and simplicity of the current DrPython is great, as you know the flexibity to extend or modify it is... uh messy :).  A rework of some of the assumptions of what is in notebook (i.e. only prompts in the prompt notebook etc) is all that really seems needed to solve the notebook problems.

Not much useful information there, but I hope that I can just confirm that the origional ideas behind DrPython are sound and that even with a major rewrite I hope you are able to keep to the simplicity that makes DrPython truely useful.

Brandon

Brandon,

Thanks.  Nice to know you find drpy functionality spot on.  I do plan on keeping it simple, and if anything moving unecessary parts out of the core (like downloading plugins from sf), or doing needed ui tweaks like having dynamic drscript exist as a prompt that is "hooked into" the current process", and appears as just another prompt (with visual cues to let you know it ain't).

And with the format, maintanable code.  The current code can be hacked on, but the same can be said for just about any piece of code out there.

Changing what can and can't go into a given panel is a priority (as this also means changing how they function internally).

Actually, I had been thinking of letting users put the prompt panel where they want to, but then again, perhaps just having every panel contain notebook, and letting each plugin or function create pages that can be added to any notebook would be a nicer way to go about this.  Imagine being able to tell prompts to just open as if they were a new document.  (I actually do this now in a small plugin I wrote for vim that turns a new scratch buffer into a python prompt.  I find when testing I want the full screen effect).  This solves another problem, which was whether or not to allow side panels of any kind to be brought to 100% in any fashion (as you currently can).  I think disabling this (and having 100% only exist for the central panel) might be a good idea, and mixing pages would allow 100% prompts without interfering.  (Of course, allowing some kind of way to toggle 100% via keyboards or whatever mightbe fine, just not via the sash.  I might change my mind on this aspect).

:)  Quite useful.

Here is what I am aiming for with drpython 4:

Stable:  DrPy should just work.  Period.
Simple:  Whether using or extending DrPy, your intuition and a few simple rules should be able to guide you.
Functional:  You should be able to do neat and useful stuff with drpython (even some things that you can't do anywhere else.)
Fast:  As much as possible, DrPy code should be fast.  (This will be accomplished by keeping the codebase small, modular, and using various nifty py optimizations tricks).
Maintainable:   Looking under the hood should be a pleasant experience.
Customizable:  You should be able to change everything about drpython with as little effort as possible.
Sweet Sweet Candy:  DrPy should look nice.  (Icons, design, etc).

Dan

Well, yes, writing it from scratch will be, but the current code is not very maintanable, especially if you don't have all the time in the world.

I actually already have the menu stuff working (The code is simple in the kind of way that makes you wonder why you didn't think of it before).