- Inkscape Devel - Inkscape Mailman

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

RE: [Inkscape-devel] 0.39 Release?
by bulia byak 26 Jun '04

26 Jun '04

>By the way, Alan has produced a collection of stock gradients, that >we're going to try to package as part of openclipart (as opposed to >bulking up the Inkscape tarball.) These will get installed to a >directory somewhere in the /usr/share/. Is it possible to inform >Inkscape of the location and identity of these gradients? Yes but not in a short term. The plan is: - switch marker menus to a new table-like widget that is updated on the fly and more responsive - add the same widget and the ability to use stock items to patterns, gradients, symbols etc. >I spent some time testing it and playing with it. It works very well >when compared with the usual RPM issues of finding/downloading various >dependencies. I think it will help us a lot, especially given the new >dependencies we've introduced recently, since it takes care of that for >the user fairly seemlessly. Good, then could you please publish a short version of my plea for help with Pango testing on the site, adding a link to the daily autopackage. >An issue is that we can publish a beta release for testing, get lots of >testing input, but meanwhile developers will be adding bug fixes or even >new code to the release branch. Ideally, betatesters would update >frequently and re-test, but realistically I think we'll get at most one >or two cycles of testing out of people. Branching out a separate beta branch before the release is something we'll definitely need to do for 1.0, but for 0.39 it's perhaps more trouble than it's worth. It only makes sense for really long testing periods. But what I think we can and should do is to allow several days of testing of a final release candidate with TOTAL freeze on CVS, and requiring a certain nunder of people to OK it before it is released. _________________________________________________________________ STOP MORE SPAM with the MSN Premium and get 2 months FREE* http://join.msn.com/?pgmarket=en-ca&page=byoa/prem&xAPID=1994&DI=1034&SU=ht…

3 3