papyrus is a C++ scenegraph library based on cairo
http://libpapyrus.sourceforge.net
===== 0.13.2 =====
Like most releases this one features both bugfixes and enhancements.
A bug causing segfaults in Drawable's destructor that removed a child from a
parent was fixed. Drawables will no longer automatically remove themselves
from parents on destruction, but this was legacy code as children have (for
some time now) been owned by their parents in the scenegraph. Thus, the
only way for a child to destruct is to first remove it from it's parent.
Fixing this bug allowed the base Papyrus::Object to inherit from
sigc::trackable again.
The Group::clear() method has been cleaned up and improved. This should
result
in a fairly significant performance improvement if you have many items in a
group and regularly clear it. A simple estimate would put the old version
at a performance level of 3 * O(n lg(n)) + O(n) and the new version at
4 * O(n).

This release is primarily a bugfix release. There was an overload
resolution bug with the virtual and non-virtual render() methods. Because
of scoping rules, the virtual methods were not seen by descendants of
Renderable causing an infinite recursion of the virtual method resulting
in a segfault.
To remedy this, two new macros have been created: PAPYRUSRENDERABLE() and
PAPYRUSDRAWABLE(). In addition to adding the using directive to a class
these macros provide some of the other repetitive code used in each
descendant of Renderable and Drawable, including declaration of smart
pointer types.
Additionally, a small bug in the shapes example program has been fixed.

Rafael de Pelegrini Soares wrote:
> Dear All,
>
> I'm trying to use Papyrus as the 2D canvas engine for our project
> http://www.enq.ufrgs.br/trac/alsoc/wiki/EMSO
>
> Currently we support both Linux and Windows. Do you have any
> experience in compiling Papyrus for Windows. In order to get it
> working with MSVC9 I had to hack the code in several places. I would
> be glad to contribute these changes. I haven't tested the compilation
> process with mingw yet, but I intent to.
>
It's been a long time since I've had any reports of papyrus compiling on
Windows.

Rafael de Pelegrini Soares wrote:
> Hi All,
>
> This is my first message to this list and I have to say that Papyrus
> is really a nice piece of software!
>
> I'm playing with Papyrus as an alternative for the 2D canvas of our
> project http://www.enq.ufrgs.br/trac/alsoc/wiki/EMSO
>
> My first question is, how can I get a Boxed with a margin. If I put a
> Text inside of a Boxed I get something like:
> ____
> |Text|
>
> But I looking form something like:
> ___________
> | |
> | Text |
> |__________|
>
> I've extended the Boxed and modified the extents() function to get
> that, is this the better way to go?
>
Right now, that's probably the best. What we need is an alignment
controller with justification and padding.
---
Rick

Dear All,
I'm trying to use Papyrus as the 2D canvas engine for our project
http://www.enq.ufrgs.br/trac/alsoc/wiki/EMSO
Currently we support both Linux and Windows. Do you have any
experience in compiling Papyrus for Windows. In order to get it
working with MSVC9 I had to hack the code in several places. I would
be glad to contribute these changes. I haven't tested the compilation
process with mingw yet, but I intent to.
Cheers.
--
Prof. Rafael de Pelegrini Soares, D.Sc
Chemical Engineering Department - UFRGS
rafael@..., rafael.enq@...
office: +55 51 3308 3528

Hi All,
This is my first message to this list and I have to say that Papyrus
is really a nice piece of software!
I'm playing with Papyrus as an alternative for the 2D canvas of our
project http://www.enq.ufrgs.br/trac/alsoc/wiki/EMSO
My first question is, how can I get a Boxed with a margin. If I put a
Text inside of a Boxed I get something like:
____
|Text|
But I looking form something like:
___________
| |
| Text |
|__________|
I've extended the Boxed and modified the extents() function to get
that, is this the better way to go?
Cheers.
--
Prof. Rafael de Pelegrini Soares, D.Sc
Chemical Engineering Department - UFRGS
rafael@..., rafael.enq@...
office: +55 51 3308 3528

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7546812
By: rvinyard
This release features a new controller called Zoomer providing mouse wheel zooming
of drawables.
There is a new viewport widget named ScrolledViewport. It contains a basic viewport,
but adds vertical and horizontal scrollers and provides an API very similar
to Gtk's ScrolledWindow widget.
Also new are two drawing modes. One allows for intermediate drawing, primarily
to support compositing. The other is alpha drawing using cairo's paint_with_alpha()
methods.
The drawable controller's have also had the insert() method renamed to add()
to match Papyrus::Group's syntax.
Support for rounded rectangles is also added using the corner_radius property
of rectangles.
There are also a number of other small enhancements and/or bug fixes.
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=500340

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=7392214
By: rvinyard
This release fixes some bugs in the Reference class' handling of composed matrices
and extents. Thanks to Julius Ziegler for reporting the problem and providing
an example application (called reference in the examples directory).
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=500340

