July 2004 - Inkscape Devel - Inkscape Mailman

Plain svg format?
by Øyvind Hvamstad 19 Jul '04

19 Jul '04

Hi, I just dig this app. Good work. However, I have some problems with the new rdf metadata tags when storing plain svg in 0.39. It seems that no namespace declarations are present for rdf, dc and cc. Adding them to the top fixes the problem, but it's really a hazzle when you have some 30 figures in a thesis. :) I added these: xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://web.resource.org/cc/" You probably know this already, but if not.. Well.. Jimi needs valid xml! Inkscape rocks! (more than sodipodi :)) -- Øyvind Hvamstad <oyvind@...457...>

5 6

All tasks for 0.39 Milestone Completed
by Bryce Harrington 18 Jul '04

18 Jul '04

All of the tasks for milestone 5 "Inkscape 0.39" are now complete (the extension proposal was the last, oft-procrastinated item). I've moved all the completed Milestone 5 tasks to the PastMilestones page. Bryce

1 0

Proposal for Hard Freeze Process
by Bryce Harrington 18 Jul '04

18 Jul '04

As mentioned in the freeze process proposal for this release, we will have a new 'Hard Freeze' step to give us better quality control for the run-up to the Release Phase. During the Hard Freeze, we all refrain from committing to CVS. Instead, necessary changes should be posted to the patch tracker. A couple people -- the "Change Control Team" -- have the responsibility to vet and apply patches if they're absolutely necessary. For this release, I'd like to propose Mental and Bulia as the Change Control Team, and that we rotate who is on this team in future releases. Because the Inkscape developers are trustworthy, I think we can rely on the honor system, rather than turning off everyone's access. If there happened to be any abuse, it can be handled on a case-by-case basis. Here's how the process would work: === Hard Freeze Phase === 0. The Hard Freeze will be announced once all of the Must Fix bugs have been addressed and the codebase passes its distcheck and tests. Nobody except Change Control commits into the release tree after this point - only to the patch tracker. 1. The Change Control Team reviews the status of the application and of recent bug fixes. They request patches for abnormalities found. 2. Only patches for key bug fixes, documentation, packaging, and translations will be taken at this point. 3. Once the Change Control Team is satisfied, they announce that the codebase is Good For Release, and branch the release candidate. (See CreatingDists.) This marks the end of the Hard Freeze phase. === Release Phase === 4. The Release Team creates the distribution source tarball package, and posts the GPG-signed tarball(s). 5. Packagers begin creating the 0.XX.0-1 packages of this release for their platforms. 6. The Release Phase should be treated like a Feature Freeze; everyone can resume committing to CVS, but should limit themselves to bug fixing, in case there are serious issues that will require making a new point release. 7. If issues are discovered during this packaging process, the Change Control Team will review the changes and their fixes and choose: a) Ignore the issue for this release. b) Put up an optional package for packagers to use as needed. The packagers increment their patch-number (i.e. 0.XX.0-1) c) Declare a minor-rev increase (i.e. 0.XX.1). All packages must be regenerated in this case. 8. Once a suitable number of working, tested packages have been posted to the file tracker, the Release Team announces that the codebase is Released. 9. Finally, announcements about the release are made. This also marks the end of the Release Freeze. 10. Normal development resumes. Bryce

3 5

tab -> 4 spaces
by Kees Cook 18 Jul '04

18 Jul '04

Is anyone interested it doing this to the source code? I made a test CVS tree to see how much would be changed. The file count is 565. :) I only processed files in /src, but it would be a giant commit. I personally find in valuable, but worry it would really disrupt other folks. On the other hand, doing it after a release seems like the best time to do it. Thoughts? -- Kees Cook @outflux.net

2 3

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