Closed Jermolene closed 8 years ago
Thanks @pmario
Hi Jeremy,
Really important for me is: https://github.com/Jermolene/TiddlyWiki5/pull/1933
I have tested it the last months in FF and Chrome (always using the latest master branch) and it works very well. Mario and Tobias also said it worked for them. Without this fix, autoheight doesn't work for textareas that are contained in a scroll container. For TiddlyMap this means, it is not possible to edit Tiddlers when working fullscreen – which is a big drawback.
Thanks!
-Felix
P.S. I think https://github.com/Jermolene/TiddlyWiki5/pull/2048 should be an easy one.
Warning @Jermolene: Alerts cannot be closed anymore by clicking on the trash icon symbol. Maybe introduced with https://github.com/Jermolene/TiddlyWiki5/pull/1981 (just guessing from the title and the recent merge date).
@felixhayashi, mhhh... confused. Will look into it.
@tobibeer, it's really just a quick guess…
I'm pretty sure that's the reason, just not how that went unnoticed.
Thanks for the help everyone.
Partly because I've ended up merging so many pull requests in the last 24 hours, I've decided to postpone the release until early next week.
Therefore, there's a few days to:
You might be interested in merging this: https://github.com/Jermolene/TiddlyWiki5/pull/2156
I've just completed the documentation, and @felixhayashi is interested in getting this into the core as soon as possible.
Seems to work -- haven't managed to find any edge cases that cause problems.
@matabele,
My preference for the core -- to leave the $radio widget as is, and replace the $checkbox widget with the $checklist widget.
Admittedly, I did not read through the entire code ...and always argued from a functional pov. With regards to that, I wonder, can't we afford both widgets, checkbox and checklist? ...on the premise of reducing the checklist functionality to mere list-handling and none other? ...so no aspirations of replacing checkbox, but rather providing checkbox-mgt for list fields and that's it?
Alternatively to a checklist widget aspiring to replace checkbox, I think I'd still favor a clear mode attribute to checkbox over a checklist widget that provides all its functionality plus list-mgt, a mode attribute that is not needed by default, so checkboxes behave in their "simple" non-list ways of today but, when specified, allows users to gracefully handle list-fields as well.
The "Filter Operators" page seems to be missing in the tw5.com edition pre-release. Try looking up filters in the reference section of the Contents tab.
@tobibeer
I have revised my thinking: https://github.com/Jermolene/TiddlyWiki5/pull/2156
I've just completed the documentation, and @felixhayashi is interested in getting this into the core as soon as possible.
Indeed, I would welcome the integration of this widget very much. Checklists are valuable for plugin developers to allow users to make choices and store these choices in a list which saves space and is highly adequate. Also, how cool is it to be able to make e.g. grocery lists with checkbox-style!
@tobibeer
I wonder, can't we afford both widgets, checkbox and checklist? ...on the premise of reducing the checklist functionality to mere list-handling and none other? ...so no aspirations of replacing checkbox, but rather providing checkbox-mgt for list fields and that's it?
This is what I am arguing here. The checklist widget is a great addition and I am very happy @matabele took the initiative and implemented it, but the checkbox still has its purpose.
@matabele
The $checklist widget can handle these cases
No, the checkbox is necessary for single-value fields because it does not add [[…]]
around titles with spaces as it doesn't treat the field as list. The checklist would always add brackets, which is correct and necessary for list fields but will cause problems when a single title is stored in a field non-list style.
Hi @Jermolene
The multiple selection feature of the select widget throws an error: Uncaught TypeError: Cannot read property 'indexOf' of null
-Felix
Also there is a recursion error in TW that you have not responded to yet. Just to make sure you are aware of it: #2025
Eric also reported the multiple select problem here voicing another meaningful expectation of being able to specify a "number of displayed lines" for a multiple-select-widget, i.e. a size or perhaps max-size.
Don't know if this is an old bug?
When checking a checkbox in the story river -- the river sometimes scrolls (jumps) down away from the active checkbox -- on other occasions the river remains stationary (the desired behaviour.)
This behaviour can be annoying when checking a list of checkboxes -- as the river has to be scrolled before checking the next box in a column of checkboxes.
Can not work out why the this behaviour is inconsistent.
@Jermolene
I have changed the name of the list
attribute of the ActionListops widget to field
. Other users felt that this was the natural choice, and maintains consistency with the Checkbox widget: https://github.com/Jermolene/TiddlyWiki5/pull/2156
It might be an idea to make this change before users become accustomed to list
-- relevant PR:
https://github.com/Jermolene/TiddlyWiki5/pull/2160
https://github.com/Jermolene/TiddlyWiki5/pull/2161
https://github.com/Jermolene/TiddlyWiki5/pull/2162
@matabele, thanks for reacting to @felixhayashi's response. I think the change makes sense and helps improve consistency.
I have changed the name of the list attribute of the ActionListops widget to field.
Thanks @matabele, you are right, makes sense for ActionListops widget as well. Looking forward to use this widget!
I think the change makes sense and helps improve consistency.
Thanks for confirming @tobibeer
I'd like to try to get 5.1.10 released in the next couple of days. There is a brief opportunity to merge any uncontroversial pull requests that I've missed over the last few weeks (thanks to @tobibeer for pointing me at some of them, please everyone bump any issues that you'd like considered).
A hastily merged pull request can cause years of regret, so I'm really keen to stick to the simple stuff; if we need much discussion of an issue then it's probably better to push it to 5.1.11.