libpapyrus-devel Mailing List for papyrus - C++ Cairo Scenegraph library
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: Rick L. V. Jr. <rvi...@cs...> - 2010-04-16 16:48:34
|
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). |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-12-11 15:21:55
|
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. |
From: SourceForge.net <no...@so...> - 2009-09-01 20:49:10
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7602268 By: rvinyard This release modifies the basic demo adding support for scrolled viewports and zooming on the shapes. New shapes are Deltilles, Hextilles and Quadrilles. ______________________________________________________________________ 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...> - 2009-08-05 21:20:12
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7546810 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=500341 |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-05-26 16:43:09
|
Denis Leroy wrote: > Rick L. Vinyard, Jr. wrote: >> Hello Denis, >> >> Just wondering if you've had a chance to check out the effects of the >> cairomm update? If not, no rush. > > Hi Rick, > > Seems to be working good, so I can't see any issues with the update. > Just an update. I've found an ABI breakage in Cairo::Context::transform()... I built papyrus against 1.6.4, and it rebuilds fine against cairomm 1.8.0. But, when conexus builds it's getting: /usr/lib/gcc/i386-redhat-linux/4.3.2/../../../libpapyrus.so: undefined reference to `Cairo::Context::transform(_cairo_matrix const&)' Rebuilding papyrus against cairomm 1.8 resolves the symbol, so I don't think it's an API issue.... looks like an ABI issue. cairomm should probably have the soname bumped. |
From: SourceForge.net <no...@so...> - 2009-05-14 18:23:37
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=7392213 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=500341 |
From: SourceForge.net <no...@so...> - 2009-03-18 19:02:02
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6859110 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=500341 |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-03-17 18:34:34
|
Thanks again. This one's applied in subversion now as well. Tim Niemueller wrote: > Hi Rick. > > Attached is a patch that fixes the Canvas background drawing. The > Canvas::draw() method was lacking a const declarator at the end. I'm > surprised though that the compiler didn't mention the improper > signature. Or it did and went unnoticed in all the compile output... > > Tim > > -- > Tim Niemueller <ti...@ni...> www.niemueller.de > ================================================================= > Imagination is more important than knowledge. (Albert Einstein) > |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-03-17 18:27:22
|
Tim Niemueller wrote: > Rick L. Vinyard, Jr. schrieb: >> Check out the new changes in subversion. They seem to be working on this >> end. With the changes there are no more lists within maps. Just a flat >> map >> with a reference count, so it should be alot simpler. > > Hmm, it fails to build from source for me: > > make[4]: *** No rule to make target `example_SVG.o', needed by > `papyrus-demo'. Stop. > make[4]: *** Waiting for unfinished jobs.... > > Any idea? example_SVG.cpp was missing from subversion. It's added now. |
From: Tim N. <ti...@ni...> - 2009-03-17 17:12:26
|
Hi Rick. Attached is a patch that fixes the Canvas background drawing. The Canvas::draw() method was lacking a const declarator at the end. I'm surprised though that the compiler didn't mention the improper signature. Or it did and went unnoticed in all the compile output... Tim -- Tim Niemueller <ti...@ni...> www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-03-17 16:41:29
|
Check out the new changes in subversion. They seem to be working on this end. With the changes there are no more lists within maps. Just a flat map with a reference count, so it should be alot simpler. Tim Niemueller wrote: > Rick L. Vinyard, Jr. schrieb: >> Hello again. >> >> I've applied the patch and fixed the naming a bit as well.... mmiter -> >> mapiter, mliter -> listiter > > Gah, seems that I broke something else resulting in an infinite loop > now. I went out for a walk with the dog, while the skillgui was running > at 100%, when I came back the CPU was at 94°C, I noticed because it > burned when I touched the VGA port (Laptop)... > > Ok, maybe you have an idea on this one. I cannot reliably reproduce it. > It occurs, sometimes... Can you see this as well? > > Tim > > -- > Tim Niemueller <ti...@ni...> www.niemueller.de > ================================================================= > Imagination is more important than knowledge. (Albert Einstein) > |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-03-17 16:29:10
|
Tim Niemueller wrote: > Rick L. Vinyard, Jr. schrieb: >> I'm looking at the list patch first. >> >> --- papyrus-0.10.2/papyrus/drawableset.cpp 2009-02-05 >> 23:48:22.000000000 +0100 >> +++ papyrus-0.10.2-drawable-init/papyrus/drawableset.cpp >> 2009-03-17 >> 14:11:26.000000000 +0100 >> @@ -24,7 +24,14 @@ >> >> DrawableSet::DrawableSet(pointer to_copy) >> { >> - if ( to_copy ) m_drawables = to_copy->m_drawables; >> + if ( to_copy ) >> + { >> + m_drawables = to_copy->m_drawables; >> + } >> + else >> + { >> + m_drawables.clear(); >> + } >> } > > That's just a left-over from the first attempts to fix the segfault... > This can be thrown out. > Sounds good. I think I have everything from this patch in subversion now. |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-03-17 16:28:19
|
Tim Niemueller wrote: > Rick L. Vinyard, Jr. schrieb: >> Hello again. >> >> I've applied the patch and fixed the naming a bit as well.... mmiter -> >> mapiter, mliter -> listiter >> >> As I apply these I'll commit them to subversion. > > Please find a new patch attached. This patch also adds the missing > disconnection of the matrix changed signal. That was causing the next > segfaults. > I've made a few more changes to the matrix changed signal. They're committed in subversion. It should clean up the external matrix signal changed handling, especially if you add the same matrix multiple times. Now, for each matrix there will only be one instance of a changed signal rather than one callback for every time the matrix has been added to the drawable. There is also a unit test added to check the correctness of the reference counting mechanism I put in. > In general, the translations are horribly slow even for small size > graphs. This is caused by the slow drawing in general that comes from > the extent calculations. For now I turn off the Translator, it just > makes the app look jerky. Papyrus realls needs to improve on the drawing > speed as this is critical for a lib like this. It does, but at this point it's mainly been optimization as needed. I've been focusing on getting the stuff into the API that is needed and then planning on optimizing at the end. In the meantime, it's mainly been a matter of looking for optimizations when things seem too slow. --- Rick |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-03-17 14:57:00
|
Hello again. I've applied the patch and fixed the naming a bit as well.... mmiter -> mapiter, mliter -> listiter As I apply these I'll commit them to subversion. --- Rick Tim Niemueller wrote: > Hi Rick. > > I have attached a patch which fixes two cases of invalid list iterator > usage in the Drawable class. > > A list was iterated over with a for loop, possibly erasing elements. > However, the iterator is no longer valid after the element has been > erased. This can be alleviated by using a while loop and appropriately > either use the return value of std::list::erase() or advance if nothing > was deleted. The attached patch does that. I haven't checked the rest of > the code if there are more of those, but a quick grep for erase suggests > so. Have you had some time to look over the other patches? > > Tim > > -- > Tim Niemueller <ti...@ni...> www.niemueller.de > ================================================================= > Imagination is more important than knowledge. (Albert Einstein) > |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-03-17 14:56:26
|
I'm looking at the list patch first. --- papyrus-0.10.2/papyrus/drawableset.cpp 2009-02-05 23:48:22.000000000 +0100 +++ papyrus-0.10.2-drawable-init/papyrus/drawableset.cpp 2009-03-17 14:11:26.000000000 +0100 @@ -24,7 +24,14 @@ DrawableSet::DrawableSet(pointer to_copy) { - if ( to_copy ) m_drawables = to_copy->m_drawables; + if ( to_copy ) + { + m_drawables = to_copy->m_drawables; + } + else + { + m_drawables.clear(); + } } DrawableSet::~DrawableSet() I noticed that you added the m_drawables.clear() if to_copy is a NULL pointer. But, since m_drawables is a std::set<Drawable::pointer> I'm not sure that is really necessary since the set is already instantiated as empty when it is constructed. I'm looking through a grep for erase now to see if there are any other changes. Tim Niemueller wrote: > Hi Rick. > > I have attached a patch which fixes two cases of invalid list iterator > usage in the Drawable class. > > A list was iterated over with a for loop, possibly erasing elements. > However, the iterator is no longer valid after the element has been > erased. This can be alleviated by using a while loop and appropriately > either use the return value of std::list::erase() or advance if nothing > was deleted. The attached patch does that. I haven't checked the rest of > the code if there are more of those, but a quick grep for erase suggests > so. Have you had some time to look over the other patches? > > Tim > > -- > Tim Niemueller <ti...@ni...> www.niemueller.de > ================================================================= > Imagination is more important than knowledge. (Albert Einstein) > |
From: Tim N. <ti...@ni...> - 2009-03-17 14:26:14
|
Hi Rick. I have attached a patch which fixes two cases of invalid list iterator usage in the Drawable class. A list was iterated over with a for loop, possibly erasing elements. However, the iterator is no longer valid after the element has been erased. This can be alleviated by using a while loop and appropriately either use the return value of std::list::erase() or advance if nothing was deleted. The attached patch does that. I haven't checked the rest of the code if there are more of those, but a quick grep for erase suggests so. Have you had some time to look over the other patches? Tim -- Tim Niemueller <ti...@ni...> www.niemueller.de ================================================================= Imagination is more important than knowledge. (Albert Einstein) |
From: SourceForge.net <no...@so...> - 2009-03-06 19:00:08
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6663514 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=500341 |
From: SourceForge.net <no...@so...> - 2009-03-05 20:34:04
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6647000 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=500341 |
From: SourceForge.net <no...@so...> - 2009-02-25 23:38:29
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6529412 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=500341 |
From: Rick L. V. Jr. <rvi...@cs...> - 2009-02-10 16:29:50
|
Hello. I cc'd the mailing list so that there is an archive of the breakdown of the affine transforms in case anyone else has the same questions, or would like to provide feedback as well. Perhaps I should copy and paste part of the explanation below into the docs? Tim Niemueller wrote: > Hi Rick. > > I have just converted our application from papyrus 0.7 to 0.9 and ran > into a few problems that I wanted to tell you about: > > - The new API documentation hard to read, dark brown on only slightly > lighter brown for the headings, and yellowish brown for black text isn't > very readable. I'd suggest giving the backgrounds a shift to white, > keeping the base color. Currently I have a hard time following the text. Yup. They're pretty bad... that's high on the todo list. I lost the previous css and hacked one up really quick picking some colors that didn't turn out to be very easy on the eyes. > - Currently compilation needs -std=c++0x when using Papyrus on Fedora. > This isn't a nice thing if you do not want to use an incomplete standard > just now. The problem is the smart pointer. As I mentioned earlier I > would suggest to use the Cairo::RefPtr. This is available everywhere > where libpapyrus would be useful and would remove the requirement of > either Boost (pretty fat for just smart pointers), C++0x or TR1, have > the same effect a nicely mix with Cairo. IIRC, Cairo::RefPtr is missing the weak pointer (std::weak_pointer, std::tr1::weak_pointer or boost::weak_pointer) which is needed in several places within papyrus. For example one of the new containers, Watcher, utilizes the weak pointer so that it doesn't take ownership of the object. If you don't compile with -std=c++0x it should default to looking for tr1, and if tr1 isn't found it should default to looking for boost. I looked at including the smart pointer within papyrus, but extracting the implementation from any of the aforementioned sources just looked like a real pain. > - Why is it set_rotation() bit then translate(). I'd suggest to either > have rotate() and translate() or to have set_rotation() and > set_translation(). I'd vote for the latter for the following reason: > When I first read the new documentation about translate() I thought > "Damn, now I need to do all kinds of relative maths", expecting that > translate() would be added every time, like it is in Cairo. Of course > that's nonsense because it's executed on different objects, but still > set_translation() would be much clearer in that it sets a certain > translation. I haven't checked if translate adds the given translation > instead of setting it. If that is the case you might want to have both, > rotate() and translate() *and* set_*(). One will add to the current > rotation/translation, the other one will set it explicitly. For each of the affine transforms there are sets of methods that provide absolute and relative transformation, plus there are sets of accessors to retrieve the current values. For the accessors I used a mixture of 'affine-noun'() and get_'affine-noun'(). Part of the reason was to expose simple access methods for the x and y position with x() and y() allowing code like: if ( drawable->x() > 5 and drawable->x() < 10 ) ... Affine translations were the only ones to use the simpler form, and the other transforms (scaling, rotation, skewing, et. al.) used the get_'affine-noun'() form: x() y() get_position(x,y) get_scale_x() get_scale_y() get_scale(sx,sy) get_rotation() get_skew_x() get_skew_y() get_skew(wx,wy) What I should have probably done was not use 'position' but rather 'translation' or 'xy'. I think I'd prefer to use the latter to stay consistent with the x() and y() methods, so it would look like this: x() y() xy(x,y) get_scale_x() get_scale_y() get_scale(sx,sy) get_rotation() get_skew_x() get_skew_y() get_skew(wx,wy) But, I thought it made the code a bit harder to read, as it turned this: if ( drawable->x() > 5 and drawable->x() < 10 ) ... into this: if ( drawable->get_translate_x() > 5 and drawable->get_translate_x() < 10 ) ... The latter just felt cumbersome. I suppose an alternative would be to provide aliases for x() and y(): x() y() xy(x,y) get_translation_x(): alias for x() get_translation_y(): alias for y() get_translation_xy(): alias for xy() get_scale_x() get_scale_y() get_scale(sx,sy) get_rotation() get_skew_x() get_skew_y() get_skew(wx,wy) For the relative transforms I used a form of 'affine-verb'(parameters): translate(tx, ty) scale(sx, sy) rotate(r) skew(wx, wy) What is probably missing on this list is the individual transforms such as: translate_x(tx) translate_y(ty) scale_x(sx) scale_y(sy) skew_x(wx) skew_y(wy) But, I was trying to keep the set of relative transforms to a minimum. I picked verbs to indicate action upon the drawable. For the absolutes I used set_'affine-noun'() so they are: set_x(x) set_y(y) set_position(x,y) (again, probably better xy) set_scale_x(sx) set_scale_y(sy) set_scale(sx, sy) set_rotation(r) set_skew_x(wx) set_skew_y(wy) set_skew(wx, wy) So, for example with rotation there is: rotate(r): rotates by r (rotation = rotation + r) get_rotation(): returns the current rotation set_rotation(r): sets the current rotation to an absolute r ( rotation = r) I like using the action verbs since it allows you to write this: drawable->rotate( M_PI ); rather than: drawable->set_rotation( drawable->get_rotation() + M_PI ); As a side note, I should probably use 'shear' instead of 'skew'. > - After conversion and running it I got 100% CPU load, and the graph > (which is updated with about 30Hz) showed only up until after my > application stopped updating the graph. I haven't checked but it seems > that the new version introduced a performance bottle neck compared to > the old version. Or is there something that has changed from before that > it expects me to do some drawing operations differently that could cause > it to cause a high load? The biggest change has been in the extents calculation. I'm offloading that to cairo, and I haven't calculated the load related to it. If I had to guess, that's where it's spending it's time. I'd be interested in seeing a profile to see what methods it's spending the most time in. > I'll let you know once I know more, today there is a deadline > approaching so probably not before tomorrow. Sounds good. --- Rick |
From: SourceForge.net <no...@so...> - 2009-02-10 14:46:46
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6391568 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=500341 |
From: SourceForge.net <no...@so...> - 2009-01-15 17:33:40
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6128531 By: rvinyard This release only fixes a variable naming problem within the pkgconfig .pc files. ______________________________________________________________________ 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...> - 2009-01-14 16:24:47
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6113208 By: rvinyard There are many changes in the papyrus library with this release. This release introduces a preview of the SVG drawable which can load an SVG and return a papyrus drawable object. ______________________________________________________________________ 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...> - 2009-01-06 16:24:54
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=6014779 By: rvinyard This is a bug fix release heading to 0.7.80. Fixed the freehand sketcher example. Fixed grid segfaults. Fixed virtual destructors on numerous drawables. ______________________________________________________________________ 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...> - 2008-03-12 14:24:20
|
Read and respond to this message at: https://sourceforge.net/forum/message.php?msg_id=4832189 By: rvinyard Just an FYI... I had hoped to leave the bug forums open to anyone, but with the start of the recent spam I have closed to bug tracker to anonymous posting. ______________________________________________________________________ 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 |