Emacs.app (from BZR) and GNUstep (from SVN)
Currently Emacs.app crash at launch with GNUstep. It worked fine
previously. I thought
it was caused by changes in emacs, but someone has confirmed it works
fine with the stable
packages of GNUstep (I will test it tomorrow). So the problem could be
in gnustep. Below I
add the backtrace. The app crash because can't retain a pixmap.
Here the backtrace:
(gdb) backtrace
#0 objc_msg_lookup (receiver=0x1400016, op=0x8482710)
at /home/german/Instalados/GCC/gcc-4.6.0/libobjc/sendmsg.c:397
#1 0x082657b0 in ns_retain_object (obj=0x1400016) at nsterm.m:466
#2 0x08255ac2 in XGetImage (display=0x89af8e8, pixmap=0x1400016, x=0,
y=0,
width=64, height=64, plane_mask=4294967295, format=2) at
image.c:160
#3 0xb50a62ea in ?? () from /usr/lib/libcairo.so.2
#4 0x089af8e8 in ?? ()
#5 0x01400016 in ?? ()
#6 0x in ?? ()
(gdb)
At frame 2 the function XGetImage is:
XImagePtr
XGetImage (Display *display, Pixmap pixmap, int x, int y,
unsigned int width, unsigned int height,
unsigned long plane_mask, int format)
{
/* TODO: not sure what this function is supposed to do.. */
ns_retain_object (pixmap);
return pixmap;
}
And at frame 1 the function ns_retain_object is:
void
ns_retain_object (void *obj)
/*
--
Retain an object (callable from C)
--
*/
{
[(id)obj retain];
}
Can this problem be related with the changes about how the images
are handled? Any idea? Thanks.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Open/Save panel issue
Hi Sebastian, Thanks for the report… should be fixed now. -Eric On 2011-12-22, at 12:52 AM, Sebastian Reitenbach wrote: > > On Wednesday, December 21, 2011 07:46 CET, Eric Wasylishen > wrote: > >> Hi Germán, thanks for pointing that out. I inadvertently deleted the code to >> draw the highlighted background when working on NSBrowserCell - It should be >> fixed now. >> >> Do the file icons I added in the open/save dialog browsers look good? > > the icons are very close to each other, overlapping a bit, is that intended > to be that way? > > Sebastian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTextField didn't change color on set...Color: while editing.
-- Sent from my GNU/Linux N900 On Thu Dec 22 2011 06:09:30 PM ICT, Ivan Vučica wrote: > I sincerely hope my comments are not the primary cause for two > contributors announcing they are dropping out. It really is nothing about you. I even started this not you. And dont take this in a bad way, but I didnt even take your opinions seriously as they dont make much sense to me, but that probably is my fault coz I always overlook things as I am a mad horse with rabies. And as it was pointed out, that is not about only one single decision. If a project has to lose momentum by every random comment, it deserved to die. > Isn't this sort of thing easily correctable in a project with source code > availability? If you are unhappy with this particular behavior, just > change it. If you are unhappy with upstream implementation and you don't > want to maintain your own fork, you can do subclassing, you can do method > swizzling. You can do a lot without the upstream losing one of the > coolest things about it: compatibility with a major platform. Because it should be obvious that I wasnt considered myself a GNUstep libraries user, but a GNUstep dev. I can assure you that everyone here know that fork is a solution, some of them did that for this particular problem, no need to tell about that. Let me take it this way, if you want a Cocoa behavior, why dont you fork or subclassing etc. etc. and let GNUstep do the right thing right? May be someone could start a separated project dedicated for that, ie. cloning all Cocoa things that doesnt make sense. > I love the fact that I can mess with GNUstep's innards if I want to. I > also love the fact that I can write tons of code for GNUstep and easily > get it to run on another big platform, without worrying about details > which may not be liked by developers. > > I don't really like how NSTableView is used. I don't really like how > NSOutlineView is used. However, I feel the solution is not in changing > them, but in adding functionality to them, or adding GNUstep-specific > additional classes which implement different ideas one may have about how > table view's methods should be named, how they should be used and how > they should work. > > If one dislikes how NSTextField works, why not write a GNUstep-specific > replacement instead of making the existing text field behave different, > even if the original behavior seems less-than-ideal? > > And yes, I do agree that the behavior we're discussing here has surprised > me extremely, and not in a good way. It does make sense now that I > understand why it occurs, but I still feel that the solution is in adding > behavior, not in changing behavior. > > -- > Ivan Vučica - i...@vucica.net I think you may want to check RFM's opinion as it already sums your stories up quite nicely. Nonetheless I am giving up this thread, TLDR, unsubscribing. And good luck guys.___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTextField didn't change color on set...Color: while editing.
On Wed, Dec 21, 2011 at 10:05, Banlu Kemiyatorn wrote: > ** > > What is this _reasonable_ compatible implementation you are talking about > on this specific case, technically? The only point that was if not almost > valid was that users may want to repeatly set colors for a cell during > editing when the cell itself is not even visible, rather set it only once > when text did end editing. > I sincerely hope my comments are not the primary cause for two contributors announcing they are dropping out. Isn't this sort of thing easily correctable in a project with source code availability? If you are unhappy with this particular behavior, just change it. If you are unhappy with upstream implementation and you don't want to maintain your own fork, you can do subclassing, you can do method swizzling. You can do a lot without the upstream losing one of the coolest things about it: compatibility with a major platform. I love the fact that I can mess with GNUstep's innards if I want to. I also love the fact that I can write tons of code for GNUstep and easily get it to run on another big platform, without worrying about details which may not be liked by developers. I don't really like how NSTableView is used. I don't really like how NSOutlineView is used. However, I feel the solution is not in changing them, but in adding functionality to them, or adding GNUstep-specific additional classes which implement different ideas one may have about how table view's methods should be named, how they should be used and how they should work. If one dislikes how NSTextField works, why not write a GNUstep-specific replacement instead of making the existing text field behave different, even if the original behavior seems less-than-ideal? And yes, I do agree that the behavior we're discussing here has surprised me extremely, and not in a good way. It does make sense now that I understand why it occurs, but I still feel that the solution is in adding behavior, not in changing behavior. -- Ivan Vučica - i...@vucica.net ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
