The widths (and Hieghts) of these view panels appear to be fixed.
Selecting the People/Person View displays the Filter gramplet taking up
about a third of the righthand side of a 1600x900 laptop screen. In practice
that’s around 6 inches/12cm.
If one goes to the Families View that filter gramplet panel is about 3 inches/9cm
in width.
The Events view is again about 6 inches/12cm in width.
The side effect is that one doesn’t seem to be able to control/adjust any of the
column widths within the View.
It’s frustrating to go to the Events View for instance, select the Place column,
and reorder it to descending order and not be able adjust the column width
see the entire length of the entries.
Is there some global setting for these Views somewhere?
The sizes of columns and split bars are adjustable by dragging the edge.
But the grab handles of the GTK interface system are very fussy. As the mouse pointer rolls over the grab-able point of the edge, it will change shape. But that hotspot is tiny.
Note that the side & bottom splitbars can be turned on/off individually for each view mode of each category view. See the View menu or use the keybindings.
And the upcoming 5.2 has an enhancement to let resizings of editor columns be persistent.
The sizes of columns and split bars are adjustable by dragging the edge.
Not so. No amount passing the cursor back and forth across edges sees
any change in the appearance of the cursor.
But the grab handles of the GTK interface system are very fussy. As the
mouse pointer rolls over the grab-able point of the edge, it will change
shape. But that hotspot is tiny.
Tiny? May I suggest non-existant?
Note that the side & bottom splitbars can be turned on/off individually
for each view mode of each category view. See the View menu or use the
keybindings
Ctrl+Shift+r switches the right-hand filter window(?) off and on which
is nice but still doesn’t allow changes to the column widths of the
views.
They are not “non-existent”… the rest of us are resizing panes and columns constantly. But resizing is either: 1) not working on your system; or 2) not being grabbed correctly.
This pointed at their bug report 12237 (“Cannot resize panes”) which was closed as a dulicate of 11951 (Pane resizing quit working). Unfortunately, it didn’t get much attention but was found to be working using a later version of the OS… 3 years later.
It got significantly more attention in another cross-referenced bug report for an osX user in the same year. But a cause was never actually isolated … it was simply no longer reproducible 3 years later. (They also had a workaround compiling with Qt instead of Gtk. Which is not an option for us.)
So the next step seems to be asking if other Mageia 8 user can reproduce.
@hviaene , since you do QA testing for the Mageia OS itself, perhaps you can check? Although your previous message said Gramps 5.1.5 was in the distro… so some version checking might be required.
Note that many problems that other users cannot reproduce have been due to a damaged installation. Those were repaired by reinstalling Gramps. (Always backup your data 1st)
No. They are there, but you may not see them, because your window handler doesn’t show them. Things may improve when you use another one, or change themes.
I’m running Gramps in Linux Mint (Debian Edition) with the Cinnamon desktop/window handler, and on that, the hotspots are large enough to work with.
Asked ChatGPT for help composing a good question to pose about this and then asked the question…
Q: what is the correct technical term for the GUI element by which a mouse pointer can grab an interface gadget.
A: The correct technical term for the GUI element by which a mouse pointer can grab an interface gadget is “Drag Handle” or “Drag Handle Icon.” This graphical element is usually displayed as a small icon or symbol, often composed of a few horizontal lines or dots, which indicates that the gadget can be dragged or moved by clicking and holding the mouse button while moving the pointer. It is a common feature in graphical user interfaces (GUIs) to allow users to interact with and rearrange elements on the screen easily.
Q: Assume that a user of a GTK Python application finds that a Drag Handle is too small to be easily selected with a mouse (or a finger in a touch screen interface). Is there a way to increase the ‘hotspot’ size?
A: Yes, there is a way to increase the “hotspot” size of a Drag Handle in a GTK Python application. GTK (GIMP Toolkit) provides a mechanism to adjust the size of the hotspot, which is the area around the draggable element where mouse events are captured.
To achieve this, you can use the set_drag_threshold method of a GTK widget. This method allows you to set the size of the drag threshold in pixels, which effectively increases the hotspot area, making it easier to interact with the draggable element.
import gi
gi.require_version('Gtk', '3.0')
from gi.repository import Gtk
class MyWindow(Gtk.Window):
def __init__(self):
Gtk.Window.__init__(self, title="Drag Handle Example")
self.set_default_size(300, 200)
box = Gtk.Box(orientation=Gtk.Orientation.VERTICAL, spacing=6)
self.add(box)
# Create a button with a drag handle
button = Gtk.Button.new_with_label("Drag Me!")
box.pack_start(button, True, True, 0)
# Increase the drag threshold (hotspot) size to 20 pixels
button.set_drag_threshold(20)
win = MyWindow()
win.connect("destroy", Gtk.main_quit)
win.show_all()
Gtk.main()
In this example, we create a GTK window with a single button that has a Drag Handle. The set_drag_threshold(20) call increases the drag threshold (hotspot) size to 20 pixels, making it easier for users to interact with the button using the mouse or touch screen interface.
Adjust the value passed to set_drag_threshold as needed to find the appropriate hotspot size for your application. A larger value will increase the hotspot area, making it easier to grab the element, while a smaller value will make it more sensitive to dragging.
Keep in mind that this method is available in GTK 3.0 and later versions. If you’re using an older version of GTK, the method may not be available, and you’ll need to consider upgrading your GTK version.
Note: Gramps transitioned to GTK3 with version 4.2.4
Q: assume that the hotspot of a drag handle for changing any column width in any table (within an Python application using the GTK toolkit) is too small. How can the the threshold be changed globally for that application?
A: To change the hotspot (threshold) globally for all drag handles within a Python application using the GTK toolkit, you can modify the GTK settings related to the threshold. GTK provides a way to set the drag threshold at the application level, affecting all drag handles in the application.
To achieve this, you can use the gtk.drag_threshold_set() method to set the threshold value. The drag_threshold_set() method is part of the GTK Settings class and allows you to modify various application-wide settings.
There does appear to be a problem with the size of the pane separators. I changed their colour to red in order to see what was going on and I could only see the separator between the navigator and the view. Changing the padding and margin make the separator visible.
I have the same configuration as stated by johnrye06, with the possible exception of the DE: john’s isn’t mentioned, mine is plasma.
I’ve never seen that problem all the way up to gramps 5.1.3. The gramps version 5.1.5 is included in Mageia 9 for which the release candidate is being seeded now thru the mirrors, the official release coming “soonish”. I’ll check the RC and report back
Checked the Mageia 9 RC: has gramps 5.1.6 in its repository.
Run this gramps on an older laptop with MATE and XFCE DE’s: in both cases I could resize e.g. the People window, but I could not resize the columns as in the Mageia 8 - Gramps 5.1.3 - Plasma configuration.
I will try Mageia 9 RC gramps 5.1.6 Plasma config on a better laptop and report back.
Tested Mageia9 RC with gramps 5.1.6 and Plasma: all works well. So to me, it seems to be some DE issue. Over to you gramps people to check this out on your configurations. And BTW tx to all of you for the good work.
I’d love to test the suggestion from @Nick-Hall, but apparently the packager in Mageia has done something differently so this file in .config does not exist at all.
I will raise a bug in Mageia for this issue, so this person can have a look where this patch could be applied.
how do we create an overlay CSS sheet for the Gramps application that does not affect other GTK applications?
It seems like User customizations should not be in .config/gtk-3.0/
Can that be done with expansion of the Themes add-on? So that a User css sheet can be defined that overlays (dark & light variants) on top of the Themes selected CSS that is on top of the default CSS of the Gramps application
I followed Nick’s suggestion and that had some results:
The panes were now marked with a thick black line, not attractive to see
but I could grab these now and resize the panes
and - not expected??
The marking of the columns were not changed (very faint) but I could grab them and resize the columns within their pane.
And to emyoulation: the maintainer of the gramps package in Mageia made the same remark on the location of a patch (not to be in the user’s home) but I am a bit puzzled of you seeing this as a user customization. If I read this as gramps being a user of the gtk facilities, then I would agree. But I think this would be generic to all gramps users.