Re: gtk_events_pending() is pending!!

[Richard Boaz]

but you haven't entered the main loop yet.  how can you process the events
off a queue that isn't being processed?

i don't think you should call this before you've entered the main loop; it
strikes me that a hang is exactly what you should expect.

and, you should use this call as little as possible.  most of the time,
requiring this to be called is more a reflection of improper design than
actual necessity.

richard

> Hi all:
> I'am trying to add the
> 1742 while(gtk_events_pending())
> 1743 {
> 1744 gtk_main_iteration();
> 1745 }
> 1746 }
>into my gtk project to make my program runs smoothly.
> but, once I add the above code in my main function. The while loop always
> busy and block all of the widgets.
> for example, I add the pending check code before the end of the main...
> 304
> 305   while (gtk_events_pending()) gtk_main_iteration();
> 306   gdk_threads_enter();
>
> 307   GUI_data_mutex = g_mutex_new ();
> 308   GUI_data_cond  = g_cond_new ();
> 309   waiting_share(key);
> 310   gtk_main ();
> 311   gdk_threads_leave();
> 312
> 313
> 314   return 0;
> 315
> 316 }
>
> It looks like some events are pending. How could I do? and How should I
> know
> which event is pending?
>
> Thanks!!!
>
> Dave.
>
>
>
> --
> System  on Chip Design  Lab.
> Dept. of Computer Science and Information Engineering,
> National Chung Cheng University
> E-mail : [EMAIL PROTECTED]
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: (severe) performance issues

[Richard Boaz]

In terms of adding functionality to the widget itself to handle this  
very contentious situation, whynot something like:

1) add an attribute to the widget named, say,  
GTK_LABEL_NO_SIZE_REDUCTION (or whatever)
2) with this attribute set, the label will only resize if the new  
label results in a size larger than the currently known maximum,  
i.e., the maximum size of all previously set labels for any given  
invocation of the program.

It would seem to me this would be fairly straightforward to  
implement, only need to save the current max size and test against it  
when the label is re-set.

Not sure, but I would bet this would solve the original poster's  
problem (while the required change to the widget would, as well, not  
be so onerous?).

richard

On Mar 30, 2007, at 1:34 PM, [EMAIL PROTECTED] wrote:

> On 3/30/07, Paul Davis <[EMAIL PROTECTED]> wrote:
>> So I've spent about 15 minutes going through software on this  
>> computer
>> looking through different windows trying to find an example of a  
>> label
>> that changes to convey some interesting piece of information. I can't
>> find any.
>
> I don't know if this is what you mean, but I have an example in my
> image processing application.
>
> Image windows have an optional status bar which shows width, height,
> etc. and also current mouse position in x/y image coordinates, and the
> value of the pixel under the mouse.
>
>   http://cima.ng-london.org.uk/~john/statusbar.png
>
> The labels showing x/y/value have to be fixed in size so they don't
> jiggle left-right as you move the mouse around. I do this by calling
> gtk_widget_set_size_request() on them after measuring the size of the
> largest value I can show in the right font.
>
> It seems that calling gtk_widget_set_size_request() on a label locks
> the size, but doesn't stop the label from triggering a resize when the
> label's content next changes.
>
> Maybe this is somthing that could be changed without breaking  
> anything?
>
> John
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: How do you develop you GTK code?

[Richard Boaz]

Hi,

Like the others posting so far, I do not use any IDE to program my gtk 
+ app.  I had a quick look once upon a time, but quickly determined  
that if you want or require to change the code that is automatically  
generated, you might as well just write your own instead of trying to  
get in the deep-end of someone else's ideas about how this should be  
done.


This subject came up a little while ago as well.  Then, the poster  
found that writing your own code was a big pain since this required  
coming up with a variable name for every widget needing to be  
created.  But I didn't and still don't understand this complaint.   
When creating widgets, two types of widgets are required, one which  
never again needs to be accessed (e.g., a static label (don't even  
start talking about dynamic labels...:) ), and the other requiring  
accessing (e.g., an entry area taking input from the user).  For  
those widgets not needing to be accessed, it is not necessary to  
provide a unique variable name, rather, you can re-use the same  
variable over and over since once a widget is registered/packed/ 
whatever, you need not reference it again.


To illustrate, the following snippet generates two buttons and an  
entry area with a label laid out simply in a vertical container:


vbox = gtk_vbox_new(FALSE, 0);

button = gtk_button_new_with_label("TRACES");
	g_signal_connect((button), "clicked", G_CALLBACK(buttonCallback),  
&enums[TRACES]);

gtk_size_group_add_widget(size_group, button);
gtk_container_add(GTK_CONTAINER (vbox), button);
strcpy(toolTip, "Open Trace files");
gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip);

button = gtk_button_new_with_label("Next");
	g_signal_connect((button), "clicked", G_CALLBACK(nextTrace), &enums 
[NEXT]);

gtk_size_group_add_widget(size_group, button);
gtk_container_add(GTK_CONTAINER (vbox), button);
strcpy(toolTip, "Display NEXT Screen of Trace Files");
gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), button, toolTip, toolTip);

hbox = gtk_hbox_new(FALSE, 0);
label = gtk_label_new("min:");
MTfixed[MIN] = entry = gtk_entry_new();
	g_signal_connect(MTfixed[MIN], "activate", G_CALLBACK(reMag), &OV 
[MAGNIFYSCR]);

gtk_entry_set_width_chars(GTK_ENTRY (entry, 5);
gtk_container_add(GTK_CONTAINER (hbox), label);
gtk_container_add(GTK_CONTAINER (hbox), entry);
gtk_container_add(GTK_CONTAINER (vbox), hbox);
	strcpy(toolTip, "MIN: define as absolute (e.g., 1000) or as  
Percentage of MAX/MIN Mean (e.g., 50%) (BLANK = Real MIN)");

gtk_tooltips_set_tip(GTK_TOOLTIPS (tips), entry, toolTip, toolTip);

As another poster pointed out, this repetitive type of widget  
creation can be contained within its own routine.  But basically,  
once you've got the various types of widgets and layouts you require,  
it is trivial to copy and paste the code over and over, only  
requiring the widget's creation details to be changed for each new  
instance.


The above snippet requires only that the entry area be uniquely named  
for later reference.  In my code, all widgets are globally defined as  
GtkWidget *, casting when- and wherever appropriate.  (Some purists  
might balk at global variables but I have no problem with globals  
which never change value over the entire life of a program,  
especially when they're widgets needed possibly anywhere.)  To handle  
the problem of having to name so many widgets nonetheless, adopt a  
simple and shorthand naming convention you can immediately recognize,  
deduce, and even guess which makes sense somehow to the program and  
their usage.  As well, arrays of widgets can be very helpful here.


And like another poster, I highly recommend attaching as few  
callbacks as possible to the widgets.  Like he does, as can be seen  
above, each button is attached to the same callback with an enum  
value passed to the callback routine.  Once called, case statements  
handle each button's differing requirements.  (Unlike how he does it,  
however, I do this more directly in the signal connection itself;  
either method works though depending on exact requirements, using  
g_object_*_data() may be more appropriate.)  In general, try to  
attach like widgets to the same callback.  In practice this won't be  
universal, some callbacks demand their own routine; the point is,  
maintaining code in the future is always made easier when the number  
of callbacks is minimized to the greatest extent possible.


And good luck,

richard___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Compile warning (newbie)

[Richard Boaz]

no need to declare *str, like this:

void edit_changed (GtkWidget *widget, gpointer *data)
{
 gchar *strcopy;

 strcopy = g_strdup(gtk_entry_get_text (GTK_ENTRY (widget)));

 g_print ("Entry changed to %s\n", strcopy);

 g_free(strcopy);
}



On Apr 17, 2007, at 8:09 AM, William D. Tallman wrote:

> On Mon, Apr 16, 2007 at 05:01:29PM -0600, Michael L Torrie wrote:
>> On Tue, 2007-04-17 at 08:22 +1000, Andrew Cowie wrote:
>>> Return type of gtk_entry_get_text() is (const gchar*), not just
>>> (gchar*). You discarded the const qualifier when assigning the  
>>> result to
>>> str.
>>>
>>> Just declare str with const.
>>
>> The reason why this is important is because gtk_entry_get_text is
>> returning you just a pointer to a buffer inside the widget.   
>> Therefore
>> you should never modify it.  If you do, you run the risk of  
>> crashing the
>> program.  That's why the return type is const and the compiler  
>> gives you
>> a warning.
>>
>> If you want to do something to the string you need to copy it with
>> g_strdup, remembering to free your copy when you are done.
>>
>> Michael
>
> Then it should be like this?
>
> void edit_changed (GtkWidget *widget, gpointer *data)
> {
> const gchar *str;
> gchar *strcopy;
>
> str = gtk_entry_get_text (GTK_ENTRY (widget));
>
> strcopy = g_strdup(str);
>
> g_print ("Entry changed to %s\n", strcopy);
>
> free(strcopy);
> }
>
> I'm no whiz with C itself and have never used strdup.  IIUC, the
> template is as above, replacing the g_print with whatever is to be  
> done
> with the copied string.  Is that correct?  If not, what don't I
> understand here?
>
> Thanks,
>
> Bill Tallman
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: Getting row numbers

[richard boaz]

maybe this will help?  the following callback will get the row number of the
row when double-clicked by the user.  basically, convert a GtkTreePath to a
string.  you must take proper care if you have a tree deeper than one level.

void recordActivate(GtkTreeView *treeview, GtkTreePath *arg1,
GtkTreeViewColumn *arg2, gpointer *hdrList)
{// called when record double-clicked
   char*row;
   introwNum;

   row = gtk_tree_path_to_string(arg1);
   rowNum = atoi(row);
   g_free(row);
}

richard

On 5/9/07, David Nečas (Yeti) <[EMAIL PROTECTED]> wrote:


On Wed, May 09, 2007 at 01:38:04PM -0400, tj wrote:
> >
> Ok, so how do I get the row number, from GtkTreePath,


http://developer.gnome.org/doc/API/2.0/gtk/GtkTreeModel.html#gtk-tree-path-get-indices

In general, the path is not a single number as it can
represent paths in trees too.  If you have a list, the path
consists of only one index though: the row number.

> from
> GtkTreeRowReference?

By converting it to GtkTreePath and continuing as above.

If you are not going to remove, move, ..., the selected
nodes, it is often easier to use gtk_tree_selection_selected_foreach().

> Where is it one of those. In fact, where are their
> struct defs? I look in /usr/include/gtk+-2.0 and All I find is thhe type
> def to it preceded by the '_'. But, no struct definition of
> _GtkTreeRowReference, etc.

Thou shalt not meddle with the internal representation.

Yeti

--
http://gwyddion.net/
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

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

Re: Getting row numbers

[richard boaz]

not sure...

On 5/10/07, David Nečas (Yeti) <[EMAIL PROTECTED]> wrote:


On Thu, May 10, 2007 at 06:46:49AM +0200, richard boaz wrote:
> maybe this will help?  the following callback will get the row number of
the
> row when double-clicked by the user.  basically, convert a GtkTreePath
to a
> string.  you must take proper care if you have a tree deeper than one
level.
>
> void recordActivate(GtkTreeView *treeview, GtkTreePath *arg1,
> GtkTreeViewColumn *arg2, gpointer *hdrList)
> {// called when record double-clicked
>char*row;
>introwNum;
>
>row = gtk_tree_path_to_string(arg1);
>rowNum = atoi(row);
>g_free(row);
> }

What is the point of the numbers -> string -> number
conversion when gtk_tree_path_get_indices(path)[0] is
the requested number?

Yeti

--
http://gwyddion.net/
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

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

Re: Regarding GLIB 2.4.0

[richard boaz]

your help is the following:

set the environment variable PKG_CONFIG_PATH to point to the correct
configuration files

unfortunately configure can only do so much, i.e., it can't do your work for
you, and neither can others.  i don't have access to your machine, nor does
anyone else (not that that would matter).

there's even more help in your configure output, but for some reason you
believe the help here will somehow be different.  i rather doubt at this
point it's going to be.

good luck,

richard


On 5/28/07, Sashi Kiran Akella <[EMAIL PROTECTED]> wrote:


David Nečas (Yeti) wrote:

>On Mon, May 28, 2007 at 01:00:40PM +0530, Sashi Kiran Akella wrote:
>
>
>> When I'm installing gtk+-2.4.0, I'm getting the following
error:
>>
>>checking for GLIB - version >= 2.4.0...
>>*** 'pkg-config --modversion glib-2.0' returned 2.4.0, but GLIB (2.6.0)
>>*** was found! If pkg-config was correct, then it is best
>>*** to remove the old version of GLib. You may also be able to fix the
error
>>*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
>>*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
>>*** required on your system.
>>*** If pkg-config was wrong, set the environment variable
PKG_CONFIG_PATH
>>*** to point to the correct configuration files
>>no
>>configure: error:
>>*** GLIB 2.4.0 or better is required. The latest version of
>>*** GLIB is always available from ftp://ftp.gtk.org/pub/gtk/.
>>
>> Please help me come out of this problem.
>>
>>
>
>- actually read the configure error message, it explains what
>  went wrong and what you should do
>- remove anything you installed to system directories from
>  sources and/or restore it from the distro packages and
>  generally get your system to the orignal sane state
>- follow
http://mail.gnome.org/archives/gtk-list/2006-December/msg00113.html
>
>Yeti
>
>--
>http://gwyddion.net/
>___
>gtk-list mailing list
>gtk-list@gnome.org
>http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
>
>
I installed glib 2.4 tarball into my system, but still I';m getting this
error. Please help me how to sort out this problem.

Sashi Kiran
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

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

Re: Regarding GLIB 2.4.0

[richard boaz]

your help is the following:

set the environment variable PKG_CONFIG_PATH to point to the correct
configuration files

unfortunately configure can only do so much, i.e., it can't do your work for
you, and neither can others.  i don't have access to your machine, nor does
anyone else (not that that would matter).

there's even more help in your configure output, but for some reason you
believe the help here will somehow be different.  i rather doubt at this
point it's going to be.

good luck,

richard


On 5/28/07, Sashi Kiran Akella <[EMAIL PROTECTED]> wrote:


David Nečas (Yeti) wrote:

>On Mon, May 28, 2007 at 01:00:40PM +0530, Sashi Kiran Akella wrote:
>
>
>> When I'm installing gtk+-2.4.0, I'm getting the following
error:
>>
>>checking for GLIB - version >= 2.4.0...
>>*** 'pkg-config --modversion glib-2.0' returned 2.4.0, but GLIB (2.6.0)
>>*** was found! If pkg-config was correct, then it is best
>>*** to remove the old version of GLib. You may also be able to fix the
error
>>*** by modifying your LD_LIBRARY_PATH enviroment variable, or by editing
>>*** /etc/ld.so.conf. Make sure you have run ldconfig if that is
>>*** required on your system.
>>*** If pkg-config was wrong, set the environment variable
PKG_CONFIG_PATH
>>*** to point to the correct configuration files
>>no
>>configure: error:
>>*** GLIB 2.4.0 or better is required. The latest version of
>>*** GLIB is always available from ftp://ftp.gtk.org/pub/gtk/.
>>
>> Please help me come out of this problem.
>>
>>
>
>- actually read the configure error message, it explains what
>  went wrong and what you should do
>- remove anything you installed to system directories from
>  sources and/or restore it from the distro packages and
>  generally get your system to the orignal sane state
>- follow
http://mail.gnome.org/archives/gtk-list/2006-December/msg00113.html
>
>Yeti
>
>--
>http://gwyddion.net/
>___
>gtk-list mailing list
>gtk-list@gnome.org
>http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
>
>
I installed glib 2.4 tarball into my system, but still I';m getting this
error. Please help me how to sort out this problem.

Sashi Kiran
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

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

Re: Simple Error

[richard boaz]

You're right, it is a simple error, in that, the solution is simple.

First scour the mail archives, this comes up from time to time and has been
thoroughly discussed.

But briefly,

  1. Do no drawing to the screen in threads other than main
  2. When the thread is ready to draw, use g_idle_add() to put a
  function on the gtk main loop queue to do/invoke the drawing command.

That's it basically.  Things can get tricky, as always with threads, but
follow the above two rules and there's always a solution to be found.

richard


On 6/24/07, Justin Hart <[EMAIL PROTECTED]> wrote:


I haven't done much GTK programming, so I seem to have tripped over
something.  Can somebody help clarify what I should do?

I have a thread running.  Every now and again, it updates an image
that I want to put into a drawing area.  That all works fine, except
that I get this error message.  It's apparently because I'm not
supposed to do this drawing in a thread other than the one with the
gtk_main.

Xlib: unexpected async reply (sequence 0xd6)!

So, I hacked around a bit and wrote a little widget class, it updates
this image when it receives a signal.  I use the thread causing the
problem to send the signal.  So, of course, I figure that this is
fine, and that the signal is picked up in gtk_main.

I guess I was mistaken, since the error remains.  Can anybody
enlighten me as to what I'm doing wrong?
--
Justin W. Hart
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

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

Re: Problem with GdkPixbuf

[richard boaz]

And to answer your question:

The documentation for gtk_image_get_pixbuf() states:

The caller of this function does not own a reference to the returned pixbuf.

I.e., you cannot free a resource that's not yours, so the request fails.
The error message is unfortunate, it's not terribly accurate.

The code rewrite suggestion is the way to go.

richard

On 7/5/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:



 Hi all:
I'm using the Gtkimage and GdkPixbuf to show picture and each time I
run the program I get the following error:
**
*GLib-Gobject-CRITICAL ** : g_object_unref : assertion
`G_IS_OBJECT(object)` failed*

I'm running GTK 2.6.4 and Glib 2.6.4 on a Debian woody.Here is the code
which reproduces the problem:

#include 

int main( int argc,
  char *argv[] )
{
  GtkWidget *window;
  GtkWidget *image;
  GdkPixbuf *pix1;
  GdkPixbuf *pix2;

  gtk_init(&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  image = gtk_image_new_from_file ("1.png");

  gtk_container_set_border_width (GTK_CONTAINER (window), 10);
  gtk_container_add (GTK_CONTAINER (window), image);

  pix1=gtk_image_get_pixbuf(GTK_IMAGE(image));
  pix2=gdk_pixbuf_scale_simple(pix1,320,160,GDK_INTERP_BILINEAR);
  gtk_image_set_from_pixbuf(GTK_IMAGE(image),pix2);
  g_object_unref(pix1);
  g_object_unref(pix2);

  gtk_widget_show (image);
  gtk_widget_show (window);

  gtk_main ();

  return(0);
}

I have no idea how to resolve the problem.Any help will be most
appreciated.Thanks.




--
百 万 玩 家 同 玩 的 乐 园，人 气 爆 发 的 梦 幻 西 游 

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


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

Re: Motion Notify Event

[richard boaz]

Hi,

Here's what I do:

In your widget creation code, "turn on" the events you want to see for the
widget:

gtk_widget_set_events (widget, gtk_widget_get_events (widget)
 | GDK_BUTTON_PRESS_MASK
 | GDK_BUTTON_RELEASE_MASK
 | GDK_POINTER_MOTION_MASK
 | GDK_POINTER_MOTION_HINT_MASK

 | GDK_BUTTON_RELEASE_MASK);

And connect the signal to your drag event:

g_signal_connect (widget, "motion_notify_event",
G_CALLBACK
(M_N_callback), (gpointer) data);

You didn't provide your complete code so it's a bit difficult to tell
exactly what's going on, but:

  1. you should call gtk_widget_set_events() before the widget is
  realized, setting all events you wish to be enabled for the widget in
  question;
  2. n.b.: take note of the gtk_widget_get_events() call - default
  events that automatically come with the widget are, thus, not lost;
  3. unless you need to add events after a widget has been realized, use
  of gtk_widget_add_events() is unnecessary.

One other very important note.  In your callback, the absolute last
executing piece of code before returning to the main loop should/must be:

gdk_window_get_pointer(gdkWindow, &x, &y, &state);

Even though you don't use the resulting values, this call tells the main
loop (managing the motion events) that the callback is done with its work
and is ready to be called again by the main loop.

This is essentially the synchronization hook used to connect back to the
HINT motion type event; as long as your callback has been called and
gdk_window_get_pointer() hasn't been called, your callback won't get called
again.  OR - From the mainloop perspective: once your callback has been
called, all succeeding user motion events are "eaten up" and not passed on
until gdk_window_get_pointer() has been called.

cheers,

richard

On 7/5/07, Dean McCullough <[EMAIL PROTECTED]> wrote:


I am trying to write a tool that uses mouse button presses and motion to
do something useful.  The mouse press is working, but I never get into
the routine from a mouse motion event any action appears to be captured
by the button press event).  The add event and signal connect calls I am
using are below.  Is there an obvious error?  (I saw a recommendation to
use  GDK_POINTER_MOTION_HINT_MASK rather than GDK_POINTER_MOTION_MASK to
keep the application from bogging down.

-

   gtk_widget_add_events(GTK_WIDGET(view),
 GDK_POINTER_MOTION_HINT_MASK);

   gtk_widget_add_events(GTK_WIDGET(view),
 GDK_BUTTON_PRESS_MASK);

   gtk_signal_connect(GTK_OBJECT(view), "motion_notify_event",
   GTK_SIGNAL_FUNC(event_mv), NULL);

   gtk_signal_connect(GTK_OBJECT(view), "button_press_event",
  GTK_SIGNAL_FUNC(event_cb), NULL);

--
-
Dean P McCullough

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

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

Re: Set Allignment of GtkComboBox Columns

[richard boaz]

Haven't tried this particular case myself, but it might be worth
investigating using gtk_size_group_* routines.  Perhaps this can be used to
force the columns to be equally sized.

richard

On 7/19/07, Andrea Zagli <[EMAIL PROTECTED]> wrote:


Il giorno ven, 06/07/2007 alle 06.05 -0700, ibrar ahmed ha scritto:
> I created combo box with multiple columns, like in first column there
> is pixbuf and string and other columns have only data string. But
> problem is that columns of combobox are not well alligned. If some
> entry have maximum string with pixpuf, columns of combobox are not
> alligned so far.
> I want to be arranged all columns of combobox.

i don't know how you can do it with gtkcombobox, but you can try to use
http://sourceforge.net/projects/gtkcombogrid

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



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

Re: installing GTK+

[Richard Boaz]

cue sergei and his ostensibly blatant self-promotion actually aimed at
trying to help the unwitting poor souls avoid such "disasters" (not my
moniker)...

nah, i'll do it:

to install gtk+ and avoid such disasters in the future, use this very
handy tool which will install gtk+ in its own directory separate from
system directories:

http://appsfromscratch.berlios.de/


On Sat, Jul 21, 2007 at 07:42:42PM +0200, Robert Kolozsi wrote:
> I am using Debian Sarge and I am not an expert of GNU/Linux. I wanted to
> install GTK+ 2.10.9 because I need it for inkscape 0.45. I downloaded
> the source of all dependencies and the GTK+ from 'www.gtk.org/'. Builded
> it succesfully with './configure --prefix=/usr'.

You overwrote lots of system libraries.  Unfortunately,
that's not a success, that's a disaster.

> I had no problems till
> I boot the machine.
> It is booting to the splash screen of 'nvidia' and
> then the whole screen becomes grey and mouse pointer looks like X. After
> a few seconds I get a window says to me:'There already appears to be a X
> server runing on display :0. Should I try another display number? If you
> answer no, I will attempt to start the server on :0 again.(You can
> change consoles by pressing Ctr+Alt plus a function key, such as
> Ctrl+Alt+F7 to go to conslole7. X servers usually run on consoles 7 and
> higher.)'
>
> Actualy I can not log in with graphic interface. There is no login
> window. I can not start gdm. How can I fix this problem? I do not know
> where I made a mistake. I do not know what information should I give more..
>
> Current GTK+ is default for Sarge. Should I uninstall it first and how?

Restore the system to the state before you started
overwriting things in /usr.  This involves finding files
that do not match their package checksums or do not belong
to any package at all, filtering out files that were
modified for valid reasons, making a list of affected
packages, reinstalling them and removal of the extra files.
It can be easier to backup and then reinstall the system
completely.

Then look for backports.  If you don't find what you need
there, install the Gtk+ stack into a ***non-system***
directory and compile Inkscape with that, following for
instance
http://mail.gnome.org/archives/gtk-list/2006-December/msg00113.html

It is probably possible to make X/gdm work again in the
current state, but (a) it can require a volunteer to break
his system according to your recipe and then figure out the
cause (b) you want your system in a sane state anyway as
even if you made it work, an upgrade of any affected library
package (which would be a downgrade wrt the manually compiled
stuff) would likely break it again.

(I have seen Ubuntu people having these problems, however,
they seemed to be due to broken packages and the resolution
generally was the reinstallation of the relevant packages --
X11, maybe others -- which does not reval much about the
cause.)

Yeti

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

Font Size change?

[Richard Boaz]

To all the font gurus:

In gtk+ version 2.6 I specified to draw some text on my drawing area using
the font "Sans bold 10" and received a favourable result.

In gtk+ version 2.10 I have not changed this specification and suddenly
the font is much larger than in version 2.6, to the point I have to change
it to make everything work as before.

I know this must relate to gtk+ since I have both versions installed on my
box and can simply point my application to one or the other and
demonstrate the difference.

I was under the impression that font sizes were fixed.  I guess I was
wrong.  But this confuses me, why would a font change real size across
different versions of gtk+?

On a more general note, how can I produce and provide my program across
multiple versions of gtk+ (now and into the future) without having to
worry about fonts changing their real size on the fly?

thanks for any pointers and explanations,

richard

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

Re: Position of Gtk+ button

[richard boaz]

actually, this information is stored in the widget data structure itself:

widget->allocation.y
widget->allocation.x

no need to use a routine, just access the data structure directly for the
info you require (there's other info there too).

On 7/21/07, vkrejcirik <[EMAIL PROTECTED]> wrote:


Hello,

I need find position (x and y coordinates) of GtkButton in my GtkWindow.
I looked for same function in C in GTk+ Reference Manual which do it, but
didn't find it.
Please can somebody help me?
thanks.

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

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

Re: help on callback

[richard boaz]

Hi,

Save a pointer to the widget you create and use the query routine(s) for the
specific widget in question using your saved pointer.

cheers,

richard

On 8/29/07, Alessandro Toso <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> I'm new to the list and to gtk. I'm playing with some examples and I
> have a question:
>
> Let's say that I have a window with a bunch of entries and I want to
> print the string that the user enters when I click a button. It's
> easy for me to print every string when I press "enter" after editing
> each entry but how can I get a pointer to each of them when calling a
> callback belonging to another widget (the button in this case)?
>
> Thanks
> Bye
>
> Alessandro
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: DrawingArea and Toolbar focus issues

[Richard Boaz]

This is what I do:

1) create a callback for mouse-enter events on your drawing area
2) execute gtk_grab_add() on the drawing area as part of this callback
3) all key events will now be routed correctly to your other callback(s)
4) execute gtk_grab_remove() for mouse-leave events on the drawing area

