Re: [Wxdevide-devs] editor plugin and dialog

[Esteban A. B. <nab...@ya...>]

I think you have most of the right concepts, but you are missing the best way (in my opinion) of modeling objects that share functionality, especially in the case of plugins: using inheritance and method overriding. 

First you think of the MCD, all the common structures and methods required in the base class of the Editor (as you describe); then you define an abstract class with all these methods, from which the base Editor and all subsequent editors inherit. Then you add this class (and all other extendable classes of the IDE) to a package and deploy it as the wxDevIDE SDK.

Now, lets say you want to create an Editor that is specific to work with PHP code... you grab the SDK, inherit a class from Base Editor class, override the methods that you care about (let's say, the syntax highlighting method to make it PHP specific). So, the editor is not just a GUI static component to which you duck tape panels to add functionality... it is a polymorphic structure that can be actually expanded and specialized from the point of view of the code.

Of course, the IDE needs a plugin controller that knows about all the abstract classes, and instantiates them at run time at the appropriate places, and deals with the messaging, etc. So the IDE (through the plugin controller) only cares about an abstract editor… all editors are special cases, that happen to share most of their code with the base Editor (or none at all, if someone wants to define a completely new editor from the abstract class).

Remember that I have offered to work on this part of the code (the plugin controller) if you don't mind, I think I have some experience here that may come handy for the project. Of course, this part requires good communication and coordination with the rest of the code components (it's kind of a central point of the IDE), so it would be good to have good communication among us... that is, if you really want me to help here ;)



--- El mar 18-ago-09, Nuklear Zelph <nuk...@gm...> escribió:

> De: Nuklear Zelph <nuk...@gm...>
> Asunto: [Wxdevide-devs] editor plugin and dialog
> A: wxd...@li...
> Fecha: martes, 18 agosto, 2009, 9:43 pm
> i had an idea last night about the editor
> dialog. i keep thinking about it because that is mostly in
> my domain, so i will most likely be the one doing most of
> the work on it. (editor plugin i mean) if the editor dialog
> is built into the ide and make generic/realistic enough for
> most any decent editor solution, then all the extra editor
> specific stuff can be put in a different gui element. either
> a dialog that is brought up via a menu item added to the
> edit menu, or a notebook page that is appended to the editor
> dialog notebook. which solution should be dependant on
> developers preference and or the actual implementation. a
> few options can easily go into a notebook page, a more
> complicated thing or multiple panels should be in its own
> dialog. 
> 
> 
> then we determine what options should go in what of three
> categories:
> core
> gray (or optional)
> extended
> 
> extended is simply what is not in the other two.
> core is expected from any plugin anyone wants to add.
> syntax highlighting for example.
> 
> gray is an optional functionality, like line numbers and
> code folding.
> i think that cursor past eol, eof needs to go into extended
> if the editor supports it. to my knowledge, scintilla
> doesn't support it at all. 
> 
> 
> then dealing with the users settings, either:
> 
> *a structure with the core and gray settings is passed to
> the editor plugin when the user changes them so that the
> editor plugin can just deal with all of the settings
> itself.
> 
> 
> *or the same thing, but the ide deals with the settings,
> but this looks like a little worse solution because it will
> take more plugin bandwidth.
> 
> *or the settings are stored separately. 
> 
> 
> as an unrelated bit, my xp went to heck on me a couple
> weeks ago and some one stole my installer cd. so i had to
> find xs's xp1 on the Internet again to make a new one.
> what a chore. and finish up with my backup/housekeeping
> stuff. finally done, very glad its over. 
> 
> 
> just before i had that issue, i was working on XSTC, and i
> finally fixed an elusive bug in the configuration system. it
> kept crashing when it should not have been called at all.
> turns out i put the variable initializer below the config
> setup call in the constructor, all fixed yay! now i can get
> back to working on the next release of XSTC like i should
> have been doing this whole time. 
> 
> 
> i am also going to work on the editor plugin/dialog issue
> in a test program. i'll create a mock plugin system to
> develop the api and do some brainstorming. when the plugin
> documentation takes more form i will keep the mock up
> updated so the api is usable in the ide. that way the
> current editor stuff can be sorted out later when a good,
> ready to use editor is already built. it will make things
> easier to keep track of. and keep my editor api updated on
> the wiki.
> 
> 
> do i have any major errors in thinking about this or is it
> a good idea? opinions?
> 
> Nuklear
> 
> 
> -----Adjunto en línea a continuación-----
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal
> Reports 2008 30-Day 
> trial. Simplify your report design, integration and
> deployment - and focus on 
> what you do best, core application coding. Discover what's
> new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> -----Adjunto en línea a continuación-----
> 
> _______________________________________________
> Wxdevide-devs mailing list
> Wxd...@li...
> https://lists.sourceforge.net/lists/listinfo/wxdevide-devs
> 

__________________________________________________
Correo Yahoo!
Espacio para todos tus mensajes, antivirus y antispam ¡gratis! 
Regístrate ya - http://correo.espanol.yahoo.com/