[Proof of concept] Tiddly Onscreen Keyboard

[BurningTreeC]

Hello community,

I'm making an onscreen keyboard and I've put a proof of concept onto http://muritest.tiddlyspot.com - it's accessible in all views in edit mode

I'd need a little help, if you're interested in such a tool

cheers,

BurningTreeC

[@TiddlyTweeter]

 Ciao BTC

Nice idea.

Early feedback. On Win 7 Firefox 52 64bit. (1) The keyboard appears over the edit area and you can't move it. (2) Too much transparency ...

 

Best wishes
Josiah

[BurningTreeC]

@TiddlyTweeter,

thanks, this is in muuri view, there I need to tinker it a bit to fit better.

how is it in the normal view?

thanks for your input,

BurningTreeC

[@TiddlyTweeter]

BTC

Teething problems ...

On both desktop Win7 FF 52 64bit &  Chrome latest, the keyboard icon does NOT show up except in TiddlyTouch mode ... standard mode the editor does not display it. 

Best, J.

[BurningTreeC]

thanks, in the normal view it should show in the bottom right page corner. I'll investigate

[@TiddlyTweeter]

BTC

NO it IS THERE. I just didn't see it because I was expecting it to behave the same in both modes.

My apologies for not noticing--however, my overlooking it may indicate a user design issue?

Best wishes
Josiah

[@TiddlyTweeter]

The "normal" mode Keyboard in the test I just tried worked well. BUT, like the other you can't move it.

A few comments.

1 - It doesn't need to be so big? The character size to key size in what I saw (Win FF52 64 desktop) was small characters, large keys ...

2 - I looked at the configuration Tiddler which looks AWESOME ...


I'm sorry I can't help you code for improvements. I just can't code.

Best wishes
Josiah

[@TiddlyTweeter]

Question:  Can you use this mechanism for ad-hoc assemblages of characters? I noticed in a config tiddler (I can no longer find) that seemed to indicate you could have ANY character on the keyboard AND that you could actually change layout (nos of keys?)

Just wondering.

Because if it could do that it could open a world of possibilities.

Here are two use cases so you know what I'm talking about...

1 - I use an Italian keyboard for everyday work. But sometimes I need to write using symbols that are NOT on the standard Italian keyboard (tilde is one). So I was thinking this gizmo might allow me to ADD certain characters I need to use that are NOT on the keyboard. Currently I use an external mini-app for that.

2 - Could it be used as a panel for EMOJIS? The web standardly now supports an emoji set across all bowsers.

Hope I'm not racing ahead too fast :-(. But the potential looks great!

Best wishes
Josiah

[BurningTreeC]

thanks @TiddlyTweeter,

the design is exactly where I need help for making decisions. Also - on mobile devices, where this could be used more - the standard mobile keyboards do make the wikis too small to be able to seriously edit tiddlers. I'd like to change that - I don't know if it's possible to prevent the default keyboard showing up on android/ios...

Then maybe someone has an idea for

1) how to get a newline character into the editor

2) how to handle a button like shift - do we have a toggle on / toggle off button?

3) how to handle a button message repeat for the buttons to be able to hold them?

4) how to get a tab-space into the editor - I'm just adding 4 spaces right now

It's possible to make different layouts - compact - split layout - .......

And different layouts for different languages

BurningTreeC

[BurningTreeC]

yeah, you can do all that - emojis, characters, whatever you want - code snippets, placeholders

you could make your own keyboard rows and put there whatever you want 

[BurningTreeC]

I was already thinking about an emoji button to switch to emoji selection

greek characters

special characters

<$button></$button> snippets (and more for all standard tw widgets)

more ideas welcome

[@TiddlyTweeter]

Just for ideas ...

Minimalist variant accent sets ... for years I have used a mini-app that works with any text entry program where you need to enter language specific variants not available on the keyboard. Here is a screen shot to show how elegant it is. All characters are definable. You can have as many as you need.

Your tool sounds like it can do the same kind of thing natively in TW.

IMO a range of "language bars" could seriously improve TW's uptake for multilingual work.

Best wishes
Josiah

BurningTreeC wrote:

[Mark S.]

I use the Null Keyboard app for suppressing the popup keyboard when I have a physical board attached. Not sure how it works when no keyboard is attached.

-- Mark

[Mark S.]

I use AutoHotKey with a small script to make my non-ascii characters. So I don't need to pick them off a form. For instance, I type Cx for Ĉ, u"" for ü,  n'' for ñ . Of course that doesn't help on devices, but there are many keyboard options on devices.

