Open Gnossos opened 3 years ago
Hey @Gnossos,
Thank you for the feedback! Regarding the features, I'd say half of them are reasonably easy to implement, whereas the other two might be more tricky:
Control over window dimensions and location. Control dimensions & locations of text boxes and other controls in the dialog window.
These could be controlled (as far as I know), so I'll make sure to add to the roadmap some options to customize this behavior
Control appearance of dialog window and controls.
These are very difficult to accomplish currently, as espanso under the hood uses wxWidgets which is based on native controls that are difficult to customize in a cross-platform way
imagine a bibliographic entry form starting with one author; for a source with multiple authors, the form could have a way of adding text boxes for additional authors in the fly; it also would be desirable to be able to relate controls for two or more pieces of related data (an "itemset"), for example author + affiliation, and allow additional pairs of author + affiliation to be added dynamically as the user enters the data. The software would have to number, or otherwise distinguish, each itemset as it's added.
These are achievable, I'm planning to improve the form capabilities in the upcoming months so some of them will very likely make their way into espanso :)
Cheers :)
If you use the sciter.com it uses HTML CSS to implement the interface, it should be easy to control the interface.
@tch123 Thank you for the feedback! I've considered sciter as well, the only blocker was the fact that (at least at that time) it was not open source...
(How does one mark issues as requests for enhancements?)
This is a request for a 4-part enhancement allowing better form dialog window management. While each part can be implemented independently, I'm grouping them together because they're closely related and in other windowing systems usually grouped together.
The enhancements are:
Comments
1 might vary depending on whether the trigger is generic (in default.yml or its app-independent children) or app-specific. In the latter case, location might be constrained to the app's open window(s); in the former, anywhere on the current screens.
2 It's particularly important to be able to dictate the minimum widths of text boxes; relative location can currently be controlled by the layout: item, but there may be a better, more precise way. A possible, particularly interesting approach would be "elastic" text boxes (and other controls) that expand horizontally when inserted text exceeds the original width.
3 Preferably implemented with something like CSS, a widely used, well-known mechanism for controlling look and feel, this would allow control over colors, fonts, character size, etc.
4 Enhancements: for example, the ability to add fields dynamically from the form dialog window.
Example Imagine a form for entering bibliographic data into a page of text. Regarding #1, the designer might want the dialog to appear at the bottom right corner or center of the page, rather than the left edge, which seems to be the only current option. Regarding #2, in anticipation of long titles, the designer might want a "title" field to be much wider than the current default width for an empty text box. Regarding #3, a designer might want to use different colors to distinguish default values from user-entered values. Regarding #4, imagine a bibliographic entry form starting with one author; for a source with multiple authors, the form could have a way of adding text boxes for additional authors in the fly; it also would be desirable to be able to relate controls for two or more pieces of related data (an "itemset"), for example author + affiliation, and allow additional pairs of author + affiliation to be added dynamically as the user enters the data. The software would have to number, or otherwise distinguish, each itemset as it's added.