Rick L. Vinyard, Jr. wrote:
> One thing you might want to take a look at is the Reference class. It
> allows a drawable to be used by reference in multiple places within a
> scenegraph.
Thanks, Reference is exactly what I was looking for!
> Rick

Julius Ziegler wrote:
> many 3d scene graph libraries I worked with allowed diamond shaped scene
> graphs, so that one group of objects can be reached via multiple pathes
> (containing different transformations), leading to effectively having
> multiple "clones" of a group in the scene.
>
> As far as I understand, papyrus cannot support this, since there is only
> one parent group in every Drawable.
>
The earlier versions of papyrus allowed that since the scenegraph was
essentially a rooted directed tree. Rendering was (is) simplistic
basically using the Painter's algorithm.
What changed things was the introduction of the global coordinate testing.
Since a parent's transform affects a child's ultimate drawing position, if
a child is to perform global hit tests, etc. it needs to know the parent's
transform, and the parent's parent, et. al. back to the root of the tree.
> Is there an alternative way of producing clones or (deep) copies of
> parts of the scene graph? Papyrus::Drawable::clone() looks like a
> candidate, but I cannot figure out how to use it.
Some of the clone() methods might need cleaning up, but the intent is to
provide a deep copy mechanism from a high-level base. That's why it
returns a Drawable::pointer, which could be downcast to a more specific
type if necessary.
> Is it meant for other
> than internal library use? How are the policies for copy constructors of
> Drawables in papyrus?
It's meant for external use if you need a deep copy. Shallow copies should
be done through the pointers.
One thing you might want to take a look at is the Reference class. It
allows a drawable to be used by reference in multiple places within a
scenegraph.
I'm pretty sure there's even an example somewhere that demonstrates use.
---
Rick

Hello list,
many 3d scene graph libraries I worked with allowed diamond shaped scene
graphs, so that one group of objects can be reached via multiple pathes
(containing different transformations), leading to effectively having
multiple "clones" of a group in the scene.
As far as I understand, papyrus cannot support this, since there is only
one parent group in every Drawable.
Is there an alternative way of producing clones or (deep) copies of
parts of the scene graph? Papyrus::Drawable::clone() looks like a
candidate, but I cannot figure out how to use it. Is it meant for other
than internal library use? How are the policies for copy constructors of
Drawables in papyrus?
Any help is appreciated,
Julius

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=6859112
By: rvinyard
Like most releases this release contains a little of everything... a few new
features... some new optimizations... some bug fixes.
In the new features category are the freeze()/thaw() methods added to Drawable.
You can try them out in the demo which includes an example.
In coordination with the introduction of the freeze()/thaw() methods the boolean
redraw parameter on all the Drawable affine transform methods has been removed.
Rather than adding this parameter per function call, you can now enclose a group
of function calls with a freeze/thaw pair.
In the bug fix category there are a number of items submitted by Tim Niemueller.
These include a fix that prevented the Canvas from drawing it's background and
several instances of invalid list iterators in Drawable's external matrices
that caused segfaults.
In the area of optimizations Drawable now handles external matrix changed signals
through a reference counted system rather than the older
one-connection-per-added-matrix. This should improve things if a matrix is added
multiple times to a drawable at the same or different levels.
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=500340

