Re: The Future?

[Paul Davis]

On Sat, Mar 9, 2019 at 5:19 AM J.Arun Mani via gtk-list 
wrote:

>
> 2. How does Gtk address the issue of its users moving to Qt?
>

What evidence is there of this? Who are the "users" of GTK that you're
referring to? Moving an existing GUI app between toolkits is typically
almost equivalent to a complete rewrite, so applications (which are the
real "users" of a toolkit) generally do not move. Developers may start new
projects using Qt having previously used GTK, but who counts this? How
would we judge if it is significant?


> 3. What makes them move to Qt? Why can't Gtk have that respective feature?
>

Qt has as many issues as GTK once you start using it for complex, deep
applications. Different issues, to be sure, but no GUI toolkit gives you a
free ride.

Qt is also developed using a different licensing/income generation model
than GTK, which changes quite a lot.

Qt mostly has distinct advantages over GTK, and to be honest if I was
starting cross-platform development now (22 years after I actually did),
I'd probably pick Qt for all the obvious reasons. But it's fairly pointless
to ask "how can GTK be more like Qt?" when there's more or less no chance
or pathway for that to happen. As it is, I don't do mobile so GTK's issues
there don't affect me. I also have 75k lines of code that would have to be
almost completely rewritten to use Qt, with no noticeable benefit for our
users and only marginal benefits for our developers.

Speaking of "why can't?", why can't I write a C application using Qt  ? :))
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Gtk::Widget::is_mapped ()

[Paul Davis]

On Sun, Mar 3, 2019 at 9:21 AM Emmanuele Bassi  wrote:

> No, it's not. The issue is not GTK: it's the windowing system.
>
> With the advent of compositing, all windows are "visible" all the time,
> from a toolkit perspective. The compositor is responsible for building
> what's presented to the user. For example: are windows fully visible when
> doing an "exposé"-like view? Are they not? If the compositor is ultimately
> responsible of creating the final result of what's on the screen, it could
> put each window on separate planets as far as the toolkit is concerned
> (assuming latency and coordinate space size aren't a problem).
>

seems to me like an extremely uninteresting question. "expose" means "while
you, the app, doesn't know why, it's time for you to redraw (some|all) of
the contents of this window right now". visibility or otherwise doesn't
seem relevant to that.


> On Wayland is even "worse", because each window surface is completely
> separate from every other window surface by design; each window has its own
> coordinate system, that has an origin in the top-left corner of the window.
> A window *cannot* be obscured by another window, as far as the toolkit is
> concerned.
>
> If you're targeting an X11 system from the late '90s/early '00s, then
> visibility notifications *may* be emitted (though they are never
> guaranteed). On anything more modern than that, or on
> Wayland/Windows/macOS, visibility notification events are either
> non-sensical, not emitted, or not possible by design.
>

macOS as of Sierra still causes GTK(2) to generate sensible visibility
notification events. AFAIK, we still get them on current Windows systems
too.

It seems to me somewhat insane that Wayland has broken this concept (I take
you at your word that it has). Part of the job of a window manager is not
just user-facing, but also app-facing, and that includes telling an
application about the state of its window(s). It doesn't seem even remotely
unreasonable to expect that this would include visibility changes.  It's a
bit like saying "some system component could make the window any size it
chooses too at all, so it has the app has no way to know how large its
windows are."

Oh well.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk::Widget::is_mapped ()

[Paul Davis]

On Sun, Mar 3, 2019 at 6:26 AM Emmanuele Bassi via gtk-devel-list <
gtk-devel-list@gnome.org> wrote:

> On Sun, 3 Mar 2019 at 12:58, John Emmas  wrote:
>
>>
> For example... let's say the widget is a top-level window.  If it's
>> currently displayed on screen but there's some other window hiding it
>> (maybe from a totally different app) would 'is_visible()' return true or
>> false?
>>
>
> That's entirely different, and you should have said so at the very
> beginning of the thread. Yes, both "visible" and "mapped" would be set to
> true because you called show() on the window, and a window has no parents,
> so once it's visible and realized, it'll be mapped as well; there is no way
> to know, from a toolkit perspective, if a top level is being partially, or
> totally, covered by some other window, either in the same process or from a
> different process. That information is only available to the window manager.
>

John should really know that there's code to do this (to the best extent
possible) within the Ardour source code at
libs/gtkmm2ext/visibility_tracker.cc :)))

It works (to whatever extent it does work) by handling GtkEventVisibility
notifications. Hopefully this is still possible in GTK3 ?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Emitting signals from threads

[Paul Davis]

You are right, and I withdraw my remarks. As noted, I didn't read it
carefully enough.

But yes, g_idle_add_full() runs in the worker thread, however that's one
thing that is always OK.

On Wed, Feb 27, 2019 at 6:03 PM Mitko Haralanov 
wrote:

> But that's not how the code is written:
>
> g_task_run_in_thread(obj->task, custom_object_work) ->
>   custom_object_worker() ->
>  signal_emit() ->
> g_idle_add_full(..., signal_emitter, ...);
>
> signal_emitter() is the function that *actually* emits the signal.
> signal_emitter() is supposed to be running in the main context thread
> by the virtue of being the g_idle_add_full() callback.
>
> Are you saying that the g_idle_add_full() callback also runs in the
> worker thread?
>
> On Wed, Feb 27, 2019 at 4:54 PM Paul Davis 
> wrote:
> >
> >
> >
> > On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov 
> wrote:
> >>
> >> How is that? The update is happening from a callback executed by the
> >> main context thread?
> >
> >
> > g_task_run_in_thread(obj->task, custom_object_worker);
> >
> > custom_object_worker() emits the "updated" signal. the handler modifies
> the model.
> >
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Paul Davis]

On Wed, Feb 27, 2019 at 5:46 PM Mitko Haralanov 
wrote:

> How is that? The update is happening from a callback executed by the
> main context thread?
>

g_task_run_in_thread(obj->task, custom_object_worker);

custom_object_worker() emits the "updated" signal. the handler modifies the
model.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Paul Davis]

On Wed, Feb 27, 2019 at 5:17 PM Mitko Haralanov via gtk-list <
gtk-list@gnome.org> wrote:

> Here is a small program that illustrates the issue:
>
>
Yep. You're updating a treemodel from your own thread while the treeview is
connected to it. You can't do this.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Emitting signals from threads

[Paul Davis]

It is possible that I haven't read this thread carefully enough.

You cannot update a GtkTreeModel or any other similar data structure that
is currently being used as "the model" by a GtkTreeView or other similar
widget, from a worker thread.

The model will emit signals reflecting what you've done to it, and the
widget will do "GTK stuff" in its handlers for those signals, which will
execute inside the worker thread.

You *can* update a GtkTreeModel (or similar) from a worker thread if you
ensure that it is detached from any view widget during your updates.


On Wed, Feb 27, 2019 at 3:45 PM Mitko Haralanov via gtk-list <
gtk-list@gnome.org> wrote:

> I could start a new thread but will be confusing for anyone who may be
> reading this thread a year from now researching a similar problem.
>
> So, with that said, let me try to clarify:
>
> The application has a GtkTreeView being populated by a GtkTreeModel.
> The TreeView has 3 columns, the last one having a GtkCellRenderPixbuf
> displaying a "gtk-edit" icon. The TreeView also has a
> button-presse-event callback connected, which checks where in the
> TreeView the mouse button has clicked and if it happens to be on the
> last column/renderer, opens an "Edit" dialog box. One of the other
> columns of the TreeView has a GtkCellRendererSpinner attached to it.
> This cell render has a cell data function that will "spin" the spinner
> when the model gets updated. The GtkTreeModel backing the TreeView
> contains a column that is of type guint64. This is the value that
> causes the GtkCellRendererSpinner to "spin" when it gets updated.
>
> The actual event which causes the model to get updated is the
> application finding a file on the filesystem matching a certain
> pattern. This discovery process is happening in a worker thread as to
> not block the main UI. In that worker thread, the filesystem is
> scanned recursively looking at all files in a directory tree. When a
> file matching the pattern is found, a function is scheduled using
> g_idle_add()/g_main_context_invoke_full(). This callback is what
> actually emits a signal whose handler updates the model.
>
> So, the worker thread is not doing the *real* signal emission. It's
> just scheduling a function to run in the main context thread, which
> does the *real* signal emission.
>
> As I mentioned in a previous email, I haven't had a lot of time to
> create a separate application to show this. I can try to do that if
> things are still not clear but I was hoping that the additional
> information, which I posted earlier might be useful.
>
> Thank you,
> - Mitko
>
> On Wed, Feb 27, 2019 at 2:18 PM Fontana Nicola  wrote:
> >
> > Il giorno mar, 08/01/2019 alle 10.02 -0800, Mitko Haralanov via gtk-list
> ha
> > scritto:
> > > Thanks for the reply.
> > > ...
> >
> > Hi,
> >
> > I find this mail thread really confusing and with a lot of misleading
> > guesses. As already stated elsewhere, a minimal working example would
> > likely be a *much* quicker way to solve your problem. I'd also suggest
> > to start a new clean mail thread.
> >
> > > One of the main reasons why I am not using g_idle_add() is the timing
> > > of the callback. I don't want to defer the processing of the callback
> > > to the "idle" time since this is signal handling related.
> >
> > g_main_context_invoke is just a wrapper around an idle GSource:
> >
> > https://gitlab.gnome.org/GNOME/glib/blob/master/glib/gmain.c#L5854
> >
> > There no magic speed gain in using it instead of g_idle_add: it just
> > happens to be more convenient.
> >
> > > Another advantage of g_main_context_invoke[_full]() is that it will
> > > check the "context" of the caller and, if possible, will call the
> > > callback directly:
> >
> > Here rings an alarm bell: you are in a worker thread and you want to
> > execute some code in the GTK thread; how can you expect that code to be
> > called directly?
> >
> > In another email you said:
> >
> > > The only thing that the threaded signal callback is doing is changing
> > > the *model*, which should be allowed.
> >
> > I don't know what a "threaded signal callback" is, but if with that you
> > meant code executed in the worker thread, can you please point me where
> > you got the idea that the model could be changed from outside the GTK
> > thread? I always thought this was *not* allowed.
> >
> > Apart from that I still did not understand if you have problems with
> > threads, with timing, with user interface not updating properly or
> > other.
> >
> > Ciao.
> > --
> > Nicola
> >
> >
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: A Question

[Paul Davis]

On Fri, Feb 22, 2019 at 7:26 PM Thomas Dineen via gtk-list <
gtk-list@gnome.org> wrote:

> Gentle People:
>
> A question on Cairo: The X Y inputs to Cairo drawing functions are
> type double.
>
> Dose this imply that pixel or line spacing could be less than 1.0?
>
> Could the spacing be say 0.5 or 0.25?
>

No.

However, there is an important semantic sense to units in Cairo that end in
.5, which you and should read more about here:

https://www.cairographics.org/FAQ/#sharp_lines

Understanding what is described there is critical to working with Cairo,
and more generally to almost any computer graphics based on pixel displays
(ie. everything at this point).
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re:

[Paul Davis]

On Wed, Feb 20, 2019 at 12:36 PM Igor Korot  wrote:

>
> This is all correct and I'm not arguing about that.
>
> What I do argue is why the context-menu event should care what mouse
> button click it comes from?
>

if the menu is shown on button press (not release) (and this is typical),
then something has be a little clever about the next-arriving button
release event.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re:

[Paul Davis]

On Wed, Feb 20, 2019 at 11:10 AM Igor Korot  wrote:

> Hi, Paul,
>
> On Wed, Feb 20, 2019 at 12:03 PM Paul Davis 
> wrote:
> >
> >
> >
> > On Wed, Feb 20, 2019 at 10:49 AM Igor Korot via gtk-list <
> gtk-list@gnome.org> wrote:
> >>
> >>
> >> Why do we even talking about button number, when the doc explicitly said
> >> "right-click", which implies "right mouse button".
> >
> >
> > X Window (at the very least) allows buttons to be remapped. Button #1 is
> typically the left mouse button, but a user may remap them (eg. left-handed
> people with a strong preference for using the mouse in their left hand).
> "left" and "right" buttons normally have a semantic meaning (e.g. "the
> button normally used for clicking on things" vs "the button used for
> context menus etc.") and you cannot hard code these on X Window.  More
> precisely, if you do hard code them, you disenfranchise a set of users who
> remap their mouse buttons.
>
> Are you saying that if I map the left mouse button to be the right one
> and click on it, I will not get that signal?
>
> As far as the user code is concerned, the button I press to get the
> context menu shouldn't matter, because this a low-level signal.
> All the user code should be aware is - did I click the action button
> or context menu one. Why do I need to care which is which?
>
> Could you give me a scenario?
>

hold the mouse in your right hand. put your index finger on the most
naturally positioned button. press it.

by default, X Window will generate a mouse button event using button number
one.

now put the mouse in your left hand, put that index finger on the most
naturally positioned button, press it.

by default, X Window will generate a mouse button event using button number
three.

programmers don't want to deal with this in their code, so they generally
assume that button #1 is "left button" and button #3 is "right button".

but what they really mean is "button used for most button clicks" and
"button used for context clicks"

a dedicated left-handed user may remap this so that their left index finger
correctly generates button 1 - the button used for most clicks.

your code can assume that 1 => most clicks; 3 => context click

it cannot assume that 1 => left ; 3 => right
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re:

[Paul Davis]

On Wed, Feb 20, 2019 at 10:49 AM Igor Korot via gtk-list 
wrote:

>
> Why do we even talking about button number, when the doc explicitly said
> "right-click", which implies "right mouse button".
>

X Window (at the very least) allows buttons to be remapped. Button #1 is
typically the left mouse button, but a user may remap them (eg. left-handed
people with a strong preference for using the mouse in their left hand).
"left" and "right" buttons normally have a semantic meaning (e.g. "the
button normally used for clicking on things" vs "the button used for
context menus etc.") and you cannot hard code these on X Window.  More
precisely, if you do hard code them, you disenfranchise a set of users who
remap their mouse buttons.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Glib::Threads:Private

[Paul Davis]

On Wed, Feb 20, 2019 at 1:17 AM John Emmas  wrote:

> I realise it's a deprecated interface but can anyone explain what
> Glib::Threads:Private does?
>
> Does it guarantee that 'SomeObject' can only be accessed by code running
> in a particular thread?  And if so, does it do that by creating a
> specific thread for the object - or does it use whichever thread was
> running when Glib::Threads:Private got called?  Hope that makes sense
>

It means that each thread that accesses the variable sees a distinct or
"thread-local" version of it.
The language runtime creates memory for thread-local storage at program
startup, and each thread has its own section (inaccessible from other
threads) where these "thread-local" variables are allocated.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GtkSelectionMode

[Paul Davis]

On Wed, Feb 13, 2019 at 10:49 PM Igor Korot  wrote:

> Hi, Paul,
>
> On Wed, Feb 13, 2019 at 10:03 PM Paul Davis 
> wrote:
> >
> >
> >
> > On Wed, Feb 13, 2019 at 2:30 PM Igor Korot via gtk-list <
> gtk-list@gnome.org> wrote:
> >>
> >>
> >> Unfortunately thats not how it looks here.
> >> When I create a control with GTK_SELECTION_MULTIPLE and just click on
> >> the item - it works just like single selection.
> >> In order to select multiple strings I have to press Ctrl key.
> >
> >
> > what platform or desktop toolkit does *not* work this way?
>
> I'm running Gentoo Linux with GNOME 3 and GTK+ 3.22.30 from Gentoo
> repository
>
>
I'm afraid you missed my point. The behaviour you described sounds like the
behaviour I have always seen on every version of Linux and every version of
macOS that I've ever used. I have never come across an
application/platform/desktop toolkit that uses a mouse and works
differently to what you've described. To select multiple strings, you have
to differentiate between "forget the current selection, i'm starting a new
one" and "i want to add this to the selection", and the convention has been
to use a modifier key (typically Ctrl) to do that.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GtkSelectionMode

[Paul Davis]

On Wed, Feb 13, 2019 at 2:30 PM Igor Korot via gtk-list 
wrote:

>
> Unfortunately thats not how it looks here.
> When I create a control with GTK_SELECTION_MULTIPLE and just click on
> the item - it works just like single selection.
> In order to select multiple strings I have to press Ctrl key.
>

what platform or desktop toolkit does *not* work this way?
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Moving from mailing lists to Discourse

[Paul Davis]

On Fri, Feb 8, 2019 at 7:33 AM Emmanuele Bassi via gtk-devel-list <
gtk-devel-list@gnome.org> wrote:

>
> As for the subscription: Discourse supports multiple identity
> providers—Google, Facebook, Instagram, Twitter, Yahoo, and GitHub are all
> supported, and there's a plugin available for GitLab authentication as
> well, so we might be able to automatically authenticate existing GTK
> contributors with an account on gitlab.gnome.org.
>

It took one of ardour's (amazing) devs not much more than several hours of
work to use Discourse's SSO capabilities to integrate with Drupal
authentication, so even if the plugin doesn't work as you want, making
something that does will be simple for someone who understands this stuff.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving from mailing lists to Discourse

[Paul Davis]

Emmaneule,

at ardour.org, we recently switched from using Drupal forums to Discourse.
The results have been delightful. We managed to get single sign on
integration with our existing site working, which was important for us, but
probably not so much for a GTK Discourse. More notably, once you figure out
how to get the settings right, the integration with email was also a
pleasure. The move has definitely made our forums more active, easier to
manage, nicer to interact with and has also largely solved the spam
problems that we had before, even when we used Mollum. So ... although our
needs and goals were slightly different from yours, I can say that for us,
the move was very successful and we like Discourse very much.

--p


On Wed, Feb 6, 2019 at 4:46 AM Emmanuele Bassi via gtk-list <
gtk-l...@gnome.org> wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> Are there any objections? Did somebody already try out Discourse and has
> opinions about it that they want to share with the community?
>
> Ciao,
>  Emmanuele.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-list mailing list
> gtk-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Moving from mailing lists to Discourse

[Paul Davis]

Emmaneule,

at ardour.org, we recently switched from using Drupal forums to Discourse.
The results have been delightful. We managed to get single sign on
integration with our existing site working, which was important for us, but
probably not so much for a GTK Discourse. More notably, once you figure out
how to get the settings right, the integration with email was also a
pleasure. The move has definitely made our forums more active, easier to
manage, nicer to interact with and has also largely solved the spam
problems that we had before, even when we used Mollum. So ... although our
needs and goals were slightly different from yours, I can say that for us,
the move was very successful and we like Discourse very much.

--p


On Wed, Feb 6, 2019 at 4:46 AM Emmanuele Bassi via gtk-list <
gtk-l...@gnome.org> wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> Are there any objections? Did somebody already try out Discourse and has
> opinions about it that they want to share with the community?
>
> Ciao,
>  Emmanuele.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-list mailing list
> gtk-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Moving from mailing lists to Discourse

[Paul Davis]

Emmaneule,

at ardour.org, we recently switched from using Drupal forums to Discourse.
The results have been delightful. We managed to get single sign on
integration with our existing site working, which was important for us, but
probably not so much for a GTK Discourse. More notably, once you figure out
how to get the settings right, the integration with email was also a
pleasure. The move has definitely made our forums more active, easier to
manage, nicer to interact with and has also largely solved the spam
problems that we had before, even when we used Mollum. So ... although our
needs and goals were slightly different from yours, I can say that for us,
the move was very successful and we like Discourse very much.

--p


On Wed, Feb 6, 2019 at 4:46 AM Emmanuele Bassi via gtk-list <
gtk-list@gnome.org> wrote:

> [Cross-posted to various relevant mailing lists; please, reply to
> gtk-devel-list]
>
> As part of an attempt at making GTK more friendly to newcomers, I and
> other core developers were thinking of moving the mailing lists from the
> current mailman installation to Discourse:
>
>   https://discourse.org/
>
> Possibly still hosted on GNOME infrastructure, depending on the
> requirements for our sysadmins.
>
> The GTK project would have various sub-topics, mostly around development
> with and of GTK. Having a better archive search, a better moderation
> system, and a decent web UI are the major selling points for switching to
> Discourse. The fact that the project is also open source is neatly aligned
> with our values.
>
> Are there any objections? Did somebody already try out Discourse and has
> opinions about it that they want to share with the community?
>
> Ciao,
>  Emmanuele.
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to set style in a GTK+ 2 widget's realize function?

[Paul Davis]

I can't answer your question. But I can say that we never use gtk_style*.
Instead we just parse the RC file that includes "widget/style"
associations, and then we use gtk_widget_set_name() on our widgets to get
them to use the right style.

On Fri, Nov 16, 2018 at 5:32 AM Brent W. Baccala 
wrote:

> Hi -
>
> I've got a GTK+ 2 "external" widget (gtkdatabox from gtkdatabox.sf.net)
> that isn't displaying right after I've patched it to compile with
> GSEAL_ENABLED.
>
> The relevant code in the older version was:
>
> widget->style = gtk_style_attach (widget->style, widget->window);
>
>
> which we changed to:
>
> gtk_widget_set_style (widget, gtk_style_attach (gtk_widget_get_style
> (widget), window));
>
>
> ...and now the background color doesn't display right on an application
> (xoscope from xoscope.sf.net) that loads style from an "rc" file using
> gtk_rc_parse().
>
> I don't understand GTK+ internals well enough to understand why.  If I
> take this line of code out completely, the background displays correctly,
> but colored lines in other applications (the gtkdatabox examples) don't
> display.
>
> The solution I've got at the moment (other than convert the entire widget
> library and application to GTK+ 3) is to compile the widget without
> GSEAL_ENABLED and go back to the older code.
>
> Can somebody who knows GTK+ 2 well help me out?  Any idea what's causing
> this and how to fix it?
>
> Thanks.
>
> agape
> brent
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Display Raster Data?

[Paul Davis]

On Wed, Aug 1, 2018 at 9:44 AM, Luca Bacci via gtk-list 
wrote:

> I suggest you use GStreamer, you can build a video by pushing bitmap
> frames and it does everything else for you.
>
> Otherwise, you can animate a DrawingArea. Set up a 60hz timer on your own.
> The timer callback simply calls
> gtk_widget_queue_draw_area()
> .
> Then, on the draw_func of your drawingarea you display the bitmaps, one
> after another.
> That's the simplest solution but can have lower timing quality
>

in GTK3, this is almost certainly not the best way to do this. You want to
use a frame timer based on the refresh/vblank cycle of the monitor.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Display Raster Data?

[Paul Davis]

On Wed, Aug 1, 2018 at 12:18 AM, R0b0t1 via gtk-list 
wrote:

> Hello,
>
> I have bitmaps being generated by a process and need to display them
> at ~60Hz.


just a quick note: you don't get to control the refresh rate.

your screen update refresh rate is independent of GTK+. All modern GUI
toolkits are driven by the screen refresh rate (aka "vblank"). if your
screen refreshes at some other rate, there's nothing the GUI toolkit can do
to speed it up.

60Hz is a reasonable common refresh rate, but it's not universal, and you
probably should not rely on it being the context in which your program runs.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK+ 4 suggestions

[Paul Davis]

On Sun, Jul 22, 2018 at 11:58 PM, scott via gtk-list 
wrote:

>
>
> As an example, my application takes no inputs. You don't click on it. You
> look at it. Originally it wasn't a GUI at all; it was an invisible service.
> But letting it paint a screen with current status was deemed useful, so I
> bolted a GUI on the side.
> *Where, in this case, it belongs.*
>

​all you need to do is to take those sockets, turn them into sources that
are handled inside the GUI event loop, and there's no threading anymore

now, should the communication taking place over the sockets have some time
constraints that the event-handling + drawing aspects of the GUI event loop
interfere with, then sure, you need threads.

but look ... in the Unix/X Window world, the fundamental design of GUI code
has always been single threaded in the sense that if you want to use
multiple threads to draw, you need to explicitly take locks to make it
work. in the MS world, the opposite it true: there are implicit locks
around everything, and you can use threads without thinking about it too
much.

my reading is that one of these models is right, and one of them is wrong.
if you want to tie drawing into the underyling hardware refresh cycle, then
you're faced with the ultimate reality that drawing is single threaded
(there's a single current screen state that gets delivered to the video
hardware on each refresh cycle, by a single thread). if you want multiple
threads to possibly affect what's in that screen state, then you either
have to composite multiple thread outputs when handling the refresh or you
have to use locks. The first one is basically insane. The second one leaves
open the question of whether the locks are explicit or implicit (buried in
the API implementation).

Most Unix-y programmers tend to prefer that things with costs are left
explicit. MS cultivated a different culture, where (some) things were
eas(ier), but the costs were hidden.

The fundamental drawing model of GTK+ is really incompatible with
multi-thread drawing. It is supposed to occur in an expose event handler
ONLY, with no specification of when or why that expose event is generated
(could be a hardware refresh (vblank); could be a window geometry or
visibility change; could be other things. The idea that your
socket-listening thread can "just draw somewhere" is at odds with this,
unless you draw into an off-screen buffer of some sort. Problem is, you
still need locks to use these buffers during the expose handler, and you're
basically talking about compositing the result of each thread. Which is
nuts.
​


> i don't love GTK. but i think it's pretty good, and at least as good as
> the alternatives. i don't agree with any of your criticisms, and wouldn't
> want to seem them implemented. some of this is because i do not (and could
> not) use glade effectively.
>
>
> I think that's telling. If Glade isn't effective, that says something
> about GTK right there.
>

​i wasn't commenting on glade's effectiveness. our development model just
doesn't use RAD tools, because it's not really the right concept for how
our GUI operates. it's not Glade that we don't use - we wouldn't use any
similar tool on any platform.​

​finally, i don't believe that your observations about the origins of MVC
are even remotely correct, but that's a sideshow.​
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK+ 4 suggestions

[Paul Davis]

On Sun, Jul 22, 2018 at 1:26 PM, scott via gtk-list 
wrote:

> I'm new here, and here to cause some trouble. I just wrote my first GTK+3
> app - or rather, I adapted an existing C++ program to give it a GUI with
> GTK+3, and the distinction is important for reasons I'll make clear. It
> wasn't a fun experience, and I'll try to keep ranting to a minimum, but I'm
> here to ask people to seriously and thoughtfully consider that gtk+4
> embrace some new ideas.
>
> 1. Threads are here to stay
> A number of years ago I was doing something in python and tkinter, and got
> a crash out of tkinter. I dug a bit and realized I'd found a tkinter issue,
> and there wasn't a workaround. Since I was stuck - and annoyed - I wrote my
> own GUI toolkit, specific to Windows (but using openGL) and python. Frankly
> it looked like crap, but it had the feature of features I'd always dreamed
> of - thread safety. Complete thread safety, invisible to the coder. You
> could delete a widget from any thread at any time, including from the click
> callback of the widget itself, and it sorted everything out for you. No
> explicit locking, no hangs or crashes.
>
> I can't tell you how freeing this was or how much I've missed it since.
> Widgets are just resources and should be like any other resource. Think of
> files on linux. If one thread is writing to a file and another decides to
> delete the file, well, maybe you got what you wanted or maybe you didn't,
> but the operating system does not refuse your request, hang or crash. The
> file is your resource, and as such, you do what you want with it, from any
> thread at any time. The resource manager, in this case the OS, deals with
> it all, leaving you free to Just Code(tm).
>
> My C++ application is now riddled with gdk_threads_add_idle calls. It has
> to be. It has a lot of threads, each doing independent tasks with sockets
> and things, and sometimes they want to update a label with new text or new
> colors. And instead of calling GTK and saying "do this", I now have a bunch
> of functions that have to get injected into GTK, each returning false. Now
> the code is ugly. And I'm not going to redesign it around some central GTK
> world view; the fact that it paints a screen with status is not the main
> point of the application and GTK shouldn't demand a starring role.
>
> Abolish the concept of a main gtk thread. "Anything anywhere and real soon
> now" should be the motto.
>

​this is a terrible, terrible idea.

the benefits of a single-threaded GUI are huge. it makes reasoning about
stuff that happens in the View (and Controller) components of the
application vastly simpler.

​"It has a lot of threads, each doing independent tasks with sockets and
things, and sometimes they want to update a label with new text or new
colors"   this is just a sign of not using proper MVC design.  stuff
driven by the socket should change the model; the view should always update
in response to changes in the model. if you design things correctly, this
just happens.

Now, if you just want a wrapper around idle_add() functions, so that they
become "invisible to the coder", fine. We have code in Ardour that looks
like sigc++ signals, but are actually cross thread:

 some_signal.connect (boost::bind (::some_method,
an_object), , ui_thread()); // when "some_signal" happens, call
SomeObject::some_method in the GUI thread

this doesn't use idle_add() either (it uses a FIFO that is used as a source
for the main event loop). This sort of design is actually very nice, but I
don't regard it as the job of my GUI toolkit to offer this, because in fact
I need cross-thread callbacks between any of the dozens (or even hundreds)
of threads inside my application.


> 2. My pixels, not yours. Hands off.
> I know that Gtk has huge investment in flowing, springy, widget layout.
> Yay adaptability to new screen sizes. But sometimes, you know, I just want
> a widget to stay where I put it.
>
> Sure, if you're writing an app that has to adapt to a 2x3" phone's screen
> or a 20x8' foot, twenty billion pixel wall screen, having the GUI engine
> manage sizing is nice. And monitors keep getting bigger, so...
>
> Except wait. They don't anymore. These days, there's small screens,
> desktop screens, and massive wall displays, and applications rarely cross
> from one to the other. When they do, they're already coded to adapt,
> because layout is philosophically different for a phone and a huge screen,
> and different in ways that the GUI engine isn't likely to be smart about
> without help.
>
​sure, but much more common is "desktop, but with various different sized
monitors, and users who prefer different sized windows and window layouts".
that's where the box-packing paradigm ​wins. i don't really anyone
advocating GTK for phones, and never have.


> In other words there's a place in the world for the ability to
> Visual-Basic-Style-I-said-This-Big-And-Right-Here-and-no-backtalk-out-of-you
> nailing down of widgets, 

Re: Can't build pango-1.40.14 on Ubntu 16.04.4

[Paul Davis]

lib packages are installed so that programs can *use* the libraries. if
you want to build software that needs the libraries, you need to install
the lib-dev "version" of the packages.

CoreText is for macOS and does not concern you.

On Tue, Jun 5, 2018 at 2:50 PM, Gail Hardmann  wrote:

> I am trying to build pango-1.40.14. Running configure, I get:
>
> checking for HARFBUZZ... no
> checking for CoreText availability... no
> checking for CAIRO... no
> configure: error: *** Could not enable any backends.
> *** Must have at least one backend to build Pango
>
> libharfbuzz 1.0.1-1ubuntu0.1, libcairo2 1.14.6-1 are installed.
> Application manager can't find CoreText.
>
> My system: Ubuntu 16.04.4, Linux 4.4.19-xanmod24 #1 SMP Mon Aug 22
> 15:42:26 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
>
> How should I proceed?
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Giving GtkPane more than 2 children?

[Paul Davis]

Does your new pane correctly restore the divider positions? The existing
GtkPane fails to be able to restore the pane divider position precisely.
The reasons why are fairly obvious once you dive into the code. I wrote a
new (GTK+2) pane widget for Ardour, too.

On Thu, May 10, 2018 at 3:30 PM, Christian Hergert 
wrote:

> On 05/10/2018 11:46 AM, Ryan Gonzalez wrote:
> >
> > In the past, I've come upon the situation of wanting *more* than two
> > panes. When I look this up, I usually see people wiring together
> > multiple GtkPanes. Would the GTK+ devs be interested in a merge request
> > to add support for multiple panes?
> >
>
>
> https://gitlab.gnome.org/GNOME/gtk/issues/545
> https://gitlab.gnome.org/GNOME/libdazzle/blob/master/
> src/widgets/dzl-multi-paned.c
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is it possible to catch ALT+TAB and do nothing

[Paul Davis]

the window manager can intervene to catch more or less any key combinations
the user has told it to be interested in. if the user told it use Alt-Tab
for focus switching, it will catch that. you can't stop it.

On Mon, May 7, 2018 at 12:52 PM, Igor Korot <ikoro...@gmail.com> wrote:

> Hi, Paul,
>
> On Mon, May 7, 2018 at 11:42 AM, Paul Davis <p...@linuxaudiosystems.com>
> wrote:
> > If there is a window manager (and there just about always is), you can't
> > stop it from doing what it is configured to do. You're just an
> application,
> > and it takes higher priority managing window events than you.
>
> Yes, we are using FVWM as WM.
> I got a suggestion to write a function for this WM to stop the
> Terminal to appear
> when our Lock Screen is active, but here no one is familiar enough with
> this WM
> to write such a function.
>
> And I guess a different route is just not possible.
>
> And I would also guess that even if I put the "stay on top" flag,
> pressing the ALT+TAB will
> definitely switch the focus. Am I correct?
>
> Thank you.
>
> >
> > On Mon, May 7, 2018 at 12:01 PM, Igor Korot <ikoro...@gmail.com> wrote:
> >>
> >>  Hi, ALL,
> >> Is it possible to catch the ALT+TAB when one particular window is
> >> displayed and do nothing, i.e. not switch to a different window?
> >>
> >> We have a program which displays a full sized window without the
> >> title. Its role is to Lock screen" - user should not be able to do
> >> anything until (s)he supplies password and hit the "Authenticate"
> >> button.
> >> problem is that t is possible to hit "ALT+TAB" and switch the focus to
> >> the window below it (such as Terminal) and type something.
> >>
> >> We also can't use the lock screen window because of some other issues.
> >>
> >> So is it possible to catch ALT+TAB and do nothing for one specific
> window?
> >>
> >> On the side note - is there a better list (with more traffic) where I
> >> can post  question like this? Or this list is still good and
> >> operational?
> >>
> >> Thank you.
> >> ___
> >> gtk-list mailing list
> >> gtk-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gtk-list
> >
> >
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Is it possible to catch ALT+TAB and do nothing

[Paul Davis]

If there is a window manager (and there just about always is), you can't
stop it from doing what it is configured to do. You're just an application,
and it takes higher priority managing window events than you.

On Mon, May 7, 2018 at 12:01 PM, Igor Korot  wrote:

>  Hi, ALL,
> Is it possible to catch the ALT+TAB when one particular window is
> displayed and do nothing, i.e. not switch to a different window?
>
> We have a program which displays a full sized window without the
> title. Its role is to Lock screen" - user should not be able to do
> anything until (s)he supplies password and hit the "Authenticate"
> button.
> problem is that t is possible to hit "ALT+TAB" and switch the focus to
> the window below it (such as Terminal) and type something.
>
> We also can't use the lock screen window because of some other issues.
>
> So is it possible to catch ALT+TAB and do nothing for one specific window?
>
> On the side note - is there a better list (with more traffic) where I
> can post  question like this? Or this list is still good and
> operational?
>
> Thank you.
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Beginners guide

[Paul Davis]

On Fri, Apr 27, 2018 at 2:27 PM, Timothy Ward  wrote:

> Hi Emmanuele,
>
> I do agree with you but, From a beginners concept,The concept of
> Gtk-application and the handling of applications arguments is confusing
> coming from someone who is still learning from say - standard "C" as they
> are handled the same way in just about any example on a google search,
>
> When you combine this with the concept of main loop and instances that
> need to be created, controlled and destroyed then the complexity may be
> simple for an experienced programmer, but not to a beginner.
>

​GtkApplication is precisely where beginners should start. The fact that
introductory books on C programming don't mention event loops, is not a
justification for hiding the fact that GUI applications (fully translated:
applications that accept unbounded and unpredictable user input while
running) are conceptually and fundamentally different from data-driven
programming.

The sooner "beginners" are exposed to this concept, the better. And let's
be honest: it's no more complex than at least a half-dozen other conpcets
that the developer of a contemporary GUI application will need to face
along the way. Quite possibly one of the simplest, in fact.

The same thing applies to the GAction/GtkAction concept. Most GTK+
applications would be very much better designed internally and at the UI/UX
level if their developers started from this concept, but it is generally
deemed "too advanced". In reality, it provides the appropriate
simplifications and scaffolding to build applications that work in the way
that users expect in 2018 and beyond.​
​
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: First deprecate APIs and then remove them in the next major version

[Paul Davis]

On Sun, Dec 24, 2017 at 10:01 AM, Christian Schoenebeck <
schoeneb...@linuxsampler.org> wrote:

> On Samstag, 23. Dezember 2017 10:47:08 CET Paul Davis wrote:
> > ​actually, my impression from interactions with the author is that GTK
> > didn't make their life miserable at all.
> >
> > however, the issues that have been mentioned before regarding host/plugin
> > toolkit interactions did make their (and users') lives miserable, hence
> the
> > switch.​
>
> The trend among DAW apps is going towards process separation for plugins
> (one
> process for all instances of a plugin). No plans for that in Ardour yet?
>

​It doesn't scale. ​Certainly not to the session size that we're interested
in being able to deal with.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: g_object_ref() now propagates types

[Paul Davis]

On Fri, Dec 8, 2017 at 6:26 AM, Philip Withnall 
wrote:

> Hi all,
>
> We just landed a patch in GLib which propagates the type from the
> argument of g_object_ref() to its return type:
>
> https://git.gnome.org/browse/glib/commit/?id=3fae39a5d
> https://bugzilla.gnome.org/show_bug.cgi?id=790697
>
> The idea here is that it will catch invalid implicit casts which the
> compiler otherwise wouldn’t have noticed because g_object_ref()
> previously operated entirely on gpointers. This will eliminate a whole
> class of bugs: bugs which are unlikely to exist, but are a complete
> pain to track down if they do.
>

​Great work. Another 3 or 4 or 200 of these and we'll almost have a C++
compiler!

tongue firmly and warmly in cheek :))) ​
​
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: OSX and XQuartz support

