Extension prefs dialog is oversized

[realh (Tony Houghton)]

This follows on from an earlier thread I created, but I’ve got a different problem now.

I implemented the UI for my extension in its prefs dialog. The problem now is that the dialog is too big, with loads of wasted space. During testing, when I created my own window, it automatically made itself just big enough for the content. As extension prefs I don’t have control over the window, I can only create its main widget. The widget is a vertical Gtk.Box containing a Label and set of radio buttons for each monitor. Any ideas on how I can shrink the window to fit it?

The extension is just about usable now, so I’ve published it on github.

[andyholmes]

You can get access to the preferences window, it’s just a bit of a trick:

function buildPrefsWidget() {
    // Your prefs widget
    let prefsWidget = new Gtk.Box();

    // At the time buildPrefsWidget() is called, the window is not yet
    // prepared, so to access it wait until the loop starts
    GLib.timeout_add(0, () => {
        let prefsWindow = prefsWidget.get_toplevel();
        return GLib.SOURCE_REMOVE;
    });

    return prefsWidget;
}

[realh (Tony Houghton)]

Yes, I saw how they used that in the wiki example to set the window title, but I thought using the “parent-set” signal would be a better idea.

However, my problem isn’t that I don’t have access to the window at all, but I don’t have enough control over it. Usually the best way to make a dialog exactly the right size for its content is to do nothing. But something is making this one far too big. I could probably change it back somehow, but reading the appropriate size for widgets and allowing for window borders etc, when GTK isn’t doing it automatically for you, is a real pain.

I’m having other problems with this persistent dialog model anyway, and finding the panel icon during overscan isn’t that big a problem, so I think on balance rewriting it as a standard St panel menu is a better way forward. Except that the ui module doesn’t seem to have a ready-made radio button widget, so I’ll have to try to work something out based on checkbox.

[andyholmes]

I believe the extension preferences window has 600x400 for default-width/default-height, probably being the cause. I’m not sure if that can be changed before it is applied, but you might open an issue in gnome-shell requesting an upstream change to this behaviour?

Of course, there’s nothing saying you have to use the provided window. You can use the same method above to proxy spawning a simple 1-window app (I do this in GSConnect so I can use a UI template widget), or like you say do your configuration in shell widgets.

I used a dead-simple implementation of radio buttons awhile ago that you’re welcome to glance at or re-use without attribution.

[realh (Tony Houghton)]

Thanks for that. I was (also) planning to base my radio on checkbox but I wasn’t sure how to make it render with a round button instead of a checkbox. gnome-shell’s checkbox uses a custom SVG fom gnome-shell’s resources, so that misdirected me from the existence of the standard radio SVG.