- Inkscape Devel - Inkscape Mailman

Tutorial translations: switching to xml2po
by Colin Marquardt 01 Jul '07

01 Jul '07

Hi, is there anyone who objects using xml2po for the tutorial translations? See http://wiki.inkscape.org/wiki/index.php/DocumentationTranslation for the process. With xml2po, translators would get regular po files to translate, with all the positive effects (no manual looking for string changes; more dedicated tools than for Docbook; familiarity of amny translators with the format; translator credits for free (even though we don't pull them yet for the About box); strings from included images are in the same file; the Gnome people are using it; and probably some more). I am using xml2po for the German translation since pre-0.45, and it worked quite well so far. I have started automating the conversion process to HTML/SVG (to the then intermediate Docbook XML) in SVN. So if there are no valid objections overriding the plusses, I will soon start converting all translated Docbook XML files to the po format. Please submit any translated XML files that are not yet in SVN. I think now is a good time to tackle that process, considering that 0.46 is probably a while but not too far away, and there are quite some efforts going into tutorials recently (thanks Ryan :). Cheers Colin PS: I'm cmarqu on IRC.

1 0

Effects on Win32 (and side note)
by Joshua A. Andler 01 Jul '07

01 Jul '07

Okay... first off, I nuked my svn checkout, xmingw, and my gtklibs... Then brought everything back up-to-date and clean at that. Cross-compiled for win32 and fired up inkscape on the win32 box. The error I reported yesterday persisted (about not finding python25.dll). I manually moved the dll file from the main inkscape dir into the python subdirectory where python.exe resides. This solved problem of not being able to find the dll. However, effects still do not work. When I try to run effects (interpolate is my example here) I now get output stating: "python: can't open file 'share\extensions\interp.py': [Errno 2] No such file or directory" For the sake of trying to find a workaround (like the dll), I copied the "share\extensions" directory structure with the contents into that python dir as well (hey it worked for the dll). Unfortunately, this did not fix it. It seems like this may be more related to our library upgrade and new python than the changes Ted made. I really want to make sure that people will still be able to use effects on win32, and it seems like the sooner we can know if there's a problem, the better. Anyone else building for/on win32 having a different experience? Again, note that I'm cross-compiling, not compiling natively. Side note: Bob, the gtkrc file copied to "inkscape\etc\gtk-2.0" has the correct change I suggested. But, the gtkrc file that is in "inkscape\share\themes\MS-Windows\gtk-2.0" does not have the change and it is the one inkscape actually uses. -Josh P.S. Ted, you're getting CC'd because I want you to know that I plan on testing your changes on win32 asap... and also to know that I will bug you if your changes don't work on win32. ;)

6 17

Getting the GdkWindow in which a verb was invoked
by Joel Holdsworth 28 Jun '07

28 Jun '07

Hi again, I'm currently working on a patch to add support for native file dialogs for windows users. It's worked out pretty well, and I'm almost finished. I have one slight problem though: parent windows. In the GTK version, sp_file_open_dialog (in file.cpp) is called from inside FileVerb::Perform in verbs.cpp. But how is it possible to get the GdkWindow object of the windows in which the verb was invoked? If I have this I can add it as an extra parameter to sp_file_open_dialog, to enable both the GTK, and Win32 file dialogs to be correctly set as child windows of the document's window. Any suggestions? Joel Holdsworth

5 7

Object Sets
by Jeff Rose 28 Jun '07

28 Jun '07

Hi Inkscapers, I was just talking with a friend while he is working on some diagrams in inkscape, and he wants to be able to have items in multiple groups. (This is a network diagram, so for example it would be nice to have a set of all nodes, to be able to change color and style, but then also put various subnets of nodes into their own groups so they can be transformed as a unit.) Looking into it a bit it seems that this is really a limitation of the way svg handles groups, and since both groups and layers in inkscape are implemented with svg groups I guess it's not possible to use a set oriented approach like this? Any ideas why groups are limited in this way within the svg spec? I can imagine a number of situations in which it would be nice to change style attributes or script or transform on different sets of potentially overlapping objects. Any thoughts on this? -Jeff