[Paul Davis]

I think you're confused :)

Quartz is the native MacOS windowing system. X11 exists as a rootless X
Window environment for Quartz. There is (to my knowledge) no sign of
XWayland for Mac OS/Quartz.


On Mon, Nov 27, 2017 at 5:29 PM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> just wondering: wouldn't a quartz with XWayland on it be able to support
> that already?
>
> On Mon, Nov 27, 2017 at 7:02 PM, Andrew Wagner <
> apwag...@alumni.stanford.edu> wrote:
>
>>
>>
>> Begin forwarded message:
>>
>> *From: *Andrew Wagner <apwag...@alumni.stanford.edu>
>> *Subject: **Re: OSX and XQuartz support*
>> *Date: *November 27, 2017 at 4:22:45 PM EST
>> *To: *Paul Davis <p...@linuxaudiosystems.com>
>> *Cc: *Stephen Whiteley <ste...@wrcad.com>
>>
>> Hi Paul,
>>
>> The project isn’t meant to choose, just use the X11 backend. The reason
>> is that its written to be cross platform as much as possible so X11 and GtK
>> are the common framework. Its an open source project found here:
>> https://github.com/wrcad/xictools and any help you or anyone can offer
>> to streamline the GUI (or just the GUI library installation) would be very
>> welcome.
>>
>> Cheers,
>>
>> Andrew
>>
>>
>> On Nov 27, 2017, at 4:12 PM, Paul Davis <p...@linuxaudiosystems.com>
>> wrote:
>>
>> Why would your project choose to use the X11 backend? How would it choose?
>>
>> On Mon, Nov 27, 2017 at 2:48 PM, Andrew Wagner <
>> apwag...@alumni.stanford.edu> wrote:
>>
>>> Hi All,
>>>
>>> I’m new to gtk and am installing it on my Mac since its a dependency for
>>> other code I’m developing. I successfully followed the OSX install
>>> instructions:
>>>
>>> ./gtk-osx-build-setup.sh
>>> jhbuild bootstrap
>>> jhbuild build python meta-gtk-osx-bootstrap meta-gtk-osx-core
>>>
>>> but noticed afterword that the x11 include files in the source directory
>>> had not been installed in the inst/include directory. The project I’m
>>> working on uses gtk via x11 rather than the native osx quartz. I was
>>> wondering if there was a module like meta-gtk-osx-x11 or
>>> meta-gtk-osx-xquartz that would install these for me (I have Xquartz
>>> installed)? Is there a way in the mean time to do this by hand? I know that
>>> macports has this sorted out but I like to try to get code “from the horses
>>> mouth” rather than the various Mac porting platforms. Thanks very much for
>>> your help.
>>>
>>> Cheers,
>>>
>>> Andrew Wagner
>>>
>>>
>>> ___
>>> gtk-list mailing list
>>> gtk-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>>
>>
>>
>>
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: OSX and XQuartz support

[Paul Davis]

Why would your project choose to use the X11 backend? How would it choose?

On Mon, Nov 27, 2017 at 2:48 PM, Andrew Wagner  wrote:

> Hi All,
>
> I’m new to gtk and am installing it on my Mac since its a dependency for
> other code I’m developing. I successfully followed the OSX install
> instructions:
>
> ./gtk-osx-build-setup.sh
> jhbuild bootstrap
> jhbuild build python meta-gtk-osx-bootstrap meta-gtk-osx-core
>
> but noticed afterword that the x11 include files in the source directory
> had not been installed in the inst/include directory. The project I’m
> working on uses gtk via x11 rather than the native osx quartz. I was
> wondering if there was a module like meta-gtk-osx-x11 or
> meta-gtk-osx-xquartz that would install these for me (I have Xquartz
> installed)? Is there a way in the mean time to do this by hand? I know that
> macports has this sorted out but I like to try to get code “from the horses
> mouth” rather than the various Mac porting platforms. Thanks very much for
> your help.
>
> Cheers,
>
> Andrew Wagner
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Flickering with Socket and Plug

[Paul Davis]

Our opinion (ardour developers) is that no desktop GUI toolkit is
appropriate for plugins.

We were distressed to see Steinberg use gtkmm for this purpose (even though
we use gtkmm for ardour).

Plugins do not need to use the same toolkit as the host.

We have no plans to add VST3 support at any time in the near future, on any
platform.


On Thu, Sep 28, 2017 at 2:06 PM, René Hansen <r...@hansen-audio.de> wrote:

> Hey Paul,
>
> thanks for your remark. Since Steinberg released the technical preview of
> VST3 with Linux support, I try to port my synthesizer. The SDK contains a
> tiny host called EditorHost. It simply opens up the GUI editor of a
> plug-in. The host uses gtkmm (like my plug-in) and passes the socket_id
> resp. the window id to the plug-in.
>
> Until I switched to Ubuntu 17.04 everything was running smooth already.
> Unfortunately it started flickering.
>
> So, in case of Ardour the plug-in has to use gtkmm for building its GUI,
> right? Using another GUI framework is not possible.
>
> OT: Any plans of having VST3 in Ardour for Linux?
>
> René
>
> On 26.09.2017 20:13, Paul Davis wrote:
>
>> For whatever it's worth, I was working on a similar plugin situation 16
>> years ago.  I tried using plug+socket. Couldn't make it work. GTK+
>> developers at the time told me to stop using it.
>>
>> We now get a Gtk::Widget* from a plugin and add that to our own
>> Gtk::Window.
>>
>> On Tue, Sep 26, 2017 at 1:54 PM, René Hansen <r...@hansen-audio.de
>> <mailto:r...@hansen-audio.de>> wrote:
>>
>> Hey Eric,
>>
>> It looks like you are trying to paint a surface 100 times every
>> 16ms.
>> Maybe not such a good thing to do.
>>
>>
>> Yes, I agree but that's on purpose in order to make the problem
>> *very* obvious ;) In one of my projects I draw round about 25
>> bitmaps (which partly overlap) onto the drawingarea. While some
>> mouse interaction takes place I need to redraw several times. This
>> results in flickering of all single bitmaps almost everytime I
>> redraw. It looks as if the drawingarea gets cleared before I finish
>> drawing my bitmaps.
>>
>> > The plug and socket are separate programs. You would start your
>> socket
>> > and add one or more plugs to it. Each plug is running as it's own
>> > process.
>>
>> Yes, that's correct. But in the documentation of Gtk::Socket::add_id
>> it says:
>> "Adds an XEMBED client, such as a Gtk::Plug, to the Gtk::Socket.
>> The client may be in the same process or in a different process."
>>
>> So I am of the assumption that both is possible. Either Socket and
>> Plug live in the same process or different processes. Is that correct?
>>
>> Some details about my real world project (I hope it is not too
>> confusing). I have a host application (executable) which builds its
>> GUI with Gtk. Then I have a plug-in (shared object resp. .so file)
>> which also builds its GUI with Gtk. But the plug-ins GUI must be
>> shown by embedding it into the host application (like x11 is capable
>> of). So I pass the socket_id of the host to the plug-in so it can
>> connect by creating a plug. The plug-in lives inside the host
>> application's process. But it is also possible that the host creates
>> an extra process to let the plug-in run, but still, the GUI must be
>> shown inside the host application. Both scenarios are possible.
>>
>> > There is some socket and plug test code at the following.
>> ...
>> > I just added a frame clock to the plug. If you are looking to
>> animate a drawing in a plug that might be of some help.
>>
>> Thanks! I will have closer look and try to figure out how this works.
>>
>> > If you are programming in C++, the gtkmm tutorial is very good.
>>
>> Yes, I know this one, built it and let it run successfully. No
>> flickering. Afterwards I extended this example by having both socket
>> and plug in the same process. I added some idle call to the plug and
>> let it draw a bunch of bitmaps. It started flickering. Then I
>> removed all the gtkmm stuff in order to have plain Gtk code. And
>> this is the example I have put on my github ;)
>>
>> Thanks for help. I will study your "plug2.c" example and see what I
>> will come up with.
>>
>>
>> René
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org <mailto:gtk-list@gnome.org>
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>> <https://mail.gnome.org/mailman/listinfo/gtk-list>
>>
>>
>>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Flickering with Socket and Plug

[Paul Davis]

For whatever it's worth, I was working on a similar plugin situation 16
years ago.  I tried using plug+socket. Couldn't make it work. GTK+
developers at the time told me to stop using it.

We now get a Gtk::Widget* from a plugin and add that to our own Gtk::Window.

On Tue, Sep 26, 2017 at 1:54 PM, René Hansen  wrote:

> Hey Eric,
>
> It looks like you are trying to paint a surface 100 times every 16ms.
>> Maybe not such a good thing to do.
>>
>
> Yes, I agree but that's on purpose in order to make the problem *very*
> obvious ;) In one of my projects I draw round about 25 bitmaps (which
> partly overlap) onto the drawingarea. While some mouse interaction takes
> place I need to redraw several times. This results in flickering of all
> single bitmaps almost everytime I redraw. It looks as if the drawingarea
> gets cleared before I finish drawing my bitmaps.
>
> > The plug and socket are separate programs. You would start your socket
> > and add one or more plugs to it. Each plug is running as it's own
> > process.
>
> Yes, that's correct. But in the documentation of Gtk::Socket::add_id it
> says:
> "Adds an XEMBED client, such as a Gtk::Plug, to the Gtk::Socket.
> The client may be in the same process or in a different process."
>
> So I am of the assumption that both is possible. Either Socket and Plug
> live in the same process or different processes. Is that correct?
>
> Some details about my real world project (I hope it is not too confusing).
> I have a host application (executable) which builds its GUI with Gtk. Then
> I have a plug-in (shared object resp. .so file) which also builds its GUI
> with Gtk. But the plug-ins GUI must be shown by embedding it into the host
> application (like x11 is capable of). So I pass the socket_id of the host
> to the plug-in so it can connect by creating a plug. The plug-in lives
> inside the host application's process. But it is also possible that the
> host creates an extra process to let the plug-in run, but still, the GUI
> must be shown inside the host application. Both scenarios are possible.
>
> > There is some socket and plug test code at the following.
> ...
> > I just added a frame clock to the plug. If you are looking to animate a
> drawing in a plug that might be of some help.
>
> Thanks! I will have closer look and try to figure out how this works.
>
> > If you are programming in C++, the gtkmm tutorial is very good.
>
> Yes, I know this one, built it and let it run successfully. No flickering.
> Afterwards I extended this example by having both socket and plug in the
> same process. I added some idle call to the plug and let it draw a bunch of
> bitmaps. It started flickering. Then I removed all the gtkmm stuff in order
> to have plain Gtk code. And this is the example I have put on my github ;)
>
> Thanks for help. I will study your "plug2.c" example and see what I will
> come up with.
>
>
> René
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Past and future evolution of Gtk+ (was: How to get a "traditional" file-chooser)

[Paul Davis]

1) this is the wrong mailing list
2) it has been made clear many, many, many times that, largely as a result
of the developers of GTK+ largely being associated with the GNOME project,
the development priorities reflect what GNOME needs/wants.
3) no other community of interest has stepped up to make GTK+ more oriented
toward people and projects with different development priorities.
4) GTK+ was not "taken over" by GNOME developers, it is just that nobody
else stepped up do any of what was clearly necessary

Arguably, there is no other such community of interest. As an example ...
I've been using GTK+ for more than 20 years. For 18 years, the Ardour
project has used GTK+ (2). Our main conclusion after all this time is that
we actually never really had any interest or need for a GUI toolkit
centered on "desktop" applications (aka "productivity tools"), and that we
ended up with GTK+ mostly as a result of my naievete about GUI programming
(not that GTK+ was a bad choice, it just wasn't really what we needed then
or need now). We have little interest in tracking the ongoing development
of GTK+, not because we think that the developers are doing a bad job or
are working on the wrong things, but because this sort of toolkit just
isn't remotely what we want.

I suspect that we are not alone. In the general "creative" application
area, most developers (both proprietary and open source) have tended to
move towards much less structured toolkits, often based on GL for portable
drawing. I suspect that there are quite a lot of developers who made the
same "mistake" that I did back in the late 1990s regarding the type of
functionality I really needed (the mistake was mostly to be beguiled by
widgets, and to ignore the poor fit of MVC programming into the general
design).

As you note, the "GNOME"-centric ness of GTK+ has come up over and over
again for the last 10 years or so, and in that time, nobody has stepped up
to do anything close to what you suggest. While I've been using GTK+, whole
new toolkits such as JUCE have emerged, and even older ones like FLTK have
continued to do their job as well as ever.



On Sun, Sep 17, 2017 at 6:43 AM, Nicolas George  wrote:

> Le nonidi 29 fructidor, an CCXXV, Daniel Kasak a écrit :
> > Come on. It's troll bait.
>
> I am very sure you will consider this mail troll bait too, but I assure
> you it is not, and an honest reading of its contents, with the
> definition of troll in mind, will show that it is not.
>
> This thread shows a trend that is very typical of the evolution of Gtk+.
>
> In the beginning of the 2000's, Gtk+ was arguably the best toolkit
> available: Libre, of course, best Unicode support, best ergonomics, best
> set of supported languages, best API, etc. In the more recent years, on
> the other hand, we have seen a growing dissatisfaction from a certain
> category of users, about both the ergonomics and the API design.
>
> A friend of mine, historian, likes to say "a false idea is a true fact":
> "people are dissatisfied" is a fact, even if one disagrees with their
> reasons for being dissatisfied.
>
> Some of the complaints are just silly or otherwise unfounded, there is
> little doubt about that. But on the other hand, some of them are founded
> and valid. Amongst them, some are a matter of taste, priorities and use
> style while some may be universally valid points. Somebody who aims to
> enhance Gtk+ needs to heed the valid complaints. And in order to know
> which one is what, all complaints need to be read with an open mind.
>
> Therefore, requesting features or expressing critics in a constructive
> way is good for Gtk+ and perfectly acceptable on its mailing-lists, it
> is not a troll. It becomes "troll bait" because some people do not read
> them with an open mind and reply in non-constructive ways, sometimes
> bordering on insulting. Of course, when polite requests are met with
> impolite replies, the ambiance eventually deteriorates on both sides,
> and the critics become less polite. All sides should make conscious
> efforts to avoid it.
>
> As I said, some critics are a matter of taste and use style. I think
> they should still be heeded: a toolkit like Gtk+ should strive to cater
> for all users and all use styles; it is possible to make a GUI more
> usable for certain users without making it less usable for others.
> Furthermore, general principles about usability often have to give way
> to other considerations. For example, if somebody is forced to work a
> lot with applications developed with a mediocre toolkit, they will want
> their few Gtk+ applications to behave as much as possible the same way:
> even if it is not the "best" way, it is still more convenient for them,
> and Gtk+ should propose it as an option.
>
> Of course, implementing options and alternate behaviours costs time and
> efforts, and testing the various combinations even more so. The work of
> the Gtk+ team is given to the community gratis, nobody has any right 

Re: How to get a "traditional" file-chooser

[Paul Davis]

Now that was surely helpful.

On Thu, Sep 14, 2017 at 6:48 PM, Daniel Kasak 
wrote:

> Of course there is. Use GTK2 or QT apps. I suggest Redhat 5. That shit
> is old school.
>
> On Fri, Sep 15, 2017 at 4:22 AM, Clemens Eisserer 
> wrote:
> > Hi,
> >
> > Until recently I tried to avoid GTK3 applications, because the GTK3's
> > file chooser is driving me crazy.
> > However, as more and more applications of my desktop environment are
> > ported to GTK3, I wonder ... is there any way, to get a more
> > traditional file chooser for GTK3 applications which resembles what
> > GTK2 or QT offer?
> >
> > Thank you in advance, Clemens
> > ___
> > gtk-list mailing list
> > gtk-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-list
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Wait cursor animation does not work properly

[Paul Davis]

On Mon, Sep 4, 2017 at 3:17 AM, Stefan Salewski  wrote:

> ​My chess engine takes only a few seconds to calculate
> the next move, so creating an own thread is some overkill.


​Incorrect thinking. ​


> What I need:
> User has done his move, so update display, indicate that computer is
> "thinking" for a few seconds, and then update display again. I think
> that should be possible with g_idle_add(). Instead of the busy pointer
> I may set a message to the window title.
>
> Later I may consider indeed using a separate thread


​Do it now.

Chris explained the rest.
​
​
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Setting pango attributes

[Paul Davis]

On Fri, Sep 1, 2017 at 7:50 PM, Igor Korot  wrote:

> Emmanuelle,
>
> On Fri, Sep 1, 2017 at 6:37 PM, Emmanuele Bassi  wrote:
> > On 1 September 2017 at 21:20, Igor Korot  wrote:
> >>  Hi, ALL,.
> >> There is a GtkFontChooserDialog class which enable a user to do a font
> >> selection.
> >>
> >> However, this dialog does not allow to select some pango attributes -
> notably
> >> strikethrough and underline.
> >>
> >> Is there a way to have some kind of a GUI controls to select them?
> >> If not - why they are not present in the dialog itself?
> >
> > Because that's not what a font selection dialog does?
>
> So I should just add 2 checkboxes to my panel to make them selectable?
>

As Emmanuelle noted, ​they are not related to font selection. ​ You have to
decide if you consider all this stuff related or not.



> >
> > The bold and italic font faces you see are different font weights
> > inside a family, not Pango attributes being set.
>
> I was actually asking about underline/strikethrough not bold/italic.
>

​so was Emmanuelle. Again: strikethrough & underline are Pango rendering
attributes, not part of font (unlike bold/italic, which are part of a font)


​
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Interactive search on GtkTreeView not working

[Paul Davis]

In theory, it shouldn't be ctrl-f on OS X. Ctrl is defined as the PRIMARY
modifier for X Window and Windows, but that role is played by Command on
MacOS/OSX.

On the other hand, you already reported that Ctrl-f does work to bring up
the search bar, so something is borked.

On Fri, Sep 1, 2017 at 2:46 PM, Eric Cashon via gtk-list  wrote:

>
> Hi Sofi,
>
> I don't have OS X to test on but have been working on a few tree views
> recently. If I give it a quick test on Ubuntu, Ctrl+f and search works well
> in the following test code. Does this work on OS X or does it give you the
> same problem?
>
> Eric
>
>
> /*
> With Ubuntu16.04, GTK3.18 and GTK3.22.
> gcc -Wall tree_search1.c -o tree_search1 `pkg-config --cflags --libs
> gtk+-3.0`
> */
> #include
>
> static GtkTreeStore* get_tree_store();
>
> int main(int argc, char *argv[])
>   {
> gtk_init(, );
>
> GtkWidget *window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
> gtk_window_set_title(GTK_WINDOW(window), "Tree View");
> gtk_window_set_position(GTK_WINDOW(window), GTK_WIN_POS_CENTER);
> gtk_window_set_default_size(GTK_WINDOW(window), 300, 300);
> g_signal_connect(window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
>
> GtkTreeStore *store=get_tree_store();
>
> GtkWidget *tree=gtk_tree_view_new_with_model(GTK_TREE_MODEL(store));
> gtk_tree_view_set_enable_search(GTK_TREE_VIEW(tree), TRUE);
> g_object_unref(G_OBJECT(store));
>
> GtkCellRenderer *renderer1=gtk_cell_renderer_text_new();
> g_object_set(renderer1, "editable", TRUE, NULL);
>
> GtkTreeViewColumn *column1 = 
> gtk_tree_view_column_new_with_attributes("Shape
> Coordinates", renderer1, "text", 0, NULL);
> gtk_tree_view_append_column(GTK_TREE_VIEW(tree), column1);
>
> GtkWidget *scroll=gtk_scrolled_window_new(NULL, NULL);
> gtk_widget_set_vexpand(scroll, TRUE);
> gtk_widget_set_hexpand(scroll, TRUE);
> gtk_container_add(GTK_CONTAINER(scroll), tree);
>
> GtkWidget *grid=gtk_grid_new();
> gtk_container_set_border_width(GTK_CONTAINER(grid), 20);
> gtk_grid_attach(GTK_GRID(grid), scroll, 0, 0, 1, 1);
> gtk_container_add(GTK_CONTAINER(window), grid);
>
> gtk_widget_show_all(window);
> gtk_main();
> return 0;
>   }
> static GtkTreeStore* get_tree_store()
>   {
> gint i=0;
> gint j=0;
> GtkTreeStore *store=gtk_tree_store_new(1, G_TYPE_STRING);
>
> GtkTreeIter iter1;
> GtkTreeIter iter2;
> gtk_tree_store_append(store, , NULL);
> for(i=0;i<3;i++)
>   {
> gchar *string1=g_strdup_printf("S%i", i);
> gtk_tree_store_set(store, , 0, string1, -1);
> g_free(string1);
> for(j=0;j<5;j++)
>   {
> gtk_tree_store_append(store, , );
> gchar *string2=g_strdup_printf("C%i", j);
> gtk_tree_store_set(store, , 0, string2, -1);
> g_free(string2);
>   }
> gtk_tree_store_append(store, , NULL);
>   }
>
> return store;
>   }
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: g_io_channel_win32_poll() Problem on Windows

[Paul Davis]

On Fri, Jul 28, 2017 at 4:37 AM, LRN  wrote:

>
>
> After trying this myself (for unrelated reasons), i found that *only*
> giochannel GSource does WSAEventSelect() on a socket event (in
> g_io_win32_prepare()) to bind it to an event handle, which can then be
> polled.
> If you are not using a main loop (and GSource), then this doesn't happen,
> and
> the events you feed to g_poll() are completely inert.
>

This is true on all platforms. The "responsiveness" of all GSources depends
on a main loop that
polls/selects/does-some-platform-equivalent-of-wait-for-something.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_container_remove may generate some noise for a GC

[Paul Davis]

On Sun, Jun 25, 2017 at 1:56 PM, Stefan Salewski  wrote:

>
> action. And GTK is single threaded? Is that already preparation for a
> multi-threaded GTK4?
>

like most GUI toolkits that had deep origins in the X Window world, GTK is
single threaded. there is support for multiple threads if the application
developer wants to use them, and you can certainly have multiple glib event
loops running in multiple threads, but the core design of GTK itself is
single threaded.

it's just the right thing to do.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Block a signal for a hierarchy of widget

[Paul Davis]

let's take the example of a button. the button may serve one or both of two
purposes:

1) to provide a target for the user to operate on in order to change
the state of some part of the "model" within the program (e.g. the state of
some variable) - for example, by clicking/pressing it
2) to indicate the current state of the "model" (e.g. a variable)

if the button serves both purposes, then its visual state should change
whenever the model changes. other aspects of the program should care about
the state of the model, not the button's state.

GTK makes this tricky because it tends to encourage you to use the button
state as the model state (i.e. when checking if the user has "set X to
true", you tend to check whether the button is pressed or not, rather than
whether some independent value is true or not).

so there are now two possible designs:

   a) the state of the button IS the "model" state
   b) the button is merely a view and a controller for the "model" state
(i.e. a variable somewhere)

if (a) is true, then changing the state of the button, whether done by the
user or programatically because of some internal logic, results in a change
in the model state. anything interested in the model state will have
connected to the button signals, and will want to know about this change.
blocking the signal implies that you are trying to hide a change in the
state of the model from other objects/methods who have stated their
interest in knowing when it changes - this can hardly be a good thing.

if (b) is true, then things interested in the model state will ignore the
button state itself, and focus on notifications about changes in the model
state (e.g. some other variable)

On Thu, Apr 20, 2017 at 7:21 AM, Emmanuel Pacaud <emman...@gnome.org> wrote:

> Hi Paul,
>
> Le mer. 19 avril 2017 à 20:57, Paul Davis <p...@linuxaudiosystems.com> a
> écrit :
>
>> This normally means that you're not using appropriate
>> model-view-controller design.
>>
>
> Could you elaborate a bit ? I fail to see where the design of my
> application could solve this issue I have with the use of Gtk.
>
> Cheers,
>
> Emmanuel.
>
>
>> On Wed, Apr 19, 2017 at 2:19 PM, Emmanuel Pacaud <emman...@gnome.org>
>> wrote:
>>
>>> Hi,
>>>
>>> Is there a way to unblock/block the emission of signals for a hierarchy
>>> of widgets ?
>>>
>>> The reason I'm asking is because of this sort of code I'm using:
>>>
>>> https://github.com/AravisProject/aravis/blob/master/viewer/
>>> arvviewer.c#L588
>>>
>>> It is not very convenient and error prone to register every connected
>>> signals and block/unblock them when one want to update some widgets
>>> programmatically.
>>>
>>> Cheers,
>>>
>>> Emmanuel.
>>>
>>> ___
>>> gtk-list mailing list
>>> gtk-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>>
>>
>>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Block a signal for a hierarchy of widget

[Paul Davis]

This normally means that you're not using appropriate model-view-controller
design.

On Wed, Apr 19, 2017 at 2:19 PM, Emmanuel Pacaud  wrote:

> Hi,
>
> Is there a way to unblock/block the emission of signals for a hierarchy of
> widgets ?
>
> The reason I'm asking is because of this sort of code I'm using:
>
> https://github.com/AravisProject/aravis/blob/master/viewer/
> arvviewer.c#L588
>
> It is not very convenient and error prone to register every connected
> signals and block/unblock them when one want to update some widgets
> programmatically.
>
> Cheers,
>
> Emmanuel.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Masked text control

[Paul Davis]

No. You need to do the filtering yourself.

On Mon, Apr 10, 2017 at 3:09 PM, Igor Korot  wrote:

>  Hi,
> Is there something like
> https://msdn.microsoft.com/en-us/library/windows/desktop/
> aa369797(v=vs.85).aspx
> in GTK+?
>
> Thank you.
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK Queue Draw Subtle Question

[Paul Davis]

You can call g_idle_add() and various related functions from a non-GTK
thread. This is easier and more reliable than using a timer. When your
other thread has finished some work, add an idle callback in the main
context. the idle callback should call gtk_queue_redraw() for the
appropriate window/widgets.

On Sat, Feb 18, 2017 at 12:47 AM, Eric Cashon via gtk-list <
gtk-list@gnome.org> wrote:

> Thomas,
>
> You could implement a worker thread that you can monitor it's progress.
> Once it is done, you can update your display. There are some things to keep
> in mind when doing this though. You don't want to call GTK functions from
> your worker thread. If you are drawing your results to a cairo surface, you
> can draw with your worker thread and when it is all done, update the
> surface in your drawing area widget. If you need to keep other data you can
> use glib. Having a worker thread will keep your application responsive.
>
> Some of these concepts are useful for drawing a Mandelbrot fractal so I
> put a little demo together if you are interested. It uses a timer to check
> when the drawing is done. When it is, it updates the drawing area. It is in
> GTK3 but the concepts should be the same for GTK2. Would have to make a few
> code changes though for GTK2.
>
> https://github.com/cecashon/OrderedSetVelociRaptor/blob/
> master/Misc/cairo_drawings/mandelbrot1.c
>
> Anyways, hope it is of some help.
>
> Eric
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK Queue Draw Subtle Question

[Paul Davis]

Sad to say, it seems that you're in a common position of not understanding
the basic structure of a GUI program. In its simplest form, it looks like
this:

main ()
{
   initialize_stuff();

   while (not_time_to_quit()) {

wait_for_events_and_timeouts ();
process_events_and_timeouts ();

if (redraws_requested) {
  do_redraw ();
}
   }

   finalize_stuff ();
}

your menu handlers execute as part of "process_events_and_timeouts ()". You
can see that if they take a long time, you are necessarily preventing the
program from reaching the "do_redraw()" stage.

you need to refactor your code so that either your menu handlers do not
take so long or you execute them in a different thread, and then use an
idle handler to queue a redraw in any relevant widgets when they are done
(queuing an idle handler is the one and only GTK-related thing you can do
from the other thread(s)).



On Wed, Feb 15, 2017 at 11:30 PM, Thomas Dineen 
wrote:

> Gentle People:
>
>I have a rather large project in progress based on the GTK2/Cairo
> packages.
> Which brings me to the following question about gtk_widget_queue_draw:
> For each Menu Function, meaning a C function, which is called by a menu
> event handle,
> in response to a Menu Selection. I place a gtk_widget_queue_draw at the
> end of the function
> to cause the screen to update in response to the command. Learned behavior
> from examples
> and experience. This seems to work great.
>
> Now the question: If the menu function is complex, requiring seconds or
> minutes to execute
> the screen freezes or if windows are moved fails to update and we are left
> with a default
> grey screen. Is there any way to cause a queue draw and screen up date
> from within this
> long latency function.
>
> My experience indicates that calling gtk_widget_queue_draw from within
> this long latency
> function dose not cause a screen update.
>
> Thomas Dineen
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Gtk3 portability

[Paul Davis]

GTK cannot be statically linked. Or if it can (I may have failed to keep up
with changes in GTK3) it requires special compile-time configuration
options.

On Sat, Feb 11, 2017 at 7:22 PM, Ian Chapman  wrote:

> Gtk3 portability
>
> Hi, I have made a Linux gtk3 program and have it running on my Debian Mint
> AMD64 machine.
>
> I mistakenly thought that the program file (binary file) held all that was
> needed to run.
>
> I moved the program file to a newly installed Mint 18.1 and ran into a few
> difficulties.
>
> 1. I had to install libsdl2 to get over the first hick.
>
> 2. My program was looking for libglew.so.1.10 but what was in the
> repository was 1.13 obviously a slightly later version.
>
> 3. I overcame hick 2 by pulling over C++ and gtk3 and recompiling from
> source.
>
> Maybe you guys and gals can give me a few pointers so that I can generate
> the program file (binary file) without all the above hassle? Regards Ian.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: using gdk_win32_window_foreign_new_for_display

[Paul Davis]

I STRONGLY, STRONGLY recommend that you do NOT use GTK or any other desktop
GUI toolkit for an audio plugin UI.

It is extremely problematic. Doing so on Windows is likely to cause even
more problems than it does on Linux.

Please don't do it.

Mea culpa: I don't have a clearly better suggestion for you.

On Thu, Jan 12, 2017 at 3:20 PM, Tilman K.  wrote:

> Hey guys,
>
> I would like to develop the GUI for a VST synth with gtk. I need to embed
> a gtk gui inside a win32 HWND parent window. I think
> "gdk_win32_window_foreign_new_for_display" could be the right function to
> create a GdkWindow that is embedded inside the native window. is this
> correct?
>
> I tried to create a GUI thread this way:
>
> std::thread guiThread([=]{
> auto app = Gtk::Application::create("test");
> auto settings = Gtk::Settings::get_default();
> settings->set_property("gtk-font-name","Sans 10");
>
> Gtk::Window window;
> window.set_default_size(400,400);
> auto disp = Gdk::Display::get_default();
> auto gdkWindow = Glib::wrap(gdk_win32_window_fo
> reign_new_for_display(disp->gobj(),(HWND)systemWindow));
> window.set_parent_window(gdkWindow);
>
> initApp(); //creating widgets
> window.show_all();
> app->run(window);
> });
> guiThread.detach();
>
> "systemWindow" is a HWND given by the VST host (in my case FLStudio).
> Unfortunately, the window remains black, no gui drawn. I would be greatful
> for suggestions
>
> Greetings
>
> Tilman
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: CSS to look more like Gtk+ 2

[Paul Davis]

On Tue, Dec 13, 2016 at 2:48 AM, Kyle Terrien  wrote:

>
> Adwaita is written in a CSS preprocessor (SCSS).
> https://git.gnome.org/browse/gtk+/tree/gtk/theme/Adwaita
>
> It is a very complicated bit of work.  In my opinion, if you need a
> preprocessor for something like CSS, your CSS is probably too
> complicated, and you are doing something wrong.
>

My understanding is that many web CSS "kits" are all developed and managed
in this way too, because in reality there are many common elements and
designs that are not trivially expressible in CSS itself.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Disabling "alt-*" menu functionality

[Paul Davis]

Mnemonics are created, AFAIK, in the code when the menu items are
constructed. There are various ways this can be done, but I suspect it
cannot be undone if you all you have is a ready to run application.

In GTK2, the simplest way to do this was to put an underscore in front of
the desired letter that would act the mnemonic (e.g. "_File" when defining
a "File" menu item). There are other ways too, and GTK3 may have changed
quite a bit here.

On Thu, Dec 8, 2016 at 11:42 PM, John Parejko <parej...@gmail.com> wrote:

> I didn't write the app. I want to be able to disable the mnemonics
> globally, and there doesn't appear to be a way to do that in gtk-3.
>
> John
>
> On 12/08/2016 03:38 PM, Paul Davis wrote:
>
>> Don't create mnemonics when creating menu items. That's all. Our app
>> (Ardour) is GTK (2) but we never define any menu mnemonics, and
>> consequently there are no Alt-* bindings created by GTK (we need all
>> available bindings for the app's own control and management.
>>
>> On Thu, Dec 8, 2016 at 11:23 PM, John Parejko <parej...@gmail.com
>> <mailto:parej...@gmail.com>> wrote:
>>
>> Is there any way to prevent gtk from taking over "alt-*" handling
>> (e.g. alt-f for _File menu, alt-e for _Edit menu) from the application? I
>> can see that some users use that, but others (like me) prefer to rebind alt
>> to other functionality (e.g. find in Firefox).
>>
>> Looking into this launchpad ticket [1], it appears that gtk is the
>> root cause here, which is why I'm bringing it up on this list.
>>
>> 1: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1113420 <
>> https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1113420>
>>
>> There are a handful of suggestions on that ticket, none of which seem
>> to apply to gtk-3. Is there another way to reconfigure gtk in this regard?
>> It seems to be a problem across a variety of window managers (I've seen it
>> in xfce4/xfwm, unity, and lxde/openbox).
>>
>> I didn't see any tickets filed about this in the gtk bug tracker, but
>> searching for "alt menu" resulted in a lot f hits...
>>
>> Thank you,
>> John
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org <mailto:gtk-list@gnome.org>
>> https://mail.gnome.org/mailman/listinfo/gtk-list <
>> https://mail.gnome.org/mailman/listinfo/gtk-list>
>>
>>
>>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Disabling "alt-*" menu functionality

[Paul Davis]

Don't create mnemonics when creating menu items. That's all. Our app
(Ardour) is GTK (2) but we never define any menu mnemonics, and
consequently there are no Alt-* bindings created by GTK (we need all
available bindings for the app's own control and management.

On Thu, Dec 8, 2016 at 11:23 PM, John Parejko  wrote:

> Is there any way to prevent gtk from taking over "alt-*" handling (e.g.
> alt-f for _File menu, alt-e for _Edit menu) from the application? I can see
> that some users use that, but others (like me) prefer to rebind alt to
> other functionality (e.g. find in Firefox).
>
> Looking into this launchpad ticket [1], it appears that gtk is the root
> cause here, which is why I'm bringing it up on this list.
>
> 1: https://bugs.launchpad.net/ubuntu/+source/nautilus/+bug/1113420
>
> There are a handful of suggestions on that ticket, none of which seem to
> apply to gtk-3. Is there another way to reconfigure gtk in this regard? It
> seems to be a problem across a variety of window managers (I've seen it in
> xfce4/xfwm, unity, and lxde/openbox).
>
> I didn't see any tickets filed about this in the gtk bug tracker, but
> searching for "alt menu" resulted in a lot f hits...
>
> Thank you,
> John
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Catch logging off in GTK application

[Paul Davis]

No, he's talking about handling notifications from a desktop environment
that strongly suggest to the application that it should exit.

On Thu, Dec 1, 2016 at 5:47 AM, Göran Hasse  wrote:

>
> You should be talking of "quit" an application. And to notice when an
> application (a process)
> exits it is possible to know.
>
> I is always possible to make a service listen on a socket and take
> connections from
> afar without "logging in" to the operating system.
>
> /gh
>
> Den 2016-11-30 kl. 20:47, skrev Igor Korot:
> >  Hi, ALL,
> > What is the way to go to catch the logging off event in the GTK+ app?
> > For both GTK+2 and GTK+3.
> >
> > Thank you.
> > ___
> > gtk-list mailing list
> > gtk-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-list
> >
>
> --
> Göran Hasse
> Raditex Control AB
> Boo 229
> 715 91 ODENSBACKEN
> http://www.rscada.se
> OrgNr: 556611-8773
> email: gor...@raditex.nu
> tel: 019-450105
> mob: 070-5530148
> Lat:  59.18805083 Long: 15.50300449
> URL: http://alturl.com/3e6hf
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Catch logging off in GTK application

[Paul Davis]

Technically, that's not a GTK+ question.

GTK+ apps can run on desktops or platforms where there's no concept of
"logging in" or "logging off".

GNOME covers that and GTK+ does represent some of it, but it isn't
necessarily portable to other desktop environments.

On Wed, Nov 30, 2016 at 7:47 PM, Igor Korot  wrote:

>  Hi, ALL,
> What is the way to go to catch the logging off event in the GTK+ app?
> For both GTK+2 and GTK+3.
>
> Thank you.
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: What class with signals capabilities?

[Paul Davis]

You may to inherit from sigc::trackable if you want to be able to connect
to a signal and disconnect from it automatically in the destructor.

On Mon, Nov 28, 2016 at 11:55 PM, Chris Vine 
wrote:

> On Mon, 28 Nov 2016 23:16:15 +0100
> Krzysztof  wrote:
> > Hi,
> >
> > I'd like to make a class with signaling capabilities (receiving and
> > emitting signals) under gtkmm. What class is the best to derive from?
> > Gio::SimpleActionGroup or something else?
>
> Do you need derivation?  Can you just include a sigc::signal object as
> a class member?
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Effective size of drawing area

[Paul Davis]

use the size-allocate event for the widget, or check its size via
gtk_widget_get_allocation() and cousins.

On Thu, Nov 3, 2016 at 10:47 PM, Krzysztof  wrote:

> Assume that:
>
> window default size is 300x300
>
> window has box with menu bar and drawing area:
>
> box = new Gtk::Box(Gtk::ORIENTATION_VERTICAL);
> box->pack_start(menuBar, Gtk::PACK_SHRINK);
> box->pack_start(*darea, Gtk::PACK_EXPAND_WIDGET);
>
> What is and how to determine the size of area where I can actually do all
> drawing?
>
>
> --
> Regards
> Krzysztof J.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Gnome with high resolution display (4k, 27 inch)

[Paul Davis]

On Sat, Sep 24, 2016 at 10:34 PM, Michael Torrie  wrote:

>
> Hopefully someone can enlighten me as to why after years of hearing
> about the promise of vector graphics allowing arbitrary and beautiful
> scaling of our user interfaces, we are stuck with this HiDPI kludge and
> apps that still think in pixels. And is this likely to ever change?
>

at some point, something has to be rendered to pixels. that layer is part
of the GTK/GDK stack.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk/quartz default font woe, and gtk-font-name

[Paul Davis]

On Wed, Jun 22, 2016 at 2:03 PM, Hin-Tak Leung 
wrote:

>
> FWIW, I am trying to embed a gtk scrolledwindow inside a carbon
> application. The gtk scrolledwindow in turn, has another foreign Cocoa
> widget inside.
>

Alarm bells sound.

I thought that what we have to do with Ardour (embed Carbon windows inside
GTK/Quartz (Cocoa) windows) was bad enough. This is so much worse that I
would strongly recommend you to just stop. In Ardour's case, we ceased to
support Carbon for our 64 bit builds, because (a) Apple declared Carbon
dead more than 15 years ago (b) in recent OS X releases, it really is
nearing full death.


> (you can probably tell from that gtksharp_object_newv I am using gtksharp).
>

*plus* gtksharp?

You need to realize that you're using a combination of technologies that I
am almost certain makes you the ONLY person on the planet to be doing so?
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Parent receiving child's button press event

[Paul Davis]

the child should have its own handler, and that handler should return TRUE.
this wil stop propagation up the widget tree.

On Tue, Aug 30, 2016 at 8:02 PM, Jim Heald  wrote:

> Hello,
>
> I have a grid set up where some event boxes are attached. Each eventbox
> (which we'll call a column) contains a box with children (which we'll call
> tiles) that are also eventboxes.
>
> What I want is for right clicking a tile to produce one menu (Edit/Delete)
> whereas right clicking an empty space produces another (which would be
> Add). I set this up and connected the signals, but when I right click a
> tile it produces both the Add menu *and* the Edit/Delete menu.
>
> Therefore, my problem is that right clicking a tile *also* sends the
> button-press signal to the column.
>
> My question is what would be the best way to filter these events to ensure
> the parent isn't receiving its childrens' events? I.e. how can I either
> prevent the parent from receiving a signal from the child or possibly in
> the handler for a column make sure there's no tile at the coordinates of
> the click event?
>
> Thanks!
>
> Jim
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Whatever happened to the Secondary Selection?

[Paul Davis]

I think you should forget about the X Window definition of
PRIMARY/SECONDARY, since this isn't really about that.

It is about issues with the normal  selection model, that just *happen* to
be addressed by some of the concepts in X's idea of SECONDARY selection,
specifically what happens to the insertion point/cursor when making
conventional selections. The suggestions really have nothing to do with the
specifics of X's definition, but really distill down to two key differences
with this "new" selection process:

1) selection itself does not move the insertion point/cursor
2) paste occurs immediately at the end of an uncancelled selection
process

I agree with you that portability issues make it hard to consider adopting
this sort of model. I didn't find the video terribly compelling - I can see
the issues raised with the way conventional selection works, but they don't
seem substantive enough to justify introducing an entirely new (for almost
all users) model.


On Sun, Aug 21, 2016 at 7:19 AM, Emmanuele Bassi <eba...@gmail.com> wrote:

> Hi;
>
> I read the textual description, mostly because after 20 years of using
> X11 I've never even seen an implementation of the SECONDARY selection
> protocol outside of Motif applications. GTK+ itself does not implement
> anything with the 'SECONDARY' atom, unlike the 'PRIMARY' one —
> unfortunately, if I may add.
>
> The GTK+ team is pretty much following the behaviour set out by the
> freedesktop.org clipboard specification:
>
>   https://specifications.freedesktop.org/clipboards-
> spec/clipboards-latest.txt
>
> which was written down in 2000-ish and has been the de facto standard
> for the free software desktop since then.
>
> Again: I think it's perfectly fine to let applications take care of
> this, especially on X11. The whole PRIMARY/SECONDARY shenanigans are
> pretty much the definition of unportable X11 behaviour anyway — i.e.
> the Windows and macOS backends do not have any support for
> PRIMARY/SECONDARY selections, even if they are part of the available
> atoms in GDK, and Wayland had to get an additional protocol extension
> to implement PRIMARY behaviour — again, unfortunately.
>
> Ciao,
>  Emmanuele.
>
>
> On 21 August 2016 at 12:07, Paul Davis <p...@linuxaudiosystems.com> wrote:
> > Emmanuele,
> >
> > did you watch his video?
> >
> > On Sun, Aug 21, 2016 at 3:07 AM, Emmanuele Bassi <eba...@gmail.com>
> wrote:
> >>
> >> Hi;
> >>
> >> thanks for your email.
> >>
> >> GTK+, as a project, tracks bugs and enhancements in Bugzilla -
> >> https://Bugzilla.gnome.org/enter_bug.cgi?product=gtk%2b - instead of
> the
> >> mailing list, which is only meant for discussion.
> >>
> >> Additionally, the latest stable version of GTK+ is 3.20, and we plan to
> >> release GTK+ 3.22 by next month.
> >>
> >> We still (optionally) support the PRIMARY selection on the X11 backend,
> >> and some compatibility layer for it on Wayland, but we have no plans on
> >> adding support for the SECONDARY selection, as it's both barely
> specified
> >> and, like the PRIMARY, highly confusing for anybody who is not
> well-versed
> >> in 20+ years of use of textual interfaces on the X Windows System.
> >> Personally, I would have jettisoned the PRIMARY selection a long time
> ago as
> >> well, but apparently a very vocal minority is still holding tight to
> that
> >> particular Easter egg. Adding support for the even more esoteric
> SECONDARY
> >> selection on the X11 backend when we're trying to move the Linux world
> >> towards the more modern and less legacy-ridden Wayland display system
> would
> >> be problematic to say the least, and an ill fit for the majority of
> >> graphical user experiences in use these days.
> >>
> >> It should be entirely possible to add support for the SECONDARY
> selection
> >> inside specific applications, like text editors; or in specific
> libraries,
> >> like VTE for terminal emulators. It would definitely make more sense
> than
> >> trying to apply it to all text entry widgets in GTK+.
> >>
> >> Ciao,
> >>  Emmanuele.
> >>
> >>
> >> On Saturday, 20 August 2016, Charles Lindsey <c...@clerew.man.ac.uk>
> wrote:
> >>>
> >>> For over 20 years, I have been using the secondary-selection (a
> standard
> >>> feature of the X-Windows system) when editing texts, using the Solaris
> >>> operating system on Sun Hardware. Recently, I have switched to Linux
> on i86
> >>> hardwar

Re: Whatever happened to the Secondary Selection?

[Paul Davis]

Emmanuele,

did you watch his video?

On Sun, Aug 21, 2016 at 3:07 AM, Emmanuele Bassi  wrote:

> Hi;
>
> thanks for your email.
>
> GTK+, as a project, tracks bugs and enhancements in Bugzilla -
> https://Bugzilla.gnome.org/enter_bug.cgi?product=gtk%2b - instead of the
> mailing list, which is only meant for discussion.
>
> Additionally, the latest stable version of GTK+ is 3.20, and we plan to
> release GTK+ 3.22 by next month.
>
> We still (optionally) support the PRIMARY selection on the X11 backend,
> and some compatibility layer for it on Wayland, but we have no plans on
> adding support for the SECONDARY selection, as it's both barely specified
> and, like the PRIMARY, highly confusing for anybody who is not well-versed
> in 20+ years of use of textual interfaces on the X Windows
> System. Personally, I would have jettisoned the PRIMARY selection a long
> time ago as well, but apparently a very vocal minority is still holding
> tight to that particular Easter egg. Adding support for the even more
> esoteric SECONDARY selection on the X11 backend when we're trying to move
> the Linux world towards the more modern and less legacy-ridden Wayland
> display system would be problematic to say the least, and an ill fit for
> the majority of graphical user experiences in use these days.
>
> It should be entirely possible to add support for the SECONDARY selection
> inside specific applications, like text editors; or in specific libraries,
> like VTE for terminal emulators. It would definitely make more sense than
> trying to apply it to all text entry widgets in GTK+.
>
> Ciao,
>  Emmanuele.
>
>
> On Saturday, 20 August 2016, Charles Lindsey  wrote:
>
>> For over 20 years, I have been using the secondary-selection (a standard
>> feature of the X-Windows system) when editing texts, using the Solaris
>> operating system on Sun Hardware. Recently, I have switched to Linux on i86
>> hardware, and have been horrified to find that this valuable feature is not
>> supported by modern toolkits and editors. The world seems to have forgotten
>> what it was meant for, and yet I believe it is the best thing since sliced
>> bread.
>>
>> This is not the place to explain what the secondary-selection does, and
>> why it should be used more widely. To see that, I invite you to visit my
>> website at
>> http://www.cs.man.ac.uk/~chl/secondary-selection.html
>> which I hope will persuade you that something needs to be done about it.
>>
>> Furthermore, to illustrate how it is used, I have implemented an
>> Experimental Extension to GTK-3 so that people can try it out for
>> themselves and to see how useful it can be for constructing texts (and
>> particularly program texts, where there is a common requirement to grab
>> existing bits of code - perhaps even just identifiers - from other places,
>> whether in the same document or from outside).
>>
>> My implementation is based on gtk+-3.10.8, because I am using Ubuntu
>> 14.04LTS "Trusty Tahr", though it may well work on other Linux versions.
>> Yes I know 3.10.8 is ancient, but I don't expect my code, which is pretty
>> hairy, to be fit for immediate incorporation in current versions of gtk.
>> But it now works well enough for it to be tested more widely, and if people
>> like it, then I would be happy to join the Developer Team and to do the job
>> properly.
>>
>> So I invite you guys to look at my website, download my code and give it
>> a try. I am also making this known on various other lists, because unless
>> people try it out (and hopefully like it), there can be no pressure to take
>> it further.
>>
>> Share and Enjoy!
>>
>> --
>> Charles H. Lindsey -At Home, doing my own
>> thing
>> Tel: +44 161 436 6131 Web:
>> http://www.cs.man.ac.uk/~chl
>> Email: c...@clerew.man.ac.uk  Snail: 5  SK8 3JU, U.K.
>> PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4
>> AB A5
>> ___
>> gtk-devel-list mailing list
>> gtk-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>>
>
>
> --
> https://www.bassi.io
> [@] ebassi [@gmail.com]
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gsk-render review

[Paul Davis]

On Wed, Jul 20, 2016 at 11:17 AM, Emmanuele Bassi  wrote:

> Hi Alex;
>
> I've been mulling over this for a bit, and started working on what I
> think is a feasible solution.
>

Just wanted to mention in passing that we've had to a custom scheme that is
very similar to what emmanuele describes here, within the Ardour context.

We have our own graph/canvas.  We have widgets/canvas items whose rendering
is closely tied to data on disk, and for which it is expensive to recompute
their rendered appearance (i.e. to be avoided whenever possible). So we
cache renderings in an LRU container, in our case as a series of
Cairo::ImageSurfaces. The cache contains entries which represent contiguous
sections of the data source represented by the widget/canvas item, and so
we will also consider consolidating it from time to time (merging adjacent
sections). The cache is invalidated when any of these things changes:

allocation size
color (style)
horizontal and vertical zoom
data contents

at which times we throw away everything in the cache and start over. The
cache is *shared* across objects, because there may be many widgets/canvas
items displaying the same data.

There are a lot isomorphisms with what Emmanuele is describing, but I'm not
sure that such a design built into GTK could replace our own.






