Backend <-> GUI Library Interaction

[Christopher Armstrong]

Hi

There are outstanding issues with the windows backend related to window
management. I believe some of these can be fixed by responding to
certain Win32 window messages that MSWindows posts out. I am referring
to the problems with window layering/levels/ordering and related focus
issues that seem to affect everything from windows going missing to
modal windows playing up. 

There are some methods which appear in GSDisplayServer that appear to
relate to these things. Without checking in detail what gnustep-gui
does, could I get some clarifications on how the following methods work
in response to certain inputs/outputs.

- (void) orderwindow: (int) op : (int) otherWin : (int) winNum

This one does appears to do window ordering (to state the bleedingly
obvious). Obviously when a window is ordered it should obey the window
level that is set. 

Take a hypothetical situation with three windows:

A - window level 0
B - window level 50
C - window level 0

C is above A. B is on top of A & C (in terms of Z-order).

if orderwindow was called to place A on top of B, should it order A to
the top of its window level (i.e. between C and B) or should it ignore
the message? 

Say the reverse happened (orderwindow was called asking it to order a a
lower level window above a higher level window), what should occur in
that case? The backend currently does what gnustep-gui tells it to do,
ignoring window layering.

In the AppKit, there are two notifications,
NSApplicationDidBecomeActiveNotification and its counterpart
NSApplicationWillBecomeActiveNotification. Are these supposed to be sent
through an application when one of it's windows is made "active" (i.e.
becomes key)? Or is it when an application begins responding to event
messages?

- (void) setinputfocus: (int) winNum

In GNUstep parlance there appear to be two things: a key window (which
responds to keyboard events) and a main window. Is this correct? How
exactly does a main window fit into the window focus equation? Is
setinputfocus: supposed to main a window "key"? If a window is not to
become the key window (e.g. some floating palette windows), does
gnustep-gui take messages from the backend that the window was made the
key window, and respond by making another window the key window?

Win32 provides some window messages such as WM_ACTIVATE (a window in an
application was given/lost the keyboard focus), WM_ACTIVATEAPP (your
application itself lost/gained the keyboard focus) and
WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED (called for a litany of window
resize/move/focus/Z-order events where the outcome can be "adjusted"). I
think these could help.

Does anyone have some guidance on this matter? I would like to start
investigating some fixes so that perhaps I could get this working on
Windows properly.

Cheers
Chris
-- 
  Christopher Armstrong
  [EMAIL PROTECTED]



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

Re: Backend <-> GUI Library Interaction

[Christopher Armstrong]

Richard Frith-Macdonald wrote:


On 7 Nov 2006, at 08:11, Christopher Armstrong wrote:


Hi

Richard Frith-Macdonald wrote:


That's interesting, I thought the only way a window could change 
window

levels was by the setwindowlevel: message.


I thought the same until I checked.  The documentation suggested 
that behavior but was not completely explicit, so I looked at the X 
backend code to confirm it.
The other interpretation (that ordering of windows relative to each 
other only worked for windows in the same level) seems a bit more 
intuitive to me.


It actually might be worth checking what MacOS-X actually does, and 
consider changing the GNUstep behavior if it does it the other way.


There seems to be a little debate about this one (re: message from 
Sheldon Gill). I'll have to dig a bit deeper on this, but I think the 
MacOSX notes are ambigious too (IIRC).


Well, in answering your question about the gui/backend interaction in 
GNUstep, Sheldon has just said how he thinks it *should* behave rather 
than how it *does* behave.  If you want to 'fix' the windows backend 
to work better with the gui now, you need to implement the actual 
behavior rather than a potential future behavior.


However, his idea of how it should behave is perfectly reasonable ... 
and I would probably support moving to it if (and only if) it's the 
way MacOS-X behaves ... once we have checked what the impact/breakage 
of changing behavior would be and if we got consensus/majority in 
favour of changing.  Perhaps very few apps actually depend upon the 
existing behavior and changing would be pretty painless.


I did a quick check against the old orderwindow operator for OpenStep 
(the docs for www.toodarkpark.org). Whilst not explicit, it does say 
that when orderwindow is called to order a window relative to another 
one, that this operation should be followed. Implicitly, the window 
level would change when it is called in this matter. It would not change 
when the user simply switches to it.


