- Inkscape Devel - Inkscape Mailman

Re: [Inkscape-devel] testing for 3D box tool
by Alexandre Prokoudine 11 Dec '07

11 Dec '07

On Dec 10, 2007 11:26 PM, Nemes Ioan Sorin wrote: > Thanks for the link, anyway I use it on a weekly basis -> but no 3d box > tool. Press "X" and start drawing :) Alexandre

2 1

Object to Path broken in 16666
by Thomas Worthington 11 Dec '07

11 Dec '07

Neither polygons nor text will convert to paths for me in revision 16666. It also seems to take a long time to not convert the objects; it's not just returning immediately. Thomas

1 0

Bug status plots
by Bryce Harrington 11 Dec '07

11 Dec '07

Hi all, I mentioned a week or so ago about the bug plots. Here's a reminder of where the plots live: http://people.ubuntu.com/~brian/project-graphs/inkscape/plots/ Of particular note are the New bugs plot, which tells the story of the HUGE work being done by bug triagers. Nearly 20% of our New bugs have been triaged within the past week - quite impressive, and great progress towards our Chill goals: http://people.ubuntu.com/~brian/project-graphs/inkscape/plots/inkscape-week… I also did up a chart of 'open' bugs (total - fixed - invalid - wontfix): http://bryceharrington.org/files/inkscape-week-open.svg http://bryceharrington.org/files/inkscape-month-open.svg Bryce

1 0

today's error in linking
by bulia byak 10 Dec '07

10 Dec '07

