Replies: 2 comments
-
Hi!
You mean user interface or single settings file? Sorry, I'm lost. If you refer to the UI this might give you some hint on what I'm planning. I would like to add an easy descriptive format to generate the settings panel but that might take some time to develop. |
Beta Was this translation helpful? Give feedback.
-
Okay, yeah. Essentially something like in this example for Obsidian was what I thought. Dynamically generated sections. Each plugin has their buttons. The only difference between that was to allow for parsing the default used formats in the editor (XML [i18n], JSON, CFG [Editor, Colorschemes]) but if you have a lib to convert that from an unifying format that is fine. Essentially in there I thought - especially for plugins etc. - that besides a classical toggle-interface like in any settings menu there'd be a possibility to have some kind of Table-View for the configs requiring default-files with all possible keys and documentative fields. Maybe something toggleable to switch to in the UI. The cells may contain keys or formatted and recognized comments, which provide documentative information to later be shown. The whole view gives ability for manipulation and an overview. So I thought the translation manager and checker may be integrated there somewhere. This is very very roughly what I thought of but it'd have an information column and would be a little more usable than this concept application. This could - for the UI part with the switches - be fed into hovering hints or little For simplicity I did just add two example hints and it won't work out as I'd want to show it but in the end the Creator of each plugin or whatever may include more hints to all their sub-entries. |
Beta Was this translation helpful? Give feedback.
-
Randomly stumbled upon this:
#261
and I had an idea. Why not tie all
configs to a single interface.
As there was a multitude of ideas, e.g. translation helper
I wondered, whether it might be beneficial to have
an additional config manager as a custom element
like the CSS manager or as a plugin. It might be
fitted with a layout that may show keys or switches
or objects as some sort of table or dropdown list
and if applicable may also be fitted with its own
translations. After that it's just to be filled it with parsed
elements from some configs like the i18n-XML or the
config files for other plugins. So there'd be one Element
that is versatile and can be fed to manipulate quite a few
things to choose from, the work for individual problems
is done in the background individually depending on
what's chosen.
In case more third party plugins would be planned (idk) this
might also provide them with a kind of surface to interface
with their custom problems as they may tie in their plugins
to that manager. Maybe they could include documentation
there as a kind of listed browsing structure.
Just an idea but to me it is questionable if it'd be worth a
tussle. I may guess tho if more people get to know the editor
it'd be of use for some.
Beta Was this translation helpful? Give feedback.
All reactions