Hi Tobias, actually, there's already a thread for TWtid/TWted/TWcalc [1] (I've even mentioned in the WYSIWYG discussion), why create another one? Sure, if you propose some code parts, that's more dev stuff, but when discussion is splitted bewteen several threads, it becomes harder to follow and understand.
Best regards, Yakov. [1] https://groups.google.com/forum/?fromgroups=#!topic/tiddlywiki/0FT6iBneYOk четверг, 7 марта 2013 г., 13:52:59 UTC+4 пользователь Tobias Beer написал: > > Hi Vincent... > > This is what I was heading. As I was trying I found some of the elements >> are easy to be refreshed, while others not, especially those with >> "sub-elements of the same type" (like sub-lists in a list or >> sub-blockquotes in a blockquote). So the current solution is to wikify the >> text in a preview panel and leave the original element untouched until >> changes accepted. I am still working in this direction and hopefully a good >> solution will come out soon. >> > > Can you give some more details on what exact approach(es) you tried for > refreshing the existing dom and some details on the kind of problems you > were facing? > > Headings seems (somewhat) straight forward to me, as all you need to do is > increase the level, e.g. > > Assuming we know it's a heading and someone used either of tab (to > increase) or shift-tab (to decrease)... > > level = parseInt( $h_old[0].nodeName.substr(1) ); > > if(ev.shiftKey) level = level > 1 ? level -- : 1; //previous level > > else level ++; //next level via tab > > $h_new = $('<h' + level + '/>').hide().insertAfter( $h_old ); >> $h_old.children().appendTo( $h_new ); >> //TODO reset the input focus / rerender it appropriately >> $h_old.remove(); >> $h_new.show(); > > > Trying to imagine this, as you can see from the TODO comment above, I > could think that your editor might lose focus of where you were last > editing. Would that be one of the problems you were facing? But then how is > that different from a <b> in a <span>? Seems the same trouble of finding > the right spot for rendering the input element focus. Also, if the actual > input would be *inside* the heading, then it would have moved with it > over to the new heading... and returning focus to it might be all that is > needed, if even. > > > Lists would probably go down a slightly different route. You would need to > inspect for... > > 1. the outer ul / ol > 2. any preceding li > 3. any following li > > And provide means to... > > 1. give the user a simple way to decide on an (allowed) list type of > the current item > - although items that the level should always be of the same type > - mixing types in the same indentation makes little sense (to me), > e.g... > 1. a > 2. b > - x > 1. c > - y > - the above are entirely new lists of their own type, obviously > 2. let the user indent / outdent using tab and shift+tab > - this must consider the type of the preceding element > - outdenting should be restricted to one level highter than the > previous > - TiddlyWiki can't handle anything else either > - although I would argue that this rather is a bug (/ missing > feature) [1] > - the following li may need to be rerendered into the right list > - altough as a first guess, it should remain as it was > - unless we had a means to select and move multiple lines at once > - which seems a very complex issue that I would avoid > 3. add a new list item! > > > So from my perspective it really boils down to starting with one > individual feature and getting it right and then move to the next... not > try and achieve all at once. > > > I am very glad to receive constructive comments, especially when they are >> long. That means you had spent a lot of time trying and writing, and that >> tells me you think it could be useful. I am very thankful for that. > > > I'm really glad you take it that way... I tend to criticise much an that > can have a discouraging if not annoying effect... neither of which being > intented. > > > My opinion is they (a and b) are possible, at least a good part of them. >> It's not yet, but will be. > > > When developing stuff, it's good to tocus on a desired core functionality > and doing so with one (prioritized) feature at a time. Right now, I would > say that TWted tries both of a) and b) and I find that to be a problem. So, > do you have plans to... > > - A) focus on Wiki Format (=a) and entirely take b) out of the focus > - B) focus on WYSIWYG (=b) and entirely take a) out of the focus > - C) make the mode switchabe, but not in the fiddly 'live' way that it > currently is, but rather as a global setting > > I guess focussing on B) is what you seem to be been after mostly ...at > least, that probably involved the most effort. > > Beyond of what I have seen so far, a formatting toolbar (not unlike the > one in newer versions of MS Office) above or below the editor might be > helpful in either case, e.g. which gives you some of the usual rtf editing > buttons... but obviously handle them differently in a) or b)... so you can > click on the desired format, instead of having to know that you can press > '' and things start to get bold... but that's probably a feature for > version 10, not version 1. > https://ssl.gstatic.com/editor/editortoolbar.png > > > Either way, there probably are some edits that need sanitation, for > example while semantically I can do this in html... > > 1. level 1 > 1. level 1.1.1 > 2. level 2 > > ... I really can't do this in TiddlyWiki as... > > # level 1 > ### level 1.1.1 > # level 2 > > ...will not work. So some 'sanitation' may always be needed to eventually > save consistent wikitext that doesn't get swallowed. > > > Many of your comments are from the editor's point of view instead of the >> coder's. They are showing me good directions. I like them! > > > I think it's crucial for ALL software to have the user perspective be the > #1 priority and spokesperson, not what is technically possible and how. Of > course there always are constraints, but all of them eventually have > implications on the user perspective, e.g.... > > - if a system was too expensive, it's not a business problem > - its the user not bying it > - if the server or client would take 10 seconds to commit an edit, > then it's not that the machine is to slow and the required hardware too > expensive > - it's the user not using the software because it is unresponsive > - if its hard to use the software its not necessarily a lack of or > poor quality of its documentaiton > - its the user (rightfully) refusing to learn stuff that is hard to > use > > Always look from the user perspective first. Now, I start to sound like > someone in TRON and I hated that movie, hail the users ;-) > > > I understand many of them are confusing, some of them confused me, too. >> It's still primitive and under development, many of them will be fixed >> along the way. > > > I think what you have accomplished neither is primitive, nor broken... it > just is, and as such rather complex and feature rich ;-) ...although there > is such a thing as 'featuritis'. So, from my mindset, the eventual piece of > art - and I am positive that it will see the light of day - is when you get > to discard all the distracting bits and reduce the thing to the very > productivity-enhancing essence... like some artist and a handful of strokes > expressing so much that you cannot but stand in awe ot the creation... > https://www.youtube.com/watch?v=JFSB3-SzgoQ > > Just to complete the picture, there also is the other end of the scale, > some form of 'simplicitis', e.g. when things are reduced (for whatever > constraints) to a barely usable feature set, like the mail apps that ship > with windows 8 or good old ms paint that far outlived its deserved > half-life. But then again it's the user saying: 'Why on earth would I use a > software that comes with such a reduced feature set while easily > accessible and far more productive alternatives have been available for > decades? > > Cheers, Tobias. > > > [1] Test this in a tiddler... > > # 1 > ### 111 > * a > *** b > # 2 > * b > -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" 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/tiddlywikidev?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
