#108 Road map for TKE 3.7?

[Alex Plotnikov]

Now that TKE 3.6 is released, boldly offered is a road map for the next release of TKE.
All offers are appreciated :))

To start with:

Plugins to make:
1. "Save Here" - a sidebar plugin that allows by one click to save a current buffer (mostly Untitled, but it isn't a must) into a sidebar directory. Perhaps may be a core functionality.
2. "Apply Command" - a sidebar plugin that allows to apply customized command(s) to a file/directory of sidebar.
3. Backuping/journaling/recovering any/selected edited files. Perhaps may be a core functionality.

Plugins to enhance:
1. "Command launcher" (for repeated calls of it) - offering the previous input that is fully selected; it would allow either to repeat/select previous command(s) without reentering or to start entering a new command without backspacing/deleting the old one.

A core functionality:
1. Setting a default syntax for Untitled (new) file. I.e. when a syntax is selected for Untitled from View/Set Syntax, it would be applied for future Untitled's.
2. Tuning 'on fly' the selected (mostly syntax & background) colors of current theme. Good for eyesight at any lightings.
3. Providing "include" directory (and corresponding api::plugin_include) for:
TKE/plugins (e.g. in TKE/plugins.include)
~/.tke/iplugins (e.g. in ~/.tke/iplugins.include)
... so that plugin writers might keep their own sourced/packaged codebase in one place.
So far, the plugins' shared modules are stored in their directories and as such duplicated.

For this site:
1. Creating new "Plugins" page similar to "Themes".
2. Copying (with enhancing) the https://tkeeditor.wordpress.com/ to "Wiki" page of this project.
3. Enhancing "Screenshots" page. TKE has much more than a mere theming.

[Alex Plotnikov]

"Save here" might be shortcutted by drag-n-dropping the buffer's title to a sidebar directory.

"Apply command" might have a checkbox option "Recursively".

For backuping/restoring it would be nice to consider ~/.tke first of all.

Command launcher might be enhanced with PageDown/PageUp navigation.

Default syntax of Untitled can be otherwise set by choosing a template that is also can be cosidered as default for Ctrl/N hotkeys. I.e. we might have a radio option "Make New File from" - " Last Choosed Template / Last Choosed Syntax / None of These".

Tuning colors 'on fly' might be implemented with a slider similar to a tone slider of Windows' color picker. At that we might have checkbox options "Include background" "Include foregrounds". Components of foreground colors might span 1/2 of 0-255 range (dark/light side of it), while background 1/2 of the opposite range (light/dark). An example how the mutual changing of color components work can be seen on the video: http://aplsimple.ucoz.ru/doc/tkcc_files/tkcolorpicker.mkv

"Wiki" page containing "Tips and Tricks" of TKE would be nice to be referred from "Help/Tips and Tricks" menu item of TKE. No ads etc.

[Trevor Williams]

I like these ideas. I'm not sure that I can complete some of the items that would need to be handled by the core logic for 3.7 as I have a list of core modifications and enhancements that I would like to get done in the 3.7 timeframe. These are essentially the following:

• Complete work on plugin manager (this has been a work in progress).
• Move multicursor support into ctext widget (work in progress).
• Add enhanced ctext index command support (work in progress).
• Add support for upgrade cleanupfunctionality.
• Add plugin support for translations.

In terms of moving the tips/tricks website into the wiki, is your goal to allow others to contribute to the content?

[Trevor Williams]

I've been thinking this morning about your #3 for core functionality. I think that mostly it is important that plugin developers not have to maintain multiple copies of the same file. I don't think that it is bad that users have multiple copies of the same file on their system.

As such, I would leave it up to plugin developers to decide where shared files reside on their local systems and then create symbolic links of those files in the respective plugins that use them. When TKE's plugin bundler goes to work, it should copy the original file into the plugin (not the symlink itself).

That would solve the issue of shared code.

Sharing data between plugins could definitely be an issue that I'm not sure how to solve. Plugins are mostly sandboxed from each other (with the exception of the data sharing facilities that we recently added to the API). If we created shared data directories, this could become a big problem for the user.

Your thoughts?

[Alex Plotnikov]

Indeed, the include directory can spawn the following issues:
1) export/import of shared code can be tricky and error-prone
2) at modifications of a shared code by one application, there might occur incompatibility with other applications
3) so, we should have the versioning for shared modules; e.g. we would have mymodule.1.1.tcl, mymodule.1.2.tcl etc. which reduces the value of sharing
4) the sandboxing may prohibit the access to the include directory which is also reducing this thing's value.

Though, as for iplugins, these issues are less serious as the iplugins don't (in theory) influence the TKE directory's contents.

Moreover, maybe it makes sense to consider the following features:
1) at exporting iplugins - make it possible to choose any directories from ~/.tke (except standard TKE's) to be zipped
2) at importing iplugins - unzip all their contents (incl. those additional directories) into ~/.tke

Those additional directories can be of any names choosed by the plugin writers. The possibility of their overlapping is generally 'at your risk and your considering', as the iplugins code at all.