Bug hunting and feedback on sidebar resizer Pull request

Developers
#1

Hello Tiddlywikians,

I want to ask the community for help if someone’s interested as this pull request is difficult to get right.
With this pull request I’d like to add a resizer that changes the width of the story-river / sidebar and a resizer that changes the width of the tiddler editor / preview.

Here’s the preview of the current state: https://deploy-preview-8663--tiddlywiki-previews.netlify.app/

What I’d be interested in is bug reports and feedback.

  • Is there a strange behavior, something that irritates you?
  • Does something not work as expected?
  • Are there jumps during drag - especially in edge cases like when reaching the maximum width or minimum width?

What needs to be taken into account is that fluid-fixed sidebarlayout and fixed-fluid sidebarlayout work differently and fixed-fluid is by far more complicated as it uses more metrics and the inner calculations therefor use more variables.
That’s why fixed-fluid mode needs more testing, but fluid-fixed mode should also be well tested.

You can also change themes in the Control Panel and test if everything works as expected also with the different themes like tight or centralised.

What should also be tested is the behavior when the sidebar is at the left - you can set that in the Control Panel > Appearance > Theme Tweaks > Sidebar position.

There are also adjustments for html dir="rtl" … to test this, you could open the developer console and add dir="rtl" to the wiki’s <html> tag.

What I hope is that this PR is useful and could in some form make it into the core.
There are some discussions about pointer capture which has the potential to make some parts easier and more performant but big parts of this PR can be seen as groundwork for a potential future solution.

Note that everything in this PR is pure wikitext without changing any Javascript.

Thank you for your interest, your comments, bug reports and feedback,

Simon

4 Likes
#2

And I’m the first one with a bug report:

On small screens the tiddler editor isn’t shown at all. Easy to fix but big ouch :smile:

#3

Fixed: tiddler editor not shown on small screens.

Preview updated within 2 minutes

#4

Hi @BurningTreeC

Tested on Linux with Firefox (latest) and Vivaldi (latest), on a typical desktop workflow, and everything works as expected.

  • Resizing is smooth, even with a crowded Story on an 8th generation mi-range core-i7 CPU.
  • When resizing, if the cursor exits the window the drag operation is ended and doesn’t resume when entering the window back (mouse button still held down), but I wouldn’t call this a bug.

Overall I love it and I support the request to make it a core feature, especially as a 100% wikitext component!

Please ask if you want some more directed tests on Linux, I’ll be glad to help.

Fred

1 Like
#5

Hi @tw-FRed

Thanks for testing, I’m also testing on Linux :slight_smile:

Arch Linux + Firefox and Chrome here. Very nice that it also works on Vivaldi!

That is expected behavior, there’s a pointerout and pointerleave detector that stops the drag-process immediately

There’s nothing that should work differently on Linux than on any other OS. I’ve noticed that on my Linux Desktop it works smoother than on my same Desktop in a Windows session.

Simon

#6

For anyone who wants to test a crowded Story, here is some wikitext that will open the 100 latest modified tiddlers by the click of a button:

<$button>
Go!
<$list filter="[!is[system]has[modified]!sort[modified]limit[100]]">
<$action-navigate $scroll="no"/>
</$list></$button>

You can change the [100] part at the end of the filter to increase/decrease the tiddler count.

Fred

1 Like
#7

Thanks @tw-FRed

your “100 last modified tiddlers” list made me test the editor-preview slider under heavy conditions and change the styles applied to the different pieces being applied through the stylesheet so that I can throttle the refresh of the UI also in these cases.

Within 2 minutes the preview should be updated with these changes

1 Like
#8

Super smooth on Win10 Firefox.

1 Like
#9

I was using abs() to calculate metrics in fixed-fluid mode but saw that it doesn’t work cross-browser.

The solution is to use max(value, (-1 * value)) which gets the absolute value and works cross-browser.

Now also Chrome user can test :smiley_cat:

#10

Wow,
to get it right: Is this is meant to become a core feature… usable in other Layouts and themes (like multicolumn) ?
That would be great !!! I would like to have it immediately!

#11

Hi @JanJo

Yes this is meant to become a core feature
It is build so that other themes can use it

3 Likes
#12

Thank you @BurningTreeC
I assume a minimum meaningful width for tiddler should be set, so like maximizing the storyriver to a maximum width, resizer should respect a minimum width (perhaps this minimum can be set through some config tiddler/field).
The minimum here can be 320px to have a tiddler title and toolbar button visible at one or two lines

#13

Is there a setting/configuration tab under $:/ControlPanel → Settings?

#14

Hi @Mohammad

The settings are all in the Control Panel under Appearance > ThemeTweaks

1 Like
#15

At this point of testing maybe users could test the various metrics that are possible to use in the Control Panel > Appearance > Theme Tweaks tab:

  • percentages (%)
  • pixels (px)
  • inch (in)
  • centimeters (cm)
  • millimeters (mm)
  • quarter-millimeters (Q)
  • picas (pc)
  • points (pt)
  • em

see: CSS values and units - Learn web development | MDN

The inner calculations can handle all these metrics.
First, every value gets converted to pixels, then all the calculations are done, and in the end every value gets converted to its original metric.

The tiddler width in fixed-fluid mode can handle percentages, too. Those percentages need to be calculated in regard to the story-river width which makes it a bit more complicated.
Therefor I invite everyone to test changing the sidebar layout to fixed-fluid, setting the tiddler width to a percentage value and see how it gets updated.

#16

It workslike a charm for me on Opera browser on Mac OS.
Thankyou !

1 Like
#17

Thank you @Thomas_Chuffart

Glad to hear that it works well for you.

I’d like testers to go crazy with the metrics, set them to unrealistic values, and see if they can break the thing.
I’m currently doing so and am finding edge cases that need to be addressed.

#18

Love it! I always set up something like this on my sites early on. Glad to see it’s on a path to be in the core, and to pick up on palettes etc.

For experienced author use, I think it’s fine to have the line be transparent until hover.

For web visitors and beginners, it’s helpful to have some unobtrusive very light (maybe alpha-reduced translucent) line in place, to draw the hunch that there’s a threshold there.

Or maybe even a muted iconic cue like

⇠|⇢

near the top, to help the visitor/user to recognize there’s a resize affordance there.

#19

Hi @Springer

Is it really transparent? I thought it was just opaque, maybe too much…

The line is in fact alpha-reduced / it has opacity even on hover. But maybe too much? What do you all think?

It’s a good idea but for me personally too much clutter, I wouldn’t want this. But let’s hear what others say :+1:

Thank you!
Simon

1 Like
#20

The line becomes visible on hover (but only on hover), for me, and seems to have muted foreground color. Until hover, it’s not visible at all. (Not sure what you would mean by opacity “even” on hover, when of course we’d expect it to be fully visible? Do you mean non-1 opacity specification, something less than full opacity, even on hover? That doesn’t seem to be the case on my view.)

Another thought is that a horizontal-drag-hint icon might itself helpfully come into view only on hover (as an option). That would clarify what the line’s sudden visibility means … again, thinking of new users/web visitors.