richard



Hi.
I've set up a GtkDrawingArea to catch keypress and keyrelease events.
However, if a toolbar created via gtk_ui_manager_get_widget() is
visible, the toolbar's first button seems to steal those events -
despite my attempts to change the focus, disable key press/release
events to the toolbar, etc. If the toolbar isn't visible, everything
works as expected. Does anyone have any suggestions on this one?

Thanks,
Brian

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

g_option_context_parse under cron execution

[Richard Boaz]

Hi,

I am using the following code to parse my routine's command line:

gboolean parsePQLXargs(int argc, char **argv, PQLXSRVRSTRUCT *pqlxSrvr)
{
  gboolean  ret=TRUE;
  GOptionContext *context;
  GError*error = NULL;
  static GOptionEntry entries[] =
  {
{ "dbName", 0, 0, G_OPTION_ARG_STRING, NULL, "PQLX Database Name",
"[SERVER:]pqlxDB" },
{ "numCPU", 0, 0, G_OPTION_ARG_INT, NULL, "Number of CPUs to use", "#" },
{ "identFile", 0, 0, G_OPTION_ARG_STRING, NULL, "File Containing List
of Traces to be Re-Analyzed", "path-to-file" },
{ NULL }
  };

  entries[0].arg_data = &pqlxSrvr->pdfSrvr;
  entries[1].arg_data = &pqlxSrvr->numCPUS;
  entries[2].arg_data = &pqlxSrvr->identFile;
  context = g_option_context_new ("- Execute pqlxSrvr");
  g_option_context_add_main_entries (context, entries, NULL);
  g_option_context_add_group (context, gtk_get_option_group (TRUE));
  if (!g_option_context_parse (context, &argc, &argv, &error))
  {
if (error)
fprintf(stdout, "parse error: %s\n", error->message);
else
fprintf(stdout, "parse failed, there is no error\n");
ret = FALSE;
  }
  return ret;
}

Everything works fine when the program is executed directly from a command
line.

However, when executed via a cron job, g_option_context_parse() returns
FALSE, i.e., failure.  Except the error structure is still NULL, i.e., no
error is set as a result of this failure.

So my questions:

1) why does g_option_context_parse() fail when executed under cron?
2) why is there no error set on this failure?

Does anyone use the glib command line parser under a cron execution? 
Search by google found no references to this particular combination being
problematic and at this point I must simply write my own command line
parser since cron execution is an absolute requirement for me.

Any pointers appreciated.  If this should be regarded as a bug, let me
know, I'm happy to log a report.

cheers,

richard

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

Re: g_option_context_parse under cron execution

[Richard Boaz]

Yes, I've fully debugged the cron-executed version.  All arguments are
identical to when executed from the command line, i.e., are properly
constructed and fully valid.

I was wondering, too: Does this particular glib routine require there be a
display available?  Still, I would expect the error structure to be filled
if this were the case, but maybe not?

richard

On 10/3/07, Sergei Steshenko <[EMAIL PROTECTED]> wrote:

Have you tried to replace (temporarily) you program with something simple
written in, say, Perl or "C" that just prints ARGV ?

I mean, can it be that somehow wrong arguments are passed to your
program from 'cron' ?

--Sergei.


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

Re: g_option_context_parse under cron execution

[Richard Boaz]

Hi John,

Thanks.  Going through the exercise of providing a small example, the
cause of the problem became known:

I had included the following call when setting up the context:

g_option_context_add_group (context, gtk_get_option_group (TRUE));

as indicated in the documentation example.  Looking into the details of
the call gtk_get_option_group(TRUE), TRUE is an indication that the
default display should be opened when parsing the command line.

So under cron, this fails, naturally.

I do not need the gtk command line options in my program (nor a display),
so simply removing this line makes everything work as required and
expected.

thanks,

richard

p.s. i still think, however, the error structure should be set; an error
occurred and the call to parse fails, why can't i know why?  (thus
avoiding bothering this list?)

On 10/3/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
...
I think the error must lie elsewhere, though I'm not sure exactly
where. Can you make a tiny standalone main.c that shows your problem?

John

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

Gdk GC and Associated Colormap

[Richard Boaz]

Hi,

I'm having a bit of a strange problem and wonder if anyone has any advice
on how to track it down further.

I have the following code (snippet) (this has been executing fine for the
last 2 years on various LINUX flavors, MAC OS X, and Solaris):

=
gc = gdk_gc_new(da->window);
gdk_gc_set_rgb_fg_color (gc, fg);
gdk_gc_set_rgb_bg_color (gc, bg);
=

where da is a previously created drawing area, and fg and bg are
appropriately defined and set.

But now, given the following two machines:
Machine A: OS = Opensuse 10.3, GTK+ = 2.12.0
Machine B: OS = Opensuse 10.1, GTK+ = 2.8.10

I am having problems displaying to machine A.

Execution and Display Combinations return the following:
1) Execute on Machine A, same display, returns the following error (twice)

Gdk-WARNING **: gdk_gc_set_rgb_fg_color() and gdk_gc_set_rgb_bg_color()
can only be used on GC's with a colormap. A GC will have a colormap if it
is created for a drawable with a colormap, or if a colormap has been set
explicitly with gdk_gc_set_colormap.

followed by a single X11 error message (asynchronously reported, of course):
...
The error was BadMatch (invalid parameter attributes)
error_code 8 request_code 70 minor_code 0
...

2) Execute on Machine B, same display
Program executes fine

3) Execute on Machine A, display to Machine B
Program executes fine

4) Execute on machine B, display to Machine A
I receive the same warning/error as in 1) above.

The conclusions I draw from this:
1) on machine A, the call to gdk_gc_new() does return a gc, but this gc
does not end up having a colormap associated with it for some reason.
2) since the same program on machine A displays fine on machine B, this
has something to do with the display, or X11, or ...?
3) some call to X11 fails and, I think, causes all other downstream
problems.  (what is request_code = 70?)

Does anybody have any idea what this could relate to and why this would be
happening?  Is it possible that a drawing area can be created, the window
for it defined, while a colormap is not created for a gc's definition? 
(fyi: other display programs using color, e.g. firefox, display fine on
machine A.)

Any pointers or advice as to how I can track this down would be appreciated.

cheers,

richard boaz

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

PNG image creation without a physical display

[Richard Boaz]

Hello,

I have a general question about how GTK+ can be used and after my
investigations have lead me nowhere, I thought I would post to the list.

I have an application that reads data from a database and renders
probability density function plots thereof to the user's display via my
gui program.

Over time, the users expressed the desire to output these images to be
viewable elsewise.  Using libpng and the appropriate GTK+ routines, it was
easy to output these images to a .png file on disk (for viewing by a
web-browser, for example).

Continuing the idea, the users requested that the middle-man, i.e., the
gui, be completely cut out of the process: produce a program that reads
the data from the database and writes directly to .png files.

I have done this without problem, I can read data, make images and output
them to disk in .png format just fine, as long as there's a physical
display available.

The problem comes when I attempt to execute this job under cron (analysis
data is created on a server, stored in a database, followed by a program
to read this data and create images for automatic web display), or if
executed directly on a server machine with no physical display (but with
X11 and GTK+ installed).

When doing in either manner, my gtk_init() fails since there is no
(alleged) existence of a display.

My questions are two:

1) when run under cron, there ma be, in fact, an X-server running (say,
serving the login splash screen), just not for the executing user.  Is
there any way to force a gtk+ program to connect to an X-server running on
the same machine from within a cron execution?

2) more ideally, however, I would like to be able to write a program that
does not in any way have to rely on an X-server instance running at all. 
All drawing routines in GTK+ demand a drawable, which, in turn, require
that gtk_init() be called before-hand.

So, in general, is it possible to write a drawing program using GTK+ that
outputs a .png image without having to rely on the physical existence of a
screen or an X-server?

Or must I resort to using some other library or program?  Or am I missing
something obvious here (which I hope)?

thanks for any tips or pointers, this is really the final open question
that will make the system I've been developing for the last three years
(graphically, at least) complete.

cheers,

richard boaz

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

Re: GDK_POINTER_MOTION_HINT_MASK has no effect

[richard boaz]

Hi,

I'm not really sure what *is_hint* is intended to provide, but anyway, what
you are trying to achieve is totally possible without its use (if I
understand you properly).

Going on the assumption I do understand what you are trying to achieve, I am
providing below some code to illustrate this.  Though actual code, it is not
runnable in its stand-alone form, you will need to tweak it a bit to make it
actually work.  However, it does contain all the hooks necessary to do the
following:

   1. Draw a solid line from point A to point B:
   point A = point at mouse-down
   point B = point at mouse-up
   2. Draw a dashed line from point A (same as in 1) to Drag Point B:
   Drag Point B = point at drag event callback

I have left out the configure and expose callbacks, I assume that these have
been called and produce a pixmap for display, this pixmap being held in the
global variable *DAcontents*.  (Again, this is to illustrate, not to
demonstrate proper coding, you probably shouldn't make a global variable for
this purpose.)

The mouse event callback:

   1. On mouse-down, save the starting point (point A)
   2. On mouse-up, draw a solid line from point A to the ending point
   (point B) and render to the screen.

The drag event callback:

   1. If mouse is not down, do nothing and return
   2. If mouse is down, create temporary pixmap and copy *DAcontents* to
   it
   3. draw a dashed line from point A to Drag Point B (event->x,
   event->y) on our temp pixmap
   4. Render temp pixmap to the screen
   5. unref temp pixmap
   6. call gdk_window_get_pointer() to tell the main loop we are done
   with the drag event and are ready to receive another call to the drag event
   callback

Not sure where the problem is in your implementation, but doing these sorts
of things with GTK+ is typically not problematic.

cheers,

richard

= begin code ===

GdkPixmap*DAcontents;
GdkGC*gcMain;

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

gtk_init(&argc, &argv);

da = gtk_drawing_area_new();
g_signal_connect (da, "button_press_event", G_CALLBACK (doMouse), NULL);
g_signal_connect (da, "button_release_event", G_CALLBACK (doMouse),
NULL);
g_signal_connect (da, "motion_notify_event", G_CALLBACK (doDrag), NULL);
gtk_widget_set_events (da, gtk_widget_get_events (da)
  | GDK_BUTTON_PRESS_MASK
  | GDK_BUTTON_RELEASE_MASK
  | GDK_POINTER_MOTION_MASK
  | GDK_POINTER_MOTION_HINT_MASK);
gtk_main();
}

intstartX, startY, endX, endY;
gboolean mouseDown;

gboolean doMouse(GtkWidget *da, GdkEventButton *event, gpointer nothing)
{
if (!gcMain)
gcMain = gdk_gc_new(da->window);

switch(event->type)
{
case GDK_BUTTON_PRESS:
startX = event->x;
startY = event->y;
mouseDown = TRUE;
break;
case GDK_BUTTON_RELEASE:
endX = event->x;
endY = event->y;
gdk_draw_line(DAcontents, gcMain, startX, startY, endX, endY);
gdk_draw_drawable(da->window,
da->style->fg_gc[GTK_STATE_NORMAL],
DAcontents, 0, 0, 0, 0, -1, -1);
mouseDown = FALSE;
break;
}
return TRUE;
}

gboolean doDrag (GtkWidget *da, GdkEventMotion *event, gpointer nothing)
{
GdkModifierType state;
gintx, y;
GdkPixmap*pixmap;
static GdkGC*gcDash=NULL;

if (!gcDash)
{// first time call setup
gcDash = gdk_gc_new(da->window);
gdk_gc_set_line_attributes(gcDash, 1, GDK_LINE_ON_OFF_DASH, 0, 0);
}

switch(mouseDown)
{
case FALSE:
break;

case TRUE:
pixmap = gdk_pixmap_new(da->window, da->allocation.width, da->
allocation.height, -1);
gdk_draw_drawable(pixmap, da->style->fg_gc[GTK_STATE_NORMAL],
DAcontents,
0, 0, 0, 0, -1, -1);
gdk_draw_line(pixmap, gcDash, startX, startY, event->x,
event->y);
gdk_draw_drawable(da->window,
da->style->fg_gc[GTK_STATE_NORMAL],
pixmap, 0, 0, 0, 0, -1, -1);
g_object_unref(pixmap);
break;
}

gdk_window_get_pointer(event->window, &x, &y, &state);
return TRUE;
}

= end code ===


On Nov 27, 2007 3:27 AM, Stewart Weiss <[EMAIL PROTECTED]> wrote:

> I have been playing around with the motion_notify_event callback in the
> Scribble example from the tutorial, and I have discovered that none of
> what the documentation states is correct.  I modified the handler to
> generate
> output on the standard outout device as follows:
>
> gboolean motion_notify_event( GtkWidget  *widget,
>  GdkEventMotion *event,
>  gpointer   *mydata )
> {
>int x, y;
>GdkModifierType state;
>
>

Re: GDK_POINTER_MOTION_HINT_MASK has no effect

[Richard Boaz]

Hi,

I'm not really sure what is_hint is intended to provide, but anyway, what
you are trying to achieve is totally possible without its use (if I
understand you properly).

Going on the assumption I do understand what you are trying to achieve, I
am providing below some code to illustrate this.  Though actual code, it
is not runnable in its stand-alone form, you will need to tweak it a bit
to make it actually work.  However, it does contain all the hooks
necessary to do the following:

   1. Draw a solid line from point A to point B:
  point A = point at mouse-down
  point B = point at mouse-up
   2. Draw a dashed line from point A (same as in 1) to Drag Point B:
  Drag Point B = point at drag event callback

I have left out the configure and expose callbacks, I assume that these
have been called and produce a pixmap for display, this pixmap being held
in the global variable DAcontents.  (Again, this is to illustrate, not to
demonstrate proper coding, you probably shouldn't make a global variable
for this purpose.)

The mouse event callback:

   1. On mouse-down, save the starting point (point A)
   2. On mouse-up, draw a solid line from point A to the ending point
(point B) and render to the screen.

The drag event callback:

   1. If mouse is not down, do nothing and return
   2. If mouse is down, create temporary pixmap and copy DAcontents to it
   3. draw a dashed line from point A to Drag Point B (event->x, event->y)
on our temp pixmap
   4. Render temp pixmap to the screen
   5. unref temp pixmap
   6. call gdk_window_get_pointer() to tell the main loop we are done with
the drag event and are ready to receive another call to the drag event
callback

Not sure where the problem is in your implementation, but doing these
sorts of things with GTK+ is typically not problematic.

cheers,

richard

= begin code ===

GdkPixmap*DAcontents;
GdkGC*gcMain;

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

gtk_init(&argc, &argv);

da = gtk_drawing_area_new();
g_signal_connect (da, "button_press_event", G_CALLBACK (doMouse), NULL);
g_signal_connect (da, "button_release_event", G_CALLBACK (doMouse),
NULL);
g_signal_connect (da, "motion_notify_event", G_CALLBACK (doDrag), NULL);
gtk_widget_set_events (da, gtk_widget_get_events (da)
  | GDK_BUTTON_PRESS_MASK
  | GDK_BUTTON_RELEASE_MASK
  | GDK_POINTER_MOTION_MASK
  | GDK_POINTER_MOTION_HINT_MASK);
gtk_main();
}

intstartX, startY, endX, endY;
gboolean mouseDown;

gboolean doMouse(GtkWidget *da, GdkEventButton *event, gpointer nothing)
{
if (!gcMain)
gcMain = gdk_gc_new(da->window);

switch(event->type)
{
case GDK_BUTTON_PRESS:
startX = event->x;
startY = event->y;
mouseDown = TRUE;
break;
case GDK_BUTTON_RELEASE:
endX = event->x;
endY = event->y;
gdk_draw_line(DAcontents, gcMain, startX, startY, endX, endY);
gdk_draw_drawable(da->window, da->style->fg_gc[GTK_STATE_NORMAL],
DAcontents, 0, 0, 0, 0, -1, -1);
mouseDown = FALSE;
break;
}
return TRUE;
}

gboolean doDrag (GtkWidget *da, GdkEventMotion *event, gpointer nothing)
{
GdkModifierType state;
gintx, y;
GdkPixmap*pixmap;
static GdkGC*gcDash=NULL;

if (!gcDash)
{// first time call setup
gcDash = gdk_gc_new(da->window);
gdk_gc_set_line_attributes(gcDash, 1, GDK_LINE_ON_OFF_DASH, 0, 0);
}

switch(mouseDown)
{
case FALSE:
break;

case TRUE:
pixmap = gdk_pixmap_new(da->window, da-> allocation.width,
da->allocation.height, -1);
gdk_draw_drawable(pixmap, da->style->fg_gc[GTK_STATE_NORMAL],
DAcontents,
0, 0, 0, 0, -1, -1);
gdk_draw_line(pixmap, gcDash, startX, startY, event->x,
event->y);
gdk_draw_drawable(da->window, da->style->fg_gc[GTK_STATE_NORMAL],
pixmap, 0, 0, 0, 0, -1, -1);
g_object_unref(pixmap);
break;

}

gdk_window_get_pointer(event->window, &x, &y, &state);
return TRUE;
}

= end code ===

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

Xlib calls and Multi-Threaded Apps

[Richard Boaz]

Thought I'd add my two cents here:

Expecting an X server to honor a multi-threaded request is always an iffy
proposition.

First, you have no guarantee that the X server you will be executing
against will actually understand the call, not all versions existing in
the world are up-to-date in this regard.

Second, imho, this is not implemented terribly well anyway at the X level.
 You will lose inordinate amounts of time trying to get your head around
why things don't work the way you cognitively think they should.  There is
nothing more unenjoyable than trying to decipher Xlib error messages. And
simply running the application synchronously is no answer here, your
experience of being thoroughly frustrated merely exists in slow motion.

Luckily, there are few, if any, applications which require this sort of
behaviour anyway.  Instead of thinking it's easier to write multi-threaded
applications which can draw in multiple threads (it's not), use the
following paradigm:

1)  Do all drawing in the main thread only
2)  Use other threads only for background sorts of processing:
communications, database requests, data analysis, etc.
3)  Once the background thread has completed its task, use
g_idle_add() to issue a request back to the main thread that a drawing
needs to be updated, i.e., call the routine that is responsible for
drawing to your background pixmap.

In essence, your application is multi-threaded, however, in the context of
communications with the X server it remains single-threaded.  Maintaining
this illusion with X will seriously increase the likelihood that your
application will work "everywhere".

In other words, do not rely on the X-server to keep your multi-threaded
app in a sane state 100% of the time; multi-threading is tricky enough
without including X in the problem.

cheers,

richard

On Nov 29, 2007 2:16 AM, Michael Lamothe <[EMAIL PROTECTED]> wrote:

Hi,

I think that they do call XInitThreads() but libraries such as
xine-lib break if you don't call it first.  Don't know why.  If your
GTK app does not use and X based (Non GDK/GTK) libraries then maybe
this isn't your problem.

Maybe, as Micah pointed out, this might be a simple problem with you
not writing a thread safe application.  Is your application
multi-threaded?

Thanks,

Michael


On 29/11/2007, Andres Gonzalez <[EMAIL PROTECTED]> wrote:
> Thank you Michael for your response.
>
> What was confusing to me was that I was not directly using X but Gtk.
> But I am using g_thread_init() and g_thread_create(). I am assuming
> that g_thread_init() calls XInitThreads() so your answer is very
> helpful.
>
> Thanks again,
>
> -Andres
>
>
>
>
> > Every time I see this it's because I've called a multi-threaded
> > library that requires XInitThreads() to be called.  This needs to be
> > called before all other X functions.
> >
> > Hope that helps.
> >
> > Thanks,
> >
> > Michael
> >
> >> On 28/11/2007, Andres Gonzalez <[EMAIL PROTECTED]> wrote:
> >> Hi,
> >>
> >> I get the following error message when displaying a dialog. Any
> ideas
> >> as to what is causing it?
> >>
> >> Xlib: unexpected async reply (sequence 0x6cb)
> >>
> >> Thanks,
> >>
> >> -Andres


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

Re: GDK_POINTER_MOTION_HINT_MASK has no effect

[Richard Boaz]

This is the paradigm I use in all my drawing apps that has served me well:

1) Do all drawing to one or more background pixmaps.
2) Do all drawing in routines separate from your configure handler or
your expose handler.
3) Call your drawing routine(s) from the configure handler.
4) Once your drawing routine has completed its task, call
gtk_widget_queue_draw_area() to force the expose event.
5) Do no drawing in your expose event except to gtk_draw_drawable(),
rendering your background pixmap to the physical display.
6) Use temporary pixmaps liberally when rendering a "temporary" state
to the screen.  (For example, display of cross-hairs and coordinates
when user is simply dragging the mouse (no buttons down) across the
drawing area.)

You will notice, here, that there is no actual drawing to the physical
screen except to render your pixmap.  This is the fastest possible manner
in which to draw to the screen.  As well, the expose handler is called
whenever your drawing area is exposed by the window manager, say if it has
been partially obscured by other windows and the user brings it to the
front.  By using gtk_draw_drawable(), you can use the same (x,y)
parameters passed to the callback to render only that part of the pixmap
requiring exposure, i.e., making it as fast as possible.  (Not to mention
that to use these (x,y) parameters to programmatically figure out what
should be re-drawn is practically impossible.)

By maintaining all drawing activity in separate routines, you are able to:

1) have multiple routines responsible for drawing a picture to a
single drawing area, determining programmatically which routine should
be called at any given moment.  These separate routines can draw to
separate backing store pixmaps.
2) easily call any drawing routine from anywhere else in your
application, including background threads (via g_idle_add()), thus
making it trivial to maintain a multi-threaded graphical application.
3) maintain, possibly, multiple backing store pixmaps that can be
easily referenced for redrawing without having to go through an entire
redraw.  (For example, to maintain "before" and "after" states of a
drawing action.  It is much easier to simply re-render a pixmap as
part of an Undo operation than to have to "remember" and redraw the
previous state.)

Basically, in de-coupling your configure and expose events from actual
drawing, you gain much more power in managing all the requirements of your
drawing area than if you use a single drawing area that is the screen. 
Not to mention that drawing directly to the screen is absolutely the
slower of the two options.

As John's post indicates, there is no single way to do all this; gtk gives
you way more than enough rope.  The trick is finding the method that works
for you and your specific requirements.

cheers,

richard

On Nov 29, 2007 4:30 AM, Stewart Weiss <[EMAIL PROTECTED]> wrote:

Many thanks for these posts. They are moving me closer to a better
understanding of the right way to tackle the drawing issues.
I still need a bit of clarification.

1. I am assuming that when I queue a draw for the old position of
the rubberbanded line, I am using XOR to draw it, so that it is in
effect, an erasing, right?

2. You say in the post referenced below that we should really draw
only in the expose event handler, not in the motion or button event
handlers.
Right now, my function to draw a line uses gdk_draw_line into the pixmap
and then calls gdk_window_invalidate_rect to send the expose event later.
If I actually call the gdk_draw_line in the expose event handler,
directly
into the pixmap, would I then use gdk_draw_drawable to copy the pixmap
into
the window?   I know I can't queue a drawing event in the handler or else
I have an infinite indirect recursive loop. Is this how?

Stewart



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

Re: GDK_POINTER_MOTION_HINT_MASK has no effect

[Richard Boaz]

On Nov 29, 2007 1:36 PM, Paul Davis <[EMAIL PROTECTED]> wrote:

On Thu, 2007-11-29 at 09:51 +0100, Richard Boaz wrote:
> This is the paradigm I use in all my drawing apps that has served me
well:
>
> 1) Do all drawing to one or more background pixmaps.

GTK already does this for you now. All widgets are double buffered
unless you explicitly request otherwise. So you are currently drawing
into your bg pixmap, than GTK will copy it into another bg pixmap and
then finally render it to the screen.

Well, this confuses me a bit.  Help me understand?

Given the following expose handler has been attached to a drawing area:

=== begin code sample 1 ===

