Setup of VmBox Mint Gramps Sandbox

Development
21

After a bit of scrambling, I have a basic environment set up again for my wxPython development - I had to restore my Win 10 environment from scratch.

If I can, I’ll attach a zip file with the bare minimum including a few test files.

Not sure they will help you much and as I am not yet familiar enough with creating a working copy of the final program, a screen shot

test1.jpg
test1.jpg646×509 57.6 KB

will have to suffice to give you an idea of what it all looks like.

There are some points to keep in mind with the current code.

It uses a copy of the Exiv2 library and not all metadata available will be shown because the library is possibly out of date compared to the current status of the Exiv2 project.

The whole program is based on a sample from the book “Creating GUI applications with wxPython” by Mike Driscoll - he does have many samples and much code from the book on his web sites.

One of my main goals was to be able to generate as much of the GUI by using wxFormbuilder, which is runnable under both Win & Linux (& I think, Mac)

The newer versions will be using Exiftool to extract the metadata. wpMeta was/is just testbed to work on the GUI.

Hope it gives you some useful details. Not sure whether there is anything similar for C#, but my effort will go into wxPython :slight_smile:

If you have had a look at the Win utility, you will have a better idea of where wpMeta will go eventually when I port all of the features and if you are interested and can run a Win copy of wxETI, I can look into updating the code on the web page. Till now, there has been no interest and so, though I have made progress with clean up & more features, there was no incentive to build & upload any of the later versions.

(Attachment wpMetaTest.zip is missing)

22

Well, it looks like the zip file was scrubbed from my post :frowning:

test1.jpg
test1.jpg646×509 57.6 KB

23

OK, I understand. You may be able to attach a ZIP file to a personal message, but righ now I’m only interested in a GUI builder for C#, and wxWidgets doesn’t seem to be good enough for that.

Please let us know if you need help with Gramplets though.

24

Sorry, Discourse doesn’t have an option (or Trust Level) to allow ZIP attachments.

Their support forum suggests posting it in a GitHub repository and linking to that in the Discourse forum.

1 Like
25

Well, if you are familiar enough with python, then I don’t see why you would not be able to move that way, but, I will speak up once I get to work on the gramplet

Surely there must be GUI builders for C# - never looked for anything like it, though. Barely know how to spell C# :slight_smile:

26

Thank you, I should have expected that. Right now, that does not seem to be a problem.

27

I hope you realize that wxFormBuilder allows you to output Python GUI building code and that, along with wxPython, puts you into a pretty pure Python environment as far as coding goes. It would still mean you have to get to know the conventions those 2 use, but I don’t see that as much different from any other coding project.

28

I know, but for me it isn’t worth learning, because of my large investment in the C family. I do some hacking in Gramps, when needed, and I’m in early retirement now, but when I do some work, it will probably in C#, with a matching GUI toolkit when necessary.

29

OK, good to know & happy coding. We have to stick with what we know better :slight_smile:

FWIW, I am well into retirement by now :slight_smile:

30

Yes, indeed. And I need to add that I learned that wxNet is dead, so for me it would be a real waste of time. I can use GTK with C#, and since GTK is also used by Gramps, focussing on GTK is a much better investment.

31

WX.Net appears to be dead.
But wxPython had a new 4.2.0 release earlier this month after a hiatus of nearly 2 years. And wxFormBuilder had a 3.10.1 release 10 months ago.

But regardless, GTK+ 3 remains the standard toolkit for Gramps interface.

1 Like
32

Don’t get me all wrong.
My only interest in the wxWidgets world is to use it for a utility I expect to need to update the metadata in specific images.

(FWIW, I have a bit of a bias against GTK if I look at the wasted screen real estate within Gramps, which I understand to be ‘built-in’ into the GTK widgets)

As I said, I see no chance of this sort of support becoming an integral part of Gramps, IMO, and, being addicted to GUIs with not much love for the command line, I have not found anything that would serve the purpose for myself.

I currently have a version which will do for my work under Windows,but as part of my learning to get used to Python, I want to leverage my wxWIdgets background to hopefully come up with an app which will server on all OSes which support Python.

The next big job I see ahead is to try and come up with some sort of ‘convention’ as to which metadata fields to use for Gramps metadata, but that will best be the topic for a separate thread.

33

The exploration of another toolkit seems worthwhile.

Gramps has a history or exploring alternate ways & means. Since there were constraints related to dependence on the bsddb database engine, explorations were made into making Gramps flexible enough to use other db engines. Although that lead to migration to a different preferred engine, it also opened opportunities for
users with special interest. (Like using database engines better suited to distributed processing, operating as a webservice, or using hardware acceleration.)

If the wxWidgets can be used in combination, then great! It is also good to explore what resource burden (if any) is involved when used in combination. And what is required so it could be used as an alternative.

I see that their webpage mentions primary bindings for are for C++ with Perl & Ruby in addition to the Python bindings that attracts interest of our project.

34

