June 2004 - Inkscape Devel - Inkscape Mailman

Re: [Clipart] new inkscape dialogs
by Alan Horkan 27 Jun '04

27 Jun '04

[moved from Clipart back to Inkscape] On Thu, 24 Jun 2004, Jon Phillips wrote: > Date: Thu, 24 Jun 2004 03:47:18 -0700 > From: Jon Phillips <jon@...235...> > To: Andrew Fitzsimon <andrew@...420...> > Cc: clipart-list <clipart@...330...> > Subject: Re: [Clipart] new inkscape dialogs > > These are rocking man!!! I can't wait until they are fully implemented. > It would be great if they could be ready by AUGUST so that I can present > them at a couple of conferences and in time for OSCON2004! > > It will be great to show the linkages between metadata in OCAL and in > Inkscape directly!!! You are cool!!! > > Jon > > > On Sun, 2004-06-20 at 23:14, Andrew Fitzsimon wrote: > > Hi guys, just a few mockups comming from inkscape. > > > > bryce mentioned you'd like to see them > > > > http://andy.fitzsimon.com.au/obman/obman2.png > > http://andy.fitzsimon.com.au/obman/docset.png > > http://andy.fitzsimon.com.au/obman/docset2.png I realise these dialogs fit in with Inkscapes current design, the are clear compact and well arranged but I think it is important to consider integration with Gnome. The way I see it Sodipodi tried to make all dialogs as small and as compact as possible, and for non-modal dialogs that are expected to be left permantly open this makes sense. (Other graphics applications refer to these types of Dialogs as Palettes, and I try to do so too). I can understand that the Object Manager is probably something you would want to leave open. These should be considered distinct and seperate from Transient dialogs (modal or non-modal, it doesn't matter) that are not intended to be left open. Transient dialogs are not under the same space constraints. As far as I know the Inkscape developers do want to follow the Gnome Human Interface Guidelines (mostly), so I hope I'm not out of line asking for a more standard layout. The Document settings (document properties?) seems more like the latter type of transient Dialog. The reason I bring this up at all is that I immediatly wondered where the Cancel, OK buttons were. By positioning the "clear" button on the bottom right where the action/OK button usually is I expect some users will absent mindedly clear the data they just typed in when in fact they wanted to dismiss the dialog not clear the information. I believe that the Reset button and Icon the GIMP uses is a stock item, using it instead might help. The abbreviation "Info" should not be used, abbreviations make English harder to understand for non-native speakers and even native speakers will need to take an extra fraction of a second to mentally unscramble it. Anyway from an Internationalisation point of view there needs to be enough space in the user interface to accomodate other languages that are more verbose, so there is no advantage to be gained by the abbreviation. (You might also consider putting the Custom name,value pairs into a seperate tab as it would provide much more room as there could potentially be many other bits of metadata. Offhand I can think of Date, Copyright (which includes licensing), keywords, being needed for OpenClipart.org content). The item "Insert OpenClipart.org RDF" is very specific and could be confusing to new users who have discovered Inkscape through their Linux distribution, perhaps this could be changed to insert metadata from file/template and one of those templates would be the OpenClipart.org metadata? I am not suggesting you redo these dialogs now but I hope you will take on these suggestions and incorporate them whenever you next need to revise the dialog. Hope that helps. Sincerely Alan Horkan

7 13

Hide and Seek! where did the menu bar go?
by Alan Horkan 27 Jun '04

27 Jun '04

