- Inkscape Devel - Inkscape Mailman

Fwd: [Bug 238796] Re: Display mode toggle needs update to all 3 modes
by the Adib 17 Sep '09

17 Sep '09

Again, pls. review and commit the patch. Thx, Adib. Is there any new TODO list for the 0.47 release? ---------- Forwarded message ---------- From: theAdib <theAdib@...1439...> Date: Sun, Sep 13, 2009 at 2:25 AM Subject: [Bug 238796] Re: Display mode toggle needs update to all 3 modes To: theAdib@...1439... attached patch cycles through all 3 display modes normal->without filters->outline pls test. HTH, Adib. ** Changed in: inkscape Status: Confirmed => In Progress ** Changed in: inkscape Assignee: MenTaLguY (mental) => theAdib (theadib) ** Attachment added: "BUG238796_display_toggle.patch" http://launchpadlibrarian.net/31734073/BUG238796_display_toggle.patch -- Display mode toggle needs update to all 3 modes https://bugs.launchpad.net/bugs/238796 You received this bug notification because you are a bug assignee.

10 19

Re: [Inkscape-devel] DVCS Discussion & Vote
by JiHO 16 Sep '09

16 Sep '09

> > Tidying history is helpful. It enables people to go off on > > experimental tangent branches knowing that they can bring order out of > > chaos when they're ready. It also means that we don't have to have > > patches merged that break inkscape. It's good to keep a clean history, > > and you can use bisect to find problems in that case. > > Uhm, I don't see how changing the number of revisions would effect how > the patch applies in any case. Neither would which changing which > revision the branch started on. I don't think Max was saying that, when you are on a personal branch, you might commit something that you later discover breaks Inkscape. Git allows you to reorganize/rework your commits before they are pushed, so that each of your commits leaves Inkscape working. That way, when you merge back in trunk, all revisions are valid. This seemed like the goal of the svn trunk at some point: always have the development version working because some people use that for actual work. > I assure you that I go on experimental tangent branches regularly, > that's simply the kind of person that I am. The histories there are > still important even though you'd never see them unless you started > really delving into the revision history to see each commit. When I > merge it into main is when I write a more useful message about what > really changed, as most people only look at the history of trunk anyway. I am not sure whether this is specific to git or a general behaviour, but in git, when you merge back a branch, you see its full history in the trunk, not just the merge commit. For example, let say your history is something like (best viewed with a fixed width font): master: A--B-------C-------D-- \ / branch: \--A'---B'--/ A,B,C are commits on the master (=trunk); A',B' are commits on the branch; D is your merge commit. After the merge, "git log" on the trunk will show: D B' C A' B A You get all the commits, in chronological order, *including* those on the branch. So you don't "only look at the history of the trunk". Of course git keeps a memory of what was on the branch and what was on the master but you still see everything from the master. This is a reason why it is sometimes interesting to rework your branch history before a merge. I don't know whether this is a feature or a drawback, but this is the way (I think) it works. JiHO --- http://maururu.net

3 3

Re: [Inkscape-devel] DVCS Discussion & Vote
by Ted Gould 16 Sep '09

16 Sep '09

On Wed, 2009-09-16 at 08:27 -0500, Aaron Spike wrote: > Ted Gould wrote: > > On Tue, 2009-09-15 at 21:31 -0400, bulia byak wrote: > >> Instead of a vote, I have a question: Ted, what was the piece of > >> software with which you did that horrendous hole in our SVN history, > >> erasing many past revisions of many files? Was it bzr? If so how can > >> we be sure this never happens again? Sorry to bring it up again but I > >> run into this "black hole" quite often when I do research in our code > >> and it's really a sore spot. > > > > It was bzr-svn. > > I thought we had seen problems with SVK. Hadn't heard about bzr-svn > problems. It does make quite a bit of sense that DVCS -> VCS would be a > lossy operation. Another reason to switch. We had some problems with the way that SVK does things as well. But, that wasn't the issue that Bulia was referring to :) I was able to work with the bzr-svn developers to get the necessary fixes in so that it would import the Inkscape repository even with the SVK-isms in it. --Ted

1 0

