- Inkscape Devel - Inkscape Mailman

'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

text recommended reading: W3C charmod
by unknown＠example.com 10 Mar '05

10 Mar '05

Recommended reading for anyone here working on text stuff: http://www.w3.org/TR/charmod/ -mental

1 0