Hide and Seek! where did the menu bar go? I turned off the menu bar only to be left wondering how to get it back short of obliterating the config files. Gun ... Foot ... shot ... blood everywhere. The easiest and most obvious solution is to disable the feature. I'm not entirely sure how the feature is useful in normal usage and worthwhile exposing to the users (an autohide option in Fullscreen mode might be more useful than all-or-nothing) but if there is any reason to keep it... Previous versions of inkscape repeated everything in the context menu and I'm glad it no longer does so, but when there is no menubar there needs to be an option to reenable it just as in Fullscreen mode the context menu needs an option to get out of Fullscreen mode. KDE consistantly uses the shortcut Ctrl+M for showing and hiding the menubar, but it is fast becoming clear to me that Inkscape is going to have a disasterous illogical collection of keybindings if we try and have bindings for everything and it is a particularly bad idea to waste keybindings for infrequent actions, particularly reconfiguring the interface which hopefully the users wont want or need to do very often. The Gnome Guidelines recommend against trying to have keybindings for everything, which is not a very helpful recommendation but am becoming more and more convinced that bindings should be reserved for actions that are likely to be repeated often. So I'd recommend against that approach. Inkscape is probably the first Gnome Application I have ever seen that allows you to hide the menubar (i suppose Dia and the GIMP do too but in an entirely different way), the downside of which is that it is the first to face these problems. If there is a solution that we can agree on then Inkscape help forge the way forward and I'll submit it to be added to the Gnome Human Interface Guidelines. At the very least I'm hoping this option to shoot yourself in the foot be sorted out in some way before the next release. Sincerely Alan Horkan http://advogato.org/person/AlanHorkan/

2 1

Funcitionality requirement
by Néstor Díaz Valencia 27 Jun '04

27 Jun '04

Hi everybody. I've been using Inkscape lately with LIVES, a linear video studio for linux. LIVES uses frames to create animation (of course) I wonder if a new functionality can be added to Inkscape to export bitmaps sequencially, I mean with this: a checkbox for increment the name of the exported file. We write a filename to export like "livingroom000.png" and then every time I press the export button it will increase the last number at the end: livingroom001.png livingroom002.png livingroom003.png . . . . It will help also with the gap plugin for The Gimp. After that we can easily import a folder to LIVES. I hope this won't suppose a big delay in other more important stuff needed by Inkscape nowadays. Yours: Néstor Díaz

2 3

Nightly windows builds?
by Bryce Harrington 26 Jun '04

26 Jun '04

I'm updating the downloads.php page in preparation for the testing effort. What is the proper link(s) that we should be pointing to for the Windows builds now? Bryce

8 11

Win32 freeze-at-border bug seems to be fixed
by Carl Hetherington 26 Jun '04

26 Jun '04

Hi, I just committed a couple of changes to sp-canvas.cpp that I copied from Sodipodi. They seem to fix the win32 freeze-at-border bug, so please could windows users test the CVS build and see how they get on. The changes are #ifdef'ed only to happen on Win32 (for the moment), so hopefully there should be no Linux side-effects. Carl

5 4

Patch to fix printing problem with shape markers
by Eric Jonas 26 Jun '04

26 Jun '04

The existing ps-output code does not correctly print shape makers, neglecting to apply the transformation. This really sucks if you've been using these markers a lot, as I've been doing in drawing a bunch of FSMs. For an example of code with this problem, see: web.mit.edu/jonas/www/input.FSM.svg The marker definition: <marker style="overflow:visible;" id="TriangleOutM" refX="0.0" refY="0.0" orient="auto" inkscape:stockid="TriangleOutM"> <path transform="scale(0.4)" style="fill-rule:evenodd;stroke:#000000;stroke-width:1.0pt;marker-start :none;" d="M 5.77,0.0 L -2.88,5.0 L -2.88,-5.0 L 5.77,0.0 z " id="path3347" sodipodi:nodetypes="cccc" /> </marker> has the "transform" attribute in its path, and in the current codebase it appears to be ignored. Thus in PS and EPS output, the markers are quite often the wrong size. The error appears to be in sp-shape.cpp, in sp_shape_print. The following patch fixes the problem, and I'd love to submit it via the SF.net patch interface, but their confirmation-mail-script to register an account is ultra-slow today :) Really, we just additionally apply the transformation from the marker_path, a rather simple bug. ...Eric The patch follows: Index: sp-shape.cpp =================================================================== RCS file: /cvsroot/inkscape/inkscape/src/sp-shape.cpp,v retrieving revision 1.38 diff -c -r1.38 sp-shape.cpp *** sp-shape.cpp 22 Jun 2004 17:35:19 -0000 1.38 --- sp-shape.cpp 26 Jun 2004 16:48:21 -0000 *************** *** 568,573 **** --- 568,574 ---- } nr_matrix_multiply (&tr, &marker->c2p, &tr); + nr_matrix_multiply (&tr, &marker_path->transform, &tr); NRMatrix old_tr = marker_path->transform; marker_path->transform = tr;