-- Mark

[BurningTreeC]

@Mark,

thanks for the tip with the Nullkeyboard app, I'll try that

I guess there may also be keyboards that can float on the screen, but I'd like to see how a tw solution would work.

[@TiddlyTweeter]

Ciao BTC

IF this things develops so you can create "sets" of characters/i.e. multiple available "keyboards", each with their own config, I'd be very happy to create some language sets. That I would know how to do.

Best wishes
Josiah

[BurningTreeC]

@TiddlyTweeter,

that's great! Do you have ideas for how such a keyboard scheme should look like for you?

the currently used scheme is just a fast thing, I'd like to establish a scheme but I haven't had time to think about it

your proposals are welcome!

BTC

[@TiddlyTweeter]

BTC

More ideas ...

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)

Best wishes
Josiah

BurningTreeC wrote:

[BurningTreeC]

@TiddlyTweeter,

I'd be very happy to create some language sets. That I would know how to do.

that's great! Do you have ideas for how such a keyboard scheme should look like for you?

the currently used scheme is just a fast thing, I'd like to establish a scheme but I haven't had time to think about it

your proposals are welcome!

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) 

I don't know much about these sets, but should be easy to implement by users if we have a scheme - maybe with a scheme editor accessible from within the keyboard under "keyboard settings"

BTC 

[@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 ...

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.

3 - IF the architecture allows it (looking at the config file and it looks very easy, in principle) then it would be a doddle (very easy) to create many variants.

Best wishes
Josiah


BurningTreeC wrote:

[@TiddlyTweeter]

FYI, Unicode support in modern browsers (i.e. font rendering) is far better than most users realise. We have a VAST library of characters and symbols a Unicode away.

[BurningTreeC]

Am Freitag, 9. Februar 2018 13:15:12 UTC+1 schrieb @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 ;)

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]

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 a 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

[BurningTreeC]

Am Freitag, 9. Februar 2018 13:51:53 UTC+1 schrieb @TiddlyTweeter:

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

yes, it can be done - I've investigated it, too. but as you say this is not the forum to discuss this and it's a user decision.

[@TiddlyTweeter]

Ciao BTC

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.

I totally agree. The idea smart-phones are smart was invented by a marketing department. They are awful to use to CREATE from. They are best for clicking boxes.

IMO you are on a Big Fight to bring sensibility to Android keyboarding.

J, x

[@TiddlyTweeter]

BurningTreeC wrote:

@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 ;)

Let a THOUSAND layouts bloom.

J.

[BurningTreeC]

They will.

To J. : Let some language sets bloom 

[@TiddlyTweeter]

Point me to the entry system and i will be your slave.

[BurningTreeC]

Point me to the entry system and i will be your slave.

When there is one I'll post it here, thanks for your help!

[BurningTreeC]

@TiddlyTweeter & @all,

a possible scheme for creating keyboard layouts:

• a new tiddler, tagged $:/tags/something, holds everything in its fields
  
• create a field "row-1-small" for the first row and the keys you want to have in the first row when caps-lock isn't set
• create a filed "row-1-small-alias" if you want something else than the keys itself displayed on the keyboard buttons. if this field doesn't exist, the keys themselves will be displayed on the buttons
• provide an alias for each key, in the row-1-small field's order
• repeat this for how many lines you want to add
• row-1-big and row-1-big-description - for the first row's keys when capslock/shift and so on for row-2/row-3...
• provide a field "keyboard-controls" and select which control buttons you want to add
• can be: backspace, return, space, capslock, shift, save, cancel, tab
• move and abc will always be added
• if you want to add new-lines with your keys or other special characters that are not possible to represent in a tiddler field, you can add a field "row-1-small-json" and insert the title of a json tiddler where you can insert your keys with new-lines and other characters:
• new-line: \n
• double quote: \"
• tab: \t
• and others, google for regex
• the index-name in the json file must be the alias you set in the row-x-alias field. Using a json-tiddler the alias-field is needed, if you don't use a json tiddler, you don't have to add this field.
• That should be it

If you have suggestions for a better scheme, don't hesitate to comment and/or provide some examples, I'd appreciate!

functional updates: 

• the keyboard on http://muritest.tiddlyspot.com now can be moved all over the screen by dragging the top left move-button
  
• the backspace, return and space buttons can be held to do their action multiple times. it uses the pan widget, that's why you'll have to move the cursor a bit while keeping the mouse button pressed (drawing small circles works fine) - I think I'll use the press widget for this when it's done - then it should work like keeping a keyboard button pressed.

