Setting the default values for a class

[Richard Shann]

In the denemo music program it would be useful for the class GtkLabel to
default to use_markup TRUE (so that the music font could be freely
used). I have tried traversing the widgets setting this value, thus

static void use_markup(GtkWidget *widget)
{
  if(GTK_IS_LABEL(widget)) {
gtk_label_set_use_markup (GTK_LABEL (widget), TRUE);
  }
  else
 if(GTK_IS_CONTAINER(widget)) {
GList *g = gtk_container_get_children (GTK_CONTAINER(widget));
for(;g;g=g-next)
  use_markup(g-data);
if (GTK_IS_MENU_ITEM(widget)) {
  use_markup(gtk_menu_item_get_submenu(widget));
}
 }
}

but this curiously fails for toolitems (the GtkLabel widget in the
GtkToolButton changes under some condition, perhaps to do with
accelerators).

I wondered if there was a call to be made to set the default for the
class, but when I looked at the source I became more perplexed:
gtklabel.c has a function
static void gtk_label_class_init (GtkLabelClass *class)
which is not called within the file, even though it is static. Short of
some preprocesser magic, I can't see how this could ever get called.

Is there a way to set the class defaults?

Richard Shann


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

Re: gtk-can-change-accels property absent in gtk 2.8.20?

[Richard Shann]

Hi Torsten,
Thanks for this - curiously I get

(denemo:16377): Gtk-CRITICAL **: gtk_settings_set_long_property:
assertion `origin != NULL' failed

with your code. I'll dig into this.

Richard


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

Re: gtk-can-change-accels property absent in gtk 2.8.20?

[Richard Shann]

Well, I've passed in a constant string 
gtk_settings_set_long_property(settings, gtk-can-change-accels,
TRUE, .gtkrc:0);
and the code has started working 
- thank you very much!
Richard Shann


On Fri, 2008-02-08 at 00:19 +0100, Torsten Reuss wrote:
 On Feb 7, 2008 10:28 PM, Richard Shann [EMAIL PROTECTED] wrote:
  Hi Torsten,
  Thanks for this - curiously I get
 
  (denemo:16377): Gtk-CRITICAL **: gtk_settings_set_long_property:
  assertion `origin != NULL' failed
 
  with your code.
 
 Hmm, I couldn't find out what the origin parameter was good for
 (documentation is blank there), so I tried NULL and never had any
 problems with it. My gtk versions are 2.12.0 (Linux) and 2.10.11
 (windows) though.
 
 Best regards,
   Torsten

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

insert-at-cursor signal in GtkTextView

[Richard Shann]

The insert-at-cursor signal in GtkTextView doesn't seem to be emitted.
There are a few references to a similar problem with GtkEntry, for which
using a signal for the GtkEditable ancestor worked around, but I cannot
see any suggestions for GtkTextView. Anybody know what is going on?
The key-press-event is working fine, but that leaves you with a lot more
work since you have to decide whether a character would be inserted...
Richard Shann


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

Is there a way to invert gtk_ui_manager_get_path()

[Richard Shann]

The function gtk_ui_manager_get_path() gets the xml path to a widget in
your menu hierarchy. Is there a way, given a widget to find this path?
Note this is not the path gotten from gtk_widget_path() which is the
container hierarchy. I want the menu hierarchy (so as to be able to
insert menu items there in some future invocation of the program).
Richard Shann


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

GdkBitmap from black white .png file

[Richard Shann]

The Gdk functions to create bitmaps from data require xbm or xpm data. 
(For example gdk_bitmap_create_from_data ()). Why do I not see anything
to create a bitmap from a (bw) .png image?
I've used the pixbuf library before, using gdk_draw_pixbuf() but the
program I am working on uses  a GdkBitmap * mask to draw in the
following fashion:

  gdk_gc_set_clip_mask (gc, mask);
  gdk_gc_set_clip_origin (gc, x, y);
  gdk_draw_rectangle (pixmap, gc, TRUE, x, y, width, height);
  gdk_gc_set_clip_mask (gc, NULL);  /* Removes clip mask */

I don't understand the issues here; I want the application to let the
user select a (small) rectangular area in the .png image for use in as
the GdkBitmap *mask in the above code.

Anyone with a wider view on this stuff? Help would be much appreciated!

Richard Shann


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

Re: GdkBitmap from black white .png file

[Richard Shann]

On Thu, 2009-02-05 at 16:20 +, gtk-app-devel-list-requ...@gnome.org
wrote:

 There are functions to convert a PNG with transparency (alpha component)
 to a GdkBitmap according to a threshold. See
 gdk_pixbuf_render_threshold_alpha()
 http://library.gnome.org/devel/gdk/stable/gdk-Pixbufs.html#gdk-pixbuf-render-threshold-alpha
 
Thank you for this - I have now taken the this approach - adding an
alpha channel to a pixbuf created from the .png and then going to xbm
format and finally to the GdkBitmap.

Richard Shann

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

g_spawn and files left locked on windows.

[Richard Shann]

My application invokes the lilypond program using the g_spawn...
functions. This works fine on linux, but on windows the files created by
lilypond are left locked when lilypond has exited. I can't re-use them
on the next invocation, for example.
Should I be exploring this as a possible bug in lilypond, or could there
be something about the way I invoke it?
Richard Shann


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

Re: g_spawn and files left locked on windows.

[Richard Shann]

On Mon, 2009-04-27 at 12:52 +0300, Tor Lillqvist wrote:
  My application invokes the lilypond program using the g_spawn...
  functions. This works fine on linux, but on windows the files created by
  lilypond are left locked when lilypond has exited.
 
 That sounds very odd and in fact impossible. Are you confusing file
 protection with locking?
Thank you for the quick and helpful reply. Having contstructed the
minimal example, everything worked fine. 
For those listening in who need to create a glib standalone minimal
example. I append the code I devised.
Richard
/ first program, invoked by the one below */
#include stdio.h

/*
program doit
 gcc test.c -o doit.exe
*/
int main(void) {
  printf(Opening the test file now\n);
  FILE *fp = fopen(thetestfile,w);
  if(fp==NULL) {
  printf(doit could not open the test file);
  return -1;
  }
  printf(Writing to the test file now\n);
  fprintf(fp, hello);
  fclose(fp);
  return 0;
}

/** second program, invoking the first */

/*
program test
 gcc  test.c -o test.exe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  
/usr/lib/libglib-2.0.so
*/
#include stdio.h
#include glib.h
static GPid pid = -1;
void finished(void) {
  g_spawn_close_pid (pid);
  FILE *fp = fopen(thetestfile,rw);
  if(fp==NULL) {
g_print(could not open\n);
exit(-1);
  }
  g_print(The file opens ok\n);
  exit(0);
}

int main(void) {
  g_print(Starting the test\n);
  gchar *arguments[] = {
doit.exe,
NULL
  };
  g_spawn_async_with_pipes (NULL,   /* dir */
arguments, NULL,/* env */
G_SPAWN_SEARCH_PATH  | G_SPAWN_DO_NOT_REAP_CHILD, NULL, /* 
child setup func */
NULL,   /* user data */
pid,
NULL,
NULL,   /* stdout */
NULL,   /* stderr */
NULL);
 g_child_watch_add (pid, (GChildWatchFunc)finished, NULL);
 g_print(looping for ever, Ctrl-C to kill\n);
 GMainLoop* gm = g_main_loop_new(NULL, 0);
 g_main_loop_run(gm);
}


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

Re: g_spawn and files left locked on windows.

[Richard Shann]

Thank you for your observations.
On Tue, 2009-04-28 at 07:45 -0700, Ardhan Madras wrote:
 As far i know in win32, if a process is opening a new file, then normally 
 another process couldn't write or remove it.
yes that's right.
  It's maybe a synchronization method offered by win32 by automatically 
 locking a file descriptor. Linux doesn't automatically provide such a file 
 locking mechanism to a file opened by a process.
 
 So if the file left locked, there are must be a process which still open the 
 file or a file is still left opened. Win32 maybe doesn't automatically 
 release such as opened file's resources.
The process had finished, and that was why I was puzzled.
 In your project or demonstration code: I see you don't fclose() your file 
 before exit 