Re: [Inkscape-devel] SPAM-LOW: Re: DVCS Discussion & Vote
by Ted Gould 15 Sep '09

15 Sep '09

On Tue, 2009-09-15 at 05:12 -0700, joel@...1709... wrote: > > > You can do most of that with the bzr-rebase plugin, but I'd > recommend > > against it. Honestly, the only reason I've seen to reorder commits > is > > to lie and say you never make mistakes, or to clean up a > visualization > > to make it look better. I don't think either of those are good > reasons > > to "change history." I'm kinda a historian on that point, it seems > like > > history is history -- leave it alone :) > > Tidying history is helpful. It enables people to go off on > experimental tangent branches knowing that they can bring order out of > chaos when they're ready. It also means that we don't have to have > patches merged that break inkscape. It's good to keep a clean history, > and you can use bisect to find problems in that case. Uhm, I don't see how changing the number of revisions would effect how the patch applies in any case. Neither would which changing which revision the branch started on. I assure you that I go on experimental tangent branches regularly, that's simply the kind of person that I am. The histories there are still important even though you'd never see them unless you started really delving into the revision history to see each commit. When I merge it into main is when I write a more useful message about what really changed, as most people only look at the history of trunk anyway. --Ted

1 0

Re: [Inkscape-devel] Inkscape-devel Digest, Vol 40, Issue 22
by Ashmi Shah 14 Sep '09

14 Sep '09

I did my research. I stand corrected. The new operating system from Microsoft after Vista is not called System 7. They call it Windows 7. We are very interested in learning whether InkScape and GIMP will provide appropriate vector and raster information to our Windows compatible printer type driver for job processing on different types of machines. Thanks in advance. Ashmi Solustan, Inc. On Mon, Sep 14, 2009 at 4:43 AM, < inkscape-devel-request(a)lists.sourceforge.net> wrote: > Send Inkscape-devel mailing list submissions to > inkscape-devel(a)lists.sourceforge.net > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/inkscape-devel > or, via email, send a message with subject or body 'help' to > inkscape-devel-request(a)lists.sourceforge.net > > You can reach the person managing the list at > inkscape-devel-owner(a)lists.sourceforge.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Inkscape-devel digest..." > > > Today's Topics: > > 1. Re: Since release is nearing, let's talk 0.48 and beyond... > (Alexandre Prokoudine) > 2. Re: Since release is nearing, let's talk 0.48 and beyond... > (Joshua A. Andler) > 3. Re: *sigh* icons (Jon A. Cruz) > 4. Re: *sigh* icons (Alexandre Prokoudine) > 5. Re: Since release is nearing, let's talk 0.48 and beyond... > (Valerie) > 6. Re: Does inkscape use windows GDI for printing? (Tobias Jakobs) > 7. Re: *sigh* icons (Jon A. Cruz) > 8. Re: Current TODO for 0.47 discussion (~suv) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 14 Sep 2009 10:45:08 +0400 > From: Alexandre Prokoudine <alexandre.prokoudine@...400...> > Subject: Re: [Inkscape-devel] Since release is nearing, let's talk > 0.48 and beyond... > To: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> > Message-ID: > <733f2c730909132345s5f7695a4wa054b2a0fb2bbda9@...401...> > Content-Type: text/plain; charset=ISO-8859-1 > > On Mon, Sep 14, 2009 at 10:38 AM, Joshua A. Andler wrote: > > > The point releases have a place... we should have had a couple for 0.46 > > honestly. If you would like to point fingers, I am willing to take the > > blame for it as I was a release warden for it and for this release. > > No fingers, no blame. The long 0.46/0.47 development cycles got quite > a few important contributors burnt out. We need to learn to deal with > it, IMO. > > > P.S. Move continents all you want Alexandre, I'll nag you wherever you > > go. ;) > > That goes without saying :) > > P.S. Thank you for posting 0.47 screenshots btw! > > Alexandre > > > > ------------------------------ > > Message: 2 > Date: Sun, 13 Sep 2009 23:49:24 -0700 > From: "Joshua A. Andler" <scislac@...400...> > Subject: Re: [Inkscape-devel] Since release is nearing, let's talk > 0.48 and beyond... > To: Krzysztof Kosi?ski <tweenk.pl@...400...> > Cc: inkscape-devel(a)lists.sourceforge.net, bulia byak > <buliabyak@...400...> > Message-ID: <1252910964.4270.114.camel@...2139...> > Content-Type: text/plain; charset="UTF-8" > > On Sun, 2009-09-13 at 18:08 -0700, Krzysztof Kosi?ski wrote: > > I vote for bzr > > Noted > > > > Additionally, if we could get cairo work in a > > > branch (under said DVCS) during this cycle, it would be excellent to > > > possibly get something to drop in for the 0.49 dev cycle > > Is there any plan on how we're going to do this? Do we write a new C++ > > library that is similar to libnr but nicer to work with and uses Cairo > and > > 2Geom internally, or rip out rendering code from libnr and replace it > with > > Cairo operations? > > bulia, can you please comment on what you think would be the best course > of action given your experiments/testing? I know you've been going it > along in this department for quite a while which is why I proposed > getting a branch going... I'm sure others would love to help make it > happen. > > Cheers, > Josh > > > > > ------------------------------ > > Message: 3 > Date: Mon, 14 Sep 2009 00:01:19 -0700 > From: "Jon A. Cruz" <jon@...18...> > Subject: Re: [Inkscape-devel] *sigh* icons > To: Alexandre Prokoudine <alexandre.prokoudine@...400...> > Cc: Inkscape Devel List <inkscape-devel(a)lists.sourceforge.net> > Message-ID: <D546B4A6-63EB-4C61-8B72-5B06258E73F6@...18...> > Content-Type: text/plain; charset="us-ascii" > > > On Sep 13, 2009, at 11:38 PM, Alexandre Prokoudine wrote: > > > On Mon, Sep 14, 2009 at 10:04 AM, Ted Gould wrote: > > > >> The icon specification provides for things like fall back icons and > >> for > >> icon themes providing their own set of fallbacks. So most icon > >> themes > >> that ship today are actually a base set, with a fallback to a more > >> complete set that is similar. Also, many applications ship with a > >> default set of icons that the theme can override. Sure, in those > >> cases > >> GIMP and Inkscape wouldn't match, but that's no worse than we have > >> today. > > > > But what we have *today* is Inkscape *always* using its default > > theme :) > > > > No. > > If external icons with the given names are present in the directory > set, then those will override the internal ones. >