gboolean exposeME(GtkWidget *da, GdkEventExpose *event, gpointer *nil)
{
  int w = da->allocation.width;
  int h = da->allocation.height;
  GdkGC *gc = da->style->fg_gc[GTK_WIDGET_STATE(widget)]

  // some lines:
  gdk_draw_line(da->window, gc, w/2, 0, w/2, h);  // vertical
  gdk_draw_line(da->window, gc, 0, h/2, w, h/2);  // horizontal
  gdk_draw_line(da->window, gc, 0, 0, w, h);  // diagonal
  gdk_draw_line(da->window, gc, 0, h, w, 0);  // diagonal

  return TRUE;
}

=== end code sample 2 ===

I assume the double-buffering occurs at least with each call to
gdk_draw_line(), but when is this double-buffer (that you the programmer
have no access to, I assume?) actually rendered to the screen?  After each
call, or only once the expose handler has exited?

If this physical event occurs only after the expose handler has exited,
then kudos to the GTK+ designers and developers, this is very good.  And
you are correct, my method employs an extra bg pixmap that is, in this
simple case, unnecessary, though in any case, not expensive.

*If* this occurs after each call, then I can do better:

=== begin code sample 2 

GdkPixmap *pmap;

void drawMe(GtkWidget *da)
{
  int w = da->allocation.width;
  int h = da->allocation.height;
  GdkGC *gc = da->style->fg_gc[GTK_WIDGET_STATE(widget)]

  gdk_draw_line(pmap, gc, w/2, 0, w/2, h);  // vertical
  gdk_draw_line(pmap, gc, 0, h/2, w, h/2);  // horizontal
  gdk_draw_line(pmap, gc, 0, 0, w, h);  // diagonal
  gdk_draw_line(pmap, gc, 0, h, w, 0);  // diagonal

  gtk_widget_queue_draw_area(da, 0, 0, w, h);
}

gboolean exposeME(GtkWidget *da, GdkEventExpose *event, GdkPixmap *pmap)
{
  int w = da->allocation.width;
  int h = da->allocation.height;
  GdkGC *gc = da->style->fg_gc[GTK_WIDGET_STATE(widget)]

  gdk_draw_drawable(da->window, gc, pmap,
event->area.x, event->area.y,
event->area.width, event->area.height);
  return TRUE;
}

=== end code sample 2 ===

Why better? For at least a couple of reasons.  First, the physical event
to render to the screen has been reduced to one instead of after each
drawing call to da->window in the previous code sample.  (Again, depending
on when the physical render actually occurs.)

Second, double-buffering aside, since (I am assuming here, please correct
me if I'm wrong) you the programmer don't have access to this double
buffer pmap, if you get an expose event from the window manager using code
sample 2, you are making a request for a physical draw that corresponds
exactly to those pixels which require being exposed.  And this particular
case is wholly not addressed in code sample 1; there, you must redraw the
entire screen even if only 4 pixels in the lower right corner require a
re-draw.  As I said before, using the GdkEvent* info to be efficient in
redrawing only what's required is impossible, and if not, a complete waste
of programming time and resources.

In both cases, this equates to a program that is more efficient.  Perhaps
a negligible increase, but an increase nonetheless.  Call me a pedantic
purist, but where graphical programming is concerned, anywhere I can find
a method that is more efficient than another and that will be the method I
choose.

For the record, I have always disagreed with the scribble example in the
demo code; it gets a simple job done, but in the real world, these things
are rarely so simple.

> 2) Do all drawing in routines separate from your configure
handler or
> your expose handler.
> 3) Call your drawing routine(s) from the configure handler.
> 4) Once your drawing routine has completed its task, call
> gtk_widget_queue_draw_area() to force the expose event.
> 5) Do no drawing in your expose event except to
gtk_draw_drawable(),
> rendering your background pixmap to the physical display.
> 6) Use temporary pixmaps liberally when rendering a "temporary"
state
> to the screen.  (For example, display of cross-hairs and coordinates
> when user is simply dragging the mouse (no buttons down) across the
> drawing area.)

richard, i know you have a lot of experience with GT

Re: GDK_POINTER_MOTION_HINT_MASK has no effect

[Richard Boaz]

Paul,

Thanks for the information, it's good to learn about how GTK+ does its
double buffering in detail.  However...

On Nov 29, 2007 5:22 PM, Paul Davis <[EMAIL PROTECTED]> wrote:

>   And this particular
> case is wholly not addressed in code sample 1; there, you must
redraw the
> entire screen even if only 4 pixels in the lower right corner require a
> re-draw.  As I said before, using the GdkEvent* info to be efficient in
> redrawing only what's required is impossible, and if not, a complete
waste
> of programming time and resources.

no, there is never any need to do this. expose events always contain
information on the region (a collection of 1 or more non-overlapping
rectangles) to redraw. this is based either on information from the
underlying window system or whatever was passed to
gdk_window_invalidate_rect() and its cousins. the only limitation is
that GDK generally "tiles" a drawable with rects no smaller than a given
size, so if there were really just 4 pixels to redraw, you'd like end up
redrawing 32 or 16 or some such number.

I'm still confused as to how this case should be handled in an expose
handler if you do all your drawing there.

To illustrate: I have been called once, and GTK+ has drawn to the double
buffer pixmap as you say.  I was partially obscured and am now re-exposed,
i.e., the main loop calls me again specifying an invalidated rectangle via
the GdkEvent structure.

Do I:
  1) redraw the entire picture since I've been called, ignoring all else,
knowing this will result in a fully refreshed screen?

  2) redraw only that part which was obscured (rectangle parameters
provided), having to determine programmatically what drawing commands
actually constitute refreshing the obscured portion?

  3) know that my drawing hasn't changed its state since the last complete
draw and doesn't need to be redrawn at all since upon exiting this call,
the double buffer I had previously written to still contains my drawing
and will physically refresh only the rectangle which was passed to the
expose handler for re-exposure?

Naturally I will demand that the third option is really the only
acceptable answer since:

  1) option 1 is a complete waste of resources when I have to process 100
million data points for drawing to the screen (I exaggerate not).

  2) option 2 is simply impossible to make a one-to-one calculation as to
which pixels must be refreshed, programmatically.

If the third option is how GTK+ handles this scenario (more kudos...),
then the expose handler would look something like?:

gboolean exposeME(.)
{
   if (redrawRequired || firstTime)
   {
  // process 100,000,000 data points to draw to da->window
   }
   return TRUE;
}

If, however, the double buffer no longer exists when called the second
time, and I have to take option 1, then it is utterly inefficient to have
to redraw the entire screen each time the expose handler is called when I
have to do so much to actually redraw.  (And besides, what's the
invalidated rectangle information used for then anyway?)

(Getting a little ahead of myself since I don't know the answer to my
previous question yet, but...)

If I must do it as per option 1, consider then the two options:

Option 1:
- draw to da->window in expose handler (...of 100M data points)
- expose handler called 10 times by main loop

Option 2:
- make bg pixmap in separate routine (...of 100M data points)
- expose pixmap in expose handler via drawing of bg pixmap
- expose handler called 10 times

Would you not take option 2 and save the time required to process 900M
points of data unnecessarily?

Or am I missing something?  It just strikes me as more efficient to issue
real drawing commands as little as possible, i.e., once to a bg pixmap,
and then to draw this pixmap to the screen.  Not only is it more efficient
(simple less CPU usage), it also makes the application more "responsive"
and "snappy" since the operation of transferring a pixmap to the screen is
instantaneous, while processing 100M data points is, er, not.

And we haven't even begun to discuss animations of these drawings.  Most
definitely in this case, you would want to:
- make all your drawings making up the entire animation as bg pixmaps
- use g_timeout_add() to invalidate the entire drawing area for redraw,
being called over and over until no more drawings
- while the expose handler does nothing more than render the next pixmap
of the animation sequence to the screen.

No?  Or would you still do all your drawing in the expose handler for an
animation?

And I still don't understand why this particular paradigm which works
without fail for me is opposite to GTK+ design.  It's nothing more than an
alternative to the scribble example that, for my requirements, doesn't
work.

The way I see it, the GTK+ designers and developers have succeeded at
doing what you said: to make it as efficient and as smooth as possible,
and this they have done well.  Is

To Draw | ! To Draw in an Expose Handler

[Richard Boaz]

splitting this out into its own thread...

>
>   2) option 2 is simply impossible to make a one-to-one calculation
as to
> which pixels must be refreshed, programmatically.

for many (perhaps even for an overwhelming majority of applications (2)
works just fine. if you application can't do this cheaply, then your
approach is the right way.

Sorry, I can't think of a single application responsible for making its
own drawings by hand where option 2 is not crazy hard.  (If anybody has an
example of this in real-world application, please post?)

(Paul, would you be willing to take the scribble code from gtk-demo and do
this, including any user additions?  Surely for such a trivial example of
drawing option 2 should be easy?)

Taking my very simple example of two lines at the midpoints and two
diagonals corner to corner, taking option 2 makes our expose handler:

gboolean exposeME(GtkWidget *da, GdkEventExpose *event, gpointer *nil)
{
 int w = da->allocation.width;
 int h = da->allocation.height;
 GdkGC *gc = da->style->fg_gc[GTK_WIDGET_STATE(widget)]

 if (event->width == w && event->height = h)
 { // draw entire area
   gdk_draw_line(da->window, gc, w/2, 0, w/2, h);  // vertical
   gdk_draw_line(da->window, gc, 0, h/2, w, h/2);  // horizontal
   gdk_draw_line(da->window, gc, 0, 0, w, h);  // diagonal
   gdk_draw_line(da->window, gc, 0, h, w, 0);  // diagonal
 }
 else
 { // only a partial invalidation
   // figure out what drawing commands to issue according
   // to event->x, event->y, event->width, and event->height
   // (for every combination possibility)
   // not so hard for our mid-point lines, but for the diagonals?
   // INSANE!

   // don't forget to include any user additions
 }
 return TRUE;
}

This solution will cost us:
  1) programming time to manage all possibilities and debug, with no real
guarantee that it will work everywhere all the time.
  2) extra CPU usage to make all computations to determine what should be
redrawn.
  3) extra CPU usage to re-draw what was already once drawn.

(And in the case where the entire drawing area is obscured and re-exposed,
we have to draw the whole thing all over again!)

And you're saying that, for some reason I still don't quite understand,
the above is proper GTK+ programming while the following is not?:

gboolean exposeME(GtkWidget *da, GdkEventExpose *event, gpointer *nil)
{
 GdkGC *gc = da->style->fg_gc[GTK_WIDGET_STATE(widget)]

 gdk_draw_drawable(da->window, gc, pmap,  // pmap = our own bg pixmap
   event->area.x, event->area.y,
   event->area.width, event->area.height);
 return TRUE;
}

Oh yeah, and when taking this option we have covered all possibilities
100% of the time with 100% accuracy and 100% efficiency.  Really?  This
isn't the preferred solution?

> If the third option is how GTK+ handles this scenario (more kudos...),
> then the expose handler would look something like?:

no, GTK discards the bg pixmaps between exposes. they exist primarily to
improve the visual appearance of the GUI (by avoid tearing and other
artifacts of the drawing process).

... and is also used to reduce screen flicker, it is not necessarily
intended to make drawing as efficient as possible (as evidenced by its
throwing away the buffer pixmap).

I will restate my general rule:

  1) Do no drawing in the expose handler, at all, ever.
  2) Managing your own background pixmaps will make your application as
efficient as possible, with very little overhead cost (pixmaps are
cheap).

Corollary: Any solution whereby drawing is managed in the expose handler
itself will reduce its efficiency, by definition.

Paul, you started this thread by stating that my proposed paradigm was
opposite to GTK+ programming and that my statement re: the power gained
was simply false.  But in challenging me to better state my case, you have
succeeded in convincing me even more that this paradigm is, in the real
world, the most efficient method going, and that it is patently not
opposite to GTK+ design intent.

thanks,

richard

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

GDK_POINTER_MOTION_HINT_MASK has no effect

[Richard Boaz]

Stewart,

Yes, all philosophies must ultimately collapse to an actual workable frame
at the end of the day.  Sorry for any confusion caused.  In an attempt to
clear this up (and hopefully not make more), you will find below a
complete workable program that does nothing, really, except to
demonstrate:

  1) programmatically generated RGB buffers converted to pixmap for display
  2) bg pixmaps used as the main background layer
  3) temporary bg pixmaps used to display layers of other drawing info
  4) copying parts of bg pixmaps to another bg pixmap
  5) swapping multiple background pixmaps for display (via the expose
handler) according to a deterministic display state
  6) a pixel to user coordinate and conversion system (very handy)
  7) dragging with mouse-down and mouse-up, with effect
  8) mouse leaving and entering drawing area, with effect
  9) etc...

Copy to drawingSample.c and it will compile "out of the box" using:

sh>  gcc `pkg-config --cflags --libs gtk+2.0` drawSample.c -o drawSample

User functions:

  1) startup - display program-generated RGB buffer
  2) drag/mouse-UP - draw dashed lines as cross hairs at mouse point
  3) drag/mouse-DOWN - draw dashed lines - display user-defined bounding box
  4) mouse-UP/post-Drag - draw solid lines - display bounding box
  5) drawing area leave/enter - display an interesting effect, before and
after bounding box definitions
  6) mouse-CLICK/no-Drag - start over
  7) resize window - start over

As Paul and John have made clear, one issue in deciding how to effectuate
all this rests very much on the size of your background pixmaps (among
other important points).  My problem entails many data points that all map
to a single displayable pixmap, i.e., my bg pixmaps are not very big, so
they're cheap.  Employing this method for large pixmaps on display could
be costly memory-wise.

As Paul also pointed out, pixmaps are server-side objects.  When they are
not large, and the distance between the client and the server is
relatively close, this is not such an issue for me.  However, one way that
the attached program could be brought more "up-to-date" (and work
everywhere) would be to convert all drawing commands to cairo routines,
thus using a drawing canvas that is client-side, only converting to a
pixmap at the last possible moment (or wherever it would make the most
sense).

As I said, hope this helps.  If there is anything confusing, please ask. 
Also, I program from the bottom of the file to the top, start at the
bottom and work your way backwards when reading it the first time.

cheers,

richard

=== BEGIN drawingSample.c ===

#include 
#include 
#include 
#include 

// defines and structures we need
enum {
 MOUSEIN,
 MOUSEOUT,
 TTLPMAPS
};

#define MAX_PIXEL_VALUE 255

typedef struct {
 gint startX, startY, endX, endY;
 gboolean mouseDown;
 gboolean mouseIn;
} MouseState;

typedef struct {
double user_xmin, user_xmax;
float  user_ymin, user_ymax;
float  user_xdif, user_ydif;
intpix_xmin, pix_xmax;
intpix_ymin, pix_ymax;
intpix_ydif, pix_xdif;
} graph;

typedef struct {
 guchar R, G, B;
} myColorStruct;

// some globals
GdkPixmap*DAdisplay, *pmap[TTLPMAPS];
GdkGC*gcSolid, *gcDash;
int CG[6][3] =   // color spectrum
 {{255, 0, 255},  // R = 255->0
  {0, 0, 255},  // G = 0->255
  {0, 255, 255},  // B = 255->0
  {0, 255, 0},  // R = 0->255
  {255, 255, 0},  // G = 255->0
  {240, 240, 240}}; // 0%

myColorStruct * colorP(float prob)
{   // probability to color conversion routine
//  return the color to be associated with the given input of probability:
//  each probability falls into a colour range as follows:
//  0 - 1%:   240,240,240 - 255,000,255 (grey (background) to purple)
//  1 - 6%:   255,000,255 - 000,000,255 (purple to blue)
//  6 - 12%:  000,000,255 - 000,255,255 (blue to cyan)
//  12 - 18%: 000,255,255 - 000,255,000 (cyan to green)
//  18 - 24%: 000,255,000 - 255,255,000 (green to yellow)
//  24 - 30%: 255,255,000 - 255,000,000 (yellow to red)
//
 int  probI = prob, cg;
 static myColorStruct probColor;

 if (prob < 1.f)
 {
  probColor.R = 240 - prob*27.;  // R = 213 - 240, 1% - 0%
  probColor.G = 240 - prob*240.;  // G =   0 - 240, 1% - 0%
  probColor.B = 240 + prob*15.;  // B = 255 - 240, 1% - 0%
  return &probColor;
 }

 cg = probI/6;
 if (cg>4) // normalize all probs > 30...
 {
  cg = 4;
  prob = 30.f;
 }

 probColor.R = CG[cg][0]; probColor.G = CG[cg][1]; probColor.B = CG[cg][2];

 switch(cg)
 {
  case 0:
   probColor.R = 255 - (prob*(MAX_PIXEL_VALUE/6.)); // R=255->0
  break; // 1% - 6%
  case 1:
   probColor.G = (prob-6.)*(MAX_PIXEL_VALUE/6.);  // G=0->255
  break; // 6% - 12%
  case 2:
   probColor.B = 255 - ((prob-12.)*(MAX_PIXEL_VALUE/6.)); // B=255->0
  break; // 12% - 18%
  case 3:
   probColor.R = (prob-18.)*(MAX_PIXEL_VALUE/6.);  // R=0->255
  break; // 18% - 24%
  case 4:
   probColor.G = 255 - ((prob-24.)*(MAX_PIXEL_VALUE/6.)); /

drawingSample.c - addendum

[Richard Boaz]

To be complete:

  1) the configMe() and exposeMe() routines are missing 'return TRUE;'
  2) main() is missing 'return 0;'

though no ill-effects occur without them, in this case, anyway.

richard

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

Re: Compilation of gtkmain.c file

[Richard Boaz]

Your problem description indicates very strongly that this is perhaps an
initial foray into GUI programming.  Before jumping into the deep-end of
event-driven GUI interfaces, there is one very important design
consideration of which you should be aware.

GUI design and programming basically comes down to this:

1.  Once you decide to make any program GUI-enabled, you must shift your
understanding as to the hierarchies of priorities.  That is, in GUI-land,
the end-user is king.  If you do not design and program based upon this
single assumption, your program will probably not work very well, and
thus, not be used very much.

(Nobody but nobody gets lucky in creating a successful user interface (and
resulting experience) while not accepting this absolute fact of reality;
if the point of the program is not the end-user, then the end-user won't
use the program.)  (Think EGO, and it all becomes clear.)

(The one exception I might consider to this rule is where you, yourself,
are the only end-user you are programming for, but how many programs does
this constitute in the world?)

So, while you think that the gtk main loop "hangs", it is actually
following #1 above: listening to all the various input channels (it has
been configured to listen to, and more) and responding accordingly when
anything is received.  These input channels mostly relate to human
input/actions, but not necessarily.

In your case, your simulator must become a background task to the GUI
front-end; while it is the "point" of your program, it isn't as far as the
mainloop is concerned.  You do this by starting the simulator as a
separate thread at program startup (i.e., in the background), and then
enter the main loop (i.e., in the foreground), waiting for activity.

Once the simulator has done something and requires a result to be
displayed (i.e., sent to the end-user), use the g_idle_add() function from
within the simulator.  This will insert an event into the main loop and
will have the function you provided to g_idle_add() be executed.  That is,
by using g_idle_add(), you create your own input channel to the main loop,
originating from your background thread, the simulator.

In other words, your program has two distinct aspects and priorities, your
background thread responsible for making data, and your foreground thread
(the mainloop) responsible for interactions with the human and drawing to
the screen.

The point of all this is: the mainloop thread is now the boss, not your
simulator.  Trying to turn this upside down (and modifying the main loop
code directly to force it) will cause you great struggle and strife, most
likely resulting in much hair loss, cursing, all coupled with a very low
likelihood of success.

As well as the mainloop documentation already provided, read up on threads
(GLIB), g_idle_add(), as well as the many previous posts on this subject.

have fun,

richard


On Jan 7, 2008 12:49 AM, Saravana Kumar <[EMAIL PROTECTED]> wrote:
> I am trying to develop a GUI for using it with Verilog Simulator.
>
> Verilog Simulator will invoke this main function in my application code and
> which in turn will call gtk_main function.
>
> Whenever it reaches gtk_main, the simulator hangs forever till I do a
> key/button press. This should not happen since verilog simulator should run
> independent of this main function call. So I thought of modifying gtk_main
> function little bit to avoid zero delay loop(which is currently
happening in
> while statement inside gtk_main function and so the simulator hangs).

There are more reasonable options at your disposal as yours is not an
uncommon need.

I believe giving a good thorough reading to this document in the
documentation will help you understand what your options are:

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

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

Re: Does gtk have issues with STL?

[richard boaz]

a nice discussion (with examples) of all this here:

http://irrepupavel.com/documents/gtk/gtk_threads.html

and, g_idle_add() is indeed thread safe.  it was written that way, on
purpose.  there's really no mystery to a function being thread-safe or not,
either it was written intended to be, or it wasn't.  gtk generally wasn't,
so it isn't.

not sure why you think that it is accessing data shared by threads.  it does
exactly one thing, take the arguments provided by the caller, and place a
call to the specified function on the main loop queue.  i don't see where it
needs to access any common memory.  (could easily have a look at the
function itself, i suppose.)

and, whether you gain an improvement in performance by removing your mutex
calls, that depends on how much multiple calls to g_idle_add() is actually
colliding.  if they never collide, you won't notice any improvement.  if you
call g_idle_add() 100X/second, you will definitely see an improvement.  best
way to answer this is run your own benchmarks and assess yourself, there's
really no other way to tell.

cheers,

richard

On Feb 12, 2008 10:19 PM, Vallone, Anthony <[EMAIL PROTECTED]> wrote:

>
> > You do not need to call gdk_thread_init()
> > if you are only invoking GDK/GTK+ functions by message passing via
> > g_idle_add() (that is, if you are not calling
> gdk_threads_enter()/leave()).
>
> That's interesting.  g_idle_add() is thread safe without telling it to
> use mutex locking? Based on the docs, I've always called g_thread_init
> assuming I had to.  This may have a complicated answer, but how does it
> safely manage being called by multiple threads given that it is probably
> accessing data shared by the threads?
>
> Also, will I get any performance improvement if I remove it?
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

problem with callback

[Richard Boaz]

you have gotten your panties into a serious twist.

start over:

when wanting to receive key press events in a drawing area, you must do
all of the following:

1. set up the drawing area to receive key press and/or release events.
2. set up the drawing area to receive enter and leave notify events.
3. when receiving an enter notify event, you must grab focus of the
drawing area and hold it until you receive the leave notify event, and
then let it go!

so, at creation of the drawing area:

// connect the signals, at least:
g_signal_connect (da, "key_press_event", G_CALLBACK (keyEvent), NULL);
g_signal_connect (da, "key_release_event", G_CALLBACK (keyEvent), NULL);
g_signal_connect (da, "enter_notify_event", G_CALLBACK (grabFocus), NULL);
g_signal_connect (da, "leave_notify_event", G_CALLBACK (grabFocus), NULL);

// set up the events to be received by the drawing area, at least:
gtk_widget_set_events (da, gtk_widget_get_events (da)
| GDK_LEAVE_NOTIFY_MASK
| GDK_ENTER_NOTIFY_MASK
| GDK_KEY_PRESS_MASK
| GDK_KEY_RELEASE_MASK);

// define you grabFocus() callback
gboolean grabFocus(GtkWidget *widget, GdkEvent *event, gpointer nil)
{ // we must grab the focus when mouse enters to receive key events
  switch(event->type)
  {
case GDK_ENTER_NOTIFY:
  gtk_grab_add(GTK_WIDGET (widget));
break;
case GDK_LEAVE_NOTIFY:
  gtk_grab_remove(GTK_WIDGET (widget));
break;
default:
break;
}
  return TRUE;
}

do it like this and when the mouse is inside the drawing are, the drawing
are will receive all keyboard events.  when the mouse is outside the
drawing area, the entry area assigned the current focus will receive the
keyboard events.  clicking inside an entry area will always assign focus
to that entry area.

to answer your other question, g_signal_connect() returns the signal
handler id you are looking for.  save it when creating the signal callback
and blocking and unblocking is easily done.

richard

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

Re: Setting up GTK+ on Windows using Mingw

[Richard Boaz]

 Well, it is kinda assumed that people interested in developing
 GTK+-using software have a broad understanding of concepts like
 pkg-config, make, shell commands, environment variables PATH and
 PKG_CONFIG_PATH etc.

 For people who really don't have a clue about stuff like that, a MinGW
 and MSYS based approach with command-line tools is never going to work
 anyway. They want some kind of IDE. Eventually there will hopefully be
 something one can plug into Visual Studio.


what is the most common method that people learn in the real world?  in my
experience it results from being forced to have to do something.  so they
go out and find the resources necessary to do two things at the same time:
1) learn how to do it, and 2) get it done.

to suggest that anyone who hasn't yet learned how to set up GTK+ on unix
isn't the kind of person who deserves to try to learn how to do it on
windows is patently absurd.