As a user, I think much the same as you, in the sense that, if I were interested in editing metadata, I would like to do that inside Gramps. And the selfish consequence of that is, that I’d rather see a new developer learning GTK than using a toolkit that is not compatible with Gramps at all. I am in fact convinced that, if I want to edit metadata outside Gramps, there are already loads of tools to choose from, on whatever platform that I use.

Another aspect is that, as a developer, I’m most interested in toolkits that have a critical mass, so that learning them is a good investment, which in my case means staying up to date with C#, because I can use that when I get bored, and want to earn some extra money in the process. And in that case, using a dead toolkit is not a very good idea.

35

I think that is true if the external tool cannot be tightly integrated or if using the external tool means double navigation & re-keying data.

But say that Gramps had a tight integration to a very mature external tool. And, instead of a double-click opening a Gramps Object Editor for that object, it opened that object in the External Tool. And when the object is saved/committed in the external tool, the changes were immediately visible in the Gramps views, tools g Gramplets.

That circumstance means using an external tool (provided it has a vibrant development community) is BETTER than recreating the capability within Gramps.

Gramps will never catch up it’s feature set to a dedicated citation database like Zotero or a dedicated text styling tool like Sphinx. But if the mutual APIs can be seamlessly interfaced, we would never need to divert the resources to replicate what already exists.

The concern about riding the coattails of a dead toolkit is valid … but you only mentioned wx.net as being dead. The tools he’s leveraging aren’t part of that. And the original developer of the metadata tool seems to have handed off to a fork of his project. (Not as generously as Don Allingham handed off Gramps. Their original developer was a bit more possessive.)

36

Yes, indeed, integration is key, and I don’t see that here, nor with Zotero. You need a technology for that, like good old OLE in Windows. And we don’t have that, just like there is no real integration when I work with a C# program that reads and writes Gramps XML. I use that for specific hacks, because they’re more easy to write with already existing .NET libraries, so that I don’t have to deal with pickles, or other Python specific things.

37

It is very nice to know what you would like to have… but …

38

… but you’re not interested in working on a Gramplet yourself. Is that right?

39

Wrong.
My need is to be able to try and add relevant metadata to some of the images.
And the most obvious way would be to do so in a gramplet, because I would prefer to ensure consistency between the two sets.
But as soon as one adds a capability to modify, either/or both an image or the Gramps db itself, one takes on a huge burden of ensuring both safety and consistency.

I have looked at the 2 available gramplets which deal with metadata,
One, Image metadata, deals pretty well only with EXIF data, but the more useful tags, at least for genealogy, will likely be in the XMP and IPTC name spaces.

The second one, Edit Exif Metadata, seems to display the same data as I see from the other metadata gramplet.
I have not yet investigated, in detail, the code for either of these gramplets recently, but from what I recall, they both rely on/use the Python interface to Exiv2, but IIRC, are based on an older version of the Exiv2 library.

I have no idea why development on the ‘Edit Metadata’ (EM) gramplet stalled, but I have been playing with software and metadata for long enough to see what issues one would face if one wanted to integrate the features ‘proposed/promised’ by EM.

Some of the more pressing and important ones, assuming the basic requirements:

  • Metadata is data stashed away inside the images
  • Gramps data is stashed away in the db
  • it is most likely that data needs to be transferred in either direction
  • data consistency is most important

  1. there is no specified mapping between which DB data goes to which metadata tag
    the purpose of the fields on either side, is ‘predefined and set’ by the designers/maintainers of Gramps and the various metadata ‘authorities’ respectively.
    There has been some related work started @ https://www.facebook.com/groups/www.fhmwg.org but it seems stalled from where I sit.

  2. What sort of correspondence between the 2 datasets is desired?
    The most obvious one is that they should correspond and match.
    What if they don’t?
    What sort of facilities can be built in to help, not only detect differences, but provide a means to ‘fix’ these.
    Which one of the 2 will be considered ‘primary’
    How does one even define ‘match’ for different data? in data format? - such as dates, coordinate representation …

As I mentioned above, as soon as one adds an option which has the potential to change the data of an existing app, the effort to ensure safety and consistency becomes very onerous and demanding.
What the main developers of Gramps have to say about incorporating such a gramplet, I can only imagine.

Without a fixed and accepted mapping between the fields, it is simply impossible to even test.
And until then, each user can make up his own mapping, which really is just putting things off, but makes true and general integration impossible.

Hence, my approach is to stay away from needing to meet the criteria involved in trying to incorporate the gramplet for as long as possible.
My current plan is:

  • add a gramplet to at least display the metadata already present in the image - as completely as possible.

  • expand this display to handle as many potential image formats, such as pngs, tif and others

  • try to come up with a preliminary mapping of data and metadata tags

  • find how to best display the mapping and any potential differences

  • look into writing some metadata to images

  • find out how that affects the media and media verification, resolve any issues if possible.

  • … there will be plenty of other issues which will show up along the way

1 Like
40

OK, thanks for explaining. I understand the way yoo work, w.r.t. consistency.