gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnustep-cvs] r28206 - in /libs/gui/trunk: ChangeLog Source/GSWindow


From: Fred Kiefer
Subject: Re: [Gnustep-cvs] r28206 - in /libs/gui/trunk: ChangeLog Source/GSWindowDecorationView.m
Date: Mon, 13 Apr 2009 20:32:41 +0200
User-agent: Thunderbird 2.0.0.19 (X11/20081227)

With fallback values I meant you added 0 initialization.
What I wanted to find out was in which code path we could end up with
this values not getting assigned to. In the meantime I spend a lot of
thinking on where this could happen (all backends always assign to these
values), the only idea I have up to now is when GSCurrentServer()
returns nil. Most likely this is the case you are fixing.

Fred

Gregory Casamento wrote:
> The code (as it was previously) was initializing the values to random
> values.  It was causing an over abundance of "given negative
> height/width" errors to appear when they didn't have to.
> 
> I'm not sure what you mean by a fallback value... do you mean something
> that is non-zero?
> 
> GC
> 
> On Mon, Apr 13, 2009 at 12:08 PM, Fred Kiefer <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     Gregory Casamento wrote:
>     > Author: gcasa
>     > Date: Mon Apr 13 01:17:49 2009
>     > New Revision: 28206
>     >
>     > URL: http://svn.gna.org/viewcvs/gnustep?rev=28206&view=rev
>     <http://svn.gna.org/viewcvs/gnustep?rev=28206&view=rev>
>     > Log:
>     >       * Source/GSWindowDecorationView.m: initialize offsets to prevent
>     >       negative value warnings suggested by Doug.
>     >
>     > Modified:
>     >     libs/gui/trunk/ChangeLog
>     >     libs/gui/trunk/Source/GSWindowDecorationView.m
> 
>     Could you please give an example of a case where this code makes a
>     difference?
>     The code is surely correct, why not add a fallback value. What interests
>     me is when this is needed, as this shows we are not properly taking care
>     of some cases and perhaps there is even a better way to do so, than
>     these default values.
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]