Fwd: [Bug 788266] Adding Underline/Strikethrough selectors
- Date: Thu, 5 Oct 2017 21:29:40 -0400
- From: Igor Korot <ikorot01@xxxxxxxxx>
- Subject: Fwd: [Bug 788266] Adding Underline/Strikethrough selectors
I don't mind discussing this on the ML.
---------- Forwarded message ----------
From: gtk+ <bugzilla@xxxxxxxxx>
Date: Thu, Oct 5, 2017 at 6:48 PM
Subject: [Bug 788266] Adding Underline/Strikethrough selectors
Comment # 15 on bug 788266 from Daniel Boles
(In reply to ikorot01 from comment #14)
> You refer me to the GTK API.
> It looks like the first comment from Mathias said "those properties have a
> different way of being selected".
> I'm still waiting for the application that allows user to select such font
> properties And to show how it's done.
> So in essence I believe Mathias failed me here.
>lol what. This isn't a help forum. It's for bug reports. You wanting code
> handed to you isn't a bug in GTK+. And no one replying here has any duty to
I don't want the code.
This feature request started as a request to add to checkboxes to the
FontChooser panel. Its not even a bug per se.
> Moreover, this is not about preview. In fact I don't card about preview In
> this case. I just want my user to be able to select those 2 properties the
> same way MS and Apple do.
>It's not about preview... so why did you file it against the FontChooser, which
>exists to preview fonts?
Then it shouldn't be called FontChooser, but rather FontPreviewer.
Wouldn't you agree?
In this case - yes, those 2 check boxes doesn't make much sense
and the programmer can easily add them to the panel either above as in
OSX or below as in Windows.
But as long as it calls itself FontChooser and its part of the font
I believe those 2 checkboxes can be added.
>You keep invoking MS and Apple as though that's an automatic rhetorical
>victory, somehow... but they don't embed huge lists of fonts in their toolbars;
t>hey provide buttons to act on text spans - like you'll be able to do with the
>API mentioned by Emmanuele. Or they provide an enhanced font chooser widget,
>which you are very welcome to subclass and use as the chooser in your own
But why subclassing?
Why just not provide ready-to-go solution as OSX or provide them
as controls on one panel as in Windows?
>Basically, I think that in this case, you expect more comprehensive or
>high-level things from GTK+ than GTK+ is setting out to provide. That's fine;
>it can't be everything to everyone. But you can usually take the components and
>create what you want.
Well, of course I can. As a programmer in C/C++ I have a full and
complete power of what
my program will do. But this is not high-level thing
Unless of course this is not a FontChooser, but FontPreviewer.
>But in the absence of GTK+ already doing it for you, you expect people here to
>provide you code on a plate or Google for another rich text editor for you.
>That kind of thing might work on the mailing list or IRC, but it's not for
It's not me who started that flame.
Like I said - re-read what Mathias said in the first reply in the ticket:
these are text attributes that should get applied to a selected range
of text, typically editors offer controls for that.
He doesn't say how they are doing it so that I can go and do that same
Nor he provided an example of such application for me to check and
implement the same "HotKey"/Menu/ContextMenu/whatever.
I tried to do some research, but was immediately turned down.
To summarize: I'm not looking for a code solution - I can code that myself.
I also gather that there is no "standard" way of applying those
attributes to any standard GNOME text editor.
So I guess it is "expected" for a developer to code thise 2 checkboxes
with the "FontPreviewer" (not FontChooser")
control on a panel.
You are receiving this mail because:
You are on the CC list for the bug.
You reported the bug.
gtk-list mailing list