2 1

Funny situation with use inside text
by Gail Banaszkiewicz 27 Jun '07

27 Jun '07

2 4

3D box tool update
by Maximilian Albert 27 Jun '07

27 Jun '07

Hi everyone, following Gail's example, I would like to post a short note on my progress, too, and at the same time announce version 0.1 of the 3D box tool. :) Well, that's probably too much of a promise. It is _extremely_ limited, the only thing it may be useful for is giving an impression of the envisaged behaviour (also see http://www.rzuser.uni-heidelberg.de/~malbert/core_functionality.shtml ). I'd appreciate comments, although I admit that there is not much to comment on yet. ;) All you can do at the current stage is create a box in a fixed perspective. No dragging of corner nodes is possible yet, nor of vanishing points (VPs) or perspective lines (PLs), nothing. Although you can of course treat boxes as "normal" groups of paths and edit them in the usual way. However, since currently the transform method is not implemented, you should hit Ctrl+Shift+G and Ctrl+G before doing so (in order to ungroup and regroup the paths representing the faces, which removes the 'sodipodi:type="inkscape:3dbox"' attribute from the group so that it is not recognized as a 3D box any more; this mainly fixes issues with undo/redo). In the current fixed perspective the edges of the box are drawn along parallel PLs directed towards "infinite" VPs in x-, y- and z-direction. You will notice, however, that as soon as the 3D box tool is activated, three points are drawn on the canvas. They represent "finite" VPs and it is possible to switch between "finite" (i.e., the PLs meet in the respective VP) and "infinite" (i.e., the PLs are parallel) in each direction by toggling the corresponding button in the 3D box toolbar. The VPs will be color-filled when their state is finite. Sorry that they don't disappear again when switching to another tool, but I didn't want to invest a lot of time in making them work better when I need to rewrite the code anyway as soon as they become draggable. BTW, already drawn boxes are not updated live yet, toggling the VPs' states only affects the drawing of new boxes (also note that when the VPs are white they don't affect the drawing of boxes, although they appear on the canvas; this is a bit counter-intuitive when using the tool for the first time). Since the functionality is so limited I decided to hide the tool's icon for the time being. To make it visible, simply uncomment line #129 in src/toolbox.cpp. You can also change the position/direction of finite/infinite VPs by setting the corresponding values in src/box3d-context.cpp (starting from line #122) and recompiling. Very inconvenient, I know. And if anyone wants to design a *nice* icon for the toolbox, you are most welcome (I haven't invested any time in that so far). Well, I really hope to make faster progress starting from next week. I have just handed in my Diplom thesis (whose completion took a lot more time than expected) so that I could only work part-time on SoC during the past weeks. Cheers, Max

6 8

Re: [Inkscape-devel] SPAM-LOW: Re: Getting the GdkWindow in which a verb was invoked
by joel＠...1709... 27 Jun '07

27 Jun '07

> If you have problems like this, please fix it in GTK and not in every > GTK app. GTK+ is a multi-platform toolkit by the definition on there > website and not only an Linux toolkit that works on windows too. I couldn't agree more, and I think the i-beam problem has been solved precisely because the later builds use more up-to-date versions of GTK. > But we need a file dialog that fits better into windows. So I would suggest > to write a gtk dialog, that looks like a windows dialog. > The pros are, that all windows gtk apps will benefit from it and that we > can still use the preview and the bookmarks. I would have to disagree with you there. It will be very difficult for a facsimily of the Windows dialog to look consistent in it's finer details - leaving Windows users rather unsatisfied. The details really do matter. The dialog should not be nearly the same (all except for that one little thing), it needs to be exactly the same. When one calls the OpenFileName API you get the open file dialog for the version of windows which you are using. But, I suspect it'll be impossible for use to make clones of the file dialogs of *all* windows versions - especially when you take forwards compatibility with future versions of Windows into account. This is why we need to use the Windows API. I'm very impressed that the Print dialog is now the native windows file dialog - it just looks so much better! For versions of Windows before Vista, there is scope for making slight changes to the dialog by modifying the "dialog template". This basically allows you to add extra controls to it. Vista has a slightly more refined, better supported way of allowing you to do the same thing. So there would need to be different code for all versions prior to vista to all versions vista and onwards. I myself am very happy to take on this rather fiddly task, because I place a very high value on consistency. > I can only agree with you, that Windows is an very important platform. > But please don't hack the Windows support into Inkscape but make it the > "right way". ;) I wouldn't have it any other way. ---------------------------------------- From: Tobias Jakobs <tobias.jakobs@...128...> Sent: 26 June 2007 12:08 To: Joel Holdsworth <joel@...1709...> Subject: SPAM-LOW: Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked Am Dienstag, den 26.06.2007, 18:09 +0100 schrieb Joel Holdsworth: > One thing I notice quite regularly is that > because this a GTK app, it is inevitably primarily designed for Gnome. An > example of this problem is the edit box I-beam cursor. In 0.45.1 when you > hover over an edit box in windows you get a GTK style I-beam, rather than > the windows system I-beam. I'm very glad that this has now been fixed in the > developement builds. A second example is scrollbars. When you scroll to the > maximum or minimum extent, the arrow buttons grey out. That behaviour makes > sense, but it's not Windows standard, so it sticks out like a sore thumb. > If you have problems like this, please fix it in GTK and not in every GTK app. GTK+ is a multi-platform toolkit by the definition on there website and not only an Linux toolkit that works on windows too. > I guess I got a similar impression of the file dialogs. Far from making me > feel like a first class citizen, it made me feel like it was one of those > linuxy things that noone had got round to fixing sorting out yet - Linux > being the primary platform for the project, and I being a mere "M$ Windoze" > user. I definitely don't think we should add more options to resolve this - > as they tend to be an excuse for dodging hard design decisions. I agree that > it would be a shame to loose bookmarks and preview, but then I don't think > many Windows users will know what they're missing. Instead they'll be happy > that the application has the humility to "play the Windows game the Windows > way". > I agree with you that we need other file dialogs on windows. An old usability rule is: "The Platform is the King." That means, it's not important to have the same dialogs on every platform, but to fit into the platform as good as possible. So the first question is, is there a standard Windows file open dialog? Look at Word, Photoshop, Coral Draw, Notepad and you will find 4 different file open dialogs. So we don't need "the standard windows file open dialog" because the users are used to different file dialogs. But we need a file dialog that fits better into windows. So I would suggest to write a gtk dialog, that looks like a windows dialog. The pros are, that all windows gtk apps will benefit from it and that we can still use the preview and the bookmarks. > I think it's quite important that we try and show Windows users that we take > their platform sersously, because the majority of developers work on that > platform, so we could do with attracting their input to get more inovation, > and faster progress. I can only agree with you, that Windows is an very important platform. But please don't hack the Windows support into Inkscape but make it the "right way". ;) Regards, Tobias

