Hi Vincent, I saw new versions of your plugins (1.5.1/0.7.8) and tried these. I did not expect a solution for my problems, so just an update of my testing: They behave exactly the same as the previous ones (v1.5.0/0.7.7): * Blank page without TWtcalc (Win7 64-bit, FF 19, Chrome 25). * No backstage button and E button with all 3 plugins installed (FF & Chrome). * Hovering over the block elements (in FF) you see the "C" button except for item3 and item6 in the ordered list and item3 in the unordered list. In Chrome you see it everywhere.
Glad to hear you want to make a separate table editor plugin. Without your plugin(s), editing of (not to small) tables is a nightmare. I'am using v1.4.6 daily and cannot imagine I succeeded editing tables in the past without it :). It saves me a lot of time. Cheers, Ton On Mar 16, 6:10 am, Vincent Yeh <[email protected]> wrote: > Ton, > > On Saturday, March 16, 2013 5:08:42 AM UTC+8, TonG wrote: > > > Hi Vincent > > > I was busy with other things and didn't have time to test (meantime > > using the v1.4.6 table editor). > > So, after a long time I started testing the new versions (v1.5/0.7.7). > > > To be honest I only need the table editing feature. That feature makes > > editing tables a breeze and I think it is worth to make a separate > > plugin for that feature alone (I'am still using the "table-only" > > version 1.4.6 daily). > > Good point! I also had this thought of code separation but for a different > reason: they are too fat to be called "plugins"! I will start separating > them after releasing 1.5.1/0.7.8. Also I will spend some time on the > documentation as mentioned in my last reply to Yakov. > > > > > > > > > > > I don't need the possibility of editing of other parts (on a PC with > > large screen), but I can imagine other users do like it. For mobile > > devices it is a different story (small screen). > > In most of my TWs I installed Eric Shulman's Quick Edit package, but > > after some time I noticed I used that package only for a few special > > (custom defined) formats like an iFrame or an iFrame within a slider. > > All other formatting (headers, lists, bold, ... and even some CSS > > style wrapping) I do "by hand". > > > For testing (Windows 7, Firefox 19.02) I made a minimal test case > > based on the new TW 2.7.1. > > When I only added TWtid.min and TWted.min I only got a blank screen > > after saving and reloading. > > At first I thought it had something to do with the TW version, but > > "older" TWs behaved the same. > > Older versions of FF did not help either. > > Since other browsers also showed a blank page, it wasn't a FF issue. > > But I remembered seeing the the v1.5 plugins working (weeks ago I did > > some preliminary testing). > > > When I added TWtid.min, TWted.min *AND* TWtcalc.min (v0.7.7) to an > > empty TW everything worked as expected. After deleting TWtcalc.min the > > blank page reappeared! > > So there is a certain dependency between the plugins. > > That wasn't the case with version 1.4.6; I use TWtid and TWted WITHOUT > > TWtcalc! > > So this explains why I never had the problem of blank page, I always use > TWtcalc. Now I have a clear direction where to look for the bug. Thanks a > lot! > > > > > > > > > > > A MTC with TWtid.min, TWted.min and TWtcalc.min did NOT show the > > "backstage" button in the upper right corner. > > I could go within the backstage with help of the "EnableEdit" > > bookmarklet by Saq Imtiaz. It "repairs" the backstage/close buttons > > during the session, but after reloading the TW the backstage button > > doesn't show again. > > With tables, headers and ordered/unordered lists I only see the "C" > > button; no "E" button is visible although TWtid and TWted are enabled > > and TWted is active in View mode (default settings). > > I remember from preliminary testing I saw the "E" button and could do > > some editing. > > An older (v3.6) portable version of FF behaved the same: no backstage > > button, no "E" button. > > Chrome portable (v25) behaved the same as well: no backstage button, > > no "E" button. > > > Another strange thing I noted in FF (NOT in Chrome): > > ---- > > !!!Ordered list > > # item1 > > # item2 > > # item3 > > ## item3.1 > > # item4 > > # item5 > > # item6 > > ## item6.1 > > !!!Unordered list > > * item1 > > * item2 > > * item3 > > ** item3.1 > > ---- > > Hovering over the block elements (in FF, v19 & v3.6) you see the "C" > > button except for item3 and item6 in the ordered list and item3 in the > > unordered list. In Chrome you see it everywhere. > > > I don't know what is happening; I can't even start testing. > > My MTC can be found here [1] > > Thanks for the test case. Next week I shall find some time to have a look > and fix them. > > Have fun! > Vincent > > Cheers, > > > > > > > > > > > Ton > > > [1]https://dl.dropbox.com/u/2638511/MTC_TWtid_TWted_TWtcalc.html > > > On Mar 15, 8:36 am, Vincent Yeh <[email protected]> wrote: > > > Hi, Yakov, > > > > On Thursday, March 14, 2013 5:31:09 AM UTC+8, Yakov wrote: > > > > > Hi Vincent, > > > > > glad the development goes on. Could you specify what bug you was > > talking > > > > about in the WYSIWYG discussion? The "cursor in the preview" one? > > > > > The bug was fixed lately so no need to worry about it. However, for > > your > > > > information I'll put some words here to explain. In TWted the editbox > > > adjusts its height as the user is typing, and, for reasons unknown to > > me, > > > the adjustment requires (for some browsers) first setting its height to > > 0 > > > to get the correct height of its content (see here< > >http://twtable.tiddlyspace.com/#%5B%5BDynamic%20TextArea%20Height%5D%5D>if > > interested). In a recent coding time I accidentally removed some of the > > > codes to set the correct height back, resulting in a zero-height editbox > > > once I started to type. But the editbox still had the focus and received > > > all the keystrokes, and the previewer was still working, so it looked > > like > > > the previewer was responding to my typing, that gave me a feeling of > > W-G. > > > > > First, I'd like to suggest some things which are not directly > > connected > > > > with the development: > > > > > * how about adding a simple startup message in the repository [1]? > > Instead > > > > of the default GettingStarted tiddler, add a breif intro about the > > plugins > > > > and links to them, so you don't need to attach the links each time and > > a > > > > visitor doesn't need to search > > > > * it seems it's time to update the Descrition slices in both> > > TWted/TWted.min and TWtid/TWtid.min (those are no longer about tables only) > > > > * I think it's better to specify what version of TWtid TWted needs (the> > > same, or not below, or.. you may specify this in the "Needs to have" slice) > > > > * the metadata table of the plugins being cut (see the screenshot 1) > > don't > > > > make them look better; in addition, when one tries to grab the > > scrollbar, > > > > he or she mouseovers it and the table jumps into the edit mode, so > > > > scrollbar avoids being cought :) (see the screeshots 2-3, red dot is > > an > > > > approximate posision of the cursor) > > > > ** in fact, I didn't get how to avoid this cutting and would like to > > know; > > > > as I pointed before, such behavior shouldn't be default > > > > > Those are good suggestions. After releasing 1.5.1 I shall spend some > > time > > > > on the documentation. > > > > > Then some notes about the new version. In fact v1.5.0 got very buggy. > > > > > 0. Online version works (there are some details, but that's not that > > > > important for now) > > > > 1. When I launch a TW v2.6.6 with TWtid.min/TWted.min v1.5.0, I get a > > > > blank screen (Opera 12.14, win7 x64) > > > > 2. When I launch a TW v2.6.6 with TWtid.min v1.5.0 with no TWted, the > > same> story > > > > 3. The same story in FF 19 (both variants) > > > > 4. In another testing TW (2.6.5, with SharedTiddlersPlugin 1.5.0 -- > > when I > > > > disable it, I get blank screen) things "work", but there are numerous > > bugs > > > > (no backstage, C/E buttons positioned in wrong places so that no > > element > > > > can be actually edited, encoding problems with non-latin letters after > > > > saving/loading...) > > > > > Honestly I did not test 1.5.0 with Opera and FF so I didn't know about > > > > these. The not-yet-released 1.5.1 does not have such problems in my > > system. > > > Maybe I fixed it somehow without knowing it? We'll see this soon. > > > > Regarding the "WYSIWYG": aside the cursor, I can see that a link is > > > > > previewed as a link when the cursor is outside its tiddlytext, > > previewed as > > > > [|[text|target]] when I get between "[[" or "]]" (!!) and parts of the > > > > "text" depending on the position otherwise (!). The (!!) part is very > > > > interesting behavior for a "WYSIWIG-like" way of editing, the (!), in > > > > contrast, is rather inconvenient. > > > > I noticed this behavior. It was caused by the "fake cursor", default to > > the > > > vertical bar (|), that I inserted to the caret position to mimic a > > cursor > > > in the previewer. This certainly affects the wikilinks because the > > vertical > > > bar is used to separate the label and URL of the link. I understand this > > > fake cursor must be changed to something else, but I haven't found a > > better > > > one yet. Any suggestions? > > > > > The last note for today is this: can the plugin for inline editing be > > > > based on hijacking the wikifier [2] and formatters [3] (or only > > > > formatters)? It seems (although I don't understand the alrogrythm > > well) > > > > that hijacking > > > > > Wikifier.prototype.outputText > > > > > can help with editing plain text.. > > > > Thanks for the note. Actually I tried this way when I was writing the > > > grandpa TableEditor, but soon gave up and turned to hijacking > > > refreshTiddler(). I couldn't quite understand the formatters, but it > > seemed > > > to me that I would need to abandon the original and rewrite a new one to > > > replace it (Am I right about this?). Hijacking the refreshTiddler() is > > easy > > > to implement but the cost is "double rendering": table cells with > > > multi-lined content are rendered twice, first by the system table > > > formatter, then the table renderer in TWtid. Currently it doesn't seem > > to > > > be a problem because it doesn't delay too much. However, to really avoid > > > this I would suggest the table formatter to have a cell handler, which > > the > > > TWtid can hijack to render the table cells with multi-lined content > > before > > > they get rendered by the system formatter. > > > > As for editing plain text in view mode, I am not sure hijacking the > > > wikifier or... > > read more » -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/tiddlywiki?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
