Hi Mat,
> First, unless you object, I will hereon refer to the end user popup > content templates as "popup tools" or, if the context allows, just "tools". > And we can now call the /_Popup tiddler simply "the popup". > > Agreed upon nomenclature is good. I struggled with this yesterday both while writing to you but also renaming macros in body/editor > The popup is now fully reworked. It has two groups of variables. See if > you think any of them should be moved upstreams into /body/editor. It feels > like the popup ought not have anything to do with the state tiddler. BTW, > the editedTiddler variable refers to the viewtemplate tiddler of a tiddler > being edited; in our case it'd be "RikerIpsum", and this variable is used > in e.g transclude tools. > I'll have a look sometime this weekend. Perhaps targetTiddler instead of editedTiddler? > Changing variable names is not as obvious as I thought: The system > variables should be prefixed with em-. But IMO variables that the user is > in direct contact with should be as friendly as possible. For example, when > he creates a popup tool I think it is better if he creates the "trigger" > field as opposed to the "em-trigger" field. Yes/no? > And "fragment"... I guess it could be changed into "nameprefix" or > "em-nameprefix" but I'm not sure that is more informative. It must not be > "titleprefix" because it is not always titles.) > I think a user you expect to write regular expressions, can also be expected to read docs and use em-trigger instead of trigger. Personally I don't like to have any fields used in my wikis that are not namespaced unless they are extremely generic in nature, e.g. parent > Q's for you > > 1) The styling you've put in $:/plugins/EditorMagic/styles - mess up e.g > buttons inside the popup (e.g the 100% width). Were these styles added to > e.g harmonize with your floating editor tools, or why were they added? > Remove the stylesheet and trigger the title picker and you will understand. None of this code is influenced by the floating editor toolbar. Having our reveal widget inside the editor means everything in the popup is inside the editor toolbar. Annoying CSS wise, but brings benefits in terms of being able to use toolbar buttons and the tm-edit-text-operation. > 2) Merely stepping with the arrows is not sufficient to trigger anything. > Eg, if it says <$ it is not merely enough to arrow ones way to after to $ > to fire popup. It would be nice if it were, because currently one needs to > e.g insert some character and delete it to trigger the popup. Do arrow keys > not fire actions like other keys? > As you will recall from the PR and even the name of the actions attribute for the edit widget, these are inputActions. That is they fire on the input event, which is triggered when the content of the textarea changes. Arrow keys do not change the content. I already wrote JS that resolves this some days ago, but the downside is it makes the action-popupcaret widget much less generic. > 3) The recursive macro and what it solves: > >> We want to test all definition tiddlers for matches, and at the end >> decide what to do. >> > > I have this nagging feeling it could be made simpler than with the > recursive macro by using some kind of external state value that is changed > for each match. Maybe each match could append the title to a list. At the > end we just extract the first title? > I actually like recursions (except their binary behaviour to fully work or > absolutely not ;-) but because it is part of the wikitext I feel it is > advantageous to keep it as simple as possible for others reading it. > Feel free to take a crack. As far as I know we don't have any other easier and efficient way to save variables for every step of a list widget run, have them persist and update, and compare them afterwards. variables set inside a list widget do not change the value of variables outside the widget. If you save the values to a field, you cannot read this again and get the updated value in the same block of actions, where block means triggered by the same triggeringWidget. In our case, that means all the actions are one block since they are all triggered by the edit widget as a result of single user interaction. I don't see an issue with complexity here as users of the tool would not need to tinker with this, unless you don't feel comfortable enough with it to maintain the code? Cheers, Saq -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywikidev/636ed68b-ab23-4913-8479-6df30835f503o%40googlegroups.com.
