Thanks, Mike, for the ideas and the encouragement. Some questions/comments...
- Easier table exploration
What did you have in mind for the above?
- Avoid having to create a new drawing from a linked database in order to style it.
You don't have to do that now if you have write permission in the database and permissions to create tables in the database. See the Example: Link GPKG and Save Style topic.
That's a very clean solution because the style is saved within the database, so it doesn't matter if links get broken or if the drawing is opened from a different computer. If you don't have permissions to save stuff into the database, then there has to be a way to save style info within the project in a way that maintains a link to the database.
That's obviously more fragile and project dependent, but it also requires user interfaces that have to be understandable and convenient to both learn and to use. If you have some sort of phantom style storage that isn't visible to the user but is created on the fly to give the impression that the drawing within the database is styled, that involves a lot of user interface and storage infrastructure which just ends up duplicating, but in a different way, what is already there for drawings. Creating a linked drawing uses exactly the same infrastructure (properties, etc) that's already in place, so no additional infrastructure to build or additional UI to learn.
I'd suggest an adjustment to the above that would simply make it easier to create a new drawing within the project from a linked database in cases where the linked database does not allow you to style it. For example, you could right-click on a drawing within an external database and choose "Create Local Link", and a local linked drawing would appear. (I'll send that in as a suggestion...)
I've sent in a suggestion for a similar thing with image servers, where I'd like to see the built in image servers have a "short name" by default, and whenever you create an image server data source it automatically creates a linked image within the local part of the project using that short name. That would greatly shorten the names used on tabs, so you could have "Bing Streets" on the tab instead of the current, long, fully-qualified name, and you could also style that layer.
Mfd should make a few downloadable projects with sample data (aerials, roads, etc.) and instructions.
There's something like that in the Examples page (same list repeated in the Viewer and main downloads pages). If what you had in mind were "raw" projects with pre-built maps with image server backgrounds, those would be easy to do as "starter" examples.
What would you recommend?
By the way, on translations, it will be interesting to see what reactions there will be to the semi-automated Google translations. It may or may not be enough, but already it's clear Google has made big progress in the last two years.
As Google's AI gets better and better, I think we'll be close, maybe in a year, to the point where Manifold itself could automatically pull text out of the current tag=text system and run it through Google's API to translate it into one of the many languages that Google knows. You could then launch Manifold and if you wanted to see the UI in Urdu, just pick that and it would happen automatically.
We're very close to that. All we need is some "do not translate" marker so some tags can be marked as not to have any text except that within <> brackets translated, thus allowing fully automated translation that wouldn't touch SQL or $ literals. (I'll send that in as a suggestion...).