Fw: Remaining critical bugs for 0.45
These two are related one to each other, and are very naughty.
1617082 Blur UI usablity issues 1629816 blur incremented by pixels
Because of the way blur is calculated, it cannot be smoothly applied to any object sizes. These are (at least for me as a designer) showstoppers as the whole usability of the "main new function" is under question...
On the other side I have no clue about how difficult is a redesign of that behaviour, so probably the blur function will make its way to 0.45 release with the actual behaviour...
Molumen
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "Bryce Harrington" <bryce@...961...> Cc: <inkscape-devel@...6...> Sent: Wednesday, January 10, 2007 10:40 AM Subject: Re: [Inkscape-devel] Remaining critical bugs for 0.45
I think these are certainly stoppers:
1630485 Inkview don't support blur / crashes 1575829 Metadata are truncated at 4 chars and add a char 18 hexa
Dunno about other listed as "crashers". Actually, I would like to caution people against overzealous bug fixing at this point. To avoid destabilizing, please concentrate either on serious crash bugs or on bugs which can be fixed as unintrusively as possible. Some of the bugs Bryce listed a more of RFEs than bugs, and now is certainly not the right time to work on them in the trunk (of course you can work on them locally to commit when 0.45 is out).
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=D... _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
On 1/10/07, momo <momo@...1386...> wrote:
These two are related one to each other, and are very naughty.
1617082 Blur UI usablity issues 1629816 blur incremented by pixels
Because of the way blur is calculated, it cannot be smoothly applied to any object sizes.
Can you please elaborate? How smooth you need it to be? The 0.1% increment is not smooth enough?
0.1% is more than enough, but the problem is in the fact that it cannot be set. In 1617082 "Blur UI usablity issues" I described the behaviour of the blur function, and there is no possibility to set amounts as trivial as 11%, or 12% for certain object sizes. I will prepare now a screen video and post a link to the list so you can see what I'm trying to explain.
thanks, Molumen
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "momo" <momo@...1386...> Cc: inkscape-devel@lists.sourceforge.net Sent: Wednesday, January 10, 2007 4:11 PM Subject: Re: [Inkscape-devel] Fw: Remaining critical bugs for 0.45
On 1/10/07, momo <momo@...1386...> wrote:
These two are related one to each other, and are very naughty.
1617082 Blur UI usablity issues 1629816 blur incremented by pixels
Because of the way blur is calculated, it cannot be smoothly applied to any object sizes.
Can you please elaborate? How smooth you need it to be? The 0.1% increment is not smooth enough?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 1/10/07, momo <momo@...1386...> wrote:
0.1% is more than enough, but the problem is in the fact that it cannot be set. In 1617082 "Blur UI usablity issues" I described the behaviour of the blur function, and there is no possibility to set amounts as trivial as 11%, or 12% for certain object sizes.
No. In that bug, you describe the behavior of the blur slider. That has nothing to do with "the way blur is calculated" as you seem to imply. It's just the GTK slider behavior, nothing else.
That's why you have both the slider _and_ the spinbutton there. The slider is for quick and dirty adjustments, the spinbutton is for precise adjustments if you need them. The precision of the spinbutton is 0.1% and you can _always_ set _any_ radius with that precision, just by typing it and pressing Enter. This works always; if it does not for you, please give me the detailed steps to reproduce.
Besides, I cannot repeat some of the slider misbehaviors that you describe. Yes, the slider jumps in rather crude steps as you drag it, but I am always able to drag it all the way to 0% or 100%. Also I do not see any difference in the slider behavior depending on the size of the object; if you do, please give more details and a sample file.
Finally, I will repeat what I wrote in that bug: we do NOT do anything special with that slider. It's just a stock GTK widget. (By now I even disabled display interruptibility while you adjust blur, so you can't blame the bugs on it.) So if it is weird or inconvenient (and it is, no doubt about that), that's something to discuss with GTK developers.
Bulia wrote:
The precision of the spinbutton is 0.1% and you can _always_ set _any_ radius with that precision, just by typing it and pressing Enter. This works always; if it does not for you, please give me the detailed steps to reproduce.
1. Open the attached file "blur.svg". 2. Select the rectangle and open the "Fill and Stroke" dialog. 3. Type 12% for blur and press enter. 4. The value is set to 11,8. When clicking on the canvas the value becomes 11,5.
This is stable reproducible behavior for me on SVN head.
-Johan
On 1/10/07, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
- Open the attached file "blur.svg".
- Select the rectangle and open the "Fill and Stroke" dialog.
- Type 12% for blur and press enter.
- The value is set to 11,8. When clicking on the canvas the value becomes 11,5.
For me this works fine. I set 12% and it stays that way. See attached blur-12.svg.
What version of GTK you have? If it's on Windows, can you give me a link to your build so I could test it on Windows too?
Anyone else seeing this?
Weird.
Maybe it's something with your locale? Can you run it in default English locale? Though I tried several non-English locales and I still cannot reproduce this.
On 1/10/07, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
Bulia wrote:
The precision of the spinbutton is 0.1% and you can _always_ set _any_ radius with that precision, just by typing it and pressing Enter. This works always; if it does not for you, please give me the detailed steps to reproduce.
- Open the attached file "blur.svg".
- Select the rectangle and open the "Fill and Stroke" dialog.
- Type 12% for blur and press enter.
- The value is set to 11,8. When clicking on the canvas the value becomes 11,5.
This is stable reproducible behavior for me on SVN head.
-Johan
On 1/10/07, bulia byak wrote:
Maybe it's something with your locale? Can you run it in default English locale? Though I tried several non-English locales and I still cannot reproduce this.
I played with blur yesterday and I saw this effect all the road. I have gtk 2.10.7. The locale is ru_RU.UTF-8.
Alexandre
It's not locale related. I tried all the january releases (including today's Inkscape0701011510.7z) with several locales set, with all the computers we have here at the studio (Win XP SP2 english and czech version, Win2K english) and it always behave the same.
With a 10x10px object the blur slider snaps to only 20-40-60-80-100% When inputing any other amount it jumps to the smaller closest value. Also when I enter for example 15%, it jumps to 0% but the object stays blurred.
Here's a link to a flash video showing this behaviour: www.lumenstudio.net/if/10by10object.swf.html (around 800Kb)
Molumen
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: <J.B.C.Engelen@...1578...> Cc: <momo@...1386...>; inkscape-devel@lists.sourceforge.net Sent: Wednesday, January 10, 2007 5:34 PM Subject: Re: [Inkscape-devel] Fw: Remaining critical bugs for 0.45
Maybe it's something with your locale? Can you run it in default English locale? Though I tried several non-English locales and I still cannot reproduce this.
On 1/10/07, J.B.C.Engelen@...1578... <J.B.C.Engelen@...1578...> wrote:
Bulia wrote:
The precision of the spinbutton is 0.1% and you can _always_ set _any_ radius with that precision, just by typing it and pressing Enter. This works always; if it does not for you, please give me the detailed steps to reproduce.
- Open the attached file "blur.svg".
- Select the rectangle and open the "Fill and Stroke" dialog.
- Type 12% for blur and press enter.
- The value is set to 11,8. When clicking on the canvas the value
becomes 11,5.
This is stable reproducible behavior for me on SVN head.
-Johan
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 1/10/07, momo <momo@...1386...> wrote:
It's not locale related. I tried all the january releases (including today's Inkscape0701011510.7z) with several locales set, with all the computers we have here at the studio (Win XP SP2 english and czech version, Win2K english) and it always behave the same.
OK, and I just tested the last build on Win XP and I still don't see anything remotely like this.
What's going on?
There appears to be a bug introduced in .44 (running on Ubuntu Edgy) in the text edit dialog where the style list doesn't reflect the current style - rather it defaults to the top style. So if you have bold text and open up the edit dialog, change the font size and save - it will be set as plain (not bold). The other list boxes for font family and text size seem to work fine. Not sure if this got addressed in .45 yet.
jtaber wrote:
There appears to be a bug introduced in .44 (running on Ubuntu Edgy) in the text edit dialog where the style list doesn't reflect the current style - rather it defaults to the top style. So if you have bold text and open up the edit dialog, change the font size and save - it will be set as plain (not bold). The other list boxes for font family and text size seem to work fine. Not sure if this got addressed in .45 yet.
See: http://sourceforge.net/tracker/index.php?func=detail&aid=1610944&gro... It is fixed for 0.45.
:) Johan
Another thing about the behaviour of the Blur function: With a simple shape (a newly created circle for example) the blur behaves normally
With a more complicated object (see attachment) the behaviour is a the one I described in my previous posts and bugs #1629816 and #1617082
Molumen
----- Original Message ----- From: <J.B.C.Engelen@...1578...> To: <buliabyak@...400...>; <momo@...1386...> Cc: inkscape-devel@lists.sourceforge.net Sent: Wednesday, January 10, 2007 5:20 PM Subject: RE: [Inkscape-devel] Fw: Remaining critical bugs for 0.45
Bulia wrote:
The precision of the spinbutton is 0.1% and you can _always_ set _any_ radius with that precision, just by typing it and pressing Enter. This works always; if it does not for you, please give me the detailed steps to reproduce.
1. Open the attached file "blur.svg". 2. Select the rectangle and open the "Fill and Stroke" dialog. 3. Type 12% for blur and press enter. 4. The value is set to 11,8. When clicking on the canvas the value becomes 11,5.
This is stable reproducible behavior for me on SVN head.
-Johan
On 1/10/07, momo <momo@...1386...> wrote:
Another thing about the behaviour of the Blur function: With a simple shape (a newly created circle for example) the blur behaves normally
With a more complicated object (see attachment) the behaviour is a the one I described in my previous posts and bugs #1629816 and #1617082
So, are you saying this mysterious bug depends on _shape_, too? :)
However, in the attached file, the path is 10px in size but its blur is 44.1% - how did you manage to set it, if it snaps to 10% increments as you say?
(needless to say, I can set any amount of blur to any of these two objects)
However, in the attached file, the path is 10px in size but its blur is 44.1% - how did you manage to set it, if it snaps to 10% increments as you say?
The object on the left renders like showed on the attached screenshot (it has a square blur shape) and blur has an increment of 24,7%. Can't tell you why or how that happened, I can just report what I get. The one on the right had an increment of 20%.
So, are you saying this mysterious bug depends on _shape_, too? :)
Bulia, Looks like you don't really want to take my reports seriously, so I'll stop loosing time reporting. I posted a video showing the bug in action, I posted a bug report, I made all I can to explain this bug's behaviour, so if someone else (Johan?) want to continue reporting, please do so. It'll be sad to see that behaviour in 0.45 release on Windows...
Molumen
----- Original Message ----- From: "bulia byak" <buliabyak@...400...> To: "momo" <momo@...1386...> Cc: inkscape-devel@lists.sourceforge.net Sent: Wednesday, January 10, 2007 7:00 PM Subject: Re: [Inkscape-devel] Fw: Remaining critical bugs for 0.45
On 1/10/07, momo <momo@...1386...> wrote:
Another thing about the behaviour of the Blur function: With a simple shape (a newly created circle for example) the blur behaves normally
With a more complicated object (see attachment) the behaviour is a the one I described in my previous posts and bugs #1629816 and #1617082
So, are you saying this mysterious bug depends on _shape_, too? :)
However, in the attached file, the path is 10px in size but its blur is 44.1% - how did you manage to set it, if it snaps to 10% increments as you say?
(needless to say, I can set any amount of blur to any of these two objects)
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 1/10/07, momo <momo@...1386...> wrote:
However, in the attached file, the path is 10px in size but its blur is 44.1% - how did you manage to set it, if it snaps to 10% increments as you say?
The object on the left renders like showed on the attached screenshot (it has a square blur shape) and blur has an increment of 24,7%. Can't tell you why or how that happened, I can just report what I get. The one on the right had an increment of 20%.
OK, now I'm totally confused. In the attached file, you have blur values of 0.5% (left) and 44.1% (right). I don't understand how they got those values if they have those increments as you say.
Note: I'm not doubting your report, I'm just trying to understand it, and trying to understand it involves trying to find logic in what you're seeing (and what I'm not seeing). So don't get offended if I appear to be looking for inconsistencies in your reports. It's all part of trying to understand what's going on.
So, are you saying this mysterious bug depends on _shape_, too? :)
Bulia, Looks like you don't really want to take my reports seriously, so I'll stop loosing time reporting. I posted a video showing the bug in action, I posted a bug report, I made all I can to explain this bug's behaviour, so if someone else (Johan?) want to continue reporting, please do so. It'll be sad to see that behaviour in 0.45 release on Windows...
It's a pity you got such impression. As I said, I'm just trying to understand, and yes, some of your first reports did seem somewhat incomplete or inconsistent to me. The movie helped, but then the shape of the object got into play and I got confused again. Lastly, the square clipping of the blur in your screenshot looks like another bug which I cannot reproduce either.
Anyway, you're right, don't waste time on me :) Since I cannot reproduce or even understand it, it's not likely that I will be able to find a fix. Let's hope someone will be able to fix it eventually.
Has a bug been filed, ideally including the movie as an attachment, so that this issue doesn't get forgotten?
It's entirely possible that the issue manifests itself under some circumstances and not others (e.g. depending on the complexity of the object and the speed of the user's machine), but as bulia says, it's going to be difficult to fix until a developer manages to observe it live with a debugger up.
Filing the bug will help make sure that other developers get a crack at it.
I think we should focus on this for 0.45, but if it turns out to be very difficult to replicate and/or fix, probably what will happen is that we release 0.45 as-is, and address this along with any other missed bugs in a follow-up 0.45.1 release. That's often been the way we've had to do things in the past.
-mental
One additional bit of information which might be useful: the relative speed of the machines on which we've seen it happen, and those we haven't.
With latest trunk, I can't duplicate the issue on my Celeron 500. bulia and Molumen, how fast are your respective machines?
-mental
On 1/10/07, MenTaLguY <mental@...3...> wrote:
With latest trunk, I can't duplicate the issue on my Celeron 500. bulia and Molumen, how fast are your respective machines?
1200Mhz Linux desktop, 1600Mhz WinXP laptop
With latest trunk, I can't duplicate the issue on my Celeron 500. bulia and Molumen, how fast are your respective machines?
-mental
WinXP, P4 2.8GHz, 2.00Gb RAM desktop WinXP, P4 3.2GHz, 1.00Gb RAM desktop Win2000, AMD Duron 1.7GHz, 512 Mb RAM desktop WinXP, AMD Athlon 3.2GHz, 2.00Gb RAM desktop WinXP, Intel Core 2 Duo T5500 (1.66Ghz), 1.00Gb RAM laptop
Molumen
On Wed, Jan 10, 2007 at 02:28:36PM -0500, MenTaLguY wrote:
Has a bug been filed, ideally including the movie as an attachment, so that this issue doesn't get forgotten?
Yes, there is a bug report in on it - the bug id was referenced in the initial post. (Btw, for future reference, when discussing bugs on the mailing list, it would be immensely helpful to preserve the bug ID, either in the subject line or the body.)
Momo, thanks for taking the time to create a movie of what you're seeing; it demonstrates very clearly the effect. I attempted to recreate it but like Bulia was unable to do so on my machine. What would be ideal is if we could find a second person who can reproduce it, and then we can see what is common between their environment and yours - and what is difference between yours and those who can't reproduce it.
I think we should focus on this for 0.45, but if it turns out to be very difficult to replicate and/or fix, probably what will happen is that we release 0.45 as-is, and address this along with any other missed bugs in a follow-up 0.45.1 release. That's often been the way we've had to do things in the past.
While this is certainly an annoying bug to have in this new feature, I don't think it meets the criteria for being a MUST FIX bug. It does not cause crashes or data loss - just annoying usability issues. We also do not yet have a developer who can reproduce it and take ownership of it.
I know it seems bad to release a new feature with some bugs remaining it it, but like mental says, this is not new. New features are rarely perfect right out of the gate, and getting all the polish into them can stretch out a long time. If we waited until they were perfect, we'd have to delay the release far too long, so it's often preferred to release with the features most of the way there. The layers feature is just such an example - the core functionality was created in one release, but it took 2-3 more releases before we had a layer dialog and all the assorted niceties to go with it.
For this release, with the blur feature it is crashes we should be most worried about. I think people will tolerate some quirkiness of a new feature (as long as we iron out the quirks in a subsequent release), but crashes will really sour them to the feature.
Bryce
On 1/10/07, Bryce Harrington wrote:
On Wed, Jan 10, 2007 at 02:28:36PM -0500, MenTaLguY wrote:
Has a bug been filed, ideally including the movie as an attachment, so that this issue doesn't get forgotten?
Yes, there is a bug report in on it - the bug id was referenced in the initial post. (Btw, for future reference, when discussing bugs on the mailing list, it would be immensely helpful to preserve the bug ID, either in the subject line or the body.)
Momo, thanks for taking the time to create a movie of what you're seeing; it demonstrates very clearly the effect. I attempted to recreate it but like Bulia was unable to do so on my machine. What would be ideal is if we could find a second person who can reproduce it, and then we can see what is common between their environment and yours
-
and what is difference between yours and those who can't reproduce it.
I can reproduce it. What information exactly do you need?
Alexandre
On 1/30/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
I can reproduce it. What information exactly do you need?
Can you recompile? If so I'd send you some testing patches to figure out what's going on.
On 1/31/07, bulia byak wrote:
On 1/30/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
I can reproduce it. What information exactly do you need?
Can you recompile? If so I'd send you some testing patches to figure out what's going on.
Yes, I can.
Alexandre
On 1/31/07, bulia byak wrote:
On 1/30/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
I can reproduce it. What information exactly do you need?
Can you recompile? If so I'd send you some testing patches to figure out what's going on.
So, no patches? :)
Alexandre
On 2/2/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
On 1/31/07, bulia byak wrote:
On 1/30/07, Alexandre Prokoudine <alexandre.prokoudine@...400...> wrote:
I can reproduce it. What information exactly do you need?
Can you recompile? If so I'd send you some testing patches to figure out what's going on.
So, no patches? :)
I don't have access to my development machine right now. Please wait a couple days.
participants (7)
-
unknown＠example.com -
Alexandre Prokoudine -
Bryce Harrington -
bulia byak -
jtaber -
MenTaLguY -
momo