May 2009 - Inkscape Devel - Inkscape Mailman

win32 build working again
by Bob Jamison 08 Apr '24

08 Apr '24

The win32 build, which was broken for the weekend, is working again. I just made a "manual autobuild" again, so that we can see how it looks on Windows: http://troi.titan-aeu.com/~rjamison/inkscape/builds/ Bob

2 1

Split text extension
by Karlisson 15 Jun '09

15 Jun '09

Hello, I've updated my split text extension! See more details in: http://nerdson.com/bin/split/ It doesn't split flowed texts. I couldn't put the splitted elements in the same position they were before (because of the way flowedText data is organized), so I decided to not support this type of element in the extension. I'd like to know if there's a way to get the X and Y of a flowed text. Apparently they are determined by the position of the flowing shape... I'd like you to test it and if possible, put it on 0.47. Files: http://nerdson.com/bin/split/split.py http://nerdson.com/bin/split/split.inx Thanks! -- Karlisson M. Bezerra http://nerdson.com/ -

5 13

What about the spray?
by Pierre-Antoine MARC 09 Jun '09

09 Jun '09

7 11

fenv.h, fmin, fmax
by Jeremy C. Reed 03 Jun '09

03 Jun '09

Using inkscape-21256 snapshot (because release version has bug causing core dump when attempting to change fill color as reported numerous times). src/display/nr-arena-shape.cpp has #include <fenv.h> But I don't see any use of floating-point definitions, FE* macros, or fe*() functions. I commented that line out and inkscape built fine. (Also some platforms don't have any fenv.h.) Also src/live_effects/lpe-dynastroke.cpp uses fmin and fmax. Some platforms don't have that. So I added to src/live_effects/lpe-dynastroke.cpp : #define fmin(a,b) ((a)<(b)?(a):(b)) #define fmax(a,b) ((a)>(b)?(a):(b)) Also work/inkscape-21256/src/display/nr-filter.cpp refers to fmax but it is commented out.

3 4

LPEs for 0.47, take two
by Alexandre Prokoudine 02 Jun '09

02 Jun '09

Hi, Could we possibly try to include two currently disabled LPEs into 0.47? I'm particularly talking about: 1. Mirror symmetrically, which resolves multiple times requested symmetric drawing mode 2. Booloops, which makes Spiro a lot more useful. For now I moved all entries for currently disabled LPEs and the LPE tool itself from POTFILES.in to a newly created POTFILES.ignore so that translators have less problems. Alexandre

3 4

LPE Effects: Red line
by Tavmjong Bah 01 Jun '09

01 Jun '09

Hi, The editable red line showing the original path in an LPE when the LPE path is selected and the Node tool in use is no longer present in 0.46 +svn. Is this by design or is this a bug? I found it quite useful to be able to manipulate the original path and see the effect on the LPE path. Tav

4 5

pedro
by Alexandre Prokoudine 01 Jun '09

01 Jun '09

Hi, Before we hit strings freeze, it would be great to do something about Pedro (XMPP client). I know that this feature is by no means complete and is supposed to be rewritten more or less from scratch, but what we have currently is something optional that is always in English. In my not very humble opinion even such a feature should be localized. Keeping something that is not ready but somewhat available unlocalizable intentionally doesn't really sound wise to me. Could we please have this fixed? Another thing is that some messages are actually marked for translation and don't work. So I'm tempted to move them to POTFILES.ignore, because they don't make any sense to translator at the moment: even if they rebuild Inkscape with --enable-inkboard they can't even check what it looks like. Alexandre

1 1

include inkscapec.exe ?
by Alvin Penner 01 Jun '09

01 Jun '09

Will the program inkscapec.exe be included in the Windows distribution of 0.47? http://kaioa.com/node/63 This would be useful for those who are tracking bugs in Windows. -- View this message in context: http://www.nabble.com/include-inkscapec.exe---tp23632618p23632618.html Sent from the Inkscape - Dev mailing list archive at Nabble.com.

7 12

Reducing the number of control/tool bars
by JiHO 29 May '09

29 May '09

Hi everyone, With the new snap control bar, Inkscape is becoming quite plump above the waist. Combined with labels that are longer in many other languages than they are in english, this does not leave very much space to draw in the end. See this example in french on a 1280*800 display (i.e. not the smallest around) http://dl.getdropbox.com/u/1047321/inkscape/fat_ui.png The width is about half-drawing/half-palette, and, more importantly, the height cannot even accommodate all the tools even in this fully maximized setting. The snap control bar is not very wide but control bars do not seem to be dockable one next to each other. They apparently need to be on top of each other. Is that specific to my version of GTK or a known limitation? Now my real questions: what do you think about removing some of the toolbar items and reducing the number of control bars to two, as before? Do we really need buttons for new document, save, print, etc. when all of them are readily available in the menu and have standard, well known keyboard shortcuts? Having the snap controls in the toolbar make sense because the expose functionality that is more difficult to get to otherwise. But for the rest... My opinion would be: item status why? new remove present just a cm above, in the file menu; well known shortcut open remove idem save remove idem print remove idem + less frequently used import ? export ? undo remove present to reach in the edit menu; very well known shortcut redo remove idem copy remove idem cut remove idem paste remove idem zoom . . align keep it is inkscape specific except maybe: layers ? there is the layers' dropdown already for easy access global prefs remove if users really need to get to the global preferences often enough that it requires a button here, it's probably that there is a deeper problem. Plus this would reduce the confusion between the two because of their very similar icons (as was mentioned earlier on the list). doc. prefs keep Removing that would make enough room to fit the snap bar next to the main control bar. If GTK can't do it dynamically, it would need to be hardcoded, for now. These changes might seem to be at the detriment of beginners, but once again they target: - functions that are similar in most software, so for which the keyboard shortcuts are easier and more efficient to learn - functions that are easily available in the menu. Navigating to a menu is not that tedious especially when the menu is just a few pixels above the tool bar button. I looks like a bad habit carried over from some windows programs rather than like a real design decision on the part of the linux desktops. Plus, other apps (like the gimp) don't have buttons for such things and I haven't heard anyone complaining (about that part of the UI at least ;) ) I hope it is not too late to mention that. I think if change ever happens, it should be before 0.47, before people get exposed and used to a more cluttered UI. Thanks in advance for your comments. JiHO --- http://jo.irisson.free.fr/

3 3

Inkscape 0.47 About Screen Contest - Voting Time
by Joshua A. Andler 29 May '09

29 May '09

Hey All, The submission portion of the contest has concluded and it is now time to vote. Things have been simplified this go 'round. Voting will ONLY take place on deviantart, and everyone gets only 1 vote. http://inkscapers.deviantart.com/journal/24960257 Cheers, Josh P.S. This simplification this time was to reduce unnecessary administrative overhead... sorry, no exceptions.

3 2