Hi all,
We have just this evening reached our bug fixing goal. There is one must-fix bug (see below) but I think it may be out of date anyway.
Thus, tonight we are officially moving into Hard Freeze, the final phase in the release cycle before Inkscape 0.44 is released.
From this point until release, DO NOT COMMIT anything to SVN without
approval from our Release Wardens (Jon Cruz and Aaron Spike). If you have bug fixes to contribute, please post them to the patch tracker and notify them.
Jon and Aaron, you two now have absolute authority over the codebase between now and when 0.44.0 is tagged. Use this time to review the codebase for any last minute bugs, must-fix bugs that we've missed until now, or other flaws that should be fixed before release. When you feel things are ready, create the 0.44.0 tag. We will split into the stable 0.44 and development 0.45 branches at that point.
I would encourage you two to try to complete the Hard Freeze within a week. Ideally, it should only take a few days to check and finalize everything, so that should be doable. If it looks like it'll take longer, let's discuss some alternate plans.
Here is the status for the remaining bugs I know about:
* We have just a single must-fix bug left (#1489175 "Win2K: Crash on Startup: entry point FreeAddrInfo not found"), however from the limited information on that bug, it sounds like it's probably out of date, so I'm not going to worry about it. You can take a look at it and decide what to do about it. #1489175
* There's some snapping bugs that haven't gotten attention, that you may want to review. They weren't included in the must-fix list due to lack of owner. #1488128
* We've gotten a bunch of reports from Debian Unstable users about Inkscape failing to run. This affects users of both old 0.43 and 0.44pre1. Dunno if this is a distro issue, or a gtk issue, or what, but probably needs more analysis. #1497837
* There are still some font issues related to the new font control. If you feel these have not been adequately addressed, consider disabling the font rendering in the font selector for this release, or other actions to hide the issue until post-release. #1494337
There's probably others, but you can decide the ones you care most about. Remember though, at this point the game is to minimize the impact of the bugs, rather than to see them fixed. This may mean hiding the symptoms (or trading them for more tolerable bugs), or simply list them as known issues, and put them on the must-fix list for 0.44.1.
Bryce
Selon Bryce Harrington <bryce@...961...>:
Hi all,
We have just this evening reached our bug fixing goal. There is one must-fix bug (see below) but I think it may be out of date anyway.
Thus, tonight we are officially moving into Hard Freeze, the final phase in the release cycle before Inkscape 0.44 is released.
Just before moving to hard-freeze : is it possible to integrate the following patches ? 1498682 Update of czech.nsh 1498640 more Korean translation 1498252 French strings for windows installer 1495666 updated keys.fr 1494987 Spanish nhs translation 1493939 Easter Egg Tutorial 1493182 updated French calligraphy tutorial 1459716 translation of Tracing tutorial into Russian 1353260 Fix author name
Regards,
matiphas
We'll do our best to get in what we can. I'll have to coordinate with ACSpike on this, but we'll be sure to bring issues to light if any of these won't be able to get in.
On Jun 1, 2006, at 12:58 AM, matiphas@...8... wrote:
Just before moving to hard-freeze : is it possible to integrate the following patches ? 1498682 Update of czech.nsh 1498640 more Korean translation 1498252 French strings for windows installer 1495666 updated keys.fr 1494987 Spanish nhs translation 1493939 Easter Egg Tutorial 1493182 updated French calligraphy tutorial 1459716 translation of Tracing tutorial into Russian 1353260 Fix author name
There are a couple translated tutorials that I will generate today and throw back on the patch tracker ready for John or Aaron to commit.
I personally think that the Easter Egg tutorial should wait until next release when we have a large tutorial update and the tuts will be categorized. At that point we will have a couple others of the same nature as well (such as glass buttons).
I will have the tutorials in the tracker within 3 hours.
-Josh
Jon A. Cruz wrote:
We'll do our best to get in what we can. I'll have to coordinate with ACSpike on this, but we'll be sure to bring issues to light if any of these won't be able to get in.
On Jun 1, 2006, at 12:58 AM, matiphas@...8... wrote:
Just before moving to hard-freeze : is it possible to integrate the following patches ? 1498682 Update of czech.nsh 1498640 more Korean translation 1498252 French strings for windows installer 1495666 updated keys.fr 1494987 Spanish nhs translation 1493939 Easter Egg Tutorial 1493182 updated French calligraphy tutorial 1459716 translation of Tracing tutorial into Russian 1353260 Fix author name
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On Thu, 1 Jun 2006 matiphas@...8... wrote:
Date: Thu, 01 Jun 2006 09:58:57 +0200 From: matiphas@...8... To: Bryce Harrington <bryce@...961...> Cc: inkscape-devel@...6... Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
Selon Bryce Harrington <bryce@...961...>:
Hi all,
We have just this evening reached our bug fixing goal. There is one must-fix bug (see below) but I think it may be out of date anyway.
There aren't any real "bugs" worrying me b but there are a few cosmetic details I'd love to see tweaked to show Inkscape at its best, especially if Effects are now going to be turned on by default.
I'd very much like for the Effects menu to be renamed to Effect (we have the are verbs, we have File, not Files, Layer, not Layers, etc) https://sourceforge.net/tracker/?func=detail&aid=1253273&group_id=93... (crappy patch included, might work, might have bitrotted) and also at the same time it would be good to get menu mnemonic for Effe_ct https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1313582...
It can wait but the layout of the user interface in the scripts I looked at are quite busy and complicated. The widgets are not lined up either which doesn't help readability (sticking them into a table and using colspan is a fairly easy way to tidy this up when designing in Glade).
It isn't clear which scripts will pop a dialog and which dont (I'll have to recheck the *HIG but) some of them should probably have ... ellipsis after the menu lable.
* hig explaination on menu item ellipsis on the following page: http://developer.gnome.org/projects/gup/hig/2.0/menus-design.html It is confusing but based on what I've seen in other apps it means most of the Effects which do pop a dialog should have ... after them.
I'm not sure I will have enough done in my attempt at a set of Adobe style keybindings but I would like to get in included if only to encourage ordinary users to help improve it.
On Thu, 2006-06-01 at 13:29 +0100, Alan Horkan wrote:
I'd very much like for the Effects menu to be renamed to Effect (we have the are verbs, we have File, not Files, Layer, not Layers, etc) https://sourceforge.net/tracker/?func=detail&aid=1253273&group_id=93... (crappy patch included, might work, might have bitrotted) and also at the same time it would be good to get menu mnemonic for Effe_ct https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1313582...
I think the menus are serving different purposes though. Menus like "Layer" are operations that you perform on a layer. The effects menu serves as more of a collection of things that you can do to the document. "Change Document" menu doesn't sound very good :)
It can wait but the layout of the user interface in the scripts I looked at are quite busy and complicated. The widgets are not lined up either which doesn't help readability (sticking them into a table and using colspan is a fairly easy way to tidy this up when designing in Glade).
Well, the real problem here is that they're automatically generated. It's unlikely that anything autogenerated will ever look good. In this case each parameter is independent to maintain good OO practice, so any change would be too much at this point in the release process.
It isn't clear which scripts will pop a dialog and which dont (I'll have to recheck the *HIG but) some of them should probably have ... ellipsis after the menu lable.
That makes sense to me, but I don't think something this trivial is worth breaking the hard freeze.
--Ted
On Thu, Jun 01, 2006 at 10:14:38PM -0700, Ted Gould wrote:
On Thu, 2006-06-01 at 13:29 +0100, Alan Horkan wrote:
I'd very much like for the Effects menu to be renamed to Effect (we have the are verbs, we have File, not Files, Layer, not Layers, etc) https://sourceforge.net/tracker/?func=detail&aid=1253273&group_id=93... (crappy patch included, might work, might have bitrotted) and also at the same time it would be good to get menu mnemonic for Effe_ct https://sourceforge.net/tracker/?func=detail&atid=604306&aid=1313582...
I think the menus are serving different purposes though. Menus like "Layer" are operations that you perform on a layer. The effects menu serves as more of a collection of things that you can do to the document. "Change Document" menu doesn't sound very good :)
Hmm, Alan is sounding more convincing on this. All the other items are singular.
It can wait but the layout of the user interface in the scripts I looked at are quite busy and complicated. The widgets are not lined up either which doesn't help readability (sticking them into a table and using colspan is a fairly easy way to tidy this up when designing in Glade).
Well, the real problem here is that they're automatically generated. It's unlikely that anything autogenerated will ever look good. In this case each parameter is independent to maintain good OO practice, so any change would be too much at this point in the release process.
Agreed. But maybe for 0.45 they could be put into a table to make them a bit more orderly.
For this release, even having a UI for many of these will be a huge step forward. :-)
It isn't clear which scripts will pop a dialog and which dont (I'll have to recheck the *HIG but) some of them should probably have ... ellipsis after the menu lable.
That makes sense to me, but I don't think something this trivial is worth breaking the hard freeze.
Plus, it might risk invalidating some strings and throwing off the translators.
However, this might be worth fixing for 0.44.1. Alan, can you check that there's a bug in on this one?
Bryce
On Fri, 2 Jun 2006, Bryce Harrington wrote:
I think the menus are serving different purposes though. Menus like "Layer" are operations that you perform on a layer. The effects menu serves as more of a collection of things that you can do to the document. "Change Document" menu doesn't sound very good :)
Hmm, Alan is sounding more convincing on this. All the other items are singular.
I don't really care that much, but I would say that "Effects" feels more natural to me than "Effect". Perhaps it's different across the pond ;) I'll go with majority opinion, as long as we don't change the name entirely again ;)
It isn't clear which scripts will pop a dialog and which dont (I'll have to recheck the *HIG but) some of them should probably have ... ellipsis after the menu lable.
That makes sense to me, but I don't think something this trivial is worth breaking the hard freeze.
Plus, it might risk invalidating some strings and throwing off the translators.
I think that we can translate before adding the "..." at the end. How does this effect RTL languages? Can I just append "..." on the end of the string and Glib::ustring will figure it out for me? Does any language have a different marking for this?
However, this might be worth fixing for 0.44.1. Alan, can you check that there's a bug in on this one?
Make sure to assign it to me.
--Ted
On 6/2/06, ted@...11... <ted@...11...> wrote:
I don't really care that much, but I would say that "Effects" feels more natural to me than "Effect".
Agreed.
On Fri, 2 Jun 2006 ted@...11... wrote:
Date: Fri, 2 Jun 2006 12:01:19 -0500 (EST) From: ted@...11... To: Bryce Harrington <bryce@...961...> Cc: Alan Horkan <horkana@...44...>, inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
On Fri, 2 Jun 2006, Bryce Harrington wrote:
I think the menus are serving different purposes though. Menus like "Layer" are operations that you perform on a layer. The effects menu serves as more of a collection of things that you can do to the document. "Change Document" menu doesn't sound very good :)
Hmm, Alan is sounding more convincing on this. All the other items are singular.
I don't really care that much,
Adobe Illustrator uses "Effect".
Unless there are *strong* reasons to do otherwise I definately encourage you do the same, and it was my understanding Inkscape developers would take the approach of the same or better not just different. To the best of my knowledge there was a convention of using verbs which happen to look like nouns for menus although there are unfortunately many exceptions. Also I tried to provide patch in the hope that someone would patch first and ask questions later. I'm still not sure if it works and I'm not in a good position to provide a better patch.
It isn't clear which scripts will pop a dialog and which dont (I'll have to recheck the *HIG but) some of them should probably have ... ellipsis after the menu lable.
That makes sense to me, but I don't think something this trivial is worth breaking the hard freeze.
Well depending on your definition it isn't really a bug (most things less than a crasher usually get moved to the RFE section) which is why I dont feel bad mentioning it this close to the hard freeze.
Plus, it might risk invalidating some strings and throwing off the translators.
I certainly would not want to annoy the translators. They do not get a lot of lead time before a release and it is a tough job to do well.
However given the tools available and the existence of fuzzy translations there isn't much benefit in dely this change which would be helpful to users. The actual impact of this or any other punctuation change on translators would only really be to throw off any statistics based on the translations but it probably wouldn't be a something the translators would be likely to complain about. (Although I suspect the translators are often too modest to complain, when in fact they would be doing users a favour by making the original texts easier to understand and translate.)
Please speak up now translators!
(Having said that the Effects look rather complicated at the first glance, I predict lots of string changes ahead later but I'd prefer not to interfere and would love if the extensions writers reevalute the work thinking of users who might be scared off by equations and not already familiar with the problem domain.)
However, this might be worth fixing for 0.44.1. Alan, can you check that there's a bug in on this one?
Make sure to assign it to me.
I'll try and remember to file it tomorrow (Saturday, when I'm not stuck on dialup) and get on with those Adobe style keybindings.
Sincerely
However given the tools available and the existence of fuzzy translations there isn't much benefit in dely this change which would be helpful to users. The actual impact of this or any other punctuation change on translators would only really be to throw off any statistics based on the translations but it probably wouldn't be a something the translators would be likely to complain about. (Although I suspect the translators are often too modest to complain, when in fact they would be doing users a favour by making the original texts easier to understand and translate.)
Please speak up now translators!
I would just like to say that (1 I'm a translator and i'm not modest (really) ) 2 a fuzzy string appears untranslated in the interface 3 we are trying to recruit some new translators to begin introduction of new localization and/or manage the unmaintained ones
-> I'm not sure it's the best moment to introduce fuzzies in the po files. Users have lived with the current strings up to now. Wouldn't it be possible to delay this change just after 0.44 ? (just after 0.44, not just before 0.45 :) )
Regards,
matiphas
On Sat, 3 Jun 2006, Matiphas wrote:
Date: Sat, 03 Jun 2006 00:51:56 +0200 From: Matiphas <matiphas@...8...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
However given the tools available and the existence of fuzzy translations there isn't much benefit in dely this change which would be helpful to users. The actual impact of this or any other punctuation change on translators would only really be to throw off any statistics based on the translations but it probably wouldn't be a something the translators would be likely to complain about. (Although I suspect the translators are often too modest to complain, when in fact they would be doing users a favour by making the original texts easier to understand and translate.)
Please speak up now translators!
I would just like to say that (1 I'm a translator and i'm not modest (really) ) 2 a fuzzy string appears untranslated in the interface
It doesn't fall back to the previous version?
Right then, my mistake, scratch that suggestion. It would be too painful for translators and the ellipses ... should definately wait until after the release.
On 6/2/06, Alan Horkan <horkana@...44...> wrote:
Adobe Illustrator uses "Effect".
So what?
I really don't get it. "Effects" sounds perfectly logical because it what we have in that menu. "Effect" would imply that there are certain "effect objects" in the document, that one of them may be current, and that the commands in this menu operate on that current effect. All of these assumptions are true for layers, objects, and paths, but none of them is true for effects. Therefore we have "Layer", "Object", "Path" yet "Effects". Anything else would be confusing, for the reasons I just gave.
I'm against this change.
On 6/3/06, bulia byak <buliabyak@...400...> wrote:
On 6/2/06, Alan Horkan <horkana@...44...> wrote:
Adobe Illustrator uses "Effect".
So what?
Here here. We're in Hard freeze, we've been in string freeze for at least a week. Regardless of which is right, now is not the time to be screwing around with strings and changing stuff. If it was that important it should have been brought up earlier. It has to wait for 0.45 or 0.44.1, and even then i think it should stay as effects. Incidentally, its effects in Paint Shop Pro. IMO even the mnemonic can wait, this is planned to be a maintained branch after all, get em in in the first update, lets get this out the door.
Cheers
Sim
On Sat, 3 Jun 2006, john cliff wrote:
Date: Sat, 3 Jun 2006 11:32:29 +0100 From: john cliff <john.cliff@...400...> To: Inkscape Devel List inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
On 6/3/06, bulia byak <buliabyak@...400...> wrote:
On 6/2/06, Alan Horkan <horkana@...44...> wrote:
Adobe Illustrator uses "Effect".
So what?
Here here.
Way to encourage people to provide feedback.
We're in Hard freeze, we've been in string freeze for at least a week.
Okay I missed the deadline by a bit but this wasn't the first time I've mentioned it. (I've a feeling of deja-vu like as if this happened before another release.)
Regardless of which is right, now is not the time to be screwing around with strings and changing stuff. If it was that important it should have been brought up earlier.
It was, several times. I filed a request and attempted as best I could to provide a patch, and I also tried to cover the problem of the menmonic for that menu too. I'm surprised the mnemonic wasn't done when it was first added so that menu will definately need to change.
It has to wait for 0.45 or 0.44.1, and even then i think it should stay as effects.
If Effects are not enabled by default in this release then go ahead but it would be a shame to turn on the Effects without a bit more polish.
Incidentally, its effects in Paint Shop Pro.
I was aware of that and other examples but I wasn't going to argue against myself but thanks for making the effort to provide a solid counter point but I was up front about the fact that many programs do not follow the best practice of using verbs for top level menus but I still hope Inkscape will make the extra effort.
Alan Horkan wrote:
I was aware of that and other examples but I wasn't going to argue against myself but thanks for making the effort to provide a solid counter point but I was up front about the fact that many programs do not follow the best practice of using verbs for top level menus but I still hope Inkscape will make the extra effort.
Anyone want to argue for "Affect"? :-)
Aaron Spike
On Sat, 3 Jun 2006, Aaron Spike wrote:
Date: Sat, 03 Jun 2006 09:16:44 -0500 From: Aaron Spike <aaron@...749...> To: Alan Horkan <horkana@...44...>, inkscape inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
Alan Horkan wrote:
I was aware of that and other examples but I wasn't going to argue against myself but thanks for making the effort to provide a solid counter point but I was up front about the fact that many programs do not follow the best practice of using verbs for top level menus but I still hope Inkscape will make the extra effort.
Anyone want to argue for "Affect"? :-)
I do understand the distiction get the grammatical distinction but in effect it doesn't matter http://dictionary.reference.com/search?q=effect
Also Layer is taken to imply one or more Layers and equally Effect can be taken to mean one or more Effects.
On Fri, 2 Jun 2006, bulia byak wrote:
Date: Fri, 2 Jun 2006 19:13:43 -0400 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
On 6/2/06, Alan Horkan <horkana@...44...> wrote:
Adobe Illustrator uses "Effect".
So what?
Why do differently?
As I said in my previous post I had understood Inkscape was going to do the same or better and not just different for the sake of it (embrace and extend works). I had hoped I wouldn't have to argue points of consistency like this everytime, else Inkscape will go the way of the GNU Image Manipulation Program where user experience becomes like a death of a thousand cuts with each and every little inconsistency adding up.
I really don't get it. "Effects" sounds perfectly logical because it what we have in that menu.
Please provide another reason than precedence. It hasn't been that way for very long and I have asked for it to be changed since very shortly after it was put in place. Precendence shouldn't be an issue at all at least until there has been a stable supported Inkscape 1.0 and show users of your intention to keep things stable, otherwise everything should be up for change.
"Effect" would imply that there are certain "effect objects" in the document,
Would it really? I disagree.
that one of them may be current, and that the commands in this menu operate on that current effect. All of these assumptions are true for layers, objects, and paths, but none of them is true for effects.
However I pointed out Inkscape (and many other programs) have: File not Files, Edit not Edits, Layer not Layers, View not Views. These are verbs not nouns/objects which is what underlies your assumptions.
It may not be the most reputable source but here is what I found in Wikipedia: "According to traditional human interface guidelines, menu names were always supposed to be verbs, such as "file" "edit" and so on[citation needed]. This has been largely ignored in subsequent UI developments." http://en.wikipedia.org/wiki/Menu_%28computing%29
[Parnoia Note: You can check the history, I have never edited that page, not yet anyway.]
Therefore we have "Layer", "Object", "Path"
As I have mentioned before there shouldn't be a Path menu either. Paths should be covered under objects and treating them otherwise is an implementation detail users shouldn't be burdened with.
I'm against this change.
Even if you are against the change of Effects to Effect you should certainly be in favour of adding the mnemonic to Effe_cts before releasing Inkscape with effects turned on by default.
On 6/3/06, Alan Horkan <horkana@...44...> wrote:
I really don't get it. "Effects" sounds perfectly logical because it what we have in that menu.
Please provide another reason than precedence.
Once again: "Effects" is so named because it contains effects, not a single effect. "Layer" is so named because it does NOT contain layers, but commands which work on, or change, the current layer (singular). Sounds like a perfect reason for me.
As I have mentioned before there shouldn't be a Path menu either. Paths should be covered under objects and treating them otherwise is an implementation detail users shouldn't be burdened with.
I disagree. There are lots of things that can only be done to paths and not just any objects. It would simply not fit into one menu, it will be a mess. Paths are the foundation of vector graphics. Anyone unaware of this "implementation detail" is not likely to create anything of value in Inkscape.
Even if you are against the change of Effects to Effect you should certainly be in favour of adding the mnemonic to Effe_cts before releasing Inkscape with effects turned on by default.
Since translators are against that, and since it's too visible to break translation of, I'm voting to postpone the underscore to the next version.
On Sat, 3 Jun 2006, bulia byak wrote:
Date: Sat, 3 Jun 2006 10:48:48 -0400 From: bulia byak <buliabyak@...400...> To: Alan Horkan <horkana@...44...> Cc: Inkscape is a vector graphics editor inkscape-devel@lists.sourceforge.net Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
On 6/3/06, Alan Horkan <horkana@...44...> wrote:
I really don't get it. "Effects" sounds perfectly logical because it what we have in that menu.
Please provide another reason than precedence.
Once again: "Effects" is so named because it contains effects, not a single effect. "Layer" is so named because it does NOT contain layers, but commands which work on, or change, the current layer (singular). Sounds like a perfect reason for me.
As I have mentioned before there shouldn't be a Path menu either. Paths should be covered under objects and treating them otherwise is an implementation detail users shouldn't be burdened with.
I disagree. There are lots of things that can only be done to paths and not just any objects.
Both appear the same for users. If things could be converted from Objects to paths as needed it would simplify things for users but require more effort from developers. As a developer I can see why you would prefer to treat them differently but I think you are too close to it to be objective. For example it would be especially great if the underlying text information could be hidden and preserved in some way which allowed text Paths to be converted back to text later, so the users don't need to really need to understand the distinction between paths and ordinary text. You understand the difference of course and many others do but it would be easier if users didn't need to. (And I'm sure there are better examples but I've borked my copy of inkscape so I picked one off the top of my head.)
It would simply not fit into one menu,
Submenus will be needed anyway.
Inkscape uses lots and lots of menus but in various cases a dialog would be able to present more options and allow great flexibility. Compare how Freehand does inset/outset in a dialog to how Inkscape does it with only a few menu items for example, the real gains are when you want to inset more than one or two items at a time.
will be a mess. Paths are the foundation of vector graphics. Anyone unaware of this "implementation detail" is not likely to create anything of value in Inkscape.
Read that back to yourself. People can create great artistic works understanding very little, and create very impressive work using only a pen and basic line shapes. Sure it would be easier if they invested more time to learn how things worked but things could be easier. This is a strange turnaround from your usual optimism when it comes to empowering artists.
Even if you are against the change of Effects to Effect you should certainly be in favour of adding the mnemonic to Effe_cts before releasing Inkscape with effects turned on by default.
Since translators are against that,
I took it to read that adding ellipses in all the right places would have changed many strings and put too much of a burden on translators, but I hope the Effe_ct change is made before Effects are turned on by default.
and since it's too visible to break translation of, I'm voting to postpone the underscore to the next version.
Wasn't the change from Effect to Effects delayed already before another release?
The request for a mnemonic was incorrectly closed as fixed last week and I had to reopen it.
If you also postpone turning Effect on by default for another release it avoids the problems and gives time for additional polish.
On 6/3/06, Alan Horkan <horkana@...44...> wrote:
It would simply not fit into one menu,
Submenus will be needed anyway.
...and the most logical way to separate some commands into a submenu would be to get all path-related commands into a Path submenu. Which will put us back where we started.
You seem to be mixing different aspects. Of course automatically converting to path when necessary is a good thing, and we do it in some cases already and will keep adding more of it. But, with or without autoconversion, the user needs some way to categorize and make sense of the awful lot of commands he has available. Separating path-related commands is the most natural thing to do, because these commands are conceptually different from all others. This is just the most very logical categorization, which helps users navigate in the commands. Whether they are in a separate menu or in a submenu in Object is secondary, though the latter option just adds clumsiness without any other benefit.
On Sat, 2006-06-03 at 12:20 +0100, Alan Horkan wrote:
that one of them may be current, and that the commands in this menu operate on that current effect. All of these assumptions are true for layers, objects, and paths, but none of them is true for effects.
However I pointed out Inkscape (and many other programs) have: File not Files, Edit not Edits, Layer not Layers, View not Views. These are verbs not nouns/objects which is what underlies your assumptions.
It may not be the most reputable source but here is what I found in Wikipedia: "According to traditional human interface guidelines, menu names were always supposed to be verbs, such as "file" "edit" and so on[citation needed]. This has been largely ignored in subsequent UI developments." http://en.wikipedia.org/wiki/Menu_%28computing%29
Uhm, I don't think they're verbs.
File - Actions that effect the "file" or the current data that you're working with. I would argue that Nautilus more adequately takes care of filing, which would be more organization of multiple files.
Layer - Actions that effect the current "layer", as in the noun.
But, in the end, it doesn't really matter. I have no problem adding the shortcut, but again, I think that really messes up translators. Fuzzy doesn't work there when many languages (especially Asian ones) have to do funny things with the shortcuts.
--Ted
Ted Gould wrote:
On Sat, 2006-06-03 at 12:20 +0100, Alan Horkan wrote:
that one of them may be current, and that the commands in this menu operate on that current effect. All of these assumptions are true for layers, objects, and paths, but none of them is true for effects.
However I pointed out Inkscape (and many other programs) have: File not Files, Edit not Edits, Layer not Layers, View not Views. These are verbs not nouns/objects which is what underlies your assumptions.
It may not be the most reputable source but here is what I found in Wikipedia: "According to traditional human interface guidelines, menu names were always supposed to be verbs, such as "file" "edit" and so on[citation needed]. This has been largely ignored in subsequent UI developments." http://en.wikipedia.org/wiki/Menu_%28computing%29
Uhm, I don't think they're verbs.
File - Actions that effect the "file" or the current data that you're working with. I would argue that Nautilus more adequately takes care of filing, which would be more organization of multiple files.
Layer - Actions that effect the current "layer", as in the noun.
But, in the end, it doesn't really matter. I have no problem adding the shortcut, but again, I think that really messes up translators. Fuzzy doesn't work there when many languages (especially Asian ones) have to do funny things with the shortcuts.
--Ted
IMHO, this has gone too far. I mean, 20+ messages for what? For an "s"? Come on, you would all have fixed some bugs in the time it took to write all these e-mails. :-)
Having witnessed many discussions in the few months I am monitoring this list, it seems that UI is a hot issue. I am planning on working on a UI customizer (like OpenOffice and most KDE apps have) to allow a user to change the UI as he sees fit (adding extra menus, changing toolbars, changing shortcut keys).
I hope such functionality will make such issues easier to resolve and will actually lighten the burden on the devel team, so that it doesn't make permanent UI decisions (and gets the blame).
However, I am pretty busy for the next weeks and I will start looking into it after that. I can't guarantee anything, but judging from a very quick code sweep it certainly looks feasible.
- Spyros Blanas
On 03/06/06, Spyros Blanas <sblanas@...400...> wrote:
Ted Gould wrote:
On Sat, 2006-06-03 at 12:20 +0100, Alan Horkan wrote:
[ snip ]
IMHO, this has gone too far. I mean, 20+ messages for what? For an "s"?
Yes and no. Whilst I am sympathetic to your point of view, and had thought of posting on the same lines, the fact is that this sort of discussion is very necessary: Think of it as a form of calibrating one's compass before going on a long march.
FWIW, I suspect that we may have to ask the parties who hold strong views, such as Alan, the Drivers such as Bulia and the Translators to give us pros and cons for two basic alternatives:
A. We agree that the present name "Effects" is wrong, but delivering Effects "On" in version 0.44 is so important that we will use this name (perhaps merely as a placeholder) and fix the UI in the next release.
B. We agree that a coherent UI is so important that we will leave Effects "Off" in version 0.44 and turn them on by default when the UI is fit for public use.
(Apologies if this offends anyone identifiable above, and apologies if I missed off the name of anyone whose name I should have included).
Whilst I do have a view on this, which I will state if asked, personally I feel that UI is very, very important for Inkscape and we should either a) 'get it right', b) make it plastic - modifiable in later versions or c) state clearly that it highly subject to change over the next 55 releases (which is what I mean by public use).
Your idea is a good one, and I would encourage you to provide it, but please note that a UI that needs to be set by the end user is not one I would propose unless your users are emacs/Lisp aficionados.
Ben.
On 6/3/06, Ben Fowler <ben.the.mole@...400...> wrote:
FWIW, I suspect that we may have to ask the parties who hold strong views, such as Alan, the Drivers such as Bulia and the Translators to give us pros and cons for two basic alternatives:
A. We agree that the present name "Effects" is wrong, but delivering Effects "On" in version 0.44 is so important that we will use this name (perhaps merely as a placeholder) and fix the UI in the next release.
B. We agree that a coherent UI is so important that we will leave Effects "Off" in version 0.44 and turn them on by default when the UI is fit for public use.
No wonder this thread grew to 20+ messages. Is no one listening to what I'm saying?
For me it's neither A nor B, but C: leave "Effects" alone forever. It's perfectly logical and in place. Any arguments for "Effect" I've heard so far were very unconvincing.
And even if I agreed to the name change, of course disabling effects for the release because of this is simply out of the question.
Can we please drop this subject?
--- bulia byak <buliabyak@...400...> wrote:
On 6/3/06, Ben Fowler <ben.the.mole@...400...> wrote:
FWIW, I suspect that we may have to ask the parties who hold strong views, such as Alan, the Drivers such as Bulia and the Translators
to
give us pros and cons for two basic alternatives:
A. We agree that the present name "Effects" is wrong, but
delivering
Effects "On" in version 0.44 is so important that we will use this name (perhaps merely as a placeholder) and fix the UI in the next release.
B. We agree that a coherent UI is so important that we will leave Effects "Off" in version 0.44 and turn them on by default when the
UI
is fit for public use.
No wonder this thread grew to 20+ messages. Is no one listening to what I'm saying?
For me it's neither A nor B, but C: leave "Effects" alone forever. It's perfectly logical and in place. Any arguments for "Effect" I've heard so far were very unconvincing.
And even if I agreed to the name change, of course disabling effects for the release because of this is simply out of the question.
Can we please drop this subject?
Couldnt agree more, I still dont believe theres anything wrong with what we have. I agree we need to add the _ when we do 0.44.1, but the idea that we disable something as positive for the users as effects because of something so minor is just daft.
__________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
On Sat, 3 Jun 2006, bulia byak wrote:
Subject: Re: [Inkscape-devel] Inkscape 0.44 Hard Freeze
On 6/3/06, Ben Fowler <ben.the.mole@...400...> wrote:
FWIW, I suspect that we may have to ask the parties who hold strong views, such as Alan, the Drivers such as Bulia and the Translators to give us pros and cons for two basic alternatives:
A. We agree that the present name "Effects" is wrong, but delivering Effects "On" in version 0.44 is so important that we will use this name (perhaps merely as a placeholder) and fix the UI in the next release.
B. We agree that a coherent UI is so important that we will leave Effects "Off" in version 0.44 and turn them on by default when the UI is fit for public use.
No wonder this thread grew to 20+ messages.
The number of comments is an overly simplistic way to judge a conversation. Anway at least of third of the message were about ellipses but it does go to show how rough the extensions still are.
Is no one listening to what I'm saying?
Yes I am listening and continuing to respond but I'm not agreeing. You as a developer and very skilled technical user are biased, and it seems like you almost always take the counter point to what I suggest.
You have very good English but you are a non-native speaker and yet without hint of doubt and leaving little room for negotiation you are making strong statements on what you consider the correct label.
No interest at all was shown in report in the tracker. That may only show not enough people are reading the reports rather than not having any opinions but it still isn't good. (bulia does comment extensively in the tracker, this comment is directed at the other naysayers.)
For me it's neither A nor B, but C: leave "Effects" alone forever. It's perfectly logical and in place.
This is the precedence argument again. It does have a certain logic to it but so does my proposal so any claims of logic are moot.
The notion of commit first ask question later falls flat if there is no willingless to change things later.
Any arguments for "Effect" I've heard so far were very unconvincing.
The arguments are not being treated equally.
And even if I agreed to the name change, of course disabling effects for the release because of this is simply out of the question.
To say something is "out of the question" is unambiguously blunt and shows an unwillingness to discuss this. Is Inkscape to be run on a veto system because that is what your previous comment sounds like? Bryce was initially encouraging and there were several comments which didn't mind either way (which I intially though was bulias opinion too but in hindsight he was agreeing with a differnt part of the same message). A straw poll might suggest people prefer not to change but the argument was not definative, please step back if you do not care to discuss it further.
Can we please drop this subject?
When has that question ever worked in an online discussion?
Ben Fowler wrote:
FWIW, I suspect that we may have to ask the parties who hold strong views, such as Alan, the Drivers such as Bulia and the Translators to give us pros and cons for two basic alternatives:
A. We agree that the present name "Effects" is wrong, but delivering Effects "On" in version 0.44 is so important that we will use this name (perhaps merely as a placeholder) and fix the UI in the next release.
B. We agree that a coherent UI is so important that we will leave Effects "Off" in version 0.44 and turn them on by default when the UI is fit for public use.
(Apologies if this offends anyone identifiable above, and apologies if I missed off the name of anyone whose name I should have included).
As for the matter discussed, having done some work on the Greek translation, I think that it's pretty late for any changes now. However, if we have reached consensus that the name is going to change for 0.44 the sooner it changes the better because it gives more time for localization teams.
In Greek language, this is not an issue, both names ("effect" and "effects") will get translated into the very same string. The word used is a non-Greek noun (don't frown upon this Alan, all menu names are nouns in Greek translations - I don't know why!), so its singular and plural forms are the same.
Personally, when looking at menus nouns came first to mind. But of course I am not a native English speaker so that may not be true for everyone. I tend to agree with Bulia that Effects is better because it refers to many things (hence the plural).
Whilst I do have a view on this, which I will state if asked, personally I feel that UI is very, very important for Inkscape and we should either a) 'get it right', b) make it plastic - modifiable in later versions or c) state clearly that it highly subject to change over the next 55 releases (which is what I mean by public use).
Your idea is a good one, and I would encourage you to provide it, but please note that a UI that needs to be set by the end user is not one I would propose unless your users are emacs/Lisp aficionados.
Ben.
I proposed this in order to better handle case (b). I didn't have a set-everything-up-yourself design in mind, but instead thought more of having presets for various UI styles (like Inkscape native UI (the current one), Corel Draw UI, Adobe Illustrator UI, etc.). And if a user doesn't like the name of something, he can change it as he sees fit.
In this way, the UI decisions could be assigned to a different team that would, for example, use feedback form usability evaluations or apply human-computer interaction guidelines to get a more user-friendly and consistent feel in menus, dialog boxes and status bar messages.
- Spyros Blanas
Threads wont seem so long if you change the subject as necessary. Apologies to those whose mail clients dont support threading properly.
On Sat, 3 Jun 2006, Spyros Blanas wrote:
IMHO, this has gone too far. I mean, 20+ messages for what? For an "s"? Come on, you would all have fixed some bugs in the time it took to write all these e-mails. :-)
but complaining about he mails only adds more traffic, like long discussions about spam.
however I addressed several seperate issues in one mail which in part accounts for the length of the discussion.
Unfortunately until I brought up the issue the bug reports had received few if any comments and haven't received any additional comments since.
Having witnessed many discussions in the few months I am monitoring this list, it seems that UI is a hot issue.
This is a good thing, better to hammer out the issues here and write honest self aware release notes than gloss over flaws and wait until some reviewer bitches about it. Most projects claim to want feedback (many only really want patches though).
I am planning on working on a UI customizer (like OpenOffice and most KDE apps have) to allow a user to change the UI as he sees fit (adding extra menus, changing toolbars, changing shortcut keys).
Will be good to have.
I hope such functionality will make such issues easier to resolve and will actually lighten the burden on the devel team, so that it doesn't make permanent UI decisions (and gets the blame).
I dont think there was any question of blame but there is a tendency for whatever gets committed first to stick, the assumption being that whoever went before must have given it lots of thought.
Even then the question of good defaults remains and you still need to balance the needs of settings things up in a way that is friendly to beginners but without making it painful for more experienced users to set things up the way they prefer (think Firefox).
However, I am pretty busy for the next weeks and I will start looking into it after that. I can't guarantee anything, but judging from a very quick code sweep it certainly looks feasible.
Best of luck
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Sat, Jun 03, 2006 at 09:36:51PM +0300, Spyros Blanas wrote:
IMHO, this has gone too far. I mean, 20+ messages for what? For an "s"? Come on, you would all have fixed some bugs in the time it took to write all these e-mails. :-)
Sometimes these threads look more productive at the outset than they turn out. Certainly it is rare for Alan and Bulia to find themselves seeing eye to eye on a ui issue. But if nothing else this thread probably got a lot of people thinking more on ui issues.
I'm glad a concensus was reached that no change should be made prior to the release. Sounds like the concensus favors keeping Effects, but there seems to be less opposition to adding ellipses and shortcut keys as long as its done after 0.44.0.
I think it's important that we don't get too caught up in achieving absolute perfection right out of the gate. Our strength as an open source project, is optimization through iteration. Our challenge is to keep discussions civil and to stay open minded to new ideas.
Bryce
On Sat, 03 Jun 2006 00:21:35 +0200, Alan Horkan <horkana@...44...> wrote:
However given the tools available and the existence of fuzzy translations there isn't much benefit in dely this change which would be helpful to users. The actual impact of this or any other punctuation change on translators would only really be to throw off any statistics based on the translations but it probably wouldn't be a something the translators would be likely to complain about. (Although I suspect the translators are often too modest to complain, when in fact they would be doing users a favour by making the original texts easier to understand and translate.)
Please speak up now translators!
I would say that as there are several effects under this menu item and no effect related actions like in case e.g. for layer and Layer menu item, then I would keep "Effects". It has in my opinion better meaning for the purpose we use it. (it is not a proof of right form but also GIMP uses plural form for Filters menu item for example)
From a view of translator: This change(to "Effect"), if there is majority for the change, would be better introduced in 0.45(or 0.44.1) than in 0.44. Just to keep translations consistent with the original string and avoid fuzzyfication of it. As Matiphas trully said, strings marked as fuzzy in translations are shown in original form and not translated.
Sincerelly Josef "cornelius" Vybíral
On Sat, 3 Jun 2006, Josef Vybiral wrote:
On Sat, 03 Jun 2006 00:21:35 +0200, Alan Horkan <horkana@...44...> wrote:
Please speak up now translators!
I would say that as there are several effects under this menu item and no effect related actions like in case e.g. for layer and Layer menu item, then I would keep "Effects". It has in my opinion better meaning for the purpose we use it. (it is not a proof of right form but also GIMP uses plural form for Filters menu item for example)
gimp used to have a Layers menu in 1.2 but changed to Layer in 2.0 they are not the best example when it comes to usability especially since Inkscape deliberately broke away from the way Sodipodi (and by implication GIMP) does things.
photoshop uses the menu Filter not Filters and I put marginally more trust that the people who designed photoshop and the massive amounts of feedback they have gotten from the enormous userbase over the years.
From a view of translator: This change(to "Effect"), if there is majority for the change,
Majority is not usually the best way to make decisions. (Resisting the temptation to make comments about politics.)
0.44. Just to keep translations consistent with the original string and avoid fuzzyfication of it.
the question of fuzzy strings was only in relation to ellipses (...)
There effect menu needs a mnemonic anyway and both these changes should be made before effects are turned on by default.
On 6/3/06, Alan Horkan wrote:
From a view of translator: This change(to "Effect"), if there is majority for the change,
Majority is not usually the best way to make decisions. (Resisting the temptation to make comments about politics.)
Having Effects instead of Effect is not an issue for me. Not having mnemonic key for that menu is an issue for me. Whether the first or the second change is inroduced, the string will become fuzzy. This is not an issue for me again, since I've already finished translation and sent it to tracker, and so can do small adjustments to ru.po any time. Which may be different for other people. This is not majority/minority issue. This is presence of spare time issue :)
Alexandre
On Fri, 2 Jun 2006 ted@...11... wrote:
string and Glib::ustring will figure it out for me? Does any language have a different marking for this?
However, this might be worth fixing for 0.44.1. Alan, can you check that there's a bug in on this one?
Make sure to assign it to me.
After serveral aborted attempts here is the bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1499985&gro...
Sincerely
Alan Horkan
Inkscape http://inkscape.org Abiword http://www.abisource.com Open Clip Art http://OpenClipArt.org
Alan's Diary http://advogato.org/person/AlanHorkan/
On Jun 1, 2006, at 12:58 AM, matiphas@...8... wrote:
Just before moving to hard-freeze : is it possible to integrate the following patches ? 1498682 Update of czech.nsh 1498640 more Korean translation 1498252 French strings for windows installer 1495666 updated keys.fr 1494987 Spanish nhs translation 1493939 Easter Egg Tutorial 1493182 updated French calligraphy tutorial 1459716 translation of Tracing tutorial into Russian 1353260 Fix author name
So, what is the status of these?
All good? All needing to be in?
etc.
Jon A. Cruz schrieb:
On Jun 1, 2006, at 12:58 AM, matiphas@...8... mailto:matiphas@...8... wrote:
Just before moving to hard-freeze : is it possible to integrate the following
patches ?
1498682 Update of czech.nsh
1498252 French strings for windows installer
1494987 Spanish nhs translation
...
So, what is the status of these?
All good? All needing to be in?
etc.
Those win32 Installer related things are commited to the sources.
Adib. ---
1498640 more Korean translation
This one has been already committed
1495666 updated keys.fr
Ready to be committed I think
1493182 updated French calligraphy tutorial
This one needs to be committed by Scislac
1459716 translation of Tracing tutorial into Russian 1353260 Fix author name
1493939 Easter Egg Tutorial
This should be delayed according to some people on the list
IMO 1500058 Catalan default template Should also be committed
Regards,
matiphas
Hi,
On Wed, May 31, 2006 at 10:42:38PM -0700, Bryce Harrington wrote:
- We've gotten a bunch of reports from Debian Unstable users about Inkscape failing to run. This affects users of both old 0.43 and 0.44pre1. Dunno if this is a distro issue, or a gtk issue, or what, but probably needs more analysis. #1497837
I wanted to write about this today, since I got into some reasonable state with reports against debian's bts. There are some issues with debian ATM, but I don't think they are all distro specific:
1. debian bugs #369706 and #369608 http://bugs.debian.org/369706 http://bugs.debian.org/369608 These are against the version 0.43, but further investigation shows that this is not an inkscape but seemingly a libgc problem. It seems that inkscape crashes with the new version 6.7 of libgc. Well, it is not a crash exactly, it seems to be a dead lock. You start inkscape on the command line and nothing happens. If you attach to the process using strace, you get millions of
futex(0x10679060, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x10679060, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x10679060, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x10679060, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x10679060, FUTEX_WAIT, 2, NULL) = -1 EAGAIN (Resource temporarily unavailable) futex(0x10679060, FUTEX_WAIT, 2, NULL <unfinished ...> Process 32245 detached
I also just built the new pre1 and here inkscape simply segfaults. I think thatis problem is not debian-specific. It only shows up because debian unstable is the the first wider spread distro using this new version of libgc. Some more issues like this were reported to me privately and they all could be resolved by downgrading libgc. I'll reassign them to libgc, but nonetheless this leaves inkscape in debian in a very bad state.
2. debian bug #354698 http://bugs.debian.org/354698 This is a bug recognized mainly by users which use inkscape under kdae and have the debian package gtk2-engines-gtk-qt installed. The package is used for different theming of gtk applications under KDE. You have it if there is an item "appearance-->gtk styles and themes" in your KControl menu. It causes duplicate inclusion of themes via different rc-files. Yuya Nishihara found out that this leads to a crash if the theme uses the smooth engine of gtk. Other applications are affected by this, too. So again, it seems this is not inkscape's fault. I contacted the debian maintainer of gtk2-engines-smooth about that but got no reply yet.
3. debian bug #366323 http://bugs.debian.org/366323 Another crash, but I don't know anything about it. Still no way to reproduce and with the bug from 1. in place it's difficult to debug now. I think 1. must be fixed first.
There are other things in debians' BTS but I think these are the most important ones.
Thanks,
Wolfi
This is a CALL FOR ACTION. Distribute widely.
Wolfram wrote
- debian bug #354698 http://bugs.debian.org/354698 This is a bug recognized mainly by users which use inkscape under kdae and have the debian package gtk2-engines-gtk-qt installed. The package is used for different theming of gtk applications under KDE. You have it if there is an item "appearance-->gtk styles and themes" in your KControl menu. It causes duplicate inclusion of themes via different rc-files. Yuya Nishihara found out that this leads to a crash if the theme uses the smooth engine of gtk. Other applications are affected by this, too. So again, it seems this is not inkscape's fault. I contacted the debian maintainer of gtk2-engines-smooth about that but got no reply yet.
From the inkscape-0.44 Release Notes (Known Issues):
* Inkscape and other Gtk programs can crash on any Linux, when the gtk2-engines-smooth / libsmooth package is installed. We have filed a bug against libsmooth which is now in gtk-engine and part of gnome. Removing the package resolves the problem, however, but it would be nice if you as affected user would inform the gtk-engines maintainers of the problem. See especially http://bugzilla.gnome.org/show_bug.cgi?id=312115 (thanks to Thomas Wood)
Please please speak up at that URL! This is the most annoying issue we have with inkscape on SuSE systems and STILL package maintainers are not aware of it.
Do not ignore this issue. Pester those unresponsive folks with good bug reports. Publish this widely. I cannot believe such ignorance still exists after ONE YEAR.
R Stephan (sorry for shouting)
Hi Ralf,
On Fri, Jun 02, 2006 at 09:53:13AM +0200, Ralf Stephan wrote:
This is a CALL FOR ACTION. Distribute widely.
Wolfram wrote
- debian bug #354698 http://bugs.debian.org/354698 This is a bug recognized mainly by users which use inkscape under kdae and have the debian package gtk2-engines-gtk-qt installed. The package is used for different theming of gtk applications under KDE. You have it if there is an item "appearance-->gtk styles and themes" in your KControl menu. It causes duplicate inclusion of themes via different rc-files. Yuya Nishihara found out that this leads to a crash if the theme uses the smooth engine of gtk. Other applications are affected by this, too. So again, it seems this is not inkscape's fault. I contacted the debian maintainer of gtk2-engines-smooth about that but got no reply yet.
From the inkscape-0.44 Release Notes (Known Issues):
* Inkscape and other Gtk programs can crash on any Linux, when the gtk2-engines-smooth / libsmooth package is installed. We have filed a bug against libsmooth which is now in gtk-engine and part of gnome. Removing the package resolves the problem, however, but it would be nice if you as affected user would inform the gtk-engines maintainers of the problem. See especially http://bugzilla.gnome.org/show_bug.cgi?id=312115 (thanks to Thomas Wood)Please please speak up at that URL! This is the most annoying issue we have with inkscape on SuSE systems and STILL package maintainers are not aware of it.
Sorry for replying that late. I just had a look to the cited URL, but it doesn't seem to be related to this issue. It shows a bug entitled "SmoothFreeArrowStyles() in libsmooth.so" which was closed in march. Nobody there mentions inkscape or SuSE there. The one open in debian's BTS seems to be different than this one and I did not find a bug related bug in gtk-themes bugzilla at a short glance. Could you please provide the correct link or explain the relationship between these bugs?
Thanks,
Wolfi
Do not ignore this issue. Pester those unresponsive folks with good bug reports. Publish this widely. I cannot believe such ignorance still exists after ONE YEAR.
R Stephan (sorry for shouting)
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
You wrote
Removing the package resolves the problem, however, but it would be nice if you as affected user would inform the gtk-engines maintainers of the problem. See especially http://bugzilla.gnome.org/show_bug.cgi?id=312115 (thanks to Thomas Wood)Please please speak up at that URL! This is the most annoying issue we have with inkscape on SuSE systems and STILL package maintainers are not aware of it.
Sorry for replying that late. I just had a look to the cited URL, but it doesn't seem to be related to this issue. It shows a bug entitled "SmoothFreeArrowStyles() in libsmooth.so" which was closed in march. Nobody there mentions inkscape or SuSE there.
I was not aware this was closed already. I'm quite sure, however, that that bug at least caused some problems with inkscape. I cannot reproduce it here anymore, unfortunately.
So, to think of it, I'll withdraw my appeal and ask the release managers to remove that URL from the Release Notes.
ralf
participants (18)
-
unknown＠example.com -
Aaron Spike -
Adib Taraben -
Alan Horkan -
Alexandre Prokoudine -
Ben Fowler -
Bryce Harrington -
bulia byak -
john cliff -
John Cliff
-
Jon A. Cruz -
Josef Vybiral -
Joshua A. Andler -
Matiphas -
Ralf Stephan -
Spyros Blanas -
Ted Gould -
Wolfram Quester