Was it intentional that you changed the version back to Unspecified, when it's clearly about 3.22, and back to this vague title instead of a better one?


(In reply to ikorot01 from comment #0)
> Moreover is there
> a reason a missing accessor for a style list control is missing from both
> implementations?

I think that should be a separate bug.

(In reply to ikorot01 from comment #0)
> I am trying to implement a font selection panel on the notebook which is on
> the dialog (something like an "Options" dialog). The dialog will have "OK",
> "Cancel" and "Apply" buttons. The "Apply" button is disabled initially, but
> if any changes to the font is made the button should become enabled in order
> to "apply" settings/options.

So, can't you listen to notify::font or notify::font-desc, then sensitise the Apply button when either changes?

https://developer.gnome.org/gtk3/stable/GtkFontChooser.html#GtkFontChooser--font

We are not going to add api back that exposes internals of the font chooser like that.

Hi, Daniel,
(In reply to Daniel Boles from comment #2)
> (In reply to ikorot01 from comment #0)
> > I am trying to implement a font selection panel on the notebook which is on
> > the dialog (something like an "Options" dialog). The dialog will have "OK",
> > "Cancel" and "Apply" buttons. The "Apply" button is disabled initially, but
> > if any changes to the font is made the button should become enabled in order
> > to "apply" settings/options.
> 
> So, can't you listen to notify::font or notify::font-desc, then sensitise
> the Apply button when either changes?
> 
> https://developer.gnome.org/gtk3/stable/GtkFontChooser.html#GtkFontChooser--
> font

At which point this property(-ies) is/are updated?
I need to enable the button on the click on the non-selected font name, for example. Is this when those are changed?
Or they are changed when I tab out of the list?

It's not hard to test that, using GTK_DEBUG=interactive to run any program that has a FontChooser widget.

The property changes when you click a different fond in the list.

Daniel,
(In reply to Daniel Boles from comment #5)
> It's not hard to test that, using GTK_DEBUG=interactive to run any program
> that has a FontChooser widget.
> 
> The property changes when you click a different fond in the list.

Is there a way to know which list was clicked?

Can you clarify what you mean? FontChoosers can't have more than one list of fonts, as far as I can tell (from experience and a search through the documentation). If you mean which FontChooser was changed, then sure, the first argument to any notify:: handler is the object on which the property changed.

Daniel,
(In reply to Daniel Boles from comment #7)
> Can you clarify what you mean? FontChoosers can't have more than one list of
> fonts, as far as I can tell (from experience and a search through the
> documentation). If you mean which FontChooser was changed, then sure, the
> first argument to any notify:: handler is the object on which the property
> changed.

But I will get a pointer to the generic GObject, right?
What I am looking for is a way to know whether it is a font list, size list or style list.

Yes, you'll get a pointer to the FontChooser only. As Matthias said, the internals like the TreeView are deliberately not exposed, and it sounds like that's what you want.

The intent of FontChooser is to provide something that lets a user choose a font and gives it to you - with a lot of detail, in the case of PangoFontDescription. That answers your first question about controlling the sensitivity of the button.

However, it's not (anymore, thankfully) meant to be an open box through which you can query lists of fonts/styles/sizes available on your system. There are real libraries for that kind of thing, which don't require GTK+ to maintain a whole load of code that's out of its scope.

So, the better solution would be not to rely on such methods, and get the info you want from somewhere else.


That said, in the meantime, it's not like GtkFontSelection is removed in GTK+ 3. It's just deprecated. It's still there, in <gtk/deprecated/gtkfontsel.h>. I don't recommend using this, since it's leaky API and will cause you a world of pain when migrating to GTK+ 4 later, where it *is* gone... but it's still in GTK+ 3.

Daniel,
As I wrote in the OP I don't care about font enumeration. I only want this to work as a page of notebook.
Also I guess I will have to query the font on every font change and assign my variables as appropriately.

It would be nice if the widget would contain a selectors for "Underline"/"Strikethrough" as in Windows/OSX, but it looks like GTK considers them not to change the font and it is completely different story.

Thank you for the pointer about the "font" property - I will test it tonight.

Daniel,
I tested with the following code:

[code]
static void font_name_change(GObject *gobject, GParamSpec *param_spec, FontPanel *page)
{
}

FontPanel::FontPanel()
#if GTK_CHECK_VERSION(3, 2, 0 )
    m_fontPanel = gtk_font_chooser_widget_new();
#else
    m_fontPanel = gtk_font_selection_new();
#endif
    g_object_ref_sink( m_fontPanel );
#if GTK_CHECK_VERSION(3, 2, 0 )
    gtk_font_chooser_set_font_desc( (GtkFontChooser *) m_fontPanel, m_font.GetNativeFontInfo()->description );
    gtk_font_chooser_set_preview_text( (GtkFontChooser *) m_fontPanel, "AaBbYyZz" );
#else
    gtk_font_selection_set_font_name( (GtkFontSelection *) m_fontPanel, m_font.GetNativeFontInfo()->ToString().c_str() );
    gtk_font_selection_set_preview_text( (GtkFontSelection *) m_fontPanel, "AaBbYyZz" );
    GtkWidget *names = gtk_font_selection_get_family_list( (GtkFontSelection *) m_fontPanel );
    GtkWidget *sizes = gtk_font_selection_get_size_entry( (GtkFontSelection *) m_fontPanel );
#endif
    g_signal_connect( m_fontPanel, "notify::font", G_CALLBACK( font_name_change ), this );
}
[/code]

I tested with the GTK+2.24 on Gentoo Linux.

The button does not become enabled. In fact the code doesn't even go into the font_name_change function.

Am I missing anything?

Thank you.

The properties I said to listen for are on the GtkFontChooser interface in GTK+ 3

If you want to achieve something similar with GtkFontSelection, then you need to use a property that it has...! so, in that case, try using :font-name instead:

  https://developer.gnome.org/gtk3/stable/GtkFontSelection.html#GtkFontSelection--font-name


I think following what Matthias said, if you can get this working (which should be OK), then we probably have to close this, since the internal lists won't be exposed again (and, even if the answer was a maybe, couldn't in GTK+ 3 by now, as it's aiming for LTS with new/modified API at minimum levels).

Daniel,
I changed that line to be:

    g_signal_connect( m_fontPanel, "notify::font-name", G_CALLBACK( font_name_change ), this );

but I still can't make it work.

I have GTK+ 2.24.29 on Gentoo Linux.

Is it possible that this is a bug with this specific version of GTK+?

Thank you.

Not sure, but I'm confused. We started with you wanting to know how to respond to changes on GtkFontChooser in GTK+ 3, but now we're talking about GtkFontSelection in GTK+ 2. Which do you really want? And is there really any bug anywhere? ;)


For the GtkFontSelection case, it's very odd: the property does not update immediately in the Inspector, but if you double-click on it, that forces the value to be updated, and then the notify:: handler runs.

I don't know whether that is considered a bug at this point, but it does seem weird.


Anyway, GtkFontChooser seemed to update fine, in real time, when I monitored the properties using the GTK+ Inspector, as the selected font or size change.


So, I'm not certain, but this may just be more evidence that rather than trying to conditionally support and achieve the same thing with both, it's probably far better to pick one and stick with it, and FontChooser will produce far less hassle in the future as it's not been removed in GTK+ 4.

Daniel,
I do want to support both GTK+2 and 3. It is visible from the code I posted earlier.
I would agree with you about sticking with one control, however FontChooser is not available on GTK+2.
Now from what you wrote it sounds like the only option for GTK+2 is to call gtk_container_forall(), find the appropriate pointers and connect them to "cursor-changed" signal. Will this approach work?

Thank you.

I don't know. Unless anyone else does, you'll just have to try various things and see if any of them suffice.

Yes, you can presumably get the treeviews through either the existing widget accessors and casts, or scary hierarchy-diving and widget-casting for the one that isn't exposed. I say presumably; this should be possible, but I doubt it'll make for pleasant code.

I didn't test other situations to see if FontSelection:font-name is useful in those, to deduce whether the property is behaving as intended Either way. I can't speak for how likely it is to be fixed at this point. But I'll leave the bug open to clarify that issue (although the other requests for more/restored detail in the API won't happen).

Daniel,
I did make it work on GTK+2 using gtk_container_forall().
I will test GTK+3 later. For now this probably needs to be closed, since GTK+2 slowly becomes outdated.
Unless there is a reason to keep it open.

Whats the reason for supporting gtk2 if you have a gtk3 port, at this point?

I don't see anything that needs fixing here, so I'll close this.