rev 16658: libinkpre.a(line-snapper.o): In function `~SnappedLineSegment':/home/d/ink/inkscape/src/snapper.h:41: multiple definition of `Inkscape::SnappedLineSegment::~SnappedLineSegment()' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:35: first defined here libinkpre.a(line-snapper.o): In function `~Snapper':/home/d/ink/inkscape/src/snapped-line.cpp:35: multiple definition of `Inkscape::SnappedLineSegment::~SnappedLineSegment()' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:35: first defined here libinkpre.a(line-snapper.o): In function `~SnappedLine':/home/d/ink/inkscape/src/snapped-line.cpp:81: multiple definition of `Inkscape::SnappedLine::~SnappedLine()' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:81: first defined here libinkpre.a(line-snapper.o): In function `__gnu_cxx::new_allocator<std::_List_node<std::pair<NR::Point, NR::Point> > >::deallocate(std::_List_node<std::pair<NR::Point, NR::Point> >*, unsigned int)':/home/d/ink/inkscape/src/snapper.h:58: multiple definition of `Inkscape::SnappedLine::~SnappedLine()' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:81: first defined here libinkpre.a(line-snapper.o): In function `SnappedLineSegment':/home/d/ink/inkscape/src/snapped-line.cpp:15: multiple definition of `Inkscape::SnappedLineSegment::SnappedLineSegment(NR::Point, double, NR::Point, NR::Point)' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:15: first defined here libinkpre.a(line-snapper.o): In function `SnappedLineSegment':/home/d/ink/inkscape/src/snapped-line.cpp:15: multiple definition of `Inkscape::SnappedLineSegment::SnappedLineSegment(NR::Point, double, NR::Point, NR::Point)' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:15: first defined here libinkpre.a(line-snapper.o): In function `SnappedLine':/home/d/ink/inkscape/src/snapped-line.cpp:62: multiple definition of `Inkscape::SnappedLine::SnappedLine(NR::Point, double, NR::Point, NR::Point)' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:62: first defined here libinkpre.a(line-snapper.o): In function `SnappedLine':/home/d/ink/inkscape/src/snapped-line.cpp:62: multiple definition of `Inkscape::SnappedLine::SnappedLine(NR::Point, double, NR::Point, NR::Point)' libinkpre.a(snapped-line.o):/home/d/ink/inkscape/src/snapped-line.cpp:62: first defined here and so on please fix :) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

3 2

autopackage builds on fedora
by Máirín Duffy 10 Dec '07

10 Dec '07

Hi, It seems the most recent autopackage builds don't work in Fedora. I am wondering why this is and if there is anything I can do to help fix it. Thanks, ~m

4 3

switching SCMs
by MenTaLguY 10 Dec '07

10 Dec '07

While I'm obviously a fan of git, I have to ask: what would our driver be for switching SCMs at this point? - It's not QRM, since that can be done with SVN - It's not getting off of Sourceforge, since we could host our own SVN - It's not being able to use DSCM, since Kees and I (at least) do so today The main thing I can think of would be getting better merge tracking, since Subversion has the worst merge tracking of any SCM I've ever used (even worse than CVS). Rather than continuing this discussion for now (which I'm starting to feel is taking attention away from the release), let's install the latest versions of Bazaar, Mercurial, and Git on the inkscape.org machine, set up live mirrors of _full_ Subversion[1][2] in each DSCM, and let people play with them. Then we can pick up the thread again in, say, six months or so. -mental --- [1] The current git mirror is only partial because git-svn sucked at the time I set it up; it has since improved substantially and I've been thinking of redoing the mirror anyway. [2] If the Launchpad mirror has the full history back to r1, including branches, then the Bazaar part is already done for us. Otherwise I'd like to set up our own full Bazaar mirror.

3 2

transform scale proportional default
by miles 10 Dec '07

10 Dec '07

In the transform dialog scale tab, the proportional check box is defaulted off. Everytime I use this I have to check it on since every graphic I make is scaled proportionally - would there be any agreement to change this to have it defaulted on ?

4 3

2geom Makefile targets doubled up
by Aaron Spike 10 Dec '07

10 Dec '07

I've been casually investigating the doubling of the 2geom targets in src/Makefile on and off over the last months. I could find absolutely no reason for it and I continue to me mostly bewildered by our autotools system. Tonight just for kicks, after another long period of fruitless investigation, I decided to rename the src/2geom directory to src/lib2geom to match our other internal libraries (I also updated the references in the Makefile stuff). The doubling went away. I wonder if we aren't somehow misunderstanding the magical automake variable naming convention. The src/Makefile seems to be ordered roughly by directories alphabetically, digits sorted after letters. The 2geom targets appear in the order in the following places: 1) extension, libcroco, libgdl, 2geom, application, debug, dialog and 2) ui, util, widgets, xml, 2geom. Seems like it appears in the alphabetical location for lib2geom and also in the location for 2geom. I don't know if it has any meaning but in both locations it is immediately preceded by generic targets: .cpp.o/.cpp.obj and .cxx.o/.cxx.obj respectively. Do these tidbits trigger anything in anyone's mind? Aaron Spike

2 1

Item transformations
by Maximilian Albert 08 Dec '07

08 Dec '07

Hi all, I'd like to consult this omniscient list for a tiny bit of further information. :) The last thing I need to get to work right before I can merge my code into SVN is transformations for 3D boxes (haven't really gotten to touch them so far). Actually, I thought they shouldn't be hard to understand but I find myself fiddling with them and the things that happen are slightly different from what I expect. Would anyone mind giving me some hints as to what happens / should happen in an item's transform method? As I understand it, the transformation matrix is passed in, but what exactly is coded in this matrix? It looks like an affine transformation, but which point is considered the origin? If I simply multiply some corner, say, with this matrix then the image is off by a certain translation. Is this the translation occurring in the matrix? Where does it come from? Should I simply discard it (as seems to be done for sp_rect)? Or how else can I extract the information I need? Unfortunately I can't simply copy the code from sp-rect.cpp because the boxes are internally stored in a more complicated way than rectangles. Thanks in advance, Max P.S.: Upon re-reading this email some ideas of how it could work are forming in my mind but right now I'm too tired to test them. I'm going to get me some hours of sleep and try again, but if anyone has any hints in the meantime I'd still be grateful. ;)

2 1

Broken on gcc 4.0.1
by Jon A. Cruz 08 Dec '07

08 Dec '07

On OS X using gcc 4.0.1 the latest SVN breaks with template issues ./ui/dialog/panel-dialog.h:124: error: template-id 'create<>' for 'Inkscape::UI::Dialog::PanelDialog<Inkscape::UI::Dialog::Behavior::Float ingBehavior>* Inkscape::UI::Dialog::PanelDialog<Inkscape::UI::Dialog::Behavior::Floati ngBehavior>::create()' does not match any template declaration I tried to look into this, but haven't found a fix so far.

3 4

Default units
by Guillermo Espertino 08 Dec '07

08 Dec '07

After realizing that there was something strange about the text size in my inkscape designs I followed the bugs associated (#168151, #168164, #168344, #170099 - some of them seem to be duplicates) and there I noticed that the text size in inkscape is expressed in pixels, but the dialog doesn't inform that. In fact, there's no way to set the font size to other units but the XML editor (and as far as I could see, it doesn't work either). In every vector illustration program the font size is expressed (by default) in points because one of the common outputs for the illustrations is print. Vector illustration programs are usually the most adecuate option to create flyers, simple brochures, logos, etc, so the use of real units is needed for type. In graphic design the default units for type are points (there are different measures for typographic points but in DTP 1 pt = 1/72"). Having typography in pixels is a big headache for graphic designers, mostly because the "12" value set by default is used as the default value en other design programs, but points, not pixels. Even office programs use points as default type units, so the common user will be expecting points and not pixels. In my opinion, the way that inkscape manages units is fine, but an option for setting the default units globally is needed. Currently, you have pixels everywhere and you have to change every time and everywhere to real units if you need to use them. That sucks and is a tedious and time consuming task (prone to errors too). It's a consistency issue too. The default inkscape artwork size is a DIN A4 size page, which is a phisical, real measure. If I have a "real" page as a container, I would expect to use real units as measures, but it's mixed up. Vector graphics are used to create elements that can be scaled without having to worry about the pixel size, so using pixels as default units doesn't make sense (imho). I'm not saying: change px for pt or mm. Of course if I have to create a website mockup I'll use pixels and not milimeters. Every choice is useful in different scenarios, but they need to be streamlined to make the options consistent with the needed workflow. I think that adding a simple category "units" in the preferences should fix the problem. Having the ability to choose the units globally for objects and type will allow users to adapt inkscape to their specific needs and will bring more consistency to the UI. What do you think about this? Regards, Gez.

4 8

Patch to dump id,x,y,w,h for all objects
by Terry Brown 08 Dec '07

08 Dec '07

I hope this can make it in to 0.46, as I think my slide making utility which needs this functionality could be quite useful, and it would help the re-stacking effect too. How should patches be submitted now? Launchpad blueprints? It wasn't immediately obvious how to use them, so I made this bug instead: https://bugs.launchpad.net/inkscape/+bug/174701 This is the patch to add the command line switch --query-all which dumps id,x,y,w,h for all objects with an Id. I sent a version just to Bulia by mistake, meant to send it to the whole list, anyway the version on launchpad corrects the transposition of x,y with w,h in the version I sent Bulia :-} Cheers -Terry [Nicu - thanks for your pointers about the ill conceived post to the users list, points well taken.]

2 3

Launchpad blueprints
by Bryce Harrington 07 Dec '07

07 Dec '07

The question about Launchpad's blueprints (specification) system came up today, so I'd like to open a broader discussion about if we want to start using it. Basically the blueprints system is a mechanism for tracking specification status. You can also include a link to a web page (such as a wiki or even a pdf) where the spec is written up. For Canonical it's used as a workflow system so people can keep track of the state (needs review, in progress, implemented, finished, etc. etc.) of various development efforts. Blueprints can also be prioritized, like we used to do with RFEs, and linked to bug reports. There's also a review/approval mechanism, which (in theory) is used by management to green light projects for engineers to work on for a release. The reason I've not brought this up before, is because I recognize it doesn't match to the workflow we use in Inkscape. Aside from the Roadmap, we don't really try to keep close tabs on individual developer's work; we're (largely) a volunteer project, so part of me worries such a system could just be extraneous overhead. However, I can definitely see the usefulness of this if enough of us were using it. First, the process of writing up a blueprint is good discipline for getting ones thoughts and plans in order at the start of a development project. It's also a good communication tool for letting fellow developers know what the plan is and to gain review feedback on your ideas. And it would certainly make release time go a bit smoother, since we'd be able to query and see the state of all development efforts (or at least those using the blueprint system). Potentially we could also subsume the (admittedly poorly maintained) roadmap into it. Obviously, this also is obviously analogous to (and clearly synergistic with) GSoC's proposal write ups, which seems to work out quite well. A more tangible benefit (and the reason I bring it up now), is that we have a lot of RFE's in our bug tracker that we could move over into blueprints. This would reduce our bug count, increase the visibility of the feature requests, and give us better tools for collaborative editing and tracking the proposals. We've already had a couple (brief) blueprints posted: https://blueprints.launchpad.net/inkscape/ Here's a couple examples of more fully fledged blueprints (look esp. at the wiki links): https://wiki.ubuntu.com/DisplayConfigGTK https://wiki.ubuntu.com/DesktopTeam/Specs/ExitStrategy Please give a look at these and consider if this is something we could benefit from with Inkscape. Should we as a project encourage using this part of Launchpad for handling feature requests? Bryce

2 1

Again display updates of SPGroups and their children
by Maximilian Albert 07 Dec '07

07 Dec '07

Hi all, I've asked this before but unfortunately I haven't been able to fix it yet. My rewritten 3D box class inherits from SPGroup. Each box has six children of type Box3DSide, each of which is inherited from SPPolygon. So far so good. The problem is that I can't figure out what functions I need to call in sp_3dbox_update so that the boxes are correctly updated on screen during handle dragging (but without writing to repr for efficiency). My most promising-looking approaches so far have been: 1) Call sp_shape_set_shape() for each of the sides (where the corresponding curve is drawn). However, this does not have any visible effect during dragging (the box is shown only when sp_box3d_write() is called). 2) Call requestDisplayUpdate() for each of the sides. This is obviously wrong since it triggers an update while another one is being processed. Consequently, Inkscape issues a corresponding warning on the command line. But at least with this approach the box is correctly updated on screen. 3) Not register sp_3dbox_update() at all in sp_3dbox_class_init(). This was a last desperate attempt because I figured that perhaps the parent SPGroup would take care of udating the children. But it turned out that in this case the update methods of the sides are not even called. So there should be something in between 1) and 2) which correctly updates the screen but doesn't issue the "update already in progress" warning. Any ideas? I'm completely lost in my maze of attempts and would appreciate any hints what else I could try or where to look further. Thanks! Max

3 6

0.46 release plan proposal
by Bryce Harrington 07 Dec '07

07 Dec '07

Hi all, Now that GSoC projects are finished and the code has had time to stabilize, it seems a good time to get the 0.46 release moving ahead. With Gutsy released, I finally have some time to contribute towards Inkscape release work, and will help try to get efforts organized. I'd like to propose the following release plan, based roughly on the 0.45 plan. Let me know if there's anything missing. 1. Open development. 2. Chill. Development focuses on wrapping up. Identify 'make distcheck' issues Triage bug reports Run an About Screen contest First draft of Release Notes. Update tutorials and other docs 3. Frost. Most development complete. Release Notes should be >90% filled in. Bug Hunt: 500 points Post inkscape-0.46-alpha.tar.gz 4. Feature Freeze. No further development work. Disable features that can't be finished in time Focus on critical bug fixing. Finalize all tutorials, docs, etc. Finalize all extensions Translators create translations. Inkscape must pass 'make distcheck' Post inkscape-0.46-beta.tar.gz 5. Hard freeze. Only release wardens can commit to mainline. No further string changes Focus on release-critical bug fixing. Finalize translations, release notes, etc. Packagers test creating pkgs of the -beta release Post inkscape-0.46-rc1.tar.gz 6. Branch. Establish the Stable Branch for release Complete any late-late-late work. Final verification of packaging, release notes, docs, etc. Publish more release candidates until ready for release. Plan 0.46.1+ release(s), if needed 7. Release. Post inkscape-0.46.tar.gz Post packages Post official announcements 8. Open development. I'm sort of thinking for this release we ought to plan on establishing a stable branch much earlier than we've done before, and maintain split devel / stable branches for a bit (maybe a couple months). I think that'd allow us to spend much more time than usual getting things release-worthy, without too heavily impacting people who wish to keep doing development work. We'll have a bunch of interesting random tasks (mostly non-coding) to do to get the release polished up and ready to go. Are you interested in participating in the release team? Let me know! Bryce

10 20

Entry fields for editing of node coordinates
by Maximilian Albert 06 Dec '07

06 Dec '07

Hi all, as I've learned in the past few days, investigating or fixing other things while waiting for tedious compiles to finish can be quite productive. :) [1] In revision #16617 I added two spin buttons to the toolbar of the node tool which allow exact editing of node coordinates (this was long overdue - see bugs #170116 and #172113). Please test and report any irregularities. ;-) One thing to note is that originally I had planned to clear the entry fields when two or more nodes are selected. But I didn't know how to do this (is it possible at all?), so I decided to go for a quick hack and display the coordinates of the center of the bounding box instead. This turned out to be quite nice because it allows one to quickly align several nodes in the following way: Select them, press Alt+x (which switches focus to the coordinate entry fields) and press enter. Since the first entry field already shows a new X coordinate (lying in the middle between the extremal nodes), this aligns all the nodes vertically to this coordinate. Although at first it was a kind of stopgap solution I now really like the concept. Unfortunately, this "feature" is not really usable by keyboard alone yet because if you want to align the Y coordinates, you need to press Alt+x and then Tab in order to get to the second entry. But since the first one (for the X coordinates) already shows a new value, pressing tab sets the X coordinates to this value, no matter if this is desired or not. Suggestions for possible solutions are welcome. To summarize, the options I can think of are: - clear the entries if more than one node is selected, or - somehow prevent the nodes' coordinates from being changed while tabbing between the entries both of which I don't know how to do. :-/ Thanks for any hints and suggestions, Max P.S.: I'm going to add this to the Release Notes tomorrow. I'm just too tired right now to find good phrasings in English. ;) [1] Aside: Especially when using a distributed version control system like git so that you can work on several things at once. It's such a pleasure compared to svn! I can only heartily recommend people to use it (or rather git-svn in our case because we need to be able to commit to the repository, of course).

3 4

Collaborate
by Daniel Garcia Moreno 05 Dec '07

05 Dec '07

Hello, first of all, thanks, I use inkscape since some years, and I love it, thaks for this excellent tools that you are making, it's amazing. I'm a programmer and I want to collaborate in this project. I am looking for a list of bugs, for write some patch, look the code and learn about the code. If you could tell me some easy bug to fix, I can write some code.

3 2

using LPEs
by Steren Giannini 05 Dec '07

05 Dec '07

hello, I made recently my first draw using Live Path Effects. (see http://pannini.lesgeorges.org/media/couv_web.png) And I can tell : they are very powerful ! I wrote the main points that need to be corrected or at least discussed. I know LPEs are not finished yet, but I want to be sure that those points are taken into account. - I had a problem when I wanted to copy a path with a pattern along path applied : the "pattern source" is not copied but the two paths share the same "pattern source". If I want to modify the pattern source of my copy and not disturb the first one, I can't. To my opinion, this is really something to change. - The same problem for the "bend path" effect - In the last SVN, when you translate a object with a "bend path" effect, it translate well. But I really think that when rotating or scaling such kind of object, it should do the same : rotate and scale the "visual object" (maybe by rotating or scaling the "source path" too) - scaling or flipping an object with a pattern along path effect applied : the source path is modified but not the "pattern source" => the "visual object" shape is not the same than before the transformation. ( see : http://pannini.lesgeorges.org/media/flip_prob1.png) Steren

3 3

Redo problem, element created without "id" attrib
by unknown＠example.com 05 Dec '07

05 Dec '07

Hi all, I have a problem that I do not know how to fix. When a grid is created and then Undo is pressed, things work great. However, then "redo" crashes inkscape (when grid tab of document properties is open). This is because of the following reason: when redo is done, a new child is added to sodipodi:namedview, this triggers updating of the documentproperties gridpage. However, at that time, the "id" attribute of the child has not been set yet. (I don't know at what time it is set, but sp_namedview_child_added is called with a child that has no 'id' attribute! This attribute is needed, because it provides the grid's name to put in the tab in the dialog. I'd like to know how I should solve this (i.e. obtaining the 'id' attribute when a 'redo' action is performed). Thanks! Johan

1 0

new stock patterns and screenshot
by bulia byak 04 Dec '07

04 Dec '07

I added a few basic stock patterns and made a screenshot: http://www.inkscape.org/screenshots/gallery/inkscape-0.46-stockpatterns.png enjoy :) -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

1 0

NEW: Grid visibility and snap enabling
by unknown＠example.com 04 Dec '07

04 Dec '07

Hi all, I just added two checkboxes to the grid settings: * Visibility and snap enabled. ** Visibility turns of display of the grid, which I find useful from time to time because snapping is still enabled for invisible grids. To disable snapping (when having multiple grids, this is essential), one should use 'snap enabled' ** "Snap enabled" does not yet work. I hope Diederik can implement this soon, I think it should not be too hard? * I hope to get the axonometric grid working soon, I need it at work! :-) * I am aware of the bugs in setting grid parameters. Hopefully I can find the cause soon, it is annoying me aswell. Cheers, Johan

7 13

Launchpad Tips & Tricks: Upstream Bugs
by Bryce Harrington 04 Dec '07

04 Dec '07

Being able to track upstream bugs is (IMHO) one of the best features of Launchpad from Inkscape's perspective. Let's take a look at how this works: First, we find a bug that is really an upstream issue. Here we go: Main window disabled if a modal dialog sinks https://bugs.launchpad.net/inkscape/+bug/168301 This is related to the infamous "dialogs not on top with Win32" problem that we know stems from Gtk, but with an unfortunate twist - if the application is minimized and you right click "close", you never see the dialog, but since the dialog is modal, you can't restore it! Feh Win32! Actually, it's a Gtk problem. So next we go to the gtk bug tracker. >From gtk.org I clicked on "Bug tracker", then went to bugzilla.gnome.org. I find the search box and enter "windows dialogs". Browsing through the list I spot this one: Bug 169965 -- transient dialogs with minimized parent http://bugzilla.gnome.org/show_bug.cgi?id=169965 [Note, all gtk bugs are also imported into Launchpad at https://bugs.launchpad.net/gtk/, which would probably be easier to search...] Reading the bug, it looks like this describes our issue. Unfortunately, the bug hasn't received much activity over the past year (we'll address this in a bit), but at least it's known... Now go back to our Launchpad bug: * Look at "Also affects: +Project... +Distribution/Package..." * Click on "+Project" * Type in "gtk" and hit Continue * For the URL, cut and paste the bugzilla.gnome.org bug URL there * Click "Add to Bug Report" Now our bug report shows the link to the upstream bug. Periodically (once a day I think), Launchpad will spider bugzilla.gnome.org and grab any status changes to the upstream bug report and notify us if the status changes. So in the future when people look at this bug, they'll be able to immediately see if/when it's fixed upstream. We're not done yet though! Let's be good citizens and let upstream know we also experience this problem. I log into my bugzilla.gnome.org account, and add a comment to the above bug: "I think we're also experiencing this bug with Inkscape on Windows. A user reports... https://bugs.launchpad.net/inkscape/+bug/168301 [Pasted copy of original report from our end] Has anyone had a chance to look into this?" This will both ping upstream about the issue (hopefully raising its importance, maybe triggering them to update the bug report if it's already fixed, or a dupe), and give the extra info to help debug it. If we had failed to find a matching bug upstream, we should report a new one. If you're unsure, it's sometimes better to report a new one and let them dupe, than to incorrectly attach our bug to a wrong report, but use best judgement there. Now go to https://bugs.launchpad.net/inkscape/ and look for the link "0 bugs fixed elsewhere". When our upstream bug gets fixed, this link will change to "1 bug fixed elsewhere", which will let us see the bugs fixed by our upstreams. :-) Notice the URL for this search says "...=resolved_upstream". If we change this to "open_upstream", we can see the bug we just linked: https://bugs.launchpad.net/inkscape/+bugs?field.status_upstream=open_upstre… Some Homework: In my gtk bugzilla searches, I ran across a couple related bugs, which sound similar to other issues we have in Inkscape. See if you can find our matching reports, and link them up: Bug 164537 -- Non-modal transient dialogs should iconify with parent http://bugzilla.gnome.org/show_bug.cgi?id=164537 Bug 171456 -- "Keep Above" option in Gimp broken on Win32 http://bugzilla.gnome.org/show_bug.cgi?id=171456 Bryce

1 0

Inkscape bugs status
by Bryce Harrington 03 Dec '07

03 Dec '07

1 0

Launchpad Tips & Tricks: Duping Bugs
by Bryce Harrington 03 Dec '07

03 Dec '07

It's good to see all the people giving Launchpad a try, and discovering both its cool bits and some frustrating bits. For those who are finding some irritations, please give it some time - when I first started using it, I also found the interface to be unintuitive in places; I'm hoping the tips and tricks I'm posting will help. Here's half a dozen tips related to bug duping: 1. Adib asked about how to dupe bugs. This falls into the cool feature category, but the links may not be where you expect. When viewing a bug, "Mark as duplicate" is in the Actions list on the left. From there, you can indicate the bug id number that this is a duplicate of. 2. The bug report will clearly tell you that there are dupes of a given bug, or that the bug is a dupe of such-and-such other bug. For bugs with dupes, there is also a listing of its dupes - this can be found on the left column in an expando-box titled "Duplicates of this Bug". 3. When a bug is marked as a dupe, it no longer shows up in searches, which is nice. But you can still get to it either directly by ID, or via the link in the parent bug. 4. People who were subscribed to the dupe bug will now receive the update notifications from the parent bug. This is usually useful, but keep it in mind if commenting on a bug with a large number of dupes that you're not spamming everyone with trivialities. 5. Note that it's not possible to mark a bug a dupe if it also has dupes attached to it. You have to individually move the dupes to the parent. Sort of annoying, but it's rare when you need to do this. 6. When closing a bug that has dupes, it's good practice to review each of the dupes and check that the solution definitely does account for all those reported problems. I was at first annoyed to find endless duplicate reports of bugs, as it seemed like a waste of effort that could be avoided if the reporter searched the existing bugs. However I've since changed my mind, for a few reasons. First, (at least for xorg) most users don't have enough knowledge to really know for certain that their problem matches someone else's, so it usually requires an expert to verify that the issue really is a dupe. Second, from a workflow perspective, finding/marking dupes is much more straightforward than trying to untangle a bug report that contains multiple unrelated issues in it. Third, a bug report with a lot of dupes typically ends up being easier to gain a fix than one with no dupes - both because it emphasizes the importance of the bug, and because the "many eyes" effect starts kicking in, and people subbed to the bug through dupes can start sharing ideas and findings with each other. So, I generally encourage tell reporters, "If you're concerned that your bug report might be a dupe but you're not sure, report it as a separate bug, and just say in your report 'might be related to bug xyz'". This saves the bug triager time of tracking down potential matches but still lets your issue be handled even if it's unrelated. Bryce

1 0

Inkscape native on OSX - try 2
by jiho 03 Dec '07

03 Dec '07

Hi everyone, I've been trying to get Inkscape to compile against the new version of GTK on OS X, with the "quartz" option enabled (i.e. without X11). The good news is that it compiles and that MacPorts provides a way to work with both native and X11 versions of GTK quite easily (which means one does not have to remove and recompile everything one way or another every time). The bad new is that, though Inkscape starts without X11 and that the GUI is shown, it crashes with this error message: ** (inkscape:9060): CRITICAL **: const GSList* sp_document_get_resource_list(SPDocument*, const gchar*): assertion `document != NULL' failed ** (inkscape:9060): CRITICAL **: const GSList* sp_document_get_resource_list(SPDocument*, const gchar*): assertion `document != NULL' failed Emergency save activated! Emergency save completed. Inkscape will close now. If you can reproduce this crash, please file a bug at www.inkscape.org with a detailed description of the steps leading to the crash, so we can fix it. (inkscape:9060): GLib-WARNING **: g_main_loop_run(): called recursively from within a source's check() or prepare() member, iteration not possible. Any idea from where than may be coming from? It doe not occur with the X11 version so that's probably related to GTK/Cairo/Pango/Poppler being freed from X11. However, the GUI shows and the messages don't seem directly display-related. Is that a GTK bug in your opinion? Backtrace below: Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_PROTECTION_FAILURE at address: 0x00000020 0x90a594c0 in objc_msgSend () (gdb) bt #0 0x90a594c0 in objc_msgSend () #1 0x19b19130 in ?? () #2 0x9082dd0e in __CFRunLoopDoObservers () #3 0x9082cdb0 in CFRunLoopRunSpecific () #4 0x9082ca6e in CFRunLoopRunInMode () #5 0x92def878 in RunCurrentEventLoopInMode () #6 0x92deeeb9 in ReceiveNextEventCommon () #7 0x92deedd9 in BlockUntilNextEventMatchingListInMode () #8 0x93295485 in _DPSNextEvent () #9 0x93295076 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] () #10 0x00daadb6 in gdk_event_prepare () #11 0x02177de4 in g_main_context_prepare () #12 0x021784a6 in g_main_context_iterate () #13 0x02178bbd in g_main_loop_run () #14 0x01ca8a87 in gtk_main () #15 0x0184d888 in Gtk::Main::run () #16 0x00003ff1 in sp_main_gui () #17 0x00167234 in Inkscape::NSApplication::Application::run () #18 0x00002ef7 in main () JiHO --- http://jo.irisson.free.fr/

4 6