7:14 a.m.
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...)
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
10:17 a.m.
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...)
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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
10:22 a.m.
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...
) 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
11:55 a.m.
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...)
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
noon
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...
)
> 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
12:26 p.m.
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...
> )
> > 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(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/inkscape-devel
1:23 p.m.
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...
>> )
>> > 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(a)lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel
>
2:36 p.m.
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...
> >> )
> >> > 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(a)lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/inkscape-devel
> >
12:33 p.m.
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
1757
days inactive
1757
days old
inkscape-devel@lists.inkscape.org
8 comments
5 participants
participants (5)
-
Alex Valavanis -
Bryce Harrington -
C R -
Patrick Storz -
Tavmjong Bah