I *do* fclose() the file in the program that creates it (i.e. in the
program doit). It is also guaranteed to be closed by the main of that
program returning, that is as part of the exit. The other program is
just finding out if the file is locked by trying to open it, so it
doesn't matter what it does with it. The test does, in fact work
pefectly on both platforms, so my problem lay elsewhere.
Richard

 (actually i don't know if this have the 'locking effect'), and you may 
 interest using a GIOChannel for file operations.
 
 --- ajhwb
 
 
 --- richard.sh...@virgin.net wrote:
 
 From: Richard Shann richard.sh...@virgin.net
 To: gtk-app-devel-list@gnome.org
 Subject: Re: g_spawn and files left locked on windows.
 Date: Tue, 28 Apr 2009 08:39:12 +0100
 
 On Mon, 2009-04-27 at 12:52 +0300, Tor Lillqvist wrote:
   My application invokes the lilypond program using the g_spawn...
   functions. This works fine on linux, but on windows the files created by
   lilypond are left locked when lilypond has exited.
  
  That sounds very odd and in fact impossible. Are you confusing file
  protection with locking?
 Thank you for the quick and helpful reply. Having contstructed the
 minimal example, everything worked fine. 
 For those listening in who need to create a glib standalone minimal
 example. I append the code I devised.
 Richard
 / first program, invoked by the one below */
 #include stdio.h
 
 /*
 program doit
  gcc test.c -o doit.exe
 */
 int main(void) {
   printf(Opening the test file now\n);
   FILE *fp = fopen(thetestfile,w);
   if(fp==NULL) {
   printf(doit could not open the test file);
   return -1;
   }
   printf(Writing to the test file now\n);
   fprintf(fp, hello);
   fclose(fp);
   return 0;
 }
 
 /** second program, invoking the first */
 
 /*
 program test
  gcc  test.c -o test.exe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include  
 /usr/lib/libglib-2.0.so
 */
 #include stdio.h
 #include glib.h
 static GPid pid = -1;
 void finished(void) {
   g_spawn_close_pid (pid);
   FILE *fp = fopen(thetestfile,rw);
   if(fp==NULL) {
 g_print(could not open\n);
 exit(-1);
   }
   g_print(The file opens ok\n);
   exit(0);
 }
 
 int main(void) {
   g_print(Starting the test\n);
   gchar *arguments[] = {
 doit.exe,
 NULL
   };
   g_spawn_async_with_pipes (NULL,   /* dir */
 arguments, NULL,/* env */
 G_SPAWN_SEARCH_PATH  | G_SPAWN_DO_NOT_REAP_CHILD, NULL, /* 
 child setup func */
 NULL,   /* user data */
 pid,
 NULL,
 NULL,   /* stdout */
 NULL,   /* stderr */
 NULL);
  g_child_watch_add (pid, (GChildWatchFunc)finished, NULL);
  g_print(looping for ever, Ctrl-C to kill\n);
  GMainLoop* gm = g_main_loop_new(NULL, 0);
  g_main_loop_run(gm);
 }
 
 
 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 
 
 
 
 _
 Listen to KNAC, Hit the Home page and Tune In Live! --- http://www.knac.com

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

Gio library on Debian Lenny

[Richard Shann]

Does anyone know if the gio library is working for getting files from
the internet in the latest Debian Lenny distribution, x86?
I have tried the following code:

  GError *err = NULL;
  GFile * file=g_file_new_for_uri
(http://www.rshann.plus.com/denemo.html;);
  GFileInputStream *stream =  g_file_read(file, NULL, err);
  if (err != NULL)
{
  g_warning (The opening of uri gave %s, err-message);
  if(err) g_error_free (err);
  err = NULL;
}
 
But get Operation not supported message. It works ok with a local file 
(file:///home/...) should it be working for http?

Richard


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

Re: Gio library on Debian Lenny

[Richard Shann]

On Fri, 2009-05-15 at 19:12 +0300, Paul Pogonyshev wrote:
 Richard Shann wrote:
  Does anyone know if the gio library is working for getting files from
  the internet in the latest Debian Lenny distribution, x86?
 
 You probably need GVFS package.  GIO itself doesn't contain any
 implementations for remote access, only interfaces and local access,
 AFAIK.
Thank you for your quick reply. I have installed the gvfs package and
the g_file_read() function now does not return, which is progress of a
sort! (I realize there is an asynchronous version, but as the page is
fetchable, I presume this ought to be returning).
gdb says that it is blocked in __kernel_vsyscall () which sounds
reasonable; any thoughts on what to try next? (I guess strace might
help ...). Or am I missing something obvious? I didn't start any demon
associated with the gvfs package... I just let synaptic install it...
Thanks again,

Richard


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

Re: Gio library on Debian Lenny

[Richard Shann]

On Sat, 2009-05-16 at 12:00 +, gtk-app-devel-list-requ...@gnome.org
wrote:
 To: richard.sh...@virgin.net
 Cc: gtk-app-devel-list@gnome.org
 Message-ID: 20090516022833.415b5...@resin14.mta.everyone.net
 Content-Type: text/plain; charset=UTF-8
 
 Have you try GNet? http://www.gnetlibrary.org/
 it has support for http protocol object (GConnHttp) and also based on
 GLib.

Thanks for this link - I didn't know about this. If possible I will go
with gio as it would seem to be under more active development, though if
it is not actually yet working that would be little comfort :-)
Richard


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

Giving GtkFileChooser different backend functions.

[Richard Shann]

Does anyone know if it would be at all easy to intercept the calls the
GtkFileChooser widget makes to get files/directories?
I am sure it would take me too long to get to grips with the whole
subclassing thing to create a special version of the widget, but if I
could just sneak in there when it was wanting the list of
files/directories I would be a happy bunny. 
Preferably some hooks in the backend but even at the cost of having to
monitor version changes... can it be done in a few lines of code?
Richard Shann


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

Printing a .png using GtkPrint

[Richard Shann]

I am trying to use GtkPrint* to print a .png file, the code I have tried
pops up the print dialog but nothing arrives in the printer queue. The
draw page signal is being received when I ok the print dialog.

The function I am using for the draw-page signal to try and print is
this:

static void
draw_page (GtkPrintOperation *operation,
   GtkPrintContext   *context,
   gint   page_nr,
   gpointer   user_data) {
  if(page_nr==0){
g_print(printing page 0);
  //gtk_print_operation_set_use_full_page() and gtk_print_operation_set_unit()
  cairo_t * cr = gtk_print_context_get_cairo_context (context);
  cairo_surface_t *surface = cairo_image_surface_create_from_png 
(denemoprint_.png);
  cairo_status_t  status = cairo_surface_status(surface);
  if(status != CAIRO_STATUS_SUCCESS)
g_print(An error %d\n, status);
  cairo_set_source_surface (cr, surface, 0, 0);
  cairo_paint (cr);
  cairo_surface_destroy (surface);
  } else
gtk_print_operation_cancel (operation);
  g_print(returning from draw\n);
}

Which has been assembled from the gtk docs and the cairo samples at
http://www.cairographics.org/samples/
The draw_page function is being called for page_nr 0 and the png load is
ok but as I say, nothing more transpires.

The bits of code that I have invented here are the calls to
cairo_surface_destroy (surface); 
and 
gtk_print_operation_cancel (operation);

The first of these can be left out, but the second prevents draw_page
being called ad infinitum.

Anyone have a working example? I am using Debian Lenny standard standard
packages.

Richard Shann


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

Re: Custom font for application

[Richard Shann]

On Mon, 2011-07-25 at 12:00 +, gtk-app-devel-list-requ...@gnome.org
wrote:
 
 Does anyone here know how I can create and load a custom font for my
 application from the source code? What method or methods do I need to
 invoke to load the font that I can render? What rendering methods do I
 need to override so that my custom fonts are the ones rendered? Are
 there any examples of source code on how to achieve this? 

The GNU/Denemo music typesetter uses a custom font, called denemo.ttf
You can look at its Makefiles for installation hints and src/utils.c for
setting font load paths. It invokes this font by using gtk's markup
language thus:

/* markup the passed string to be in the denemo music font
* caller must free the returned string
*/
gchar * music_font(gchar *str) {
  return g_strdup_printf(span font_desc=\Denemo 12\%s/span,
str);
}

Where Denemo 12 is asking for denemo.ttf in 12pt.

I have all this at my fingertips because I want to change it so that I
don't have to switch fonts using markup, but instead use just one font
for both regular text and music symbols.
So I too need to know, how do you tell a gtk application to use a
specific font for all the widget labels and other text which it would
normally render in some default or use preferred font?

Richard Shann
http://www.denemo.org


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

Re: Custom font for application

[Richard Shann]

I sorted this out yesterday (see denemo-devel mailing list), what you need I 
suspect is along the lines of this:

GtkSettings *settings = gtk_settings_get_default( );
gtk_settings_set_string_property(settings, gtk-font-name , FreeSerif 12, 
denemo);
// Note: GTK complains that the font does not have a +ve size unless you 
mention, one as here.
gtk_main();

where FreeSerif 12 indicates the font you want the application to use, and 
the last string can be anything.

you will also need to call something like:

#include fontconfig/fontconfig.h
void add_font_directory(gchar *fontpath) {
#ifdef G_OS_WIN32
  AddFontResource(fontpath);
#else
  FcConfigAppFontAddDir(NULL, fontpath);
#endif
}

if the font isn't a system one.
Creating a font = fontforge, of course.

Richard


 On Mon, 2011-07-25 at 12:00 +, gtk-app-devel-list-requ...@gnome.org
 wrote:
  
  Does anyone here know how I can create and load a custom font for my
  application from the source code? What method or methods do I need to
  invoke to load the font that I can render? What rendering methods do I
  need to override so that my custom fonts are the ones rendered? Are
  there any examples of source code on how to achieve this? 
 
 The GNU/Denemo music typesetter uses a custom font, called denemo.ttf
 You can look at its Makefiles for installation hints and src/utils.c for
 setting font load paths. It invokes this font by using gtk's markup
 language thus:
 
 /* markup the passed string to be in the denemo music font
 * caller must free the returned string
 */
 gchar * music_font(gchar *str) {
   return g_strdup_printf(span font_desc=\Denemo 12\%s/span,
 str);
 }
 
 Where Denemo 12 is asking for denemo.ttf in 12pt.
 
 I have all this at my fingertips because I want to change it so that I
 don't have to switch fonts using markup, but instead use just one font
 for both regular text and music symbols.
 So I too need to know, how do you tell a gtk application to use a
 specific font for all the widget labels and other text which it would
 normally render in some default or use preferred font?

Richard Shann
http://www.denemo.org



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

Signals that do not get emitted

[Richard Shann]

At one time we had the GtkPrintOperation widget working, sending
begin_print and draw_page signals; now it no longer works - the callback
is never reached - and I wonder if anyone has some idea as to why that
should be.
It is not the specific bit of code that creates/launches the widget, but
something more generic (like disabling a class of signals, if such a
thing is possible). I say this because I only came across it when I
installed a widget from libevince which uses the GtkPrintOperation and
that fails to get the callbacks.
I have built the evince widget as a standalone program (see below) and
it works. But the same piece of code called from within our (large)
program does not.

This has been seen in Gtk 2.30.2 and also in Gtk-3 (not sure which
version).

Any ideas how this can happen? (the project is Denemo, www.denemo.org,
and the file concerned is print.c).

Below is the Evince widget demo code which I wrote to test out.

Richard Shann

#include stdio.h
#include gtk/gtk.h
#include evince-view.h


evince_print() {
GError *err = NULL;
  GFile   *file;
  gchar *filename = test.pdf;
  file = g_file_new_for_commandline_arg (filename);
  gchar *uri = g_file_get_uri (file);
  g_object_unref (file);
  EvDocument *doc = ev_document_factory_get_document (uri, err);
  if(err) {
g_warning (Trying to read the pdf file %s gave an error: %s, uri,
err-message);
if(err)
g_error_free (err);
err = NULL;
  } else {
EvPrintOperation *printop = ev_print_operation_new (doc);  
ev_print_operation_run (printop, NULL);
  }
}

int main(int argc, char **argv)
{

  GtkWidget *main_vbox, *top;
  gtk_init(argc, argv);
  ev_init();
  GtkWidget *printarea;
  top = gtk_window_new(GTK_WINDOW_TOPLEVEL);
  gtk_window_set_title(GTK_WINDOW(top), Evince Print Test);
 

  printarea = gtk_button_new_with_label(click me to print the file
test.pdf);  
  gtk_container_add (GTK_CONTAINER(top), (GtkWidget*)printarea);

  g_signal_connect (G_OBJECT (printarea), clicked,
  G_CALLBACK (evince_print), NULL);  
  gtk_widget_show_all(top);  
gtk_main();
return 0;
}

 end of source code
To build use something like

gcc testevince.c -o test -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
 -I/usr/include/libxml2   -pthread -I/usr/include/gtksourceview-2.0 
-I/usr/include/libxml2 -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include 
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/pixman-1 -I/usr/include/freetype2 
-I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   
-pthread -I/usr/include/librsvg-2 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/include/cairo 
-I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   
-I/usr/include/evince/2.30 -levview -levdocument

(a lot of that could be omitted I'm sure :)

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

Re: Signals that do not get emitted

[Richard Shann]

I have the solution, and it is potentially of general interest. It seems
that the GtkPrintOperation widget is interacting with the (Unix) SIGUSR1
signal, which our program started using a while ago to do the client
thing. Dropping the (unix) signal handler for that signal made the
(glib) signals on the GtkPrintOperation widget start to work again.
I don't know if that is documented anywhere.

Richard Shann




On Mon, 2011-11-21 at 12:00 +, gtk-app-devel-list-requ...@gnome.org
wrote:
 Message: 4
 Date: Sun, 20 Nov 2011 16:13:57 +
 From: Richard Shann richard.sh...@virgin.net
 To: gtk-app-devel-list@gnome.org
 Subject: Signals that do not get emitted
 Message-ID: 1321805637.2172.21.camel@debian2.myhost
 Content-Type: text/plain; charset=UTF-8
 
 At one time we had the GtkPrintOperation widget working, sending
 begin_print and draw_page signals; now it no longer works - the
 callback
 is never reached - and I wonder if anyone has some idea as to why that
 should be.
 It is not the specific bit of code that creates/launches the widget,
 but
 something more generic (like disabling a class of signals, if such a
 thing is possible). I say this because I only came across it when I
 installed a widget from libevince which uses the GtkPrintOperation and
 that fails to get the callbacks.
 I have built the evince widget as a standalone program (see below) and
 it works. But the same piece of code called from within our (large)
 program does not.
 
 This has been seen in Gtk 2.30.2 and also in Gtk-3 (not sure which
 version).
 
 Any ideas how this can happen? (the project is Denemo, www.denemo.org,
 and the file concerned is print.c). 

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

Cursor not visible in GtkTextView

[Richard Shann]

I have a GtkTextView widget which refuses to display the cursor. All the
other editing commands seem fine (marking text, switching to overwrite
mode and back) but despite calls to gtk_text_view_get_cursor_visible()
reporting TRUE, no cursor is visible.
This text view widget is packed in a scrolled window in a GtkVbox in a
GtkFrame in a GtkNotebook in a GtkWindow. If, instead I put it directly
in a top level window the cursor shows.
The Gtk version 2.20.1, does anyone have any insights into this problem?

Richard Shann


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

Re: Re: DLL Hell on Windows..

[Richard Shann]

On Sun, 2012-08-05 at 12:00 +, gtk-app-devel-list-requ...@gnome.org
wrote:
 Send gtk-app-devel-list mailing list submissions to
   gtk-app-devel-list@gnome.org
 
 To subscribe or unsubscribe via the World Wide Web, visit
   https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 or, via email, send a message with subject or body 'help' to
   gtk-app-devel-list-requ...@gnome.org
 
 You can reach the person managing the list at
   gtk-app-devel-list-ow...@gnome.org
 
 When replying, please edit your Subject line so it is more specific
 than Re: Contents of gtk-app-devel-list digest...
 
 
 Today's Topics:
 
1. Re: DLL Hell on Windows.. (Robin Vossen)
 
 
 --
 
 Message: 1
 Date: Sat, 4 Aug 2012 15:07:13 +0200
 From: Robin Vossen ro...@codeinject.org
 To: gtk-app-devel-list@gnome.org
 Subject: Re: DLL Hell on Windows..
 Message-ID:
   camrwj1fynmvos3a_pjwplrmbqff-acegxseyfyv9d3_gnvf...@mail.gmail.com
 Content-Type: text/plain; charset=ISO-8859-1
 
 Hello,
 
 I have figured out I require 2.4.0 of libatk (by reading headers).
 Who can give me libatk 2.4.0 prebuild for Windows (x86)?

I don't know if it would help, but the package
http://www.denemo.org/downloads/denemo-0.9.5rc5.exe
installs the gtk dlls including that one, not sure which version. So you
could lift them out of there I guess.
I have wondered why we use dlls on windows, we should link statically to
the libraries.

Richard Shann


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

Location for gspawn_win32_helper.exe in a static build.

[Richard Shann]

Hi,
at GNU/Denemo we are currently trying to use mxe to build statically for
windows. The gspawn_win32_helper.exe is built but installing it in the
path does not seem to work, giving the same error message as when it
wasn't available as a static binary:

Failed to execute helper program (Invalid argument)

Anyone know where it should be/if there are environment variables that
can be set to help glib here? As it is we cannot spawn processes.

Richard Shann


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

Re: Location for gspawn_win32_helper.exe in a static build.

[Richard Shann]

 Location for gspawn_win32_helper.exe in a static build.

It turns out there are two helper programs, and it was calling the other
one gspawn_win32_helper-console.exe which was not installed.

Richard Shann


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

gdk-pixbuf-query-loaders on Windows does nothing.

[Richard Shann]

Some years ago I was building GNU Denemo on windows and had some help
with running gdk-pixbuf-query-loaders. For some years now we have been
building the program by cross-compiling on GNU/Linux systems.
I don't think we have ever sorted out how to run the
gdk-pixbuf-query-loaders automatically on installation, however.

As a first step, I have tried to run gdk-pixbuf-query-loaders.exe
manually (with elevated permissions). The program executes but does not
seem to perform any I/O. It is built without debug symbols
unfortunately, but running it under gdb it will break at fopen a couple
of times, but otherwise there is no sign of it doing anything.

Does anyone have any idea what might be wrong?

(I should add that the program runs fine - apart from not loading .svg
files for which a loader is present - making extensive use of gtk)

Richard Shann





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

Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

I want to replace the existing GtkDrawingArea with a GtkLayout in a
large application (GNU Denemo).
When I do this just by substituting gtk_drawing_area_new() with
gtk_layout_new(NULL, NULL) I do not receive the configure_event and
scroll_event signals, although the code gtk_widget_add_events ..
GDK_EXPOSURE_MASK is still in place.

I suspect this is to do with the cryptic note that drawing has to be
done to the bin_window instead of window, but beyond that I am stumped.
The draw event is being handled fine, and mouse button clicks etc are
all working.

Any help in migrating from GtkDrawingArea to GtkLayout would be much
appreciated.

Richard Shann


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

Re:Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

I have constructed the following minimal example, it creates a GtkLayout
with one label inside it, sets the GDK_STRUCTURE_MASK on the GdkWindow
of the GtkLayout and connects the configure-event signal to a routine
that would just exit the main loop. Instead of exiting, the window is
created without the configure-event signal firing. The GdkWindow and its
mask are printed out and appear to be set as per the documentation.
Please can someone explain what is wrong!

#include gtk/gtk.h
static gboolean
configure_event ()
{
fprintf (stderr, configure-event\n);
gtk_main_quit ();
return FALSE;
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *layout;
GtkWidget *label1;

gtk_init (argc, argv);

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
   
layout = gtk_layout_new (NULL, NULL);
gtk_container_add (GTK_CONTAINER (window), layout);
   

label1 = gtk_label_new (label 1);

gtk_layout_put (GTK_LAYOUT (layout), label1, 10, 50);
  

gtk_widget_show_all (window);

GdkWindow *win = gtk_widget_get_window(layout); 
g_print(win is %p initial mask 0x%x\n, win, gdk_window_get_events (win));
gdk_window_set_events (win, gdk_window_get_events (win) | 
GDK_STRUCTURE_MASK);
g_print(After adding GDK_STRUCTURE_MASK mask 0x%x\n, 
gdk_window_get_events (win));
gtk_widget_add_events (layout, GDK_ALL_EVENTS_MASK);
g_signal_connect (layout, configure-event, G_CALLBACK (configure_event), 
NULL);

gtk_main ();

return 0;
}


Richard Shann

 From: Richard Shann rich...@rshann.plus.com
 To: gtk-app-devel-list@gnome.org
 Subject: Help replacing GtkDrawingArea with GtkLayout
 Message-ID: 1393771664.4221.117.ca...@debianbox.loc
 Content-Type: text/plain; charset=UTF-8
 
 I want to replace the existing GtkDrawingArea with a GtkLayout in a
 large application (GNU Denemo).
 When I do this just by substituting gtk_drawing_area_new() with
 gtk_layout_new(NULL, NULL) I do not receive the configure_event and
 scroll_event signals, although the code gtk_widget_add_events ..
 GDK_EXPOSURE_MASK is still in place.
 
 I suspect this is to do with the cryptic note that drawing has to be
 done to the bin_window instead of window, but beyond that I am stumped.
 The draw event is being handled fine, and mouse button clicks etc are
 all working.
 
 Any help in migrating from GtkDrawingArea to GtkLayout would be much
 appreciated.
 
 Richard Shann


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

Re: Re:Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

On Mon, 2014-03-03 at 16:49 +0100, Stefan Salewski wrote:
 On Mon, 2014-03-03 at 15:17 +, Richard Shann wrote:
  I have constructed the following minimal example,
 
 Yes indeed,
 
 https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-events
 
 This function must be called while a widget is unrealized.

Thank you for giving this some thought. I think it is not the case
however that the gtk_widget_show_all() call causes the widget to be
realized in gtk-speak, it just sets a flag on the widget to say it
should be visible (I am guessing).

I think I have just made a breakthrough with my problem however -
setting the configure-event signal handler on the parent GtkWindow
widget instead of the GtkLayout window it contains causes it to fire
off. I have tried this with the scroll-event too and that works. Why
this should be different from the case where I use a GtkDrawingArea I
have no idea, but it looks like I am cooking with gas!

Thank you once more

Richard



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

Re: Re:Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

On Mon, 2014-03-03 at 16:38 +0001, Bernhard Schuster wrote:
 On Mon, Mar 3, 2014 at 5:26 PM, Richard Shann
 rich...@rshann.plus.com wrote:
  On Mon, 2014-03-03 at 16:49 +0100, Stefan Salewski wrote: 
  On Mon, 2014-03-03 at 15:17 +, Richard Shann wrote:  I
  have constructed the following minimal example, Yes indeed,
  
  https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-set-events
   This function must be called while a widget is unrealized.
  Thank you for giving this some thought. I think it is not the case
  however that the gtk_widget_show_all() call causes the widget to be
  realized in gtk-speak, it just sets a flag on the widget to say it
  should be visible (I am guessing). I think I have just made a
  breakthrough with my problem however - setting the configure-event
  signal handler on the parent GtkWindow widget instead of the
  GtkLayout window it contains causes it to fire off. I have tried
  this with the scroll-event too and that works. Why this should be
  different from the case where I use a GtkDrawingArea I have no idea,
  but it looks like I am cooking with gas!
 
 Either - I strongly recommend to stick to
 
 
 gdk_window_add_events (win, GDK_STRUCTURE_MASK);
 
 
 which does not have any dependency on widget/window realization. (I
 found myself in that very same pit some time ago).

The docs indicate that this may be set anyway:

The ::configure-event signal will be emitted when the size, position or
stacking of the widget's window has changed. 
To receive this signal, the GdkWindow associated to the widget needs to
enable the GDK_STRUCTURE_MASK mask. GDK will enable this mask
automatically for all new windows.

Once I moved the signal handler attachment upwards in the widget
hierarchy it sprang into life without any explicit setting of the
GdkWindow mask.

Richard


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

Re: Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

 From: Jo?l Kr?hemann j...@weedlight.ch
 To: gtk-app-devel-list@gnome.org
 Subject: Re: Help replacing GtkDrawingArea with GtkLayout
 Message-ID: 1394327737.3369.3.camel@debian
 Content-Type: text/plain; charset=us-ascii
 
 Hi,
 
 Didn't before but may be check the following:
 
 g_object_set(G_OBJECT(layout),
   app-paintable\0, TRUE, 
   NULL);

Hmm, I hadn't noticed that property. It is presumably set ok since I can
draw and place widgets on the GtkLayout. It was the configure and scroll
events that I didn't receive.
BTW why do you have two NULL bytes at the end of the property name
(AFAIK only one is needed)?

Richard


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

Re: Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

On Mon, 2014-03-10 at 09:29 +0100, Joël Krähemann wrote:
 On Mon, 2014-03-10 at 09:26 +0100, Joël Krähemann wrote:
  On Sun, 2014-03-09 at 14:03 +, Richard Shann wrote:
From: Jo?l Kr?hemann j...@weedlight.ch
To: gtk-app-devel-list@gnome.org
Subject: Re: Help replacing GtkDrawingArea with GtkLayout
Message-ID: 1394327737.3369.3.camel@debian
Content-Type: text/plain; charset=us-ascii

Hi,

Didn't before but may be check the following:

g_object_set(G_OBJECT(layout),
  app-paintable\0, TRUE, 
  NULL);
   
   Hmm, I hadn't noticed that property. It is presumably set ok since I can
   draw and place widgets on the GtkLayout. It was the configure and scroll
   events that I didn't receive.
   BTW why do you have two NULL bytes at the end of the property name
   (AFAIK only one is needed)?
   
   Richard
   
   
  
  Assumed you get annoyed by warnings, you can slightly disable it. It's
  distribution depend what flags are per default on. For further reading:
  
  http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
  
  regards
  Joël
  
  
  ___
  gtk-app-devel-list mailing list
  gtk-app-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 
 You should ask why I forget to add GDK_SCROLL_MASK

Well, I didn't ask because I already tried it. The GtkLayout didn't
receive that nor the configure signal even with setting
GDK_ALL_EVENTS_MASK. What *did* work is receiving the events on the
parent.
But I am still curious why you have two NULL bytes termination your
signal name strings, the extra one must surely get ignored...

Richard


 
 gtk_widget_set_events (GTK_WIDGET (layout),
   GDK_EXPOSURE_MASK 
   | GDK_LEAVE_NOTIFY_MASK 
   | GDK_BUTTON_PRESS_MASK 
   | GDK_BUTTON_RELEASE_MASK 
   | GDK_POINTER_MOTION_MASK 
   | GDK_POINTER_MOTION_HINT_MASK 
   | GDK_SCROLL_MASK
   );
 
 then you have to
 
 g_signal_connect(G_OBJECT(layout), scroll-event\0,
   G_CALLBACK(layout_callback), NULL);
 
 
 gboolean
 layout_callback(GtkWidget *widget, GdkEvent *event, gpointer user_data)
 {
   /* do your thing */
 
   return(FALSE);
 }
 
 
 


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

Re: Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

On Tue, 2014-03-11 at 13:18 +0100, Joël Krähemann wrote:
 On Tue, 2014-03-11 at 08:12 +, Richard Shann wrote:
  On Tue, 2014-03-11 at 04:43 +0100, Joël Krähemann wrote:
   On Mon, 2014-03-10 at 09:52 +, Richard Shann wrote:
On Mon, 2014-03-10 at 09:29 +0100, Joël Krähemann wrote:
 On Mon, 2014-03-10 at 09:26 +0100, Joël Krähemann wrote:
  On Sun, 2014-03-09 at 14:03 +, Richard Shann wrote:
From: Jo?l Kr?hemann j...@weedlight.ch
To: gtk-app-devel-list@gnome.org
Subject: Re: Help replacing GtkDrawingArea with GtkLayout
Message-ID: 1394327737.3369.3.camel@debian
Content-Type: text/plain; charset=us-ascii

Hi,

Didn't before but may be check the following:

g_object_set(G_OBJECT(layout),
  app-paintable\0, TRUE, 
  NULL);
   
   Hmm, I hadn't noticed that property. It is presumably set ok 
   since I can
   draw and place widgets on the GtkLayout. It was the configure and 
   scroll
   events that I didn't receive.
   BTW why do you have two NULL bytes at the end of the property name
   (AFAIK only one is needed)?
   
   Richard
   
   
  
  Assumed you get annoyed by warnings, you can slightly disable it. 
  It's
  distribution depend what flags are per default on. For further 
  reading:
  
  http://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html
  
  regards
  Joël
  
  
  ___
  gtk-app-devel-list mailing list
  gtk-app-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 
 You should ask why I forget to add GDK_SCROLL_MASK

Well, I didn't ask because I already tried it. The GtkLayout didn't
receive that nor the configure signal even with setting
GDK_ALL_EVENTS_MASK. What *did* work is receiving the events on the
parent.
But I am still curious why you have two NULL bytes termination your
signal name strings, the extra one must surely get ignored...

Richard


 
 gtk_widget_set_events (GTK_WIDGET (layout),
   GDK_EXPOSURE_MASK 
   | GDK_LEAVE_NOTIFY_MASK 
   | GDK_BUTTON_PRESS_MASK 
   | GDK_BUTTON_RELEASE_MASK 
   | GDK_POINTER_MOTION_MASK 
   | GDK_POINTER_MOTION_HINT_MASK 
   | GDK_SCROLL_MASK
   );
 
 then you have to
 
 g_signal_connect(G_OBJECT(layout), scroll-event\0,
   G_CALLBACK(layout_callback), NULL);
 
 
 gboolean
 layout_callback(GtkWidget *widget, GdkEvent *event, gpointer 
 user_data)
 {
   /* do your thing */
 
   return(FALSE);
 }
 
 
 


   Is your code somewhere online? Are you using
   gtk_widget_set_size_request()?
   
  
  I gave a minimal example earlier in the thread:
  
  https://mail.gnome.org/archives/gtk-app-devel-list/2014-March/msg7.html
  
  
  Richard
  
  
 Much better! As someone told you before the widget is realized you have
 to set the appropriate flags.

The widget is not realized before the flags are set. Indeed gtk_main()
has not even been called, so no signals have been emitted when the flags
are set.
Here is the code with the sequence altered as you suggest:

8
#include gtk/gtk.h
static gboolean
configure_event ()
{
fprintf (stderr, configure-event\n);
gtk_main_quit ();
return FALSE;
}

int main(int argc, char *argv[])
{
GtkWidget *window;
GtkWidget *layout;
GtkWidget *label1;

gtk_init (argc, argv);

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
   
layout = gtk_layout_new (NULL, NULL);
gtk_widget_add_events (layout, GDK_ALL_EVENTS_MASK);
gtk_container_add (GTK_CONTAINER (window), layout);
   

label1 = gtk_label_new (label 1);

gtk_layout_put (GTK_LAYOUT (layout), label1, 10, 50);
  

gtk_widget_show_all (window);

GdkWindow *win = gtk_widget_get_window(layout); 
g_print(win is %p initial mask 0x%x\n, win, gdk_window_get_events
(win));
gdk_window_set_events (win, gdk_window_get_events (win) |
GDK_STRUCTURE_MASK);
g_print(After adding GDK_STRUCTURE_MASK mask 0x%x\n,
gdk_window_get_events (win));

g_signal_connect (layout, configure-event, G_CALLBACK
(configure_event), NULL);

gtk_main ();

return 0;
}



As you can verify, it makes no difference - it would be very bizarre if
it did.

 
 layout = gtk_layout_new (NULL, NULL);
 
 /* SET FLAGS HERE */
 
 gtk_container_add (GTK_CONTAINER (window), layout);
 
 
 and don't forget to add the missing parameters.

The parameters in the definition of the callback function
configure_event(void) are not missing, it is deliberately declared not
to have them. It is not a good idea to declare the callback with
parameters if they are not going to be used.

Richard


 
 gboolean
 configure_event(GtkWidget

Re: Help replacing GtkDrawingArea with GtkLayout

[Richard Shann]

On Tue, 2014-03-11 at 21:43 +0100, Joël Krähemann wrote:
[...]
  Please consider the documentation of gtk_widget_set_app_paintable()
  don't believe GtkLayout can do your job. You could try id with a
  GtkDrawingArea with a cairo surface. I do some drawing in C take a look
  at http://sourceforge.net/p/ags/code/HEAD/tree/src/ags/X/ags_editor.c
  
  regards Joël
  
  
  
  ___
  gtk-app-devel-list mailing list
  gtk-app-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 
 
 Finally got it you can't read GdkWindow before you didn't show the assigned 
 widget.

I am unsure what you mean by read GdkWindow, as you can see from the
console output when running the minimal example the GdkWindow attached
to the GtkLayout does exist and does get its flags set. Those g_print()
statements are there to confirm that fact.

 
 #include gtk/gtk.h
 
 gboolean
 configure_event (GtkWidget *widget,
  GdkEventConfigure *configure,
  gpointer data)
 {
   fprintf (stderr, configure-event\n);
   gtk_main_quit ();
   return FALSE;
 }
 int main(int argc, char *argv[])
 {
   GtkWidget *window;
   GtkWidget *layout;
   GtkWidget *label1;
   GdkWindow *win;
 
   gtk_init (argc, argv);
 
   window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
 
   layout = gtk_layout_new (NULL, NULL);
   g_object_set(G_OBJECT(layout),
app-paintable, TRUE,
NULL);
 
   gtk_widget_add_events (layout, GDK_ALL_EVENTS_MASK);
   gtk_container_add (GTK_CONTAINER (window), layout);
 
   label1 = gtk_label_new (label 1);
 
   gtk_layout_put (GTK_LAYOUT (layout), label1, 10, 50);
 
 
   gtk_widget_show_all (window);
 
   win = gtk_layout_get_bin_window (GTK_LAYOUT(layout));
   g_print(win is %p initial mask 0x%x\n, win, gdk_window_get_events
   (win));
   gdk_window_set_events (win, gdk_window_get_events (win) |
  GDK_STRUCTURE_MASK);
   g_print(After adding GDK_STRUCTURE_MASK mask 0x%x\n,
   gdk_window_get_events (win));
 
   g_signal_connect (layout, configure-event,
 G_CALLBACK (configure_event), NULL);
 
   gtk_main ();
 
   return 0;
 }
 

When I compile the version you have given the code behaves as before,
the window pops up (because the configure-event signal has not been
received, whose callback would cause an exit).
Are you saying it does something different for you?

Richard


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

GtkTextView background color when not focused

[Richard Shann]

Hi,

When a GtkTextView widget does not have the keyboard focus I would like
it to be grayed out, so that the user knows his keystrokes are going
elsewhere.


GdkRGBA color = {0.5, 0.5, 0.5, 1.0};
gtk_widget_override_background_color (staff-currentverse-data, 
GTK_STATE_FOCUSED, color);

and the like are not doing it, because presumably these would affect the
border of the text.
I would prefer not to have to insert and remove tags from the text on
the focus signal - is there any way to achieve this otherwise?

Richard Shann


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

A simple choice dialog won't work...

[Richard Shann]

I wanted to pop up two buttons for the user to choose between two
options (primary and secondary), returning true or false depending
which was chosen. I tried this

gboolean
choose_option (gchar *title, gchar * primary, gchar * secondary)
{
  GtkWidget *dialog;
  dialog = gtk_dialog_new_with_buttons (title, 
GTK_WINDOW (Denemo.window), 
(GtkDialogFlags) (GTK_DIALOG_MODAL | 
GTK_DIALOG_DESTROY_WITH_PARENT),
primary, GTK_RESPONSE_ACCEPT,
secondary,GTK_RESPONSE_REJECT,
NULL);
  g_signal_connect_swapped (dialog, response, G_CALLBACK 
(gtk_widget_destroy), dialog);
  
  return (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT);
}

but it seems to return 0 for both button presses. What am I doing wrong?

I'm using GTK3 on a Debian stable installation.

Richard


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

Re: A simple choice dialog won't work...

[Richard Shann]

On Thu, 2015-05-07 at 16:21 +0200, Stefan Salewski wrote:
 On Thu, 2015-05-07 at 13:02 +0100, Richard Shann wrote:
 
 From https://developer.gnome.org/gtk3/stable/GtkDialog.html
 
 GTK_RESPONSE_REJECT Generic response id, not used by GTK+ dialogs
 GTK_RESPONSE_ACCEPT Generic response id, not used by GTK+ dialogs
 
 Maybe try
 
 GTK_RESPONSE_OK and GTK_RESPONSE_CANCEL

Hmm, I wonder what that means - Generic response id ... I understood
that the idea of the pairs in the trailing arguments of
gtk_dialog_new_with_buttons () was that the button with the given text
would return the paired response id. I tried the ones you suggested, and
also two positive values with the same result.

After experimenting with a different bit of code, I think I've found the
cause of the problem: doing the widget destroy by responding to the
response signal seems to be ruining the return value.
So, I seem to be back on track - the code that works is below.
Thank you for your prompt response!

Richard

gboolean
choose_option (gchar *title, gchar * primary, gchar * secondary)
{
  GtkWidget *dialog;
  gboolean r;
  dialog = gtk_dialog_new_with_buttons (title, GTK_WINDOW (Denemo.window), 
(GtkDialogFlags) (GTK_DIALOG_MODAL | GTK_DIALOG_DESTROY_WITH_PARENT), 
  primary, 
GTK_RESPONSE_ACCEPT, secondary, GTK_RESPONSE_REJECT, NULL);
  //g_signal_connect_swapped (dialog, response, G_CALLBACK 
(gtk_widget_destroy), dialog);
  r = (gtk_dialog_run (GTK_DIALOG (dialog)) == GTK_RESPONSE_ACCEPT);
  gtk_widget_destroy (dialog);
  return r; 
}

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

[Richard Shann]

On Mon, 2015-08-10 at 15:05 +0100, Emmanuele Bassi 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.

I'm sorry if the word cripples seemed strong to you, I intended it in
a purely technical sense of removes a major part of the functionality.
Since the widget in question only has one non-optional feature: The
frame widget is a Bin that surrounds its child with a decorative frame
and an optional label, it is clearly the major part of the
functionality.  I can't think of another English word for this meaning
(vitiated? emasculated? these are not so common/have bad connotations).

 
 Grouping can be achieved by white space, for instance. Or by changing
 the background color. Or by changing the typographical appearance.

Thank you for these excellent suggestions. I tried 

gtk_widget_override_background_color (frame, GTK_STATE_FLAG_NORMAL, color);

but could not see the effect (even adding padding or applying it to the
child GtkBox of the frame). I did however get colored labels by using
gtk_widget_override_color(), but then I read that these calls are
deprecated and that a lot more code would be required to do this
involving setting up styles.

 
 Just because you expect a border,

Well, I didn't expect a border until I read the documentation:
The frame widget is a Bin that surrounds its child with a decorative
frame and an optional label.
then I expected a decorative frame surrounding the widget. I guess that
a theme could make all widgets invisible if it chose to set the
foreground color equal to the background color, but I don't expect theme
designers to do that or anything else that essentially negates the
documented behavior.

  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,

then that should be the default and the Description should read

The frame widget is a Bin that surrounds its child with a, (by default
invisible), decorative frame and an optional label.

  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

a developer will only look up the documentation on the shadow type if
they have some reason not to use the default. So they won't see this
caveat, which after all would surely apply to most things - a theme
could be created to cripple almost any widget I would guess.

What would be nice would be to give GtkFrame the features suggested in
the GNOME HIG document you cited:

gtk_frame_new_with_markup ()
gtk_frame_set_indent ()

where the indent would behave nicely under re-sizing. Then the default
of GTK_SHADOW_NONE would make sense (else GtkFrame is almost a synonym
for GtkBin). Well, I hope that is a constructive suggestion,

best wishes

Richard Shann










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

GtkFrame has no frame border drawn?

[Richard Shann]

I've recently noticed that the GtkFrames in my application have lost the
line drawn around the frame - the text is present but not the line.
I see that in the documentation

file:///usr/share/doc/libgtk-3-doc/gtk3/ch03.html

the widget is illustrated without any line too. I am building and
running against GTK version 3.4.2 on 64-bit Debian Wheezy.

The same application built for Windows using GTK 3.6.5 *does* show a
line around frames, albeit rather indistinct...

Is this a known bug?

Richard Shann


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

[Richard Shann]

On Mon, 2015-08-10 at 09:05 +0100, Emmanuele Bassi 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.

Thank you for explaining the problem. As a developer of a free software
program using GTK+ I consult the documentation to choose suitable
widgets to communicate with the users of my program. 

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.

From Chris Vine's reply (thank you too, Chris) I gather that this is a
bug which has been rectified in more recent versions of the default
theme - I am currently summoning up my courage to upgrade to Debian
Jessie, and most people I guess will have even more recent versions. So
I can treat this as a closed issue.

Thank you for help

Richard Shann



 
 Ciao,
  Emmanuele.
 
 
 On 9 August 2015 at 17:07, Richard Shann rich...@rshann.plus.com wrote:
  I've recently noticed that the GtkFrames in my application have lost the
  line drawn around the frame - the text is present but not the line.
  I see that in the documentation
 
  file:///usr/share/doc/libgtk-3-doc/gtk3/ch03.html
 
  the widget is illustrated without any line too. I am building and
  running against GTK version 3.4.2 on 64-bit Debian Wheezy.
 
  The same application built for Windows using GTK 3.6.5 *does* show a
  line around frames, albeit rather indistinct...
 
  Is this a known bug?
 
  Richard Shann
 
 
  ___
  gtk-app-devel-list mailing list
  gtk-app-devel-list@gnome.org
  https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 
 
 


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

Re: [Denemo-devel] Tooltips - what am I doing wrong?

[Richard Shann]

On Wed, 2015-11-18 at 12:27 +, Emmanuele Bassi wrote:
> Hi;
> 
> On 18 November 2015 at 11:16, Richard Shann <rich...@rshann.plus.com> wrote:
> 
> > I've tracked this down, in the latest manual for gtk3:
> > https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-tooltip-browse-timeout
> > GtkSettings:gtk-tooltip-browse-timeout has been deprecated since version 
> > 3.10 and should not be used in newly-written code.
> > This setting is ignored.
> >
> > So, it is a "feature". It appears to be the case that even the regular
> > time before a tooltip appears can no longer be controlled, which many
> > people will find intolerable (I know of people who set very long times
> > on the tooltips, basically because it takes them long enough to read the
> > labels on menu items, so that having tooltips pop up while they are
> > looking for something is annoying - they would take a long time to read
> > a tooltip anyway).
> > I think we'll have to disable tooltips for GTK version 3.10 and above.
> > Fortunately the tooltip information is still available for commands,
> > it's just all the help for playback controls etc etc that will get lost.
> 
> I honestly don't understand why would application developers expose a
> tweak to ensure their applications don't behave like any other
> application on the system.
> 
> If the people that are not interested in tooltips, and thus change the
> timeout to ensure that they are not subject to them, then you can
> simply offer a way to disable all tooltips on your controls without
> any loss of functionality — after all, these people are not interested
> in tooltips in the first place.
> 
> If this is an accessibility issue, like you seem to present it, then
> we definitely need a session-wide toggle that changes the delay for a
> tooltip to be raised for all applications, not just one. That would be
> a great thing to introduce in the session, and I'd be happy to review
> a patch to that effect.
> 
> > But in the longer term we are coming up to a crunch - the people
> > developing Gtk are clearly only interested in a narrow group of users.
> 
> Defining "narrow" as "the group that I'm not in" is not conducive to
> an honest discussion.

which is why I didn't do anything so idiotic as to define narrow as "not
my group". But you could very reasonably argue that "wide" equates to
large numbers of users and narrow to a few. Whereas, what I had in mind
is wide equating to diverse and complex uses and narrow just to the
popular simple uses. You can send an email and switch to a calendar and
lookup a web page with a simple interface comprising a few gestures, but
you can't do complex technical tasks efficiently that way. 

>  You already reached your conclusion, and I'm
> honestly not interested in convincing you, at that point.
> 
> Personally, I think the amount of users GTK is interested in covers
> much, much more than the people tweaking their applications to change
> the timeout of the tooltip on a per application basis — but I'm
> *personally* interested in getting application developers to stop
> considering GTK as a black box, where you just consume an API.
> 
> I've recently run some numbers on the GTK repository[0][1], and it's
> clear that while the contributors change over the years, the number of
> contributors is mostly stable; this means that new features come at
> the expense of deprecations — otherwise there are simply not enough
> resources to grow the toolkit while maintaining the old API
> indefinitely.
> 
> For better or worse, the world of computing is changing. 

I think this is the crux of the matter. The "world of computing" has
been joined (swamped?) by millions of new users with new devices that
can't be used for complex tasks (which those millions would not think of
attempting anyway). And the GTK project is adapting to this "big
league".
So, I think you may have answered my question "Where do we go?": we will
have to revert to Gtk2 sooner or later. 

I guess the problem is that if we continue to offer a Gtk3 version the
GNU/Linux distributions will want to build against ever-newer versions
of Gtk3 with resultant problems like the one that started this thread.

Richard


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

Re: [Denemo-devel] Tooltips - what am I doing wrong?

[Richard Shann]

On Wed, 2015-11-18 at 17:15 +, Emmanuele Bassi wrote:
> Hi;
> 
> On 18 November 2015 at 16:55, Richard Shann <rich...@rshann.plus.com> wrote:
> 
> >> > But in the longer term we are coming up to a crunch - the people
> >> > developing Gtk are clearly only interested in a narrow group of users.
> >>
> >> Defining "narrow" as "the group that I'm not in" is not conducive to
> >> an honest discussion.
> >
> > which is why I didn't do anything so idiotic as to define narrow as "not
> > my group". But you could very reasonably argue that "wide" equates to
> > large numbers of users and narrow to a few. Whereas, what I had in mind
> > is wide equating to diverse and complex uses and narrow just to the
> > popular simple uses. You can send an email and switch to a calendar and
> > lookup a web page with a simple interface comprising a few gestures, but
> > you can't do complex technical tasks efficiently that way.
> 
> You still haven't demonstrated that "changing tooltip delay",

a complex task can be helped by having tooltips on every thing the user
might click on, it turns out that having such a density of tooltips
results (I am told at the start of this thread) with popup tooltips
happening continuously and, since 3.10 uncontrollably.

>  having
> frame widgets draw a box,

a complex task can be helped by dividing the feedback to the user up
with frames round the different bits.

>  or dropping tear-off menus, 

a complex task can be organized into a hierarchy of menus, which when
you arrive at the right one it is convenient to tear off and use as a
palette. Denemo now has palettes and a right click on the menu item
allows the user to place the menu item as a button in a palette...

> equates to
> "performing complex tasks"
>  — unless, obviously, you consider the
> current Denemo UI the only way to perform complex tasks,
> in which case
> I strongly encourage you to look at the wider world of user
> interaction and design, including in the proprietary world.

No, I don't consider it the only way of doing the job, but re-designing
the program is not appealing to me personally, since "it ain't broke"
and my interest is mainly in what the program achieves and how easily
and musically it achieves it, not whether it works in a similar way to
the email program I use.

Having said that, Denemo's user interface is evolving - the palettes
feature mentioned above will mitigate the lack of tear-off menus. I
don't relish reworking the tooltip system, though again, for menu items
at least, that is mitigated by the help available by right clicking the
item rather than waiting for the tooltip.

But really, this last one just seems like a bug - Denemo is not unusual
except by using tooltips as much as possible. So if people are finding
Gtk>3.10 makes Denemo unusable it would seem to merit a bug report.

Richard

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

Re: Which toplevel window is on top?

[Richard Shann]

On Sun, 2015-12-20 at 19:22 +, Emmanuele Bassi wrote:
> Hi;
> 
> On 20 December 2015 at 18:01, Richard Shann <rich...@rshann.plus.com> wrote:
> > I would like to know which of the top-level windows in my application is
> > on top. Is there a way of doing this? I see that
> 
> You can only see if your window has focus or contains the pointer —
> i.e. it's the one that the user is interacting with at this very
> moment. That usually implies that the window is at the top of the
> stack maintained by the window manager. You could also check if the
> "always-on-top" bit is set, but obviously that does not guarantee that
> the user is interacting with the window.
> 
> Any other information about the window stack is maintained by the
> window manager itself, and you'll have to ask that component, using
> window manager and platform specific API, if an API is even exposed.
> 
> > 
> > GdkEventVisibility has been deprecated since version 3.12 and should not
> > be used in newly-written code.
> >
> > Modern composited windowing systems with pervasive transparency make it
> > impossible to track the visibility of a window reliably, so this event
> > can not be guaranteed to provide useful information.
> > -
> > but is there an alternative for my (simpler) question?
> 
> There is, sadly, nothing "simple" about your question. It truly
> depends on the platform, and on top of that, it depends on how your
> windows are managed.
> 
> For instance, in a tiled window management policy, windows are not
> stacked — hence, there is no conventional "on top". Compositing window
> managers on X11, such as Mutter or Compiz, may re-arrange the windows
> as displayed to the user, even if the user cannot interact with them
> outside of the existing stacking order; again, "on top" is not
> something that can be conveyed to an API, when your windows are in
> "exposé" or laid out on the faces of a 3D solid. Finally, on Wayland,
> each surface has no knowledge of anything outside its own coordinate
> space; there is no way to access the windows stacking, and for all
> intent and purposes, your window manager may put the application's
> window on Mars.
> 
> The only reliable way thing you can know is if the user is currently
> interacting with a window you're presenting, via pointer, touch, or
> keyboard events; either because the pointer or a finger entered the
> window, or because the window has key focus. GTK+ provides you with
> events to let you know when any of those things happens.

Thank you for your clear and comprehensive explanation. I think I will
need to provide an option to move all the windows inside a single
application window, or two if there are two screens.

Richard


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

gtk_image_new_from_file fails on Windows for SVG

[Richard Shann]

For a long time now I have been working around 
gtk_image_new_from_file ()

not working on windows trying to load SVG images. Instead I have used

pb = rsvg_pixbuf_from_file (filename, );

and then

gtk_image_new_from_pixbuf (pb)

and this works for some SVG images. However, even this is failing for
the SVG files generated by LilyPond, it generates an image with only the
background color.

I thought this might be due to the use of the syntax "currentColor" but
changing this to "black" did not help. I also noticed that rsvg library
has a change log entry for fixing rgb color parsing, so avoided that
syntax, but I still can't get the images to load on Windows. The Gtk
version being built (and run) against is 3.6.5 
Any suggestions what might be causing the trouble in LilyPond's output?

Richard


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

Which toplevel window is on top?

[Richard Shann]

I would like to know which of the top-level windows in my application is
on top. Is there a way of doing this? I see that


GdkEventVisibility has been deprecated since version 3.12 and should not
be used in newly-written code.

Modern composited windowing systems with pervasive transparency make it
impossible to track the visibility of a window reliably, so this event
can not be guaranteed to provide useful information.
-
but is there an alternative for my (simpler) question?

Richard Shann


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

Re: [Denemo-devel] Tooltips - what am I doing wrong?

[Richard Shann]

On Sat, 2015-11-28 at 12:00 +, gtk-app-devel-list-requ...@gnome.org
wrote:
> Date: Fri, 27 Nov 2015 20:42:25 +0100 (CET)
> From: Lucas Levrel 
> To: gtk-app-devel-list@gnome.org
> Subject: Re: [Denemo-devel] Tooltips - what am I doing wrong?
> Message-ID: 
> Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
> 
> Le 27 novembre 2015, John Coppens a ?crit :
> > I think those 'tear-offs' are not the same ones as referred to here.
> > The 'main menu bar' of GIMP doesn't have tear-offs anymore. I
> believe
> > the ones you are showing are from right-clicking on the canvas.
> 
> Right.
> 
> > I also suspect that the complexities arise from detaching menus from
> > the main menu bar, not from the right-click, which is already a
> > pop-up
> 
> Thanks for clarifying. This said, I don't see much difference between
> e.g. 
> the sub-menus of a menu and those of the right-click pop-up. Never
> mind.

And, indeed, it is particularly in the sub-sub-sub menus where it is
very handy to tear-off a menu to be used for a few minutes.

I notice that gimp has no tooltips on its menu items - perhaps they were
forced to abandon them when the Gtk developers decided to make them pop
up uncontrollably fast as you move down a menu... I've worked around
this "feature" in Denemo now by allowing people to press the f1 key
while hovering on a menu item to bring up the (otherwise disabled)
tooltip.

Richard

> 
> 


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

Re: [Denemo-devel] Tooltips - what am I doing wrong?

[Richard Shann]

On Wed, 2015-11-18 at 10:35 +0100, Johan Vromans wrote:
> On Wed, 18 Nov 2015 07:59:38 +
> Richard Shann <rich...@rshann.plus.com> wrote:
> 
> > One of the time settings available in the preferences sets the browse
> > timeout, choosing a value for this (and, possibly, re-starting the
> > program) causes a call the gtk to set that value.
> > From what you say, none of these calls to set the timings were being
> > honored in Gtk 3.10?
> 
> From what I can deduce from experimenting with several programs:
> 
> a. There's an initial delay for a tooltip popup that is approx 1 second. I
>haven't found a (system/global) setting that can change the delay time.
> 
> b. If two sensitive areas are more or less adjacent, and one is showing the
>tooltip popup, moving to the other area immedeately shows its popup. Only
>when the mouse gets some time in between the areas, approx 0.5 seconds,
>the popup delay timer is restarted. 
> 
> This behaviour seems consistent between all Gtk-based applications I have
> tried, both Gtk 2 and Gtk 3 based.
> 
> Apparently, before Gtk 3.10, it was possible to control the popup delay
> time, and, also apparently, that disabled (circumvents) the behaviour
> described at b. above.
> 
> But this was changed in Gtk 3.10. Now all applications behave consistent
> according to a. and b. above. Since Denemo is heavily equipped with
> tooltips-sensitive areas, moving the mouse will almost always cause popping
> up tooltips all of the time.
> 
> > Are you able to use a bug-fixed version of Gtk?
> 
> Are you saying this has been ackowledged as a bug, and a bug fix exists?
> I have no problems building my own Gtk libraries, as long as an officially
> fixed version is in the works.

I've tracked this down, in the latest manual for gtk3:
https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-tooltip-browse-timeout
GtkSettings:gtk-tooltip-browse-timeout has been deprecated since version 3.10 
and should not be used in newly-written code.
This setting is ignored.

So, it is a "feature". It appears to be the case that even the regular
time before a tooltip appears can no longer be controlled, which many
people will find intolerable (I know of people who set very long times
on the tooltips, basically because it takes them long enough to read the
labels on menu items, so that having tooltips pop up while they are
looking for something is annoying - they would take a long time to read
a tooltip anyway).
I think we'll have to disable tooltips for GTK version 3.10 and above.
Fortunately the tooltip information is still available for commands,
it's just all the help for playback controls etc etc that will get lost.

But in the longer term we are coming up to a crunch - the people
developing Gtk are clearly only interested in a narrow group of users.
They decide that menus should not be torn off, and that is that, despite
the fact that Denemo users do tear off menus if they are going to be
using them for a while. They decide that GtkFrames should not have a
frame drawn, and so on.

Any suggestions as to where we might go?

Richard










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

Re: [Denemo-devel] Tooltips - what am I doing wrong?

[Richard Shann]

On Wed, 2015-11-18 at 23:41 +0100, Johan Vromans wrote:
> On Wed, 18 Nov 2015 18:49:52 +
> Richard Shann <rich...@rshann.plus.com> wrote:
> 
> > I've pushed a fix that turns off tooltips on menus while leaving them on
> > everything else (for GTK version >=3.10).
> > Can you test if this makes a usable interface?
> 
> It doesn't, and I fail to see why it should...
> (I backported the fix to 2.0.0 but I do not think that matters.)
> 
> Not setting a tooltip on the individual menus

it is the menu *items* that have the tooltip disabled. I was imagining
the problem came when moving the cursor down the menus, that is the
browse mode. Experimenting yesterday I saw that if you don't have a
tooltip on an widget then the enclosing widget's tooltip fires, so I can
imagine there is no escape if tooltip timing is now ordained from above.

I have just looked at gimp 2.8.2 and it has the tooltips popping up
uncontrollably as you move down menus, the only saving grace is that
there aren't quite so many menu items one after the other with tooltips
as Denemo has.

>  makes little sense if there's
> still a tooltip on the menu bar itself.
> 
> Moreover, everything else, all buttons, all areas on the window, still have 
> tooltips, so there's really no difference with the unfixed version.
> 
> I'm afraid disabling all tooltips for Gtk >= 3.10 is the only option.

I've put a fix like that in git now.

> 
> Maybe our Gnome3 friend on the list has a suggestion what mechanism should
> be used instead of tooltips?

Emmanuele was only able to help because I copied the email to the
gtk-app-devel-list, I'll cc this one there too, in case this might be
taken seriously as a bug in Gtk which they might be glad to get feedback
on. The version of gimp that I have does seem to be adversely impacted.

Richard





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

Re: [Denemo-devel] Tooltips - what am I doing wrong?

[Richard Shann]

On Thu, 2015-11-19 at 13:33 +, Richard Shann wrote:
> On Thu, 2015-11-19 at 12:01 +, Emmanuele Bassi wrote:
> > Hi;
> > 
> > On 19 November 2015 at 09:53, Richard Shann <rich...@rshann.plus.com> wrote:
> > > On Wed, 2015-11-18 at 23:41 +0100, Johan Vromans wrote:
> > >> On Wed, 18 Nov 2015 18:49:52 +
> > >> Richard Shann <rich...@rshann.plus.com> wrote:
> > >>
> > >> > I've pushed a fix that turns off tooltips on menus while leaving them 
> > >> > on
> > >> > everything else (for GTK version >=3.10).
> > >> > Can you test if this makes a usable interface?
> > >>
> > >> It doesn't, and I fail to see why it should...
> > >> (I backported the fix to 2.0.0 but I do not think that matters.)
> > >>
> > >> Not setting a tooltip on the individual menus
> > >
> > > it is the menu *items* that have the tooltip disabled. I was imagining
> > > the problem came when moving the cursor down the menus, that is the
> > > browse mode. Experimenting yesterday I saw that if you don't have a
> > > tooltip on an widget then the enclosing widget's tooltip fires, so I can
> > > imagine there is no escape if tooltip timing is now ordained from above.
> > >
> > > I have just looked at gimp 2.8.2 and it has the tooltips popping up
> > > uncontrollably as you move down menus, the only saving grace is that
> > > there aren't quite so many menu items one after the other with tooltips
> > > as Denemo has.
> > 
> > If this is happening on Gimp 2.8.2, it means that the issue has
> > nothing to do with GTK 3.x, since Gimp 2.8.2 is still very much using
> > GTK 2.x
> 
> Actually, what I think it indicates is that the Gtk team have for a long
> time had a sense of good default values for tooltip timeout and tooltip
> browse timeout which don't suit the more complex programs such as gimp.
> (I'm guessing here that gimp is using the default values); indeed as I
> move down the menus in gimp unless they are broken up by non-tooltip
> items the tooltips once started are difficult to shake off. 
> 
> I strongly suspect that is why I looked up the API and gave the user
> control in Denemo. All that has happened in Gtk 3.10 is that the user no
> longer gets control. Looking at other applications that my (old -
> Wheezy) Debian distro provides I see that most do not have tooltips,
> Evince in particular is at version 3.4.0 and has no tooltips and
> Evolution 3.4.4 has none either.

Well, Evolution has none on the menu items, it *does* have them on tool
buttons. I notice that the calculator gcalc has them on the buttons but
not on menu items as well, and again they are quite difficult to shake
off once it has got into browse mode. I suspect most people would find
that ideally they would want them to start after a longer delay as well;
but programs like this don't get much critical attention, people aren't
working with them for hours on end.

Richard






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

Re: [Denemo-devel] Tooltips - what am I doing wrong?

[Richard Shann]

On Thu, 2015-11-19 at 12:01 +, Emmanuele Bassi wrote:
> Hi;
> 
> On 19 November 2015 at 09:53, Richard Shann <rich...@rshann.plus.com> wrote:
> > On Wed, 2015-11-18 at 23:41 +0100, Johan Vromans wrote:
> >> On Wed, 18 Nov 2015 18:49:52 +
> >> Richard Shann <rich...@rshann.plus.com> wrote:
> >>
> >> > I've pushed a fix that turns off tooltips on menus while leaving them on
> >> > everything else (for GTK version >=3.10).
> >> > Can you test if this makes a usable interface?
> >>
> >> It doesn't, and I fail to see why it should...
> >> (I backported the fix to 2.0.0 but I do not think that matters.)
> >>
> >> Not setting a tooltip on the individual menus
> >
> > it is the menu *items* that have the tooltip disabled. I was imagining
> > the problem came when moving the cursor down the menus, that is the
> > browse mode. Experimenting yesterday I saw that if you don't have a
> > tooltip on an widget then the enclosing widget's tooltip fires, so I can
> > imagine there is no escape if tooltip timing is now ordained from above.
> >
> > I have just looked at gimp 2.8.2 and it has the tooltips popping up
> > uncontrollably as you move down menus, the only saving grace is that
> > there aren't quite so many menu items one after the other with tooltips
> > as Denemo has.
> 
> If this is happening on Gimp 2.8.2, it means that the issue has
> nothing to do with GTK 3.x, since Gimp 2.8.2 is still very much using
> GTK 2.x

Actually, what I think it indicates is that the Gtk team have for a long
time had a sense of good default values for tooltip timeout and tooltip
browse timeout which don't suit the more complex programs such as gimp.
(I'm guessing here that gimp is using the default values); indeed as I
move down the menus in gimp unless they are broken up by non-tooltip
items the tooltips once started are difficult to shake off. 

I strongly suspect that is why I looked up the API and gave the user
control in Denemo. All that has happened in Gtk 3.10 is that the user no
longer gets control. Looking at other applications that my (old -
Wheezy) Debian distro provides I see that most do not have tooltips,
Evince in particular is at version 3.4.0 and has no tooltips and
Evolution 3.4.4 has none either.

>  — unless, obviously, the change predates the branching of GTK
> 2.x and 3.x, in which case punting to GTK 3.10 won't do you any good.
> 
> It may be a case of a backported patch; since it's easier to bisect on
> the gtk-2-24 branch, would you be able to do so, and identify the
> commit in GTK that introduced this behaviour?
> 
> > Emmanuele was only able to help because I copied the email to the
> > gtk-app-devel-list, I'll cc this one there too, in case this might be
> > taken seriously as a bug in Gtk which they might be glad to get feedback
> > on. The version of gimp that I have does seem to be adversely impacted.
> 
> Feel free to open a bug on Bugzilla:
> 
>   https://bugzilla.gnome.org/enter_bug.cgi?product=gtk%2B

Thanks for the link, it is often difficult to track down the place to
raise an issue.

Richard



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

Workaround for too-fast tooltips

[Richard Shann]

Here are two macros that developers may need when building with GTK versions 
above 3.10
They replace the tooltip system with a call to a custom display of the
tooltip.


#define gtk_widget_set_tooltip_text(w, t) {gchar *tip = 
g_strdup(t);g_object_set_data(G_OBJECT(w), "tooltip", 
(gpointer)tip);gtk_widget_add_events (w, 
FAKE_TOOLTIPS_MASK);g_signal_connect_after (w, "destroy", 
G_CALLBACK(free_tooltip), tip);g_signal_connect (w, FAKE_TOOLTIPS_SIGNAL, 
G_CALLBACK (show_tooltip), tip);}

#define gtk_widget_get_tooltip_text(w) g_object_get_data (G_OBJECT(w), 
"tooltip")

You have to write the functions show_tooltip()and free_tooltip() yourself, of 
course.

The background to this is that if your applications uses tooltips
heavily (e.g. on every item of a menu) then recent versions of GTK3
throw them up too quickly, and once they start to appear they are very
difficult to throw off; the tooltip time out is no longer controllable.


Richard Shann


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

caret-color (and caret-width?)

[Richard Shann]

I see at

https://developer.gnome.org/gtk3/stable/chap-css-properties.html

that there is a caret-color property. Is it possible to change the
thickness of the text caret?

and, how exactly is caret-color supposed to be set I have:

str = "GtkTextView {caret-color: rgb(255,0,80);}";
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);

but this doesn't seem to work (I have other code such as

str =  "GtkTextView:selected {background-color: rgb(200,128,0);}";
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);

