Placement of popup ( CellRendererDate from examples )

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Placement of popup ( CellRendererDate from examples )

Daniel Kasak
Greetings.

I'm using some code from the example folder to provide a
CellRendererDate in a treeview. I've had some complaints that the
calendar goes off-screen if the cell being edited is too far down the
screen.

The code that positions the popup is ( from the cellrendererdate.pl
example script ):

  # Align the top right edge of the popup with the the bottom right edge
of the
  # cell.
  my ($x_origin, $y_origin) =  $view -> get_bin_window() -> get_origin();

  $popup -> move(
    $x_origin + $cell_area -> x() + $cell_area -> width() - $popup ->
allocation() -> width(),
    $y_origin + $cell_area -> y() + $cell_area -> height()
  );

How would I go about modifying this to detect whether the calculated y
position puts part of the calendar off-screen?

I know ( or I think I know anyway ... I haven't tried it yet ) I can do
$popup->allocation to get the size of the popup. But how do I get the
screen size?

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [hidden email]
website: http://www.nusconsulting.com.au
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

muppet-6

On Sep 5, 2005, at 7:31 PM, Daniel Kasak wrote:

> How would I go about modifying this to detect whether the  
> calculated y position puts part of the calendar off-screen?

Simply calculate whether $y_origin + $cell_area->y + $cell_area-
 >height + $popup->allocation->height is greater than the available  
screen height.   (You imply this below, so i suspect you already knew  
that.)  If it is, then place the popup above the cell instead of  
below it.


> I know ( or I think I know anyway ... I haven't tried it yet ) I  
> can do $popup->allocation to get the size of the popup.

There's also get_size_request(), which will ask the widget to  
calculate the size it wants (which propagates to children); you can  
use this before the widget is onscreen to avoid flicker.


> But how do I get the screen size?

# since gtk+ 2.2:
$screen = $widget->get_screen;
$width = $screen->get_width;
$height = $screen->get_height;

# for gtk+ 2.0.x, there were Gtk2::Gdk->get_screen_(width|height),  
but they don't play nicely with multihead stuff.




--
In some newer operating systems, time_t has been widened to 64 bits.  
In the negative direction, this goes back more than twenty times the  
age of the universe, and so suffices. In the positive direction,  
whether this range is sufficient to represent all possible times  
depends on the ultimate fate of the universe, but it can be expected  
to postpone overflow long enough for such implementation limits to be  
abolished.
   -- Wikipedia, on UNIX time.

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

Elijah Newren
In reply to this post by Daniel Kasak
On 9/5/05, Daniel Kasak <[hidden email]> wrote:
> Greetings.
>
> I'm using some code from the example folder to provide a
> CellRendererDate in a treeview. I've had some complaints that the
> calendar goes off-screen if the cell being edited is too far down the
> screen.

Window manager bug, IMO.
http://bugzilla.gnome.org/show_bug.cgi?id=136307, if your user is
running with Metacity[1].  Of course, you may want to work around this
for buggy window managers anyway, but it really isn't something you
should need to do.

Hope that helps,
Elijah

[1] Yeah, I'm working on it, but as per Havoc's comments 18 and 20, it
also involves a rewrite of all of constraints.c and thus I'm trying to
also address over a dozen other bugs simultaneously...
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

Daniel Kasak
Elijah Newren wrote:

>On 9/5/05, Daniel Kasak <[hidden email]> wrote:
>  
>
>>Greetings.
>>
>>I'm using some code from the example folder to provide a
>>CellRendererDate in a treeview. I've had some complaints that the
>>calendar goes off-screen if the cell being edited is too far down the
>>screen.
>>    
>>
>
>Window manager bug, IMO.
>http://bugzilla.gnome.org/show_bug.cgi?id=136307, if your user is
>running with Metacity[1].  Of course, you may want to work around this
>for buggy window managers anyway, but it really isn't something you
>should need to do.
>
>Hope that helps,
>Elijah
>
>[1] Yeah, I'm working on it, but as per Havoc's comments 18 and 20, it
>also involves a rewrite of all of constraints.c and thus I'm trying to
>also address over a dozen other bugs simultaneously...
>
>  
>
I don't think this is a WM bug. The WM ( in this case,
Enlightenment-0.17 ) is doing exactly what the code says - aligning the
top-right of the popup with the bottom-right of the cell. The problem is
in the logic of the positioning of the popup. I'm almost done on a solution.

Thanks for the post though :)

