I’m programming a gramplet that I find useful used in multiple places in Gramps, usually in the side panel of both “People” and “Relationships”. The gramplet can present the data in two different styles, as a single panel or as a notebook, selectable using radio buttons at the bottom of the gramplet. The problem is that if I switch style in one instance, the change is not reflected in the other instance.
Is there a way to tell within the gramplet that I have switched from one instance to the other?
I’ve got something working on this, but it seems a bit too kludgy for my tastes.
I’m currently checking the Gtk “draw” signal to see if I’m switching to another gramplet instance. However, it is being signaled several times. Just wondering if there’s a better signal to use. That is, a signal that’s called just once when switching instances.
Any gramplet that you place in a view’s sidebar, or bottombar, has their settings stored in the view’s sidebar.ini;
In your user directory, in the gramps version folder, gramps51, will a long list of ini files, three for each view; i.e. Relationships_relview.ini, Relationships_relview_bottombar.ini, Relationships_relview_sidebar.ini. So a gramplet in the Relationships view sidebar will have different settings if stored in the People_personlistview_sidebar.ini.
If you have the Collections Clipboard in a view’s sidebar and in the same view’s bottombar, different obejects can be stored in each instance, as well as in different views.
Thanks, Dave, for giving me something to think about. I had implemented the view style as a global setting, which meant that ensuring consistency among the different instances was problematic.
But I’m also fine with having view specific settings. Hmmm, in fact, the more I think about that, the more I like it that way.
One simple way would be also to use a separate Python module that the gramplet imports. Gramps imports such modules in the global namespace (sys.modules) and therefore they are shared by all plugins.
The module could include method to send a message and another that allows other modules to “subscribe” to receive notifications of those messages. Something like this (in “common_module.py”):
callbacks = []
def subscribe(callback):
callbacks.append(callback)
def send(value):
for callback in callbacks:
callback(value)
The main gramplet code would notify others of the “style change” by calling the “send” method:
But, although there is a User Tutorials category and a Developer Tutorials category, we seem to be missing a framework that organizes tuition from introduction to basic competency.
There is nothing to synchronize a gramplet in different parts of gramps.
Each gramplet is independant.
To do such a thing a method could be to implement a signal processing in the gramps core.
I don’t think this is the best thing
I think in your case a shared memory could do the trick if you really want to do that.
You could implement a shared memory segment each gramplet will use.
My question: Is it so important every gramplet use the same style ?
It’s often useful to have different syles.
As I mentioned before, I eventually did get the other instances to update as I expected, but using the Gtk “draw” signal to trigger the check, which seemed a bit kludgy. One issue I also had was my confusion in dealing with class variables. I had forgotten that when modifying a class variable, you have to prefix it with the class name. This is a bit of an inconsistency. You can access the value of a class variable using “self.x”. But if you try to modify “self.x”, you create a new instance variable. You need to code it as “ClassName.x”. (I love Python, but it still has its quirks.)
I think there are other possible approaches to synchronizing attributes among various gramplet instances, that I hadn’t yet bothered exploring. I was discussing the issue with my (non-programmer) daughter, and she had in interesting idea. We can’t share Gtk widgets among different parent widgets, but using class variables, we can keep track of the widgets in other instances.
Anyways, I think consistency is important within an application. So I’m happy with each view having it’s own view style setting. And I learned how to use the gramplet options, so now my gramplet uses the “Configure the active view” dialog. I still wanted the radio buttons in my gramplet, so I had to do a bit of extra coding to make sure both ways of setting the view were in synch.
(Based on other feedback, I may end up adding a few other options. But they can go in just the “Configure the active view” dialog.)
Not sure how to answer that. However, yesterday I spent some time poring over the on-line docs looking for a description of how to code the gramplet options. I was sure I had come across something before on the subject. I eventually gave up on that and looked at the code for some other gramplets, as well as the base Gramplet class.
I am getting up to speed on Gramps development, but often it seems that experimentation is the way to figure out things. I’ve become very family with the Python debugger! Often, you just have to set a breakpoint and see what attributes are available for the objects you’re interested in. But this is not unique to Gramps.
Let’s leave that vague for now. Let it get through peer review so people don’t don’t have to suffer through the aggravation of waiting.
It doesn’t really matter WHAT any new feature is. As soon as something is announced, suddenly it grows into something long overdue.
This particular gramplet helps visualize something that is currently too obscure and hard to access via reports. It makes discovering the information interactive & painless.
But let it be a surprise so you will be able to better appreciate the gift.