Hi Vincent, I can confirm Yakov's observations about strange behaviour of transcluded sections in a slider. I do see it in my "work" FF17 and in my "test" FF17. What I also observed was that in the tiddler with 2 sections, only the table in the first section shows the 'E' button; the table in the second section only shows the 'C' button. I made a MTC [1]. 1) Start MTC; it shows Test2 and Test1 tiddlers. The slider in Test2 works normal. 2) With the slider closed, click the 'E' button => strange behaviour of the slider. 3) After clicking the 'E' button again, the strange behaviour stays. Hope that helps.
Cheers, Ton [1] https://dl.dropbox.com/u/2638511/MTC_TW266_TWtable146_TWted146_slider.html On Dec 4, 7:02 am, Vincent Yeh <[email protected]> wrote: > Hi, Yakov, > > On Tuesday, December 4, 2012 1:50:02 AM UTC+8, Yakov wrote: > > > Hello Vincent, > > > sorry for the delay, time is pressing as usual :) > > No problem. You see I am slow these days, too. > > > Yes, partial self-transclusion now works correctly (tested in Opera and > > FF). > > > Strange behaviour in two tiddlers mentioned in my previous post (with two > > transclusions, one by the tiddler macro and another by slider) remains > > nearly the same in both Opera and FF (did you mean this by "the wrong > > behavior in a closed slider panel"?). Tapping E on one of the tables (when > > the slider is opened) toggles edit mode of both, opening edit mode when the > > slider is closed causes troubles with the other table when the slider is > > opened. > > Hm..., that is strange, for I don't see such behavior with my Opera and FF > in Ubuntu as well as Win7 64 and Win XP 32... (yes I meant that by "the > wrong behavior in a closed slider panel"). However, I found some other bugs > from this test case, will fix them as soon as I have time. > > And you are right that the codes in TWtable+TWted can be easily generalized > to work on all types of block elements (paragraphs, tables, lists, > blockquotes, headers, block examples, preformats...) In principle it should > work on inline elements as well but I will leave it later. I had done the > generalization for block elements over the weekend and started working on > the list editing things. Thanks to your detailed explanations simple lists > are now editable in my development version, but list trees and other things > are more complicated than I thought, shall need much more time... Will put > up a pre-release file for you to play with in a few days (well, I hope so). > > Have fun! > Vincent > > > > > > > > > The "hide until mouseover" option is fine, it also works in touchscreen > > (instead of mouseover, one needs to tap a table to make buttons visible, > > just as expected), thanks. > > > Best regards, > > Yakov. > > > четверг, 29 ноября 2012 г., 19:45:59 UTC+4 пользователь Vincent Yeh > > написал: > > >> Yakov, > > >> Thank you very much for so much detailed description of your ideas, I > >> actually haven't thought that deep yet! I will think more about it and > >> probably start working on it not far from now, though it seems like a big > >> project to me. > > >> About the bugs I think I have fixed a couple of them, > > >> - the wrong behavior in a closed slider panel, > >> - the strange results in partial self transclusion, > > >> The keyboard navigation in a spanned cell shall be fixed soon. > > >> Ton, I should have fixed the TWtcalc bug you mentioned, too. > > >> A pre_release file is prepared at > >>https://dl.dropbox.com/u/23745840/pre_release.htmlfor you to try. > >> Please do try it and tell me if there are more I need to fix. Thanks. > > >> Have fun! > >> Vincent > > >> On Wednesday, November 28, 2012 10:57:36 PM UTC+8, Yakov wrote: > > >>> 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 > > ... > > read more >> -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. 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.
