Error trying to build Objective-C++ on Windows
I'm getting a "No rule to make target" error when trying to compile some Objective-C++ files that I just added to my project on Windows. I haven't used Objective-C++ previously, so I googled around to find out what I need to do. I added a _OBJCC_FILES section to list my .mm files, and also "CC=$(CXX)" but no luck. Here's the relevant portion of my GNUmakefile: CC=$(CXX) APP_NAME=Eggplant VERSION=__VERSION__ Eggplant_OBJCC_FILES=\ ABBYYCommands.mm\ NSString+Wchar.mm\ Engine.mm ... And here's the actual error: make[4]: *** No rule to make target `obj/Eggplant.obj/ABBYYCommands.mm.o', needed by `Eggplant.app/./Eggplant.exe'. Sto p. make[3]: *** [internal-app-run-compile-submake] Error 2 make[2]: *** [Eggplant.all.app.variables] Error 2 make[1]: *** [internal-all] Error 2 make: *** [internal-all] Error 2 _ Any clues about what I'm missing? Is there a compile flag I need to add somewhere? It looks as though it doesn't even recognize the .mm file type. Thanks for any help! Doug Simons ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Methods +readable/writableTypes
On Feb 24, 2014, at 12:39 PM, Germán Arias wrote: > I solve the problem using _openableFileExtensions and > writableTypesForSaveOperation:. The title of the panel let me know the type > of save operation. Now I will add a little hack in ProjectCenter to allow it > use native panels. It looks like this change has broken something else. When we call setAllowedFileTypes: on the NSSavePanel and pass our document extension, it works fine when the current window is one of our document windows. When the current main window is not a document window, the save panel shows "All (*.*)" instead of our document type, and when we enter a file name and click Save we get an NSRangeException -- Index 0 is out of range 0 (in 'objectAtIndex:'). I'm not sure yet if the exception is coming from our code or from the save panel, but setting the allowedFileTypes needs to work in any case. I'll look into it some more, but I'm running short on time today, and may not be near a Windows machine tomorrow... Regards, Doug___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Methods +readable/writableTypes
Hello Germán, On Feb 24, 2014, at 12:39 PM, Germán Arias wrote: > > I solve the problem using _openableFileExtensions and > writableTypesForSaveOperation:. The title of the panel let me know the type > of save operation. Now I will add a little hack in ProjectCenter to allow it > use native panels. Unfortunately, your changes broke the basic behavior when an array of fileTypes is passed in to the runModalForDirectory:file:types:relativeToWindow: method of WinNSOpenPanel. Our application calls this method directly, passing a list of image file extensions (tiff, png, etc.) in places where we want the user to be able to select an image file. These are not registered as document types for our app (we also have some of those -- opening them works okay with your changes). I've committed some changes that fix the problem for our cases, without removing your code. When no fileTypes array is passed in, it should still be using your code to pick up the document types from the NSDocumentController. So hopefully this will still work for you, although I don't fully understand your scenario. Regards, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep.org website redesign proposal
On Dec 31, 2013, at 5:09 AM, Markus Hitter wrote: > Am 31.12.2013 02:09, schrieb Sebastian Reitenbach: > >> https://www.l00-bugdead-prods.de/index7.html > > First, big compliments for the Dock implementation. It works flawlessly > in a mouse/trackpad driven environment. > > Hovever, menus at the bottom of a web pages / windows are very unusual > (the real thing is at the bottom of the screen, which is something > different), so it took me a second visit to see it at all. Having a > standard menu in the upper region suggested there's no need to search > for navigation. I agree that it's unexpected to have a navigation control at the bottom of the window, so many people will miss it. I was totally impressed by the implementation, though -- awesome job! And I agree with Sebastian's points about making the site look modern, cool, and appealing to Mac users. So why not move the dock to the left side? It's not the Mac OS X default, but a lot of people move their docks to the left so it will still be very recognizable to Mac users. And it's a common location for secondary web navigation controls, so even though it may look slightly odd to non-Mac visitors they should be able to use it too. There remains the issue that it might still be slightly less obvious to folks using touch devices. Maybe it would be possible to add titles below the icons for those devices? Overall, this looks to me like a vast improvement over the current site! I think the text of the first paragraph still needs work to focus it more tightly: drop any mention of NeXT and OpenStep, which is only a distraction now, and make Cocoa more prominent. Maybe something like this for the first paragraph: GNUstep is an open-source framework modeled on Apple's Cocoa frameworks to provide a cross-platform API to make it easy to create sophisticated modern software. Ports of OS X software to other platforms and new software development in Objective-C are both supported, with or without a graphical user interface. (And then be sure to include the obligatory trademark disclaimers in the fine print at the bottom of the page to keep Apple's lawyers from getting excited!) Cheers, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Unresolved Issues with libxml2
Thanks, Fred!
I can confirm that your change fixes the crash for me. I'll see about providing
a test case that demonstrates my issue #1 soon.
Cheers,
Doug
On Apr 4, 2012, at 3:38 PM, Fred Kiefer wrote:
> Hi Doug,
>
> thank you for providing this test code. I could reproduce the problem
> and have committed a simplified version of your test code to SVN. Plus a
> solution to the problem.
> It turned out to be caused by the private document I use to hold
> detached nodes. This together with the code that allows the document to
> provide replacement classes for node types could lead to a segmentation
> fault. I fixed this by not allowing the private document to be
> considered in class replacements. Please test again with SVN code.
>
> If you are interested in a solution to your issue #1, please provide some
> test code that shows this behaviour.
>
> Cheers,
> Fred
>
> On 04.04.2012 00:56, Doug Simons wrote:
>> Hello Fred,
>>
>> Thanks for all of your work on the XML classes, and for your summary
>> of the areas that still need attention. My original issue #1 (at the
>> beginning of this thread) is still outstanding as well. My issues #2
>> and #3 have been resolved -- thanks!
>>
>> As it happens, I managed to get back to this yesterday, and spent
>> most of yesterday and today trying to isolate the memory crash I was
>> seeing. It turns out there were (unfortunately) a lot of red herrings
>> in my earlier description of the sequence that leads to the crash,
>> and obviously some missing steps or you would have been able to
>> reproduce it. I was finally able to reproduce the crash myself and
>> create a minimal test case for this problem.
>>
>> Unfortunately, I've now spent too much time on this to do much more
>> with it. I appreciate that you've spent a lot of time on this code,
>> too, but I hope you might be able to figure out how to resolve this
>> problem. If not, we will revert to a slightly earlier version of the
>> NSXML* code for now, which doesn't crash in this way.
>>
>> Regards,
>>
>> Doug
>>
>> Here is my crashTest:
>>
>> #import "ObjectTesting.h" #import
>> #import
>> #import
>>
>> int main() { NSAutoreleasePool *arp = [NSAutoreleasePool new];
>> NSXMLDocument *node; NSXMLDocument *node2; NSXMLElement *elem;
>> NSXMLElement *elem2; NSXMLNode *child; NSXMLNode *child2;
>>
>> NSString *simpleXML = @"6";
>>
>> // create two documents (containing root elements with the same name
>> ("num") -- may be significant?) node = [[NSXMLDocument alloc]
>> initWithXMLString:simpleXML options:0 error:NULL]; PASS(node != nil,
>> "document was initialized from a string");
>>
>> node2 = [[NSXMLDocument alloc] initWithXMLString:simpleXML options:0
>> error:NULL]; PASS(node2 != nil, "document 2 was initialized from a
>> string");
>>
>> // detach the root elements from their documents elem = [node
>> rootElement]; // PASS_EQUAL([elem XMLString], simpleXML, "root
>> element is correct"); [elem detach];
>>
>> elem2 = [node2 rootElement]; // PASS_EQUAL([elem2 XMLString],
>> simpleXML, "root element 2 is correct"); [elem2 detach];
>>
>> // now, simply accessing the text node child of each element leads to
>> a CRASH child = [elem childAtIndex:0]; child2 = [elem2
>> childAtIndex:0];
>>
>> [node release]; [node2 release];
>>
>> [arp release]; arp = nil;
>>
>> return 0; }
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Unresolved Issues with libxml2
Hello Fred,
Thanks for all of your work on the XML classes, and for your summary of the
areas that still need attention. My original issue #1 (at the beginning of this
thread) is still outstanding as well. My issues #2 and #3 have been resolved --
thanks!
As it happens, I managed to get back to this yesterday, and spent most of
yesterday and today trying to isolate the memory crash I was seeing. It turns
out there were (unfortunately) a lot of red herrings in my earlier description
of the sequence that leads to the crash, and obviously some missing steps or
you would have been able to reproduce it. I was finally able to reproduce the
crash myself and create a minimal test case for this problem.
Unfortunately, I've now spent too much time on this to do much more with it. I
appreciate that you've spent a lot of time on this code, too, but I hope you
might be able to figure out how to resolve this problem. If not, we will revert
to a slightly earlier version of the NSXML* code for now, which doesn't crash
in this way.
Regards,
Doug
Here is my crashTest:
#import "ObjectTesting.h"
#import
#import
#import
int main()
{
NSAutoreleasePool *arp = [NSAutoreleasePool new];
NSXMLDocument *node;
NSXMLDocument *node2;
NSXMLElement *elem;
NSXMLElement *elem2;
NSXMLNode *child;
NSXMLNode *child2;
NSString *simpleXML = @"6";
// create two documents (containing root elements with the same name ("num")
-- may be significant?)
node = [[NSXMLDocument alloc] initWithXMLString:simpleXML
options:0
error:NULL];
PASS(node != nil, "document was initialized from a string");
node2 = [[NSXMLDocument alloc] initWithXMLString:simpleXML
options:0
error:NULL];
PASS(node2 != nil, "document 2 was initialized from a string");
// detach the root elements from their documents
elem = [node rootElement];
// PASS_EQUAL([elem XMLString], simpleXML, "root element is correct");
[elem detach];
elem2 = [node2 rootElement];
// PASS_EQUAL([elem2 XMLString], simpleXML, "root element 2 is correct");
[elem2 detach];
// now, simply accessing the text node child of each element leads to a CRASH
child = [elem childAtIndex:0];
child2 = [elem2 childAtIndex:0];
[node release];
[node2 release];
[arp release];
arp = nil;
return 0;
}
On Apr 3, 2012, at 12:58 AM, Fred Kiefer wrote:
> Doug, you never replied to this mail. This hopefully means all your issues
> were resolved.
>
>
> In the meantime I added a few more features to our libxml2 wrapper, but wont
> have much time to work on this area in the future. I also found another nice
> implementation of some of these classes: KissXML
> (https://github.com/robbiehanson/KissXML). They do things quite differently
> from our approach and in many respects these classes are more complete. (In
> others I definitely prefer our code)
>
> There are still some open issues with our NSXML classes. We should do a lot
> more checks, whether we are actually dealing with the right sort of node.
> This is especially true for the NSXMLDTDNode class, where only the handling
> of entity declarations has been implemented. For all other node types this
> will horribly fail.
> We also need a complete rewrite of the namespace handling. The current code
> works well for all the simple cases, but it is easy to construct code where
> we differ from Apples results.
> The namespace nodes don't represent a hierarchy, which means the methods
> level and index return nonsense.
> The code I have in place for older versions of libxml2 when transferring a
> node to a different document, wont work when the old document goes away.
> Somebody needs to write a replacement here. (Maybe even by replacing the DOM
> functions from libxml2 I am using, because they have a few surprising side
> effects)
> The isEqual: implementation needs a review.
> The sub-node handling needs a lot more testing, only when running KissXML
> test code did I learn that setStringValue: will destroy sub-nodes!
> And of course we don't have anythign in place for XML Query.
>
> Overall you need to be careful when using this code as a lot of memory issues
> may still lurk there. The code will need plenty of testing and should be
> taken over by somebody with an actual use case in this area.
>
> And when all these issues are taken care of, there is still plenty of room to
> optimise the code.
>
> All of this sounds overly negative, the code is usable and I hope, it is in a
> lot better shape than it was before.
>
> Fred
>
> On 23.03.2012 10:40, Fred Kiefer wrote:
>> Hi
Re: Unresolved Issues with libxml2
ut crashing with the XML code as it existed a couple weeks ago. So I'm hoping maybe you have a clue about which changes might lead to this. Thanks, Doug On Mar 14, 2012, at 4:27 PM, Fred Kiefer wrote: > On 29.02.2012 23:28, Doug Simons wrote: >> Since we've submitted the new implementation of the NSXML... classes >> based on libxml2 and people are beginning to use them, I thought I >> would mention some remaining unresolved issues in the hope that other >> people might have more experience with the libxml2 libraries and have >> some ideas about how to solve them. These are currently the top >> issues on my list: >> >> 1. Parsing an XML document generates text nodes in the tree for >> whitespace between elements even when the XML_PARSE_NOBLANKS option >> is given. Cocoa doesn't do this. >> >> 2. Find a way to control formatting of "empty" nodes. Cocoa has the >> options NSXMLNodeExpandEmptyElement and NSXMLNodeCompactEmptyElement >> to control whether an empty node foo is displayed as "" or >> as"" . Currently our libxml2 implementation will only display >> the latter. >> >> 3. Find a way to control "pretty-print" formatting. Cocoa has an >> option NSXMLNodePrettyPrint to control whether a string >> representation of a tree will include indentation for enhanced >> readability or not. Currently our libxml2 implementation always >> includes indentation. >> >> I have searched the libxml2 documentation for ways to control these >> issues but haven't come up with anything that works (in particular I >> tried the xmlKeepBlanksDefault() function for issue 1 without any >> success). > > I hope that I have solved the last two of your issues. Could you please give > it a try? > > ___ > 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
NSXMLNode copyWithZone: is broken for Processing Instructions
Fred, One of your recent changes to NSXMLNode's copyWithZone: now causes the content of some nodes (processing instructions, at least) to be lost in the copy. The call to setObjectValue: is the culprit, as it in turn calls setStringValue: (with a nil value, at least in the case I traced through) which erases the content of the libxml node. I'm not sure what the motive was for your recent change, but take a look and see if you can resolve this problem. Thanks, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Unresolved Issues with libxml2
Hello Fred, That's a very interesting idea -- and perhaps you've already implemented it (I've been busy with some issues with releasing our software so wasn't able to find the time to respond sooner). And if this is how Cocoa does it then perhaps it is what GNUstep should do, but I'm not entirely happy with the idea. I don't entirely like it because I believe it creates the potential for some rather odd and potentially unexpected (and undesirable) behavior, although perhaps not all that likely in practice. But please indulge me for a moment, if only so that I can justify to myself the rather considerable effort that I put into making the current (possibly overly-complex) scheme work. ;-) Imagine a scenario where an NSXMLDocument is created (by parsing an XML document, let's say) and retained by an object that we'll call Ancestor. Another object, Son, is created that references (and retains) one of the NSXMLElements that is a descendant somewhere further down in the tree. Ancestor and Son are used and accessed in various places in the application. At any time, Son is able to access its Parent node, and from there can gain access to any of Parent's other children -- Son's siblings. Now, at some point in time every object in the application with a direct reference to Ancestor is released, causing Ancestor to be fully released and (under the scheme you're proposing) deallocated. Suddenly and without warning, through no action of its own, Son is detached and made an orphan, with no parent, and no way to access its siblings even though some of them may already be instantiated as Obj-C objects, which are now similarly orphaned. Perhaps that's not the most likely scenario, but I don't think it's entirely far-fetched. The only solution I see for such a scenario is for the application author to have Son keep and retain a reference to Ancestor for as long as Son is around -- but then you've suddenly created exactly the kind of retain loop between Son and Ancestor that the current NSXMLNode memory management scheme goes to great lengths to resolve, so it will all "just work" for the application developer. Under the current scheme, as long as the application holds a retain on any Obj-C object anywhere in the tree, the entire underlying tree structure and any other Obj-C objects that have been instantiated as part of it are kept in memory. When the final "external" (from outside of the tree) retain is released, the entire structure and all of the objects are freed. A fair bit of complexity internal to the framework to make using the framework simple. So I'm disappointed to hear that Cocoa does it the cheap way! I appreciate that that approach will be simpler to implement and easier to understand the internal GNUstep code, but I wonder if it would be at all worthwhile at this point to allow a "WholeTreeIntegrity" flag to enable a developer to choose either memory behavior. Any thoughts? Cheers, Doug On Mar 2, 2012, at 10:06 AM, Fred Kiefer wrote: > On 01.03.2012 11:08, Richard Frith-Macdonald wrote: >> >> Agreed. In particular we need a lot of tests to run on Apple systems >> to find out exactly how their object ownership model works. What >> happens when you create documents and then release them while holding >> references to various nodes within them? Does behaviour vary >> depending on how documents are created? What about standalone nodes >> without documents? What about namespaces?!! > > It turns out that things are a lot simpler than we thought. I wrote a few > tests on Cocoa and nothing of that mysterious behaviour that we tried to > mimic showed up. It looks like Apple implemented a simple top down approach. > The parent retains the child and nothing more. And we had even test code that > took advantage of that behaviour, see basic.m in NSXMLNode: > >NSXMLElement *node = [[NSXMLElement alloc] initWithKind: NSXMLElementKind]; >NSXMLDocument *docA = [[NSXMLDocument alloc] initWithRootElement: node]; >NSXMLDocument *docB = nil; >// NSLog(@"Here..."); >[node detach]; >PASS(docB = [[NSXMLDocument alloc] initWithRootElement: node], "Detached > children can be reattached."); >[docA release]; >// NSLog(@"Here... again"); >[docB release]; <-- HERE >docA = [[NSXMLDocument alloc] initWithRootElement: node]; >// NSLog(@"Yet again"); >PASS_EXCEPTION(docB = [[NSXMLDocument alloc] initWithRootElement: node], > NSInternalInconsistencyException, "Reusing a child throws an exception"); > > Did you spot the release on the document docB? This make the node usable > again, that is node no longer has a parent and may be used as a root element > in docA. I added a few tests that prove this behaviour. After the release of > docB parent of node is nil! > This could be implemented rather easily by detaching all subnodes of any > deallocated node. The only clever bit needed here is to make sure we free up > the libxml2 nodes th
Unresolved Issues with libxml2
Hello, Since we've submitted the new implementation of the NSXML... classes based on libxml2 and people are beginning to use them, I thought I would mention some remaining unresolved issues in the hope that other people might have more experience with the libxml2 libraries and have some ideas about how to solve them. These are currently the top issues on my list: 1. Parsing an XML document generates text nodes in the tree for whitespace between elements even when the XML_PARSE_NOBLANKS option is given. Cocoa doesn't do this. 2. Find a way to control formatting of "empty" nodes. Cocoa has the options NSXMLNodeExpandEmptyElement and NSXMLNodeCompactEmptyElement to control whether an empty node foo is displayed as "" or as "" . Currently our libxml2 implementation will only display the latter. 3. Find a way to control "pretty-print" formatting. Cocoa has an option NSXMLNodePrettyPrint to control whether a string representation of a tree will include indentation for enhanced readability or not. Currently our libxml2 implementation always includes indentation. I have searched the libxml2 documentation for ways to control these issues but haven't come up with anything that works (in particular I tried the xmlKeepBlanksDefault() function for issue 1 without any success). I welcome any ideas or suggestions. Thanks, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [NSXML + libxml2] external retains
Hi Niels,
Thanks for your feedback and helpful suggestions! It's good to know that other
people are looking at the code and trying it out.
I apologize for the current state of the code regarding memory management. It's
actually a work in progress right now. I've been actively working on the
problems you mentioned today and have already implemented the needed code for
the detach method. Your proposed approach may be simpler though, so I'll give
it some more thought before I check it in. The conditional you mentioned in the
retain method was a little hack to temporarily try to avoid some crashes. As
you noted, it's incorrect, and probably shouldn't have been checked in. Look
for some more updates in the next day or two.
Regards,
Doug Simons
On Jan 26, 2012, at 4:05 PM, Niels Grewe wrote:
> Hi Doug, Greg and all,
>
> I've just been digging into the new libxml2 powered NSXML code and got a
> bit confused about the code path that takes care of external references.
> I get that we want to increase the retain count of the top node in a
> tree if any object outside the tree makes reference to some node in the
> tree. Otherwise, we'd get dangling parent pointers when nothing
> references the top node and it gets deallocated.
>
> But from looking at the code, I somehow think that we should also be
> decreasing the top node's external retain count when a node gets
> detached from the tree (which we don't do presently). But with the way
> things are done now, I don't see how we would do that because once the
> node is attached the record keeping for external references is taken
> over by the top node. The situation basically looks like this ("|"
> denotes the parent-child-relation where the parent is written above the
> child and "<-" denotes an external object holding a reference to the node):
>
> A (externalRetains == 2)
> |
> B<-X (externalRetains == 0)
> |
> C (externalRetains == 0)
> |
> D<-Y (externalRetains == 0)
>
> Now if we detach, say, C, then we have no way to tell:
>
> a) that we should send C and extra -retain in order to prevent D from
> ending up with a dangling reference to C.
>
> b) that we should decrease the externalRetains of A by 1. And we need to
> do that, because if we don't, and X stops retaining B, we start leaking
> A and B.
>
> This would be much easier to handle if we were tracking the extra
> refcount all the way through the tree:
>
>
> A (externalRetains == 2)
> |
> B<-X (externalRetains == 2)
> |
> C (externalRetains == 1)
> |
> D<-X (externalRetains == 1)
>
> Would that be about right? Also: Couldn't we just do away with this
> whole contraption if we had the children retain their parents while the
> parents only hold weak references to them?
>
> Also there is another thing I cannot quite wrap my head around right now
> and it would be nice if someone could elaborate on that as well: Why
> does NSXMLNode's -release method decrease the externalRetains only "if
> ([self retainCount] == [internal->subNodes count])" (NSXMLNode.m:590)?
>
> I already apologise if I'm just overlooking the obvious here. Also, I
> hope that I don't sound overly cirtical about this code, which I think
> is really a nice new feature. I already turned on some bits in DBusKit
> that require NSXML, and it turns out that it's working quite well in
> general :-)
>
> Cheers,
>
> Niels
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
NSSearchField remaining issues
Yesterday I updated NSSearchFieldCell.m (r31911) to fix a number of issues with things not displaying quite right and with the search menu in particular. Mostly search fields are now working much better, with behavior that more closely matches Cocoa. There are a couple of little things left that I didn't manage to track down, though, so if anyone else has an idea or cares to take a look that would be much appreciated. Specifically: 1. Clicking in the search field when it contains text but is not already being edited causes the insertion point to be placed in front of the text rather than at the click location. I tried to trace this problem in the debugger but there are lots of methods involved. It seems to basically be calling the same code as ordinary text fields, but it doesn't work the same for search fields for some reason. 2. On Windows, using the WinUX theme, the search menu items don't highlight as you drag the mouse over the menu. Other popup and pulldown menus are highlighting fine, and I think this is calling the same underlying code in a similar way (although I didn't dig into it extensively). So if anyone has an idea what might be missing here that would be helpful. Thanks, Doug Simons TestPlant, Inc. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Problem with processing of key events
Hello,
Some key events are not being processed exactly as they should be.
We have been experiencing a problem in this scenario: We have a window with a
table view, a "delete" button, and a text field. The delete button deletes the
selected item in the table view, and has its keyEquivalent set to the delete
key. So pressing delete with something selected in the table view will delete
it.
The problem is this: When we are editing a value in the text field, pressing
delete will still delete the selected item in the table view, rather than
deleting a character in the field. We don't have this problem on OS X.
After considerable time looking at the code and reading all of the relevant
parts of the Cocoa documentation, I think I've figured out what the difference
is and (more or less) how to fix it.
The Cocoa documentation talks about dispatching "events it recognizes as
potential key equivalents (based on the presence of modifier flags)" as key
equivalents. GNUstep has been sending ALL key events in this way, which caused
the problem, since the delete button would handle the event in its
performKeyEquivalent: method and it would never be sent to the text field.
So I've changed NSApplication's sendEvent: method to only call
performKeyEquivalent: when the event has modifier keys (other than the shift
key, which I think is not considered a modifier in this context).
With this change in place, the delete key event goes to the text field as it
should, but now the opposite problem exists, namely that the delete button
NEVER gets the event, even when the field is not being edited.
To handle this part of the problem, I modified NSWindow's keyDown: method to
send performKeyEquivalent: to itself. In this way, performKeyEquivalent: will
be sent to every view in the window for ALL keyDown events (that aren't
otherwise handled), those with modifiers first, from NSApplication, and those
without modifiers later, from NSWindow's keyDown after the event has been up
the responder chain.
I believe this is approximately how Cocoa handles it, based on backtraces I
captured (see below) although the documentation doesn't seem to be explicit
about this point.
My code in NSApplication looks like this:
NSApplication.m:2059
unsigned int modifiers = [theEvent modifierFlags];
BOOL usesModifiers = ((modifiers & ~NSShiftKeyMask) != 0);
BOOL handledKeyEquivalent = NO;
if (usesModifiers)
handledKeyEquivalent = [[self keyWindow] performKeyEquivalent:
theEvent];
if (handledKeyEquivalent == NO
&& [[self mainMenu] performKeyEquivalent: theEvent] == NO)
{
[[theEvent window] sendEvent: theEvent];
}
break;
And the code in NSWindow:
NSWindow.m: 3272
unsigned int modifiers = [theEvent modifierFlags];
BOOL usesModifiers = ((modifiers & ~NSShiftKeyMask) != 0);
if (!usesModifiers && [self performKeyEquivalent:theEvent])
return;
Let me know if you'd like me to go ahead and check this in -- I hesitate to
just throw it in without any warning in this case because this is tinkering
with fairly basic behavior that may have subtle impacts. The code in NSWindow
in particular could be moved earlier in the keyDown: method (and I'm inclined
to think that it should be) to allow performKeyEquivalent: to take precedence
over the standard tab and shift-tab behavior, etc. -- what do you think?
Regards,
Doug
P.S. Here are some Cocoa backtraces from our application running on OS X that
give some clues about how Cocoa handles these events:
Delete key pressed on view with the scenario presented above, with an item
selected in the table view and NO active field editor. Note that
performKeyEquivalent: is invoked from NSWindow's keyDown: method:
#0 0x00099a0b in -[EGGSuite deleteScripts:] at EGGSuite.m:3287
#1 0x9360ac46 in -[NSApplication sendAction:to:from:]
#2 0x93a06a8c in -[NSMatrix sendAction:to:]
#3 0x939f8fe5 in -[NSMatrix sendAction]
#4 0x93a066a1 in -[NSMatrix performKeyEquivalent:]
#5 0x93704858 in -[NSControl _performKeyEquivalent:conditionally:]
#6 0x939fff1f in -[NSMatrix _performKeyEquivalent:conditionally:]
#7 0x93704724 in -[NSView performKeyEquivalent:]
#8 0x93704724 in -[NSView performKeyEquivalent:]
#9 0x93704724 in -[NSView performKeyEquivalent:]
#10 0x93704724 in -[NSView performKeyEquivalent:]
#11 0x93704496 in -[NSWindow performKeyEquivalent:]
#12 0x937a97a7 in -[NSWindow keyDown:]
#13 0x935f7ac1 in forwardMethod
#14 0x935f7ac1 in forwardMethod
#15 0x935f7ac1 in forwardMethod
#16 0x935f7ac1 in forwardMethod
#17 0x935f7ac1 in forwardMethod
#18 0x935f7ac1 in forwardMethod
#19 0x938f6565 in -[NSControl keyDown:]
#20 0x937ddf61 in -[NSTableView keyDown:]
#21 0x936e1d38 in -[NSWindow sendEvent:]
#22 0x935fa817 in -[NSApplication sendEvent:]
#23 0x9358e2a7 in -[NSApplication run]
#24 0x935862d9 in NSApplicationMain
Re: [Gnustep-cvs] r31213 - in /libs/gui/trunk: ChangeLog Source/NSMenuView.m Source/NSPopUpButtonCell.m
Solved!
Okay, after much thought and carefully talking through this with Greg and my
colleague Jonathan, we've come up with what seems to be a good solution. This
involves adding a new theme method which allows us to inquire whether the
current theme handles event processing for a popUp menu. If so, we stop
processing events in the NSPopUpButtonCell after the menu window has been
attached. This works quite well to resolve the problem, since the basic issue
turned out to be that both the theme code and the NSPopUpButton/NSMenuView code
were taking responsibility for calling the action method. One is enough!
Here are my changes to the code in gui:
Index: Source/GSThemeMenu.m
===
--- Source/GSThemeMenu.m(revision 31561)
+++ Source/GSThemeMenu.m(working copy)
@@ -130,5 +130,11 @@
{
// default implementation of this method does nothing.
}
+
+- (BOOL) doesProcessEventsForPopUpMenu
+{
+ return NO; // themes that handle events in a popUpMenu should return YES
+}
+
@end
Index: Source/NSPopUpButtonCell.m
===
--- Source/NSPopUpButtonCell.m (revision 31561)
+++ Source/NSPopUpButtonCell.m (working copy)
@@ -993,6 +993,8 @@
// Attach the popUp
[self attachPopUpWithFrame: cellFrame
inView: controlView];
+ if ([[GSTheme theme] doesProcessEventsForPopUpMenu])
+return YES; // the theme handles the events, so we're done
p = [[controlView window] convertBaseToScreen: [theEvent locationInWindow]];
p = [menuWindow convertScreenToBase: p];
And here is the code change in the WinUXTheme:
Index: WinNSMenu.m
===
--- WinNSMenu.m (revision 31569)
+++ WinNSMenu.m (working copy)
@@ -495,6 +495,12 @@
win,
NULL);
}
+
+- (BOOL) doesProcessEventsForPopUpMenu
+{
+ return YES; // this theme handles all of the popUpMenu event processing
+}
+
@end
Fred, please let me know if this looks to you like a satisfactory solution, and
I'll check it in.
Thanks!
Doug
On Oct 26, 2010, at 9:49 PM, Doug Simons wrote:
> Hello Fred, Greg, and anyone else who cares to look at this problem with
> Windows events.
>
> Unfortunately, without the former fix in place the pulldown menus are not
> working correctly on Windows. Here's the situation:
>
> Our action method gets called twice on Windows when selecting an item from a
> pulldown menu.
> Unfortunately, the mechanism behind this has to do with Windows' tendency to
> call back into
> GNUstep whenever the app checks for incoming events. Here's a narrated
> transcript of what's happening:
>
> Breakpoint 3, -[NSMenuView trackWithEvent:] (self=0x1589148, _cmd=0x6dac7728,
> event=0x1474bc0)
>at NSMenuView.m:1444
> 1444 NSDate *theDistantFuture = [NSDate distantFuture];
> (gdb) bt
> #0 -[NSMenuView trackWithEvent:] (self=0x1589148, _cmd=0x6dac7728,
> event=0x1474bc0)
>at NSMenuView.m:1444
> #1 0x6d9471fb in -[NSMenuView mouseDown:] (self=0x1589148, _cmd=0x6dad7548,
> theEvent=0x1474bc0)
>at NSMenuView.m:1779
> #2 0x6d9639e6 in -[NSPopUpButtonCell trackMouse:inRect:ofView:untilMouseUp:]
> (self=0x9aaaef0,
>_cmd=0x6dad5d00, theEvent=0xb886a78, cellFrame=
>{origin = {x = 0, y = 0}, size = {width = 148, height = 26}},
> controlView=0x9ca5110,
>untilMouseUp=1 '\001') at NSPopUpButtonCell.m:1014
> #3 0x6d95f89a in -[NSPopUpButton mouseDown:] (self=0x9ca5110,
> _cmd=0x6db17d80,
>theEvent=0xb886a78) at NSPopUpButton.m:457
> #4 0x6d9ec8f3 in -[NSWindow sendEvent:] (self=0x9ae3f80, _cmd=0x6da77048,
> theEvent=0xb886a78)
>at NSWindow.m:3684
> #5 0x6d89dc8e in -[NSApplication run] (self=0x1317938, _cmd=0x6da6cd20) at
> NSApplication.m:1541
> #6 0x6d88220a in NSApplicationMain (argc=1, argv=0x10fda18) at Functions.m:89
> #7 0x004018bd in main (argc=1, argv=0x10fda18) at main.m:13
> (gdb)
>
> This is how we enter the NSMenuView trackWithEvent: method. So far, so good.
>
> The processing then continues normally through this method up to line 1659,
> at which point it
> (indirectly) calls our action method and hits another breakpoint:
>
> (gdb) n
> 1462 original = AUTORELEASE(RETAIN(event));
> (gdb)
> 1464 type = [event type];
> (gdb)
> [… many steps omitted here …]
> 1640 if (!justAttachedNewSubmenu && index !=
> _highlightedItemIndex)
> (gdb)
> 1659 event = [NSApp nextEventMatchingMask: eventMask
> (gdb) n
>
> Breakpoint 1, -[VNCConnection(ScriptGeneration) enterTypeTextKeys:]
> (self=0x1420260,
>_cmd=0x1702b78, sender=0x9aaaef0) at VNCConnection+ScriptGenera
Re: [Gnustep-cvs] r31213 - in /libs/gui/trunk: ChangeLog Source/NSMenuView.m Source/NSPopUpButtonCell.m
Thanks for the suggestion, Kai. But the problem is that we'd like to not change
existing GNUstep code in awkward ways. The code uses the standard
nextEventMatchingMask:... method to get the next event, which inevitably calls
some Windows function that allows the callbacks to come in.
Fortunately, after a lot of head scratching we've found a good solution, which
I'll post in a moment in response to my earlier message.
Doug
On Oct 27, 2010, at 8:43 AM, SPUeNTRUP - Kai Henningsen wrote:
> Hallo Doug,
>
> Am Tue, 26 Oct 2010 21:49:28 -0600
> schrieb Doug Simons :
>
>> 2. Figure out a more general solution for blocking callbacks from Windows
>> while getting events. This would be ideal,
>
> Surely those callbacks only happen when we call LRESULT DispatchMessage(const
> MSG *lpmsg); ?
>
> More precisely, the typical message loop looks like this:
>
>// Start the message loop.
>while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0)
>{
>if (bRet == -1)
>{
>// handle the error and possibly exit
>}
>else
>{
>TranslateMessage(&msg);
>DispatchMessage(&msg); <<< callbacks happen here
>}
>}
>
> It's not as if windows does callbacks here without being explicitly
> asked to. Presumably, you could just as well queue messages up and
> dispatch them later, if that is more convenient. Or ignore them
> altogether.
>
> For Windows API docs, see around here:
>
> http://msdn.microsoft.com/en-us/library/ms644928%28v=VS.85%29.aspx#creating_loop
>
> Mit freundlichen Grüßen aus Münster /
> with kind regards - Kai Henningsen
>
> --
> SPUeNTRUP Software
> An der Kleimannbrücke 52
> D-48157 Münster, Germany
>
> Reg: Münster Nr.29047
>
> Fon: +49 700 CALL CATS (=22552287)
> Fon: +49 251 322 311 0
> Fax: +49 251 322 311 99
>
> Web: http://www.cats.ms
> Mail: support-k...@cats.ms
>
> ___
> 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
Re: [Gnustep-cvs] r31213 - in /libs/gui/trunk: ChangeLog Source/NSMenuView.m Source/NSPopUpButtonCell.m
operly record the selected item. In my previous fix I modified the [NSPopUpButtonCell _popUpItemAction:] method to set the popup's selected item. As the code stands now, it's necessary to call that method for the menu to work properly, and that code is called as part of the chain initiated by the callback from Windows. So if the callback were eliminated the trackWithEvent: method would need to set the selected item, which probably makes better sense anyway. 3. Any other ideas? I would really like to see a good general solution to the callback problem, but it may not be trivial to do. Fred, you suggested that it might be possible to do something in the processCommand: method in the theme, but I'm not sure quite what you had in mind. Based on what I've described above, do you still think a solution might be possible there? I'm not sure how that method would decide whether to send the action callback or not. Comments and ideas are very welcome. Doug On Oct 19, 2010, at 2:31 PM, Fred Kiefer wrote: > Hi Doug, > > sorry the revert is already committed, but if there is a way to help you > I am willing to jump in. > In my first mail I suggested to add the popup test into the > processCommand: method of the tehme. I still think this should work, but > it may not be the best way to resolve the issue. Greg, who is more > familiar with that theme should know. > > Fred > > Am 19.10.2010 17:42, schrieb Doug Simons: >> Hi Fred, >> >> I apologize for letting this slide and not responding before. The >> changes I made definitely resolved some specific problems that we >> were seeing, but perhaps not solved in the best possible way. I >> certainly understand your point about addressing any Windows-specific >> issues in the backend or in the theme if possible. I just haven't had >> time to revisit the issue to see if there is a way to do that. If you >> have reverted my original fix then I will no doubt have to look into >> it again soon! ;-) >> >> I'll see if I can come up with a better solution this time. Working >> with the Windows integration is a challenge, particularly the way >> Windows has a habit of generating callbacks into our code while we're >> in the middle of doing something else, which I believe was one of the >> problems in this case. >> >> Doug >> >> On Oct 17, 2010, at 6:04 AM, Fred Kiefer wrote: >> >>> I never got a reply on this mail. I will now undo this dubious >>> change. If it was really required for the WinUX theme I hope that >>> somebody will add a corresponding change into that theme. I really >>> would have preferred to have some discussion on this subject. >>> >>> Fred >>> >>> Am 12.09.2010 20:49, schrieb Fred Kiefer: >>>> Am 31.08.2010 01:02, schrieb Doug Simons: >>>>> Author: dpsimons Date: Tue Aug 31 01:02:21 2010 New Revision: >>>>> 31213 >>>>> >>>>> URL: http://svn.gna.org/viewcvs/gnustep?rev=31213&view=rev >>>>> Log: fix problem of pulldown action not being called for >>>>> correct cell, and being called twice on Windows >>>>> >>>>> Modified: libs/gui/trunk/ChangeLog >>>>> libs/gui/trunk/Source/NSMenuView.m >>>>> libs/gui/trunk/Source/NSPopUpButtonCell.m >>>> >>>> Hi Doug, >>>> >>>> could you please explain the first part of this change? The code >>>> itself looks to me horribly wrong but I am sure you had good >>>> reasons for it. The change note says it was needed for Windows, >>>> but I cannot find any special handling for this case in our >>>> Windows backend. This leads me to the assumption that you needed >>>> this change to get the WinUX theme working. If this is correct, >>>> wouldn't it be better to fix the theme instead? Currently we have >>>> the basic idea that themes don't change any behaviour they only >>>> result in a different appearance. If this isn't true for the >>>> WinUX theme, and there may be good reasons for that, eg for a >>>> better Windows integration, it is the obligation of the theme to >>>> keep the results at least consistent. Most likely the >>>> processCommand: method of that theme will need some tweaking to >>>> work correctly in your case. Could you please look into this and >>>> undo the change on gui? >>>> >>>> Fred > > > ___ > 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
Re: [Gnustep-cvs] r31213 - in /libs/gui/trunk: ChangeLog Source/NSMenuView.m Source/NSPopUpButtonCell.m
Hi Fred, I apologize for letting this slide and not responding before. The changes I made definitely resolved some specific problems that we were seeing, but perhaps not solved in the best possible way. I certainly understand your point about addressing any Windows-specific issues in the backend or in the theme if possible. I just haven't had time to revisit the issue to see if there is a way to do that. If you have reverted my original fix then I will no doubt have to look into it again soon! ;-) I'll see if I can come up with a better solution this time. Working with the Windows integration is a challenge, particularly the way Windows has a habit of generating callbacks into our code while we're in the middle of doing something else, which I believe was one of the problems in this case. Doug On Oct 17, 2010, at 6:04 AM, Fred Kiefer wrote: > I never got a reply on this mail. I will now undo this dubious change. > If it was really required for the WinUX theme I hope that somebody will > add a corresponding change into that theme. I really would have > preferred to have some discussion on this subject. > > Fred > > Am 12.09.2010 20:49, schrieb Fred Kiefer: >> Am 31.08.2010 01:02, schrieb Doug Simons: >>> Author: dpsimons >>> Date: Tue Aug 31 01:02:21 2010 >>> New Revision: 31213 >>> >>> URL: http://svn.gna.org/viewcvs/gnustep?rev=31213&view=rev >>> Log: >>> fix problem of pulldown action not being called for correct cell, and being >>> called twice on Windows >>> >>> Modified: >>>libs/gui/trunk/ChangeLog >>>libs/gui/trunk/Source/NSMenuView.m >>>libs/gui/trunk/Source/NSPopUpButtonCell.m >> >> Hi Doug, >> >> could you please explain the first part of this change? The code itself >> looks to me horribly wrong but I am sure you had good reasons for it. >> The change note says it was needed for Windows, but I cannot find any >> special handling for this case in our Windows backend. This leads me to >> the assumption that you needed this change to get the WinUX theme >> working. If this is correct, wouldn't it be better to fix the theme >> instead? Currently we have the basic idea that themes don't change any >> behaviour they only result in a different appearance. If this isn't true >> for the WinUX theme, and there may be good reasons for that, eg for a >> better Windows integration, it is the obligation of the theme to keep >> the results at least consistent. >> Most likely the processCommand: method of that theme will need some >> tweaking to work correctly in your case. >> Could you please look into this and undo the change on gui? >> >> Fred > > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Problem with recent change to w32_activate.m -- PLEASE REVERT
Hi, The change made by Eric in r31206 to call [NSApp deactivate] when a WM_ACTIVEAPP message is received reporting that the app lost focus causes trouble. I'll describe what I know about the issue. In our application, if we have two editor windows open (call them A and B) and minimize the one that has focus (say, B) then Windows apparently sends this message even though the focus switches to window A (within the same instance of the app). Window A then becomes the key window, but when we restore window B by clicking on its tile in the task bar, it now becomes the key window but leaves window A in a broken state such that after clicking in window A you can make text selections there, but all keystrokes in window A are now sent to window B!! Closing window A and reopening that document is the only way to restore it to normal functioning. I added an NSLog at the point where the new code calls [NSApp deactivate] and found that it was called more than 20 times when I minimized a window. A comment I read online suggests that WM_ACTIVEAPP is sent for every window in the application. Perhaps that includes offscreen windows, because I only had 3 or 4 windows open at the time. Since these messages are also being sent on minimizing a window even when the app remains the active app it seems like this isn't really working the way it should. On restoring window B, I get the message "Bogus attempt to set key window" (from line 3897 of NSApplication.m) so clearly the application's notion of the key window is getting confused. I'd like to request that this change be reverted until a better implementation can be found that doesn't have these issues. Thanks! Doug P. S. Eric -- THANK YOU, THANK YOU, THANK YOU for fixing the problem with reverse ordering of windows while in gdb under Windows! Debugging is so much more tolerable now! ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: build error: Undefined reference to 'objc_sync_enter'
Thanks. Removing the weak reference fixes our problem. We're checking in that change to sync.m. Doug On Aug 25, 2010, at 9:47 AM, David Chisnall wrote: > On 25 Aug 2010, at 16:24, Gregory Casamento wrote: > >> The issue is the weak linking directive in sync.m. Windows doesn't >> support weak linking, so it ignores these functions. > > > The weak linkage shouldn't be needed anymore. It comes from back when sync.m > was in Foundation. Now it should be in ObjectiveC2.framework and libobjc2, > so you should never have the case when it's present in both the ObjC runtime > and the Foundation lib (which was the point of marking it weak - so that you > always used the runtime's version in preference to the one in Foundation). > > David > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
build error: Undefined reference to 'objc_sync_enter'
The recent changes in base have caused us to get link errors on objc_sync_enter and objc_sync_exit (on Windows). I don't understand what the problem is, since both functions are present in sync.m, which is being built (and is now the implementation of sync that we need). But currently the only way we can build our app is to roll back base to r31185. Help! Thanks, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
where did objc-gnu2next.h go?
Somewhere along the way in the last month or two the header file .../base/Headers/Additions/GNUstepBase/objc-gu2next.h went away. I can't find any mention of it in the ChangeLog and my SVN skills are insufficient to find what happened. Does anyone know why it was removed or if there is a replacement somewhere? Currently we are manually installing an old copy of this file into System/Library/Headers/GNUstepBase/ in order to be able to compile our app, which isn't at all ideal. Thanks for any help. Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
crashing in __objc_resolve_class_links
I recently updated to the tip of the trunk (r31073) and am now getting at least
2 different crashes in __objc_resolve_class_links as shown in the backtraces
below (on Ubuntu 8.04). I've rebuilt everything in case something was out of
sync. Does anyone have an idea what might be going on here?
Eggplant: /build/buildd/gcc-4.2-4.2.4/src/libobjc/class.c:561:
__objc_resolve_class_links: Assertion
`((class1->class_pointer)&&class1->class_pointer)->info)&0x2L)==0x2L))'
failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb55feb90 (LWP 1670)]
0xb7f37410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f37410 in __kernel_vsyscall ()
#1 0xb7280085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb7281a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb727910e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4 0xb73d31b1 in __objc_resolve_class_links () from /usr/lib/libobjc.so.2
#5 0xb7a5f069 in objc_registerClassPair (cls=0x87da460) at runtime.c:991
#6 0xb7a61055 in objc_sync_enter (obj=0x8b7ab58) at sync.m:77
- - - - - - -
Eggplant: /build/buildd/gcc-4.2-4.2.4/src/libobjc/class.c:560:
__objc_resolve_class_links: Assertion
`((class1)&&class1)->info)&0x1L)==0x1L))' failed.
Program received signal SIGABRT, Aborted.
[Switching to Thread 0xb41a7b90 (LWP 1686)]
0xb7f8c410 in __kernel_vsyscall ()
(gdb) bt
#0 0xb7f8c410 in __kernel_vsyscall ()
#1 0xb72d5085 in raise () from /lib/tls/i686/cmov/libc.so.6
#2 0xb72d6a01 in abort () from /lib/tls/i686/cmov/libc.so.6
#3 0xb72ce10e in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4 0xb74281db in __objc_resolve_class_links () from /usr/lib/libobjc.so.2
#5 0xb7aa28d7 in GSPrivateLoadModule (filename=0x8a71ef0,
errorStream=0xb73f5580,
loadCallback=0xb7950040 <_bundle_load_callback>, header=0x0,
debugFilename=0x0)
at objc-load.m:225
#6 0xb794fc91 in -[NSBundle load] (self=0x89042a0, _cmd=0xb7b33e08)
at NSBundle.m:1588
#7 0xb794cd74 in -[NSBundle principalClass] (self=0x89042a0, _cmd=0xb7eadcc0)
at NSBundle.m:1519
#8 0xb7c7b92e in converter_bundles (format=0xb7f5a178, producer=1 '\001')
at NSAttributedString.m:158
#9 0xb7c7bb7f in converter_class (format=0xb7f5a178, producer=6 '\006')
at NSAttributedString.m:210
#10 0xb7c7fb3b in -[NSAttributedString(AppKit)
dataFromRange:documentAttributes:error:] (self=0x856c250, _cmd=0xb7eade78,
range={location = 0, length = 77},
dict=0x88547a8, error=0x0) at NSAttributedString.m:1016
#11 0xb7c7a831 in -[NSAttributedString(AppKit)
RTFFromRange:documentAttributes:] (
self=0x856c250, _cmd=0x81c0530, range={location = 6, length = 77},
dict=0x88547a8) at NSAttributedString.m:947
Thanks,
Doug
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Is typing in Japanese supported?
Hello, I have a quick sanity question I hope someone can answer for me: Is typing in Japanese something that I should expect to "just work" in a GNUstep application? Specifically, we have a customer who is having trouble typing in Japanese in our GS app on a Windows system. Before we dig too deeply into troubleshooting it would be nice to know whether this ought to work on Windows. If so, then we'll have to try to figure out what configuration settings may need to be tweaked or whatever to get it working. If not, then at least we'll know and won't waste time beating our heads against the wall... :-) I have no clue about how typing in Japanese is done, or what settings may be relevant, so if you have any pointers that would be appreciated, but even a simple "yes it should work" (or "no it won't") at this point would be helpful. Thanks! Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Testing for drawing fixes r30523
Hi Quentin, Thanks for working on this! We look forward to rolling ahead once everything is working. Windows XP and later is all that matters to us. Cheers, Doug On Jun 11, 2010, at 4:46 AM, Quentin Mathé wrote: > On Wed, Jun 9, 2010 at 4:42 PM, Quentin Mathé wrote: > > I now have several applications that run fine such as Gorm and > SystemPreferences :-) > I can now tackle the drawing issue for real. > > I have started to work on the various drawing issues I have observed with the > Windows backend. This backend has issues very similar to the one I initially > reported for the Cairo backend (e.g. composite is broken in rotated > coordinates). > However GDI and Cairo are not the same, so I won't be able to just copy the > Cairo implementation as I initially hoped it. > > Since I don't know much about GDI and there are more than a single drawing > issue, I think it's going to take me a week or so to figure out the right > implementation. > > Can I use the updated GDI API introduced with Windows 2000? I doubt anyone is > currently interested in deploying Windows applications on older Windows > versions, but let me know… I'm interested in using SetWorldTransform() and > similar to support stuff like rotation. > > Doug, if you are stuck because of the issues I introduced, feel free to roll > back my changes (r30523 and 30524)… > > Cheers, > Quentin. > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Testing for drawing fixes r30523
Quentin, I don't know if this will help you or not, but we install everything in core in the SYSTEM domain, which requires these steps: cd base ./configure --with-installation-domain=SYSTEM make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install cd ../gui make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install cd ../back make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install The ./configure step is only needed in base. If you have previously installed things, you may need to do a 'make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM distclean' in each directory first. Good luck! Doug On Jun 8, 2010, at 3:54 AM, Quentin Mathé wrote: > > Le 7 juin 2010 à 18:39, Doug Simons a écrit : > >> Thanks Quentin, we appreciate it! >> >> For the sake of tracking this issue, I've opened bug #30069 in the bug >> system. > > ok. For now, I'm still trying to get GNUstep core & Gorm from svn trunk > properly installed on top of a GNUstep install with the Windows installers > from this page: http://www.gnustep.org/experience/Windows.html > I initially tried an install from scratch with the README.MinGW doc, but I > had various issues and had to give up on the fact GCC was unable to find the > libobjc headers when everything was set up. > > On my new install, when compiling the core libs, GNUstep Base and Gui headers > appear to be installed incorrectly. e.g. GNUstep/Local/Headers/Foundation > once installed contains no headers and GNUstep/Local/Library/Headers/AppKit > contains the headers that should be the GNUstepGUI directory (quite weird). > As a result of this, GSXibLoading.h is currently not found when I try to > compile Gorm. > > SystemPreferences from svn trunk once compiled and installed is also unable > to find libPreferencePanes-1.dll each time a .prefPane is loaded (I get a > warning dialog and an empty SystemPreferences window once the app launch is > done). > > If you have suggestions to solve these problems, I'm interested :-) > > Cheers, > Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Testing for drawing fixes r30523
Thanks Quentin, we appreciate it! For the sake of tracking this issue, I've opened bug #30069 in the bug system. Doug On Jun 7, 2010, at 3:35 AM, Quentin Mathé wrote: > Le 5 juin 2010 à 00:31, Doug Simons a écrit : > >> Did you have a chance to try this on Windows yet? We are stuck on moving >> forward with any new updates in gui or back until this is resolved, which >> is not good. > > I haven't yet, I was away for the week-end. I'm currently finishing to > install GNUstep on Windows. Once I get the example running, I'll solve the > issue asap. > > Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Testing for drawing fixes r30523
Quentin,
Did you have a chance to try this on Windows yet? We are stuck on moving
forward with any new updates in gui or back until this is resolved, which is
not good.
Thanks,
Doug
On Jun 3, 2010, at 9:41 AM, Doug Simons wrote:
> Quentin, thanks for working on this.
>
> As a simple test, I tried commenting out these lines:
>> if (viewIsFlipped && (self
>> != source))
>>{
>> destPoint.y -= sourceRect.size.height;
>>}
>
> That fixed the display of the image in the tableView, but introduced the same
> problem for all of the images of items in my toolbar: they were all shifted
> down and drawn with their tops in the same place as the item titles. So
> clearly a more sophisticated change is needed.
>
> I tried a couple of other things without success, but it would take some time
> for me to wrap my head around what's going on here and really understand it,
> so at this point I'm just poking at things in the dark.
>
> If you can get this running on Windows and make whatever adjustments it needs
> to work with your other recent changes, that would be greatly appreciated.
> Thanks!
>
> Doug
>
>
> On Jun 3, 2010, at 4:46 AM, Quentin Mathé wrote:
>
>> Hi Doug,
>>
>> Le 2 juin 2010 à 21:36, Doug Simons a écrit :
>>
>>> This change has broken some things on Windows. Here is a screenshot from
>>> our application showing the problem, with an image displayed in a tableView
>>> (the table here contains only one row):
>>>
>>>
>>>
>>> When I roll back this change, it displays as it should:
>>>
>>>
>>>
>>> It's hard to tell from this particular image, but the image itself is not
>>> flipped, just displaced. Hopefully that's enough for you to tell what's
>>> going on. If you need additional information please let me know.
>>
>> I think the backend is trying to compensate/revert an extra flipping
>> previously done in Gui.
>> The code where the problem is located is -[Win32GState
>> compositeGState:fromRect:toPoint:op:fraction:] pasted below.
>>
>> The implementation looks similar to the old Cairo implementation, so the
>> best way is probably to rewrite it in a similar way. That means I have to
>> set up Windows somewhere since it's hard to get the implementation right. I
>> don't have time today, but tomorrow I'll try to get a working GNUstep
>> install on Windows to work on it.
>>
>> By the way, does the scrolling still work on Windows?
>>
>>> if (viewIsFlipped && (self
>>> != source))
>>>{
>>> destPoint.y -= sourceRect.size.height;
>>>}
>>
>> You can try to remove this part since the backend shouldn't need it now. But
>> I I don't think it's enough to fix it.
>>
>>> destRect.origin = destPoint;
>>> destRect.size = sourceRect.size;
>>> [ctm boundingRectFor: destRect result: &destRect];
>>
>> The transform should be applied to destPoint only here.
>>
>>> rectTo = GSWindowRectToMS(
>>> self
>>> , destRect);
>>> x = rectTo.left;
>>> y = rectTo.bottom - sourceRect.size.height;
>>>
>>> {
>>>NSRect newRect;
>>>
>>>[source->ctm boundingRectFor: sourceRect result: &newRect];
>>>rectFrom = GSWindowRectToMS(source, newRect);
>>>y += (sourceRect.size.height - newRect.size.height);
>>> // adjust location for scaled source
>>
>> The line before the last one looks dubious to me. To get it working properly
>> in all cases (rotation, scaling, flipping etc.), I had to rewrite the Cairo
>> backend to use a more complex check.
>>
>> Thanks for feedback,
>> Quentin.
>>
>>
>> ___
>> 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
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Testing for drawing fixes r30523
Quentin, thanks for working on this.
As a simple test, I tried commenting out these lines:
> if (viewIsFlipped && (self
> != source))
>{
> destPoint.y -= sourceRect.size.height;
>}
That fixed the display of the image in the tableView, but introduced the same
problem for all of the images of items in my toolbar: they were all shifted
down and drawn with their tops in the same place as the item titles. So clearly
a more sophisticated change is needed.
I tried a couple of other things without success, but it would take some time
for me to wrap my head around what's going on here and really understand it, so
at this point I'm just poking at things in the dark.
If you can get this running on Windows and make whatever adjustments it needs
to work with your other recent changes, that would be greatly appreciated.
Thanks!
Doug
On Jun 3, 2010, at 4:46 AM, Quentin Mathé wrote:
> Hi Doug,
>
> Le 2 juin 2010 à 21:36, Doug Simons a écrit :
>
>> This change has broken some things on Windows. Here is a screenshot from our
>> application showing the problem, with an image displayed in a tableView (the
>> table here contains only one row):
>>
>>
>>
>> When I roll back this change, it displays as it should:
>>
>>
>>
>> It's hard to tell from this particular image, but the image itself is not
>> flipped, just displaced. Hopefully that's enough for you to tell what's
>> going on. If you need additional information please let me know.
>
> I think the backend is trying to compensate/revert an extra flipping
> previously done in Gui.
> The code where the problem is located is -[Win32GState
> compositeGState:fromRect:toPoint:op:fraction:] pasted below.
>
> The implementation looks similar to the old Cairo implementation, so the best
> way is probably to rewrite it in a similar way. That means I have to set up
> Windows somewhere since it's hard to get the implementation right. I don't
> have time today, but tomorrow I'll try to get a working GNUstep install on
> Windows to work on it.
>
> By the way, does the scrolling still work on Windows?
>
>> if (viewIsFlipped && (self
>> != source))
>>{
>> destPoint.y -= sourceRect.size.height;
>>}
>
> You can try to remove this part since the backend shouldn't need it now. But
> I I don't think it's enough to fix it.
>
>> destRect.origin = destPoint;
>> destRect.size = sourceRect.size;
>> [ctm boundingRectFor: destRect result: &destRect];
>
> The transform should be applied to destPoint only here.
>
>> rectTo = GSWindowRectToMS(
>> self
>> , destRect);
>> x = rectTo.left;
>> y = rectTo.bottom - sourceRect.size.height;
>>
>> {
>>NSRect newRect;
>>
>>[source->ctm boundingRectFor: sourceRect result: &newRect];
>>rectFrom = GSWindowRectToMS(source, newRect);
>>y += (sourceRect.size.height - newRect.size.height);
>> // adjust location for scaled source
>
> The line before the last one looks dubious to me. To get it working properly
> in all cases (rotation, scaling, flipping etc.), I had to rewrite the Cairo
> backend to use a more complex check.
>
> Thanks for feedback,
> Quentin.
>
>
> ___
> 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
Re: Testing for drawing fixes r30523
Hi,This change has broken some things on Windows. Here is a screenshot from our application showing the problem, with an image displayed in a tableView (the table here contains only one row):When I roll back this change, it displays as it should:It's hard to tell from this particular image, but the image itself is not flipped, just displaced. Hopefully that's enough for you to tell what's going on. If you need additional information please let me know.Doug On Jun 1, 2010, at 6:00 AM, Quentin Mathé wrote:Hi,I just committed a patch I have been working on for a while. See bug report https://savannah.gnu.org/bugs/?27782This should solve various differences between GNUstep vs Cocoa image drawing when Cairo is used, especially with -[NSImage drawInRect:fromRect:operation:fraction:] or similar.For the Cairo backend, this method should now give the same result than Cocoa when the destination is flipped, rotated or scaled. The scaling between the inRect and the fromRect should also work correctly. Various border cases such as passing NSZeroRect are now handled in a way that matches Cocoa.The performance should also be much better when you draw a small source rect from a big image, since we only manipulate the source rect area rather than the whole image now. We also do not create an intermediate image to apply the graphics context transform, we just delegate that to Cairo, so this should improve performance a bit too.Cairo also had various issues with -compositeGStateXXX and -DPSimageXXX. This means NSImage composite/dissolve methods now behave correctly, NSCopyBits too and -[NSView scrollRect:by:] should work in non-flipped coordinates unlike previously.The Cairo backend unlike other backends should now match the Cocoa image drawing behavior exactly. This should be visible if you play with NSAffineTransform a lot. For example, in a flipped view, concat a rotation, a scaling and a manual flip transform, then draw an image with by scaling it with inRect and fromRect.Art, Xlib and Winlib backends shouldn't have changed much since they still use the old code path. This code path is much more complex than the Cairo code path that delegates as much as possible to the backend rather than trying to handle things like rotation on the Gui side.I tested Cairo, Art and Xlib, they work fine for me with GSTest, Gorm and various Étoilé applications. I haven't tested the Winlib backend, so I'm interested to know if it still works correctly.I'll commit the test application I have been using to compare Cocoa vs GNUstep behavior soon.Although I tried to simplify the code as much as possible, there are still some cleaning to do and also things to be worked out. e.g. NSCopyBits doesn't behave the same on GNUstep and Cocoa when you give it a view gstate.Cheers,Quentin.___Gnustep-dev mailing listGnustep-dev@gnu.orghttp://lists.gnu.org/mailman/listinfo/gnustep-dev___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
compile broken by recent check-in
Is anyone else experiencing this problem? It seems to be caused by the change to base/Source/ObjectiveC2/runtime.h in r30438. Reverting that one change enables the build to proceed. I'm seeing this problem on both Windows and Linux: $ make GNUSTEP_INSTALLATION_DOMAIN=SYSTEM install This is gnustep-make 2.2.0. Type 'make print-gnustep-make-help' for help. Making all in Source... Making all in ObjectiveC2... Making all for subproject ObjectiveC2... Compiling file runtime.c ... In file included from runtime.c:1: .././ObjectiveC2/runtime.h:116: error: expected declaration specifiers or '...' before 'uint8_t' runtime.c:145: error: expected declaration specifiers or '...' before 'uint8_t' runtime.c: In function 'class_addIvar': runtime.c:181: error: 'alignment' undeclared (first use in this function) runtime.c:181: error: (Each undeclared identifier is reported only once runtime.c:181: error: for each function it appears in.) make[4]: *** [obj/runtime.c.o] Error 1 make[3]: *** [internal-subproject-all_] Error 2 make[2]: *** [ObjectiveC2.all.subproject.variables] Error 2 make[1]: *** [internal-all] Error 2 make: *** [internal-all] Error 2 It would be nice if this could be corrected (or reverted) soon. Thanks! Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: open recent in renaissance?
On May 10, 2010, at 1:28 PM, Fred Kiefer wrote: > As far as I know none of the GNUstep sample applications has a recent > document menu. This means we just don't know whether this works at all. I believe the recent document menu simply doesn't work right now. I looked into this a little bit a couple of months ago, and it appeared that most of the code was there, but a small part was missing -- as I recall it was missing the needed code to actually connect up the menu to the code in the document controller. I don't have easy access to the code right now to be more specific about what was missing, but it seemed like it would only take an hour or two to get it working. I just wasn't able to do it at the time. Doug (sent from a bus on the way to San Francisco airport) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
>> So the correct fix is simply to delete that block of code (and the >> declaration >> and assignment of 'sub' a few lines earlier). I've done that, and also >> delete >> the other call to setSupermenu: that I had added. > > If that works for you, all the better. It is always great to remove some > code :-) > > Did you also read the rest of my mail? What do you think about the > suggestion to move the last menu theme call out of NSApplication? > > With that (and the indentation) sorted out you should be able to push > your change. Done and committed. :-) Cheers, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: What happened to the code freeze?
Hello, Fred wrote: > As far as I can tell none of the recent commits in gui or back is > related to any reported bug. > [snip] > I am referring to the ongoing changes to gui by Eric and Doug. All of > these are valid changes as far as I can tell. They surely fix some > behaviour that was annoying enough for them. But all these changes may > and did also introduce new issues to others. This is fine in normal > development mode, while trying to come up with a stable release it wont > help. It's true that the changes I've been submitting aren't in response to bugs in the GNUstep bug system. We are actively fixing bugs in our own application. As an illustration, when we have a bug that affects only the Windows version of our product, I'm pretty sure that it's caused by a problem somewhere in GNUstep, but I don't know for sure until I dig in and debug exactly what's going wrong. This typically takes several hours of debugging, at which point I can see what the problem is, so I fix it. Now, at that point I suppose I could enter a bug on savannah and then mark it as fixed, but I don't really see the point of doing that (and I'm under a lot of time pressure right now, as we are scheduled for a release next week!). So I've just been careful to review my own fixes and try to describe what I'm fixing when I check it in. Since we're in 'code freeze' mode, I hope that someone (maybe more than one someone?) is looking at any changes that are checked in to make sure they look sane, and perhaps think about whether they might have unintended consequences. I'm about to check in a significant fix, that substantially improves performance on Windows (with in-window menus). The change dramatically reduces the frequency of rebuilding the Windows menus. They were rebuilding with every event rather than only when needed. The resulting drag on performance wasn't just an "annoyance" -- it basically made editing text in an NSTextView almost unusable. I've checked my code over carefully, and believe it won't have any negative consequences. As part of this fix, I corrected a bug in NSMenu which was never setting its supermenu ivar correctly, and improved NSMenuItem to only notify its menu that it has changed when something actually changes. It's conceivable that that could impact some other code, but is clearly more "correct" now than its former behavior. The main impact of this change will only be on Windows for applications that use in-window menus. For those applications, there is a small chance that I missed something such that menus will fail to update when they should, now that they're not updating all the time (I don't think so, but it's worth watching out for). I could hold off on submitting this change, but it seems to me like exactly the kind of fix that I (at least) would like to see going in right now. So I plan to check it in as soon as it's validated by some other people here. Please let me know if you see any problems with this change or any others that I submit. We really appreciate the timing of this "feature freeze", by the way, since we are in the middle of a release. Knowing that things are relatively stable and only getting bug fixes is perfect for us right now. And while I'm at it, I'd like to say "THANK YOU" to everyone on the GNUstep team! The more I dig into the code, the more I'm reminded of what an incredible amount of work has gone into it, and despite the bugs (which are frustrating, and are the cause of my digging into the code in the first place) there is an amazing amount of functionality here that is working really well. Hopefully our small contributions will help GNUstep to be even better. Cheers, Doug ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Issues with nextKeyView chain
Our application had a crash when deallocating a clipView, because its nextKeyView pointed to an object that had already been freed. On carefully reviewing the code, I discovered that the system is designed such that each view can have _multiple_ next and previous key views. I understand why a view could have multiple _previous_ key views (since it's possible to have several other views all pointing to it as their nextKeyView). But I don't believe a view should ever have more than one _next_ key view. I've checked in a change to NSView.m (r30088) that fixes this problem (part of the issue for us turned out to be caused by ivars being zeroed out at the wrong point during nib loading). But it appears to me that the code could be cleaned up and simplified quite a bit if everyone agrees with my assertion that a view should only have one (or zero) nextKeyView. To begin with, the _nextKeyView ivar could be turned into a direct pointer to the next key view rather than a GSIArray. Also, the code is not well encapsulated right now, as it makes direct changes to ivars of other objects. Does anyone see any reason not to change nextKeyView to a single object? Would someone familiar with that code like to make the change? (In particular, I'm unsure whether there may be other classes besides NSView that might be impacted…) Doug Simons TestPlant, Inc. P.S. I tried to send this twice before but it was rejected, so I'm trying this as a reply to a different thread. Any ideas why my email would be "delayed" with this message: "eggs.gnu.org:451 Could not complete sender verify callout" ? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Issues with nextKeyView chain
Our application had a crash when deallocating a clipView, because its nextKeyView pointed to an object that had already been freed. On carefully reviewing the code, I discovered that the system is designed such that each view can have _multiple_ next and previous key views. I understand why a view could have multiple _previous_ key views (since it's possible to have several other views all pointing to it as their nextKeyView). But I don't believe a view should ever have more than one _next_ key view. I've checked in a change to NSView.m (r30088) that fixes this problem (part of the issue for us turned out to be caused by ivars being zeroed out at the wrong point during nib loading). But it appears to me that the code could be cleaned up and simplified quite a bit if everyone agrees with my assertion that a view should only have one (or zero) nextKeyView. To begin with, the _nextKeyView ivar could be turned into a direct pointer to the next key view rather than a GSIArray. Also, the code is not well encapsulated right now, as it makes direct changes to ivars of other objects. Does anyone see any reason not to change nextKeyView to a single object? Would someone familiar with that code like to make the change? (In particular, I'm unsure whether there may be other classes besides NSView that might be impacted…) Doug Simons TestPlant, Inc. P.S. I tried to send this twice before but it was rejected, so I'm trying this from a different account. Any ideas why my email would be "delayed" with this message: "eggs.gnu.org:451 Could not complete sender verify callout" ? "Be kind whenever possible. It is always possible." - Dalai Lama ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
awakeFromNib not called on File's Owner
As far as I can tell, the NSSecureTextView in our nib is now loading properly
-- thanks for that fix!
Unfortunately, this only gets us to the next problem: awakeFromNib is not being
called on the nib file's owner.
In digging through this issue in gdb I noticed that this nib is another one
that contains objects which load other nib files in their init methods. I don't
think this is the cause, because I think we have other nibs that do the same
that are loading okay, but I thought I'd mention it.
I didn't see where the code is supposed to call awakeFromNib on the owner -- is
the file's owner supposed to be one of the regular objects in the nib's list of
objects? It's not in that list.
Also, I noticed that one of the objects that is in the list is a custom object
that resolves to NSApp, causing awakeFromNib to be called on NSApp for EVERY
NIB that is loaded. This seems wrong to me (although it isn't causing us any
trouble). In fact, I just set a breakpoint on our application's awakeFromNib on
Mac OS X and verified that it is only called once by Cocoa, when the MainMenu
nib is loaded.
Doug
On Mar 24, 2010, at 2:00 AM, Fred Kiefer wrote:
> No this wasn't caused by the NIB loading fixes, this time it was the
> NSTextView change I made :-)
> While investigating the NIB problem I noticed that Ink kept on to each
> text network it created. I thought that there was no point in fixing NIB
> loading when most the same objects get retain just a little bit later
> anyway and so I fixed that as well. The basic issue was that the text
> storage was retained inside of NSTextView buildUpTextNetwork:, but not
> set into the ivar. Correcting this removed the memory leak here. But it
> also uncovered places where we weren't careful enough about our text
> network. The method replaceTextContainer: was one such place, here the
> text storage now needs an extra retain to have it around for the whole
> method execution. The same is true in the NSTextContainer method
> replaceLayoutManager: and Riccardo pointed me to that in a private mail
> yesterday. At the time you reported this bug it was already fixed in
> SVN, if we could only be that fast all the time.
>
> The whole text system network is really too complicated. Removing an
> object at one level could trigger a release at a completely different
> level. It would just be great if somebody with enough time at hand could
> have a deep look at all this and see how it could be restructured.
>
> Part of the problem here is the way we program in GNUstep. I try to use
> as much explicit memory handling as possible. That is, to avoid auto
> released objects. The benefit of this is that objects get freed as soon
> as they are no longer needed. But sometimes this might be a little bit
> to early, as the recent problems show. With auto release objects these
> would stay around until their auto release pool get drained and many
> issues could be hidden that way. Still I am reluctant to change my
> coding style. I think a library should be as strict as possible with
> memory usage. What ever wast can be avoided should be avoided.
>
> Fred
>
> Am 23.03.2010 23:15, schrieb Doug Simons:
>> Okay, here's another problem that's apparently been exposed by the recent
>> changes to retains when loading a nib. It appears there is a problem in the
>> way objects retain/release each other in the text system.
>>
>> We have an NSSecureTextField in a panel loaded from a nib file. When the
>> panel is displayed, it tries to setup the secure text field which replaces
>> the layout manager with a secure layout manager. But when
>> replaceLayoutManager: calls [textStorage removeLayoutManager:
>> _layoutManager] this results in the textStorage object itself being freed,
>> and it crashes on the next line. I tried to figure out what was going on,
>> but there are a lot of subtle interconnections in the text system, so I'm
>> not sure exactly what isn't being retained that needs to be (or is being
>> released that shouldn't be!).
>>
>> Here's what the crash looks like:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x67848ae6 in objc_msg_lookup () from
>> c:\GNUstep\GNUstep\System\Tools\objc-1.dll
>> (gdb) bt
>> #0 0x67848ae6 in objc_msg_lookup () from
>> c:\GNUstep\GNUstep\System\Tools\objc-1.dll
>> #1 0x63c24e04 in -[NSTextContainer replaceLayoutManager:] (self=0x9de34b0,
>> _cmd=0x63d65b38,
>>aLayoutManager=0x144b890) at NSTextContainer.m:171
>> #2 0x63bee87e in -[NSSecureTextView initWithFrame:textContainer:]
>> (self=0x1401ea0,
>>_cmd=0x63db4870, frameRect={origin = {x = 0, y = 0}, size
TextStorage freed when its LayoutManager is removed
Okay, here's another problem that's apparently been exposed by the recent
changes to retains when loading a nib. It appears there is a problem in the way
objects retain/release each other in the text system.
We have an NSSecureTextField in a panel loaded from a nib file. When the panel
is displayed, it tries to setup the secure text field which replaces the layout
manager with a secure layout manager. But when replaceLayoutManager: calls
[textStorage removeLayoutManager: _layoutManager] this results in the
textStorage object itself being freed, and it crashes on the next line. I tried
to figure out what was going on, but there are a lot of subtle interconnections
in the text system, so I'm not sure exactly what isn't being retained that
needs to be (or is being released that shouldn't be!).
Here's what the crash looks like:
Program received signal SIGSEGV, Segmentation fault.
0x67848ae6 in objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
(gdb) bt
#0 0x67848ae6 in objc_msg_lookup () from
c:\GNUstep\GNUstep\System\Tools\objc-1.dll
#1 0x63c24e04 in -[NSTextContainer replaceLayoutManager:] (self=0x9de34b0,
_cmd=0x63d65b38,
aLayoutManager=0x144b890) at NSTextContainer.m:171
#2 0x63bee87e in -[NSSecureTextView initWithFrame:textContainer:]
(self=0x1401ea0,
_cmd=0x63db4870, frameRect={origin = {x = 0, y = 0}, size = {width = 0,
height = 0}},
aTextContainer=0x9de34b0) at NSSecureTextField.m:305
#3 0x63c9e5f1 in -[NSTextView initWithFrame:] (self=0x1401ea0,
_cmd=0x63d8b058, frameRect=
{origin = {x = 0, y = 0}, size = {width = 0, height = 0}}) at
NSTextView.m:744
#4 0x63c3aa9c in -[NSView init] (self=0x1401ea0, _cmd=0x63d65aa8) at
NSView.m:566
#5 0x63bee378 in -[NSSecureTextFieldCell setUpFieldEditorAttributes:]
(self=0x15a35a0,
_cmd=0x63d7df98, textObject=0x1290ee0) at NSSecureTextField.m:209
#6 0x63c2649e in -[NSTextField selectText:] (self=0x994d9d0, _cmd=0x63d7e070,
sender=0x994d9d0)
at NSTextField.m:181
#7 0x63c26e17 in -[NSTextField becomeFirstResponder] (self=0x994d9d0,
_cmd=0x63d91b70)
at NSTextField.m:431
#8 0x63c53285 in -[NSWindow makeFirstResponder:] (self=0x16594c0,
_cmd=0x585240,
aResponder=0x994d9d0) at NSWindow.m:3176
On Mar 22, 2010, at 3:44 PM, Doug Simons wrote:
> Thanks Fred,
>
> It looks like that has fixed the problem with NSApp. It also appears to have
> solved the other problem that I reported to you privately. We will do some
> more testing and let you know if we run into any other problems with nib
> loading. Thanks for the quick fix!
>
> Regards,
>
> Doug
>
> On Mar 22, 2010, at 3:27 PM, Fred Kiefer wrote:
>
>> Thank you for pointing out the problem with NSApp. This was caused by a
>> missing retain in some part of GSNibLoading that I hadn't cleaned up.
>>
>> Hopefully this is fixed now. If there are any other issues I hope we can
>> resolve them as quick as that one.
>>
>> Fred
>>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Thanks Fred,
It looks like that has fixed the problem with NSApp. It also appears to have
solved the other problem that I reported to you privately. We will do some more
testing and let you know if we run into any other problems with nib loading.
Thanks for the quick fix!
Regards,
Doug
On Mar 22, 2010, at 3:27 PM, Fred Kiefer wrote:
> Thank you for pointing out the problem with NSApp. This was caused by a
> missing retain in some part of GSNibLoading that I hadn't cleaned up.
>
> Hopefully this is fixed now. If there are any other issues I hope we can
> resolve them as quick as that one.
>
> Fred
>
> Am 22.03.2010 18:24, schrieb Doug Simons:
>> I'm not positive, but I'm guessing that these nib loading changes
>> checked in over the weekend are the cause of new crashes that we are
>> seeing when building with the latest code (r30018) on Windows.
>>
>> Our app now crashes on launch. Here's the relevant gdb output:
>>
>> Program received signal SIGSEGV, Segmentation fault. 0x67848ae6 in
>> objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
>> (gdb) bt #0 0x67848ae6 in objc_msg_lookup () from
>> c:\GNUstep\GNUstep\System\Tools\objc-1.dll #1 0x63c4ba52 in
>> -[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
>> NSWindow.m:754 #2 0x65a2afad in -[NSObject release] (self=0x151f1a8,
>> _cmd=0x65b1b850) at NSObject.m:1890 #3 0x6594337f in -[GSArray
>> dealloc] (self=0x99fee40, _cmd=0x65b59950) at GSArray.m:136 #4
>> 0x65a2afad in -[NSObject release] (self=0x99fee40, _cmd=0x65b2dc50)
>> at NSObject.m:1890 #5 0x659971dc in -[NSAutoreleasePool emptyPool]
>> (self=0x1215cb8, _cmd=0x65b2dcc0) at NSAutoreleasePool.m:441 #6
>> 0x65996ff2 in -[NSAutoreleasePool dealloc] (self=0x1215cb8,
>> _cmd=0x65b2dcb8) at NSAutoreleasePool.m:342 #7 0x65996fb8 in
>> -[NSAutoreleasePool release] (self=0x1215cb8, _cmd=0x53b228) at
>> NSAutoreleasePool.m:335 #8 0x004209de in -[EggplantApplication
>> finishLaunching] (self=0x1211510, _cmd=0x63cf1af0) at
>> EggplantApplication.m:262 #9 0x63adedfc in -[NSApplication run]
>> (self=0x1211510, _cmd=0x63ce6ca0) at NSApplication.m:1506 #10
>> 0x63ac1f0f in NSApplicationMain (argc=1, argv=0x10ae698) at
>> Functions.m:74 #11 0x00401a65 in main (argc=1, argv=0x10ae698) at
>> main.m:13 (gdb) up #1 0x63c4ba52 in -[NSWindow dealloc]
>> (self=0x151f1a8, _cmd=0x65b59950) at NSWindow.m:754 754 [NSApp
>> removeWindowsItem: self]; (gdb) p NSApp $1 = (class NSApplication *)
>> 0x1211510 (gdb) p *NSApp $2 = {{{isa = 0xfeeefeee}, _interface_style
>> = 4277075694, _next_responder = 0xfeeefeee, _menu = 0xfeeefeee},
>> _default_context = 0xfeeefeee, _current_event = 0xfeeefeee, _session
>> = 0xfeeefeee, _key_window = 0xfeeefeee, _main_window = 0xfeeefeee,
>> _delegate = 0xfeeefeee, _listener = 0xfeeefeee, _main_menu =
>> 0xfeeefeee, _windows_menu = 0xfeeefeee, _app_is_launched = 238 'ε',
>> _app_is_running = 254 '■', _app_is_active = 238 'ε', _app_is_hidden =
>> 254 '■', _unhide_on_activation = 238 'ε', _windows_need_update = 254
>> '■', _app_icon = 0xfeeefeee, _app_icon_window = 0xfeeefeee, _hidden =
>> 0xfeeefeee, _inactive = 0xfeeefeee, _hidden_key = 0xfeeefeee,
>> _infoPanel = 0xfeeefeee, _runLoopPool = 0xfeeefeee} (gdb)
>>
>> As you can see, NSApp has been freed!! I'm guessing this is because
>> it is the File's Owner for our main nib file? I'm not sure how else
>> to explain it getting released.
>>
>> By adding [NSApp retain] we can get beyond this point, but are
>> hitting other problems with object loaded from nibs.
>>
>> Can someone familiar with the recent changes see what might be
>> causing NSApp to be released? Something is clearly broken here.
>> Thanks!
>
>
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
I'm not positive, but I'm guessing that these nib loading changes checked in
over the weekend are the cause of new crashes that we are seeing when building
with the latest code (r30018) on Windows.
Our app now crashes on launch. Here's the relevant gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x67848ae6 in objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
(gdb) bt
#0 0x67848ae6 in objc_msg_lookup () from
c:\GNUstep\GNUstep\System\Tools\objc-1.dll
#1 0x63c4ba52 in -[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
NSWindow.m:754
#2 0x65a2afad in -[NSObject release] (self=0x151f1a8, _cmd=0x65b1b850) at
NSObject.m:1890
#3 0x6594337f in -[GSArray dealloc] (self=0x99fee40, _cmd=0x65b59950) at
GSArray.m:136
#4 0x65a2afad in -[NSObject release] (self=0x99fee40, _cmd=0x65b2dc50) at
NSObject.m:1890
#5 0x659971dc in -[NSAutoreleasePool emptyPool] (self=0x1215cb8,
_cmd=0x65b2dcc0)
at NSAutoreleasePool.m:441
#6 0x65996ff2 in -[NSAutoreleasePool dealloc] (self=0x1215cb8, _cmd=0x65b2dcb8)
at NSAutoreleasePool.m:342
#7 0x65996fb8 in -[NSAutoreleasePool release] (self=0x1215cb8, _cmd=0x53b228)
at NSAutoreleasePool.m:335
#8 0x004209de in -[EggplantApplication finishLaunching] (self=0x1211510,
_cmd=0x63cf1af0)
at EggplantApplication.m:262
#9 0x63adedfc in -[NSApplication run] (self=0x1211510, _cmd=0x63ce6ca0) at
NSApplication.m:1506
#10 0x63ac1f0f in NSApplicationMain (argc=1, argv=0x10ae698) at Functions.m:74
#11 0x00401a65 in main (argc=1, argv=0x10ae698) at main.m:13
(gdb) up
#1 0x63c4ba52 in -[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
NSWindow.m:754
754 [NSApp removeWindowsItem: self];
(gdb) p NSApp
$1 = (class NSApplication *) 0x1211510
(gdb) p *NSApp
$2 = {{{isa = 0xfeeefeee}, _interface_style = 4277075694, _next_responder =
0xfeeefeee,
_menu = 0xfeeefeee}, _default_context = 0xfeeefeee, _current_event =
0xfeeefeee,
_session = 0xfeeefeee, _key_window = 0xfeeefeee, _main_window = 0xfeeefeee,
_delegate = 0xfeeefeee, _listener = 0xfeeefeee, _main_menu = 0xfeeefeee,
_windows_menu = 0xfeeefeee, _app_is_launched = 238 'ε', _app_is_running = 254
'■',
_app_is_active = 238 'ε', _app_is_hidden = 254 '■', _unhide_on_activation =
238 'ε',
_windows_need_update = 254 '■', _app_icon = 0xfeeefeee, _app_icon_window =
0xfeeefeee,
_hidden = 0xfeeefeee, _inactive = 0xfeeefeee, _hidden_key = 0xfeeefeee,
_infoPanel = 0xfeeefeee, _runLoopPool = 0xfeeefeee}
(gdb)
As you can see, NSApp has been freed!! I'm guessing this is because it is the
File's Owner for our main nib file? I'm not sure how else to explain it getting
released.
By adding [NSApp retain] we can get beyond this point, but are hitting other
problems with object loaded from nibs.
Can someone familiar with the recent changes see what might be causing NSApp to
be released? Something is clearly broken here. Thanks!
Doug
On Mar 22, 2010, at 8:12 AM, Wolfgang Lux wrote:
> Hi Fred!
>
>> Am 19.03.2010 09:20, schrieb Fred Kiefer:
>>> My current position on NIB loading is that no magic should happen there.
>>> Objects created while loading a NIB file should follow the standard
>>> rules. Nothing will be retained except for the top level objects being
>>> retained in the top level object array. (And of course instantiated and
>>> visible windows by the normal window display mechanism)
>>> That way anything that is not retained by the owner or specifically
>>> extracted from the top level object array will be freed after loading
>>> the NIB file when no other reference exists.
>>> If we can all agree on this position (and better yet, check that it is
>>> valid on Cocoa), I am going to change our code into this direction.
>>> This may require some extra handling in NSWindowController or NSDocument.
>>
>> Wolfgang was right, the problem in Bean was not relate to NIB loading at
>> all. This issue should be resolved (or at least worked around), by the
>> change I made to NSDocument last night.
>>
>> The problem with NIB loading was rather that we retained too much. I
>> tried to resolve this by adding proper releasing of the real object to
>> many of the NIB loading helper classes and correcting the top level
>> object handling there as well. This is only the beginning of more clean
>> up, but should resolve most of the known issues.
>
> Thanks for cleaning this up. I had a look at this, too, and was totally
> frustrated by the code. Apparently, the author of that code either does not
> understand or does not care about object ownership.
>
>> Could you please give this code a try and load your favourite NIB file?
>> I haven't tried the results this change has on Gorm, which should also
>> be tested.
>
> Unfortunately, your change introduces a new bug. In NSBundleAdditions, the
> owner is now bound to key NSNibOwner, but GSGormLoading (still) expects it to
> be NSOwner. GSNibLoading also uses NSOwner as primary key but at least uses
> NSNibOwner as fa
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Okay, we've resolved this issue in our code at this point. We had a situation where a controller object was being instantiated within our MainMenu.nib. When that controller's init method was called it was loading another nib, and it was an object in that nib (or maybe lots of them, who knows?) that was being freed before we could retain it in our applicationDidFinishLaunching: method in the controller. We removed the controller instance from the MainMenu.nib and are instantiating it separately in code (which is probably better anyway) and are no longer crashing. Doug Simons P.S. No stupid company disclaimer this time -- I'll try to remember to delete it in the future. :-) On Mar 18, 2010, at 2:24 AM, Fred Kiefer wrote: > Just in case my last mail wasn't clear enough on that point: All you > have to do to get your application working again with the current NIB > loading code is to add a setter method that retains its argument. > And for us it would be important to have an example of how it is failing > without that setter. > > Fred > > Am 17.03.2010 20:16, schrieb Fred Kiefer: >> I don't expect to see much differences between Windows and X11 on NIB >> loading. If you could provide me with an stripped down example I would >> try to have a look at what goes wrong there. >> >> I'm already investigating an issue with the new code when loading a NIB >> file that Wolfgang prepared for Ink. But there things seem to be the >> other way around. Object are retained while loading that shouldn't be. >> >> What you cannot expect in the short run is a revert of this code. If we >> start that there will be no stopping. The intermediate code was proven >> wrong and it had issues for Wolfgang. Now the new code, which is the old >> one, should be correct as far as we know, but it may uncover issues with >> NIB loading that had been previously hidden. I think it is better to >> track this issues down. Hiding issues wont help. Take a look at the hack >> Greg added some time ago into NSClipView to have it retain the cursor >> twice when loading it from a NIB file. This was not only wrong, it also >> hid the fact that the NSCursor un-archiving was broken. >> >> I am really willing to help you here, but for that I will need some code >> to work with that clearly shows this problem (and is proven to work on >> Apple). >> >> Fred >> >> PS: Have we talked about your stupid disclaimer before? Is there a way >> to turn it off when sending mails to this mailing list? >> >> >> Am 17.03.2010 18:19, schrieb Doug Simons: >>> Unfortunately, this change (Fred's commit in r29223) has broken our >>> ported Cocoa application (at least on Windows -- haven't had time to >>> check on Linux yet). At least some objects in our nib files are now >>> freed after the nib loads, and our application crashes when trying to >>> access them. Reverting NSBundleAdditions.m to the version prior to >>> r29223 fixes the problem for us. >>> >>> We would appreciate if this change could be backed out until this >>> problem can be resolved. I don't understand everything that's going >>> on during nib loading well enough to attempt to solve this myself. >>> Thanks! >>> >>> -- Doug Simons Principal Developer >>> >>> >>> TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 >>> 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA >>> http://www.testplant.com This email and any attachments may contain >>> privileged / confidential information. If you have received this >>> email in error or believe that you are not the intended recipient, >>> please delete all content and attached files and contact TestPlant >>> via the switchboard on +1 720-890-0211 or via return e-mail. You >>> should not copy, forward or use any part of the contents in any way. >>> Any such unauthorised use or disclosure may be unlawful. >>> ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Unfortunately, this change (Fred's commit in r29223) has broken our ported Cocoa application (at least on Windows -- haven't had time to check on Linux yet). At least some objects in our nib files are now freed after the nib loads, and our application crashes when trying to access them. Reverting NSBundleAdditions.m to the version prior to r29223 fixes the problem for us. We would appreciate if this change could be backed out until this problem can be resolved. I don't understand everything that's going on during nib loading well enough to attempt to solve this myself. Thanks! -- Doug Simons Principal Developer TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA http://www.testplant.com This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. On Mar 13, 2010, at 6:21 AM, Fred Kiefer wrote: > Am 13.03.2010 00:31, schrieb Wolfgang Lux: >> Fred Kiefer wrote: >> >>> Thank you for looking into this. >>> Looks like the basic difference between Cocoa and us is in the window, >>> window controller and document interaction. And you are the sole expert >>> we have on this :-) >> >> At the end of the day it looks like my expertise isn't needed here. The >> problem rather seems to be a space leak in the nib loading code, which >> seems to retain the owner of the nib file. To make testing a bit simpler >> I've attached a hopefully faithful translation of Ink's Document.gorm >> into a nib file with Apple's InterfaceBuilder. When I use that nib file >> instead of Document.gorm, Ink does not release the document when its >> window is closed. The window itself and its window controller are >> released correctly. > > Thank you for looking into this: I will try to resolve this issue. I > remember scattering FIXME's in the NIB loading code some time ago. One > of them might come in helpful now. > >>> I think it is now save to replace the NIB outlet connector code. I just >>> checked the old code against the new runtime functions of base and as >>> far as I can tell the old code would still work. We could just revert my >>> change. >> >> Please do so. > > Done :-) > > > ___ > 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
Re: [Gnustep-cvs] r29912 - in /libs/back/trunk: ChangeLog Source/win32/WIN32Server.m
Capturing the mouse allows GNUstep to receive mouseDragged events when the mouse is outside of the window. Without this, the autoscroll mechanism doesn't work properly when a user moves the mouse out of the window while holding the button down. I'm not at all expert (in fact I'm a complete newbie) with regards to the Windows event API, so I'm very open to other suggestions. The call to SetCapture() that I added solves the problem, and I was careful to call ReleaseCapture() when there are no longer any mouse buttons down. Hopefully that's done in such a way that it will always get called when the mouse is released. I didn't see anything in Microsoft's documentation about what happens if SetCapture() is called more than once, so I was presuming it's a simple on/off toggle, with extra calls being ignored, but I don't know that for sure. Let me know if anyone has a better idea for how to do this. -- Doug Simons Principal Developer TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA http://www.testplant.com This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. On Mar 13, 2010, at 5:15 AM, Fred Kiefer wrote: > Am 12.03.2010 22:29, schrieb Doug Simons: >> Author: dpsimons >> Date: Fri Mar 12 22:29:37 2010 >> New Revision: 29912 >> >> URL: http://svn.gna.org/viewcvs/gnustep?rev=29912&view=rev >> Log: >> capture the mouse to get mouse moved events outside of window >> >> Modified: >>libs/back/trunk/ChangeLog >>libs/back/trunk/Source/win32/WIN32Server.m > > Hi Doug, > > are you sure this is what you need to do? Capturing the mouse is a very > dangerous operation, you have to make sure you always get to the release > code as well. And if this code interacts with user code that actually > tries to capture the mouse, we may get into unclear states. > > If I understand your comment then this is about getting the mouse up > event that follows a mouse down on a GNUstep window. When the mouse > moves out of the window this event wont get send to GNUstep, so we will > think the mouse is still up. Is this the problem you are trying to address? > There must be a difference in the event handling of X11, as we don't > need to capture the mouse there. Perhaps the mouse up event there is > always send to the window where the mouse went down? > > Sorry, I am no longer familiar with all that code, it has been ages > since I last dug that deep into the difference of the event model of X11 > and Windows. > > Fred > ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
problems building on Windows
Recent updates have left base unbuildable for me on Windows (I haven't tried other platforms). Are some of the recent changes still being checked in? Here's the last part of what I'm seeing (I'm currently at r29700): Compiling file NSUserDefaults.m ... Linking subproject win32 ... Making all for library libgnustep-base... Compiling file inet_pton.c ... In file included from ../Headers/Additions/GNUstepBase/preface.h:79, from GNUstepBase/GSConfig.h:221, from inet_pton.c:22: c:/GNUstep/GNUstep/System/Library/Headers/objc/objc.h:42: error: conflicting types for 'BOOL' c:\gnustep\mingw\bin\../lib/gcc/mingw32/4.4.0/../../../../include/windef.h:234: note: previous decla ration of 'BOOL' was here make[3]: *** [obj/inet_pton.c.o] Error 1 make[2]: *** [internal-library-all_] Error 2 make[1]: *** [libgnustep-base.all.library.variables] Error 2 make: *** [internal-all] Error 2 -- Doug Simons Principal Developer TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA http://www.testplant.com This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r29026 - /libs/gui/branches/testplant_1/Source/NSMenuView.m
I agree that my present solution is a workaround. The code I added checks whether the window is actually in a different place than the frame that is recorded in the NSWindow object, and adjusts the mouse location accordingly. But obviously the real problem is that the NSWindow doesn't know where the window really is. Are you saying that the backend notifies the gui of the window movement through posting an asynchronous notification? I would have thought it would make a direct call for something like that, but then I don't know anything about the backend and how it's structured. I assumed that the notification was just broken somehow (or not implemented) but I don't have the knowledge needed to fix the problem, hence the workaround. I don't know what the right solution is, but it doesn't seem like developers who use GNUstep (such as myself) should have to worry about running an event loop periodically in order to guarantee the internal consistency of the system. But maybe that wasn't quite what you meant. -- Doug Simons Principal Developer TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA http://www.testplant.com This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. On Nov 18, 2009, at 2:11 AM, Fred Kiefer wrote: Doug Simons schrieb: Author: dpsimons Date: Mon Nov 16 23:51:14 2009 New Revision: 29026 URL: http://svn.gna.org/viewcvs/gnustep?rev=29026&view=rev Log: fix problem with mouse tracking being off in submenus that are shifted to stay on screen Modified: libs/gui/branches/testplant_1/Source/NSMenuView.m I think that this is an important patch we should discuss on this mailing list. The patch clearly is wrong, as it is only trying to address the result of a problem, but not the problem itself. What happens is that after opening a submenu the interaction of the mouse has an offset, when the window manager repositions the submenu. I think that this is caused by the code not accepting any repositioning events for the submenu. I would expect that the backend tries to tell gui where the submenu window did get positioned, but as we are in a tracking loop we ignore these events. An easy solution would be to run the normal event loop for a short time after we attach a new submenu, but this looks like just another hack. Any better idea, how to resolve the issue? ___ 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
Re: Question on NSXMLNode and related classes
Hi Richard, Thanks for your reply! Actually, we're fairly heavily invested in using the NSXMLNode API's. So if we were going to look at GSXML or any other library, it would be as a means to implement those classes. I have no inside information about how Apple's implementation works, but I see that libxml2 is installed on the system, so your assumption that they use it seems reasonable. So probably building the GNUstep implementation on that library will help to keep everything compatible. Here's a list of the methods we are using in these classes (it's possible that I missed a couple, but this should be close): NSXMLNode Methods: + elementWithName: + elementWithName:children:attributes: + textWithStringValue: + attributeWithName:stringValue: + commentWithStringValue: + processingInstructionWithName:stringValue: - kind - name - setName: - childCount - children - childAtIndex: - parent - nextNode - previousNode - nextSibling - previousSibling - detach - stringValue - setStringValue: - XMLString - XMLStringWithOptions: - description - copy - copyWithZone: - XPath - nodesForXPath:error: NSXMLDocument Methods: + initWithRootElement: + initWithXMLString:options:error: - initWithRootElement: - rootElement - characterEncoding - documentContentKind - MIMEType - URI - DTD - version - setCharacterEncoding: - setDocumentContentKind: - setMIMEType: - setURI: - setVersion: - XMLData NSXMLElement Methods: - initWithName: - initWithXMLString:error: - setChildren: - addChild: - removeChildAtIndex: - insertChild:atIndex: - replaceChildAtIndex:withNode: - attributes - addAttribute: - setAttributesAsDictionary: - removeAttributeForName: - normalizeAdjacentTextNodesPreservingCDATA: Let me know if you have more questions about our use of any of this. -- Doug Simons Principal Developer TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA http://www.testplant.com This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. On Aug 28, 2009, at 9:28 AM, Richard Frith-Macdonald wrote: On 28 Aug 2009, at 16:12, Richard Frith-Macdonald wrote: On 27 Aug 2009, at 18:43, Doug Simons wrote: Hello all, Currently in GNUstep, the NSXMLNode class and its relatives have been stubbed out but not implemented yet. Because of this our application on Mac includes XML parsing and generating capabilities that are missing from the Linux/GNUstep version. We would love to add this functionality to the Linux version. Unfortunately, our current development schedule won't give us a chance to devote any large chunks of time to this until probably sometime next year. My question right now is a general one about where these XML classes fit in the GNUstep list of priorities. Specifically, is anyone likely to be working on them in the next few months? It will help our planning and setting expectations with our customers. While we don't have time to do the implementation ourselves, we would be very happy to help with testing and debugging. Our code covers a substantial number of the methods in these classes, so I think we can help ensure that at least the basic functionality is all working the same as in Cocoa when the implementation gets to that point. I don't think they fit in the list of priorities at all ... mostly we add new stuff when people actually ask for it and are prepared to devote time to it, and do long term prioritisation of stuff on the basis of actual needs. Historically GNUstep has been way ahead of OSX in XML support, as we had the GSXML classes long before OSX had any XML support, and we fully implemented Apple's NSXMLParser before Apple did! Most likely, any functionality from the new XML classes is already available in the GSXML classes, so you might not need the new stuff. All that being said ... I've had quite a lot of experience implementing/using XML code, and i'd like to get those classes in place just for API completeness/ tidyness if nothing else. The current stubs are designed on the assumption (based on Apple's new API) that Apple implemented their new classes on top of libxml2, and we might do the same. However, Dr Nikolaus Shaller has done partial native objc implementations in his software, which we can incorporate into GNUstep if we want. So ... if Apple did not wrap libxml2 (can you confirm that one way or the other) we could definitely adopt one of those two approaches ... and I ought to be
Question on NSXMLNode and related classes
Hello all, Currently in GNUstep, the NSXMLNode class and its relatives have been stubbed out but not implemented yet. Because of this our application on Mac includes XML parsing and generating capabilities that are missing from the Linux/GNUstep version. We would love to add this functionality to the Linux version. Unfortunately, our current development schedule won't give us a chance to devote any large chunks of time to this until probably sometime next year. My question right now is a general one about where these XML classes fit in the GNUstep list of priorities. Specifically, is anyone likely to be working on them in the next few months? It will help our planning and setting expectations with our customers. While we don't have time to do the implementation ourselves, we would be very happy to help with testing and debugging. Our code covers a substantial number of the methods in these classes, so I think we can help ensure that at least the basic functionality is all working the same as in Cocoa when the implementation gets to that point. Thanks! GNUstep is an amazing project, and we very much appreciate the tremendous amount of effort that has gone into it. -- Doug Simons Principal Developer TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA http://www.testplant.com This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r28488 - /libs/gui/branches/testplant_1/
Hi, sorry if I'm not following protocol. These are my first direct commits. I entered a log message on each change, but I guess that doesn't automatically go to the ChangeLog. How should I go about entering information in the ChangeLog? As for the purpose of the branch: We need a known version that we have verified works for us, for our production builds. We would like to be using the tip of the trunk, in order to get recent fixes, but some of the recent commits have broken things for us. Until we have time to track those down and get them corrected, we need a place to add some of our own fixes based on a version that is stable for us. We will also try to build from the trunk when we have a chance during our development, and find, report, or fix any issues we run into. But we've found that the tip is too risky (understandably!) for deployment builds. Hopefully, our fixes can be merged into the trunk, and we can jump our branch ahead (or create new branches, I guess) to later points along the trunk periodically, when we are able to verify a version that works for us. -- Doug Simons Principal Developer TestPlant Inc T+1 720-890-0211 ext 13 4730 Walnut Street F+1 720-890-0209 Boulder, CO 80301 doug.sim...@testplant.com USA http://www.testplant.com This email and any attachments may contain privileged / confidential information. If you have received this email in error or believe that you are not the intended recipient, please delete all content and attached files and contact TestPlant via the switchboard on +1 720-890-0211 or via return e-mail. You should not copy, forward or use any part of the contents in any way. Any such unauthorised use or disclosure may be unlawful. On Aug 21, 2009, at 8:43 AM, Riccardo Mottola wrote: Fred Kiefer wrote: Gregory Casamento schrieb: Author: gcasa Date: Thu Aug 20 00:25:33 2009 New Revision: 28488 URL: http://svn.gna.org/viewcvs/gnustep?rev=28488&view=rev Log: Add new branch with corrected revision number. Added: libs/gui/branches/testplant_1/ - copied from r28233, libs/gui/trunk/ Hi Greg, could you please explain the purpose of this new branch? I can see that Doug and Jonathan have started using it. Most of the changes they made up to now are perfectly legitimate for trunk (Apart from those already in trunk and that GSContext change. I am unsure about the NSOpenPanel patch) Who will be porting these changes back to trunk? Currently the commits on the branch are without Change log entries, how are we going to add these? I think I can agree with Fred here, keeping the ChangeLog would make things much easier in the futuere event of a merge. Riccardo ___ 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
Re: Elevating privileges
Apple's Security framework provides this sort of functionality in Cocoa. It looks like at least parts of it are open source: http://developer.apple.com/opensource/security/ I don't know if that will do what you want but it may be a place to start. Doug "The best way to predict the future is to invent it." - Alan Kay, 1971 On Mar 26, 2009, at 4:23 PM, Steven L wrote: Hello, I'm working on an application that would require elevated privileges during certain functions. I would like to implement something like the SuSE Yast setup tool, where if a function is selected by a non privileged user, a prompt is presented for the root password, which in turn allows the function to perform properly. I don't know what the technique is to achieve this. So far I'm looking at Linux "capabilities", libcap, but I'm not sure this is the right direction and if this solution would be portable, to say a BSD based GNUstep system. Many thanks for your help Steven ___ 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
Re: Question on NSToolbar
On Jan 2, 2009, at 2:55 PM, Fred Kiefer wrote: And I changed the code to resize the content view instead of resizing the whole window. I think this is what Apple is doing and it will lead to less flickery displays. Actually, when a toolbar is shown or hidden Apple resizes the window to accommodate the change, not the content view. Currently, GNUstep does the same. So I think changing this is a bad idea, unless you meant something different here... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