>
> On 14 July 2016 at 22:09, Alexander Larsson 
> wrote:
> > (Sorry for breaking threading, etc, posting from my phone)
> >
> > So, I think you misunderstood my opinion. I think the change in API to
> make
> > render nodes immutable, etc, is correct. The issue I have is on a higher
> > level, in the gtk widget tree. Let me try to explain.
>
> Yep, I see what you mean.
>
> > Every frame when we draw a toplevel we have each widget in the gtkwidget
> > tree submit geometry in the form of render nodes. The final result is a
> > transient immutable entity describing the entire set of rendering
> operations
> > for the frame. We can then do complex work on this in the backend to
> > efficiently render it.
>
> Indeed.
>
> > However, submitting geometry shouldn't automatically mean a complete
> rework
> > from scratch. We submit a description, which includes references to
> > textures, vertex arrays, shaders, etc. But we shouldn't have to e.g.
> > re-upload the textures each time we submit. However, we can't
> pre-calculate
> > many of these things ahead of time, even it they are theoretically known
> by
> > size-allocate time. For instance, we don't yet have a reference to the gl
> > context, and we probably want to wait as long as possible to avoid later
> > size-allocates invalidating the work before render time.
>
> > As a simple example, consider a widget that renders just a textured quad.
> > The texture depends on the size of the widget and some widget state. Lets
> > consider how this is drawn. By render time the first frame we know the
> size
> > and the state, so we can generate and upload the texture data. Then we
> > create a new render node referencing it and hand it of to the tree.
> However,
> > we also keep the texture around, because the next frame we can submit a
> new
> > render node referencing the same texture unless something changed.
>
> Yep, I was thinking something along the lines of a texture cache that
> is provided by the GSK renderer, but available to GTK via a
> specialised API.
>
> Basically, a GskTextureCache would work in terms of surface data,
> since this is what GTK already understands, and what GskRenderNode
> kind of expects behind the scenes.
>
> If the widget is in invalid state, it asks the texture cache for a
> draw surface, draws on it, and then sets the surface as the content of
> the render node; additionally, it gets a "cookie" from the texture
> cache, so that the widget can get the exact same surface for the
> cookie on subsequent frames. The cookie also allows us to keep
> references to the surface alive in the texture cache, when we'll move
> the rendering off the main thread — thus we can drop a surface from
> the cache only when all the frames that have been queued are pushed to
> the compositor. The default behaviour would be to drop the surface
> reference at the beginning of the render; if the newly submitted
> render nodes tree has an additional reference to a texture inside the
> cache then the surface will survive; if the contents of the nodes are
> different, the surface will be dropped, alongside its GL texture.
>
> If the widget drawing is simple enough that it can be discarded for
> every frame, then we can simply call the existing
> gsk_render_node_get_drawing_context() instead, and basically get the
> exact same behaviour as current GTK+.
>
> The hard part is, as you identified, invalidating the cache — or, at
> least, being able to tell a GTK+ widget that its contents have been
> invalidated and that it should submit a new surface.
>
> > So, what can change? If the widget state changes then we 

Re: Gtk+4.0

[Paul Davis]

I'm thinking of the "current,revision,age" psuedo-standard.


On Mon, Jul 11, 2016 at 5:19 PM, Behdad Esfahbod <beh...@behdad.org> wrote:

> On Mon, Jul 11, 2016 at 1:47 PM, Paul Davis <p...@linuxaudiosystems.com>
> wrote:
> > If soname was changed in keeping with the nominal "standard", it
> wouldn't be
> > that much of an issue. The soname would indicated added API, internal
> fixes,
> > and no change to public API/ABI. No?
>
> Humm.  I don't quite follow.  Common practice for "added API, internal
> fixes,
> > and no change to public API/ABI" is to keep the soname.
>
> > On Mon, Jul 11, 2016 at 4:29 PM, Behdad Esfahbod <beh...@behdad.org>
> wrote:
> >>
> >> I also think bumping soname every six months would be disaster.  It
> >> was painful enough when libstdc++, libpng, libssl, etc changed soname
> >> every few years.
> >>
> >> On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
> >> <poch...@gmail.com> wrote:
> >> > Hi,
> >> >
> >> > On 21/06/16 16:26, Peter Weber wrote:
> >> >> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying
> >> >> to
> >> >> write about my thoughts, in a careful way. In the first moment, I
> >> >> thought
> >> >> this is a good idea and just the numbering is misleading. Stability
> is
> >> >> what
> >> >> developers want, we need it, we love it. With a few days distance,
> >> >> numbering is just a small issue, I see this now entirely different
> and
> >> >> three major issues:
> >> >
> >> > Here are some thoughts I have about all this, from a downstream
> >> > maintainer POV.
> >> >
> >> > My concern with this new scheme is that GTK+ libraries will have to
> bump
> >> > the
> >> > soname every 6 months (if they want to support the latest GTK+). That
> >> > can be
> >> > manageable for say vte or gnome-desktop, although it may be bad if
> some
> >> > third
> >> > party apps pick a dependency on the vte for GTK+ 4.2 but don't update
> it
> >> > for
> >> > GTK+ 4.4, as then distros would need to ship an increasing number of
> >> > versions
> >> > that are unlikely to get any support upstream.
> >> >
> >> > But do you expect WebKitGTK+ to bump the ABI every 6 months?
> >> >
> >> > I feel like the X.[024] releases are just snapshots of a development
> >> > branch,
> >> > with X.6 being the stable release, and I wonder if X.[024] shouldn't
> >> > clearly be
> >> > labelled as that, regardless of what version number is chosen (be it
> >> > 4.0,
> >> > 3.99.0, 4.0beta1 or whatever).
> >> >
> >> > Cheers,
> >> > Emilio
> >> > ___
> >> > gtk-devel-list mailing list
> >> > gtk-devel-list@gnome.org
> >> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >>
> >>
> >>
> >> --
> >> behdad
> >> http://behdad.org/
> >> ___
> >> gtk-devel-list mailing list
> >> gtk-devel-list@gnome.org
> >> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
> >
> >
>
>
>
> --
> behdad
> http://behdad.org/
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Gtk+4.0

[Paul Davis]

If soname was changed in keeping with the nominal "standard", it wouldn't
be that much of an issue. The soname would indicated added API, internal
fixes, and no change to public API/ABI. No?

On Mon, Jul 11, 2016 at 4:29 PM, Behdad Esfahbod  wrote:

> I also think bumping soname every six months would be disaster.  It
> was painful enough when libstdc++, libpng, libssl, etc changed soname
> every few years.
>
> On Thu, Jul 7, 2016 at 11:23 AM, Emilio Pozuelo Monfort
>  wrote:
> > Hi,
> >
> > On 21/06/16 16:26, Peter Weber wrote:
> >> I don't see here an active discussion about Gtk+4.0[1]? So I'm trying to
> >> write about my thoughts, in a careful way. In the first moment, I
> thought
> >> this is a good idea and just the numbering is misleading. Stability is
> what
> >> developers want, we need it, we love it. With a few days distance,
> >> numbering is just a small issue, I see this now entirely different and
> >> three major issues:
> >
> > Here are some thoughts I have about all this, from a downstream
> maintainer POV.
> >
> > My concern with this new scheme is that GTK+ libraries will have to bump
> the
> > soname every 6 months (if they want to support the latest GTK+). That
> can be
> > manageable for say vte or gnome-desktop, although it may be bad if some
> third
> > party apps pick a dependency on the vte for GTK+ 4.2 but don't update it
> for
> > GTK+ 4.4, as then distros would need to ship an increasing number of
> versions
> > that are unlikely to get any support upstream.
> >
> > But do you expect WebKitGTK+ to bump the ABI every 6 months?
> >
> > I feel like the X.[024] releases are just snapshots of a development
> branch,
> > with X.6 being the stable release, and I wonder if X.[024] shouldn't
> clearly be
> > labelled as that, regardless of what version number is chosen (be it 4.0,
> > 3.99.0, 4.0beta1 or whatever).
> >
> > Cheers,
> > Emilio
> > ___
> > gtk-devel-list mailing list
> > gtk-devel-list@gnome.org
> > https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
> --
> behdad
> http://behdad.org/
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk_entry_set is a bit late.

[Paul Davis]

On Mon, Jul 4, 2016 at 9:46 PM, Ian Chapman  wrote:

> extern "C"
> void on_Signal_activate(){
> /*Phase 1  */
> gtk_entry_set_text(Status, "Starting phase 1"); //just
> show activity.
> std::cout << "Starting phase 1"  << std::endl;
> /*Phase 2  */
> gtk_entry_set_text(Status, "Starting phase 2"); //just
> show activity.
> std::cout << "Starting phase 2"  << std::endl;
> /*etc */
> gtk_entry_set_text(Status, "All phases complete"); //just
> show activity.
> std::cout << "All phases complete"  << std::endl;
> return; }
> I guess the guys who understand gtk can see what happens.  The progress
> messages come out on the terminal in order as expected from cout. The
> only message in the status field (GtkEntry) is the last one at the
> termination
> of servicing the signal.


You've got some fairly basic work to do on understanding how GUI programs
work. Lets start with the basic "event loop" that surrounds any GUI
application:

while (not told to quit) {
  wait_for_next_event ();
  process_events ();
  redraw_stuff ();
}

in the context of GTK, your signal handlers execute as part of
process_events(). From the structure above, you can see that nothing will
be redrawn on the screen until process_events() is done, and redraw_stuff()
is called.

Thus, you only see the final message/text that was set at the end of your
signal handler, drawn as part of redraw_stuff().

There are variety of ways to accomplish what you want, all of them more
complicated than the normal simple programming you might be hoping for.

The simplest is to run the main event loop yourself (recursively) after
each phase. This will get drawing done, and thus the text for that phase
will show up. The problem is that you have no control over what your
recursive main loop will do, and this can cause issues of both subtle and
disastrous proportions (though it usually is OK).

The best method is use threads, and carry out the work of each phase there,
queuing updates to the GUI via gtk_idle_add() or its contemporary
equivalent.

Other people may make other suggestions.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: signal for closing app

[Paul Davis]

the window manager "close" button being clicked causes
signal_delete_event() to be emitted for the window.

On Mon, Jun 6, 2016 at 5:21 PM, Krzysztof  wrote:

> I'm the very beginner in GTKmm.
> I design a simple interface in Glade. The application itself is written in
> C++.
>
> Which signal should I choose and which handler should I specify in
> File-Quit menu item to have the same action as clicking the X at upper
> right corner of window?
> How should I make it working in my application?
>
> --
> Regards
> Krzysztof J.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Disabling accelerators when typing text

[Paul Davis]

Just for reference, the somewhat conceptually cleaner current code is here:

https://github.com/Ardour/ardour/blob/master/gtk2_ardour/ardour_ui.cc#L5421

This doesn't show how to use GTK+ to do what you want, but it does
illustrate the basic idea: figure out if there is a focused widget in the
window; if there is, and that widget is a GtkEntry, treat the key event
differently than if it is not (or if there is no focus widget.


On Sat, Jun 4, 2016 at 4:03 PM, Paul Davis <p...@linuxaudiosystems.com>
wrote:

> I don't have a GTK+3 answer for you. We wrestled with this in Ardour which
> uses GTK+2, and cooked up quite a substantial hack to make it work. You can
> read that and the explanatory comments here:
>
> https://github.com/Ardour/ardour/blob/4.7/gtk2_ardour/utils.cc#L448
>
> SInce that tag (4.7) we've now replaced the entire GTK+2 accelerator
> mechanism with our own, because we cannot be limited by GTK+ ideas that
> some accelerators are off-limits. We now use our own system which hooks
> into the key_press and key_release events for every top level window.
>
> We do use Actions (such as they were in GTK+2) for almost everything, and
> we continue to push our bindings into GTK+ so that accelerators show up in
> menu items. I can't recommend this drastic of an approach, just noting that
> we had to take it.
>
> On Sat, Jun 4, 2016 at 3:34 PM, productivememberofsociety666 <
> productivememberofsociety...@weltenfunktion.de> wrote:
>
>> Hello,
>>
>> I just want to reask a question that was asked on StackOverflow [1] but
>> didn't receive a satisfactory answer there. Maybe someone on this list
>> has a better idea:
>>
>> I want to use ordinary letters *without modifiers* as accelerators in my
>> GTK+ 3 application, similar to vim's control scheme. For example, the
>> user could just press 'r' and it would remove an item in a list or
>> something like that.
>> So far this works fine, except the accelerators are also enabled while
>> the user has focused a text editing widget, and as a result it's
>> impossible to write text without activating a dozen accelerators in the
>> process.
>>
>> Is there a standard way to disable accelerators in  text editing
>> widgets? If not, what would you say is the best approach for a
>> workaround? E.g. should I try to intercept key presses somehow and check
>> whether a text editing widget is focused, or should I try to remove
>> accelerators whenever such a widget is focused and add them again when
>> it loses focus, or do something else entirely?
>>
>> I'm using GTK+ 3 and try to adhere to the "new" recommended way of
>> handling menu items, accelerators and corresponding actions using Gio,
>> i.e. the way it is described in [2].
>>
>> Thank you in advance!
>>
>> [1]: http://stackoverflow.com/q/22782726/2748899
>>
>> [2]: https://wiki.gnome.org/HowDoI/GAction
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Disabling accelerators when typing text

[Paul Davis]

I don't have a GTK+3 answer for you. We wrestled with this in Ardour which
uses GTK+2, and cooked up quite a substantial hack to make it work. You can
read that and the explanatory comments here:

https://github.com/Ardour/ardour/blob/4.7/gtk2_ardour/utils.cc#L448

SInce that tag (4.7) we've now replaced the entire GTK+2 accelerator
mechanism with our own, because we cannot be limited by GTK+ ideas that
some accelerators are off-limits. We now use our own system which hooks
into the key_press and key_release events for every top level window.

We do use Actions (such as they were in GTK+2) for almost everything, and
we continue to push our bindings into GTK+ so that accelerators show up in
menu items. I can't recommend this drastic of an approach, just noting that
we had to take it.

On Sat, Jun 4, 2016 at 3:34 PM, productivememberofsociety666 <
productivememberofsociety...@weltenfunktion.de> wrote:

> Hello,
>
> I just want to reask a question that was asked on StackOverflow [1] but
> didn't receive a satisfactory answer there. Maybe someone on this list
> has a better idea:
>
> I want to use ordinary letters *without modifiers* as accelerators in my
> GTK+ 3 application, similar to vim's control scheme. For example, the
> user could just press 'r' and it would remove an item in a list or
> something like that.
> So far this works fine, except the accelerators are also enabled while
> the user has focused a text editing widget, and as a result it's
> impossible to write text without activating a dozen accelerators in the
> process.
>
> Is there a standard way to disable accelerators in  text editing
> widgets? If not, what would you say is the best approach for a
> workaround? E.g. should I try to intercept key presses somehow and check
> whether a text editing widget is focused, or should I try to remove
> accelerators whenever such a widget is focused and add them again when
> it loses focus, or do something else entirely?
>
> I'm using GTK+ 3 and try to adhere to the "new" recommended way of
> handling menu items, accelerators and corresponding actions using Gio,
> i.e. the way it is described in [2].
>
> Thank you in advance!
>
> [1]: http://stackoverflow.com/q/22782726/2748899
>
> [2]: https://wiki.gnome.org/HowDoI/GAction
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk/quartz ... a tale of nested incompatible event loops

[Paul Davis]

The problem I was describing only affects a situation where some code that
uses Cocoa (CoreGraphics,really) directly exists in the same process as a
gtk/gdk/glib event loop. And it only is a problem if the CG rendering is so
slow that the CFRunLoop never idles. This only happens to use on systems
with Retina, and appears to be caused by the invocation of a specific
function from Apple that seems to be incredibly inefficiently implemented.
So unless you're triggering all of these things, I doubt it is the same
problem. But ... the basic underlying issue here is that gtk/gdk/glib on OS
X is 100%, absolutely dependent on the main CFRunLoop going idle - if it
does not go idle, then the gtk main event loop will not run.

On Tue, May 24, 2016 at 5:13 AM, Stuart Axon <stua...@yahoo.com> wrote:

> Hi,
> For Shoebot we use python with gi.repository, along with
> main_iteration + custom drawing with cairocffi, however on the most recent
> OSX, when I try and run, nothing is rendered - could this be the same / a
> similar issue ?
>
> S++
>
>
>
>
> On Monday, May 23, 2016 7:20 PM, Paul Davis <p...@linuxaudiosystems.com>
> wrote:
>
>
>
>
>
> On Mon, May 23, 2016 at 2:07 PM, Sébastien Wilmet <swil...@gnome.org>
> wrote:
>
> On Mon, May 23, 2016 at 01:29:44PM -0400, Paul Davis wrote:
> 
> > I'm emailing it
> > just in case anybody else decides to wade into a complete overhaul of the
> > design of the glib event loop on Quartz.
> 
>
> Looks somewhat obscure and low-level.
>
>
> The conditions that led to use needing to do this are obscure. The fix is
> definitely low level. But the issue is a design that landed in GTK+ some
> years ago (possibly as many as 10 years ago), and is fundamentally
> problematic. Replacing a call to some variant of poll() with a call into
> the native windowing system's own event loop is ... well, different :)
>
>
>
> I think on bugzilla it would have more chances to be read by someone
> interested to improve the quartz support in the future. When doing a
> complete overhaul, looking at the existing reported bugs seems a good
> thing to do.
>
>
> I would say that there is a 90% chance that I will be person to
> reimplement things. I wasn't looking so much for someone to fix it for me,
> but to see how much moral support I might raise :)
>
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: gtk/quartz ... a tale of nested incompatible event loops

[Paul Davis]

On Mon, May 23, 2016 at 2:07 PM, Sébastien Wilmet <swil...@gnome.org> wrote:

> On Mon, May 23, 2016 at 01:29:44PM -0400, Paul Davis wrote:
> 
> > I'm emailing it
> > just in case anybody else decides to wade into a complete overhaul of the
> > design of the glib event loop on Quartz.
> 
>
> Looks somewhat obscure and low-level.
>

