Re: Gdk-WARNING **: gdkwindow-win32.c:1834: SetWindowLongPtr failed: Invalid window handle.

[Nicola Fontana]

Il Wed, 16 May 2018 02:40:44 + songqing shan  scrisse:

> Hello,
> 
> 
> I am learning GTK and developing a small application, which uses gtktextview 
> widget.
> 
> In my application, I compile it well. When running it, clicking the texview 
> and "Gdk-WARNING **: gdkwindow-win32.c:1834: SetWindowLongPtr failed: Invalid 
> window handle" occurs.
> 
> Then I find an example on internet as follows. The same error occurs.

Hi,

that is not an error, it is a warning. The code you posted does
not have any problems here.

Are you experiencing some real problem apart from the spurious
warning?

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: IDE to develop app with GTK3 on windows using MSYS2

[Nicola Fontana]

Il Mon, 7 May 2018 09:30:13 +0200 arkkimede  scrisse:

> ...
> Now I would migrate on WIndows 10 by means of MSYS2.
> 
> There is an IDE (better if open source) that I can use instean to follow to
> use vi?
> ...

Hi,

it seems to me a step backward: nothing can beat a properly
configured (vim|emacs)+(gcc|clang) pair.

Anyway many years ago there was DevCpp: I used it once and it was
very easy to get a GTK+ project started.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkRevealer glitches the text view drawing

[Nicola Fontana]

Il Fri, 4 May 2018 14:19:42 +0300 Marius Gedminas  scrisse:

> ...
> I've checked https://gitlab.gnome.org/GNOME/gtk/issues briefly but
> couldn't find an existing bug, so perhaps nobody has reported it
> upstream.

Hi,

I think this bus is #710888 [1] that is already fixed in master.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=710888

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Dimensions in pixels of a draw Area to obtain a plot on a A4 paper

[Nicola Fontana]

Il Sat, 21 Apr 2018 04:01:21 +0200 arkkimede  scrisse:

> HI!
> I've realized an App with GTK3 and the library CAIRO to plot results of
> measurements.
> I use the function "cairo_surface_write_to_png" to obtain a png file that I
> put on a paper of format A4 (with usual resolution of 300dpi) to generate
> reports.
> Consider also that preliminary plot are observed on a screen with
> resolution 1920x1080.
> 
> The question is:
> 
> Could you advice me dimensions in pixels of the draw area in order to
> obtain png file to plot on A4 paper and see (more or less) similar pictures
> on the screen
> (or different dimensions for the plot on png and dimensions for the plot on
> screen)?

Hi,

the PNG backend must not be used for serious applications. From
the doc [1]:

It is a toy API. It only offers very simple support for
reading and writing PNG files, which is sufficient for testing
and demonstration purposes.

So my advice is "use the PDF backend".

[1] https://cairographics.org/manual/cairo-PNG-Support.html

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: simple question

[Nicola Fontana]

Il Mon, 19 Feb 2018 09:24:20 +0100 Wojciech Puchar <w.puc...@digitalsystems.pl> 
scrisse:

> On 2018.02.19 08:09, Nicola Fontana wrote:
> > Il Sat, 17 Feb 2018 21:32:19 +0100 (CET) Wojciech Puchar 
> > <woj...@puchar.net> scrisse:
> > ...
> > If you want full control over something just use a canvas. Don't  
> can you please tell more about it? at least where to search.
> i am not gtk expert.

A canvas is a blank space where you can draw and interact freely.
For example, in an application I'm working on [1] I wanted to
present some data in a label format, so I inserted a canvas
widget in the middle of the UI.

In that particular example I used GooCanvas [2] but you are free
to use whatever you need: see [3] for a (non-exaustive) list.

[1] http://ntd.github.io/assets/tesbli-2.png
[2] https://wiki.gnome.org/action/show/Projects/GooCanvas
[3] https://wiki.gnome.org/Attic/ProjectRidley/CanvasOverview

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: simple question

[Nicola Fontana]

Il Sat, 17 Feb 2018 21:32:19 +0100 (CET) Wojciech Puchar  
scrisse:

> i want in my program to change background color of the gtk_button to red 
> sometimes as a signal to the user.
> 
> it works fine with default theme but not with some other themes like 
> E17gtk.
> 
> how to fix this and ENFORCE color of button?

Hi,

you can't. Some theme (e.g. the ones based on the pixmap engine)
can use images and totally ignore the background colors you set.
E17gtk seems to be pixmap based:

https://github.com/tsujan/E17gtk/blob/master/gtk-2.0/gtkrc#L99

You can disable the engine and style from scratch, but this will
quickly end up in creating a new theme.

If you want full control over something just use a canvas. Don't
try to bend the theme to do what they are not supposed to do, e.g.
change the background image to something "redish" because you set
a red background.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Jump from PyGTK to C GTK

[Nicola Fontana]

Il Tue, 7 Nov 2017 13:52:01 +0100 Nils Söderman  scrisse:

> Hello, i have been using glade to build a GUI, doing an app to fill the 
> entry-boxes with data. OK so far. But when i wanted to color the boxes 
> with help of PyGTK according to their content and did not succeed with 
> that i decided to start using c instead, where i have 20 years more 
> experience. But i fell on a simple detail, when in PyGTK i wanted a 
> pointer to an entrybox, using MyBox  = builder.get_object ( "MyBoxID" ) 
> and tried to find an equivalent in GTK c i was in no luck. So, how to 
> exchange MyBox  = builder.get_object ( "MyBoxID" ) to c-acceptable code? 
> ALL the example code i have found uses pointer derived with a variant of 
> 'new', not applicable using glade! PLEASE point me right!

Hi,

the translation is basically 1:1.

GtkEntry *MyBox = GTK_ENTRY(gtk_builder_get_object(builder, "MyBoxID"));

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Show dialog after hide another

[Nicola Fontana]

Il Wed, 6 Sep 2017 16:08:07 + Rúben Rodrigues  
scrisse:

> ...
> void on_button_Util_Firmware_Update_clicked(GtkButton *button, gpointer 
> user_data)
> {
>      GtkLabel    *gLabel_Result;
>      FILE        *fp;
>      gchar        pcTmp[BUFSIZ];
> 
>      // Fecha a janela.
> gtk_widget_hide(GTK_WIDGET(gtk_widget_get_toplevel(GTK_WIDGET(button;
> 
>      // Mostra a janela de espera.
>      gtk_widget_show(GTK_WIDGET(gtk_builder_get_object(builder, 
> "Setup_Wait_dialog")));
>      sleep(10);
> ...

Hi Rúben,

this is the normal behavior in a single-threaded application: the
user interface is updated only when you release the CPU so that
the execution returns to the main loop:

https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description

The rule of thumb is: never block, i.e. never put a `sleep(10)` or
something equivalent in your code otherwise you'll get what you
requested, in that case an unresponsive interface for 10 seconds.

If you have a heavy process, fork to a working thread or decompose
it in a loop that can be run incrementally with an idle callback.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: "click" event on a GtkSpinEntry

[Nicola Fontana]

Il Tue, 22 Aug 2017 15:10:44 -0400 cecas...@aol.com scrisse:
> ...
> There is a good read about the spin button at
> 
> https://blog.gtk.org/author/ebassi/
> 
> with Tim Bader on April 25, 2017. I don't know if you have seen that.

Hi Eric,

no, I did not see that... it would have saved me some reverse
engineering time.

> My first try was just to get the GdkWindow of the spin button
> but that gave me the main window. No help there.

Yes, that was my second attempt too. My first one was to check for
the presence of the spin callback. I was using
g_main_context_find_source_by_user_data() with the instance as
user_data but I soon discovered the argument of that callback is
wrapped by gdk_threads_add_timeout() [1] [2], so I gave up.

[1] https://git.gnome.org/browse/gtk+/tree/gtk/gtkspinbutton.c#n769
[2] https://git.gnome.org/browse/gtk+/tree/gdk/gdk.c?h=3.22.19#n929

> Noticed that
> the cursor changed with the mouse movement so I went with that.
> Probably even more hackish than your solution. 

That is really smart and dirty! Yes, the hackishness level is still
quite high.

Many thanks for the suggestions, really appreciated. It seems the
solution requires a macgyverism after all.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

"click" event on a GtkSpinEntry

[Nicola Fontana]

Hi all,

I want to catch a click/button-press event *only* on the entry
part of a GtkSpinButton. Put in other words I want to filter out
events happening on the up and down buttons of a spin entry.

I tried several strategies until actually finding a working
approach. The implementation though is too hackish for my taste:

#define WHEEL_MASK (GDK_BUTTON1_MOTION_MASK|GDK_BUTTON3_MOTION_MASK)

static gboolean
button_press_event_callback(GtkSpinButton *spin, GdkEventButton *event)
{
if ((gdk_window_get_events(event->window) & WHEEL_MASK) > 0) {
...
}
}

I found sperimentally that the event mask of the up and down
GdkWindows are different from the GdkWindow of the entry and I'm
leveraging this fact to filter out the unwanted events.

This anyway could be an implementation detail so this behavior can
potentially be changed in the future.

Is there a more reliable way to accomplish the same result?

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: undefined reference to gtk label set xalign

[Nicola Fontana]

Il Fri, 16 Jun 2017 08:58:41 + Rúben Rodrigues  
scrisse:

> Hi guys,
> 
> Someone could help with this? 
> https://stackoverflow.com/questions/44547398/undefined-reference-to-gtk-label-set-xalign

Hi,

you are linking against GTK+ 3.14.5 and gtk_label_set_xalign has
been introduced in 3.16.0.

How do you get the build command?

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Combobox focus event

[Nicola Fontana]

Il Fri, 7 Apr 2017 13:52:57 -0400 Eric Cashon via gtk-app-devel-list 
 scrisse:

> Thomas, 
> 
> Your original question looked easy. Connect the "focus-in-event" to the combo 
> box and everything will work fine.
> ...

Hi,

GtkComboBox is a GtkContainer, so I would try to connect the
callback to the set-focus-child signal instead:

https://developer.gnome.org/gtk3/stable/GtkContainer.html#GtkContainer-set-focus-child

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Input event reduction

[Nicola Fontana]

Il Thu, 30 Mar 2017 09:38:41 +0200 Stefan Salewski <m...@ssalewski.de> scrisse:

> On Wed, 2017-03-29 at 23:26 +0200, Nicola Fontana wrote:
> > 
> > 
> > idle functions do *not* run in the background so if you don't
> > release the CPU you will experience what you described.
> > 
> > AFAIK all the GMainLoop code is single-threaded hence, as a
> > consequence, you will block the UI whenever the CPU is busy
> > running your code, being it inside a signal handler, a timeout
> > function or (as in your case) an idle function.
> > 
> > Just avoid loops when you know they are expensive. Instead
> > leverage the cyclic nature of GMainLoop for iterating over your
> > code, i.e. by respawning your idle function as much as needed.
> >   
> 
> In that case it is really a bad idea to have a outer loop in that idle
> function :-(

As said you can leverage the main loop and unroll yours, e.g.:

gboolean my_idle_callback()
{
gint n;
for (n = 0; n < 100; ++n) {
...
}
return FALSE;
}

should become:

gboolean my_unrolled_idle_callback()
{
static gint n = 0;
...
++n;
return n < 100;
}

Depending on your use case, the above could or could not be
possible.

> So I have to go back to my initial idea -- create a thread which gets a
> message for each "changed" signal, and then calls an idle function only
> for the last message in the queue each. I have to use
> gdk_threads_add_idle() then.

This is probably the cleanest solution, although I don't
understand why you would have to use gdk_threads_add_idle().

> The task of that idle function in my current use case would be to get
> highlight syntax information from the IDE process called nimsuggest and
> then to apply the corresponding tags to gtksource textbuffer.

IMO it is essential to split your code in two parts: (1) gathering
the highlight information and (2) applying it to the textbuffer.

(1) can be run entirely in the working thread (hence non-blocking)
while (2) must be implemented as a callback to be run in the GTK+
thread. I cannot believe (2) takes tenths of second.

When you are ready from (1) you can spawn the idle callback with
g_source_attach()... no needs for gdk_threads_add_idle(). In the
following StackOverflow answer I provided an example in C:

http://stackoverflow.com/questions/27950493/safety-of-using-pthreads-in-gtk2-0-application#27990662

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Input event reduction

[Nicola Fontana]

Il Wed, 29 Mar 2017 21:27:48 +0200 Stefan Salewski  scrisse:

> ...
> 
> Problem is the idle function added with
> 
> https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#g-idle-add
> 
> I have the strong feeling, that the provided function is not running
> silently in the background, ...

Hi Stefan,

idle functions do *not* run in the background so if you don't
release the CPU you will experience what you described.

AFAIK all the GMainLoop code is single-threaded hence, as a
consequence, you will block the UI whenever the CPU is busy
running your code, being it inside a signal handler, a timeout
function or (as in your case) an idle function.

Just avoid loops when you know they are expensive. Instead
leverage the cyclic nature of GMainLoop for iterating over your
code, i.e. by respawning your idle function as much as needed.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Best practise inheritance

[Nicola Fontana]

Il Tue, 21 Mar 2017 17:55:31 + Tristan Van Berkom 
 scrisse:

> ...
>   o I believe the lookups with G_TYPE_INSTANCE_GET_PRIVATE() are just
>     as cheap as the pointer dereference (as it will be implemented
>     using simple pointer arithmetic).

Hi Tristan,

the lookup indeed is quite expensive, and looking at the
implementation [1] it is not that straightforward.

The very same example provided by the official documentation [2]
caches that pointer into the instance struct.

[1] https://git.gnome.org/browse/glib/tree/gobject/gtype.c#n4709
[2] 
https://developer.gnome.org/gobject/stable/gobject-Type-Information.html#g-type-class-add-private

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cross platform developmentG

[Nicola Fontana]

Il Mon, 20 Mar 2017 03:30:54 +0100 Dirk Gottschalk via gtk-app-devel-list 
 scrisse:

> ...
> I'll take a look at this. The question was which DLLs are nedded.

Hi,

in my cross-compiled installer script [1] I've the following list:

  File "${DLLDIR}/libwinpthread-*.dll"
  File "${DLLDIR}/libgcc_*-*.dll"
  File "${DLLDIR}/zlib1.dll"
  File "${DLLDIR}/libbz2-*.dll"
  File "${DLLDIR}/libexpat-*.dll"
  File "${DLLDIR}/libintl-*.dll"
  File "${DLLDIR}/iconv.dll"
  File "${DLLDIR}/libffi-*.dll"
  File "${DLLDIR}/libpng*-*.dll"
  File "${DLLDIR}/libglib-2.0-*.dll"
  File "${DLLDIR}/libgthread-2.0-*.dll"
  File "${DLLDIR}/libgmodule-2.0-*.dll"
  File "${DLLDIR}/libgobject-2.0-*.dll"
  File "${DLLDIR}/libgio-2.0-*.dll"
  File "${DLLDIR}/libfreetype-*.dll"
  File "${DLLDIR}/libpixman-1-*.dll"
  File "${DLLDIR}/libcairo-*.dll"
  File "${DLLDIR}/libcairo-gobject-*.dll"
  File "${DLLDIR}/libpango-1.0-*.dll"
  File "${DLLDIR}/libpangocairo-1.0-*.dll"
  File "${DLLDIR}/libpangowin32-1.0-*.dll"
  File "${DLLDIR}/libatk-1.0-*.dll"
  File "${DLLDIR}/libgdk_pixbuf-2.0-*.dll"
  File "${DLLDIR}/libgdk-3-*.dll"
  File "${DLLDIR}/libgtk-3-*.dll"

A couple of things are deliberately missing, most notably SVG and
tiff support. Furthermore, this list is based on my own mingw
toolchain for archlinux [2], that in turn is based on the fedora
one [3], so some detail could be different.

[1] https://github.com/ntd/adg/blob/master/build/adg.nsi
[2] https://github.com/ntd/aur-fedora-mingw
[3] https://fedoraproject.org/wiki/Features/Mingw-w64_cross_compiler

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Accessors vs Properties

[Nicola Fontana]

Hi,

Il Tue, 3 Jan 2017 22:46:13 +0100 Tobias Knopp  scrisse:

> ...
> - Is any accessor backuped with a property and vice versa?

Only the second part stands, i.e. any property should have its
own accessors. There is some exception though, e.g.
GtkContainer:child, but that is a special property anyway (it is
write-only).

> - Which one is to prefer?

They are equivalent. Sometime you can encounter missing accessors,
so I'd use g_object_{set,get}_property(), more so if you plan
to do some automatic processing (e.g. writing binding code).

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Accessors vs Properties

[Nicola Fontana]

Il Thu, 05 Jan 2017 07:27:10 + Gergely Polonkai  
scrisse:

> Hello,
> 
> I don't know about others, but in my own code, my_obj_set_property() does
> nothing else just calls the setter functions (and the same for getters). It
> makes much more sense, and I saw it in a lot of Gtk and Gnome code, too.

Hi,

at least in GTK+ it is the other way, i.e. the setters call
gtk_*_set_*():

https://git.gnome.org/browse/gtk+/tree/gtk/gtkwidget.c?h=3.22.6#n3684

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: The Big Gtk limitations: a reliable GUI builder

[Nicola Fontana]

Il Wed, 30 Nov 2016 14:35:59 +0100 Pozz Pozz <pozzu...@gmail.com> scrisse:

> 2016-11-30 9:09 GMT+01:00 Nicola Fontana <n...@entidi.it>:
> 
> > ...
> > If your workflow heavily rely on a GUI
> > builder, you have 4 options: (1) use glade as is, (2) prepare to
> > file bugs and wait for the fixes, (3) fix the bugs yourself or (4)
> > switch to another GUI. You can also push to speed up (2)... but
> > you are already doing it.
> >  
> 
> I'm interested in (3)... I'm not a guru, but I'm able to write some code
> and fix simple bugs. However building current version of Glade under
> Windows it's a difficult task for me. The configure script complained with
> the GTK_DEBUG_CHECK (or something similar) present in the configure.ac.

In this case I'd directly try to contact the glade maintainers,
asking for advices:

https://git.gnome.org/browse/glade/tree/MAINTAINERS

Maybe they are more active on a specific IRC channel rather than
on mailing list.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: The Big Gtk limitations: a reliable GUI builder

[Nicola Fontana]

Il Wed, 30 Nov 2016 11:08:13 +1100 Daniel Kasak  
scrisse:

> ...
> My normal workflow is to lay things out *roughly* in glade, then
> actually run the app and see what it looks like.
> ...

This is my workflow too, apart the fact that after the first draft
I prefer to edit the XML files directly.

I always had problems with glade on Linux (also with glade 2
and/or with GTK+2) but I never submitted bugs because I'm not
really that interested. If your workflow heavily rely on a GUI
builder, you have 4 options: (1) use glade as is, (2) prepare to
file bugs and wait for the fixes, (3) fix the bugs yourself or (4)
switch to another GUI. You can also push to speed up (2)... but
you are already doing it.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: SpinButton: how to avoid calling signal handler when set_value()

[Nicola Fontana]

Il Wed, 2 Nov 2016 14:40:58 +0100 Pozz Pozz <pozzu...@gmail.com> scrisse:

> 2016-11-02 11:24 GMT+01:00 Nicola Fontana <n...@entidi.it>:
> > ...
> >
> > you don't necessarily need the handler id. In C (I don't use
> > python) you could write the following:
> >
> > void my_set_value(GtkSpinButton *spin_button, gdouble value)
> > {
> > g_signal_handlers_block_matched(spin_button,
> > G_SIGNAL_MATCH_FUNC,
> > 0, 0, NULL,
> > callback_to_skip,
> > NULL);
> >
> > /* This will not trigger callback_to_skip */
> > gtk_spin_button_set_value(spin_button, value)
> >
> > g_signal_handlers_unblock_matched(spin_button,
> >   G_SIGNAL_MATCH_FUNC,
> >   0, 0, NULL,
> >   callback_to_skip,
> >   NULL);
> > }
> >  
> 
> I got the idea. I don't know if g_signal_handlers_block_matched() or
> similar functionality is available in Python. However, remaining in C, your
> code make the assumption there is a single callback function for all the
> spinbuttons. This is not true: I have a different handler for each
> spinbutton, because I have to make different things.

Sorry but I am a developer, not a mind reader.

You can match by data or try to lookup the callback by detail with
g_signal_handler_find or refactor your code to use a single
callback. The fact that you are using different callbacks has a
foul smell indeed.

Come on, a little bit of initiative. Here, today only, the link to
the official (C) documentation:

https://developer.gnome.org/gobject/stable/gobject-Signals.html

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: SpinButton: how to avoid calling signal handler when set_value()

[Nicola Fontana]

Il Wed, 2 Nov 2016 10:23:44 +0100 Pozz Pozz  scrisse:
> ...
> How do you implement the generic function _my_set_value()? It should have
> two parameters: spinbutton and value. signal_handler_block() function needs
> the handler_id associated that I don't have.
> Maybe during initialization, when I connected the handlers, I could create
> a data structure (a list) with spinbuttons and associated handler_id. In
> this way, _my_set_value() could accept the item of the list and could
> recover the handler_id to block.
> 
> However there is another problem with this approach. I'm using Glade and I
> connect *all* the handlers with a single instruction:
> builder.connect_signals(). So I don't have the handler IDs.
> ...

Hi,

you don't necessarily need the handler id. In C (I don't use
python) you could write the following:

void my_set_value(GtkSpinButton *spin_button, gdouble value)
{
g_signal_handlers_block_matched(spin_button,
G_SIGNAL_MATCH_FUNC,
0, 0, NULL,
callback_to_skip,
NULL);

/* This will not trigger callback_to_skip */
gtk_spin_button_set_value(spin_button, value)

g_signal_handlers_unblock_matched(spin_button,
  G_SIGNAL_MATCH_FUNC,
  0, 0, NULL,
  callback_to_skip,
  NULL);
}

Not tested, but should give you the idea.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: SpinButton: how to avoid calling signal handler when set_value()

[Nicola Fontana]

Il Wed, 2 Nov 2016 00:09:29 +0100 pozzugno  scrisse:

> ...
> A simple and clear sequence of instructions:
> 
>_set_value()
>_set_value()
>..
> 
> will be transformed in a complex, long and cryptic sequence of 
> instructions:
> 
>_block()
>_set_value()
>_unblock()
>_block()
>_set_value()
>_unblock()

Hi,

I hope you are missing some fundamental detail because this is a
non-problem.

_my_set_value()
_block()
_set_value()
_unblock

_my_set_value()
_my_set_value()

> I hoped there was another better solution. Actually I'm using a flag 
> that is checked in the handler:
> 
>refreshing = True
>_set_value()
>_set_value()
>...
>refreshing = False

This is not equivalent to what you wrote above. This is (roughly)
equivalent to:

_block()
_set_value()
_set_value()
...
_unblock()

A minimal test case exposing the problem would be much clearer.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Adding and removing widgets at runtime

[Nicola Fontana]

Il Mon, 12 Sep 2016 13:37:04 -0300 "Daniel."  scrisse:

> Well, if I wasn't clear before my layout is totally questionable. I
> more generic question would be:
> 
> How you guys aproaches when the problem is showing applications
> behavior on screen?

Hi,

I don't see any problem in your approach. The only issue you can
meet is the UI *must* be updated from the main GTK+ thread.

I wrote an example that shows how this can be accomplished by
using a GSource-based solution:

http://stackoverflow.com/a/27990662

though any other valid synchronization solution (e.g. using a
GAsyncQueue and a listener) would work.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: argv revisited

[Nicola Fontana]

Il Mon, 9 May 2016 09:35:06 -0500 Edscott Wilson 
 scrisse:

> ...
> Many thanks to all those who have responded. With all the advice I'm now
> going to try cross compiling 64 bit GTK application for windows using all
> the tools available in ArchLinux and the AUR (which is quite a lot). Only
> if that fails I'll go back to Msys-Mingw64.

If you are using Archlinux you can also try my toolchain [1]. I am
maintaining it in sync with the fedora one. I've even been able to
cross compile gobject-introspection so the whole toolchain is
built with introspection enabled, although honestly I did not test
it that much.

[1] https://github.com/ntd/aur-fedora-mingw

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Simple glib compilation problem: DSO missing from command line

[Nicola Fontana]

Il Fri, 27 Mar 2015 11:31:59 +0100 Bruno Cauet brunoca...@gmail.com scrisse:

 Hi,
 I'm having trouble compiling stuff with glib. Here it is:
 $ LANG=C gcc -I /usr/include/glib-2.0  -I /usr/lib/glib-2.0/include -L
 /usr/lib -l gio-2.0 segfault.c
 /usr/bin/ld: /usr/lib/libgio-2.0.so: undefined reference to symbol
 'g_object_unref'
 /usr/lib/libgobject-2.0.so.0: error adding symbols: DSO missing from
 command line
 collect2: error: ld returned 1 exit status

Hi,

you are missing a couple of libraries from the command-line and the
order is wrong. To be on the safe side just use pkg-config:

$ LANG=C gcc $(pkg-config --cflags gio-2.0) segfault.c $(pkg-config --libs 
gio-2.0)

 You will find gio.c attached. There's related problems with solution on the
 internet but those solutions were related to the library inclusion order,
 and I cannot adapt it to my case (single library in which the symbol is
 also defined).

Nothing attached here.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re:

[Nicola Fontana]

Il Fri, 06 Feb 2015 16:24:39 -0600 zeta kmsi...@gmail.com scrisse:

 I am new on the community, I am a bachelor student at BUAP, I love gome
 since I meet it, and know I want to contribute in something, I was
 writing an application with gtk and when I want to create some cool
 charts I see that there isn't a library for do it, or I don't find one

Hi,

there are some libraries with naviv GTK+ support indeed, the most
relevant ones being goffice [1] and gtkextra [2].

Five years ago I gave an answer on StackOverflow [3] and AFAIK the
situation has not changed that much.

[1] https://git.gnome.org/browse/goffice
[2] http://gtkextra.sourceforge.net/
[3] http://stackoverflow.com/a/2631361

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Best practice query: Entry field user's done editing handling?

[Nicola Fontana]

Il Mon, 23 Dec 2013 22:19:28 -0800 A. Walton awal...@gnome.org scrisse:

 Frankly I don't see what's wrong with making it instant apply from the
 description. Connect to the GtkEditable::changed signal, throw in a short
 timeout that gets reset any time someone changes the field. If they have
 stopped changing the field for more than some amount of time, say half a
 second, then commit the change - do whatever you have to do with it
 (validate it, send it to a server, write it to a file, etc.)

This is an excerpt directly taken from the doc you are pointing out:

Do not attempt to validate or apply changes caused by editing a text
field control until the user has moved focus to a different control in
the window, or the window is closed. Validating after each keypress is
usually annoying and unnecessary. 

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: widget to represent dial/speedometer kind of object

[Nicola Fontana]

Il Tue, 10 Dec 2013 17:30:42 +0800 (SGT) Mahesh Chaudhari 
mahesh.chaudh...@ymail.com scrisse:

 Hi list ,
 
 is there any widget available to represent meter/dial/speedometer kind of 
 object, needle of which rotates dynamically with magnitude of input values 
 
 
 one widget i found is Gtkdial , but it has support from gtk+-2.18 onwards and 
 i am having gtk+-2.10.0 

Hi,

if you find GtkDial fulfils your needs the obvious answer is update
your GTK+. I did not see any apparent reason preventing it.

Other gauge alternatives include GIW [1], phat [2], TzClock [3] and
tgauge [4]. I've personally used none of them.

Ciao.
-- 
Nicola

[1] https://sourceforge.net/projects/giw/
[2] http://phat.berlios.de/
[3] http://www.theknight.co.uk/
[4] http://tgauge.sourceforge.net/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Output Widgets

[Nicola Fontana]

Il Mon, 7 Oct 2013 20:19:36 +0800 (SGT) Mahesh Chaudhari 
mahesh.chaudh...@ymail.com scrisse:

 Output widget in the sense , user is informed (e.g. by changing widget's 
 color) about some system events not user provides input (e.g button press, 
 mouse clicks)
 in short I wanted to represent an LED which should change color according to 
 some condition  

If you are looking for some sort of instrumentation widgets the closest
thing I'm aware of is GIW [0]. You could find some other somewhat
related project around [1] [2] but I did not meet any serious effort.

On the opposite, if you use (or can use) Ada you will have much more
luck [3].

Ciao.
-- 
Nicola

[0] http://sourceforge.net/projects/giw/
[1] http://phat.berlios.de/
[2] http://tgauge.sourceforge.net/
[3] http://www.dmitry-kazakov.de/ada/aicwl.htm
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Updating GUI during long operation

[Nicola Fontana]

Il Fri, 26 Apr 2013 02:24:01 -0700 Kip Warner k...@thevertigo.com scrisse:

 On Thu, 2013-04-25 at 22:18 -0700, Simon Feltman wrote:

  Similarly, use
  Gdk.threads_add_idle instead of GObject.idle_add for scheduling GUI updates
  from worker threads. The necessity of these is still somewhat unclear to me
  at the moment though.
 
 I'll give that a try. I'm not sure what the difference is either, but
 the link above seems to recommend it too so it can't hurt to try.

gdk_threads_add_idle() is only a convenient way of calling g_idle_add()
without the need of decorating the callback code with a
gdk_threads_enter()/gdk_threads_leave() pair:

http://developer.gnome.org/gdk/stable/gdk-Threads.html#gdk-threads-add-idle-full

The code of the dispatcher can be found here:
http://git.gnome.org/browse/gtk+/tree/gdk/gdk.c?id=3.8.1#n779

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Cross-compilation of glib2 on win32/win64: glibconfig.h

[Nicola Fontana]

Il Sat, 13 Oct 2012 19:47:32 +0200 Nicola Fontana n...@entidi.it
scrisse:

 Hi all,
 
 I'm cross-compiling the GTK+ toolchain with mingw-w64 to win32
 and win64 platforms. Cairo fails in the cairo-gobject component
 in win64 mode and I strongly *suspect* this is due to a wrong
 glibconfig.h

It was my mistake: I forgot to add the proper --host triplet when
calling configure. With that option set properly, a suitable
glibconfig.h (different between win32 and win64 platforms) is
generated.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Cross-compilation of glib2 on win32/win64: glibconfig.h

[Nicola Fontana]

Hi all,

I'm cross-compiling the GTK+ toolchain with mingw-w64 to win32
and win64 platforms. Cairo fails in the cairo-gobject component
in win64 mode and I strongly *suspect* this is due to a wrong
glibconfig.h (infact it is the same as the one installed for
win32, and I think this cannot be possible). This is the trimmed
down failing code:

#include glib-object.h

int main()
{
   static volatile gsize value = 0;
   g_once_init_enter((volatile void *) value);
   return 0;
}

It fails at compilation stage with:

test.c: In function 'main':
test.c:6:1: error: size of array '_GStaticAssertCompileTimeAssertion_0' is 
negative
test.c:6:4: error: invalid use of void expression
test.c:6:1: error: size of array '_GStaticAssertCompileTimeAssertion_1' is 
negative
test.c:6:4: warning: dereferencing 'void *' pointer [enabled by default]
test.c:6:4: error: invalid use of void expression

Now the questions: how do you deal with glibconfig.h in cross
compilation? Is there a sample glibconfig.h suitable for win64 or
the only idea is an abomination?

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkFileChooserButton::file-set

[Nicola Fontana]

Il Thu, 4 Oct 2012 02:00:39 +0200 Rafał Mużyło
galtge...@gmail.com scrisse:

 On Thu, Oct 04, 2012 at 12:33:24AM +0200, Nicola Fontana wrote:
  Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło
  galtge...@gmail.com scrisse:
  
   but the change on cancel was
   recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not 
   in 2.24 though, even if it seems to be only a matter of a cherry-pick).
  
  What I mean is pressing ESC or clicking cancel unset the file name
  and I didn't find a way to catch it: this is not the same issue.
  
  I'm using gtk 3.4.4 but I don't think it is relevant.
 
 It's in fact not only the *very same* problem, but also while it *was*
 fixed on 3.4 branch, there was no release there yet containing this
 commit from this branch - it's post 3.4.4.

I'm interested in the notification not in the fact it is unset:
this hardly makes them *very same*.

Anyway thanks for pointing out it is unwanted behavior: I'll wait
for the fix.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GtkFileChooserButton::file-set

[Nicola Fontana]

I need to catch when the file has changed in a
GtkFileChooserButton. I thought connecting to file-set was
enough but this signal is not emitted when the user cancels
(although bug 555351 does not agree [1]). Here is the proof:


#include gtk/gtk.h

int main(int argc, char **argv)
{
GtkWidget *window, *chooser;

gtk_init(argc, argv);

window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
chooser = gtk_file_chooser_button_new(NULL,
  GTK_FILE_CHOOSER_ACTION_OPEN);
gtk_container_add(GTK_CONTAINER(window), chooser);

g_signal_connect_swapped(chooser, file-set,
 G_CALLBACK(g_print), file-set\n);

gtk_widget_show_all(window);
gtk_main();

return 0;
}


What am I supposed to do? I can provide my custom dialog to
GtkFileChooserButton but checking when the file has changed in a
file chooser seems a too natural request for requiring such
effort.

Ciao.
-- 
Nicola

[1] https://bugzilla.gnome.org/show_bug.cgi?id=555351
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkFileChooserButton::file-set

[Nicola Fontana]

Il Wed, 3 Oct 2012 23:28:23 +0200 Rafał Mużyło
galtge...@gmail.com scrisse:

 On Wed, Oct 03, 2012 at 10:23:12PM +0200, Nicola Fontana wrote:
  I need to catch when the file has changed in a
  GtkFileChooserButton. I thought connecting to file-set was
  enough but this signal is not emitted when the user cancels
  (although bug 555351 does not agree [1]). Here is the proof:
  
  
  #include gtk/gtk.h
  
  int main(int argc, char **argv)
  {
  GtkWidget *window, *chooser;
  
  gtk_init(argc, argv);
  
  window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  chooser = gtk_file_chooser_button_new(NULL,
GTK_FILE_CHOOSER_ACTION_OPEN);
  gtk_container_add(GTK_CONTAINER(window), chooser);
  
  g_signal_connect_swapped(chooser, file-set,
   G_CALLBACK(g_print), file-set\n);
  
  gtk_widget_show_all(window);
  gtk_main();
  
  return 0;
  }
  
  
  What am I supposed to do? I can provide my custom dialog to
  GtkFileChooserButton but checking when the file has changed in a
  file chooser seems a too natural request for requiring such
  effort.
 
 Well, I'm not 100% sure what you mean (and that callback of yours
 looks like it's only working by chance)

No, this is valid GTK+ code.

 but the change on cancel was
 recently fixed in bug . in regard of gtk 3.4 and 3.6 (unfortunately, not in 
 2.24 though, even if it seems to be only a matter of a cherry-pick).

What I mean is pressing ESC or clicking cancel unset the file name
and I didn't find a way to catch it: this is not the same issue.

I'm using gtk 3.4.4 but I don't think it is relevant.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtkrbtree core dump

[Nicola Fontana]

Il Sun, 30 Sep 2012 06:37:12 -1000 (HST) Roger Davis
r...@soest.hawaii.edu scrisse:

 Has anyone else ever seen this (I found only a couple not especially 
 helpful references on the web), and/or does anyone know what is calling 
 _gtk_rbtree_insert_after()? It isn't me, at least not directly, and I can 
 find no reference to it in the GTK+3 docs. What kind of programming error 
 on my part might lead to such an outcome?

You did not (and will not) find any documentation on
_gtk_rbtree_insert_after() because it is a private exported
function. AFAIK GtkRBTree (hence _gtk_rbtree_insert_after) is
used extensively by GtkTreeView, so I'd look at my code using it.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtkrbtree core dump

[Nicola Fontana]

Il Sun, 30 Sep 2012 08:48:20 -1000 (HST) Roger Davis
r...@soest.hawaii.edu scrisse:

 I was wondering about that, but unfortunately my code does not explicitly 
 use any GtkTree* objects! Is there any way to search the documentation 
 efficiently to determine which object types are inheriting from 
 GtkTreeView? I have begun searching on my objects one by one (e.g., 
 GtkMenu, etc.), but I am not finding any that appear to inherit from 
 GtkTree*. Of course my app uses dozens of different object types and it 
 will be quite a chore to exhaustively search the documentation of each one 
 to examine its object hierarchy graph. I suspect that in the end I will 
 come up empty, as I have already looked at the objects I am using which, 
 by their appearance, look the most related to a GtkTreeView, e.g., menus, 
 file chooser dialogs, etc.

There are much more to explore. The most effective way I found to
approach this kind of issues is grepping inside the source tree:

$ grep -rl gtk_tree_view *.c
gtkappchooserwidget.c gtkcellarea.c
gtkcellrendererspinner.c
gtkcombobox.c
gtkcustompaperunixdialog.c
gtkentry.c
gtkentrycompletion.c
gtkfilechooserdefault.c
gtkfontsel.c
gtkmountoperation.c
gtkprintunixdialog.c
gtkrecentchooserdefault.c
gtktooltip.c
gtktreednd.c
gtktreeselection.c
gtktreeview.c
gtktreeviewcolumn.c

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Not understanding the g_type_from_name() behaviour

[Nicola Fontana]

Il giorno Sun, 13 May 2012 10:37:16 +0200
Marc Balmer m...@msys.ch ha scritto:

 I have a (hopefully) basic question.  g_type_from_name() does not behave
 as I would it expect to behave:
 
 When I call it with e.g. GtkButton, I get GTK_TYPE_BUTTON.  But when I
 call it with GtkFrame, it returns 0 (no such type found).
 
 To add to my confusion, when I call printf(%s\n,
 g_type_name(GTK_TYPE_FRAME) before calling g_type_from_name(), it
 returns GtkFrame (as expected) and the following call to
 g_type_from_name() succeeds as well.
 
 I am obviously missing sth here, or making a stupid mistake, so any
 pointers would be greatly appreciated.

GTK_TYPE_... macros are really a shorthand for gtk_..._get_type() calls
that register that given type. If you don't register the type,
g_type_from_name() should not return it (and in fact your snippet
returns to me that neither GtkButton or GtkFrame are defined).

If g_type_from_name(GtkButton) is non 0, you have GTK_TYPE_BUTTON or
something equivalent before it.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GtkCellRendererState comparison

[Nicola Fontana]

Il giorno Fri, 20 Apr 2012 09:53:33 +0430
Bijan Binaee bijanb...@gmail.com ha scritto:

 hi
 
 once i compile my code i got following a warning how can I fix it?
 
 gtksourcefoldcellrenderer.c:331:14: warning: comparison between
 'GtkCellRendererState' and 'enum anonymous' [-Wenum-compare]
 
 here is the code:
 if (state == GTK_STATE_PRELIGHT)

You are comparing GtkCellRendererState to GtkStateType. Try to use
GTK_CELL_RENDERER_PRELIT instead.

Ciao.
-- 
Nicola

 also the full source is
 here:http://paste.kde.org/460382/http://paste.kde.org/460376/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: memory lead while using Glib regexp

[Nicola Fontana]

Il giorno Fri, 2 Mar 2012 11:00:46 +0800 (CST)
Xi Yang jianding...@163.com ha scritto:

 Hi, everyone!
 
 
 I use Glib's regular expression in a cycle, and find a rapid memory 
 consumption increase. Did I forget to release anything?
 
 
 Thanks a lot!

A working example would be better. Anyway, citing the g_regex_match()
doc:

Note that if match_info is not NULL then it is created even if the
function returns FALSE, i.e. you must free it regardless if regular
expression actually matched.

 ...
 // match and fetch something
 if ( g_regex_match(regex_illumina, seq.header.c_str(), 
 GRegexMatchFlags(0), what) ) {
 tile_str = g_match_info_fetch(what,3);
 }
 else if ( g_regex_match(regex_casava_1p8, seq.header.c_str(), 
 GRegexMatchFlags(0), what) ) {
 tile_str = g_match_info_fetch(what,5);
 }
 ...

If your first g_regex_match() fails you have a sharp leak.

Ciao.
-- 
Nicola

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: [Win32] Hidden window cannot be shown more than once

[Nicola Fontana]

Il giorno Fri, 17 Jun 2011 11:56:12 -0500
Michael Cronenworth m...@cchtml.com ha scritto:

 Michael Cronenworth on 06/17/2011 11:46 AM wrote:
 My callbacks were of return type void. Changing them to gboolean and 
 returning TRUE makes the window appear upon the second call. It seems in 
 Win32 the default is to continue the signal callbacks, which destroys 
 the window.

AFAICT there is no such difference between platforms: the documentation
explicitely requires a gboolean [1]. I think your program was working on
Linux only because of a coincidence or something else outside of the
GTK+ scope.

Ciao.
-- 
Nicola

[1] http://developer.gnome.org/gtk/stable/GtkWidget.html#GtkWidget-delete-event
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: [Win32] Hidden window cannot be shown more than once

[Nicola Fontana]

Il giorno Fri, 17 Jun 2011 13:09:07 -0500
Michael Cronenworth m...@cchtml.com ha scritto:

 Nicola Fontana on 06/17/2011 12:29 PM wrote:
  AFAICT there is no such difference between platforms: the documentation
  explicitely requires a gboolean [1]. I think your program was working on
  Linux only because of a coincidence or something else outside of the
  GTK+ scope.
 
 This could be attributed to my bad experience with GTK examples showing 
 void return types in callbacks.

You have both. Basically in case of events you have to return a
gboolean [1] but for other signals the callback should usually be
void. Just check the signature of every callback in the docs to
be sure.

Ciao.
-- 
Nicola

[1] http://developer.gnome.org/gtk-tutorial/2.90/x182.html
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: How to get a widget from its parent of parent(...) by name?

[Nicola Fontana]

Il giorno Wed, 9 Jun 2010 14:54:07 +0200
Tadej Borovšak tadeb...@gmail.com ha scritto:

 Hello.
 
  Thank you, I'm sorry for that I didn't explain the problem clearer. What I
  meant is that there is no similar function of
  'glade_get_widget_tree(widget)'. At the context where should call
  gtk_builder_get_object(), there is no 'GtkBuilder* builder' available. In
  the previous code, we can call 'glade_get_widget_tree(widget)' to get the
  GladeXml object of the given 'widget'. However, I don't know how to do it in
  GtkBuilder?
 
  If I can get the GtkBuilder object from 'assistant', then I can call
  gtk_builder_get_object() to get the widget by its id. If I cannot get it,
  then how to get the widget by id from the top level widget? Thanks.
 
 I'm afraid that there is no equivalent for that in GtkBuilder (objects
 that are constructed by builder don't carry any information about who
 constructed them). You'll need to pass your builder object around
 manually (g_object_set_data() would be one option, global variable
 second, struct that is passed to all of the functions would be third,
 ...).

I'd like to suggest another alternative, that is programmatically
traverse the widget tree. The following untested snippet just to
give the idea:

GtkWidget *
gtk_widget_lookup(GtkWidget *top_level, const gchar *name)
{
GtkWidget *widget = NULL;

if (strcmp(name, gtk_widget_get_name(top_level) == 0) {
widget = top_level;
} else if (GTK_IS_CONTAINER(top_level)) {
GList *children = gtk_container_get_children(top_level);
while (children) {
if (widget == NULL)
widget = lookup_widget(children-data, name);
children = g_list_delete_link(children, children);
}
}

return widget;
}

-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Default values for spin buttons in Glade

[Nicola Fontana]

Il giorno Sat, 24 Apr 2010 06:26:03 +
dfg dfg abx...@msn.com ha scritto:

 Can someone tell me how to set up a default value for a spin button in Glade?

The adjustment generated by glade has the following properties:

property name=value.../property
property name=lower.../property
property name=upper.../property

I manually moved the value property *after* the limits and the
default values started to work. This has the huge drawback you
cannot use glade3 anymore.

By using GtkAdjustment you'll probably meet also the issue
#575714 [0], present in old versions of GtkBuilder such as
the one shipped with gtk-2.16.6 (the windows stable gtk).

Ciao.
-- 
Nicola

[0] http://bugzilla.gnome.org/show_bug.cgi?id=575714
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Question about modal dialog in gtk application

[Nicola Fontana]

Il giorno Wed, 14 Apr 2010 14:27:21 -0700
silverburgh silverburgh.me...@gmail.com ha scritto:

 Can you please help me what happens if I use 'gtk_set_transient_for to
 mark it modal to only one window' under the hood.
 
 Normally (as far as what I know), there is 1 gtk main thread listen
 for all ui events (mouse click, resize etc). And when a moral dialog
 is poped up, that main ui tread is blocked until user clicks OK or
 Cancel (hence the window is frozen).
 
 But for the case of 'gtk_set_transient_for ', how will that work? how
 can 1 window is interactive when the Main UI thread is blocked by a
 moral dialog in the 2nd window? (like the case in Firefox).

A modal window freezes the other windows, period. This is what
modal means and what gtk_dialog_run() is supposed to do. This
has nothing to do with the stack order of the windows, although
it is common practice to keep the modal window above the stack.

gtk_window_set_transient_for() sends a hint to the window
manager, asking to keep one window above another, and can be done
either for modal and non-modal windows. So with gtk_widget_show()
and gtk_window_set_transient_for() you get a *non-modal* window
that stays on top of the parent window.

-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: g_test_trap_fork() fails on g_return_...

[Nicola Fontana]

Il giorno Mon, 8 Feb 2010 23:17:52 +0100
Nicola Fontana n...@entidi.it ha scritto:

 #include glib.h
 #include stdlib.h
 
 static void dummy(void)
 {
 g_return_if_reached();
 }
 
 static void
 test_trap_fork(void)
 {
 if (g_test_trap_fork(0, G_TEST_TRAP_SILENCE_STDERR)) {
 dummy();
 exit(0);
 }
 g_test_trap_assert_passed();
 }
 
 
 int
 main(int argc, char *argv[])
 {
 g_test_init(argc, argv, NULL);
 
 g_test_add_func(/trap_fork test, test_trap_fork);
 
 return g_test_run();
 }
 
 
 The above test fails (glib-2.22.4), no way to succesful returns after
 a g_return_...() macro is encountered.

Answering to myself: g_test_init() always makes warnings and criticals
fatal [1]. A proper way to change this behaviour would be to use
g_test_log_set_fatal_handler() to install a new handler that ignores
log messages coming from the library domain: this works fine but pull
in a glib-2.22 dependency.

I ended up using g_log_set_always_fatal(0) instead, forcibly
disabling any fatal flag (apart g_error() ones, fatal by design).

-- 
Nicola


[1] http://git.gnome.org/browse/glib/tree/glib/gtestutils.c#n489
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

g_test_trap_fork() fails on g_return_...

[Nicola Fontana]

Hi all,

I'd like to sanitize my library by passing invalid values to GObject
properties. I built a test case with g_test_trap_fork() to trap
eventual segmentation faults, so far without success. I tracked down
the problem to this case:


#include glib.h
#include stdlib.h

static void dummy(void)
{
g_return_if_reached();
}

static void
test_trap_fork(void)
{
if (g_test_trap_fork(0, G_TEST_TRAP_SILENCE_STDERR)) {
dummy();
exit(0);
}
g_test_trap_assert_passed();
}


int
main(int argc, char *argv[])
{
g_test_init(argc, argv, NULL);

g_test_add_func(/trap_fork test, test_trap_fork);

return g_test_run();
}


The above test fails (glib-2.22.4), no way to succesful returns after
a g_return_...() macro is encountered.

Any idea?

Thank you.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Should gtk_widget_draw be un-depreicated?

[Nicola Fontana]

Il giorno Fri, 04 Dec 2009 15:01:25 -0600
Harry Coin hc...@quietfountain.com ha scritto:

 The only answer I can think of to retain the ability to time most 
 accurately, starting the moment that the image has been drawn is to
 use gtk_widget_draw right after setting the pixbuf.

If gtk_widget_draw() is working for you, why don't you pasteadapt its
code in your application? The implementation is quite trivial:

http://git.gnome.org/cgit/gtk+/tree/gtk/gtkwidget.c#n3811

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Crash processing g_object_new arguments

[Nicola Fontana]

Il giorno Mon, 09 Nov 2009 03:24:04 -0500
Braden McDaniel bra...@endoframe.com ha scritto:

 Clearly the Address ... out of bounds looks fishy; but I'm just
 not seeing what could be a problem there; and I'm wondering if gdb
 isn't just messing with me.  The call site for
 openvrml_xembed_browser_new looks like this:
 
 OpenvrmlXembedBrowser * const browser =
 OPENVRML_XEMBED_BROWSER(
 g_object_new(OPENVRML_XEMBED_TYPE_BROWSER,
  control-host-proxy, host_proxy,
  control-host-name, host_name,
  dbus-thread-context,
 dbus_thread_context, expect-initial-stream, expect_initial_stream,
  0));

Change 0 to NULL: on 64 bit platforms 0 != NULL, hence the property list
is not terminated.

Ciao.
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: trauma spliting source into multiple files and applying autotools

[Nicola Fontana]

Il giorno Wed, 22 Jul 2009 17:20:06 +1000
Mick mickh...@bigpond.net.au ha scritto:

 src/Makefile.am
 --
 bin_PROGRAMS = nuchimp
 
 nuchimp_SOURCES = \
   callback.c callback.h \
   main.c main.h 
 
 AM_CPPFLAGS = $(GTK_CFLAGS)
 AM_LDFLAGS = $(GTK_CFLAGS)

You should use:

AM_LDFLAGS = $(GTK_LIBS)

Ciao
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: An 'oldie' question... GtkCList anyone?

[Nicola Fontana]

On Tue, 27 Jan 2009 12:38:09 -0200
John Coppens j...@jcoppens.com wrote:

 char *bff, str[4];
 
 bff = strdup(abc|def|ghi|etc); Just to show bff has to freed later
 splitline(bff, str);  This puts pointers into str to each of
   the substrings (at the start and
   after each |, converting them to \0 ) 
 gtk_clist_append(clist, str); Add the line,
 g_free(bff);

Hi John,

first of all I warmly suggest you to update your code to
GtkTreeView. GtkCList is not maintained since ages: you'll
surely meet bigger problem than this and you'll be alone.

Anyway, apart from the typo, I suspect the str array should be
NULL terminated because there's no other way gtk_clist_append()
can know how many line to append.

Ciao
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: An 'oldie' question... GtkCList anyone?

[Nicola Fontana]

On Tue, 27 Jan 2009 19:08:30 -0200
John Coppens j...@jcoppens.com wrote:

 On Tue, 27 Jan 2009 17:02:32 +0100
 Nicola Fontana n...@entidi.it wrote:
 
 gtk_clist_append appends only 1 row, so that shouldn't be the problem. The
 elements in the str[] array correspond to cells, the number is defined in
 the CList, at creation time (gtk_clist_new takes nr of columns as
 parameter). Number of columns in a CList cannot be changed dynamically.

Yes, I've seen. Anyway, just to be sure, I executed the following
program and works as expected (gtk+-2.14.5) although I had to set
the titles to see all the columns.

#include gtk/gtk.h

int
main(gint argc, gchar **argv)
{
GtkWidget *window;
GtkWidget *clist;
gchar *values[] = {abc, def, ghi, jkl};

gtk_init(argc, argv);

window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(window, delete-event,
 G_CALLBACK(gtk_main_quit), NULL);

clist = gtk_clist_new_with_titles(4, values);
gtk_container_add(GTK_CONTAINER(window), clist);

gtk_clist_append(GTK_CLIST(clist), values);
gtk_clist_append(GTK_CLIST(clist), values);
gtk_clist_append(GTK_CLIST(clist), values);

gtk_widget_show_all(window);

gtk_main();

return 0;
}

gtk_clist_append() dups the strings, so you can do whatever you
want with values after the call.

If you're lucky there's something wrong in your splitline(),
if not you're experiencing the result of a previous memory
corruption or hitting a GtkCList bug or... who knows.

Ciao
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Question about Callback

[Nicola Fontana]

On Sun, 11 Jan 2009 12:42:41 +0100
Rudolfo Pinewood rudolfo.pinew...@googlemail.com wrote:

 I have several togglebuttons, that are all registered to call one
 specific function (ApplyFlags). In this function I actually don't know
 which button was activated.
 
 My attempt was giving each button/callback an additional parameter that
 should be passed to my ApplyFlags function.

You yet have the caller widget in ApplyFlags(). If you're using
g_signal_connect_swapped(), just use the second arg:

void ApplyFlags(gpointer your_data, GtkWidget *button)

Ciao
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gio memory management

[Nicola Fontana]

On Tue, 14 Oct 2008 17:41:13 +0200
Damien Caliste [EMAIL PROTECTED] wrote:

 Hello,
 
 Le 14/10/2008, nico [EMAIL PROTECTED] a écrit :
  And here is the source code of the program:
  http://yojik.shtooka.net/gio.c
 I didn't run nor check extensively the program but maybe there is a
 memory leak coming from the path you build with g_build_filename(). The
 documentation states that the returned string must be free. And a quick
 look to your source doesn't make this g_free() call appears to me...
 http://library.gnome.org/devel/glib/unstable/glib-Miscellaneous-Utility-Functions.html#g-build-filename
 
 So after the recursive call I would have put a g_free() there.

And you're also g_freeing a GFileInfo, which is a GObject. Try
to use g_object_unref() instead.

Ciao
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Gio memory management

[Nicola Fontana]

On Tue, 14 Oct 2008 18:03:05 +0200
nico [EMAIL PROTECTED] wrote:

 Thank you Nicola,
 
  And you're also g_freeing a GFileInfo, which is a GObject. Try
  to use g_object_unref() instead.
 
  Ciao

 When I use g_object_unref()  instead of  g_free(file_info); I've got  
 this error :
 
 (process:30949): GLib-GObject-CRITICAL **: g_object_unref: assertion 
 `G_IS_OBJECT (object)' failed

Because you are unrefing it in the wrong place. Now you have:

while ((file_info = g_file_enumerator_next_file()) != NULL) {
...
}
g_object_unref(file_info);

Here file_info is surely NULL and you're lacking tons of refs.
You must do instead:

while ((file_info = g_file_enumerator_next_file()) != NULL) {
...
g_object_unref(file_info);
}

Ciao
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtkmm and autoconf

[Nicola Fontana]

On Fri, 03 Oct 2008 11:00:35 +0200
Murray Cumming [EMAIL PROTECTED] wrote:

 or this might be better:
 
 AM_CPPFLAGS = $(MYAPP_CFLAGS)
 onwindow_LDADD = $(MYAPP_LIBS)

I don't know the technical difference (I always seen
preprocessing and compilation in the same step), but is not
AM_CXXFLAGS a better place for MYAPP_CFLAGS?

-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: gtk_icon_theme_load_icon very slow

[Nicola Fontana]

On Wed, 01 Oct 2008 13:51:39 +0200
Adolfo González Blázquez [EMAIL PROTECTED] wrote:

 The problem is that gtk_icon_theme_load_icon takes about two seconds to
 load icons from themes which are not standard [2]. I mean, if the user
 use a theme with 256x256 icons, the load of 5 icons (text-x-generic,
 audio-x-generic and so on) it's about ten seconds.

Hi Adolfo,

have you tried to update the icon cache with
gtk-update-icon-cache?

-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Finding a widget in a Glade interface

[Nicola Fontana]

On Sun, 03 Aug 2008 19:10:37 +
dhk [EMAIL PROTECTED] wrote:
 Is gtk_container_get_children() suppose to return a list of all children 
 including children of children down to the last leaf or just the 
 immediate children?  I only seem to get the immediate children.  Will 
 gtk_container_foreach() or gtk_container_forall() go down all levels to 
 the last leaf or just the next level?

Both work on immediate children. You must call them recursively,
something like that:

void
action(GtkWidget *widget)
{
  /* Do something */
}

void
callback(GtkWidget *widget)
{
  action(widget);
  if (GTK_IS_CONTAINER(widget))
  gtk_container_foreach(GTK_CONTAINER(widget),
callback, NULL);

}

gtk_container_foreach() is the way: the forall() version
traverses also internal stuff I think you don't care about.

Ciao
-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Finding a widget in a Glade interface

[Nicola Fontana]

On Thu, 31 Jul 2008 11:07:34 +
dhk [EMAIL PROTECTED] wrote:

 Jim George wrote:
 I wasn't a fan of keeping the GladeXml object around due to the 
 resources it used.  Even though it's not as efficient as storing 
 pointer, I wish I could just traverse up and down the the object tree 
 for my pointer.  I guess I'll be storing the pointers that I need.  That 
 would mean that after calling glade_xml_new() I need to call 
 glade_xml_get_widget() on each object I will need and then save that 
 pointer . . . right?

You don't need special API to traverse Gtk widgets, and GladeXml
is less than needed: just use GTK_IS_CONTAINER() and
gtk_container_get_children() or gtk_container_forall().

If you want to go from the leafs to the root, use
gtk_widget_get_parent().

-- 
Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Histogram and other statistical graphs

[Nicola Fontana]

On Wed, 23 Apr 2008 12:29:27 +0200
Roberto Mantovani - AL [EMAIL PROTECTED] wrote:
 I need to write a program that displays some statistical values so I
 would know if there are libraries fot GTK+ to draw histograms and other
 statistical rapresentations.

There is also goffice, the graph library used by abiword and
gnumeric.
http://ftp.gnome.org/pub/gnome/sources/goffice/

It lacks a bit/lot of documentation...
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Signal propagation with g_signal_emit_valist()

[Nicola Fontana]

Hi all,

I've the following function:

void
propagate_valist (GSList *children,
  guint   signal_id,
  GQuark  detail,
  va_list var_args)
{
  GSList *child = children;
  while (child)
{
  if (G_IS_OBJECT (child-data))
g_signal_emit_valist (child-data, signal_id, detail, var_args);

  child = g_slist_delete_link (child, child);
}
  }
}

Is it valid to do multiple calls to g_signal_emit_valist() using the same 
va_list?
I'm noticing segfaults on my AMD64 system and I suspect this is the problem...

Thankyou,
-- Nicola
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list