MacOS X seems to concur in the same ambiguous fashion. A window that is 
ordered relative to another (via NSWindow's -orderWindow:relativeTo:), 
it seems to imply (it doesn't say) that the window should be moved 
immediately above/below this window. It also mentions the relative 
window number being zero, in which case it moves the window to the 
top/bottom of that window level. The -orderFront:/-orderBack: methods 
explicitly mention the window level i.e. they order to the front or back 
of that window level. Therefore, I think the compatible or "correct" 
behaviour is being observed. I'm not sure about what should happen when 
an application is inactive though. An interesting snippet from the 
NSWindow docs is that a window is brought to the top of its window level 
when its window level is changed using -setLevel:.


And damn, I've been forwarding the messages to the wrong mailing list. 
Oh well, I'll CC to both now.


Thanks for your help on this; with a little effort I think it may be 
possible to emulate this window level stuff on Windows. I just hope 
there isn't too many race conditions and I'm not sure what I'll do about 
other application's windows.


Cheers
Chris



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

Menu Proposal

[Christopher Armstrong]

Hi all

I wish to make a proposal regarding NSMenu. There has been alot of
debate about GNUstep's stacked menus in the past. It is clear that alot
of people like GNUstep's stacked menus, but alot of people also have
different ideas about how menus should be displayed. I want to propose
one pragmatic solution that should make it easier to support multiple
menuing paridigms.

I have been looking at the code in NSMenu, and at the moment NSMenu is
reponsible for creating an NSMenuView and the NSPanel object that it is
housed in. As a result, this code makes the assumption that a menu is
always in a separate window, and that there is only one displayed
representation of a menu. It also assumes that the menu representation
is drawn in the same process with an NSMenuView object.

In order to support different paridigms, such as the (addmittedly broken
but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu
server, I believe that programmers currently need to modify NSMenu
through means such as subclassing or overriding using categories. These
methods are prone to breakage as they often depend on internal
implementations.

I am proposing that we separate the visual representation of a menu
(which includes the window it is drawn in (NSMenuPanel), the view
(NSMenuView) and the item cells (NSMenuItemCell)) from the abstract
representation of a menu (NSMenu). I am suggesting we do this allowing
people to supply an object which will receive menu update notifications
(such as items being added, removed, etc.) and be responsible for
coordinating the drawing of the menus and handling events. It should be
different from the current use of the "NSMenuRepresentation" which
assumes that the menu representation is a subclass of NSView. This
"object" should implement some sort of protocol for communication
between itself and NSMenu, the protocol supplying methods which inform
the object of changes in the NSMenu, something like the interaction
between a Model and Controller in MVC.

For example, you may wish to place a menu on each of your document
windows, but this breaks the current assumption that there is only one
visual representation (view) of the menu. In this case, the intermediary
object would sit between NSMenu and the associated set of NSMenuViews
which reside in each document window. It would be responsible for
receiving update messages from the NSMenu object and forwarding them to
each of the NSMenuViews. These views in turn would somehow notify the
NSMenu when they are clicked/selected.

I think this may be a reasonably opportune time to play with the current
design, as Apple have deprecated the usage of NSMenuView and
NSMenuItemCell along with the -menuRepresentation property of NSMenu
(according to the Cocoa docs). Before I possibly attempted to implement
such a solution, I wanted to discuss it with the list as I fear this
solution may be too complex where simpler solutions exist, and I know it
has implications for some other areas in the AppKit (especially popup
buttons). I don't wish to engage anyone in debate about the merits or
disadvantages of stacked vs horizontal menus; I think this has been
discussed enough on these mailing lists before. I believe we should be
pragmatic and offer people a choice.

It would be helpful to gain some feedback about this idea, particularly
its feasibility. I think it is not too difficult to implement and I do
think it is necessary if we want to be flexible in supporting different
kinds of menu paridigms.


Cheers

Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au



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

Re: Menu Proposal

[Christopher Armstrong]

Fred Kiefer wrote:

I like the original idea, although I currently don't see to much benefit
from it. Perhaps we should have the interface for the new implementation
first, before we get any new code.
  
I do wish to devise some sort of protocol before I carry out any work. 
This was meant as a sort of discussion around the issue of different 
menuing paridigms, and a solution which I think is feasible and doesn't 
encourage too much breakage. I feel it is necessary as what we current 
have doesn't allow other menuing paridigms to be implemented as easily, 
such as those that place a copy of each menu in each document window. 
Multiple menu views or a menu view in a document window (as opposed to 
in NSMenuPanel) isn't supported by what we currently have. I admit that 
I'm not sure how flexible this proposal should be in terms of how much 
it allows an application writer to change the appearance of their menus.



As for the second mail on NSPopUpButton I totally seem to miss the point
here. What is the problem here? I have been involved in the development
of NSPopUpButtonCell, so I may be blind to the fact that the code here
is "hodge podge".
  
There is some dependency on NSMenuView for NSPopUpButtons, but it is not 
to the extent as suggested by the second email on this topic. It is not 
my intention to completely discard NSMenuView, in fact, I would be 
looking to reuse it as much as possible. I think we have a pretty clear 
separation between NSMenu and NSMenuView as it is, but I was hoping to 
extend it a little further in order to be more flexible.


Cheers
Chris


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

Re: Menu Proposal

[Christopher Armstrong]

Richard Frith-Macdonald wrote:


On 29 Nov 2006, at 12:19, Christopher Armstrong wrote:


I have been looking at the code in NSMenu, and at the moment NSMenu is
reponsible for creating an NSMenuView and the NSPanel object that it is
housed in. As a result, this code makes the assumption that a menu is
always in a separate window, and that there is only one displayed
representation of a menu. It also assumes that the menu representation
is drawn in the same process with an NSMenuView object.


I have been assuming that we could support per-window menus by 
dynamically moving the menu view from window to window as the menu in 
each window needs to be drawn (since this is what is already done for 
transient menus), but having multiple menu views may be better.
In terms of the event handling system, how would such a mechanism work? 
There still needs to be a "view" in each window of some sort, so are you 
proposing some sort of "dummy" view in each window where the real 
NSMenuView is ripped out each time an update is triggered and 
temporarily pasted into the window. I don't think I understand what you 
mean.

In order to support different paridigms, such as the (addmittedly broken
but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu
server, I believe that programmers currently need to modify NSMenu
through means such as subclassing or overriding using categories. These
methods are prone to breakage as they often depend on internal
implementations.
I am proposing that we separate the visual representation of a menu
(which includes the window it is drawn in (NSMenuPanel), the view
(NSMenuView) and the item cells (NSMenuItemCell)) from the abstract
representation of a menu (NSMenu). I am suggesting we do this allowing
people to supply an object which will receive menu update notifications
(such as items being added, removed, etc.) and be responsible for
coordinating the drawing of the menus and handling events. It should be
different from the current use of the "NSMenuRepresentation" which
assumes that the menu representation is a subclass of NSView. This
"object" should implement some sort of protocol for communication
between itself and NSMenu, the protocol supplying methods which inform
the object of changes in the NSMenu, something like the interaction
between a Model and Controller in MVC.


I think the current separation, using notifications, is a pretty good 
start and could be extended if necessary ... but I'm not sure that it 
*is* necessary to go much further ... the assumption that the menu 
representation is a subclass of NSView appears to be OK  for doing 
per-window menus, and in the etoile case of having a completely 
separate process handling the menu, it seems to me that the best 
solution is to replace the entire NSMenu with a proxy to that remote 
process.
I agree, although -menuRepresentation makes the assumption that there is 
one and only one representation of a menu i.e. there can't be many menu 
views. Whilst the "multiple menu views" idea involves multiple 
instantiations of NSMenuView, practically they should all be displaying 
exactly the same thing, just with consideration for the window they are 
displayed in.



For example, you may wish to place a menu on each of your document
windows, but this breaks the current assumption that there is only one
visual representation (view) of the menu.


Not necessarily ... the current implementation already uses the same 
view in two different windows (for transient menu support) ... but 
it's probably better to have multiple views (in the current 
implementation the rectangle the view is drawn in is the same in both 
windows, but that would not generally be the case).  I would suggest 
carefully examining the option of extending the 
single-view-moved-between windows approach before deciding that 
multiple views are really necessary/best.
What was your ideas as to how a single view is moved between windows. I 
can't picture how this would work.



In this case, the intermediary
object would sit between NSMenu and the associated set of NSMenuViews
which reside in each document window. It would be responsible for
receiving update messages from the NSMenu object and forwarding them to
each of the NSMenuViews. These views in turn would somehow notify the
NSMenu when they are clicked/selected.


Alternatively, the menu can send a notification, and all views 
associated with it could watch for that notification and handle it.  
The notification mechanism is already used to inform menu 
representations of changes to the items in a menu, and implicitly has 
the feature that multiple views can observe the same notification.  
The notification center is acting as the intermediary object you 
suggest.  The use of notifications has the additional advantage that 
it allows other objects outside the menu/representation mechanism to 
track the operatio

Re: GNUmakefile and a strange case

[Christopher Armstrong]

Hi

> gcc -o account.so -shared Account.os cli.os man.os User.os Group.os 
> LoggedUser.os -L/usr/lib/GNUstep/System/Library/Libraries -lobjc
> -lgnustep-base
> scons: done building targets.

Note with this you're linking against the gnustep-base library, which
includes the NSString class (the missing export in your error messages).
I guess you are making use of NSString somehow (either in the constant
(@"") or non-constant form).

> 
> Thanks.
> On Monday 18 December 2006 19:49, José Pablo Fernández wrote:
> > Hello,
> > I have a strange situation here, it used to be a C library compiled with
> > SCons, but now I am using ObjC and GNUstep and I was recommended to use
> > GNUmakefiles because of the added goodies.
> > Now, I need to create a library, the library should be called account.so
> > (note, not libaccount.so, account.so) and it should be installed
> > on /usr/lib/account/modules/ not on /whatever/Library/whatever. How can I
> > do this ?
> > Now, this library is dlopened, when I compile it with SCons it is loaded
> > succesfully, when I compile it with GNUmakefile (and copy the file by hand
> > renaming it in the process) I get this error:
> >
> > Error loading module 'account.so': /usr/lib/asterisk/modules/account.so:
> > undefined symbol: __objc_class_name_NSString
> >
> > Evidently there's something different in how it was linked with the gnustep
> > libraries.
> >
> > And as a last detail, I get this warnings, what do they mean:
> >
> > User.m:108: warning: ‘_OBJC_INSTANCE_0’ defined but not used
> > User.m:185: warning: ‘_OBJC_INSTANCE_1’ defined but not used
> > User.m:194: warning: ‘_OBJC_INSTANCE_2’ defined but not used
> >
These warnings come with gnustep-base when you use constant strings in
the form 

@"something here"

They seem to be harmless, and its a bug in gcc that should be fixed when
the gcc guys get round to it (ask them; check their bug reporting system
first).
> > ?
> >
> > Any help in any of these problems is appreciated.

You said you were compiling a "c library". This form of a GNUmakefile
with GNUstep does not link in gnustep-base. You will want to compile as
a normal library ($(GNUSTEP_MAKEFILES)/library.make). Please note that
what you are doing by putting the library in a different directory is
likely to cause problems. The gnustep-base library and the objective-c
runtime will somehow need to be in your library export path (ldconfig
and friends) for libaccount.so to load properly. 

For other customisations, I suggest taking a look a the gnustep-makefile
manual on GNUstep's web site; it has some options for customising your
output. 

Cheers

Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au



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

Re: Proposal to deprecate Xlib backend

[Christopher Armstrong]

[EMAIL PROTECTED] wrote:

I've been thinking about deprecating the Xlib backend, so that we can focus 
more on Cairo.   I have discussed this with Fred and I would like to know what 
everone else thinks about it.
  
I think the less backends the better, as its less code to maintain. That 
said, the cairo backend should function correctly out of the box i.e. 
there should be any need to go fishing around for anything other than 
cairo and cairo-glitz on the Internet. I believe this is already the case.


Also, whilst we're on the topic of backends, is it worth trying to 
formalise and clean up the backend API? I don't know how other people 
feel about this, but to me it seems to be in want of some cleaning up 
e.g. set standards on the API instead of a mixture of old DPS commands 
and methods from various classes used to define the backend.


Regards
Chris



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

Theming integration

[Christopher Armstrong]

Hi all

I've downloaded the theming branchg of gnustep-gui from svn in order to
see what is happening with regards to theming. The approach so far looks
promising and pragmatic enough to deal with many kinds of theming, from
tiled images to full class overrides (which wouldn't be easy without
Objective-C).

I'm curious as to know how the GSTheme class will be implemented. Will
it contain the code of Camaelon, so that the default implementation of
GSTheme uses a combination of interface style information, colouring
information and interface tiles? Or will GSTheme contain a default
code-based implementation of a GNUstep "look and feel" such as what is
currently implemented in each control class? How much of Camaelon will
be put into GNUstep?

Will GSTheme provide enough methods so that each control's look and feel
can be completely customised from code i.e. a set of methods for drawing
buttons, a set of methods for drawing menus, a set of methods for
drawing scrollbars etc? I think it is important we provide this a some
theme implementers may have different ideas for how things are drawn.
For example, if I were implementing a theme using code, I wouldn't draw
a menu item as a "button" but instead just as a rectangle or just text.

Also, who is currently working on the theming code integration?


Cheers

Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au



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

Re: Questions to NSButtonCell

[Christopher Armstrong]

Hi

Quite coincidentally, I've been playing around with this stuff myself in 
an attempt to develop further the theming API. I've been having trouble 
trying to sort out some of these problems as well. I was going to 
develop further what I was working on for submitting it, but I may as 
well share it now to avoid duplication. Find attached a patch against 
the gnustep-gui theming branch in SVN (please note it contains some 
extra API's I've been prototyping but haven't used yet, plus some 
documentation for NSScroller that I need to separate out and submit as a 
different patch).


[EMAIL PROTECTED] wrote:

While I working on NSButtonCell I stumbled over a few questions that I
am not able to solve myself. Perhaps one of you knows some of the answers.

2. Cell Frame
All my previous test on MacOSX suggest, that the cell frame being passed
into drawInteriorWithFrame:inView: is exactly the same that did get
passed into drawWithFrame:inView:. But in the current GNUstep
implementation this frame gets reduced by the size of the bezel border.
This solution is a lot more elegant, but it will break porting between
Cocoa and GNUstep, if there is indeed a difference. I think what we need
to do is correct drawingRectForBounds: to ask the theme for the size of
the border.
  
Reading the Cocoa documentation and some old OpenStep documentation, 
-drawInteriorWithFrame:inView: is supposed to receive the same frame as  
-drawWithFrame:inView:, but it could be slightly reduced for unspecified 
reasons. It is ambiguous why it should be reduced, but I don't think it 
would be as a result of the border or bezel. My attached patch calls a 
method in the theme to determine this information.

3. border and bezel
Now NSCell has two different concepts for its border. It is either a
simple line, in which case it is called border, or a more complex thing,
then it is called bezel. For NSButtonCell these two seem to be merged.
Our code only checks the border flag, but it will draw a bezel.
I think that our code is correct, but we should get it better in sync
with the cell code.
  
I noticed this also. I couldn't decipher the Cocoa docs to make exactly 
clear what a "border" is, but I think its supposed to be a black line. 
The bezel stuff is the fancier button types I think. The border flag is 
possibly being used incorrectly in this case.


Cheers
Chris
Index: Source/GNUmakefile
===
--- Source/GNUmakefile  (revision 24388)
+++ Source/GNUmakefile  (working copy)
@@ -182,6 +182,7 @@
 externs.m \
 linking.m \
 GSTheme.m \
+GSTheme_menu.m \
 GSDragView.m \
 GSFontInfo.m \
 GSTable.m \
Index: Source/GSTheme.m
===
--- Source/GSTheme.m(revision 24388)
+++ Source/GSTheme.m(working copy)
@@ -767,8 +767,122 @@
 
 @end
 
-
[EMAIL PROTECTED] GSTheme (ButtonDrawing)
 
+- (void)   button: (NSButtonCell*)cell
+drawWithFrame: (NSRect)frame 
+   inView: (NSControl*)controlView
+style: (int)style 
+state: (GSThemeControlState)state
+{
+  GSDrawTiles  *tiles = nil;
+  NSColor  *color = nil;
+  NSRect   interiorFrame;
+
+  if (state == GSThemeNormalState)
+{
+  tiles = [self tilesNamed: @"NSButtonNormal" cache: YES];
+  color = [NSColor controlBackgroundColor];
+}
+  else if (state == GSThemeHighlightedState)
+{
+  tiles = [self tilesNamed: @"NSButtonHighlighted" cache: YES];
+  color = [NSColor selectedControlColor];
+}
+  else if (state == GSThemeSelectedState)
+{
+  tiles = [self tilesNamed: @"NSButtonPushed" cache: YES];
+  color = [NSColor selectedControlColor];
+}
+
+  if (tiles == nil)
+{
+  interiorFrame = [cell drawingRectForBounds: frame];
+  [color set];
+  NSRectFill(frame);
+
+  if (state == GSThemeNormalState)
+   {
+ [self drawButton: frame withClip: NSZeroRect];
+   }
+  else if (state == GSThemeHighlightedState)
+   {
+ [self drawGrayBezel: frame withClip: NSZeroRect];
+   }
+  else if (state == GSThemeSelectedState)
+   {
+ [self drawGrayBezel: frame withClip: NSZeroRect];
+ interiorFrame
+   = NSOffsetRect(interiorFrame, 1.0, 
+[controlView isFlipped] ? 1.0 : -1.0);
+   }
+}
+  else
+{
+  /* Use tiles to draw button border with central part filled with color
+   */
+  interiorFrame = [self fillRect: frame
+  withTiles: tiles
+ background: color
+  fillStyle: GSThemeFillStyleNone];
+}
+
+  //return interiorFrame;
+}
+
+- (NSSize) buttonBorderSize:(NSButtonCell*)cell
+{
+  // FIXME: Make this method find out the size of the tiles.
+  BOOL bordered, bezeled;
+  NSCellImagePosition imagePosition;
+  NSSize borderSize;
+
+  bordered = [cell isBordered];
+  bezeled = [cell isBezeled];
+  imagePos

Win32 Text Rendering

[Christopher Armstrong]

Hi all

I'm currently running GNUstep SVN on Windows. I'm experiencing very
unusual text rendering, where it appears strings are being rendered with
giant spaces in them (about 5-10 characters wide).  It seems these
spaces are inserted at about the 16th character in each string. They
also make the dialog or view they are in bigger than usual.

Has anyone else experienced this issue? I've never experienced it in the
past, and I don't experience it with the previous GNUstep release
version. The link below is a screenshot of the Info Panel:

http://members.optusnet.com.au/~smokey27/info-panel.jpg

Cheers
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au



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

Re: gnustep-make experiment

[Christopher Armstrong]

Hi

I usually try to avoid playing with GNUstep on Windows as it always
takes too long to setup an environment to run stuff in, but these
pkg-config discussions drew me back in.

> Wim Oudshoorn schrieb:
> > 
> > Well, did you actually try compiling pkg-config?  
> > I did not investigate deeply but the suggested way of compiling:
> > 
> > ./configure
> > make
> > 
> > Did not work.  ./configure succeeded splendidly, but make
> > failed and the reason was that glib.h could not be found.
> > 
> > But I don't want to start a discussion in the GNUstep mailing lists on
> > how to install pkg-config.   I just wanted to see how it would work on 
> > windows.
> > 
> 
> I wanted to keep out of this discussion, but somehow these resolutions
> never work out :-)
> 
> First of all there is a pre-compiled pkg-config for Windows on the Gimp
> download page, but be warned, I have not used it myself:
> http://www.gimp.org/~tml/gimp/win32/pkg-config-0.20.zip

I started by trying to compile the glib included with pkg-config on
Windows...this failed to work properly. I then tried to download the
source code for glib 2.0 on Windows. Quite annoyingly, glib 2.0 depends
on pkg-config, and pkg-config depends on glib, which leads to a
ridiculous chicken-and-egg situation. I gave up trying to compile either
of them and downloaded the binaries from gimp.org. 

They seem to work correctly, although I was struggling with the
pkg-config files that come with all the gnuwin32 stuff (i.e. all those
precompiled dependencies such as zlib, libjpeg, libtiff, libpng, etc).
This is because as pkg-config hardcodes paths in its .pc files, and the
.pc files distributed with gnuwin32 binaries pathnames to directories on
the machines they were compiled on e.g. c:/progra~1/libiconv. Hopefully
things like this can be cleaned up with a sed script.

> Second, I like the idea of using more standard tools in the GNUstep
> configuration and compilation process. pkg-config could come in rather
> nicely here. But I don't quite understand, how it could be used as a
> replacement for GNUstep.conf. Not that I like the role GNUstep.conf is
> currently playing in GNUstep, but this is clearly different from what
> pkg-config is normally doing. GNUstep.conf is a file that gets accessed
> each time a GNUstep application is run to find out about the various
> GNUstep settings. It is there to allow GNUstep installations to be moved
> to arbitrary places after compilation. pkf-config is by its intention a
> compile time tool. It looks for include paths and libraries and such
> stuff. It is not supposed to be around when a compiled application or
> libraries is run.

Considering some of the effort needed to get pkg-config working on
Windows, could we please maintain all existing build methods in
gnustep-make? IMHO pkg-config still feels like a alpha quality programme
in some environments, despite being widely used. The classic
gnustep-make build environment is still my first choice and is alot
easier to install as it has no unusual or difficult dependencies.

Lastly, on a slightly unrelated note, the GNU dependencies (zlib,
libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can
be automated using an installer from the gnuwin32.sf.net project which
downloads most of the precompiled GNU environment. I was thinking that
it may be possible to take the scripts given there, combine them with
scripts for installing mingw/msys and create an installable mingw
environment on Windows that is ready to compile source code within.
 
Regards
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au



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

Re: Win32 Text Rendering

[Christopher Armstrong]

Hi

Sorry for the late reply, been busy with other stuff.
 
> Weird! Which back-end are you using? Win32? If so, I thought we were 
> going that in favor of cairo under win32. Has that not happened yet. As

Not as far as I can see in SVN. From what I can work out, there exists a
few patches to get it to compile, but there are "out of memory errors"
which sound like GDI resource leaks such as forgetting to call ReleaseDC
or some other "free handle" sort of function.
 
> for the sixteen-character spacing weirdness, I seem to *very* vaguely 
> recall Alexander Malmberg doing something pertaining to this in the art 
> back-end (but perhaps it was more generic, this was at least a few years 
> ago) pertaining to text and sixteen character blocks...but I don't know 
> why I remember this...it might be worth your while to search the dev 
> mailing list archive for his name and/or sixteen/16 and see if you get 
> any pertinent info back.

As per Richard's suggestion, this has been fixed in the backend. I am
still experiencing problems with scrolling in a tableview, where the
text smears across a few pixels when you scroll. I end up having to
click on a row to get it to redraw correctly. This might have something
to do with the updated bounding box/glyph advancement metrics code in
the winlib backend. I'm using the Info Panel resource window as my
guide.

Regards
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au



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

Re: gnustep-make experiment

[Christopher Armstrong]

Hi

On Sun, 11 Feb 2007 14:51:39 -0800, "Alex Perez" <[EMAIL PROTECTED]>
said:
> > Lastly, on a slightly unrelated note, the GNU dependencies (zlib,
> > libpng, libjpeg, etc) that are needed to compile GNUstep on Windows can
> > be automated using an installer from the gnuwin32.sf.net project which
> > downloads most of the precompiled GNU environment. I was thinking that
> > it may be possible to take the scripts given there, combine them with
> > scripts for installing mingw/msys and create an installable mingw
> > environment on Windows that is ready to compile source code within.
> 
> Yes, that would be a great thing to have available to the community :) 
> I've thought about doing exactly this many times myself, but 
> unfortunately do not have the time. Are you volunteering? If not, would 
> anyone else like to volunteer? If we don't get any responses, perhaps it 
> would be wise to trim this particular subthread down and forward it to 
> gnustep-discuss to see if there are any willing volunteers.

Whilst I would love to volunteer to do this I'm really pressed for time
at the moment, and when university resumes I will be even more pressed
for time, so much so that I am unable to do any serious work on GNUstep.
Please feel free to forward the idea to the gnustep-discuss list and see
if anyone's up for it. From what I can work out, it could be done with a
series of batch files and an installer programme. The gnuwin32 project
actually includes some utilities like sed, grep and wget in its
installer to locate and download all the latest versions of the
binaries. MINGW currently uses a binary installer which is likely to be
a InstallShield style install-programme builder kind of thing.

Regards
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au



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

RE: Problem building gnustep-base tools with MinGW

[Christopher Armstrong]

Hi

XSLT is #***ed on Windows. It compiles as a static library, and its 
imports end up overriding the imports in gnustep-base.dll when you do a 
"-lxslt", such that all of the libxml2 and gnustep-base exported symbols 
get obliterated (all the __objc_ and NS* functions). I don't know what 
the solution is, but I usually leave xslt out. If you have a copy of 
Visual Studio 6 lying around, the "depends" tool in it will give you an 
idea of what I mean (run it against gnustep-base.dll).


We should contact the xslt people and let them know about this, but 
likely they don't have the time to fix it as its a Windows compile 
issue. I'm not sure, but I think the gnuwin32 binaries with libxslt 
precompiled using VC++ may work. These are hidden on the sf download 
page of this project.


Regards
Chris


lcomdlg32 -lmpr -lnetapi32 -lm -I.
  

The only difference that I can see if that you have -lxslt ... could it be
anything to do with the problem ?



xslt is installed since a very long time...
But it seems you're right !!

This morning i deleted everything and re-install from scratch and now it works
with gnustep-make in c:/GNUstep, with gcc 3.4.2, without xslt.
(I still cant use --enable-native-objc-exceptions but that's not so important)

But if i install xslt, gnustep-base doesn't build !
(i tried twice as i wanted to be sure :-)

I build xslt from source without any oddity. It is installed by default in
/usr/local - like any other library. And it is found by gnustep-base configure
script :

checking for xml2-config... /usr/local/bin/xml2-config
checking for libxml - version >= 2.3.0... yes
checking libxml/SAX2.h usability... yes
checking libxml/SAX2.h presence... yes
checking for libxml/SAX2.h... yes
checking for xsltApplyStylesheet in -lxslt... yes
checking libxslt/xslt.h usability... yes
checking libxslt/xslt.h presence... yes
checking for libxslt/xslt.h... yes

I still dont understand all the problems i encountered :
Why the old release version couldn't be built ? I'm (almost) sure they used to.

  



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

Re: Window managers

[Christopher Armstrong]

Hi

I have added Yen-Ju Chen's contributions to the wiki. Thank you very much for
helping out. If anyone has stuff to add, speak up! Please read and
contribute to the wiki page at
http://wiki.gnustep.org/index.php/Window_manager .
  
I was just reading Yen-Ju Chen's contribution and the bit about "windows 
turning black" caught my eye. This problem exists on Microsoft Windows 
as well when you activate native window borders. I found a partial 
solution for this problem on Windows.


Another problem with window drawing is that non-retained (i.e. 
unbuffered) windows on Microsoft Windows do not seem to update properly. 
For example, when you drag items from the toolbox in Gorm.app to a 
non-retained window, it doesn't show up. By dragging the window off the 
screen and back on, a repaint is forced and then it shows up again. I 
can't seem to remember if this problem exists on X11.


I have been sitting on some code to fix black windows on Windows (please 
note the capitalisation carefully) and a fix for a problem where mouse 
up events don't get sent when the mouse is released outside of a GNUstep 
window. A patch is attached; please test with GNUstep window decorations 
turned OFF. There is also a (partial, "seems to work") fix for incorrect 
backbuffer blitting after a resize.


Regards
Chris

P.S: [Forwarding this to gnustep-dev]
Index: ChangeLog
===
--- ChangeLog   (revision 24952)
+++ ChangeLog   (working copy)
@@ -1,3 +1,16 @@
+2007-03-31 Christopher Armstrong <[EMAIL PROTECTED]>
+
+   * Source/win32/WIN32Server.m: Backend capture mouse when it
+   is clicked down, and releases the mouse capture when the mouse button
+   is released.
+   * Source/win32/w32_movesize.m: WM_SIZING sends
+   GSAppKitWindowResized events to the frontend so that frame rect is
+   updated during the resize.
+   * Headers/win32/WIN32Server.h
+   * Source/win32/w32_windowdisplay.m: Added a flag to the WIN_INTERN
+   structure so that we can tell when the backing store contains no
+   useful data and a repaint should occur.
+
 2007-03-30 Fred Kiefer <[EMAIL PROTECTED]>
 
* header/xlib/XGGeometry.h: Replace calls to the now deprecated
Index: Source/win32/w32_windowdisplay.m
===
--- Source/win32/w32_windowdisplay.m(revision 24952)
+++ Source/win32/w32_windowdisplay.m(working copy)
@@ -35,6 +35,18 @@
 {
   WIN_INTERN *win = (WIN_INTERN *)GetWindowLong((HWND)hwnd, GWL_USERDATA);
 
+  if (!win->useHDC || win->backingStoreEmpty) 
+{
+  NSWindow *window = GSWindowWithNumber((int)hwnd);
+  NSRect r = MSWindowRectToGS(svr, (HWND)hwnd, rect);
+  
+  /* Repaint the window's client area. */
+
+  [[[window contentView] superview] setNeedsDisplayInRect: r];
+  [[[window contentView] superview] displayIfNeeded];
+  win->backingStoreEmpty = NO;
+
+}
   if (win->useHDC)
 {
   HDC hdc = GetDC((HWND)hwnd);
@@ -49,18 +61,6 @@
   }
   ReleaseDC((HWND)hwnd, hdc);
 }
-  else 
-{
-  NSWindow *window = GSWindowWithNumber((int)hwnd);
-  NSRect r = MSWindowRectToGS(svr, (HWND)hwnd, rect);
-  
-  /*
-   NSLog(@"Invalidated window %d %@ (%d, %d, %d, %d)", hwnd, 
-   NSStringFromRect(r), rect.left, rect.top, rect.right, rect.bottom);
-  */
-  // Repaint the window's client area. 
-  [[[window contentView] superview] setNeedsDisplayInRect: r];
-}
 }
 
 @implementation WIN32Server (w32_windowdisplay)
@@ -206,6 +206,7 @@
   RECT rect;
//LPPAINTSTRUCT lpPaint;
//HDC theHdc;
+  PAINTSTRUCT pPaint;
 
/*BOOL InvalidateRect(
HWND hWnd,   // handle to window
@@ -216,14 +217,14 @@
//theHdc=BeginPaint(hwnd, lpPaint);
//if (flags.HOLD_PAINT_FOR_SIZING==FALSE)
// {
-  if (GetUpdateRect(hwnd, &rect, NO))
+  if (GetUpdateRect(hwnd, &rect, TRUE))
 {
-  //InvalidateRect(hwnd, rect, YES);
-  
+  BeginPaint(hwnd, &pPaint);  
+  
+  // Perform drawing (or blitting if buffered) in response to WM_PAINT
   invalidateWindow(self, hwnd, rect);
-  // validate the whole window, for in some cases an infinite series
-  // of WM_PAINT is triggered
-  ValidateRect(hwnd, NULL);
+
+  EndPaint(hwnd, &pPaint);
 }
// } 
   flags._eventHandled=YES;
@@ -281,6 +282,7 @@
   win->hdc = hdc2;
   
   ReleaseDC((HWND)hwnd, hdc);
+  win->backingStoreEmpty = YES;
 }
 }
 
Index: Source/win32/WIN32Server.m
===
--- Source/win32/WIN32Server.m  (revision 24952)
+++ Source/win32/WIN32Server.m  (working copy)
@@ -418,8 +419,9 @@
 
 /*  stubs for window server events note other stubs should be 
 declared for mouse and keyboards
-thes

Re: Window managers

[Christopher Armstrong]

Hi

Sorry, realised I left a debugging message in that patch I sent. It 
should be removed unless you like flooded console windows ;-)


Regards
Chris

Christopher Armstrong wrote:
I have been sitting on some code to fix black windows on Windows 
(please note the capitalisation carefully) and a fix for a problem 
where mouse up events don't get sent when the mouse is released 
outside of a GNUstep window. A patch is attached; please test with 
GNUstep window decorations turned OFF. There is also a (partial, 
"seems to work") fix for incorrect backbuffer blitting after a resize.






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

Re: Window managers

[Christopher Armstrong]

Hi


I am not sure if capturing the mouse is a great idea. I understand that
we have the problem with Windows of not getting a mouse up event when
the mouse leaves the current window. But this should be handled on
another level. In most cases we are not interested in a mouse up, so why
always capture it? This could disturb the interaction with other
applications.
  
I believe we are interested in the mouse up event. The key problem is 
that mouse up events are expected to be sent when the mouse is released 
outside of  the window it went down in i.e.


1. mouse goes down in our window
2. user holds button down and moves the mouse outside one of our windows
3. user releases the same mouse button

This particular scenario is used for popupbuttons at least. IMHO 
capturing the mouse for this scenario is reasonably safe; every windows 
application does it for menus in order to determine if the user clicks 
outside their window. We need it to track this particular set of events 
as it is expected by our UI.


If you read the Cocoa docs carefully, you will notice that mouse up 
events only get sent when a mouse button goes down in one of your 
windows (it doesn't get sent in other scenarios). Capturing the mouse in 
this way emulates the appropriate event handling. The only other way is 
to install a hook DLL, which is too extreme.



As for the change in windowbacking:, I could prove to you that it is not
needed. But if you feel more comfortable with explicit code, it is fine
for me.
  
I feel a bit uncomfortable with the change to invalidateWindow(). This

looks like a potential recursion problem. The back end here asks the
front end to do some drawing and this of course will ask the back end to
do it. I think it wont loop, but still it looks a bit dangerous. Perhaps
some simplification and documentation of the code would help here.
It looks like invalidateWindow is now only used in
decodeWM_PAINTParams:::. So why not move the code to here?
  
The main reason for forcing a redraw is that the window has been 
resized, and the frontend thinks it can hold off redrawing until the 
resize event loop is over, which is correct on many other platforms, but 
incorrect on Windows when full redraw during resize is sent. During 
WM_PAINT, the window is expected to redraw itself, so that's why I 
forced it here. The reason for keeping track of whether the backing 
store is empty is that we don't want to blit a blank backing store onto 
a window that has just been invalidated anyway. OTOH could you explain 
how a recursive loop may occur? Is it possible that the frontend would 
try re-enter the runloop whilst it is redrawing?


Regards
Chris




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

Re: Window managers

[Christopher Armstrong]

Hi

Fred Kiefer wrote:

I did understand all this when writing my mail :-)
Still I think it is dangerous to steal mouse events that are not meant
for our application. Perhaps it would be better to move the capture into
the trackMouse:inRect:ofView:untilMouseUp: method on NSCell (if the falg
is YES). This seems to be the only place where this is valid. On the
other hand, if you have a proof that your code will never have any
negative outside effect then share it with me.
  
Yep I think this would be a better solution, only reason I didn't pursue 
it is that it is platform dependant (although we can still call 
capturemouse/releasemouse from the frontend on X anyway). I only 
advocate capturing the mouse as it best replicates the functionality the 
frontend is expecting i.e. mouse up events outside a window, AFTER a 
mouse down.


The other solution I had thought of was in fact something from the 
frontend that used such services in the backend. With the 
backend/frontend interaction in general, I think there are points where 
we need more fine-grained interaction than what is currently possible, 
e.g. in terms of events . I also think that there are also points where 
we should shift responsiblity to the backend i.e. (and this is just my 
opinion)
* mouse tracking is currently in the frontend, when the window servers 
we are targeting have this functionality in them.

* window resize events need to be more coordinated with the frontend.

Considering we are really only targeting win32 and X, this shouldn't be 
too difficult. Whilst we may wish to target other servers in future, I 
think its fairly safe to assume that most of our users rely on either X 
or win32. This should at least make the job of fixing display server 
interaction easier.



The main reason for forcing a redraw is that the window has been
resized, and the frontend thinks it can hold off redrawing until the
resize event loop is over, which is correct on many other platforms, but
incorrect on Windows when full redraw during resize is sent. During
WM_PAINT, the window is expected to redraw itself, so that's why I
forced it here. The reason for keeping track of whether the backing
store is empty is that we don't want to blit a blank backing store onto
a window that has just been invalidated anyway. OTOH could you explain
how a recursive loop may occur? Is it possible that the frontend would
try re-enter the runloop whilst it is redrawing?

No, I don't think so. I was just not sure, what may cause a WM_PAINT
message. If this never gets triggered by our code, only by a resize,
then the code is valid.

  
I think there are also some bugs related to the use of nonretained 
windows in the frontend. If you switch to a non-retained window in Gorm, 
it doesn't update in response to normal interaction, only when a repaint 
is forced. Have you observed this? I've been unable to solve this issue 
from the backend, I may need to look into the frontend as well.


Regards
Chris


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

Themeing

[Christopher Armstrong]

Hi

I've been playing around with our theming API (GSTheme) with the intent 
of fleshing it out a bit further. In order to confirm the style of 
programmatic API I've been using, I have been trying to integrate 
Windows uxtheme with the API in order to demonstrate it that it is possible.


For those who are interested in what is happening, and are running 
GNUstep on Windows XP or Vista, please look at:


http://carmstrong.fastmail.com.au/gnustep-gui-themeing-20070429.diff
http://carmstrong.fastmail.com.au/win32theme.tgz

The first is a patch that should be applied against the current 
gnustep-gui SVN (don't use your working copy as this patch is not by any 
means complete). It gives a (partial) API for theming menus and 
scrollbars, on top of the existing buttons themeing.


The second file is a bundle that compiles to a theme. It links against 
uxtheme so you will need at least Windows XP (I've only tested against 
Windows Vista however) and uses code that is private and specific to the 
win32/winlib backend.


I'm putting this up as a point of discussion. Comments and suggestions 
are welcome.


Regards
Chris
carmstrong at fastmail dot com dot au


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

Re: Themeing

[Christopher Armstrong]

Fred Kiefer wrote:

Hi Christopher,

there is a small but very annoying problem with your patch for gui: You
added some clean up of he formatting to it. Now it is great to replace
the tab characters that went into the files with spaces. After noticing
that my editor used tabs instead of spaces for indentation I switched
that off and started to clean up files myself, each time I do a commit
on GNUstep. But having to proofread a huge patch with mostly whitespace
changes is rather boring. It is too easy to miss out on the important
bits, while skipping over the formatting changes.
Also your indentation does not match with the formatting rules for
GNUstep. You use

if (XXX)
{
  [AAA bb];
}

whereas GNUstep has

if (XXX)
  {
[AAA bb];
  }

(There are other differences as well, but this is the most prominent)
Could you please switch over to the GNUstep style before doing a huge
commit?
For the changes to the comments, I also don't see why the reformatting
was necessary.
  
Sorry, the reformatting is an accidental part of me writing code or 
possibly my editor (I'm using VIM with tabs set to be expanded to 
spaces: sw=2, cin, expandtab, ai, sta - which one do I turn off?). I'll 
definitely fix it up for next time. I didn't intend this patch to be 
committed to SVN or even reviewed as such; I attached it as an example 
of what I've done so that people could try it out. I know it is a mess 
and thats why I suggest you apply it against a temporary SVN checkout to 
save messing up your working copy.



As much as I like some of the stuff you did with the Windows themes, in
the current form this patch is not ready for a review.
Have your thought about moving your NSColor code into a separate
application that will just change the system colour list and write it
out? Your code is great for most cases, but when somebody tries to
access the system colour list the result will be totally different.
  
Yep, this is currently a hack. I need a way to map the GetSysColor() 
function to the NSColor system APIs, but the theming API only accepts 
static NSColorLists. I might try and expand something out to permit 
themes to specify a color list on the fly.

The theming extensions for menu and scrollers are surely something we need.

To make your live easier in the future I will submit a whitespace change
to NSButtonCell and NSMenuItemCell removing all the tab characters.

  
Does this mean you are going to commit part of this patch, or would you 
like me to split it out first so you can get part of it in?


Regards
Chris


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

Re: Themeing

[Christopher Armstrong]

Hi

Turns out that svn diff command can be told to ignore whitespace 
changes. This patch is alot smaller and contains the useful changes. I 
don't know if it works.


http://carmstrong.fastmail.com.au/gnustep-gui-themeing-20070429-2.diff 



Regards
Chris


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

Re: Themeing

[Christopher Armstrong]

Hi

I'm currently trying to theme button images (e.g. "NSRadioButton" or 
"NSSwitch"). I've noticed the NSButtonImageSource stuff in gnustep-gui 
and the "ThemeImages" directory stuff in GSTheme.m, but I'm not sure how 
these work, or how to use them. I'm guessing they're a bit incomplete 
but I'm still not certain how they are intended to be implemented.


Does anyone have some hints on what is happening with this? Does it need 
further work?


Regards
Chris


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

GCC 4.1 on mingw platform

[Christopher Armstrong]

Hi

Those that use mingw know that they have quite an old, but stable, set 
of compilers (gcc 3.4 series). I've been experimenting with compiling 
gcc 4.1 for a mingw target and host and have been able to successfully 
produce binaries. Is there any interest in the GNUstep community for a 
gcc 4.1 compiler set that runs on mingw and produces mingw binaries?


If anyone's interested, I'd write up some instructions and/or post 
binaries if I had somewhere to put them. It appears to be possible to 
compile the c and objc frontends using a normal 2/3 stage bootstrap 
("make bootstrap"), and produce c/c++/objc/objc++ frontends by 
recompilation with a gcc 4.1 set. I'm otherwise using mingw 
binutils/w32api/mingw-runtime + a couple of gcc patches. I've been using 
Windows Vista 32bit.


Has anyone else had any experience with gcc 4.1 on windows, particularly 
with GNUstep? It would be interesting to hear about other people's 
experience with this as well. Do people prefer cross-compilation (e.g. 
produce a gcc cross-compiler for mingw target on a linux host)? I hope 
this is not too off-topic for this list.


Regards
Chris


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

Re: GCC 4.1 on mingw platform

[Christopher Armstrong]

Hi

I used the libobjc that is distributed with GNUstep instead of the one 
used with gcc. I'm guessing that the gcc folks have not configured their 
makefiles to accept a shared libobjc version on mingw, possibly an 
outcome of the autoconf/automake usage which deliberately suppresses 
building shared libraries on windows unless the package maintainer 
enables it (in which case they need to supply a .def file). Having used 
this combination before, --enable-objc=shared is probably ignored.


Perhaps if we copied it out and wrote a GNUmakefile for it? That might 
work; it appears to be the approach with the GNUstep version of libobjc 
(although it has some extra patches against it AFAIK).


Regards
Chris


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

Button Cell Images

[Christopher Armstrong]

Hi

I think I've written on this before, but I don't remember getting a 
reply so I'll try again. I want to put some images into a theme bundle 
that are to be used as button images for radio buttons and switch 
buttons. It appears the API for this is incomplete. Someone has been 
working on it but I am trying to understand what they were doing.


From what I can see, button images are currently loaded from the Appkit 
bundle by using the +[NSImage imageNamed:] API when -[NSButtonCell 
setButtonType:] is called. I believe the intention is to replace the 
encoding and decoding of system button images with instances of 
NSButtonImageSource; there appears to be some code to do this in 
NSButtonCell.m but it doesn't make any sense. NSButtonImageSource also 
seems incomplete and it isn't clear what role GSTheme plays in this.


My guess is that NSButtonImageSource instances are to be created for 
each type of button (NSRadioButton and NSSwitch), and they are to be put 
where -[NSButtonCell setImage:] is. NSButtonImageSource appears to be a 
hidden class in Cocoa as both QuantumStep and Cocotron have versions of 
it. I don't understand the part where it only gets stored for the 
alternate image (not the main one as well).


Would someone kindly explain what the intention of this is and how it 
should work? I have the time to work on it at the moment but I have no 
idea what should happen.


Cheers
Chris


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

Re: Button Cell Images

[Christopher Armstrong]

Hi

Gregory John Casamento wrote:
GNUstep has this class as well... it's in GSNibCompatibility.m.   I wrote it originally as part of the keyed-nib decoding mechanism in GNUstep.   


I wrote it to model the behavior I was seeing on Mac OS X.  WHY Apple chose to 
do it this way I'm not quite certain, but it is one of the classes which is 
read and unarchived during nib processing and, thus, needed to be present.

  
I didn't know about that version of it but thanks for pointing it out. I 
was actually talking about the version in SVN  under 
NSButtonImageSource.m that is present but doesn't appear to be compiled 
as part of gnustep-gui. I'm not entirely sure how this one was intended 
to work.


Regards
Chris



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

Re: Button Cell Images

[Christopher Armstrong]

Hi

Gregory John Casamento wrote:

I've been meaning to remove the NSButtonImageSource.m file in SVN.   It's not 
being used and is superflous since the version in GSNibCompatibility is the one 
which is currently being used.
  
OK then. From what I can work out, something like it is necessary for 
themed button images in GNUstep, as we need to modify NSButtonCell to 
use something other than NSImage instances to draw the themed version of 
a radio button or a switch button. I think it is Apple's solution to 
this problem as well, and it appears to be what was happening with 
regards to NSButtonImageSource.m and some code for the 
initWithCoder/encodeWithCoder in NSButtonCell.m.


We need some sort of way to theme button images regardless, so should I 
look at extending this class so it is used internally in GNUstep?


Cheers
Chris



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

Re: Button Cell Images

[Christopher Armstrong]

Hi

Richard Frith-Macdonald wrote:
It's a long time since I had a chance to work on that ... I can hardly 
remember myself.  I think I stopped at the point where I realised I 
needed to do a lot of experimentation with Apple's code to make sure 
we matched it's behavior, and didn't have the time to do that 
experimentation.
Do we really need to match Apple's behaviour? This is an undocumented 
API so it shouldn't need to conform anyway as third party developers 
shouldn't depend on it, especially if they're are porting code to GNUstep.


From what I can see, button images are currently loaded from the 
Appkit bundle by using the +[NSImage imageNamed:] API when 
-[NSButtonCell setButtonType:] is called. I believe the intention is 
to replace the encoding and decoding of system button images with 
instances of NSButtonImageSource; there appears to be some code to do 
this in NSButtonCell.m but it doesn't make any sense. 
NSButtonImageSource also seems incomplete and it isn't clear what 
role GSTheme plays in this.


My guess is that NSButtonImageSource instances are to be created for 
each type of button (NSRadioButton and NSSwitch), and they are to be 
put where -[NSButtonCell setImage:] is. NSButtonImageSource appears 
to be a hidden class in Cocoa as both QuantumStep and Cocotron have 
versions of it. I don't understand the part where it only gets stored 
for the alternate image (not the main one as well).


Would someone kindly explain what the intention of this is and how it 
should work? I have the time to work on it at the moment but I have 
no idea what should happen.


The basic idea is that buttons of the standard types have to have a 
default set of images to be automatically used when the button is in 
various states, but the programmer can override this behavior by 
setting their own image and alternate image.  Apple implemented this 
using a private NSButtonImageSource class to provide the images as 
long as the button didn't have the images overridden by the 
programmer.  Exactly what the circumstances are in which the use of 
the methods to set images will remove the NSButtonImageSource, and how 
you can get it set for a button, are not clear without experimentation.
With regards to that last point I can see we have the -setImage: and 
-setAlternateImage: methods. I guess if the user overrides one image and 
not the other we can just leave the untouched NSButtonImageSource in 
place and continue to use it. It is likely we will just use the same 
instance in the _cell_image and _altImage instance variables.


Greg implemented a minimal NSButtonImageSource to handle decoding of 
nibs, but it doesn't really work the way Apples' implementation does, 
and doesn't support  theming.


What I wanted to do was produce an implementation which was consistent 
with Apple's implementation, but also worked with GSTheme to provide 
alternative sets of images for each default button type, so that a 
theme could change the default button types cleanly.  So when a button 
of the default type wants to draw itssself, it asks its imagesource 
for the image for the current state of the button, and the image 
source provides it from a cache which it populates from the current 
theme (and flushes when the theme changes).


IMHO I think we need to do the following things:

1. Maintain compatibility with existing GNUstep nibs. For this, we need 
to detect when a NSButtonCell refers to an NSImage that is a stock image 
and use a NSButtonImageSource instance instead. I think we can do this 
by detecting when we have deserialised an image with the name 
NSRadioButton or similiar, which looks like it already happens.


2. Use a NSButtonImageSource in place of an NSImage instance in 
-[NSButtonCell image]. The NSButtonCell should be aware that it could 
have a NSButtonImageSource or an normal NSImage instance in its _image 
property. It should detect which one is there, and ask a 
NSButtonImageSource instance (if present) to get the appropriate state 
image if asked to draw.


3. The -[NSButtonCell setImage:] call should simply replace any existing 
NSImage or NSButtonImageSource instance. We should probably do runtime 
type checking to ensure that nobody tries to stick a NSButtonImageSource 
back in.


4. Implement NSButtonImageSource to satisfy our needs whilst still being 
compatible with Cocoa nibs. I think we can do this without much 
difficulty, as the instances already retrieve enough information from 
the nibs to do this (a string with the name we want). It should call 
into GSTheme for the appropriate images and leave the caching upto it.


5. Modify GSTheme to handle this. Shouldn't be too difficult with the 
theme image loading code already in place (although it really shouldn't 
put all the theme images in the default namespace - that feature is 
incompatible with this solution.


6. Modify NSButtonCell to handle NSButtonImageSource instances. This 
would involve storing them when nibs are serialized (should w

Re: Button Cell Images

[Christopher Armstrong]

Hi

Richard Frith-Macdonald wrote:


On 25 Jun 2007, at 12:15, Christopher Armstrong wrote:
Do we really need to match Apple's behaviour? This is an undocumented 
API so it shouldn't need to conform anyway as third party developers 
shouldn't depend on it, especially if they're are porting code to 
GNUstep.


Certainly we need to match Apple's behavior if we want to make porting 
easy (the alternative is that we accept the lousy press when people 
who try to port from Apple just say GNUstep is no good because code 
that works on MacOS-X doesn't work with GNUstep).  Especially because 
Apple have a habit of updating/improving their documentation to 
include explicit descriptions of behaviors that were previously there 
but not mentioned...
So while implementing undocumented behaviors is not high on my 
priority list, I try to ensure that GNUstep matches Apple when I can.
Sorry I didn't think that Apple would expose this behaviour considering 
it is such a clumsy way of doing things. I don't have access to an Apple 
machine to experiment with. I am more inclined to just guess the 
behaviour and fix it later, even though it isn't the ideal solution as 
you outline above. The results of your experimentation would be most 
welcome.
5. Modify GSTheme to handle this. Shouldn't be too difficult with the 
theme image loading code already in place (although it really 
shouldn't put all the theme images in the default namespace - that 
feature is incompatible with this solution.


I agree ... the image sup[port in GSTheme needs to be enhanced to 
correctly differentiate between system images (which should be named 
and in the global namespace) and images used for tiling etc
I was thinking it shouldn't put any images in the global namespace at 
all, and instead the theme provides an API to access them from GSTheme.


6. Modify NSButtonCell to handle NSButtonImageSource instances. This 
would involve storing them when nibs are serialized (should we bump 
the class version?) and loading them out when they are inflated 
again. We also need to handle the theme changed events so they redraw.


Okay that reads more like an action plan but we probably want to get 
this right and coding for GNUstep on Windows is painful (this is what 
I'm trying to theme).


I had thought that it would be good to develop a windows theme under 
gnu/linux to start with, then add backend specific features later.
By backend specific features I meant things like the ability to get 
the system colors from windows APIs and make them appear as a system 
color list in the theme, and to sample things like button images from 
the windows api, and make sections of a button image appear as tile 
images for tiling within the theme.  Such extensions could mean that a 
windows theme, when running on windows, could adapt itsself to conform 
to the native windows theming mechanisms.
I have considered doing things this way but I am currently going the way 
I am for a few reasons:


* In order to draw like a Windows machine, we have the option of using 
the theming API on windows (aka "Visual Styles") or using custom drawing 
to do everything manually. Unfortunately we have to do both, as the 
theming API is not available on Win2K and on WinXP/Vista the theme API 
deliberately fails when the Win98/2K theme is enabled so that controls 
fall back on their normal drawing which is the old style.


* We just can't sample on Windows and create tiles as it supports quite 
a number of themes that we will want to be compatible with.


* Windows visual styles API doesn't let you retrieve the images that 
make up the visual style; it only lets you draw with them (under WinXP 
anyway).


* For the parts where the visual styles fail, and I need to fall back on 
manual drawing, it is easier to confirm the results of drawing output on 
the OS I am targeting. I can also separate these parts and port the 
result back to other OS's.


All that said, given that I don't have access to a Mac for development, 
I think I will go ahead and implement something along the lines I 
specified above so that I can get themeing working better.


On another note, please find attached a patch that contains what I have 
so far in terms of theming. It is the same as last time but I've cleaned 
it up somewhat.


Regards
Chris
Index: Source/GSTheme.m
===
--- Source/GSTheme.m(revision 25290)
+++ Source/GSTheme.m(working copy)
@@ -43,6 +43,7 @@
 #include "AppKit/NSImageView.h"
 #include "AppKit/NSMatrix.h"
 #include "AppKit/NSMenu.h"
+#include "AppKit/NSMenuView.h"
 #include "AppKit/NSPanel.h"
 #include "AppKit/NSScrollView.h"
 #include "AppKit/NSTextContainer.h"
@@ -613,7 +614,7 @@
* VerticalDivision  Where to divide the image into rows.

GNUstep on Windows - libm5.dll caveat

[Christopher Armstrong]

Hi all

This is just a notice about a problem I've been having with GNUstep on
Windows. I wanted to post a description of the problem and the solution
in case it ever comes up again as a note of my experience with GNUstep.
I've been trying to integrate uxtheme with GNUstep and use this as an
example to develop the themeing API.

I use the gnuwin32 binary packages (http://gnuwin32.sf.net) to provide
libtiff, libpng, zlib, etc. to provide the necessary libraries for
GNUstep on Windows. I compile my own libxml2 and disable libxslt2 (when
it gets linked into gnustep-base, it seems to clobber all the symbols
and results in libgnustep-base.dll containing only its symbols). The way
I download gnuwin32 was by telling it to get all the packages (I thought
this would be easier).

One of the packages it comes with is libm5.dll, which seems to be a math
library that utilises the x86 floating point instructions. This library
gets linked in by accident because GNUstep passes "-lm" to the command
line, which snags its import library. Somehow, its floating point
functions don't seem to work with GNUstep and it causes all sorts of
bizarre and unexpected behaviour. Some examples include:
* Scrolling tears in a NSScrollView, probably because the floating point
calculations for scrolling don't work out correctly.
* NSScanner -scanDouble: function fails when it calls pow() (this
returns junk). This affects things in unusual places, e.g. the GUI has a
white shade wherever it is supposed to use NSLightGray or NSDarkGray,
because NSColor sets up the System colorlist by scanning strings with
floating point values in them (and -[NSScanner scanFloat:] returns NaN).

I know this message is probably "noise", but couldn't think where else
to put it. Maybe useful as an example of one of those hairy and bizarre
problems that occurs. I've spent all week trying to figure it out.

Regards
Chris



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

Re: gnustep on windows

[Christopher Armstrong]

Hi Fred

On 04/03/2008, at 7:06 AM, Fred Kiefer wrote:


Just one comment on this impressive patch. You seem to override some
system colour methods on NSColor to use the Windows colour settings in
GNUstep. This is the wrong approach to do so. You should be  
generating a

new system colour list and send that via the themeDidActivate
notification of your theme. That way even system colours loaded from a
NIB file would be displayed correctly.


All you have to do is create the list:

list = [[NSColorList alloc] initWithName: @"System"];

and to add your colours to it:

[list setColor: Win32ToGSColor(COLOR_WINDOWTEXT)
forKey: @"controlTextColor"];


Thanks, this looks like just what I was looking for. I know what I was  
doing was a hack but I wasn't sure about the way around it.


Also, I'm not sure what patch version you have but I was thinking of  
introducing another theme notification called GSThemeDidUpdate or the  
like, which is sent the first time a theme is updated, or by a theme  
whenever it changes its appearance and requires widgets to be updated.  
Another alternative is sending GSThemeDidActivate every time a theme  
needs to update its appearance. This is even if the theme itself does  
not change but needs to change what it looks like. It is necessary,  
because Windows uxtheme (or a similar adapted theme engine) could  
undergo a theme change, and we would need to update our appearance.


Christopher Armstrong
[EMAIL PROTECTED]





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

Re: Copyright assignment

[Christopher Armstrong]

Hi all

Didn't mean to make you guys panic ;-) I didn't realise that you were 
using my work - I haven't posted anything for a while except a couple of 
minor bug fixes. I know I have various patches here and there floating 
around cyberspace. May I ask what is being used?


Cheers
Chris

Adam Fedor wrote:

It's at

http://www.gnustep.org/developers/copyright.html

and Christopher does have an assignment

On Apr 2, 2008, at 2:57 AM, Fred Kiefer wrote:

I am about to integrate a couple of patches by Christopher Armstrong 
for the Windows backend and juts need to make sure we have a 
copyright assignment from him before I continue.


I know the list of developers is somewhere on our web page, but at 
the moment I am unable to find it.


Cheers,
Fred






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

Re: Copyright assignment

[Christopher Armstrong]

Hi

Only the themeing patch+theme, but that is mostly incomplete anyway and 
there is some dispute about the technical approach. Its probably left 
for some other time or maybe for any GSoC students looking to work on 
theme integration.


Cheers
Chris

Fred Kiefer wrote:
I am currently working on your old patch to support glyph appending on 
Windows. Next I am thinking about integrating the GDI+ patch. But this 
will take some time.

Is there anything else important that I missed?

Cheers,
Fred


Christopher Armstrong wrote:

Hi all

Didn't mean to make you guys panic ;-) I didn't realise that you were 
using my work - I haven't posted anything for a while except a couple 
of minor bug fixes. I know I have various patches here and there 
floating around cyberspace. May I ask what is being used?


Cheers
Chris

Adam Fedor wrote:

It's at

http://www.gnustep.org/developers/copyright.html

and Christopher does have an assignment

On Apr 2, 2008, at 2:57 AM, Fred Kiefer wrote:

I am about to integrate a couple of patches by Christopher 
Armstrong for the Windows backend and juts need to make sure we 
have a copyright assignment from him before I continue.


I know the list of developers is somewhere on our web page, but at 
the moment I am unable to find it.


Cheers,
Fred










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

Re: Gnustep-dev Digest, Vol 74, Issue 16

[Christopher Armstrong]

Hi

Could you please post:

* a copy of the source code file you were compiling
* a copy of the GNUmakefile you were using to compile with
* the command that you executed the compiler with in order to compile  
the program


Cheers
Chris

On 23/01/2009, at 4:01 AM, Gupta, Arjit (HP Labs India) wrote:



I have been getting an error
/mingw/lib/libmingw.a:main.c:<.text+0xbd>:Undefined refrence  
to nm...@16

Collect2 :Id returned 1 exitstatus

I am not able to compile a simple objective C class main the main.


----
Christopher Armstrong
carmstr...@fastmail.com.au







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

Re: NSSound Reimplementation

[Christopher Armstrong]

e to GNUstep-back, like
suggested by David C., seems like a good idea (specially with the  
plug-in
based setup) removing the dependency on the -gui library but pushing  
it over

to -back.


You shouldn't be afraid of extra threads - they're really not that bad  
if you follow some simple design patterns when using them. The  
"asynchronous notification" API (which sounds like what you have with  
pulseaudio) is usually just a matter of calling functions in the right  
order, and noting if they are blocking or non-blocking.


Hope this is of some help.

Cheers
Chris


Christopher Armstrong
carmstr...@fastmail.com.au







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

Error compiling libobjc2 - unwind.h not found

[Christopher Armstrong]

I've been wanting to try out the new libobjc2 runtime (discussed at http://etoileos.com/news/archive/2009/09/10/1744/) 
 that is in GNUstep SVN. I've compiled and installed gnustep-make  
from SVN, and now I'm trying to build libobjc2 but it fails with this  
error:


ch...@debian:~/gnustep/libobjc2/trunk$ make
This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for  
help.

Making all for library libobjc...
 Compiling file archive.c ...
 Compiling file class.c ...
 Compiling file encoding.c ...
 Compiling file exception.c ...
exception.c:27:10: fatal error: 'unwind.h' file not found
#include "unwind.h"
 ^
1 diagnostic generated.
make[2]: *** [obj/exception.c.o] Error 1
make[1]: *** [internal-library-all_] Error 2
make: *** [libobjc.all.library.variables] Error 2

I couldn't find unwind.h anywhere in the distribution, and it doesn't  
appear to be a public header on my system. Am I missing something  
before I try installing libobjc2? I have installed gnustep-make into a  
non-standard location, but I'm not sure how this would influence it.


Thanks
Chris


Christopher Armstrong
carmstr...@fastmail.com.au







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

Re: Error compiling libobjc2 - unwind.h not found

[Christopher Armstrong]

Hi David

Thanks for tracking this down so quickly.

I realised that I forgot to mention that I'm using clang (r82855) to  
compile it with (I presume that you need clang to compile code that  
uses libobjc2?). If I search the headers included with llvm, its not  
present. I didn't assume I should use GCC to compile libobjc2, because  
as suggested by Matt Rice, and now by yourself, its included with gcc  
(on my system at /usr/lib/gcc/i486-linux-gnu/4.3/include/unwind.h).


I've tried with your fix, but because its not included with llvm,  
obviously I'm going to have to either use GCC or include this header  
somehow.


Cheers
Chris

On 04/10/2009, at 4:57 PM, David Chisnall wrote:

Ah, well spotted.  I've fixed that now.  Libobjc was originally  
intended to be built as part of gcc (modularity is not something  
that gcc team are big fans of) and so used "unwind.h" to make sure  
it picked up the version of the header provided by GCC, not the one  
provided by the system, which is the exact opposite of what we want.


David

On 4 Oct 2009, at 15:52, Matt Rice wrote:

On Sun, Oct 4, 2009 at 7:30 AM, David Chisnall   
wrote:

Hi Chris,

It's a private GCC header which, unfortunately, varies a little  
bit between
platforms.  I'm a bit surprised it isn't found for you; it has  
been on all
of the platforms that I've tried so far, but in some uleb128 is  
defined and
in others it isn't.  I plan on removing this dependency soon,  
because the

unwind headers just contain copies of the functions from the ABI
specification (which doesn't seem to stop the FSF from slapping a  
GPL header

on them).


Yeah, i thought it referred to that unwind.h,
the use of "unwind.h" made me wonder though, why not ?

http://packages.debian.org/lenny/gcc-3.4
http://packages.debian.org/lenny/gcc-4.1
http://packages.debian.org/lenny/gcc-4.2
http://packages.debian.org/lenny/gcc-4.3

all of the 'list of files' links i've followed from those contain  
the header.

e.g.
http://packages.debian.org/lenny/sparc/gcc-4.3/filelist
http://packages.debian.org/sid/mips/gcc-4.1/filelist
http://packages.debian.org/squeeze/mipsel/gcc-4.1/filelist


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



-- Sent from my brain




Christopher Armstrong
carmstr...@fastmail.com.au







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

Re: Error compiling libobjc2 - unwind.h not found

[Christopher Armstrong]

th clang  
-fobjc-nonfragile-abi, but the library itself can be built with GCC.


Please also be aware that it is still in active development.  I may  
still change the non-fragile ABI between now and the first official  
release.  There are probably still bugs that may break things for  
you.  There are a lot of compiler flags set in the default build  
that make it easier for me to track down bugs, but are going to make  
things very slow (for example, message sends call a few functions  
that are inlined normally, but the default compile flags at the  
moment disable inlining, so message sends are quite a lot slower  
than they would be with an optimised build).  Until the first  
release, I wouldn't recommend it for anything other than  
experimenting.


David

On 4 Oct 2009, at 16:03, Christopher Armstrong wrote:


Hi David

Thanks for tracking this down so quickly.

I realised that I forgot to mention that I'm using clang (r82855)  
to compile it with (I presume that you need clang to compile code  
that uses libobjc2?). If I search the headers included with llvm,  
its not present. I didn't assume I should use GCC to compile  
libobjc2, because as suggested by Matt Rice, and now by yourself,  
its included with gcc (on my system at /usr/lib/gcc/i486-linux-gnu/ 
4.3/include/unwind.h).


I've tried with your fix, but because its not included with llvm,  
obviously I'm going to have to either use GCC or include this  
header somehow.


Cheers
Chris

On 04/10/2009, at 4:57 PM, David Chisnall wrote:

Ah, well spotted.  I've fixed that now.  Libobjc was originally  
intended to be built as part of gcc (modularity is not something  
that gcc team are big fans of) and so used "unwind.h" to make sure  
it picked up the version of the header provided by GCC, not the  
one provided by the system, which is the exact opposite of what we  
want.


David

On 4 Oct 2009, at 15:52, Matt Rice wrote:

On Sun, Oct 4, 2009 at 7:30 AM, David Chisnall  
 wrote:

Hi Chris,

It's a private GCC header which, unfortunately, varies a little  
bit between
platforms.  I'm a bit surprised it isn't found for you; it has  
been on all
of the platforms that I've tried so far, but in some uleb128 is  
defined and
in others it isn't.  I plan on removing this dependency soon,  
because the

unwind headers just contain copies of the functions from the ABI
specification (which doesn't seem to stop the FSF from slapping  
a GPL header

on them).


Yeah, i thought it referred to that unwind.h,
the use of "unwind.h" made me wonder though, why not ?

http://packages.debian.org/lenny/gcc-3.4
http://packages.debian.org/lenny/gcc-4.1
http://packages.debian.org/lenny/gcc-4.2
http://packages.debian.org/lenny/gcc-4.3

all of the 'list of files' links i've followed from those contain  
the header.

e.g.
http://packages.debian.org/lenny/sparc/gcc-4.3/filelist
http://packages.debian.org/sid/mips/gcc-4.1/filelist
http://packages.debian.org/squeeze/mipsel/gcc-4.1/filelist


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



-- Sent from my brain




Christopher Armstrong
carmstr...@fastmail.com.au







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



-- Sent from my PDP-11




Christopher Armstrong
carmstr...@fastmail.com.au







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

In-window menus

[Christopher Armstrong]

Hi all

For those who have been monitoring the bug tracking list, I've posted  
a patch that attempts to properly implement in-window menus (i.e.  
NSWindows95InterfaceStyle) that don't jump around as the main window  
changes. I don't believe the patch breaks anything for  
GSWindowMakerInterfaceStyle menus, but it still needs review as I've  
had to take a slightly more creative approach to implement it, without  
refactoring NSMenu/NSMenuView completely.


Please find it attached at:
https://savannah.gnu.org/bugs/?27088

Some issues still remain, but I'd want feedback if I should develop  
this any further.


Cheers
Chris

----
Christopher Armstrong
carmstr...@fastmail.com.au







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

Re: Last change in NSMenuView.m

[Christopher Armstrong]

Hi all

Having worked on a window manager recently, I'd thought I better comment on 
this.

On 24/01/2011, at 20:59 PM, Wolfgang Lux wrote:

> The change to open menus with their bottom at the mouse cursor looks  
> less convincing to me. The real problem with menus is that the gui  
> blindly expects the window manager to place menus at the intended  
> position and simply ignores information from the backend when the  
> window manager has decided to place the menu differently. Rather than  
> fixing the problem, your patch just alleviates it by reducing the  
> chance that the window manager interferes with the gui's placement.

If you don't want the WM to interfere *at all* with window placement, you 
should mark the window as "override-redirect", which prevents the window 
manager from reparenting the window, and prevents it from intercepting 
ConfigureNotify events and MapNotify events. Well-behaved window managers just 
ignore these windows completely. 

You should also grab the mouse when displaying drop down menus (and popup menus 
too). This will prevent clicks and mouse movements from being lost to other 
windows (and the resulting undefined behaviour).

However, you should really only use these for the Win95 and Mac style windows, 
as grabbing the mouse only makes sense with those styles, and override-redirect 
was intended for windows with a very short lifetime.

I understand these would be a pain to integrate with the backend because it 
starts to violate separation of concerns, but they would be worth it. At least, 
grabbing the mouse would enhance the user-experience on Windows platforms too. 
Its also how these things are implemented on Windows, GNOME, KDE, etc. too (but 
interestingly not MacOS X).

Cheers
Chris


Christopher Armstrong
carmstr...@fastmail.com.au






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

NSMenuView patch

[Christopher Armstrong]

I've reposted this here because I don't believe patches show up on the mailing 
lists. 

I've attached a patch at savannah that fixes some outside mouse behaviour 
issues with Mac and Windows style menus. Specifically:

* Clicking outside the attached menu window to close it doesn't close the menu
* Moving the mouse outside the menu in Windows mode closes the menu
* Attached sub-menus in Windows mode stay open until another top-level menu is 
selected, instead of disappearing when the mouse is moved outside the attached 
sub-menu

https://savannah.gnu.org/patch/?7470

Cheers

Christopher Armstrong
carmstr...@fastmail.com.au
--

Index: Source/NSMenuView.m
===
--- Source/NSMenuView.m (revision 32140)
+++ Source/NSMenuView.m (working copy)
@@ -1439,7 +1439,6 @@
   int delayCount = 0;
   int indexOfActionToExecute = -1;
   int firstIndex = -1;
-  int space = 0;
   NSEvent *original;
   NSEventType type;
   NSEventType end;
@@ -1487,7 +1486,6 @@
   eventMask |= NSLeftMouseUpMask | NSLeftMouseDraggedMask;
   eventMask |= NSLeftMouseDownMask;
 }
-
   /* We attempt to mimic Mac OS X behavior for pop up menus. If the user
  presses the mouse button over a pop up button and then drags the mouse
  over the menu, the is closed when the user releases the mouse. On the
@@ -1503,6 +1501,11 @@
*/
   shouldFinish = NO;
 }
+  
+  // Capture the mouse so we get clicks outside the menus and
+  // GNUstep windows.
+  [_window _captureMouse: self];
+
   do
 {
   /*Close the menu if the user press a modifier key and menu
@@ -1512,6 +1515,7 @@
{
  [self setHighlightedItemIndex: -1];
  NSApp mainWindow] menu] attachedMenu] close];
+ [_window _releaseMouse: self];
  return NO;
}
 
@@ -1585,7 +1589,6 @@
   NSPoint locationInScreenCoordinates;
   NSWindow *windowUnderMouse;
   NSMenu *candidateMenu;
- NSMenu *anAttachedMenu = [[[NSApp mainWindow] menu] attachedMenu];
 
   subMenusNeedRemoving = NO;
 
@@ -1631,6 +1634,7 @@
   
   candidateMenuResult = [[candidateMenu menuRepresentation]
trackWithEvent: original];
+  [_window _releaseMouse: self];
   return candidateMenuResult;
 }
 
@@ -1650,6 +1654,7 @@
 {
   [self detachSubmenu];
 }
+  [_window _releaseMouse: self];
   return subMenuResult;
 }
  
@@ -1660,23 +1665,16 @@
  ![[self menu] isTransient] &&
  ![[self menu] _ownedByPopUp])
{
- if ([self hitTest: location] == nil)
+  // If the user moves the mouse into the main window
+  // horizontal menu, start tracking again.
+  NSWindow *mainWindow = [NSApp mainWindow];
+  NSPoint locationInMainWindow = [mainWindow 
+convertScreenToBase: locationInScreenCoordinates];
+ if ([[[mainWindow menu] menuRepresentation] 
+hitTest: locationInMainWindow] != nil)
{
- /*This gives us time to move the cursor between a menu and
-   its submenu (or vice versa) without lose the mouse
-   tracking*/
- space += 1;
-
- if (space == 2)
-   {
- [anAttachedMenu close];
- return NO;
-   }
-   }
- 
- if (self != [[[NSApp mainWindow] menu] menuRepresentation])
-   {
  [self setHighlightedItemIndex: -1];
+ [_window _releaseMouse: self];
  return NSApp mainWindow] menu] menuRepresentation]
   trackWithEvent: original];
}
@@ -1711,6 +1709,9 @@
 }
   while (type != end || shouldFinish == NO);
 
