- Inkscape Devel - Inkscape Mailman

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