|Version 6 (modified by azawawi, 3 years ago) (diff)|
Padre the Next Generation IDE
I wanted to share my thoughts about how we can drive Padre in 2012. I know that we have been adding feature after feature to Padre core lately and bloat seems inevitable. You will notice how Adam cleverly added the features tab in preferences to keep the Padre startup and runtime memory cost at a minimum. However as Padre matures, we need to move into a more plugin-based architecture. Each Padre release has been growing bigger and bigger. For example:
- Padre 0.94 => 1.78 MB (~ 2 months ago)
- Padre 0.92 => 1.74 MB
- Padre 0.90 => 1.61 MB
- Padre 0.84 => 1.53 MB (~ a year ago)
WARNING: FULL OF COMPLAINTS
Lately when I joined back padre development after a full gaming season full of headshots, I wanted to relax a little and use what we have built in Padre as a platform to build upon. I wanted to learn Moose so much along with its friends Mouse and MooseX::Declare and lately PDL. I noticed after developing Moose and the initial PDL support that we lack a proper event manager. We currently rely on the wxWidgets API or what Padre::Wx::Editor currently fires back through the document subclass for keyboard, focus and mouse events. However, they are not complete in their approach. To be able to work *as a plugin* on a padre document with the Perl mimetype (i.e. application/x-perl), you need to provide registered_documents in your Padre::Plugin subclass. Cool, but what about when i have two or more plugins that need to work on the same Perl document with different syntactic sugar and keyword highlighting and event management. Padre should provide a way to choose which one to activate on the current content via a list like "View / Perl 5| Perl 6|HTML|...etc".
- on_create, on_destroy
- on_focus, on_unfocus
Padre Menu API
hmmm, Method modifiers
- Remove the concept of user levels (i.e. beginner mode)
Why Padre needs Moose or something like it
How about we fix Padre to be minimal and move some of the functionality or unused features outside of Padre core. We should start working on well-thought-out plugin API that truly allows plugins to modify Padre behavior in every way possible.