working nicely).

Richard Shann


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

Re: caret-color (and caret-width?)

[Richard Shann]

> From: Colomban Wendling <lists@herbesfolles.org>
> To: gtk-app-devel-list@gnome.org
> Subject: Re: caret-color (and caret-width?)
> Message-ID: <6524684c-f52e-ec20-0906-b63224766...@herbesfolles.org>
> Content-Type: text/plain; charset=windows-1252
> 
> Hi,
> 
> Le 26/01/2017 ? 16:57, Richard Shann a ?crit :
> > I see at
> > 
> > https://developer.gnome.org/gtk3/stable/chap-css-properties.html
> > 
> > that there is a caret-color property. Is it possible to change the
> > thickness of the text caret?
> 
> Yes:
> https://developer.gnome.org/gtk3/stable/GtkWidget.html#GtkWidget--s-cursor-aspect-ratio,
> that is "-GtkWidget-cursor-aspect-ratio".
> 

I see - I did spot that cursor-aspect-ratio style item, but could not
guess that I had to prefix it with -GtkWidget-
So I have the following code which now works:

str =  "GtkTextView {-GtkWidget-cursor-aspect-ratio: 0.2;}";
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);


> > and, how exactly is caret-color supposed to be set I have:
> > 
> > str = "GtkTextView {caret-color: rgb(255,0,80);}";
> 
> Which GTK version do you use?  this property is new in 3.20, before that
> you had to use "-GtkWidget-cursor-color" instead.

