On 10/16/05, jiho <jo.irisson@...400...> wrote:
On 15 oct. 05, at 20:23, Ben Fowler wrote:
On 10/15/05, jiho <jo.irisson@...400...> wrote:
On 15 oct. 05, at 18:34, Ben Fowler wrote:
On 10/15/05, bulia byak <buliabyak@...400...> wrote:
On 10/15/05, Ben Fowler <ben.the.mole@...400...> wrote:
Having said that, perhaps Inkscape compiled in debug mode should have some of these artifical limits, (just as we have assertion statements). It will help identify to developers just where the shoe pinches, but users do not need to handle this.
If they could, why not? Once you pointed me to the problem the fix was really easy. Having that build into inkscape would have avoided you all my long emails ;-)
Not really, the root cause of this e-mail conversation (maybe lengthy, but not unnecessary) is the fact that Inkscape did not gracefully handle a specific error condition. This wasn't deliberate. It was just that the precise combination of circumstances that brings it about had not occurred to any of the developers who had worked on that part of the code.
Bringing this up up was very necessary. This kind of bug report is one of the most important raw materials needed for the production of good software.
Now, release versions should not have 'articifical limits' or training wheels.
Th assumption is that if the Application is in an unexpected state with a developer, it is because he or she got something wrong, and we want the earliest indication of when this is happening. If the application is in an unexpected state with a user, then the user is probably 'in the right' and merely doing something that hadn't been tested or anticipated.
In the present case, if a scale factor exceeds 1 million, we are going to guess that on a developer's machine there is something wrong the code, but on a user's machine that he or she is simply working with large objects.
Ben