Re: Pause and resume GtkApplication

[Chris Vine]

On Fri, 26 Jan 2018 11:14:36 +0700
"Lucky B.C"  wrote:
> Well, in the case, I will tell something about me, first I've never
> used the GtkApplication just main window maybe sub windows (dialogs)
> too, and my programs did not do as what you are trying to do. Second
> I'm a C programmer, in my opinion, you should redesign your app
> because sometimes we must do that to gain our main target not about
> GUI which we only need for rendering/displaying to the user. Nothing
> is perfect! If we don't want the user see the private data or
> something else, we just don't show it by doing in another thread.
> Yes, the main loop of GTK always runs after we called gtk_main (),
> but we can create another thread before gtk_init () is called and run
> it anytime we need by gdk_threads_enter and gdk_threads_leave, for
> more detail see GThreads
> 
> and IDLES
> . Finally
> just reload/refresh our new data/thing again to the user or show a
> message dialog says somthing else, for example "Your data changed!".
> I wonder is there some programs which have the same what you are
> trying to do? If there's one or more, please send me the link, I
> really want to test them.

gdk_threads_enter and gdk_threads_leave are absolutely not the way to
do it.  They are deprecated in GTK+3 and will be removed in GTK+4.
Furthermore they only work with the X backend (not with windows or
wayland) and are horribly error-prone.

The correct way for a worker thread to pass back a result to the glib
main loop, or to execute code in that loop, is for it to post an event
using g_idle_add() and cognates.  The glib main loop is thread safe.

gdk_threads_add_idle is only necessary if your code interfaces with
ancient third-party library code which uses gdk_threads_enter and
gdk_threads_leave.  The best thing to do with such ancient libraries is
not to use them.

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

Re: gdk_pixbuf_new_from_inline to Gresource conversion

[Chris Vine]

On Tue, 5 Sep 2017 16:39:12 -0600
Charles Curley  wrote:
[snip]
> The second one is new on debian 9. I have several options. The
> documentation for gdk_pixbuf_new_from_inline () indicates that it is
> deprecated and one should use a Gresource.
> 
> Question: how do I use a Gresource here?

I am not going to answer your question I am afraid, but I am going to
make the observation that since GTK+2 will not be updated except for bug
fixes, unless you are thinking of porting your code to GTK+3 or GTK+4
you might as well leave it as it is.  If the warning bothers you, you
can add -Wno-deprecated-declarations to your CFLAGS to suppress it.

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

Re: GtkPrintOperation; request for assistance

[Chris Vine]

On Fri, 10 Feb 2017 18:55:39 +0100
Norbert de Jonge  wrote:
[snip]
> I'm a fan of GTK+ and have always been a fan. The printing
> functionalities are extremely versatile. But it's difficult for me to
> understand why there is no function that requires only a buffer (of
> any size), font type and font size as parameters, then presents the
> user with a print dialog. As a programmer, I don't want to think about
> margins, pages, cairo, pango, and so on. I also feel sorry for all
> other programmers who suddenly need to write begin_print() and
> draw_page() functions just to print a buffer. I feel like there's room
> for improvement here. :)

If you happen to use C++, this will do what you want I think:

http://cxx-gtk-utils.sourceforge.net/2.2/classCgu_1_1TextPrintManager.html

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

Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 18:10:46 -1000 (HST)
rbd  wrote:
> Eric (cecas...@aol.com) sent me the following earlier today in
> response to another discussion thread I started a few days ago re:
> GSubProcess:
> 
> > I put together a test example of GSubprocess. ...
> >
> > 
> > https://github.com/cecashon/OrderedSetVelociRaptor/blob/master/Misc/Pipes/gnuplot5.c
> >   
> 
> In an amazing bit of coincidence, Eric's example contains the
> following bit of code which would seem to have some bearing on this
> file descriptor watch discussion thread:
> 
> >  GSource
> > *source=g_pollable_input_stream_create_source((GPollableInputStream*)err_stream,
> >
> NULL);
> >  g_source_attach(source, NULL);
> >  g_source_set_callback(source, (GSourceFunc)read_err, NULL, NULL);  
> 
> Could this be yet another way to skin my cat? Perhaps better than the 
> GIOChannel, if not the g_source_add_unix_fd() solution? Looks like I
> could create my own GInputStream with
> 
>GInputStream *gis= g_unix_input_stream_new(mypipefd, FALSE);
> 
> and then use that stream (which should also be a
> GPollableInputStream, yes?) in the call to
> g_pollable_input_stream_create_source(). I had not intended to use
> stream (i.e., buffered) i/o, but there's probably no harm in doing
> so. This seems like a perspiration-free way to create the GSource I
> need.

I didn't know about that.  Yes, that looks as if it will do what you
want.  GInputStream is not buffered by the way.  GIO streams are based
on the class heirarchy of the java.io package, so for buffering you
would need to instantiate an object of the GBufferedInputStream type
(which is derived from GInputStream).  GPollableInputStream is an
interface which is implemented by any pollable GInputStream (which in
practice seems to mean any input stream for a device represented by a
file descriptor).

If you are not going to use any of the GInputStream methods to read
from the file descriptor that could be regarded as a somewhat heavy
weight way of doing it, but if it is convenient for you, why not, and
you could say something of the same for GIOChannel.  Given what you want
to do and what we now know to be your four options (GIOChannel,
GPollableInputStream, using g_source_add_unix_fd() directly or using
GPollFD directly) on reflection I think I would probably go for
GIOChannel for ease of use, but that is just a matter of impression.

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

Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 22:18:19 +
Emmanuele Bassi  wrote:
> Hi;
> 
> On 23 January 2017 at 22:09, rbd  wrote:
> 
> >> It is not quite that bad.  The documentation for
> >> g_source_add_unix_fd() is inadequate, but although not immediately
> >> obvious the prepare, check and finalize handlers can in fact
> >> usually just be set to NULL (provided you have set the 'events'
> >> argument for g_source_add_unix_fd() correctly) so you only need to
> >> provide the dispatch handler, which executes your callback when an
> >> event occurs.
> >>
> >> The poor quality of the documentation is the real problem here.  I
> >> would give it a try and see how you get on with it.  
> >
> >
> > Nothing about the g_source_* functions is obvious from the official
> > docs, either immediately or otherwise! ;-> Seriously, one of the
> > least illuminated points there actually has to do with timeouts,
> > exactly where in the check->prepare->dispatch sequence the poll()
> > gets done, etc.  
> 
> Of course, patches and bugs for the documentation are welcome.
> 
> A good set of articles on GSource and the main context API in GLib is
> on Philip Withnall's blog; Philip actually contributed back that
> documentation in the API reference, but this kind of discussions on
> how the implementation works is ill-suited for an API documentation.
> 
> See:
> 
>   - https://tecnocode.co.uk/2014/03/27/what-is-gmaincontext/
>   - https://tecnocode.co.uk/2015/05/05/a-detailed-look-at-gsource/
>   -
> https://tecnocode.co.uk/2014/04/19/ensuring-functions-are-called-in-the-right-context/
> 
> The second article also covers your use case pretty accurately.

I don't want to appear argumentative, but the second article is not of
great assistance with respect to the OP's usage of a wrapper for poll()
which executes a callback in the glib main loop when a file descriptor
becomes available for reading - as the OP put it, a replacement for
XtAppAddInput().  For that (if not using GIOChannel) he needs
g_source_add_unix_fd(), NULL for the prepare, check and finalize
handlers and a dispatch handler which executes the callback and a type
derived from GSource which interfaces with that.  As far as I can see
there is little in the second article which explains that. (And I have
not seen any other article which does that either.)

The second article is concerned with a more complex implementation of a
non-file descriptor based event source.  For a file descriptor based
event source these days you just use g_source_add_unix_fd(), which does
most of the boiler plate for you, were one to know it.

Let me stress I am not being negative here.  I very much appreciate the
efforts of the glib developers.  But I have stubbed my toe on exactly
the same issue myself: having said that, setting up a few test cases
and reading the source code made it apparent fairly quickly how
g_source_add_unix_fd() actually works, and from there it was pretty
straightforward.

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

Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 09:30:17 -1000 (HST)
rbd  wrote:
> Hi Chris,
> 
> Thanks very much for all of that information -- it was very helpful!
> 
> >> I do not fully understand your question (especially I don't
> >> understand your reference to using "g_idle_add_full() and do my
> >> own non-blocking select() inside my callback", which would not
> >> work), ...  
> 
> I won't be trying the above approach unless all else fails (see
> below), but I am curious as to why you say that I could not
> successfully call a non-blocking select() (or poll(), if you prefer)
> on my file descriptor of interest inside a callback registered via
> g_idle_add_full(), then read from that descriptor if select() tells
> me there's something there. This is not as logically sensible as
> registering a separate input source to be polled inside the main
> loop, but I can't see why it wouldn't work.

The problem is that the main loop would enter a busy loop.  Well, maybe
a 'busy-ish' loop.  If you call up g_idle_add() with a repeating
callback (one which returns TRUE) which does nothing except examine a
non-blocking select(), you will end up with one CPU core using
approximately 100% CPU.  The default idle priority
G_PRIORITY_DEFAULT_IDLE will put the idle event somewhat at the end of
the main loop's event queue, but when there is nothing else to do it
will continue executing it.  (On a multi-core system this might not be
immediately apparent - you need to be able to interpret top or whatever
other tool you use to see it.)

You could make this work with a timeout, say of around 50mS delay,
which puts the main loop to sleep for a while between iterations.

> >> ... This may (or may not) help:
> >>   
> https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_$
> 
> Thanks very much for the above code sample -- unfortunately it
> confirms my very worst expectations of what might be involved with
> using g_source_add_unix_fd(), etc., to monitor a file descriptor,
> i.e., create a new GSource, code up a whole set of GSourceFuncs
> routines to implement a process which is not well-described in the
> docs, etc. I'm clearly barking up the wrong tree on that!

It is not quite that bad.  The documentation for g_source_add_unix_fd()
is inadequate, but although not immediately obvious the prepare, check
and finalize handlers can in fact usually just be set to NULL (provided
you have set the 'events' argument for g_source_add_unix_fd()
correctly) so you only need to provide the dispatch handler, which
executes your callback when an event occurs.

The poor quality of the documentation is the real problem here.  I
would give it a try and see how you get on with it.
 
> >> ...
> >>   
> https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch
> >
> > By the way, if you are thinking of using GIOChannel, you might also
> > want to look at the implementation of gdk_input_add() and
> > gdk_input_add_full() in gtk+-2. Although now deprecated in gtk+-2,
> > you can still use those functions if you happen to be building
> > against gtk+-2.  
> 
> Using gtk3, not 2.
> 
> >
> > If you are using gtk+3 you can set up a read watch as follows (I
> > have not done a test compile on this snippet but it is what I have
> > on occasions done in the past, and it avoids keeping an explicit
> > GIOChannel object in scope if you only want to execute a callback
> > when a descriptor is ready for input - you can use the internal
> > reference counting to control channel lifetime):
> >
> >
> > guint start_read_watch(int fd, GIOFunc func) {
> >  GIOChannel *channel = g_io_channel_unix_new(fd);
> >  guint id = g_io_add_watch(channel,
> >G_IO_IN | G_IO_HUP | G_IO_ERR,
> >func,
> >NULL);  
> 
> GIOChannel is the ticket, I think, thanks for pointing me there
> (where I would probably have never gotten on my own)! Unlike 
> g_source_add_unix_fd(), of which I could find no useful example code 
> whatsoever other than the code you sent me, there seem to be a fair
> number of examples around on basic use of GIOChannel to more or less
> do what I want to do (I hope). This 2005 Robert Love article in
> particular was quite useful:
> 
> http://www.linuxjournal.com/node/8545/print
> 
> Still not as drop-dead simple as libXt/Motif's XtAppAddInput() (and I 
> cannot believe that I am actually favorably comparing Motif to any 
> more contemporary API whatsoever ;-> ), but simple enough to be
> useful.

The GIOChannel interface is not well designed by today's standards.  It
confuses concerns by combining a wrapper for poll() with an object for
locale-based reading to and writing from files.  It is against modern
design practice to combine purposes in this way.  But it is old (it goes
back to GTK+-1.2 days) when large multi-purpose objects were all the
rage. We know better now.

Its naming is also now highly confusing as it is not related to glib's

Re: watching a file descriptor in gtk3

[Chris Vine]

On Mon, 23 Jan 2017 00:29:46 +
Chris Vine <ch...@cvine.freeserve.co.uk> wrote:
[snip]
> I do not fully understand your question (especially I don't understand
> your reference to using "g_idle_add_full() and do my own non-blocking
> select() inside my callback", which would not work), but you can
> either use glib's g_poll()/g_source_add_poll() implementation or (on
> unix) its g_source_add_unix_fd() implementation to watch on a file
> descriptor. The functionality of both is equivalent, and on unix both
> use poll() underneath. This may (or may not) help:
> 
> https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_watch.cpp
> 
> If you want to use glib's g_source_add_poll() implementation rather
> than its g_source_add_unix_fd() implementation, you can avoid some of
> the boiler plate with g_io_add_watch() - you can use this to call up a
> callback function whenever a file descriptor is ready (you don't need
> to use the GIOChannel object for any other purpose, such as reading
> from or writing to the descriptor):
> 
> https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch

By the way, if you are thinking of using GIOChannel, you might also want
to look at the implementation of gdk_input_add() and
gdk_input_add_full() in gtk+-2.  Although now deprecated in gtk+-2, you
can still use those functions if you happen to be building against
gtk+-2.

If you are using gtk+3 you can set up a read watch as follows (I have
not done a test compile on this snippet but it is what I have on
occasions done in the past, and it avoids keeping an explicit GIOChannel
object in scope if you only want to execute a callback when a
descriptor is ready for input - you can use the internal reference
counting to control channel lifetime):

guint start_read_watch(int fd, GIOFunc func) {
  GIOChannel *channel = g_io_channel_unix_new(fd);
  guint id = g_io_add_watch(channel,
G_IO_IN | G_IO_HUP | G_IO_ERR,
func,
NULL);
  /*
 The call to g_io_add_watch incremented the channel's reference
 count.  Decrement the count now so that when func returns FALSE
 or g_source_remove() is applied to the returned id, the channel
 object will automatically be destroyed.
  */
  g_io_channel_unref(channel);
  return id;
}

This will not close the file descriptor when the watch has finished
(but see g_io_channel_set_close_on_unref()).

g_source_add_unix_fd() may be more efficient if you have a large number
of file watches in any one program.

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

Re: watching a file descriptor in gtk3

[Chris Vine]

On Sun, 22 Jan 2017 11:05:41 -1000 (HST)
rbd  wrote:
> Hi all,
> 
> I need to monitor a Unix file descriptor for input within my gtk3
> program. I believe that I need to somehow be using
> g_source_add_unix_fd() and friends but am finding the documentation
> confusing. Are there any simple examples which show how to do this
> anywhere? (I looked but could not find, apologies for any oversight
> on my part.)
> 
> I am porting an old Motif app which used
> 
>  XtAppAddInput( ... fd ... callbackproc ...)
> 
> to register an input handler callbackproc() to be called whenever
> there was input pending on fd. Whatever I use to replace this should
> NOT block for any user-perceivable amount of time when checking fd
> for pending input, which will typically be very small (under 80
> bytes) and occurring between a few times per second and a few times
> per hour.
> 
> Absent a working understanding of how to use g_source_add_unix_fd(),
> etc., my inclination is to just use g_idle_add_full() and do my own
> non-blocking select() inside my callback. Seems like
> g_source_add_unix_fd() is perhaps better suited to this task, but I
> can't figure out what I need to do vs. what glib can do without me,
> i.e., do I really need to create and attach my own GSource and code
> my own entire set of GSourceFuncs? That would seem to be a hugely
> complicated effort compared to the simple XtAppAddInput() call, or
> even to coding my own select() stuff inside a g_idle_add_full()
> callback. Monitoring a few stray file descriptors within a gtk3
> program would seem to be a not-unusual need, so I am hoping someone
> will tell me that there is an existing GSource somewhere that I can
> just add my own fd into, but that is not at all obvious from the
> documentation.

