July 2007 - Inkscape Devel - Inkscape Mailman

SPStyle now uses SPFilterReference
by bulia byak 07 Jul '07

07 Jul '07

I changed SPStyle to use SPFilterReference for linking up filters, the same as filters use to link up to each other. This simplified SPStyle code (got rid of ad-hoc hreffing, etc) and fixed at least one bug: now filters are no longer lost when you undo an effect from Effects menu. Of course there may be gotchas, so please report to me any crashes and misbehaviors in filters linking (but not rendering - that is Niko's domain now, my changes should not affect that). If all goes smoothly I will similarly switch SPStyle's paintservers (gradients and patterns) which will fix a bunch of other long-standing bugs. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 6

Re: [Inkscape-devel] GTK+ and GTKMM problems
by joel＠...1709... 07 Jul '07

07 Jul '07

> I think the best thing to do would be to rewrite the desktop window code to use > a Gtk::Window rather than a GtkWindow as the top-level window. It's a small > step towards the complete Gtkmmification we have been wanting anyway. I agree, and I'm embarking on this process. My investigations have lead me to this little gem in edgit-widget.cpp: void * EditWidget::getWindow() { return this ; } This surprised me a little as EditWidget is a subclass of Gtk::Window. EditWidget is cast into a void*, then in SPDesktop::getToplevel it's cast into GtkWindow*. Can someone explain to me why EditWidget::getWindow returns a void* not a Gtk::Window*? why is the type thrown out? Am I missing something here? I'm very surprised that this series of casts works at all. I assume that the Gtk::Window class contains GtkWindow* as the first member. Shouldn't this be fixed? Joel ---------------------------------------- From: MenTaLguY <mental@...3...> Sent: 06 July 2007 15:21 To: joel@...1709... Subject: Re: [Inkscape-devel] GTK+ and GTKMM problems On Fri, 6 Jul 2007 15:09:04 -0700, "joel@...1709..." wrote: > What I really want here is "temporary wrapper" just to satisfy > FileChooserDialog. There seems to be rather a lack of documentation about > all this - or maybe I don't know where to look. Glib::wrap wasn't intended to be used that way. > Am I right in thinking that while all inkscape dialogs use Gtkmm, the main > window is based on plain old GTK+ ? If not, is there a way I can get a > reference to it's underlying Gtk::Window rather than a crumby GtkWindow*? I think the best thing to do would be to rewrite the desktop window code to use a Gtk::Window rather than a GtkWindow as the top-level window. It's a small step towards the complete Gtkmmification we have been wanting anyway. -mental

2 1

GTK+ and GTKMM problems
by joel＠...1709... 07 Jul '07

07 Jul '07

Hi All, After the discussions of a few weeks back, I'm working on a (supposedly) minor mod to correctly set the parenting of the file dialogs. Many inkscape modal dialogs do not have the inkscape desktop correctly set as their parent window, so that in Windows, at least, it becomes possible for the user to hide a file dialog, say, behind the inkscape desktop by simply clicking on it (as mentioned in bug #1431528) for example. For the file dialogs, correcting this is fairly simple: there's a version of the Gtk ::FileChooserDialog constructor which has an extra parameter allowing you to specify a parent window. Now here's my problem: It's fairly easy to get the GtkWindow* of the desktop window - C style, from a SPDesktop pointer. However, the Gtk ::FileChooserDialog constructor requires a Gtk::Window&. The obvious solution to this is to use the Glib ::wrap function which takes in one, and returns the other. The problem comes when you have to tidy up. If you do a C++ delete on the desktop's wrapper Gtk::Window* returned by Glib::wrap, it doesn't just destroy the wrapping, but also the desktop window itself. So that if you press OK or Cancel in a file dialog, gtkmm responds by completely closing down inkscape - which is rather a shame. What I really want here is "temporary wrapper" just to satisfy FileChooserDialog. There seems to be rather a lack of documentation about all this - or maybe I don't know where to look. Am I right in thinking that while all inkscape dialogs use Gtkmm, the main window is based on plain old GTK+ ? If not, is there a way I can get a reference to it's underlying Gtk::Window rather than a crumby GtkWindow*? If so, would it be appropriate to create a wrapped Gtk::Window at the beginning of the life of the SPDesktop and stored inside, only deleting it after the desktop is finally closed? - so that the SPDesktop::getToplevel would instead return a pointer/reference to this Gtk::Window, rather than a GtkWindow*? [I seem to be the only one using SPDesktop::getToplevel]. As much of a PITA as all this is, I would like to find a solution, because it's not just the file dialogs that are suffering from a lack of parentage. It's even possible to put the About box behind the desktop - which is just a bit yucky. Oh and sorry about the ^Ms Joel

3 3

Trailing whitespace
by John Faith 06 Jul '07

06 Jul '07

Hello, I noticed the trailing whitespace item here http://wiki.inkscape.org/wiki/index.php/InkscapeJanitors#Cleanup:_Whitespace so I made a script which generates a (large) patch. Should this be done for just .cpp, .c and .h files in src/ or should other files be touched? , John

3 3

Need some input for solving UI bug
by Diederik van Lierop 06 Jul '07

06 Jul '07

Revision #15307 fixes bug #1740146, in which changes in the document-properties dialog are written to the wrong document when multiple documents are open. In registered-widget.cpp, we used to have if (!repr) repr = SP_OBJECT_REPR (sp_desktop_namedview(dt)); but this won't update "repr" when the focus has changed to another document. Just removing the if-statement did the trick, but this is also needed for the other controls. We have two other options though: - make "repr" a local variable instead of a class-variable. Why should it be a class-variable after all? - have a mechanism to notify the class of changes in the focus and update "repr" accordingly, but I don't see a reason for doing it like this. I'm not very familiar with the GUI stuff yet, so some pointers in the right direction would be appreciated. Diederik

3 3

GSoC Midterm Evaluations
by Gail Banaszkiewicz 06 Jul '07

06 Jul '07

Just wanted to give a heads up to anyone that doesn't receive these announcements, and for those that interested in the program but aren't directly involved. Gail LH wrote: > Hello everyone, > > All participants in GSoC should take a moment to peruse the newly > published midterm survey documentation. The document covers > information for students, mentors with assigned students, mentors > without assigned students and organization administrators. There are > detailed instructions for submitting the surveys, as well as a > granular survey timeline. If you have any questions after reading the > documentation, just let us know. > > Cheers, > LH > > http://groups.google.com/group/google-summer-of-code-announce/web/midterm-s…

3 2

Crashbug on fixing XML node creation.
by unknown＠example.com 05 Jul '07

05 Jul '07

Hi all, I am about to fix a bug in the code... /display/canvas-grid.cpp line 229: newnode = xml_doc->createElement("inkscape:grid"); newnode->setAttribute("type", getSVGName(gridtype)); repr->appendChild(newnode); Inkscape::GC::release(repr); <--- this line should be there but isn't When I add that GC::release line, a strange bug appears. When repeating grid creation and undoing by pressing the new button and then pressing ctrl+z, first it works fine, but after a number of repetitions Inkscape crashes (svnhead, WinXP). Can anyone shine light on this matter please? (note that i did not yet commit this 'fix') Cheers, Johan

2 1

Svg to pdf color not exported
by PICHOT ANTOINE 05 Jul '07

05 Jul '07

Hello, I'm using Inkscape 0.45.1, built Mar 21 2007 on Windows XP. The pdf produced by an export (using save a copy...) of the attached file does not include the color. Is this a known bug/behaviour ? Can someone help ? Cheers, Antoine Pichot Alcatel-Lucent Research Engineer Research & Innovation Centre de Villarceaux Room COP 2.A06F Route de Villejust 91620 Nozay antoine.pichot@...1768... Tel : +33 1 3077 2663 Fax : +33 1 3077 6177

1 0

Script Updates
by Ted Gould 05 Jul '07

05 Jul '07

Okay, I've committed some updates, which I think fix most of the minor issues. -- Effects without GUIs work now -- The working directory for scripts is the same as the working directory for Inkscape instead of a temp directory. I don't think this fixes all the win32 issues -- but it is the same as before. -- Parameters don't have extra quotes -- Removed plugin code to the SVN history --Ted

4 10

Re: [Inkscape-devel] Google Summer of Code
by Ted Gould 05 Jul '07

05 Jul '07

On Thu, 2007-06-28 at 14:42 -0500, Christopher Brown wrote: > I'm trying to find out if I can affect embedded images without writing > temporary files by using ImageMagick's blobs, so I'm implementing IM > in Inkscape via MagickCore. The problem is that after I affect an > Image, sometimes Inkscape doesn't update the image to reflect the > change (since I don't change the filename), until I save it, or copy > the image, or do something to it. I think that you need to emit the contentChanged signal from the node. But, I can't seem to figure out how this is supposed to be done. I'm CC'ing the -devel list to see if someone can help you there. > I'd run the update sp_item on every item in the selection, but that > method wants a SPCtx pointer, and I have no idea where to get that. Is > there an easier way to update the sp_image or can you tell me how to > get the SPCtx pointer? I think that you're going to have to keep things at the repr/xml level because I don't think that we currently have a way to take the data modified in the SP_ level and reencode it back into a PNG for the repr level. So, it'll be better to have IM build the PNG and place it on the XML node as data. Then Inkscape can pull it into the renderer. Not as efficient, but it should work without having to implement some crazy PNG stuff. (again, the people on -devel may correct me :) ) --Ted

1 0