Publisher 2.6.0 Mac: Not respecting system settings for Scrollbar behaviour.

[mattspace]

I have my system's scroll settings set to:

Click in the scroll bar to: Jump to the spot that's clicked.

Publisher does not follow this behaviour. Clicking in the scrollbar merely jumps the document a number of pages in that direction, it does not jump the entire document to put the scrollbar handle in the place the user clicked.

[thomaso]

By the way, this issue seems to affect only the layout scroll bar (“Document View”), while the scroll bars in Panels take a specific click position into account.

[MikeTO]

I didn't know this macOS setting existed. Now I want it. 🙂 

[mattspace]

1 minute ago, MikeTO said:

I didn't know this macOS setting existed. Now I want it. 🙂 

Really? It's been there for ever. I think it even predates Mac OS X.

[MikeTO]

I've switched back and forth between Mac and Windows so many times that I tend to remember only the features common to both platforms.

My brain is also still stuck in System 7.

[mattspace]

4 minutes ago, MikeTO said:

I've switched back and forth between Mac and Windows so many times that I tend to remember only the features common to both platforms.

My brain is also still stuck in System 7.

haha, It might actually be a System 7 feature - one of those crazy UX things that predates proportional scroll thumbs (which I think were Sys 7.5, or 7.6).

[thomaso]

2 hours ago, mattspace said:

It might actually be a System 7 feature

Do you remember which control panel? Apparently not the mouse. – Clicking the scroll bar doesn't jump to an according position; it scrolls all the way. Note, the scrolling direction is still different, not 'natural'. – And, even nowadays users may miss a scrolling option: https://discussions.apple.com/thread/255168532

[mattspace]

2 minutes ago, thomaso said:

Do you remember which control panel? Apparently not the mouse. – Clicking the scroll bar doesn't jump to an according position; it scrolls all the way. Note, the scrolling direction is still different, not 'natural'. – And, even nowadays users may miss a scrolling option: https://discussions.apple.com/thread/255168532

I think that's an earlier version than I'm referring to (looks to be system 6, at the latest). My first fulltime machine was 7.1.2, but I think it was 7.5 or 7.6 that introduced it.

The whole natural vs (the alternative) scrolling thing is a bit of a misnomer - it should have been called direct, and indirect scrolling. The modern direct way, your trackpad swipe, or scroll wheel are moving the content itself, pushing and pulling it around directly. The older, indirect way, your input device is moving the scrollbar, which is then winching the content up and down, like a window's sashcord, hence the direction reversal.

[R C-R]

6 hours ago, thomaso said:

By the way, this issue seems to affect only the layout scroll bar (“Document View”), while the scroll bars in Panels take a specific click position into account.

Could you clarify what you mean by "the layout scroll bar" and/or "Document View"? I'm sure I'm overlooking something that should be obvious but I can't seem to find anything in APub V2 that has that name ... or any place (so far) that does not respect the system 'jump to' setting.

[thomaso]

2 minutes ago, R C-R said:

"Document View"?

https://affinity.help/publisher2/English.lproj/index.html?page=pages/Workspace/interface.html&title=Interface Visual Reference

As the OP pointed out, the Affinity scrollbar reacts different on a click than the macOS Finder or a browser app for instance. Unlike the latter, Affinity may require multiple clicks on the scrollbar to jump to the beginning or end of a document.

[R C-R]

27 minutes ago, thomaso said:

Unlike the latter, Affinity may require multiple clicks on the scrollbar to jump to the beginning or end of a document.

Thanks. This seems to have something to do with the document window space being bigger than what actually is needed to display all of its content. So if I manually drag the scrollbar to the top or bottom of the view, & the zoom level is high enough, then there is a lot of empty space above or below the pages, artboards, or whatever.

[mattspace]

6 hours ago, R C-R said:

Thanks. This seems to have something to do with the document window space being bigger than what actually is needed to display all of its content. So if I manually drag the scrollbar to the top or bottom of the view, & the zoom level is high enough, then there is a lot of empty space above or below the pages, artboards, or whatever.

In essence, the way the scrollbar is supposed to work, is that its entire length is maps to the entire length of the document itself, regardless of how big or small it is, and when I click 20% down from the top in the scrollbar, the document should jump immediately to 20% down in its content, not take that click a a suggestion to move the viewport a bit in that direction. The zoom level shouldn't play into it, because the scroll handle will be resizing larger proportionally to the scale of the content vs the size of the viewport, as you zoom out.

[thomaso]

7 hours ago, R C-R said:

This seems to have something to do with the document window space being bigger than what actually is needed to display all of its content. So if I manually drag the scrollbar to the top or bottom of the view, & the zoom level is high enough, then there is a lot of empty space above or below the pages, artboards, or whatever.

There is no reason that the pasteboard would/should/has to cause the odd click-scroll behaviour in Affinity: As there is a certain limit if you drag the slider to the top or bottom of the scroll bar the app is well aware about a total distance and can/could handle the scroll distance of a click in the scroll bar according to the click's position – just as Affinity does in the scrollbar of the pages panel.

The systematic nature of click-scroll distances reminds me of ruler divisions, which vary strangely depending on the zoom level and can even switch between decimal and non-decimal (sub-)divisions. Like the ruler, the click-scroll distance seems more random than logical and predictable.

[R C-R]

6 hours ago, thomaso said:

There is no reason that the pasteboard would/should/has to cause the odd click-scroll behaviour in Affinity...

