Backend <-> GUI Library Interaction
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
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
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
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
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
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
[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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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)
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
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
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
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