Can we make the default shape prefs as colorful as they used to be? Right now if I start up inkscape without prefs, they're just black shapes. I liked the partially see-through yellow, blue, red, etc.
I agree with Kees,
It gets irritating when you are drawing fully transparent shapes for the firts time on a new canvass
On Sun, 30 Jan 2005 12:26:34 -0800, Kees Cook <inkscape@...62...> wrote:
Can we make the default shape prefs as colorful as they used to be? Right now if I start up inkscape without prefs, they're just black shapes. I liked the partially see-through yellow, blue, red, etc.
-- Kees Cook @outflux.net
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Sun, 30 Jan 2005 12:26:34 -0800, Kees Cook <inkscape@...62...> wrote:
Can we make the default shape prefs as colorful as they used to be? Right now if I start up inkscape without prefs, they're just black shapes. I liked the partially see-through yellow, blue, red, etc.
Huh? These defaults are in preferences-skeleton.h and nobody changed them recently.
I see what you mean, it's a bug. Will look into it.
Mental, this is yours again. In desktop-style.cpp, this checks if the repr has no attributes:
if (((SPRepr *) css)->attributeList() == NULL) {
However attributeList() returns non-NULL even if there are no attributes. Please either fix it to return NULL as before (preferable) or provide a new function e.g. bool attributeListIsEmpty().
To test, delete your ~/.inkscape/preferences.xml, run, and break at sp_desktop_get_style. Draw a shape. A new empty css attr is created:
SPCSSAttr *css = sp_repr_css_attr_new();
Merge does nothing because desktop->current is empty too:
sp_repr_css_merge(css, desktop->current);
Yet after that, the check fails:
if (((SPRepr *) css)->attributeList() == NULL) {
and the function returns the empty css instead of NULL.
This needs to be done before the release, because this may have caused other breakage which we haven't discovered yet.
By the way: Mental: This is likely related to the PPC crash which is assigned to you too. The backtrace of that crash goes through this same check in desktop-style:
if (((SPRepr *) css)->attributeList() == NULL) {
So if attributeList() returns a bogus pointer, it may be a sign of some internal SPRepr breakage which gets exposed via this call.
On Sun, 2005-01-30 at 23:30, bulia byak wrote:
Mental, this is yours again. In desktop-style.cpp, this checks if the repr has no attributes:
if (((SPRepr *) css)->attributeList() == NULL) {However attributeList() returns non-NULL even if there are no attributes. Please either fix it to return NULL as before (preferable) or provide a new function e.g. bool attributeListIsEmpty().
... What. The. Heck?
this used to be:
if (((SPRepr *) css)->attributes == NULL) {
And the only change I made was to move SPRepr::attributes to SimpleNode::_attributes, and implement SimpleNode::attributeList() thusly:
SPReprAttr const *attributeList() const { return _attributes; }
If there are no attributes, attributeList() should BY DEFINITION return NULL.
I think you're right that whatever is going on here is a likely source of the PPC/AMD64 crash anyway...
-mental
Hi, I'm skilled in C++ and have a basic knowledge of cvs.
Is there a basic task to perform to begin helping in inkscape development ?
Best regards Pierre
On Mon, Jan 31, 2005 at 05:15:29PM +0100, Pierre Boulenguez wrote:
I'm skilled in C++ and have a basic knowledge of cvs.
Is there a basic task to perform to begin helping in inkscape development ?
Mental might be able to think of some things. Myself, I tend to try and fix bugs in the tracker. That gets me exposed to a large cross-section of the code. I'm still a pretty green C++ programmer, but I've been using C for a long time.
Probably the best way to get involved is to jump on the Jabber channel. We meet on the "inkscape" channel on the "conference.gristle.org" server. If no one is there, just try to hang out and usually people will filter in and out. http://inkscape.org/discussion.php
Quoting Kees Cook <inkscape@...62...>:
I'm still a pretty green C++ programmer, but I've been using C for a long
time.
Incidentally, I'd strongly, strongly recommend that everyone read this site thoroughly and bookmark it for reference:
http://www.parashift.com/c++-faq-lite/
It's actually more in-depth than the name FAQ warrants, but there it is. Even many experienced C++ programmers I've worked with would benefit from it.
-mental
On Mon, Jan 31, 2005 at 01:40:05PM -0500, mental@...3... wrote:
Incidentally, I'd strongly, strongly recommend that everyone read this site thoroughly and bookmark it for reference:
http://www.parashift.com/c++-faq-lite/
It's actually more in-depth than the name FAQ warrants, but there it is. Even many experienced C++ programmers I've worked with would benefit from it.
Cool. I've added it to the DeveloperManual wiki page.
Quoting Pierre Boulenguez <boulenguez@...558...>:
Hi, I'm skilled in C++ and have a basic knowledge of cvs.
Is there a basic task to perform to begin helping in inkscape development ?
Off the top of my head, here's one easy and low-risk task that needs doing:
In src/xml/repr.h, there are a bunch of inline functions that are trivial wrappers for SPRepr member functions. Your task, should you choose to accept it: replace all calls to those wrapper functions with direct calls to the wrapped member functions, then remove the unused wrapper functions.
If you can catch me on Jabber tonight (GMT +5), I can probably think of some more. There is a lot of badly needed refactoring work that I would like to do, but which I have not had time for.
-mental
On Mon, 31 Jan 2005 mental@...3... wrote:
Quoting Pierre Boulenguez <boulenguez@...558...>:
Hi, I'm skilled in C++ and have a basic knowledge of cvs.
Is there a basic task to perform to begin helping in inkscape development ?
Off the top of my head, here's one easy and low-risk task that needs doing:
In src/xml/repr.h, there are a bunch of inline functions that are trivial wrappers for SPRepr member functions. Your task, should you choose to accept it: replace all calls to those wrapper functions with direct calls to the wrapped member functions, then remove the unused wrapper functions.
If you can catch me on Jabber tonight (GMT +5), I can probably think of some more. There is a lot of badly needed refactoring work that I would like to do, but which I have not had time for.
Maybe we should set up and maintain a janitor's list with stuff like this? Even for those of us who are working on larger projects, sometimes you're in the mood for some simple tasks...
Bryce
On Mon, Jan 31, 2005 at 11:22:03AM -0800, Bryce Harrington wrote:
Maybe we should set up and maintain a janitor's list with stuff like this? Even for those of us who are working on larger projects, sometimes you're in the mood for some simple tasks...
How about using the Wiki? I'd love to have a list to work off of. Like you said, sometimes I just want to work on something simple.
How about: http://inkscape.org/cgi-bin/wiki.pl?action=edit&id=InkscapeJanitors
On Mon, 31 Jan 2005, Kees Cook wrote:
On Mon, Jan 31, 2005 at 11:22:03AM -0800, Bryce Harrington wrote:
Maybe we should set up and maintain a janitor's list with stuff like this? Even for those of us who are working on larger projects, sometimes you're in the mood for some simple tasks...
How about using the Wiki? I'd love to have a list to work off of. Like you said, sometimes I just want to work on something simple.
How about: http://inkscape.org/cgi-bin/wiki.pl?action=edit&id=InkscapeJanitors
Sounds great, wanna pile up the simpler tasks identified in this thread (esp. the ones mental pointed out) there?
I'll add a link to this page to the FAQ and roadmap once the page exists. :-)
Bryce
On Mon, Jan 31, 2005 at 02:16:42PM -0800, Bryce Harrington wrote:
Sounds great, wanna pile up the simpler tasks identified in this thread (esp. the ones mental pointed out) there?
I've added mental's idea and linked it under the "Developer Documentation" area...
On Mon, 31 Jan 2005 17:15:29 +0100, Pierre Boulenguez <boulenguez@...558...> wrote:
Hi, I'm skilled in C++ and have a basic knowledge of cvs.
Is there a basic task to perform to begin helping in inkscape development ?
Perhaps the best advice is this: Do whatever interests you. Browse the bug list, RFE list, Wiki. Invent something simple, small, and reasonably orthogonal to the rest of the program that would however be helpful or otherwise attractive to you. Start small, but don't do something because it must be done; do it because you want it to be done :)
On Mon, 31 Jan 2005, Pierre Boulenguez wrote:
Hi, I'm skilled in C++ and have a basic knowledge of cvs.
Is there a basic task to perform to begin helping in inkscape development ?
There are a number of fairly basic tasks. We haven't been maintaining an 'Inkscape Janitors List' or anything, but you can generally uncover some good tasks with a small amount of digging.
We like to encourage new developers to do the exploration and find some task that appeals to them, because a basic task to you may seem like an advanced one to me (or vice versa). Some people find it most comfortable to approach from the packaging side of things, others with fixing bugs and using gdb, others via adding comments as they read through the code, others like to pick a dream feature to implement and start picking away towards that as a long range goal. Figure out what you personally really enjoy for coding, and it's hard to go wrong. :-)
Btw, the CVS access policy is straightforward: First get two patches accepted (submit through the patch tracker), and second send your sourceforge ID to me or one of the other admins and you'll be granted commit access.
If you need more info about types of work we need help with, read on...
You can get a high level picture of what others are thinking about working on via the Detailed Roadmap:
http://inkscape.org/cgi-bin/wiki.pl?Roadmap
However, there's tons and tons of stuff needing to be worked on that are not on that list. Like Kees mentioned, the bug tracker is also a great way to find something to do, although I'll warn you that at this particular moment in our release cycle I expect most of the _easy_ bugs have already been done (but maybe there's some easy ones hiding down in the priority-3 level).
Another area we will need a lot of help in fairly soon is with upgrading the UI to gtkmm. This will involve a lot of meat-and-potatos C++ class creation and conversion of C code into OOP style. Presently this work is going on in a separate cvs module but it's scheduled for integration within about a week. If you're interested in working on this, let me know and I can give more details. It should be pretty straightforward work, and will be seeing progress rapidly, so it could be fun. :-)
Other largish projects that probably have some basic tasks attached:
* Extensions - Ted and Ishmal are each doing coding to gain a capability to extend Inkscape with external modules, and may have some general coding work they could farm out.
* Printing / Postscript - Needs a lot of TLC, a lot of us have been reluctant to get near the code since it needs so much work, so even small improvements here will be well appreciated, and if someone would be interested in owning this subsystem we'd be thrilled.
* Cairo Gtk Canvas - A long term project we have talked about is to replace our internal renderer with Cairo, but there's a ton of R&D experimentation needed to get there. If you like working from a blank sheet of paper and just coming up with a lot of good ideas that others can build off of later, this would be a good opportunity.
* CSS style support - Huge and complicated effort, but someone with an interest in SVG could do a lot of good for the world here. We've got the tasks to do this scoped out, but it will be a big project so haven't started on it.
Anyway, again, look around and pick something that really appeals to you. The above all need to get done, but the best task is the one that scratches your own itch, since it'll give you a real motivation to do it. :-)
Let us know what you think, or any questions you've got about it.
Bryce
I realized the problem.
if (((SPRepr *) css)->attributeList() == NULL) {
^^^^^^^^^^ The explicit C-style cast here makes deep assumptions about structure layout which were broken when the layout of SPReprs changed. I'm surprised it didn't break more spectacularly...
The resulting SPRepr * ends up pointing to the wrong place in the object, and getting the wrong vtable entry (or even random memory instead of a vtable). The backtrace from the PPC crash was probably accurate -- the wrong method really was getting called.
The quick and dirty fix for this particular case would be to rename the SPCSSRepr class in repr-css.cpp, then turn the forward declaration of SPCSSRepr in repr.h into a typedef SPRepr, so SPCSSRepr and SPRepr are the same type. At that point, the sp_repr_css_* functions end up taking SPRepr *s directly, so there wouldn't be any address fixup issues.
[ the somewhat more correct fix would be to set up SPCSSRepr the same way as has been done for SPReprDoc, with its own public abstract class that derives from SPRepr, and a non-public implementation class that derives from both SimpleNode and the abstract class ]
We may begin to encounter problems with C casts more frequently as we begin to use more C++ features. C-style casts just aren't safe in C++, and will often shoot you in the foot without any compiler warnings.
I have been doing my best to clean these sorts of things up in advance (which is why we've not seen other breakage so far), but I do occasionally miss them, as I did with the CSSRepr stuff. In new code, it's better to use the C++ casting operators, when you need to use casts at all (C++ should require them far less than C if you're doing things right).
-mental
On Mon, 31 Jan 2005 13:00:13 -0500, mental@...3... <mental@...3...> wrote:
I have been doing my best to clean these sorts of things up in advance (which is why we've not seen other breakage so far), but I do occasionally miss them, as I did with the CSSRepr stuff. In new code, it's better to use the C++ casting operators, when you need to use casts at all (C++ should require them far less than C if you're doing things right).
Well, though the function is mine, I didn't write this comparison, but copied it from somewhere. If you fix it I'll copy the correct idiom next time :)
Have you looked into the new crash-on-load bug?
On Mon, Jan 31, 2005 at 01:00:13PM -0500, mental@...3... wrote:
The quick and dirty fix for this particular case would be to rename the SPCSSRepr class in repr-css.cpp, then turn the forward declaration of SPCSSRepr in repr.h into a typedef SPRepr, so SPCSSRepr and SPRepr are the same type. At that point, the sp_repr_css_* functions end up taking SPRepr *s directly, so there wouldn't be any address fixup issues.
[ the somewhat more correct fix would be to set up SPCSSRepr the same way as has been done for SPReprDoc, with its own public abstract class that derives from SPRepr, and a non-public implementation class that derives from both SimpleNode and the abstract class ]
I found SPCSSAttr, but it doesn't seem to have anything in common with SPRepr. Am I blind? (repr-css.cpp) It's an Inkscape::XML::SimpleNode, which does have an attributeList. Maybe this is just the wrong cast?
This, however, isn't working:
if (dynamic_cast<Inkscape::XML::SimpleNode *>(css)->attributeList() == NULL)
desktop-style.cpp: In function `SPCSSAttr* sp_desktop_get_style(SPDesktop*, bool)': desktop-style.cpp:167: error: cannot dynamic_cast `css' (of type `struct SPCSSAttr*') to type `class Inkscape::XML::SimpleNode*' (source is a pointer to incomplete type)
What can I try next?
Quoting Kees Cook <inkscape@...62...>:
I found SPCSSAttr, but it doesn't seem to have anything in common with SPRepr. Am I blind? (repr-css.cpp) It's an Inkscape::XML::SimpleNode, which does have an attributeList. Maybe this is just the wrong cast?
Well, yes and no. XML::SimpleNode implements the abstract class SPRepr.
[ SPCSSAttr isa XML::SimpleNode isa SPRepr ]
HOWEVER, XML::SimpleNode is an implementation class. It should ****NOT**** be exposed to any code outside src/xml/, so please don't do this...
if (dynamic_cast<Inkscape::XML::SimpleNode *>(css)->attributeList() ==NULL)
SPRepr is the public interface; use that. The general idea behind the original code was correct ... you want to do SPRepr things with a SPCSSAttr, which (indirectly) isa SPRepr. It was just the methedology that was fragile...
Ideally the way this should work is that SPCSSAttr would also be an abstract class that extends SPRepr (see SPReprDoc for an example of this). We could then make enough information available for the compiler to see that SPCSSAttr isa SPRepr without exposing the actual class implementing SPCSSAttr, so no cast would be required at all.
There would be some implementation class behind it (SimpleNode-derived or not), but nobody outside repr-css.cpp would need to know about that.
desktop-style.cpp: In function `SPCSSAttr* sp_desktop_get_style(SPDesktop*, bool)': desktop-style.cpp:167: error: cannot dynamic_cast `css' (of type `struct SPCSSAttr*') to type `class Inkscape::XML::SimpleNode*' (source is a pointer to incomplete type)
"incomplete type" means that the full definition of the type (SPCSSAttr in this case) is not visible to the compiler at that location (in this case because it is located in src/xml/repr-css.cpp).
What can I try next?
The quickest thing would simply be to rework the sp_repr_css_* functions to take and return SPRepr * rather than SPCSSAttr * (i.e. typedef SPRepr SPCSSAttr, and rename the class in repr-css.cpp). You'd need to get rid of some unused forward declarations of SPCSSAttr too.
I'm going to go ahead and do it right tonight though.
-mental
On Tue, Feb 01, 2005 at 12:01:11PM -0500, mental@...3... wrote:
HOWEVER, XML::SimpleNode is an implementation class. It should ****NOT**** be exposed to any code outside src/xml/, so please don't do this...
Oops. Okay, nevermind. I will wait. I was working my way towards this, which felt wrong as I was doing it, but I wasn't sure why.
The quickest thing would simply be to rework the sp_repr_css_* functions to take and return SPRepr * rather than SPCSSAttr * (i.e. typedef SPRepr SPCSSAttr, and rename the class in repr-css.cpp). You'd need to get rid of some unused forward declarations of SPCSSAttr too.
I'm going to go ahead and do it right tonight though.
Okay, cool. I've run out of time this morning, but I think I learned a good bit. :)
On Mon, Jan 31, 2005 at 01:00:13PM -0500, mental@...3... wrote:
[ the somewhat more correct fix would be to set up SPCSSRepr the same way as has been done for SPReprDoc, with its own public abstract class that derives from SPRepr, and a non-public implementation class that derives from both SimpleNode and the abstract class ]
I hurt my brain several times over, but I did it! :P Default preference object attrs are visible once again.
Can folks with PPC (and amd64) try the build? I'm not sure if this is the whole fix or not...
participants (7)
-
unknown＠example.com -
Andy Fitzsimon -
Bryce Harrington -
bulia byak -
Kees Cook -
MenTaLguY -
Pierre Boulenguez