BTC

[@TiddlyTweeter]

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?

Great stuff!

Best wishes
Josiah

[BurningTreeC]

@TiddlyTweeter,

Am Samstag, 10. Februar 2018 20:34:07 UTC+1 schrieb @TiddlyTweeter:

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?

you're right, we only need a json tiddler for storing the keys.

the fields should hold the aliases 

- 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.

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

- Am I right in thinking that for the Json data Tiddlers you need a separate one for each line? Could get cumbersome?

My description  is not clear enough about that. You can have all keys in one json tiddler.

[@TiddlyTweeter]

BTC

Just by way of background here are some NOTES ON FONTS. They don't change anything you are doing. But I thought you might find it useful ...

Being able to render some languages so you don't get "tofu" like ...
 
... you need to add the font needed.

To know what extra fonts are needed I will make a table of the default fonts in TW to see what they cover.

WebFonts that Google has been advancing are a good solution. In particular the NOTO font-family (link) that is aiming to cover the full Unicode in a way with consistent style. They also have OTF font file versions that can be downloaded for offline use.

Its not currently possible to have a single fully complete all-Unicode font. Unicode runs to thousands upon thousands of characters. Font file architecture is limited to thousands.

The design issue would be to provide access to the font needed for a specific keyboard layout not supported by the standard fonts in TW.

In Tiddlywiki one can add online fonts easily. A method is described here:  https://ibnishak.github.io/Tesseract/UI/index.html#How%20to%20use%20google%20fonts%20in%20TW5. Its involves (1) a link to the font in the header (2) addition of the font to the stylesheet.

Some keyboard designs will need fonts adding, one way or another. Its fairly easy if a webfont exists for it. Most keyboard characters ARE covered for most languages in one webfont of another.

Best wishes
Josiah

[@TiddlyTweeter]

BTC

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.

Once the architecture for constructing the keyboards is a bit clearer I can make some demos.

Best wishes
Josiah

[@TiddlyTweeter]

BTC

I wrote a note on GitHub concerning the font support issue

https://github.com/Jermolene/TiddlyWiki5/issues/3111

Best wishes
Josiah

[BurningTreeC]

@TiddlyTweeter,

 

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. 

I agree with you!

About the fonts:

As I understand it, the standard fonts list in TiddlyWiki covers some of the most commonly used fonts. So every user should already have at least one of them installed on its system (knowing or not) so that characters get rendered without having to include a font into a TiddlyWiki html file.

The font-stylesheets inside tiddlywiki are for fonts one wants to provide to users that possibly don't have them on their computers. Like Fontawesome, material icons, special emojis, or just some less-used fonttypes.

As far as I know, TW doesn't come with integrated fonts but I could be wrong.

-------

for creating a keyboard layout that uses special characters the solution would be one of two:

a) searching a font and include it in a stylesheet that users need to drag to their wikies

b) adding informations about which font to install on their system to be able to render the characters

I would prefer b) if I'm the user - it keeps the file small - fonts are heavy

BTC

[@TiddlyTweeter]

BTC

TW does not come with inbuilt fonts (rightly IMO). It just uses the normal CSS method of a cascade of font-families to ensure there is at least one basic font on the computer that works.

Slightly unusual is that the cascade includes the DejaVu font for both proportional and monospaced fonts. Its good in a way as DejaVu has a very large character set that covers most languages in Unicode well. But few people will have that on their computer so can't benefit without downloading it.

For some situations additional WebFonts can help.

For most European situations the TW cascade will activate available fonts on computer that should suffice. Get beyond Europe and it is another story.

Josiah 

[BurningTreeC]

ah, now I get your point. I've read your github issue, could you clarify that a little bit so that it's clear what you mean?

BTC

[@TiddlyTweeter]

I know its a bit of a mind bender :-)

Partly because we don't know what fonts are on which users computers.

I'm in midst as looking at the fonts in the standard CSS cascade for TW to see what the Common Reliable Core is (i.e. if you only had one of them actually on your computer what is the minimal set it would share with all the others?) That would show what languages can be reliably keyboarded without any additional fonts.

Get it?

