https://sourceforge.net/p/wxdevide/wiki/EditorApi/Recent changes to EditorApienFri, 10 Aug 2012 05:16:32 -0000https://sourceforge.net/p/wxdevide/wiki/EditorApi/<pre>--- v1 +++ v2 @@ -1,64 +1,31 @@ -Editor Plugin api +Editor Plugin API --- ~~~ -#!html <span style="color:darkgreen;">by Nuklear Zelph</span> ~~~ -[[Image(EditorModel.gif, 640px, 480px )]] +Due to more thought and some new ideas the old design of the settings dialog that where outlined here are no longer applicable. Instead the settings dialog will be part of the editor "Master Plugin". A generic interface to the various settings will be supplied for the specific editor plugin to handle. -This page is going to explain the editor interaction for text manipulation. Later it should become a complete sdk doc, but we need a concrete plugin api first. +The general tab will be a set of key-value pairs that will automatically be stored in the editor section of the configs. "Highlight Current Line" the "caret" and "right margin" sections will remain, leaving the various settings in the above area to be added freely. -First off all of the functionality of an editor are separated into three sections. +The display tab will probably remain the same and those settings can be access by the plugin via configs. -~~~ -#!html -<span style="color:orange;">Core:</span> Those functionality that are just expected by any editor plugin.<br /> -<span style="color:#464646;">Gray:</span> (optional) These are great to have if they are implemented, but are not necessary. These will be grayed On the editor options dialog if they are not availible.<br /> -<span style="color:blue;">Extended:</span> These are extra options that are not necessary for all plugins. These options will be loaded by the editor plugin on demand rather than always showing up on the options dialog. -~~~ +The syntax highlighting tab will remain as it is, however the example code will be supplied by the compiler plugin. A generic set of coloring settings will be updated in the editor section of configs. -What needs to be decided is how the extras are added. A button can be placed on the general options panel that pops a dialog, an extra panel can be added to the notebook or a menu item could be put on the menubar. Alternatively if there are not too many options they can be appended to the current options panel. +The default code tab I don't understand enough to know what to do with at the moment. I suspect a set of default codes can be stored in the users settings based on language and toolkit they are associated with. -Since wxScrolledWindow now supports sizers there is a chance that we could use that to our advantage with the appending of other options. -We may need to put a language selector combo box or something to handle settings for various languages, thus dynamically changing the extended options on the panel. +The class browsing tab depends on how that is handled. I suspect it will be a plugin, perhaps a panel adding mechanism needs to be added to the editor dialog or it should be moved. Unless we build a similar built-in browser for C++. -These are my thoughts so far. - -Also the actual api will follow wxScintilla's api loosely. Not all of the api needs to be used and some of the functionality will be changed through options. - -All of wxDevIDE config files will be xml based. I think that there should be a global set of editor options stored under one namespace and language/editor specific settings in another place. (not including coloring which will take its own place) - -I have an idea on how to handle the dialog pages in the Editor Options dialog. A subclassed panel is passed to the dialog from the editor. this panel has a config handler in it to take care of the specific options that the panel displays. a plugin specific subclessed version of the generic one is passed to the dialog when it asks for it from the editor plugin. it does not actually have an instance of the panel, instead it has an instruction manual for how to create the graphical instances. when the dialog gets the panel it calls a create function and gives it the appropriate parent to create the panel for. the panel is then created and it internally handles the configuration changes. there may be an optional function pointer that will tell the editor to update to the current config state. +The plugin will essentially supply a list of settings that it supports for the general tab. The dialog will automatically add a scrollbar if the check boxes wont fit on a single page. Each setting will be passed as a pair, a name for the dialog and a config-enry that the editor can read from. Similarly the display and syntax pages will have a fixed set of entrys that can be read from. Each time the user closes the dialog, the editor will be sent a message telling it to read in the configs for changes. -the image at the top of the page explains in basic detail how the inside of the editor plugin is going to look. an editor base is going to have all the interaction functions defined in its api and that is what will be called by other plugins and the gui. a subclassed editor will create the actual instances of a notebook and editor windows. the notebook api will be a generic and complete api for accessing the notebook and adding panels to it that are related to other plugins. for the primary editor plugin a single instance of scintilla will be used and multiple documents will be stored and swapped between that instance. +The editor itself can decide how it manages syntax highlighting, bookmarks, breakpoints, error lines and the like. It will only need to read the various settings from configs in a standard way. -The other apis are included to allow other plugins to interact with the editor. the code completion plugin for example will be able to tell the editor to show its completion window and provide the options it should provide. an automated text macro plugin could assess the editor api to do a series of repedative modifications to the text. also the built in functions of the ide will use that api as well. +There will be several sub-API's to interface with the plugin. This way the editor component used internally will not matter. +Selection API, for updating or retrieving the current text selection. (some may support multiple selections 6as well) +Text access/manipulation API, the core of the editors capability. +Marker access API, this one allows any plugin to access and modify any sort of markers, highlighters and folding. The compiler and debugger plugins will have a special access area that other plugins cannot access, these will be generic. This way error lines, breakpoints and such can be managed without interference. +The editor plugin will have a type entry that will let third party plugins know which editor component is in use. This way plugins can know if they will be compatible. a certain set of markers is expectable, but not all editors are likely to have the support Scintilla does. folding will be a generic API, however the editor may not support it in which case all calls will fail. An entry should exists to tell plugins if folding is supported. Syntax highlighting and compiler/debugger markers as well as user bookmarks are expected in any plugin, if they don't exist the plugin will be considered broken. -The raw api is in EditorApi_Doc.txt, this page explains how everything works. - -/* -core: -AutoIndent -SmartTabs -keep/trim trailing spaces -group undo -ensure file ends with newline -coloring -breakpoints -enhance home key - -gray: -show hidden chars -insert dropped files -highlight current line -cursor past eof/eol -line numbers -folding -bookmarks - -extended: -brace matching -*/ +Multi-selection will be supported in the official plugin. Probably manual highlighting of text selections as well. Once the NZTextEditor spell checker plugin is built it will be added as an optional plugin, probably enhanced some for checking comments and what not. Also a JavaScript plugin will be created for NZTE, probably something will be built based on that as another plugin. </pre>Nuklear ZelphFri, 10 Aug 2012 05:16:32 -0000https://sourceforge.net1b1db23612e5179ae36357b5dd2764cd40aa450chttps://sourceforge.net/p/wxdevide/wiki/EditorApi/Editor Plugin api --- ~~~ #!html <span style="color:darkgreen;">by Nuklear Zelph</span> ~~~ [[Image(EditorModel.gif, 640px, 480px )]] This page is going to explain the editor interaction for text manipulation. Later it should become a complete sdk doc, but we need a concrete plugin api first. First off all of the functionality of an editor are separated into three sections. ~~~ #!html <span style="color:orange;">Core:</span> Those functionality that are just expected by any editor plugin.<br /> <span style="color:#464646;">Gray:</span> (optional) These are great to have if they are implemented, but are not necessary. These will be grayed On the editor options dialog if they are not availible.<br /> <span style="color:blue;">Extended:</span> These are extra options that are not necessary for all plugins. These options will be loaded by the editor plugin on demand rather than always showing up on the options dialog. ~~~ What needs to be decided is how the extras are added. A button can be placed on the general options panel that pops a dialog, an extra panel can be added to the notebook or a menu item could be put on the menubar. Alternatively if there are not too many options they can be appended to the current options panel. Since wxScrolledWindow now supports sizers there is a chance that we could use that to our advantage with the appending of other options. We may need to put a language selector combo box or something to handle settings for various languages, thus dynamically changing the extended options on the panel. These are my thoughts so far. Also the actual api will follow wxScintilla's api loosely. Not all of the api needs to be used and some of the functionality will be changed through options. All of wxDevIDE config files will be xml based. I think that there should be a global set of editor options stored under one namespace and language/editor specific settings in another place. (not including coloring which will take its own place) I have an idea on how to handle the dialog pages in the Editor Options dialog. A subclassed panel is passed to the dialog from the editor. this panel has a config handler in it to take care of the specific options that the panel displays. a plugin specific subclessed version of the generic one is passed to the dialog when it asks for it from the editor plugin. it does not actually have an instance of the panel, instead it has an instruction manual for how to create the graphical instances. when the dialog gets the panel it calls a create function and gives it the appropriate parent to create the panel for. the panel is then created and it internally handles the configuration changes. there may be an optional function pointer that will tell the editor to update to the current config state. the image at the top of the page explains in basic detail how the inside of the editor plugin is going to look. an editor base is going to have all the interaction functions defined in its api and that is what will be called by other plugins and the gui. a subclassed editor will create the actual instances of a notebook and editor windows. the notebook api will be a generic and complete api for accessing the notebook and adding panels to it that are related to other plugins. for the primary editor plugin a single instance of scintilla will be used and multiple documents will be stored and swapped between that instance. The other apis are included to allow other plugins to interact with the editor. the code completion plugin for example will be able to tell the editor to show its completion window and provide the options it should provide. an automated text macro plugin could assess the editor api to do a series of repedative modifications to the text. also the built in functions of the ide will use that api as well. The raw api is in EditorApi_Doc.txt, this page explains how everything works. /* core: AutoIndent SmartTabs keep/trim trailing spaces group undo ensure file ends with newline coloring breakpoints enhance home key gray: show hidden chars insert dropped files highlight current line cursor past eof/eol line numbers folding bookmarks extended: brace matching */Nuklear ZelphWed, 08 Aug 2012 04:40:14 -0000https://sourceforge.netda4ef7560d4720f9f979e07281e2357c5cca7824