ah, yes, that was the trouble, well that and not finding anything to
suggest that I needed to prefix the style property name with -GtkWidget-

thank you very much for this I'm now back on course.

Richard


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

Re: gtk_dialog_get_action_area() deprecation

[Richard Shann]

On Sat, 2016-12-31 at 20:11 +, Emmanuele Bassi wrote:
> consider using a small
> CSS fragment shipped with your own application, if you want to change
> the appearance of your UI, instead of hardcoding a space.
> 
> Especially now that the CSS system is documented and extremely
> powerful.

are you referring to

https://developer.gnome.org/gtk3/stable/chap-css-properties.html

here? This seems to be just some examples. Looking back through the
widget hierarchy I see sometimes "Style Properties" but this example
from such an entry (for GtkWidget)



GtkWidget:cursor-color has been deprecated since version 3.20 and should not be 
used in newly-written code.
Use the caret-color CSS property


indicates that these "Style Properties" are not the CSS properties that
can be altered for the widget concerned.

So where are they documented, on a widget by widget basis.

Richard Shann






___
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 get objecttype

[Richard Shann]

> On Fri, Sep 9, 2016 at 9:14 AM Thomas R?nshof <t...@kyborg.dk> wrote:
> 
> > Hi,
> >
> > We are converting some OLD COBOL applications to GTK.
> > The XML is created dynamically from SCREEN SECTIONS and we then use
> > gtk_builder to get the objects into the program.
> >
> > Is there a way to get the objecttype ?
> > If it's a gtk-combo we do this, if it's a gtk-entry we do that in the
> > program and so on...

