Misc. comments

[Malmberg]

Hi all,

A few comments from a 'new developer' (heard you wanted some of those):

- I work quite a lot with 3d-rendering and modelling, so I often use
ridiculously high resolutions. Thus, the GUI really must be resolution
independent (resolution as in dpi). How is this supposed to be handled
in GNUstep? Is the backend supposed to rescale everything transparently
(so dimensions given in a program are really 1/72's of an inch, not
pixels), or are the widgets supposed to take font sizes into account
when calculating their sizes?

- There's a bug in the menu title drawing that occurs when anything less
than the entire title bar is redrawn. This patch seems to take care of
it (tell me if you have any preferred diff format):

Index: gui/Source/NSMenu.m
===================================================================
RCS file: /gnustep/gnustep/core/gui/Source/NSMenu.m,v
retrieving revision 1.77
diff -r1.77 NSMenu.m
1378,1379c1378,1380
<   
<   PSmoveto(rect.origin.x + 7, rect.origin.y + 7);
---
> 
>   workRect=[self bounds];
>   PSmoveto(workRect.origin.x + 7, workRect.origin.y + 7);

- Focus handling in WindowMaker is messed up with GNUstep programs (but
you already knew that). I've made my problems go away by removing a
check for a gnustep app in wSetFocusTo (actions.c, line ~240) around a
call to wWindowFocus. I'm not sure if it fixes everything, though,
handling of gnustep programs in there seems generally chaotic and
inconsistent.

- Scrolling an NSClipView messes up at times. Specifically, the copy
won't work if the entire clipview isn't visible, and it won't work if
the scroll delta isn't an integer. Related to this is a problem with
snapping coordinates to integers in device space when scrolling (done in
constrainScrollPoint:). E.g. coordinates in the clipview like (10,10)
get converted to (9.5,9.5) in device space, snapped to (9,9), and
converted back to (9.5,9.5). If you scroll in one direction, the other
will slowly drift towards 0 due the repeated converting and snapping.
Maybe it'd be better to separate 'real' scroll coordinates and drawing
coordinates, so drawing coordinates could be kept to integers to make
copying work, and the 'real' coordinates wouldn't move around from all
the converting back and forth.

- On my system (Linux 2.0.36 based kernel), there is a /proc/self/exe
link, but it points to '[device]:inode', so when NSBundle tries to get
the executable's directory from it, it fails (NSBundle.m, line ~543),
along with all resource loading. Simply undefining HAVE_PROC_FS_EXE_LINK
solves all problems, since it then uses the methods in NSProcessInfo.

- Alexander Malmberg <alexander@malmberg.org>