1 0

*sigh* icons
by Alexandre Prokoudine 14 Sep '09

14 Sep '09

Hi, Could anybody please explain how one could get Tango icons back? The last thing I heard is that one should be using Tango icons on system level to get them in Inkscape. Well, I switched to Tango theme in GNOME prefs and I still see the default icon theme. I don't mean to ask for a new feature this close to releasing, but for future - just how difficult would it be to add a simple switcher in Preferences and get rid of this brain damage forever? :) Alexandre

4 8

Does inkscape use windows GDI for printing?
by Ashmi Shah 14 Sep '09

14 Sep '09

(1) Our company builds Windows compatible user level drivers for XP, Vista, and System 7 versions. These drivers accepts vector information from programs like Corel Draw and control the following: - Engraving machines - CNC milling machines - Vinyl cutting machines - Generates G codes for most popular CNC controllers -Torch cutting machines - Waterjet cutting machines - CO2 laser cutting and rastering machines Basically, we convert vectors to motion control commands in many different ways. Also, we could similarly use GIMP to accept the information and generate raster control commands for laser machines. Generally, programs like Corel Draw, AutoCAD, Illustrator, and others work with Windows GDI architecture. GDI passes the vector and raster information to our driver and we control machines. The potential is literally thousands of copies of Inkscape and GIMP all over the world. We need to unfill all the shapes, designs, and text in Corel Draw, for example, and make sure that the line widths are hairline (0.001 inch, I believe). The definition of hairline varies with different programs. However, it should be such that GDI is told to interpret the information as vectors. Can our users use Inkscape and GIMP in place of Corel Draws of the world to provide proper info to GDI and in turn to our drivers? We noticed that the version 0.46 of inkscape was able to print to a HPLaserjet type laser printer. Most programs can work with our driver if they can print to laser printer. What do we need to do to make this happen? (2) Does Inkscape work with the following operating systems? - Windows XP - Windows Vista 32 bit - Windows Vista 64 bit - System 7 32 bit - System 7 64 bit (3) This question was first presented to the launchpad inskscape question #82515. It was suggested that we should ask the same question to the developers at this address. We are available for phone discussions, if necessary, during the working hours. Ashmi Shah Solustan, Inc. www.solustan.com 781-449-7666 -- ashmi