In GNU-Denemo I use

 g_type_name (G_TYPE_FROM_INSTANCE (widget))

Richard Shann


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

Re: GTK menus on Ubuntu

[Richard Shann]

> Message: 1
> Date: Thu, 13 Oct 2016 09:49:53 -0400 (EDT)
> From: Allin Cottrell 
> To: Jason Benjamin 
> Cc: gtk-app-devel-list@gnome.org
> Subject: Re: GTK menus on Ubuntu
> Message-ID:
>   
> Content-Type: text/plain; charset=US-ASCII; format=flowed
> 
> On Tue, 11 Oct 2016, Jason Benjamin wrote:
> 
> > On Wed, 5 Oct 2016 21:11:41 -0400 (EDT)
> > Allin Cottrell  wrote:
> >
> >> I'm wondering if anyone knows the machanism whereby Ubuntu
> >> "commandeers" the main menu system of a GTK application and sticks
> >> it into the global top-of-screen menu bar, or combines it with the
> >> application-window title bar? I'm talking about a "traditional",
> >> non-CSD GTK application, where the "natural" location for the main
> >> menu system is at the top of the program's window but underneath the
> >> window's title bar as added by a WM.
> >
> > I am familiar with this "distribution", if you could link some
> > screenshots with details for the different operating systems that would
> > help. That could be difficult, but if you need to use VirtualBox or
> > something.  I may not be able to give you an answer with the little
> > time I have right now, but at least someone else may be able to with a
> > more comparable question.
> 
> Thanks, Jason. I think I now have a better handle on what's going on. 
> It seems that the code responsible for the effect I mentioned is
> unity-gtk-module, a "GTK+ module for exporting old-style menus as 
> GMenuModels". There's a mechanism for "blacklisting" applications so 
> they're not subject to this treatment, and there's also a relevant 
> environment variable, UBUNTU_MENUPROXY: I gather that if this is set 
> to 0 then unity-gtk-module doesn't kick in.
> 
> It seems to me that Ubuntu would have been better to adopt a 
> "whitelist" approach -- that is, apply this mechanism only to programs 
> that have been properly tested as working well under it. In the case 
> of my application the main menus are set up using the GtkUIManager and 
> GtkAction APIs, and the trouble (or one trouble) with unity-gtk-module 
> is that calls to gtk_action_set_sensitive() are not getting through to 
> the "hijacked" menus. It's hard to believe that my app is the only one 
> to get broken in this way.

Indeed not, GNU Denemo was distributed in broken form for some years by
Ubuntu, I don't know if it is fixed now...

Richard


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

gtk_key_snooper deprecation

[Richard Shann]

I see gtk_key_snooper is deprecated - it is currently in use to allow
the program to intercept key presses made on GtkMenuItems in my
application.
The suggestion is that the key press event should be intercepted by the
widget.
The key-press-event documentation says that the GdkWindow associated
with the widget has to have the GDK_KEY_PRESS_MASK enabled for the event
to be received.
But gtk_widget_get_window (menu_item) gives a NULL pointer.

All attempts to get 

g_signal_connect (G_OBJECT (menu_item), "key-press-event", 
G_CALLBACK(my_key_snooper), NULL);

to work are failing.

Can anyone suggest a way forward?

Richard Shann


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

pango_scan_string() deprecation

[Richard Shann]

I see that pango_scan_string() is deprecated since version 1.38
but the documentation doesn't indicate what it should be replaced with -
anyone got any ideas?

Richard Shann


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

Re: pango_scan_string() deprecation

[Richard Shann]

On Thu, 2017-01-05 at 17:02 +0100, infirit wrote:
> Op 01/05/2017 om 03:39 PM schreef Richard Shann:
> > I see that pango_scan_string() is deprecated since version 1.38
> > but the documentation doesn't indicate what it should be replaced with -
> > anyone got any ideas?
> 
> See [1] for the reasoning. Its now deprecated but from the looks of it
> there is no intention just yet to remove it.
> 
> And there is no replacement but its fairly simple and self contained so
> you could just copy [2] it and include it in your own code.

Thank you I've done that.
Richard
> 
> ~infirit
> 
> [1] https://bugzilla.gnome.org/show_bug.cgi?id=682840
> [2] https://git.gnome.org/browse/pango/tree/pango/pango-utils.c#n448
> 


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

Re: gtk_dialog_get_action_area() deprecation

[Richard Shann]

On Sat, 2016-12-31 at 10:05 +, Gergely Polonkai wrote:
> It would be helpful to see your exact use case. If you put only
> buttons in your GtkBox, you will be fine with gtk_dialog_add_button().
> If you add other, more complex widgets, there might be a design flaw
> in your application. Solutions in between might be OK, but without
> knowing what you want to achieve, it's hard to tell.

Thank you for you quick reply. I guess the answer to my question was
"no". 
There isn't the manpower to investigate the purpose of this bit of code
nor to start re-imagining the design 17 years in to this project,
unfortunately.

For now, I see that I can get at the action area via

action_area = gtk_widget_get_parent (cancelbutton); 

which will be ok unless the GtkDialog widget gets some new internal
implementation. Perhaps this will be useful to other developers hitting
this deprecation.

Richard

> 
> Best,
> Gergely
> 
> 
> On Sat, Dec 31, 2016, 10:39 Richard Shann <rich...@rshann.plus.com>
> wrote:
> 
> The documentation for gtk_dialog_get_action_area() suggests
> using
> gtk_dialog_add_button() etc. However, my application is
> storing a GtkBox
> in that area - is there a way to do this, going forward?
> 
> Richard
> 
> 
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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

gtk_dialog_get_action_area() deprecation

[Richard Shann]

The documentation for gtk_dialog_get_action_area() suggests using
gtk_dialog_add_button() etc. However, my application is storing a GtkBox
in that area - is there a way to do this, going forward?

Richard


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

Re: gtk_dialog_get_action_area() deprecation

[Richard Shann]

On Sat, 2016-12-31 at 20:10 +, Emmanuele Bassi wrote:
> Hi;
> 
> On 31 December 2016 at 16:03, Richard Shann <rich...@rshann.plus.com> wrote:
> > On Sat, 2016-12-31 at 15:44 +, Emmanuele Bassi wrote:
> >> Hi;
> >>
> >>
> >> Deprecations will only impact you if you want to update the code base
> >> to the next major API bump.
> >
> > Yes, it is to be ready for GTK4 that I am working on these.
> >
> >>  Since you don't have or want to commit resources to do so,
> >
> > I am committing my meagre resources to this.
> 
> I'm sorry to say this, but then you'll likely need more than just
> replacing deprecated API. In some cases we do expect changes in how
> applications are designed, if they want to keep up with new
> environments and human interface guidelines.

I haven't thought of trying to do either of those - I'm happy if people
with a computer with keyboard, mouse and one (preferably two) large
screens can use the program - I'm not sure if touch screens, virtual
keyboards etc would be feasible for this sort of work.

> 
> That's also why we generally expect mature, low-maintenance
> applications, to bundle a copy of GTK+ if they rely on a specific API.
> On Linux, you can look at using Flatpak to build and distribute your
> application.

Thanks for this pointer - I'm not sure how we create binaries for
GNU/Linux at the moment, but I'll flag this up as a possibility.

> 
> > I have just got to this
> > one:
> >
> > gtk_widget_reparent() is deprecated.
> >
> > Following the suggestion it seems this can be avoided with this:
> >
> > #define gtk_widget_reparent(w,p) 
> > (g_object_ref(G_OBJECT(w)),gtk_container_remove(GTK_CONTAINER(gtk_widget_get_parent(w)),
> >  w),gtk_container_add(GTK_CONTAINER(p), w),g_object_unref(G_OBJECT(w)))
> 
> More or less, yes.
> 
> The reparent() call was a call needed to avoid costly
> mapping/unmapping of real X11 resources, back in the day; once we
> stopped using real windowing system resources for each widget,
> reparent() relied on side effects and widget authors always doing the
> right thing, which exposed a bunch of bugs every time somebody wrote a
> new widget. So the idea is to always remove and add a widget, instead
> of reparenting it. This way, all code paths get consolidated.
> 
> > I think it would make developers of applications feel happier if some
> > indication was given as to why something was deprecated so as to guide
> > them in re-working the code.
> 
> Please, feel free to file bugs when a deprecation does not have a
> suggestion. We usually try to be explicit, but sometimes it's either
> complicated or we simply forget.
> 
> > (I'm assuming there's some reason that this
> > macro is not simply put into a header).
> 
> Because macros are not bindable anyway, so we generally don't use them
> as API. The only exceptions are the type system macros, but we are
> kind of replacing them with inlined functions, and those are
> implemented by other means in language bindings anyway.
> 
> We also do not provide a "compatibility layer" because now we'd have
> to deal with the bugs in two separate layers, and the bad interactions
> with applications and toolkit.

Ah, a macro wouldn't be a good thing, I see. Though I'm still not so
clear why the implementation of the function was not just simplified to
the above code when the fancier stuff had become unnecessary. No need to
invoke the deprecation machinery. Perhaps it's in the interest of a
shorter, "cleaner" API, or is there some (conceivable) type of GtkWidget
for which the above code would not work?

Richard


___
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 change GTK+3 label color dynamically

[Richard Shann]

From: R?ben Rodrigues <ruben...@live.com.pt>

