Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I have been extremely busy. My temp-to-perm job just went perm. I am now gainfully employed! Woot!
I've been working super long hours, and I am moving soon (hopefully), so I just haven't had time to work on drpy.
What remains is copyright info for two images (which will be replaced if I can't find it), and changelog info.
The initial release is unstable. The debugger still has major bugs, and as such, will be shortly moved out of the core and into a plugin. However the debugger, and searchinfiles, and codecompletion, will be included as "default plugins".
The code reorganization will be gradual, and less sweeping than originally intended. I still plan on drastically reducing the size of drpython.py, and making things more modular.
I also plan on removing the built in plugin downloader, as in practice, it is not very dependable (given sf file availability).
The first changes planned will be default plugins (eventually a proper installer will exist), the new file dialog, and new search.
I also plan on heavily attacking drscripts, as there are quite a few bugs therein.
The menu will also need to be reorganized to account for new items, and there will be a Prompts menu to complement the Documents menu.
And bugfixes, of course.
However I am planning on delaying wxpython platform specific bugs (eg the combobox is twitching like crazy, or a particular platform producing reliable segfaults).
The wxPython folks are putting out releases faster and faster, and 2.6.x is starting to stabilize quite nicely.
Of course any of this may change (all it takes is a proper argument).
Further on, I plan on drastically simplifying some preferences. Styles are way too complex. I think font size and font type, as well as indentation type and tab width, should be universal across file types. It is just too confusing to switch this for every single bit.
I also want to build on the beginner/expert mode, as this is really an excellent framework for adding advanced features in that might confuse new students.
That's about it for the moment.
Congratulation for your success in your job!
I have some thoughts for the code completition plugin.
(I also created a wxpython wiki page for it).
You know Visual Assist?
they have some powerful functions for code completition and callips or Intellisense.
(icons, inherited and non inherited methods, dynamic elimination while typing, ...)
that would require, i think, to quit using stc Autocompletition methods and create a new, more flexible one.
As for the debugger: I can imagine, that this huge project
of course have many initial bugs.
Hm, the plugin loader is a fine thing for first users of DrPython, although I never used it. Will you toss it?
I sf is not available, there could be a message.
I sf is not available, plugins coudn't be downloaded anyway.
Will you remove the old find dialog? I hope not ;)
(I for me don't like a find like the Firefox one.)
What is the new file dialog? Do you want to change
the DrPython File Open/Save Dialog drastically?
>I think font size and font type, as well as indentation
>type and tab width, should be universal across file
>types. It is just too confusing to switch this for every
I would find it a pity. This was a big progress.
I edit cpp, txt and python files, and it is very convenient,
to "overwrite" the default tab, indent, line ending settings.
I hope, you don't make to much changes in the internal
methods/variables, so plugins don't need to be reworked ;)
I am planning on more modest changes, when I get back to drpy dev.
I am simply too busy at the moment with life, my job, and everything.
Although I do feel a bit of pride in having my very own vaporware ;). Kind of like when I wrote a scheme program that accomplished in mere days what other students took whole minutes to do.
I think Franz's observations about the level of customization were right on. I do think the currently prefs afre too complex for novices, and simply need to strike a balance between flexibility and simplicity.
I do think the old find dialog is a mess however. Firefox find is just so much better! I do plan on doing this in a way that will allow for a find dialog to easily exist as a plugin however.
I am more and more inclined to toss the plugin loader. I never use it either, and cutting down on code/stuff to maintain, etc, seems quite attractive to me.
The new file dialog would not be so drastic, just a bit simpler (one location bar is pretty much the gist of it).
In terms of internal stuff, I am no longer aiming at a grand rewrite. I am too lazy/busy. I think reducoing the size of drpython.py, and gradually becoming more modular is a good goal, but no grand designs.
So the current inconsistent naming will likely stay in place. Hooray for lazyness.
yes, the preferences could be confusing.
Therefore I like the "beginner" mode for new users.
Sometimes the find isn't working.
I cannot duplicate it exactly: somehow search => move cursor, then search again or search the other direction then. (was forward, then search backward).
It finds nothing then (until you fire up find dialog again).
I also never used the plugin loader, but what about keeping or making it itself plugin later (a default plugin)?
But not so important.
I find it only so elegant to see the plugin downloading
and installing themself :-)
I agree with the not rewriting. It costs to much time/effort,
and I favour also a rewrite, when it is appropriate.
I use DrPython for all my editing lol :)
Actually not too far from the truth.
I use it for python and C/C++
Most of the C/C++ stuff I do is boost python modules.
I have been using DrPython for last few months under wxpython '22.214.171.124' with no probs except for the last one to do with the folding.
I am not sure if that is a DrPython problem or a linux problem. Anyway happy to see things are working out for you :)
I recently discovered the very nice combination of rpdb2 and it's wxpython GUI Winpdb: http://www.digitalpeers.com/pythondebugger/
I was wondering if perhaps it would be easier to reuse these components within DrPy than from scratch implementing DrPy's debugger. Just a thought.