Hi @TiddlyTitch
Can you show me the screenshot of the error messages if you get them?
Thank you,
Simon
Is this difference in “grip bars” expected between browsers? …
Firefox on Chromebook …
… and Brave on Chromebook?
TT
IF it happens again I will!
The Chromebook has a Touchscreen, right?
1 Like
Yes. I’m using it now to write this.
given your awareness of this would it possible to save the cursor in the edit buttons solution?
with the save and keep open button we always loose the cursor position, this reduces the buttons value as one has to relocate where one was editing.
- I had come to believe it was impossible
- perhaps one day we could even restore the cursor from a saved offset when we return to edit a tiddler
this would be a great feature for those who spend time at the keyboard and have structured tiddlers. one real world example I faced was taking notes when in a class/training. if I did a safety save / commit I often had to reread the whole tiddler to find where I was, disrupting any flow state.
Hello @TW_Tones
while the issues you mentioned are in nature totally different than the problem I fixed in CSS, I think the text-operation “focus-editor” can be used to restore the cursor position to where it was before clicking those buttons.
Have a look at the functionality of the “preview” button. It restores the cursor position to where it was before clicking the button.
So similarily, the “save and keep open” button could do (if it’s an editor toolbar button) after all his actions:
<$action-sendmessage $message="tm-edit-textoperation" $param="focus-editor"/>
this is how the resizer should look like on a non-Touchscreen device
I’m detecting Touchscreen devices and make the resizer larger on them
Should probably be an opt-in option, or do you have an idea?
It has phenomenal NESTING …
Here I nested one of your examples in another to get a 5-grid …
Great stuff!!
TT
3 Likes
Definitely something a user can choose on in a setting?
Personally, even on a Touchscreen, I’m okay, mostly, with the standard more narrow bars.
But on very small devices (I.e. smartphones) I think it would be an essential first choice?
TT
I expect you will need media queries but remember we already have
| $:/info/browser/screen/width | Screen width in pixels |
|---|---|
| $:/info/browser/screen/height | Screen height in pixels |
and $:/info/mobile
1 Like
the screen width and height give incorrect values to me (I dont think it’s a TW bug as browserleaks.com gives the same - a 5% higher value than real - which smells a lot like an X11 setting that is adjusting for TV with a fake overscan. Otoh, my macbook (also Firefox) gives different screen sizes between browserleaks and TW’s info! 
(tangent: $:/info/node reports “no”, which is unclear if that’s incorrect because it is a node back-end here, or correct because it’s loaded in a browser - in which case I’m not even sure what that one is for)
Maybe to detect a mobile device correctly (or better a device without a mouse pointer or digitizer that can hover) we can use this media query (need to test it):
@media only screen and not (hover:hover)
Do you use Firefox advanced privacy protection settings? They fake screen dimensions -among other variables like timezone- which might cause these symptoms.
Just a guess…
[Edit]: just tried now on browserleaks, toggling advanced privacy settings doesn’t change reported screen/window dimensions, at least on my PC.
Fred
I have firefox’s privacy tracking protection set to strict.
However… Linux dual monitor setup, each monitor is 1920x1080.
Firefox reports 2016x1134.
Chromium reports 2015x1134
So… not a firefox bug? I wouldn’t put it past being a quirky X11 bug on my setup too, so unless someone else sees the same thing, prob not worth pursuing.
If this wonderful creation is not directly merged into the core, and you instead will only serve it as a plugin, then you may consider letting the user him/herself activate the plugin to overwrite the core tiddler instead of it being overwritten by default. I’ve used the user-activated approach for a few of my recent plugins and it has a few advantages. If your implementation is not merged, I’d be happy to elaborate more.
1 Like
Hi @twMat ,
I’ll separate the sidebar tiddler from the plugin but make it available on the page for who’s interested in overwriting the core shadow tiddler with it
Hi all,
I’ve updated the plugin to version 0.4.7
- no core tiddler overridden anymore
- a different media query so that only on touch devices without
hoverpossibility the large resize handles are shown (@media only screen and not (hover: hover)) - improvements for the
resizable-table- but only for thewikitextTableattribute
Best wishes,
good night,
Simon
3 Likes