> On 16-03-2017 11:20, Tilo Villwock wrote:
> > Am Donnerstag, den 16.03.2017, 09:55 + schrieb R?ben Rodrigues:
> >> Hi,
> >>
> >> THanks. This is dynamically? I need in c language if possible :S
> > Dynamic version:
> >
> > ...
> >
> > static GtkCssProvider* provider = NULL;
> >
> > static void
> > set_label_color(GtkWidget* label, const char* color)
> > {
> >  const char* format = "label { color: %s; }";
> >  size_t length = strlen(format) - 2 + 1;
> >  char style[length];
> >  sprintf(style, format, color);
> >
> >  if (provider == NULL) {
> >  /* only create and add the provider the first time */
> >  provider = gtk_css_provider_new();
> >  gtk_style_context_add_provider(
> >  gtk_widget_get_style_context(label),
> >  GTK_STYLE_PROVIDER(provider),
> >  GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
> >  g_object_unref(provider);
> >  }
> >
> >  gtk_css_provider_load_from_data(provider, style, -1, NULL);
> > }
> >
> > ...
> >
> > This might not be ideal in all situations. Just make sure you don't
> > create a new provider everytime you set a new color. Hope that helps.
> >
> > --Tilo
> 

> Hi,
> 
> This is what i have, and don't works...
> 

I have this function (for any widget type):

void set_background_color(GtkWidget *w, gchar *color)
{
GtkCssProvider *gcp;
GtkStyleContext *gsc;
gsc = gtk_widget_get_style_context(w);
const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w));
gchar *str = g_strdup_printf ("%s {background-color: %s;}", type,
color);
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
g_free (str);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}

I don't know if there is a memory leak here though...

HTH

Richard Shann

___
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-devel-list Digest, Vol 156, Issue 16

[Richard Shann]

> Date: Fri, 21 Apr 2017 09:01:54 +
> From: R?ben Rodrigues <ruben...@live.com.pt>
> To: "gtk-app-devel-list@gnome.org" <gtk-app-devel-list@gnome.org>
> Subject: CheckButton background color
> Message-ID:
>   
> <am5pr0801mb1891bafc8348eed3cffab1e7ad...@am5pr0801mb1891.eurprd08.prod.outlook.com>
>   
> Content-Type: text/plain; charset="utf-8"
> 
> Hi,
> 
> Someone knows how to change gtkcheckbutton background and size in CSS?

The GNU Denemo program uses this function that changes the background
color of a widget:

void set_background_color(GtkWidget *w, gchar *color)
{
GtkCssProvider *gcp;
GtkStyleContext *gsc;
gsc = gtk_widget_get_style_context(w);
const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w));
gchar *str = g_strdup_printf ("%s {background-color: %s;}", type,
color);
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
g_free (str);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}


HTH

Richard Shann

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

Trouble setting the value of a GtkAdjustment

[Richard Shann]

Compiling with Gtk 3.14.5
I can't seem to set the "value" of a GtkAdjustment once I have added a widget 
to it with gtk_container_add(), it seems to be locked at 0.0

The code looks like this fragment:

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

 GtkAdjustment *ADJ = gtk_adjustment_new (1.5, 0.0, 2.0, 0.01, 0.01, 0.01); 
   
 GtkWidget *sw = gtk_scrolled_window_new (ADJ , gtk_adjustment_new (1.5, 0.0, 
2.0, 0.01, 0.01, 0.01));
 gtk_container_add (GTK_CONTAINER(keyboard_window), sw);
 gtk_container_add (GTK_CONTAINER(sw), keyboard);
 
 gtk_adjustment_set_value (ADJ, 1.2); 

 g_print ("value %p is %f\n", ADJ, gtk_adjustment_get_value (ADJ));

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

where keyboard_window is a toplevel GtkWindow, and keyboard is a GtkGrid.

The value printed out is always 0.0 after the widget is added to the scrolled 
window.

Can anyone help? I'm trying to center the scroll-bars on the window.

Richard Shann


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

Re: Trouble setting the value of a GtkAdjustment

[Richard Shann]

On Mon, 2017-04-24 at 14:48 -0400, cecas...@aol.com wrote:
> 
> Hi Richard,
> 
> It looks like how you add containers makes a difference in this case.
> Also the window placement might have to be adjusted after the window
> is shown. Here is a try at it.

Thank you very much - it seems you are right, by moving the
gtk_container_add() calls until just before the gtk_show_all() the
GtkAdjustment widget becomes controllable. The values it has are no
longer what were set when it was created however, so I set it with this
code after the gtk_show_all() call:

gdouble lower, upper, page;
lower = gtk_adjustment_get_lower (hadj);
upper = gtk_adjustment_get_upper (hadj);
page = gtk_adjustment_get_page_size (hadj);
//g_print ("Lower ... %f %f %f\n", lower, upper, page);
gtk_adjustment_set_value (hadj, (upper-page - lower)/2);

which gets the horizontal slider in the middle.

The values when printed out are:

Lower ... 0.00 1901.00 800.00

where those values come from is a mystery. And, I suppose the way it
changes depending on the order of placing the widgets inside each other
will have to remain a mystery too.

Thanks once again,

Richard


> 
> Eric
> 
> 
> //gcc -Wall adj1.c -o adj1 `pkg-config --cflags --libs gtk+-3.0`
> //Tested on Ubuntu16.04 and GTK3.18
> 
> #include
> 
> int main(int argc, char **argv)
>  {
>gtk_init(, );
> 
>GtkWidget *keyboard_window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
>gtk_window_set_title(GTK_WINDOW(keyboard_window), "Keyboard
> Window");
>gtk_window_set_default_size(GTK_WINDOW(keyboard_window), 200, 200);
>gtk_window_set_position(GTK_WINDOW(keyboard_window),
> GTK_WIN_POS_CENTER);
>g_signal_connect(keyboard_window, "destroy",
> G_CALLBACK(gtk_main_quit), NULL);
> 
>GtkWidget *label=gtk_label_new("Label");
>gtk_widget_set_size_request(label, 400, 400);
> 
>//GtkAdjustment *ADJ = gtk_adjustment_new (1.5, 0.0, 2.0, 0.01,
> 0.01, 0.01);
>//GtkWidget *sw = gtk_scrolled_window_new (ADJ , gtk_adjustment_new
> (1.5, 0.0, 2.0, 0.01, 0.01, 0.01));
>GtkAdjustment *ADJ = gtk_adjustment_new (100.0, 0.0, 400.0, 0.0,
> 0.0, 0.0);
>GtkWidget *sw = gtk_scrolled_window_new (ADJ , ADJ);
> 
>//gtk_adjustment_set_value (ADJ, 1.2);
>g_print ("value %p is %f\n", ADJ, gtk_adjustment_get_value (ADJ));
> 
>GtkWidget *keyboard=gtk_grid_new();
>gtk_grid_attach(GTK_GRID(keyboard), label, 0, 0, 1, 1);
>gtk_container_add(GTK_CONTAINER(sw), keyboard);  
>gtk_container_add(GTK_CONTAINER(keyboard_window), sw);
> 
>//gtk_container_add(GTK_CONTAINER(keyboard_window), sw);
>//GtkWidget *keyboard=gtk_grid_new();
>//gtk_grid_attach(GTK_GRID(keyboard), label, 0, 0, 1, 1);  
>//gtk_container_add(GTK_CONTAINER(sw), keyboard);
> 
>gtk_widget_show_all(keyboard_window);
> 
>gtk_adjustment_set_value (ADJ, 100.0);
> 
>gtk_main();
> 
>return 0;  
>  }
> 
> 


___
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 find CSS style syntax changes between Gtk 3.12 and Gtk 3.22

[Richard Shann]

On Wed, 2017-05-10 at 18:34 +0100, Emmanuele Bassi wrote:
> On 2017-05-08 at 13:57, Richard Shann wrote:
> > On Mon, 2017-05-08 at 12:28 +0100, Emmanuele Bassi wrote:
> 
> > > > But I will have to wait for
> > > > Debian to catch up with Gtk 3.20 before I can seriously look at this.
> > > 
> > > And this is why I suggest you use a CSS class, instead;
> > 
> > Is that something different from the GtkWidgetClass that the widget has?
> 
> CSS classes are not related to widget classes.
> 
> https://developer.mozilla.org/en-US/docs/Web/CSS/Class_selectors
> 
> > Are there a gtk_css_class_new() and a gtk_widget_assign_css_class()
> > functions to use them?
> 
> You want `GtkStyleContext` and `gtk_style_context_add_class()`:
> 
> https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-get-style-context
> https://developer.gnome.org/gtk3/stable/GtkStyleContext.html#gtk-style-context-add-class
> 
> > I'm completely at sea.
> 
> You probably want to read the API reference, then:
> 
> https://developer.gnome.org/gtk3/stable/theming.html

Thank you for the references. I had seen that stuff but was lost right
at the start, it would seem that a background in HTML would be helpful,
and

> 
> Additionally, you may want to read online resources about CSS.

some notion about what CSS is. So I will have a lot of reading to do. 

But, meanwhile, I see that the code I posted (which I didn't originate,
just cooked up from someone else's earlier posting) did use
`GtkStyleContext` though not 'gtk_style_context_add_class()' but rather
'gtk_style_context_add_provider()' so perhaps it is ok code, if the
lookup of the css selector were more robust.
I append a copy, in case anyone cares to point out deficiencies.

Richard Shann

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
void set_background_color(GtkWidget *w, gchar *color)
{
GtkCssProvider *gcp;
GtkStyleContext *gsc;
gsc = gtk_widget_get_style_context(w);
gchar *type = get_css_selector(w);
gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); 
//g_print ("%s", str);
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
g_free (str);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><



___
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 find CSS style syntax changes between Gtk 3.12 and Gtk 3.22

[Richard Shann]

On Sun, 2017-05-07 at 17:54 +0100, Emmanuele Bassi wrote:
> On 7 May 2017 at 16:52, Richard Shann <rich...@rshann.plus.com> wrote:
> > I have a test program that pops up a label with a customized
> background
> > and foreground color. This works in 3.12 using the syntax
> >
> > "GtkLabel {background-color: #00;}"
> >
> > and
> >
> > "GtkLabel {color: #FF00FF;}"
> >
> > but fails in 3.22
> 
> The selector for labels is "label" since GTK+ 3.20.

Thank you very much for this. Is there a function to get the selector
for a widget? Sort of gchar *gtk_widget_get_css_selector (GtkWidget *w)
thing? Looking through a few widgets it seems the rule is chop off the
Gtk prefix and lower case what remains ... is that guaranteed?

Richard


___
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 find CSS style syntax changes between Gtk 3.12 and Gtk 3.22

[Richard Shann]

On Sun, 2017-05-07 at 19:52 +, Emmanuele Bassi wrote:
> 
> On Sun, 7 May 2017 at 19:53, Richard Shann <rich...@rshann.plus.com>
> wrote:
> 
> On Sun, 2017-05-07 at 17:54 +0100, Emmanuele Bassi wrote:
> > On 7 May 2017 at 16:52, Richard Shann
> <rich...@rshann.plus.com> wrote:
> > > I have a test program that pops up a label with a
> customized
> > background
> > > and foreground color. This works in 3.12 using the syntax
> > >
> > > "GtkLabel {background-color: #00;}"
> > >
> > > and
> > >
> > > "GtkLabel {color: #FF00FF;}"
> > >
> > > but fails in 3.22
> >
> > The selector for labels is "label" since GTK+ 3.20.
> 
> Thank you very much for this. Is there a function to get the
> selector
> for a widget? Sort of gchar *gtk_widget_get_css_selector
> (GtkWidget *w)
> thing? 
> 
> 
> I'm not sure what would that accomplish. Could you elaborate?

It would enable my program to work. Currently it gets the string
"GtkLabel" from the type name of the widget, and that works for setting
the background color of various widgets in the program, replacing
deprecated calls.
> 
> 
> Looking through a few widgets it seems the rule is chop off
> the
> Gtk prefix and lower case what remains ... is that guaranteed?
> 
> 
> No, it's not. It's part of the API reference for a reason.
> 
> If somebody creates a custom widget, with a custom CSS element name,
> then they will have to document it.
> 
yes, but surely there is no harm in you documenting what you do with the
widgets that come with Gtk in order to create a selector name? Otherwise
a) we have to look it up each time
b) we can't create it programmatically for programs like the one I
posted.

Richard

> 


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

How to find CSS style syntax changes between Gtk 3.12 and Gtk 3.22

[Richard Shann]

I have a test program that pops up a label with a customized background
and foreground color. This works in 3.12 using the syntax 

"GtkLabel {background-color: #00;}"

and

"GtkLabel {color: #FF00FF;}"

but fails in 3.22

