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.
