- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] extensions usability
by Jose Hevia 13 Mar '05

13 Mar '05

> Ted Gould wrote: > > Yes, I think the text needs to change -- but I think the dialog needs to > > stay. > > I'd like to recommend disabling the dialog, at least until it's pretty > common people will have most extensions. Let me tell you a story: I'm a inkscape user that eventually learned to use inkscape to make vector drawings. I use debian sid ,so I just made an update to apt-get.If you have used it you know how easy is to upgrade +30 programs at once.I was working hard until night for a deadline project so I just shut down the computer and didn't use this computer for some days when finished. Later ,I needed to open a SVG to work with and so it happened: One or more extensions failed to load!!! The failed extensions have been skipped... What the hell? (#?!(%$·#!!!!!).Something is crashed,but what?,I open inkscape from command line ,no indication.No help.Nada.Nil.Nothing. Simply ,I don't know what an extension here means,I only recently read the mailing list,and don't know.They are optional parts like extras or fundamental part? It says: [...]please refer to the error log located a[...]ooh, so it's an error. (If it wasn't inkscape will start without pushing an (annoying) OK button.) But it's strange ,I could use inkscape like I was used to and nothing breaks (but beware ,don't trust, something is broken and could make lost your important data). I didn't unmarked "Show dialog on startup" because if something is broken I don't want it to hide this fact. No need to tell you that I didn't read /home/xxx/.inkscape/extension-errors.log(or if I did don't remember), and it took me some time to connect the general update with this "crash".I thought it was inkscape having problems,then I notice something different with the program,had a look to about dialog to see that I just installed a new version. Sorry for my behavior, if I had no others things to do I'd do better Jose Hevia

1 0

'using namespace' considered harmful
by MenTaLguY 13 Mar '05

13 Mar '05

Guys, I've been noticing a lot of usage of 'using namespace' starting to creep into the codebase. With few exceptions, that's not a good thing... The reason is that as more classes get added to the imported namespace, a class or function may eventually get added that conflicts with one in your own namespace. Depending on the exact nature of the conflict, it may not result in a compile failure, but instead introduce subtle bugs into the compiled code (e.g. if overload resolution picks the wrong function). So, as a rule, please 'using' the individual classes or functions that you actually need. Do NOT 'using' an entire namespace, and especially DO NOT use any form of 'using' in the global scope of a header file -- that will pollute the namespace of every file that directly or indirectly includes your header. Current offenders: (header files with inappropriate 'using's that MUST be fixed) src/ui/dialog/align-and-distribute.h:using namespace Inkscape::UI::Widget; src/ui/dialog/document-preferences.h:using namespace Inkscape::UI::Widget; src/ui/dialog/export.h:using namespace Inkscape::UI::Widget; src/ui/dialog/fill-and-stroke.h:using namespace Inkscape::UI::Widget; src/ui/dialog/find.h:using namespace Inkscape::UI::Widget; src/ui/dialog/inkscape-preferences.h:using namespace Inkscape::UI::Widget; src/ui/dialog/messages.h:using namespace Inkscape::UI::Widget; src/ui/dialog/text-properties.h:using namespace Inkscape::UI::Widget; src/ui/widget/unit-menu.h:using namespace Inkscape::Util; (modules where individual 'using's would be better) src/ui/dialog/inkscape-preferences.cpp:using namespace Inkscape::UI::Widget; src/ui/stock-items.cpp: using namespace Gtk::Stock; src/application/editor-impl.cpp:using namespace Inkscape::UI; src/application/editor-impl.cpp:using namespace Inkscape::UI::Widget; src/io/ftos.cpp:using namespace std; src/svg/ftos.cpp:using namespace std; src/svg/itos.cpp:using namespace std; Please fix, thanks. -mental

1 0

NEW: more gradient stuff
by bulia byak 13 Mar '05

13 Mar '05

Some improvements since the last announcement: - All tools that were previously able to click to select (namely node, shapes, and gradient tools), can now do Shift+click (add to selection) and Alt+click (select under) exactly as the Selector tool. - Dragging a gradient handle with Ctrl+Shift will scale the entire linear or radial gradient around its center. - Gradient handles for each gradient are connected by blue lines for fill gradient and yellow lines for stroke gradient. - In gradient tool, instead of dragging, you can double-click an object to create a new gradient centered within the object's bounding box. If you have several objects selected, or if your selected object is behind another one, you can double-click with Ctrl to create gradients on selected object(s) without changing selection. - The selected gradient handle will intercept any color/opacity setting commands and apply them to the corresponding stop(s) of its gradient(s). This means that at least two-stop gradients can be completely edited without ever opening the Gradient Editor dialog. In particular, you can use these methods to change the color of the selected handle: + Dropper tool (for example, to blend a radial gradient onto background, select its outer handle and pick the background color with the dropper). + Paste style (if the pasted style contains both fill and stroke style, the stop will take the fill style). + Fill and stroke dialog [this does not quite work yet because the dialog switches to gradient button and won't let you edit the color] - Double-clicking any gradient handle will open the Gradient Editor dialog with that handle's gradient loaded and the corresponding stop selected in the list. - Before, the actual direction of the linear gradient was not always perpendicular to the line connecting it handles if the bounding box of the object was not a square. This is now fixed, though the fix only works for new gradients that you create (i.e. gradients in old files are not affected). In other news, Richard Hughes' text layout rewrite appears to have reduced the memory consumption on a text-heavy document by about 20%, and rendering is faster by the same percentage. Hooray! :)

