I'd be very happy to create some language sets. That I would know how to do.
UNICODE sets
Could be interesting, for instance (in combination with using online fonts where needed), to have a Unicode "keyboard" set for the hexagram block (http://jrgraphix.net/r/Unicode/4DC0-4DFF) or dingbats (http://jrgraphix.net/r/Unicode/2700-27BF)
BTC
At level of DESIGN-for-purpose I have two responses... I'm talking here about basic keyboard LANGUAGE issues.
1 - for DESKTOP users with real keyboards Minimalist Sets of Variant Accents (ONE line) would be very useful ... In THIS case the user has a bar of the minimal variants of a language that work alongside the keyboard. They don't need a full keyboard on-screen as they already have one. The example I gave before explains it better than words ...
2 - for SMART-PHONE users living in virtual reality a full-keyboard would be the way. But in this case you'd need a reason to replace the default keyboard that's adding something new. It looks complex to do that. I'll comment separately on that issue.
Ciao BTC
I looked at a bunch of discussions on "how to switch off/replace the default keyboard" on Android. There is a LOT of useful discussion of that.
Most of it is beyond me to understand.
My crude understanding is ...
1 - It can be done
2 - Its done via identifying/specifying the app. and providing alternative run options for the app.
3 - That's as problem if we talking TW within a browser as the browser IS the app.
I may be completely wrong as my grasp of this as I am Caveman --.
The one thing that is clear is you need is to ask this question on Android, not here.
Best wishes
Josiah
2 - for SMART-PHONE users living in virtual reality a full-keyboard would be the way. But in this case you'd need a reason to replace the default keyboard that's adding something new. It looks complex to do that. I'll comment separately on that issue.
For smartphones I just can't use the built-in keyboards for editing tiddlers. Or the screen gets resized so that you cannot see the tiddler anymore or you need to click and adjust the keyboard just to insert some characters in a comfy way.
@TiddlyTweeter:BTC
At level of DESIGN-for-purpose I have two responses... I'm talking here about basic keyboard LANGUAGE issues.
1 - for DESKTOP users with real keyboards Minimalist Sets of Variant Accents (ONE line) would be very useful ... In THIS case the user has a bar of the minimal variants of a language that work alongside the keyboard. They don't need a full keyboard on-screen as they already have one. The example I gave before explains it better than words ...But if your name is BTC and you're on linux with a convertible laptop and not many onscreen keyboards to choose from, you'll want this on desktop, too ;)
Point me to the entry system and i will be your slave.
BTC
Sounds good! Comments ...
- Given that each field holds an array and that the tiddler is just filled fields I was wondering if a data dictionary tiddler might not be just as good?
- To be able to emulate many European keyboards it would be brilliant if you could add Keyboard state key for AltGr and AltGr+Shift. The states are used to access characters like # and @ and € and in some countries accented characters. They would also allow emulation of some Mac key combinations too.
- Am I right in thinking that for the Json data Tiddlers you need a separate one for each line? Could get cumbersome?
I'll add AltGr. I'm thinking about how to make key combinations possible, I want to add them, still have to give it some thoughts
IF possible emulation of extant keyboard designs would be good. AltGr & AltGr+Shift would allow that.
Of course there is also great option to add a line for items normally under AltGr that could have normal Shift, rather than anything special.
In design terms on-screen keyboards have a flex physical ones don't. And being able to customise for ones actual usage is brilliant. But matching a physical keyboard a user already understands, however cumbersome, has merit.
1 - Make it double-click to launch.
It's easy to launch accidentally with single-click.
2 - Restrict the movement to the owning tiddler.
Downside: For new (empty) tiddlers this does mean it will completely hide the tiddler
3 - A way to close it from within somehow (addresses downside above).
Hi Coda,1 - Make it double-click to launch.
It's easy to launch accidentally with single-click.yes, then I'd like to make it configurable how to launch it, because the options are many: tapping (1/2/3/...times) or swiping could be the two favourites there
2 - Restrict the movement to the owning tiddler.
Downside: For new (empty) tiddlers this does mean it will completely hide the tiddleryou know, I thought about it. but it's nice to be able to view and edit it while editing another tiddler...I'll make this configurable, too
Hi Coda,1 - Make it double-click to launch.
It's easy to launch accidentally with single-click.yes, then I'd like to make it configurable how to launch it, because the options are many: tapping (1/2/3/...times) or swiping could be the two favourites there
Other option: give the textarea of the edit template a min-height = height of the entryPanel + N (where N is something like 2 lineheights so?)
1 - Make it double-click to launch.
It's easy to launch accidentally with single-click.yes, then I'd like to make it configurable how to launch it, because the options are many: tapping (1/2/3/...times) or swiping could be the two favourites thereSwiping is an obvious benefit on mobile/devices, sure.While I think of it, I saw a "gestures" lib somewhere I long time ago. Would be cool on desktop, too. Maybe if you stumble on it...
Eeek! Loss of keyboard! :-) And there I was researching character sets :-) FYI Re on-screen keyboards I responded to PMario's negative comments on GitHub here: https://github.com/Jermolene/TiddlyWiki5/issues/3111
This is very different but interesting & useful too.
Maybe when you iterate it next you might want to start a newly titled thread because the title of this thread is misleading. This is an editor-bar mod, not a keyboard?
I looked and played ... A few comments ...
_DOWNSIDES_ (Current)
POSITIONING: The gadget currently scrolls off-screen if you working and moving around in a long Tiddler (Firefox 52, Win64. Chrome latest Win). That kinda defeats the objective?
PERFORMANCE: If you have a VERY long Tiddler, like novel length, the performance is bad. Its okay for first invoke but not if need to re-invoke it a lot. That is likely to do with big Tiddlers not the gadget per se but it is a practical issue.
DESIGN: Visual position: I can't really see the advantage over a normal editor bar that was "sticky". IMO design-wise an editor bar that stays visible position at the TOP of the Tiddler as you scroll down (i.e. the Tiddler content scrolls under it and goes offscreen, but the bar remains in position) is an adequate solution that functionally extends TW. ALSO the right-hand positioning of the normal controls I think will be difficult to make work universally. It eats screen estate and currently conflicts with other settings like some side-bar widths (ask if you need more info on this).
SCOPE: I think there is an issue, a kinda conflict, between what it can give access to and the scope of an edit bar. To open that up ... take the example of Emojis ... there are dozens of them. Is it limited to one line? Say it could show 3 lines of Emojis, how might that impact the line being edited? Would it get hidden? I guess that opening a tab with multiple lines of symbols could be set to close after you selected on item?
FYI, in design terms I was interested in the "Keyboard" because it gave access to potentially hundreds of items. This, I think, maybe can't work so easily that way?
_MAJOR UPSIDE ++_
VISUAL INPUT: It gives a rich way to do what the Stamp tool does but in a visually direct way. That is a real upside. Particularly for character sets (I was thinking particularly of MINIMAL VARIANT CHARACTERS for European languages ... For instance, on standard Italian keyboards "@" "#" require special AltGr shifts, "tilde" is non-existent, and most irritating "curly brackets" are missing too) . Having such characters available on one click makes great sense for practical editing.
Hope this does not come over as negative. Its not meant to be. I think its a very interesting and potentially useful way with the editor.
Very best wishes
Josiah
ALSO the right-hand positioning of the normal controls I think will be difficult to make work universally. It eats screen estate and currently conflicts with other settings like some side-bar widths (ask if you need more info on this).
..I'm not decided about how this should look like from design aspects.
I like my approach more for having the fields, tags and type input fields accessible anywhere
are you using firefox?
J: Eeek! Loss of keyboard! :-)BTC: It's still also a keyboard like the first design was!
You just add a tiddler tagged $:/tags/EntryPanel and populate it with how many characters you want, there's no limit
FYI, in design terms I was interested in the "Keyboard" because it gave access to potentially hundreds of items. This, I think, maybe can't work so easily that way?
BTC ...
Further idea from someone inventing hard work for others to do 'cause he can't himself :-)
Suggestion, on open ...
1 - your editor bar opens at the top of the editing space & is "sticky". Tiddler slides under it if its long.
2 - but it also has a "move" glyph that that lets you drag it anywhere in the viewport you want where it will stay.
Just thoughts
J.
On Thursday, 15 February 2018 13:55:45 UTC+1, @TiddlyTweeter wrote:BTC .....I'm not decided about how this should look like from design aspects.
Suggestion... for the two presentational modes ...
1 - Mode 1 - have it IN editor fixed at top with the Tiddler under-scrolling as mentioned before.
2 - Mode 2 - as a re-positionable overlay float that keeps position relative to viewport, not tiddler. Similar to the emergent keyboard behaviour.
Just thoughts
Josiah