Re: Xlib: unexpected async reply (sequence #####)!
On Sun, 2007-08-05 at 11:29 +0800, Gregory Hosler wrote:
I'm looking for code examples specifically on how to use/implement
g_idle_add().
Know any projects that uses g_idle_add() and related infrastructure?
static gboolean
make_insensitive_idle_cb(gpointer data)
{
GtkWidget *widget = GTK_WIDGET(data);
gtk_widget_set_sensitive(widget, FALSE);
/* Return FALSE so as not to keep executing this function over and over
again */
return FALSE;
}
static gpointer
my_thread(gpointer data)
{
/* ... do something of long duration, during which ... */
g_idle_add(make_insensitive_idle_cb, some_widget);
/* ... do the rest of the long duration stuff ... */
return NULL;
}
Have a look at
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#id2603517
HTH,
Gabriel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
On Sun, 2007-08-05 at 11:24 +0800, Gregory Hosler wrote: The main loop is already protected (by threads_enter()/threads_leave() so I didn't need to add any code at all to the main code (and I don't have any timeout callbacks either), so the only places I needed to add the threads_enter/leave was in the threads (2 small ones) themselves. That's fine, except that you will also need it in any handler called from the glib main loop, such as GIOChannel callbacks, child watch callbacks and any custom GSource objects that you attach to the main loop, where any of these call GDK/GTK+ functions. having said that... That is why using g_idle_add() is often a better approach. just looked at the man/devhelp page. Looks interesting. I'm looking for some code examples. actual working examples would be nice. All you need to do is have an idle handler returning FALSE which calls the GDK/GTK+ functions that you want to have executed from the calling thread. The only other point to remember is that you need to ensure that any data passed by reference via the data argument is still valid when the main loop executes the idle handler, which usually means that you need to allocate it on the heap and free it in the idle handler when you are finished with it. Chris ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Xlib: unexpected async reply (sequence #####)!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gabriel Schulhof wrote:
On Sun, 2007-08-05 at 11:29 +0800, Gregory Hosler wrote:
I'm looking for code examples specifically on how to use/implement
g_idle_add().
Know any projects that uses g_idle_add() and related infrastructure?
static gboolean
make_insensitive_idle_cb(gpointer data)
{
GtkWidget *widget = GTK_WIDGET(data);
gtk_widget_set_sensitive(widget, FALSE);
/* Return FALSE so as not to keep executing this function over and over
again */
return FALSE;
}
static gpointer
my_thread(gpointer data)
{
/* ... do something of long duration, during which ... */
g_idle_add(make_insensitive_idle_cb, some_widget);
/* ... do the rest of the long duration stuff ... */
return NULL;
}
Have a look at
http://developer.gnome.org/doc/API/2.0/glib/glib-The-Main-Event-Loop.html#id2603517
I actually had a look at that page prior to my post. It didn't answer some of
the basic questions / concerns I had.
Your example clears up alot of stuff for me. One of my questions (that your
example pretty much clarifies for me), was what do I g_idle_add() ?
If I understand correctly, you basically add callback functions, and in
particular, ones that are gtk/gdk related (i.e. that deal with the displaying of
widgets).
is this more or less correct ?
so, um, when a g_idle_add does a gtk_widget_show() on a widget, and that
widget would get displayed as part of the main thread.
Am I correct to say that things like gtk_label_new(), and all the related calls
to build a label widget, can be done in a thread, but the show must be done in
the main loop (via the g_adle_add() call) ?
If there a list (or guideline) of which gtk_calls should be done in the idle,
and which need not be ?
many thanks,
- -Greg
HTH,
yes, it did!
- -G
Gabriel
- --
+-+
Please also check the log file at /dev/null for additional information.
(from /var/log/Xorg.setup.log)
| Greg Hosler [EMAIL PROTECTED]|
+-+
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGtb57404fl/0CV/QRAtJHAKCcPTvYTNlvKN71ttWyEGUTkuBd2ACcDmvx
eJuwrFcdbeHq0vHmnwBHets=
=S79l
-END PGP SIGNATURE-
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Which OS are supported by GLib?
Hello! Where can I find information about operating systems supported by GLib? -- Cya! Tom ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 04:24 +0200, Milosz Derezynski wrote:
Just FWIW, can we agree on one meaning of transactional?
For me, the fact that the model shouldn't have to know about the
number of views showing it has nothing to do with transactionality:
there may be multiple views on the model, and when changing the
model, one
should not be required to know about the number of views. excellent
point, end of story for me. it ought to be transactional.
I think the most sensible meaning is the one we e.g. know from SQL and
which Kris mentioned: One atomic changeset which can be committed to
the model in one run. (It can probably not be rolled back, or if it
would be possible, then it'd be quite expensive, but that's not really
the point anyway).
For me, what is important is that MVC is that what it is supposed to be:
- View observes Model
And not:
- Some extra code done by the application developer observes for
the View the Model, because the View can't cope with the actual
MVC paradigm.
The simplicity of MVC is also what makes it so useful. By assuming that
the application developer will solve all the problems that the normal
View observes Model solves (he has to reset the model, he has to reset
the view's state, he has to detect changes to the model, ...) you void
the simplicity.
If the view internally actually resets its model, then that's fine.
It's a complexity that got solved by the View and didn't have to be
solved by the application developer. If it's more easy for Kris to
internally swap the Model (reloading everything and recovering the
state, like sorting --in case of a sortable -- or selection details),
then that's fine from the application developer's point of view.
As for the model-should-be-view-ignorant issues, they have nothing to
do with transactions, but are just as valid concerns of course.
On 8/5/07, Paul Davis [EMAIL PROTECTED] wrote:
On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
The model itself is the source. The view is just a
viewer for it. The
source itself doesn't change. The content of the source
changes. The
view, being an observer of the model in the MVC
paradigm, should adapt
to the changes. It should not require a sudden set and
unset of its
model.
I'm a big user of MVC. Although on some level I agree with
you, I would
ask what the difference is between:
void gtk_treeview_freeze (GtkTreeView* tv) {
/* store model in tv, then unset */
}
void gtk_treeview_thaw (GtkTreeView* tv) {
/* reset model in tv */
}
Owk .. it's a bit lengthy and there are a lot of personal
opinions
about MVC embedded in this one:
it didn't need to be so lengthy :) thats why i noted that i
use MVC a
*lot* myself. the key point you raise is one that i had
forgotten: there
may be multiple views on the model, and when changing the
model, one
should not be required to know about the number of views.
excellent
point, end of story for me. it ought to be transactional.
--p
___
gtk-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Support for a new scripting language.
Hello to the list readers. Sorry for being impolite and jumping in, but it seems there is no other mean to contact GTK developers. I lead a project for a new embeddable open source scripting language called The Falcon Programming Language: http://www.falconpl.org We have just released a stable version of our scripting language and we would like to provide a module to integrate GTK+. Actually, what we would like to do is to provide an abstract windowing system, of which GTK+ would then be the first (and preferred) driver. However, we would glad do have also a pure GTK+ binding, or possibly both the AWS and the binding. I feel most comfortable in programming with GTK+, and I regard GTK+ as the library that allows faster GUI programming and better GUI design-from-code (i.e. what-you-program-is-what-you-get) i've ever come in touch with; and I know a few. In the past, I realized a GTK+ based GUI interface for a language called Xharbour (an X-Base descendant), so I am not completely new to the topic. What we're missing now are programming hands; if you or someone you know may be interested in participate our project, please contact me or register with the forum at our server: http://www.falconpl.org/forum Anyhow, I hope I can count on the assitance of the people in this list in our development effort, were we in need for some advice. TIA, Giancarlo Niccolai. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: Support for a new scripting language.
Giancarlo Niccolai wrote: Hi Giancarlo, Very nice that you want to make GTK+ bindings for your scripting language. While there are several subscribers to this list with a lot of experience in binding GTK+ in various languages (I'm not one of them), you might also want to join the [EMAIL PROTECTED] [1] mailing list. Good luck! Best Regards, Mikael Hallendal [1] http://mail.gnome.org/archives/language-bindings/ Hello to the list readers. Sorry for being impolite and jumping in, but it seems there is no other mean to contact GTK developers. I lead a project for a new embeddable open source scripting language called The Falcon Programming Language: http://www.falconpl.org We have just released a stable version of our scripting language and we would like to provide a module to integrate GTK+. Actually, what we would like to do is to provide an abstract windowing system, of which GTK+ would then be the first (and preferred) driver. However, we would glad do have also a pure GTK+ binding, or possibly both the AWS and the binding. I feel most comfortable in programming with GTK+, and I regard GTK+ as the library that allows faster GUI programming and better GUI design-from-code (i.e. what-you-program-is-what-you-get) i've ever come in touch with; and I know a few. In the past, I realized a GTK+ based GUI interface for a language called Xharbour (an X-Base descendant), so I am not completely new to the topic. What we're missing now are programming hands; if you or someone you know may be interested in participate our project, please contact me or register with the forum at our server: http://www.falconpl.org/forum Anyhow, I hope I can count on the assitance of the people in this list in our development effort, were we in need for some advice. TIA, Giancarlo Niccolai. ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list -- Imendio AB, http://www.imendio.com/ ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
RE: color of gtk widget
will this change the text color of gtkbutton
style = gtk_widget_get_style (button);
style-text[0]=red color; // is there any API to do this.
gtk_widget_set_style(button, style);
Regards,
Prasanna.
From: Benjamin Berg [mailto:[EMAIL PROTECTED]
Sent: Sat 8/4/2007 6:07 AM
To: [EMAIL PROTECTED]
Cc: Prasanna Kumar K; gtk-devel-list@gnome.org
Subject: Re: color of gtk widget
On Fri, 2007-03-08 at 16:17 +0100, [EMAIL PROTECTED] wrote:
On 8/3/07, Prasanna Kumar K [EMAIL PROTECTED] wrote:
I have a GtkWidget Button. I want the color of the button should be
complete red.
You can do it with a gtkrc. For example, set this resource file:
widget *red_widget style red_style
If you already use a style, you can also use
widget *red_widget* style red_style
instead. And then you just need to set the name on the button and none
of its children. As the label will also be affected with the above line
(because of the trailing *).
Now in your code do:
void
set_name( GtkWidget *widget, const char *name )
{
gtk_widget_set_name( widget, name );
if( GTK_IS_CONTAINER( widget ) )
gtk_container_foreach( GTK_CONTAINER( widget ),
(GtkCallback) set_name, (char *) name );
}
set_name( button, red_widget );
Then a simple gtk_widget_set_name is enough.
The only other choice is to call gtk_widget_modify_fg recursively on all
the widgets.
Benjamin
This message (including any attachment) is confidential and may be legally
privileged. Access to this message by anyone other than the intended
recipient(s) listed above is unauthorized. If you are not the intended
recipient you are hereby notified that any disclosure, copying, or distribution
of the message, or any action taken or omission of action by you in reliance
upon it, is prohibited and may be unlawful. Please immediately notify the
sender by reply e-mail and permanently delete all copies of the message if you
have received this message in error.
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 00:32 +0200, Milosz Derezynski wrote:
--snip--
void
Playlist_V::put_track_at_iter (Track const track,
Gtk::TreeModel::iterator iter)
{
(*iter)[m_track_cr.track] = track;
(*iter)[m_track_cr.uid] = track.bmpx_track_id ;
(*iter)[m_track_cr.localUid] = m_localUid;
(*iter)[m_track_cr.searchKey] = track.title ?
track.title.get() : std::string();
(*iter)[m_track_cr.playTrack] = track.active.get();
--snip--
And yes, this is exactly how it looks like: The row is accessed for
each of those lines, and each uses a separate call to list_store_set()
internally. Yes, it i disastrous to performance. One guy on the
gtkmm-devel list recently made a benchmark and found that the gtkmm
way of doing this is approximately 75 times (not 75% -- 75 times)
slower than the C Gtk+ method.
Youch. And I recently changed Tasks from append/set/implicit sort to
insert at index 0/implicit sort because it is visibly faster on slower
devices (as well as leading to cleaner code, no more row-inserted events
with unset data).
Ross
--
Ross Burton mail: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED]
www: http://www.burtonini.com./
PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
The model itself is the source. The view is just a viewer for it. The
source itself doesn't change. The content of the source changes. The
view, being an observer of the model in the MVC paradigm, should adapt
to the changes. It should not require a sudden set and unset of its
model.
I'm a big user of MVC. Although on some level I agree with you, I would
ask what the difference is between:
void gtk_treeview_freeze (GtkTreeView* tv) {
/* store model in tv, then unset */
}
void gtk_treeview_thaw (GtkTreeView* tv) {
/* reset model in tv */
}
Owk .. it's a bit lengthy and there are a lot of personal opinions
about MVC embedded in this one:
Well I'm in favour of having a strict separation between code that views
data (the view), and code that represents the data (the model).
If you require that using the model is to be adapted or adjusted to
certain limitations, you are requiring that the model's code becomes
specific for the view. Let me explain:
Let's take the example with a person and a view for a person:
Person p = new Person ();
PersonView v1 = new PersonView ();
v1.Model = p;
I have another PersonView open on (another) screen (whether it's another
computer or another process or another whatever is irrelevant for now):
PersonView v2 = new PersonView ();
v2.Model = p;
Imagine I'm working at the p's town administration and I change person
p's name. Let's say we did this in v1.
We'll assume a simple system where each person has one instance in this
global system or where each system gets notified by triggers on the
remote database (quite Utopical, I know. But it's irrelevant. You can
also imagine one computer, one application with two PersonView instances
being visible at the same time, showing the same model -- the same
person instance, as we got the instance from a factory and the instance
is, indeed, the exact same instance --).
In v1's instance (image on_name_textbox_changed indeed happens) :
public class PersonView
{
public Person Model;
private void on_name_textbox_changed (TextBox o, ...) {
this.Model.Name = o.Text;
}
}
Note that maybe some people want to do this with a separate Controller
type, in which case we're in the exact same situation.
Now if we'd require that you always now refresh v1 and v2's model before
either v1 OR v2 (not AND, because v1 can indeed update itself in the
on_name_textbox_changed method, but since PersonView should rather
observer its Model, we usually don't do this --but it can, I know--) ...
... how will v2 get itself updated in time?
It can't, because the view requires getting updated by having it set its
model each time it needs an update.
Now this is a simple example. Whether model is a list of rows, a tree of
things, a bear, a person, a traffic light (which is a typical example),
a remote control for a television ...
Whether the model is a list of 800,000 E-mails. Whether its 300,000 song
titles, ...
Doesn't matter for the MVC theory. You can always have a v1 and a v2
showing the same model instance.
When v1 causes a change to its model, and v2 shares the same instance as
model with v1, v2 should update itself instantly. Because both v1 and v2
observe the model.
Now the update (which gets called by the notify of the observable
model) of PersonView can of course do this internally (resetting its
model, resetting its state, doing this or doing that). That's just an
implementation detail.
In case of GtkTreeView this would mean that GtkTreeView would have to
implement this implementation detail. Not the application developer.
In GtkTreeView's case, if the changes are big .. its right now only
practical (else the performance is very weak, yadi yada) if you unset
the model and reset the model. But that's broken as illustrated in the
example above.
and just calling gtk_treeview_set_model (NULL) and
gtk_treeview_set_model (NOTNULL).
there are additional issues: freeze/thaw semantics require use of a
counter, so that, for example, if 3 nested contexts call freeze, only
the 3rd subsequent call to thaw actually unfreezes. contrast this to
the simplicity of code in which only the top level sets+unsets the
model, and all lower levels act on the model regardless of whether its
connected to a view or not.
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
As a somewhat related topic (this thread seems to not be nailed on a very
specific topic yet and this still fits in i think), a changeset+commit API
(in the truer sense; not what was proposed with just saying all nodes below
this one have changed) would be _very_ welcome for gtkmm, because right
now, setting row data looks like this (snippet from our code):
--snip--
void
Playlist_V::put_track_at_iter (Track const track,
Gtk::TreeModel::iterator iter)
{
(*iter)[m_track_cr.track] = track;
(*iter)[m_track_cr.uid] = track.bmpx_track_id;
(*iter)[m_track_cr.localUid] = m_localUid;
(*iter)[m_track_cr.searchKey] = track.title ? track.title.get() :
std::string();
(*iter)[m_track_cr.playTrack] = track.active.get();
--snip--
And yes, this is exactly how it looks like: The row is accessed for each of
those lines, and each uses a separate call to list_store_set() internally.
Yes, it i disastrous to performance. One guy on the gtkmm-devel list
recently made a benchmark and found that the gtkmm way of doing this is
approximately 75 times (not 75% -- 75 times) slower than the C Gtk+ method.
Now without going to deep into C++, let's just say that with the way gtkmm
at least works, if not to be sane C++ altogether, it's not possible to have
a C-like TreeModel API in gtkmm, and that's where the changesets come in.
I've been already thinking of a transactional system for TreeModel, and i
have some ideas, but nothing that could be put to code right now.
_However_, a native API for this in C TreeModel (perhaps an additional
interface to TreeModel? GtkTreeModelTransactional?) would make this task
very simple because then it could be normally wrapped without needing
gtkmm-specific API.
Kris if you are really on to having a TreeModelTransactional Iface, please
just say yeah, and i'll also start working on something (deadchip in
#gtk+, btw). This would be a major help for the other discussed problems
here, as well as for this one.
-- Milosz
On 6/24/07, Kristian Rietveld [EMAIL PROTECTED] wrote:
On Tue, Jun 19, 2007 at 12:45:09PM +0100, Peter Clifton wrote:
This seems to break the MVC abstraction - if the model changes
drastically, I need to know which tree-views are connected so I can
disconnect them? Bad!
We need some new API I guess - which signals any connected views that
the data it has cached about the model should be invalidated, and that
the model may be changing without emitting signals.
Once the model is updated, a further signal will inform the view that it
can keep cached state again.
In practise this won't be all that different compared to setting a new
model on the tree view, except that with a signal it will be initiated
from the model. After the model emits the I am finished changing
everything signal, the tree view will have to rebuild its internal
rbtree by iterating over the full model again (any other model that is
connected to this model will have to rebuild its internal state tree
too), since it has no clue what has changed. This will probably also
involve unreferencing all nodes when the model emits invalidate and
re-reference the new nodes after the mass changing, and remembering
selection and expansion state during the mass-changing (this information
is kept in the internal rbtree too), etc.
I think a much better solution would be to be able to group a bunch of
changes together in a kind of atomic changeset which is then emitted
with a single signal. All connected views/models could then process the
full changeset in one pass. (Possibly this could also add/remove ranges
of nodes, etc).
regards,
-kris.
___
gtk-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: 'reloading' gtktreeview when model changes drastically
On Sun, 2007-08-05 at 04:24 +0200, Milosz Derezynski wrote:
Just FWIW, can we agree on one meaning of transactional?
For me, the fact that the model shouldn't have to know about the
number of views showing it has nothing to do with transactionality:
there may be multiple views on the model, and when changing the
model, one
should not be required to know about the number of views. excellent
point, end of story for me. it ought to be transactional.
I think the most sensible meaning is the one we e.g. know from SQL and
which Kris mentioned: One atomic changeset which can be committed to
the model in one run. (It can probably not be rolled back, or if it
would be possible, then it'd be quite expensive, but that's not really
the point anyway).
For me, what is important is that MVC is that what it is supposed to be:
- View observes Model
And not:
- Some extra code done by the application developer observes for
the View the Model, because the View can't cope with the actual
MVC paradigm.
The simplicity of MVC is also what makes it so useful. By assuming that
the application developer will solve all the problems that the normal
View observes Model solves (he has to reset the model, he has to reset
the view's state, he has to detect changes to the model, ...) you void
the simplicity.
If the view internally actually resets its model, then that's fine.
It's a complexity that got solved by the View and didn't have to be
solved by the application developer. If it's more easy for Kris to
internally swap the Model (reloading everything and recovering the
state, like sorting --in case of a sortable -- or selection details),
then that's fine from the application developer's point of view.
As for the model-should-be-view-ignorant issues, they have nothing to
do with transactions, but are just as valid concerns of course.
On 8/5/07, Paul Davis [EMAIL PROTECTED] wrote:
On Sun, 2007-08-05 at 00:25 +0200, Philip Van Hoof wrote:
On Sat, 2007-08-04 at 16:51 -0400, Paul Davis wrote:
On Sat, 2007-08-04 at 17:00 +0200, Philip Van Hoof wrote:
The model itself is the source. The view is just a
viewer for it. The
source itself doesn't change. The content of the source
changes. The
view, being an observer of the model in the MVC
paradigm, should adapt
to the changes. It should not require a sudden set and
unset of its
model.
I'm a big user of MVC. Although on some level I agree with
you, I would
ask what the difference is between:
void gtk_treeview_freeze (GtkTreeView* tv) {
/* store model in tv, then unset */
}
void gtk_treeview_thaw (GtkTreeView* tv) {
/* reset model in tv */
}
Owk .. it's a bit lengthy and there are a lot of personal
opinions
about MVC embedded in this one:
it didn't need to be so lengthy :) thats why i noted that i
use MVC a
*lot* myself. the key point you raise is one that i had
forgotten: there
may be multiple views on the model, and when changing the
model, one
should not be required to know about the number of views.
excellent
point, end of story for me. it ought to be transactional.
--p
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
___
gtk-devel-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
--
Philip Van Hoof, software developer
home: me at pvanhoof dot be
gnome: pvanhoof at gnome dot org
http://www.pvanhoof.be/blog
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
implementing a delayed busy cursor
hi --
i want the mouse cursor in my app to only switch to busy after
a brief delay (perhaps 1 second). i have an implementation that
works in some places, but not others, and i'm wondering if
there's a better/safer way.
in my first cut at implementing this i fell back on old habits,
namely, signal handlers. i know using signals within gui apps is
risky -- and in fact the app implements the handle signals via
an event pipe trick to deal with SIGTERM, for this very reason.
but that trick won't work for the busy cursor delay, which really
needs to be asynchronous to program execution.
here's my current code:
void busy_cursor_handler(int signal)
{
set_my_cursor (CURSOR_BUSY);
}
void set_my_cursor (int newcursor)
{
GdkCursor *cursor;
static int lastcursor;
static int delayed;
if (delayed) {
alarm(0);
delayed = 0;
}
if (newcursor == CURSOR_BUSY_WITH_DELAY) {
signal(SIGALRM, busy_cursor_handler);
alarm(1);
delayed = 1;
return;
}
if (newcursor == lastcursor)
return;
lastcursor = newcursor;
switch (newcursor) {
case CURSOR_NORMAL:
cursor = NULL;
break;
case CURSOR_BUSY:
cursor = gdk_cursor_new(GDK_WATCH);
break;
}
gdk_window_set_cursor(MainWindow-window, cursor);
if (cursor) {
gdk_cursor_destroy(cursor);
}
gdk_flush();
}
the app looks roughly like:
...
set_my_cursor(CURSOR_BUSY_WITH_DELAY);
...do stuff that may or may not take a long time (the program
is a mapping program, so processing the data which needs to
be rendered can be costly), which includes calls to gdk and
gtk drawing functions made to update a DrawingArea widget.
the final call is to gtk_widget_draw() to paint it on the
screen...
set_my_cursor(CURSOR_NORMAL);
...
this all seems to work very solidly in current (as in, ubuntu
feisty up-to-date) versions of both GTK 1.2 (1.2.10-18) and GTK2
(2.10.11). this testing was done on a modern x86 laptop (1.6Ghz)
but when i run it on an older GTK 1.2 (1.2.10-17) from debian
sarge, i regularly get lockups, with the app spinning in a loop
down in the X libraries somewhere (i don't have a backtrace
handy). this testing was on a slow handheld device (400Mhz
au1100 mips).
is it possible that the minor revision difference for gtk1.2
could have fixed this problem? somehow i'm skeptical, and
suspect that the problem exists everywhere, but is being exposed
on the older slower hardware.
i tried modifying the above code so that only the gdk_flush()
happened during the signal handler (i even tried changing it
to XFlush(GDK_DISPLAY())), but i still get the lockups.
i figure i have several choices:
- live with restricting the feature to newer versions of GTK,
if indeed it's a problem that's been fixed in newer
releases, and if i can easily determine the version
level at runtime.
- add a user-configurable option to suppress the delay
feature if the user determines it causes lockups. (ugh.)
- implement the delayed busy cursor in a different way
guaranteed to work everywhere. is my implementation
using signals way off base? is there a more standard way
of doing this? my googling came up short.
many thanks.
paul
=-
paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 69.4 degrees)
'02 V-Strom, DoD #1462, AMA #545601
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed busy cursor
On Sun, 2007-08-05 at 11:20 -0400, Paul Fox wrote:
hi --
i want the mouse cursor in my app to only switch to busy after
a brief delay (perhaps 1 second). i have an implementation that
works in some places, but not others, and i'm wondering if
there's a better/safer way.
if (newcursor == CURSOR_BUSY_WITH_DELAY) {
signal(SIGALRM, busy_cursor_handler);
alarm(1);
this is unsafe coding. POSIX signal handlers should do almost nothing,
and they should certainly not call GTK functions.
investigate the use of timeouts within GTK itself, which are *much*
better suited for this purpose.
--p
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed busy cursor
paul davis wrote:
On Sun, 2007-08-05 at 11:20 -0400, Paul Fox wrote:
hi --
i want the mouse cursor in my app to only switch to busy after
a brief delay (perhaps 1 second). i have an implementation that
works in some places, but not others, and i'm wondering if
there's a better/safer way.
if (newcursor == CURSOR_BUSY_WITH_DELAY) {
signal(SIGALRM, busy_cursor_handler);
alarm(1);
this is unsafe coding. POSIX signal handlers should do almost nothing,
and they should certainly not call GTK functions.
investigate the use of timeouts within GTK itself, which are *much*
better suited for this purpose.
okay, thanks -- that confirms my suspicions (and results :-).
will these timeouts (can you point me at an API function i can
search for?) work asynchronously to the main event loop?
paul
=-
paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 72.9 degrees)
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed busy cursor
On Sun, 2007-08-05 at 12:56 -0400, Paul Fox wrote: google gtk timeout - gtk_timeout_add - gtk.org/api - Main Loop Events - gtk_timeout_add has been deprecated since version 2.4 and should not be used in newly-written code. Use g_timeout_add() instead. and no, these run synchronously with the main loop, which is why they are safe to use. --p ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed busy cursor
paul davis wrote: On Sun, 2007-08-05 at 12:56 -0400, Paul Fox wrote: google gtk timeout - gtk_timeout_add - gtk.org/api - Main Loop Events - gtk_timeout_add has been deprecated since version 2.4 and should not be used in newly-written code. Use g_timeout_add() instead. and no, these run synchronously with the main loop, which is why they are safe to use. thanks -- i'll do some reading. at the moment, i'm not sure how this will work. if i set a gtk timeout for 1 second, but my program's think time is 10 seconds, then i won't get back to the event loop until after that, and i've therefore blown my intended timeout. but i've probably just given myself away as the gtk newb that i am, and am probably missing something really obvious, so i'll go do some reading, like i said. (i'm actually kind of surprised there's no gdk_window_set_cursor_after_delay() call, for just this purpose. :-) paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 74.1 degrees) ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed busy cursor
Hi Paul, On Sun, 05 Aug 2007 14:02:22 -0400 you wrote: thanks -- i'll do some reading. at the moment, i'm not sure how this will work. if i set a gtk timeout for 1 second, but my program's think time is 10 seconds, then i won't get back to the event loop until after that, and i've therefore blown my intended timeout. If your program is doing something that will take it 10 seconds, you need to adjust your architecture to shift that operation out of the loop. Either: - Split the big think into lots of little chunks - Let the GTK main loop get a shot in between them or: - Move the complex thinky bit into another thread - Send a completion notification when it's done. For the first method you should use g_idle_add to put the iteration of chunks into free time. This leaves GTK running properly and doing your hard stuff when there's nothing else to update. For the second, the rule of thumb is that only the main thread should ever do a GTK call. Passing status from the worker thread can be done in several ways, but it's not a GTK issue. ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: implementing a delayed busy cursor
Paul Fox wrote: paul davis wrote: On Sun, 2007-08-05 at 12:56 -0400, Paul Fox wrote: google gtk timeout - gtk_timeout_add - gtk.org/api - Main Loop Events - gtk_timeout_add has been deprecated since version 2.4 and should not be used in newly-written code. Use g_timeout_add() instead. and no, these run synchronously with the main loop, which is why they are safe to use. thanks -- i'll do some reading. at the moment, i'm not sure how this will work. if i set a gtk timeout for 1 second, but my program's think time is 10 seconds, then i won't get back to the event loop until after that, and i've therefore blown my intended timeout. During this think time, the GTK main loop cannot run, so yes, your timeout won't fire. But at the same time your app won't respond to the user either. It's just going to appear to be hung. This is generally considered bad. but i've probably just given myself away as the gtk newb that i am, and am probably missing something really obvious, so i'll go do some reading, like i said. (i'm actually kind of surprised there's no gdk_window_set_cursor_after_delay() call, for just this purpose. :-) Even if there was, it wouldn't do any good in this case, as your app is spending those 10 seconds hogging the CPU, and never giving control to the main loop. So it wouldn't possibly have a chance to run, even if such a call existed. Just a note of caution. Threaded programming with GTK has be careful. Calling GTK calls from threads is problematic, and not cross-platform to boot. The recommended way is probably to use g_idle_add calls from the thread to notify the GUI loop of things, and using asyncqueues (a glib primitive) to pass data back and forth between the long-running task and the gui. Either that, or iterate the GTK main loop every so often from within your long-running task. Michael paul =- paul fox, [EMAIL PROTECTED] (arlington, ma, where it's 74.1 degrees) ___ 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 about SIGSEGV and backtrace
Hi all: I want to use SIGSEGV and backtrace to debug my programme. But I do not know how to use them. I'm running GTK 2.6.4 and Glib 2.6.4 on a Debian woody. Could you please guide me and tell where to find what I am looking for? Any help will be most appreciated. Thanks a lot. 你 玩 过 大 富 翁 吗？与 朋 友 网 络 对 战，还 能 一 起 挑 战 GM ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Is it possible to stop a signal callback?
Hi,
In my application, there is a callback which may take a long time to
finish.
Is it possible to return from the callback when user really need? For
example,
code as following, can I press the button 'cancel' to stop the counting?
Is there any document about thread in Gtk2?
use Gtk2 '-init';
use Glib qw(TRUE FALSE);
my $window = Gtk2::Window-new('toplevel');
$window-signal_connect('delete_event' = sub { Gtk2-main_quit; });
my $hbox= Gtk2::HBox-new(FALSE, 0);
my $but;
$but = Gtk2::Button-new('start');
$but-signal_connect(
'clicked' = sub {
my $i = 0;
while ($i 10) {
sleep( 1 );
$i++;
print I'm working\n;
}
return FALSE;
}
);
$hbox-pack_start($but, TRUE, TRUE, 5);
$but = Gtk2::Button-new('Cancel');
$but-signal_connect(
'clicked' = sub {
die Stop it\n;
}
);
$hbox-pack_start($but, TRUE, TRUE, 5);
$window-add($hbox);
$window-show_all();
Gtk2-main;
--
Best regards,
Ye Wenbin
___
gtk-perl-list mailing list
gtk-perl-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Re: Is it possible to stop a signal callback?
On Mon, 06 Aug 2007 01:35:41 +0800, zentara [EMAIL PROTECTED] wrote: Have you looked at http://forgeftp.novell.com/gtk2-perl-study/download/ it will answer alot of questions. I have read this document. It is really helpful. Don't use while(1) or sleep in a gui script, they cause malfunctions. I did not use sleep to do some work periodly. I was trying to show the signal callback will take a long time to finish. Maybe it need fork or using thread. But the problem is I don't know how to communicate with subprocess. I will try to find it. -- Best regards, Ye Wenbin ___ gtk-perl-list mailing list gtk-perl-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-perl-list