3 2

Inkscape hangs; create rectangle, lock layer, select (root)
by xscd 13 Mar '05

13 Mar '05

Can someone confirm the following issue? I'm using Inkscape 0.41 (Feb 10 2005), installed via Debian package, in Debian with a dual-CPU Tyan motherboard. I can reliably cause this hang by doing the following steps: * launch Inkscape, and in the default new document, choose the rectangle tool and draw a rectangle * with the rectangle still selected and its handles visible, click the "lock layer" icon on the status bar at the bottom of the window * click the layer menu on the status bar next to the lock icon, and select "(root)" At this point Inkscape hangs and begins to monopolize the CPU(s). Thank you, Steve D, New Mexico, US -- ---------------------------------------------------------------- The difference between a violin and a viola is that a viola burns longer. -Victor Borge ----------------------------------------------------------------

6 7

gradient editing strangeness
by Johan Forsberg 11 Mar '05

11 Mar '05

Hello, I *really* like the new "on canvas" gradient editing mode. However, the gradient editing still has a feature that I find puzzling. Maybe it's part of the svg standard or something and then it can't be changed I suppose. When editing a linear gradient, the line between the handles seems like it should represent the actual direction of the gradient, but it doesn't, exactly, unless the object has a perfectly square bounding box. If the bounding box is rectangular, the only directions in which the line and the direction of the gradient are the same are horizontal and vertical; all other directions the gradient appears "sheared" ('m not sure if this is the correct term); it is not parallel to the line. (This is a bit hard to explain, perhaps I should make a screen shot to demonstrate what I mean?) Even more confusing is the fact that this behaviour does not change even if the object is resized to have a square bounding box. This sometimes makes it difficult, for example to fine-tune a gradient on a very long and thin object, depending on its orientation. I don't know it I should report this as a bug or if there is some rational explanation :) Cheers, Johan Forsberg

2 2

Absolute paths for website
by Jonathan Leighton 11 Mar '05

11 Mar '05

I've been working on a prototype of the Inkscape news using WordPress, but am having trouble as URIs for archives come out like "/archives/2005/01/". Due to the relative paths used on the website, the browser then can't locate the stylesheets, and links point to the wrong place on those pages. So... does it matter if I change to absolute paths? (Which, IMHO, are better anyway) -- Jonathan Leighton aka. Turnip http://turnipspatch.com/ | http://digital-proof.org/

5 10

Please help fixing i18n bug
by Samphan Raruenrom 11 Mar '05

11 Mar '05

Please help fixing the bug 1093864 http://sourceforge.net/tracker/index.php?func=detail&aid=1093864&group_id=9… It renders Inkscape almost useless for Thai (and other CTL languages). I guess any nonspacing combining character, no matter what language it is, shouldn't work too. Please tell me if there're anything I can help (e.g. test cases, I can't attach the file to the issue). Thanks. -- _/|\_ Samphan Raruenrom.

2 5