I do not fully understand your question (especially I don't understand
your reference to using "g_idle_add_full() and do my own non-blocking
select() inside my callback", which would not work), but you can either
use glib's g_poll()/g_source_add_poll() implementation or (on unix) its
g_source_add_unix_fd() implementation to watch on a file descriptor.
The functionality of both is equivalent, and on unix both use poll()
underneath. This may (or may not) help:

https://sourceforge.net/p/cxx-gtk-utils/git/ci/master/tree/c++-gtk-utils/io_watch.cpp

If you want to use glib's g_source_add_poll() implementation rather
than its g_source_add_unix_fd() implementation, you can avoid some of
the boiler plate with g_io_add_watch() - you can use this to call up a
callback function whenever a file descriptor is ready (you don't need
to use the GIOChannel object for any other purpose, such as reading from
or writing to the descriptor):

https://developer.gnome.org/glib/stable/glib-IO-Channels.html#g-io-add-watch

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

Re: gtk3 and fork/exec of non-gtk child

[Chris Vine]

On Sat, 14 Jan 2017 06:24:18 -1000 (HST)
rbd  wrote:
> Hi Emmanuele,
> 
> Thank you for the suggestion! I have just now looked over the
> GSubprocess API. It appears to have the necessary functionality and
> would at first inspection integrate well with GUI main loop
> processing.
> 
> However, I am still curious as to whether the
> fork/exec/SIGCHLDhandler model of my existing X11/Motif app will or
> will not work with gtk3. This design has worked quite well in this
> particular application for many years and I am reluctant to change it
> unless there is a strong argument that it either (i) no longer works
> as well as it did because of circumstances peculiar to gtk3 vs.
> X11/Motif or (ii) is likely to stop working in the near-to-medium
> future given current gtk3(/4?) development direction.
 
If you want to go by POSIX, then you can only call async-signal-safe
functions between the fork() and the exec().  Your code called
XtRemoveInput() and close().  close() is async-signal-safe.  I have no
idea whether XtRemoveInput() is, but I doubt it.

This rule would ordinarily preclude calling anything which might
allocate or free memory between fork() and exec() (none of those are
async-signal-safe), but glibc provides atfork handlers for the
allocator mutexes which actually makes that safe, and glib's g_spawn*
family rely on that.  But not all allocators are: Chromium's tcmalloc
allocator definitely is not, so you have problems if that gets linked
into your code.  Caveat forkor.

Just use the stuff glib provides, as suggested.

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

Re: Slackware 14.2 -- configuration can not find gtk3 and gtk2 , unicode will not supported

[Chris Vine]

On Tue, 3 Jan 2017 15:39:13 +
Chris Vine <ch...@cvine.freeserve.co.uk> wrote:
> On Tue, 3 Jan 2017 15:31:57 +
> "intmai...@gmail.com" <intmai...@gmail.com> wrote:
> > Hello,
> > 
> > I use slackware 14.2 and trying to build wxWidget 3.0.2 which
> > required gtk. Ther are three packages and versions of gtk installed
> > on the system: 1, 2 then 3.
> > 
> > The configuration/compilation achieved without problem but wxWidget
> > will not able to use unicode:
> > ./configure --with-gtk --enable-gtk2 --enable-unicode --enable-debug
> > 
> > The reason is the header gtk.h can not be found for both recent
> > version:  gtk+3-3.18.9 and gtk+2-2.24.30.
> > Then the old version gtk+-1.2.10 will be used instead: unfortunately
> > this version can NOT use unicode !
> > I need absolutely unicode for wxWidget.
> > 
> > Slackware is not longer use Gnome for years. This means that the 3
> > gtk packages provided and installed on my system may be very lean
> > and lose some functionality. May be there is many configurations
> > and tools missing.  
> 
> You have broken your system somehow.  Slackware provides the upstream
> libraries in complete form:
> 
>   grep gtk-2.0/gtk/gtk\\.h /var/log/packages/gtk+2-2.24.31-i686-1
>   usr/include/gtk-2.0/gtk/gtk.h
> 
>   grep gtk-3.0/gtk/gtk\\.h /var/log/packages/gtk+3-3.22.5-i686-1
>   usr/include/gtk-3.0/gtk/gtk.h

Actually that's from some updated packages I have compiled.  Here are
the original slackware-14.2 packages:

  tar tvf gtk+2-2.24.30-i586-1.txz | grep gtk\\.h
  usr/include/gtk-2.0/gtk/gtk.h

  tar tvf gtk+3-3.18.9-i586-1.txz | grep gtk\\.h
  usr/include/gtk-3.0/gtk/gtk.h

> > Bellow are a part of debuging screen during configuration of
> > wxWidget:
> > 
> > [code]
> > ...
> > checking for GTK+ - version >= 2.6.0... Package gtk+-2.0 was not
> > found in the pkg-config search path.
> > Perhaps you should add the directory containing `gtk+-2.0.pc'
> > to the PKG_CONFIG_PATH environment variable
> > No package 'gtk+-2.0' found
> > no
> > *** Could not run GTK+ test program, checking why...
> > *** The test program failed to compile or link. See the file
> > config.log for the
> > *** exact error that occurred. This usually means GTK+ is
> > incorrectly installed.
> > checking for pkg-config... (cached) /usr/bin/pkg-config
> > checking for GTK+ - version >= 3.0.0... Package gtk+-3.0 was not
> > found in the pkg-config search path.
> > Perhaps you should add the directory containing `gtk+-3.0.pc'
> > to the PKG_CONFIG_PATH environment variable
> > No package 'gtk+-3.0' found
> > no
> > *** Could not run GTK+ test program, checking why...
> > *** The test program failed to compile or link. See the file
> > config.log for the
> > *** exact error that occured. This usually means GTK+ is incorrectly
> > installed.
> > checking for gtk-config... no
> > checking for GTK - version >= 1.2.7... no
> > *** The gtk-config script installed by GTK could not be found
> > *** If GTK was installed in PREFIX, make sure PREFIX/bin is in
> > *** your path, or set the GTK_CONFIG environment variable to the
> > *** full path to gtk-config.
> > checking for gtk-config... (cached) no
> > checking for GTK - version >= 1.2.3... no
> > *** The gtk-config script installed by GTK could not be found
> > *** If GTK was installed in PREFIX, make sure PREFIX/bin is in
> > *** your path, or set the GTK_CONFIG environment variable to the
> > *** full path to gtk-config.
> > configure: error:
> > The development files for GTK+ were not found. For GTK+ 2, please
> > ensure that pkg-config is in the path and that gtk+-2.0.pc is
> > installed. For GTK+ 1.2 please check that gtk-config is in the path,
> > and that the version is 1.2.3 or above. Also check that the
> > libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
> > --libs' are in the LD_LIBRARY_PATH or equivalent.
> > ...
> > [/code]  
> 
> This just seems to follow from the fact that you have broken your
> system.  The pkg-config files are correctly installed in
> slackware-14.2:
> 
>   grep gtk+-2.0.pc /var/log/packages/gtk+2-2.24.31-i686-1
>   usr/lib/pkgconfig/gtk+-2.0.pc
> 
>   grep gtk+-3.0.pc /var/log/packages/gtk+3-3.22.5-i686-1
>   usr/lib/pkgconfig/gtk+-3.0.pc

Here are the original slackware-14.2 packages:

  tar tvf gtk+2-2.24.30-i586-1.txz | grep gtk+2.0.pc
  usr/lib/pkgconfig/gtk+-2.0.pc

  tar tvf gtk+3-3.18.9-i586-1.txz | grep gtk+3.0.pc
  usr/lib/pkgconfig/gtk+-3.0.pc

> Reinstall the gtk+2 and gtk+3 libraries from your slackware repository
> and it should be OK.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Slackware 14.2 -- configuration can not find gtk3 and gtk2 , unicode will not supported

[Chris Vine]

On Tue, 3 Jan 2017 15:31:57 +
"intmai...@gmail.com"  wrote:
> Hello,
> 
> I use slackware 14.2 and trying to build wxWidget 3.0.2 which required
> gtk. Ther are three packages and versions of gtk installed on the
> system: 1, 2 then 3.
> 
> The configuration/compilation achieved without problem but wxWidget
> will not able to use unicode:
> ./configure --with-gtk --enable-gtk2 --enable-unicode --enable-debug
> 
> The reason is the header gtk.h can not be found for both recent
> version:  gtk+3-3.18.9 and gtk+2-2.24.30.
> Then the old version gtk+-1.2.10 will be used instead: unfortunately
> this version can NOT use unicode !
> I need absolutely unicode for wxWidget.
> 
> Slackware is not longer use Gnome for years. This means that the 3 gtk
> packages provided and installed on my system may be very lean and lose
> some functionality. May be there is many configurations and tools
> missing.

You have broken your system somehow.  Slackware provides the upstream
libraries in complete form:

  grep gtk-2.0/gtk/gtk\\.h /var/log/packages/gtk+2-2.24.31-i686-1
  usr/include/gtk-2.0/gtk/gtk.h

  grep gtk-3.0/gtk/gtk\\.h /var/log/packages/gtk+3-3.22.5-i686-1
  usr/include/gtk-3.0/gtk/gtk.h

> Bellow are a part of debuging screen during configuration of wxWidget:
> 
> [code]
> ...
> checking for GTK+ - version >= 2.6.0... Package gtk+-2.0 was not found
> in the pkg-config search path.
> Perhaps you should add the directory containing `gtk+-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'gtk+-2.0' found
> no
> *** Could not run GTK+ test program, checking why...
> *** The test program failed to compile or link. See the file
> config.log for the
> *** exact error that occurred. This usually means GTK+ is incorrectly
> installed.
> checking for pkg-config... (cached) /usr/bin/pkg-config
> checking for GTK+ - version >= 3.0.0... Package gtk+-3.0 was not found
> in the pkg-config search path.
> Perhaps you should add the directory containing `gtk+-3.0.pc'
> to the PKG_CONFIG_PATH environment variable
> No package 'gtk+-3.0' found
> no
> *** Could not run GTK+ test program, checking why...
> *** The test program failed to compile or link. See the file
> config.log for the
> *** exact error that occured. This usually means GTK+ is incorrectly
> installed.
> checking for gtk-config... no
> checking for GTK - version >= 1.2.7... no
> *** The gtk-config script installed by GTK could not be found
> *** If GTK was installed in PREFIX, make sure PREFIX/bin is in
> *** your path, or set the GTK_CONFIG environment variable to the
> *** full path to gtk-config.
> checking for gtk-config... (cached) no
> checking for GTK - version >= 1.2.3... no
> *** The gtk-config script installed by GTK could not be found
> *** If GTK was installed in PREFIX, make sure PREFIX/bin is in
> *** your path, or set the GTK_CONFIG environment variable to the
> *** full path to gtk-config.
> configure: error:
> The development files for GTK+ were not found. For GTK+ 2, please
> ensure that pkg-config is in the path and that gtk+-2.0.pc is
> installed. For GTK+ 1.2 please check that gtk-config is in the path,
> and that the version is 1.2.3 or above. Also check that the
> libraries returned by 'pkg-config gtk+-2.0 --libs' or 'gtk-config
> --libs' are in the LD_LIBRARY_PATH or equivalent.
> ...
> [/code]

This just seems to follow from the fact that you have broken your
system.  The pkg-config files are correctly installed in slackware-14.2:

  grep gtk+-2.0.pc /var/log/packages/gtk+2-2.24.31-i686-1
  usr/lib/pkgconfig/gtk+-2.0.pc

  grep gtk+-3.0.pc /var/log/packages/gtk+3-3.22.5-i686-1
  usr/lib/pkgconfig/gtk+-3.0.pc

Reinstall the gtk+2 and gtk+3 libraries from your slackware repository
and it should be OK.

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

Re: Using fork() in a GTK C/Vala application

[Chris Vine]

On Tue, 1 Sep 2015 15:33:19 +0200
rastersoft  wrote:
> Thanks for your answer. Unfortunately, I'm running out of options:
> currently I'm using threads, but there is a nasty bug that makes my
> program crash sometimes. It is very subtle, because it hapens usually
> after being running for two-three days. It is a double free. I tried
> with Valgrind, but when I use it, the error doesn't trigger, which
> makes me suspect it is a race condition between both threads
> (valgrind ensures that only one thread runs each time). I checked all
> the code, and isolated everything as much as I could, and adding as
> many locks as I could imagine, trying to remove that bug, but its
> imposible, so I decided to separate the code in two independent
> processes to be able to use valgrind and finally find what is
> happening. But as you say, it seems I'll have to do something else...

Can you fork() before you launch any new threads or call any gio/gtk+
functions, and then perhaps communicate using pipes?  That should be
safe.

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

Re: GtkFrame has no frame border drawn?

[Chris Vine]

On Mon, 10 Aug 2015 15:05:30 +0100
Emmanuele Bassi eba...@gmail.com wrote:
 Hi;
 
 On 10 August 2015 at 14:51, Richard Shann rich...@rshann.plus.com
 wrote:
 
  Having invested effort in this it is exasperating to discover that
  GTK+ chooses a default theme that cripples one of the widgets - by
  failing to draw a frame around the contents the user can no longer
  see clearly what is being grouped by the frame.
 
 Crippling is a strong word, and one that I don't think applies.
 
 Grouping can be achieved by white space, for instance. Or by changing
 the background color. Or by changing the typographical appearance.
 
 Just because you expect a border, it does not mean your expectations
 are correct or are the only possible outcome.
 
 For instance, using a border around a GtkFrame has been deprecated in
 the GNOME HIG since the 2.x era, almost a decade ago:
 https://developer.gnome.org/hig-book/2.32/hig-book.html#controls-frames
 
 The human interface guidelines for MacOS also group controls without a
 border:
 https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/ControlsView.html#//apple_ref/doc/uid/2957-CH52-SW8
 
 In general, you want to use your GtkFrame with GTK_SHADOW_NONE, and
 use spacing. The documentation of GtkShadowType also specifies that
 themes may very well not have different types of shadows, and you
 should not rely on them:
 https://developer.gnome.org/gtk3/stable/gtk3-Standard-Enumerations.html#GtkShadowType

Obviously everyone is entitled to their own opinion, but I just don't
agree with that.  For some grouping purposes you need a proper visual
representation which spacing does not offer, and the purpose of
GtkFrame is (or was) to provide it: if you want spacing there are other
ways to do it.  I found it intensely annoying with one particular
application which needed the correct visual representation.  To give the
Adwaita developer (or developers) credit, I convinced him/her/them
of this with respect to that application in a bug report and in
response they reinstated the etched in frame marking as a kind of
honourable compromise.

My suggestion that the documentation should make it clearer that
whether you get A bin with a decorative frame and optional label as
advertised was at the whim of the theme author, was not attended to.  No
one seemed willing to take ownership of the documentation and it
remains incorrect.

In my view essential components like frames should not be a matter of
theming.  But perhaps I am too averse to problem areas which encourage
people who like to think they know best about what is good for others
to assert themselves.

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

Re: GtkFrame has no frame border drawn?

[Chris Vine]

On Mon, 10 Aug 2015 09:05:50 +0100
Emmanuele Bassi eba...@gmail.com wrote:
 Hi;
 
 the theme is responsible for drawing the frame. The old Windows theme
 engine shows a frame; the default GTK+ theme (Adwaita) does not.

The original Adwaita theme did not show frames.  More recent versions
(for GTK+ versions released within the last 5 or so years) do show
frames, and are much improved thereby (in my opinion).

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

Re: How to use socket conditions ?

[Chris Vine]

On Sat, 11 Jul 2015 00:09:54 -0400
Jacques Pelletier jpellet...@ieee.org wrote:
 Hi,
 
 I'm using a glib socket: when a client (glib) is connected to a
 server, the client doesn't get the HUP messages when the server
 closes its connection.

That's probably because the socket implementation does not provide HUP
on closure of the remote side of the connection (most don't).  You have
to inspect whether the read unblocks with 0 bytes received, indicating
end of file.

See http://www.greenend.org.uk/rjk/tech/poll.html

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

Re: Debian 6 with Sudden GTK application crash @ libGDK

[Chris Vine]

On Tue, 09 Dec 2014 13:11:59 +0530
venkat venka...@vortexindia.co.in wrote:
[snip]

The problem is almost certainly in your approach to threading.  I
didn't even know that you could run the gtk+ main loop in other than
the main program thread and the one in which you called gtk_init().  

One obvious problem is that you have not surrounded gtk_main() by
gdk_threads_enter() and gdk_threads_leave().  You could try doing that,
and also do the same in respect of the call to gtk_init() (and
definitely make your call to gtk_init() after the call to
g_thread_init() so that glib threads have been initialized).  That may
or may not solve your problem. In any event, your example code only
works at present by chance.

Using the GDK global lock is of course now deprecated (in GTK+-3) and
the best thing is to rewrite the program using callbacks from worker
threads via g_idle_add() and cognates.

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

Re: GHashTable with function pointers as values

[Chris Vine]

On Sat, 23 Aug 2014 11:35:05 +0100
Emmanuele Bassi eba...@gmail.com wrote:
 hi;
 
 On 23 August 2014 11:18, Iñigo Martínez inigomarti...@gmail.com
 wrote:
  Yes, it works, but i doesn't look like the best approach:
 
  warning: ISO C forbids passing argument 3 of 'g_hash_table_insert'
  between function pointer and 'void *' [-Wpedantic]
 
 drop `-Wpedantic`: it doesn't serve any practical purposes. instead,
 identify a set of warnings that you care about, and use them.
 
 in this particular case, we're talking about undefined behaviour that
 every compiler that is not a university student project, or an arcane
 compiler for a niche architecture, supports anyway.
 
 in practice, everything that GLib supports, will also support this
 construct.

As you say, glib requires it to work because it uses this conversion
for its closures.

However, it is not just a convention about undefined behaviour which (in
practice) any modern platform will support.  It is actually defined
behaviour on any POSIX platform, because the POSIX standard _requires_
it to work, for dlsym amongst other things.  It will also work on any
windows platform, as a windows extension.

Furthermore, in C++11 (I am not sure about C11) it is not even undefined
behaviour, but implementation defined behaviour.  It is conditionally
supported, specifically for the purpose of meeting the requirements of
POSIX:

  Converting a pointer to a function into a pointer to an object
  type or vice versa is conditionally-supported. The meaning of such a
  conversion is implementation defined, except that if an
  implementation supports conversions in both directions, converting an
  rvalue of one type to the other type and back, possibly with
  different cv-qualification, shall yield the original pointer value. 

You can suppress the warning emitted by gcc with -Wpedantic by casting
through a union, which is also supported by gcc although it technically
breaks C99's strict aliasing rules.  But that is pointless. The direct
C-style cast which POSIX and glib requires to work, and C++11 (and maybe
C11) conditionally permits, is the way to go on this.

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

Re: nuts!

[Chris Vine]

On Mon, 28 Jul 2014 23:00:34 -0700
Gary Kline kl...@thought.org wrote:
 while I can create several {N} labels, they print centered.  how do I 
 get the labels to print from the left side of the window widget:

Use 'gtk_misc_set_alignment(GTK_MISC(label), 0, 0.5)' to align left,
and 'gtk_misc_set_alignment(GTK_MISC(label), 1, 0.5)' to align right.
For multi-line labels, you would also want to call gtk_set_justify().

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

Re: GTK+ app development: avahi service browsing and Gtk+ main loop problem

[Chris Vine]

On Tue, 17 Jun 2014 10:51:21 +0300
Andrei Macavei andrei.macave...@gmail.com wrote:
 I am resending the code examples in plain text as the first message 
 contained some html part which made the code un-copy-paste-able.
 
 The problem description can be summarized as : when using gtk's main 
 loop ( Gtk.main() ) how to deal with gobject.MainLoop.().run() which
 is used by avahi client.

I do not know python particularly well but you probably first need to
explain why you are running two main loops.  Can't your program just
use one, so that you can use the default main loop for both?

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

Re: GTK+ app development: avahi service browsing and Gtk+ main loop problem

[Chris Vine]

On Wed, 18 Jun 2014 02:03:44 +0300
Andrei Macavei andrei.macave...@gmail.com wrote:
 On 17.06.2014 12:43, Chris Vine wrote:
  I do not know python particularly well but you probably first need
  to explain why you are running two main loops.  Can't your program
  just use one, so that you can use the default main loop for both?
 
  Chris
 
 
 Hi,
 I haven't shown the full code of the ServiceDiscover class, I will
 post it here again after my message.
 
 In the ServiceDiscover class , in the method discover() , a 
 dbus.Interface object is connected to the signal ItemNew :
 .
 self.sbrowser.connect_to_signal(ItemNew, self.handler)
 .
 
 Afterwards it must call the main loop or else it cannot use the above 
 signal I suppose. This has to be done inside the ServiceDiscover
 class.
 
 The code for both the service publishing and service browsing using 
 avahi is taken from avahi website:
 
 http://avahi.org/wiki/PythonBrowseExample
 http://avahi.org/wiki/PythonPublishExample
 
 The problem is that I have to use a main loop inside the
 ServiceDiscover class, and another one for the gtk+ main window class.

I cannot really help you, as I would need a greater knowledge of
python's dbus interface and avahi's interfaces than I possess in order
to do so.  When using gio's C interface for dbus, I have never had to
futz around with different main loops - the default program main loop
(the one which gtk+ uses) is automatically used for gio's asynchronous
continuations unless you go out of your way to set up something
different using g_main_context_push_thread_default().  I am also highly
suspicious of the use of two main loops, which amongst other things
requires a thread for each main loop, but maybe this is an avahi
thing.  It begs the question of how the two main loops communicate with
each other, and why.

In addition it looks as if your python library wraps dbus-glib rather
than gio's dbus implementation and I do not know what options that
gives you for main loops, as I don't use it.

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

Re: GTK signals question.

[Chris Vine]

On Wed, 05 Mar 2014 09:44:48 -0500
Chris Moller mol...@mollerware.com wrote:
 I was actually writing that testcase when I found a correlation: I'm 
 using gcc and my callbacks were nested functions.  Pull the callbacks 
 out and make them normal, top-level, functions, and it all works even 
 without no blocking of any kind.  So, if this is a bug at all, I
 suppose it could be a compiler bug.

Your question contained references to GTK+'s C interface.  If that
means that you are using C or C++ for your program, those languages do
not have a syntax for nested functions, so what you say does not really
make sense.  If you are simulating them in C++ using static methods of a
nested struct, in C++98 you have undefined behaviour if you try to use
them as a callback, because static member functions of classes with
local scope have no linkage (this follows because §3.5/5 of the standard
provides that a member function of class scope has external linkage if
the name of the class has external linkage, which it doesn't in the
case of local nested structs, and §3.5/8 provides that Names not
covered by these rules have no linkage).

So it is most likely a misunderstanding on your part rather than a
compiler bug, but you would need to post your code to be sure.

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

Re: GTK signals question.

[Chris Vine]

On Wed, 05 Mar 2014 13:43:29 -0500
Chris Moller mol...@mollerware.com wrote:

 On 03/05/14 12:07, Chris Vine wrote:
  On Wed, 05 Mar 2014 09:44:48 -0500
  Chris Moller mol...@mollerware.com wrote:
  I was actually writing that testcase when I found a correlation:
  I'm using gcc and my callbacks were nested functions.  Pull the
  callbacks out and make them normal, top-level, functions, and it
  all works even without no blocking of any kind.  So, if this is a
  bug at all, I suppose it could be a compiler bug.
  Your question contained references to GTK+'s C interface.  If that
  means that you are using C or C++ for your program, those languages
  do not have a syntax for nested functions, so what you say does not
  really make sense.  If you are simulating them in C++ using static
  methods of a nested struct, in C++98 you have undefined behaviour
  if you try to use them as a callback, because static member
  functions of classes with local scope have no linkage (this follows
  because §3.5/5 of the standard provides that a member function of
  class scope has external linkage if the name of the class has
  external linkage, which it doesn't in the case of local nested
  structs, and §3.5/8 provides that Names not covered by these rules
  have no linkage).
 
  So it is most likely a misunderstanding on your part rather than a
  compiler bug, but you would need to post your code to be sure.
 
 gcc supports nested functions as an extension to standard C.  I tend
 to use them a lot because they operate within the stack frame of the 
 enclosing function, thereby minimising the amount of information you 
 have to pass.  This is especially valuable in GTK callbacks where you 
 can only pass one pointer/int.

Having read Columban's posting, I see that the gcc documentation on
this extension explicitly rules out the use of nested functions as
pseudo-closures:  If you try to call the nested function through its
address after the containing function exits, all hell breaks loose. If
you try to call it after a containing scope level exits, and if it
refers to some of the variables that are no longer in scope, you may be
lucky, but it's not wise to take the risk. If, however, the nested
function does not refer to anything that has gone out of scope, you
should be safe.

This is equivalent to the position with nested structs: they have no
linkage.  Presumably that was your problem in this case.

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

Re: Still confused on new thread starting idle functions to update UI.

[Chris Vine]

On Tue, 3 Dec 2013 19:59:22 -0800 (PST)
David Buchan pdbuc...@yahoo.com wrote:
 ok, I may be getting somewhere. I did some reading on heap memory
 versus stack.
 
 Here's a vastly simplified example program which doesn't use GTK+,
 but I'm using to demonstrate my plan of attack.
 
 I use a function called packit() which allows me to still use
 strdup().
 
 Comments?
 
 Dave
 
 
 Valgrind is happy with this:
 #include stdio.h
 #include stdlib.h
 #include string.h
 #include unistd.h
 
 typedef struct _msgdata msgdatas;
 struct _msgdata {
   char *message;
   int *textview;
 };
 
 msgdatas *packit (msgdatas *, char *);
 int myfunc (msgdatas *);
 
 int
 main (int argc, char ** argv)
 {
   int i;
   char *message;
   msgdatas *msgdata;
 
   // Allocate memory on the heap, not stack.
   msgdata = (msgdatas *) malloc (1 * sizeof (msgdatas));
   msgdata-textview = (int *) malloc (1 * sizeof (int));
   message = (char *) malloc (1024);
 
   // Main loop.
   for (i=0; i100; i++) {
     sprintf (message, %i Dave is here., i);  // In reality, this is
 a more complicated sprintf().
 
     *(msgdata-textview) = 7;  // This is a stand-in for a pointer to
 a textview. myfunc (packit (msgdata, strdup (message)));  // strdup()
 allocates memory for message on the heap.
 
     sprintf (message, %i Dave is no longer here., i);  // In
 reality, this is a more complicated sprintf().
 
     *(msgdata-textview) = 3;  // This is a stand-in for a pointer to
 a textview; only changed for fun. myfunc (packit (msgdata, strdup
 (message)));  // strdup() allocates memory for message on the heap. }
 
   // Don't free msgdata-message; it gets free'd by myfunc().
   free (msgdata-textview);
   free (msgdata);
   free (message);
 
   return (EXIT_SUCCESS);
 }
 
 msgdatas *
 packit (msgdatas *msgdata, char *message)
 {
   msgdata-message = message;
 
   return (msgdata);
 }
 
 // This is a stand-in for an idle function which would update the
 textview in the UI. int  // Would really be gboolean
 myfunc (msgdatas *data)
 {
   printf (Pointer to textview: %i\n, *(data-textview));
   printf (message: %s\n, data-message);
 
   // Only free the element message of msgdatas struct.
   free (data-message);
 
   return (EXIT_SUCCESS);  // Would really be return (G_SOURCE_REMOVE)
 }

I don't really understand what you are trying to do.  It seems bizarre
to allocate a pointer to a textview on the heap (it seems completely
unnecessary), and even more bizarre then to free it again in the same
thread.  In fact I have no idea why you are passing a pointer to a text
view at all: that sounds like shared data (you shouldn't create a
GtkTextView except in the main loop thread), which may defeat part of
the purpose of the exercise.  If the worker thread can see the textview
then presumably so can the main thread.  If myfunc() is a stand-in for
g_idle_add(), then there is also a clear error in freeing msgdata and
its textview member in main(), and using these in myfunc(). You should
free the struct and any of its members which need freeing in myfunc()
(the g_idle_add() stand-in). Furthermore your call to strdup() is
completely unnecessary as 'message' has already been allocated on the
heap.

I may be wrong but I get the impression you do not know much about C.
You need to take some basic tuition on the use of C pointers and on
memory allocation as a minimum.  Learning C is a good thing to do if
you are serious about programming but you cannot run until you can
walk.  I would caution you against trying to program with threads,
which bring in a host of new issues concerning synchronization, at your
level of understanding.  Having said that, if you want to plough on
regardless, then good on you, as you need to start somewhere and learn
from there.  Possibly you already know about how to use threads safely
from another language, in which case fine.

Otherwise, have you considered perhaps using something like the python
bindings for GTK+?  These have a binding for g_idle_add() and handle
all the memory allocation for you.  I recommend using the
gobject-introspection binding for GTK+-3 rather than the old pygtk for
GTK+-2.  Python is another language which is worth learning.  There are
also introspection bindings for javascript if you prefer that (although
you won't be able to use threads in javascript - but that may be an
advantage for you).

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

Re: Still confused on new thread starting idle functions to update UI.

[Chris Vine]

On Thu, 5 Dec 2013 03:06:59 +1100
Chris Angelico ros...@gmail.com wrote:
[snip]
 As promised, here's a simple Pike program that listens for socket
 connections.
 [snip]
 
 See how much effort goes into
 making sure everything's thread-safe? The same amount, because this
 isn't even threaded - though it will happily handle any number of
 simultaneous clients.

And to make the point for David, you can do the same in the C
GTK+/glib libraries, by abandoning threads and instead setting up an
asynchronous watch on the socket using a GIOChannel with
g_io_channel_add_watch().

However, even better than that is to use gio's high level
GSocketListener and GSocketConnection, and read on the contained
GInputStream asynchronously using g_input_stream_read_async().

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

Re: Still confused on new thread starting idle functions to update UI.

[Chris Vine]

On Tue, 3 Dec 2013 11:02:53 -0800 (PST)
David Buchan pdbuc...@yahoo.com wrote:

 These darn threads and idle functions still baffle me. I'm sorry to
 be such a pest.
 
 I want to periodically update a textview as new information comes
 available. Sometimes this information can come in quickly (roughly
 every tenth of a second). Each update is a single line of text.
 
 The observed bad behavior is that sometimes messages don't appear at
 all, or appear twice in my textview. It's quite unpredictable. Sounds
 like a race condition.
 
 I spawn a thread from the main program - and from now on I don't talk
 about main - and this new thread prepares messages in a character
 string. The thread then passes a pointer to the character string to
 an idle function so that the idle function can update a textview in
 the UI. When done, the idle function stops itself by returning a
 G_SOURCE_REMOVE boolean.
 
 The thread allocates memory for the character string, and the idle
 function does not free it. Instead, the thread free's the memory just
 before it stops. It waits a bit to make sure the idle function has
 finished using the memory containing the message.
 
 But I lied...
 
 Because there are several messages (roughly 30), the thread actually
 allocates memory for an *array* of character strings. An index is
 then used to specify which one we're using.
 
 This may seem awkward and unnecessary, but if I just use a single
 character string, it is possible for the thread to replace the
 contents of the string with the next message while an idle function
 is still working with the previous message.

It is awkward, and probably unnecessary.  Unless you have a very good
reason, that is not the way to do it.  Pass the idle function a string
allocated on the heap, and free it in the idle function when finished
with.  Any other way creates thread dependencies which the message
passing approach you have adopted is intended to avoid.

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

Re: Still confused on new thread starting idle functions to update UI.

[Chris Vine]

On Tue, 3 Dec 2013 13:15:28 -0800 (PST)
David Buchan pdbuc...@yahoo.com wrote:
[snip]
 It is awkward, and probably unnecessary.  Unless you have a very good
 reason, that is not the way to do it.  Pass the idle function a string
 allocated on the heap, and free it in the idle function when finished
 with.  Any other way creates thread dependencies which the message
 passing approach you have adopted is intended to avoid.
 
 Chris
 =
 
 Chris, 
 
 For clarification, if I use strdup() to pass to the idle function a
 pointer to a copy of the string, and then have the idle function free
 it when finished, is that passing it on the heap?
 
 Simplified rough example:
 
 In main():
 
 char *message
 message = (char *) malloc (1024);
 
 for loop {
 
    Calculate good stuff.
 
   strcpy (message, Super duper message.);
   g_idle_add ((GSourceFunc) post_message, strdup (message));
 
   if (we're done) break;
 }
 
 free (message);
 return (EXIT_SUCCESS);
 
 And the idle function would free that memory before it stops:
 
 int
 post_message (char *message)
 {
   GtkTextBuffer *textbuffer;
   GtkTextIter end;
 
   textbuffer = gtk_text_view_get_buffer (GTK_TEXT_VIEW
 (data-textview)); gtk_text_buffer_get_end_iter (textbuffer, end);
   gtk_text_buffer_insert (textbuffer, end, data-message, -1);
   gtk_text_view_scroll_to_iter (GTK_TEXT_VIEW (data-textview), end,
 0.0, FALSE, 0, 0);
 
   // Free memory used for message string.
   free (message);
 
   return (G_SOURCE_REMOVE);
 }
 
 I'm not clear on the exact meaning of heap. Is that what the above
 would do?

Yes, malloc() allocates on the heap, as do most of the glib memory
allocation functions.  For any memory allocation function, make sure
you use the corresponding memory freeing function (for malloc() use
free(), for g_malloc() and cognates (such as g_strdup()) use g_free()
and for g_slice_alloc() and cognates use g_slice_free1() and cognates).

However, you have unnecessary steps in your example.  Pass
g_strdup(Super duper message.) to the data argument of g_idle_add(),
and in the idle handler dispose of it with g_free().  Your intermediate
step using the 'message' variable is pointless.  You might want to read
up on memory allocation in C.  Your post_message() function would also
be more aptly described as receive_message(), but that is just a label.

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

Re: Delay time to spawn new threads?

[Chris Vine]

On Thu, 28 Nov 2013 09:11:45 +
Osmo Antero osm...@gmail.com wrote:
 My audio-recorder that was based on GTK2 had some threads that also
 modified the GUI-elements. I had to call
 GDK_THREADS_ENTERhttps://developer.gnome.org/gdk3/3.10/gdk3-Threads.html#GDK-THREADS-ENTER:CAPS
  /
 GDK_THREADS_LEAVEhttps://developer.gnome.org/gdk3/3.10/gdk3-Threads.html#GDK-THREADS-ENTER:CAPS
 before modifying the GTK-elements, otherwise the GUI froze.
 
 Now in GTK3, I've replaced the threads with
 g_timeout_add_fullhttps://developer.gnome.org/glib/2.30/glib-The-Main-Event-Loop.html#g-timeout-add-full
 () and
 GAsyncQueuehttps://developer.gnome.org/glib/2.26/glib-Asynchronous-Queues.html#GAsyncQueue
  .
 g_timeout_full_id() runs within the MainLoop so GUI-locking is handled
 automatically.

I am not saying that using a polling timeout which checks for action
keys has no uses, but using g_idle_add() to have a worker thread
communicate with the glib main loop is usually preferable because it
avoids the need to poll, and it is just as thread safe.

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

Re: Delay time to spawn new threads?

[Chris Vine]

On Wed, 27 Nov 2013 19:32:26 -0800 (PST)
David Buchan pdbuc...@yahoo.com wrote:
 I removed the call to g_thread_init() and it still works fine! Great
 catch there.

You can include it with glib = 2.32 - it is a no-op then.  You should
include it if you want your code to be able to run on earlier as
well as later versions

 I had put the cast to GThreadFunc there because otherwise I get the
 following error:
 
 callbacks.c: In function ‘on_button1_clicked’:
 callbacks.c:3829: warning: passing argument 1 of
 ‘g_thread_create_full’ from incompatible pointer
 type /usr/include/glib-2.0/glib/gthread.h:225: note: expected
 ‘GThreadFunc’ but argument is of type ‘int (*)(struct MyData *)’
 
 I saw other people on the web do the cast as well to remove that
 error. Is there a mistake in how I use g_thread_create()? I'd like to
 drop the cast if I can. It seemed strange at the time I put it in.

That's fine.  If you are passing user data then you need to do that.

[snip] 
 My newly spawned thread calls a function which starts a messaging
 idle-function.
 
 [my main program] --- [my new thread]  [post_message function]
 === [update GUI idle function]
 
 In my new thread, I call:
 
 post_message (text, data);
 
 and that looks like:
 
 // Start an instance of activity_message() idle function.
 int
 post_message (char *message, MyData *data)
 {
   // Allocate memory for string; Idle function will free it.
   data-activity_message = allocate_strmem (TEXTLEN);
   // Copy message.
   strncpy (data-activity_message, message, TEXTLEN - 1);  // Minus 1
 for string termination.
 
   g_idle_add ((GSourceFunc) activity_message, data);
   sleep (1);
   return (EXIT_SUCCESS);
 }
 
 // Idle function to add a message to the activity textview
 // This idle function returns 0 in order to stop.
 int
 activity_message (MyData *data)
 {
   ...
   Update a textview with our message ...
 
   return (0)
 }
 
 I set it up this way so the GUI can be updated.
 
 The call to sleep() protects me against the situation in which my
 thread makes a second call to post_message() when activity_message()
 hasn't finished updating the GUI from the first call. 
 
 Is there a way to have my thread call post_message() whenever it
 needs to, and have the messages queue-up?

You do not need the call to sleep().  g_idle_add() will queue up events
in the glib main loop's event list.  Any one main loop is single
threaded.

By the way, why not have your idle function return FALSE instead of
EXIT_SUCCESS? Both evaluate to 0, but returning FALSE is clearer.
EXIT_SUCCESS is a macro intended to provide a process return value
indicating successful execution of the whole process.  (And could in
theory, though not in practice, be a value other than 0.)

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

Re: Delay time to spawn new threads?

[Chris Vine]

On Thu, 28 Nov 2013 14:17:00 +
Emmanuele Bassi eba...@gmail.com wrote:
 GSourceFunc functions should return G_SOURCE_CONTINUE or
 G_SOURCE_REMOVE; those are aliases for boolean values, but are much,
 much clearer to read.

I suggest you put a bug in bugzilla.  The documentation for the main
loop functions such as g_idle_add(), g_timeout_add() and so forth still
refer to returning FALSE.

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

Re: Delay time to spawn new threads?

[Chris Vine]

On Wed, 27 Nov 2013 11:59:23 -0800 (PST)
David Buchan pdbuc...@yahoo.com wrote:
 Hi Michael,
 
 My 32-bit, GTK+2 version does
 
   // Secure glib
   if (!g_thread_supported ()) {
     g_thread_init (NULL);
   }
 
 at the beginning, and then the thread is spawned via:
 
 on_button1_clicked (GtkButton *button1, MyData *data)
 {
   GThread *thread;
   GError *error = NULL;
 
   thread = g_thread_create ((GThreadFunc) my_function, data, FALSE,
 error); if (! thread) {
   g_print (Error: Unable to create new thread for my_function()
 in on_button1_clicked().%s\n, error-message); exit (EXIT_FAILURE);
     }
 
 My 64-bit, GTK+3 versions does not do the g_thread_init() call.
 
 It spawns a new thread via:
 
 int
 on_button1_clicked (GtkButton *button1, MyData *data)
 {
   GThread *thread;
 
   thread = g_thread_new (my_function, (GThreadFunc) my_function,
 data); if (! thread) {
   fprintf (stderr, Error: Unable to create new thread for
 my_function() in on_button1_clicked().\n); exit (EXIT_FAILURE);
     }

Show us your my_function(): you are almost certainly doing something
wrong. Best of all, provide a complete compilable example which
demonstrates the problem. And why are you casting the function pointer
to GThreadFunc?  You do not need to call g_thread_init() with glib =
2.32, and you do with earlier versions. Prior to version 2.24
g_thread_init() had to be the first glib call. Between 2.24 and 2.30 it
had to be the first call relevant to threads.

Also, please don't top post.

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

Re: Printing with GTK/Cairo produces only empty pages

[Chris Vine]

On Mon, 14 Oct 2013 19:34:53 +0200
Satz Klauer satzkla...@googlemail.com wrote:

 Hi,
 
 I try to print some vector data using GTK/Cairo. Unfortunately my
 printer only produces empty pages, means there is no print operation,
 the paper sheets are just moved.
 
 That's how I'm initialising everything:
 
 GtkPrintOperation *op;
 
 op = gtk_print_operation_new();
 gtk_print_operation_set_allow_async(op,TRUE);
 gtk_print_operation_set_n_pages(op, 1);
 gtk_print_operation_set_unit (op,GTK_UNIT_POINTS);
 g_signal_connect (op, draw_page, G_CALLBACK(draw_page), NULL);
 gtk_print_operation_run (op, GTK_PRINT_OPERATION_ACTION_PRINT,NULL,
 NULL);
 
 The print-callback (which is called successfuly) looks like this:
 
 static void draw_page (GtkPrintOperation *operation,GtkPrintContext
 *context,int page_nr)
 {
GtkPrintSettings *settings;
 
cairo_t *cr = gtk_print_context_get_cairo_context (context);
settings = gtk_print_operation_get_print_settings (operation);
cairo_set_source_rgb(dc,0,0,0);
cairo_set_line_width(dc,m_data-config.m_linewidth);
 
cairo_move_to (cr,x0,y0);
cairo_line_to (cr,x1,y1);
cairo_line_to (cr,x2,y2);
...
// some more lines...
 }
 
 What could be missing here? Do I have to close/finish the drawing
 operation somehow?

That depends on what you are trying to draw.  I suspect you are looking
for cairo_stroke(), but you could also consider cairo_fill(). Note also
the *_preserve() variants.

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

Re: GTK free function doesn't appear to have any affect.

[Chris Vine]

On Sun, 16 Jun 2013 12:28:52 +0530
dE de.tec...@gmail.com wrote:
 Apart from that, in the free_ptr? Does memory get freed for anyone
 else?
 
 #include stdio.h
 #include gtk/gtk.h
 #define COLS 200
 void free_ptr ( GtkListStore * );
 
 int main (  ) {
  gtk_init( NULL, NULL );
  int i, j;
  char *temp;
  GtkTreeIter current;
  GType *str_type = g_malloc (sizeof (GType) * COLS);
  for (i = 0; i  COLS; i++)
  str_type [i] = G_TYPE_STRING;
  GtkListStore *store = gtk_list_store_newv (COLS, str_type);
  g_free (str_type);
  for (i = 0; i  30 ; i++) {
  gtk_list_store_append ( store, current );
  for ( j = 0 ; j  COLS ; j++ ) {
  gtk_list_store_set ( store , current , j , Hello world 
 Hello world Hello world!, -1 );
  }
  }
  printf ( freeing after 10 seconds\n );
  sleep (10);
  free_ptr ( store );
  printf (Now freed\n);
  sleep (10);
  return 0;
 }
 
 void free_ptr ( GtkListStore *store ) {
  gtk_list_store_clear (store);
  g_object_unref( G_OBJECT (store) );
 }

You should compile your code with warnings enabled.  Then you would
find out other things about your code (namely that 'temp' is not used).
Apart from that, technically the code is OK and it does destroy the
list store correctly.

Turning to the main point, the thing about your code is that it is
inadequate for detecting memory leakage, because it does not take
account of caching.  To come up with a meaningful test, you need to
rerun the memory-using code more than once in the program.  If you do
so, you will find that on each run other than the first, memory usage
does not increase.  From this I deduce (I hope) that list stores cache
the memory allocated to individual records for reuse. Presumably that
is thought to be an optimization for most uses.  In the pathological
case of a list store with 30 x 300 cells holding allocated strings
that clearly is not the case, but a list store with so many cells would
be unusably slow anyway when used in conjunction with a tree view.

There are various additional things you can do to check memory usage:
see https://developer.gnome.org/glib/2.36/glib-running.html .

For those kinds of pathological cases, you probably need to write your
own tree model which does things the way you want them.

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

Re: GTK free function doesn't appear to have any affect.

[Chris Vine]

On Fri, 14 Jun 2013 21:41:05 +0530
dE de.tec...@gmail.com wrote:
 On 06/14/13 17:02, Matthias Clasen wrote:
  On Fri, Jun 14, 2013 at 3:27 AM, dE de.tec...@gmail.com wrote:
  I was monitoring the memory usage before and after execution of
  g_object_unref and gtk_list_store_clear, and it didnt change the
  memory usage by a bit.
 
  Is this normal (am I doing it right?)?
  What are you monitoring, and how ?
 
  It is i normal that freeing memory does not change the resource
  consumption of the process. The freed memory will be available for
  reuse by malloc, but malloc does not immediately return the memory
  to the OS.
 
 No, filled more than 7GB, swap was at ~350 MB, and then I loaded a
 small table which would otherwise take less than 10 MB memory, but
 the memory usage increased.

Can you post the smallest compilable program which demonstrates your
problem (run with G_SLICE=always-malloc set), and with particulars of
how you are measuring memory usage?  That should identify if you are
doing something wrong with how you are handling the memory in your
program.

Chris

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

Re: GTK free function doesn't appear to have any affect.

[Chris Vine]

On Fri, 14 Jun 2013 23:03:55 +0530
dE de.tec...@gmail.com wrote:
 On 06/14/13 22:09, Chris Vine wrote:
  On Fri, 14 Jun 2013 21:41:05 +0530
  dEde.tec...@gmail.com  wrote:
  On 06/14/13 17:02, Matthias Clasen wrote:
  On Fri, Jun 14, 2013 at 3:27 AM, dEde.tec...@gmail.com  wrote:
  I was monitoring the memory usage before and after execution of
  g_object_unref and gtk_list_store_clear, and it didnt change the
  memory usage by a bit.
 
  Is this normal (am I doing it right?)?
  What are you monitoring, and how ?
 
  It is i normal that freeing memory does not change the resource
  consumption of the process. The freed memory will be available for
  reuse by malloc, but malloc does not immediately return the memory
  to the OS.
  No, filled more than 7GB, swap was at ~350 MB, and then I loaded a
  small table which would otherwise take less than 10 MB memory, but
  the memory usage increased.
  Can you post the smallest compilable program which demonstrates your
  problem (run with G_SLICE=always-malloc set), and with particulars
  of how you are measuring memory usage?  That should identify if you
  are doing something wrong with how you are handling the memory in
  your program.
 
  Chris
 
 
 You can have the whole source code:
 
 http://pastebin.com/4a5DiMsQ
 
 I'd been distributing it around to fix issues.

This isn't going to help I am afraid.

On some general observations on your earlier questions however:

A GtkBuilder object is a plain GObject.  It will be freed by calling
g_object_unref() on it.  That will also cause it to release its
references to the objects it has created.  Whether that will destroy
those created objects depends on whether there are any other
references to them which have been acquired, such as by their having
been put in a container.  If so, then you need to release those other
references as well in order to destroy the created objects and free
their memory.  Top level windows need to have gtk_widget_destroy()
called on them.  If you want to remove a widget from a container or top
level window but keep the container or top level window alive, you can
cause the container to release its reference with
gtk_container_remove().  If you want all containers holding a reference
to a particular GtkWidget to release their references so leading to the
widget's destruction, call gtk_widget_destroy() on the widget.

For plain GObjects, namely those which are not created with a floating
reference (and so are not derived from GInitiallyUnowned/GtkWidget),
to free them you need to have called g_object_unref() on them explicitly
as well as destroy (or remove them from) their container (if any):
except that GtkBuilder will already have done that for you if it
supplies a plain GObject already embedded in a container it has
supplied. For objects derived from GInitiallyUnowned/GtkWidget,
destroying (or removing them from) their container by one of the means
mentioned above is enough.

You may be aware of all that.  If so I am afraid you need to break your
code down to see whether you have discovered a referencing bug (not
likely but possible - I have reported referencing bugs before now), or
you have neglected to release something somewhere.

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

Re: Can I install both GTK+2 and GTK+3?

[Chris Vine]

On Fri, 17 May 2013 03:50:57 +0100
Emmanuele Bassi eba...@gmail.com wrote:
 hi;
 
 yes, you most definitely can have gtk 2.x and gtk 3.x installed on the
 same machine, without them interfering with each other. the shared
 libraries and ancillary files are all parallel installable.
 
 what you cannot do is using gtk 2.x *and* gtk 3.x at the same time, in
 the same process.
 
 if you want to write your application to support both gtk 2.x and 3.x,
 you can do that only by compiling once against gtk 2.x and again
 against gtk 3.x — i.e. you will need two binaries.
 
 targeting gtk 2.x is not a good idea, though, unless you're migrating
 from 2.x to 3.x and you want to have a grace period for your users
 to switch. gtk 3.x is already 2.5 years old, and will be 3 years old
 when 3.10 is released this September.

I wouldn't agree with that.  gtk+-2 is still maintained (the latest
maintenance release is 4 days old) and is a far more stable target.

The introspection bindings for gtk+-3 break at regular intervals (I
gave up on trying write minor tools using gjs/introspection about 2
years ago because of it), and the theming breaks with every release.
Theming is not necessarily an issue for many programs, but
introspection is.

Possibly things might be settling down with gtk+3 now but I have not
seen any announcement that these are considered stable now.  Until there
is more stability I doubt there is any prospect of the big non-gnome
gtk+ applications I use (claws-mail, firefox and libreoffice) moving to
gtk+-3.

Chris
___
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

[Chris Vine]

On Sat, 20 Apr 2013 16:25:50 -0700
Kip Warner k...@thevertigo.com wrote:
 On Sat, 2013-04-20 at 23:35 +0100, Chris Vine wrote:
  If you have a main loop running, this is completely unnecessary,
  unless you are doing something to block the loop, which you
  shouldn't do.
 
 Hey Chris. Although your response was not particularly constructive,
 I'll give you the benefit of the doubt. Perhaps I am doing something
 unnecessary to block the loop which I should not do. Take a look at
 the method defined at 287:

Thank you for your condescension: an interesting way of asking for help.

The code to which you refer does not block, so something else is
blocking the loop. The point you need to understand is that in normal
code there will very rarely be a reason to call while
Gtk.events_pending(): Gtk.main_iteration() in a well behaved
application (although that call does not appear in the file to which
you refer), and it would need special justification and explanation.
Furthermore your original posting appeared to indicate (including the
following within it...) that those iteration calls were made in some
idle handler somewhere, which on the face of it is pointless.

Clearly you are doing something wrong, probably at the design level.
The answer I gave is that most that anyone could give you in the light
of your somewhat incomplete and ambiguous posting.

Chris
___
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

[Chris Vine]

On Sun, 21 Apr 2013 11:33:45 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 On Sat, 20 Apr 2013 16:25:50 -0700
 Kip Warner k...@thevertigo.com wrote:
  On Sat, 2013-04-20 at 23:35 +0100, Chris Vine wrote:
   If you have a main loop running, this is completely unnecessary,
   unless you are doing something to block the loop, which you
   shouldn't do.
  
  Hey Chris. Although your response was not particularly constructive,
  I'll give you the benefit of the doubt. Perhaps I am doing something
  unnecessary to block the loop which I should not do. Take a look at
  the method defined at 287:
 
 Thank you for your condescension: an interesting way of asking for
 help.
 
 The code to which you refer does not block, so something else is
 blocking the loop. The point you need to understand is that in normal
 code there will very rarely be a reason to call while
 Gtk.events_pending(): Gtk.main_iteration() in a well behaved
 application (although that call does not appear in the file to which
 you refer), and it would need special justification and explanation.
 Furthermore your original posting appeared to indicate (including the
 following within it...) that those iteration calls were made in some
 idle handler somewhere, which on the face of it is pointless.

By the way, rather than overt blocking it may just be that the program
is putting more graphical events through the main loop than it can
handle.  Since any one main loop is single threaded there is very
little you can do about that, except reduce the rate at which you pass
events to the main loop.  Since any thread can have its own main loop
you may be able to pass some event-driven work off to another loop,
but any graphical (GDK/GTK) events have to go to the main loop, and
there is no easy way out of that.

Chris
___
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

[Chris Vine]

On Sat, 20 Apr 2013 09:10:11 -0700
Kip Warner k...@thevertigo.com wrote:

 Hey list,
 
 I have a separate thread from the main loop that performs some long
 and resource intensive operation. The GUI displays an animated GIF
 while this process takes place via Gdk.PixbufAnimation. 
 
 Sometimes the animation and the rest of the GUI is very slow to
 repaint and respond to other event messages. What is the best way of
 giving the message pipeline a breather every now and then from
 outside of the main thread?
 
 I was using GObject.idle_add(self._updateGUI, ...) within the worker
 thread to specify a function to be called regularly that could provide
 some other GUI related update tasks, including the following within
 it...
 
 # Pump the Gtk+ event handler...
 while Gtk.events_pending():
 Gtk.main_iteration()
 
 However, my application will crash if I do this with a stack overflow
 within updateGUI. I'm assuming that since idle_add posted the message
 to call the updateGUI callback, when the callback is invoked and
 tries to pump the message pipeline, the method is invoked again
 because it still hasn't cleared itself from the queue.
 
 I could have tried this aforementioned event pump from outside the
 updateGUI callback and done it from within the worker thread, but I
 didn't know if that was thread safe to do.

If you have a main loop running, this is completely unnecessary, unless
you are doing something to block the loop, which you shouldn't do.

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

Re: Porting Between Linux and Windows

[Chris Vine]

On Sat, 23 Jun 2012 18:13:41 -0400 (EDT)
Allin Cottrell cottr...@wfu.edu wrote:
 You say you're learning C++. If you have good reason to do that, 
 then fine, but note that GTK itself is written in C and is 
 C-oriented. Using C++ will complicate matters. You say you're new to 
 this, so let me point out that C and C++ are separate languages and 
 although C++ interfaces for GTK are available (gtkmm) the more 
 standard development path is to use C with GTK.

To put the counter argument for someone who says he is a newbie, I
think you are looking at this from the wrong direction.  The GTK+
headers are in the subset common to C and C++, and can be used in
either language (there is also no need to use gtkmm in C++, and
sometimes good reasons not to do so).

The real question is what language best suits the problem space the
program is trying to solve.  For some things, C++ is better (in my
opinion). With C++11 auto variables, variadic templates and particularly
lambda expressions, it is quicker to write code for some problem areas
using C++ than C. The GTK+ code you write for a graphical interface
will look pretty much the same in either language, if you are not using
a wrapper, for the reasons I have mentioned.

In other words, GTK+ is the servant and not the master in language
choice here.

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

Re: How do I fix the window size?

[Chris Vine]

On Tue, 5 Jun 2012 11:50:42 -0700 (PDT)
Ferdinand Ramirez ramirez.ferdin...@yahoo.com wrote:
 --- On Tue, 6/5/12, James Tappin jtap...@gmail.com wrote:
 
  I think the solution is to place the treeview in a
  gtk_scrolled_window rather than using an hbox and an explicit
  scrollbar. 
 
 The reason for trying out with an explicit hbox is that the column
 headers scroll out of view with a gtk_scrolled_window.

Are you calling gtk_scrolled_window_add_with_viewport()?  If so, use
gtk_container_add() instead, because tree views have native scrolling
capabilities.

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

Re: Identifying a structure by reading it's first field.

[Chris Vine]

On Sat, 02 Jun 2012 00:04:18 -0400
Ernie Wright ern...@comcast.net wrote:
 On 6/1/2012 2:17 PM, Osmo Antero wrote:
 
  I have couple of C structures that I want to distinguish between by
  reading the structures' first (type) field.  [...]
  
  Q:  Can I assume that the type field is always first in the
  structures, so I can read it with: NodeType type = *(NodeType*)node;
 
 Yes.  Structure members are stored in the order in which they're
 defined, and a pointer to a structure also points to its first member
 (suitably cast).  This is guaranteed by the C standards.
 
  but can I trust it on all *nix plattforms and GCC compilers.
 
 Anything that's standards-compliant.

Osmo,

You are probably also interested in the strict aliasing rule, as well
as alignment.  If not, you ought to be, as the strict aliasing rule
does not permit casting a pointer from one type to a different type and
then dereferencing the pointer pointing to that different type, except
in certain defined circumstances (one of which is that you can always
cast to char* and dereference, and another of which is that you can
always cast back to the original type and dereference). This is an
alarmingly often overlooked rule.

As it happens, your proposed cast is permitted as an exception to the
strict aliasing rule (C99 6.5/7, fifth bullet), to allow the poor man's
inheritance in C that you seem to be implementing, and which is used for
example by GObject.

In a different posting on this list, you seemed to indicate you were
using C++.  If so, you would be better off either using the C++ typeid
system with a virtual method, or use templates with partial
specialization.  The compiler will then do all the work for you in a
less error-prone way.

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

Re: Identifying a structure by reading it's first field.

[Chris Vine]

On Sat, 02 Jun 2012 09:10:06 -0400
Ernie Wright ern...@comcast.net wrote:
 On 6/2/2012 6:16 AM, Chris Vine wrote:
 
  You are probably also interested in the strict aliasing rule, [...]
  This is an alarmingly often overlooked rule.
 
 In part because it wasn't in the standard prior to C99, which isn't
 supported to the degree C90 is.

It was in C89 - §6.3:

  An object shall have its stored value accessed only by an lvalue
  that has one of the following types:

  * the declared type of the object,

  * a qualified version of the declared type of the object,

  * a type that is the signed or unsigned type corresponding to the
declared type of the object,

  * a type that is the signed or unsigned type corresponding to a
qualified version of the declared type of the object,

  * an aggregate or union type that includes one of the
aforementioned types among its members (including, recursively,
a member of a subaggregate or contained union), or

  * a character type.

It is the fifth bullet point which permits your usage.  Not many
1990-vintage compilers used strict aliasing for optimization, but most
(all?) now do with a sufficiently high optimizing level.

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

Re: Help with a multi-threaded application. Spot a crash.

[Chris Vine]

On Fri, 1 Jun 2012 09:23:35 +0100
jcup...@gmail.com wrote:
 Hi again Osmo,
 
 On 31 May 2012 17:50, Osmo Antero osm...@gmail.com wrote:
  Jcupitt:
  Ok, g_idle_add() seems to need protection by gdk_threads_enter() and
  leave().
  Ref:
  http://developer.gnome.org/gdk/stable/gdk-Threads.html#gdk-threads-add-idle
 
 That's out of date. g_idle_add() does not need any locking by you.

I think you may be confusing this with the fact that with glib = 2.32
it is no longer necessary to call g_thread_init() to make glib thread
safe, which is of course a completely different issue.

There is a proposal to deprecate the use of the GDK global lock, but in
a program which does use it, g_idle_add() does not exempt you from the
need to invoke the global lock in idle callbacks, either by doing it in
the idle callback yourself or by calling gdk_threads_add_idle().

The better approach is not to use the GDK global lock.

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

Re: Help with a multi-threaded application. Spot a crash.

[Chris Vine]

On Fri, 1 Jun 2012 22:00:35 +0100
jcup...@gmail.com wrote:
 On 1 June 2012 20:41, Chris Vine ch...@cvine.freeserve.co.uk wrote:
  jcup...@gmail.com wrote:
  That's out of date. g_idle_add() does not need any locking by you.
 
  I think you may be confusing this with the fact that with glib =
  2.32 it is no longer necessary to call g_thread_init() to make glib
  thread safe, which is of course a completely different issue.
 
  There is a proposal to deprecate the use of the GDK global lock,
  but in a program which does use it, g_idle_add() does not exempt
  you from the need to invoke the global lock in idle callbacks,
  either by doing it in the idle callback yourself or by calling
  gdk_threads_add_idle().
 
 I think we must be talking at cross-purposes. g_thread_init() is
 becoming optional (it will always be called for you), but you've never
 needed to lock either around calls to g_idle_add() and friends, or in
 the handler when it is invoked, since it is run by the main loop.
 
 For example, I posted some sample code ages ago (scroll down a bit):
 
 http://old.nabble.com/g_main_loop-and-g_async_queue-td21288177.html
 
 Or have I missed something horribly?

I am not sure if you have missed anything, but you said
that the documentation on gdk_threads_add_idle() is out of date.  It
isn't (to the best of my knowledge), nor has the position with respect
to g_idle_add() changed.

Perhaps you were intending to say that if you don't you use the GDK
global lock and allow worker threads to address GTK+ via g_idle_add(),
but don't need to lock the GDK global lock.  Whilst true, that has
always been the case.

Chris

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

Re: key press events holding keys down

[Chris Vine]

On Sun, 18 Mar 2012 20:08:12 -0800
Christopher Howard christopher.how...@frigidcode.com wrote:
 On 03/16/2012 04:29 PM, Christopher Howard wrote:
  
  I control the spacecraft with the arrow keys, which I do by
  grabbing the GdkEventKey and then checking it against GDK_KEY_Left,
  GDK_KEY_Right, and so forth. Strictly speaking what I am concerned
  with is whether or not the key is held down, but this seems to work
  because the key event gets repeated.
  
  However, if one of the arrows is held down, and another arrow is
  pressed, then it shuts off events for the first arrow. That's bad,
  of course, because in my game the player may want to hold down two
  arrows keys at once (e.g., UP for acceleration and LEFT to turn the
  spacecraft). So...
  
 
 Okay, having got no responses, let me ask the question in a more
 direct manner: under Gtk+, how does one check whether or not any
 particular keyboard key is currently pressed? I know this is possible
 because I used to do it back in my ClanLib days.
 
 I see in the Gdk docs that there is a GdkDevice object, but it is not
 clear to me how to create or utilize this to such an end.

Since GtkWidget objects have key-press-event and a key-release-event
signals that you can connect to (and from your explanation, clearly you
have connected to), you will probably need to explain why these don't do
what you want in order to get a meaningful answer. Most people would
monitor these in conjunction with gdk_event_get_keyval() or
gdk_event_get_keycode() and keep state.

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

Re: key press events holding keys down

[Chris Vine]

On Mon, 19 Mar 2012 09:21:27 -0800
Christopher Howard christopher.how...@frigidcode.com wrote:
 On 03/19/2012 03:34 AM, Chris Vine wrote:
  Since GtkWidget objects have key-press-event and a key-release-event
  signals that you can connect to (and from your explanation, clearly
  you have connected to), you will probably need to explain why these
  don't do what you want in order to get a meaningful answer. Most
  people would monitor these in conjunction with
  gdk_event_get_keyval() or gdk_event_get_keycode() and keep state.
  
  Chris
 
 I'm currently attempting to code a simple space combat game. In my
 game it is possible (quite likely) that two keys will be held down at
 the same time (especially the up arrow and another arrow) e.g. to
 turn and to accelerate at the same time. Currently I monitor for key
 press events as you say; the problem is that key press events are
 only being generated for the last key that was pressed. So if a user
 attempts to turn and accelerate at the same time, he will actually
 only do one or the other, depending on which key he happened to press
 last.

A key remains pressed until a key-release-event for it is received.
That is what I meant by 'keep state'.

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

Re: Beyond GDK threads and gtk_dialog_run - What to use?

[Chris Vine]

On Tue, 6 Mar 2012 17:15:21 +0100
Žan Doberšek zandober...@gmail.com wrote:
 I'm running an effort to add support for modal dialogs in WebKitGTK+,
 bug report is located at WebKit's bugzilla[1]. When a web page
 requests a modal dialog, the user agent is required to create a new
 window that will represent the modal dialog, set it transient to its
 parent and set it as modal. The window will be shown and after that
 the WebKit library will take over, running a loop to prevent user
 interaction with other windows. When the modal dialog window is
 closed, the loop is ended.
 
 gtk_dialog_run was a perfect example to follow, using main loops with
 GDK_THREADS_LEAVE and GDK_THREADS_ENTER calls. These, however, seem
 to be on their way to become deprecated.[2] WebKitGTK+ should,
 however, still provide the modal effect when modal dialogs are to be
 shown and run (i.e. there's no signals or similar workarounds as with
 gtk_dialog_run), meaning a main loop should probably be established
 and run until the dialog itself is destroyed.
 
 I'd like some input on what's the best and most (thread-)safe way to
 set up the main loop or if there are any other options to avoid using
 GDK threads calls and make the implementation future-complaint today.

You could test for the symbol GTK_DISABLE_DEPRECATED and for the gtk+
version with GTK_CHECK_VERSION, in order to conditionally compile the
calls to GDK_THREADS_LEAVE and GDK_THREADS_ENTER, if you think you need
to do that.  If so, you would have to make sure that all other calls to
the GDK global lock in webkit-gtk (if any) are similarly removed.  All
that these calls do is to unlock and lock the GDK global lock
respectively if gdk_threads_init() has been called where the X11
backend is in use: otherwise I think they are no-ops.

If you are also concerned about the proposed deprecation of
gtk_dialog_run() as you say I should ignore it unless you also feel
compelled to force users to connect to a response signal to run their
continuations.  It seems odd that the GTK+ developers should want to do
this however, as a blocking 'run' call is a common GUI programming
idiom for modal dialogs and I don't know of any proposal corresponding
proposal to deprecate nested main loops in glib.  However, you may want
to inquire on the gtk-devel list why this proposal has been made.

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

Re: Are there such tings like custom signals?

[Chris Vine]

On Mon, 23 Jan 2012 08:41:22 -0700
Michael Torrie torr...@gmail.com wrote:
 On 01/23/2012 02:18 AM, Manuel Ferrero wrote:
  Il 20/01/2012 18.08, Jack ha scritto:
  
  However, that is separate from knowing that the button has been
  pushed, so you can then start the communications. For this, is
  there any reason to use a custom signal? Wouldn't it be easier to
  catch the standard signal emitted when a button is pushed, by
  attaching a call-back routine?
  
  Infact there is no need for a custom signal once you know about
  GIOChannel. But my question was intended for general cases. If I
  need to trigger a complicated task when a button is pushed I'll
  write a callback to manage the standard signal in which I'll start
  my $COMPLEX_PROCESS then return. The question was about how to
  write $COMPLEX_PROCESS: it doesn't involve GUI so it doesn't have
  any standard signal, but I'd like to have the signal-callback
  paradigm and I was wondering if GTK gives me some tool or if I have
  to rely on an external infrastructure for it.
 
 GTK indeed gives you a tool for generating your own signals.  You can
 then catch them normally.

This runs the risk of being horribly misunderstood.  You don't catch
emissions from GSignal objects, you connect to them (you catch unix/C
asynchronous signals and interrupts).  And rather than generating a
GSignal, you implement a GObject which registers the signal in its
class init function to connect to, and emit on the signal.

But the OP's reference to GIOChannels (which don't use GSignals) may
indicate that he wants something different, namely to execute an event
in a glib main loop.  g_idle_add() is available for that.

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

Re: Forcing a G Timeout to be handled by a specific thread

[Chris Vine]

On Wed, 05 Oct 2011 14:00:40 +0100
Andrew Wood a@me.com wrote:
 Is there a way to ensure a timeout callback set with g_timeout_add is 
 always executed by a specific pthread?

Timeouts started with g_timeout_add() or g_timeout_add_full() execute
in the default main context, which is normally the main context
of the thread with which the program begins and which first creates a
main loop (as by, for example, calling gtk_main()/g_main_loop_run()).

If you have more than a worker thread with its own main loop and you
want the timeout to execute in the worker thread's main loop, you have
to create a timeout source with g_timeout_source_new() and attach it to
the worker thread's main context with g_source_attach().

Chris


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

Re: Simple GTKMM front-end

[Chris Vine]

On Wed, 21 Sep 2011 07:13:56 +0100
John Emmas john...@tiscali.co.uk wrote:
 An interesting point.  Technically, the Library GPL and the
 Lesser GPL aren't the same document - even though they might have
 the same wording.  Just as a loan agreement signed by me isn't the
 same legal instrument as one signed by my neighbour - even though
 they might come from the same lender and have identical wording.  The
 original Lesser GPL has been superseded and programmers using Lesser
 GPL code are often free to choose version 2 or later, at their
 discretion.  However, gtkmm isn't released under the Lesser GPL.
 It's released under the Library GPL which I suspect isn't the same
 legal instrument as the one that that got superseded.
 
 As with most legal documents, the only people they tend to benefit
 are the lawyers..!

Your views are highly idiosyncractic (to choose a more neutral
expression than FUD).  On looking at the source files, I see that it is
in fact GTK+ which is released under the LGPL-2 or later, at the choice
of the user. gtkmm is released under the the LGPL-2.1 or later at the
choice of the user.

The LGPL-2.1 itself says This is the first released version of the
Lesser GPL.  It also counts as the successor of the GNU Library Public
License, version 2, hence the version number 2.1.  Where a licence
includes the words or (at your option) any later version, the
licensee in effect allows a user to adopt any license which the FSF say
is a later version of the original license.  Some developers (the linux
kernel developers in particular) do not like this, and do not include
the or (at your option) any later version.  However, GTK+ and gtkmm
do include those words.

In any event, your later versions point is immaterial to your view
that the LGPL-2 and 2.1 do not allow derived works which only link
dynamically to the library, because both use exactly the same words.  It
is also completely contrary to the purpose of the LPGL, which is clearly
intended to allow dynamic linking without applying restrictions of use
to the object code.

Your views seem to be intended to discourage the original poster from
adopting GTK+/gtkmm. You no doubt have your own reasons for
discouraging commercial use of GTK+, but as I say that is clearly
contrary to the intention of the licence and of the GTK+ project.

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

Re: Simple GTKMM front-end

[Chris Vine]

On Wed, 21 Sep 2011 16:50:29 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 [ship] Some developers (the
 linux kernel developers in particular) do not like this, and do not
 include the or (at your option) any later version.

I should say that I realise that the kernel is released under the GPL
and not the LGPL, but the same point on this applies.

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

Re: GtkTree and GtkThread: update and refresh

[Chris Vine]

On Wed, 21 Sep 2011 22:53:01 +0200
Paolo pra...@gmail.com wrote:
 Hi! I have a problem about the update and refresh of a tree. This is
 the situation: I have a populated tree and a button that update the
 tree. The button's event calls a function that permorfs the following
 things: 1) Reset the treemodel appending a single text row Loading
 2) Execute a db query
 3) Reset the treemodel appending the results of the query
 No errors, but a refresh problem. I can't see the text row
 Loading (1st step); I can just see the new populated tree (3th
 step).
 
 I could put the following code between the step 1 and 2:
 
   while(gtk_events_pending())
   gtk_main_iteration();
 
 This solution works but it blocks the whole GUI.
 A thread can help me for the GUI block and the pending events, but I
 have another problem: after several clicks of the button the program
 blocks. I don't know what happen: no errors, no segmentation fault.
 
 Is it correct create a thread for each event of the button in that
 way?
 
 g_thread_create((GThreadFunc)
 loading_tree_and_the_fill_tree, NULL, FALSE, err)

Read
http://developer.gnome.org/gdk/stable/gdk-Threads.html#gdk-Threads.description
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Simple GTKMM front-end

[Chris Vine]

On Tue, 20 Sep 2011 21:26:31 +0100
John Emmas john...@tiscali.co.uk wrote:
 On 20 Sep 2011, at 07:11, Andy Tai wrote:
 
  come on... gtkmm is LGPL...
  
 
 Interesting  I just checked this on the gtkmm web site and
 discovered that it's actually released under the GNU Library General
 Public License.  After further reading it seems that inclusion of
 the word Library indicates that this is an old version of what
 later morphed into the Lesser General Public License or LGPL.
 Technically though, it's neither GPL nor LGPL in the modern sense.
 Clause 5 of the Library General Public License states:-
 
  linking a work that uses the Library with the Library creates an
 executable that is a derivative of the Library
 
 [...]
 
  if the work is a derivative of the Library, you may distribute the
 object code for the work under the terms of Section 6. Any
 executables containing that work also fall under Section 6, whether
 or not they are linked directly with the Library itself. 
 
 However, sections 6 and 2 seem to state the you need only distribute
 the source code for any changes you made to the library.  For example
 if your executable uses classes derived from gtkmm, you must release
 those classes (and any modifications that were needed to gtkmm) as a
 new library in its own right.  However, those parts of the executable
 which make no use of gtkmm do not need to be released.
 
 So it's probably closer to the LGPL than to the GPL but you might
 still need to release parts of your source code.

As far as I am aware the only difference between the Library General
Public Licence v2, and the Lesser General Public Licence v2.1 is the
change of name.

gtkmm is released under the LGPL-2.0 or later, at the choice of the
user. That includes the LGPL-3.0, which would be the choice of any C++
developer because of the template exemption.

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

Re: Can g_file_monitor_file () report events from before it was created?

[Chris Vine]

On Tue, 06 Sep 2011 01:42:43 +0100
Peter Clifton pc...@cam.ac.uk wrote:
 I'm working on some code to monitor for file changes in our
 application, and ran into a bit of a problem today with the Save-As
 case.
 
 The order of operations is something like:
 
 1. File monitor exists on the document file which was loaded last
 2. User hits File-Save as.. (and enters a filename)
 3. Core of app saves file into the new file name
 4. File monitor does not fire, as the saved file is not the one being
 monitored 5. Core of app notifies the GUI (with the file monitor)
 that the document we should be watching is now in the new filename.
 6. g_object_unref() the old file monitor 7. Create new file monitor
 on the new file.
 
 After this happens, I actually get a change event fire from the new
 file monitor - despite the changes having been saved by the app's core
 (fopen / fclose directly to the file in question), before I even
 created the file monitor.
 
 Is it possible that Glib / GIO is caching some state incorrectly, and
 spotting on-disk changes from _before_ I created the file monitor, or
 is it more likely that the file doesn't hit the disk until some time
 after I fclose() it - and that it spots the change at this point in
 time?

Does it help if you call fsync() on the underlying file descriptor
after calling fclose() (assuming you are using a unix-like OS)?  That
should at least force the write onto the hardware, so far as the kernel
is concerned.

From the man page of close(): A  successful close does not guarantee
that the data has been successfully saved to disk, as the kernel defers
writes.  It is not common for a file system to flush the buffers when
the stream is closed.  If you need to be sure that the  data  is
physically stored use fsync(2).  (It will depend on the disk hardware
at this point.)

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

Re: Strange dead lock with g_threads_enter

[Chris Vine]

On Sun, 6 Mar 2011 10:57:24 +0800
Wei-Ning Huang aitjc...@gmail.com wrote:
 Thanks Chris. I tried to remove any function call in the
 compile_thread, i.e:
 
 // Thread function
 // It is signaled to wake up for every 1 second
 gpointer motion_compile_thread(gpointer data) {
 ...
while (TRUE) {
  if (!g_mutex_trylock(cp_mutex)) continue;
  g_cond_wait(compile_cv, cp_mutex);
  g_mutex_unlock(mutex);
 }
 
 Now that what the thread does is simply wake up every 1 second
 (signaled by the main thread) and go back to sleep.
 It STILL deadlocked!!!
 I tried running this on ubuntu 10.10, and it worked perfectly fine (no
 deadlock)

Well, everything depends on what is in your   When the thread
reacquires the mutex when g_cond_wait() returns or through the trylock,
that may involve itself in a sequence of out-of-order locking with
another thread, if your ... involves acquiring and holding a
second lock apart from your cp_mutex, or it involves acquiring the gdk
global lock.  (Your while loop could of course also create a livelock,
since it doesnt perform a yield, although I doubt that is your issue
here.)

 I'm starting to think it's the bug of gtk+, or perhaps the kernel?
 btw, I'm using Arch Linux with Kernel 2.6.37(autogroup patched), Gtk+
 2.22.
 
 SI once suspect that it maybe something to do with the autogroup
 patch I'm using, so I switch to the
 default 2.6.37 kernel. The result is the same.. still deadlocks.
 
 frustrated ... (but glad that this didn't happen on ubuntu)

In theory it could be a bug in glib, gtk+ or the kernel.  If, say, your
motion_compile_thread() function is the only function executed by the
test thread and never acquires any other locks than your test mutex,
and you do not have a livelock, then I think you are right to be worried
about that. Otherwise, it is more likely to be a bug in your code, and
the fact that it works on ubuntu is not particularly indicative of
anything, since this may just be the result of timing differences or
different scheduling policies.

I assume incidentally that you have correctly initialised glib for
threading?

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

Re: Strange dead lock with g_threads_enter

[Chris Vine]

On Sun, 6 Mar 2011 16:03:43 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 On Sun, 6 Mar 2011 10:57:24 +0800
 Wei-Ning Huang aitjc...@gmail.com wrote:
[snip]
  I'm starting to think it's the bug of gtk+, or perhaps the
kernel?
  btw, I'm using Arch Linux with Kernel 2.6.37(autogroup patched),
  Gtk+ 2.22.
  
  SI once suspect that it maybe something to do with the autogroup
  patch I'm using, so I switch to the
  default 2.6.37 kernel. The result is the same.. still deadlocks.
  
  frustrated ... (but glad that this didn't happen on ubuntu)
 
 In theory it could be a bug in glib, gtk+ or the kernel.  If, say,
 your motion_compile_thread() function is the only function executed
 by the test thread and never acquires any other locks than your test
 mutex, and you do not have a livelock, then I think you are right to
 be worried about that. Otherwise, it is more likely to be a bug in
 your code, and the fact that it works on ubuntu is not particularly
 indicative of anything, since this may just be the result of timing
 differences or different scheduling policies.

By the way, your first code did not treat the gdk global lock as 'Lock
1' and you did not indicate in your latest e-mail whether you have
corrected that: I should not even think about a glib/gtk+/kernel bug
until you have done so.

To take an example, if your test thread is started from a gtk+ signal
handler, the thread will be started holding the gdk global lock, and
therefore your 'while' loop will acquire 'cp_mutex' holding that lock.
If another thread calls gdk_threads_enter() while holding cp_mutex, you
are in line for a deadlock just from that.

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

Re: Strange dead lock with g_threads_enter

[Chris Vine]

On Sat, 5 Mar 2011 11:58:23 +0800
Wei-Ning Huang aitjc...@gmail.com wrote:
[snip]
 From what I can see, the program is stuck because the main thread
 locked a mutex in #3.
 But from the backtrace, the mutex seems to be locked by
 gtk_main_loop_run() which is something I can't control,
 and somehow it locked the same mutex as gdk_threads_enter()? any
 ideas?

If it isn't recursion then somewhere in your '' you probably have
out-of-order locking.

I should start by making the gdk global lock 'Lock 1' and work from
there. In other words, don't call gdk_threads_enter() when you are
holding a lock of your own.  Also, don't call gdk_threads_enter() in a
GTK+ signal handler because it will already be locked there.  (But that
is not true of ordinary glib main loop events.)

Best of all, don't use the global lock at all but instead invoke
callbacks in the main loop with g_idle_add().   This is a cleaner
design and also has the benefit of making your program portable to
windows and other non-X11 platforms.

Chris


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

Re: Using GSocket in a GTK application

[Chris Vine]

On Tue, 22 Feb 2011 23:25:43 -0500
Jacques Pelletier jpellet...@ieee.org wrote:
[snip]
 ...
 /* Connect asynchronously */
   mySocketClient = g_socket_client_new();
 
   g_socket_client_connect_to_host_async(
 mySocketClient,
 myUrl,
 myPort,
 NULL,
 my_client_connect_async_function,
 NULL);
 ...
 
 
 void my_client_connect_async_function(GObject *source_object,
   GAsyncResult *res,
   gpointer user_data)
 {
   mySocketConnection = 
 g_socket_client_connect_to_host_finish(source_object,res,NULL);
 
   if (mySocketConnection != NULL)
 {
   mySocket = g_socket_connection_get_socket(mySocketConnection);
   mySource = g_socket_create_source(mySocket,
   G_IO_IN
 | G_IO_PRI | G_IO_NVAL, NULL);
   g_source_set_callback(mySource, myCallback,NULL,NULL);
   mySource_id = g_source_attach(mySource,NULL);
 
   /* Instructions for updating the GUI */
 }
   else
   {
   /* Socket connection failed */
   }
 }
 
 /* Process incoming data from socket */
 gboolean myCallback(GSocket *source, GIOCondition condition, gpointer
 data) {
   int Input_Length;
   gchar Receive_Buffer[1024];
 
   switch (condition)
   {
 /* Check for socket error */
   case (G_IO_ERR | G_IO_HUP):
   case G_IO_HUP:
   g_message(Socket error HUP\n);
 PortClose();
   goto error;
 
   case (G_IO_ERR | G_IO_NVAL):
   case (G_IO_NVAL):
   g_message(Socket error NVAL\n);
   goto error;
 
 /* Check for data to be read (or if the socket was closed)
 */ case G_IO_IN:
 Input_Length = g_socket_receive(source, (gchar 
 *)Receive_Buffer,1024,NULL,NULL);
 if (Input_Length != -1)
   {
   /* Update GUI according to the received data
 */ MyGuiUpdate(Receive_Buffer,Input_Length);
   }
 break;
 
   default:
 ;
   } /* condition */
 
   /* Returns TRUE so it remains installed until we remove it */
   return TRUE;
 
  error:
   return FALSE;
 }
 
 void SocketClose(void)
 {
   g_socket_close(mySocket,NULL);
   g_object_unref(mySocketConnection);
   g_object_unref(mySocketClient);
   g_source_unref(mySource);
 }
 
 
 Any comments about how to improve, missing code, etc.?

Your callback seems to rely on the ability reliably to detect an
end-of-file on the socket by means of the G_IO_HUP revent poll
condition. However, you can't rely on that: see
http://www.greenend.org.uk/rjk/2001/06/poll.html .

From looking at the implemention of g_socket_receive_with_blocking() in
gio's socket.c, g_socket_receive() returns 0 (like recv()/read())
rather than returning -1 and an error, on encountering end-of-file (to
that extent the statement in the documentation that if the socket is
in blocking mode the call will block until there is some data to
receive or there is an error appears to be wrong, since it will also
unblock on orderly close down of the remote peer). However, your code
doesn't act on either outcome from g_socket_receive().

I also didn't understand your switch fall-throughs - I avoid bit
testing in switch statements - but they appear to treat G_IO_ERR and
G_IO_HUP as the same, and view G_IO_HUP as an error, which it isn't
except in the limited sense that you don't expect the server to close
its end first. A G_IO_HUP event will become G_IO_ERR on further read
attempts of course, and maybe that was your design approach on that
point, except that your switch statements don't accommodate a case where
the G_IO_ERR flag is set and none of the others are.

On a minor point, in this kind of usage I always call g_source_unref()
immediately after g_source_attach() (g_source_attach() will increment
the reference count).  This saves having to call it in SocketClose()
(instead the source object will be destroyed as soon as the callback
returns FALSE).  As it happens, SocketCLose() isn't called in your code
snippet but no doubt something else does that.

As someone else has mentioned however, GSocketConnection inherits from
GIOStream, and if you use the GIOStream interface you can do an
asynchronous read with g_input_stream_read_async() via
g_io_stream_get_input_stream(), which does all this stuff for you.

Chris


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

Re: Localization issues

[Chris Vine]

On Wed, 29 Dec 2010 17:11:47 +0530
Lourembam Lenin lenin...@gmail.com wrote:
 I have a text in English which i want to convert it into French.
 
 The sequence that i followed are as under:
 
1. generate all the text using xgettext command in terminal,
 creating .pot file
2. creating .po file from .pot file
3. creating .mo file from .po file
 
 I have copy the .mo file in /usr/share/locale/fr/LC_MESSAGES
 
 here is my code for main.c file:
 
 int main()
 
 {
 
 setlocale(LC_ALL,);
 bindtextdomain(main,/usr/share/locale);
 textdomain(main);
 printf( gettext(Hello world\n));
 return (0);
 }
 
 But when i execute the program, french version is not printed on
 terminal after changing the language to french.

You shouldn't copy your po file by hand: if your program is
gettextize'd then 'make install' will do it for you, with the correct
name.  In your case, if you were to copy it by hand you would need to
name it main.po, which is a very odd name.  Bind to a more sensible name
instead.

You might also want to call bind_textdomain_codeset() depending on what
codeset you are using.

For managing your translation files, I should use intltools.

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

Re: Localization issues

[Chris Vine]

On Thu, 30 Dec 2010 10:53:15 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:

 On Wed, 29 Dec 2010 17:11:47 +0530
 Lourembam Lenin lenin...@gmail.com wrote:
  I have a text in English which i want to convert it into French.
  
  The sequence that i followed are as under:
  
 1. generate all the text using xgettext command in terminal,
  creating .pot file
 2. creating .po file from .pot file
 3. creating .mo file from .po file
  
  I have copy the .mo file in /usr/share/locale/fr/LC_MESSAGES
  
  here is my code for main.c file:
  
  int main()
  
  {
  
  setlocale(LC_ALL,);
  bindtextdomain(main,/usr/share/locale);
  textdomain(main);
  printf( gettext(Hello world\n));
  return (0);
  }
  
  But when i execute the program, french version is not printed on
  terminal after changing the language to french.
 
 You shouldn't copy your po file by hand: if your program is
 gettextize'd then 'make install' will do it for you, with the correct
 name.  In your case, if you were to copy it by hand you would need to
 name it main.po, which is a very odd name.

Correction: that is main.mo of course, copied from your gmo file.

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

Re: Glib mutex doesn't work on Windows

[Chris Vine]

On Thu, 16 Dec 2010 12:17:51 -0700
Kevin DeKorte kdeko...@gmail.com wrote:
[snip] 
 I had this problem developing a GTK application on OpenBSD, it seems
 that GMutex's are not guaranteed to be recursive or non-recursive.
 
 I altered my code to work with GConditionals and worked fine. Perhaps,
 that will work for you as well.
 
 http://kdekorte.blogspot.com/2009/01/gnome-mplayer-094-will-work-with-bsds.html
 
 Kevin

This is irrelevant, as the OP's code example does not do recursive
locking.

It is highly unlikely that glib mutexes do not work on windows, and
that the OP is the first person to notice this.  It is much more likely
that his code is defective.  One suspicious feature is that his test
case for GMutex starts a thread using the windows API rather than glib's
API. That is not of itself an error, but it invites the question
whether, for example, he has called g_thread_init().

To the OP: you need to provide a complete compilable test case,
including your code in main(), to demonstrate the problem.  You should
be able to do that in no more than 20 lines of code with something as
simple as this.

Chris



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

Re: Glib mutex doesn't work on Windows

[Chris Vine]

On Thu, 16 Dec 2010 21:15:36 +
Chris Vine ch...@cvine.freeserve.co.uk wrote:
 On Thu, 16 Dec 2010 12:17:51 -0700
 Kevin DeKorte kdeko...@gmail.com wrote:
 [snip] 
  I had this problem developing a GTK application on OpenBSD, it seems
  that GMutex's are not guaranteed to be recursive or non-recursive.
  
  I altered my code to work with GConditionals and worked fine.
  Perhaps, that will work for you as well.
  
  http://kdekorte.blogspot.com/2009/01/gnome-mplayer-094-will-work-with-bsds.html
  
  Kevin
 
 This is irrelevant, as the OP's code example does not do recursive
 locking.
 
 It is highly unlikely that glib mutexes do not work on windows, and
 that the OP is the first person to notice this.  It is much more
 likely that his code is defective.  One suspicious feature is that
 his test case for GMutex starts a thread using the windows API rather
 than glib's API. That is not of itself an error, but it invites the
 question whether, for example, he has called g_thread_init().
 
 To the OP: you need to provide a complete compilable test case,
 including your code in main(), to demonstrate the problem.  You should
 be able to do that in no more than 20 lines of code with something as
 simple as this.

Looking at your web page, it looks as if what you were trying to do was
unlock a mutex in a different thread from the one which owns (ie has
locked) the mutex.  It so happens that although that is not
allowed by POSIX, linux-based pthreads implementations do permit this,
whereas BSD sticks to the standard and does not (windows critical
sections do not permit it either). You should be using condition
variables in that usage, as you found out.

Again, this is not relevant to the OP's test case.

Chris



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

Re: gthreads vs pthread

[Chris Vine]

On Tue, 26 Oct 2010 22:41:44 +
Juan Pablo L. jpablolorenze...@hotmail.com wrote:
 Hello, i m using threads in a glib-only project, a service daemon, i
 have implemented them using GThreads, but i see now that GThreads is
 only a wrapper around pthreads (with the corresponding overhead from
 doing so) and does not provide any additional benefit (if i dont
 mistake the only real benefit is the cross platform feature).
[snip]

I doubt very much you will notice any difference.  Compared to the
overhead of starting new threads and potential contention on mutexes,
wrapping costs are likely to be negligible.  There is a case for using
pthread directly if you are using your own wrappers for automatic
lifetime management and exception safety in, say, C++, or if you want
to use thread cancellation, or the small number of other features
supported by pthread but not by GThreads.

 1. if i dont issue the g_thread_init, at the beginning of my
 application, will there be any problem in glib itself? some functions
 or functionality willl cease to work or work incorrectly ?

You must call g_thread_init() if more than one thread might call glib
functions in order to make glib thread safe.  So call g_thread_init() in
a multi-threaded program.

 2. Can i
 just use Glib with pthread instead of GThread ? i know that the main
 loop and GAsyncQueue will work out of the box.

Yes, provided you have called g_thread_init().

 3. The documentation
 says that by issuing g_thread_init Glib will become thread safe, i
 dont understand this, if i dont issue the command Glib will not work
 in a multithreated environment ?

It won't, no.  See above.

 4. If in the future i use glib in
 another project and decided to use pthread in my code but i know GTK
 uses GThread inside, will this be a problem? will it be overhead
 because i would be using pthreads and GThread together ?

No.  As you have already deduced, GThread is a wrapper for pthread in
unix-like environments.

Chris


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

Re: poll with timeout 0 in main loop

[Chris Vine]

On Fri, 22 Oct 2010 10:37:01 +
Juan Pablo L. jpablolorenze...@hotmail.com wrote:
 i attached the code but did not make thru, here is the server code:

Something odd is going on.

I see you are using GIOChannel not to do any reading, but in order to
notify you that a connection is available.  poll()/select() of course
support this in unix-like systems, but I don't know if GIOChannel
does (I have never tried). Possibly it only works if you set the channel
as non-blocking with g_io_channel_set_flags() rather than by
manipulating the file descriptor directly, which you have done.  Again,
I don't know.

Sending snippets of code really isn't going to help.  It could of
course be other things, such as you not having initialized glib for
threads correctly. You need to send the simplest test case which
demonstrates the problem, in compilable form: given the nature of
the problem you should be able to reproduce it with very simple code.

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

Re: poll with timeout 0 in main loop

[Chris Vine]

On Fri, 22 Oct 2010 13:53:55 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:

 On Fri, 22 Oct 2010 10:37:01 +
 Juan Pablo L. jpablolorenze...@hotmail.com wrote:
  i attached the code but did not make thru, here is the server code:
 
 Something odd is going on.
 
 I see you are using GIOChannel not to do any reading, but in order to
 notify you that a connection is available.  poll()/select() of course
 support this in unix-like systems, but I don't know if GIOChannel
 does (I have never tried). Possibly it only works if you set the
 channel as non-blocking with g_io_channel_set_flags() rather than by
 manipulating the file descriptor directly, which you have done.
 Again, I don't know.

Actually, in this usage (attaching the file descriptor of a listening
socket to a main loop) there is no need to make the file descriptor
non-blocking since you will not make any blocking calls on it until you
actually get to call accept() to establish the connection, and you may
get undefined behaviour if you do - I don't know what POSIX says about
that when you attempt to use poll() with it.  Once poll() indicates
that a connection is available, accept() can't block anyway.

Does it work if you omit your call to fctl()?

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

Re: Performance issues of GDK deprecation in favour of Cairo

[Chris Vine]

On Tue, 17 Aug 2010 10:01:43 +0100
James Morris ja...@jwm-art.net wrote:

 I see that some GDK drawing functions and graphics contexts have been
 deprecated in favour of using Cairo.
 
 Yesterday I spent a few hours *removing* Cairo code from my fledgling
 GTK application and replacing it with gdk_draw_rectangle,
 gdk_gc_set_rgb_fg_color, and gdk_gc_set_function. I did this for
 performance reasons[1]
 
 I am wondering if my approach to drawing is wrong however and if a
 better approach might yield less CPU usage?
 
 It begins with a 33ms timeout. The timeout callback calls
 gtk_widget_queue_draw on the window and the drawing area.
 
 (Imagine rectangles appearing each time a note is played in a piece of
 music and disappearing when that note ends.)
 
 In the expose event callback a linked-list of rectangles is
 maintained. Rectangles are added to the list and removed from the list
 as notes start and end (The application is an experimental MIDI
 sequencer/arpeggiator operating in real time).
 
 Each and every time the expose event callback is called (every 33ms)
 the background and the entire list of rectangles is drawn as well as
 various maintenance functions performed on the list.
 
 The documentation of gdk_cairo_create seems to suggest this is the
 only way of doing it when it says:
 
 Note that due to double-buffering, Cairo contexts created in a GTK+
 expose event handler cannot be cached and reused between different
 expose events.
 
 Is it possible to do this any other way?
 Cheers,
 James.

Can you avoid redrawing the entire list of rectangles on each expose
event?

When drawing in an expose event callback, you would normally clip to
the rectangle representing the dirty area (the area enclosed by
event-area.x, event-area.y, event-area.width, event-area.height).
You could then only call gdk_window_invalidate_rect() or
gdk_window_invalidate_region() on the particular parts of the
particular GdkWindow object(s) which need redrawing.

In your particular case, unless the notes move, you could just
invalidate only the areas representing the notes which have just begun
or ended. Depending on your program logic you may be able to dispense
with the timeout entirely: your active code which handles note changes
could call gdk_window_invalidate_* on a selective basis as necessary.

Chris


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

Re: Performance issues of GDK deprecation in favour of Cairo

[Chris Vine]

On Tue, 17 Aug 2010 12:26:04 +0100
James Morris ja...@jwm-art.net wrote:
 On 17 August 2010 11:23, Chris Vine ch...@cvine.freeserve.co.uk
 wrote:
  Can you avoid redrawing the entire list of rectangles on each expose
  event?
 
 Yes this is what I'm hoping. Though I've been a bit mixed up with how
 Cairo and GTK work together.
 
  When drawing in an expose event callback, you would normally clip to
  the rectangle representing the dirty area (the area enclosed by
  event-area.x, event-area.y, event-area.width,
  event-area.height). You could then only call
  gdk_window_invalidate_rect() or gdk_window_invalidate_region() on
  the particular parts of the particular GdkWindow object(s) which
  need redrawing.
 
 Right. I think I'm starting to see where I went wrong. Though say it
 is a real expose event (ie not due to the timeout) which has erased
 some rectangles. Do I need to redraw the dirty area with calls to
 cairo, that is, I will still need to maintain a list of rectangles
 that currently exist?

Yes.  You can just clip (mask) the area to be drawn to with something
like:

  cairo_rectangle (cr, event-area.x, event-area.y,
   event-area.width, event-area.height);
  cairo_clip (cr);

After that you can draw to the cairo surface as normal but areas
outside the clipped area will be masked out and ignored.  I imagine it
would still be more efficient even so to ignore note rectangles which
you know have not been changed if you can (that would I imagine depend
on how complex they are) but I don't think there is any easy means of
determining, in the callback, what has generated the expose event.  In
other words, I don't think you can assume that any particular expose
event is not one generated artificially rather than one called up by
the window manager.  So you may need to examine the co-ordinates of any
one note rectangle with those of the dirty area of the event if you
wanted to make the implementation more efficient still.

 What about drawing via cairo to a pixbuf and using that for the (real)
 expose events?

You can convert pixels in pixbuf format to cairo image format, but I
don't see why that would be advantageous in your case. They use
different formats (RGB/RGBA, alpha not pre-multipled, for pixbuf, and
BGR/BGRA, with pre-multiplied alpha, for image surfaces). You would
also need to allow for endianness in converting, because image
surfaces are in 32-bit native endian format.

Draw to the surface directly, if you can, because it saves conversion,
and futzing around with endianness.  That is why gdk provides you with
a cairo context, incorporating a destination surface, for any
GdkDrawable.

I am not an expert on cairo drawing functions.  Others in the list
probably know considerably more.  I just know what I need to know for
the things I write.

Chris


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

Re: GtkProgressBar state update issue

[Chris Vine]

On Sat, 29 May 2010 06:35:24 -
John Emmas john...@tiscali.co.uk wrote:
 When you call one of the g_idle_add() functions, you're saying to gtk,
 don't execute this function now - but delay it until the GUI thread
 has some idle time available and execute it there.  By doing that,
 you ensure that GUI elements get updated in the right way and in the
 right place.

That's not quite right.  It adds a callback to the event queue, and
with g_idle_add_ful() you can specify any priority you want (you can,
if you wish, put it at the top of the event queue).  The idle is
really a misnomer and just relates to the default priority in the
queue for the callback.

Chris


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

Re: gthreads and file operations

[Chris Vine]

On Wed, 14 Apr 2010 10:01:15 +0530
Nischal Rao rao.nisc...@gmail.com wrote:
 Let me explain the entire scenario.
 
 I need to be listening to a socket for data from an external program.
 I do this using an infinite loop. Once i get the data, i call a
 function and after it returns I go back into infinite loop again.
 While all this is happening I also need to listen to some signals
 (libwnck signals, which work using the gtk_main() loop). Since
 gtk_main() blocks, I created a new thread for the infinite loop.
 
 I got one idea now. I created a separate thread just to listen to a
 socket (while the other thread is listening for signals). Is it
 possible to listen to the socket through the main event loop? If so,
 please let me know how (possibly with an example). I can then safely
 remove the thread.

OK, that makes a bit more sense.  As someone else has said,
g_io_add_watch() is intended for this kind of situation.  You can
read/write in the callback using the GIOChannel object but you are not
obliged to do so (you could use unix read/write or sockets recv/sendin
the callback for example).

However, having a dedicated thread for the socket in this kind of case
is not entirely off the wall and may be the better solution if you have
a large amount of traffic, but it does introduce complications.  If you
want to have a dedicated thread for the socket I would still do all
accessing of GTK+ in the main program thread rather than use
gdk_threads_enter() and gdk_threads_leave().  You can send event
callbacks from the server thread to the main program thread using
g_idle_add()/g_idle_add_full() (a somewhat misleading name as with
g_idle_add_full() you can choose any priority you want).  Both those
functions are thread safe (in fact, all of the main loop is thread
safe).

Another solution if you want a multi-threaded solution is to let the gio
module do the work for you (http://library.gnome.org/devel/gio/stable/):
see in particular the gio asynchronous functions. (There is another poor
choice of names here: gio is completely different to, and in some
respects supercedes, GIOChannel, although it is really a replacement
for gnome VFS.)

Chris


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

Re: gthreads and file operations

[Chris Vine]

On Wed, 14 Apr 2010 00:13:38 +0530
Nischal Rao rao.nisc...@gmail.com wrote:
 
 is there any way to listen to signals without calling gtk_main()
 (which never returns) ? If so, then i ll be able to get rid of
 threads(happily!!) I am new to glib threads and gnome signals.. i
 have just been following examples that i found on the net.

Of course gtk_main() blocks, as it starts the main program event loop.
(You end the loop in order to terminate the program by calling
gtk_main_quit().)

Are you saying that you are using some external library which has its
own main loop?  If not, I don't understand your problem.  If you are
using such an external library, how are you interfacing (or trying to
interface) between the two?

Chris


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

Re: g_idle_add(): limits?

[Chris Vine]

On Wed, 10 Mar 2010 15:10:50 +0100
fka...@googlemail.com fka...@googlemail.com wrote:
 Chris Vine:
 
   I make heavy use of g_idle_add(), and encounter this problem:
   It seems that the idle functions aren't called sometimes.
 
 [...]
 
  Assuming that is right, any sources you add before calling
  gtk_main_quit() without returning control to the main loop will not
  be executed.  I think it probably also means that if you call
  gtk_main_quit() in a GTK+ signal handler, which will have a higher
  priority than a default idle event, a stacked idle callback will
  also not be called (that depends on what the documentation that I
  have referred to means by dispatched).
 
 This might be the case here: I am definitly not calling
 gtk_main_quit() too early, since I am sleeping in a loop
 before calling it, waiting for my pending idle function
 counter to become 0 (but it doesn't sometimes as
 mentioned).  However, the locking situation here really
 prevents giving GTK+ back control while waiting.
 
 I assume this is the problem (since not occuring always I
 can not yet say definitly this was the cause, though).

You could test it by running 'while (gtk_events_pending())
gtk_main_iteration();' immediately before the call to gtk_main_quit(),
(or you could call 'while (g_main_context_pending(NULL))
g_main_context_iteration(NULL, FALSE)'). In either case, make it
absolutely the last thing that is done before gtk_main_quit().

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

Re: g_idle_add(): limits?

[Chris Vine]

On Tue, 9 Mar 2010 10:06:19 +0100
fka...@googlemail.com fka...@googlemail.com wrote:
 Hi,
 
 I make heavy use of g_idle_add(), and encounter this problem:
 It seems that the idle functions aren't called sometimes.
 
 To track that: I used a counter before g_idle_add() and one
 inside the idle function (always executed once only).  When
 the app is closed, the counters are sometimes not equal.

You probably had some stacked in the event queue when you terminated
the main loop.  The documentation for g_main_loop_quit() states Note
that sources that have already been dispatched when g_main_loop_quit()
is called will still be executed, which implies that sources which
have been added but not dispatched will not execute.  Presumably this
extract from the documentation is principally intended to refer to cases
where a different thread from the main loop thread has added a source.

Assuming that is right, any sources you add before calling
gtk_main_quit() without returning control to the main loop will not be
executed.  I think it probably also means that if you call
gtk_main_quit() in a GTK+ signal handler, which will have a higher
priority than a default idle event, a stacked idle callback will also
not be called (that depends on what the documentation that I have
referred to means by dispatched).

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

Re: Capture console app output into texview?

[Chris Vine]

On Thu, 19 Nov 2009 22:11:18 +0100
Till Harbaum / Lists li...@harbaum.org wrote:
 Hi,
 
 i am trying to run a text mode application in the background of my
 gtk one and display its output in a textview. I know this is supposed
 to be done using g_spawn_async_with_pipes and then link to the output
 via g_io_add_watch. I even got something that sort of works, but the
 output is very much delayed and comes in chunks and worse, the CPU
 load is at max while and after i run my code.
 
 Are there any examples for doing this? There must be many programs
 doing something similar to run e.g. some little helper program or
 similar. 

You generally won't get away with forking after the gtk+ main loop is
running.  You should fork before the main loop is running, and if you
cannot do that start a new thread to fork from.

If you do the latter on a POSIX (unix-like) system you must only call
async-signal-safe functions between the fork and the exec*.  If you are
using windows, I do not know what the restraints are.

Chris


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

Re: code work wrong when i put it in gtk+ application

[Chris Vine]

On Wed, 11 Nov 2009 16:35:23 -0800 (PST)
cet cet xni...@yahoo.com wrote:
 After i updated my system my previously working gtk+ application
 start to print wrong result.The problem is atof() i used in the
 program.The code is working as expected in a standart c console
 version.(Program reads some datas from file and make some
 calculations)The code i used is;
 
 suppose that at line 62 the file have data;
 10   5  15 B   15.031103
 
 the code;
 
 gchar *temp,cm[11];
 gfloat m;
 gint l00;
 .
 
 while(!feof(in)){
 fgets(temp,30,in);
 
 
 
 for(i=0;i10;i++) cm[i]=temp[i+15];
 
 cm[10]='\0';
 if(l==62) g_print(mass=%s\n,cm);/*prints 15.031103  */
 
 m=atof(cm);
 
 if(l==62) g_print(mass=%f\n,m);/*prints 15,00 notice that not
 15.00 it prints with the comma 15,00 */
 l++;
 }
 
 I also tried sscanf(cm,%f,m) and m=strtof(cm,NULL);
 always gives 15,00 When i try exactly the same code in a standart
 c program it is working as expected.

The radix is locale dependent.  You will need to set a C locale.

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

Re: Detecting whether a widget is displayed.

[Chris Vine]

On Thu, 5 Nov 2009 06:28:36 -0800
Daniel Burrows dburr...@algebraicthunk.net wrote:
 
   I have what's probably a simple GTK+ problem, and I was wondering if
 anyone could give me a tip.
 
   I'm trying to write a custom widget (in GTK--) that would benefit
 from knowing whether it's currently visible or not.  It seems pretty
 easy to detect when a widget becomes visible for the first time by
 hooking into the expose signal, but I can't for the life of me find
 any way of detecting when a widget becomes invisible.  (for instance,
 when the user switches away from its tab in a notebook or scrolls past
 it in a TextView)
 
   The most promising thing I found was the visibility notify event,
 but it never seems to get delivered to my widget.  I've also tried to
 use is_viewable() and get_visible_region() on the GDK window, but even
 if these work (they don't seem to so far, but I could be doing it
 wrong) I need a signal or event so that I know when to test them.

You need to add the GDK_VISIBILITY_NOTIFY_MASK for the widget with
gtk_widget_add_events() in order to get visibility notify events on it.
Also test GTK_WIDGET_VISIBLE() if you might call hide() on the widget
(eg when in the system tray), because hiding a widget for some reason
does not count as a change of visibility status.  Depending on what
you are after, you may also want to track window state events for cases
where a window is iconified (minimised).

In other words, a lot depends on what you mean by visible.  Your
meaning many not be the same as GDK's meaning.  If you test for all of
the conditions I have mentioned it will probably do what you want.

Chris


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

Re: main loop asynchronous queues

[Chris Vine]

On Thu, 24 Sep 2009 14:32:30 -0500
Thomas Stover tho...@wsinnovations.com wrote:
[snip]
 For anyone in the future searching around for more info on this
 topic, here is a variation of the gtk hello world program I was doing
 some experiments with. My main question at this point to anyone who
 might know is, should the idle source get dereferenced / freed
 somehow? My other question is g_source_attach() working on another
 thread's GMainContext with atomic operations, will it possibly have
 to block for access, or I'm I not doing this in a thread safe way?

Since you call g_thread_init(), g_source_attach() is thread safe so
that is fine.  However, to get the GSource objects to clean up when
they are finished with you need to call g_source_unref() after
g_source_attach() (g_source_attach() increments the reference count).

The main loop has a mutex protecting it when sources are added or
removed or callbacks are read for dispatch.  That might block
momentarily if there is contention but nothing that you would notice.

Chris


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

Re: main loop asynchronous queues

[Chris Vine]

On Tue, 22 Sep 2009 18:59:25 -0500
Thomas Stover tho...@wsinnovations.com wrote:
 Does glib allow for things like a two threaded program with
 inter-thread communication via async queues while each thread has a
 separate main loop waiting for both external stimulus and new queue
 messages to arrive? In other words, a) can a main loop be made to run
 a callback when a queue message arrives without polling (possibly
 futex based on linux),

I do not know of a way to poll a condition variable, (which seems to be
what you are asking) other than by the stand wait call for the
condition variable, but it would be the wrong way to achieve what you
want even if you could, first because it would be completely
non-portable and secondly because in glib a thread can cause the main
loop for another thread to execute an arbitrary callback by means of an
idle source.

In the case of callbacks to execute in the default program loop/context
(the main main loop) a worker thread can use g_idle_add()/
g_idle_add_full().  To execute a callback in other threads' main loops
you will have to do it in long-hand, making a GSource object with
g_idle_source_new(), and attach it to the GMainContext for the thread
in question (it is relatively trivial).

http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description

You won't need an asynchronous queue as you can pass whatever
data you want to g_idle_add() or your custom event poster.  Each main
loop retains its own (thread-safe) event queue.  You can give any
priority in the loop you want to an idle handler (idle is something
of a misnomer, just reflecting the default priority).

 and b) can two threads each have a main loop?

Yes.  Each can have their own GMainContext and thus their own GMainLoop
objects.  Every GMainContext object is owned by a thread.

Chris


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

Re: main loop asynchronous queues

[Chris Vine]

On Wed, 23 Sep 2009 08:44:06 -0500
Thomas Stover tho...@wsinnovations.com wrote:

 
 Chris Vine wrote:
  In the case of callbacks to execute in the default program
  loop/context (the main main loop) a worker thread can use
  g_idle_add()/ g_idle_add_full().  To execute a callback in other
  threads' main loops you will have to do it in long-hand, making a
  GSource object with g_idle_source_new(), and attach it to the
  GMainContext for the thread in question (it is relatively trivial).

 Wow that might open up some doors, but I've got to understand this 
 first. I'm fuzzy on several things. Here is some stabbing in the dark:

[snip]

To be honest I am not entirely clear from your code snippet what you are
trying to do, but the link I sent in my last post explains how to do it.

In your code you didn't create a GMainContext object for each of your
threads, which is the key point. Each thread in which you want a main
loop should call g_main_context_new() which will create a GMainContext
object for the calling thread, then use that to create a GMainLoop
object, then call g_main_loop_run() on it to run it.

You can then post to that main loop from any thread using an idle
source. If you want to see an example of how to set up an idle source,
look at the implementation of g_idle_add_full().  You can do the same,
except pass the GMainContext object for the receiving thread as the last
argument of g_source_attach() instead of NULL.

However, if all you want is to have a worker thread which will execute
tasks sent to it, then you might as well just block on a GAsyncQueue
object in a perpetual loop and put callbacks in the queue for execution.
Or thread pools may suit what you are doing better (see GThreadPool).

Chris


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

Re: Idle Function Not Getting Called

[Chris Vine]

On Mon, 14 Sep 2009 18:02:25 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:

 I'll be a son-of-a-gun.  Removing the gdk_* calls fixed the problem.
 It's something I should have known.

The GDK global lock is difficult to use correctly.  All GTK+ signal
callbacks are entered holding the lock (as is gtk_main(), although
the lock is relinquished by the main loop before calling glib timeouts,
idle handlers, gio callbacks and the like).

This means that you usually need to treat the GDK global lock as Lock 1
and never call gdk_threads_enter() holding another lock, and to ensure
that any idle handlers or other main loop callbacks release their own
locks before returning, so as to allow GTK+ to reacquire the global
lock for its signal handlers in the correct order. I expect that one or
other of those may have been the problem.

As I say, it is best to avoid the global lock if you can, and you can
if you only allow worker threads to access GTK+ through idle handlers.
You are obliged to do that under windows anyway, as the global lock
does not work with windows, so it is the more portable approach.

Chris


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

Re: Idle Function Not Getting Called

[Chris Vine]

On Sun, 13 Sep 2009 18:35:06 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:
 I've taken some time to check the mutex and locks/unlocks between the 
 secondary thread and the idle function.  All appear as it should.
 The locks/unlocks are being applied in an orderly fashion and as they
 should be, and there are no recursive locks.  The program flows as it
 should.
 
 I still feel my problem has something to do with the secondary thread
 and idle function working together but at this point I'm not sure
 what to check next.

I am only familiar with glib on unix-like systems, where GMutex/GThread/
GCond are thin wrappers for their pthread counterparts.  g_idle_add()
is implemented differently in windows as well, with a windows event
object rather than a unix pipe.

If you are using windows, possibly the contortions necessary to fit
windows threads into a pthread-type model is causing the difficulty.
You may want to look at the glib source code: as a random thought,
possibly the idle handler has to be dispatched under a lock (normally a
no-no) in which case it offers up new possibilities of deadlocks.  But
this is pure guess-work.

I assume you have made the main loop thread-safe by calling
g_thread_init()?

Chris


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

Re: Idle Function Not Getting Called

[Chris Vine]

On Mon, 14 Sep 2009 13:24:30 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:

 I'm using only Linux.
 
  I assume you have made the main loop thread-safe by calling 
  g_thread_init()?
 
 The following are the first few lines of my main() ...
 
  openlog (gtknsbclient, LOG_NDELAY, LOG_USER);
  if (!g_thread_supported ())
  g_thread_init (NULL);
  gdk_threads_init ();
  gdk_threads_enter ();
 
  /* initialize GTK interface */
  gtk_init (argc, argv);


And now you pull the GDK global lock out of the hat to add to the mix!

I would suspect that you are recursively, or out-of-order, locking on
that, given the large number of other locks you seem to have in your
program. It is difficult to use correctly.  

Why incidentally are you using both extra-threaded access to GTK+ with
the GDK global lock and also accessing GTK+ from threads via the idle
handler?  You would normally do one or the other, not both.  Why not
drop the global lock, or drop the idle handlers (preferably the first
of those)?

Chris


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

Re: Idle Function Not Getting Called

[Chris Vine]

On Sat, 12 Sep 2009 17:46:17 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:
  The important point in looking at out-of-order locking (or other 
  locking issues) is that the idle handler runs in the thread in
  which the main program loop runs, not the thread which called
  g_idle_add()/ g_idle_add_full(), and that it runs at a time not
  of that calling thread's choosing.
 
  I don't quite understand this.  Don't all idle functions run in
  the main program loop thread?
 
  Yes.
 
 Then I don't understand what you mean by the idle handler runs in
 the thread in which the main program loop runs, not the thread which
 called g_idle_add()/g_idle_add_full().
 
 Maybe I don't know what idle handler is but isn't that a moot point 
 since the idle function (handler?) always runs in the main program
 loop thread?
 
Perhaps we speak slightly different versions of English, but I was
merely alerting you to the fact that the idle callback runs in the main
program loop, in case you didn't realise that. Clearly you do, which
is fine.

Incidentally, to see if you have recursive locking have you tried
recursive mutexes to see if that exhibits the same problem or not?  If
they don't your search is narrowed considerably.

Chris


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

Re: Idle Function Not Getting Called

[Chris Vine]

On Sat, 12 Sep 2009 00:18:59 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:
[snip]
 I can't find a non-commercial deadlock checker for Linux.  I agree
 that the multi-threaded facet of the code is causing my problem but
 so far I'm having trouble using breakpoints/debug code to isolate the
 exact cause.
 
 The mutex locks/unlocks are only in a secondary thread and an idle 
 function.  I assume there's no problems with idle functions using
 mutexes?

There is no problem provided that any mutex acquired by the idle
function does not block (it immediately acquires), or if it does block
then it only does so transiently.  If the secondary thread undertakes a
lengthy operation holding a lock which the idle function may also want
to acquire, then there is a bottleneck in the code.  If at the same
time the secondary thread is waiting for the idle handler to complete,
there is a deadlock.

The important point in looking at out-of-order locking (or other
locking issues) is that the idle handler runs in the thread in which the
main program loop runs, not the thread which called g_idle_add()/
g_idle_add_full(), and that it runs at a time not of that calling
thread's choosing.

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

Re: Idle Function Not Getting Called

[Chris Vine]

On Sat, 12 Sep 2009 12:00:11 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:
[...]
Me:
  The important point in looking at out-of-order locking (or other
  locking issues) is that the idle handler runs in the thread in
  which the main program loop runs, not the thread which called
  g_idle_add()/ g_idle_add_full(), and that it runs at a time not of
  that calling thread's choosing.
 
 I don't quite understand this.  Don't all idle functions run in the
 main program loop thread?

Yes.

Chris


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

Re: Idle Function Not Getting Called

[Chris Vine]

On Wed, 9 Sep 2009 12:23:07 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:

 
 
  I tried G_PRIORITY_HIGH_IDLE with similar results ... the idle
  function is called only with the following code:
 
   g_idle_add_full (G_PRIORITY_HIGH_IDLE, (GSourceFunc)
  idlefunc, NULL, NULL); while (gtk_events_pending ())
   gtk_main_iteration ();
 
  If the while loop is not part of the coding then the idle function 
  (idlefunc) is not called.
 
  The difference with using G_PRIORITY_HIGH_IDLE is that some of the 
  buttons inside the dialogs drawn in the idle function are not 
  displayed.  But they still react to user clicks if clicked in the
  right area.  I expect this is linked to your GDK drawing
  functions statement above.
 
  Then you must have some function blocking between your call to
  g_idle_add_full() and control returning to the main loop.
 
  Anything in a GTK+ signal or event handler must not block.  This
  means in practice that nothing should block after your call to
  gtk_main().
 
 After spending more time with my code I'm just not seeing it.  Below
 is the pertinent code.
 
 AddName() is called from a drop-down menu item.
 
 Via debug code I've seen that the program flow is as it should be ...
 all functions are exited.  The first idle function (PlayNetGame()) is
 added, executed, and exited as it should be.  The second idle
 function (PlayTheGame()) is added but is never called.
 
 Does anyone see what might be blocking the call of PlayTheGame() or
 have any other suggestions?

I have not tried to find it in the code, but as your application is
multi-threaded you are showing the symptoms of a deadlock, either by
recursive locking or more likely by out of order locking.  Can you run
the code through a deadlock checker, or if not can you by appropriate
breakpoints find out if it is occurring in a mutex lock?

Although not relevant to your problem I should add to my comment that
you should not block after your call to gtk_main().  You can block in a
further recursive call to gtk_main() (modal dialogs generally do that)
but that is fine as main loop events continue to be serviced.

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

Re: Idle Function Not Getting Called

[Chris Vine]

On Sat, 5 Sep 2009 17:39:33 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:
 I tried G_PRIORITY_HIGH_IDLE with similar results ... the idle
 function is called only with the following code:
 
  g_idle_add_full (G_PRIORITY_HIGH_IDLE, (GSourceFunc) idlefunc,
 NULL, NULL); while (gtk_events_pending ())
  gtk_main_iteration ();
 
 If the while loop is not part of the coding then the idle function 
 (idlefunc) is not called.
 
 The difference with using G_PRIORITY_HIGH_IDLE is that some of the
 buttons inside the dialogs drawn in the idle function are not
 displayed.  But they still react to user clicks if clicked in the
 right area.  I expect this is linked to your GDK drawing functions
 statement above.

Then you must have some function blocking between your call to
g_idle_add_full() and control returning to the main loop.

Anything in a GTK+ signal or event handler must not block.  This means
in practice that nothing should block after your call to gtk_main().

Chris


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

Re: Idle Function Not Getting Called

[Chris Vine]

On Fri, 4 Sep 2009 23:12:24 -0400 (EDT)
Marshall Lake ml...@mlake.net wrote:

 What stops an idle function from being executed? ... pending events, 
 right?
 
 I have a situation where an idle function does NOT get called with
 the following code:
 
  g_idle_add ((GSourceFunc) idlefunc, NULL);
 
 OR
 
  while (gtk_events_pending ())
  gtk_main_iteration ();
  g_idle_add ((GSourceFunc) idlefunc, NULL);
 

[snip]

Assuming there is no coding error in your program which causes an event
in the main loop to block (including a blocking g_idle_add() callback),
use g_idle_add_full() and give the callback a higher priority in the
event queue to put it ahead of the other events.

G_PRIORITY_HIGH will even put it above any GDK drawing functions (not
to be recommended though).

Chris


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

Re: outstream question [i think]

[Chris Vine]

On Fri, 28 Aug 2009 08:16:25 -0400
Boggess Rod rbogg...@corefurnace.com wrote:
  -Original Message-
  The intent is to have the results go to the gui (as opposed 
  to the console).
  
  
  mysql show columns from customers;
  ++--+--+-+-++
  | Field  | Type | Null | Key | Default | Extra  |
  ++--+--+-+-++
  | vend_id| int(11)  | NO   | PRI | NULL| auto_increment |
  | cust_lname | char(50) | YES  | | NULL||
  | cust_fname | char(50) | YES  | | NULL||
  | cust_phone | char(50) | YES  | | NULL||
  ++--+--+-+-++
  
 Is this your first experience developing in a GUI environment?  I
 thought the same thing, way back when I first started.  However, it
 just doesn't work that way.  In every graphical environment I've
 worked in (several), all of the text - all of the output - is managed
 by placement of strings onto or into some type of display widget.
 
 Instead, what you'll need to do is grab the data one cell at a time,
 convert it into a formatted string, and assign the string to a
 displayable widget: a label, entry box, drop-down list, spin button,
 etc.
 
 Various development tools exist to automate this task to various
 degrees, but the end result is always the same.  There is no widget
 I've ever seen that can accept a stream of text for display.  And I
 believe the closest you'll get to something like that, is to direct
 that stream into a memory or string stream, and display the text in
 text-box type display element.

It may be that at GtkListStore object with a GtkTreeView is what would
suit the OP best.

Chris


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

Re: Why is ChangeValue reentrant on a gtk_dialog_run?

[Chris Vine]

On Tue, 11 Aug 2009 09:08:52 -0400
Boggess Rod rbogg...@corefurnace.com wrote:

 
 At the risk of beating a dead horse, I've figured out what the problem
 is, I just don't understand why it's occurring or how to fix it.
 
 If I call hscale's value-changed signal callback, I can return TRUE or
 FALSE, and it behaves as expected.  If I create a static variable,
 increment it, do a modulo 2 and return TRUE or FALSE on alternating
 returns, in every case, it behaves as expected.
 
 However, when I create a message dialog, it re-enters the
 value-changed callback.  What's especially odd is that it re-enters
 when the message dialog is created, not when it's actually
 gtk_dialog_run().
 
 Is this a threading issue?  I thought I was running the message dialog
 modally, and if so, they should be on the same thread.  Anyone know
 where I can find more info on this?

If you are writing a multi-threaded program and are trying to invoke
GTK+ functions from different theads without correctly using the GDK
global lock then you will find all sorts of problems, of which the one
you have observed will be the least of them.  Whether you happen to be
operating on a modal or non-modal dialog is irrelevant to that.

Personally I should avoid the GDK global lock and only call GDK/GTK+
functions in the main program thread, and communicate with it from
worker threads using eg g_idle_add*.  In a complicated program, you
will end up with a much cleaner and more intelligible program.  You will
have to do that anyway under windows as the GDK lock does not operate
under windows.

Chris

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

Re: flow control question

[Chris Vine]

On Tue, 21 Jul 2009 23:45:38 -0400 (EDT)
Allin Cottrell cottr...@wfu.edu wrote:
 On Tue, 21 Jul 2009, Dov Grobgeld wrote:
 
  Here are two programs that implement through the text viewer
  widget what you are asking for:
 
 - The Python console in gimp
 - GemTcl - a tcl interpreter
 
  The way I set up the interaction is to listen to both the
  key-press-event and the insert-text events of the text-viewer.
  The key-press-event signals to the insert-event handler that it
  is supposed to enter eval mode... and the insert-event catches
  this before the newline is inserted into the buffer, runs the
  eval and inserts the result into the buffer[.]
 
 Thanks for the references.  That is pretty much what I have been
 doing up till now.  What I really wanted that was new, though, was
 a loop of precisely the form
 
 while (get_a_command()) {
   respond
 }

You can't put a single threaded program in a blocking loop like this
if you are running an event based GUI such as GTK+ or Qt.

You either have to put your blocking loop in a separate thread (and
you must make sure that get_a_command() really does block or you will
have a tight loop using 100% of one of your CPU cores), or use
the event mechanism, which means connecting to a relevant GTK+/GObject
signal such as a key-press-event as suggested (which is in fact
dispatched by the glib main loop).

Chris

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

Re: inter process communication

[Chris Vine]

On Fri, 10 Jul 2009 16:56:28 +0200
Luka Napotnik luka.napot...@gmail.com wrote:

 If you need more advanced IPC, take a look at D-BUS. For basic IPC you
 could use unix local sockets or shared memory.

... or named pipes/fifos (man 3 mkfifo) for the most basic IPC.

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

Re: Bringing a GtkWindow to the current desktop with libwnck

[Chris Vine]

On Sun, 5 Jul 2009 11:51:19 +0200
Vivien Malerba vmale...@gmail.com wrote:
 
 2009/7/3 Jim George jimgeo...@gmail.com
 
  Hi all,
  I'm writing a program that needs to be single-instance. The
  program will only run on gnome desktop machines. I'm using dbus to
  ensure this, by having the program try a dbus rpc each time it
  starts. If there's a running instance, it responds to the rpc by
  calling gtk_window_present on the main window. However, if the user
  switches desktops and tries to run another instance,
  gtk_window_present will only cause the window to appear on the
  previous desktop, not the current one.
 
  I tried to get around this using libwnck. I call
  wnck_window_get(GDK_WINDOW_XID(main_window-window)), but the
  WnckWindow returned is always NULL. The X window ID seems to make
  sense (it's a large integer), so what am I doing wrong?
 
 
 You could use Libunique http://live.gnome.org/LibUnique for that
 purpose.

libunique does not address the OP's problem, which is that
gtk_window_present() does not do what it should do.  (libunique would
make it unncessary for him to write his own dbus RPC for the purpose,
but since he has already written that I would stick with what he has, as
it is one dependency less.)

Metacity is responsible for the program not presenting itself on the
current workspace, but something also appears to go wrong in GTK+'s
tracking of window status, which can be demonstrated by repeatedly
hiding and presenting a window on different workspaces and when
obscured by different windows.  I did set up a test program to try and
get to the bottom of it, but didn't have the time to follow through
(but I did manage to show it was generating bogus status information).

What I do when re-presenting an instance of a single instance program is
to transfer the window to the current workspace using libwnck, and then
after doing so present it with gtk_window_present().  Sometimes however
the window reaches a state where it will not go to the top of the
Z-order.  I have found that the following sequence in the routine
which presents the program to the user on a restart deals with this:

* transfer to the current workspace with libwnck
* call gtk_widget_hide() on the window
* call gtk_window_present() on the window
* call gtk_window_deiconify() on the window

The last call should be completely otiose, but sometimes metacity
reaches the conclusion that the window is or should be iconified when it
should not be or isn't, and that prevents that particular problem.

On the OP's other issue, as suggested by another poster, if he first
calls wnck_screen_force_update(wnck_screen_get_default()) before
getting his WnckWindow object, that will result in him getting a valid
pointer back when he subsequently calls wnck_window_get().

Chris

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

Re: Where is Glib::strfreev()?

[Chris Vine]

On Fri, 1 May 2009 22:34:48 +0300
sledge hammer sledgehammer_...@hotmail.com wrote:
 
 Hello,
 
 I use Gtk::SelectionData::get_uris() and in the docs says that if I
 get a non-0 result I should use Glib::strfreev() to free it.
 
 The problem is there is no documentation about Glib::strfreev() and I
 don't know how to use it. I cant even find an example that uses it.
 So can you show me how to use it to free the result and have mem
 leaks?
 
 Sidenote: I use std::vectorGlib::ustring as container.

This looks like a result of the automatic generation of documentation
from the C source.  There is no Glib::strfreev() and you don't need to
try and call it.  You can pass the return value directly to a
std::vectorGlib::ustring  container.

I suggest you enter a documentation bug for it.

You should take anything further up on this on the gtkmm mailing list,
which is the mailing list for the c++ bindings for gtk+.

Incidentally, are uris always in the utf-8 codeset, or are they
dependent on the filename codeset (which may not be utf-8, depending on
how you have set the G_BROKEN_FILENAMES and G_FILENAME_ENCODING
environmental variables)?  I don't know the answer to that, but if they
are not guaranteed to be in the utf-8 charset you would be better off
putting them in a container of std::string objects before you do
anything with them.

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

Re: A few quick questions about gtkprint

[Chris Vine]

On Wed, 15 Apr 2009 07:02:07 +0530
Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote:

 
 hello,
 
 I am a gsoc applicant for sugar, and doing a project which adds print
 support to our applications.
 The idea is to convert our mime types to a more printable format and
 print them.
 So, now the question is how does convertion to ps/pdf take place with
 gtkprint
 I would like to know if it is true that gtkprint uses a common filter
 for converting to pdf/ps for any application?
 or will it again interact with different respective filters?

At the library user level, gtk-print doesn't convert to ps or pdf in
order to print. It uses cairo/pango-cairo to write each page to a cairo
context.  It becomes clearer if you look at the documentation for
GtkPrintOperation (including the draw-page signal) and
GtkPrintContext.  After the drawing of the document with cairo has been
completed, gtk-print will convert those pages to postscript where unix
(cups or lpr) rather than windows is the underlying print system, but
that is not for the user to do nor bother with.

Since you refer to sugar, you may be doing this in python.  The py-gtk
documentation is generally pretty good (better in some respects than
the C interface documentation) so look at gtk.PrintOperation and
gtk.PrintContext etc., which covers the same ground with some
mini-examples.

As it happens, if you are only interested in running your programs
under unix-like operating systems, you can print a pre-prepared
postscript document using GtkPrintUnixDialog and GtkPrintJob with the
gtk_print_job_set_source_file() function, but doing that would offer
less features. You could not for example select the pages to be
printed, nor scale it nor set the margins, and it is not really the
best way to do it. So it is best to stick to the high level
GtkPrintOperation/cairo interface in order to give users what they
expect.

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

Re: A few quick questions about gtkprint

[Chris Vine]

On Wed, 15 Apr 2009 15:33:03 +0530
Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote:
 Thanks for your effort and time Chris!
 That pretty much answers all of my questions, one question though,
 will poppler and such libs really be necessary when the file can
 already be viewed by an application? As I think if a page can be
 viewed, without doubt it  can be rendered to cairo objects.
 I have gone through gtkprint previously, made a simple printing
 program in python which read text mime types. and could print as pdf
 or to the printer.

I think that will depend on the application.  If it draws pages using
cairo and then paints them directly to X server side objects
(eg GDK drawables via gdk_cairo_create()) then you are in a very
straightforward position because you should be able to use the same
drawing functions when drawing to cairo surfaces for painting to the
print cairo context.  All you may have to do is do some scaling of the
print cairo context.

If the application doesn't do that, but you can get hold of (or convert
to) pixel data in an image format supported by
cairo_image_surface_create_for_data() then you can use that to paint to
the print cairo context (after scaling).

If though the application uses higher-level GTK+ interfaces to display
program material, such as GtkTextView, then I think you are going to
have to draw the text yourself with pango-cairo.  If it is just pure
text you are thinking about, this is pretty straightforward (I can send
you an url to some code I have written to print plain text log
files using GtkPrintOperation if you like).

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

Re: A few quick questions about gtkprint

[Chris Vine]

On Wed, 15 Apr 2009 10:24:13 +0100
Chris Vine ch...@cvine.freeserve.co.uk wrote:

 At the library user level, gtk-print doesn't convert to ps or pdf in
 order to print. It uses cairo/pango-cairo to write each page to a
 cairo context.  It becomes clearer if you look at the documentation
 for GtkPrintOperation (including the draw-page signal) and
 GtkPrintContext.  After the drawing of the document with cairo has
 been completed, gtk-print will convert those pages to postscript
 where unix (cups or lpr) rather than windows is the underlying print
 system, but that is not for the user to do nor bother with.
 
 Since you refer to sugar, you may be doing this in python.  The py-gtk
 documentation is generally pretty good (better in some respects than
 the C interface documentation) so look at gtk.PrintOperation and
 gtk.PrintContext etc., which covers the same ground with some
 mini-examples.
 
 As it happens, if you are only interested in running your programs
 under unix-like operating systems, you can print a pre-prepared
 postscript document using GtkPrintUnixDialog and GtkPrintJob with the
 gtk_print_job_set_source_file() function, but doing that would offer
 less features. You could not for example select the pages to be
 printed, nor scale it nor set the margins, and it is not really the
 best way to do it. So it is best to stick to the high level
 GtkPrintOperation/cairo interface in order to give users what they
 expect.

Sorry, just to complete the picture, you can draw the pages of pdf files
to cairo surfaces for printing via GtkPrintOperation using the poppler
library, and similarly for postscript using libspectre, but I do not
think that is what you were thinking about.  However, if you are, look
at the evince source for examples.

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

Re: A few quick questions about gtkprint

[Chris Vine]

On Wed, 15 Apr 2009 17:48:18 +0530
Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote:

 Thank you again!
 Here is the code I was talking about; my code pretty much does the
 job of printing .txt files and related mime types,
 http://pastebin.be/17838
 But I would love to see your code as well.
 
 Our Read activity (sugar apps are called activities) supports a
 plethora of formats (let me just check how it draws on screen), okay
 it uses the evince library, meaning I should be able to draw to a
 Cairo context right? as the underlying lower level implementation
 would be cairo if I am not mistaken? (let me make sure that too). Yep
 evince uses poppler for pdf, and that cairo as backends.

Mine for text is here:
http://efax-gtk.cvs.sourceforge.net/viewvc/*checkout*/efax-gtk/efax-gtk/src/utils/text_print_manager.h
http://efax-gtk.cvs.sourceforge.net/viewvc/*checkout*/efax-gtk/efax-gtk/src/utils/text_print_manager.cpp

The guts of it are similar to yours, although it has more twiddly bits.

I do not know anything about OLPC/sugar, so I do not completely
understand all your comments about evince, since evince is a
postscript/pdf display application, rather than a library.  The
libraries it uses are as I recall, although it is some time since I
looked, poppler, libspectre and libgs.  If evince is the main display
application for sugar, though, then it already comes equipped with
printing via gtk-print, for which purpose it uses poppler/cairo and in
recent versions libspectre/cairo (I think).

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

Re: A few quick questions about gtkprint

[Chris Vine]

On Wed, 15 Apr 2009 19:03:17 +0530
Vamsi Krishna Davuluri vamsi.davul...@gmail.com wrote:
 Oh, the thing is sugar has bindings for the evince classes, which we
 use as import modules.
 And I will look into it for modules on printing.
 Thanks for your time.
 If you are on the #gtk+, can you tell me your nick, so I can ping you
 live when I am in a glitch :p

That's rather nice.  It should be trivial to print ps/pdf documents
then.  However, if you use poppler and libspectre directly it should be
relatively easy to do so in longhand.

I don't normally do IRC I am afraid, as I tend to have other things to
do (and on my mind).  It's a bit like twitter: I feel people should have
better things to do with their lives.  However, I agree IRC can be
useful to talk through technical problems.

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

Re: g_io_channel_win32_new_messages() WaitForSingleObject()

[Chris Vine]

On Thu, 02 Apr 2009 19:49:48 -0500
Thomas Stover tho...@wsinnovations.com wrote:
 Some notes for anyone else who is just figuring out several things
 like myself:
 -a real new source would have a constructor that would do the 
 allocation and setup
 -it would also have its own functions for setting up callbacks to
 source specific events
 -I think g_source_remove_poll() would be called in related
 destructor, so I suppose the GPollFD structure needs to be stored in
 MySource as well -I guess the destructor would be the
 closer_callback of the GSourceFuncs parameter
 -the GSourceFuncs and GPollFD variables are just copied by glib when 
 they given as parameters, so they don't need to dynamic (or 
 global/static like my last examples)

I do not really understand what the issues are (that may be more my
problem than yours) but first, yes you generally would store the GPollFD
object in the source object by value if you are making your own custom
polling source, and secondly since you do need to pass g_source_new()
a GSourceFunc struct, the sensible way to implement that is to make the
GSourceFunc object (which is just a struct of function pointers common
to all source objects of that type) a static object - you don't have to,
but it would be pointless doing it any other way because you may have
more than one of the custom source objects in use at any one time which
would otherwise result in duplicated GSourceFunc objects.

Lastly, glib will correctly manage resources if you use the mechanisms
which it provides.  The finalize function you pass to GSourceFuncs
should free any MySource data which happens to have been allocated on
the heap (generally you would not have any).  Everything else will be
taken care of.  In particular g_source_attach() increments the
reference count on the source object, and after you have called
g_source_attach() you can pass ownership of the MySource object to the
main loop in the normal way by calling g_source_unref() on the MySource
source object. The main loop will then automatically destroy your
MySource object if either the dispatch function returns false, or if
g_source_remove() is called on the source id returned by
g_source_attach().  (The function you use to create your custom source
object should return this ID so that users can do just that.)

Chris

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

Re: g_io_channel_win32_new_messages() WaitForSingleObject()

[Chris Vine]

On Thu, 02 Apr 2009 16:53:11 -0500
Thomas Stover tho...@wsinnovations.com wrote:

 
 Well if any lone googlers ever find this, and want to know what 
 happened. I did fix it with this, but I still think the right way is
 to some how create a new structure that is inherits the
 GSourceFuncs and adds a place to store the event handle and the
 protected data (in this case global_int). If there was an example of
 how to create a source, or some doc on a source life cycle, that
 would be helpful. I did look at the source, but was quickly lost. I'm
 guessing the main loop architecture involves multiple sources,
 fds, and realization callbacks all being able to exist without
 extras. So for instance 1 fd could trigger 5 sources, which each
 result in glib calling a variable number of callbacks. If only there
 was more time to spend on these things

I may be missing your point (I would have to read through the
back-posts to make sense of it), but if you want to create your own
source object to hold its own protected/private data, it is just this:

struct MySource {
  GSource source;
/* my data, such as a gpointer but it could be anything and as much member data 
as you want */  
  gpointer data;
};

It is created with:

MySource *my_source = (MySource*) g_source_new(source_funcs, sizeof(MySource));
/* initialise data */
my_source-data = my_object;

For more information see this, in particular the section Creating new
sources types:

http://library.gnome.org/devel/glib/stable/glib-The-Main-Event-Loop.html

An idle object may already do much of what you want.  With windows, I think
it uses a window event object under the hood.

Chris


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