3 2

Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
by joel＠...1709... 26 Jun '07

26 Jun '07

Ok, well if emost people are happy then I'll go ahead, and do the job as neatly as I can. You probably won't see too much visible progress in a while, because I'm holiday for the next 2 weeks, and after that I have a contract which always seems to soak up most of my brain power, but I will have it on the back burner. ---------------------------------------- From: "Joshua Blocher" <verbalshadow@...400...> Sent: 26 June 2007 16:16 To: joel@...1709... Subject: Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked Hi Joel, On 6/27/07, joel@...1709... wrote: > Hi Joshua, > > Yes I can see how you would loose out - I quite understand. Although I do > think we need to think about the needs of more common Windows users. You use > one application on several platforms, wheras most people use one platform > and several applications, so we really need to optimise consistency on a > per-platform basis, not on a per-app basis; simply to satisfy the > expectations of the users. The aim here is to reduce the number of > different-functioning dialogs that the user of any given platform has to > learn and understand. I would say that is the way windows works almost every app has a slightly different spin on what their apps open dialog looks and functions like. Sure most use the base open dialog as a base for their implementation but its still different, some even implement completely different looking and functioning ones, that's every version of office that i can remember and many other graphic apps. Sorry, I'm not trying to discourage you. What you want to do will probably help the average windows user. I just want to make sure that we think carefully about the downside for multi-platform users and issues is may cause with helping users. We need to remember that this is a cross-platform program and that every bit of platform specific code may additional complexity of maintaining and supporting for the long term. Since Dev's seem to have blessed off on it with conditions, good luck. Joshua L. Blocher verbalshadow > > ________________________________ > From: "Joshua Blocher" > Sent: 26 June 2007 15:02 > To: inkscape-devel(a)lists.sourceforge.net > Subject: Re: [Inkscape-devel] Getting the GdkWindow in which a verb was > invoked > > I'm personnelly for keeping the current gtk dialog, i use both windows > and linux and I simply expect inkscape to provide the same > functionality and work in the same way (where possible) on both > platforms. This provides maximum usability for multi-platform users > and reduces the need to know the platform specifics when helping > other users. I'm not against making things more "usable" for windows > users, so i feel that IF need that a gtk dialog made to look like > office 2003 open dialog ( what tobias suggested) is probably the best > half way point. It offers bookmarking and previews. It still wouldn't > function and work in exactly the same way but at least it would still > be there. > > Joshua L. Blocher > verbalshadow > > ------------------------------------------------------------------------- > 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 > >