Duplicating libcroco code in Inkscape tree
by Peter Moulder 11 Mar '05

11 Mar '05

I am working on supporting non-inline CSS stylesheets, by using libcroco (a C library for CSS parsing and determining what CSS properties apply to a given element). Not quite: libcroco 0.6 (the most recent released version) isn't really suitable for Inkscape's use for finding what properties apply to a given element: it requires a libxml in-memory representation of the document tree rather than allowing use of our preferred Inkscape::XML::Node. (See near end of http://www.inkscape.org/cgi-bin/wiki.pl?CSS_Support for more details.) I have prepared some modifications to libcroco to make this more suitable for us, and I've gradually been feeding patches to the libcroco maintainer, but that will take some time for all the changes just to reach CVS, let alone be released as libcroco 0.7, let alone be available on a reasonable number of our users' systems. There are two main ways of addressing this that I'm considering: i) Put our own version of the rule selection code (cr-sel-eng.{c,h}) into Inkscape, and make it play nice with an installed (external) copy of libcroco 0.6. ii) Put all of libcroco into the Inkscape source tree. For (i), there are two aspects of "playing nicely with installed libcroco": - Getting `#include "cr-foo.h"' to find cr-foo.h (usually referenced from user apps as `#include <libcroco/cr-foo.h>'). The simplest approach is to change all `#include "cr-foo.h"' to `#include <libcroco/cr-foo.h>'. This is my preferred approach at the moment. It's tempting to try instead to get `-I/usr/include/libcroco-0.6/libcroco' (or whatever the path on the user's system) into our INCLUDES variable. This approach would be pleasing in its simplicity, and would also slightly reduce work in merging changes back into upstream libcroco. However, given that the exact path varies from system to system, the best I can think of involves adding to configure.ac something like ink_cr_incl=`pkg-config --cflags libcroco-0.6 | sed 's, .*,/libcroco ,'` INCLUDES="$INCLUDES $ink_cr_incl" (while retaining libcroco-0.6 in a PKG_CHECK_MODULES call, which would take care of LDFLAGS and error handling). Not too big a deal, but then neither is the #include-changing alternative. - Avoiding linkage errors from having cr-sel-eng symbols both in Inkscape's internal libraries and also in installed libcroco. Is there some linker options to avoid this? Otherwise, the alternatives are either to #define all the external symbols of our own cr-sel-eng to something else, or to convert cr-sel-eng.c to C++, which I believe should give different linker symbols (mangled); we could wrap in a namespace{} too if we want. My local copy uses the convert-to-C++ approach. It involved adding explicit casts in a dozen or so places (no implicit cast from void* in C++, no treating enums as ints). Approach (ii) has at least the following advantages & disadvantages: Advantages: - All libcroco source files can stay in C and can retain their existing #include text. - It guarantees us that libcroco is available. Otherwise we must choose between either: - Requiring libcroco (and bundling on some platforms with poor package management -- can't they all just use Debian? ;-) ); or - Using `#ifdef WITH_LIBCROCO' in the source code, and accepting that not all builds of 0.42 (or whatever) will be able to read SVG files using non-inline style. Disadvantages: - Makes Inkscape source tree about 1MB bigger, and increases Inkscape's memory usage at runtime. - Any bug fixes to libcroco would have to wait until at least one release of Inkscape before being fixed. This is most of concern if the bug fix is security-related. Licensing doesn't seem to be a problem: libcroco appears to be LGPL. I haven't yet checked with the libcroco maintainer for his comments; I'll bcc him. Can people add to this list of advantages & disadvantes, or suggest alternatives, or give other relevant information? pjrm.

7 18

icon issues
by bulia byak 11 Mar '05

11 Mar '05

Jon, a couple small icon-related things: 1 when double clicking a guide to open guide dialog, i get ** (inkscape:24066): WARNING **: failed to load icon 'guide_dialog' 2 launch, ctrl+n to open a new window, ctrl+q to quit: (inkscape:24082): Gtk-CRITICAL **: gtk_size_group_remove_widget: assertion `GTK_IS_SIZE_GROUP (size_group)' failed

2 3

icon preview?
by bulia byak 10 Mar '05

10 Mar '05

Jon, what is this new icon preview dialog? Is it temporary?

4 6