Inkscape

On 9/1/11 16:12, J.B.C.Engelen@... wrote:

> Cairo 1.10.2 has been released, and a bug concerning Inkscape was fixed.
> https://bugs.launchpad.net/inkscape/+bug/665628
> It is a pity it is just too late to include in 0.48.1
> 
> Krzystof, can you update Cairo in the Windows devlibs when 0.48.1 is
> done? 

I don't think it would be too late for the win32 packages of 0.48.1
(they are not yet done), though it doesn't leave any time to test the
updated cairo version on Windows (if cairo 1.10.2 can be built without
issues on Windows ;) ).

@Michael - could you do the same for the osx packages of 0.48.1? On
modevia, the most recent devel builds still list cairo 1.10.0 as
included dependency.

Cairo 1.10.2 also fixes a critical regression in cairo 1.10.2 [1], see

Bug #672686 <https://bugs.launchpad.net/inkscape/+bug/681512>
“Some diagrams results in "Illegal character" in the generated pdf”

Bug #681512 <https://bugs.launchpad.net/inkscape/+bug/672686>
“Opaque radial gradients cause PDFs to fail to open in Adobe Reader”


~suv


[1] this second issue (regression in cairo 1.10.0) is only important for
packaging on osx, since the devlibs for Windows had not been updated to
cairo 1.10.0.

On 9/1/11 16:38, ~suv wrote:

sorry, typo:
> Cairo 1.10.2 also fixes a critical regression in cairo 1.10.2 [1], see

should be
> Cairo 1.10.2 also fixes a critical regression in cairo 1.10.0 [1], see


~suv

On Jan 9, 2011, at 7:38 AM, ~suv wrote:

> 
> I don't think it would be too late for the win32 packages of 0.48.1
> (they are not yet done), though it doesn't leave any time to test the
> updated cairo version on Windows (if cairo 1.10.2 can be built without
> issues on Windows ;) ).
> 
> @Michael - could you do the same for the osx packages of 0.48.1? On
> modevia, the most recent devel builds still list cairo 1.10.0 as
> included dependency.

We definitely want to look at however much testing as we can. Windows, especially, gives us some of the worst problems in terms of bugs and support.

We also need to avoid setting *requirements* of Inkscape up until enough distros have brought it into mainline, LTS, etc.

But windows and mac might be good.

On Sun, Jan 9, 2011 at 11:13 AM, Jon Cruz <jon@...> wrote:
>
> On Jan 9, 2011, at 7:38 AM, ~suv wrote:
>
>>
>> I don't think it would be too late for the win32 packages of 0.48.1
>> (they are not yet done), though it doesn't leave any time to test the
>> updated cairo version on Windows (if cairo 1.10.2 can be built without
>> issues on Windows ;) ).
>>
>> @Michael - could you do the same for the osx packages of 0.48.1? On
>> modevia, the most recent devel builds still list cairo 1.10.0 as
>> included dependency.
>
> We definitely want to look at however much testing as we can. Windows, especially, gives us some of the worst problems in terms of bugs and support.
>
> We also need to avoid setting *requirements* of Inkscape up until enough distros have brought it into mainline, LTS, etc.
>
> But windows and mac might be good.

I'd say that given 0.48.1 being a stable release update, and this
release of cairo is also a stable release update we go for it.

Cheers,
Josh

On 10/01/2011, at 2:38 AM, ~suv wrote:

> On 9/1/11 16:12, J.B.C.Engelen@... wrote:
> 
>> Cairo 1.10.2 has been released, and a bug concerning Inkscape was fixed.
>> https://bugs.launchpad.net/inkscape/+bug/665628
>> It is a pity it is just too late to include in 0.48.1
> 
> @Michael - could you do the same for the osx packages of 0.48.1? On
> modevia, the most recent devel builds still list cairo 1.10.0 as
> included dependency.

No problems, I've updated cairo to 1.10.2.  Nightly builds for Mac OS X from tomorrow will use it.


Cheers,
Michael

2011/1/9  <J.B.C.Engelen@...>:
> Hi all,
>  (best wishes for the new year!)
>
> Cairo 1.10.2 has been released, and a bug concerning Inkscape was fixed.
> https://bugs.launchpad.net/inkscape/+bug/665628
> It is a pity it is just too late to include in 0.48.1
>
> Krzystof, can you update Cairo in the Windows devlibs when 0.48.1 is
> done?