Regarding the GitHub point: Say one wants to give a keyboard in Canadian Aboriginal (https://www.google.com/get/noto/#sans-cans) you'd likely do best using the webfont. Its not so difficult. But there is a kinda methodology missing at the moment to make it as easy as it could be.

Hope this is a bit clearer?

Best wishes
Josiah  

BurningTreeC wrote:

[BurningTreeC]

@all

From playing around with the initial keyboard design I came to a new approach,

you can find it here: http://entrypanel.tiddlyspot.com

It's almost done and I'd like to get some critics, would you like to use it, what would I have to change to make it better?

How should it be styled?

best wishes,

BurningTreeC

[coda coder]

Hi BTC

Interesting.  Some thoughts...

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).

Coda

[BurningTreeC]

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 tiddler

you 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

3 - A way to close it from within somehow (addresses downside above).

you're right, I'll make a button for that

thank you Coda!

BTC 

[coda coder]

On Wednesday, February 14, 2018 at 9:22:24 AM UTC-6, BurningTreeC wrote:

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 tiddler

you 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

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?)

[coda coder]

On Wednesday, February 14, 2018 at 9:22:24 AM UTC-6, BurningTreeC wrote:

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

Swiping 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...

[BurningTreeC]

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?)

Great idea! I'll do that  

 

 

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

Swiping 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...

 

With my swipe widget you can swipe with mouse or fingers -  

[@TiddlyTweeter]

Ciao BTC

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

[BurningTreeC]

Ciao Josiah, 

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

oh no creativity there .... I'm playing around, come on  :D 

but that's no problem, I make concepts which not always make sense but I explore them anyway

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

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 will do when the design is settled 

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?

klicking the right or left space hides it and clicking again brings it back where you clicked - so if it scrolls off screen you don't have to search for it, just click it back 

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.

hm, I'll have to try that out - are you using firefox? 

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).

that's true. if it's only for the bar then a sticky bar on top would do it.

I like my approach more for having the fields, tags and type input fields accessible anywhere 

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?

No limit for how many emojis you want to add - only the number of available emojis

Have you seen that the panel can be shown at the right side of tiddlers? There's a Settings tab

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?

This still works the same 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.

No this is good! I'm not decided about how this should look like from design aspects. I can't say that I like how it looks :D

I'm playing around to see how this can add functionality and if it's worth something 

Very best wishes
Josiah

BTC 

[BurningTreeC]

about PERFORMANCE:

I've seen that having certain sidebar tabs open affects the panel performance A LOT, a real LOT

Like the Recent Tab or the More Tab.

I guess that avoiding certain widgets like the list widget for creating the panel could improve performance but I really can't tell what exactly causes that behaviour that the performance drops that much when certain sidebar tabs are open....

[BurningTreeC]

@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).

the positioning of the controls is just a small setting in the stylesheet tiddler. I'll add a setting  in the Settings tab

[@TiddlyTweeter]

Right. Performance is a broader issue. Its being debated elsewhere and some steps already taken in the current pre-release.

From MY point of-view having to bend-backwards to squeeze it better is okay for developer mind, but its not for the average user. So its a bit of a limit as is in some circumstances.

Best wishes
Josiah 

BurningTreeC wrote:

[@TiddlyTweeter]

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

 

[@TiddlyTweeter]

BTC ...

I like my approach more for having the fields, tags and type input fields accessible anywhere

Right. Agreed. Its very useful.

J.

[@TiddlyTweeter]

BTC ...

are you using firefox?

Both FF & Chrome. Chrome on VERY long tiddlers (whole text of Robinson Crusoe) IS more responsive that FF, though still sluggish. BUT I'd need put that in context as my FF 52 (not-multi-process) is running zillions of tabs. I could test further to differentiate but past experience tells me TW can get sluggish when you have a gizmo that needs additional rendering in edit mode things slow down whatever the browser.

J.  

[@TiddlyTweeter]

BTC

Follow up on KEYBOARD. Looking at the configuration it doesn't look like it could home a keyboard to me (i.e. visually emulating a physical keyboard). Rather it looks like CHARACTER SETS of any kind could be done BUT there are (1) no Shift States, and (2) Layout of keyboards (i.e.lines that match physical keyboard layouts) is not possible?

Or have I misunderstood?

J.
 

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?

[@TiddlyTweeter]

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.

[BurningTreeC]

@TiddlyTweeter,

thanks for your feedback and ideas!

I may come back at a later point to these experiments as I decided to focus on getting a new MuuriTouch version out

My adventures in playing around with what I learn from that pluginning will surely lead to more funny things

On Thursday, 15 February 2018 15:42:29 UTC+1, @TiddlyTweeter wrote:

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

 

I'll have to give this some thoughts and see where it can lead

all the best,

BurningTreeC