The conditions that led to use needing to do this are obscure. The fix is
definitely low level. But the issue is a design that landed in GTK+ some
years ago (possibly as many as 10 years ago), and is fundamentally
problematic. Replacing a call to some variant of poll() with a call into
the native windowing system's own event loop is ... well, different :)


> I think on bugzilla it would have more chances to be read by someone
> interested to improve the quartz support in the future. When doing a
> complete overhaul, looking at the existing reported bugs seems a good
> thing to do.
>

I would say that there is a 90% chance that I will be person to reimplement
things. I wasn't looking so much for someone to fix it for me, but to see
how much moral support I might raise :)
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

gtk/quartz ... a tale of nested incompatible event loops

[Paul Davis]

The following text is take from a comment that is part of a recent (3 week
old) commit to Ardour. Hopefully it will speak for itself. I'm emailing it
just in case anybody else decides to wade into a complete overhaul of the
design of the glib event loop on Quartz.

First, here's the core of the code in the commit. Apologies to those who
don't read Objective C, and even if you do, it isn't exactly
self-explanatory. Btw, the original name for this commit was "Gandalf", for
reasons that might be slightly more clear.



static void interposed_drawIfNeeded (id receiver, SEL selector, NSRect rect)
{
if (block_plugin_redraws && (find (plugin_views.begin(),
plugin_views.end(), receiver) != plugin_views.end())) {
block_plugin_redraws--;
#ifdef AU_DEBUG_PRINT
std::cerr << "Plugin redraw blocked\n";
#endif
/* YOU ... SHALL  NOT ... DRAW */
return;
}
(void) ((int (*)(id,SEL,NSRect)) original_nsview_drawIfNeeded)
(receiver, selector, rect);
}

@implementation NSView (Tracking)
+ (void) load {
static dispatch_once_t once_token;

/* this swizzles NSView::displayIfNeeded and replaces it with
 * interposed_drawIfNeeded(), which allows us to interpose and block
 * the redrawing of plugin UIs when their redrawing behaviour
 * is interfering with event loop behaviour.
 */

dispatch_once (_token, ^{
Method target = class_getInstanceMethod ([NSView class],
@selector(displayIfNeeded));
original_nsview_drawIfNeeded = method_setImplementation
(target, (IMP) interposed_drawIfNeeded);
});
}

@end



And now here's the explanation:

This deeply hacky block of code exists for a rather convoluted reason.

The proximal reason is that there are plugins (such as XLN's Addictive
Drums 2)
which redraw their GUI/editor windows using a timer, and use a drawing
technique
that on Retina displays ends up calling arg32_image_mark_RGB32, a function
that
for some reason (probably byte-swapping or pixel-doubling) is many times
slower
than the function used on non-Retina displays.

We are not the first people to discover the problem with
arg32_image_mark_RGB32.

Justin Fraenkel, the lead author of Reaper, wrote a very detailed account
of the
performance issues with arg32_image_mark_RGB32 here:
http://www.1014.org/?article=516

The problem was also seen by Robert O'allahan (lead developer of rr, the
reverse
debugger) as far back as 2010:
http://robert.ocallahan.org/2010/05/cglayer-performance-trap-with-isflipped_03.html

In fact, it is so slow that the drawing takes up close to 100% of a single
core,
and the event loop that the drawing occurs in never sleeps or "idles".

In AU hosts built directly on top of ocoa, or some other toolkits, this
isn't
inherently a major problem - it just makes the entire GUI of the application
slow.

However, there is an additional problem for Ardour because GTK+ is built on
top
of the GDK/Quartz event loop integration. This integration is rather
baroque,
mostly because it was written at a time when FRunLoop did not offer a way to
wait for "input" from file descriptors (which arrived in OS X 10.5). As a
result, it uses a hair-raising design involving an additional thread. This
design has a major problem, which is that it effectively creates two nested
run
loops.

The GTK+/GDK/glib one runs until it has nothing to do, at which time it
calls a
function to wait until there is something to do. On Linux or Windows that
would
involve some variant or relative of poll(2), which puts the process to sleep
until there is something to do.

On OS X, glib ends up calling [FRunLoop waitForNextEventMatchingMask] which
will
eventually put the process to sleep, but won't do so until the FRunLoop
also has
nothing to do. This includes (at least) a complete redraw cycle. If
redrawing
takes too long, and there are timers expired for another redraw (e.g.
Addictive
Drums 2, again), then the FRunLoop will just start another redraw cycle
after
processing any events and other stuff.

If the CFRunLoop stays busy, then it will never return to the glib level at
all,
thus stopping any further GTK+ level activity (events, drawing) from taking
place. In short, the current (spring 2016) design of the GDK/Quartz event
loop
integration relies on the idea that the internal FRunLoop will go idle, and
totally breaks if this does not happen.

So take a fully functional Ardour, add in XLN's Addictive Drums 2, and a
Retina
display, and Apple's ridiculously slow blitting code, and the FRunLoop never
goes idle. As soon as Addictive Drums starts drawing (over and over again),
the
GTK+ event loop stops receiving events and stops drawing.