1 0

Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
by Joel Holdsworth 26 Jun '07

26 Jun '07

Are you saying that at some stage there was suport for native windows file dialogs which was then removed? If so why was this? and if I was to add the support in once again would I be reversing some community decision from a while ago? if that decision was made, on what grounds was it made? > ----- Original Message ----- > From: "Bob Jamison" <rwjj@...127...> > To: "Joel Holdsworth" <joel@...1709...>; > <inkscape-devel(a)lists.sourceforge.net> > Sent: Tuesday, June 26, 2007 4:20 PM > Subject: SPAM-LOW: Re: [Inkscape-devel] Getting the GdkWindow in which a > verb was invoked > > >> Joel Holdsworth wrote: >>> Hi again, >>> I'm currently working on a patch to add support for native file dialogs >>> for windows users. It's worked out pretty well, and I'm almost finished. >>> I have one slight problem though: parent windows. >>> In the GTK version, sp_file_open_dialog (in file.cpp) is called from >>> inside FileVerb::Perform in verbs.cpp. But how is it possible to get the >>> GdkWindow object of the windows in which the verb was invoked? If I have >>> this I can add it as an extra parameter to sp_file_open_dialog, to >>> enable both the GTK, and Win32 file dialogs to be correctly set as child >>> windows of the document's window. >>> Any suggestions? >>> Joel Holdsworth >> >> You might look at src/dialogs/filedialog-win32.cpp as an >> example. It was the original native dialog that we replaced with the >> current one. >> >> >> bob >> >

8 20

Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked
by joel＠...1709... 26 Jun '07

26 Jun '07

Hi Joshua, Yes I can see how you would loose out - I quite understand. Although I do think we need to think about the needs of more common Windows users. You use one application on several platforms, wheras most people use one platform and several applications, so we really need to optimise consistency on a per-platform basis, not on a per-app basis; simply to satisfy the expectations of the users. The aim here is to reduce the number of different-functioning dialogs that the user of any given platform has to learn and understand. ---------------------------------------- From: "Joshua Blocher" <verbalshadow@...400...> Sent: 26 June 2007 15:02 To: inkscape-devel(a)lists.sourceforge.net Subject: Re: [Inkscape-devel] Getting the GdkWindow in which a verb was invoked I'm personnelly for keeping the current gtk dialog, i use both windows and linux and I simply expect inkscape to provide the same functionality and work in the same way (where possible) on both platforms. This provides maximum usability for multi-platform users and reduces the need to know the platform specifics when helping other users. I'm not against making things more "usable" for windows users, so i feel that IF need that a gtk dialog made to look like office 2003 open dialog ( what tobias suggested) is probably the best half way point. It offers bookmarking and previews. It still wouldn't function and work in exactly the same way but at least it would still be there. Joshua L. Blocher verbalshadow ------------------------------------------------------------------------- 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

2 1