(take the simple case of the windows developer sans unix experience who
hasn't had to bother with all the idiotic intricacies of compilation and
linking requirements in the precious unix world.  are you suggesting that
they should do a rather long stint of development in unix before
attempting to install and use GTK+ on windows?  shame, it strikes me that
you're going to miss out on winnning over a lot of people to use GTK+ on
windows.  what's the point of GTK+ on windows again?)

and yet, the question is answered on this list, while very clearly noted
that the download page wouldn't be updated to provide a simple answer to a
simple question allowing many more people to learn how to do something
useful and beneficial for everyone involved.

it's one of the drawbacks of open-source: no one can be held responsible
for a bad attitude created from a position of power; not a little unlike
the same attitude created from a position of monopoly.

i've said it before (many years ago now) and i'll say it again: providing
a product without good documentation that will allow new users to both
learn how to use it and get the job done at the same time is a product
that has yet to even begin to reach it's true potential.

ridiculous,

richard

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

Re: Setting up GTK+ on Windows using Mingw

[Richard Boaz]

On Wed, 2008-05-14 at 14:04 +0200, Richard Boaz wrote:
>> i've said it before (many years ago now) and i'll say it again: providing
>> a product without good documentation that will allow new users to both
>> learn how to use it and get the job done at the same time is a product
>> that has yet to even begin to reach it's true potential.

>for some reason, neither my table saw or router came with such
>instructions. the power tool companies seem to have given up on reaching
>their true potential, i guess. its odd how they just expect users to
>learn how to use their equipment somewhere else.


yes, i suppose i could adopt this policy for my software tool and user
base (seismologists).  but then, they just wouldn't care, they just
wouldn't use it, a useful tool would just be wasted, and i'd just be out
of a job.

i wonder how far ikea would have gotten in the world had they adopted this
policy early on.

r-

p.s. i find it rather difficult to swallow that if you bought a tool that
needed to be assembled and it came without assembly instructions, leaving
you with nothing to use, you wouldn't take it back, annoyed all along the
way.

and to be clear, i am very much referring here to *assembling* the tool
that is GTK+; i find the user manual to be (mostly) superb, it is my good
friend.

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

Re: bug(s) in all-in-one bundle?

[Richard Boaz]

>> Shouldn't the instructions include such a thing?

> What instructions? ;)


and we programmers wonder why we have such a poor reputation re:
documentation of our work.

:(

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

Re: Alt+Button click and events

[richard boaz]

not sure what's could be going wrong since you didn't supply any code,
but...

first, see the accelerator documentation:

http://library.gnome.org/devel/gtk/stable/gtk-Keyboard-Accelerators.html#gtk-accelerator-set-default-mod-mask

and to "see" if the ALT key is pressed, in your mouse callback:

gboolean mouse(GtkWidget *widget, GdkEventButton *event, gpointer nil)
{
static guintmodifiers = gtk_accelerator_get_default_mod_mask();
gboolean  ALTkeyActive;

ALTkeyActive = ((event->state & modifiers) == GDK_MOD1_MASK) ? TRUE :
FALSE;
switch (ALTkeyActive)
{
case TRUE:   // do something when pressed
break;
case FALSE:  // do something when not pressed
break;
}
}

cheers,

richard

On Wed, Jul 9, 2008 at 10:32 AM, Toralf Lund <[EMAIL PROTECTED]> wrote:

> I have an odd feeling that this is a stupid question because I'm
> overlooking something very obvious, but does Alt+Mouse button click have any
> special meaning in Gtk?
>
> What I mean to say is, I have an application where I draw to a drawing area
> widget, and also handle various events for it "by hand" via the
> button-press-event and button-release-event signal, among others. This all
> works rather fine, but if the Alt button is pressed, my event handlers
> doesn't seem to "see" the button presses. Is there any obvious reason for
> this?
>
> - Toralf
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: load a gtkimage from Bytes string

[richard boaz]

if you mean an image that is contained (in some format) in memory that you
want to render to the screen, then you need to first convert this data to an
array of RGB values for each pixel, and then call:

gdk_draw_rgb_image()

with all the appropriate parameters.  fill the array properly and get the
stride right or you're doomed.

r-

On Wed, Jul 16, 2008 at 5:15 PM, fred <[EMAIL PROTECTED]> wrote:

> douwe vos a écrit :
>
>> http://library.gnome.org/devel/gtk/stable/GtkImage.html
>>
>> says:
>>
>>
>> The GtkImage widget displays an image. Various kinds of object can be
>> displayed as an image; most typically, you would load a GdkPixbuf ("pixel
>> buffer") from a file, and then display that. There's a convenience function
>> to do this, gtk_image_new_from_file(),
>> used as follows:  GtkWidget *image;
>>  image = gtk_image_new_from_file ("myfile.png");
>>
>> If the file isn't loaded successfully, the image will contain a
>> "broken image" icon similar to that used in many web browsers.
>> If you want to handle errors in loading the file yourself, for example by
>> displaying an error message, then load the image with
>> gdk_pixbuf_new_from_file(), then create the GtkImage with
>> gtk_image_new_from_pixbuf(). But maybe you already tried this ?
>>
>>
>>
>>
>> - Original Message 
>> From: fred <[EMAIL PROTECTED]>
>> To: gtk-list@gnome.org
>> Sent: Wednesday, July 16, 2008 4:45:11 PM
>> Subject: load a gtkimage from Bytes string
>>
>> Hi all,
>>
>> Is there a way to load a gtkimage from bytes string ? I tried with
>> GdkPixbufLoader but no luck.
>>
>> Regards,
>>
>> Fred.
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>
>>
>>
>>
>>
>>
> Yes, I already know that, but thanks.
>
> I want to load from bytes strings (0x85 ...) not from file or something
> like Pixel + Mask Strings.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

gtk_print

[Richard Boaz]

Hi,

The documentation for gtk_print states that once the user is finished with
gtk_print_operation_run(), the "::draw-page" signal will be emitted. This
signal is then to be caught by the program, using Cairo to render to the
GtkPrintContext.

Except that I have a Postscript file that needs to be sent to the printer.

Does this mean that I cannot use the GtkPrint functionality?;
specifically, the dialog showing the available printers and allowing the
user to select one of them to send the Postscript file to?

Thanks in advance for any insight...

richard

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

gtk_print

[Richard Boaz]

On Tue, Aug 19, 2008 at 3:41 PM, Chris Vine <[EMAIL PROTECTED]>
wrote:

On Tue, 19 Aug 2008 10:47:54 +0200 (CEST)
"Richard Boaz" <[EMAIL PROTECTED]> wrote:

> Hi,
>
> The documentation for gtk_print states that once the user is finished
> with gtk_print_operation_run(), the "::draw-page" signal will be
> emitted. This signal is then to be caught by the program, using Cairo
> to render to the GtkPrintContext.
>
> Except that I have a Postscript file that needs to be sent to the
> printer.
>
> Does this mean that I cannot use the GtkPrint functionality?;
> specifically, the dialog showing the available printers and allowing
> the user to select one of them to send the Postscript file to?

or if you are using Unix you could use the
GtkPrintJob/GtkPrintUnixDialog interface to send the postscript file
directly to the underlying print system (cups or lpr) - see
gtk_print_job_set_source_file().

Unfortunately, this needs to work on W32 platform as well, so the
UNIX-specific solution won't work for me.

You can draw the postscript file to the cairo surface in the ordinary
way using GtkPrintOperation,

I'm confused.  The example for the draw-page signal renders to the cairo
print context using cairo commands.  How do I take a postscript file and
"draw" it to this cairo print context (in the ordinary way)?

I've looked at the GTK+ and Cairo documentation and see only functions
that are uni-directional, i.e., Cairo -> Postscript.  Are there functions
that go the other direction, PS -> Cairo?

Or am I missing something completely obvious?

thanks,

richard

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

gtk_print

[Richard Boaz]

On Thu, Aug 21, 2008 at 11:44 PM, Chris Vine <[EMAIL PROTECTED]>
wrote:
No, you are not missing anything obvious.  Doing it "in the ordinary
way" means I think writing your own postscript interpreter for
writing the pages to the cairo surface via pango.

It will be hard work, but looking at the evince and poppler source may
give you some ideas.  Poppler would probably lighten the load if you
were to convert the file to PDF format.

You do not explain why you want to print a postscript file under
windows in the first place, but unless you have a special need I
strongly suspect this approach will not be worth the effort. I do not
use windows, but I believe there are some command-line tools available
for printing postscript (via ghostscript, which has been ported to
windows, for non-postscript printers) which might be suitable for your
purposes.

Chris

The reason I have a PS file in the first place is historical.  Back when I
originally wrote my plotting program, it was v2.4 of GTK+, thus, no Cairo,
and no GtkPrint.

To print, then, I plot my image internally, convert to a pixbuf, read the
pixel data and output this to a postscript file, i.e., it's an image I'm
plotting, with a little bit of text thrown in.

I realize that with the advent of Cairo and GtkPrint, this solution is
dated.  However, in order to convert to the current standard, I would need
to modify all of my gdk_* drawing calls to Cairo equivalents (and a little
re-architecting), not something I currently have the luxury to do.

What I was wanting to do, then, was to take advantage of the new GtkPrint
dialog (specifically, that it knows about all printers, allowing the user
to select one) and send this internally generated PS file directly to the
selected printer.

On a different note, a question:  One trick I employ when creating the PS
file is to plot my image in memory twice as large as the screen, save this
to the PS file, and then let the printer re-scale to fit the page.  Since
printers (typically) have a better resolution than a screen, this results
in a plot that is very sharp, (better than what the user sees on the
screen even).

When, one day, I do change all my gdk_* drawing calls to Cairo, will I be
able to effectuate this extra sharpness as well?  Or must the Cairo calls
in my GtkPrint callback conform to the paper size?  Or, is this not a
concern, i.e., the resulting printed image using Cairo would be as sharp
as possible given that Cairo takes into account the available dpi of the
selected printer?

Thanks for the feedback.  At this point I will have to recommend to my
users that a 3rd party program be used to send the PS file I create to a
printer.  (There is a nice free-ware version of this functionality
available, btw.)  Essentially making them have to engage in a 2-step
process to get a print out of my program instead of through a single step.

richard

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

Re: gtk_print

[Richard Boaz]

On Sat, Aug 23, 2008 at 2:32 AM, Paul Davis <[EMAIL PROTECTED]>
wrote:

 On Sat, 2008-08-23 at 00:28 +0100, Chris Vine wrote:
 > On Fri, 22 Aug 2008 19:04:19 -0400
 > Paul Davis <[EMAIL PROTECTED]> wrote:
 > > On Fri, 2008-08-22 at 14:12 +0100, Chris Vine wrote:
 > > > On Fri, 22 Aug 2008 13:40:20 +0200 (CEST)
 > > > "Richard Boaz" <[EMAIL PROTECTED]> wrote:
 > > > [snip]
 > >
 > >  [ ... snip snip snip ... ]
 > >
 > > this sounds like a disaster of an API.
 > >
 > > most other GTK/GDK APIs that involve things that ultimately come down
 > > to pixels seem to have variants that allow you to provide
 > > unstructured data and structured data, sometimes in multiple formats.
 > > there is often a way to get data directly from a file too.
 > >
 > > a print API that hides all the hard work of printer discovery and
 > > configuration but then prevents you from pointing it at a file to get
 > > the data to be printed seems fundamentally broken.
 >
 > On the issue of printing a postscript file under windows, I don't think
 > GTK+ should be expected to provide its own postscript interpreter, just
 > because windows does not natively support printing postscript in the
 > way that unix-like OSes do.

 aha. a very fair point, and one that is highly relevant to the OP's
 question. Richard, i think you need to think carefully about how you
 would print this file *outside* of GTK. if selecting a printer and
 identifying the file to be sent there is not enough to get the job done,
 its a bit hard to expect GTK to go the extra mile and work this way.

=

Hi again (sorry to be coming back to this so much later, was away...),

I guess what I'm really looking for is a separation between the two
distinct functionalities currently provided by GtkPrint.  As it is, it
provides two distinct features:

1) identification (and selection) of known/found printers, and
2) issuing commands for selected printer, commands being currently limited
to the Cairo family.

In my case, I have a *file* that I want to send to the printer.  If the
printer is PS-aware, then sending the file is enough, interpretation
happens at the printer (no?).  So, I need the functionality described by
1), but not the functionality described by 2).  Except that on windows
they are, seemingly, inseparable.

As stated, this is only a problem in the windows platform since
GtkPrintUnixDialog in conjunction with GtkPrintJob will send a manually
generated PS-file to the selected printer.

I guess I don't understand why this is available only on Unix?

For my 2-step solution, I have found a program (PrintFile) that will send
a PS file to a printer on Windows.  What exactly prevents the
functionality provided by this program from being imported into Gtk for
windows?; effectively providing the non-portable Unix print functionality.
 The only thing it does is send a PS file to the printer disabling the
windows driver from interpreting it as text, much like GtkPrintUnixDialog
and friends.

I realize that GtkPrint is a recent addition to the library and that first
editions do not necessarily provide all possible desired functionality; I
don't have a problem with this, evolution is what it is.  But I do wonder
if this gap (as perceived by me) will be addressed in some future release.

Or is windows so special that this isn't really possible?  ;)

cheers,

richard

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

gdk_visual_get_best_depth() - Usage Question

[Richard Boaz]

I have the following code (snippet):

==
depth = gdk_visual_get_best_depth();
pmap=gdk_pixmap_new(NULL, 100, 100, depth);

ctxt = gdk_gc_new(pmap);
gdk_gc_set_rgb_fg_color (ctxt, fg);
==

I have recently upgraded my OS to Ubuntu and after the upgrade, this code
caused the program to fail to start and produced the following output
(this worked without problem under FC4):

===
(pqlx:13657): Gdk-WARNING **: gdk_gc_set_rgb_fg_color() and
gdk_gc_set_rgb_bg_color() can only be used on GC's with a colormap. A GC
will have a colormap if it is created for a drawable with a colormap, or
if a colormap has been set explicitly with gdk_gc_set_colormap.
===

The Xorg.log contains the following re: screen depth:

==
(II) RADEON(0): Creating default Display subsection in Screen section
"Default Screen" for depth/fbbpp 24/32
(==) RADEON(0): Depth 24, (==) framebuffer bpp 32
(II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
(==) RADEON(0): Default visual is TrueColor
==

And when I modify the above code to hardcode the depth to 24 bits, the
problem is resolved.

So my question is, generally: where does the origin of this problem reside
exactly?  with Ubuntu, Xorg setup, gdk, my code, other?

Specifically: is it incorrect to assume that gdk_visual_get_best_depth()
will return the depth I can specify when creating a pixmap?

In the meantime, I have coded that 24 is the maximum depth I can specify
when creating a pixmap, and this works, but I'm not convinced it's
necessarily the best solution since I don't understand why the problem
happens in the first place.

Any and all insights appreciated.

richard

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

Re: Question about Threads y gtk+

[Richard Boaz]

Inexplicably (read: I don't know), there is no glib equivalent for the
function pthread_kill().

Not sure why, perhaps the glib gurus could elaborate on why it is not
possible to externally kill a thread a la pthread_kill()?

Or is there some equivalent I have not found?

Assuming there is no glib thread kill function, you've got to get creative
here: let the thread complete and then ignore its results, or,
periodically read a queue that the main thread writes to telling the
thread it needs to quit, or, periodically read a global flag, etc.

richard

On Fri, Oct 3, 2008 at 1:56 AM, Moises <[EMAIL PROTECTED]> wrote:

Question about Threads y gtk+

To end a thread, you have to leave the function of the thread with an
exit, return  or calling g_thread_exit.

My question is how can I finish the thread from my main thread?

I try to use g_object_unref, for finish the thread but get me error.




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

Re: Questions about combobox.

[Richard Boaz]

you really are making this way more complicated than necessary, i think.

all your problems will be solved if you:

   1. simply make the title you want to be seen to be the first item in
the list.
   2. set this item to be the item on display any time you want to force
the user to make a new selection.
   3. have all your code understand that the first item is not an actual
valid selection, i.e., all references to combo box list items start
from a reference of 1.
   4. error checking can simply take into account that the first item on
the list is not valid and proceed forthwith.

you've never really explained why it is so undesirable to implement it
like this.  this method works, i use it everywhere in my program.

richard

On Mon, Oct 13, 2008 at 1:47 AM, Moises <[EMAIL PROTECTED]> wrote:

programa no generate error if the user does not select an item.

as you can see here. http://kronos2008.blogspot.com/

I need that comobobox show a initial message saying "Select a robot"


As you can see, I select an item of comobox, the reason is that user
know that would select, then I want that appear a initial message
“select a robot"
in comobobox.



 ¡Todo sobre Amor y Sexo!
La guía completa para tu vida en Mujer de Hoy.
http://mx.mujer.yahoo.com/
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list




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

A problem about programming with Gtk+

[Richard Boaz]

what exactly are you trying to do?  cause your program's not gonna do much
as it is, and it's not obvious to me what exactly you're trying to achieve
here.

if it's related to modifying the cursor as a result of user interaction,
you should try another model.

that is, set up a different thread to do the background work, not change
the cursor.  and you instantiate this thread from within the callback, not
as part of your main routine.

so, the sequence of events might be:

in your callback:
1) modify the cursor as necessary
2) create a thread to do the background work
3) quit

in your thread:
1) do your work
2) call g_idle_add() invoking a function that understands you are
returning from your background thread, i.e., render the results back to
the user

basic guidelines to follow:
1) have your callback do as little work as possible.
2) do any work requiring time in a separate thread, returning to the
mainloop via g_idle_add()

following this model, you will gain the following:
1) user interface will always be responsive since mainloop() will remain
free to process events
2) cursor will change in a timely fashion
3) multiple cpu's will be utilized to their best advantage

if this isn't what you want, then perhaps you could restate your goals?

cheers,

richard

On Sat, Dec 20, 2008 at 11:37 AM, haitao_y...@foxitsoftware.com
 wrote:

As nobody else seems to want to follow up on this, I'll try to...
(Please, no *personal* replies to me. Follow up to the list.)


> > Maybe there is a reason that can explain this phenomenon. You can
launch a
> > thread with g_idle_add or g_time_out_add,
>

Sorry, either you are misunderstanding seriously, or just using the
term "thread" in a way that nobody else does. g_idle_add() and
g_timeout_add() do *not* "launch" any threads. The callback functions
passed as parameters to these functions run in the same thread that
runs the main loop in question. (That might of course be a different
thread than the one where you called g_idle_add() or g_timeout_add(),
but anyway, no new thread creation is involved.)


> > nevertheless, this new thread can
> > not run with your main thread simultaneously.
>

"can not" or "should not"? threads that can not run simultaneously
would be rather pointless, I think;) Anyway,  if your following text
is based on the wrong belief that g_idle_add() or g_timeout_add()
create new threads, it is pointless to try to understand what you try
to say.

--tml

===

Thanks for your reply. I think I make a mistake about the concept.
Following is my summary:
1) g_idle_add() or g_timeout_add() is not related to "thread", but
related to "event-loop".
2) When you call the sleep() function in the callback function of
g_idle_add or g_time_add, your whole program will wait;
 When you call the sleep() in other "thread", the whole program will
not wait.
3) Would the callback function be called till gtk_main() being called?
(you can examine the example below )


#include 

static gpointer cursor_change(gpointer data_pass)//2
//static gboolean cursor_change(gpointer data_pass)//1
{
   //1 ---
   /*fprintf(stderr, "In cursor_change\n");
   sleep(10);
   return TRUE;*/

   //2 ---
   gint i=0;

   while(1)
   {
   gdk_threads_enter();
   fprintf(stderr, "thread:%d\n", i++);
   sleep(10);
   gdk_threads_leave();
   }
}

void callback (GtkButton* pbtn, gpointer data)
{
   fprintf(stderr, "In Button Callback\n");
}

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

   gtk_init (&argc, &argv);
   if (!g_thread_supported ())
   {
   g_thread_init(NULL);
   gdk_threads_init();
   }
   //1 ---
   //g_idle_add( cursor_change, NULL);
   //2 ---
   //g_timeout_add(1, cursor_change, NULL);
   //3 ---
   g_thread_create ( cursor_change, NULL, FALSE, NULL);

   //5 ---
   //sleep(100);
   //6
   GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
   GtkWidget *button = gtk_button_new_with_mnemonic ("button");
   g_signal_connect (G_OBJECT (button), "clicked",  G_CALLBACK
(callback), NULL);
   gtk_widget_show (button);
   gtk_container_add (GTK_CONTAINER (window), button);
   gtk_widget_show (window);

   gtk_main ();
   return 0;
}


--
Sincerely,
Alfred Young
R&D, Application Architectures
www.foxitsoftware.com

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




___
gtk-list m

Re: A problem about programming with Gtk+

[Richard Boaz]

Hi,

You're doing a couple of things wrong in the setup:

1) you are not using any gdk() routines in threads, therefore, you do not
need to call gtk_threads_init().  (call all gtk_ and gdk_ routines only
from routines executing as part of the main loop and strange behaviours
are minimized.)

2) you should call g_thread_init() before you call gtk_init().

3) calling g_thread_supported() only tells you whether or not you've
already called g_thread_init(), if you call g_thread_init() only once in
your main routine, calling g_thread_supported() is not necessary.

so rewrite the thread initialisation part of your main() as:

g_thread_init(NULL);
gtk_init (&argc, &argv);

and your dialog will work as it should.

other recommendations:

1) declare your busy cursor static, create it only once, and never destroy
it.
2) make all your widgets and call gtk_widget_show_all(window), i.e., do
not call gtk_widget_show() as you make each widget.

cheers,

richard



Hello all:
Firstly, Thanks Richard for his valuable infomation and thanks all who
reply me.
I still follow the thread "A problem about programming with
Gtk+(gtk-list Digest, Vol 56, Issue 22)". Maybe I unintentionally
changed the subject in my code:)

I followed the step of Richard's guide, everything run well, but I can
not exit from the callback of g_idle_add correctly. Why?

Following is the code:
//gcc -o tbug t_bug3.c `pkg-config --cflags --libs gtk+-2.0`-lgthread-2.0 -g
//
#include 
#include 
#include 
#include 
#include 

GtkWidget *win;
static GtkWidget *xpm_label_box( gchar *xpm_filename,
gchar *label_text )
{
GtkWidget *box;
GtkWidget *label;
GtkWidget *image;

box = gtk_hbox_new (FALSE, 0);
gtk_container_set_border_width (GTK_CONTAINER (box), 2);
image = gtk_image_new_from_file (xpm_filename);
label = gtk_label_new (label_text);
gtk_box_pack_start (GTK_BOX (box), image, FALSE, FALSE, 3);
gtk_box_pack_start (GTK_BOX (box), label, FALSE, FALSE, 3);
gtk_widget_show (image);
gtk_widget_show (label);
return box;
}

static gboolean Result (gpointer data)
{
gint param = (gint)data;
GtkWidget* pDialog = gtk_message_dialog_new(GTK_WINDOW(win),
GTK_DIALOG_MODAL,
GTK_MESSAGE_INFO,
GTK_BUTTONS_OK,
"The thread result: %d ",
param);
gtk_dialog_run(GTK_DIALOG(pDialog));
gtk_widget_destroy(pDialog);
return FALSE;
}


static gpointer cursor_change(gpointer data)
{
//1) do your work
GtkWidget *window = (GtkWidget *) data;
win = window;
int i,j;
for(i=0;i<100;i++)
{
g_print ("Hello again - %s was pressed %d\n", (char *) data, i);
}

//2) call g_idle_add to render the result to user
g_idle_add( Result, (gpointer)i);

return NULL;
}


static void callback( GtkWidget *widget, gpointer data )
{
//1) modify the cursor as necessary
GtkWidget *window = (GtkWidget *) data;
GdkCursor *new_cursor;
new_cursor=gdk_cursor_new(GDK_WATCH);
g_print ("I make it!");
gdk_window_set_cursor(window->window, new_cursor);
gdk_cursor_destroy(new_cursor);

//2) create the thread to do the background work
g_thread_create ( cursor_change, data, TRUE, NULL);

//3) quit
return;
}


int main( int argc, char *argv[] )
{
GtkWidget *window;
GtkWidget *button;
GtkWidget *box;

gtk_init (&argc, &argv);
if (!g_thread_supported ())
{
g_thread_init(NULL);
gdk_threads_init();
}

window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
gtk_window_set_title (GTK_WINDOW (window), "Pixmap'd Buttons!");
g_signal_connect (G_OBJECT (window), "destroy",
G_CALLBACK (gtk_main_quit), NULL);
g_signal_connect (G_OBJECT (window), "delete_event",
G_CALLBACK (gtk_main_quit), NULL);


gtk_container_set_border_width (GTK_CONTAINER (window), 10);

button = gtk_button_new ();
g_signal_connect (G_OBJECT (button), "clicked", G_CALLBACK (callback),
(gpointer) window);

box = xpm_label_box ("info.xpm", "cool button");
gtk_widget_show (box);
gtk_container_add (GTK_CONTAINER (button), box);
gtk_widget_show (button);
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (window);

gtk_main ();
return 0;
}




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

Re: A problem about programming with Gtk+

[Richard Boaz]

that bit of documentation is a bit confusing and definitely misleading. 
what it essentially says is that if you make calls to gtk_ or gdk_ then
the thread calls are required.

but if all calls to gtk_ and gdk_ are executed within routines executing
as part of the main loop, thread calls are not required.

g_idle_add() is guaranteed to be thread-safe without calling
g_thread_init() or gdk_threads_init().

since Result() is executed via g_idle_add(), it is executed under the main
loop.  therefor, no calls to gtk_threads...() are necessary here.

richard


On Sat, Dec 27, 2008 at 3:42 AM, Vyacheslav D.  wrote:

On Tue, 23 Dec 2008 04:42:09 +0300, haitao_y...@foxitsoftware.com
 wrote:

From gnome help:

"Idles, timeouts, and input functions from GLib, such as g_idle_add(),
are executed outside of the main GTK+ lock. So, if you need to call
GTK+ inside of such a callback, you must surround the callback with a
gdk_threads_enter()/gdk_threads_leave() pair or use
gdk_threads_add_idle_full() which does this for you"

Proof link: http://library.gnome.org/devel/gdk/stable/gdk-Threads.html

So i think you should try so:


static gboolean Result (gpointer data)
{
   gint param = (gint)data;
   gdk_threads_enter();

   GtkWidget* pDialog = gtk_message_dialog_new(GTK_WINDOW(win),
   GTK_DIALOG_MODAL,
   GTK_MESSAGE_INFO,
   GTK_BUTTONS_OK,
   "The thread result: %d ",
   param);
   gtk_dialog_run(GTK_DIALOG(pDialog));
   gtk_widget_destroy(pDialog);
   gdk_threads_leave();
   return FALSE;
}

--
Vyacheslav D.



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

Re: Setting background color for a GtkFrame

[Richard Boaz]

hi,

you need to use an event box, GtkFrame does not have its own X window, so
you must make one yourself using GtkEventBox and then modify it, e.g.,
your background color.

discussion and example at:

http://www.pygtk.org/pygtk2tutorial/ch-ContainerWidgets.html

richard

2008/12/30 Harinandan S 

Hi All,

Is it possible to set background color to a GtkFrame? I am using Gtk+
2.12.2 over DirectFB 1.1.1 and there are no window decorations. I am
not able to enable it either. So thought of putting a background color
to a GtkFrame and put the window contents in that.

But I'm not able to set background color. How can I do this?

Regards,
Harinandan S

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




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

Re: how to leave a specific thread?

[richard boaz]

the question should be changed to: how do i tell a thread to kill itself?

glib does not allow for killing a thread from another thread.  this is a bad
idea since killing a thread from another does not allow for the thread being
killed to shutdown any processing it is doing in a graceful manner.  thus
possibly leaving the program in a crap state.

what needs to happen is that the thread that wants to do the killing has to
provide some sort of communication mechanism that is then picked up by the
thread to be killed.  the thread to die then shuts itself down in a graceful
manner.

which mechanism is a matter of choice on the part of the programmer.  a
global variable, for example, or, better yet, usage of GAsyncQueue.

richard


On Sat, Jul 11, 2009 at 11:30 PM, Sergei Steshenko wrote:

>
>
>
> --- On Sat, 7/11/09, frederico schardong  wrote:
>
> > From: frederico schardong 
> > Subject: how to leave a specific thread?
> > To: gtk-list@gnome.org
> > Date: Saturday, July 11, 2009, 12:08 PM
> > I'm using this example of threads..
> >
> > /* Compile me with:
> >  *  gcc -o sample3 sample3.c $(pkg-config --cflags
> > --libs gtk+-2.0 gthread-2.0)
> >  */
> > #include 
> >
> > static gpointer
> > thread_func( gpointer data )
> > {
> > while( TRUE )
> > {
> > usleep( 50 );
> >
> > gdk_threads_enter();
> > g_print("\naa");
> > gdk_threads_leave();
> > }
> >
> > return( NULL );
> > }
> >
> > static gpointer
> > thread_func1( gpointer data )
> > {
> > while( TRUE )
> > {
> > sleep( 1 );
> >
> > gdk_threads_enter();
> > g_print("\nbb");
> > gdk_threads_leave();
> > }
> >
> > return( NULL );
> > }
> >
> > int
> > main( intargc,
> >   char **argv )
> > {
> > GThread   *thread, *th;
> > GError*error = NULL;
> >
> > /* Secure glib */
> > if( ! g_thread_supported() )
> > g_thread_init( NULL );
> >
> > /* Secure gtk */
> > gdk_threads_init();
> >
> > /* Obtain gtk's global lock */
> > gdk_threads_enter();
> >
> > /* Do stuff as usual */
> > gtk_init( &argc, &argv );
> >
> > /* Create new thread */
> > thread = g_thread_create( thread_func, NULL,
> >
> >   FALSE,
> > &error );
> > if( ! thread )
> > {
> > g_print( "Error: %s\n",
> > error->message );
> > return( -1 );
> > }
> >
> > /* Create new thread */
> > th = g_thread_create( thread_func1, NULL,
> >
> >   FALSE,
> > &error );
> > if( ! th )
> > {
> > g_print( "Error: %s\n",
> > error->message );
> > return( -1 );
> > }
> >
> > gtk_main();
> >
> > /* Release gtk's global lock */
> > gdk_threads_leave();
> >
> > return( 0 );
> > }
> >
> >
> > And I must know how I can stop some thread without stop all
> > the
> > others? Just stop one thread, not all
> >
> > --
> > Abraço,
> > Frederico Schardong,
> > SOLIS - O lado livre da tecnologia
> > www.solis.coop.br
>
>
> You can still use global variables, and threads can monitor their value.
>
> Kinda signals.
>
> Or I'm getting it wrong ?
>
> Regards,
>  Sergei.
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Is the guint32 time of GdkEventKey the timestamp?

[richard boaz]

what kind of values to you get when you print out the variable during the
execution of the callback?

does it like like the current time according to the computer clock?  then
yes, otherwise, no.

r-

On Mon, Feb 1, 2010 at 10:58 PM, Teste123 Teste123 wrote:

> Please,
>
> Can anyone help me?
>
> 2010/1/29 Teste123 Teste123 
>
>> Is the guint32 time of GdkEventKey the timestamp of when the event happen?
>>
>> In the documentation (
>> http://library.gnome.org/devel/gdk/stable/gdk-Event-Structures.html#GdkEventKey)
>> I haven't found.
>>
>> Thanks!
>>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to change the height of the top window from a program?

[richard boaz]

i would think about embedding the dialog window you want at the bottom
within the top window itself.  hiding and unhiding then, you can easily
achieve the effect you want.

that is, unless the dialog *must* be its own separate top window.  is this
true?

on the other hand, try using gtk_window_resize() instead, it will work
where gtk_widget_set_size_request() is failing.

richard

On Sat, Mar 27, 2010 at 11:52 AM, Ken Resander  wrote:

> The top window has a menu and a single textview. This window uses all of
> the available area on the screen, but sometimes it has to make room for a
> dialog window that that needs to be just below. When the dialog window is no
> longer needed the top window should expand and reclaim the space at the
> bottom.
>
> I want to do this by reducing and increasing the height of the top window
> by the program, but I cannot make it work.
>
> Setting top window:
> [code]
> ...
>gtk_window_set_title (GTK_WINDOW (window), title );
>gtk_widget_set_size_request (window, wdavail, htsrcwnd ); // request
> works
>gtk_window_move ( (GtkWindow *)window, 0 , 0 );   //  works
> ...
>gtk_widget_show_all (window);
> [/code]
>
> Reducing height of top window:
> [code]
> ...
>   gtk_widget_set_size_request (window, wdavail, reducedheight );  //
> request ignored
> ...
> [/code]
> So, the height of the top window remains as initialised.
>
> I can destroy window by gtk_widget_destroy and then recreate another top
> window with reduced height and then place the dialog window at the bottom.
> However, this is ugly and irritating because the top window destroy and
> immediate recreate are clearly visible.
>
> How can I make the transition a bit smoother?
>
>
> --
>  Get your new Email address!
> 
> Grab the Email name you've always wanted before someone else does!
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to move focus to another window by program?

[richard boaz]

did you try using gtk_window_present()?  i would call it first, then grab
the focus to the proper widget after.

cheers,

richard

p.s. if you've solved it somehow else, i'd be interested to hear how.

On Thu, Apr 1, 2010 at 1:39 PM, Ken Resander  wrote:

> Richard:
>
> Your idea is interesting. Would like to try it, but...
>
> I checked gtk_widget_event ( widget,event ) in the manual which says this
> function should not be used for synthesizing events. It continues: 'instead,
> use gtk_main_do_event() so the event will behave as if it were in the event
> queue'.
>
> However, the manual says this about gtk_main_do_event(): 'While you should
> not call this function directly, you might want to know how exactly events
> are handled'.
>
> Not much joy!
>
> Has anyone successfully used any or both of these functions?
>
> Or, is there some other way to synthesize events?
>
> Ken
>
>
> --- On *Thu, 1/4/10, richard boaz * wrote:
>
>
> From: richard boaz 
>
> Subject: Re: How to move focus to another window by program?
> To: "Ken Resander" 
> Date: Thursday, 1 April, 2010, 4:53 PM
>
>
> you might try this in a different way.
>
> instead of requesting the focus to occur from the top window (to make the
> dialog have focus), send a message (via an event) to the dialog from the top
> window, where the dialog will receive the message and then grab focus onto
> itself.
>
> this way the focus request is happening from inside the dialog itself and
> not from another window.
>
> richard
>
> On Thu, Apr 1, 2010 at 10:36 AM, Ken Resander 
> http://mc/compose?to=kresan...@yahoo.com>
> > wrote:
>
>> Thanks Yeti,
>>
>> I used g_signal_connect_after for the menu activate event for all menu
>> items with actions. It did not make any difference.
>>
>> I can force focus from a dialog to the top window by gtk_window_present
>> ((GtkWindow *)window ), but gtk_window_present ((GtkWindow *)dlg) does not
>> work the other way around.
>>
>> Is there a way to force focus from top window to a dialog by the program?
>> I think there ought to be.
>>
>> Ken
>>
>>
>>
>>
>> --- On *Wed, 31/3/10, David Nečas 
>> http://mc/compose?to=y...@physics.muni.cz>
>> >* wrote:
>>
>>
>> From: David Nečas 
>> http://mc/compose?to=y...@physics.muni.cz>
>> >
>> Subject: Re: How to move focus to another window by program?
>> To: "Ken Resander" 
>> http://mc/compose?to=kresan...@yahoo.com>
>> >
>> Cc: gtk-list@gnome.org <http://mc/compose?to=gtk-l...@gnome.org>
>> Date: Wednesday, 31 March, 2010, 11:51 PM
>>
>>
>> On Wed, Mar 31, 2010 at 08:43:14AM -0700, Ken Resander wrote:
>> > The program has a top window with a menu. The menu is used for functions
>> directly associated with the top window and for functions associated with
>> dialogs that are brought up via the menu. Each dialog has a single textview
>> and the top window menu contains functions that generate and insert text
>> fragments into the textview.
>> >
>> > A dialog gets focus when starting (the title bar has 'active' colour). I
>> then move the caret to the position in the dialog where text is to be
>> inserted and select what to insert from the menu. This causes the focus to
>> move to the top window because the menu is part of it.
>> >
>> > The program writes to the correct place in the dialog by:
>> >
>> > [code]
>> >GtkTextBuffer * buf =  gtk_text_view_get_buffer (textviewwidget) ;
>> >gtk_widget_grab_focus ( textviewwidget ); // want to force focus back
>> to dialog
>> >... // prepare text, indentation,buf-insert-position etc
>> >gtk_text_buffer_insert (buf,...);
>> > [/code]
>> >
>> > but the focus stays in the top window and I don't understand why. The
>> dialog title bar never changes to active colour, not even a hint or flicker.
>> Having or not having gtk_widget_grab_focus does not seem to make any
>> difference.
>>
>> It is probably too early to move the focus, the menu will eat it again.
>> If you connect-after now and it does not help, moving the textview
>> operation to an idle function should help.
>>
>> Yeti
>>
>>
>> --
>>  New Email names for you!
>> <http://sg.rd.yahoo.com/aa/mail/domainchoice/mail/signature/*http://mail.promotions.yahoo.com/newdomains/aa/>
>>  Get the Email name you've a

Re: Question About Hash

[richard boaz]

show your code, without it your comment is an opinion and not likely to get
much of an interesting response.

why?  because there are multiple ways of setting up hash tables, their
contents, and the automatic (or not) destroy functions which should be used.

try again,

richard

On Fri, Apr 9, 2010 at 12:03 PM, Tata  wrote:

> HELLO:
>
>When i destroy a GHashTable by g_hash_table_destroy, i found some memory
> leak. Hash func is g_direct_hash. Key equal func is g_direct_equal. There
> are more than 100,000 record in my GHashTable.
>
>Thanks.
>
> Austin
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Question About Hash

[richard boaz]

try rewriting as:

   - create using g_hash_table_new_full()
   - remove the call to g_hash_table_foreach_remove() (or not, doesn't
   matter)

if you look at the documentation for g_hash_table_foreach_remove() you might
notice that the element will only be removed if the function called returns
true.  except you provide NULL for the function which i have serious doubts
returns TRUE.

look at it another way: why are you expecting the elements you insert will
be deleted when you make no accomodations for such in your code and the
documentation clearly states that you are responsible for (somehow)
arranging for the data to be freed?

richard

On Fri, Apr 9, 2010 at 12:22 PM, Tata  wrote:

> Thank you, Some code like this:
>
> func1()
> {
> ..
> table_3= g_hash_table_new(g_direct_hash, g_direct_equal);
> ..
> }
> func2()
> {
> ...
> g_hash_table_insert(table_3, GUINT_TO_POINTER(key_3), value);
> 
> }
> func3()
> {
> ...
> g_hash_table_foreach_remove(table_3, NULL, NULL);
> g_hash_table_destroy(table_3);
> ...
> }
>
>
>
> 2010/4/9 richard boaz 
>
> show your code, without it your comment is an opinion and not likely to get
>> much of an interesting response.
>>
>> why?  because there are multiple ways of setting up hash tables, their
>> contents, and the automatic (or not) destroy functions which should be used.
>>
>> try again,
>>
>> richard
>>
>> On Fri, Apr 9, 2010 at 12:03 PM, Tata  wrote:
>>
>>> HELLO:
>>>
>>>When i destroy a GHashTable by g_hash_table_destroy, i found some
>>> memory leak. Hash func is g_direct_hash. Key equal func is g_direct_equal.
>>> There are more than 100,000 record in my GHashTable.
>>>
>>>Thanks.
>>>
>>> Austin
>>>
>>> ___
>>> gtk-list mailing list
>>> gtk-list@gnome.org
>>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>>
>>>
>>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: how can I let application emit "configure event" signal?

[richard boaz]

the easiest way is to force it, by calling the
function gtk_widget_queue_resize() on the widget you want the configure
event to be called on.

richard

On Fri, Apr 16, 2010 at 4:10 PM, Randy  wrote:

> Hi list,
> I know when I change the widget's size,it will emit the
> "configure_event",so the function "gtk_widget_set_size_request()"could
> work.
> But I'd like to know is there anything else could do this too?
> I mean if GTK could send messages to a thread's message queue like in
> Windows programming?
> And if so,is there any "message" could let application emit the signal
> like "configure_event"?
> Thanks a lot!
>
> Best regards,
> randy
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to bring up tooltip text for certain words in a GTK textview?

[richard boaz]

i have had to do this and solved it just like you have proposed.  if you do
go with this method, some heads-ups: the "extra" issues one must handle when
doing this are:

   - unless gtk is now providing direct access to tooltip style pop-ups, you
   must create it yourself
   - meaning that you must create and manage your own borderless top-level
   window
   - whose location must be explicitly specified to be placed onto the
   screen
   - calculation of the window location coordinates must access the
   root-window where to the tooltip is to be located on top of, and
   - since you don't have access to the size of the WM's borders on the root
   window, a little "guessing" as to the WM's size must be taken into account

but, i can verify that this method should work.  if you'd like the little
bit of code i've come up with to solve this problem, let me know, happy to
forward.

cheers,

richard

On Wed, May 19, 2010 at 7:50 PM, Ken Resander  wrote:

> A textview shows help text with many 'technical' words that users may not
> know or remember. I would like a tooltip text with a short explanation to
> pop up when a user hovers the cursor over a technical phrase. There is a
> lookup table from technical phrases to explanations. I am thinking about
> using the mouse move event to get x,y then getting the technical phrase from
> x,y, then looking up the explanation and outputting the tooltip text.
>
> Are there better ways?
>
>
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: GThreads and GThreadPool help for a dummy

[richard boaz]

this is how i do it (not using pools), i have modified my code for your
purposes, though it's probably wrong somewhere in the implementation details
(i didn't even compile it), but i leave that to you.

this is very easily generalizable to do any kind of background work on a
"list" of items.

richard

=== BEGIN code snippet ===

{ // in the main routine
 gfloat *retPtr, tot_err;
 GQueue *threadsQ = g_queue_new(); // Q holding list of data items to
process
 data_t data[N_DATAPOINTS];  // data items to process
 fill_the_data_array(data);
for(i = 0;
 i < N_DATAPOINTS;
 i++)
 {
g_queue_push_head(threadsQ, &data[i]); // put data item onto Q for
processing
 }
g_thread_init(NULL);
commQ = g_async_queue_new();  // create comms Q
 threadsProc(threadsQ, maxThreads);  // initiate threads
 retPtr = (g_float*) g_async_queue_pop(commQ); // sit and wait for all
threads in threadsProc() to complete...
 tot_err = *retPtr;   // the answer
 }

// all the rest in a different source file...

static GQueue *threadsQ; // Q holding the data to process
static int numThreads; // number of threads (and a counter too)
static g_float *tot_err; // array of g_float, one element per thread
static g_float total_errors; // total errors, added up, returned to main
static GStaticMutex QMutex = G_STATIC_MUTEX_INIT; // mutex to read Q

typedef struct _THREADARGS
{ // structure of arguments to thread proc
GThreadFunc returnFunc;
 int threadNum;
} THREADARGS;

static void finishThreads()
{ // called once a thread has finished its work
numThreads--;
if (!numThreads)
 { // return to main routine
int i;
 g_float retValue = 0;
for (i = 0;ithreadNum;
GThreadFunc retFunc = threadArgs->returnFunc;
 data_t *data = get_data(); // get a data item to process
 while (data)
{
 tot_err[threadNum] += calc_error(data);
data = get_data(); // until no more to do
 }
(*(retFunc))(NULL);
}

void threadsProc(GQueue *q, int nThreads)
{
int i;
numThreads = nThreads;
 tot_err = calloc(numThreads, sizeof(g_float));
 threadsQ = q;
 for(i=0;ireturnFunc = (GThreadFunc) finishThreads;
 threadArgs->threadNum = i;
g_thread_create((GThreadFunc) _addData, (void *) threadArgs, FALSE, NULL);
 }
}

=== END code snippet ===


2010/7/23 Øystein Schønning-Johansen 

> I tried, and the new problem is now:
>
>  pool = g_thread_pool_new( my_calc, (gpointer) &common, 8, FALSE, &err );
>
>  for (i = 0; i < n_tot; i++ )
>  g_thread_pool_push( pool, &store[i], &err );
>
>  g_thread_pool_free( pool, FALSE, TRUE );
>
> When I run this code, it continues without waiting for the threads to
> complete. I expected that the g_thread_pool_free function would make it
> wait
> for all threads to complete before the program code continues, however
> it does not! How can I make it wait?
>
> (Yes, I added a static mutex in my_func. I'm convinced that I need it. )
>
> -Øystein
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: GThreads and GThreadPool help for a dummy

[richard boaz]

I realized after i sent that email that it was a little rushed, and too
unqualified.  So in the interest of completeness (and to avoid possible
misuse), the following addendum to the last post:

The code provided assumed a background program, i.e., not a GUI or a program
running with a main loop, since the call to g_async_queue_pop() in the main
routine is blocking.  As written, this code should absolutely NOT be used in
a program where a main loop is expected to remain responsive.

However, with a little modification, the algorithm can easily be made
non-blocking and usable in a GUI:

   - Remove all references to the async queue commQ.
   - In finishThreads(), instead of returning the answer via commQ, use
   g_idle_add() to pass the result back to the main loop.  (write a new routine
   that takes the result and presents it back to the user, whatever that
   means.)

In general, too, the following warnings must accompany this code:

   - Case is not handled when code is called a second time before the first
   call has completed, i.e., it is not re-entrant as written.  Calling a 2nd
   time before 1st execution has completed will cause indecipherable havoc;
   either handle this case, or disallow it.
   - There are memory leaks.

And, while I'm here, a couple of relevant guidelines to writing
multi-threaded code:

   - Use as few locks as possible in the threads.  In the example provided,
   the stored result could have been referred to directly (added to) in each
   executing thread, using a lock around the summation.  Instead, the solution
   provides for each thread to access to a single (and unique) element of an
   array of float values holding the summing result, while the finishThreads
   sums each thread's result once all threads have completed, returning this
   single value to the main routine/loop.  In this manner, no lock is necessary
   here in computing the result, guaranteeing a faster completion.


   - Whatever code must exist inside a lock, make it absolutely as small as
   possible.  The more code that exists inside a lock, the greater the chance
   that other threads will get stuck waiting on the lock to be free.  The more
   threads that must sit and wait for a lock to be free, the less the point of
   having made the code multi-threaded in the first place (since, by
   definition, locked code means only one can execute at a time, not much
   different than writing in-line...).  In the provided solution, a single lock
   is required around g_queue_pop_head() (which executes very fast), making the
   likelihood of a thread having to wait on the lock to be free very low
   indeed.

cheers,

richard

2010/7/23 richard boaz 

> this is how i do it (not using pools), i have modified my code for your
> purposes, though it's probably wrong somewhere in the implementation details
> (i didn't even compile it), but i leave that to you.
>
> this is very easily generalizable to do any kind of background work on a
> "list" of items.
>
> richard
>
> === BEGIN code snippet ===
>
>  { // in the main routine
>  gfloat *retPtr, tot_err;
>  GQueue *threadsQ = g_queue_new(); // Q holding list of data items to
> process
>  data_t data[N_DATAPOINTS];  // data items to process
>  fill_the_data_array(data);
> for(i = 0;
>  i < N_DATAPOINTS;
>  i++)
>  {
> g_queue_push_head(threadsQ, &data[i]); // put data item onto Q for
> processing
>  }
> g_thread_init(NULL);
> commQ = g_async_queue_new();  // create comms Q
>  threadsProc(threadsQ, maxThreads);  // initiate threads
>  retPtr = (g_float*) g_async_queue_pop(commQ); // sit and wait for all
> threads in threadsProc() to complete...
>  tot_err = *retPtr;   // the answer
>  }
>
> // all the rest in a different source file...
>
> static GQueue *threadsQ; // Q holding the data to process
> static int numThreads; // number of threads (and a counter too)
> static g_float *tot_err; // array of g_float, one element per thread
> static g_float total_errors; // total errors, added up, returned to main
> static GStaticMutex QMutex = G_STATIC_MUTEX_INIT; // mutex to read Q
>
> typedef struct _THREADARGS
> { // structure of arguments to thread proc
> GThreadFunc returnFunc;
>  int threadNum;
> } THREADARGS;
>
> static void finishThreads()
> { // called once a thread has finished its work
> numThreads--;
> if (!numThreads)
>  { // return to main routine
> int i;
>  g_float retValue = 0;
> for (i = 0;i  retValue += tot_err[i];
>  total_errors = retValue;
> g_async_queue_push(commQ, &total_errors);
>  }
> }
>
> static data_t *get_data()
> { // get the next data item off the Q to process, called by _addData()
>  data_t *data;
> g_static_mutex_lock(&QMutex);
>  data = g_queue_pop_head(threadsQ);
> g_static_mutex_unlock(&QMutex);
&

Re: GThreads and GThreadPool help for a dummy

[richard boaz]

indeed.  the way i solve this is by programmatically determining the number
of CPU's available on the machine at program startup, knowing (through
testing) how much of the CPU a particular task requires, taken in
conjunction with how much the program should be allowed to "take over" the
machine.  and then starting the maximum number of threads determined by all
of these (there's probably even more one could consider here).  all
programmable, thus always making best use of all available CPU's vs.
requirements vs. known trade-offs.

further, by knowing how many data elements are required to be processed, if
this number is actually less than the computed allowed maximum number of
threads, then this becomes the maximum number of threads to be started.  (no
sense starting more worker threads than there are elements to be processed.)

another thing i left out is adding a progress meter.  when the app is a GUI,
indications back to the user how far along the task is, (if the task
requires say more than 2 seconds), is good practice, and will make your
users happy.  this is easily achieved by adding a call to g_idle_add() in
the worker thread to invoke a routine responsible for updating a progress
meter.  since the main loop is not blocked, screen refresh is immediate
(assuming you've left space on the CPU's to allow the computer to do more
work than just the worker threads).

richard

On Sat, Jul 24, 2010 at 4:03 AM, Robert Pearce wrote:

> On Sat, 24 Jul 2010 10:16:09 +0200 richard wrote:
> >
> > And, while I'm here, a couple of relevant guidelines to writing
> > multi-threaded code:
>
> There's another that you've missed:
>
>  - Use as few threads as possible.
>
> Basically, threads add overhead. You get benefit only up to the point where
> there are as many threads as you have independent CPU cores. Beyond that
> your performance drops off as compared to a well structured idle loop, and
> the readability isn't noticeably better either.
>
> If you want to sum the results of foo(x[i]) over an array of N elements,
> where N is large and foo() is simple, I wouldn't use threads. If this is a
> background task and you want GTK to remain responsive, I would launch
> exactly ONE thread to do the summing. If foo() is complex, I would split N
> into M ranges, where M is roughly the number of CPU cores you expect to
> have, and launch M threads. Only if N is approximately equal to M would I
> take the approach being discussed here.
>
> Rob
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

GIOChannel & Intercepting stdout

[richard boaz]

So, after tweaking the attached program and pulling veritable tufts of hair,
I am not one inch closer to understanding how GIOChannel should work, nor
how it is actually working, in my particular case.  Which leads me to
conclude that I suffer from a rather fundamental lack of understanding as to
how GIOChannel should behave for this particular example.

What I want to do: wrap stdout (and eventually stderr as well) with
GIOChannel within my program so that all messages going to stdout are
intercepted (via g_io_add_watch()) for more processing.  I realize there are
many other ways to solve this problem, except that my situation/requirements
disallow them, since I need to:

   1. handle stdout and stderr messages being written to by libraries
   employed by my program that are external, i.e., i can't rewrite them to make
   their messages go elsewhere; and,

   2. these messages need to go to two places, both a file and to a DB; and,

   3. I would ideally like to intercept known error conditions and handle
   them real-time (thus requiring no user intervention).

My reading of GIOChannel functionality renders my usage understanding to be:

   - create a channel using the file descriptor (in this case STDOUT_FILENO)
   - add a watch on the conditions of interest (in this case G_IO_IN)
   - start the main loop
   - read the data on the channel within my callback and process accordingly

Which, I think, would result in:

   - the callback being called with condition G_IO_IN whenever anything is
   written to stdout

Except that I don't experience anything close to this result.

Below is sample code demonstrating what I'm trying to achieve here, but
basically, it:

   - creates a GIOChannel on stdout
   - adds a watch on condition G_IO_IN
   - adds an idle routine to write a message to stdout
   - starts the main loop

As I said, what I would expect from this:

   - callback fired with condition G_IO_IN when idle call writes to stdout

However, when this executes, I get:

   - the test message output to the terminal (completely bypassing the
   callback routine)
   - the callback gets fired only after the  key is hit on the
   keyboard, with nothing to be read from the channel.  (huh?...)

Swapping the commented call to g_io_add_watch() (adding condition G_IO_OUT)
also results in not understood results.  When this version executes, the
callback fires immediately (before the idle call).  Further, when taking
this path (G_IO_OUT) and subsequently writing to the channel (still stdout)
using g_io_write_chars(), this output also goes directly to the terminal.

I have scoured the internet for two days to no avail (including google code
search).  There are abundant examples of trapping stdout and stderr from
spawned processes from within a program, but I could find no example doing
what I would need to do here.  I have also tweaked the code below 1.1
million different ways (okay, i exaggerate somewhat, but only a little) and
come no closer to understanding:

   - why it behaves the way it does
   - how my understanding of how it should work is wrong
   - how it needs to really be written to achieve what I need it to do

What am I missing here?  Am I doing something that is "not allowed" or
simply not possible?  If solving my problem is not possible with GIOChannel,
is there another way I'm also yet unaware of?  But surely it is not true
that GIOChannel can trap stdin, stdout, and stderr streams from
spawned/child processes but not its own?

Any and all insight here is greatly appreciated.  My hope is that I'm just
stupid and missing something totally obvious, i.e., that I'll be able to
solve my problem elegantly with GIOChannel.

thanks in advance for any advice,

richard

p.s. OS = Ubuntu 9.10, glib = 2.22.3


 BEGIN SAMPLE CODE =
*// save to:* io.c
*// compile as:* gcc io.c `pkg-config --cflags --libs glib-2.0`
*
*
#include 
#include 
#include 

gboolean my_callback(GIOChannel *source, GIOCondition condition, gpointer
data)
{
  GMainLoop *loop = (GMainLoop *) data;
  gchar *buf=NULL;
  GError *error = NULL;

  switch (condition)
  {
case G_IO_IN:
  fprintf(stderr, "callback: condition G_IO_IN (%d)\n", condition);
  g_io_channel_read_line(source, &buf, NULL, NULL, &error);
  if (buf)
  {
FILE *fp = fopen("/tmp/test.out", "w+");
fprintf(fp, "%s", buf);
g_free(buf);
fclose(fp);
  }
  g_main_loop_quit(loop);// kill main loop, i.e.,
force pgm exit
  g_io_channel_shutdown(source,TRUE,NULL);   // close channel
break;
case G_IO_OUT:
{
  char *str = g_strdup("string OUT via g_io_channel_write_chars()\n");
  fprintf(stderr, "callback: condition G_IO_OUT (%d)\n", condition);
  g_io_channel_read_line(source, &buf, NULL, NULL, &error);
  if (buf)
  {
fprintf(stderr, "read on channel returned data (%s)\n", buf);
g_free(buf);
  }
  else
  {
fprintf(stderr, "read on channel

Re: GIOChannel & Intercepting stdout

[richard boaz]

On Thu, Aug 26, 2010 at 11:01 AM, Hrvoje Niksic wrote:

>
> The good news is that libraries shouldn't require a terminal for stdout
> because then they wouldn't work with stdout being redirected to a file
> (highly unlikely).
>
> The bad news is that this is harder to do correctly than it sounds.  If you
> connect stdout to a pipe, then a thread (or a subprocess) should exist to
> collect output from the pipe, or the program deadlocks whenever a library
> prints a chunk of output larger than the pipe buffer.
>
> The other bad news is that the dup2/pipe solution is very Unix-specific.
>  It is not clear if this is a problem to Richard.
>

Hi guys,

Thanks for the feedback, I'm now sorted.

You are correct, the libraries don't expect a terminal, no problem there.

The actual program I intend to use this in is a background process where the
actual processing executes in a separate thread while the main thread sits
in the main loop.  With the watch on the read-end of the pipe, the callback
is fired and executes within the main loop, while all writing occurs on the
execution thread; i.e, backwards from what you suggest, but both processing
entities (write to, read from) are separate and so can't collide with or
block each other (he says, crossing fingers furiously).

I re-post the modified code, very pared down, using GIOChannel watching that
now works as expected/required.

thanks again,

richard

 BEGIN CODE =
*// save to:* io.c
*// compile as:* gcc io.c `pkg-config --cflags --libs glib-2.0`

#include 

> #include 

> #include 

>
enum {READFD, WRITEFD, TTLPIPEFDS};

> int fd[TTLPIPEFDS];

>
gboolean my_callback(GIOChannel *source, GIOCondition condition, gpointer
data)

> {

>   GMainLoop *loop = (GMainLoop *) data;

>
  switch (condition)

>   {

> case G_IO_IN:
{
  gchar buf2[100];

>   memset(buf2, 0, sizeof(buf2));
  read(fd[READFD], buf2, sizeof(buf2));// read the data from the
read-end of the pipe

>   if (buf2[0])

>   {  // output to text file and to stderr

> FILE *fp = fopen("/tmp/test.out", "w+");

> fprintf(fp, "%s", buf2);

> fclose(fp);

> fprintf(stderr, "written to file: '%s'\n", buf2);

>   }
  g_main_loop_quit(loop);
  g_io_channel_shutdown(source,TRUE,NULL);
}

> break;

>   }

>   return FALSE;

> }

>
gboolean idle_function(gpointer nil)

> {

>   printf("printf() test" );

>   fflush(stdout);

>   return FALSE;  // remove

> }

>
int main()

> {

>   GMainLoop *loop = g_main_loop_new(NULL,FALSE);

>   GIOChannel *channel;

>
  if (pipe(fd) < 0) return(-1);// make a new
pipe

>   if (dup2(fd[WRITEFD], fileno(stdout)) < 0)return(-1);// copy
stdout to write-end

>close(fd[WRITEFD]);

>

>   g_idle_add((GSourceFunc) idle_function, NULL);   // write message to
stdout

>
  channel = g_io_channel_unix_new(fd[READFD]); // watch read-end of pipe

>   g_io_add_watch(channel, G_IO_IN,(GIOFunc) my_callback, loop);

>
  g_main_loop_run(loop);

>

>   return 0;
}

 END CODE =
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: g_strcmp0

[richard boaz]

2010/9/1 David Nečas 

> On Tue, Aug 31, 2010 at 10:38:13PM +0200, Milosz Derezynski wrote:
> > Well, to be honest, the g_ stuff serves as an abstraction layer; I don't
> > think that currently there is any problem with using the plain C type
> > instead of the g_ type in this (or other) functions, but for
> consistency's
> > sake and for the case that this typedef will become more complex
> depending
> > on other platforms supported in the future I would consider this a minor
> bug
> > and opt to get it fixed.
>
> I am not against changing the function prototype.  However, the
> reasoning that the typedef can change is bogus.  The type is equivalent
> to the C type and has been always specified so:
>
>Types which correspond exactly to standard C types, but are included
>for completeness - gchar, gint, gshort, glong, gfloat, gdouble.
>
> A typedef to something else would be a major API breakage.
>
> Yeti
>

desiring consistency is never a bogus reason.  making it right now, since,
as you say, it is currently equivalent, would cause no API breakage (what
breaks exactly?).

when, and if, the typedef wrapper ever does need to change, this would
indeed result in API breakage.

better to fix now when no harm possible, rather than waiting till a
necessary change necessarily breaks the API.  the longer into the future
that the typedef remains unchanged, the less likely it will cause harm in
old code.

or, why should it remain wrong just because it wasn't right in the first
place?  i.e., this "wrongness" works now, but is not guaranteed to work
forever.

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

Re: Status for long-running operation

[richard boaz]

yep, i concur with the set sensitive method.

the way i do this is: when the user:

   - executes something that gets done in the background,
   - that requires some time,
   - is non-interruptable,
   - and must complete before any next user action

loop over a list of GtkWidget pointers i have saved to a g_ptr_array() at
program startup/widget creation, making them insensitive for the entire
duration of the blocking operation.  once the operation completes/returns,
execute the set sensitive loop again making all necessary widgets again
sensitive, i.e., return to the user access to the widget's function.

you can also use this paradigm to make various widgets visible/invisible,
editable/uneditable, or sensitive/insensitive, according to one of many
possible display states.  your example has only two states, ON or OFF;
however, many other examples abound, e.g., connected/not connected to a DB,
viewing data in read-only vs. edit mode, background op is interruptable
(making interrupt button the only possible action), etc.

in the example below, the following end-user display states are defined:

   - No connection to DB
   - DB Connection to a particular DB - read-only mode
   - DB Connection to a particular DB - edit mode
   - DB Connection to server - DB Creation mode

for each state, a particular widget is defined to be:

   - sensitive or insensitive
   - visible or invisible
   - editable or non-editable

with this particular model, all states are absolutely defined.  that is, no
assumptions are made as to the previous state when setting a widget's
current display state.  this is good since you can then just call
setDispState() for a particular display state and know that all widgets will
be correctly defined and displayed regardless where you're coming from.  as
well, as development continues, one need only to add new widgets to the
pointer arrays appropriately and everything else just keeps running, no need
to write anything further to make a widget's state be what it needs to be.

cheers,

richard


 BEGIN CODE SNIPPET ==

enum { // display states
  DBNOCONN,// No DB Connection
  DBDISPLAY,   // DB Info Display
  DBEDIT,  // DB Info Edit
  DBCREATE,// DB Create
  TTLDBDISPSTATES
};

enum {  // display state types
  DISPSENS, // sensitivity
  DISPVISIBLE,  // visibility
  DISPEDITABLE, // editable
  TTLDISPTYPES
};

enum {  // display state settings
  OFF,
  ON,
  TTLDISPDIRS
};

GPtrArray  *dispState[TTLDBDISPSTATES][TTLDISPTYPES][TTLDISPDIRS];

static void _setSensitive(GtkWidget *widget, gpointer s)
{
  gboolean sens = (gboolean) GPOINTER_TO_INT(s);
  gtk_widget_set_sensitive(widget, sens);
}

static void _setVisible(GtkWidget *widget, gpointer v)
{
  gboolean vis = (gboolean) GPOINTER_TO_INT(v);
  vis ? gtk_widget_show(widget) : gtk_widget_hide(widget);
}

static void _setEditable(GtkWidget *widget, gpointer e)
{
  gboolean edit = (gboolean) GPOINTER_TO_INT(e);
  gtk_editable_set_editable(GTK_EDITABLE(widget), edit);
}

void setDispState(int state)
{  // set all widgets ON | OFF for the requested state
  int i;
  for (i=0;iwrote:

> One option as already said is a modal dialog with progress bar, another
> option is to have a progress bar in the main GUI and set the rest of the GUI
> insensitive (you _really_ should familiarize yourself with
> gtk_widget_set_sensitive() ).
>
>
> http://library.gnome.org/devel/gtk/unstable/GtkWidget.html#gtk-widget-set-sensitive
>
> M.
>
>
> On Sat, Sep 18, 2010 at 3:01 AM, Jeffrey Barish  > wrote:
>
>> Lex Trotman wrote:
>>
>> > On 18 September 2010 08:22, Jeffrey Barish 
>> > wrote:
>> >> Jeffrey Barish wrote:
>> >>
>> >>> My application has one operation that runs for a long time (~1
>> minute).
>> >>> During this time, the user is not allowed to do anything.
>>  Nevertheless,
>> >>> I felt that it was important to give the user some feedback that the
>> >>> application is still alive and that the operation is running.  My
>> >>> solution was to print a message in a TextBuffer and follow the message
>> >>> with a string
>> >>> of dots that grows in length by one every second.  To get the TextView
>> >>> to update, I used events_pending/main_iteration.  This all works
>> nicely.
>> >>> However, because of the events_pending/main_iteration statements, the
>> >>> entire
>> >>> GUI is now alive.  Thus, the user is able to do things that disrupt
>> the
>> >>> long-running operation.  Basically, what I want is a way to get the
>> >>> TextView to update so that I can update the progress indicator but for
>> >>> everything
>> >>> else still to be locked out.  Is there a way to do this?
>> >>
>> >> Here's a possibility that seems to work:
>> >>
>> >> I used event_handler_set to define an event handler that filters out
>> all
>> >> events (by not calling main_do_event) except EXPOSE while the
>> >> long-running operation is underway.  I wish that there were a way to
>> >> restore the default event handler, but there i

Re: Status for long-running operation

[richard boaz]

On Sun, Sep 19, 2010 at 8:33 PM, Paul Davis wrote:

> On Sat, Sep 18, 2010 at 3:24 AM, richard boaz  wrote:
> > yep, i concur with the set sensitive method.
>
> all good, except that in an ideal world, the sensitivity changes are
> applied to GtkAction's, not widgets. this way, keybindings and other
> methods of driving specific actions are all taken care of together.
>
> of course, not many GTK apps have been written with an action-centric
> approach, which is unfortunate.
>

but since GtkActions are pointers, and can be made both visible/invisible
and/or sensitive/insensitive using available methods, can the paradigm not
be extended to work for these "user-available functions" as well?

i would think yes, but since my program doesn't employ GtkAction (i.e., i am
unfamiliar with its particular implementation details), perhaps i'm missing
something.

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

Re: How to implement a global hot-key listener ?

[richard boaz]

not entirely sure what you mean: global to your application, or global to
the window system?

if you mean your application, then it's easy:

   - make your top level window
   - connect "key-press-event" signal to the top level window
   - process the key press action in your registered callback function
   - done

richard

On Sun, Nov 21, 2010 at 2:25 AM, Shuge Lee  wrote:

> Hi all:
>
> Any good idea about grab key global and works on Linux, Mac OS X and
> Windows ?
>
> XgrabKey seems not works well on Windows.
>
> --
> Shuge Lab. Lee Li
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: How to implement a global hot-key listener ?

[richard boaz]

indeed.

and if i'm not wrong, it seems the future here will be solved by D-Bus:

http://www.freedesktop.org/wiki/Software/dbus

in time, i hope, this solution/implementation will take hold at the WM level
and this problem will be solved in a generic and universal manner for now
and ever.  but, as always with new solutions, its universal adoption and
implementation will take time.

complete description here:
http://www.freedesktop.org/wiki/Software/dbus

richard

2010/12/6 Erick Pérez Castellanos 

> Hey:
>
>  so i think system wide hotkey registrations and management is something
>> at least GTK 3 should so support!!! (so this is something for the
>> gtk-devel list i think)
>>
>
> You do realize there's no way that is gtk responsibility. Global, system
> wide hotkey is not for gtk to handle, That is for the window
> manager/desktop
> enviroment/whatever manager you've been running, to catch and then signal
> the applications to do something in response.
>
> "GTK+ is a highly usable, feature rich toolkit for creating graphical user
> interfaces" from http://www.gtk.org
>
> Erick
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_file_chooser_get_filenames multiple folders

[richard boaz]

oops, left a little important bit out of the readFiles() routine, i.e., the
actual traversal/processing of the selected folders.  this routine should
read:

static void readFiles()
{  // called on user selection from GtkFileChooser
  GSList  *selected, *sel;
  sel = selected =
gtk_file_chooser_get_filenames(GTK_FILE_CHOOSER(fileSel));
  while(selected)
  {
getFiles(selected->data);
g_free(selected->data);
selected=selected->next;
  }
  g_slist_free(sel);
}


On Tue, Feb 8, 2011 at 11:06 AM, richard boaz  wrote:

> i do this just fine.  but you must do the recursive traversal yourself.
>
> a code snippet illustrating how is below.  this is not stand-alone, i.e.,
> it will not compile.  you must add your own code to:
>
>- set up and execute the file selector itself (here named *fileSel)*,
>- write the routine registerFile(), which is responsible for
>registering the file with your program for subsequent processing, whatever
>that means to you.  (typically, a list that, once completely filled (i.e.,
>as returned from file selector), is traversed for individual file
>processing; though there are certainly other ways to effectuate this.)
>- as well, the routine fileType() can be expanded to explicitly
>include/allow for only certain file types, returning:
>   - FTDIR  - it's a directory
>   - FTFILE - it's a file to process
>   - FTDONOTPROC - it's a file we don't care about, so ignore
>
> cheers,
>
> richard
>
> === BEGIN SNIPPET 
> enum {
>   FTDIR,
>   FTFILE,
>   FTDONOTPROC
> };
>
> static int fileType(char *name)
> {  // is the input a file or a directory?
>   // can't use extended field d_type from dirent.h, doesn't exist on
> SOLARIS
>   DIR*dp;
>   int   ret = FTFILE;
>
>   if (!((dp=opendir(name))==NULL))
>   {  // succeeded, it's a directory
> ret = FTDIR;
> closedir(dp);
>   }
>
>   return ret;
> }
>
> static void getFiles(char *dirFile)
> {  // recursive function:
>   // descend into every directory and
>   //  1) if it's a directory call us again, or
>   //  2) if it's a file, register for processing
>   DIR*dp;
>   struct dirent *ep;
>   char *newDirFile;
>
>   if ((dp=opendir(dirFile))==NULL)
>   {  // failed, it must be a file
> registerFile(dirFile);
>   }
>   else
>   {  // succeeded, it must be a directory
> while((ep=readdir(dp)))
> {
>   if (!strcmp(ep->d_name,".") ||
> !strcmp(ep->d_name, ".."))
> continue;  // don't read '.' and '..' directories
>
> #ifdef WIN32
>   newDirFile = g_strdup_printf("%s\\%s", dirFile, ep->d_name);
> #else
>   newDirFile = g_strdup_printf("%s/%s", dirFile, ep->d_name);
> #endif
>   switch(fileType(newDirFile))
>   {
> case FTDIR:
>   getFiles(newDirFile);
> break;
> case FTFILE:
>   registerFile(newDirFile);
> break;
> case FTDONOTPROC:  // file type we don't care about, ignore...
> break;
>   }
>   free(newDirFile);
> }
> closedir(dp);
>   }
> }
>
> static void readFiles()
> {  // called on user selection from GtkFileChooser
>   GSList  *selected, *sel;
>   sel = selected =
> gtk_file_chooser_get_filenames(GTK_FILE_CHOOSER(fileSel));
> }
> === END SNIPPET 
>
> 2011/2/8 David Nečas 
>
> On Tue, Feb 08, 2011 at 02:35:02AM +, kevin.s.anth...@gmail.com wrote:
>> > Is there a way, to use gtk_file_chooser_get_filenames to recursively
>> > descend into all the folders selected?
>> >
>> > so you select folders ABC
>> > and click open,
>> > you then go into ABC and select and return all the files in each
>> subfolder,
>>
>> No.  You can use GFileEnumerator or GDir to traverse the tree – deciding
>> how to handle hidden files, symlinks to directories, crossing file
>> system boundaries, etc. as the definition of ‘all files’ depends...
>>
>> Yeti
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>
>
>
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: logical problem

[richard boaz]

hi,

the way i have solved this is problem is to set up a graphing coordinate  
system between the user coordinates (from the CAD file) and the window  
coordinates: this amounts to setting up a structure containing the min and  
max of the user coordinates and the window coordinates (and probably more)  
to be used to translate between the two.


then write the functions user_to_pix_x(), user_to_pix_y(), pix_to_user_x()  
and pix_to_user_y() for the coordinate system and you can get to there  
from here with ease, always right vs. the size of the window.


i can provide code if you like.

cheers,

richard


On Mon, 20 Jun 2005 14:10:51 +0200 (MEST), <[EMAIL PROTECTED]> wrote:


hi,
please help me i have a logic problem. i write a application
that draws CADpoints from a Cadfile (x,y coord.) on a
drawingarea. so far so good. now i wanna align this points to the
windowsize. my idea was, add the windows x-y coord. to the pointcoord.
but this is not very suggestive. i know this is not a real gtk thing but
i thought some of you are really c++ cracks and could bring me on the
right way. thanks!





--
Richard Boaz
[EMAIL PROTECTED]
+31.(0)648.792.484
http://www.boazconsultancy.com
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: expose-event

[richard boaz]

hmm, not sure if i'm getting the wrong end of the stick, here, but in my  
drawing program i adhere 100% to the following algorithm:


configure_event - responsible for all drawing code, drawing only to an  
internal pixmap buffer.
expose_event - responsible for rendering the pixmap drawn in the configure  
event to the drawing area itself, i.e, the screen.


for my application, the pixmap i draw to is determined by several program  
settings/factors: it is possible for me to be maintaining more than one  
internal pixmap at a time for a certain drawing area, while only one of  
these pixmaps is ever rendered to the screen at any given moment.


the configure event, then, determines which internal pixmap i should draw,  
makes this internal pixmap, and then sets the variable defining the actual  
pixmap to render to the screen.  it is the configure event that is called  
first upon a resize with the expose event following.


the expose event, then, simply renders the pixmap held in this variable to  
the screen.


N.B. i would not recommend managing drawing areas by using only the expose  
event to render the screen, this is incredibly inefficient since there are  
expose events which do not require redrawing the entire drawing area.


cheers,

richard


On Wed, 22 Jun 2005 10:37:27 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote:


Hi,

[EMAIL PROTECTED] writes:


resize my window. i wanna redraw a drawingarea after i resize
the window. but in this case my drawing-function do her work,
and after that the expose-event delete it.


You must not do any drawing outside the expose event callback.


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





--
Richard Boaz
[EMAIL PROTECTED]
+31.(0)648.792.484
http://www.boazconsultancy.com
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: gtk_toggle_button_set_active()

[richard boaz]

thanks, guys... r-

On Tue, 26 Jul 2005 17:09:32 +0100, John Cupitt <[EMAIL PROTECTED]> wrote:


On 7/26/05, Tristan Van Berkom <[EMAIL PROTECTED]> wrote:

[EMAIL PROTECTED] wrote:
[...]
> Thus, my questions fall into the categories: how this could occur,  
under
> what circumstances it might be possible (e.g., that I'm doing  
something
> "illegal" in my code (though not "breaking" anything), etc.  Or,  
barring
> any direct knowledge in this regard, how I might try to track the  
problem

> down and answer the question: why is my call to
> gtk_toggle_button_set_active() not resulting in my radio button being
> properly set?

There has to be something wrong with your code (since you have a dozen
working examples of togglebuttons in your code).

Try:
(gdb): break gtk_toggle_button_set_active
(gdb): run

Add g_print() all over the place like a true terrorist and
eventually you'll nail the sucker.


I agree, it sounds lke a bug in your code. If it's memory corruption,
I'd try valgrind too. It can (usually) very quickly spot pointer
problems in your code.

John






--
Richard Boaz
[EMAIL PROTECTED]
+31.(0)648.792.484
http://www.boazconsultancy.com
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: force configure-event

[Richard Boaz]

> Hi all,
>
> in my app I connect an "event" callback to a button. From within this
> callback I try to force a "configure-event" for a gtdrawingarea by calling
> gtk_widget_queue_draw(drawing_area). However, this signal is never
> emitted, therefore the drawingarea never gets redrawn.
>
> Any ideas why?

hi,

configure-event is called upon initial exposure of the drawing area and
changes in dimension (and probably more).  gtk_widget_queue_draw() will
invoke the expose-event callback you have defined for the drawing area.

one paradigm for managing this type of situation:

- in the configure event, call the routine responsible for making the drawing
- in the drawing routine, draw everything to a pixmap.  last line of code
is gtk_widget_queue_draw() on the drawing area the pixmap should be
rendered to.
- in the expose event, do nothing (in terms of drawing) except draw the
pixmap to the drawing area

following this allows you to call your drawing routines from within the
program itself, always resulting in a refresh of the drawing area.

ciao,

richard

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

gtk_window_set_focus()

[Richard Boaz]

hi,

I have an app to draw seismograms on the screen.  When the user hits the
"Next" button, the app goes away and reads the next batch of traces for
display, does various statistics, plots the output to an internal pixmap
and then renders this to the screen; depending on the number of files to
be read, this could take a fair amount of time (up to a minute).  no
problems there.

One issue that came up over time (when actually unleashed to the end
users...) was that when the program was away reading the files, user
events (e.g., mouse click) would get caught and (maybe) cause problems
since the program was not in the proper state to process this event
properly.

I got around this by introducing an invisible widget used to grab focus
while the program is off reading and processing files, and then ungrabbing
this focus once the program's processing is complete, thus disallowing any
user events to be propogated to the widget receiving the user event.  This
also works just fine.

However, this has now introduced a new problem.  If the user has the mouse
over the Next button (to read traces), clicks this button (thus invoking
the file processing described above), and doesn't move the mouse off this
button, when the program returns (ungrabbing focus of my invisible
widget), focus is not reset to this button.  (Clicking this button again
has no effect; focussing somewhere else and returning to this button
results in a working button.)

To get around this, then, I tried to use gtk_window_get_focus() to save
the widget having focus at the moment my internal processing is invoked,
and then returning this focus to this saved widget when the process is
complete, via the following function:

void focusLock(int lockCmd)
{
  static GtkWidget *oldFocus;

  switch(lockCmd)
  {
case LOCK:
  oldFocus = gtk_window_get_focus(topWindow);
  gtk_grab_add(invisible);
  break;

case UNLOCK:
  gtk_grab_remove(invisible);
  gtk_window_set_focus(topWindow, oldFocus);
// tried also gtk_widget_grab_focus(): also no effect
  break;
  }
}

However, using this code, the focus is not reset back to the oldFocus
widget; there is no change in the problem behaviour.  In order to be able
to press the button a second time, I must still move the mouse away from
the button and back over it.

So, I'm wondering, first, is there a way to achieve my above-stated goals
some other (better) way?  Second, if the above methodology is okay, why
does the gtk_window_set_focus() call above not result in the focus being
returned to the widget having focus before my program stole it with
gtk_grab_add()?

Thanks for any ideas in advance, I'm finding myself in a loop of solve one
problem and I simply make another needing solving.

cheers,

richard boaz

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

gtk_file_chooser_set_filter does not work as advertised

[Richard Boaz]

hi,

last august i posted a question about the use of
gtk_file_chooser_set_filter() routine and that fact that it does not work
as advertised.  of course, i always prefer to think that i'm doing
something wrong since a bug of my own making is ultimately easier and
quicker to fix than a bug in gtk+.

however, after coming back to this and playing with it some more, i cannot
deduce how i am doing anything wrong.  this, coupled with the fact that i
didn't receive a single response to my original query back in august. 
(rather frustrating as well that when i googled this today as part of my
ongoing investigation, the first hit i got was my own email last august;
how frustrating is that?)

my original query is below, but basically it comes down to this:

the documentation for gtk_file_chooser_set_filter() indicates that this
can be used without having to call gtk_file_chooser_add_filter() to
restrict the files on display.  this simply does not work.

should i be submitting a bug instead of assuming i've done something wrong
(and then ask for help in identifying it)?

cheers,

richard boaz

= ORIGINAL QUERY==

I'm implementing the GtkFileChooser and am having a problem with the
gtk_file_chooser_set_filter() routine.

If I understand the documentation correctly, I should be able to use this
call without being required to call gtk_file_chooser_add_filter().  In
that, I want to apply a filter without the user having a pulldown list of
same.  (Actually, it's the user who wants to specify the filter, so I want
to provide them a text entry field on the dialogue where they can specify
the filter, and then apply it to the dialogue's contents without creating
any pulldown list of filters.)

My code follows the order:

  gtk_file_chooser_dialog_new()

  gtk_file_chooser_set_select_multiple()

  filter = gtk_file_filter_new()
  gtk_file_filter_add_pattern(filter, "*.1")
  gtk_file_chooser_set_filter()

  gtk_dialog_run()

Yet when the dialogue comes up, the filter has not been applied.  If I add
gtk_file_chooser_add_filter() with the same filter, the dialogue comes up
with a filter list, nothing selected, and no filter applied, (but with the
filter I've defined as being in the list); when I select my filter from
the list, everything works fine, filter is applied and works correctly.

So, am I doing something wrong?  The GTK+ documentation for
gtk_file_chooser_set_filter() states the following:

BEGIN DOC =

Sets the current filter; only the files that pass the filter will be
displayed. If the user-selectable list of filters is non-empty, then the
filter should be one of the filters in that list. Setting the current
filter when the list of filters is empty is useful if you want to restrict
the displayed set of files without letting the user change it.

END DOC ===

>From the last sentence I assume that what I am trying to do is possible,
so I also assume I'm doing it wrong.  (And what does it mean to say "when
the list of filters is empty"?  Simply that gtk_file_chooser_add_filter()
has never been called?  Or do i need to do something to create an "empty"
list as opposed to a "non-existent" list?)

Anybody have a clue and care to point me in the right direction?

All responses greatly appreciated, cheers,

richard boaz


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

Re: gtk_file_chooser_set_filter does not work as advertised

[Richard Boaz]

Hi,

thanks for the response, this prompted more investigative ideas and i
discovered my problem.

the problem was that i had also used the call
gtk_file_chooser_set_filename(), though only specifiying a directory.  it
seems that when calling this, calls to gtk_file_chooser_set_filter() are
ignored.

because when i changed gtk_file_chooser_set_filename() to
gtk_file_chooser_set_current_folder() (more appropriate for my purposes),
everything works fine.

thanks for the followup, that's exactly what i needed to get me to the
solution.

cheers,

richard

>> the documentation for gtk_file_chooser_set_filter() indicates that this
>> can be used without having to call gtk_file_choo, ser_add_filter() to
>> restrict the files on display.  this simply does not work.
> It appears to work for me. I've attached a sample program that does what
> you've described. When I run it, I don't see the drop down to select a
> filter, but it only contains files matching the pattern "*.1"
>
> I'd be forced to guess, then, that there's either a bug in the
> particular version of gtk you're running against, or there's a glitch in
> your code. You describe giving a file entry to allow the user to specify
> the pattern; assuming this simple test case works for you, can you post
> your specific code, rather than a vague description that seems to match
> my little test case here?
>
> Of course, if the simple test case fails for you, it clearly points the
> finger at your specific version of gtk. Mine, which it works
> successfully with, is 2.6.7, from the fc4 2.6.7-4 rpm.
>
> Hope this helps some.
>
> --
> David Hoover <[EMAIL PROTECTED]>
>


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

Re: How to use the GnomeAppBar

[Richard Boaz]

hi,

every time in your code where the progress bar should be updated, execute
the following code:

while (gtk_events_pending())
gtk_main_iteration();

this will force the events generated by your call to update the progress
bar to be processed by the main loop, thus updating the screen.

beware: this will process all main loop events.  if your processing code
in the background generates its own events to be processed by the main
loop, they will get processed as well.

if you do generate other events during your processing that should not be
processed by the main loop until your code has completed, you need to
instantiate a new main_loop() that will be responsible for only processing
the progress bar update events.

cheers,

richard



> I've been using GTK+ for a short time now, and I'm still trying to figure
> out some of the little things.  (So far I've found this to be an excellent
> source of great information so thanks to everyone who has helped me in the
> past).  Anyway, I added a GnomeAppBar at the bottom of my app because I
> wanted to use its progressbar (GtkProgressBar *).  So when I call
> gtk_progress_bar_set_fraction() in a loop, nothing happens (that I can
> see).  Basicly all I end up seing is the last call to
> gtk_progress_bar_set_fraction().  Am I required to make some call to force
> it to update on each call inside the while loop?
>
> Thanks for any help,
> Travis Miller
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: Not understanding the principles of drawing areas and primitives etc... Colors?

[Richard Boaz]

you can follow this basic algorithm, (there are many ways to effect this, this is just one that works and is, hopefully, descriptive):// set up colors and some GCsGdkColor	red, black;GdkGC		*gc, *inverse_gc;gc = gdk_gc_new(window);			// regular GC for the windowinverse_gc = gdk_gc_new(window);	// inverse GC// init the various aspects/qualities of the GCsred.red = 65535; 	red.green = 0; 	red.blue = 0;			// redblack.red = 0; 	black.green = 0; 	black.blue = 0;		// blackgdk_gc_set_rgb_fg_color(gc, &red);gdk_gc_set_rgb_bg_color(gc, &black);gdk_gc_set_rgb_fg_color(inverse_gc, &black);gdk_gc_set_rgb_bg_color(inverse_gc, &red);// plus any other qualities of the line you would like to set, like dashes, thickness, etc.// see gdk_gc_set_function(gc, FUNCTION) in the documentation// then in your configure routine for your drawing area:// make the pixmap you will be drawing onGdkPixmap *pixmap = gdk_pixmap_new(da->window, da->allocation.width, da->allocation.height, -1);// paint the background using the background color (foreground color of our inverse GC)gdk_draw_rectangle(pixmap, inverse_gc, TRUE, 0, 0, da->allocation.width, da->allocation.height);// draw a line from corner to corner, twicegdk_draw_line(pixmap, gc, 0, 0, da->allocation.width, da->allocation.height);gdk_draw_line(pixmap, gc, 0, da->allocation.height, da->allocation.width, 0);// force the expose event for the drawing area to be calledgtk_widget_queue_draw_area(da, 0, 0, da->allocation.width, da->allocation.height);// render the pixmap to the screen in your expose routine for the drawing area:gdk_draw_drawable(widget->window,	widget->style->fg_gc[GTK_WIDGET_STATE (widget)],	pixmap, 	event->area.x, event->area.y	event->area.x, event->area.y	event->area.width, event->area.height);richardOn Mar 11, 2006, at 5:29 PM, Leo - wrote:I think I can grasp the GC idea; it's just a way to reduce the number of parameters sent to certain functions, but where do I "get" the colors from? When I check up on gdk_gc_set_foreground etc. they require a gdkColor parameter, and following that link (clicking gdkColor) gets me to a page about colormaps and, my impression is that I need to set up a "palette", link it to the widget, add my colors etc. etc., before I can actually draw on my widget.  Is that really the case?  Whether it is or not, it would be nice if somebody could give me a (c language) source snippet on how to set up colors and colormaps for a widget and then draw a red line on it...2006/3/9, Paul Davis <[EMAIL PROTECTED] >: On Thu, 2006-03-09 at 19:39 +0100, Leo - wrote:> I want to be able to draw lines on a gtkDrawingArea, with a color the> user selects (r,g,b),> however I don't understand how I would do.> The whole business with gdkGC's and gdcColors seems very alien. If > somebody could> point me to a tutorial (the scribble one isn't enough since that one> doesn't use color).no tutorial here, but a brief lecture.there are many different possible parameters for many drawing primitives. in your case of line drawing, we have things like:* is the line dashed?* if dashed, what are the stroke & gap sizes?* the pen width* the color of the line for other drawing primitives, there are many more.rather than constantly pass all these parameters into every drawingfunction, most drawing kits based on the X Window System instead using aGraphics Context (or GC) which contains a set of values that can be used by any drawing primitive. This is more efficient in other ways too, butyou probably don't need to worry about them. You generally work with afixed number of> What I simply want to do is something like line(gtkDrawingArea* da, > int x1, int y1, int x2, int y2, r, g, b)just grab a suitable GC, such as   Glib::RefPtr gc = get_style()->get_fg_gc();change its foreground color, specifically for whatever state the drawing area is in right now (widgets in GTK can be in one ofseveral possible states):   gc.set_foreground_gdk (redColor, get_state());and draw on the window:   get_window()->draw_line (gc, x1, y1, x2, y2); the precise details might be slightly off, i am writing from memory.--p___gtk-list mailing listgtk-list@gnome.orghttp://mail.gnome.org/mailman/listinfo/gtk-list ___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Auto-scrolling up or down a GtkScrolledWindow

[Richard Boaz]

Hi,

first, there seems to be some information missing from your  
question.  namely, what type of widget is the child the scrolled  
window is holding?


because, your positioning requirement is a requirement for the child,  
not the scrolled window, the scrolled window simply acts as a helper  
container for child widgets without native scrolling support, in that  
the scrolled window does not have access to modifying the display  
position of the child's contents.


for example, if the child widget is a TreeView (columns of data), you  
can achieve what you are trying to do with the following calls:


charrow_num[5] = "100";
GtkTreePath *path = gtk_tree_path_new_from_string(row_num)
gtk_tree_view_scroll_to_cell(GTK_TREE_VIEW (hdrVIEW), path, NULL,  
TRUE, 0.0, 0.0);

gtk_tree_view_set_cursor(GTK_TREE_VIEW (hdrVIEW), path, NULL, FALSE);

see the documentation for GtkTreeView for further details.  or,  
alternatively, see the documentation for the child widget relevant  
for your scenario and available support for positioning its contents.


cheers,

richard

On Mar 28, 2006, at 8:58 PM, Meli Vázquez wrote:


Hi again guys.

I have a GtkScrolledWindow which contents I refresh periodically. I
would like it to scroll down each time I update its contents.

I've tried something like this:

VScrollBarPos = gtk_scrolled_window_get_vadjustment (..);
VScrollBarPos->value--; (or value++)

each time I write in it. But it doesn't seem to work. The scroll
window doesn't scroll down (though I can still do it manually).

I also tryied with combinations of:
- gtk_scrolled_window_set_vadjustment(..)
- gtk_adjustment_set_value(..)

But still doesn't work.

When debugging I saw that upper and lower bounds don't change (though
I still can scroll up and down manually in the GUI).

What am I doing wrong? Why isn't it working?


Thanks again in advance.
AV.
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list




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

Re: pango text size

[Richard Boaz]

hi,

i have no idea if i do this correctly myself (comments?), but the way  
i have achieved this is with the following code:


int fontSIZE(char *str, gboolean type)
{
int width, height, ret;
PangoFontDescription *desc;
PangoLayout *layout = pango_layout_new (gtk_widget_get_pango_context 
(widget /* drawing area, e.g. */));


pango_layout_set_text(layout, str, -1);
pango_layout_set_font_description(layout, desc);
pango_layout_get_pixel_size (layout, &width, &height);

switch (type)
{
  case HEIGHT:
ret = height;
break;
  case WIDTH:
ret = width;
break;
}
g_object_unref (layout);
return(ret);
}

but i'm with you, it would seem to me there should be an easier way  
of getting these values, in that, requiring to know the width/height  
of a string strikes me as crucial information if you're rendering  
text to a drawing area where the location of other stuff in the  
drawing area is dependent on the size of other displayed text.


good luck, and if anyone else has any more interesting/correcter  
information on this subject, i would also be very interested.


cheers,

richard


On Mar 20, 2006, at 3:38 PM, Jose Hevia wrote:


Hello,
I need to know the size of chars(width,height) written in a text view,
so I could calculate the number of "words" per line I could write.
So I downloaded "gnome-terminal" source code to see if I could
understand how can it do it, but I'm little confused.
I just want to know  the width and heigth of a given monospace font
cell, looking at the documentation I only found:
pango_font_metrics_get_approximate_digit_width()
[ http://developer.gnome.org/doc/API/2.0/pango/pango- 
Fonts.html#id2931730 ]

but I need the fontmetrics, I can get the metrics from a fontset, but
how do I get the fontset?
gdk functions that do it are deprecated.
Seems too complicated for something so simple.
Do you know a good pango tutorial/ebook that covers this?  Any simple
program that already do this with viewable code?

   Jose Hevia
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list




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

Re: Controlling resizing of boxes when a window is resized

[Richard Boaz]

hi,

you should pack the two widgets into a vertical box so:

gtk_box_pack_start (vbox, topWidget, TRUE, TRUE, 0);
gtk_box_pack_start (vbox, bottomWidget, FALSE, FALSE, 0);

see the documentation for argument #3 to achieve the effect you  
want.  also, avoid using gtk_widget_set_size_request() if the user  
ultimately has the say-so in deciding window size, use  
gtk_window_resize() on the top level window at startup instead.


cheers,

richard


On Apr 5, 2006, at 3:43 AM, Ian Puleston wrote:


Hi,

I have an app that has its main display divided vertically into two  
- an
upper box displaying various things, and a lower box containing  
buttons. I
use a gtk_widget_set_size_request to set the minimum size of the  
upper box,

and let the lower button box choose its own size.

The problem is if the user resizes the window, it is the height of  
the lower
button box that gets resized while the upper box stays unchanged,  
which is

exactly the opposite of what I want.

So, is there some way to control which child boxes within a window get
resized when the window is resized?

Ian



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




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

No Doubts

[Richard Boaz]

huh?

I'm not familiar with wxWidget, so I'm afraid I can't comment from a  
true comparison perspective, but I write programs with Gtk+ running  
on LINUX, MAC OS X (X11), and Solaris (a rather complicated affair,  
displaying seismograms in many forms and transforms, i.e., not a  
simple app with a couple of buttons), and I have run into absolutely  
zero multi-platform issues.


IMHO, Gtk+ is ideal for multiple platform applications, whether  
wxWidget is actually better or not, I can't say, but how exactly  
could it be when Gtk+ exhibits zero problems in this regard (that  
I've found)?


cheers,

richard


On Apr 6, 2006, at 10:50 AM, Michele O-Zone Pinassi wrote:


On Saturday 25 February 2006 09:44, Lloyd wrote:
Which one is better to use, GTK+ or wxWidget, to get a fast and  
easilt

portable application among multiple platforms (OS).


wxWidget is better for building multiple platforms programs, IMHO,  
of course !


Oz
--

O-Zone ! No (C) 2005
WEB @ http://www.zerozone.it
BLOG @ http://blog.zerozone.it/user/o-zone
HOBBY @ http://peggy.altervista.org
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list



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

Re: drawing a generated bitmap

[Richard Boaz]

hi,

i do something like this in an application to draw probability  
density function plots.  what i do is render the image to an internal  
RGB buffer, followed by gdk_draw_rgb_image() to render it to the  
internal pixmap (this pixmap subsequently rendered to the screen):

width = DrawingArea->allocation.width;
height = DrawingArea->allocation.height;
rgbbuf = malloc(width * height * 3);
memset(rgbbuf, 240, width * height * 3);// set the background 
to  
GREY=(240, 240, 240)
DrawBufferImage(rgbbuf, width, height, data);
gdk_draw_rgb_image(pixmap, DrawingArea->style->fg_gc[GTK_STATE_NORMAL],
0, 0, width, height, GDK_RGB_DITHER_NONE, rgbbuf, width*3);
free(rgbbuf);

inside the DrawBufferImage() routine, i examine the data, point by  
point, and assign each pixel to be the RGB combination corresponding  
to the colour defined/assigned for each data value.

my input data also dictates an absolute starting size, so inside the  
DrawBufferImage() routine, i also magnify the image using a bi-cubic  
spline interpolation algorithm.  the speed achieved in ultimately  
rendering the image is as fast as possible, and there is no real  
discernable delay between receiving the data to plot and rendering  
the image to the screen, i.e., it's instantaneous.

plotting pixel by pixel (and magnifying to boot) can result in a  
quickly drawn image (depending on the number of data points, of  
course), if gone about in the right manner.

cheers,

richard


On Jun 18, 2006, at 1:28 PM, kamil stachowski wrote:

> thank you for the answer :)
>
>> Don't draw pixel by pixel, it would be awfully slow.
>> Use GdkPixbufs and gdk_draw_pixbuf().
>
> you mean "don't draw pixel by pixel using drawpoint", is that it?
>
>> Something along these lines should be doable *if* you can
>> get a indexed color visual, which you cannot count on.  So
>> I would just redraw it (incidentally I develop a program
>> which uses false-color maps a lot and redrawing works good
>> enough).
>
> that's a pity but i'll have to cope with that if there's no other way.
>
> however, i ran into a problem with colourmaps. i was using  
> gdk.image (has the
> putpixel method which treats the colours in a more traditional way,  
> and seems
> to be fast enough for my needs) but didn't manage to change the  
> colours it
> uses. i keep getting a blue gradient which is not precisely what i  
> want.
> here's the code:
>
> def img=Image(ImageType.Fastest,Visual.System,500,500);
> for (mutable x=0, x<500; x++) for (mutable y=0; y<500; y++)
>   img.PutPixel(x,y,(x+y):>UInt32);
>   
> def gc=GC(args.Event.Window);
> mutable col=Color(0xff,0,0);
> gc.Colormap.AllocColor(ref col,true,true);
> img.Colormap=gc.Colormap;
>
> args.Event.Window.DrawImage(gc,img,0,0,0,0,500,500);
>
> i don't seem to be able to spot anything red in the result. could  
> you please
> tell me what i am doing wrong?
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: What's worry with the "entry" widget? It makes my application so ugly!

[Richard Boaz]

hi,

if you want fine control over the size of your entry widgets, the  
following routines may be of help:

gtk_entry_set_max_length()
gtk_entry_set_width_chars()

richard

On Jul 16, 2006, at 9:39 AM, chao yeaj wrote:

> Hello everyone
> First ,I am sorry for my poor Englisth !
>
> In my application, there are sveral "entry" widgets
>
> usually ,they are nice, and the widget's default size is that:
> it's width can accommodate 12 characters ,as follow,
>   +-+
>|012345678901|
>   +-+
>
> But ,today , when I test my application,
> I suddenly found that, the "entry" widget's default size it lagger
> than before
>it's width can accommodate nearly 25 characters ,asfollow,
>  ++
>   |01234567890123456789012345|
>  ++
>
>
>   The entry widget suddenly changed so large,
>   It makes my application ugly
>
>   I did not know why it becomes so large
>   I need your help!
>
>   Any commets would be much appreciated, and thanks in advance!
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: GtkFileChooser, Filters and Typeahead

[Richard Boaz]

I have previously done exactly as Mark as suggested here.

Use the extensibility of the FileChooserDialog to add your own  
widgets, namely, an entry widget.  The callback for this entry widget  
should read the test entry's contents, and then apply this user- 
provided filter to the gtk_file_filter_add_pattern() and  
gtk_file_chooser_set_filter() functions, which will then  
automatically update the contents of the file window as per this filter.

requires a little playing around to get what you want, but it really  
is as simple as that.  (btw, using regex is not necessary here.)

good luck,

richard

On Jul 21, 2006, at 4:22 PM, Mark Kegel wrote:

> I recently read in a tutorial (or somewhere) that FileChooserDialog is
> extendable with your own widgets. You should just be able to add
> whatever widgets you want since FileChooserDialog inherits from
> Container. You may be able to then grab the text from a widget and
> send that text as a filter to the file chooser. Just a thought.
>
> Mark Kegel
>
> On 7/21/06, Surya Kiran Gullapalli  
> <[EMAIL PROTECTED]> wrote:
>> Why not give user additional filter pattern, using regex. (another  
>> window
>> opening up to specify the pattern.)
>>
>> If you use regex then take look at pcre and Boost.Regex.
>>
>> SUrya
>>
>> ___
>> gtk-list mailing list
>> gtk-list@gnome.org
>> http://mail.gnome.org/mailman/listinfo/gtk-list
>>
>>
>>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: Threads...

[Richard Boaz]

from inside your init routine, whenever you require your message box:

g_idle_add() a function to make the message box.  this function  
should be gtk+ library aware and your message box will be made  
without problems.

and that's it.

richard

On Jul 25, 2006, at 6:00 PM, Christian Schaubschlaeger wrote:

>
> Hello!
>
> I have kind of a conceptual problem concerning a multithreaded app.
> Let me describe the following small scenario:
>
> Below you can see a very simple gtk+ program (or at least the  
> important
> parts of it). In the main function the threads environment is  
> initialized,
> then a "dialog_init" is created and shown:
>
> int main(int argc, char **argv)
> {
>   if (!g_thread_supported ())
>   {
>   g_thread_init (NULL);
>   gdk_threads_init();
>   printf("Threads initialized\n");
>   }
>   else
>   {
>   printf("Threads not supported!\n");
>   exit(1);
>   }
>   gtk_init(&argc, &argv);
>
>   dialog_init = create_dialog_init();
>   gtk_widget_show(dialog_init);
>
>   gdk_threads_enter();
>   gtk_main();
>   gdk_threads_leave();
> }
>
> The purpose of this "dialog_init" is to
>
>   1) call the function "init_app()", which does the actual  
> initialization stuff
>  (which takes a long time), and
>
>   2) display and update a progress bar until init_app() is finished.
>
> I have implemented this in the following way, which actually works  
> fine:
>
> void on_dialog_init_show()
> {
>   ...
>   g_timeout_add(10,on_dialog_init_login_update_pb,NULL);
>   g_init = g_thread_create(t_init,NULL,FALSE,&error);
> }
>
> gboolean on_dialog_init_login_update_pb(gpointer data)
> {
>   ... update the progress bar...
>   if (init_finished) return FALSE;
>   else return TRUE;
> }
>
> void *t_init(void *p)
> {
>   init_app();
>   init_finished = 1;  // global var, indicates that init_app() has  
> finished
>   return NULL;
> }
>
> on_dialog_init_login_update_pb is called periodically and updates  
> the pb,
> until init_app is finished.
>
> Now during initialization it is necessary to occasionally popup  
> messageboxes,
> ie. it might be the case, that from somewhere within init_app() a  
> messagebox
> is shown.
>
> init_app() is a function which doesn't know anything about gtk+  
> (since I want
> it to be independent from a GUI), therefore I provide a callback  
> function
> (cb_messagebox) to init_app, which - when called - shows a messagebox.
>
> Since init_app() runs in a separate thread, it is necessary to use
> gdk_threads_enter and gdk_threads_leave, therefore I have changed the
> thread function to:
>
> void *t_init(void *p)
> {
>   gdk_threads_enter();
>   init_app(cb_messagebox);
>   gdk_threads_leave();
>
>   init_finished = 1;  // global var, indicates that init_app() has  
> finished
>   return NULL;
> }
>
> void cb_messagebox(char *msg_text)
> {
>   // popup a gtk+ messagebox displaying
>   // msg_text
>   ...
>   gtk_dialog_run(...);
>   ...
> }
>
> Unfortunately now the progress bar is no longer updated, which is  
> quite clear,
> since the call to gdk_threads_enter in t_init blocks all 'drawing  
> requests'
> from outside this thread, especially those from the progress bar,  
> until
> gdk_threads_leave is called.
>
> My question now is: how can I solve or avoid this problem?
> I _need_ to popup messageboxes from within init_app (which forces  
> me to use
> gdk_threads_enter), but I still want the progress bar to be updated.
>
> What I could do is not to use gdk_threads_enter in t_init, but in
> cb_messagebox (before the call to gtk_dialog_run), but this is not  
> a good
> soluion, since cb_messagebox is sometimes called from within a  
> separate
> thread, and sometimes from within the main process (which inhibits  
> the use of
> gdk_threads_enter).
>
> Tricky...
>
> Looking forward for suggestions!
> Thanks!
> Christian
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: problem displaying rgb images on window

[Richard Boaz]

your problem is that the gtk_widget_show_all() routine is responsible for
rendering widgets, not updating the display with the latest version of
whatever underlying pixmap is to be rendered to the screen.

you should implement a new paradigm for rendering your images, thus:

1) all pixmap rendering should happen through the expose event callback
for the drawing area (widget made at startup) responsbile for displaying
the image.

2) the routine responsible for converting the data to an image should
create the new pixmap and make this new pixmap available to the expose
event for rendering, followed by a call to gtk_widget_queue_draw_area() to
force the expose event to be called.

an example of this logic could be:

GdkPixmap *dispPmap;
GtkWidget *DrawingArea;

gboolean pmap_expose(GtkWidget *widget, GdkEventExpose *event, gpointer none)
{
  gdk_draw_drawable(widget->window, widget->style->fg_gc[GTK_WIDGET_STATE
(widget)], dispPmap, event->area.x, event->area.y, event->area.x,
event->area.y, event->area.width, event->area.height);
  return TRUE;
}

void makeDrawing()
{
 static GdkPixmap *pixbuf;
 while(!feof(fp))
 {
  decode();
  convert_yuv_to_rgb();

  if(pixbuf)
g_object_unref(pixbuf);
  pixbuf =
gdk_pixbuf_new_from_data(rgb_buffer,0,0,8,width,height,width,NULL,NULL);
  dispPmap = pixbuf;
  gtk_widget_queue_draw_area(DrawingArea, 0, 0,
DrawingArea->allocation.width, DrawingArea->allocation.height);
  while (gtk_events_pending())
gtk_main_iteration();
 }  // end while
 g_object_unref(pixbuf);
 pixmap=NULL;
}

in this manner, a single call to makeDrawing() from anywhere (internal to
the program, or as a result of a user request) will end up doing what you
want.

richard

> Hi,
> I am writing an application using GTK+ (version 2.10.0) for x86 pc.
> Iam decoding an mp4 video stream and displaying the RGB data on the
> window.
> This is in a loop.
>
> while(!feof(fp))
> {
>
> decode(); //decodes one frame of mp4 data to yuv format
> convert_yuv_to_rgb(); //converts one frame of decoded  yuv data to rgb
> format
>
> /* Iam using the following code to render the rgb data on display window
> */
>
> pixbuf =
> gdk_pixbuf_new_from_data(rgb_buffer,0,0,8,width,height,width,NULL,NULL);
> gtk_image_set_from_pixbuf(image_display,pixbuf);
> gtk_widget_show_all(display_window); //image_display is contained in this
> window
> g_object_unref(pixbuf);
>
> }
>
> Now my problem is that the decoding and conversion is happening at a very
> high rate but the display changes only once in a while and out of 370
> frames
> decoded only abt 8 to 10 are displayed. I also observed that clicking on
> the
> application or any button increases the number of frames displayed.
> Please let me know the solution to this or if there is any better way to
> display rgb images on the window.
>
> Thanks
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: Question about gtk_label_set_justify()

[Richard Boaz]

hi,

so far, all discussion of this problem has related to whether or not a
solution resides wholly withing gtk/pango/cairo/whatever.

it would seem to me that the fact that gtk/pango/cairo/whatever does not
provide a built-in solution for chinese style justification only means
that the solution must be found elsewhere.

namely, before rendering the label string, provide your own function that
creates the string exactly as you would want it to be displayed, simply
using spaces to fill out the string accordingly, and then provide this new
string to render the label.

whynot?

richard

> Yes ,I am chinese
>
>  First ,I am apologize for my terribly  English
> I am a junior student of a college
>
>   Actually,in my application,I use chinese  characters,
>   The user of my application need the texts   fully justified
>
>  In china,pepole like the characters in alignment
>  both horizontal  and vertical
>
>  In fact, many word prossesor provide  full justification,
>  such as Microsoft word and Kingsoft WPS
>
>  One  chinese character like a squale,
>  So we certainly want  a line of chinese characters like a rectangle
>
>  I am newbie of gtk+
>  So I may not  make my text fully justified,since gtk+ not provide
> this justification  for now
>
> Thank you very much !
> With best wishes
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: Question about gtk_label_set_justify()

[Richard Boaz]

i would achieve this thus:

// calculate the total space required to render the string (string  
here contains no spaces):
string_width_in_pixels = string_width(string_to_render);//  
string_width() function is implementation specific

// leaving us with how much white space is required to be inserted:
total_white_space_in_pixels = label_widget_width_in_pixels -  
string_width_in_pixels;

// compute the pixels for a space (' '):
space_pixels = string_width(" ");

// total white space required between each character
space_fill_in_pixels = total_white_space_in_pixels /  
(total_characters_in_display_string - 1)

spaces_required = space_fill_in_pixels / space_pixels;

and now we have enough information to make our string by hand, one  
character at a time, evenly distributing the displayed characters:

for(i=0;i On Wed, Jul 26, 2006 at 07:09:40AM +0200, Richard Boaz wrote:
>> so far, all discussion of this problem has related to whether or  
>> not a
>> solution resides wholly withing gtk/pango/cairo/whatever.
>>
>> it would seem to me that the fact that gtk/pango/cairo/whatever  
>> does not
>> provide a built-in solution for chinese style justification only  
>> means
>> that the solution must be found elsewhere.
>>
>> namely, before rendering the label string, provide your own  
>> function that
>> creates the string exactly as you would want it to be displayed,  
>> simply
>> using spaces to fill out the string accordingly, and then provide  
>> this new
>> string to render the label.
>>
>> whynot?
>
> How do you achieve an exact width just by adding spaces?
>
> If the program is Chinese-only and gives up the possibility
> to be ever internationalized right away, well, one can
> create a Pango layout, measure all the glyphs in the label,
> calculate the space to put between them and then render the
> glyphs one by one to the calculated positions -- this all
> encapsulated in a new widget, something like MyChineseSpreadLabel.
> Of course this assumes there is an easy way to tell how
> a string is broken to glyphs for Chinese.
>
> Yeti
>
>
> --
> Anonyms eat their boogers.
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: problem with gtk_list_store_set

[Richard Boaz]

hi,

the gtk_list_store_set() function only sets the values of the current row
defined by iter.

you must add a new row individually with the function
gtk_list_store_append() before setting the actual values for the new row
with gtk_list_store_set().

richard

> Hello , i got a little problem with this fuction , when i try to add a new
> item to the list , it erase the last one , in final i got one item in my
> list , and i want 5 items for example , this a piece of the code:
>
> if(gtk_spin_button_get_value(GTK_SPIN_BUTTON(moy))>9.26)
> {
> strcpy(success,"Successed") ;
> pass=TRUE;
> }
> else {
>  strcpy(success,"Dismissed");
>  pass=FALSE;
>  }
> gtk_list_store_set(store,&iter,
> STUDENT_COLUMN,gtk_entry_get_text(GTK_ENTRY(name)) ,
> MOY_COLUMN,gtk_spin_button_get_value(GTK_SPIN_BUTTON(moy)),
> PASS_COLUMN,pass,
> MENTION_COLUMN,success,
> -1);
> Please help
>
> _
> Testez Windows Llive Mail Beta !
> http://www.msn.fr/newhotmail/Default.asp?Ath=f
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Re: how we can create folder in Gtk+2

[Richard Boaz]

better than any folder, is this:

http://www.catb.org/~esr/faqs/smart-questions.html

On Jul 27, 2006, at 2:10 PM, cnu_sree wrote:

>
> how we can create folder in Gtk+2.
>
> --  
> View this message in context: http://www.nabble.com/how-we-can- 
> create-folder-in-Gtk%2B2-tf2009168.html#a5519775
> Sent from the Gtk+ - General forum at Nabble.com.
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: Pixmap

[Richard Boaz]

hi,

one possible paradigm is to adhere to the following guidelines:

1) the configure event callback is responsible for calling all  
routines responsible for "drawing" the pixmap for ultimate display,  
but does NOT do the actual display to the screen;

2) the expose event callback is responsible for rendering the current  
pixmap to be displayed to the screen, but does NO "drawing" here,  
only render the pixmap to the screen via gdk_draw_drawable() or  
equivalent;

3.1) the drawing routine(s) are responsible for creating the pixmap  
for ultimate display;

3.2) store the address of the pixmap in a variable that the expose  
event callback also has access to (global or otherwise)

3.3) the last command as part of the drawing routine is to call  
gtk_widget_queue_draw_area() on the widget used to display
the pixmap; this will force an expose event

in this manner, your drawing routine is called on all configure  
events followed immediately by the expose event rendering the pixmap  
to the screen.  while calling your drawing routine via a user-event,  
or some other event internal to the program, will also result in the  
expose event being called to render the newly made pixmap to the screen.

so, in your case, you would attach the button-click to a callback  
ultimately calling your pixmap drawing routine.  the drawing routine  
will then be called on button-click and your new pixmap will be  
rendered via the expose event.

cheers,

richard

On Aug 2, 2006, at 11:43 AM, Roses Roses wrote:

> Hi!!!
>
> I'm programming a little interface but I have a  prblem. The  
> objective of
> this program is shows a pixmap qhich must ghange qhen the user  
> clicks on  a
> button. How the fuction of the button can change the pixmap assigned?
>
> One idea I've is declare  the GtkPixmap as a global variable, but  
> I'm not
> sure if this plan can run.
>
> Thank you very much
>
> _
> Descarga gratis la Barra de Herramientas de MSN
> http://www.msn.es/usuario/busqueda/barra?XAPID=2031&DI=1055&SU=http% 
> 3A//www.hotmail.com&HL=LINKTAG1OPENINGTEXT_MSNBH
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: Pixmap (II)

[Richard Boaz]

Hi,

1) gtk_pixmap_new() is old and should not be used; I think you want  
to be using gtk_image_new_from_pixmap() instead.
2) though that said, if the image is going to be changing during the  
course of the program, you might want to do it differently (depending):
2.1) create the image widget at app startup with gtk_image_new()
2.2) then, in your drawing routine, once you've got your pixmap, set  
the image widget with gtk_image_set_from_pixmap()
3) and I believe, in the case of using an image widget, you do not  
need to manage configure and expose events yourself, they are  
internally managed, so this part of my explanation is not relevant/ 
valid; you can execute your drawing routine (to get the pixmap and  
then place it in the image) and be done.

(I do not use the Gtk image myself, so if any of the above is wrong,  
would someone else please correct me?)

Rather, the paradigm I laid out below I use for DrawingArea widgets  
and displaying pixmaps therein; drawing area widgets require the user  
manage the configure() and expose() events themselves.

richard

On Aug 9, 2006, at 10:13 AM, Roses Roses wrote:

> Hi!
>
> I've read your solution, but I haven't obtained the correct answer.
>
> My drawable routine is the next:
>
>   GdkBitmap *masc; // Mascara de bits
>   GtkStyle *stile; // Estilo
>   stile = gtk_widget_get_style(window);
> pixmap=gdk_pixmap_create_from_xpm(window->window,&masc,&stile->bg 
> [GTK_STATE_NORMAL],"gtk.xpm");
> //pixmap is a GdkPixmap and gtk.xpm is the new path of the new image
>   pixmapwid= gtk_pixmap_new (pixmap, masc); //pixmapwid is a GtkWidget
>   gtk_widget_queue_draw_area(pixmapwid,0,0,900,400);
>   gtk_widget_show(pixmapwid);
>
> But seems it's not correct. Have I any erro?
>
> Thanks!!
>
> 
>
> hi,
>
> one possible paradigm is to adhere to the following guidelines:
>
> 1) the configure event callback is responsible for calling all   
> routines
> responsible for "drawing" the pixmap for ultimate display,  but  
> does NOT do
> the actual display to the screen;
>
> 2) the expose event callback is responsible for rendering the current
> pixmap to be displayed to the screen, but does NO "drawing" here,   
> only
> render the pixmap to the screen via gdk_draw_drawable() or   
> equivalent;
>
> 3.1) the drawing routine(s) are responsible for creating the  
> pixmap  for
> ultimate display;
>
> 3.2) store the address of the pixmap in a variable that the expose   
> event
> callback also has access to (global or otherwise)
>
> 3.3) the last command as part of the drawing routine is to call
> gtk_widget_queue_draw_area() on the widget used to display
> the pixmap; this will force an expose event
>
> in this manner, your drawing routine is called on all configure   
> events
> followed immediately by the expose event rendering the pixmap  to the
> screen.  while calling your drawing routine via a user-event,  or  
> some other
> event internal to the program, will also result in the  expose  
> event being
> called to render the newly made pixmap to the screen.
>
> so, in your case, you would attach the button-click to a callback
> ultimately calling your pixmap drawing routine.  the drawing  
> routine  will
> then be called on button-click and your new pixmap will be   
> rendered via the
> expose event.
>
> cheers,
>
> richard
>
> On Aug 2, 2006, at 11:43 AM, Roses Roses wrote:
>
>   Hi!!!
>
> I'm programming a little interface but I have a  prblem. The   
> objective of
> this program is shows a pixmap qhich must ghange qhen the user   
> clicks on  a
> button. How the fuction of the button can change the pixmap assigned?
>
> One idea I've is declare  the GtkPixmap as a global variable, but   
> I'm not
> sure if this plan can run.
>
> Thank you very much
>
> _
> Horóscopo, tarot, numerología... Escucha lo que te dicen los astros.
> http://astrocentro.msn.es/
>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>
>

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