Sorry for the week+ lag. I have a lot to do in the organic chemistry
lab at the moment.

I have updated cairo, I'm waiting for a rebuild of Inkscape after
updating the trunk to commit it - there's a required change in
build.xml because the upstream Cairo win32 build started using
libpng14, and Inkscape and GTK loaders are still using libpng12.

Regards, Krzysztof

2011/1/9  <J.B.C.Engelen@...>:
> Cairo 1.10.2 has been released, and a bug concerning Inkscape was fixed.
> https://bugs.launchpad.net/inkscape/+bug/665628
> It is a pity it is just too late to include in 0.48.1
>
> Krzystof, can you update Cairo in the Windows devlibs when 0.48.1 is
> done?

I updated it today. (Sorry for lag, I need to spend a lot of time in
the lab these days.)
I still don't see
Regards, Krzysztof

W dniu 16 stycznia 2011 01:51 użytkownik Krzysztof Kosiński
<tweenk.pl@...> napisał:
> I still don't see

Oops.
Continuing, I don't see 0.48.1 being available for download yet, so
maybe the new Cairo can make it after all.
I think we are suffering from high bus factor again. [1] Is the
release process documented somewhere so that someone other than Ted
can do it?
Regards, Krzysztof

[1] http://en.wikipedia.org/wiki/Bus_factor

It's out-of-date documented in the wiki, I've been thinking the same thing
though that we need more than Ted able to do this. Also, yes it's cool to
backport the cairo fix for 0.48.1.

Cheers,
Josh
On Jan 15, 2011 4:59 PM, "Krzysztof Kosiński" <tweenk.pl@...> wrote:
> W dniu 16 stycznia 2011 01:51 użytkownik Krzysztof Kosiński
> <tweenk.pl@...> napisał:
>> I still don't see
>
> Oops.
> Continuing, I don't see 0.48.1 being available for download yet, so
> maybe the new Cairo can make it after all.
> I think we are suffering from high bus factor again. [1] Is the
> release process documented somewhere so that someone other than Ted
> can do it?
> Regards, Krzysztof
>
> [1] http://en.wikipedia.org/wiki/Bus_factor
>
>
------------------------------------------------------------------------------
> Protect Your Site and Customers from Malware Attacks
> Learn about various malware tactics and how to avoid them. Understand
> malware threats, the impact they can have on your business, and how you
> can protect your company and customers by using code signing.
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

> De : Krzysztof Kosiński <tweenk.pl@...>

> I have updated cairo, I'm waiting for a rebuild of Inkscape  after
> updating the trunk to commit it - there's a required change  in
> build.xml because the upstream Cairo win32 build started  using
> libpng14, and Inkscape and GTK loaders are still using  libpng12.

I've just noticed a small regression on Windows XP, Inkscape revision 10006, 
devlibs r21 (clean build): moving the mouse cursor on the layers list in the 
layers dialog (you must have at least 2 layers) makes the show and lock icons 
disappear.
Not reproduced with revision 9997, devlibs r20.

Regards.
--
Nicolas

> I've just noticed a small regression on Windows XP, Inkscape  revision 10006, 
> devlibs r21 (clean build): moving the mouse cursor on the  layers list in the 
> layers dialog (you must have at least 2 layers) makes the  show and lock icons 

> disappear.
> Not reproduced with revision 9997, devlibs  r20.

Also affected:
* Filters editor dialog (filters inputs are completely invisible).
* Undo history (flickering icons).
* Font editor (strange black strip).

Other lists that don't use icons (in the Preferences and Properties dialogs) are 
not affected.
--
Nicolas

I can reproduce the disappearing in the filter settings dialog. All
inputs are invisible if i drag the mous over it.

Maybe we shoud use the older cairo/pixman version to publish 0.48.1 and
fix this annoying error in 0.48.2 ?

Sincerely,

UweSch

