Thu Jan 24, 2019 5:35 pm Post
Thu Jan 24, 2019 7:19 pm Post
Fri Jan 25, 2019 9:41 am Post
What you are referring to as the "formatting controls/bottom menu bar" is actually called the Keyboard Row.
Fri Jan 25, 2019 2:21 pm Post
I found my way to this forum thread after I bought the Scrivener iOS app for my ancient iphone 4s. I thought it would be great to be able to read through my Scrivener projects on the phone (I work on a Macbook Air), and do the odd bit of simple editing.
The first thing that I looked for was how to hide the menu bars while reading, and was quite surprised that my search led me to this forum, and the confusion that seems to have occurred.
I was a bit loathe to write here, but I hoped I might try and clarify things, as reading through the thread it seems that people may be talking about different elements on the page.
I think the original person who posted was asking if there was a way to hide the top and bottom menu bars while editing text items, as marked in red in fig-1 below:
And I think some of the confusion was that in the next reply, Keith thought the OP was referring to the formatting controls along the top of the pop-up keyboard (fig-2):
Keith’s understandable desire to keep the rich text formatting controls seems to have been taken as the reason why the menu bars can’t be hidden.
Note: Just for the record, I have no problem with the formatting icons--they’re great!
So, it seems that people keep asking for the menu bars to be hidden, but get a reply that Keith has repeatedly said that they will not be hidden, when in fact he was referring to the formatting icons.
I think is where the confusion lies, but I apologise if I have misunderstood.
There also seems to be confusion over how hiding all the menus might work for users without access to an external keyboard, i.e they would be unable to bring the menus back.
I would expect it could work in the same way as the current navigation works at present:
On my phone, if I swipe from left to right on a text item (red arrow), the screen slides across to reveal the previous menu:
I imagine, that if, instead of swiping left-to-right, I swiped right-to-left, then the top and bottom menu bars could slide away, leaving a distraction-free screen for reading or editing:
Menu bars swiped away - Distraction-free mode:
I would still be able to tap on the screen, and the keyboard would appear as normal (unless of course I was using an external keyboard):
To get the menus back, one would simply swipe the screen from left-to-right, sliding the menus back into place:
If an external keyboard were being used, I imagine that the menu bars could be hidden using a keyboard shortcut instead of a swipe.
I apologise for such a long-winded post, but it seemed that a few different topics had been mixed into one, and I just hoped I may be able to reduce some of the confusion and frustration that has been generated.
If I’ve just made things worse then it wasn’t my intention!
As you can see from the screenshots above, on an iphone, the menu bars do take up a lot of the screen, and my preference would be to hide them if possible, especially if I will be reading for a long period of time.
This post is not meant to be a criticism, just an attempt to clarify a wishlist item that could be added to what is a great piece of software.
...and if anyone wonders how much work can get done on an iphone anyway - I typed up about 100,000 words on this setup…
All the best,
Fri Jan 25, 2019 3:53 pm Post
Ah yes Ian, you are correct! The menu bars are separate interface items.ighulme wrote:But when you say, "formatting controls (Keyboard Row)/bottom menu bar" as the same element, I think this is where the confusion arises.
In total there are 5 users online :: 0 registered, 0 hidden and 5 guests (based on users active over the past 5 minutes)
Most users ever online was 1048 on Mon Feb 06, 2012 9:07 pm
Users browsing this forum: No registered users and 5 guests