- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] Re: [Inkscape-devel] BUG and solution in align dialog
by bulia byak 18 Jul '04

18 Jul '04

> My SF name is o__b Done, you can commit your code now. Welcome to the team! :) > > One idea I had is this: Imagine you have a path consisting of strict > > horizontal and vertical segments, and you want to distribute (some of > > the) vertical segments (not nodes!) equi-spacely. I think it's a > > pretty common situation, but distributing _nodes_ will break the > > verticality of segments. So I propose to add a (perhaps optional) > > rule: If two or more nodes are aligned vertically (within some > > tolerance), consider them one node and move them as a whole during > > horizontal distributions, and the same for horizontal > > alignment/vertical distributions. Makes sense? > > > Looks weird to me, and could be surprising for the user. But I understand the > need for such a functionality. If we generalize a bit, this would be > distributing groups of nodes. But this is hard in terms of UI. Yes, what I propose is a subset of "distribute groups", and yes, fully generalized "distribute groups" is difficult to implement and may be overcomplex in terms of UI. Which is why I propose this special case - I think it's very common in practice and pretty intuitive once you get used to it. Just think of it as nodes "snapping together" when they're on one horizontal or vertical, so that distribution buttons treat them as a whole. This may be switched off by a checkbox in the align dialog (on by default, with the state remembered across sessions in a preference value). > > Another thing I always wanted to have is Random distribution. Maybe > > you can add it while you're working on that dialog, I think it should > > be easy enough? > > > > I'm not sure to understand what it means. Just throw each node on an random > position, or keeping the order and randomize the step size, or even > distribute against a distribution function (gaussian, poisson, etc.) ? In fact there may be many various approaches to randomization, but for practice, what I think will be the most useful is two buttons: Shake and Shuffle. 1. Shake: Each selected object moves by some small random distance from its current position. Here a Gaussian distribution would be appropriate, so that small displacements are more frequent than large ones. The default radius might be 0.05 of the total span (span == the distance between the outermost selected object), with this value ("the force of the shake") settable in preferences. Shake may sometimes change the order of objects if they're close together, but normally it will not. If you need a stronger shake, just keep pressing the Shake button. 2. Shuffle: All objects are placed at random points within the entire span between the outer objects. This does not preserve the order of the objects, but shuffles them like cards in the pack. For example, if you have a row of equispaced objects and you want to change their positions randomly but keep the equispaced distribution, you press Shuffle and then Distribute equispaced to space them evenly again. Note: it is obvious that the overall span of the objects will keep getting narrower if you press Shuffle repeatedly. I'm not sure if this is a problem that we have to live with, or it makes sense to try to compensate for it by artificially expanding the span before shuffling so that, _on average_, the span stays the same across many subsequent shuffles (it's an interesting mathematical problem, by the way - how much we need to expand the span for this condition to satisfy). Also note: in the above, "objects" may be nodes (in node tool) or object centers (otherwise); I don't think we need separate shake/shuffle buttons for left/right edges. However, when calculating the span, it makes sense to measure it between the outer edges of the bboxes of the outer objects, not between their centers. Let me know what you think of this plan. > Done. I'm just wondering why so many enums are anonymous and you pass plain > ints as parameters ? No idea, maybe just Sodipodi legacy... > > > Yes. But as we will refactor all the dialogs, that should be > > > the right time to do it. The only thing needed is to make > > > each dialog inherit from a class. > > > > That's a good idea, as currently there's much shared code that can be > > moved to the parent class (delete/destroy handlers, etc.). Some of the > > shared code is already factored out into dialog-events but not all. > > > OK, I'll look at this. Obviously what needs to go into that class is all the standard global variables in all dialog files (x, y, w, h, dlg, etc.).

2 1

gtkmm 2.4
by MenTaLguY 18 Jul '04

18 Jul '04

Now that we've branched for the release, HEAD is unfrozen. I think my first bit of work will be to merge Aubanel's gtkmm 2.4 patch sometime in the next few days. If this will cause undue problems for anyone, please scream now. -mental

4 6

RPM packaging issue
by Bryce Harrington 18 Jul '04

18 Jul '04