Dan

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [hidden email]
website: http://www.nusconsulting.com.au
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

Elijah Newren
On 9/5/05, Daniel Kasak <[hidden email]> wrote:
> Elijah Newren wrote:
>
> I don't think this is a WM bug. The WM ( in this case,
> Enlightenment-0.17 ) is doing exactly what the code says - aligning the
> top-right of the popup with the bottom-right of the cell. The problem is
> in the logic of the positioning of the popup. I'm almost done on a solution.

Ooops, I missed the part where you were manually positioning it.
Yeah, that's a tough call on whether the WM should follow that or
force the window onscreen, so it's not clear which is right.

Sorry for the noise.
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

Daniel Kasak
Elijah Newren wrote:

>On 9/5/05, Daniel Kasak <[hidden email]> wrote:
>  
>
>>Elijah Newren wrote:
>>
>>I don't think this is a WM bug. The WM ( in this case,
>>Enlightenment-0.17 ) is doing exactly what the code says - aligning the
>>top-right of the popup with the bottom-right of the cell. The problem is
>>in the logic of the positioning of the popup. I'm almost done on a solution.
>>    
>>
>
>Ooops, I missed the part where you were manually positioning it.
>Yeah, that's a tough call on whether the WM should follow that or
>force the window onscreen, so it's not clear which is right.
>
>  
>
I disagree that it's a tough call. If an app requests to be drawn at a
particular position, then the only valid action on the part of the WM is
to do just that. Consider an app that starts off-screen and scrolls
onscreen. Maybe this is a tacky example, but it's perfectly valid. No,
actually, here's a not-so-tacky example - an OS-X like starter bar :)

>Sorry for the noise.
>  
>
Doesn't bother me :)

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [hidden email]
website: http://www.nusconsulting.com.au
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

Daniel Kasak
In reply to this post by muppet-6
muppet wrote:

>> I know ( or I think I know anyway ... I haven't tried it yet ) I  can
>> do $popup->allocation to get the size of the popup.
>
>
> There's also get_size_request(), which will ask the widget to  
> calculate the size it wants (which propagates to children); you can  
> use this before the widget is onscreen to avoid flicker.

This is returning -1 for x and y sizes. Not to worry - allocation() is
working fine, and I've got a working solution now.
I've attached a patch, against the cellrenderer_date.pl from Gtk2-1.081,
to fix the issue ... it's a damned useful example ... maybe even a
candidate for Gtk2::Ex::CoolStuff or something?

Is this the right place to send patches for the example apps?

--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [hidden email]
website: http://www.nusconsulting.com.au

--- cellrenderer_date.pl.original 2005-09-06 12:26:08.000000000 +1000
+++ cellrenderer_date.pl 2005-09-06 12:27:47.000000000 +1000
@@ -212,14 +212,26 @@
   $popup -> move(-500, -500);
   $popup -> show_all();
 
-  # Align the top right edge of the popup with the the bottom right edge of the
-  # cell.
+  # Figure out where to put the popup - ie don't put it offscreen,
+  # as it's not movable ( by the user )
+  my $screen_height = $popup->get_screen->get_height;
+  my $popup_height = $popup->allocation->height;
+  
   my ($x_origin, $y_origin) =  $view -> get_bin_window() -> get_origin();
-
-  $popup -> move(
-    $x_origin + $cell_area -> x() + $cell_area -> width() - $popup -> allocation() -> width(),
-    $y_origin + $cell_area -> y() + $cell_area -> height()
-  );
+  
+  my ($popup_x, $popup_y);
+  
+  if ($x_origin + $cell_area -> x() + $cell_area -> width() - $popup -> allocation() -> width() < 0) {
+    $popup_x = 0;
+  } else {
+    $popup_x = $x_origin + $cell_area -> x() + $cell_area -> width() - $popup -> allocation() -> width();
+  }
+  
+  if ($y_origin + $cell_area->y + $cell_area->height + $popup_height > $screen_height) {
+    $popup_y = $screen_height - $popup_height;
+  } else {
+    $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height();
+  }
 
   # Grab the focus and the pointer.
   Gtk2 -> grab_add($popup);

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

muppet-6

On Sep 5, 2005, at 11:28 PM, Daniel Kasak wrote:

> muppet wrote:
>
>>> I know ( or I think I know anyway ... I haven't tried it yet ) I  
>>> can do $popup->allocation to get the size of the popup.
>>
>> There's also get_size_request(), which will ask the widget to  
>> calculate the size it wants (which propagates to children); you  
>> can  use this before the widget is onscreen to avoid flicker.
>
> This is returning -1 for x and y sizes.

I told you wrong; gtk_widget_get_size_request() merely fetches the  
existing size request, which is -1,-1 before the widget goes  
onscreen.  gtk_widget_size_request() asks the widget to calculate and  
populate the requisition.  I can never remember which is which  
without going to the docs...

But in this case, it doesn't matter, because the widget it fully  
realized offscreen.

But now that i look at it, this is pretty hackish, and can actually  
result in obnoxious flicker if you have another screen configured to  
the left and above the main one, and even worse if the screen at  
-500,-500 has a different font size.  Unlikely, but hey, it's a  
chance to learn how to use size_request() properly.

     # ensure that you've already called show() on all children of  
$popup
     $popup->realize();
     my $requisition = $popup->size_request();
     my $popup_width = $requisition->width;
     my $popup_height = $requisition->height;
     ...
     $popup->move (...);
     $popup->show;


This leaves you open the the possibility that the allocation is not  
the same as the requisition, but doesn't map-then-move the window.



> Not to worry - allocation() is working fine, and I've got a working  
> solution now.
> I've attached a patch, against the cellrenderer_date.pl from  
> Gtk2-1.081, to fix the issue ... it's a damned useful example ...  
> maybe even a candidate for Gtk2::Ex::CoolStuff or something?
>
> Is this the right place to send patches for the example apps?

Yep.


> --- cellrenderer_date.pl.original    2005-09-06 12:26:08.000000000  
> +1000
> +++ cellrenderer_date.pl    2005-09-06 12:27:47.000000000 +1000
> @@ -212,14 +212,26 @@
>    $popup -> move(-500, -500);
>    $popup -> show_all();
>
> -  # Align the top right edge of the popup with the the bottom  
> right edge of the
> -  # cell.
> +  # Figure out where to put the popup - ie don't put it offscreen,
> +  # as it's not movable ( by the user )
> +  my $screen_height = $popup->get_screen->get_height;
> +  my $popup_height = $popup->allocation->height;
> +
>    my ($x_origin, $y_origin) =  $view -> get_bin_window() ->  
> get_origin();
> -
> -  $popup -> move(
> -    $x_origin + $cell_area -> x() + $cell_area -> width() - $popup  
> -> allocation() -> width(),
> -    $y_origin + $cell_area -> y() + $cell_area -> height()
> -  );
> +
> +  my ($popup_x, $popup_y);
> +
> +  if ($x_origin + $cell_area -> x() + $cell_area -> width() -  
> $popup -> allocation() -> width() < 0) {
> +    $popup_x = 0;
> +  } else {
> +    $popup_x = $x_origin + $cell_area -> x() + $cell_area -> width
> () - $popup -> allocation() -> width();
> +  }

For brevity and to avoid repeating yourself,

    $popup_x = big hairy calculation;
    $popup_x = 0 if $popup_x < 0;

> +  if ($y_origin + $cell_area->y + $cell_area->height +  
> $popup_height > $screen_height) {
> +    $popup_y = $screen_height - $popup_height;

That just anchors it at the bottom of the screen.  Less surprising,  
and somewhat more useful, is to hang the popup off the top edge of  
the cell instead of the bottom edge, like so:

   my $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height();
   if ($popup_y + $popup_height > $screen_height) {
     $popup_y = $y_origin + $cell_area -> y() - $popup_height;
   }

That way, the user can still click the arrow to pop down easily,  
e.g., if it was an accident to pop it up in the first place.  ;-)

> +  } else {
> +    $popup_y = $y_origin + $cell_area -> y() + $cell_area -> height
> ();
> +  }

And don't forget to add back the

   $popup->move ($popup_x, $popup_y);


>    # Grab the focus and the pointer.
>    Gtk2 -> grab_add($popup);


It's handy; i'll commit that.  You still get credit.  :-)


