- Inkscape Devel - Inkscape Mailman

moves
by bulia byak 10 Jul '07

10 Jul '07

1. I moved the 3D box tool back under Rect on the toolbar - it's definitely one of the shape tools and most logically belongs with other shapes. 2. I moved the filter effects dialog to Object menu under Fill and Stroke, instead of the Effects menu. The two kinds of "effects" are confusing enough as they are, even without further confounding them by placing them into one menu. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
by bulia byak 09 Jul '07

09 Jul '07

On 7/9/07, Chris Adams <oneseventeen@...400...> wrote: > Ironically I prefer Inkscape on Windows, there's a couple of things > (like trying to select an object that is behind another object via the > alt key) that don't work for me on my Ubuntu laptop see http://wiki.inkscape.org/wiki/index.php/FAQ#How_to_make_Alt.2Bclick_and_Alt… -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

one more
by bulia byak 08 Jul '07

08 Jul '07

* Previously, the only way to switch selection from scale mode to rotate mode or back was to click on it, which was rather inconvenient when the selected object is in a group or under other objects. Now you can switch modes with keyboard as well by pressing Shift+S in Selector tool. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

Re: [Inkscape-devel] WebDav class patch submitted today
by Jon Phillips 08 Jul '07

08 Jul '07

Yes, it does. Since we can already set this at config time, would be better to vut down dependencies... Jon -----Original Message----- From: Bruno Dilly <bruno.dilly@...400...> Sent: Saturday, July 07, 2007 7:18 PM To: Ted Gould <ted@...11...> Cc: inkscape-devel@...6...; Bryce Harrington <bryce@...961...> Subject: Re: [Inkscape-devel] WebDav class patch submitted today Yes, it does. I've found some libs that support WebDav, when I was searching about it. I should had explained better, I'm not starting from the scratch. I'm using the neon lib, an WebDAV client library, http://www.webdav.org/neon/. It has worked fine for our purpose. I don't know the gnome-vsf library too much, I will try to study it better. On 7/7/07, Ted Gould <ted@...11...> wrote: > On Sat, 2007-07-07 at 16:23 -0300, Bruno Dilly wrote: > > I'm Bruno and I'm working in the Export to/Import from Open Clip Art > > Library gsoc project. > > Today I submitted a patch (item #1749698) with the webdav class, that > > implements all the necessary webdav methods. > > > > If you could take a look in it, I will be grateful. Soon I will submit > > an Export to OCAL patch, that will use this class to store files in > > webdav servers. > > Uhm, doesn't gnome-vfs support webdav? > > --Ted > > > ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ Inkscape-devel mailing list Inkscape-devel(a)lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel

3 2

WebDav class patch submitted today
by Bruno Dilly 08 Jul '07

08 Jul '07

Hi, I'm Bruno and I'm working in the Export to/Import from Open Clip Art Library gsoc project. Today I submitted a patch (item #1749698) with the webdav class, that implements all the necessary webdav methods. If you could take a look in it, I will be grateful. Soon I will submit an Export to OCAL patch, that will use this class to store files in webdav servers. See you

2 3

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