Hmmm, sounds like a bug. Though, it's probably a long standing one for us on Windows. 😄

This is easy to change, but the interesting part is agreeing on the best option. I propose these:

1. Move Preferences to Edit menu
2. Rename the View menu to Options, with the same entries.
3. Add a new Tools menu and move there the Preferences entry and some of the entries in File menu, which are not referring directly to database or project files, for example: Load extension, Compact Database, Set Encryption.

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 Tools menu sounds reasonable. 😄

I'd still move "Preferences" under the Edit menu though, for consistency with other applications (on Windows).

Renaming the View menu to Options.... meh. No strong objection here. It's not something I personally have a preference about either way. 🤷‍♂️

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:

    https://nightlies.sqlitebrowser.org/latest/

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. 😄

Thanks.

I went to the download page for nightlies (I wanted the latest SQLite with ON CONFLICT support).
There was no clue about what the Cipher version was, so I went for what looked safe. (As I said, "new user".)

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.

Edit -> Preferences... is not always used in Windows. In fact MS preferred Tools -> Options before making its "Ribbon revolution".

This is an interesting read:
https://ux.stackexchange.com/questions/340/where-should-the-preferences-item-go-in-a-desktop-application

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 Preferences entry to Options might be that under MacOS, it should be named Preferences (the entry has a special Preferences role, and I think Qt moves then the entry under the application menu in MacOS. I don't know what would happen if this special entry is named Options).

When that wouldn't be a problem, I like both Edit -> Preferences and Tools -> Options but if we add a new Tools menu for some entries which would be better located there than in the File menu, I'd go for Tools -> Options. Although Edit -> Preferences is quite customary, I feel that this entry is a bit alien in that menu, because it usually contains actions applying to the "document", not the application.

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.

Ahhh, hadn't thought of including a README.txt or similar there. Makes sense, I'll throw one up there now. 😄

k, there's a README.txt in place now. It's not automatically shown in the footer, but it should still improve things for people a bit. 😄

Thanks for the README.

Appreciate your responsiveness.

there's a readme.txt in place now

Mangled URL? Is that a space before the filename, and some other character?
/latest/%2A%20README.txt

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?)

Aah, didn't look at the file directory.... thanks.

Just don't ask a neophyte to delete it from the shell...

Hopefully they'll use shell completion, so could just use tab or whatever they have it set to. 😁

Appreciate your responsiveness.

You're welcome. It's a good idea, and super easy to implement so was do-able immediately. 😄

I'm thinking on making this structure:

• File (some entries moved to tools)
• Edit (move here Preferences)
• View (the same except Preferences)
• Tools, new menu with:
  • Compact Database
  • Set Encription
  • Load Extension

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).

I've created a Pull Request with the changes that I described above, so it can be seen in action and discussed.

For those of us who don't build from git - if you want comments, perhaps you could post some screenshots...

Unfortunately, a native UI on all the major platforms (Linux, Windows, Mac, mobile) usually means some conditionals for labels/positions.

For those of us who don't build from git - if you want comments, perhaps you could post some screenshots...

Of course!

The new placement seems logical to me. 😄

Just a pedantic thing ... if a menu option takes you to another dialog, then 'traditionally', it should show ellipses ('...'), eg, as on File | Open.
Therefore, Tools | Compact Database should have ellipses, as should Tools | Load extension, File | Attach Database, File | Load Project and File | Save Project.
Even more pedantically, 'Load extension' should be Camel Case, so 'Load Extension'.

Good point @chrisjlocke. 😄

To be fair, with >300 outstanding issues, a missing ellipses (ellipsi?) is way, way, WAY down on the list of 'must fix' .... ;)

@chrisjlocke Yes, I've already noticed those issues reading at:
https://docs.microsoft.com/es-es/windows/desktop/uxguide/cmd-menus#using-ellipses

According to that, we have several actions without ellipses that should have. And several others in the Help menu, that shouldn't have them.

To be fair, with >300 outstanding issues, a missing ellipses (ellipsi?) is way, way, WAY down on the list of 'must fix' .... ;)

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! ;)

Ellipsis changes:

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.

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! ;)

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:

• Firefox: Menu button -> Preferences
• QtCreator: Tools -> Options...
• Git Gui: Edit -> Options...
• Gnome Terminal: Edit -> Preferences
• Eclipse: Tools -> Options...
• Gimp: Edit -> Preferences
• LibreOffice: Tools -> Options...
• Inkscape: Edit -> Preferences...
• VLC: Tools -> Preferences

Conclusion: life is free and varied!

That looks good. It will look better when the Tools menu has some more entries, e.g. as discussed in #1435

I have no strong feeling on the ellipsis - it does seem like a rainy day project.

See also #1497.

I've just merged @mgrojo's changes, so they should be in the next nightly build. Can you give it a try, @tlhackque? 😄

Thanks @chrisjlocke by the way for explaining the ellipsis thing. Didn't know that before 😄

Closing this, as it was a pretty simple change and nobody has reported any problem.