There's a new build coming out this weekend (yay!) with a variety of features, some bugfixes, etc.

One of the new features is a File - Info dialog prompted by a user suggestion that reports the project's full path, size, and last-saved date. What else would you find useful in it? (Component counts by type? Data size breakdown? ... etc.) There are a couple of days left before the weekend so we can squeak a few requests in.

If you have an idea and miss this weekend's release, there's another build coming up in 2-3 weeks.

a heads-up on some of the new features would be helpful so that we might identify somelow hanging fruit that isn't on the new feature list.

Well, the low hanging fruit for today is what you'd like to see in the File - Info dialog. :-) Any ideas?

I sent a couple of things in through other channels. But, anything you do with File -> Info, I wonder if you could do it through a right click/properties from the folder. Sort of like how a word document will tell you how many words are in it without opening.

File - Info is for the project, and there's something already a bit like what you suggested for items in the Project pane in that you can right click anything in the Project pane and choose Properties. That will show things like the initial text in a comments field. It's basically a read-out of properties for that item from the mfd_meta table and their values.

But that's a more technical thing that's info on the plumbing, and not a report of metrics like total size. To get metrics like that I think it's a good idea to add a more expanded "Info" entry to the context menu for anything you can see in the Project pane... folders, components, data sources, etc. I've contributed that as a suggestion.

That's an extremely easy feature to add from a technical perspective. What moves it up or down in implementation priority is the difficult part: deciding what exactly *what* info you want to show for various items. The info you'd want to show for a folder, for example, would have some differences from what you'd want to show for info on a drawing or a drawing's table and yet again different for data sources.

So, if somebody sits down and draws up a list of metrics or other things to display in an Info display for each possible item that might be found in the Project pane, then technical implementation is trivial. But if you don't have that list then implementation doesn't get done because the response comes back, "Sure. Easy to do. What do you want to report?"

In that respect File - Info is a trial run. If anybody gives a hoot about getting more expanded info in an easy to copy form (just one click to grab the full path for the project...), then it will get populated with more items than just the three in the initial version this weekend. If nobody gives a hoot about File - Info, then that's an indication extending that idea to context menu Info on individual items in the Project pane isn't worth doing. I think that's OK because there are zillions of ideas and the ones people care about should get done first.

Within theexpanded "Info" entry, status of linked projects, or data sources.

In my case, that's services no longer alive, or data sources that are on other drives not connected. (If that makes sense)

How about a column in the Project pane, say, by the right margin, that could be cycled through readouts of

interest, such as total size, date/time of last change (for KlauseDE's note, below), status in terms of connected or not, etc. ?

That would be perfect.

I am with Dale on this but beyond that Manifold files are for me ongoing records of projects that are still current but in some cases have been in progress for a long time (often working with colleagues). During this time I have had to update my computer setup, replace disks, etc. I never throw away any of this gear now that it has such a small footprint, but if File-Info could contain clues to the machine-source of files imported to a project .MAP file that would be tremendously helpful.

Well, File - Info is about the project. It sounds like the source from which a component was import might better be a property of that component, or automatically written into the description for that component, such as "Imported from ARCHIVES C:\data\shapefiles\lakes.shp on <date>". How does that sound?

Automatically adding this information to description with the opportunity to edit is a god place to capture theses data.

I often copy/paste queries from one project to another via clipboard. However this doesn't allow for keeping this information and I should then change workflow to Import from mfd project.

Do you really want to ruin economy only to save the planet?

Not necessarily: if you copy a component and paste it, then the description should also be copied and pasted too.

I would like to see two additional rows indicating the item and date of last changes in File-Info:

First row: Changes of components: [Date+Time], [Component], Action

'Action' is:edit component (style, ... any property ) | add component |deleted component

Second row: Changes of data in local tables

'Action' refers to records:edit table;mfd_id | add table;mfd_id| delete table;mfd_id

Do you really want to ruin economy only to save the planet?

User chooses a 'zoom scale' option in preferences for 'Zoom to selection' when the selection is a point or points. (See Zoom to Selection for a single point zooms out to max extent - contrary behaviour)

That doesn't have anything to do with File - Info, the topic of this thread, but here are two comments anyway:

First, if a single point is selected, say, in a "Cities" layer, then right clicking the layer tab and choosing Zoom to Selection will *not* zoom out to maximum extent. It simply zooms to that one selected point.

Second, if you want to zoom to a specific scale, zoom to selection and then click the scale setting in the status bar at the bottom of the Manifold application window and choose the scale you want.

I'd like to nominate a new feature that allows single point 'zoom to selection'.

Perhaps a user-defined zoom scale can be an option for the drawing (or the map).

I have many thousands of old school locations I'm attempting to accurately/correctly geo-reference, most of which no longer exist in space, but do in a table and have a wildly approximate location (based on gazetteer records).

Since many schools no longer exist, I can't rely on the drawing to find each school; instead I must select the school record on the table, then find it on old parish maps and then then update (edit) the coordinates and mark the record as confirmed. With 7000 points to visualize, it's impractical to use the drawing to select points for processing.

Thanks.

Greg

In the USA we have historic topo maps online that locate and symbolize schools.

The M9 "Location" feature may do what you want if you have a drawing with a coordinate system.

Or ask Gemini AI to geo-reference your gazetteer records.

I'd like to nominate a new feature that allows single point 'zoom to selection'.

Perhaps I don't understand what you're asking for, but that feature already exists. Suppose you have a layer of thousands of school locations in your map. That layer is a drawing of school locations. OK. Open the drawing's table and select the school you want to see in the table. That point is also selected in the map. In the map, right click on the schools layer tab and choose "Zoom to Selection" and the map zooms to that point.

I love a detective story. 7,000 schools is a lot of schools. How many parishes are involved, and how long has it been since the schools were torn down? (rhetorical questions) You might be able to enlist the help of librarians working in the various parishes. Librarians also love a good detective story, and one about school locations would seem, to me, to be right up their street. If you ask nicely and show them how, they might give you LAT/LONG coordinates in a spreadsheet for the schools they know of.

Or,

Enlist the help of AI to get the creative juices flowing. Pick all your favorite AIs and give them a prompt like, "I have Australian gazetteer locations of 7,000 schools. Many have been closed and/or demolished. I would like to find the specific locations to put into a layer using Manifold 9 GIS. Which agencies, libraries, and societies should I contact to find the locations of the schools?"

The results I got yielded some surprising ideas. One was to search for ANZAC memorial trees, avenues, and brass plaques which were often installed by student associations and never removed, because ANZAC. I did not see that one coming!

If you don't mention Manifold 9, the AI will spend time giving you instructions for QGIS, Arc, etc. Mentioning Manifold might get you specific SQL queries for parsing the data you get.