Problem with SuSE 7.1
I upgraded my system to SuSE 7.1 with Linux kernel 2.4.0 and XFree86 4.0.2 and all the other releases that come with it. I than did a 'make distclean' in all the gnustep core modules and run the configure/make/install cycle for make, core, gui and xgps. This did not work well for gui, so I had to do a 'make install' instead of 'make; make install'. But than everything looked alright. The error reported was: mkdir -p example.service/Resources /bin/sh: opentool: command not found make[3]: *** [example.service/Resources/Info-gnustep.plist] Error 1 make[2]: *** [example.build] Error 2 make[1]: *** [example.all.svc.variables] Error 2 make[1]: Leaving directory `/lin3/usr/src/gnustep/core/gui/Tools' make: *** [internal-all] Error 2 Now the first problem is that I get an error message from make_services: Feb 12 12:25:45 make_services[631] missing info - /usr/GNUstep/System/Library/Services/example.service I keep on ignoring this and get a X error each time an AlertPanel or the file open panel is called from Ink: Feb 12 16:04:35 Ink[4016] X-Windows error - BadMatch (invalid parameter attributes) on display: :0.0 type: 0 serial number: 3425 request code: 73 Feb 12 16:04:36 Ink[4016] X-Windows error - BadMatch (invalid parameter attributes) on display: :0.0 type: 0 serial number: 3426 request code: 73 Debugging shows that this comes from _pixmap_combine_alpha() and the problem also disappears when I replace the Ink_app.tiff with another tiff file. So it is just the displaying of the icon that goes wrong. What further information is neede to track that problem down? The tiff library is libtiff.so.3 and wraster is libwraster.so.2.0.0 ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Problem with SuSE 7.1
Thank you for that help. Yes it is the image size, somehow the Xfree86 release 4.0.2 is not as tolerant as older releases about indexes that are out of range. I will provide a smaller icon for Ink, but in the long run we will have to correct image scaling, otherwise that problem will keep on popping up. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Problem with NSColor/NSString initialisation
While searching for another problem in NSComboBoxCell I ran into an
initialization problem that I don't quite understand. Perhaps someone on
this list can explain it and even fix it?
When running this small test program, I get a lot of error messages from
NSColor.
#include Foundation/NSAutoreleasePool.h
#include Foundation/NSString.h
#include AppKit/NSComboBox.h
#include AppKit/NSComboBoxCell.h
int main (int argc, const char *argv[])
{
CREATE_AUTORELEASE_POOL(pool);
NSComboBox *cb;
int n = 0;
/*
NSString *str = @"0.00 0.00 0.00";
const char*ptr = [str cString];
float r, g, b;
//NSLog(@"Found string %s", ptr);
n = sscanf(ptr, "%f %f %f", r, g, b);
if (n == 3)
{
NSLog(@"Resulted in Color %f, %f, %f", r, g, b);
}
else
NSLog(@"Only found %d", n);
*/
NSLog(@"Control uses %@", [NSControl cellClass]);
NSLog(@"ComboBox uses %@", [NSComboBox cellClass]);
NSLog(@"Control uses %@", [NSControl cellClass]);
[NSComboBox setCellClass: [NSComboBoxCell class]];
NSLog(@"Control uses %@", [NSControl cellClass]);
NSLog(@"ComboBox uses %@", [NSComboBox cellClass]);
RELEASE(pool);
return 0;
}
The output is (with the corrected version of ComboBox):
Apr 09 22:27:58 cell[2674] System color 'controlTextColor' has bad
string rep -
'0.00 0.00 0.00'
Apr 09 22:27:58 cell[2674] System color 'disabledControlTextColor' has
bad string rep - '0.333000 0.333000 0.333000'
Apr 09 22:27:58 cell[2674] System color 'controlDarkShadowColor' has bad
string
rep - '0.00 0.00 0.00'
Apr 09 22:27:58 cell[2674] Control uses NSCell
Apr 09 22:27:58 cell[2674] System color 'textBackgroundColor' has bad
string rep - '1.00 1.00 1.00'
Apr 09 22:27:58 cell[2674] System color 'textColor' has bad string rep -
'0.00 0.00 0.00'
Apr 09 22:27:58 cell[2674] ComboBox uses NSComboBoxCell
Apr 09 22:27:58 cell[2674] Control uses NSCell
Apr 09 22:27:58 cell[2674] Control uses NSCell
Apr 09 22:27:58 cell[2674] ComboBox uses NSComboBoxCell
Ignore the last four line, as they are the expected output. This shows
that NSColor is not able to convert some string values into colours.
When I just add one NSLog line before the first access of any ComboBox
or Control, e.g. by uncommenting the last line before that, this error
messages vanish and everything works fine.
From this I think that the problem is caused by a missing initialization
of NSString, but how could that happen?
Any explanation of this phenomena is welcome
Fred
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Problem with NSColor/NSString initialisation
Adam Fedor wrote: I just tried your sample program and got the expected output (No errors). This is with all the latest CVS code installed. -- Adam Fedor, Digital Optics| Fudd's law of opposition: Push [EMAIL PROTECTED] http://www.doc.com | something hard enough, and it [EMAIL PROTECTED] http://www.gnustep.org | will fall over. I installed the newest release of GNUstep and all the libraies as recommended (Which took some time to get it working, because of the NSProcessInfo bug introduced by Richard. For two days my SuSE Linux 2.4.0 kernel produced a segmentation fault for every GNUstep program). Not that this is working I still get the error messages from NSColor on the string conversion. The only difference I see may be in the GNUstepmake file, that I did not include. I did compile it as a test application, so my Makefile looks something like; GNUSTEP_INSTALLATION_DIR = $(GNUSTEP_SYSTEM_ROOT) GNUSTEP_MAKEFILES = $(GNUSTEP_SYSTEM_ROOT)/Makefiles include $(GNUSTEP_MAKEFILES)/common.make # The application to be compiled TEST_APP_NAME = cell # The Objective-C source files to be compiled cell_OBJC_FILES = cell.m # The Resource files to be copied into the app's resources directory -include GNUmakefile.preamble -include GNUmakefile.local include $(GNUSTEP_MAKEFILES)/test-application.make -include GNUmakefile.postamble Is there a problem with this, or is it in the runtime that does not resolve the initilisation of the classes correctly. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Segfault from NSMatrix
NSMatrix still produces a segmentation fault if you click between two items. This can be tested with the NSBox example of GSTest. Mirko, could you please send a short description of what you have changed on that class and in which state this changes are. I looked at the changelog, but this does not help much to get the idea behind the changes. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Problem with dragging
I did just switch to KDE 2.2 and now dragging does no longer work in GNUstep. I don't want to start any discussion about window managers, GNUstep will try to work together with any window manager that follows the rules. And KDE is on of them, we will have to support the new release (Which by the way is the first 2.X release of KDE that I find worth using). Richard, you did rewrite the window finding code the last time, do you have KDE 2.2 to reproduce this problem? Or should I look into this myself? Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Fix: NSView, view clipping
Hi Georg, I am having the same drawing problems, where sometimes parts of a window is missing (e.g. in the Box test of GSTest). So any solution to this would be fine. I had a look at your clipping code and did not quite understand it. Your code seems to add another stack to the graphics context, while we already use a stack for the gstates, which should be handling the clipping as well. I don't think that we should introduce a new PS call for this functionality, it should already be possible to implement this by correcting our current code. First of all [NSView lockFocusInRect:] looks wrong. It only uses the given rect to set the clipping when there is no gstate for the current view. This are, as far as I see it, two independent operations, the gstate of the view must have its clipping set to the extend of the view and for each new lock focus we must restrict the clipping to the current rectangle. Perhaps solving this would make your problem disappear. If not the problem is with the gstate itself and we should have a closer look on this. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: bug in NSMenu
Hi Benhur, tahnk you for this bug report. I tried to fix it with two changes to NSMenu. For one now the initWithCoder will send all notifications at the end and when inserting an item the notification is send before the menu of the item is set. Please check if this changes remove all your problems. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Problem with window placement
Enrico Sersale wrote: On Sat, 17 Nov 2001, Stéphane PERON wrote: Hi, I am under WindowMaker 0.7 with Xfree4. When I put a Gnustep window in the top left corner of the root screen, at each launching of the concerned application, the window is moving left. Do it ten times and you will notice the window moving. Do you have this bug too ? Bye Stef Yes, it seems that, hiding and showing 10 times a window, make it to move 27 up and -9 left. Enrico I think nobody ever replied to this mail. The problem seems to come from the way GNUstep places windows. It has to take the border of a window into account to do this correcly, but we have currently no sure way to tell, how big the borders are that get provided by the window manager . So when GNUstep gets them wrong it misplaces the window a bit in your case 3 pixel in one and 1 in the other direction. I will have a deeper look into this, at least for a mapped window it should be possible to get the correct values. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: XQueryTree problems in xgps
Hi Adam, the surprising thing with that patch is that it even works on my KDE 2 environment. I am sure that I had to add the iterative call to XQueryTree here to get the different levels of additional windows sorted out on this platform, but now even a drag and drop between different applications seems to work without it. I don't quite understand how this could work, but if this will work in all cases we might even be able to drop the switch for double parenting checks. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Fonts (2) - problems with GSFontAntiAlias 'YES'
Perhaps I should explain a bit more on how the current Anti-Alias font implementation works and which limitations are caused by this. This code was a hack that I came up with kust to see if there is any demand for better fonts in the GNUstep community or if this is only a low priority addon. Currently the available fonts are determined by the font cacher using the standard X font enumeration. This knows nothing about anti-aliasing and which fonts would support it. Than when a font is selected and AA is switched on the normal X name of the font is handed on to the AA font module that tries to create a font for this X name, if it does not find a suitable AA font it falls back on a standard AA font (or even a simple X font). SO what would be needed here is a separate font manager for the AA fonts that would run its own cacher, looking only at AA fonts. This manager could than know more about the available fonts and select a better one if the requested is not available. This should explain your 3. problem and a way to solve it. What it does not account for is the first problem you are having. For this I will need some more information. Does this only happen for specific text? (E.g. some encodings might not be available for the AA fonts) I could not reproduce this with the standard GNUstep applications. Cheers Fred Pascal Bourguignon wrote: Pascal Bourguignon wrote: When I open the Font Panel, I get a list with about 60 different fonts. However, in the Preview they all look the same but the following: I reverted the xgps backend to find fonts by pixel size. Please let me know if anything improves. Yes and no. I updated from CVS 12 yours ago (after your email), and tested it now. Here are the results. (See attached window content dumps). I've found what produced the bad results I got : I had the following default set: NSGlobalDomain GSFontAntiAlias 'YES' When removing it, everything works as expected, I can change the fonts and size with the corresponding defaults and I don't get any black rectangle. When I have NSGlobalDomain GSFontAntiAlias 'YES' set, then: 1/ It seems that for most windows, the display of the text halts halfway. For the menu, I've seen once when updating slowly that it had transitorily the state of black rectangles, then the text was overwritten. For the other windows, when resizing the window, sometimes the text would appear and sometimes it would disappear, but this state stays untile the window is resized again. Notably, for the open panel, whatever navigation is done don't change the state black rectangle or text. Moving the window off-screen, then back on-scren does not change anything. The same occurs for the Font panel. When I don't get the black rectangles, it previews correctly the fonts. The text in pop-up menus appears correctly. It's probably the same bug than that that don't display pictures in a window when not running with a runloop. Note that in that case, moving the window off-screen then on-screen would at least show the picture. 2/ The sizes are correct. The NSFontSize default is not taken into account, but the other NS*FontSize are. 3/ The same font is used everywhere (seems to be Times) but in the menu title. Thanks for the font size correction. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Small FontPanel glitch.
Hi Pascal, I tried to implement some of the font panel features you did describe. Please test them if they fit your expectations. As for the keyboard navigation and the text editing we need a lot more support from the rest of the gui lib. NSBrowser still lacks the up and down navigation and currently it is not even possible to change the size value with keyboard input. As soon as this is there I will add more of the listed features. Cheers Fred Pascal Bourguignon wrote: Fred Kiefer [EMAIL PROTECTED] wrote: Hi Pascal, a few days back yopu wrote this mail: Pascal Bourguignon wrote: There is this small bug in the Font Panel: 1/ The typeface selected in the list of typefaces is not synchronized with the typeface shown in the font name in the preview box. When selecting for example: Helvetica Normal 12PT and preview, then clicking ont Times in the Family column shows Time NoFace 12 PT in the preview box, in Times (I don't know if it's Times NoFace or Times Normal), but the Typeface column still shows the Normal typeface selected. I would expect that if the selected typeface exists in the new font, then the new font should be displayed with this same typeface. If not, then the typeface should be deselected from the Typeface column. 2/ Now, bug of feature: once selected and previewed a font, if we unselect the Preview button, and continue browsing the fonts, the name of the font (family, typeface and size) displayed in the preview box stays unchanged. I'll check as soon as possible on my OPENSTEP 4.2, but I believe that at all times the preview box should show the selected font name. I'll come back on this with the OPENSTEP Font panel behavior. Could you confirm the OpenStep behaviour? If so I would try to adjust the GNUstep code to fit with that. Cheers Fred Oops ! I promised to come back with the OPENSTEP Font Panel behavior, which I promptly tested and documented, but then my notes stayed forgotten unsentbetween my NeXTstationand my GNUstep workstation. Sorry for the delay. Here it is: There are differencies of behavior of the Font Panel between GNUstep and OPENSTEP 4.2. Here is a description of the behavior of the Font Panel on OPENSTEP 4.2 on the points where it differs. IMHO, most of these differences should be implemented in GNUstep too, because they're more user friendly and logical. - When selecting a Family and Typeface (let's say Courrier-Bold), then selecting another Family that has the same Typeface (eg. Helvetica) will select the other Family with the same Typeface (Helvetica-Bold will be selected). - When selecting a Family and Typeface (let's say Courrier-Bold), then selecting another Family that has more than one typefaces, none the same than the currently selected (eg. Shalom), then no typeface will be selected in the column, but one of the typeface is used to write the name in the preview box. This should be considered a bug, the behavior of the GNUstep Font Panel, writting noface is better here. But IMHO, it would be best to select the first typeface in the column and use it in the name written. - There are some exceptions probably due to some equivalence between some typefaces. With: Textbook-Medium Textbook-Italic Textbook-Bold Times-Roman Times-Italic Times-Bold Times-BoldItalic when selecting Times-BoldItalic, then clicking on Textbook selects no typeface ; but when selecting Times-Roman, then clicking on Textbook selects the Medium typeface. Regular, Medium, Normal, Roman seems to be equivalent. I think that this feature introduce some strangeness to the algorithm and that we should keep clear and logical rules and we should avoid it. - When selecting a Family and Typeface (let's say Courrier-Bold), then selecting another Family that only has one typeface (eg. Palladam), then this typeface will be selected again. - In any cases, when selecting again a Family having a typeface of the same name than the last typeface selectioned by a click, then this typeface is selected anew. - In all cases, when selecting a new family, a new typeface or a new size, the preview mode is reset. - The preview mode can be locked on with a shift click on the Preview button. I think that the behavior of the GNUstep Preview button is more user friendly here. In addition, the current computer should be fast enough to give good response times when browsing the fonts with preview on. - In preview mode, the preview box is editable by the user. Once this box has been edited, it's not replaced by the new font name. - In Edit.app, for example, when the preview mode is not activated, activating a text window
BUG [ 100250 ] highlight menu item sometimes fails
I had a deeper look into the problem behind the bug 100250 and found that it is created by a view that is moved to another window, while the view needs display. In that specific constellation the method [NSView setNeedsDisplayInRect:] does not work correct. As the whole area of the view is already invalid the new window (and the super views) is not marked as needing display. There are multiple ways to resolve this problem and I am not sure which is the best. Currently I would prefer to flag the view when moving it to a new superview first as not to need display and than as needing display. That way the invalid area is first cleared and than everything works as expected. This would require changes to the methods [addSubview:], [replaceSubview:with:] and [addSubview:positioned:relativeTo:]. Another way to do it would be to flag a view as not needing display in the [removeFromSuperview:] and [removeFromSuperviewWithoutNeedingDisplay:] methods. Or to try to handle this case in [setNeedsDisplayInRect:], but this would need a lot of extra checks. There is another smaller problem here in the method [NSWindow orderWindow:relativeTo:]. Here the sending of needs display calls from the runloops to the window is only started when the window does not need display. This seem to be the wrong way round. Could anybody with more insight in this matter propose the correct solution (And perhaps also submit it). I send much more time to find the problem than I expected and now just want to get rid of it. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSPopUpButton*, NSMenu* patch.
Hi Michael, I just had a look at your patch and failed to understand how with the new code you suggest for NSApplication the name of a window could be changed and correctly displayed in the windows menu. Perhaps you just wanted to optimize the case away, when the name didn't actually change? As for the rest of your patch I would like to analyse it a bit more before committing it. It is a rather huge patch and there is some code that looks strange. (E.g. why is the setNeedsDisplayForItemAtIndex method called in the NSMenu implementation of itemChanged and not in that of NSMenuView?) Sorry, but the menus are a very complicated and important aspect of GNUstep and I did spend quite some time last year to sort them out at least half (I gave up on the popup buttons and on moving more code from the menu to the menu view). Cheers Fred Michael Hanni wrote: Hi, Here is a rather large patch that makes some changes to NSMenu* and NSPopUpButton*. Basically it allows one to use images in popupbuttons once again and it removes many redisplays which were causing the menus and popups to be quite painful on slow machines (bonus: the windows menu should display a little better both as a tornoff and as a regular menu.) Finally, it also includes a change to NSTabView which addresses a bug noted on discuss-gnustep. There are still issues, but I believe this patch is some improvement (it makes things nicer on my slow machine. :)) ChangeLog: * Source/NSApplication.m: (-changeWindowsItem:) If the item in question already exists we abort further processing. * Source/NSMenu.m: (-itemChanged:) Mark the menuitemcell that has changed for redisplay (thus allowing us to only redisplay the item changed as opposed to the entire view.) (-sizeToFit) Alot of reformulation to suppress multiple redisplays. (-_popUpButtonCell) Allow access to the popupbuttoncell privately. * Source/NSMenuItemCell.m: Moved drawing of popupbutton icon here. Also, reallow use of NSImages in an NSPopUpButton. (-imageRectForBounds:) Remove popupbutton code. (-drawImageWithFrame:) Dim image if item is not enabled. (-_drawPopUpIconWithFrame:) New method to draw popupbutton icons. (-drawInteriorWithFrame:) Draw popupbutton icon if needed. * Source/NSMenuView.m: (-sizeToFit) Check for popupbutton to remove additional 1 pixel. * Source/NSPopUpButtonCell.m: reformulate drawing. (-drawWithFrame:) Have the menuRepresentation fetch us the NSMenuItemCell for the selectedItem and draw it. (-drawInteriorWithFrame:) Remove all code save for NSDottedRect drawing. * Source/NSTabView.m: (-mouseDown:) new method to fix problems with NSSplitView interaction. (-hitTest:) removed. Cheers! Michael __ Do You Yahoo!? Yahoo! Sports - Coverage of the 2002 Olympic Games http://sports.yahoo.com ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
GNUstep under mingw
I am running GNUstep with mingw and there are a few problems left. First you hae to use the cygwin make (/usr/bin/make) otherwise the common.make file gives an error as it tests the $PATH variable to include the GNUSTEP_SYSTEM_ROOT/Tools directory. For this to work also the environment variable GNUSTEP_TARGET_OS has to be set to mingw32, which is not mentioned in the README.mingw. You should also download a iconv library, gnustep base runs without one, but it will be needed later on. (BTW Why do we run without iconv, but need libxml2?) Even after solving all this there is a problem when compiling the Testing code of base: $ /usr/bin/make Making all for test_tool awake... make[1]: Nothing to be done for `internal-test_tool-all'. Making all for test_tool basic... make[1]: Nothing to be done for `internal-test_tool-all'. Making all for test_tool benchmark... gcc -o shared_obj/ix86/mingw32/gnu-gnu-gnu/benchmark.exe \ shared_obj/ix86/mingw32/gnu-gnu-gnu/benchmark.o\ -L../Source/shared_obj/ix86/mingw32/gnu-gnu-gnu -Lc:userskieferGNUstep/ Libraries/ix86/mingw32/gnu-gnu-gnu -Lc:userskieferGNUstep/Libraries/ix86/mingw32 -Lc:/users/kiefer/GNUstep/cygwin/usr/GNUstep/Local/Libraries/ix86/mingw32/gnu-g nu-gnu -Lc:/users/kiefer/GNUstep/cygwin/usr/GNUstep/Local/Libraries/ix86/mingw32 -Lc:/users/kiefer/GNUstep/cygwin/usr/GNUstep/Network/Libraries/ix86/mingw32/gnu -gnu-gnu -Lc:/users/kiefer/GNUstep/cygwin/usr/GNUstep/Network/Libraries/ix86/min gw32 -Lc:/users/kiefer/GNUstep/cygwin/usr/GNUstep/System/Libraries/ix86/mingw32/ gnu-gnu-gnu -Lc:/users/kiefer/GNUstep/cygwin/usr/GNUstep/System/Libraries/ix86/m ingw32 -lgnustep-base -lobjc -liconv -lcallback -lavcall -lws2_32 -ladvapi32 -lc omctl32 -luser32 -lcomdlg32 -lmpr -lnetapi32 -lm -I. shared_obj/ix86/mingw32/gnu-gnu-gnu/benchmark.o: In function `bench_object': //c/users/kiefer/GNUstep/core/base/Testing/../Headers/Foundation/NSZone.h:178: undefined reference to `__nszone_private_hidden_default_zone' //c/users/kiefer/GNUstep/core/base/Testing/../Headers/Foundation/NSZone.h:178: undefined reference to `__nszone_private_hidden_default_zone' //c/users/kiefer/GNUstep/core/base/Testing/../Headers/Foundation/NSZone.h:178: undefined reference to `__nszone_private_hidden_default_zone' //c/users/kiefer/GNUstep/core/base/Testing/../Headers/Foundation/NSZone.h:178: undefined reference to `__nszone_private_hidden_default_zone' //c/users/kiefer/GNUstep/core/base/Testing/../Headers/Foundation/NSZone.h:178: undefined reference to `__nszone_private_hidden_default_zone' shared_obj/ix86/mingw32/gnu-gnu-gnu/benchmark.o://c/users/kiefer/GNUstep/core/ba se/Testing/../Headers/Foundation/NSZone.h:178: more undefined references to `__nszone_private_hidden_default_zone' follow make[1]: *** [shared_obj/ix86/mingw32/gnu-gnu-gnu/benchmark.exe] Error 1 make: *** [benchmark.all.test-tool.variables] Error 2 This lloks like we need to export more than just the classes from our DLL. Has anybody else faced this problem and how could it be resolved? Cheeers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Slow Image scrolling
HiIan, Ian Jones wrote: I have a problem with scrolling large image attachments. I regularly recieve quite large image files attached to my email, someone recently sent a 270kb .jpg attachment and even on my dual celeron 500 it kept stopping trying to scroll through it and my CPU usage was up to 80%. I have talked to some other people about this in the #GNUstep IRC channel who have experienced the same problem with ImageViewer and Ink.app and various image types. Does anyone have any ideas as to what is causing this and how it could be improved? The problem here is that NSImageView relies on the NSControl method drawRect: when doing a redraw. This basically ignores the given rectangle and redraws the full cell. That way an image embedded into a scroll view will always draw the full contents, even if only part is visible. And to make things worse, the scroll view will also attempt to copy parts of the image over, while you scroll. NSImageView and NSImageCell are just not designed to be but into a scroll view (The same is true for all other control and cell subclasses). What can be done about this? Not much, as long as you are using a NSImageView. But you could write another subclass of NSView, that would implement drawRect: in a more clever way and put that into the scroll view. As long as you dont need a border or image scaling, this should be fairly simple usinge [NSImage compositeToPoint:fromRect:operation:]. I hope this helps Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Bug in opentool
Nicola Pero wrote: I hope that is a first help for windows. I'm dead late with applying your windows patches to gnustep-make / making the makefile rearrangement for windows, but it's the next improvement to gnustep-make. I also think I should likely install gnustep on windows myself to work on that. Only, just the idea of opening windows makes me feel sick. :-@ You don't have to, it should be enough that Richard, Adam and I are suffering that way. But than again, how could you test the makefiles with no MS Windows? BTW your last change in CVS, the removal of the class GSTransparentView once again broke the build of GUI on MS Windows, as this class is listed in libgnustep-gui.def. We should remove all the internal classes from this file, they are not needed there and keep on causing trouble. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Problem loading German settings
Hi Richard, back on my Linux machine I find so problems to run GNUstep with German as the selected language: fred@hugo:/usr/src/gnustep/usr-apps/examples/gui LANG=de_DE fred@hugo:/usr/src/gnustep/usr-apps/examples/gui openapp GSTest/GSTest.app/ 03 30 19:20:27 GSTest[6203] File NSDictionary.m: 458. In [GSDictionary -initWithContentsOfFile:] Contents of file '/usr/GNUstep/System/Libraries/Resources/Languages/German' does not contain a dictionary fred@hugo:/usr/src/gnustep/usr-apps/examples/gui LANG=en_GB fred@hugo:/usr/src/gnustep/usr-apps/examples/gui openapp GSTest/GSTest.app/ fred@hugo:/usr/src/gnustep/usr-apps/examples/gui LANG=fr_FR fred@hugo:/usr/src/gnustep/usr-apps/examples/gui openapp GSTest/GSTest.app/ 03 30 19:21:55 GSTest[6255] File NSDictionary.m: 458. In [GSDictionary -initWithContentsOfFile:] Contents of file '/usr/GNUstep/System/Libraries/Resources/Languages/French' does not contain a dictionary My feeling is that this is caused by some of your latest changes. Now a property list file must either be ASCII or UTF8, while our language file are still ISO Latin 1 encoded. Is there any simple method to convert them? (recode, iconv ?) Or should we use the \U escape sequence here? I am also wondering, why I am the first to have this problem. Did we loose all our European users? ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: New 'back' backend
Hi Nicola, for your fix in the bundle make file you added a comment that we should explain, why we have to link against all libraries on Windows while we don't need this on any other system. The reason is simple, we don't need this on Windows either. What we need there is that we define a pre-processor variable XXX_ISDLL for all the DLLs we include. And this definition is currently connected to the same variable that is used for the libraries to link against. What we should do now is split up this two different uses. And if possible let the later be handled by a general rule for all different forms of projects (There is already a rule for this in rules.make, but somehow it only works for libraries). It was my fault to overlook the harm that could come from uncommenting that line in the bundle make file, but as my knowledge of the GNUmake mechanism is only marginal, I am surely not able to implement the correct solution, which we have been discussing in private mail for almost a month now. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Usage of rint() in gui
Two new files are now using rint() in the gui library (NSMatrix and NSClipView) as this function is not available on all systems (namely not on MS Window) it is not possible to compile gui on such a system. To work around this the configuration checks for this function and sets a flag whether it is found. This information is not used in these two files. So they must be patched just as NSBrowser or NSRulerView. Or as this becomes more common now, we could move the replacement definition of rint() up into the config.h file itself. Any ideas on this solution? Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Backend make fails
Trying to build the new backend back on mingw fails with the message: kiefer@XANTHUS ~/GNUstep/core/back $ /usr/bin/make GNUmakefile.postamble:31: *** target pattern contains no `%'. Stop. This happens independend of the actual backend I am configuring for. Commenting out that rule just moves the error to the next rule. If I comment out all rules in this file the compilation works. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
two bugs while building back on mingw
1. the new backend results in the line GRAPHIC_LIBS=-ltiff -lX11 being written to the files config.make and back.make even when not configured for any X backend. 2. As the new backend works with subproject these must now be able to correctly set set the XXX_ISDLL flags as well. Currently we have this correct for applications, libraries and bundles, but not for subprojects. Before adding a new workaround I would prefer a general solution that would work with all the different project types. Perhaps it would be sufficient to extract that code into a shared file, set one variable, e.g. ALL_USED_LIBS and than include that shared file. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
GUI bug for new backend
In the header file GSDisplayServer.h in gui the new functions GSServerForWindow() and GSCurrentServer() are lacking the APPKIT_DECLARE modifier. That way these functions are not exported correctly for MS Window. Also the class GSDisplayServer itself has to be added to the libgnustep-gui.def file to be exported correctly. There is also a minor problem with the tool gpbs, as this uses signal values that are not defined for mingw. BUt as gpbs in gui never gets compiled this can only be seen when compiling back on MS Windows. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Usage of rint() in gui
Adam Fedor wrote:
Fred Kiefer wrote:
Or as this becomes more common now, we could move the replacement
definition of rint() up into the config.h file itself. Any ideas on
this solution?
Done.
Sorry, perhaps my idea wasnt that good. I now did get a compile error,
because of different difinitions of rint(). This is caused by config.h
not being protrected againet multiple includes and also by math.h being
included after config.h. To work around this I did exetent the
definition of rint in config.h.bot to
#ifndef HAVE_RINT
extern double floor(double a);
static double rint(double a)
{
return (floor(a+0.5));
}
#define HAVE_RINT
#endif
This now works for me, but results still in a lot of compiler warnings
as config.h is included into files where rint() is not used, so it is an
unused variable.
Cheers
Fred
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Strangeness in NSWindow
Adam Fedor wrote: Fred Kiefer wrote: Then there is this NSWindowDepth stuff, according to NSGraphics this are rather complicated values that describe the availabe colours of a window or screen. But in NSWindow 8 is returned as a NSWindowDepth and the method [windowdepth] on XGServerWindow also returns rather just a bit size. So what is the use of all this and what would be the correct beahviour. Looking at this got me to notice that the current GSDisplayServer and XGServer can't handle multiple screens properly. X-Windows can handle multiple screens from a single display, so I could change things around so that GSDisplayServer does this also, but I'm wondering about Windows. Do you know at all if Windows can handle multiple screens and if it would be easier to do it with multiple GSDisplayServers for each screen or on GSDisplayServer for all screens? I don't quite see the connection of this two issues, but to answer your question: As far as I can tell, and I never have see or used a multiple monitor system with MS Windows, it should be implemented with one GSDisplayServer not multiple. And before we can add any support for multiple screens (or monitors as MS Windows calls this) to the GNUstep backend, we should support it in the gui. Currently NSWindow does not even care which screen it is using. We should think of a concept for the window screen interaction first, before putting support for this in our backends. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Cursor blinks in background
After adding a NSLog() statement to the _blink method of NSTextView I noticed that this method get called, while the window of the text view is no longer active. This can be seen in the GSTest.app when switching to another test window after editing text in the NSForm test. In this case the blinking wont be displayed and is just a waste of computer time. The reason for this blinking seems to be that the class NSTextView does not implement resignKeyWindow. This method gets called on the first responder, when the window looses key window status. But I am not sure, what an implementation of this method should do. Just switch off the blinking cursor? Or more? Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
NSSavePanel complains about .hidden
Richard latest changes to NSData caused that the NSSavePanel now complains, if it cannot find a .hidden file in a directory: 2002-10-05 13:21:29.687 Ink[1323] File NSData.m: 219. In readContentsOfFile Open (/.hidden) attempt failed - No such file or directory The questions is of course, if we should first check in NSSavePanel, if the file is there and only then try to read it or if we should switch off this log message. I would opt for the first solution, as this would make things a lot faster, if the the file does not exist. For the NSData code it looks a bit strange the the zone determination is scattered all through function readContentsOfFile(), why not find out when the function gets called (this is done in one of the places, but not in the other). BTW, this error message is shown eight times, when a NSSavePanel is opened, although only two columns are shown. I will inspect into this to find out if there are unneeded operations going on. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: GSSimpleLayoutManger.patch (mouse selection at EOL)
Hi Nicola, could you please give a bit more details for the following sentence: Nicola Pero wrote: I'd say that standard non-rich editing is very usable. Why do you restrict this statement to non-rich editing. As far as I know, editing for RFT and non-rich text is implemented with exactly the same code, which is either working or not working. So there should be no visible differences for those cases. And remember that non-rich text might still have any possible attributes, it is just that the whole text will have the same attributes. What I want to say is, that we are doing a lot better than you think. Text displaying and editing is still slow (so is most of the rest of GNUstep gui), but it is usable and improving. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSSavePanel complains about .hidden
Fred Kiefer wrote: BTW, this error message is shown eight times, when a NSSavePanel is opened, although only two columns are shown. I will inspect into this to find out if there are unneeded operations going on. After a bit of investigation I did find out that this behaviour is there by specification. The NSDocumentController first initialises the NSOpenPanel by setting the directory and than starts it without giving a directory. This leads to the NSBrowser being set to the same path twice and thereby reading all the directories in the path twice. As it is hard to determine if we get the same path again in NSBrowser, I would recommend that we change the NSDocumentController to start up the NSOpenPanel with the directory directly, without first setting this. This is not exactly what the specification says, so I would like to ask if somebody could test this on MacOSX and even if they do it different, I would vote for this change. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSSavePanel complains about .hidden
Adam Fedor wrote: Fred Kiefer wrote: Fred Kiefer wrote: BTW, this error message is shown eight times, when a NSSavePanel is opened, although only two columns are shown. I will inspect into this to find out if there are unneeded operations going on. After a bit of investigation I did find out that this behaviour is there by specification. The NSDocumentController first initialises the NSOpenPanel by setting the directory and than starts it without giving a directory. This leads to the NSBrowser being set to the same path twice and thereby reading all the directories in the path twice. As it is hard to determine if we get the same path again in NSBrowser, I would recommend that we change the NSDocumentController to start up the NSOpenPanel with the directory directly, without first setting this. This is not exactly what the specification says, so I would like to ask if somebody could test this on MacOSX and even if they do it different, I would vote for this change. I didn't test this on MacOSX, but it sounds fine to me. Although I don't see where either behavior is described in the documentation The old behaviour is described in detail in the NSDocumentController interface. See, fileNamesFromRunningOpenPanel. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Fix, NSFont, XGFont (was RTFConsumer)
Most of this patch looks fine for me. What is missing is the special handling now needed for the getNSFont() function. Here we should make sure, that we always return a usefull font. As the only font we can be sure about is the user font in the default size we should return this, if any font is missing here. Not returning any font here will screw up the system as we always expect the font attribute to be set to usable value. Fred Georg Fleischmann wrote: Looks like [NSFont -initWithName:matrix:] is our own extension, and likely it should return nil if the font can't be found (it now returns the default font if I understand correctly). In that case I suppose we need to change GSFontInfo to return nil (rather than a font info for a default font) if the font is not found. NSFont -initWithName:matrix: will then check the created font info, and if it's nil, it will destroy self and return (nil) as well. Now, with the changes NSFontManager's -convertFont methods work as they should. All seems to work fine - I got no crash :-) My suggested RTFConsumer changes work much better, too. I will send the RTFConsumer patch in a separate mail with some additional comments. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSBezierPath setLineDash
I applied a patch that should resolve this. The more general problem of path handling is still to be discussed. Stefan Urbanek wrote: Whe I set NSBezierPath setLineDash:count:phase: to one path then all paths created after that one will have same line dash style. I think it should be local to the path, or is it global? This value is reset after each NSView drawRect:. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Memory leak of GSAttrInfo and GSCString suspicion
Stefan Urbanek wrote: When usnig GNUmail it wil grow to enormous size (now it has ~136MB) and I have to restart it time to time. When I browse my mail in the mailbox (with mouse or with keys) the amount of GSAttrInfo classes will grow. Another thing: when I type in NSTextView (for example when composing a mail), with each keystroke there is a leakage of two GSCStrings. The later problem was caused by the XIMInputServer and should be fixed now. For the first problem I don't have any idea, just one remark: This seems to come from internal NSAttributedStrings as the text storage used for text views use TextInfo instead of GSAttrInfo. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Segemantation fault while printing
When printing two times form within the same GNUstep applciation I get a segmentaion fault. This is caused by a rather complex interplay between the NSFont management and the SetLocal calls for printing. To explain it I will have to list the involved steps: 1. My computer has a german setup, so the local for numericals uses a , to start with. 2. When printing the code switches to . as the numerical separator. 3. When a NSFont is used it looks up in the cache if a similar font already exists, here the matrix is printed into the lookup string so the . will be used here. And the font will be created as a new one and stored under this key. 4. At the end of printing, we switch back to , as the numerical separator. 5. When the NSFont object gets released by the autorelease pool, a key with , is used and no object will be freed (or even a wrong one) from the cache. 6. Next time the same font gets printed there will be still an entry in the cache, but no font that corresponds to it. To work around the current problem it would be sufficient to bring the SetLocal calls and autorelease pool code closer together. But this wont resolve the general case, where an NSFont object survives longer. We could also use a well defined local, for the creation of key for fonts. Or we could store the key with the font itself, so that always the same key will be used for caching and release. All of this solutions have their drawbacks so it is hard to decide which one should be used. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSMenu patch version 2.
Hi Wim, menus kep on appearing in the lower left corner for me as well. It would be great if you could resolve this problem quickly. What I did not understadnd about your changes is the introduction of the NSMenuView protocol. I could not find this in my MacOSX documentation and I also see no additional value in it. The code in the (deprecated) method setMenuRepresentation: checks if the handed in view is a subclass of NSMenuView, so anything else never could be used. Also most of the interaction between the MenuView and the Menu is generic and will be used by all menu views, whichever way they will draw. I would say that allowing for subclasses is sufficient here. And perhaps we could even move some of the declaration of the interface between the menu and its view into a private file. Cheers Fred Willem Rein Oudshoorn wrote: Michael Hanni [EMAIL PROTECTED] writes: I tried this patch and it does some nice stuff, though my biggest pet peeve with the menus still exists. That is, if you click on a menu item and drag up and down the menu after a few passes you start getting menu windows showing up at (0,0). Are you seeing this as well? I looked into this a little this afternoon, but I didn't see anything that jumped out at me. Yes, I have seen this as well. I think this bug is related to #101876 - Menus do not dissappear. Which is not fixed. I have strong suspicion that the bug is not in the NSMenu code, but that the frequently mapping/unmapping windows bring to light a bug in the x11 part of back. Also, running GNUstep applications insided Xnest and WindowMaker with sloppy focuse will make it much easier to reproduce this behaviour. This is also a reason I suspect the x11 part of back. I was planning to look into it. But did not want to have this bug delay the rest of the patch. But if you want to hunt this one down, go ahead :-) ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSMenuView and popups (was: Re: [PATCH] Menus in lowerleftcorner)
Hi Wim, Willem Rein Oudshoorn wrote: Since the NSMenuViewWindowTitleBar-thingie is created in NSMenuView's initWithFrame, and the NSMenu creating the NSMenuView doesn't know its owned by a popup until right after its init, we are slightly screwed. I suppose we could catch this on the first sizeToFit in NSMenuView -- like we catch the left offset? Yes, that would be an option. Although I would prefer to split the NSMenuView class into two: GSPopupMenuView and GSMenuView. But your suggestion is easier and Fred Kiefer might object to the split. looks as if there was some misunderstanding. I am strongly in favour of such a change. If there is sufficent difference between these cases split them up! What I don't like is, that you came up with a new protocoll for NSMenuView, which is not there in MacOSX nor Openstep and which is also not required for this change, as both classes will have the superclass NSMenuView. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [semi-PATCH] menu title bar sizing menu close button
Benhur Stein wrote: Citando Fred Kiefer [EMAIL PROTECTED]: There are also a lot of problems with setShowsFirstResponder:. I think from the documentation that this only indicates that the dotted line will be drawn, when the cells also becomes first responder. But our current code treats this as unconditional, the value itself determines if the dots get drawn. This value is screwed up by the current code in NSButton, whenever the button becomes first responder. And even worse in NSMatrix. I would like to change this, so that the redraw code of NSCell takes over the processing of showsFirstResponder (drawing the dotted frame whenever the control is the first responder and the cell is the selected cell of the responder) and just selecting the cell everywhere else. Is this solution fine for everybody? Well, I don't agree with this change. It would break object encapsulation. IMHO, it should be the control that makes the decision of which cell should show first responder status, not the cell. For example, with NSMatrix, it is keyCell, not selectedCell (the code in NSMatrix is wrong) that should be dotted. A different control could have another way to choose its first responder cell. This is an interesting point you are making. I did not know, that for NSMatrix the key cell should be the first responder, but than yes, when you think about it it is obvious. My underlying question is what the showsFirstResponder method is used for. Will it be just be called internally for the cell of the first responder to switch on the dotted frame, as it is now used in the GNUstep code or should it, as the documentation seems to imply be used to switch on and off the behaviour of showing the dotted line, when becoming first responder? Perhaps somebody with a MacOSX could check if the way I do understand the documentation is correct. If not than only the two new methods on NSControl (becomeFirstResponder and resignFirstResponder) and thedrawInteriorWithFrame:inView: method on NSButtonCell and NSPopupButtonCell must be adopted. Otherwise all the drawing of cells will need reviewing. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [NSImage imagedNamed:] and application startup tuning
Michael Hanni wrote: [NSImage imageNamed:] provides a very easy way to grab images. You can simply provide a name, minus even an extension, and NSImage will find your image. However, this can be more intensive than required when you already know your image's extension. For example, when you strace a gnustep app right now there are hundreds of attempts to find images -- this method loops through every possible directory with every possible image extension until it finds the right one -- used in the AppKit. The time involved is not huge, but it is entirely unnecessary I think. With the attached patch I've added a '.tiff' extention to most images loaded in the AppKit. Not sure if this is the best way to get a better speed at startup. There is even one small drawback, we may on some system have to use the extension of '.tif' if we ever port GNUstep to such a dump platform. So I had to think up something better, and here it is: Loading the tiff images is so slow because on systems where WRaster is available GNUstep first tries all the formats provided by WRaster before looking for TIFF files. Switching this order around, i.e. looking first for '.tiff', should result in the same speedup. Please test this and give me your comments. If this is not enough we should of course use your patch. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Memory leak in GNUstep
There seems to be a new memory leak in GNUstep that can be most easily seen in GSTest.app. 1) Start up GSTest.app. 2) Select the Info Panel from the menu. 3) Start the Memory Panel by clicking the image. 4) Hit Update a few times. You will notice that the number of GSUnicodeInlineString keeps on increasing by 132. This is 8 times the 16 lines in the table plus 4 (perhaps the header?). My first thought was that this may come from the Memory Panel itself, but this code looks sound to me. The next suspect was the table view, but further tests did bring up a similar leak for other drawing operations. So now I am thinking about the new string drawing code as a possible source of the leak. But there is also a striking similarity in the number of leaked GSUnicodeInlineStrings and the total number of GSNotifications used by the application. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] make NSProgressIndicator lovely.
Michael Hanni wrote: The attached patch makes NSProgressIndicator a little more appealing -- I think. Personally, I would like to see NSProgressIndicatior like in attach (NeXT one). I can create it after fixing/testing/cleanup NSMenu* and friends. The original one is okay, though I kinda feel it doesn't fit in with the other controls. I mean, it isn't bad to have something different, but the gtk+ one looks nice with the overall OpenStep look I think. Plus, implementing the indeterminate look would be pretty easy: create a beveled box 1/10 the size of the control and simply move it back and forth within the control. I can implement this easily if someone would like that. Either way is fine, I'm just too lazy to implement anything more complex. :-) What about implementing all thse different looks at once, by having code for different NSInterfaceStyles? That way all off you would be happy and the rest of us will have a choice. I think this is currently only used in NSMenuView (and even there not exactly correct), though it should be working. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Tear off menus broken
One of the recent patches for NSMenu and family must have broken the functionality of tear off menus. It is not that I like them that much, but we should not loose them that easily. How to test this yourself. 1) Open Ink.app 2) Select one sub menu and tear it off. 3) Select New Document form the file menu. 4) As soon as the new window apears the tear off menu will vanish. 5) Quit Ink and restart it. 6) The tear off menu will shortly show on the screen. The same happens each time the applications is reactivated. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSWorkspace launchedApplications method
Hi Adam, Adam Fedor wrote: Matt Rice wrote: here is a patch i figure we should probably discuss, it implements the launchedApplications method (Replying kind of late...) It's a bummer there has to be a deamon just for handling this. Is there anyway to combine it with something else? Maybe just using gdnc to spread the information around? This could be better as at least with gdnc we've thought about all the problems of where information should be sent (e.g. are applications running on the server, the client, the display?...) Matt and I did discuss this as a possible solution some time ago but reached the conclusion that this functionality does not belong into base. A new idea that came to my mind since than, is to let the normal mechanism of GNUstep do the work. That is an application that wants a list of all running GNUstep application asks GDOMAP for it and is than able to use each connection to an application to get its application information. For the later step we only need to enable the GSServicesManager to get the activeApplication information from its local NSWorkspace and export this as a method. We could also implement the hide other applications call in a similar way. I am surely not able to implement this, but for Richard it shouldn't be to hard. Of course only if this is really a sensible solution. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
File URLs in NSURL
While playing around with thumbnails (thanks to Charles Philip Chan for the link!) I came up with the following code: file = @~/GNUstep/Images/TextSystem1.png; absolute = [file stringByStandardizingPath]; NSLog(@file: %@, absolute: %@, file, absolute); absolute = [[NSURL fileURLWithPath: absolute] relativeString]; digest = absolute dataUsingEncoding: NSASCIIStringEncoding] md5Digest] hexadecimalRepresentation] lowercaseString]; NSLog(@file: %@, absolute: %@, digest %@, file, absolute, digest); file = [[[@~ stringByAppendingPathComponent: @.thumbnails] stringByAppendingPathComponent: @normal] stringByAppendingPathComponent: [digest stringByAppendingPathExtension: @png]]; image = [[NSImage alloc] initByReferencingFile: file]; But this does not give the correct result. According to the specification the URL file name absolute should be something like file:///home/fred/GNUstep/Images/TextSystem1.png but in GNUStep I do get: file:/home/fred/GNUstep/Images/TextSystem1.png When using absoluteString instead of relativeString I get: file://localhost/home/fred/GNUstep/Images/TextSystem1.png Again this will result in a different MD5 digest than the one expected by the thumbnail standard, so we wont find the correct file. The question now is, if there is another method to get the required string or if this is a bug in GNUstep, which we should correct. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Text drawing bug - gaps after 16th character in scaled view
Alexander Malmberg wrote: Yes, there must be a mismatch between the metrics reported by -xlib to -gui and the actual width of the glyphs when drawn. I'm not very familiar with -xlib's font code, but I had a quick look at it and fixed one fairly obvious bug that would cause incorrect metrics to be reported for non-latin1 fonts on big-endian systems. Does this apply to your system? If so, can you check if it works with latest cvs of -back? The actual fix solves a problem on systems where unsigned int == unsigned short does not hold. I think that this is indendent of the endianess of the system (You rather expect it to fail on a 16 bit or 64 bit machine). Still it was a bug and it is great that you did resolve it. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib
Hi Kazu, this is a nice patch you came up with. This should fill the gap between people only able to use basic X fonts and the ones with a XFT implementation (which also offers UTF8 support). As far as I know font sets are not restricted to XFree86 so this may be of help for more people out there using X Window systems without XFT. As you by now will have noticed, the xlib backend comes along with its own XFT font class and I think that the font set support should be packaged up in a similar way. That is, a separate class in its own file that gets set as the default font class in [XGContext initializeBackend]. This allows even for a different way to list all the available font sets, if this is needed. And we don't need to fiddle with XGFont, ending up with a cleaner and smaller implementation. This will on the other hand also show some of the limitations of the font sets. There are no character metric informations available for font sets, which was the reason I decided to give up on my own implementation based of font handling on top of them. Ok, I have to admitt, that this decission was European centric. As for the comment in the dealloc method I am a bit worried. If this is true our current font handling is totally wrong. I cannot belive that we give up the reference to a font before we draw any text with it. Let us both try to dig deeper into this problem. It may just be a limitation of your current implementation. As for your private UTF8 conversion function, I am not sure if this is needed or if GSFromUnicode() would do. This is restricted to only a part of the UTF range, but than again it is that part you may store in a NSString. Cheers Fred Kazunobu Kuriyama wrote: Hi, all. Attached are the patches to make the xlib backend fully supports unicode. Accordingly, if the patches are applied, the backend should handle all characters represented with NSGlyph. If the X Window System in use is already set up properly for your language environment (i.e., locale, fonts, an input method), GNUstep with back-xlib should work in cooperation with your native language only by setting the GNUSTEP_STRING_ENCODING to an appropriate value. For example, you can browse and edit text files written in your native language with GNUstep applications. (NOTE: This may not be true if a language in use is one of those in which text is drawn from right to left, such as Arabic or Hebrew. ) The underlying window system must be XFree86 4.0.2 or higher to enable the new function provided by the patches. Moreover, to enable it, you need to pass -DUSE_MULITIBYTE to a compiler when you build -back. When this macro is not defined, the implementation reverts to the original. To ease this task, I prepared the patch for configure.ac. To use this, go to the top directory of the source tree of -back, and do $ cp configure.ac configurea.ac.orig $ patch configure.ac.patch $ autoheader $ autoconf Then you will find the new option --enable-multibyte in the newly generated configure script. You can use this option to pass the above macro to a compiler automatically. The new configure script also checks if the underlying window system is XFree86 4.0.2 or higher if --enable-multibyte is specified. The patches were made against the corresponding files stored in the CVS repository of July 10. Any feedback is welcome. - KK ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib (2)
Hi Kazu, this patch looks great! There a only a few things I would like to change: - As XGFontSetEnumerator is currently not implemented I would remove all reverences to it. - [initWithFontName:matrix:screenFont:] may lead to memory leaks as RELEASE(self) is missing for all the error cases. - char_struct_for_glyph() could return a boolean value if the chracter was found. Thereby making all the calls, especially [glyphIsEncoded:] a lot simple and removing the need of memset() inside this function. - My man pages warn about the use of the funtion strtok(). Why not pass into load_font_set() the NSString and use [componentsSeparatedByString:] (This method is also use in the font_chacher.m)? In this part of the code I am also a bit unsure about the pieces of the XLFD that you use and the ones you discard. Could you explain, document what you do and why? (For example, I would use the family and discard the foundry, you do the opposit) - What we could also think of is to make the switch between your and the standard implementation of font handling one at runtime. Allowing for a simpler transistion without recompiling the backend each time. See the user default for the use of the XFT fonts. Cheers Fred Kazunobu Kuriyama wrote: Based on Fred Kiefer's suggestion, I rewrote the patches I previously sent to bug-gnustep with the email 'Full unicode support for back-xlib'. A few bug fixes have also been done. While the functionality the new patches offer remains the same as that of the previous ones, both the organization and the performance are improved. The main differences are: (1) The part that was included in XGSFont.m.patch becomes two new files, XGFontSetFontInfo.h and XGFontSetFontInfo.m. (2) The new module resulting from these files is used in XGContext.m. As a result, the new module can be handled similarly to those of XGFont.m and GSXftFontInfo.m. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Full unicode support for back-xlib (2)
Hi Kazu, we now have reached a disagreement and need some more views on the remaining problems. Perhaps Nicola, Adam, Wim or Alex could join in and state their views on the use font sets. I am away for a few days anyway. Cheers Fred Kazunobu Kuriyama wrote: Fred Kiefer wrote: snip It is even worse, the man page says: BUGS Never use these functions. If you do, note that: These functions modify their first argument. These functions cannot be used on constant strings. The identity of the delimiting character is lost. The strtok() function uses a static buffer while parsing, so it's not thread safe. Use strtok_r() if this matters to you. I don't think that this could cause any harm in your case, still I would avoid it. Taking all the points above into consideration, I did it. Hopefully, harmless. Though the current code might look a bad programming style, I think it is the right place to compromise. I was also worried about the special treatment you do for missing add styles, as I can tell from the fonts installed on my machine almost any part of a XLFD may be missing, this should not cause any special treatment. I simply need to distinguish the token '--' from the token '-'. It could be written in a more generalized way, but it would results in over-engineering. You can't use the return value of XGFontName() directly to load multiple fonts with XCreateFontSet() because XGFontName() is biased in favor of European fonts (see below). The code which looks special to you absorbs this GNUstep's specialization. As for the latter question: People can't expect every font on the earth has the family property called 'Helvetica', 'Courier' or something else which is taken for granted in Latin characters, while they can find fonts with the foundry property such as 'Adobe' and 'fixed'.. The current implementation reflects this reality. (Because I thought this was a common knowledge, I didn't document it in detail. This gives another example that people always think their own ways as 'the' standard, doesn't this?) Are you saying that for Asian fonts there is no such thing as a font family? Or do they just have different names not Helvetica, which is what I would expect. I didn't say Asian fonts have no font family. When I checked the state of the internal variables of GNUstep related to fonts, I found that it exclusively uses Helvetica, Courier or something like that. You'll never find Japanese Helvetica, Chinese Courier, Korean Times, Thai Utopia, ... (If I remember correctly, Alexander Malmberg once told us in discuss-gnustep that he considered to make the family specification user-configurable.) We seem to have a real problem here. On my machine I have about 10 different fonts from Adobe installed (of course each with dozens of styles and sizes). They have a totally different appearance and I never would want to mix them when displaying a string. Whereas I would not mind to mix Helvetica coming from different sources. Your current implementation of building up font sets would be rather unusable for any European language user (probably even for US Americans, but you never can tell), as this would merge fonts that don't belong together. Don't worry. The X server tries loading two or more fonts only if it needs to do so. This is done based on the locale in use. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSWindowController
Andrew Ruder wrote:
Quick question:
144 - (void) setDocument: (NSDocument *)document
145 {
146 // FIXME - this is RETAINed and never RELEASEd ...
147 ASSIGN (_document, document);
148 [self synchronizeWindowTitleWithDocumentName];
in NSWindowController.m
Is there some reason the RELEASE of _document can't just
be put in the dealloc method or is it more involved than that?
(I'm not seeing any reason why not right away here...)
Your solution looks fine for me.
Actually for many window controlers the document gets freed by a cal to
[_windowWillClose:], but only if the window returns YEAS from
isReleasedWhenClosed.
Fred
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Making GUI fails
Richard Frith-Macdonald wrote: On Wednesday, August 6, 2003, at 07:09 AM, Richard Frith-Macdonald wrote: Removing the stamp file therefore fixes the problem ... since make can no longer read it for dependency information. distclean ought to remove the stamp file for you ... but perhaps it isn't doing it properly. Or perhaps the file was created by root and you can't remove it? Another thought ... since the filesystem layout change, the documentation is built in three parts, and there therefore three stamp files (in the Gui, GuiAdditions, and GuiUser subdirectories). Perhaps, when you removed the stamp file, you removed the wrong one? I think the one with the old dependency info would have been in the Gui subdirectory. The only stamp file I have is the one in gui/Source/Gui and that was the one I did remove manually. So neither make distclean nor manuall removal work for my and I do all this testing as root. No idea, why this works for you. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [Fwd: Bug#204645: gnustep-back: font_cacher useobsolete /etc/X11/Xftconfig]
Hi, I don't quite understand what this bug is all about. Lets assume that you are talking about the xlib backend, the only one that uses font_cacher: First you should understand that xlib uses different mechnisms to get informations about the installed fonts on the machine it is runnig on. One of this mechnisms is the tool font_cacher which asks X for all the installed fonts. This uses the standard X mechnism to find fonts, if this results in invalid fonts your system setup is wrong and must be fixed. Nothing in GNUstep could prevent this problem. When the Xft fonts are used and the fontconfig is installed another mechanism gets used to find the existing files (see file GSXFTFontInfo.m). Again standard calls are used here. Could you please describe in more detail which version of GNUstep back you are using and what problem you are facing? Another question would be why the libart backend wont work for you, but this is outside the scope of this thread. Cheers Fred Eric Heintzmann wrote: -Forwarded Message- From: Alban Browaeys [EMAIL PROTECTED] To: Debian Bug Tracking System [EMAIL PROTECTED] Subject: Bug#204645: gnustep-back: font_cacher use obsolete /etc/X11/Xftconfig Date: 09 Aug 2003 01:14:56 +0200 Package: gnustep-back Version: 0.8.8-1 Severity: important Tags: upstream As of X 4.2 and Xft2+fontconfig /etc/X11/XftConfig config file is deprecated : debian fails to noticed this and the file is still there ... though no more updated nor used by fontconfig complient apps . This is not a critical problem on my old debian which have enough fonts descriptions in this file .. i managed to move a few windows stations to debian and them have no access to fonts as gnustep-back does not support libart. I do know the menu quite well, though i admit that s quite boring .X PS: feel free to redirect me to the code , i love objective-C though as a beginner those big libs are still maze to my mind Cheers Alban -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux argos 2.6.0-test1 #14 Sat Jul 26 13:20:31 CEST 2003 i686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR Versions of packages gnustep-back depends on: ii gnustep-back 0.8.8-1The GNUstep GUI Backend ii gnustep-base1 1.7.2-1GNUstep Base library package ii gnustep-gui0 0.8.8-3The GNUstep Gui Library ii libc6 2.3.1-17 GNU C Library: Shared libraries an ii libfreetype6 2.1.4-4FreeType 2 font engine, shared lib ii libobjc1 1:3.3.1-1 Runtime library for GNU Objective- ii libwraster2 0.80.1-7 Shared libraries of Window Maker r ii xlibmesa4-gl [libgl1] 4.3.0-0ds4 Mesa 3D graphics library [XFree86] ii xlibs 4.3.0-0ds4 X Window System client libraries ii zlib1g1:1.1.4-14 compression library - runtime -- no debconf information ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Lifting size limitation on X-to-GS copy paste (was Re: [bug#4658] Broken gpbs when doing pb operations between GS and X)
Hi Kazu, your proposed change overlapps with the changes I did do yesterday to get copy and paste to GNUstep working with my Emacs (21.2.1) again. So your patch needs a bit of rewritting to work in this changed environment (and not to break my Emacs again). I would also suggest not to read bigger and bigger junks of data, but to append each read junk to an NSMutableData object and read the next junk while supplying an offset. I wont have time for this changes today, so you either have to do them yourself or wait for another week. BTW. the long wainting on conversion failers has laos be removed through my patch (this was not part of the original plan, but it did anoy me as well). For the ignorance of the existing selection I have a strong feeling that this is caused by the method [XPbOwner initialize] not being called when gpbs is started. This could be changed by using different code in [PasteboardServer init]. Cheers Fred Kazunobu Kuriyama wrote: Hi, Attached is the patch fixing the bug that is pointed out by part of the bug report #4658: 2. It is not possible to copy from X and paste in GNUstep strings longer than 1024 characters. The patch is slightly better in memory management (preventing possible memory leak resulting from an error) than the one I sent a few hours ago. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Making GUI fails
Yes, this did solve the problem. Thank you Fred Richard Frith-Macdonald wrote: On Wednesday, August 6, 2003, at 10:42 PM, Fred Kiefer wrote: Richard Frith-Macdonald wrote: On Wednesday, August 6, 2003, at 07:09 AM, Richard Frith-Macdonald wrote: Removing the stamp file therefore fixes the problem ... since make can no longer read it for dependency information. distclean ought to remove the stamp file for you ... but perhaps it isn't doing it properly. Or perhaps the file was created by root and you can't remove it? Another thought ... since the filesystem layout change, the documentation is built in three parts, and there therefore three stamp files (in the Gui, GuiAdditions, and GuiUser subdirectories). Perhaps, when you removed the stamp file, you removed the wrong one? I think the one with the old dependency info would have been in the Gui subdirectory. The only stamp file I have is the one in gui/Source/Gui and that was the one I did remove manually. So neither make distclean nor manuall removal work for my and I do all this testing as root. No idea, why this works for you. I *think* I have tracked this down ... The stamp file is regenerated taking information from the .igsdoc file. There was a bug in the autogsdoc make file which caused the stamp file to be regenerated when doing a 'make clean' I think the 'make clean' is now fixed in CVS ... so you could try that. Alternatively, try deleting Gui.igsdoc as well as stamp ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [bug #4658] Broken gpbs when doing pb operations between GS andX
Stefan Urbanek wrote: On 2003-08-10 19:24:12 +0200 Fred Kiefer [EMAIL PROTECTED] wrote: would you mind to retest with the GNUstep CVS from yesterday. Right about the time when you were complaining about this problem I already did try to fix it. If it still doesn't work keep on complaining so that somebody has another go on it. thank you. with recent gnustep it seems to partially work (with that default set to YES). only thing that does not work is copy and paste non-latin1 (like latin2) text from GS to X and back. From GS to X nothing happens (no paste), from X to GS latin1 characters are used. Ok, lets compare our tests: Basic copy and paste of Latin 1 seems to work for both of us between the applications that support it. For some old applications only middle mouse paste works, as they only use Clipboard. Setting GSOldClipboard to Yes should return the old functionality here, breaking middle mouse operation. BTW I never did get any reply on this suggestion from Kazu, does this mean it works for him as well? It is so easy to give negative feedback, but people tend to forget about the positive one. Copying of general unicode seems to work for me from OpenOffice to Ink. But my GNUstep fonts are not able to display the copied characters correctly. So looking at the Ink document I get the impression that the characters have been changed. Saving the text in an RTF file reveals that everything is all right. Copying this formatted text back from Ink to OpenOffice works as well and gives the expected results in OpenOffice. All of this tested with GSOldClipboard as No and in an KDE 3.1 envrionment, which may of course lead to wrong results, as KDE has its own pasteboard background process. I will retest with Gnome and WindowMaker next. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [bug #4658] Broken gpbs when doing pb operations between GS andX
Hi Stefan, would you mind to retest with the GNUstep CVS from yesterday. Right about the time when you were complaining about this problem I already did try to fix it. If it still doesn't work keep on complaining so that somebody has another go on it. You may need to switch on GSOldClipboard, a new user default setting, if the applications you are working with, don't stick to newer standards. Cheers Fred Stefan Urbanek wrote: On 2003-08-08 17:22:05 +0200 Kazunobu Kuriyama [EMAIL PROTECTED] wrote: O.K. Because I'm not sure why gpbs doesn't work for you, could you please give us more detailed information on the bug and the environment you use so that we can reproduce the bug? ok, so: 1. delete /usr/GNUstep/System 2. fresh CVS checkout, as of 8.8.2003 23:00 CET 3. make install make, base, gui, back (without any patches) 4. ldconfig 5. launch GNUmail and some xapp (nedit or ooffice or whatever) 6. select text in GNUmail, copy it 7. x-paste in nedit - does not work 8. open some file in nedit and select all 9. paste in GNUstep app - previously copyied text in GNUstep is pasted (should be X selection) 10. select something short in GNUstep and paste it in GNUstep -works 11. select something short in X and paste it in GNUstep - GNUstep app freezes for several seconds (not because of gpbs crash, but because of that failed operation) That's all i can say so far. Described behaviour was experienced now. Stefan ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Making GUI fails
Gregory John Casamento wrote: You need to delete the stamp file. I had this issue. This did not help, neither did the make distclean, as I was already using this. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [bug #4658] Broken gpbs when doing pb operations between GS andX
Hi Peter, Hi Stefan, would you two mind to retest large cutpaste again? I did fix this today. There is still a lot more that should be done in xpbs.m, but for the moment I hope we have now reached a rather stable version. So if this works it will be the last change until the next release. Fred Pete French wrote: Large cut and pastes still do nothing - e.g. cut the whole of the UTF8 sample page at - http://www.columbia.edu/kermit/utf8.html and try and paste it into a GNUstep app does not work, though cutting and pasting chunks of it does. This is the standarsd page I use for testing cut and paste BTW. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [bug #4824] configuring ffcall with Apple runtime
Hi Adam, this bug is already set as closed. This may explain, why you are not allowed to change the status. If it is still open, you may have to open a new bug report. On the other hand I was at least able to change the severity to 4. Cheers Fred [EMAIL PROTECTED] wrote: === BUG #4824: LATEST MODIFICATIONS == http://savannah.gnu.org/bugs/?func=detailbugbug_id=4824group_id=99 Changes by: Adam Fedor [EMAIL PROTECTED] Date: Tue 08/19/2003 at 22:06 (US/Mountain) -- Additional Follow-up Comments For some odd reason I can't change the status of this bug report. Can anyone else? === BUG #4824: FULL BUG SNAPSHOT === Submitted by: ayers Project: GNUstep Submitted on: Mon 08/18/2003 at 02:32 Category: Base/FoundationSeverity: 3 Bug Group: Bug Resolution: None Assigned to: fedor Status: Open Summary: configuring ffcall with Apple runtime Original Submission: It's been reported that the configure script for base fails on OS X with: checking ffi.h usability... no checking ffi.h presence... no checking for ffi.h... no checking for forwarding callback in runtime... no checking callback.h usability... yes checking callback.h presence... yes checking for callback.h... yes checking FFI library usage... none GNUstep requires the ffcall library to do invocations and DO. Make sure this library is installed (see installation instructions). Otherwise DO will not be compatible with other systems, and you will not be able to use gnustep-gui. ... The intersting line is: checking for forwarding callback in runtime... no which is a GNU Runtime specific test that probably sets enabled_ffcall to 'no' with Apple's runtime.. This seems correct as we probably don't want to configure for ffcall for Apple's runtime, as there isn't a hook we can use. Yet this seems to lead to neither ffi nor ffcall being configured and due to: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/configure.ac.diff?r1=1.13r2=1.14diff_format=hsortby=date we fail the configure (probably also for apple-apple-apple, ie. -baseadd on OS X, where we don't need ffcall as we use Apple's DO/AppKit). Follow-up Comments *** --- Date: Tue 08/19/2003 at 22:06 By: fedor For some odd reason I can't change the status of this bug report. Can anyone else? --- Date: Mon 08/18/2003 at 02:45 By: ayers A work around for the common apple-apple-apple case could be to: ./configure --disable-do CC list is empty No files currently attached For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailbugbug_id=4824group_id=99 ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [bug #4658] Broken gpbs when doing pb operations between GS andX
Fred Kiefer wrote: I did my orignal copying from the UTF8 page with konqueror, which does not have this problem, doing it with Mozilla showed that we still need to support more of the X selection interface. The error I do get here is a bit clearer than the one you list: Unsupported data type 'INCR' from X selection. And INCR is a rather complex X selection transfer mode, which really has not been implemented up to now (Checkout section 2.7.2 of the ICCCM standard). I may look into this later on, but any help here is really appreciated. Ok, as nobody did step up I tried it myself and lets all have a look at the results. First the good news: GNUstep now supports the INCR transfer for the X selection (and a lot more smaller ICCCM stuff was added in the same go). But there is of course also a bit of bad news, which is that this specific page still cannot be transfered, which is according to my findings caused by the Unicode conversion inside of NSString which fails. This may be a bug or caused by the fact that this page includes characters that cannot be expressed as UCS-2. This is a known limitation of our current NSString implementation. There is of course still plenty of room for improvements on xpbs... For now please test again, but remember there is a lot more that may go wrong when no paste result shows up than just the X selection interaction. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Scrub last - better patch....
Hi Pete, just tired this with your favourit UTF-8 page and I was able to copy it from Mozilla over to Ink. Great now all that Unicode copying should be working. (Not that I ever wanted to copy that page anyway) Cheers Fred Richard Frith-Macdonald wrote: On Tuesday, September 9, 2003, at 10:41 PM, Pete French wrote: Sorry about this, please ignore the last UTF8/UTF16 patch, this one has a slight change which makes it better (but got missed in the original email). The addition is to consider the high word of the surrogate pairs as non-spacing. That is a very convenient way for the rest of the code which does not understand UTF-16 to look at it, as well as having a nice side effect of causing the rangeOfComposedCharacterSequenceAtIndex: method to functionas it does on OSX - i.e. give the range of the surrogate pair when applied to either of them individually. Thanks ... looked OK and seemed to work (not break my existing code) so I applied it, though I don't have any testcases for what it's supposed to do. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSDocument close NSApplication targetForAction
Matt Rice wrote: bug when using NSDocument, the key window always responds to close and so NSDocument close never gets called.. and reopening a document would show the one which you just closed rather than reading from disk.. (tested with Ink..) this patch moves the check for document based apps up above the key window, and checks for them on performClose for the windowmaker close button. Sorry for replying so late, I was away for a week. Still I want to oppose this change as it does not stick with the documentation. As for the first part of the patch it changes the search order for targets in a way that does not correspond to what the Cocoa documentation says. According to this the document is asked right after the windows delegate. If we cannot prove that this is handled differently in the actual Cocoa implementation we should keep the old way. Perhaps we have to change the way NSWindow implements close, as I can see the real problem that this patch tries to fix. The second part is even worse, here closing the window and closing the document are mixed. This are two almost independend operations. A document may have multiple windows and may only close when the last one gets closed or sometimes not even then. Again I understand why this patch was intendend, but it tries to solve the problem the wrong way. Once more, I am sorry for the late intervention and hope that together we can find a better way to solve this. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: patches to gnustep/core/back/Source/winlib/WIN32GState.m
Hi Leigh, Leigh Smith wrote: It seems I accidently sent my last patch to WIN32GState.m without a ChangeLog entry. Sorry for that. I am resubmitting the patch together with a ChangeLog entry. Hopefully this will expedite incorporation of the patch into the repository. Please let me know if there are any problems with the patch that needs revision. 2003-10-19[EMAIL PROTECTED] * Source/winlib/WIN32GState.m ([WIN -_paintPath:drawType]): Corrected bug in Bezier curves, a bug in line widths and adds a workaround for a Windows GDI drawing bug when drawing curved wide lines. it would be my task to look into this patch, but I wont have time for this until next weekend. Could you in the meantime provide a bit more information on the underlying problem? I am still unsure, if this is caused by a problem in our code, which then needs a different correction. Or if this is a well known problem of some windows version. Where we might need a version specific patch. Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Recent Documents
Rob Burns wrote: I find I have to delete the defaults for Ink relatively often, because a file I have either deleted or moved, is in the recent documents list. When this is the case, starting Ink results in some errors about adding nil to an array. Could you please provide a gdb backtrace for this? Which version of Ink are you using? The one from Renaissance or the original one. I tried to reproduce this problem with the later and failed to get an error. Perhaps I need more details on how to exactly get it. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] -setTarget: and -setAction: enabled in NSImageView
Kazunobu Kuriyama wrote: Fred Kiefer wrote: I want to second Alexanders position here. The documentation from Apple is rather thin on what change should happen. On the other hand it is rather clear on what should not be changed. NSImageCell should remain a subclass of NSCell and not of NSActionCell. So I asked more than one time why NSImageCell needs to be a subclass of NSCell. Do you know any document that makes this point clear? If there's one, it would give a good foundation for our discussion, reducing perception gap. Anyway, the new behavior of Cocoa's NSImageView seems not to be documented yet. Should we be prudent till an updated decumentation is available? Waiting for a complete documentation from Apple may keep you waiting for ever. Still their documentation is the best we have, as NSImageCell was not part of the OpenStep standard, and there NSImageCell is listed as a direct subclass of NSCell. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] -setTarget: and -setAction: enabled in NSImageView
Kazunobu Kuriyama wrote: Fred Kiefer wrote: Kazunobu Kuriyama wrote: So I asked more than one time why NSImageCell needs to be a subclass of NSCell. Do you know any document that makes this point clear? If there's one, it would give a good foundation for our discussion, reducing perception gap. Anyway, the new behavior of Cocoa's NSImageView seems not to be documented yet. Should we be prudent till an updated decumentation is available? Waiting for a complete documentation from Apple may keep you waiting for ever. Still their documentation is the best we have, as NSImageCell was not part of the OpenStep standard, and there NSImageCell is listed as a direct subclass of NSCell. Hmm...Don't you read the thread from the beginning? I don't have the slightest clue, what I may have missed in the previous mails, which I did read as far as they were send to the public mailing list. Was there any argumetn why NSImageCell may not be a direct subclass of NSCell? I rather drop out of this discussion now, otherwise I might take some offence. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: resetCursorRectsForView
Hi Rob, I just compiled your code and it works fine on my machine. Would you mind to update all of your GNUstep again and recompile your application. If the problem persists, could you than send a detailed description on how to reproduce it and your system parameters. Cheers Fred Rob Burns wrote: Hello, I recently updated gnutep cvs, and found one my apps broken. I dont' know if that is because a recent change uncovered a bug in my app, or if there is a bug in a recent change in GNUstep. The app will segfault when opening a file, or making a new file. There is a backtrace attached. a copy of the app in quiestion can be gotten from here: http://www.eskimo.com/~pburns/rob/Popup-1103.tar.gz I've also found a couple other apps that segfault under similar operations, with a similar backtrace. Thanks Rob Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 3678)] 0x405445fa in objc_msg_lookup () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libobjc.so.1 (gdb) bt #0 0x405445fa in objc_msg_lookup () from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/libobjc.so.1 #1 0x401c0803 in resetCursorRectsForView () from /System/Library/Libraries/libgnustep-gui.so.0 #2 0x401c08a7 in resetCursorRectsForView () from /System/Library/Libraries/libgnustep-gui.so.0 #3 0x401c08a7 in resetCursorRectsForView () from /System/Library/Libraries/libgnustep-gui.so.0 #4 0x401c08a7 in resetCursorRectsForView () from /System/Library/Libraries/libgnustep-gui.so.0 #5 0x401c08a7 in resetCursorRectsForView () from /System/Library/Libraries/libgnustep-gui.so.0 #6 0x401c08a7 in resetCursorRectsForView () from /System/Library/Libraries/libgnustep-gui.so.0 #7 0x401c08f3 in -[NSWindow resetCursorRects] () from /System/Library/Libraries/libgnustep-gui.so.0 #8 0x401bd3cd in -[NSWindow becomeKeyWindow] () from /System/Library/Libraries/libgnustep-gui.so.0 #9 0x401bd88f in -[NSWindow makeKeyWindow] () from /System/Library/Libraries/libgnustep-gui.so.0 #10 0x401b938d in -[NSWindow(GNUstepPrivate) _lossOfKeyOrMainWindow] () from /System/Library/Libraries/libgnustep-gui.so.0 #11 0x401c40df in -[NSWindow sendEvent:] () from /System/Library/Libraries/libgnustep-gui.so.0 ---Type return to continue, or q return to quit--- #12 0x40135a1e in -[NSPanel sendEvent:] () from /System/Library/Libraries/libgnustep-gui.so.0 #13 0x400934cd in -[NSApplication sendEvent:] () from /System/Library/Libraries/libgnustep-gui.so.0 #14 0x40091fe6 in -[NSApplication run] () from /System/Library/Libraries/libgnustep-gui.so.0 #15 0x40088db3 in NSApplicationMain () from /System/Library/Libraries/libgnustep-gui.so.0 #16 0x08050ec9 in main () ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSCell -_nonAutoreleasedTypingAttributes minor change.
Michael Hanni wrote: Seemingly the baseline for string drawing in controls is one pixel too low. Maybe I'm seeing things, but this small patch for NSCell makes these strings center a little better. Some extra research might be necessary. One possible reason for the different appearance of GNUstep may be that we tread the cellFrame wrong in drawWithFrame:inView:. This value is handled on to drawInteriorWithFrame:inView: untouched no matter sort of border is drawn. This may be different in OpenStep and/or Cocoa. At least it is different in myStep where the cellFrame is reduced to exclude the border. This looks logical to me, but again this is something that must be tested on a Cocoa/OpenStep system. Any volunteer for this? In most cases we try to adjust the border in the drawInteriorWithFrame:inView: method, but some of the code may be wrong. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH (revised)] -setTarget: and -setAction of NSImageView
Alexander Malmberg wrote: Kazunobu Kuriyama wrote: --- gui/Headers/AppKit/NSImageCell.h2003-12-29 13:57:42.0 +0900 [snip] + int _tag; + id _target; + SEL _action; + id _control_view; However, the general idea was to add target and action. Adding a tag and a control view effectively turns NSImageCell completely into an NSActionCell, it isn't required to get dragging working, and it isn't in apple's docs (but then, target and action aren't, either). However, I think adding them now is the right thing to do. The cost (amount of code) is low, it makes NSImageCell more useful, and by adding all the stuff at once, we won't have to change the ivar layout/encoding format twice if it turns out that we want them later (eg. because apple really did add them, or will). I don't see any benefit in this additional ivars. Also the main problem why there still is no patch for this is on a different level. What we need to decide is wether to implement the storing of target and action on the cell (as gets done by NSActionCell) or on the view (as done by NSMatrix and loads of others). Here only a test on a MacOSX system could show how Apple did introduce this partly documented feature. But no one with a Mac system has commented on this up to now, that is why the problem may stay unresolved for some more time. There is no abstract way of telling which way around it should be done. As both are in themselves valid. Anyway, unless there are any other ideas about what to do about this, I'll commit this (with the above issues fixed) soon. No, please wait until this question gets answered. If we get the encoding wrong once, we will have to support it for ever! Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH (revised)] -setTarget: and -setAction of NSImageView
Thank you Quentin,
but at GNUstep we prefer not to have a direct contact with Apple code or
headers. I personaly think, that looking at headers should not be to
problematic, but after the recent development with SCO we cannot be to
careful. So please don't send any more information that has been
directly captured from Apple copyrighted files,
On the other hand your findings and that of Ken Ferry cleary show that
Apple did implement the setTarget: and setAction: methods on the level
of the NSImageView. So we rather should do this as well on GNUstep.
Cheers
Fred
Quentin Mathé wrote:
Le 13 janv. 04, à 21:01, Fred Kiefer a écrit :
Alexander Malmberg wrote:
However, the general idea was to add target and action. Adding a tag and
a control view effectively turns NSImageCell completely into an
NSActionCell, it isn't required to get dragging working, and it isn't in
apple's docs (but then, target and action aren't, either).
However, I think adding them now is the right thing to do. The cost
(amount of code) is low, it makes NSImageCell more useful, and by adding
all the stuff at once, we won't have to change the ivar layout/encoding
format twice if it turns out that we want them later (eg. because apple
really did add them, or will).
I don't see any benefit in this additional ivars. Also the main
problem why there still is no patch for this is on a different level.
What we need to decide is wether to implement the storing of target
and action on the cell (as gets done by NSActionCell) or on the view
(as done by NSMatrix and loads of others). Here only a test on a
MacOSX system could show how Apple did introduce this partly
documented feature.
But no one with a Mac system has commented on this up to now, that is
why the problem may stay unresolved for some more time.
There is no abstract way of telling which way around it should be
done. As both are in themselves valid.
Anyway, unless there are any other ideas about what to do about this,
I'll commit this (with the above issues fixed) soon.
No, please wait until this question gets answered. If we get the
encoding wrong once, we will have to support it for ever!
Here are the Mac OS X headers for NSImageView and NSImageCell :
@interface NSImageView:NSControl
{
char _editable;
id _target;
SEL _action;
}
@interface NSImageCell:NSCell NSCopying, NSCoding
{
id _controlView;
struct __ICFlags _icFlags;
struct _NSImageCellAnimationState *_animationState;
NSImage *_scaledImage;
}
Hope that will help.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH (revised)] -setTarget: and -setAction of NSImageView
Thank you Quentin,
but at GNUstep we prefer not to have a direct contact with Apple code or
headers. I personaly think, that looking at headers should not be to
problematic, but after the recent development with SCO we cannot be to
careful. So please don't send any more information that has been
directly captured from Apple copyrighted files,
On the other hand your findings and that of Ken Ferry cleary show that
Apple did implement the setTarget: and setAction: methods on the level
of the NSImageView. So we rather should do this as well on GNUstep.
Cheers
Fred
Quentin Mathé wrote:
Le 13 janv. 04, à 21:01, Fred Kiefer a écrit :
Alexander Malmberg wrote:
However, the general idea was to add target and action. Adding a tag and
a control view effectively turns NSImageCell completely into an
NSActionCell, it isn't required to get dragging working, and it isn't in
apple's docs (but then, target and action aren't, either).
However, I think adding them now is the right thing to do. The cost
(amount of code) is low, it makes NSImageCell more useful, and by adding
all the stuff at once, we won't have to change the ivar layout/encoding
format twice if it turns out that we want them later (eg. because apple
really did add them, or will).
I don't see any benefit in this additional ivars. Also the main
problem why there still is no patch for this is on a different level.
What we need to decide is wether to implement the storing of target
and action on the cell (as gets done by NSActionCell) or on the view
(as done by NSMatrix and loads of others). Here only a test on a
MacOSX system could show how Apple did introduce this partly
documented feature.
But no one with a Mac system has commented on this up to now, that is
why the problem may stay unresolved for some more time.
There is no abstract way of telling which way around it should be
done. As both are in themselves valid.
Anyway, unless there are any other ideas about what to do about this,
I'll commit this (with the above issues fixed) soon.
No, please wait until this question gets answered. If we get the
encoding wrong once, we will have to support it for ever!
Here are the Mac OS X headers for NSImageView and NSImageCell :
@interface NSImageView:NSControl
{
char _editable;
id _target;
SEL _action;
}
@interface NSImageCell:NSCell NSCopying, NSCoding
{
id _controlView;
struct __ICFlags _icFlags;
struct _NSImageCellAnimationState *_animationState;
NSImage *_scaledImage;
}
Hope that will help.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH (revised)] -setTarget: and -setAction of NSImageView
Thank you Quentin,
but at GNUstep we prefer not to have a direct contact with Apple code or
headers. I personaly think, that looking at headers should not be to
problematic, but after the recent development with SCO we cannot be to
careful. So please don't send any more information that has been
directly captured from Apple copyrighted files,
On the other hand your findings and that of Ken Ferry cleary show that
Apple did implement the setTarget: and setAction: methods on the level
of the NSImageView. So we rather should do this as well on GNUstep.
Cheers
Fred
Quentin Mathé wrote:
Le 13 janv. 04, à 21:01, Fred Kiefer a écrit :
Alexander Malmberg wrote:
However, the general idea was to add target and action. Adding a tag and
a control view effectively turns NSImageCell completely into an
NSActionCell, it isn't required to get dragging working, and it isn't in
apple's docs (but then, target and action aren't, either).
However, I think adding them now is the right thing to do. The cost
(amount of code) is low, it makes NSImageCell more useful, and by adding
all the stuff at once, we won't have to change the ivar layout/encoding
format twice if it turns out that we want them later (eg. because apple
really did add them, or will).
I don't see any benefit in this additional ivars. Also the main
problem why there still is no patch for this is on a different level.
What we need to decide is wether to implement the storing of target
and action on the cell (as gets done by NSActionCell) or on the view
(as done by NSMatrix and loads of others). Here only a test on a
MacOSX system could show how Apple did introduce this partly
documented feature.
But no one with a Mac system has commented on this up to now, that is
why the problem may stay unresolved for some more time.
There is no abstract way of telling which way around it should be
done. As both are in themselves valid.
Anyway, unless there are any other ideas about what to do about this,
I'll commit this (with the above issues fixed) soon.
No, please wait until this question gets answered. If we get the
encoding wrong once, we will have to support it for ever!
Here are the Mac OS X headers for NSImageView and NSImageCell :
@interface NSImageView:NSControl
{
char _editable;
id _target;
SEL _action;
}
@interface NSImageCell:NSCell NSCopying, NSCoding
{
id _controlView;
struct __ICFlags _icFlags;
struct _NSImageCellAnimationState *_animationState;
NSImage *_scaledImage;
}
Hope that will help.
Quentin.
--
Quentin Mathé
[EMAIL PROTECTED]
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: i dont know if it is a bug in gui but i suppose to
Reuss Andras wrote: i have a window rect(300,300,200,100) and a [[[NSTextField alloc] initWithFrame: NSMakeRect(30,50,140,20)] setStringValue: @Öt szûz õrült tizenharom írót nyúz]; in case of [[window dataWithEPSInsideRect: NSMakeRect(0, 0, 199, 99)] writeToFile: @afile atomically: YES]; there is always a newpath 88 -4.5 moveto after the 16th character that distorts the output. I tried to find the cause of this bug (if it is) in the source files, but grep did not output any 'newpath' string in the gui source directory, sorry. is it a bug? and the following: why the output of button is gray if the background of the window is white? i think it should be gray too or the button white. best regards andras reuss Hi Andras, you did run into a number of different issues here. First the constant strings shoudl only contain ASCII characters. So when you need to set up your (hungarian?) string you have to do something like: [[NSString alloc] initWithBytes: Öt szûz õrült tizenharom írót nyúz length: 34 encoding: NSISOLatin1StringEncoding]; This is correcter, but does not make an actual difference, as our current implemetnation handles ISOLatin correctly most of the times. Teh drawing being split up in chunks of 16 is an artefact of the NSLayoutManager. This normally would not make any difference, as the layout manager knows the position of every glyph and computes the following moveto correctly. But when doing output to PS files the metrics of the fonts the layout manager uses are different from the actual PS fonts and this will give wrong results when displayed. Also when you use the xlib backend, which does not provide the method nameOfGlyph: on GSFontInfo the glyhs will be output as a string (which gives invalid PS) and this will result in the conversion of the PS output file into ASCII data to fail and the result file would be empty. As for the second problem (button drawing its background in fixed colour), I will look into this now and probably change the NSButtonCell to use the new drawing functions. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSMenu
Quentin Mathé wrote: NSMenuItem autoenabling doesn't work with NSPopUpButton... is it an unimplemented feature ? other problem... with the code below : NSMenu *menu = [[NSMenu alloc] initWithTitle:@]; [NSMenu popUpContextMenu:menu withEvent:myEvent forView:myView]; RELEASE(menu); the menu object doesn't seem to be released (its dealloc method is not called)... Why ? This seems to eb a real bug, so lets move teh discussion to this mailing list. My impression after a short inspection is that the problem comes from the fact that a menu allways registers itself with the notification centre, which in turn will keep a reference to the object thereby keeping it alive. But I might be wrong here, as many classes in GUI use a similar pattern and would thereby be living longer than expected. Coudl somebody with mre knowledge of the implementation of NSNotificationCenter comment on this? Than this problem would even exist in the above code if the menu is only created and released later. Is this true? ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] Fix NSMenu retainCount problem
Quentin Mathé wrote: Here is the patch, two exactly, I was talking about. NSMenu.m patch reworks the notifications use in order that the menu itself hasn't be included in a notification until the notification is sent. I'm less sure for the NSMenuView.m patch : it only removes few lines which seems to have no reason to be there and caused a retain on NSMenu. Must be confirmed. NSMenu patch has fixed the code below : NSMenu *menu = [[NSMenu alloc] initWithTitle:@boum]; [menu addItem:menuItem]; // now the menu retain count is still 1 and not higher NSMenuView patch has fixed the code below : NSMenu *menu = [[NSMenu alloc] initWithTitle:@boum]; [NSMenu popUpContextMenu:menu event:event view:view]; [menu release]; // now the menu is released and deallocated I did spend some time on this problem and I would like to only accept half of your patches. First I have to admit, that I was wrong with the notification center. There everythign seems to be ok. On the other hand I was right that the problem should also occure if you only create a menu and released it again. And this gets solved by your patch on NSMenuView, which really doesnt do any harm as the GSTitleView never uses the menu, it only refers to its owner ivar. In the second case you may have been mislead by the notification still hanging around. When trying to investigate memory leaks one cannot be to carefull to wrap extra layers of auto release pools around the operations in question. Only when the count is still wrong on the highest level, than there is an actual problem. So if you agree, I will apply the second patch and also some of the more verbose error messages you did add to NSMenu. The other changes would only make the code in NSMenu harder to read and give no benefit I can see. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] Fix NSMenu retainCount problem
Quentin Mathé wrote:
Le 5 févr. 04, à 22:37, Fred Kiefer a écrit :
Quentin Mathé wrote:
I did spend some time on this problem and I would like to only accept
half of your patches. First I have to admit, that I was wrong with the
notification center. There everythign seems to be ok.
On the other hand I was right that the problem should also occure if
you only create a menu and released it again. And this gets solved by
your patch on NSMenuView, which really doesnt do any harm as the
GSTitleView never uses the menu, it only refers to its owner ivar.
ok.
In the second case you may have been mislead by the notification still
hanging around. When trying to investigate memory leaks one cannot be
to carefull to wrap extra layers of auto release pools around the
operations in question. Only when the count is still wrong on the
highest level, than there is an actual problem.
I think it's the case (the count is wrong at the highest level, here
NSMenu) or I'm not understanding what you have said.
Ok, so I did not make myself clear. Look at the example below.
Here is an example :
with Cocoa, the code below release and dealloc the menu variable.
NSMenu *menu = [[NSMenu alloc] initWithTitle:@Youlà];
[menu addItem:[[NSMenuItem alloc] initWithTitle:@You
action:@selector(john:) keyEquivalent:@]];
[menu release];
with GNUstep, the same code doesn't dealloc the menu because in NSMenu
_notifications retain the menu itself (in my experience).
That's not nice, because you must remove each menu item retained in the
menu to be able to dealloc it.
menu = [[NSMenu alloc] initWithTitle: @boum];
NSLog(@menu retain count before = %d, [menu retainCount]);
{
CREATE_AUTORELEASE_POOL(pool2);
menuItem = [[NSMenuItem alloc] init];
[menu addItem: menuItem];
RELEASE(menuItem);
RELEASE(pool2);
}
NSLog(@menu retain count after = %d, [menu retainCount]);
For me this results in a menu with a retain count of one, so it will be
deallocated after the next release. GNUSteop might need and internal
autorelease pool in one of the NSMenu methods
Other example :
NSMenu *menu = [[NSMenu alloc] initWithTitle:@Youlà];
NSMenu *item = [[NSMenuItem alloc] initWithTitle:@You
action:@selector(john:) keyEquivalent:@];
[menu addItem:item];
[menu release];
menu = [[NSMenu alloc] initWithTitle:@other];
[menu addItem:item];
The code above which is ok with Cocoa doesn't work with GNUstep.
Yes, this just shows that your cleanup code in NSMenu does the right
thing. That is why I wanted to use it. This has nothing to do with the
notifications.
Last words. You decide... You are involved for far more time than me in
GNUstep :-).
This would be a very bad argument, if this would be the only one. I hope
I have a few more ;-)
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: new encoding
Alexander Malmberg wrote: Rob Burns wrote: I update gnustep cvs today, and found that many of my nibs won't load anymore. Some still do. The difference appears to be the use of NSTableView. None of the nibs that contain NSTableView's can be loaded by the app, or by gorm. I get this error, when running an app: [snip] Fred's keyed decoding additions included some unrelated cleanups of the non-keyed decoding, and these were broken. NSTableView is fixed in cvs. Thanks for the report! :) Thank you for fixing this! I really tried to be carefull with the rework (and believe me some cleanup was needed) but must have made some stupid mistake. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Dynamic loading no longer compiles in base
I tried to compile base from scratch and did run into to following problem: Compiling file objc-load.m ... In file included from objc-load.m:54: dynamic-load.h: In function `__objc_dynamic_get_symbol_path': dynamic-load.h:95: error: `Dl_info' undeclared (first use in this function) dynamic-load.h:95: error: (Each undeclared identifier is reported only once dynamic-load.h:95: error: for each function it appears in.) dynamic-load.h:95: error: parse error before info dynamic-load.h:98: error: `RTLD_DEFAULT' undeclared (first use in this function) dynamic-load.h:105: Warnung: implicit declaration of function `dladdr' dynamic-load.h:105: error: `info' undeclared (first use in this function) make[2]: *** [shared_obj/objc-load.o] Fehler 1 make[1]: *** [libgnustep-base.all.library.variables] Fehler 2 make[1]: Leaving directory `/usr/src/gnustep/core/base/Source' make: *** [internal-all] Fehler 2 This must be related to Adams recent change on simple-load.h as this gets used on my Suse 9.0 Linux machine. When I add # define __USE_GNU before the include of dlfcn.h it works again. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Problems with GORM
I just tested GORM and it is no longer able to display any specific attribute inspector and when selecting the custom class entry from the inspector it seg. faults. Some debugging showed, that the later is caused by setting the string GormCustomClassInspector as the delegate of the browser instead of an object of the class with this name. The question now is, what causes this change in behaviour? After the failure, that was caused by one of my previous changes I am a bit worried, that this may result from the keyed coding stuff I added. So I went through most of the code again, but could not spot any problem. Another possibility could be, that the recent NIB loading changes did affect this, but this sounds even less plausible as Gregory surely checks GORM first. As it is getting late here, I will stop investigating this for today, perhaps somebody else has an idea... ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Once again the NSOutlineView
Andreas Heppel wrote: I have again stumbled across some strange behaviour in NSOutlineView. This time it has to do with reloading items. The method -reloadItem:reloadChildren is using another method called _findItem:childIndex:ofParent:. I suppose that this method is intended to return the parent and the index relative to this parent of the given item. Unfortunately, it is not, as the parameter 'parent' is not by reference. Furthermore, -reloadItem:reloadChildren does not update NSOutlineView's data structures _items and _levelOfItems, which leads to some more starnge behaviour in the case that the NSOutlineView's delegate does not simply return a changed item, but a new one. Maybe, this behaviour is intended, as the delegate is supposed to return the same, but changed item. However, fixing this is not difficult imho, thus, I'd prefer to change this behaviour. Attached is patch with a fix, containg a couple of detailed comments on what I did. I did (hopefully) resolve this problem in a different way, by removing the helper method and inlining the code into reloadItem:reloadChildren:. This allowed for a few more corrections/simplifications (and would allow for more, if I only would understand better, what this method should do). I must admit, that NSOutlineView is a part of GUI, where I don't understand most of the code. No idea, for example, why it replaces the item with NULL, if it is nil. Perhaps you may want to take over the maintainance this class? Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Once again the NSOutlineView
Gregory John Casamento wrote: P.S. Fred, I'm aware of no place in the code where it replaces items with NULL if they are nil. :) Sorry, my fault, I used the word NULL as a short hand for [NSNull null], as can be see in the following line (used about five times in the code of NSOutlineView): id sitem = (startitem == nil)?[NSNull null]:startitem; This makes it possible to work with nil almost as if it was a valid item, but why would you want to do this? This also has been done half heartedly, so some of the replacements, as in the method at hand (reloadItem:reloadChildren:) hs not been done. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Once again the NSOutlineView
Hi Fred, On 2004-02-14 14:11:51 +0100 Fred Kiefer [EMAIL PROTECTED] wrote: I did (hopefully) resolve this problem in a different way, by removing the helper method and inlining the code into reloadItem:reloadChildren:. This allowed for a few more corrections/simplifications (and would allow for more, if I only would understand better, what this method should do). I must admit, that NSOutlineView is a part of GUI, where I don't understand most of the code. No idea, for example, why it replaces the item with NULL, if it is nil. I just had a look at what you checked in two days ago. Seems ok to me, but a part of my patch is missing, and I wonder why. At the end of the reloadItem... method I updated _items and _levelOfItems to ensure that those containers reflect the possible change of the item object. Did you just forget this or was something wrong with that part of the patch? I did forget about that, or rather, I didn't even realize that there was more in the patch. Sorry for that. As I am currently away from home it will take some time until I am able to correct this. Perhaps somebody else will pick up this task? Cheers Fred -- GMX ProMail (250 MB Mailbox, 50 FreeSMS, Virenschutz, 2,99 EUR/Monat...) jetzt 3 Monate GRATIS + 3x DER SPIEGEL +++ http://www.gmx.net/derspiegel +++ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSButtonCell
Adam Fedor wrote: On Thu, 2004-02-05 at 08:00, Quentin Mathé wrote: Here is a patch for NSButtonCell.m which permits to the class to be drawn transparent when it is not bordered. I also removed few lines about the focus dotted rect in order to have it always drawn with the same size than the button. It looks inconsistent to me to have the dotted rect not drawn with the same size when the button has a title, IMHO it should indicate the last focused area which in this case is not just the title area, but like always the button area. And I think also the focus dotted rect must be drawn even when the button is not bezeled (nor bordered). What do you think ? Looks reasonable to me. Any other comments on this? I thought, that due to my drawing patch for NSButtonCell this patch was no longer needed. Am I wrong here? We rather ask Quentin before we make any further change. Apart from that, I would join Gregory and clain that the way this patch handles things is not fully correct. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: Can't use long long variables?
Adam Fedor wrote: On Friday, February 27, 2004, at 05:43 PM, Fred Kiefer wrote: Is there any way to include this setting into make? Up to now I always took it for granted that my Suse Linux didn't have long long support and never thought about it. This is what I'm thinking: In the patch for configure.ac the n in #ifdef _GNU_SOURCE is missing. Does anybody understand why Suse is different in this repesct to other Linux systems? ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Kazunobu Kuriyama wrote: Attached is a patch that corrects NSSavePanel's - (void)beginSheetForDirectory: (NSString *)path fileName: (NSString *)filename modalForWindow: (NSWindow *)docWindow modalDelegate: (id)delegate didEndSelector: (SEL)didEndSelector contextInfo: (void *)contextInfo; For the case where delegate is non-nil, the current implementation fails to work when the OK button on the sheet is pressed. (As delegate is set to nil mostly, this bug has seemingly been overlooked, IMHO.) Reason: The current implementation directly invokes NSApplication's -beginSheet: through the global NSApp. In the implementation of this method, we see ret = [self runModalForWindow: arg1 relativeToWindow: arg2]; and ret is passed to didEndSelector. Since self is NSApp, -runModalForWindow:relativeToWindow: invoked in this case is the one implemented in NSApplication. However, that method returns neither NSCancelButton nor NSOKButton, which are to be passed to didEndSelector by the specifications when NSSavePanel or NSOpenPanel is used. Rather, when using NSSavePanel or NSOpenPanel, ret is always set to NSRunStoppedResponse (0), which is incidentally equal to NSCancelButton (0). This is why the sheet fails to work when the OK button is pressed. The patch rectifies the NSSavePanel's method so that it can work with the OK button properly. Recently, someone corrected the signature of didEndSelector found in NSApplication.m, the need of which was pointed out by my previous patch. The attached patch relies on that correction. So use the latest CVS if you would like to try it. This patch tries to add another workaround on top of all the hacks, that are already there for model and sheet handling. This doesn't look right to me, so I suggest another, hopefully cleaner, way to resolve this: We should give the correct Cocoa values to the constants NSRunStoppedResponse, NSRunAbortedResponse and NSRunContinuesResponse. With these there will no longer be a conflict to the values of NSCancelButton and NSOKButton. So we are able to undo the hack Nicola put into the save panel years ago and to use stopModalWithCode: there again, using the button constant as the code. That way everything will fall into place again and no further hacks will be needed. And perhaps somebody will in the future even donate a fully working sheet processing to GNUstep. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Kazunobu Kuriyama wrote: Fred Kiefer wrote: This patch tries to add another workaround on top of all the hacks, that are already there for model and sheet handling. This doesn't look right to me, so I suggest another, hopefully cleaner, way to resolve this: I agree with the view above as a general idea or policy; the existing code relevant to sheet somewhat looks unnatural, and hence someday it needs to be overhauled. I don't think, however, the view and the ones blow are reasonable verification strong enough to keep the bug alive. We should give the correct Cocoa values to the constants NSRunStoppedResponse, NSRunAbortedResponse and NSRunContinuesResponse. With these there will no longer be a conflict to the values of NSCancelButton and NSOKButton. Because I don't have access to the Cocoa's header files, I'm not sure how this can be done. The NSRun* enum stands for the state of a panel/sheet, whereas the NS*Button enum for the state of buttons on it. Obviously, they are conceptually/semantically different, and we can't identify the former with the latter in a natural way. It would be rather confusing if we could establish a correspondence between them. In addition, I don't think relying on the values of enums is a good programming style; it definitely constitutes buggy code. So we are able to undo the hack Nicola put into the save panel years ago and to use stopModalWithCode: there again, using the button constant as the code. Yes. But I could not do this because of lack of time, and because I found a fairly simple solution. Look, the patch I sent consists of only a few lines of code. It is completely localized in a single method and doesn't introduce any formidable dependency. You can easily remove it when you obtain a complete solution you think of. All of all, it does fix the bug, thus making GNUstep better. It's at least a good tentative solution for now. That way everything will fall into place again and no further hacks will be needed. And perhaps somebody will in the future even donate a fully working sheet processing to GNUstep. I don't understand why you seemingly try to allow GNUstep to live with the bug, which is simply fixed by a few lines of code. It sure is easier to reply to this by actually changing the code, which is what I did. You will see, that I mostly had to remove code that was no longer needed. (There is more, that is now obsolete, we should remove this later on, when the new code is proven to work in all cases) It is surprisingly often the case, that clean code is less lines than hacks, still hack are in general easier to do. As for the new constant value, I don't have access to any Apple headers. I am just able to use the published Application Kit Reference. And as I said, there still is no sheet handling code in NSApplication, there is only that nasty workaround there, which I put in place some years ago (Flaged with lots of FIXMEs). Feel welcome to implement this cleanly. Hope this code works for you Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Alexander Malmberg wrote: Fred Kiefer wrote: We should give the correct Cocoa values to the constants NSRunStoppedResponse, NSRunAbortedResponse and NSRunContinuesResponse. With these there will no longer be a conflict to the values of NSCancelButton and NSOKButton. Relying on two separate enums having distinct values for their constants is wrong unless there is explicit documentation stating that the two enums are disjoint wrt values. There isn't currently, afaict, any such documentation in GNUstep or OpenStep, and I think it'd be a hack to add this for just two specific enums. At least for Cocoa these enums are fully documented, we just need to do the same for GNUstep. And what is the hack, you see here? I just don't get the meaning of the sentence. Instead, if we want to have useful support for passing arbitrary values to -stopModalWithCode:, I think we should do the following (which somewhat overlaps changes to the handling of -abortModal discussed recently): a. Unify handling of -stopModal... and -abortModal (by making all of them equivalent to calling -stopModalWithCode: with the right constant). This will require some changes in the way timers are handled in NSRunLoop to be really useful, but those changes are also needed for other reasons, so I think that's appropriate. I've used those changes locally for a fairly long time, and it hasn't broken anything (and it has fixed some minor issues). I'll send the patch to the list soon, I hope. This does change the semantics of -abortModal. Currently, it raises an exception and never returns. However, this is ugly, causes problems with exception handlers between -abortModal and the run loop, and can't be extended to work across threads. The new behavior would be just like -stopModal's. This is consistent with OpenStep (and, I think Cocoa), but not OPENSTEP. I don't think compatibility will be an issue; all uses in my collection of GNUstep apps are already written as if -abortModal would return. b. Remove all semantic meaning from all NSRun.*Response except NSRunContinuesResponse (which needs to be special in -runModalSession:). Thus, NSRunStoppedResponse and NSRunAbortedResponse are just convenience values for -stopModal and -abortModal. This is actually already the case, so it just needs to be documented. c. Give NSRunContinuesResponse a well-defined, documented value. Since NSRunContinuesResponse has special semantics, apps must avoid using that specific value. This is necessary to make it safe to pass in arbitrary values. I almost fully agree to what you write. But this does not clash with anything I did change, it just complement it with regard to -abortModal and this had already been discussed before. The point where I may disagree but I am not that sure, is b). What would be the result of -runModalSession: if -stopModalWithCode: gets called with NSRunStoppedResponse or NSRunAbortedResponse? If this will still be that value, things are fine for me. To make it easy to use other enums as codes, we should avoid typical enum values, so the current value (-1002) is probably as good as it gets. It's arbitrary, but non-arbitrary values have a greater risk of colliding with other constants. The values of the other NSRun.*Response don't matter (they have no special meaning). Thus, this amounts to documenting the actual value of NSRunContinuesResponse. (Another reason to keep -1002 is that changing the values of these constants breaks binary compatibility. GNUMail and MusicBox users will want to recompile or there'll be odd issues with modal windows; this may have been the cause of some recent bug reports.) Oops, this is a point I missed in my original change. Thank you for pointing this out. Anyway, with these changes, it would be possible for anyone to use any enum or set of constants as codes in -stopModalWithCode: as long as they stay away from the explicitly documented -1002, which seems like a good thing. :) Thoughts? ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] NSSavePanel.m -beginSheetForDirectory::::::
Alexander Malmberg wrote: Fred Kiefer wrote: Alexander Malmberg wrote: [snip] I suppose you could see the headers, which do specify the integer values, as implicit documentation, but GNUstep doesn't have a the header is the documentation-tradition. This is a very strange statement, I already did reply to a previous mail from Kazu, that I don't have access to any Apple header files. Up to now I thought, that my writen word for not using any Apple headers should be enough. This sounds like a misunderstanding. I wasn't talking about apple's headers, I was talking about GNUstep's headers, and what exactly we consider part of our public API, and thus what we need to do to make sure that the integer values of the constants are a part of our public API. Ok, now I see the other way your sentence could be read and was surely meant to be understood. Sorry for reading this different. As for the technical issue, what you wanted to document, as stated in one of your previous mails, is fully suffient. There is one thing, that I really don't understand, which is why the Apple documentation make a big difference between -abortModal and all the -stopModalWithCode: calls. There must be a bit more to this. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] Proposal to fix NSCell issue
Quentin Math wrote: In the current situation NSCell performClick: method doesn't work with NSMatrix and cannot be used for an NSCell subclass with embedded cells. Here is a screenshot for the issue with NSMatrix when you call performClick: on a cell : before the performClick: call http://www.quentinmathe.com/gnustep/work/matrix_before_click.jpg After the performClick: call http://www.quentinmathe.com/gnustep/work/matrix_after_click.jpg To fix this issue, I'm proposing the patches set below. The idea is to have an NSControl method which can return the frame for the cell passed as a parameter, and to have also a such method for NSCell in order to allow NSCell subclasses to embed other cells (like in NSComboBoxCell which I'm currently trying to rewrite). Then the situation will be : Each NSControl knows which is the frame for its cells... Similarly at the cell level, each NSCell knows which is the frame (relative to the control view) for its subcells. To implement this proposal, I have created a protocol GSCellContainer with one method -frameForCell: which is implemented by NSControl and NSCell class, and this NSCell class implements a method -container which returns the container for itself : the container can be a cell or a control (when supercell ivar is nil). This sounds interesting, but what about implementing it with a set of methods more similar to the one from NSPopupButtonCell: -performClickWithFrame:inView: I don't mean the actual implementation there, rather the interface. If we implement this method already in NSCell we should have a nice starting point for the experiments needed to find the best way to implement the functionality needed for NSComboBoxCell and the matrix interaction. It would for example work nicely together with the -frameForCell: method suggested by Quentin. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] Proposal to fix NSCell issue
Quentin Mathé wrote: Le 23 mars 04, à 01:07, Quentin Mathé a écrit : Well, here is two patches which add -performClickWithFrame:inView: to NSCell and mark performClick: as deprecated. If everybody is ok, I can commit this NSCell modification. Here are a more complete set of patches to fix the related issues : I like the code in NSCell and also the cleanup of the unneeded defintions for NSButton, what worries me is the sending of the action in NSButtonCell. This already gets done in the super class, so why doublicate it here? Also I see no reason for the change on NSWindow, performClick: will still work, so why change it? For NSPopupButtonCell the documentation states that the default action should be the the opening of the popup, so perhaps the whole code here is unneeded we just should set up the action and target correctly for the cell. And for NSCell the documentation has some hint that the sender will be used if no control view is already set. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] Proposal to fix NSCell issue
Quentin Mathé wrote: Here is an updated set of patches... I hope it's ok now : I removed the action send in NSButtonCell and also the NSWindow patch (-performClick: is kept until better solution is found). I think it is ok to commit. As I wrote before, I like the patch. There are a few remaining minor things, I don't see the reason for the change on NSControl and NSCell performClick: still ignores the sender if the controlView is unset. But anyway, for me it would be fine to have this commited. Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] Proposal to fix NSCell issue
Quentin Mathé wrote: Le 31 mars 04, à 09:25, Fred Kiefer a écrit : Alexander Malmberg wrote: I'd rather remove [NSCell -performClick:] than extend it, but either way, it'll be easy to do this after this change. here I have to object. performClick: is an interface that is documented by Apple (and as far as I remember was even in the OpenStep specification), we never should remove such an interface. Even the comment that makes this deprecated is a bordering case, as it may be seen as suggesting, that we might remove it at some time. It would be very frustrating for OpenStep and Cocoa programmers to stumble over such a trivial change when porting things to GNUstep. performClick: is not part of the OpenStep specification. Sorry, as I wrote, I was not sure. After your mail I checked and it is there on NSButton and NSButtonCell at least in my OpenStep specification (October 19, 1994, not sure if there are different versions). As this issue is becoming a bit strange now, would you mind to state explicitly what you and Alexander are aiming at? My position is rather clear: Trying to improve our actual implementation, while keeping an interface that is compliant to OpenStep as well as to Cocoa. Which is fairly easy in this specific case, as the two are not conflicting. I hope, that you are with me here and we just keep this method and apply the rest of the patch. Fred (a bit confused) ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: [PATCH] Proposal to fix NSCell issue
Quentin Mathé wrote: Le 1 avr. 04, à 01:40, Fred Kiefer a écrit : Sorry, as I wrote, I was not sure. After your mail I checked and it is there on NSButton and NSButtonCell at least in my OpenStep specification (October 19, 1994, not sure if there are different versions). As this issue is becoming a bit strange now, would you mind to state explicitly what you and Alexander are aiming at? My position is rather clear: Trying to improve our actual implementation, while keeping an interface that is compliant to OpenStep as well as to Cocoa. Which is fairly easy in this specific case, as the two are not conflicting. I hope, that you are with me here and we just keep this method and apply the rest of the patch. Fred (a bit confused) Don't be confused :-). The problem is the following, Apple has added -performClick: to NSCell but this is impossible to implement without large modifications on NSMatrix for example (see my first set of patches) and moreover it doesn't fit very well with the NSCell philosophy : when you ask something to a cell you should pass a frame and a view for the display with the method arguments. Then Alex and me have thought it would better to deprecate NSCell -performClick: method in favor of a more NSCellish method like performClickWithFrame:inView: which follows the NSCell philosophy like drawInteriorWithFrame:inView:. Now you are saying -performClick: method for NSButtonCell is part of the OpenStep specification. Then I agree now to not remove this method in NSButtonCell and NSCell also to stay compatible with Apple and OpenStep spec. I think we should just deprecate such method for the moment, but I still think also that -performClick in NSCell (like Apple) or in NSButtonCell (like OpenStep spec.) is a design error. You must know also that with my proposed set of patches NSCell NSButtonCell will still be unusable inside an NSMatrix with the method -performClick. Here I reassert this is the reason to deprecate it in favor of performClickWithFrame:inView: I hope I have been clearer than the light ;-). Sad enough your mail did not clear up things. The technical issue is clear to me. That was why I, and not you together with Alexander, suggested to use the -performClickWithFrame:inView: interface borrowed from NSPopupButtonCell. And using this method inside of NSMatrix implementation of -performClick: should fix your problems, without needing to deprecate -performClick:. And that was puzzling me, why do you want to deprecate a method that has is valid usages and is part of two standards, just because there are cases, where it better is not used? And I am still surprised that you stated in the previous mail, -performClick: was not in OpenStep and in this mail write, I am saying it is. This is something rather easy to decide. It either is in the standard or it is not. Without me saying so. As far as I remember, I was only making technical comments on your different patch versions in the mailing list and would have sticked to that, if Alexander wouldn't have started to harass the poor little -performClick: method. Here I steped in and from than on things went strange. And I now want to know why. ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
Re: NSPathUtilities Patch - 2 - Win32
Hi Sheldon, the current state of this patches looks rather dubious to me. In the function Win32GetUserProfileDirectory an undeclared variable s (NSString *) is used and InitialisePathUtilities calles Win32Initialise unconditionally. This make me feel rather uneasy with the whole set of patches. Could you please retest the patch on a non Windows platform? I would also suggest, that you drop the fancy stuff with the #pragma mark statements (or explain why you need them and the decoration around). I did not follow the original discussion in every detail, but as far as I remember the suggestion was, that you split up your big patch in smaller ones to be reviewed and applied separatly. The current patch has been split up in different mails, but again may only be applied in one go. What about introducing the new Win32 functions (and removing obsolte functions and perhaps renaming the file) in one patch and doing the rest in separate patches? Cheers Fred ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #8820] Number of columns is not increased in NSMatrix's -addColumn
This mail is an automated notification from the bugs tracker of the project: GNUstep. /**/ [bugs #8820] Latest Modifications: Changes by: Fred Kiefer [EMAIL PROTECTED] 'Date: Thu 05/13/04 at 22:01 (GMT) What | Removed | Added --- Resolution | None | Works for me Status | Open | Analyzed -- Additional Follow-up Comments I tried to reproduce this bug report witht he attached small file. But this works fine for me. Could you please come up with a bit of code that demonstrates the problem? Otherwise I will close this bug report after some time. /**/ [bugs #8820] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8820 Project: GNUstep Submitted by: 0 On: Thu 05/06/04 at 09:19 Category: Gui/AppKit Severity: 5 - Average Item Group: Bug Resolution: Works for me Assigned to: None Status: Analyzed Summary: Number of columns is not increased in NSMatrix's -addColumn Original Submission: When adding a new column to an NSMatrix object via -addColumn the the number of columns (ivar _numCols) is not adjusted properly. -numberOfColumns always reports the initial number of columns. Removing columns seems to work, though. Follow-up Comments -- --- Date: Thu 05/13/04 at 22:01 By: FredKiefer I tried to reproduce this bug report witht he attached small file. But this works fine for me. Could you please come up with a bit of code that demonstrates the problem? Otherwise I will close this bug report after some time. --- Date: Thu 05/06/04 at 09:38 By: None Sorry, my mistake. I did not look close enough. There is NO bug. File Attachments --- --- Date: Thu 05/13/04 at 22:01 Name: matrix.m Size: 1KB By: FredKiefer http://savannah.gnu.org/bugs/download.php?item_id=8820amp;item_file_id=1300 For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8820 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #8385] NSKeyedUnarchiver doesn't unarchive on Windows
This mail is an automated notification from the bugs tracker
of the project: GNUstep.
/**/
[bugs #8385] Latest Modifications:
Changes by:
Fred Kiefer [EMAIL PROTECTED]
'Date:
Sun 05/09/04 at 15:57 (GMT)
What | Removed | Added
---
Resolution | None | Fixed
Status | Open | Closed
-- Additional Follow-up Comments
I tried to reproduce this problem with the current GNUstep code on Cygwin and it works
perfectly there. Must have been fixed by some of Richard changes.
/**/
[bugs #8385] Full Item Snapshot:
URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8385
Project: GNUstep
Submitted by: 0
On: Wed 03/31/04 at 10:25
Category: Base/Foundation
Severity: 5 - Average
Item Group: Change Request
Resolution: Fixed
Assigned to: None
Status: Closed
Summary: NSKeyedUnarchiver doesn't unarchive on Windows
Original Submission: NSKeyedUnarchiver doesn't seem to unarchive on Windows.
The following code
id test=[NSMutableArray arrayWithObjects:@Test, @Keks, @Hurz, nil];
id e = [test objectEnumerator];
id c;
printf(beforen);
while(c=[e nextObject])
{
printf(%sn, [c cString]);
}
[NSKeyedArchiver archiveRootObject:test toFile:@test];
test = [NSKeyedUnarchiver unarchiveObjectWithFile:@test];
e = [test objectEnumerator];
printf(aftern);
while(c=[e nextObject])
{
printf(%sn, [c cString]);
}
works perfectly in OS X (with Apple's foundation library). On Windows, it doesn't.
The unarchived array seems completely empty (but the program doesn't crash).
Also, NSKeyedArchiver saves the version property as a string; it should be an
integer. When I manually change that, I can unarchive the archived object from Windows
on OS X.
Follow-up Comments
--
---
Date: Sun 05/09/04 at 15:57 By: FredKiefer
I tried to reproduce this problem with the current GNUstep code on Cygwin and it works
perfectly there. Must have been fixed by some of Richard changes.
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailitemitem_id=8385
___
Message sent via/by Savannah
http://savannah.gnu.org/
___
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #8018] NSMutableDictionary writeToFile:atomically:
This mail is an automated notification from the bugs tracker of the project: GNUstep. /**/ [bugs #8018] Latest Modifications: Changes by: Fred Kiefer [EMAIL PROTECTED] 'Date: Sun 05/09/04 at 20:11 (GMT) What | Removed | Added --- Status | Open | Closed -- Additional Follow-up Comments Adopted the status field to the resolution field. /**/ [bugs #8018] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8018 Project: GNUstep Submitted by: 0 On: Fri 03/05/04 at 12:06 Category: Base/Foundation Severity: 5 - Average Item Group: Bug Resolution: Fixed Assigned to: CaS Status: Closed Summary: NSMutableDictionary writeToFile:atomically: Original Submission: The problem is located when a Distant dictionary is an Object for a Key in a local dictionary and the local one has to be written to a file, no matter if atomically or not. This causes a SIGSEGV on the process which registered the object trying to write. It has been tested with gnustep-base 1.7.2, 1.9.0, 1.9.1, it is the same. Tests have been performed with gcc 3.3.2 on i686 architecture. In attacched files: t3.m - exports a dummyObj t3c.m - client, creates a dictionary and passes it as a parameter to t3-exported remote dummyObj. dummy.h - interface for 'dummyObj' dummy.m - implementation for 'dummyObj': creates a 1 unit dictionary containing the passed dictionary and writes it to file. Possible (failed) workarounds are commented in dummy.m On NeXT Runtime the same code runs perfectly. Follow-up Comments -- --- Date: Sun 05/09/04 at 20:11 By: FredKiefer Adopted the status field to the resolution field. --- Date: Tue 03/16/04 at 14:55 By: None Thank you. Do you think the latter one to be a libffi problem and that I should report them it ? --- Date: Mon 03/15/04 at 18:05 By: CaS Fixed in CVS. One problem was the use of -getObjects: to retrieve items to write to file ... which can't work with distributed objects. Another problem appeared to happed with libffi and caching a method implementation ... I don't understand that one and simply altered the code a little to avoid the cachign as a workaround ... not a proper solution as, as far as I can see, the cacheing ought to work. --- Date: Fri 03/05/04 at 16:25 By: None More debugging revealed the problem is more generic: given a remote mutable dictionary, a [dict allKeys] call will fail by problems of the DO code. --- Date: Fri 03/05/04 at 12:10 By: None my email is [EMAIL PROTECTED] File Attachments --- --- Date: Fri 03/05/04 at 12:10 Name: dummy.h Size: 114KB By: None dummy header http://savannah.gnu.org/bugs/download.php?item_id=8018amp;item_file_id=1091 --- Date: Fri 03/05/04 at 12:09 Name: dummy.m Size: 735KB By: None dummyobj http://savannah.gnu.org/bugs/download.php?item_id=8018amp;item_file_id=1090 --- Date: Fri 03/05/04 at 12:08 Name: t3c.m Size: 481KB By: None client http://savannah.gnu.org/bugs/download.php?item_id=8018amp;item_file_id=1089 --- Date: Fri 03/05/04 at 12:06 Name: t3.m Size: 371KB By: None server http://savannah.gnu.org/bugs/download.php?item_id=8018amp;item_file_id=1088 For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8018 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #7509] Does not load on Cygwin
This mail is an automated notification from the bugs tracker of the project: GNUstep. /**/ [bugs #7509] Latest Modifications: Changes by: Fred Kiefer [EMAIL PROTECTED] 'Date: Sat 05/08/04 at 12:11 (GMT) What | Removed | Added --- Resolution | None | Invalid Status | Open | Declined -- Additional Follow-up Comments As the original poster did not reply to the request for more information this report will be closed as unreproducable. /**/ [bugs #7509] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7509 Project: GNUstep Submitted by: 0 On: Thu 01/29/04 at 15:10 Category: Gui/AppKit Severity: 5 - Average Item Group: Bug Resolution: Invalid Assigned to: None Status: Declined Summary: Does not load on Cygwin Original Submission: It compiles correctly but dies with a segfault when loading any application using it, either at startup if linked in or whenever it's loaded. It seems to be a strange initialization error, as the segfaul occurs in _cygwin_init_dll, which is called at DLL load time. Follow-up Comments -- --- Date: Sat 05/08/04 at 12:11 By: FredKiefer As the original poster did not reply to the request for more information this report will be closed as unreproducable. --- Date: Tue 02/24/04 at 20:31 By: FredKiefer Could you please describe your system setup in more detail? There has been a similar problem on windows before which was always due to some corrupt DLL (mostly the tiff) or the ObjC runtime was linked in statically. Only when this has both been ruled out, it will be important that you provide the output of the configuration of base and gui. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7509 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #7901] NSDocument (portability)
This mail is an automated notification from the bugs tracker of the project: GNUstep. /**/ [bugs #7901] Latest Modifications: Changes by: Fred Kiefer [EMAIL PROTECTED] 'Date: Sat 05/08/04 at 13:42 (GMT) What | Removed | Added --- Assigned to | None | FredKiefer Status | Open | Closed -- Additional Follow-up Comments Added a basic implementation of these methods. Delegation setting on the save panel is still missing. /**/ [bugs #7901] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7901 Project: GNUstep Submitted by: Fabien VALLON On: Wed 02/25/04 at 11:03 Category: Gui/AppKit Severity: 5 - Average Item Group: Change Request Resolution: None Assigned to: FredKiefer Status: Closed Summary: NSDocument (portability) Original Submission: runModalSavePanelForSaveOperation:delegate:didSaveSelector:contextInfo: saveToFile:saveOperation:delegate:didSaveSelector:contextInfo: not implemented. Extention (and popup) not implemented. Fabien Fred : do you plan to work on it ? Follow-up Comments -- --- Date: Sat 05/08/04 at 13:42 By: FredKiefer Added a basic implementation of these methods. Delegation setting on the save panel is still missing. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7901 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #7876] NSSavePanel
This mail is an automated notification from the bugs tracker of the project: GNUstep. /**/ [bugs #7876] Latest Modifications: Changes by: Fred Kiefer [EMAIL PROTECTED] 'Date: Sat 05/15/04 at 17:09 (GMT) What | Removed | Added --- Status | Analyzed | Declined /**/ [bugs #7876] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7876 Project: GNUstep Submitted by: Fabien VALLON On: Tue 02/24/04 at 16:32 Category: Gui/AppKit Severity: 3 - Ordinary Item Group: Change Request Resolution: None Assigned to: None Status: Declined Summary: NSSavePanel Original Submission: Into _initWithoutGModel : [_browser setDoubleAction: @selector(performClick:)]; [_browser setTarget: _okButton]; What does it supposed to do ? Follow-up Comments -- --- Date: Tue 02/24/04 at 20:27 By: FredKiefer This few lines result in a double click on an item in the browser to be treated as a click of the ok button. That way the user has it easier to select something without moving the mouse to much. I cannot see, why this has been reported as a bug. If the behaviour is considered as wrong a bit more explaination is missing on what should be changed. If it was just a question the mailing list are surely the better place for this. For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=7876 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #4749] GWorkspace thumbnail views are not correct
This mail is an automated notification from the bugs tracker of the project: GNUstep. /**/ [bugs #4749] Latest Modifications: Changes by: Fred Kiefer [EMAIL PROTECTED] 'Date: Sat 05/15/04 at 17:21 (GMT) What | Removed | Added --- Category | Gui/AppKit| Backend -- Additional Follow-up Comments Adam implemented this method in GUI and the xlib backend some time ago. It is still missing in the other backends. /**/ [bugs #4749] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=4749 Project: GNUstep Submitted by: 0 On: Sat 08/16/03 at 10:58 Category: Backend Severity: 1 - None Item Group: Change Request Resolution: None Assigned to: None Status: Open Summary: GWorkspace thumbnail views are not correct Original Submission: When I thumbnail an image file in GWorkspace, the resulting thumbnail does not adequately represent the original image. I am running a CVS version of GWorkspace from 20030813 on NetBSD/i386. While the thumbnail image might be considered attractive in an impressionist way, the image cannot be used to identify the contents of the file. Follow-up Comments -- --- Date: Sat 05/15/04 at 17:21 By: FredKiefer Adam implemented this method in GUI and the xlib backend some time ago. It is still missing in the other backends. --- Date: Sun 08/17/03 at 18:30 By: esersale NSBitmapImageRep should implement -initWithFocusedViewRect: File Attachments --- --- Date: Sat 08/16/03 at 10:58 Name: impressions.png Size: 44KB By: None Capture of a window containing the quot;impressionistquot; thumbnails http://savannah.gnu.org/bugs/download.php?item_id=4749amp;item_file_id=602 For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=4749 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
[bugs #8334] No text display on NetBSD
This mail is an automated notification from the bugs tracker of the project: GNUstep. /**/ [bugs #8334] Latest Modifications: Changes by: Fred Kiefer [EMAIL PROTECTED] 'Date: Sat 05/15/04 at 17:30 (GMT) What | Removed | Added --- Category | Gui/AppKit| Backend -- Additional Follow-up Comments Could you please check if the fontcacher process has run successfully and if not run it manually? (There should be a non empty file in ~/GNUstep/Library/Fonts/Cache/) /**/ [bugs #8334] Full Item Snapshot: URL: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8334 Project: GNUstep Submitted by: Riccardo mottola On: Sat 03/27/04 at 17:40 Category: Backend Severity: 5 - Average Item Group: Bug Resolution: None Assigned to: None Status: Open Summary: No text display on NetBSD Original Submission: On NetBSD (68k) gnustep builds but there is no text display (inside dialog boxes) and menus are only a few pixel wide. This using the xlib backend. It does happen on the local xserver and exporting to different xservers. Doing a clean reinstall of the operating system (upgraded to latest 1.6.2 and a clean build of GNUstep from CVS did not help. Follow-up Comments -- --- Date: Sat 05/15/04 at 17:30 By: FredKiefer Could you please check if the fontcacher process has run successfully and if not run it manually? (There should be a non empty file in ~/GNUstep/Library/Fonts/Cache/) For detailed info, follow this link: http://savannah.gnu.org/bugs/?func=detailitemitem_id=8334 ___ Message sent via/by Savannah http://savannah.gnu.org/ ___ Bug-gnustep mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-gnustep
