Menu problem (?)

QNX Newsgroups (Archives) qdn.public.qnxrtp.photon
1

This is what happens (sample):

  1. In PhAB, create new application, plain window.
  2. Add menu module (int. links) with few items
  3. Add one button with callback to open the menu

Great so far.

  1. Change the window fill to transparent

Now the menu does not function as expected (does not close after selection,
etc… )

Is this correct behavior and if it is, why?

Thanks
Joe

2

Hi Joe! Getting along with your project, I see.

Joe Hezina <hezinjo@snapon.com> wrote:

This is what happens (sample):

  1. In PhAB, create new application, plain window.
  2. Add menu module (int. links) with few items
  3. Add one button with callback to open the menu

Great so far.

  1. Change the window fill to transparent

Now the menu does not function as expected (does not close after selection,
etc… )

Actually, the menu itself is functioning just as expected. It’s
opening and closing. To prove this to yourself, try dragging the
window so that the part where the menu appeared is off screen,
and then drag it back on. I just did this here to prove it to
myself. :slight_smile:

Is this correct behavior and if it is, why?

Yes, it’s expected (or at least, well known…) behaviour. Using
transparent fill colour for the parent widget of a module doesn’t
work very well in Photon at present. The widgets don’t recapture
what’s “underneath” them properly. For the moment, you really
can’t have what one student of mine referred to as “glass
bottomed modules”.

There has been some work going on behind the scenes that touches
on transparency, though, so long-term, it may be possible to get
this effect.

Hey Rod - what can be said about the current state of play?


Norbert Black
QSSL Training Services

3

Norbert,

thanks for the reply. The project goes well, thanks. No “glass bottom” - so
I guess I can’t cheat, heh :slight_smile: ?

Got just one more for today:

  1. New application, standard window
  2. Create button
  3. Set Filtered Child Event callback, Ph_EV_BOUNDRY
  4. just place some printf in the callback and compile and run in debug

You’ll see that event is correctly fired when pointer crosses the boundry,
but leave the pointer inside the button and another event will be fired just
about two seconds later, on it’s own. Same event type and subtype.

Expected behaviour? If so, why?

Thanks again
Joe




Norbert Black <nblack@qnx.com> wrote in message
news:99t6a9$jok$1@nntp.qnx.com…

Hi Joe! Getting along with your project, I see.

Joe Hezina <> hezinjo@snapon.com> > wrote:
This is what happens (sample):

  1. In PhAB, create new application, plain window.
  2. Add menu module (int. links) with few items
  3. Add one button with callback to open the menu

Great so far.

  1. Change the window fill to transparent

Now the menu does not function as expected (does not close after
selection,
etc… )


Actually, the menu itself is functioning just as expected. It’s
opening and closing. To prove this to yourself, try dragging the
window so that the part where the menu appeared is off screen,
and then drag it back on. I just did this here to prove it to
myself. > :slight_smile:

Is this correct behavior and if it is, why?

Yes, it’s expected (or at least, well known…) behaviour. Using
transparent fill colour for the parent widget of a module doesn’t
work very well in Photon at present. The widgets don’t recapture
what’s “underneath” them properly. For the moment, you really
can’t have what one student of mine referred to as “glass
bottomed modules”.

There has been some work going on behind the scenes that touches
on transparency, though, so long-term, it may be possible to get
this effect.

Hey Rod - what can be said about the current state of play?


Norbert Black
QSSL Training Services

4

Joe Hezina <hezinjo@snapon.com> wrote:

Norbert,

thanks for the reply. The project goes well, thanks. No “glass bottom” - so
I guess I can’t cheat, heh > :slight_smile: > ?

Well, you can cheat. We’ll all be able to notice, though. :slight_smile:

Got just one more for today:

  1. New application, standard window
  2. Create button
  3. Set Filtered Child Event callback, Ph_EV_BOUNDRY
  4. just place some printf in the callback and compile and run in debug

You’ll see that event is correctly fired when pointer crosses the boundry,
but leave the pointer inside the button and another event will be fired just
about two seconds later, on it’s own. Same event type and subtype.

Expected behaviour? If so, why?

Can’t say this for certain (without source diving for which I’ve
not got time just this instant), but I’d bet a small sum that
that’s how the server produces the “the pointer has been sitting
over your widget for a while - do you have balloon help?” cue.
The time sounds about right for the 1.25 seconds that’s
associated with the behaviour.

The way to confirm this would be to build an app that had balloon
help, and a filter callback on the widget with the help – let
the first boundary event through, and discard the second one.
Does the balloon appear or not?



Norbert Black
QSSL Training Services

5

Norbert,

you’re right, it is related to the ballon, it hit me right after I finished
the last post on the subject. I enabled baloon and sure enough, it fires in
sync with the second event. If you wait for the baloon to pop, exiting the
widget also generates two events, one of which is also baloon related
(close). If you don’t, just one is emitted. It fires regardless, if ballons
are enabled for the widget or not.

Omitting events wouldn’t help or be to messy, because you may exit the
widget before the baloon event was emitted. So, depeding on how long you
spent in the widget, you may get two or four events per entry/exit.

However, I figured that the event subtype ( cbinfo->event->subtype ) can be
used to distinguish between these.
0 = crossed boundry from outside
1 = crossed boundry from inside

All others are baloon related.

Guess you have new goodie for your next class :slight_smile:

Thanks again

Joe

Norbert Black <nblack@qnx.com> wrote in message
news:99thg2$p8r$1@nntp.qnx.com…

Joe Hezina <> hezinjo@snapon.com> > wrote:
Norbert,

thanks for the reply. The project goes well, thanks. No “glass bottom” -
so
I guess I can’t cheat, heh > :slight_smile: > ?

Well, you can cheat. We’ll all be able to notice, though. > :slight_smile:

Got just one more for today:

  1. New application, standard window
  2. Create button
  3. Set Filtered Child Event callback, Ph_EV_BOUNDRY
  4. just place some printf in the callback and compile and run in debug

You’ll see that event is correctly fired when pointer crosses the
boundry,
but leave the pointer inside the button and another event will be fired
just
about two seconds later, on it’s own. Same event type and subtype.

Expected behaviour? If so, why?

Can’t say this for certain (without source diving for which I’ve
not got time just this instant), but I’d bet a small sum that
that’s how the server produces the “the pointer has been sitting
over your widget for a while - do you have balloon help?” cue.
The time sounds about right for the 1.25 seconds that’s
associated with the behaviour.

The way to confirm this would be to build an app that had balloon
help, and a filter callback on the widget with the help – let
the first boundary event through, and discard the second one.
Does the balloon appear or not?



Norbert Black
QSSL Training Services