Re: Fwd: NSView patch

2009-02-26 Thread Fred Kiefer 
Matt Rice wrote:
 I don't think that will work because I'm also seeing rounding errors on
 the isect = NSIntersectionRect(...) calls... though not in the stuff i
 sent earlier for some reason... not sure why...
 but that would also only work when displaying whole views,
 and i take it you don't like the idea of just using
 GSAlmostEqualRects() in NSView?
 
 here's 2 test cases, bar.app is the minimal one and another one that
 allows you to drag the purple view around by clicking on it, and
 resize it by clicking the black square, rotate and scale and all that
 other stuff... (note that scaling doesn't seem to work until its been
 rotated)
 the one thing it doesn't do is allow you to set the origin at
 non-integer increments unless whatever input device your using gives
 non-integer coordinates (i don't appear to have one)
 if its not reproducable I could add something like a NSStepper to
 increment the deal by the value of the value of the top slider or
 something...
 
 after adding some NSLog's to NSView
 
 2009-02-24 21:34:36.263 bar[10292] subviewFrame
 displayRectIgnoringOpacity:inContext: BarView: 0x24cbd70
 
 146.749039 205.641785 118.00 54.00
 
 2009-02-24 21:34:36.263 bar[10292] aRect
 displayRectIgnoringOpacity:inContext: BarView: 0x24cbd70
 
 0.00 0.00 700.00 500.00
 
 2009-02-24 21:34:36.271 bar[10292] isect before conversion
 displayRectIgnoringOpacity:inContext: BarView: 0x24cbd70
 
 146.749039 205.641785 117.85 54.00
 
 
 2009-02-24 21:34:36.271 bar[10292] isect after conversion
 displayRectIgnoringOpacity:inContext: BarView: 0x24cbd70
 
 0.00 0.00 117.85 54.00
 
 now i could probably work around this by just flooring the points, but
 i am hesitant to work around things in gui for fear they will be
 forgotten,
 and go unnoticed give someone else the joy of rediscovering this..

Thank you for that great test application. It is already my favourite. I
will port it over to my Apple and use it there to fix more display bugs
in GNUstep. And then use it with all our backends.


___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Re: [Gnustep-cvs] r27911 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m

2009-02-26 Thread Fred Kiefer 
Hi Greg,

this look was what I actually wanted to achive :-)
Looks like we don't have a case of not working code, but different
goals. We better start out by defining the problem, listing possible
solutions and then arguing for or against them.

The problem I see is that we have a duplication of menu reorganisation
code. Once for switching between horizontal and vertical and another one
for loading NIB files. This duplication is bad in itself and will lead
to inconsistencies when switching a loaded NIB menu to horizontal (and
back again).

My solution was to bring the NIB menu as close to the way the menu of
normal GNUstep application looks. That is have on the main menu an info
item (could also be a sub menu), at the very bottom the quit item and
above that the services and hide items, if any. In the info sub menu all
the other entries from the application sub menu of the NIB file get
collected.

The way I implemented that was to look for the Services entry and move
everything above that into the info submenu and everything below in the
main menu. If you take a look at the main menu of Gorm you will notice
almost looks like the one you reject. The only differences are that the
converted menu also has some separator items and two additional
hide/show entries.

You could argue now that the normal menu layout of GNUstep menus is bad.
This is a possible point of view, but then we again should try to find a
shared view on how to organise menus. Perhaps we can even move the menu
reorganisation into a theme?

As for the difference to the original code. When I tried to switch of
your code the first time without any changes to NSMenu, it ended up with
the Services item being the first one and all of the entries that are
now gathered in the info submenu being at the end of the main menu. I
hope you find my solution better than that.

What looks wrong in my implementation is that the menu has the title
MainMenu, that needs to be changed. I don't remember that happening to me.


Fred

Gregory Casamento wrote:
 I have attached how it looks using the new code
 (Flexisheet_organizeMenu.jpg).   I'm not seeing any difference between
 that and how it looked before.
 
 For reference, with my code, it looks like the attached file
 Flexisheet_gsnibcode.jpg.
 
 Thanks, GC
 
 On Tue, Feb 24, 2009 at 5:35 PM, Fred Kiefer fredkie...@gmx.de
 mailto:fredkie...@gmx.de wrote:
 
 Gregory Casamento wrote:
  Author: gcasa
  Date: Wed Feb 18 08:38:02 2009
  New Revision: 27911
 
  URL: http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev
 http://svn.gna.org/viewcvs/gnustep?rev=27911view=rev
  Log:
* Source/GSNibLoading.m: Rollback of previous change.  Found a
minor problem.
 
  Modified:
  libs/gui/trunk/ChangeLog
  libs/gui/trunk/Source/GSNibLoading.m
 
 Greg,
 
 could you please explain why you had to undo this change? If there was a
 problem I am willing to help fixing it. I did not remove this code
 myself, as I wanted to give you enough time to check, whether my
 replacement was working.
 I really would like to the see this code here go away.
 



___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev