TxEditor

[BlackGad]

Features that i require: 1) Multiple dictionary files editing. 2) UI improvement(arguments description for specific key etc) 3) Drag'n'drop support tree 4) Partial key templates for common element description (commands, forms etc)

So I must to decide what to do: 1) Rework UI core (I am afraid that it will broke backward compatibility with your current master state or pull requests will be huge) 2) Add this features externally with out core rewriting (add additional pane for multiple files).

I will choose 2 if you interested in your master Editor improvement. If you do not care about requested features I will choose 1.

[ygoe]

Can you please provide more details? How should the "multiple files editing" work? Which text key belongs to which file then? What is the "arguments description"? Is drag&drop for duplicating/copying and renaming/moving, or something else? What is point 4?

Drag&drop support for the tree lies in the responsibility of the MultiSelectTreeView project which is an independent NuGet package. This may be implemented in the future (like this year) but I don't have specific plans yet.

Somehow I've got the feeling that I'm not comfortable with the prospect of huge pull requests.

[BlackGad]

Multiple dictionary files editing.

I have separated localization files in modules (using MEF plugin system). So it is hard to work with several Editor windows at once. Multiple files representing could be done in 3 ways: 1) Add another root into treeview named physical file. 2) Add another pan somewhere in UI with linear(or tree) representing of physical files.(preferred way) 3) Merge all keys into global view and remember in their model source. (It is fantastic way and require full app redesign so is not real)

Also I am using subversion(svn) and different modules lays in different svn branches so in future I want to commit physical file directly from UI :)

UI improvement(arguments description for specific key etc)

Different people doing development and documentation so devs must be able to specify what params they actually pass into localization key for documentators(they will decide what is important and what is not in key value).

Example:

var message = "explorer.main:startup.errors.start failure"
                    .L()
                    .Argument("details", exceptionDetails)
                    .Argument("version", appVersion);

Drag'n'drop support tree

Editor not flexible when you work with keys. For example when you create key with wrong namespace(colon and dot included) you must either duplicate or recreate same key in new destination. Also there is collisions when subpath of one key is actual full path for another key. You cannot delete it with out children delete.

Partial key templates for common element description (commands, forms etc)

Some UI parts are standardized. So doc man must be able to add subset of keys from predefined template. Example: We have a button in our UI. All buttons have their own commands, which have title, group, description. Also this kind of stuff must be placed in specific location.

• named form
  • commands
  • close command
    • title*
    • group*
    • description*
  • save command
    • title*
    • group*
    • description*
  • header*

Now designer can bind this command to a shortcut and to a button. Also this commands will be handy discovered by app command manager

[ygoe]

Multiple dictionary files editing.

Option 1 and 2 are probably similar. It must be checked how the editor treats text keys as unique. If that's hard to change, then switching files (from the panel as in option 2) means closing the current file (and optionally saving!) and opening the other file. This can already be done by loading the most-recently used files.

Commit to SVN is a bit off-topic. First I consider it bad practice to work on different branches at the same time (or even to check out multiple branches), second this is completely impossible with Git.

UI improvement(arguments description for specific key etc)

Can you use the text key comment for that?

Drag'n'drop support tree

You can use the existing Duplicate and Rename commands to rename keys. This doesn't restrict you to the current tree branch. If you change the entire text key, the tree should be updated accordingly. Have you tried that?

Partial key templates for common element description (commands, forms etc)

Looks interesting. So you mean that when you add texts for a new command, the editor should automatically insert these three subkeys as well? Where would such templates be defined? And this won't work with the text key wizard. I usually go the wizard way: Just write the code with literal strings, change them during development, and finally replace them with dictionary keys.

[ygoe]

Oops, I'm sorry, MRU files isn't available in TxEditor yet. But I might want to add that. In the meantime, you can pin TxEditor to the taskbar and use the Windows jump list for that.

[BlackGad]

Can you use the text key comment for that?

Already.

Have you tried that?

Nice.

So you mean that when you add texts for a new command, the editor should automatically insert these three subkeys as well?

Yes. Templates must be defined externally. Xml files in specific location is a good solution as we can sync then with repository. (UI editor for templates is not necessary)

Wizard way is fine with simple projects. When peoples works together with several products at once overall situation more complex. So devs in few words documenting strings in localized files and then in several days real documentation team do this strings right (syntax, meaning, standards)

In the meantime, you can pin TxEditor to the taskbar and use the Windows jump list for that.

:) real project - it is about 10-30 libraries so 10-30 instances of txEditor is a bit too much) Jumping between windows lower overall productivity for about 20% (peoples change focus too often)

We just cannot use one big localization source bcs of code reusage in several products.

[ygoe]

Editing multiple dictionary files simultaneously needs more architecture investigation. From a quick look into MainViewModel.cs I don't imagine it's possible to do that easily. There must always be some kind of switching between files so that it's clear what file to operate on. Also I imagine it a chaotic situation when general features like suggestions work on all opened files, but users might open a different set of files because there's no concept of a "project" file like Visual Studio holds together all source files of a project. Each user needs to "collect" all interesting files manually (each time).

Drag&drop is desired, but this project isn't the right place to do it. Once MultiSelectTreeView has drag&drop, it will certainly be used in TxEditor.

