libpapyrus-devel Mailing List for papyrus - C++ Cairo Scenegraph library (Page 3)
Status: Beta
Brought to you by:
rvinyard
You can subscribe to this list here.
2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2007 |
Jan
(8) |
Feb
(20) |
Mar
(2) |
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(2) |
Dec
|
2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2009 |
Jan
(3) |
Feb
(3) |
Mar
(12) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: SourceForge.net <no...@so...> - 2007-02-24 21:15:15
|
Patches item #1662558, was opened at 2007-02-17 15:41 Message generated for change (Settings changed) made by rvinyard You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662558&group_id=149649 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: Peter Miller (pmiller) >Assigned to: Rick L. Vinyard, Jr. (rvinyard) Summary: tweak configure.in Initial Comment: I had to move the AC_PROG_LIBTOOL further forward in the configure.in file to avoid a heap of errors from automake. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662558&group_id=149649 |
From: SourceForge.net <no...@so...> - 2007-02-23 18:29:09
|
Patches item #1667320, was opened at 2007-02-23 18:29 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1667320&group_id=149649 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Mjumbe Wawatu Ukweli (mjumbewu) Assigned to: Nobody/Anonymous (nobody) Summary: lower_to_bottom in Papyrus::Group Initial Comment: There is currently a bug in the lower_to_bottom function in Papyrus::Group. If an item is at the top of its layer, it will not move to the bottom. This is a (potential) fix: line 332 in papyrus/group.cpp is currently: if ( ... && ichild != ilayer->second.begin() ) { ... should be: if ( ... && ++ichild != ilayer->second.end() ) { --ichild; ... because in lower_to_bottom, you want to check that the item is not already at the bottom, not the top. Is there a better way to do this than incrementing and decrementing the iterator? I was thinking using "item != ilayer->second.back()" instead (and analagously "item != ilayer->second.front()" in raise_to_top), but I feel better about comparing the iterators. Also (and this is NOT in the attached patch), the conditions could be nested instead of in the same if clause in order to save on some potentially unnecessary iterations of the for loop, as long as each item exists on at most one layer. i.e.: if ( ichild != ilayer->second.end() ) { if ( ichild != ilayer->second.begin() ) { ... } return true; } ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1667320&group_id=149649 |
From: SourceForge.net <no...@so...> - 2007-02-17 22:44:09
|
Patches item #1662562, was opened at 2007-02-17 22:44 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662562&group_id=149649 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Miller (pmiller) Assigned to: Nobody/Anonymous (nobody) Summary: useless white space Initial Comment: Trailing white space has been removed from the ends of source lines. Blank lines have been removed from the ends of files. These things bug me. Cal it a pet peeve. Humans can't see them, and from time to time over the years they have bitten me. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662562&group_id=149649 |
From: SourceForge.net <no...@so...> - 2007-02-17 22:42:42
|
Patches item #1662560, was opened at 2007-02-17 22:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662560&group_id=149649 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Miller (pmiller) Assigned to: Nobody/Anonymous (nobody) Summary: Papyrus::Image(Cairo::Image*) Initial Comment: It is now possible to create a Papyrus::Image from a Cairo::Image. This means it is possible to have a single image drawn more than once into the canvas. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662560&group_id=149649 |
From: SourceForge.net <no...@so...> - 2007-02-17 22:41:14
|
Patches item #1662558, was opened at 2007-02-17 22:41 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662558&group_id=149649 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Peter Miller (pmiller) Assigned to: Nobody/Anonymous (nobody) Summary: tweak configure.in Initial Comment: I had to move the AC_PROG_LIBTOOL further forward in the configure.in file to avoid a heap of errors from automake. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=775467&aid=1662558&group_id=149649 |
From: Rick L V. Jr <rvi...@cs...> - 2007-02-13 06:05:52
|
Peter Miller wrote: > If the get_rotation, get_scale, etc, methods weren't there, the internal > transformation state could be kept in a cairo_matrix_t object, and a > set_matrix method would be possible. > > And much of the internal machinery for tracking it (m_scale_x, y, > m_rotate, m_centroid_x,y, etc) would be unnecessary. If a user needs to > track this, say to animate a rotation, they can do it a derived class or > in a Controller. > > I am wondering if the Drawable transform methods should perhaps mirror > the Cairo::Context transform methods? i.e. > > void translate(double tx, double ty); > void scale(double sx, double sy); > void rotate(double angle); > void transform(const Cairo::Matrix &matrix); > void set_matrix(const Cairo::Matrix &matrix); > void get_matrix(Cairo::Matrix &matrix) const; > void set_identity_matrix(); > > It would be less confusing if there were fewer API differences between a > Papyrus::Drawable's transforms and a Cairo::Context's transforms. > I'm actually torn between the two methods. The latter approach was the initial approach I took until I needed the ability to track the individual transforms, which is the common case for a lot of what I'm doing at which point I switched to the former (current) approach... which predated the introduction of controllers (or really re-introduction since I had them in papyrus' predecessor). Moving that behavior into a controller would certainly lean up the API. But, at the same time I'm not really comfortable with the Model/Controller interaction... something seems like it's still missing there in the API. > It took me a while to see that you are trying to have an M-V-C > separation, where the Papyrus::Renderable is the Model, and the > PapyrusGtk::Viewport is the view, which then makes the name of the > Papyrus::Controller class make sense. It would help of the Doxygen > descriptions of the base class(es) included this rationale, if I have > interpreted your design correctly. > Yes, that is a correct interpretation. Unfortunately I haven't had much time to update the docs. In particular I wanted the separation between the model and the view to allow the model to render independent of Gtk, and the controller to allow for controls beyond the UI (i.e. as the result of an inference engine or other external events beyond the traditional keyboard/mouse events). |
From: Rick L V. Jr <rvi...@cs...> - 2007-02-13 05:32:10
|
Peter Miller wrote: > Interesting things happen if you attempt to put an images into more than > one group: neither group draws it. > There must be a bug in there somewhere then. What should be happening is that the image is unparented from the first group and reparented to the second. > What I probably want is a Papyrus::Image constructor (and corresponding > create class method, and set_image method) which takes a > Cairo::ImageSurface::pointer argument. That way I can draw the same > image over and over, without consuming more memory. > That's a good idea. > But it raises an interesting point: what is the correct way to draw a > group more than one, in more than one place? E.g. sprites in games. > That was a tough design decision. In earlier versions a child knew nothing of its parent, and there was even an example which used sprite like animations to move the wheels on a car. But, I changed the behavior to accommodate the case of doing hit tests on objects without traversing downward through the scene graph. In order to do it the child needed to be aware of the parent's transformation matrix, so I took the easy way out and only allowed for a single parent. Unfortunately that also meant creating multiple copies of objects, and gave up the ability to have modifications to a single object take effect in whatever multiple places it was in the scenegraph. I suppose one solution would be to allow a child to know about multiple parents... > How about I start sending some patches? > Absolutely. Any and all help is welcome. Ideally, I'd prefer to see them posted to Sourceforge's patch tracker so that anyone else can use and examine them without waiting for me to integrate them, in case I can't get to them right away. Also, it would make it a lot easier if they were done as diffs against CVS. > Do you have an .indent.pro file you can send me so that indent(1) > formats source files the way you like? > Nah, don't worry about it... kdevelop will take care of it with 'source reformat'. Any formatting that's reasonably readable is fine. |
From: Jon P. <jo...@re...> - 2007-01-30 06:08:57
|
This is great Rick and libpapyrus-devel ppl. I'm cc'ing the Inkscape-devel list, Bryce Harrington and Mental, both core developers on Inkscape, as they can more adequately ask/answer questions. More below... On Mon, 2007-01-29 at 22:51 -0700, Rick L Vinyard Jr wrote: > Jon Phillips wrote: > > Message body follows: > > > > Hi, have you considered using Inkscape's canvas for your > > project (http://inkscape.org). > When I thought about restructuring glcanvasmm (an OpenGL based canvas) > as the cairo based (and then later cairomm based) papyrus I looked all > over for a library that would make it easy to do research in > diagrammatic reasoning... more specifically visual programming languages > (not Visual C++)... and even more specifically rule-based visual languages. > > I looked at GnomeCanvas, GnomeCanvasmm, Evas, DiaCanvas, Zinc, FooCanvas > (GooCanvas didn't exist then), et. al with the thought of just using the > library or writing a wrapper for the non-C++ libraries. I also looked at > several apps such as Dia, Inkscape, Sodipodi, et. al. with the thought > of extracting the drawing canvas. I even looked at pure vector drawing > libraries as well as 3D scenegraph libraries (such as Ogre and > OpenSceneGraph) that also had decent support for 2D primitives. > > Specifically, several things I was looking for: > * A standalone object-oriented C++ library with a minimalist set of > dependencies... to paraphrase Einstein... as few dependencies as > possible, but no fewer. > > * Easy to extend the canvas items either through inheritance or > through new drawing primitives > > * Easy to modify the behavior of objects in the canvas, either through > external controllers and events or through user interaction > > * Because of the above reasons, I really wanted something that > returned to Smalltalk's concept of a Model-View-Controller as separate > concepts > > So, I suppose to bring a long answer to your question to a conclusion... > yes, I did consider Inkscape's canvas but I really wanted something that > didn't tie the geometrical structure (model) to Gtk or the display (view > and controller), and at the time it looked like more work to extract the > canvas from Inkscape (or any of the other apps) and rewrite it as a > cairo based canvas, as opposed to rewriting glcanvasmm as a cairo based > canvas. > > But, I'm always open to either: > (1) Using sp_canvas if it makes sense > (2) Looking to sp_canvas as a model for improving the papyrus canvas Great! Ok, I hope we can work towards a model of collaboration. > With respect to (2), I know there are many aspects of the papyrus canvas > that are ripe for improvement. In particular, I've been looking for an > easy to use API first and speed second. That doesn't mean I'm not > concerned about speed... just that it is currently second in priority. This seems to be the same strategy for cairo. > > We are trying to modularize > > our code more so that we can help other projects and get > > more contributors. > That sounds great. I think there are many pieces of Inkscape that could > be reused all over the place if they were structured into libraries. Yes, we are working towards this. Maybe you could recommend pieces you would like that we could work to box up :) > > Plus, we want the benefits of Cairo on > > our app. > > > Which is a huge benefit. That's another reason for the separation > between papyrus and papyrusmm. Papyrus renderables only require a cairo > context to draw into, and thus only has a dependency on cairomm. Wow, cool! > Also, just browsing through the Inkscape repository, it looks like there > is a lot of duplicative effort between the Inkscape codebase and cairo. > For example: > > 88 void sp_curve_reset(SPCurve *curve); > 89 > 90 void sp_curve_moveto(SPCurve *curve, NR::Point const &p); > 91 void sp_curve_moveto(SPCurve *curve, gdouble x, gdouble y); > 92 void sp_curve_lineto(SPCurve *curve, NR::Point const &p); > 93 void sp_curve_lineto(SPCurve *curve, gdouble x, gdouble y); > 94 void sp_curve_lineto_moving(SPCurve *curve, gdouble x, gdouble y); > 95 void sp_curve_curveto(SPCurve *curve, NR::Point const &p0, NR::Point const &p1, NR::Point const &p2); > 96 void sp_curve_curveto(SPCurve *curve, gdouble x0, gdouble y0, gdouble x1, gdouble y1, gdouble x2, gdouble y2); > 97 void sp_curve_closepath(SPCurve *curve); > 98 void sp_curve_closepath_current(SPCurve *curve); > > From a cursory scan it looks like these and other methods could be > eliminated by moving to cairo. And, if there is some optimization you > have that cairo doesn't, I'm sure Carl would gladly accept patches. Yes, agree. He sits in our channel all the time, so we are all buddies :) > > If you get a chance, please check out sp-canvas.cpp which is > > our main canvas code. It works really well: > > > > http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/display/sp-canvas.cpp?view=markup > > > I have... along with many of the canvas items as well. There are some > great things there. > > > Also, please forward this onto your project list so others > > can see. > Not a problem. Great Rick, lets keep the dialogue happening and hopefully great collaboration we can aim towards :) Jon > --- > > Rick > -- Jon Phillips San Francisco, CA USA PH 510.499.0894 jo...@re... http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: re...@gr... IRC: re...@ir... |
From: Rick L V. Jr <rvi...@cs...> - 2007-01-30 05:52:19
|
Jon Phillips wrote: > Message body follows: > > Hi, have you considered using Inkscape's canvas for your > project (http://inkscape.org). When I thought about restructuring glcanvasmm (an OpenGL based canvas) as the cairo based (and then later cairomm based) papyrus I looked all over for a library that would make it easy to do research in diagrammatic reasoning... more specifically visual programming languages (not Visual C++)... and even more specifically rule-based visual languages. I looked at GnomeCanvas, GnomeCanvasmm, Evas, DiaCanvas, Zinc, FooCanvas (GooCanvas didn't exist then), et. al with the thought of just using the library or writing a wrapper for the non-C++ libraries. I also looked at several apps such as Dia, Inkscape, Sodipodi, et. al. with the thought of extracting the drawing canvas. I even looked at pure vector drawing libraries as well as 3D scenegraph libraries (such as Ogre and OpenSceneGraph) that also had decent support for 2D primitives. Specifically, several things I was looking for: * A standalone object-oriented C++ library with a minimalist set of dependencies... to paraphrase Einstein... as few dependencies as possible, but no fewer. * Easy to extend the canvas items either through inheritance or through new drawing primitives * Easy to modify the behavior of objects in the canvas, either through external controllers and events or through user interaction * Because of the above reasons, I really wanted something that returned to Smalltalk's concept of a Model-View-Controller as separate concepts So, I suppose to bring a long answer to your question to a conclusion... yes, I did consider Inkscape's canvas but I really wanted something that didn't tie the geometrical structure (model) to Gtk or the display (view and controller), and at the time it looked like more work to extract the canvas from Inkscape (or any of the other apps) and rewrite it as a cairo based canvas, as opposed to rewriting glcanvasmm as a cairo based canvas. But, I'm always open to either: (1) Using sp_canvas if it makes sense (2) Looking to sp_canvas as a model for improving the papyrus canvas With respect to (2), I know there are many aspects of the papyrus canvas that are ripe for improvement. In particular, I've been looking for an easy to use API first and speed second. That doesn't mean I'm not concerned about speed... just that it is currently second in priority. > We are trying to modularize > our code more so that we can help other projects and get > more contributors. That sounds great. I think there are many pieces of Inkscape that could be reused all over the place if they were structured into libraries. > Plus, we want the benefits of Cairo on > our app. > Which is a huge benefit. That's another reason for the separation between papyrus and papyrusmm. Papyrus renderables only require a cairo context to draw into, and thus only has a dependency on cairomm. Also, just browsing through the Inkscape repository, it looks like there is a lot of duplicative effort between the Inkscape codebase and cairo. For example: 88 void sp_curve_reset(SPCurve *curve); 89 90 void sp_curve_moveto(SPCurve *curve, NR::Point const &p); 91 void sp_curve_moveto(SPCurve *curve, gdouble x, gdouble y); 92 void sp_curve_lineto(SPCurve *curve, NR::Point const &p); 93 void sp_curve_lineto(SPCurve *curve, gdouble x, gdouble y); 94 void sp_curve_lineto_moving(SPCurve *curve, gdouble x, gdouble y); 95 void sp_curve_curveto(SPCurve *curve, NR::Point const &p0, NR::Point const &p1, NR::Point const &p2); 96 void sp_curve_curveto(SPCurve *curve, gdouble x0, gdouble y0, gdouble x1, gdouble y1, gdouble x2, gdouble y2); 97 void sp_curve_closepath(SPCurve *curve); 98 void sp_curve_closepath_current(SPCurve *curve); From a cursory scan it looks like these and other methods could be eliminated by moving to cairo. And, if there is some optimization you have that cairo doesn't, I'm sure Carl would gladly accept patches. > If you get a chance, please check out sp-canvas.cpp which is > our main canvas code. It works really well: > > http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/display/sp-canvas.cpp?view=markup > I have... along with many of the canvas items as well. There are some great things there. > Also, please forward this onto your project list so others > can see. Not a problem. --- Rick |
From: SourceForge.net <no...@so...> - 2007-01-21 03:22:21
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=4113671 By: rvinyard Release Name: 0.7.0 Notes: This release adds the concept of drawing layers within Groups, and the use of layers is shown in the rewritten Boxed and Handlebox classes. Methods show(), hide() and is_visible() have been added to Drawable. Rectangle, Circle and Arc also have new create() methods that accept default fill and outline patterns, allowing most basic aspects to be defined in construction. Changes: 2007-01-19 Rick L Vinyard Jr <rvi...@cs...> ===== 0.7.0 ===== ViewBox: Renamed to Viewbox Viewbox: Added equality and assignment operators Moved papyrus.h to top-level directory, so syntax is #include <papyrus.h> rather than #include <papyrus/papyrus.h> Drawable: Added show(), hide() and is_visible() methods. Drawable: Added set_exclude_from_extents() Group: Added concept of layers within a group. Group: Removed Children typedef, use Layers and Layer. Added Position enum Rectangle: Added parameter to create() to accept fill pattern, and added new create() method to allow fill and outline on creation. Circle: Added parameter to create() to accept fill pattern, and added new create() method to allow fill and outline on creation. Arc: Added parameter to create() to accept fill pattern, and added new create() method to allow fill and outline on creation. Boxed: Rewrote to take advantage of group layers and draw box always at lowest possible layer Handlebox: Rewrote to take advantage of group layers and draw markers at highest possible layer to keep on top Handlebox: Added activate_handle(), deactivate_handle() and is_active() Handlebox: Removed clear_handle() methods. Use deactivate_handle() instead. Handlebox: Changed handle methods to accept enums rather than ints. ______________________________________________________________________ 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=500341 |
From: SourceForge.net <no...@so...> - 2007-01-08 06:19:12
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=4091239 By: rvinyard This release features a working implementation of the Grid item. A Grid is a canvas item that inherits from Drawable, and thus can have any of the standard affine transforms (scaling, rotation, translation, skewing) applied to it. It provides an API that allows for independent line drawing styles of the X and Y axes, each border and X and Y interval lines. Additionally, initialization of the X11 color map has been split into four files to make compilation easier on machines with 512MB or less. Changes: 2007-01-07 Rick L Vinyard Jr <rvi...@cs...> ===== 0.6.1 ===== Split the X11 color initializer into four files to allow building the std::map on low memory machines Improved the grid example to include borders and interval lines. Papyrus::Linestyle: Added operator == and operator != Papyrus::Grid: Working now... no longer just a preview ______________________________________________________________________ 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=500341 |
From: Rick L V. Jr <rvi...@cs...> - 2007-01-04 23:23:28
|
Rick L Vinyard Jr wrote: > > The gcc-4.x series seems to have some issues regarding memory > > consumption when compiling c++ code. This hits the compiling process of > > x11_color.cpp, since hundreds of RGBA structs are constructed and filled > > into a map. Until the gcc team handled the mentioned issue, a workaround > > could be to split x11_color.cpp into > > - x11_color.cpp > > - x11_colors_1of2.cpp > > - x11_colors_2of2.cpp > > Good idea. That is a bit of a bear to compile. > > Unfortunately, I didn't get it into 0.6.0, but I'll release an 0.6.1 > right away if you want to post a patch. Probably the best place would be > Sourceforge's patch tracker. > > I've already split it into four files (to be kinder to those with 256mb RAM). I'll release 0.6.1 in the next few days. |
From: Rick L V. Jr <rvi...@cs...> - 2007-01-03 06:26:20
|
> The gcc-4.x series seems to have some issues regarding memory > consumption when compiling c++ code. This hits the compiling process of > x11_color.cpp, since hundreds of RGBA structs are constructed and filled > into a map. Until the gcc team handled the mentioned issue, a workaround > could be to split x11_color.cpp into > - x11_color.cpp > - x11_colors_1of2.cpp > - x11_colors_2of2.cpp Good idea. That is a bit of a bear to compile. Unfortunately, I didn't get it into 0.6.0, but I'll release an 0.6.1 right away if you want to post a patch. Probably the best place would be Sourceforge's patch tracker. |
From: Rick L V. Jr <rvi...@cs...> - 2007-01-03 06:22:39
|
> The link to the gtk widget example gallery at the font page > navigation-bar points to > http://libpapyrus.sourceforge.net/gallery/papyrusgtk/index.html > which doesn't work, because it should be > http://libpapyrus.sourceforge.net/gallery/papyrusmm/index.html > I think. Got it fixed. Thanks. |
From: Rick L V. Jr <rvi...@cs...> - 2007-01-03 06:15:25
|
Some new features, some drawing improvements and some bug fixes. The drawing improvements use more of the cairo API to improve both speed and drawing quality. Several new controllers are present such as the Rotator and Scaler controllers that can be used in combination with a Handlebox. This presents handles on selections that can be used for rotation and scaling. The demo has been extended to demonstrate the operation of the new controllers and also contains example code. Changelog: 2007-01-02 Rick L Vinyard Jr <rvi...@cs... <mailto:rvi...@cs...>> ===== 0.6.0 ===== 2007-01-01 Rick L Vinyard Jr <rvi...@cs... <mailto:rvi...@cs...>> Papyrus demo: Added Rotator controller demo Papyrus demo: Added Scaler controller demo Papyrus demo: Added Handlebox Scaler demo Papyrus demo: Updated selector demo to use Selector controller's new selection group Papyrus demo: Updated translator demo to include a box around selected items Papyrus::Boxed Added constructor that accepts a parent group Won't draw() if there are no children Papyrus::Drawable Added distance_global_to_local() and distance_local_to_global() for transforming distances to/from drawable's local/global coordinate spaces Added local_extents() which provides extents after local affine transforms have been applied Renamed extents_transformed() to global_extents() Added the concept of a drawing parent responsible for drawing order Papyrus::Group Added constructor that accepts parent group Made most methods such as add(), remove(), raise(), etc. virtual Changed m_connections to m_redraw_connections Changed m_child_connections to m_changed_connections Changed on_child_need_redraw() to append pointer to child as last parameter Rewrote add() and remove() methods to account for containing a child as a drawing parent only Rewrote draw() to only draw children that this group is responsible for calling render upon Papyrus::Handlebox Added constructor that allows specification of which default handles to create Papyrus::Selector Changed selection_group to select_from_group notation Added constructor that accepts selection group to add/remove selection to/from Added extents() to return global extents of selection Papyrus::Shape Fixed bug that didn't set fill and outline paths to null after freeing objects Papyrus::Translator Added constructor that accepts selection group to add/remove selection to/from Fixed bug that didn't set y coordinate of original translation position Added Papyrus::Rotator Added Papyrus::Scaler 2006-12-03 Rick L Vinyard Jr <rvi...@cs... <mailto:rvi...@cs...>> Changed *_boundingbox() notation to *_extents() Changed need_redraw() methods to shape_changed() Polygon: Use cairo's close_path() rather than drawing to starting vertex. Shape: Reimplemented to use cached cairo paths rather than recreating paths every time the shape is redrawn. Added Grid drawable. |
From: Maik B. <mai...@gm...> - 2006-11-21 14:00:29
|
Hello The link to the gtk widget example gallery at the font page navigation-bar points to http://libpapyrus.sourceforge.net/gallery/papyrusgtk/index.html which doesn't work, because it should be http://libpapyrus.sourceforge.net/gallery/papyrusmm/index.html I think. greetz Maik |
From: Maik B. <mai...@gm...> - 2006-11-13 10:10:09
|
Hello Rick The gcc-4.x series seems to have some issues regarding memory consumption when compiling c++ code. This hits the compiling process of x11_color.cpp, since hundreds of RGBA structs are constructed and filled into a map. Until the gcc team handled the mentioned issue, a workaround could be to split x11_color.cpp into - x11_color.cpp - x11_colors_1of2.cpp - x11_colors_2of2.cpp where x11_colors( ) in x11_color.cpp now looks like <code> #include "x11_color.h" #include <papyrus/rgba.h> namespace Papyrus { void fill_x11_colors_1of2(X11Colors& colors); void fill_x11_colors_2of2(X11Colors& colors); X11Colors x11_colors( ) { X11Colors colors; fill_x11_colors_1of2(colors); fill_x11_colors_2of2(colors); return colors; } //... } </code> and i.e. x11_colors_1of2.cpp <code> #include "x11_color.h" #include <papyrus/rgba.h> namespace Papyrus { void fill_x11_colors_1of2(X11Colors& colors ) { colors["snow"] = RGBA( 1, 0.980392156862745, 0.980392156862745 ); // ... } } </code> The x11_color.cpp entry for libpapyrus_la_SOURCES has to be changed to - ... x11_colors_1of2.cpp x11_colors_2of2.cpp x11_color.cpp ... This decreases the memory consumption dramatically and a PC with 512MB ram can compile papyrus without problems(sure only if make -j1 is used). If you want me to, I can send a papyrus-0.5.1-patched.tar.gz or the files: - papyrus/Makefile.am - papyrus/x11_color.cpp - papyrus/x11_colors_1of2.cpp - papyrus/x11_colors_2of2.cpp Regards, Maik Beckmann |