Am 21.01.2011 15:53, schrieb Nicolas Dufour:
>
>> I've just noticed a small regression on Windows XP, Inkscape  revision 10006, 
>> devlibs r21 (clean build): moving the mouse cursor on the  layers list in the 
>> layers dialog (you must have at least 2 layers) makes the  show and lock icons 
>> disappear.
>> Not reproduced with revision 9997, devlibs  r20.
> Also affected:
> * Filters editor dialog (filters inputs are completely invisible).
> * Undo history (flickering icons).
> * Font editor (strange black strip).
>
> Other lists that don't use icons (in the Preferences and Properties dialogs) are 
> not affected.
> --
> Nicolas
>
>
>
>       
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Inkscape-devel mailing list
> Inkscape-devel@...
> https://lists.sourceforge.net/lists/listinfo/inkscape-devel

On 25/1/11 21:47, Uwe Schöler wrote:
> Am 21.01.2011 15:53, schrieb Nicolas Dufour:
>>> I've just noticed a small regression on Windows XP, Inkscape  revision 10006, 
>>> devlibs r21 (clean build): moving the mouse cursor on the  layers list in the 
>>> layers dialog (you must have at least 2 layers) makes the  show and lock icons 
>>> disappear.
>>> Not reproduced with revision 9997, devlibs  r20.
>>
>> Also affected:
>> * Filters editor dialog (filters inputs are completely invisible).
>> * Undo history (flickering icons).
>> * Font editor (strange black strip).
>>
>> Other lists that don't use icons (in the Preferences and Properties dialogs) are 
>> not affected.
>
> I can reproduce the disappearing in the filter settings dialog. All
> inputs are invisible if i drag the mous over it.
> 
> Maybe we shoud use the older cairo/pixman version to publish 0.48.1 and
> fix this annoying error in 0.48.2 ?

... or release 0.48.1-1 for Windows with the previous cairo version
(1.8.8) and an updated win32 package 0.48.1-2 with cairo 1.10.2 as soon
as a fix is available?


Bug report including screenshots:

Bug #707255 Layer dialog - symbols dissappear when mouse hover over
<https://bugs.launchpad.net/inkscape/+bug/707255>

Current development builds with cairo 1.10.2 are available for testing
from <http://inkscape.modevia.com/win32/?C=M;O=D>


~suv

2011/1/25 ~suv <suv-sf@...>:
> ... or release 0.48.1-1 for Windows with the previous cairo version
> (1.8.8) and an updated win32 package 0.48.1-2 with cairo 1.10.2 as soon
> as a fix is available?

The older releases have a PDF export bug for black strokes, which
might be more severe han an UI glitch. What do you think? It's easy to
revert the Cairo upgrade temporarily, or the person building the
Windows installer could use an earlier revision of devlibs.

Regards, Krzysztof

On 28/1/11 01:25, Krzysztof Kosiński wrote:
> 2011/1/25 ~suv <suv-sf@...>:
>> ... or release 0.48.1-1 for Windows with the previous cairo version
>> (1.8.8) and an updated win32 package 0.48.1-2 with cairo 1.10.2 as soon
>> as a fix is available?
> 
> The older releases have a PDF export bug for black strokes, which
> might be more severe han an UI glitch. What do you think? It's easy to
> revert the Cairo upgrade temporarily, or the person building the
> Windows installer could use an earlier revision of devlibs.

It is tricky...
On the one hand, the new cairo version fixes at least one known issue
with PDF export (and likely others, too, but I don't have an overview of
the changes between cairo 1.8.8 and 1.10.2), on the other hand the first
user reaction we got in the bug report was "It's a VERY annoing bug."

Releasing with a _known_ UI regression doesn't feel quite right to me,
nor does not fixing the PDF issue. But the UI issue will affect all
users, the PDF export likely far fewer (otherwise it would have been
reported and commented more often, in the bug tracker and elsewhere).

Any comments from Windows users (Johan, JazzyNico, Uwesch,...)? The
issue is limited to the Windows builds afaict [1] and its impact on
usability seems difficult to evaluate without actually using an affected
build.


While the outage of most of Sourceforge's services [2] (including "New
Release upload capability") buys us some time - is there a chance this
issue could be investigated whether there's possibly an "easy" fix?


~suv


[1] on osx for example, with the same upgraded cairo/libpng versions
Inkscape doesn't have the GUI glitch, at least not with the latest gtk+ 2.22
[2] <http://sf.net/sitestatus>

Hello,

Sorry for the late reply.