Re: problem displaying rgb images on window

[Richard Boaz]

hi,

the gtk_widget_queue_draw_area() creates/forces an expose event on  
the drawing area in question; this event, then, to be processed by  
the mainLoop.

the while loop, then, forces all outstanding events sitting in the  
mainLoop event queue to be processed until all events are exahusted;  
essentially forcing your expose event callback code to be executed,  
immediately.  (and, using this paradigm, this is the reason, too, you  
should do no drawing in the expose event except to render the pixmap  
to the physical display, i.e., it must be the end-point in the entire  
process of making and displaying your image).

you also use this while loop construct, for example, when wanting to  
update a progress meter while doing work in the background (that's  
being metered).

ta,

richard


On Aug 15, 2006, at 1:59 PM, Daniel Haude wrote:

> On Wed, 26 Jul 2006 06:41:38 +0200, Richard Boaz <[EMAIL PROTECTED]>  
> wrote:
>
>>   gtk_widget_queue_draw_area(DrawingArea, 0, 0,
>> DrawingArea->allocation.width, DrawingArea->allocation.height);
>>   while (gtk_events_pending())
>> gtk_main_iteration();
>>  }  // end while
>
> What is the while loop for?
>

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

Re: getting an image from gtkdrawingarea

[Richard Boaz]