Agreed that it should not but consider for instance how the Scrollbar in Safari is limited to the extent of the web page, with no extra display room above or below the page's content.

[mattspace]

4 minutes ago, R C-R said:

Agreed that it should not but consider for instance how the Scrollbar in Safari is limited to the extent of the web page, with no extra display room above or below the page's content.

The scroll handles don't appear at all until the visible portion of the document exceeds the document window's viewport, so clearly the application knows the bounds of the content. There's no justification for it to be unable to apply the appropriate scrolling behaviour to a spatial domain it's already measured.

[R C-R]

1 minute ago, mattspace said:

The scroll handles don't appear at all until the visible portion of the document exceeds the document window's viewport

They do for me if I set my General system preferences to always show scrollbars, but only if I change the view even slightly, like by wiggling the view in the Navigation panel. And when doing that the scrollbars do not scale properly to the view, again allowing large gaps around the view if scrolled far enough.

IOW, I think it is quite buggy.

[mattspace]

8 minutes ago, R C-R said:

They do for me if I set my General system preferences to always show scrollbars, but only if I change the view even slightly, like by wiggling the view in the Navigation panel. And when doing that the scrollbars do not scale properly to the view, again allowing large gaps around the view if scrolled far enough.

IOW, I think it is quite buggy.

I also have my system set to always show scroll bars - until the document content exceeds the viewport size, there's empty scroll bars. Once the content exceeds the viewport, the scroll handles appear. It even calculates the appearance of the scrollbars when half the document is offscreen vertically - so it's able to measure the entire document at its current magnification, even when it's outside the viewport bounds, and compare that against the viewport size to trigger the scrollbar appearance.

Is it buggy, or is it another lowest common denominator to Windows behaviour, like only having one document window?

[R C-R]

3 hours ago, mattspace said:

Is it buggy, or is it another lowest common denominator to Windows behaviour, like only having one document window?

When I said "quite buggy" was my opinion not clear????

Also, not sure what you mean about only one document window. While it does not work in a very intuitive way, you can use "Float View to Window" to have multiple document windows open in the Mac versions.

[mattspace]

6 minutes ago, R C-R said:

When I said "quite buggy" was my opinion not clear????

Oh yeah, I'm just not sure it's a bug as opposed to "works as designed".

6 minutes ago, R C-R said:

Also, not sure what you mean about only one document window. While it does not work in a very intuitive way, you can use "Float View to Window" to have multiple document windows open in the Mac versions.

Yeah, but they're not proper windows. You still have one privileged document view. It's a huge regression from V1 where you could go to Separated mode, and then have multiple equal document windows, and a free floating Toolbar (which I'd usually put on a different portrait-orientation screen).

[R C-R]

7 minutes ago, mattspace said:

Yeah, but they're not proper windows. You still have one privileged document view. It's a huge regression from V1 where you could go to Separated mode, and then have multiple equal document windows, and a free floating Toolbar (which I'd usually put on a different portrait-orientation screen).

All that is possible in V2, but it is just not intuitive or simple to set up. That said, I agree that V1 separated mode was far better -- it is something many of us have complained about but they seem to have no interest in bringing it back.

[mattspace]

7 minutes ago, R C-R said:

All that is possible in V2, but it is just not intuitive or simple to set up. That said, I agree that V1 separated mode was far better -- it is something many of us have complained about but they seem to have no interest in bringing it back.

Well I've been trying to set it up to see if it's progressed since 2.0, and I can't make the empty main window (after floating all documents to new views) any less than 50% of the display's height, so that's a "no" on "is this doable in a useful fashion". 🤷‍♂️

[R C-R]

11 minutes ago, mattspace said:

Oh yeah, I'm just not sure it's a bug as opposed to "works as designed".

Try this:

Double-click on a page or spread in the Pages panel of an APub file with at least 3 smallish pages like 600 x 800 px.

Set the View to Zoom to Document. Note that there is no bar showing in the scrollbar track.

Now, click & begin to drag somewhere in the scrollbar track.

Note that the view immediately jumps to well above or below the document's extent ... & there is still no bar showing in the track.

Surely, it was never designed to do that!

[mattspace]

12 minutes ago, R C-R said:

Surely, it was never designed to do that!

Photo has the same behaviour though, on a single document - you zoom in, click in the scrollbar near the top, and the scrollbar jumps a bit, but not to the actual point you clicked.

That to me looks like a design / implementation issue / choice with the general Affinity window system, but I'd be happy to be wrong.

[R C-R]

11 minutes ago, mattspace said:

That to me looks like a design / implementation issue / choice with the general Affinity window system, but I'd be happy to be wrong.

Isn't the fact that the bar is not always shown and/or that the view jumps to some point the moment a drag is started in the scrollbar track evidence enough that it is a bug? IOW, why would it be intentionally designed to do that? 

[mattspace]

1 minute ago, R C-R said:

Isn't the fact that the bar is not always shown and/or that the view jumps to some point the moment a drag is started in the scrollbar track evidence enough that it is a bug? IOW, why would it be intentionally designed to do that? 

That could be a separate issue, what I'm observing is that scroll handles are always shown when the visible document is larger than the viewport (and not when it is smaller), but that the "jump to the clicked point" behaviour isn't implemented. Instead clicking in the scrollbar's track causes the scroll handle to jump a step in the direction - maybe a quarter of the distance it's supposed to move, but not directly to the clicked location.