I'm obviously missing something but I can't make any of the new icons
appear on the editor toolbar. They, and indeed everything besides H4, H5
section, but nothing I've tried makes them appear.
Post by Jeremy Ruston
Thanks to everyone for the feedback - and particular congratulations to
Andrew Harrison for the âreduceâ button. Iâve answered comments from Mat,
Knut and Stephen below.
** selectable colours with a new reusable colour picker
** selectable painting width
** selectable opacity
** clear image to colour
** resize the image
* New button for switching the text editor between automatic resizing and a fixed height
edit mode text toolbar could really be a general platform for
manipulating edit mode content, something that we have not really had thus
That is correct. The mechanism isnât specific to wikitext. I plan to add
suitable buttons to the Markdown plugin, for example, and as you suggest,
the KaTeX and Railroad plugin could ship with itâs own toolbar buttons too.
Another valuable tool type would be a kind of fold/unfold, possibly
using the revealwidget and similar to Erics old NestedSlidersplugin (an
absolute favourite of mine in TWC); I.e select a text portion and click a
text editor tool to have the selection surrounded with the necessary reveal
mechanism. The resulting view mode button and the content text could be of
You could build that button based on the existing âboldâ button.
IMO to hide/reveal parts in content is very powerful concept for text
(hypertext?) - i.e for conveying a message with text in the most efficient
way. It lets you design a text that turns to readers of different levels in
a much(!) more elegant way than common hyperlinking does; instead of
jumping away from the text for more in-depth, it lets you access depth in
place. (One could even imagine a text where a reader fills in at what level
he wants the text - "summary", "overview", "in-depth but with highlighted
basic concepts"... - and this sets the depth for the reveals. Or the system
stores depth level from previous use and uses this as default.)
The concept of âstretchtextâ in classical hypertext is pretty close to
Hide/reveal is IMO also generally underused in hypertext, probably
because there is no standard html construct for it. In TW we do have the
revealwidget but this is IMO much to complex to apply - compare it to the
simplicity in adding a link, or a transclusion.
We have discussed before adding wikitext syntax for a hide/reveal pair,
itâs an interesting idea.
I might have missed it before or there is a new tool to the right of the
Redo button; it seems to be something to insert/control the vertical
distance between two sections (great idea). I don't get it to work though
(FF nor Chrome, win10) and the popup looks a bit rough with very airy
squares stating a pixel number.
It was actually the embryonic control for setting the text editor height.
Itâs fixed now.
On the matter of including the Rich text editor in core; I think it
should be in standard distro (as expected by newcomers!) but maybe now is a
good time to introduce a more advanced edition without pretty stuff.
It would be quite surprising if the âadvancedâ edition had less stuff in
it than the âstandardâ one! But I get what you mean.
I think pushing the inline markup buttons with no text selected should
insert start/end markers (which they do) and then position the cursor in a
suitable position for immediately entering bold/strikethrough/... text
(instead of selecting the inserted markup). Same for ordered/unordered
lists and headings when the cursor is on an empty line.
I agree, and plan to do just that.
When the cursor is at the end of a line (with no selection), block
markup buttons behave differently than when the cursor is anywhere else on
the same line. This may be confusing.
If some text in the middle of a paragraph is selected, the block markup
(code/quote/list/numbered list/headings) buttons fail to insert the empty
leading line needed for correct rendering.
Thanks, Iâll look at both those..
For excising text, I believe linking would be a better default than
transclusion. Splitting up a tiddler that has grown too large is probably a
more common use case than including a snippet somewhere else; though this
may be my personal preference.
Makes sense, Iâll change the default and letâs see how others feel.
Anyway, a big thumbs-up on this; it substantially improves the already
considerable discoverabilty-factor for new users. :)
Ya know... I'm beginning to realize that a edit mode text toolbar could
really be a *general *platform for manipulating edit mode content,
something that we have not really had thus far.
For example the katex <http://tiddlywiki.com/plugins/tiddlywiki/katex/>people
could have their own set of buttons. Or when we put on the locomotive hats
and want a railroad <http://tiddlywiki.com/#Railroad%20Diagrams>diagram.
For the occasional user I'd think richtext tools should be superior to
having to learn the notation. Actually - I strongly suspect that many who
would really benefit from such special notations just don't bother with it
because it is too cumbersome to learn the wikitext for it. I even suspect
this is the case with the existing bitmap editing feature - so I just added
an idea to the github thread
Jeremys note about later adding bitmap widget toolbars.
But overall, it'd be great if people can easily create toolbuttons to add
to the new toolbar. Andrews contribution indicates that this might already
be the case!!
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.