Templates sounds like a specific requirement of your project. Might it be possible to handle that with some sort of plugins for TxEditor? Plugins are not supported now but it could be a good way of letting others extend and customise the text key handling. In this scenario, a plugin could jump in on the creation of a new text key, and if it matches a certain pattern (like *.commands.*) it automatically adds the subkeys as well. Other scenarios that come to mind are validation or key name rule enforcement.

[ygoe]

Another idea for editing multiple files: It wouldn't be necessary to save and unload a file when switching to another file. Instead, all selected files can be loaded into memory at the same time, and switching files would only set the view to a different root of the files. There are still two possible implementations for selecting files: 1. Another tree level above all keys, and 2. a separate ListBox to the left of the tree. We now need to imagine which of these options is more usable.

[BlackGad]

Well I mean exactly this idea when purpose you 3 variants :)

Implementation depends on plugin system(purposed by you). I think it make sense to implement files into treeview as root and introduce plugin system (using MEF load all assemblies which ends with *.Plugin.dll and implements basic API)

API example:

interface IPlugin
{
        /// <summary>
        /// Called on editor loading.
        /// </summary>
        /// <param name="model">Model created by editor for main window.</param>
        void Initialize(MainViewModel model);
}

MainViewModel will contains public events (code will be rewritten as EventHandlers with correct EventArgs):

/// <summary>
///     Called on key creation by editor.
/// </summary>
/// <param name="sourceModel">Model created by editor for source key.</param>
/// <param name="duplicatedModel">Model created by editor for duplicated key.</param>
void CloneKey(TextKeyViewModel sourceModel, TextKeyViewModel duplicatedModel);

/// <summary>
///     Called on root creation by editor.
/// </summary>
/// <param name="sourceModel">Model created by editor for source root.</param>
/// <param name="duplicatedModel">Model created by editor for duplicated root.</param>
void CloneRoot(RootKeyViewModel sourceModel, RootKeyViewModel duplicatedModel);

/// <summary>
///     Called on xml loading for every detected key
/// </summary>
/// <param name="model">Model created by editor for key.</param>
/// <param name="keyNode">Loaded xml node for key.</param>
void LoadKey(TextKeyViewModel model, XmlNode keyNode);

/// <summary>
///     Called on xml loading at start.
/// </summary>
/// <param name="model">Model created by editor for root.</param>
/// <param name="rootNode">Loaded xml root node.</param>
void LoadRoot(RootKeyViewModel model, XmlNode rootNode);

/// <summary>
///     Called on key creation by editor.
/// </summary>
/// <param name="model">Model created by editor for key.</param>
void PrepareKey(TextKeyViewModel model);

/// <summary>
///     Called on root creation by editor.
/// </summary>
/// <param name="model">Model created by editor for root.</param>
void PrepareRoot(RootKeyViewModel model);

/// <summary>
///     Called on key save.
/// </summary>
/// <param name="model">Model created by editor for key.</param>
/// <param name="keyNode">Node which will be saved for key.</param>
void SaveKey(TextKeyViewModel model, XmlNode keyNode);

/// <summary>
///     Called on root save.
/// </summary>
/// <param name="model">Model created by editor for root.</param>
/// <param name="rootNode">Node which will be saved for root.</param>
void SaveRoot(RootKeyViewModel model, XmlNode rootNode);

API could be simplified if root and text key models will be inherited from one parent.

Anyway you need 4 methods for every model: 1) When loading from xml (plugin must be able to load custom data) 2) When saving to xml (plugin must be able to save custom data) 3) When creating new (plugin must be able to initialize custom data and configurate model) 4) When duplicating model (plugin must be able to duplicate custom data and configurate new model)

In all this models must be public methods/properties for:

• Icon override
• Context menu group injection (here i can implement sub template specific features)
• Black box storage for plugin specific info

Also it make sense to create *.txdproj files, which will contain batch of txd references (just filenames and some generic info)

[BlackGad]

So what are you think about my message? If you have no objection I will start to implement this tomorrow.

[ygoe]

I'm not sure if I understand exactly what you mean. Also I'm sceptical about MEF. Previous investigations showed that it's too huge for a simple plugin system. But maybe I'll understand it better when I see your code. So for now it's only about the plugin feature, right?

[BlackGad]

Yep with system like this I could write specific to my cases plugins independently.

[BlackGad]

Also I'm sceptical about MEF. Previous investigations showed that it's too huge for a simple plugin system

Vanilla MEF is simple and clear :) Also it is integrated into NET so does not require additional references.

[ygoe]

Well then, I'm looking forward to your suggestion. :-)

[BlackGad]

Editor's code is too bound so: 1) I will rewrite load/save mechanism(same functionality but another decomposition and code clean up) 2) I will decompose logic from main view model

[BlackGad]

Could you explain what is Template file?

[ygoe]

An example is the template file provided with the TxEditor source. It contains the system keys that are used for various formatting functions. I'm not sure right now why that was necessary but there should be some decisions upon this flag in the code, probably mostly in the import stuff. Templates cannot be created with TxEditor so that's probably nothing for the end user. This was added in commit fbaf859.