Hi Vincent, The MTC in my last post was based upon the "official" releases of TWtable and TWted (v1.4.6). The weird behaviour stays with the prelease file of november 30. MTC based on that prelease file (after deletion of superfluous tiddlers) [1]
Cheers, Ton [1] https://dl.dropbox.com/u/2638511/pre_release_3.html On Dec 4, 11:16 am, TonG <[email protected]> wrote: > 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... > > 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.htmlforyou 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 > > ... > > 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.
