[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: Gnome::Canvas remarks
- From: Roderich Schupp <Roderich Schupp partner bmw de>
- To: gtk-perl-list gnome org
- Subject: Re: Gnome::Canvas remarks
- Date: 02 Jul 2003 14:02:47 +0200
On Wed, 2003-07-02 at 12:57, scott asofyet org wrote:
> Roderich Schupp said:
> > I had to add
> > use utf8;
> > to the top of canvas-rich-text.pl.
>
> didn't work for me. then again, i copied the text straight from the C source,
> so it may be encoded incorrectly. and i may me missing the correct
fonts. if
No, the string is fine. It will show correctly (in arabic) in a UTF-8
aware editor, e.g. gedit, provided you have the fonts :)
> well, yeah, a ScrolledWindow would be easier. but it would not illustrate how
> to add your own scrollbars. a ScrolledWindow doesn't give you access to the
> unused space between the ends of the scrollbars, where the Gimp puts the
> button that brings up the navigation popup; if you want fine control over
> those bits, you have to do it by hand.
Sure. On the other hand, it's a nice shortcut if you just want them
darn scrollbars - and it works even for widgets that can't scroll
natively. Perl-Tk has this nice constructor
$w = $parent->Scrolled('Foo',
-scrollbars => '...',
-other_options_for_Foo_widgets => ...)
which creates a Foo inside a container with scrollbars attached to it.
Most events etc for $w are redirected to the contained Foo widget.
> occurrences of Scroll... would you like to write an example that illustrates
> the Easy Way and the Hard Way, comparing and contrasting? :-)
I'll give it a try :)
BTW canvas-rich-text.pl has another problem (again not the porter's
fault): the colored rectangles that underly the text have fixed sizes,
but the text may render to a different height depending on what
font gets chosen. I tried to remedy this by first creating the
RichText items, then ask them for their bounding box (with get_bounds)
and then create the Rects accordingly. Doesn't work, get_bounds
returns (0, 0, 0, 0) - even after $canvas->update_now,
which works for other CanvasItem types.
>
> > (3) Creating a new canvas item of type Foo (attached to canvas
> > group $group) is done by
> >
> > $item = Gnome2::Canvas::Item->new($group, "Gnome2::Canvas::Foo", ...);
> >
> > That's the same way gtk-perl did this. But wouldn't
> >
> > $item = Gnome2::Canvas::Foo->new($group, ...);
> >
> > be more natural?
>
> again, it was a straight port from the C API. while the second syntax is
> preferrable in general, canvas items are indeed special in that you can't
> create them with the normal Glib::Object constructor --- they are not complete
> without the $group parameter, which binds them to a particular GnomeCanvas
> object.
OK, it's
gnome_canvas_item_new(canvas_group, type, arg...)
and we're mapping this to
Gnome2::Canvas::Item->new($canvas_group, "Gnome2::Canvas::Type", ...)
what about
$canvas_group->new("Gnome2::Canvas::Type",...)
Cheers, Roderich
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]