Gtk::window.present() doesn't always present

> Hello everybody,
>
> I tried to describe my problem as short as I could...
>
> I'm writing a gui for our orbital welding machine
which my company is
building. Everything went really well but now I'm stuck.
>
> Our gui consists of several modular gtkmm programs
communicating through
an ipc message queue. All programs start without showing any
window.
They can send a message to each other to present themselves
to the user
when necessary.
>
> The first time they present a window it works fine. But
after they've
hide and later want to show themselves again the window
doesn't popup.
Actually, they do popup but only after I click with the
mouse, anywhere
on the screen.
>
> I've googled around and found a few hints, like the
window manager only
wants to popup windows the user explicitly asked for with a
mouse click,
to prevent stealing focus from other windows. Probably this
is why there
exists a function present with time stamp...  I tried to
kill the window
manager but this doesn't make any difference.
>
> If anybody could help me out, even with some hints to
search for, I
would be very thankful.

I guess you are using the metacity window manager, like most
GNOME
installations.

I have CCed the metacity mailing list so they can give you
some help with
this. (Resent with the correct address)


Murray Cumming
murraycmurrayc.com
www.murrayc.com
www.openismus.com



Murray Cumming
murraycmurrayc.com
www.murrayc.com
www.openismus.com

_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list

On 7/12/06, Murray Cumming <murraycmurrayc.com> wrote:
> > Our gui consists of several modular gtkmm programs
communicating through
> an ipc message queue. All programs start without
showing any window.
> They can send a message to each other to present
themselves to the user
> when necessary.
> >
> > The first time they present a window it works
fine. But after they've
> hide and later want to show themselves again the window
doesn't popup.
> Actually, they do popup but only after I click with the
mouse, anywhere
> on the screen.
> >
> > I've googled around and found a few hints, like
the window manager only
> wants to popup windows the user explicitly asked for
with a mouse click,
> to prevent stealing focus from other windows. Probably
this is why there
> exists a function present with time stamp...  I tried
to kill the window
> manager but this doesn't make any difference.
> >
> > If anybody could help me out, even with some hints
to search for, I
> would be very thankful.
>
> I guess you are using the metacity window manager, like
most GNOME
> installations.
>
> I have CCed the metacity mailing list so they can give
you some help with
> this. (Resent with the correct address)

There's very little information about the use case here,
making it
hard to know what to say.  Could you provide more info about
it, and
what causes these windows to appear (that is, what events
occur to
make you decide to show the windows)?  Also, it'd help if
you
specified what steps you've taken to try to get the
behavior you want.
 I wouldn't have guessed Gtk::window.present() was at all
related from
reading the email, but it does appear on the subject line. 
It'd be
interesting to know how/when/where you are calling that
function as
well.
_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list

On 7/14/06, Mikkel Kamstrup Erlandsen
<mikkel.kamstrupgmail.com> wrote:
> I think the question from Harm really is about how you
can show a window
> without an event (or atleast with an event from an
external process), and I
> have been wondering the same thing too (if it is at all
possible).  As I
> read it he wants to present a window when something is
received through an
> IPC message queue.  - In my world this is isomorphic to
"how do I present a
> window from a dbus callback?"

My questions were there to point out that you got a dbus
callback for
a reason, most likely because of a user interaction with
another
application.  Information from such user interaction events
should be
passed along to the application being requested to handle
it.

> Admittedly I have not tried sending the the event.time
via dbus to the
> application which should do the window presenting
(which then could do a
> present_with_time with the given timestamp). Does this
have any chance of
> working?

Yes.  
_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list

On 7/15/06, Harm Hamberg <h.hambergdynamicc-welding.biz>
wrote:
> Great! But how can I get the timestamp from a
> Gtk::Button::signal_clicked()? Should I override the
on_frame_event and save
> the last timestamp?

gtk+ keeps track of events it is processing.  It has the
notion of a
"current event" that it is processing (which may
be NULL), and there
are methods to access this information.  When you're in a
signal_clicked handler, gtk's current event is the button
press event
that caused that handler to be called.  Using
gtk_get_current_event(),
you can get that event, and then just access its time
member.  I tried
looking in the gtkmm documentation to see if that function
was wrapped
and had a different name, but didn't find anything.
_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list

Elijah Newren wrote:
> On 7/15/06, Harm Hamberg <h.hambergdynamicc-welding.biz> wrote:
>> Great! But how can I get the timestamp from a
>> Gtk::Button::signal_clicked()? Should I override
the on_frame_event and save
>> the last timestamp?
> 
> gtk+ keeps track of events it is processing.  It has
the notion of a
> "current event" that it is processing
(which may be NULL), and there
> are methods to access this information.  When you're
in a
> signal_clicked handler, gtk's current event is the
button press event
> that caused that handler to be called.  Using
gtk_get_current_event(),
> you can get that event, and then just access its time
member.  I tried
> looking in the gtkmm documentation to see if that
function was wrapped
> and had a different name, but didn't find anything.

There's also a get_current_time() or something like that,
so it's even 
easier. The get_current_time() should support a key press
that activated 
the button, as well.

Havoc

_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list

On 7/15/06, Havoc Pennington <hpredhat.com> wrote:
> There's also a get_current_time() or something like
that, so it's even
> easier. The get_current_time() should support a key
press that activated
> the button, as well.

It's gtk_get_current_event_time() and I advise against its
use, unless
you either understand gtk+ event handling thoroughly enough
to know
when it'll return a valid timestamp and when it won't OR
you go to the
extra trouble of always checking the return value (in the
latter case,
of course, you've lost all the keystroke savings you would
have gained
in the switch from gtk_get_current_event() to
gtk_get_current_event_time()).  Of course, this is mostly
selfish
advice: I'm just kind of sick of debugging apps that have
misused it.
  By
going the gtk_get_current_event() route and then looking at
the time field of the returned event, you'll immediately
know that
you've used it in the wrong place if you get NULL back for
the current
event.  gtk_get_current_event_time() kind of hides whether
there is a
valid current event or not and people who use it tend to
ignore
whether they have a valid timestamp or a bogus one
(GDK_CURRENT_TIME),
and just use what it returns regardless.

Just my $0.02,
Elijah
_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list

Elijah Newren wrote:
> event.  gtk_get_current_event_time() kind of hides
whether there is a
> valid current event or not and people who use it tend
to ignore
> whether they have a valid timestamp or a bogus one
(GDK_CURRENT_TIME),
> and just use what it returns regardless.
> 

Wouldn't it be correct to write:

  int t = gtk_get_current_event_time();
  if (t != GDK_CURRENT_TIME)
    /* use the time */;

With the event route, it seems people need to do something
like:

GdkEvent *event = gtk_get_current_event();
if (event != NULL) {
   switch (event->type) {
   case GDK_BUTTON_PRESS:
   case GDK_KEY_PRESS:
   ...

}

Havoc

_______________________________________________
metacity-devel-list mailing list
metacity-devel-listgnome.org
http://mail.gnome.org/mailman/listinfo/metacity-devel-
list