2 1

scaling & snapping
by bulia byak 26 Jun '04

26 Jun '04

Carl, 1. When you are finished with snapping refactoring, don't forget to update the Release Notes. From my viewpoint, what matters is using of Shift for no-snap mode and it working the same in all tools including node edit. 2. The new scaling origin mode you did does not quite work. The "outermost point" mode works, but the "bounding box" mode does not. Turn on box selection cue, zoom in and draw a small rect with thick stroke. Now when I drag the right handle, the left edge of the rect also moves a bit in the same direction. It must stay unmoved in that mode. 3. Better names for the options are: - Opposite bounding box edge - Farthest opposite node [not point] 4. Additionally the bbox option does not sit well with the "scale stroke" option. When I don't want to scale stroke, i.e. use a compensation after scaling, that compensation moves the bbox of the object even farther away from the original position, making the bug in 2. above worse. This mode must check the value of the "scale stroke" option and take it into account.

3 5

Re: [Inkscape-user] Pango testing - help needed!
by MenTaLguY 26 Jun '04

26 Jun '04

On Fri, 2004-06-25 at 14:24, Joshua N Pritikin wrote: > Inkscape not only rendered improperly, it also crashed. > > I used the raghu font for testing because I'm not sure whether Pango > knows about Gargi yet. > > http://www.yudit.org/download/fonts/raghu.ttf > > There are two attachments. The PNG image is what the letters _should_ > look like. The TXT file is the UTF8 for the letters. > > Therefore, it should be easy for you to reproduce the crash even if > you don't know devanagari. Thank you! This is just what we need for testing. I've filed this as bug #980136 in the bug tracker. -mental

1 0

[Fwd: Re: [Inkscape-user] Pango testing - help needed!]
by MenTaLguY 26 Jun '04

26 Jun '04

-----Forwarded Message----- From: Joshua N Pritikin <jpritikin@...237...> To: inkscape-user(a)lists.sourceforge.net Subject: Re: [Inkscape-user] Pango testing - help needed! Date: Fri, 25 Jun 2004 23:54:59 +0530 On Sat, Jun 19, 2004 at 06:21:17PM +0000, bulia byak wrote: > 2. Here is what SHOULD work now but is not yet tested because we don't > speak these languages. This is where we need your help: I tried the autopackage binary because I didn't want to spend the time to build from CVS. Inkscape not only rendered improperly, it also crashed. I used the raghu font for testing because I'm not sure whether Pango knows about Gargi yet. http://www.yudit.org/download/fonts/raghu.ttf There are two attachments. The PNG image is what the letters _should_ look like. The TXT file is the UTF8 for the letters. Therefore, it should be easy for you to reproduce the crash even if you don't know devanagari.

1 0

Re: [Clipart] Is anyone working on categorizing the existing images?
by Bryce Harrington 26 Jun '04

26 Jun '04

Kees, take a look at this 'wordnet' resource... Bryce On Wed, 9 Jun 2004, Mike Linksvayer wrote: > Karl Ove Hufthammer wrote: > > The point is: Images aren't placed in hierarchical categories, > > they have keywords assigned to them. The hierarchy is a separate > > thing. > > Good idea. > > Wordnet <http://xmlns.com/2001/08/wordnet/> may be useful here. > > Example: http://xmlns.com/wordnet/1.6/Flag > > If a keyword is known by Wordnet, a hierarchy is provided. > >

1 0