Add_option for boolean options in gramplet

Development
1

in my addon HistContext HistContext I have a couple of options.
The BooleanOption will show the label both before and after the checkbox.
I noticed this was also the case with the pedigree gramplet.
Is this on purpose, am I doing something wrong or should i file a bug ticket

2

What is the origin of the link URL that you have been using for your GitHub repository in these Discourse threads?

I have not seen a link with an @ symbol outside of eMail.

Why not use https://github.com/kajmikkelsen/TimeLineGramplet.git as the URL?

3

I think that it should correspond to the label of a Gtk.CheckButton which is usually displayed after the checkbox.

1 Like
4

Can Glade be used for layout of Configuration options? Tweaking labels would be very easy there.

Most of the Configuration options tab layouts are very raw and messy. So my guess is that it isnā€™t designed for Glade compatibility.

5

That is the link I get to clone the repository I get when I press the ā€œcodeā€ button
Perhaps I should use this link instead? https://github.com/kajmikkelsen/TimeLineGramplet

1 Like
6

Sorry my bad, - I have never used the github this way before, should have done some thinking

7

That was what I thought as well

8

I havenā€™t a clue.
Never used glade

9

The ā€œGlade for view Configuration tabsā€ inquiry is a Gramps Architect question for @Nick.

When Gramps developers want a more elegant layout (or more control) in the Gtk GUI, they are typically nudged to using Glade.

1 Like
10

Our options are written such a way that they can be used by both the GUI and command line interfaces.

We also need to investigate the status of Glade and Gtk4. Is it being discontinued?

2 Likes
11

So it should be considered a bug.

12

Asked Perplexity to outline Glade plans for Gtk 4 and 5.

Glade, the traditional interface designer for GTK, is not directly compatible with GTK 4. The GTK developers have decided not to port Glade to GTK 4, citing various reasons including architectural changes and a desire for different approaches to UI design. The GTK 5 development team recognizes the need for UI design tools, but theyā€™re exploring new approaches rather than updating Glade,

Alternatives and Workarounds

  1. Cambalache: This is a new RAD (Rapid Application Development) tool designed specifically for GTK 4 and 3. It aims to eventually replace Glade, though itā€™s still in development and may not be as user-friendly as Glade yet.
  2. Manual Conversion: For existing GTK 3 projects using Glade, thereā€™s a conversion tool available:
     gtk4-builder-tool simplify --3to4 my.glade
13

I note that configuration options for this Gramplet are not stored in a single file leveraged by all instances. Instead, the configuration is distributed across many locations.

Is there a better way?

  1. As always, there is a single position listing (if you ignore the historicaltimeline beta versions) in the the gramps52/gramps.ini file. (Considering that there could be 15 detached gramplets for the built-in People view modes, how does this support all the instances? It does not. Detached status for Dashboard gramplets are remembered between session. But apparently not for view mode gramplets.)
[interface]
histcontext-gramplet-height=858
histcontext-gramplet-horiz-position=26
histcontext-gramplet-vert-position=23
historicaltimeline-gramplet-horiz-position=26
historicaltimeline-gramplet-vert-position=23
2) The options for each gramplet instance can different than the others. That means that Gramps (with no addon view modes) could have 15 different configurations.

Gramplets_dashboardview_gramplets.ini

[Historical Context]
name=HistContext
height=20
expand=True
title=Historical Context
detached_width=510
detached_height=480
state=detached
column=0
row=1
page=0
help_url=https://github.com/kajmikkelsen/TimeLineGramplet
navtypes=['Person', 'Dashboard']

2 splitbar (_sidebar.ini/_bottombar.ini) preferences for 3 categories of ā€˜Personā€™ (2 People, 1 Relationships, 4 Charts) built-in view modes:

[HistContext]
name=HistContext
height=20
expand=True
detached_width=510
detached_height=860
state=maximized
data[0]=Census
data[1]=True
data[2]=True
data[3]=/home/districtsupport/.gramps/gramps52/plugins/TimeLine(World)/custom_v1_0.txt
help_url=https://github.com/kajmikkelsen/TimeLineGramplet
navtypes=['Person', 'Dashboard']
page=4
14

Maybe use gramps/gen/config as described at:

https://gramps-project.org/wiki/index.php/Addons_development#Config

This will put all config settings in a single file histcontext.ini .

1 Like
15

I initially created the gramplet as a standalone app. There I had option stored in the standard config directory as it was returned to me from python ( I think it was ~/.config/HistTimeLine.ini) I actually created a config class. Good training, but wasted efforts.
I couldnā€™t figure out how to enter options, until I saw another gramplet do it in the ā€œview optionsā€.
I think it should be stored in a central place, at least for my gramplet, but other gramplet could be depending on whether they are on the side or the bottom, or which view they are in. The link @GaryGriffin posted look promising, will play around with it.

1 Like
16

That seems to be is a good thought. Letā€™s go further. What is the proper destination for this file?

I have seen the .ini for an addon in many levels of the Gramps User Directory. The .ini could be in its top .gramps level, in .gramps/gramps52, .gramps/gramps52/plugins, in the folder of the addon, in a subdirectory of the addon. And with the advent of supporting the XDG Base Directory, it can be in the new or legacy location.

The developer docs may need some love after @Nick-Hall advises of the preferred location for addon .ini files.

1 Like
17

Personaly I hate to see all the inifiles in the plugin directory.
In order not to clutter the addons directories, perhaps there should be a .config directory in the gramps directory, or why not use the standard ~/.config/gramps/whatever you config, at least in Linux.
Donā€™t know anything about windows, but there it should probably be in the registry database, not as a file :face_(vomiting:)

18

I agree. It gets very messy and adds complexity to the troubleshooting process.

The @cdhorn CardView family of add-on view modes has a truly MASSIVE number of configuration options. CardView then layers SETS of configurations on top of that. He consolidates his .ini files in a .gramps/gramps52/templates folder. So they are not mixed in among the view mode .ini files. Although there are also sidebar/bottombar .ini files for each added CardView view modes which only have Gramplet ordering and layout information.

While exploring this issue, I finally isolated the source of one oddity in Plugin Registration. When the .gpr.py is revised for a `help_url` target, the Help buttons often did not change to the new target. I suspected browser caching.

But the real reason is that the Grampletā€™s help_url value is stored in the splitbar .ini files. This value is not updated when the plug-in registration updates. It only updates when the splitbars Gramplet configuration is changed in the right way. I have not yet determined if this requires re-moving and re-adding the Gramplet or if some lesser change will refresh the URL.

Feature request filed. 0013494.: Gramplet attributes stored in splitbar .ini files are notā€¦

19

The natural location for .ini files would be in the directory in which the addon is installed.

Using the main gramps.ini file for addon preferences could potentially lead to a conflict between addons.

Other locations and file formats are possible. I would leave this decision to the addon developer.

1 Like
20

Guidance added to the wiki:Addons_development#Config

1 Like