wiki:PadreNextGen

Version 7 (modified by azawawi, 2 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".

So again,

Document events

  • on_create, on_destroy
  • on_focus, on_unfocus
  • on_key_up
  • on_key_down
  • on_char
  • on_left_up/on_left_down
  • on_right_up/on_right_down
  • ...

Padre Menu API

  • add
  • replace
  • delete
  • on_menu_click
  • before_on_menu_click
  • after_on_menu_click

hmmm, Method modifiers

$self->$main->$event_manager->register_event('.*x-perl', 'event_name');

TODO

  • Remove the concept of user levels (i.e. beginner mode)

Why Padre needs Moose or something like it

[WhyPadreNeedsMoose]

Usability propositions (Highest priority first)

  • Follow common guidelines. Read and memorize your favorite platform's user interface guidelines, and follow them as closely as possible in your application. Worst case scenario, they'll prevent "spurious" bug reports from "annoying" users. Best case scenario, your app will actually benefit of tried and true ideas, embodied in your platform's UI, and embedded in your users' brains. And you'll learn a new thing or two about usability.
  • Autoconfig. Make your application deduce configuration, instead of relying on the user to provide that information for you. Go the extra mile and write the "detection" code to enable this.
  • Simplify. Dump unnecessary configuration options.
  • Copy ideas. Steal ideas used in other popular — and similar — applications. Pay attention to the details. Often, the small details embedded in a user interface teature (very consisten behavior, pixel-perfect accuracy) win unsung praise from their users, and keep them loyal.
  • Refactor. Run a quick survey on your user inteface among your closest friends, and ask them if they understand, and if they don't, what don't they understand. Then propose new UI layouts.
  • Divide and conquer. If your application does too much in a single user interface, split your UI in more manageable parts. Whether you do two apps that meet via named pipes or databases on disk, or you do a single app with two windows, it's up to you. Just be consistent and stick to your strategy.
  • Make your app work using "contexts" or "activity centers". That way, you can show and keep tightly related options, functionality and UI controls together.

Conclusion

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.

References

Why User Levels are Bad Usability