Thanks Julius. I updated the pick example to also include a group, plus I
put a few transforms on the rectangle just to make sure the transform was
being applied properly.
I think it's fixed now. I found a problem in Group's reimplementation of
inside(x,y) that was transforming the query point with the group's
transformation matrix rather than using the inverse matrix.
The new 0.10.2 release should have this fixed.
Thanks again,
Rick
Julius Ziegler wrote:
> Hi Rick,
>
> unfortunately, the example breaks if I add an intermediate group note
> with translation. I have modified the Simple::Simple() constructor as
> below.
>
> The effect is that picking works still right in some areas of the
> screen, but not in the lower right area (with the code below, try to
> pick the red square). Since the extra transformation is, in principle,
> accounted for, I think that something goes wrong by some cropping
> operation, as if the transformed pointer coordinates are cropped to the
> window dimension.
>
> Best,
> Julius
>
>
>
> Simple::Simple()
> {
> set_title("Papyrus Object Picking Demo");
>
> Rectangle::pointer rect;
> Circle::pointer circle;
> RegularPolygon::pointer regularpolygon;
> Group::pointer group;
>
> rect = Rectangle::create( "rectangle", 40, 80, RGBA("red") );
> circle = Circle::create( "circle", 60, RGBA("green") );
> regularpolygon = RegularPolygon::create( "octagon", 8, 40,
> RegularPolygon::ZERO_APOTHEM, RGBA("blue"));
> group = Group::create();
>
> m_viewport.canvas()->add( group );
>
> group->add( rect );
> group->add( circle );
> group->add( regularpolygon );
>
> group->set_xy( 20, 20 );
>
> m_viewport.signal_papyrus_event().connect( sigc::mem_fun(*this,
> &Simple::on_papyrus_event));
>
> add(m_viewport);
> show_all();
> }
>
>
> Rick L. Vinyard, Jr. wrote:
>> Just an update...
>>
>> I cleaned up and simplified (I removed about 80% of the code) the
>> picking
>> example before digging into Group::select(). After simplifying it I made
>> a
>> few small changes to the way Viewport handles event propagation and used
>> the new signal_papyrus_event() method in the picking example.
>>
>> However, selection seems to be fine in the picking example. Take a look
>> at
>> the new one and let me know if you have any questions or if you find any
>> examples that break the selection code.
>>
>> I've released 0.10.1 that incorporates these changes.
>>
>> Even though the simple pick example works there could still be an issue
>> with a larger example that incorporates different elements.
>>
>> ---
>>
>> Rick
>>
>> Julius Ziegler wrote:
>>> Hello Rick,
>>>
>>> First I would like to say thank you for this great library. It really
>>> fills a gap, in my opinion!
>>>
>>> Now, I cannot get picking to work. I am using PapyrusGTK. I believe
>>> that
>>> just feeding coordinates from Papyrus::Gtk::Viewport::get_pointer(...)
>>> (inherited from Gtk::Widget) into
>>> Papyrus::Gtk::Viewport::canvas()->select() should "just work",
>>> independently from transformations applied within the canvas, but it
>>> does not. I am not using custom shapes, just circles and rectangles
>>> (and
>>> groups thereof).
>>>
>>> The "pick" demo from the examples directory does not seem to work right
>>> either. I am sometimes getting "picked object at ..." messages, but the
>>> area where this happens does not really have something to do with the
>>> objects in the canvas (might be only an offset, though).
>>>
>>> Am I forgetting to apply some necessary transformations to the pointer
>>> coordinates?
>>>
>>> Thanks!
>>>
>>> Julius
>>>
>>> ------------------------------------------------------------------------------
>>> Open Source Business Conference (OSBC), March 24-25, 2009, San
>>> Francisco,
>>> CA
>>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>>> Enterprise
>>> -Strategies to boost innovation and cut costs with open source
>>> participation
>>> -Receive a $600 discount off the registration fee with the source code:
>>> SFAD
>>> http://p.sf.net/sfu/XcvMzF8H
>>> _______________________________________________
>>> Libpapyrus-users mailing list
>>> Libpapyrus-users@...
>>> https://lists.sourceforge.net/lists/listinfo/libpapyrus-users
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Libpapyrus-users mailing list
> Libpapyrus-users@...
> https://lists.sourceforge.net/lists/listinfo/libpapyrus-users
>

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=6663517
By: rvinyard
This release fixes a bug in the Group::inside(x,y) method that prevented
selection/picking from working properly.
There are also a few new convenience methods added to Matrix related to operations
in inverse matrices.
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=500340