How can I track changes needed to CSS syntax from one version to another
in the documentation (mostly I struggle to find the correct syntax :( )

Any help appreciated: test code follows.

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
//gcc -Wall TestStyleChange.c -o TestStyleChange `pkg-config --cflags --libs 
gtk+-3.0`

#include
void set_background_color(GtkWidget *w, gchar *color)
{
GtkCssProvider *gcp;
GtkStyleContext *gsc;
gsc = gtk_widget_get_style_context(w);
const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w));
gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); 
g_print("%s", str);
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
g_free (str);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}

void set_foreground_color(GtkWidget *w, gchar *color)
{
GtkCssProvider *gcp;
GtkStyleContext *gsc;
gsc = gtk_widget_get_style_context(w);
const gchar *type = g_type_name (G_TYPE_FROM_INSTANCE (w));
gchar *str = g_strdup_printf ("%s {color: %s;}", type, color); g_print("%s", 
str);
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
g_free (str);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}

int main(int argc, char **argv)
 {
   gtk_init(, );

   GtkWidget *top_window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
   g_signal_connect (top_window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
   
   GtkWidget *eventbox = gtk_event_box_new ();
   GtkWidget *label=gtk_label_new("Label");
   
   set_background_color (label, "#00");
   set_foreground_color (label, "#FF00FF");
  
   gtk_widget_set_size_request(label, 400, 400);
   gtk_container_add (GTK_CONTAINER (eventbox), label);
   gtk_container_add (GTK_CONTAINER(top_window), eventbox);
   gtk_widget_show_all (top_window);

   gtk_main();

   return 0;  
 }


8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

Richard Shann

___
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 find CSS style syntax changes between Gtk 3.12 and Gtk 3.22

[Richard Shann]

On Mon, 2017-05-08 at 08:42 +0100, Emmanuele Bassi wrote:
> On 7 May 2017 at 20:57, Richard Shann <rich...@rshann.plus.com> wrote:
> > On Sun, 2017-05-07 at 19:52 +, Emmanuele Bassi wrote:
> >>
> >> On Sun, 7 May 2017 at 19:53, Richard Shann <rich...@rshann.plus.com>
> >> wrote:
> >>
> >> On Sun, 2017-05-07 at 17:54 +0100, Emmanuele Bassi wrote:
> >> > On 7 May 2017 at 16:52, Richard Shann
> >> <rich...@rshann.plus.com> wrote:
> >> > > I have a test program that pops up a label with a
> >> customized
> >> > background
> >> > > and foreground color. This works in 3.12 using the syntax
> >> > >
> >> > > "GtkLabel {background-color: #00;}"
> >> > >
> >> > > and
> >> > >
> >> > > "GtkLabel {color: #FF00FF;}"
> >> > >
> >> > > but fails in 3.22
> >> >
> >> > The selector for labels is "label" since GTK+ 3.20.
> >>
> >> Thank you very much for this. Is there a function to get the
> >> selector
> >> for a widget? Sort of gchar *gtk_widget_get_css_selector
> >> (GtkWidget *w)
> >> thing?
> >>
> >>
> >> I'm not sure what would that accomplish. Could you elaborate?
> >
> > It would enable my program to work. Currently it gets the string
> > "GtkLabel" from the type name of the widget, and that works for setting
> > the background color of various widgets in the program, replacing
> > deprecated calls.
> 
> I'm still puzzled as to why you need programmatic access to the CSS
> element name.
> 
> Are you generating CSS fragments from a generic function with only the
> widget type as the input?

yes

> 
> You can use `gtk_widget_class_get_css_name()`:
> 
>   
> https://developer.gnome.org/gtk3/stable/GtkWidget.html#gtk-widget-class-get-css-name
> 

thanks for alerting me to this. My development system is Debian Stable,
so I don't have access to this function as it is from 3.20, however it
gave me a starting point for looking at what will be possible.

> But I'd strongly recommend you use CSS classes instead of styling the
> bare element name.
> 
> CSS selectors in GTK+ work exactly like the HTML counterpart; you can
> style "div" or "p" directly, but it's often much more appropriate to
> create a specific CSS class, like "green-background", and add it to
> the widget you wish to style.

I didn't find anything describing creating a GtkWidgetClass in the
gtk3/stable documentation, it seems that there is a field in the
GtkWidget structure pointing to such a structure accessed via

GTK_WIDGET_GET_CLASS (widget)

so I imagine that using

gtk_widget_class_set_css_name (class, name)

could mean you would get control over the style of that widget and any
others whose class you assigned that name. But I will have to wait for
Debian to catch up with Gtk 3.20 before I can seriously look at this.

Thanks again for your responses.

Richard Shann


___
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 find CSS style syntax changes between Gtk 3.12 and Gtk 3.22

[Richard Shann]

On Mon, 2017-05-08 at 12:28 +0100, Emmanuele Bassi wrote:
> On 8 May 2017 at 12:04, Richard Shann <rich...@rshann.plus.com> wrote:
> 
> >> But I'd strongly recommend you use CSS classes instead of styling the
> >> bare element name.
> >>
> >> CSS selectors in GTK+ work exactly like the HTML counterpart; you can
> >> style "div" or "p" directly, but it's often much more appropriate to
> >> create a specific CSS class, like "green-background", and add it to
> >> the widget you wish to style.
> >
> > I didn't find anything describing creating a GtkWidgetClass in the
> > gtk3/stable documentation, it seems that there is a field in the
> > GtkWidget structure pointing to such a structure accessed via
> >
> > GTK_WIDGET_GET_CLASS (widget)
> 
> Yes, this is part of basic GObject usage: each instance has a pointer
> to its instantiating class structure.
> 
> > so I imagine that using
> >
> > gtk_widget_class_set_css_name (class, name)
> >
> > could mean you would get control over the style of that widget and any
> > others whose class you assigned that name.
> 
> You don't have *control* over the style. You can *add* to the existing
> style — which may include undoing what the existing style does, but
> then you need to know what the style does, or essentially reset CSS
> properties by using their initial state, see:
> https://drafts.csswg.org/css-cascade-3/#initial
> 
> This is how CSS works. The only way for you to control the style of a
> GTK+ application

I haven't thought about trying to control the style of my application,
just do things like creating a label with a certain background color.


>  is to ship your own theme, and load it in place of
> the user theme.
> 
> CSS is a *very* powerful set of rules for rendering content using a
> declarative syntax; it's *really* not a bunch of color definitions,
> like the style system in GTK+ 2.x. You will need to learn how CSS
> works in order to use it.
> 
> > But I will have to wait for
> > Debian to catch up with Gtk 3.20 before I can seriously look at this.
> 
> And this is why I suggest you use a CSS class, instead;

Is that something different from the GtkWidgetClass that the widget has?
Are there a gtk_css_class_new() and a gtk_widget_assign_css_class()
functions to use them?
I'm completely at sea. Meanwhile for anyone with an application that has
to compile with versions of Gtk+ before and after version 3.20 here is
the code that is currently working for me to set the background color of
a widget:

8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><
static gchar *get_css_selector (GtkWidget *w)
{
static gchar *ret = NULL;

#if ((GTK_MAJOR_VERSION==3) && (GTK_MINOR_VERSION>=20))
  g_free (ret);
  ret = g_ascii_strdown (g_strdup (g_type_name (G_TYPE_FROM_INSTANCE (w))), -1);
  return ret+3;
#else
   ret = (gchar *)g_type_name (G_TYPE_FROM_INSTANCE (w));
   return ret;
#endif
}

void set_background_color(GtkWidget *w, gchar *color)
{
GtkCssProvider *gcp;
GtkStyleContext *gsc;
gsc = gtk_widget_get_style_context(w);
gchar *type = get_css_selector(w);
gchar *str = g_strdup_printf ("%s {background-color: %s;}", type, color); 
//g_print ("%s", str);
gcp= gtk_css_provider_new();
gtk_css_provider_load_from_data(gcp, str, -1, 0);
g_free (str);
gtk_style_context_add_provider(gsc, GTK_STYLE_PROVIDER(gcp), 
GTK_STYLE_PROVIDER_PRIORITY_APPLICATION);
}
8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><8><

Thank you for your patience,

Richard Shann



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

g_log_set_fatal_mask() not working for me.

[Richard Shann]

I am getting a warning message:

 Gtk-WARNING **: Allocating size to GtkScrollbar 0x5647efd0 without
calling gtk_widget_get_preferred_width/height(). How does the code know
the size to allocate?

however when I call 

call g_log_set_fatal_mask ("Gtk", 1<<4)

at the start of main the warning is not converted into a fatal error.
I've tried

call g_log_set_fatal_mask ("Gtk", 0x)

as well, to no avail.

This is with Gtk version runtime: 3.22.11, compiled against: 3.22.11

Any suggestions to track down the source of the trouble gratefully
received...

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

Re: g_log_set_fatal_mask() not working for me.

[Richard Shann]

On Sun, 2017-12-17 at 17:54 -0500, cecas...@aol.com wrote:
> 
> Hi Richard,
> 
> This sounds similar to the problem Dino Aljević had in "Scrolled
> TreeView and size allocation warnings" in this list in September?
> 
> I can get the warning
> 
> "(treeview4:3830): Gtk-WARNING **: Allocating size to GtkWindow
> 0x843e188 without calling gtk_widget_get_preferred_width/height().
> How does the code know the size to allocate?"
> 
> with the following code with GTK3.22.26 but I don't see the warning
> in GTK3.18.9. To get the warning expand the treeview until the list
> extends past the window boundry. I looked on Bugzilla but I didn't
> see it listed there. I am not great at finding things on Bugzilla so
> that doesn't mean it isn't there.
> 
> Do you have some test code to produce the GtkScrollbar warning you
> are seeing?

No, indeed, the warnings are appearing during the start up of a very
large program and I'm trying to locate the part of the program they are
coming from ...

> 
> For the g_log_set_fatal_mask() and a runtime
> stop, try starting your code with 
> 
> G_DEBUG=fatal-warnings
> 
That's good to know, but it is rather a blunt instrument, calling
g_log_set_fatal_mask() from the debugger normally lets you pin down
particular warnings. Bizarrely, at present gdb has suddenly got amnesia
and declares
(gdb) call g_log_set_fatal_mask ("Gtk", 0x)
No symbol "g_log_set_fatal_mask" in current context.
Where previously it was returning the previous mask as it should.

> It is a warning though. Something needs to be fixed but your program
> should run fine.

Yes, it doesn't seem to cause a problem, but there is worse to come - I
have had a couple of crashes coming from Gtk since upgrading to Debian
Stable (hence Gtk 3.22) and I can get this:

Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion 'size >= 0'
failed in GtkScrollbar

during a gtk_widget_show_all () of a widget that has previously been
working. At least I know where this one is happening...

Thanks for you helpful reply,

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

How to get a directory from the user

[Richard Shann]

Hi,

I have seen GtkFileChooser for getting a file from the user, but how to
get a directory (folder)?

Richard Shann

___
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 get a directory from the user

[Richard Shann]

On Mon, 2018-06-04 at 13:24 +0100, Emmanuele Bassi wrote:
> 
> 
> On 4 June 2018 at 13:06, Richard Shann 
> wrote:
> > Hi,
> > 
> > I have seen GtkFileChooser for getting a file from the user, but
> > how to
> > get a directory (folder)?
> > 
> 
> You can use GtkFileChooser with GTK_FILE_CHOOSER_ACTION_SELECT_FOLDER
> as the action:

Thank you!

Richard

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

g_log_set_fatal_mask () does not appear to be present

[Richard Shann]

I used to call 
g_log_set_fatal_mask ()

via gdb to catch the place where critical errors happen. But now I get

(gdb) call g_log_set_fatal_mask ("Gtk", 0x)
No symbol "g_log_set_fatal_mask" in current context.


any ideas?

Richard Shann


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

Re: g_log_set_fatal_mask () does not appear to be present

[Richard Shann]

> Date: Sun, 09 Sep 2018 20:21:54 +0100
> From: Richard Shann 
> To: gtk-app-devel-list@gnome.org
> Subject: g_log_set_fatal_mask () does not appear to be present
> Message-ID: <1536520914.1394.1.ca...@rshann.plus.com>
> Content-Type: text/plain; charset="UTF-8"
> 
> I used to call 
> g_log_set_fatal_mask ()
> 
> via gdb to catch the place where critical errors happen. But now I
> get
> 
> (gdb) call g_log_set_fatal_mask ("Gtk", 0x)
> No symbol "g_log_set_fatal_mask" in current context.

I've been trying to dig deeper into this (guessing that
g_log_set_fatal_mask may have become a macro or something) and find
that I can call it after gtk_init_check() from within the program
without a compile time error, but the program still does not stop on
errors.

Indeed

g_print ("Error level was %x\n", g_log_set_fatal_mask (NULL, -1));
g_print ("Error level now %x\n", g_log_set_fatal_mask (NULL, -1));

prints out 0x5 as the initial setting of the mask and 0xfffd
 as the setting after setting to -1

but I then can trigger a slew of 

(denemo:1717): Gtk-CRITICAL **: gtk_box_gadget_distribute: assertion
'size >= 0' failed in GtkScrollbar

errors without the program stopping.

Is there something involving threads here?

Richard Shann

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

GdkKeymap default for Display problem

[Richard Shann]

Using Gtk 3.22.11 under Debian stable I get a different keymap than the
one the application was launched with on calling 

gdk_keymap_get_for_display(gdk_display_get_default ())

This shows up when there are two keymaps available and I select the
alternative one for a terminal, launch the application and then use 

gdk_keymap_translate_keyboard_state ()

what happens is that it is *not* translated using the keymap that was
used to launch the application (and which shows up in GtkEntry etc
widgets). Instead it is translated using the "default" keymap for the
Desktop.
This lead me to look at the documentation and I see that there is
nothing to suggest you can access the GdkKeymap that the GtkWidgets are
using - indeed there is nothing to suggest you can create a GdkKeymap
other than getting this "default for display" keymap.

Is there something I've missed here?

Richard Shann

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

Re: GdkKeymap default for Display problem

[Richard Shann]

Following this up:

> Using Gtk 3.22.11 under Debian stable I get a different keymap than
> the
> one the application was launched with on calling 
> 
> gdk_keymap_get_for_display(gdk_display_get_default ())
> 
> This shows up when there are two keymaps available and I select the
> alternative one for a terminal, launch the application and then use 
> 
> gdk_keymap_translate_keyboard_state ()
> 
> what happens is that it is *not* translated using the keymap that was
> used to launch the application (and which shows up in GtkEntry etc
> widgets). Instead it is translated using the "default" keymap for the
> Desktop.
> This lead me to look at the documentation and I see that there is
> nothing to suggest you can access the GdkKeymap that the GtkWidgets
> are
> using - indeed there is nothing to suggest you can create a GdkKeymap
> other than getting this "default for display" keymap.
> 
> Is there something I've missed here?
> 
> Richard Shann

I've created a minimal example of the problem:

//gcc -Wall KeyMap-test.c -o KeyMapTest `pkg-config --cflags --libs gtk+-3.0`
//Tested on debian stable and GTK3.22.18

#include
static void callback (GtkWidget * widget, GdkEventKey * event)
{
   guint keyval;
   g_print ("key press event: keyval %d (%s)\n", event->keyval, 
gdk_keyval_name(event->keyval));
   gdk_keymap_translate_keyboard_state (gdk_keymap_get_default (), 
event->hardware_keycode,0,0, , NULL, NULL, NULL); 
   g_print ("After keymap translate keyval %d (%s)\n", keyval, 
gdk_keyval_name(keyval));
}
int main(int argc, char **argv)
 {
   gtk_init(, );

   GtkWidget *top_window=gtk_window_new(GTK_WINDOW_TOPLEVEL);
   g_signal_connect (top_window, "destroy", G_CALLBACK(gtk_main_quit), NULL);
   g_signal_connect (G_OBJECT(top_window), "key-press-event", G_CALLBACK 
(callback), NULL);
   gtk_widget_show_all (top_window);

   gtk_main();

   return 0;  
 }

The output on setting a US keyboard in the terminal with a UK keyboard
as the desktop default and pressing the key code 51

rshann@debian:~$ ./KeyMapTest 
key press event: keyval 92 (backslash)
After keymap translate keyval 35 (numbersign)

The US key map is used for the GtkWindow widget to provide the keyval
92 but then the UK keymap is used for the call to
gdk_keymap_translate_keyboard_state() giving the keyval 35

Is this a bug in Gtk 3.22?

Richard




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