Hi,

I'm a bit confused about some things in your original post and so don't
really know what's going on to be of precise help, but some thoughts
nonetheless:

1) the speed of the expose event, whether for a GtkImage or a
GtkDrawingArea, is a function of how much code must be executed as part of
the expose event itself, not a function of the type of widget displaying
the image.  In other words, I do not think your proposed solution is the
correct one.

2) when you say the background of the drawing area is displayed when
covered and then uncovered, why is this the case?  the expose event should
re-render the display area to contain the whole image currently displayed
there.  Meaning, I'm not convinced the problem is fully understood quite
yet, and unless the problem is correctly understood, searching for a
solution can only make things more confusing (and wronger) in the long
run.

One way of achieving the effect you want (while also guaranteeing quick
re-drawing of uncovered display areas, of whatever type) is to do no real
drawing in the expose event itself.
You achieve this by doing all drawing commands to a pixmap (generated from
within the configure event and/or explicit events, either internally- or
user-generated), and not to the screen.

The expose event should contain only one drawing command, namely,
gdk_draw_drawable(), responsible for rendering the pixmap to the screen. 
This way, all expose events will immediately render the image to the
screen, leaving no display background to be seen.

You say you have an animation, which may necessarily complicate matters,
though conceptually nothing changes.  But, to that end, is your program
constructed such that the animation still occurs even when the display
area is partially or fully covered?  Is the user responsible for turning
it on and off or is it simply always 'on'?

Basically, if you manage an internal pixmap holding the current image to
be displayed, you can achieve what you require without all the gymnastics
of managing different types of display widgets depending on context; a
solution which should be avoided where possible.

cheers,

richard

> Hi all,
>
> I'm still stuck on this issue.  The previous post was my first to the
> list,
> so if I need to give extra info or add anything to the post I'd be happy
> to
> do so.
>
> Thanks
>
>
> On 9/22/06, Michael L. Gualtieri <[EMAIL PROTECTED]> wrote:
>>
>> I'm writing an app that has several cairo animations inside
>> gtkdrawingareas.  Unfortunately, everytime the window is covered and
>> uncovered the expose events show the ugly grey background of the drawing
>> area instead of my nice cairo surface.
>>
>> I have noticed that GtkImages expose much quicker than a GtkDrawingArea.
>> Is there a way to convert the contents of a gtkdrawingarea to a GtkImage
>> or
>> other type that is easily drawable on the screen?
>>
>> My idea is that I can draw an image of the drawing area while it is
>> static, and then when I need to animate it, I will replace it back with
>> the
>> drawing area.
>>
>> Thanks!
>>
>>
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>


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

Programmatically Collapsing a Widget

[Richard Boaz]

Hi,

I have a simple dialogue widget holding server names and the  
databases they individually serve.  In the lower half of the dialogue  
I have fields detailing the database information.   These details are  
viewable/hideable via MORE and LESS buttons.

My problem is that when the dialogue is first rendered, the detail  
information is not displayed (all details held within a single widget  
which is hidden), except that the size of the dialogue is the same as  
if it were displayed, i.e., a whole bunch of blank space at the  
bottom.  When hitting the MORE button, the details are displayed  
correctly, and when hitting LESS, are also hidden correctly.  But  
again, same as at startup, the overall dialogue does not collaps to  
the size of only what is on display.

Is there a programmatic way of collapsing a widget to the size of its  
contents which are not hidden?

thanks for any pointers,

richard boaz
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Dialogue Screen Placement

[Richard Boaz]

Hi,

More on dialogues:

I have attempted to use gtk_window_set_position() on my dialogues to  
be centered on the parent (GTK_WIN_POS_CENTER_ON_PARENT), but to no  
avail.  (I have, in fact, tried all possible settings, they are all  
ignored.)  I know screen managers can do whatever they want, but I  
see nothing in the documentation for this call indicating that it may  
fail, i.e., ignored by the screen manager.

I have also tried setting the parent for the dialogue with  
gtk_window_set_transient_for(), but this also had no effect.

Anyone have a clue why this would not work or how to make it work?  I  
find it annoying and ugly that all dialogues come up positioned to  
the upper left-hand corner of the screen.

thanks,

richard boaz
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list

Re: Programmatically Collapsing a Widget

[Richard Boaz]

After investigating a little more myself, the solution seems to be  
rather straightforward:

calling gtk_window_resize(dialogue, 1, 1) collapses the dialogue to  
the minimum size required to display the dialogues contents.

If anybody has another interesting method, please forward, I prefer  
to know multiple ways of getting where I need to be.  At the same  
time, this problem is now solved.

cheers,

richard

On Sep 26, 2006, at 3:50 PM, Richard Boaz wrote:

> Hi,
>
> I have a simple dialogue widget holding server names and the
> databases they individually serve.  In the lower half of the dialogue
> I have fields detailing the database information.   These details are
> viewable/hideable via MORE and LESS buttons.
>
> My problem is that when the dialogue is first rendered, the detail
> information is not displayed (all details held within a single widget
> which is hidden), except that the size of the dialogue is the same as
> if it were displayed, i.e., a whole bunch of blank space at the
> bottom.  When hitting the MORE button, the details are displayed
> correctly, and when hitting LESS, are also hidden correctly.  But
> again, same as at startup, the overall dialogue does not collaps to
> the size of only what is on display.
>
> Is there a programmatic way of collapsing a widget to the size of its
> contents which are not hidden?
>
> thanks for any pointers,
>
> richard boaz
> ___
> gtk-list mailing list
> gtk-list@gnome.org
> http://mail.gnome.org/mailman/listinfo/gtk-list
>

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

Re: Dialogue Screen Placement

[Richard Boaz]

Below is a small program demonstrating my problem.

My window manager is Gnome v2.10.0.

In the program, I have set both the main window and the dialogue window to
be positioned at the center of the screen.  Interestingly, for the main
window, this works fine; it is only for the dialogue that the position
command seems to be ignored.

Any ideas why this is behaving so?

All thoughts/input appreciated.

cheers,

richard boaz


=== BEGIN PROGRAM ==

#include 
int nums[3] = {0, 1, 2};
void doDialogue(GtkButton *but, int *action)
{
  static GtkWidget *dialogue;
  GtkWidget *button;

  switch(*action)
  {
case 0:  // make and realize dialogue widget
  if (!dialogue)
  {
dialogue = gtk_window_new (GTK_WINDOW_TOPLEVEL);
g_signal_connect (dialogue, "destroy", G_CALLBACK (doDialogue), 
&nums[2]);
button = gtk_button_new_with_label("Cancel");
g_signal_connect((button), "clicked", G_CALLBACK(doDialogue), &nums[1]);
gtk_container_add(GTK_CONTAINER (dialogue), button);
gtk_widget_show_all(dialogue);
  }
  gtk_window_set_position(GTK_WINDOW (dialogue), GTK_WIN_POS_CENTER);
  gtk_widget_show(dialogue);
break;

case 1:  // hide the dialogue
  gtk_widget_hide(dialogue);
break;

case 2:  // dialogue has been destroyed, record
  dialogue = NULL;
break;
  }
}

int main(int argc, char **argv)
{
  GtkWidget *mainWin, *button;

  gtk_init(&argc, &argv);
  mainWin = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  g_signal_connect (mainWin, "destroy", G_CALLBACK (gtk_main_quit), NULL);
  button = gtk_button_new_with_label("Dialogue");
  g_signal_connect((button), "clicked", G_CALLBACK(doDialogue), &nums[0]);
  gtk_container_add(GTK_CONTAINER (mainWin), button);

  gtk_window_resize (GTK_WINDOW (mainWin), 250, 250);
  gtk_window_set_position(GTK_WINDOW (mainWin), GTK_WIN_POS_CENTER);
  gtk_widget_show_all(mainWin);

  gtk_main();
}

 END PROGRAM 

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

Re: Dialogue Screen Placement

[Richard Boaz]

Thanks, John, that works great!

cheers,

richard

On Sep 27, 2006, at 1:01 PM, John Cupitt wrote:

> On 9/27/06, Richard Boaz <[EMAIL PROTECTED]> wrote:
>> Below is a small program demonstrating my problem.
>
> Here's a working version of your prog. The main problem was that you
> were setting the position hint after showing the dialog. So when the
> WM was selecting a position, there was no position hint set by you.
>
> I noticed a couple of other minor things, though I guess you know
> these anyway and this is just a test prog:
>
> - use gtk_window_set_default_size() to set the start size for your  
> main window
>
> - best to let the WM position the main window for you, rather than
> setting the CENTER hint (that's mostly for things like splash screens
> I think)
>
> - the dialog should be positioned with GTK_WIN_POS_CENTER_ON_PARENT
>
> - you need to use gtk_window_set_transient_for() to get the WM to
> preserve your main window / dialog stacking order ... this is
> especially important on win32
>
> -
> #include 
>
> int nums[3] = { 0, 1, 2 };
>
> void
> doDialogue (GtkButton * but, int *action)
> {
>  static GtkWidget *dialogue;
>  GtkWidget *button;
>
>  switch (*action)
>{
>case 0: // make and realize dialogue widget
>  if (!dialogue)
>{
>  dialogue = gtk_window_new (GTK_WINDOW_TOPLEVEL);
> gtk_window_set_transient_for (GTK_WINDOW (dialogue),
>GTK_WINDOW (gtk_widget_get_toplevel (GTK_WIDGET (but;
>  gtk_window_set_position (GTK_WINDOW (dialogue),
> GTK_WIN_POS_CENTER_ON_PARENT);
>  g_signal_connect (dialogue, "destroy", G_CALLBACK  
> (doDialogue),
>&nums[2]);
>  button = gtk_button_new_with_label ("Cancel");
>  g_signal_connect ((button), "clicked", G_CALLBACK  
> (doDialogue),
>&nums[1]);
>  gtk_container_add (GTK_CONTAINER (dialogue), button);
>  gtk_widget_show_all (dialogue);
>}
>  gtk_widget_show (dialogue);
>  break;
>
>case 1: // hide the dialogue
>  gtk_widget_hide (dialogue);
>  break;
>
>case 2: // dialogue has been destroyed, record
>  dialogue = NULL;
>  break;
>}
> }
>
> int
> main (int argc, char **argv)
> {
>  GtkWidget *mainWin, *button;
>
>  gtk_init (&argc, &argv);
>  mainWin = gtk_window_new (GTK_WINDOW_TOPLEVEL);
>  g_signal_connect (mainWin, "destroy", G_CALLBACK (gtk_main_quit),  
> NULL);
>  button = gtk_button_new_with_label ("Dialogue");
>  g_signal_connect ((button), "clicked", G_CALLBACK (doDialogue),  
> &nums[0]);
>  gtk_container_add (GTK_CONTAINER (mainWin), button);
>
>  gtk_window_set_default_size ( GTK_WINDOW (mainWin), 250, 250);
>  gtk_widget_show_all (mainWin);
>
>  gtk_main ();
> }
> -
>

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