Hi Rick,
unfortunately, the example breaks if I add an intermediate group note
with translation. I have modified the Simple::Simple() constructor as below.
The effect is that picking works still right in some areas of the
screen, but not in the lower right area (with the code below, try to
pick the red square). Since the extra transformation is, in principle,
accounted for, I think that something goes wrong by some cropping
operation, as if the transformed pointer coordinates are cropped to the
window dimension.
Best,
Julius
Simple::Simple()
{
set_title("Papyrus Object Picking Demo");
Rectangle::pointer rect;
Circle::pointer circle;
RegularPolygon::pointer regularpolygon;
Group::pointer group;
rect = Rectangle::create( "rectangle", 40, 80, RGBA("red") );
circle = Circle::create( "circle", 60, RGBA("green") );
regularpolygon = RegularPolygon::create( "octagon", 8, 40,
RegularPolygon::ZERO_APOTHEM, RGBA("blue"));
group = Group::create();
m_viewport.canvas()->add( group );
group->add( rect );
group->add( circle );
group->add( regularpolygon );
group->set_xy( 20, 20 );
m_viewport.signal_papyrus_event().connect( sigc::mem_fun(*this,
&Simple::on_papyrus_event));
add(m_viewport);
show_all();
}
Rick L. Vinyard, Jr. wrote:
> Just an update...
>
> I cleaned up and simplified (I removed about 80% of the code) the picking
> example before digging into Group::select(). After simplifying it I made a
> few small changes to the way Viewport handles event propagation and used
> the new signal_papyrus_event() method in the picking example.
>
> However, selection seems to be fine in the picking example. Take a look at
> the new one and let me know if you have any questions or if you find any
> examples that break the selection code.
>
> I've released 0.10.1 that incorporates these changes.
>
> Even though the simple pick example works there could still be an issue
> with a larger example that incorporates different elements.
>
> ---
>
> Rick
>
> Julius Ziegler wrote:
>> Hello Rick,
>>
>> First I would like to say thank you for this great library. It really
>> fills a gap, in my opinion!
>>
>> Now, I cannot get picking to work. I am using PapyrusGTK. I believe that
>> just feeding coordinates from Papyrus::Gtk::Viewport::get_pointer(...)
>> (inherited from Gtk::Widget) into
>> Papyrus::Gtk::Viewport::canvas()->select() should "just work",
>> independently from transformations applied within the canvas, but it
>> does not. I am not using custom shapes, just circles and rectangles (and
>> groups thereof).
>>
>> The "pick" demo from the examples directory does not seem to work right
>> either. I am sometimes getting "picked object at ..." messages, but the
>> area where this happens does not really have something to do with the
>> objects in the canvas (might be only an offset, though).
>>
>> Am I forgetting to apply some necessary transformations to the pointer
>> coordinates?
>>
>> Thanks!
>>
>> Julius
>>
>> ------------------------------------------------------------------------------
>> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
>> CA
>> -OSBC tackles the biggest issue in open source: Open Sourcing the
>> Enterprise
>> -Strategies to boost innovation and cut costs with open source
>> participation
>> -Receive a $600 discount off the registration fee with the source code:
>> SFAD
>> http://p.sf.net/sfu/XcvMzF8H
>> _______________________________________________
>> Libpapyrus-users mailing list
>> Libpapyrus-users@...
>> https://lists.sourceforge.net/lists/listinfo/libpapyrus-users
>>
>

