May 2006 - Inkscape Devel - Inkscape Mailman

Feature Freeze for Inkscape 0.44
by Bryce Harrington 24 May '06

24 May '06

Hi all, This is to announce that we are now officially moving into Feature Freeze. At this time, feature development work on HEAD should cease, in favor of bug fixing work. Any bug fixing work is welcomed. I will be maintaining a list of must-fix bugs, which I will publish within the next day. If you'd like to continue feature development work, you're encouraged to do so on an SVN branch. (If you don't know how to create a branch in SVN, just ask!) ACSpike will publish a -pre0 release ASAP. We will encourage all users to help us test out pre-releases and report issues found. Thank you to all who have been helping Aaron sort out distcheck issues! I would also like to take this chance to thank lucychili for her work at triaging our bug list. There are still some bugs left to be ranked, but due to her work we're close to having them fully ranked. Bryce

1 0

Resize handle on bottom-right of Inkscape window missing
by Michael Wybrow 24 May '06

24 May '06

In recent SVN builds, i.e., the last week or so, the resize handle that was on the far right of the status bar has disappeared. The reason it was added to Inkscpae was that on OSX, every resizable window has a small handle in this position that is above any widgets in the window itself -- meaning the statusbar zoom controls could not be clicked on OSX. It was decided (previously on the mailing list) that we would put our own resize handle here, which shifted the zoom control slightly to the left. I looked at recent commits, but couldn't find where this happened or the relevant code that needs changing. Could someone please add the resize handle back and document in the code the reason for it being there. Thanks, Michael

2 3

default shape style
by bulia byak 24 May '06

24 May '06

In the early days of Inkscape, njh changed the default style of shape tools to include fill-opacity:0.75. The motivation was "to make default shapes more interesting" and "to demonstrate that Inkscape can do opacity". Now, with a master opacity control in the statusbar, the second reason is much less relevant. Besides, we slightly discourage using fill-opacity and stroke-opacity in general, because they are somewhat more cumbersome to change - you can only do it in fill&stroke dialog. For these reasons, I have removed fill-opacity from the default style of the shape tools. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

2 1

another change in defaults
by bulia byak 24 May '06

24 May '06

With all the recent improvements, the Calligraphic tool is becoming much more than just a calligraphic tool - it's now more of a general purpose paint tool. So I changed this tool to use the last set style by default, instead of the fixed black. This means that in a newly installed copy of Inkscape it will paint black, but as soon as you change the fill of anything it will use that new color. I think it makes it more usable for newbies. -- bulia byak Inkscape. Draw Freely. http://www.inkscape.org

4 5

New: Inkscape Stable Branch plans
by Bryce Harrington 23 May '06

23 May '06

Hi all, For the 0.44 release, we will be establishing a stable branch maintenance team, to release 0.44.1, .2, etc. as the 0.45 development proceeds. This is a somewhat different process than we've followed in the past, because while we've done point releases in the past to correct packaging or security flaws, or major bugs, we generally have not treated them as formally maintained branches before. The motivation for doing this is primarily driven by the vast number of new features in this release. It's almost guaranteed that there are hidden defects that we're not likely to find until well after release. Rather than have a very lengthy hard freeze period to find these, as last time, this new process will enable active development and stabilization to be done in parallel. In speaking with Mental and Bulia and some of the other developers, we feel it wise to establish the infrastructure and procedures that will allow us to actively backport fixes for these issues as they're found, so that users won't be forced to wait until 0.45 is released. There is nothing particularly exotic about doing this; many other large projects have split devel/stable branches, and the techniques and best practices are well known and well established: 1. When fixing a critical bug that may need to be backported, make SURE there is a ticket in the bug tracker (create a new one if needed). 2. Create a patch for the bug fix. Do not include any changes other than the fix. Keep the patch as terse as possible (no formatting changes or other cleanup.) Attach the patch to the bug ticket. 3. Notify inkscape-devel@ about the fix, and recommend that it be considered for the Stable Branch. If defect is a potential security issue, please contact the stable maintainer privately. 4. New stable releases with a detailed listing of changes will be produced periodically. It will be recommended that all users upgrade to these releases as soon as possible. We will also establish a Stable Branch Maintenance Team once 0.44 has been released. This team will have the responsibility to keep an eye out for fixes to critical bugs, integrate them into the stable branch, and perform the releases. Mentalguy has been the de factor stable branch maintainer for all of our past releases, and has agreed to be the team lead for the Inkscape 0.44 Stable Branch series. If you would like to be a member of the Stable Branch Maintenance Team, please speak with Mental. I am sure he can make particularly good use of folks with packaging or QA expertise. Of course, we can't say for certain how many stable releases there will be in the 0.44.x series, but I'm anticipating new releases could appear as frequently as every week or two. It will depend largely on how many critical bugs there are, and how many people will be available to handle them. Bryce

1 0

Inkscape and Zero Install
by Thomas Leonard 23 May '06

23 May '06

Hi all, I'm Thomas Leonard, one of the main developers of the ROX desktop[1]. I'd like to make Inkscape the default vector drawing application for ROX. We provide a "ROX-All" package[2] with launchers for a number of programs. Each launcher automatically downloads the program the first time it is run, using Zero Install[3]. Zero Install is also used to fetch any required libraries and to check for updates, etc. I made a launcher for Tgif without any trouble[4], but Inkscape is proving more difficult. The binary RPM on your site seems to use hard-coded paths to get the icons. I looked at the source code to see about fixing it, and I notice that you're already using autopackage's excellent binreloc tool. But, it appears that the RPM was compiled with this turned off! I tried replacing the bin/inkscape file in the RPM with the one from the autopackage and it then worked fine. However, Zero Install can't extract from autopackages because they are implemented as 'executable archives' - extracting them requires running code inside them. This is OK for a program installed on a single-user machine, but Zero Install needs to support multi-user systems where the admin must be able to install a package without having to execute any of its code. [ Aside: The goal of Zero Install is to make installing software system-wide so 'safe' (for the admin) that the admin can actually be replaced by a SetUID script, letting users share software installs automatically without needing an admin and without requiring them to trust each other. This combines ease-of-use and security, rather than trading them off against each other as in most other systems. ] Would it be possible for you to build your binary RPMs with binreloc enabled, so that we can use them? Or, if you could host the "payload.tar.bz2" file from inside the autopackage then that would work too. Actually making Inkscape available is then extremely easy - I'll just create a short XML file giving the available versions, download locations and dependencies, as with the current Tgif XML file[4]. These XML files can be used by ROX (and Xfce) users by simply dragging the link from a web-page to the desktop's installer. They can also be run from the command-line using the '0launch' or '0alias' commands. Thanks, [1] http://rox.sourceforge.net [2] http://rox.sourceforge.net/desktop/ROX-All [3] http://0install.net/ [4] http://0install.net/tests/Tgif.xml -- Dr Thomas Leonard http://rox.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1

4 16

Panel refactoring
by Jon A. Cruz 23 May '06

23 May '06

I just committed a bit of a larger change with much panel rework. The main visible changes are with the palettes. In the swatches dialog it will now remember the last palette selected and restore that on startup. In the docked palette at the bottom of the UI it will separately remember the palette used there (not quite per- document yet). The docked palette will also now shrink when it's "Wrap" menu item is unchecked. It respects the selected size, and places only a single row. In hand with this and the remembering the last palette, someone can probably now change the default preferences to use a small size, turn off wrap, and select the "SVG" palette. Then have the palette shown in the UI by default.

2 1

configure.ac and PKG_CHECK_MODULES (was Re: [Inkscape-devel] distcheck)
by Ben Fowler 23 May '06

23 May '06

On 23/05/06, Ben Fowler <ben.the.mole@...400...> wrote: > On 22/05/06, Aaron Spike <aaron@...749...> wrote: > [ snip ] > > ..., I am working on the basis that you run two > calls to PKG_CHECK_MODULES (instead of picking one). > > Does the second one over-write the results of the first one? > > Does your ./configure really do what you want? For the avoidance of doubt, I am not saying that it is wrong to have two calls to PKG_CHECK_MODULES, and one reason to do this is mentioned here: http://www.openismus.com/documents/linux/using_libraries/using_libraries.sh… Ben

1 0

distcheck
by Aaron Spike 23 May '06

23 May '06

In preparation for the upcoming release, I thought I'd try `make distcheck`. $ make -k distcheck make[1]: *** No rule to make target `make.dep', needed by `distdir'. make[1]: *** No rule to make target `make.files', needed by `distdir'. make[1]: *** No rule to make target `make.ofiles', needed by `distdir'. make[1]: Target `distdir' not remade because of errors. make: *** [distdir] Error 1 make: Target `distcheck' not remade because of errors. I know the solution for this first problem is to run mkfiles.pl and mkdep.pl, but I wonder if those scripts should be thrown into the autogen.sh or configure mix somehow. After I generate those files `make distcheck` produces the errors that can be found at: http://www.ekips.org/comp/inkscape/inx/distcheck/stderr.txt Aaron Spike

3 10

Re: [Inkscape-devel] transparency pdf export
by Martin Owens 22 May '06

22 May '06

All you do is remove the features and downgrade the version, that wouldn't help you because you'd be left with grey or unpainted items in the pdf. On Mon, 22 May 2006 02:54:06 +0200 , Peter Dedecker <Peter.Dedecker@...1292...> wrote: >bulia byak wrote: >> I think that it's much easier and better from all possible viewpoints >> to fix ghostscript/evince/whatever to fully support standard PDF than >> design hideous workarounds for this in Inkscape. > >Off course Evince should support the latest PDF version, but I think it >might be good if Inkscape should also support the previous one without >transparency to maintain compatibility with lots of applications and >printer drivers. But it shouldn't be on a high priority, I think. > >-- >Peter Dedecker Peter.Dedecker@...1292... >Studentenvertegenwoordiger Isabellakaai 124 - 9000 Gent > GSM: 0486/15.23.20 > > >------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, security? >Get stuff done quickly with pre-integrated technology to make your job easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 >_______________________________________________ >Inkscape-devel mailing list >Inkscape-devel(a)lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/inkscape-devel > > -- #::::::::::::::::::::::::::::::::::::# #::.. http://www.doctormo.co.uk/ ..::# #::::::::::::::::::::::::::::::::::::#

1 0