Hi Tobias,
On Thursday, March 7, 2013 5:52:59 PM UTC+8, Tobias Beer wrote:
>
> 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 are already done in the current release so I do not worry about
them. What's not yet is when the user changed the level of a list item.
Your suggestions below, and Yakov's some time ago, are very useful and
saved me quite some time. Thanks!
The refreshing problems I am facing are more technical than logical and
most of them I do have ideas how to fix or get around. I just don't have
time to get them done yet. I don't like to get you bored with technical
problems, only if you like to know:
- Determine the right part of innerHTML to refresh a list item.
- The current way I am trying to refresh the original element is to pull
out the innerHTML (using jQuery method .html()) from the previewer and
put
it to the original DOM element (also using .html()). It works fine for
elements with no levels or sub-elements. For a list item I see additional
bullets (<UL>) or numbers (<OL>) in addition to the original bullet or
number.
- *How to fix*:* need to find the level of item and pull out only the
correct part.*
- Missing sub-lists when refreshing the original list item
- Currently TWted handles edits the list item itself without doing
anything to its sub-lists. With 1.5.0 when you click on a list item with
sub-lists attached to it, you see an editbox containing only one line of
text (that defines the list item itself), and a previewer showing just
the
list item (without its sub-lists). When I refresh the original DOM
element
using .html(), the element gets refreshed for sure, but its sub-lists are
gone because the previewer does not have them.
- *How to fix: detach the sub-lists from the original element and
re-attach back after refreshed*.
- Well, let's skip the boring technical problems...
Yakov I suggest you to leave pre-1.5.1 along at this moment, for the
pre-release I put out was mainly to quickly show an idea of W-G-ish
behavior, it will not be the default behavior in the released 1.5.1.
>
> 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.
>
Actually I have been focusing on (A) instead of (B). I didn't think W-G is
possible with wiki style text before, so I started all these with this
"micro editing" (or partial editing as Yakov suggested) in mind. I didn't
even think of a previewer until Yakov suggested it. That pre-release of
1.5.1 was really a quick idea that popped into my mind when I was fixing a
bug recently. The bug was that I accidentally hid the editbox so I only saw
the previewer and the original element without the editbox. But I found I
was still able to type and the previewer was still updating, that gave me a
feeling of W-G-ish behavior. So I thought that might give some one a hint
how to do W-G thing with wiki text and decided to post a quick demo. I
guess it was too quick. :-)
>
> 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
>
> This I would like to try collaborating with QuickEditPlugin, as suggested
by wolfgang a while ago. It will probably start in v2.0... or maybe 10.0...
>
> 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 ;-)
>
Very well said! I do agree with you on these.
>
>
>
> 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?
>
> I should keep these in mind. Thanks. :-)
I like to see a programmer with a sense of an artist. Best regards,
Vincent
> 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.