Just an update...
I cleaned up and simplified (I removed about 80% of the code) the picking
example before digging into Group::select(). After simplifying it I made a
few small changes to the way Viewport handles event propagation and used
the new signal_papyrus_event() method in the picking example.
However, selection seems to be fine in the picking example. Take a look at
the new one and let me know if you have any questions or if you find any
examples that break the selection code.
I've released 0.10.1 that incorporates these changes.
Even though the simple pick example works there could still be an issue
with a larger example that incorporates different elements.
---
Rick
Julius Ziegler wrote:
> Hello Rick,
>
> First I would like to say thank you for this great library. It really
> fills a gap, in my opinion!
>
> Now, I cannot get picking to work. I am using PapyrusGTK. I believe that
> just feeding coordinates from Papyrus::Gtk::Viewport::get_pointer(...)
> (inherited from Gtk::Widget) into
> Papyrus::Gtk::Viewport::canvas()->select() should "just work",
> independently from transformations applied within the canvas, but it
> does not. I am not using custom shapes, just circles and rectangles (and
> groups thereof).
>
> The "pick" demo from the examples directory does not seem to work right
> either. I am sometimes getting "picked object at ..." messages, but the
> area where this happens does not really have something to do with the
> objects in the canvas (might be only an offset, though).
>
> Am I forgetting to apply some necessary transformations to the pointer
> coordinates?
>
> Thanks!
>
> Julius
>
> ------------------------------------------------------------------------------
> Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco,
> CA
> -OSBC tackles the biggest issue in open source: Open Sourcing the
> Enterprise
> -Strategies to boost innovation and cut costs with open source
> participation
> -Receive a $600 discount off the registration fee with the source code:
> SFAD
> http://p.sf.net/sfu/XcvMzF8H
> _______________________________________________
> Libpapyrus-users mailing list
> Libpapyrus-users@...
> https://lists.sourceforge.net/lists/listinfo/libpapyrus-users
>

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=6647001
By: rvinyard
This release contains a few minor changes to the handling of events within the
papyrus-gtkmm Viewport class. The drawable picking example has also been updated
and simplified to focus on how to perform mouse-based selection.
Other items include:
* Added Papyrus::Event::InterruptMarshaller to stop signal propagation on the
first true slot return value.
* Added Papyrus::Event::signal typedef to simplify the declaration event signals
with an interrupt marshaller
* Added signal_event_papyrus() to Viewport allowing connections to be made to
the Viewport papyrus events
* Added a drawable vector typedef named Selection to simplify Group::select(x,y)
returns
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=500340

Julius Ziegler wrote:
> Hello Rick,
>
> First I would like to say thank you for this great library. It really
> fills a gap, in my opinion!
Thanks.
>
> Now, I cannot get picking to work. I am using PapyrusGTK. I believe that
> just feeding coordinates from Papyrus::Gtk::Viewport::get_pointer(...)
> (inherited from Gtk::Widget) into
> Papyrus::Gtk::Viewport::canvas()->select() should "just work",
> independently from transformations applied within the canvas,
It should... but there have been some significant changes recently that
might have broken something. I'll take a look at the example.
> but it
> does not. I am not using custom shapes, just circles and rectangles (and
> groups thereof).
>
> The "pick" demo from the examples directory does not seem to work right
> either. I am sometimes getting "picked object at ..." messages, but the
> area where this happens does not really have something to do with the
> objects in the canvas (might be only an offset, though).
>
> Am I forgetting to apply some necessary transformations to the pointer
> coordinates?
No, it should be able to take the pointer coordinates without
modification. Sounds like something is broken.

Hello Rick,
First I would like to say thank you for this great library. It really
fills a gap, in my opinion!
Now, I cannot get picking to work. I am using PapyrusGTK. I believe that
just feeding coordinates from Papyrus::Gtk::Viewport::get_pointer(...)
(inherited from Gtk::Widget) into
Papyrus::Gtk::Viewport::canvas()->select() should "just work",
independently from transformations applied within the canvas, but it
does not. I am not using custom shapes, just circles and rectangles (and
groups thereof).
The "pick" demo from the examples directory does not seem to work right
either. I am sometimes getting "picked object at ..." messages, but the
area where this happens does not really have something to do with the
objects in the canvas (might be only an offset, though).
Am I forgetting to apply some necessary transformations to the pointer
coordinates?
Thanks!
Julius

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=6529413
By: rvinyard
This release introduces new changes to support more of an SVG-like structure
including paint and drawable dictionaries respectively similar in concept to
SVG's paint servers and defs section.
This release also adds two new dependencies on glibmm (mainly for UTF strings
and regular expression support) and libxml++ as well as removing the dependency
on expat.
Limited support for linear gradients in SVGs is also introduced as is the new
class Paint; a thin encapsulation of cairo's patterns with a signal emitted
when the pattern is changed.
Also new is extended unit tests and devhelp support.
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=500340

Read and respond to this message at:
https://sourceforge.net/forum/message.php?msg_id=6391566
By: rvinyard
With this release papyrus changes from GPLv3 to LGPLv3.
This release also contains a rewrite of the extents calculation mechanisms (fixing
some issues with viewboxes) and the controller hierarchy.
Other changes include the addition of a new shape Annulus (aka donut, ring),
extended documentation including a brief discussion on the role of MVC within
papyrus, and a few other code cleanups and bug fixes.
______________________________________________________________________
You are receiving this email because you elected to monitor this forum.
To stop monitoring this forum, login to SourceForge.net and visit:
https://sourceforge.net/forum/unmonitor.php?forum_id=500340