Hello.
About sliders: the story seems to be rather complicated and may be far from
usual usage. I put many tests in one tiddler and that's where sliders work
incorrectly. I simplified the test and made it closer to real cases. Create
tiddler 1 with couple of sections and a table in each:
!Section 1
|table 1|c
|editable|k
|h-cell1|h-cell2||h
|c11|c12++||
|c21|c22||
!Section 2
with merged cells:
|h-cell1|>|h-cell2|h
|c11|c12|c13|
|~|c22|c23|
then create another tiddler which transluces this sections, one via
<<tiddler>> and another via <<slider>>:
<<tiddler [[Tiddler 1##Section 1]]>>
<<slider "" [[Tiddler 1##Section 2]] "*" "">>
And then try this: first, open the slider and click E on a table. Each
table will enter the edit mode, no matter which E button was clicked. (then
click E again or reload the tiddler or go to edit mode and back) And
second, close the slider, click E on the table which is transcluded via
<<tiddler>>, then (or after clicking E once more) open the slider. The
table disappears; if you click E on the first table again, the second table
appears once more, but with messed numeration.
Regarding the self transclusion. A usual case for it is when I create
sliders (without NestedSlidersPlugin) and tab sets like this:
<<slider "" [[This tiddler##section]] "somelabel" "sometooltip">>/%
!section
some content
!end%/
/%
!section 1
...
!section 2
...
!end
%/<<tabs .....>>
Although, I place the sections *after* the transclusion macros most of the
times (this test case appear from that tiddler with many tests in it).
As for the test, it doesn't work for me. What I did:
* downloaded the pre_release.html file via FireFox -> save -> save all
* open it (in both FF 16.0.2, 17.0 with enabled and disabled TiddlyFox and
in Opera 12.11 without TiddlySaver.jar), opened the "test" tiddler
* click E, click c14, add "+" in there, click out (in edit mode the content
is shown as "c14+"), then click E again (the content is shown as "c14+c14"
now)
* open edit mode of the tiddler (in there the table is unchanged, the
content of the cell being "c14")
The behavoir is the same with all the combinations of browsers/saving
engines listed above.
Navigation with keyboard is very nice, thanks! I especially like the
behavior of the cursor when navigating left and right. The thing that needs
some more tweaking is merged cells: currently arrows don't move focus into
the "~" and ">" cells; what I'd expect is that pressing left always moves
to the cell on the left (including ones with ">" or "~"), not down or jump
over a cell.
Another idea: instead of clicking E, it can be very convenient to
double-click a table to toggle the edit mode. But this has to difficulties:
first, to implement this, it's necessary to stop handling even of
double-clicking the tiddler which opens the edit mode of the tiddler (set
by the fetchTiddler method of the story object [1]); and second,
touchscreens (or, better to say Android browsers) have some different event
handling (in Android, double-tap doesn't work for opening a tiddler to
edit).
Then, about editing lists.
First, there are three basic things which should be handled:
* simple list
* list tree
* list tree with items with wrappers like this {{justDiv{
> here goes, for instance, a quotation
* or
* another
* list
| or | a |
| table |
etc
}}} and then some more text. Unfortunately, there are other wrappers. In
some TWs I use NestedSlidersPlugin when makes +++[this wrapper]
some content
=== and also /%
comment wrapper
%/
and it is to be decided what parts are opened in the edit mode. A simple
way would be to edit a list item with everything inside it, but when
there's only a sublist inside, like this:
* item
** sublist item
** another sublist item
than it's more convenient to open only the
* item
part on editing the item.
Next, there should be some way to activate the edit mode. There has to be a
method for each list item. There can be some buttons, or a button can
appear on click, or double-click can activate the edit mode. What I think:
* double-click is a very good solution but
** this can have the same problems with touchscreens as I mentioned above
** there should be some way to activate other control elements (analogue of
C button, menu for moving up and down etc). This buttons can appear in the
edit mode; as for "where?" -- in the end or in the beginning of the list
(perhaps hovering over a list item marker).
* single-click+buttons is a bit worse, because buttons will appear in some
situations where that's not necessary (like opening a slider or clicking a
<<tag>> macro). The advantage compared to the double-click approach is that
there's no need to open the "editor" for other operations and also no need
to investigate the "Android double-click event handling" issue
* permanent buttons version isn't tidy at all and I guess will be not good
enough in mobile devices as buttons will eat extra space
The third things to look into is extra operations. Not necessary to
implement them at once, but they are to be accounted when designing the
engine. So operations that I see to be useful are:
* the same as in TableEditor: add an item, cut/copy/paste
* move up/down (in principle this can be done by copy-pasting)
hm.. in fact this doesn't seem to make much restrictions..
Finally, a general note (perhaps, too general). I was thinking about how
this is different from WYSIWYG and concluded that the basic difference is
between "simple text field" (in the edit mode) and a "text field" with an
arbitrary element inside. Let me give an example. Consider this line:
This is an equation: $a + b = c$ and this is a macro: <<tag [[smth]]>>.
Ordinary "tiddler edit mode" opens this as it is written here. A list
editor made with text fields will do the same (and, for instance, show the
whole wrapper with the content inside itself). On the other hand, if there
was a possibility to open this as
This is an equation: <here the equation element is generated> and this is a
macro: <here is the macro element>.
where text can be edited and navigated like in the ordinary text field and
"elements" are shown wikified that would ease many things, like working
with formulae, or with list items containing wrappers or other things (and
this is the main step to WYSIWYG). See ASciencePad [2] to get some ideas:
especially about workflow with formulae inside text (keep in mind that
that's an adaptation, meaning that the core TW code is altered; and it also
works only in some browsers partially because of MathML).
Hope this post is not totally overwhelming.
Best regards,
Yakov.
[1] https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/Story.js#L253
[2] http://math.chapman.edu/~jipsen/asciencepad/asciencepad.html (
#MathExamples )
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/tiddlywiki/-/BHSebhKnPAwJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/tiddlywiki?hl=en.