--
Without treatment, a common cold will last about seven days.
With treatment, it will last about a week.
   -- conventional wisdom

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

Jan Hudec
In reply to this post by Daniel Kasak
On Tue, Sep 06, 2005 at 12:01:53 +1000, Daniel Kasak wrote:

> Elijah Newren wrote:
> >On 9/5/05, Daniel Kasak <[hidden email]> wrote:
> >>Elijah Newren wrote:
> >>I don't think this is a WM bug. The WM ( in this case,
> >>Enlightenment-0.17 ) is doing exactly what the code says - aligning the
> >>top-right of the popup with the bottom-right of the cell. The problem is
> >>in the logic of the positioning of the popup. I'm almost done on a
> >>solution.
> >
> >Ooops, I missed the part where you were manually positioning it.
> >Yeah, that's a tough call on whether the WM should follow that or
> >force the window onscreen, so it's not clear which is right.
> >
> I disagree that it's a tough call. If an app requests to be drawn at a
> particular position, then the only valid action on the part of the WM is
> to do just that. Consider an app that starts off-screen and scrolls
> onscreen. Maybe this is a tacky example, but it's perfectly valid. No,
> actually, here's a not-so-tacky example - an OS-X like starter bar :)
Isn't popoup an OverrideRedirect window?

If it is, than window manager just can't do anything about it, because it
simply does not know about it.

--
                                                 Jan 'Bulb' Hudec <[hidden email]>

_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Placement of popup ( CellRendererDate from examples )

Elijah Newren
On 9/7/05, Jan Hudec <[hidden email]> wrote:

> On Tue, Sep 06, 2005 at 12:01:53 +1000, Daniel Kasak wrote:
> > Elijah Newren wrote:
> > >On 9/5/05, Daniel Kasak <[hidden email]> wrote:
> > >>Elijah Newren wrote:
> > >>I don't think this is a WM bug. The WM ( in this case,
> > >>Enlightenment-0.17 ) is doing exactly what the code says - aligning the
> > >>top-right of the popup with the bottom-right of the cell. The problem is
> > >>in the logic of the positioning of the popup. I'm almost done on a
> > >>solution.
> > >
> > >Ooops, I missed the part where you were manually positioning it.
> > >Yeah, that's a tough call on whether the WM should follow that or
> > >force the window onscreen, so it's not clear which is right.
> > >
> > I disagree that it's a tough call. If an app requests to be drawn at a
> > particular position, then the only valid action on the part of the WM is
> > to do just that. Consider an app that starts off-screen and scrolls
> > onscreen. Maybe this is a tacky example, but it's perfectly valid. No,
> > actually, here's a not-so-tacky example - an OS-X like starter bar :)
>
> Isn't popoup an OverrideRedirect window?
>
> If it is, than window manager just can't do anything about it, because it
> simply does not know about it.

Yes, if it is, you're right.  For some reason I just assumed it was a
dialog window; don't know why.  Any other blunders I made besides
missing the manual positioning bit and the likely case that the window
is override-redirect?  :-/
_______________________________________________
gtk-perl-list mailing list
[hidden email]
http://mail.gnome.org/mailman/listinfo/gtk-perl-list