+  // Uncapture the mouse again.
+  [_window _releaseMouse: self];
+
   /*
* Ok, we released the mouse
* There are now a few possibilities:


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

Re: NSMenuView patch

[Christopher Armstrong]

Hi German

On 19/02/2011, at 04:01 AM, Germ?n Arias  wrote:

> Well, definitely this behavior is better. But there are some problems:
> 
> * You need do three clicks on title bar to get a response (minimize,
> close,...) when a submenu is displayed.
> 
> * If a submenu is displayed, and you do a click at horizontal bar in a
> place where there isn't an item, after some second the app crash.
> 

I'm unable to replicate the issues you are talking about. I'm using the latest 
SVN code and tried it under GNOME (Metacity) and WindowMaker with Gorm. 

Could you give a more detailed description of your environment including:
* application you're testing with
* defaults output relevant to the programme your running (effectively 'defaults 
read NSGlobalDomain && defaults read ')
* window manager
* GNUstep version

All are quite important and could make a difference to the environment that 
affects this sort of patch.

Thanks

Christopher Armstrong
carmstr...@fastmail.com.au






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

Re: NSMenuView patch

[Christopher Armstrong]

Hi Germán

I am still investigating both problems. I think the first might be a bit more 
subtle, as I was able to get something similar to happen (the menu closes if 
you slowing move the cursor upwards over the top-level menu item and then try 
and click the minimise button). For this, I've attached a new patch you can 
give a try.

I'm still looking into replicating the second issue, but the patch might 
address that too.

Cheers
Chris


005-win95_mac_and_menus_close_fix_highlightlogic.patch
Description: Binary data


On 19/02/2011, at 12:08 PM, Germán Arias wrote:

> On sáb, 2011-02-19 at 10:34 +1100, Christopher Armstrong wrote:
>> Hi German
>> I'm unable to replicate the issues you are talking about. I'm using the 
>> latest SVN code and tried it under GNOME (Metacity) and WindowMaker with 
>> Gorm. 
>> 
>> Could you give a more detailed description of your environment including:
>> * application you're testing with
>> * defaults output relevant to the programme your running (effectively 
>> 'defaults read NSGlobalDomain && defaults read ')
>> * window manager
>> * GNUstep version
>> 
>> All are quite important and could make a difference to the environment that 
>> affects this sort of patch.
>> 
>> Thanks
> 
> I have the latest SVN code, but even I face these problems. I'm trying
> this with Ink but I get the same problems with other apps. Here the
> output of "defaults read NSGlobalDomain"
> 
> NSGlobalDomain 'Local Time Zone' America/Guatemala
> NSGlobalDomain NSFontSize 11.0
> NSGlobalDomain GSFirstControlKey Super_L
> NSGlobalDomain NSLabelFont 'Bitstream Charter'
> NSGlobalDomain GSTheme Silver
> NSGlobalDomain GSSecondAlternateKey ISO_Level3_Shift
> NSGlobalDomain GSUseIconManager 1
> NSGlobalDomain NSLanguages '(
>Spanish
> )'
> NSGlobalDomain GSSecondCommandKey Control_R
> NSGlobalDomain NSLabelFontSize 11.0
> NSGlobalDomain GSWorkspaceApplication ''
> NSGlobalDomain GSSecondControlKey Super_R
> NSGlobalDomain NSPreviewApp evince
> NSGlobalDomain NSMenuFontSize 10.0
> NSGlobalDomain NSMenuFont 'Bitstream Charter'
> NSGlobalDomain NSMenuInterfaceStyle NSWindows95InterfaceStyle
> NSGlobalDomain GSFirstAlternateKey Alt_L
> NSGlobalDomain NSFont 'Bitstream Charter'
> NSGlobalDomain GSRemovableMediaPaths '(
>"/mnt/floppy",
>"/mnt/cdrom"
> )'
> NSGlobalDomain GSReservedMountNames '(
>proc,
>devpts,
>shm,
>usbdevfs,
>devpts,
>sysfs,
>tmpfs
> )'
> NSGlobalDomain GSFirstCommandKey Control_L
> 
> 
> 
> The output of "defaults read Ink"
> 
> Ink NSDefaultOpenDirectory /home/german/Escritorio
> Ink NSMenuLocations '{
>"\033" = "-1 540 77 202 0 0  1024 768 ";
> }'
> Ink NSRecentDocuments '(
> 
> "file://localhost/home/german/Instalados/FisicaLab/English.lproj/mod_cinema.rtfd/",
> 
> "file://localhost/home/german/Instalados/FisicaLab/English.lproj/bienvenida.rtfd/",
> 
> "file://localhost/home/german/Instalados/FisicaLab/Spanish.lproj/bienvenida.rtfd/",
>"file://localhost/home/german/Escritorio/pruenamn.txt",
> 
> "file://localhost/home/german/Instalados/Gemas-0.1/HighlighterKit/Documentation/SyntaxFileFormat.rtf"
> )'
> Ink GSScrollerButtonsOffset 0
> Ink 'NSWindow Frame NSFindPanel' '0 546 462 222 0 0  1024 768 '
> 
> 
> I'm trying this on GNOME 2.22.1 (metacity). Here a better explanation of
> the problems:
> 
> 1) Launch Ink, open a submenu, try to minimize the window with a clic on
> title bar. The first click doesn't nothing, the second click close the
> submenu, and the third miniaturize the window.
> 
> 2) Launch Ink, open a submenu, click at main menu in a place where there
> aren't items (for example at right of item "Windows") and wait, after
> some seconds the app crash.
> 
> 
> 


Christopher Armstrong
carmstr...@fastmail.com.au





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

Re: NSMenuView patch

[Christopher Armstrong]

Hi Fred

I agree this method is very fragile and has a ridiculously high cyclomatic 
complexity, but I'm struggling to work out how to simplify it.

If you split it up so that we have an implementation for each menu style, we 
won't get much code reduction. Each menu style uses most of the code in that 
method, so that there will be little difference between them. We'd also get 
alot of duplicated code which will be even more complicated to maintain (three 
divergent implementations of the same method).

We could also consider splitting each of the if..then sections into separate 
methods, but I think that might end up hiding some of the complexity of the 
method, especially where it re-enters itself through other menu views. There is 
also alot of variables to pass along for the calculations.

I'd be tempted to apply the patch as it stands because our current menu 
handling is frustrating for any user and can cause too much weird behaviour 
(e.g. menus still open if you release the mouse outside the GNUstep windows).

Cheers
Chris

On 20/02/2011, at 01:27 AM, Fred Kiefer wrote:

> First off, we are talking about a method here that is already 350 lines
> long. This surely is wrong and needs to be changed. The patch only
> slightly shortens the method, but makes a few things clearer, which
> surly is a good thing.
> Christopher also took create care to release the captured mouse on all
> possible paths. This is very important, as otherwise the application
> could stop responding. But now consider that somebody else works on this
> method in the future. The person might easily not know about that
> necessity and accidentally break stuff. Even in this patch the mouse
> sometimes gets release after a tracking in a submenu. I don't have a
> clue how this is supposed to work. We always have to release the mouse
> before handling over control to a different window. This of course is
> easy to fix for now. But who will remember this for future changes?
> 
> As much as I like the idea of this patch, I think it is too fragile code
> to be added. We should think hard on how to restructure the code here to
> make it less fragile and then we might be able to safely add a mouse
> capture to it.
> 
> Cheers
> Fred
> 
> Am 19.02.2011 07:08, schrieb Germán Arias:
>> OK, I tested this patch and works fine. I don't see problems, and
>> definitively is a better implementation for menu in window. Are there
>> objections to apply it? Fred? Greg?
>> 
>> 
>> On sáb, 2011-02-19 at 13:09 +1100, Christopher Armstrong wrote:
>>> Hi Germán
>>> 
>>> I am still investigating both problems. I think the first might be a bit 
>>> more subtle, as I was able to get something similar to happen (the menu 
>>> closes if you slowing move the cursor upwards over the top-level menu item 
>>> and then try and click the minimise button). For this, I've attached a new 
>>> patch you can give a try.
>>> 
>>> I'm still looking into replicating the second issue, but the patch might 
>>> address that too.
>>> 
>>> Cheers
>>> Chris
>>> 
>>> On 19/02/2011, at 12:08 PM, Germán Arias wrote:
>>> 
>>>> On sáb, 2011-02-19 at 10:34 +1100, Christopher Armstrong wrote:
>>>>> Hi German
>>>>> I'm unable to replicate the issues you are talking about. I'm using the 
>>>>> latest SVN code and tried it under GNOME (Metacity) and WindowMaker with 
>>>>> Gorm. 
>>>>> 
>>>>> Could you give a more detailed description of your environment including:
>>>>> * application you're testing with
>>>>> * defaults output relevant to the programme your running (effectively 
>>>>> 'defaults read NSGlobalDomain && defaults read ')
>>>>> * window manager
>>>>> * GNUstep version
>>>>> 
>>>>> All are quite important and could make a difference to the environment 
>>>>> that affects this sort of patch.
>>>>> 
>>>>> Thanks
>>>> 
>>>> I have the latest SVN code, but even I face these problems. I'm trying
>>>> this with Ink but I get the same problems with other apps. Here the
>>>> output of "defaults read NSGlobalDomain"
>>>> 
>>>> NSGlobalDomain 'Local Time Zone' America/Guatemala
>>>> NSGlobalDomain NSFontSize 11.0
>>>> NSGlobalDomain GSFirstControlKey Super_L
>>>> NSGlobalDomain NSLabelFont 'Bitstream Charter'
>>>> NSGlobalDomain GSTheme Silver
>>>&g

Re: NSMenuView patch

[Christopher Armstrong]

Hi Wolfgang and Fred

I have had another attempt at this patch, trying to address some of your 
concerns.

On 20/02/2011, at 19:51 PM, Wolfgang Lux wrote:

>> Christopher also took create care to release the captured mouse on all
>> possible paths. This is very important, as otherwise the application
>> could stop responding. But now consider that somebody else works on this
>> method in the future. The person might easily not know about that
>> necessity and accidentally break stuff. Even in this patch the mouse
>> sometimes gets release after a tracking in a submenu. I don't have a
>> clue how this is supposed to work. We always have to release the mouse
>> before handling over control to a different window. This of course is
>> easy to fix for now. But who will remember this for future changes?

Actually, IMHO *shouldn't* release the mouse before handing control over to 
another window while we are still tracking the mouse, as it introduces a 
possible (but tiny) race condition where another app could capture the mouse. 
When we capture the mouse in the first window, we get events for all the 
windows sent to GNUstep, and GNUstep just passes them all along. All the 
internal calls for other windows to capture/release mouse are just ignored by 
X11 (it just returns a error value to the caller). The last (outermost) call 
should release the mouse.

>> As much as I like the idea of this patch, I think it is too fragile code
>> to be added. We should think hard on how to restructure the code here to
>> make it less fragile and then we might be able to safely add a mouse
>> capture to it.
> 
> The safe solution is of course to move the body of this method without the 
> code for capturing the mouse into a new private method -_trackWithEvent: and 
> to define trackWithEvent: as a thin wrapper around the new method, which 
> performs mouse capturing. E.g., something like


I've created a new patch incorporating Wolfgang's suggestion, which seems like 
an elegant way to solve the mouse capture problem without interspersing the 
method with capture/release calls. It can be found here:

https://savannah.gnu.org/patch/index.php?7470

Cheers
Chris


Christopher Armstrong
carmstr...@fastmail.com.au






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

Re: [patch #7470] Fix mouse behaviour in Windows 95 and Macintosh menu styles

[Christopher Armstrong]

Hi Fred

I agree that the capture mouse behaviour does seem extreme, but it is
the only way that you can implement reliable popup menus (on X11 and
Windows, although I haven't tested the latter). As far as I know, there
is no other method to receive clicks outside your window except for
grabbing the mouse (and this makes sense, as applications shouldn't be
receiving events outside their set of windows). Even the grabbing method
that we are using isn't the best but it should be enough to prevent the
common set of problems. 

I don't know about the periodic event stopping code. It doesn't seem to
cause problems for me. I could take a closer look, but there is probably
a reason for it (even if it isn't documented yet). The only issue I have
with this method is that it chews alot of CPU time.

Would you please commit this for me if you're okay with it now, as I
don't have committer access (I do have GNU copyright assignment though).

Thanks
Christopher Armstrong

On Sun, 20 Feb 2011 15:33 +, "Fred Kiefer" 
wrote:
> Follow-up Comment #2, patch #7470 (project gnustep):
> 
> I still don't like the _captureMouse: call, but at least this is now
> implemented safely.
> 
> There is a lot that I don't understand about this long method, but one
> line
> seems to be obviously wrong. That is the stopping of periodic events. Why
> is
> this done here as well as outside of this method? But this hasn't changed
> with
> your patch, you may as well just leave it broken.
> 
> ___
> 
> Reply to this item at:
> 
>   <http://savannah.gnu.org/patch/?7470>
> 
> _______
>   Nachricht geschickt von/durch Savannah
>   http://savannah.gnu.org/
> 
> 
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au


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

Re: NSMenuView patch

[Christopher Armstrong]

Hi Eric

Thanks.

I obviously missed this one :-(. I spent more time testing for
intermittent behaviour and the other menu styles to make sure there was
no breakage instead of testing actual menu items.

Its perfectly safe to release it more than once - at least on X11, the
subsequent calls to XReleasePointer should be ignored. On Windows, I
presume SetCapture/ReleaseCapture will just return an error (MSDN
doesn't help here), which is probably also ignored by the backend.

Cheers
Chris

On Tue, 22 Feb 2011 14:24 -0700, "Eric Wasylishen"
 wrote:
> Hey Fred & Cristopher,
> 
> The only problem with this patch is the mouse isn't uncaptured before
> executing the menu item's action, so when you open a file dialog the
> mouse stops working now (at least, on X11). 
> 
> I think NSMenuView.m needs the following change:
> 
> Index: Source/NSMenuView.m
> ===
> --- Source/NSMenuView.m (revision 32303)
> +++ Source/NSMenuView.m (working copy)
> @@ -1773,6 +1773,9 @@
>return YES;
>  }
>  
> +  // Before executing the action, uncapture the mouse
> +  [_window _releaseMouse: self];
> +
>if([self _executeItemAtIndex: indexOfActionToExecute
>  removeSubmenu: subMenusNeedRemoving] == NO)
>  {
> 
> Does that make sense? Is there any harm in uncapturing the mouse twice?
> (once in the line I added, and once in -trackWithEvent:)
> 
> Cheers,
> Eric
> 
> On 2011-02-20, at 5:10 AM, Christopher Armstrong wrote:
> 
> > Hi Wolfgang and Fred
> > 
> > I have had another attempt at this patch, trying to address some of your 
> > concerns.
> > 
> > On 20/02/2011, at 19:51 PM, Wolfgang Lux wrote:
> > 
> >>> Christopher also took create care to release the captured mouse on all
> >>> possible paths. This is very important, as otherwise the application
> >>> could stop responding. But now consider that somebody else works on this
> >>> method in the future. The person might easily not know about that
> >>> necessity and accidentally break stuff. Even in this patch the mouse
> >>> sometimes gets release after a tracking in a submenu. I don't have a
> >>> clue how this is supposed to work. We always have to release the mouse
> >>> before handling over control to a different window. This of course is
> >>> easy to fix for now. But who will remember this for future changes?
> > 
> > Actually, IMHO *shouldn't* release the mouse before handing control over to 
> > another window while we are still tracking the mouse, as it introduces a 
> > possible (but tiny) race condition where another app could capture the 
> > mouse. When we capture the mouse in the first window, we get events for all 
> > the windows sent to GNUstep, and GNUstep just passes them all along. All 
> > the internal calls for other windows to capture/release mouse are just 
> > ignored by X11 (it just returns a error value to the caller). The last 
> > (outermost) call should release the mouse.
> > 
> >>> As much as I like the idea of this patch, I think it is too fragile code
> >>> to be added. We should think hard on how to restructure the code here to
> >>> make it less fragile and then we might be able to safely add a mouse
> >>> capture to it.
> >> 
> >> The safe solution is of course to move the body of this method without the 
> >> code for capturing the mouse into a new private method -_trackWithEvent: 
> >> and to define trackWithEvent: as a thin wrapper around the new method, 
> >> which performs mouse capturing. E.g., something like
> > 
> > 
> > I've created a new patch incorporating Wolfgang's suggestion, which seems 
> > like an elegant way to solve the mouse capture problem without 
> > interspersing the method with capture/release calls. It can be found here:
> > 
> > https://savannah.gnu.org/patch/index.php?7470
> > 
> > Cheers
> > Chris
> > 
> > 
> > Christopher Armstrong
> > carmstr...@fastmail.com.au
> > 
> > 
> > 
> > 
> > 
> > 
> > ___
> > Gnustep-dev mailing list
> > Gnustep-dev@gnu.org
> > http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
> 
> ___
> Gnustep-dev mailing list
> Gnustep-dev@gnu.org
> http://lists.gnu.org/mailman/listinfo/gnustep-dev
> 
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au


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

Re: Miniaturize a panel

[Christopher Armstrong]

Hi Wolfgang

On Wed, 16 Mar 2011 10:34 +, "Wolfgang Lux" 
wrote:
> Germán Arias wrote:
> 
> > With native decoration, trying to miniaturize a panel don't work (I'm
> > trying on GNOME). Sometimes works, but this is a odd behavior.
> 
> Quoting Apple's User Interface Guidelines: “A user would never need to  
> minimize a panel because it is displayed only when needed and  
> disappears when its application is inactive. Therefore, the minimize  
> button is always unavailable. A panel should have the close and zoom  
> buttons or, if you don’t want users to be able to use the zoom button,  
> only the close button.”
> (http://developer.apple.com/library/mac/#documentation/ 
> UserExperience/Conceptual/AppleHIGuidelines/XHIGWindows/ 
> XHIGWindows.html%23//apple_ref/doc/uid/2961-TPXREF17).
> 
> So the problem is that GNOME's window manager displays a miniaturize  
> button in the first place (incidentally, I observed this behavior  
> under KDE and not under GNOME, but then I'm not using either of these  
> environments regularly). The problem is that -back uses Motif style  
> window manager hints to tell the window manager about the intended  
> window decorations and in addition maps window levels onto EWMH window  
> types. Unfortunately, the EWMH standard gives window managers a lot  
> (too much?) of freedom about how to decorate windows and in particular  
> allows them to completely ignore Motif style window manager hints and  
> we end up with panels that are not prepared (or supposed) to be  
> miniaturized but do have a miniaturize button.

I'd disagree that EWMH gives window managers too much freedom about
window decoration (the point of a window manager is to dictate
consistent window decoration policy, not clients), but I'm in the
opposite camp that believe EWMH is a good thing and that we should work
with it, not ignore it.

Ignoring all that, you said that panels *never* have a minimise button
(according to Apples HIG). If that is true, we should be checking for
the NSMiniaturizableWindowMask in the backend, and using some other EWMH
hints such as:
* _NET_WM_STATE_SKIP_TASKBAR.  We can request this so the panels do not
appear in the taskbar, which would (hopefully) mean that it cannot be
miniturised i.e. whats the point of miniaturising a window if the user
can't restore it again. 
* _NET_WM_WINDOW_TYPE_UTILITY for normal panels will probably help, as
should NET_WM_WINDOW_TYPE_DIALOG for modal dialog panels. 
* ICCCM's WM_TRANSIENT_FOR should also also be enough to indicate that
panels are not normal windows - it should be enough to set this hint to
point to the main window or the menu window if it is present. Note that
this hint is a "nice to have" and not a "need to have" if we are only
considering EWMH support.

I think the problem at the moment is that we use only window levels to
determine the EWMH hints, and the window masks to determine Motif hints,
when we probably need something more sophisticated for EWMH that
considers both window levels and window masks. Abandoning EWMH
altogether I think is a rash decision, especially if newer window
managers decide not to support Motif hints.

Cheers
Chris
-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au

-- 
  Christopher Armstrong
  carmstrong ^^AT^ fastmail dOT com /Dot/ au


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

Re: Emacs.app (from BZR) and GNUstep (from SVN)

[Christopher Armstrong]

I believe Pixmap objects are server-allocated resources, but the X client (i.e. 
the GNUstep application) is still expected to release the resource when it is 
no longer in use to prevent leaking memory on the X server. X resources should 
be wrapped in an Objective-C object so they can be retained/released like 
normal objects, and have something in their dealloc method to call XFreePixmap 
on the stored integer. However, there is no need to wrap them if the lifetime 
is well-known during design.

Cheers
Chris

Christopher Armstrong
carmstr...@fastmail.com.au

On 24/12/2011, at 15:47 PM, Germán Arias wrote:

> You are right this is confusing. But maybe is possible delete this code 
> that don't have sense.
> 
> On 2011-12-23 03:07:24 -0600 Ivan Vučica  wrote:
> 
>> I'm new to Xlib, but isn't Pixmap an integer? How could have one ever sent 
>> an 
>> Objective-C message to an integer?
>> 
>> Shouldn't there be a wrapper around this integer if one wants to retain it?
>> 
>> Why bother retaining an object which is not a part of Objective-C reference 
>> counting system?
>> 
>> I'm confused. :)







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

Re: NSAutoreleasePool issue related to Clang and libobjc2

[Christopher Armstrong]

Hi Quentin

I did some experiments by modifying the  -[NSAutoreleasePool emptyPool] 
code for the ARC runtime to stuff a poison value in any _child instances 
it deallocates. I also added a check at the beginning of the method to 
print out when this occurs:


#define POISON (NSAutoreleasePool*)0xdeadbead
- (void) emptyPool
{
  struct autorelease_thread_vars *tv = ARP_THREAD_VARS;
  if (_child == POISON)
{
   NSLog(@"This autorelease pool %p has already been emptied!", self);
}

  while (_child)
{
  NSAutoreleasePool *pool = _child;
  if (pool == POISON)
{
  NSLog(@"Autorelease pool %p has already been emptied!", pool);
}
  _child = pool->_child;
  pool->_child = POISON;
  push_pool_to_cache(tv, pool);
}
  tv->current_pool = self;
  objc_autoreleasePoolPop(_released);
}

Sure enough, this code tripped up in the CoreObject TestCommon unit test 
- in this case, it was caused by TestCommon maintaining a reference to a 
NSAutoreleasePool as an instance variable. This violates the assumptions 
of the NSAutoreleasePool code above which believes that all 
NSAutoreleasePool variables are created on the stack. From what I 
understand, the code above is designed to clean up orphaned "child" 
NSAutoreleasePools that are leftover from a exception-caused stack unwind.


I'm not sure what the correct solution is - it seems that we should 
detect bad code, but leaving the POISON value in place I think is only 
going to catch the instance where object is returned to the autorelease 
cache, and the NSAutoreleasePool is sent -release again, but before it 
is re-used i.e.


Pool A allocated
Start exception handler
> Pool B allocated
> Pool B assigned to an instance variable of long-lived object N
>> Pool C allocated
>> Throw exception
Exception caught and handled by stack frame of Pool A
Pool A -release called
> Pool A -emptyPool
> Pool B emptied and deallocated by Pool A and returned to cache
> Pool C emptied and deallocated by Pool A and returned to cache
N deallocated
> -release sent to Pool B (Pool B not re-used yet)

I believe if Pool B had already been re-used *before* there is an 
attempt by other code to release it, the POISON value would not allow 
this to be detected. IMHO, the only safe thing we could do in this 
-emptyPool method is to release the NSAutoreleasePool instances and not 
return them to the cache i.e. we should only use the cache for objects 
that return themselves to the cache in -dealloc.


Cheers
Chris
On 03/11/12 08:11, Quentin Mathé wrote:

Le 2 nov. 2012 à 12:11, Tom Davie a écrit :


Heya,

We unfortunately are running into this same issue now.  Did you manage to find 
a solution to the crash?

Not yet. I was hoping that Richard or David had some ideas about this issue.

Did you try to disable the pool caching code entirely? I should probably try 
that next week.

Cheers,
Quentin.


On 31 Oct 2012, at 18:37, Quentin Mathé  wrote:


Hi,

The NSAutoreleasePool implementation bound to the ARC_RUNTIME has some issues I 
think.

For the same current pool instance, it calls push_pool_to_cache() twice, once 
in -emptyPool and another -dealloc. Which means a pool still in use can be 
reused, then it's possible to get stuck in an infinite loop. For example, in

- (void) emptyPool
{
struct autorelease_thread_vars *tv = ARP_THREAD_VARS;

// Infinite loop when pool == pool->_child
while (_child)
  {
NSAutoreleasePool *pool = _child;
_child = pool->_child;
push_pool_to_cache(tv, pool);
  }

Here is a partial backtrace for this problem :

#0  0xb7a29933 in -[NSAutoreleasePool emptyPool] (self=0x8cf7f34, 
_cmd=0xb7f3d000)
  at NSAutoreleasePool.m:413
#1  0xb7a29d07 in -[NSAutoreleasePool dealloc] (self=0x8cf7f34, _cmd=0xb7f3cfe0)
  at NSAutoreleasePool.m:739
#2  0xb7a29c6e in -[NSAutoreleasePool release] (self=0x8cf7f34, _cmd=0xb7f6dc28)
  at NSAutoreleasePool.m:732
#3  0xb7c29493 in -[NSRunLoop limitDateForMode:] (self=0x85a1b9c, 
_cmd=0xb7f6db10,
  mode=0x80f02e4) at NSRunLoop.m:1080
#4  0xb7c2bac7 in -[NSRunLoop runMode:beforeDate:] (self=0x85a1b9c, 
_cmd=0xb7f8ab78,
  mode=0x80f02e4, date=0x8ea2dbc) at NSRunLoop.m:1255
#5  0xb7d4b3db in -[GSMessageHandle sendMessage:beforeDate:] (self=0x8cf7dcc,
  _cmd=0xb7f8ab10, components=0x86dd12c, when=0x8ea2dbc) at NSMessagePort.m:1028
#6  0xb7d5292c in -[NSMessagePort 
sendBeforeDate:msgid:components:from:reserved:] (
  self=0x8cf3f34, _cmd=0xb7f46428, when=0x8ea2dbc, msgId=0, 
components=0x86dd12c,
  receivingPort=0x8cf5174, length=16) at NSMessagePort.m:1960
#7  0xb7a9201d in -[NSConnection(Private) _sendOutRmc:type:] (self=0x8cf577c,
  _cmd=0xb7f46198, c=0x86dd0bc, msgid=0) at NSConnection.m:3426
#8  0xb7a8312b in -[NSConnection(GNUstepExtensions) 
forwardInvocation:forProxy:] (
  self=0x8cf577c, _cmd=0xb7f4c0f8, inv=0x86dd064, object=0x8cf920c)
  at NSConnection.m:2041
#9  0xb7ae4ed1 in -[NSDistantObject forwardInvocation:] (self=0x8cf920c,
  _cmd=0xb7f8bba0, anInvocation=0x86dd064) at

Re: compiling libobjc-2.0 and gnustep on Ubuntu 14.04

[Christopher Armstrong]

Hi all

I was attempting to get GNUstep to compile a little while ago, and I 
ended up putting together some Chef scripts to automate the build of a 
developer VM. At the moment, it works only for Ubuntu 14.04 and 
llvm-3.4, but the idea was to expand the scripts out for other Linux 
variants and to compile and install llvm/clang. It depends on the git 
branch of libobjc2 that David has been maintaining. You can use it with 
Vagrant, which will download everything including a fresh VM and Chef, 
or on a fresh VM with Chef alone (not tested).


https://github.com/chris-armstrong/gnustep-chef-bootstrap

** Do not use this on your regular developer workstation - it creates 
users with default passwords and installs new system packages. **


On another note, I agree that llvm/clang takes a while to compile from 
source. --enable-targets=host option to ./configure reduces the amount 
of code llvm compiles.


Cheers
Chris

On 1/06/2015 4:50 AM, allynm wrote:

Patryk, Richard, and David,

Tried David's -DLLVM_OPTS=false fix and it didn't work.  I've gone back and
downloaded fresh versions of llvm/clang and libobjc2 from trunk locations.
In the middle of compiling LLVM.  So slow...

Mark



--
View this message in context: 
http://gnustep.8.n7.nabble.com/compiling-libobjc-2-0-and-gnustep-on-Ubuntu-14-04-tp39256p39269.html
Sent from the GNUstep - Dev mailing list archive at Nabble.com.

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



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

Re: Jumpstarting a GNUstep development environment using vagrant

[Christopher Armstrong]

Hi Niels

On Mon, Jan 4, 2016, at 08:03 PM, Niels Grewe wrote:
> For that reason, I made it my holiday project to create a vagrant box
> that provides a GNUstep development environment and that has now actually
> reached a working state. 

I actually started something similar to this using Vagrant and Chef to
bootstrap a GNUstep development environment.  I'm not in a position to
maintain it (I don't use GNUstep for my day to day work), but there
might be something there that is useful for your own efforts, especially
if you are interested in using Chef to automate the package installation
and download across multiple platforms.

https://github.com/chris-armstrong/gnustep-chef-bootstrap

It's at a similar state i.e. it compiles and boots up a GNUstep
environment with a Ubuntu 14.04 base.

Cheers
Chris

-- 
  Christopher Armstrong
  carmstr...@fastmail.com.au

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