Btw, there was one issue I found in the inkscape.spec file that other RPM packagers will need to look to as well: * Remove the following line from the spec file: %{_libdir}/inkscape/extensions/* We have consolodated extensions into the /usr/share/inkscape directory with the other data files. Bryce

2 2

Crash on editing a circle
by Mike Hearn 17 Jul '04

17 Jul '04

Hi, I have a reproducable crash on CVS from a few days ago, when doing the following: * Start Inkscape * Zoom in a bit on the blank canvas * Add a new circle (made whole) * Press ctrl+shift+f (fill/stroke dialog). Here is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1087436352 (LWP 15995)] 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 256 ~basic_ios() { } (gdb) bt #0 0x080b1589 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #1 0x080b15c8 in SPObject::deleteObject(bool, bool) () at basic_ios.h:256 #2 0x0814be5a in sp_marker_prev_new(unsigned, char const*, SPDocument*, SPDocument*, char*, NRArena const*, unsigned, NRArenaItem*) (size=22, mname=0x87534a0 "Arrow1M", source=0x83134a8, sandbox=0x8313470, menu_id=0x822f56b "marker-start", arena=0x87db328, visionkey=7, root=0x875f600) at sp-object.h:173 #3 0x0814c51a in sp_marker_list_from_doc (m=0x8647700, current_doc=0x8313400, source=0x83134a8, markers_doc=0x0, sandbox=0x8313470, menu_id=0x822f56b "marker-start") at dialogs/stroke-style.cpp:1008 #4 0x0814c9b6 in ink_marker_menu (tbl=0x88c1e58, menu_id=0x822f56b "marker-start", sandbox=0x8313470) at dialogs/stroke-style.cpp:1126 #5 0x0814da4e in sp_stroke_style_line_widget_new() () at dialogs/stroke-style.cpp:1532 #6 0x081481cf in sp_object_properties_dialog() () at dialogs/object-properties.cpp:216 #7 0x081a00aa in sp_action_perform(SPAction*, void*) (action=0x879a3d0, data=0x0) at helper/action.cpp:132 #8 0x0809dcc6 in sp_shortcut_invoke(unsigned, SPView*) (shortcut=50331718, view=0x858b130) at shortcuts.cpp:33 #9 0x081a2816 in sp_window_key_press (widget=0x894c468, event=0x0) at helper/window.cpp:34 #10 0x405c427c in _gtk_marshal_BOOLEAN__BOXED (closure=0xbffff2d4, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8, marshal_data=0x0) at gtkmarshalers.c:82 #11 0x40884dd6 in g_closure_invoke (closure=0x894c450, return_value=0xbffff190, n_param_values=2, param_values=0xbffff2c0, invocation_hint=0xbffff1b8) at gclosure.c:437 #12 0x4089698a in signal_emit_unlocked_R (node=0x831c268, detail=0, instance=0x894c468, emission_return=0xbffff260, instance_and_params=0xbffff2c0) at gsignal.c:2506 #13 0x40895a21 in g_signal_emit_valist (instance=0x894c468, signal_id=0, detail=0, var_args=0xbffff450 "h\2240\bx}\213j@...455...") at gsignal.c:2205 #14 0x40895eab in g_signal_emit (instance=0x894c468, signal_id=52, detail=0) at gsignal.c:2239 #15 0x406a8ebc in gtk_widget_event_internal (widget=0x894c468, event=0x8974620) at gtkwidget.c:3563 ---Type <return> to continue, or q <return> to quit--- #16 0x405c2a16 in gtk_propagate_event (widget=0x894c468, event=0x8974620) at gtkmain.c:2318 #17 0x405c1857 in gtk_main_do_event (event=0x8974620) at gtkmain.c:1582 #18 0x4079844a in gdk_event_dispatch (source=0x0, callback=0, user_data=0x0) at gdkevents-x11.c:2133 #19 0x408d1384 in g_main_dispatch (context=0x82c0000) at gmain.c:1895 #20 0x408d2349 in g_main_context_dispatch (context=0x82c0000) at gmain.c:2441 #21 0x408d266e in g_main_context_iterate (context=0x82c0000, block=1, dispatch=1, self=0x82c24c0) at gmain.c:2522 #22 0x408d2bd6 in g_main_loop_run (loop=0x8982d68) at gmain.c:2726 #23 0x405c11cb in gtk_main () at gtkmain.c:1172 #24 0x08089ead in sp_main_gui(int, char const**) (argc=1, argv=0xbffff6f4) at main.cpp:311 #25 0x08089d24 in main (argc=1, argv=0xbffff6f4) at main.cpp:233 thanks -mike

9 15

Test strategy
by Gazal, Geraud (MED) 17 Jul '04

17 Jul '04

Hi all, here is my workaround for the testing strategy of Inkscape. (sorry it's a copy paste of my doc in the mail, I can forward you the rtf document if you want)(easier to read) I'm currently listing the "specifications", in order to have a reference of features to be tested. The main things that should be defined if you agree with this : - establish a test process - establish communication/coordination tools (wiki / specific web page /mail list ?) - prepare/review specifications,test tools and test cases - begin tests Regards, Matiphas Preliminary note: This is a preliminary/draft document for defining a test strategy for Inkscape projet (http://www.inkscape.org) It is currently in Rich Text Format (rtf), for easy exchange purposes. -> Don't know yet how to manage this document (Dookbook ? Open Office)(specific web page ? wiki ? cvs ?) -> Any way this document will split for the following reasons : - separate specifications of software, test strategy, test traceability, test items, test results... - ease of maintenance - separation of features under test At the moment, it is mainly architectured according to the categories of bug tracking under sourceforge tool for Inkscape (see http://sourceforge.net/tracker/?group_id=93438) Reference: Inkscape testing framework: http://www.inkscape.org/cgi-bin/wiki.pl?TestingFramework (Missing) Inscape "specifications" (not really a pure specification of the software, this would be incompatible with the development process of Inscape, but somewhat a hierarchised and detailed list of features to be tested) Introduction: Why testing ? Just to ensure quality of the software (does it suits user needs ?) and even better the quality of the code/design What are the important concepts of testing : - measure: metrics (specifications and comparison to those specifications) are needed. This is important for the homogeneity of the tests and the correct interpretation of their results - coverage: what are the areas (design / code / features / architectures) covered by the tests. Stronly linked to the efficiency of the testing process - repeatability/reproducibility. The tests must provide coherent results, in order to to be correctly interpreted. Automatisation of the tests and well documented references (vocabulary, procedures...) help a lot. - periodicity: when shall the test be executed. This depends on the criticity, probability of bug and level of test. What is required for having efficient tests : - KISS : tests cases should be very simple in order to be easy to understand, easy to implement, and the results easy to interpret. - well maintained and documented Acronyms and abbreviations: (not used yet, but might become usefull) NA : Not Applicable TBD : To Be Done Levels of tests: Unit testing: at code level, providing tools/script in order to test classes/functions... Mainly depends on coding team Feature testing: the biggest part, and the largest amount of work. After definition of the features to be tested, establish precise test cases and execute them. Can be partially automated (see in this document) Non regression testing: the ability to check nothing has been broken in the code after important/critical development. Can be covered by feature and unit testing, but a non regression analysis after important/critical development is a great help. Plus after finding some new bugs covered by the test plan, prepare new test itemand ensure it covers properly the new bug. Reference tools: Purpose : define a list of reference tool against which the software should be compared. (especially for issues around import/export / rendering / printing / maybe UI) To be refined. At the moment : take a look at http://www.inkscape.org/cgi-bin/wiki.pl?OtherProjects SVG software Vector software Tests: Build Linux (Debian / Gentoo / Slackware / Mandrake / Fedora / Suse / Others) Windows (98 / 2000 / XP) MacOS (X) BSD (Free / Open) Other Unices (Solaris / Irix) Notice : should be automated (example see : http://public.kitware.com/Dart/HTML/Index.shtml) List of tasks : - establish a list of builders and link it with the architectures they can manage - establish a kind of "test contract" defining the tools to be used (compiler, dependancies, test report tool...) and the periodicity of the tests Import Bitmap Vector Export Bitmap Vector Printing Node editing Shape editing Transformations Color Management Internationalization Main tasks : - list the internationalization that are actively maintained - starting with http://www.inkscape.org/cgi-bin/wiki.pl?InkscapeTerminology, prepare a good dictionnary covering the maintained languages (can be very helpful for the reading of test procedures), plus the vocabulary of the application (messages, menus, etc etc) - establish a list of users with the languages they can check and define a kind of "test contract" UI SVG compliance See in 'specifications of software' plus SVG specifications The main idea is to provide a large repository of reference "SVG files" and "editing sequences". then two types of actions : - open reference files with inkscape, export it as bitmap and compare with a reference bitmap provided by a reference application (Batik ?) - open Inkscape, launch reference editing sequence, export result as bitmap and compare with a reference bitmap provided by a reference application on the same sequence (Inkscape itself for non regression, Batik ?) Previous sequences can be combined in one in order to save time, but then analysis of results can become more complex. Performance "Speed benchmarking" (can be automated) - provide a list of criterias to be tested (time to launch, time to open complex docs, time to save complex docs, speed of scrolling, speed of application of different types of transformations) - provide a benchmark tool - establish a list of users with the architecture on which they use the software, then define a kind of "test contract" defining the tools to be used and the periodicity of the tests Verification of robustness - testing memory leaks (not a specialist of this : I need help) - provide a shaker tool (this tool would launch Inkscape and then start a predefined number of pseudo-random commands -logging each action). The goal is to detect crashes and analyse their conditions with the logs - testing against severe conditions (corrupted files / out of memory / out of disk space ...)

2 1

Re: [Inkscape-devel] BUG and solution in align dialog
by aubi＠...373... 17 Jul '04

17 Jul '04

>> BTW, I finished refactoring the align dialog to use gtkmm and more >>OO code. >> Now I'll add the align nodes features. > >How is it going to look in terms of UI? I think the most intuitive >would be to make it work on selected nodes when the node edit tool >is >active on the active desktop, and on selected objects otherwise. >This >way you need no additional buttons or switches in the dialog. > >Also it would be nice to disable all or some of the buttons >depending >on what is selected. Thus, if no objects or only object is selected, >all align/distribute buttons are grayed out; if several nodes are >selected, "distribute top/bottom/right/left" are disabled because >they >make no sense for sizeless nodes (only distribute centers and >equi-spaced remain). That was what I was planning to do. But instead of grayed icons, I think I'll replace them by specific node align icons (node align vert, node align hor, node ditribute vert, node distribute hor). To do so, if it's not already here, I'll add a stdc::signal<void, ToolIdent> _tool_changed; for the desktop. >> I also would like to talk about the possibility to use the dialogs >>like in >> gimp2 (drag and dropable notebook tabs, multiple instances of the >>same >> dialog, etc) >> I started a very simple implementation, but I'm not sure you want >>to do that. >> Now I'm used to it, I find it easier to remember keyboard >shortcuts and have >> transient dialogs. No mess with tabs. PLease let me know your >>opinions. >Draggable notebook tabs may be a good idea - it will let one combine >all the tabs used frequently into one dialog and have only that >dialog >open, thus saving space. But it's likely to be rather difficult to >implement, it will very much disrupt our old dialogs code. > Yes. But as we will refactor all the dialogs, that should be the right time to do it. The only thing needed is to make each dialog inherit from a class. For me the main question is the impact on the GUI. Do we keep buttons for calling each dialog ? How much docker areas can you create? How do you create one ? What happens with keyboard shortcuts ? >Multiple instances of the same dialog does not sound like a good >idea >at all. I think it will be just confusing without any advantage. OK, so maybe a ctrl+shift+a shortcut could bring the align dialog in a new docker if it does not already exists. This way, you could still work as now, but w/ the ability to group several dialogs in one. I was also wondering if we could split the fill dialog in 3 different dialogs, strarting in the same docker, but you could rearrange that, eg if you want to see in the same time fills and strokes ... ************************ ADSL ILLIMITE TISCALI + TELEPHONE GRATUIT ************************ Surfez 40 fois plus vite pour 30EUR/mois seulement ! Et téléphonez partout en France gratuitement, vers les postes fixes (hors numéros spéciaux). Tarifs très avantageux vers les mobiles et l'international ! Pour profiter de cette offre exceptionnelle, cliquez ici : http://register.tiscali.fr/adsl (voir conditions sur le site)

2 1

Inkscape Status July 15, 2004
by Bryce Harrington 17 Jul '04

17 Jul '04

Inkscape 0.39 has been released! It has been amazing to watch everything coming together over the past few weeks. Users have been very attentive to locating, reporting, and following up on wide ranges of bugs across an impressive range of platforms. Meanwhile developers have been grinding away at the bug list; the rate of bug fixing is astounding - it is not unusual for bugs to be fixed the day they're reported. The number of translations that have come in has also been impressive. Statistics Nov 15 May 15 Jun 15 Jul 01 Jul 15 ========== ====== ====== ====== ====== ====== Lifetime Rank on SourceForge: 4391 1028 928 930 845 (68.5%) (92.7%) (93.4%) (93.4%) (94.0%) Max Week's Rank on SourceForge: 62 36 41 43 33 (99.6%) (99.8%) (99.8%) (99.8%) (99.8%) Total SF Page Views * 475,000 616,263 678,767 741,681 Total SF Downloads * 27,400 34,015 36,979 39,359 Total Freshmeat URL Hits 746 * 7,333 7,615 7,946 Total Freshmeat Subscriptions 16 74 87 91 93 Lines of Code in src/: 115,901 189,116 280,263 261,927 264,418 Code lines 147,471 210,119 190,519 192,240 Comment line 16,757 40,620 41,422 41,926 Blank 25,886 34,677 35,134 35,422 Lines of Docs in doc/: 1,135 4,544 15,170 15,201 15,217 Lines of content in website: 1,173 6,008 6,372 6,581 6,784 Size of the Inkscape wiki: 3,700 18,638 17,176 16,600 17,854 Minutes since last ChangeLog mod: 360 * * 28 54 Bugs open/total: 9/15 57/365 63/401 88/452 73/496 Features open/total: 18/18 183/238 210/285 222/307 242/331 Patches open/total: 1/ 6 4/ 83 5/ 88 6/ 91 8/110 CVS Commits (as per inkscape-cvs): 481 3391 5549 6033 6314 Inkscape-devel membership: 49 78 84 87 95 Inkscape-announce membership: 9 43 53 58 60 Inkscape-user membership: 71 76 84 90 Num Translations: Translated: 338 405 Fuzzy: 288 270 Untranslated: 349 325 Total number of PO files: 32 32 Ave Translation Ratio: 34.7% 40.5% * - Statistics unavailable

3 7

HELP WANTED: OSX packager for 0.39
by Bryce Harrington 17 Jul '04

17 Jul '04

Hi all, We have not had Mac OSX packages to provide in the past, but we'd certainly like to! OSX is an important platform for artists, and it would make sense for Inkscape to have a good presence there, as it does on Windows and Linux. Kees and others have verified that it builds and can be run on OSX, so the hardest part is done. The notes are available here: http://inkscape.org/cgi-bin/wiki.pl?CompilingInkscape What we need is someone who can create a package that other OSX users can easily download and install. This probably doesn't require any coding know-how, but does require someone knowledgeable of fink and in compiling under OSX. If you're interested, please go ahead, and when you've got a working package, announce it here, and we'll add it to the Download area. :-) Bryce

1 0

[Fwd: Autopackage: fantastic, thanks.] (fwd)
by Bryce Harrington 17 Jul '04

17 Jul '04

---------- Forwarded message ---------- Date: Sat, 17 Jul 2004 12:42:28 +0100 From: Mike Hearn <mike@...333...> Reply-To: autopackage-dev@...375... To: autopackage-dev@...375... Subject: [Fwd: Autopackage: fantastic, thanks.] -------- Forwarded Message -------- From: Leland McInnes <leland.mcinnes@...456...> To: mike@...333... Subject: Autopackage: fantatsic, thanks. Date: Sat, 17 Jul 2004 03:01:08 -0400 Mailer: Ximian Evolution 1.4.6 (1.4.6-2) Hi, I've been keeping vague tabs on the autopackage project as it looked promising, but mostly it was still in the "unstable API" stage, so wasn't really much to use to me as an end user. I was looking at the latest inkscape however, and noticed an autopackage install. I figured this was a good chance to actually give it a try. It worked flawlessly and elegantly and did everything I would expect of it. I look forward with great anticipation to the 1.0 version and a wide variety of packages available. This is exactly the sort of things linux package management desperately needs. Thanks for all the great work. Leland McInnes. -- "The bitter apple and the bite in the apple. And the ragged and restless waters" -- The Dry Salvages (Four Quartets), T.S. Eliot --------------------------------------------------------------------- To unsubscribe, e-mail: autopackage-dev-unsubscribe@...375... For additional commands, e-mail: autopackage-dev-help@...375...

1 0

problems compiling in macosx
by Albert 17 Jul '04

17 Jul '04

Hi inkscapers Inkscape 0.38 compiled in MacOSX after djusting several details as I reported to the inkscape-users list some time ago. Now for 0.39: I have gone already over the gtkmm issue by doing what was suggested by Peter Moulder, that is change 'ink_gtkmm_pkg=gtkmm-2.0' to 'ink_gtkmm_pkg=' But just to find another issue: checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape I know my system has libpng 1.2.5 installed. Note that 0.38 compiled without complaining about this. I've noted the failing test in configure.in has not changed since version 0.38, so I'm pretty lost here. Here the last terminal output lines from ./configure before failing: ... checking GNU compiler version... 3.1 checking locale.h usability... yes checking locale.h presence... yes checking for locale.h... yes checking for LC_MESSAGES... yes checking libintl.h usability... no checking libintl.h presence... no checking for libintl.h... no checking for pkg-config... /sw/bin/pkg-config checking for png_read_info in -lpng... no configure: error: libpng >= 1.2 is needed to compile inkscape Any help would be appreciated. Albert

3 7