Font chooser GtkAction migration
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction usage in the TextToolbar. It seems that the only sticking point is the use of the Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do that, I just wondered if we had considered using the standard GtkFontButton ( https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would pop-up a font-chooser dialog ( https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht...) rather than providing an entry in a combobox. This could result in a less cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything without asking!
Any thoughts?
AV
Hi Alex,
I think there is a technical and an UX aspect to this question:
* On the UX side of things I have a feeling people expect the text toolbar to offer direct controls for font family, style and size and will not appreciate the additional dialog and additional click(s) that come with it. Also this takes the possibility from people to have an immediate preview of their change on canvas, making tuning around the font to match the drawing much harder. One more thing to consider is that gtk's font picker offers more or less the same functionality as our "Text and Font" dialog (effectively duplicating that functionality) whereas it seems we actually have two groups of users: Some seem to prefer the text toolbar, some seem to prefer the "Text and Font" dialog. * On the technical side of things: How does gtk determine the available fonts / the fonts to display in the picker? How'd a selection be translated to a font available for on-canvas use in Inkscape? There are at least three things to consider: o We use pango's freetype2 / fontconfig back-end for rendering fonts on canvas. That might also be gtk's default on Linux, but on Windows and Mac native back-ends are in use (I think via the cairo back-end) and the available fonts are known to differ between the back-ends. As a consequence rendering of fonts on canvas (which currently matches the available fonts and the preview in the text toolbar) is different from native rendering via gtk (which is also used for the "Text and Font" dialog preview I think) and sometimes fonts are claimed to be available (but are actually not) and vice-versa. This has caused a lot of confusion in the past already and might get much worse if also the font toolbar behaves differently than what Inkscape eventually renders on-canvas. o We taught Inkscape to add additional fonts (i.e. webfonts / or fonts from custom non-system directories) by attaching them to Pango's "FcConfig" (see commit d6c5424f69aeb91cf1cfeba262b5466a42dd95a5). Will they be available in the gtk3 font picker? o As on-canvas rendering is done by pango's freetype2 / fontconfig back-end we ultimately have to rely on fontconfig to index all available fonts and at least on Windows this needs some adjustments in etc/fonts.conf. Will those have any effect on the gtk3 font picker?
Cheers, Patrick
Am 11.02.2019 um 16:14 schrieb Alex Valavanis:
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction usage in the TextToolbar. It seems that the only sticking point is the use of the Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do that, I just wondered if we had considered using the standard GtkFontButton (https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would pop-up a font-chooser dialog (https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht...) rather than providing an entry in a combobox. This could result in a less cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything without asking!
Any thoughts?
AV
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2019-02-11 at 15:14 +0000, Alex Valavanis wrote:
Hi Tav and devs, I'm currently looking into getting rid of the deprecated GtkAction usage in the TextToolbar. It seems that the only sticking point is the use of the Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do that, I just wondered if we had considered using the standard GtkFontButton ( https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would pop-up a font-chooser dialog ( https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht... ) rather than providing an entry in a combobox. This could result in a less cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything without asking!
Any thoughts?
Our font selector has a lot of custom features that are incompatible with the standard font selector. It will indicate when fonts in the SVG are not locally available. It handles CSS font fallback lists. It displays fonts that are used in an SVG file at the top. It has a customizable font preview. Might be one or two things I've forgotten. It would be difficult to replace this functionality with the standard Gtk font button. Tav
AV
On Mon, Feb 11, 2019 at 03:14:53PM +0000, Alex Valavanis wrote:
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction usage in the TextToolbar. It seems that the only sticking point is the use of the Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do that, I just wondered if we had considered using the standard GtkFontButton ( https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would pop-up a font-chooser dialog ( https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht...) rather than providing an entry in a combobox. This could result in a less cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything without asking!
Any thoughts?
Like Tav and Patrick mentioned, there's been a lot of customization work of the font selector toolbar and dialog, and given that this is heavily used by our userbase, even small behavior reductions may generate a lot of complaints. This is an area to be especially cautious with.
Are there any behavioral improvements that GtkFontButton would provide over our current widgets?
Bryce
Ok thanks for the feedback... I expected that this would be a can of worms, so I'm glad I checked!
I'll go ahead with migrating the existing widget to a tool-item derivative so we don't lose any of the existing functionality.
AV
On Mon, 11 Feb 2019, 19:55 Bryce Harrington, <bryce@...961...> wrote:
On Mon, Feb 11, 2019 at 03:14:53PM +0000, Alex Valavanis wrote:
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction usage
in
the TextToolbar. It seems that the only sticking point is the use of the Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do
that, I
just wondered if we had considered using the standard GtkFontButton ( https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would pop-up
a
font-chooser dialog (
https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht... )
rather than providing an entry in a combobox. This could result in a
less
cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything without asking!
Any thoughts?
Like Tav and Patrick mentioned, there's been a lot of customization work of the font selector toolbar and dialog, and given that this is heavily used by our userbase, even small behavior reductions may generate a lot of complaints. This is an area to be especially cautious with.
Are there any behavioral improvements that GtkFontButton would provide over our current widgets?
Bryce
Is it possible for Inkscape to store the font previews in a file instead of having to re-draw them all each time Inkscape is re-opened (and the font dialog clicked on). The reason is if you have a large number of fonts on the system, it takes a very long time for Inkscape to re-draw them all, and in the meantime the user can do nothing but wait (nothing else can be done in Inkscape until all the previews are complete).
Ideally, Inkscape would only re-draw these previews when fonts are added or updated, and even more ideally, NOT at the time when the user opens the drop-down font chooser. Seems like something which could be checked when Inkscape starts up? Thanks for looking at it, Alex!
-C
On Mon, Feb 11, 2019 at 8:01 PM Alex Valavanis <valavanisalex@...400...> wrote:
Ok thanks for the feedback... I expected that this would be a can of worms, so I'm glad I checked!
I'll go ahead with migrating the existing widget to a tool-item derivative so we don't lose any of the existing functionality.
AV
On Mon, 11 Feb 2019, 19:55 Bryce Harrington, <bryce@...961...> wrote:
On Mon, Feb 11, 2019 at 03:14:53PM +0000, Alex Valavanis wrote:
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction
usage in
the TextToolbar. It seems that the only sticking point is the use of
the
Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do
that, I
just wondered if we had considered using the standard GtkFontButton ( https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would
pop-up a
font-chooser dialog (
https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht... )
rather than providing an entry in a combobox. This could result in a
less
cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything without asking!
Any thoughts?
Like Tav and Patrick mentioned, there's been a lot of customization work of the font selector toolbar and dialog, and given that this is heavily used by our userbase, even small behavior reductions may generate a lot of complaints. This is an area to be especially cautious with.
Are there any behavioral improvements that GtkFontButton would provide over our current widgets?
Bryce
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Caching of the font previews is an orthogonal issue to the widget layout, but may be worth looking into. In fact the whole subsystem's codebase could probably benefit from a deep review and look at how to make it both more performant and more user-friendly. But from what I recall from when it was developed, that could prove to be quite a big project.
Feel free to jot down your own thoughts about improvements into a bug report in Inbox that we can focus brainstorming into.
Bryce
On Mon, Feb 11, 2019 at 08:26:37PM +0000, C R wrote:
Is it possible for Inkscape to store the font previews in a file instead of having to re-draw them all each time Inkscape is re-opened (and the font dialog clicked on). The reason is if you have a large number of fonts on the system, it takes a very long time for Inkscape to re-draw them all, and in the meantime the user can do nothing but wait (nothing else can be done in Inkscape until all the previews are complete).
Ideally, Inkscape would only re-draw these previews when fonts are added or updated, and even more ideally, NOT at the time when the user opens the drop-down font chooser. Seems like something which could be checked when Inkscape starts up? Thanks for looking at it, Alex!
-C
On Mon, Feb 11, 2019 at 8:01 PM Alex Valavanis <valavanisalex@...400...> wrote:
Ok thanks for the feedback... I expected that this would be a can of worms, so I'm glad I checked!
I'll go ahead with migrating the existing widget to a tool-item derivative so we don't lose any of the existing functionality.
AV
On Mon, 11 Feb 2019, 19:55 Bryce Harrington, <bryce@...961...> wrote:
On Mon, Feb 11, 2019 at 03:14:53PM +0000, Alex Valavanis wrote:
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction
usage in
the TextToolbar. It seems that the only sticking point is the use of
the
Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do
that, I
just wondered if we had considered using the standard GtkFontButton ( https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would
pop-up a
font-chooser dialog (
https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht... )
rather than providing an entry in a combobox. This could result in a
less
cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything without asking!
Any thoughts?
Like Tav and Patrick mentioned, there's been a lot of customization work of the font selector toolbar and dialog, and given that this is heavily used by our userbase, even small behavior reductions may generate a lot of complaints. This is an area to be especially cautious with.
Are there any behavioral improvements that GtkFontButton would provide over our current widgets?
Bryce
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
Yea, just thought I'd mention it because it's currently being looked at. No pressure, just me pitching ideas to the poor mechanic drowning in motor oil under the car, from the waiting room. :)
-C
On Mon, Feb 11, 2019 at 9:23 PM Bryce Harrington <bryce@...961...> wrote:
Caching of the font previews is an orthogonal issue to the widget layout, but may be worth looking into. In fact the whole subsystem's codebase could probably benefit from a deep review and look at how to make it both more performant and more user-friendly. But from what I recall from when it was developed, that could prove to be quite a big project.
Feel free to jot down your own thoughts about improvements into a bug report in Inbox that we can focus brainstorming into.
Bryce
On Mon, Feb 11, 2019 at 08:26:37PM +0000, C R wrote:
Is it possible for Inkscape to store the font previews in a file instead
of
having to re-draw them all each time Inkscape is re-opened (and the font dialog clicked on). The reason is if you have a large number of fonts on the system, it
takes a
very long time for Inkscape to re-draw them all, and in the meantime the user can do nothing but wait (nothing else can be done in Inkscape until all the previews are complete).
Ideally, Inkscape would only re-draw these previews when fonts are added
or
updated, and even more ideally, NOT at the time when the user opens the drop-down font chooser. Seems like something which could be checked when Inkscape starts up? Thanks for looking at it, Alex!
-C
On Mon, Feb 11, 2019 at 8:01 PM Alex Valavanis <valavanisalex@...400...> wrote:
Ok thanks for the feedback... I expected that this would be a can of worms, so I'm glad I checked!
I'll go ahead with migrating the existing widget to a tool-item
derivative
so we don't lose any of the existing functionality.
AV
On Mon, 11 Feb 2019, 19:55 Bryce Harrington, <
bryce@...961...>
wrote:
On Mon, Feb 11, 2019 at 03:14:53PM +0000, Alex Valavanis wrote:
Hi Tav and devs,
I'm currently looking into getting rid of the deprecated GtkAction
usage in
the TextToolbar. It seems that the only sticking point is the use
of
the
Ink_ComboBoxEntry_Action widget to select fonts.
It should be OK to migrate this to a Gtk::ToolItem, but before I do
that, I
just wondered if we had considered using the standard GtkFontButton
(
https://developer.gnome.org/gtk3/stable/GtkFontButton.html)?
This would provide a summary of the font face and size, but would
pop-up a
font-chooser dialog (
https://developer.gnome.org/gtkmm-tutorial/stable/sec-font-chooser-dialog.ht...
)
rather than providing an entry in a combobox. This could result in
a
less
cluttered toolbar, but I suspect there might be some "clever things" going on in our font support, and I don't want to break anything
without
asking!
Any thoughts?
Like Tav and Patrick mentioned, there's been a lot of customization
work
of the font selector toolbar and dialog, and given that this is
heavily
used by our userbase, even small behavior reductions may generate a
lot
of complaints. This is an area to be especially cautious with.
Are there any behavioral improvements that GtkFontButton would provide over our current widgets?
Bryce
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Mon, 2019-02-11 at 20:00 +0000, Alex Valavanis wrote:
I'll go ahead with migrating the existing widget to a tool-item derivative so we don't lose any of the existing functionality.
AV
I seem to have started this project at one point. Take a look at src/ui/widget/font-selector-toolbar.h/cpp. Also, it might be possible to share code with the Text Dialog font selector: src/ui/widget/font- selector.h/cpp
Tav
participants (5)
-
Alex Valavanis -
Bryce Harrington -
C R -
Patrick Storz -
Tavmjong Bah