Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Preferences hiding #1434
Details for the issue
What did you do?
Looked for preferences (new user)
What did you expect to see?
The preferences in one of the usual places: tools->options, edit->preferences, or even File->Preferences"
What did you see instead?
The preferences are under "View"
This is an odd, unconventional place. The preferences aren't restricted to View - they include default DB parameters, auto-update, language, file extensions, etc. So it's not as if they preferences for appearance were there and preferences for other options were somewhere else. (Which also would be unusual.)
As a usability concern, it would be better if preferences were located in one of the conventional places.
Not a major issue, but certainly one that every first-time user will encounter.
Useful extra information
The info below often helps, please fill it out if you're able to. :)
What operating system are you using?
What is your DB4S version?
Did you also
This is easy to change, but the interesting part is agreeing on the best option. I propose these:
I'd go for 2. It's the more sensible option for both new and old users, although it isn’t very standard on the other hand.
Moving "Load extension", "Compact Database", "Set Encryption" to a new
I'd still move "Preferences" under the
I lean towards standard. Consolidating under Tools seems like a good choice.
I think VACUUM (Compact database), Load extensions are appropriately tools. So would be an interface to Analyze (when you get around to it). So "Options" would have company there.
The other entries under "View" seem different - they configure the toolbars & provide shortcuts. To a first impression, I'm OK with them having their own menu.
I'm surprised at the mention of 'set encryption' - since you mentioned it, I looked for it everywhere and can't find it. Perhaps it's part of an extension (I have none). There should be an easy way for extensions to integrate with the standard options/preferences presentation - as opposed to all doing their own thing.
Some applications try to match expectations by presenting a different menu organization by os so they can meet Windows, Xwindows/linux, and Mac standards. It's not a lot of work - but given the audience for this tool, perhaps not worth the complexity.
Ahhh, the lack of encryption just means that when you grabbed the nightly build, you picked one of the "SQLite" ones vs the "SQLCipher" ones:
The "SQLCipher" ones include encryption. If that's of interest, then grab one of those. Your existing SQLite databases will work fine with it - they'll just be used without encryption.
To enable encryption, open a suitable database and turn it on with (for now) File -> Set Encryption.
There's a page on the wiki with basic info about it too, if that's useful.
I went to the download page for nightlies (I wanted the latest SQLite with ON CONFLICT support).
You might put a README on the server that explains what the various builds (and support status) are. Apache autoindex has a directive that would even display it - I don't think nginx does...
I was only curious from the UI point of view.
You might add the encryption option, greyed out for the version that doesn't support it; perhaps hover or maybe leave it active that results in a popup to the effect of "no encryption support, here's how to get it".
I'm going through Perl's DBI/DBD::SQLite - which according to the wiki isn't supported yet. So apparently it's a moot point for me.
Thanks for the quick responses. Its' a really helpful tool.
This is an interesting read:
Microsoft guideline under: Standard menu bars section of https://msdn.microsoft.com/en-us/library/windows/desktop/dn742392(v=vs.85).aspx
The problem with renaming the
When that wouldn't be a problem, I like both
tools -> options seems like the right choice for windows.
I don't know about Qt and the Mac, but I presume it can be convinced to do the right thing, if not automagcially, with "persuasion".
As noted above, I think there are several other candiates for "Tools" - and I agree that for this application, "Edit" would be an inferior choice. (It kinda makes sense for MS Office, where that convention started. But that's long ago in software years.)
Your MS reference agrees that the (current) standard place for Options is under tools. It gives generally good advice.
You don't present a Ribbon interface, so that doesn't seem to apply.
Yes, it's space. 2A is asterisk ('"), which he used as part of the filename to ensure that it sorted before anything else. The filename is "" "space" README.txt. You can see this by backing up one level to https://nightlies.sqlitebrowser.org/latest/.
Just don't ask a neophyte to delete it from the shell...
(Doesn't anyone memorize the ASCII code in decimal, octal and hex anymore? What's the world coming to?)
I'm thinking on making this structure:
The reason to not moving/renaming Preferences to Tools -> Options is not breaking translations and not being too flow breaker for old users. Another reason is not breaking the MacOS version. I don't know if it having a different name, would still be moved to the application menu (I suppose Qt will still be moving it based on the PreferencesRole that we set in the menuRole property, but maybe with the 'Tools' name, which, I suppose, would be unexpected for MacOS users).
added a commit
Aug 6, 2018
referenced this issue
Aug 6, 2018
Just a pedantic thing ... if a menu option takes you to another dialog, then 'traditionally', it should show ellipses ('...'), eg, as on File | Open.
@chrisjlocke Yes, I've already noticed those issues reading at:
According to that, we have several actions without ellipses that should have. And several others in the Help menu, that shouldn't have them.
At the same time, it's easier to fix than most of the others. I think I'll add all that you have mentioned plus those in the Help menu to the current Pull Request. Translators will have a great deal of work in this release anyway
Thanks for linking to the document, @mgrojo. Never realised it was quite so specific. "This doesn't mean you should use an ellipsis whenever an action displays another window only when additional information is required." I've always slapped them on 'Preferences' and 'Options' menus. Oops! ;)
For the "Bug Report..." I've kept the ellipsis, because the user can still decide to open the report or cancel. The other are simple help/documentation pages open in a web browser, so they shouldn't have ellipsis.
That line is too blur for me so I've left the ellipsis in Preferences, but should I remove it?
Little survey here in Ubuntu:
Conclusion: life is free and varied!