3 2

Re: [Inkscape-devel] Since release is nearing, let's talk 0.48 and beyond...
by Valerie 14 Sep '09

14 Sep '09

On Sun, 2009-09-13 at 23:09 -0500, Ted Gould wrote: > On Sat, 2009-09-12 at 23:16 -0700, Joshua A. Andler wrote: > > One thing that Debian is considering is fixed dates for freezes. > > So they'd do a freeze on a fixed schedule, and then > > release when it's ready. I'm curious if this might work for us > > long term, certainly with a DVCS we'd have more flexibility there. > > Interesting approach... I think that this may work for us > too after 0.49 since it may be a little unpredictable with > the library changes. It'd probably be a good idea after 0.49, yes, after major tasks such as library change is complete. Open source projects often push back the release date so that they can stabilize all the features they have added during the development cycle (and even then, some don't make it on time anyway). To the user, the choice is pretty simple though: - In 6 months, you get to access Feature A, and 6 months after that, you get to access Feature B, or: - You get to access Features A and B in 1 year. Those 6 months with "just" Feature A isn't pointless, it may mean hours of work saved, or that the user could accomplish things that he couldn't have otherwise. For some users, the absence of a crucial feature can be just as crippling as a bug. Good thing for the Development version, though that's not a solution for everybody.

1 0

Inkscape nightlies PPA
by Ted Gould 14 Sep '09

14 Sep '09

Hello, I set up this repository a while ago, but it broke, and now I think I have it all running again. I'm still running the builds manually so they're not quite "nightlies" but it's been running reliably, so I'm almost ready to move it to an automated script. This is a PPA that contains frequent builds of Inkscape directly from the trunk branch. It creates a separate package called "inkscape-devel" that you can install while you have stable version of Inkscape installed as well. Hardy is still a bit broken, so this is for people on Ubuntu releases 8.10 or newer. https://launchpad.net/~inkscape-nightly/+archive/ppa/ Currently, this will have pre2 plus other patches and translations that have been put in trunk since it's release. --Ted

1 0

[patch] Allow inkscape to zoom a wider range
by Arjan van de Ven 14 Sep '09

14 Sep '09

Hi, A program I've written (timechart, see http://blog.fenrus.org/?p=5 ) has SVG as output format. The idea behind timechart is to show what is happening in a system as part of performance tuning, and to do so in a way that is "infinitely zoomable", that is, if you want more information about a portion of the timechart, all you need to do is zoom in and more small details appear. With Inkscape being the primary suggested tool for viewing the output, I currently have a problem in that I can't put the finest details into the SVG, because inkscape just won't allow zooming deep enough to be able to see those details. I made the patch below that bumps the limits on zooming so that users of timechart then can get to the very finest details (if this patch is accepted I'll change timechart to put the details in that I've not been able to put in so far). I hope this (or a change with similar effects) is acceptable for inclusion into Inkscape. Greetings, Arjan van de Ven Intel Open Source Technology Center Index: src/desktop-handles.h =================================================================== --- src/desktop-handles.h (revision 22220) +++ src/desktop-handles.h (working copy) @@ -21,8 +21,8 @@ class Selection; } -#define SP_DESKTOP_ZOOM_MAX 256.0 -#define SP_DESKTOP_ZOOM_MIN 0.01 +#define SP_DESKTOP_ZOOM_MAX 4096.0 +#define SP_DESKTOP_ZOOM_MIN 0.001 #define SP_COORDINATES_UNDERLINE_NONE (0) #define SP_COORDINATES_UNDERLINE_X (1 << Geom::X)

2 3