> De : ~suv <suv-sf@...>
> Any comments from Windows users (Johan,  JazzyNico, Uwesch,...)? The
> issue is limited to the Windows builds afaict [1]  and its impact on
> usability seems difficult to evaluate without actually  using an affected
> build.

I'm afraid we're going to have the same kind of reaction we had with the 
persistent markers with 0.48 on GNU/Linux. The problem with UI issues is that 
even when they are not severe (here it's just flickering, and doesn't prevent 
Inkscape from working), they are more visible than PDF export bugs. Frankly (if 
it's not too late), I'd rather keep the old devlibs for 0.48.1 and start using 
the new one (and try to find a fix or a workaround) in 0.48.2.

Regards.
--
Nicolas

On 7/2/11 11:36, Nicolas Dufour wrote:

>> De : ~suv <suv-sf@...>
>> Any comments from Windows users (Johan,  JazzyNico, Uwesch,...)? The
>> issue is limited to the Windows builds afaict [1]  and its impact on
>> usability seems difficult to evaluate without actually  using an affected
>> build.
> 
> I'm afraid we're going to have the same kind of reaction we had with the 
> persistent markers with 0.48 on GNU/Linux. The problem with UI issues is that 
> even when they are not severe (here it's just flickering, and doesn't prevent 
> Inkscape from working), they are more visible than PDF export bugs. Frankly (if 
> it's not too late), I'd rather keep the old devlibs for 0.48.1 and start using 
> the new one (and try to find a fix or a workaround) in 0.48.2.

As far as I know, the 0.48.1-1 packages already uploaded to sf.net
(installer, archives, debug and portable) have been built with the
current devlibs (cairo 1.10.2).

Not sure, but it looks like we'll have to bear with the user reactions
until the next bug-fix release is ready (0.48.2). Or replace the
uploaded files with new packages (0.48.1-2), built with the old devlibs
(cairo 1.8.8). The links to the new files have already been spread
quickly via twitter et al. - replacing the files now could cause some
confusion for users. OTOH the release wasn't yet officially announced.


~suv

On Mon, Feb 7, 2011 at 2:52 AM, ~suv <suv-sf@...> wrote:
> On 7/2/11 11:36, Nicolas Dufour wrote:
>
>>> De : ~suv <suv-sf@...>
>>> Any comments from Windows users (Johan,  JazzyNico, Uwesch,...)? The
>>> issue is limited to the Windows builds afaict [1]  and its impact on
>>> usability seems difficult to evaluate without actually  using an affected
>>> build.
>>
>> I'm afraid we're going to have the same kind of reaction we had with the
>> persistent markers with 0.48 on GNU/Linux. The problem with UI issues is that
>> even when they are not severe (here it's just flickering, and doesn't prevent
>> Inkscape from working), they are more visible than PDF export bugs. Frankly (if
>> it's not too late), I'd rather keep the old devlibs for 0.48.1 and start using
>> the new one (and try to find a fix or a workaround) in 0.48.2.
>
> As far as I know, the 0.48.1-1 packages already uploaded to sf.net
> (installer, archives, debug and portable) have been built with the
> current devlibs (cairo 1.10.2).
>
> Not sure, but it looks like we'll have to bear with the user reactions
> until the next bug-fix release is ready (0.48.2). Or replace the
> uploaded files with new packages (0.48.1-2), built with the old devlibs
> (cairo 1.8.8). The links to the new files have already been spread
> quickly via twitter et al. - replacing the files now could cause some
> confusion for users. OTOH the release wasn't yet officially announced.

I see minimal harm with what has spread via twitter that is not
official. :) If people file bug reports about it prior to official
announcement and say they found out via AwesomeSoftware2011 on
twitter, we just need to tell them to watch trusted people (myself,
joncruz, prokoudine, or any number of others) for *accurate*
information about releases. Confused users that trust third-party
sources instead of trusted/official sources are the least of my
worries and imho kinda deserve the pain they subject themselves to
(like people who get malware infected machines because they pirate via
P2P and such).

Enough of that mini-rant. :) I think that we should see about
repackaging the win32 versions with the less "annoying" bug for now
until fixed libs are released. Uwe & Chris, do you think you'll be
able to do that? BTW, has anyone checked if it's a known issue
upstream?

Cheers,
Josh