One fix for this was to run a nested GTK+ event loop iteration (or two)
whenever
a plugin window was redrawn. This works in the sense that the immediate
issue
(no GTK+ 

Re: multiple windows

[Paul Davis]

You need to make the 2nd window modal.

And you need to fix the bugs in your code. Use a debugger and set a
breakpoint in g_logv, then look at the backtrace to get clues on where
those error messages are coming from.

On Thu, May 19, 2016 at 9:19 AM, Ian Chapman  wrote:

> Hi,
> I must have missed a basic point on how to use tdk and glade.  I have
> my main window and that works the way it should.  I have a signal from a
> button that opens a second window and three thing are not right.
> When the window opens the terminal shows ---
> (main:17061): Gtk-WARNING **: Symbolic icon pan-down-symbolic-ltr of size
> 16 is in an icon theme directory of size 128
> When I close the window2 (same way as window1) the terminal shows ---
> (main:17061): Gtk-CRITICAL **: gtk_widget_destroy: assertion
> 'GTK_IS_WIDGET (widget)' failed
>
> The second window2 works that way I expect, the only hick is that
> window1 functions can be executed in parallel and that is not desired.
> I'm using the top level window but there are also offscreen and
> application windows and I've not determined when they should be used?  Any
> pointers greatly appreciated.  Regards Ian.
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: loops and contexts

[Paul Davis]

Also, worth differentiating between 1 main loop per thread + multiple
threads, and multiple recursive main loops per thread.

Modal dialogs involve a recursive main loop, but it runs in the same thread
as the normal main loop does (since it runs "inside" the "real" main loop).

An application like Ardour runs N main loops in N threads, with each thread
dealing with a different type of event source. We do not multiplex the
event sources into the normal main loop, because we do not want the GUI
behaviour potentially interferred with by the demands of these other UI
control systems. Not many applications require this design.


On Sat, May 7, 2016 at 6:10 PM, Ben Iofel  wrote:

> Dialogs, for example, have their own main loop.
>
> Generally, though, you will have one main loop (gtk's loop) even for
> multiple windows in your app.
>
> On Fri, May 6, 2016 at 4:11 PM, Krzysztof  wrote:
>
>> Is there a reason to have more than one MainContext or more than one
>> MainLoop? Or is it more appropriate to add event handlers to one
>> application main loop (I mean GtkApplication)?
>>
>> --
>> Regards
>> Krzysztof J.
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK3 on Darwin

[Paul Davis]

On Sat, May 7, 2016 at 5:17 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

>
> As summary: can anyone please confirm development on Darwin is still
> active and,
>

The vast majority of GTK+ development happens on and within the context of
Linux platforms and their issues/designs/needs. GTK+ continues to function
and even be improved on Windows and OS X because there are a few
applications using GTK+'s touted cross-platform abilities. When those
applications run into issues, most of the time the problems get fixed,
typically with involvement from developers of those apps. If there are
problems not encountered by those apps, or if they are discovered by
someone not willing to get involved in GTK+ itself, they will likely
persist for some unbounded period of time.

The vast majority of GTK+ works as expected on OS X.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk3(mm) under Os X

[Paul Davis]

On Thu, Apr 14, 2016 at 1:31 AM, C Gosch  wrote:

> Hi List,
>
> I started using gtk3 (gtkmm-3.0) on OS X, coming from Linux.
> I installed everything using homebrew. I noticed that the windows of a
> very old test program that I wrote are having the wrong spacings between
> widgets and that
> some stock icons are missing. That program was last used with gtk2.4, so I
> am guessing it might be a mix of old code and maybe things being slightly
> different under OS X.
> Does anyone on this list have experience with gtk3 in OS X and can give me
> some hints on how I can use it so that it blends well into the rest of the
> desktop?
>

Making a cross-platform toolkit look like something implemented with
Apple's own Cocoa APIs is quite problematic. Doing it "right" relies on an
API that Apple do provide but do not maintain much any more, and it has
become rather stale. This means that implementing GTK drawing of widgets in
ways that are consistent with Apple's "current" version (which changes
quite a lot - compare El Capitan with older versions, for example) becomes
something that has to be manually implemented pixel by pixel. There were
some attempts to do this for GTK+2 but they were never completed AFAIK.

You also have issues like the fact that most applications use Apple's own
Finder-like widget when presenting a dialog involving choosing files and
folders; the GTK+ one will never look or feel like that.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GSource count

[Paul Davis]

fundamentally, it relies on OS facilities to wake a process when certain
events happen. Some of those facilities are designed, these days, to handle
web servers dealing thousands of concurrent connections. so at some level,
the answer is "sure, it is fine".

however, whether or not glib actually harnesses those facilities correctly
to scale up in this way is a separate question, and i suspect that it
probably does not (e.g. use of poll (2) rather than epoll or kevent or
whatever a more scalable mechanism on a given platform is). but my
assessment could be wrong, and i'm sure others will contribute 

On Mon, Apr 4, 2016 at 4:28 PM, Krzysztof  wrote:

> Is it reasonable to have thousands of sources added to event loop? I mean
> efficiency of computing. I don't know how this factory of event consuming
> exactly works.
> A population of artificial cells may be an example.
>
> --
> Regards
> Krzysztof J.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk+ 3 custom widget

[Paul Davis]

>From a post here just yesterday:

https://wiki.gnome.org/HowDoI/CustomWidgets

On Wed, Mar 30, 2016 at 6:45 PM,  wrote:

> Hi,
>
> I'm currently starting to work on some client using gtk+ 3. We have
> several clients, qt for windows, mac stuff for macos. Those clients try to
> be closest as possible of the guidelines of their respective system they
> are intended to be used.
>
> in other hand, we want that some parts of the clients much more similar as
> possible. One part is about the overlay we use over video. Those buttons
> are circulars, with some transparency.
>
> I used gtkmm in the past, but the client I'm working on uses gtk+ 3. I try
> to figure where I can found tuts/doc about making my own widget &
> transparency.
>
>
>
> I personally found the gtk+ 3 documentation pretty scarce... for gtk+ 3, I
> found nothing about that subject so far...
>
>
>
> regards,
>
> Nicolas JAGER
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: [glib] malloc and bdwgc

[Paul Davis]

There are many libraries that can call malloc before main().

On Thu, Jan 7, 2016 at 2:10 AM, 张海  wrote:

> I'm using glib without the whole GObject system and reference counting
> mechanism, and I'd like to integrate bdwgc
> (https://github.com/ivmai/bdwgc/) because of the complexity of my
> program.
>
> I've read about using GMemVTable to redirect memory allocation of glib
> to GC_malloc, however as in
> https://mail.gnome.org/archives/commits-list/2015-July/msg05892.html ,
> such mechanism no longer works, and even more unfortunately it says
> glib allocates memory before main() so it seems that I'm even unable
> to hook to malloc in time as in
> http://www.gnu.org/software/libc/manual/html_node/Hooks-for-Malloc.html
> .
>
> Can I use bdwgc with glib >= 2.4.6? If so, how can I achieve that
> correctly?
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: GTK2_PATH and GTK3_PATH

[Paul Davis]

GTK2 on Linux is not relocatable. I did a patch that makes it so, it lives
somewhere in bugzilla. We have been using it in our distro-neutral
builds/packages of Ardour for several years (the package includes all
required libraries except libc and X Window, and GTK is the only one that
is not relocatable without a patch.

On Wed, Jan 6, 2016 at 3:44 PM, Ricardo Wurmus  wrote:

> Hi,
>
> I’m using GuixSD[1], a variant of the GNU system which does not follow
> the FHS in order to provide declarative system configuration and
> functional package management.  As the functional package manager
> installs each package into its own directory under “/gnu/store”, the
> GTK+ libraries are obviously not installed in the same global tree as
> input method modules or themes.
>
> When a user installs, say, an IBus input method into their profile at
> “~/.guix-profile” they have no good way to tell the GTK libraries
> (somewhere in “/gnu/store/...-gtk.../lib”) about the location of these
> modules.  As a user may have applications of which some use GTK+ 2 and
> others use GTK+ 3, the usual GTK+ environment variables cannot be used
> to direct a particular version of GTK+ to load compatible modules from a
> given path.
>
> The documentation at [2] explicitly warns about setting GTK_PATH or
> GTK_IM_MODULE_PATH system-wide, as both GTK+ 2.x and GTK+ 3.x will
> respect these variables.
>
> This is why I would like to propose two patches, one against GTK+ 2.x
> and the other against GTK+ 3.x, introducing the environment variables
> GTK2_PATH and GTK3_PATH, which allow users to specify additional search
> paths that are only respected by one major version of GTK+ (and not the
> other).
>
> I packaged IBus and the libpinyin input method module for Guix and could
> only make it work in all applications after patching both major versions
> of GTK+ to respect these additional environment variables.[3][4]
>
> We intend to use a slightly modified version of the attached patches for
> Guix (prefixing the variable names with “GUIX_”), but we think it would
> be best to see if upstream would be okay with these patches, or if there
> are better ways we haven’t thought of.
>
> The patches are inlined below.
>
> ~~ Ricardo
>
> 
> [1]: https://www.gnu.org/software/guix/
> [2]: https://developer.gnome.org/gtk3/stable/gtk-running.html
> [2]: http://lists.gnu.org/archive/html/guix-devel/2015-09/msg00306.html
> [3]: http://lists.gnu.org/archive/html/guix-devel/2015-12/msg00046.html
>
>
> ___
> gtk-devel-list mailing list
> gtk-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list
>
>
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: After use g_io_add_watch , the cpu usage to 100%

[Paul Davis]

You need to actually read whatever data is available.

On Tue, Dec 15, 2015 at 12:32 AM, <neil...@emerson.com> wrote:

> Hi, Paul
>
> Thank you for your reply.  I don’t know how to clean the “data ready”
> condition on the socket. Please help me know how to do it.
>
>
>
> Thanks
>
> Neil
>
>
>
> *From:* Paul Davis [mailto:p...@linuxaudiosystems.com]
> *Sent:* Tuesday, December 15, 2015 11:33 AM
> *To:* Wu, Neil [CLIMATE/RS/CN]
> *Cc:* ML-gtk
> *Subject:* Re: After use g_io_add_watch , the cpu usage to 100%
>
>
>
> You're probably not clearing the "data ready" condition on the socket in
> the callback. As soon as you return to main event loop, the socket still
> has data ready.
>
>
>
> On Mon, Dec 14, 2015 at 10:07 PM, <neil...@emerson.com> wrote:
>
> Hi, all
>
>
>
> I upload the glib-2.0 library  from 2.38.2 to 2.44.1, then the cpu usage
> to 100%.
>
> After testing , I find the problem is caused by g_io_add_watch function.
> Following is the part code about the glib.
>
>
>
>struct sockaddr_can addr;
>
> struct ifreq ifr;
>
> int loopback = 0;
>
> gint fd;
>
> GIOChannel *io;
>
> guint ev_id;
>
>
>
> if (getenv("CANLOOPBACK"))
>
> loopback = 1;
>
>
>
> memset(, 0, sizeof(addr));
>
> memset(, 0, sizeof(ifr));
>
> fd = socket(PF_CAN, SOCK_RAW, CAN_RAW)
>
>
>
> addr.can_family = AF_CAN;
>
>
>
> strcpy(ifr.ifr_name,”can0”);
>
> ioctl(fd, SIOCGIFINDEX, 
>
> addr.can_ifindex = ifr.ifr_ifindex;
>
>
>
> setsockopt(dcan->fd, SOL_CAN_RAW, CAN_RAW_LOOPBACK,
> , sizeof(loopback));
>
>
>
>  bind(dcan->fd, (struct sockaddr *) , sizeof(addr))
>
>  io = g_io_channel_unix_new(fd);
>
> g_assert(io);
>
> g_io_channel_set_encoding(io, NULL, NULL);
>
> g_io_channel_set_buffered(io, FALSE);
>
> ev_id = g_io_add_watch(io, G_IO_IN, NULL, NULL); / ev_id
> = g_io_add_watch(io, G_IO_IN, my_function, NULL);
>
>
>
> If any people know how to solve the problem, or any information may lead
> to this problem, please tell me .   Thanks very much
>
>
>
> Neil
>
>
>
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: After use g_io_add_watch , the cpu usage to 100%

[Paul Davis]

You're probably not clearing the "data ready" condition on the socket in
the callback. As soon as you return to main event loop, the socket still
has data ready.

On Mon, Dec 14, 2015 at 10:07 PM,  wrote:

> Hi, all
>
>
>
> I upload the glib-2.0 library  from 2.38.2 to 2.44.1, then the cpu usage
> to 100%.
>
> After testing , I find the problem is caused by g_io_add_watch function.
> Following is the part code about the glib.
>
>
>
>struct sockaddr_can addr;
>
> struct ifreq ifr;
>
> int loopback = 0;
>
> gint fd;
>
> GIOChannel *io;
>
> guint ev_id;
>
>
>
> if (getenv("CANLOOPBACK"))
>
> loopback = 1;
>
>
>
> memset(, 0, sizeof(addr));
>
> memset(, 0, sizeof(ifr));
>
> fd = socket(PF_CAN, SOCK_RAW, CAN_RAW)
>
>
>
> addr.can_family = AF_CAN;
>
>
>
> strcpy(ifr.ifr_name,”can0”);
>
> ioctl(fd, SIOCGIFINDEX, 
>
> addr.can_ifindex = ifr.ifr_ifindex;
>
>
>
> setsockopt(dcan->fd, SOL_CAN_RAW, CAN_RAW_LOOPBACK,
> , sizeof(loopback));
>
>
>
>  bind(dcan->fd, (struct sockaddr *) , sizeof(addr))
>
>  io = g_io_channel_unix_new(fd);
>
> g_assert(io);
>
> g_io_channel_set_encoding(io, NULL, NULL);
>
> g_io_channel_set_buffered(io, FALSE);
>
> ev_id = g_io_add_watch(io, G_IO_IN, NULL, NULL); / ev_id
> = g_io_add_watch(io, G_IO_IN, my_function, NULL);
>
>
>
> If any people know how to solve the problem, or any information may lead
> to this problem, please tell me .   Thanks very much
>
>
>
> Neil
>
>
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: How method g_timeout_add uses Linux timer?

[Paul Davis]

Why not read the source code?

Hint: it doesn't use signals. The event loop is always running, which means
blocking and waiting for events (or a timeout).

On Wed, Dec 9, 2015 at 7:10 AM, Andrzej Borucki 
wrote:

> For Windows is ::SetTimer, ::KillTimer but how glib uses timewr for Linux?
> is sort of:
> timer_t tid;
> sigevent sig;
> timer_create(CLOCK_REALTIME, , );
> ?
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: 64bit GTKmm

[Paul Davis]

gtkmm, like almost all open source software with at least one foot in the
linux world, naturally builds for 64 bit. Linux has supported 64 bit
systems for a very, very long time now.

On Wed, Dec 9, 2015 at 11:13 PM, phillip mobley 
wrote:

> Hello everyone,
>
> I am  currently looking at different toolkits to build a UI for an
> application that I have.
>
> I am currently leaning towards gtkmm as the way to go. However, I need a
> confirmation on whether or not gtkmm is capable of being compiled for 64
> bits. I am creating a UI for a FEA simulator so the 64 bits will be
> necessary
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: memory leak on modify_bg fuction

[Paul Davis]

Most memory leaks in GTK are not memory leaks. People write about once
every two months that they've found one, without really understanding how
GTK (and more importantly, glib) uses memory.

If you want people to respond sensibly/usefully to such things, then you
need to start by describing what tools you've used to identify the "memory
leak".

On Mon, Oct 19, 2015 at 12:20 PM, rolozanop  wrote:

> Could someone please tell me why modify_bg give me memory leaks and how to
> resolve it?
>
> Gdk::Color colorSelected;
> colorSelected.set("orange");
> m_buttonsGTK[E_BUTTON_LEVEL]->modify_bg(Gtk::STATE_NORMAL, colorSelected);
>
> Thanks.
>
>
>
> --
> View this message in context:
> http://gtk.10911.n7.nabble.com/memory-leak-on-modify-bg-fuction-tp88346.html
> Sent from the Gtk+ - General mailing list archive at Nabble.com.
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Trigger a GtkEntryCompletion's popup

[Paul Davis]

On Fri, Oct 9, 2015 at 6:43 AM, Stefan Salewski  wrote:
>Entry completion working for zero
> characters -- I have some difficulty understanding it. When there is
> zero input, there is not much to complete.

it means, typically, "show me all possible completions". Useful in
cases where there are not that many options.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: GTK/GDK Bug 09/30/15

[Paul Davis]

On Wed, Sep 30, 2015 at 5:50 PM, Thomas Dineen  wrote:
> Gentle People:
>
>  I am getting a segfault from GTK/GDK. This segfault is associated with
> the top level window freezing up! It dose seem to "wake up" again if the top
> level menus are accessed.

This is not how you report bugs. They go to bugzilla. And you provide
no source code so there's no way for anyone to provide any feedback on
what might cause your crash.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Chinese font not displayed in gtk app on Windows

[Paul Davis]

That guess would be wrong.

This problem is related to font discovery. I can't tell you more, sorry.

On Thu, Sep 24, 2015 at 4:16 PM, Gergely Polonkai  wrote:
> Hello,
>
> my first guess is that the font GTK uses doesn't support Chinese characters.
> However, I don't know a way to check this under W10…
>
> Best,
> Gergely
>
> On 24 Sep 2015 19:25, "Francois Naggar-Tremblay" 
> wrote:
>>
>> Hi,
>>
>> I'm using a Chinese handwriting recognition GTK application
>> (http://www.tegaki.org/) on Windows 10. It works well, apart from the fact
>> that every Chinese character is replaced by a rectangle with 4 circles in it
>> and a dot in each circle. Any clue as to why this is happening and how to
>> fix it?
>>
>> Thank you!
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to grey out menu items

[Paul Davis]

On Sun, Sep 20, 2015 at 9:30 AM, richard boaz  wrote:
> Hi Stefan,
>
> this question also came up a few years ago, where i detailed the solution i
> have employed for this problem here:
> https://mail.gnome.org/archives/gtk-list/2010-September/msg00047.html
>
> i subsequently formalized this into a self-contained library, with a
> complete description of it here:
> http://www.binpress.com/app/gtk-widget-state-manager/1008
>
> and, feel free to find the complete source code for free download here:
> https://gitlab.com/ivor/GTK-WSM


just a note: doing this "properly" should involve Actions, not widgets.

it is unfortunate that neither GTK's own documentation, along with
most stuff I've read on GUI programming, doesn't emphasize the concept
of Actions as a more basic element of GUI programs.

why is this important? Because in any good GUI program, many of the
possible things a user can do should be drivable by both mouse/touch
based interaction with a widget, but also by other mechanism (such as
the keyboard, or external network control). By coding around widgets
as the basic concept, the design misses out on this basic truth.

if you use Actions, then you can make actions insensitive. This will
propagate to their on-screen proxies (widgets) but also to the
action's activability via other mechanisms (i.e. Action::activate()
will not do anything no matter who or what invokes it).
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: [GTK2] GTK2_RC_FILES override clashes with current theme

[Paul Davis]

There are very, very few apps that come with per-app GTK RC files.

In my/our case, Ardour (http://ardour.org/) specifically works to try
to prevent loading ANY other RC files except the one it comes with.

So yes, you are not the first to run into it, but you are among a very
small number of people to do so, and likely most of us have just
worked around it.


On Tue, Sep 15, 2015 at 5:59 PM, lemonsqueeze <lemonsque...@gmx.com> wrote:
> I guess what greatly confuses me is:
> 1) GTK2_RC_FILES is documented as specifying
> (https://developer.gnome.org/gtk2/stable/gtk-running.html)
> "a list of RC files to parse instead of the default ones"
> 2) Actual behavior differs
> "a list of RC files to parse in addition to the default ones"
> 3) Fix is a trivial one line change to gtkrc.c
>(which I'm not asking for btw, trying to understand the situation
>here)
>
> This doesn't make sense. With GTK so widely used, I find it hard to
> believe I'm the first one to run into this...
>
>
> On 09/15/2015 04:49 PM, Paul Davis wrote:
>> No, you posted in the right place. I just added the part after the
>> "..." in case you followed with "is anyone working to fix this?"
>>
>> the "fix" is/was to completely redesign the entire themeing system,
>> but that is something you will only find in GTK3.
>>
>> On Tue, Sep 15, 2015 at 10:41 AM, lemonsqueeze <lemonsque...@gmx.com> wrote:
>>>
>>>
>>> On 09/14/2015 01:52 PM, Paul Davis wrote:
>>>> On Mon, Sep 14, 2015 at 3:49 AM, lemonsqueeze <lemonsque...@gmx.com> wrote:
>>>>> Hi all,
>>>>
>>>>> Question: Is this a bug or my understanding of how GTK2_RC_FILES works ?
>>>>> Shouldn't GTK ignore the current theme altogether when GTK2_RC_FILES is
>>>>> set ? Surely themes don't seem to be expected to use globally unique
>>>>> style names ...
>>>>
>>>> that's where you'd be wrong ... remember that GTK2 is no longer under
>>>> development and the themeing mechanism in GTK3 bears essentially no
>>>> relationship whatsoever to the design in GTK2.
>>>
>>> That was a question about GTK2 actually, did I post in the wrong place
>>> perhaps ?
>>> ___
>>> gtk-list mailing list
>>> gtk-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: [GTK2] GTK2_RC_FILES override clashes with current theme

[Paul Davis]

No, you posted in the right place. I just added the part after the
"..." in case you followed with "is anyone working to fix this?"

the "fix" is/was to completely redesign the entire themeing system,
but that is something you will only find in GTK3.

On Tue, Sep 15, 2015 at 10:41 AM, lemonsqueeze <lemonsque...@gmx.com> wrote:
>
>
> On 09/14/2015 01:52 PM, Paul Davis wrote:
>> On Mon, Sep 14, 2015 at 3:49 AM, lemonsqueeze <lemonsque...@gmx.com> wrote:
>>> Hi all,
>>
>>> Question: Is this a bug or my understanding of how GTK2_RC_FILES works ?
>>> Shouldn't GTK ignore the current theme altogether when GTK2_RC_FILES is
>>> set ? Surely themes don't seem to be expected to use globally unique
>>> style names ...
>>
>> that's where you'd be wrong ... remember that GTK2 is no longer under
>> development and the themeing mechanism in GTK3 bears essentially no
>> relationship whatsoever to the design in GTK2.
>
> That was a question about GTK2 actually, did I post in the wrong place
> perhaps ?
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: [GTK2] GTK2_RC_FILES override clashes with current theme

[Paul Davis]

On Mon, Sep 14, 2015 at 3:49 AM, lemonsqueeze  wrote:
> Hi all,

> Question: Is this a bug or my understanding of how GTK2_RC_FILES works ?
> Shouldn't GTK ignore the current theme altogether when GTK2_RC_FILES is
> set ? Surely themes don't seem to be expected to use globally unique
> style names ...

that's where you'd be wrong ... remember that GTK2 is no longer under
development and the themeing mechanism in GTK3 bears essentially no
relationship whatsoever to the design in GTK2.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Desktop as transient window

[Paul Davis]

On Mon, Aug 10, 2015 at 12:31 PM, Igor Korot ikoro...@gmail.com wrote:
 Jasper,

 On Sun, Aug 9, 2015 at 7:19 PM, Jasper St. Pierre jstpie...@mecheye.net 
 wrote:
 The desktop is not a window. It could be in some desktop environments,
 but is not always. In fact, in some desktop environments, there is no
 desktop window or desktop concept at all. There is no standard
 protocol to fetch the desktop window if it exists, either.

 The reason that unparented dialogs are discouraged are because in most
 cases, dialogs shouldn't just pop up out of the blue -- they should
 come from an understandable user action or application window to tie
 it back to. Otherwise, you might see a random dialog pop up at some
 point without knowing where it came from.

 I understand this part.
 The trouble is - what if the application is dialog based?

 Let's say by design of my application it starts up by displaying the
 dialog with some options
 and after that the main window shows up after I click OK.

 How do I handle this?

This has nothing to do with setting a transient parent, which is a
specialized operation that is actually the wrong thing to do on some
platforms anyway.

In the use case you describe: you show the options dialog, when the
user activates a dialog response you hide (or destroy) the dialog, and
show the main window.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Desktop as transient window

[Paul Davis]

On Mon, Aug 10, 2015 at 12:42 PM, Paul Davis p...@linuxaudiosystems.com wrote:
 On Mon, Aug 10, 2015 at 12:40 PM, Igor Korot ikoro...@gmail.com wrote:

 IIUC, in this specific case I should create the main frame, hide it and then
 set the parent for my options dialog to be this main frame.

 you do not need to set the parent, and in almost all cases you should
 not set the parent.

to be clear, i am referring to explicitly setting the transient
parent of a GtkWindow. I am not referring to setting the parent of a
GtkDialog, but GtkDialog's are entirely happy to have no parent.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Desktop as transient window

[Paul Davis]

On Mon, Aug 10, 2015 at 12:40 PM, Igor Korot ikoro...@gmail.com wrote:

 IIUC, in this specific case I should create the main frame, hide it and then
 set the parent for my options dialog to be this main frame.

you do not need to set the parent, and in almost all cases you should
not set the parent.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Desktop as transient window

[Paul Davis]

On Mon, Aug 10, 2015 at 12:57 PM, Jasper St. Pierre
jstpie...@mecheye.net wrote:
 Hi Paul,

 In recent GTK+ versions, GtkDialog emits a warning when it is mapped
 without a parent, saying that it is discouraged. See
 https://git.gnome.org/browse/gtk+/tree/gtk/gtkdialog.c#n776

I should my mouth/fingers closed/still when GTK3 is on the table.

Sorry for the noise. This warning seems unfortunate though. GtkDialog
is a useful class and doesn't inherently need a parent. Does it?

Using transient-parent on OS X is a very bad idea, and it really buys
nothing with tiled WM's either. It is very regrettable that X (and its
successors) have not implemented a more sophisticated app-centric
window layering model.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: What to use on GTK+3

[Paul Davis]

On Sat, Aug 8, 2015 at 8:41 PM, Allin Cottrell cottr...@wfu.edu wrote:

 However, in relation to Igor's original point, giving the user options of
 Yes/No is IMO fine if your dialog asks a short, simple question that
 requires an answer of Yes or No. As in

 Overwrite filename? Yes/No
 Send message? Yes/No
 Really delete X? Yes/No

 One could rephrase these messages as something other than Yes/No questions
 but would that actually be clearer? I doubt it.

I think you're wrong. Each one of these can be converted into a dialog
of the following general form:

  Need confirmation to carry out potentially significant action

[ Do not take this action ][ Take this action ]


A specific case may help


  Overwriting this file may cause data loss

   [ Do not overwrite the file ]   [ Overwrite the file ]


or

  Once your message is sent, you cannot delete it.

   [ Do not send this message]  [ Send this message]


Both these examples are clearer, because they explain what is at stake.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Documentation inconsistency

[Paul Davis]

On Wed, Aug 5, 2015 at 7:04 AM, Igor Korot ikoro...@gmail.com wrote:

 Well the trouble is that documentation gives incorrect information:
 First it says function is deprecated and then gives an impression it's
 OK to use it.

That's the impression you got. It isn't the impression I got.

The documentation has to cover the following cases:

   * someone new to GTK/glib, writing new code
   * someone new to GTK/glib, working on existing code that uses g_thread_init
   * someone with experience using GTK/glib and threads, writing new code
   * someone with experience using GTK/glib and threads, working on
existing code that uses g_thread_init

I think that the documentation covers all these cases reasonably well,
attempting to
make it clear that you should not use the function anymore, but if you
have existing code that calls it,
you should modify the way the function is called if you choose not to remove it.

It could be clearer, yes. But it isn't actually inconsistent.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Outdated win32 bundle

[Paul Davis]

On Tue, Jun 16, 2015 at 11:26 AM, LRN lrn1...@gmail.com wrote:

 On 11.06.2015 15:44, anatoly techtonik wrote:

  Can GTK be cross-compiled for Windows?

 It should be possible.


Just for the record, the Ardour project does automated builds of the entire
GTK(2) stack for Windows by cross-compiling inside a cow/pbuilder (chroot)
environment on Linux. We compile Ardour for Windows in the same way.

Our application builds are fully automated (nightly.ardour.org has the
results); the stack build is fully scripted and can be run unattended when
needed. Obviously, we don't update our GTK stack(s) very often.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Misconduct of GTK+/glib Bugtracker Admins

[Paul Davis]

On Thu, Jun 4, 2015 at 5:17 PM, IgnorantGuru ignorantg...@openmailbox.org
wrote:

 On Thu, 4 Jun 2015 16:30:43 -0400
 Paul Davis p...@linuxaudiosystems.com wrote:

  Wow, what an amazing waste of time and space.

 Yes, that's what I thought for such a simple bug.  Imagine if Comment #1
 had been:

 Indeed, we seem to have broken gio when we added our gvfs hack, making
 the file chooser see only our file manager's mounts, ignoring everyone
 else's.  That's a simple fix so I'll take care of it immediately.  Thanks
 for bringing it to our attention.

 Everything else from them in that bug report was inaccurate and
 irrelevant, hostile and dismissive, and completely unnecessary.


You are the person who began their first post on the bug with I realize
that GTK development is effectively dead for non-Gnome projects,... In
your second post, you added We are doing so here, and as usual, those
needs are summarily dismissed if not coming from Red Hat. It is you who
was inflammatory and irrelevant.

For the record, I'm the lead dev of a extremely non-GNOME (you might even
say anti-GNOME) project that has used GTK for over 15 years. I do GTK
internal development work from time to time. I don't agree with anything
about the way you've characterized anything that happened in that bug
report. Robert Schroll seemed to summarize the whole thing extremely
accurately.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Misconduct of GTK+/glib Bugtracker Admins

[Paul Davis]

Wow, what an amazing waste of time and space. Also, it isn't on a mailing
list that is even halfway relevant, unless you're just trying to poison the
air.
___
gtk-list mailing list
gtk-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-list

Re: Using Python v3.3 while building Glib

[Paul Davis]

On Wed, May 13, 2015 at 6:59 AM, Fan, Chun-wei (范君維) fanc...@yahoo.com.tw
 wrote:
[ ... ]

It isn't possible for John to use anybody else's build of the GTK stack,
because we apply patches to parts of it that have been turned down for
inclusion in the mainline GTK2 tree.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list