Re: Recent NSMenu changes..
Nicolas Roard schrieb: On 1/29/07, Gregory John Casamento [EMAIL PROTECTED] wrote: All, Perhaps we could put a set of images to represent the key masks needed.The #/+/- scheme adds absolutely nothing and only clutters the interface. It would be better to implement a mechanism which shows some images (pehaps *original* versions of the same symbols used in Cocoa) to represent Control, Command, Shift, and Alt. Images would be better, indeed. You probably do not need to show the shift modifier though -- simply use an uppercase letter (unless it's not a letter, of course). Not sure here. At least reusing the Apple images wont help those of us that don't use an Apple keybord :-) Also when displaying images we need another whole set of changes to the size calculation and drawing code in NSMenuItemCell. Who ever wants to do this is free to do so, but I wont do anything in that direction. To answer the other mails as well: - Not showing the modifier symbol for Alt wont help. What would you display for a key that works without any modifier? For example F12 could be a short cut and Alt-F12 one as well. How would a user be able to distinguish these? - Showing the full explanation of a modifier is a bubble help is in itself a great idea. But it does not resolve the original problem that we need to display something to give the user an idea, what modifiers have to be used. - The code already tries to remove the shift modifier, when an uppercase letter is given. The code here may be wrong, as I did change Nikolaus original code. Sorry, as I wrote in my first answer, I am not happy with the current approach either. But all the answers up to now suggest that nobody actually sees the problem here or is taking it serious. I am going to drop out of the further discussion until that stage has been reached. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Recent NSMenu changes..
Matt Rice schrieb: I don't really like the new NSMenuItemCell behaviour which adds #, /, +, ^ to show the key mask before the key equivalent.. i think its unattractive and makes it hard to quickly see the key equivalent, and doesn't increase the comprehension of which keys to press since they don't map to the actual keys to be pressed on the keyboard It is a good point that this does look ugly and that it does not really help a user to judge what modifier she needs to press to get the key equivalent working. I did copy this code from mySTEP because up to then the GNUstep code had only displayed the key equivalent itself. This might in some cases even be a non printable character like return or escape, so some change was needed. But our old code also did not show the key modifier. I think in May last year Richard corrected the GUI code to respect the key equivalent modifier, since then other modifier apart from ALT where possible, but the GUI did not give a glue about which modifier where needed. So seeing an s as the key modifier you had to go through all the possible modifier combinations to trigger the short cut. This clearly needed to be changed. The question now is, if you have a better proposal on how to display the modifier? Any idea here would be welcome. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Duplicate Member in NSMenuItemCell.h
Adam Fedor schrieb: On Jan 26, 2007, at 7:48 AM, Richard Frith-Macdonald wrote: On 24 Jan 2007, at 16:36, Ted Howard wrote: Perhaps a bigger issue is that my compiler (gcc-4.1.1) happily compiles the current code! Now that seems to me like a rather severe compiler bug. Does anyone know different? I don't know why it wouldn't be a bug. Anyway, the Testfarm shows several machines that fail (and don't). For instance gcc 4.0.1 on Darwin fails to compile, but 4.1.1. (on Solaris) happiliy compiles this... http://www.gnustep.org/developers/testfarm-results.txt Sorry for taking so long to fix this simple bug. The ivar in NSMenuItemCell was totally useless and was only set and used within a single method. But then the code did not belong into this method at all. So I had to move it to a different method and then one thing followed from the other. In the end I had do do quite a few changes to the file and would even prefer to change more in it. But before doing this, I would like to get some feedback on the changes up to now. As for the compiler, I now think that the correct behaviour was to allow the duplicate ivar. In NSMenuItemCell this ivar was declared as private. With that scope it should not clash with another ivar of the same name in a super class. At least this is what I think. Still it is better to avoid this case and have unique names for ivars. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: emacs.app does not support -GSFilePath
Adrian Robert schrieb: Someone was asking me about whether Emacs.app supports the -GSFilePath option which GWorkspace uses to tell applications to open files. I thought that there were already two ways to do this in OpenStep / Cocoa: -NSOpen option, and NSApplication-application:openFIle: method via DO or notifications. Is this correct or is the GNUstep-specific -GSFilePath really needed? Not sure, if I did understand your question. The code in [NSApplication finishLaunching] supports NSOpen and GSFilePath, so if an application inherits from this class it should just work with both parameters. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Duplicate Member in NSMenuItemCell.h
Ted Howard schrieb: When I try to compile gui from the trunk, I get a duplicate member error in NSMenuItemCell.h on _backgroundColor. Upon looking at the code, I noticed that NSButtonCell was recently modified to include a _backgroundColor member. Since NSMenuItemCell extends NSButtonCell, the _backgroundColor member of NSMenuItemCell should be removed. I tried this on my machine, and it seems to work fine. I have attached a patch that does this. This problem is interesting, as I did not get it reported by my gcc. I had noticed it myself before, but as gcc did accept my code without a warning I thought it wont pose a problem to anyone. So I thought, that I could address it later on, when in my progress of adding MacOS 10.4 methods to each class I ever would reach this one. I will correct this tomorrow, removing all references to the ivar in NSMenuItemCell, which never had been needed there at all. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Questions to NSButtonCell
Christopher Armstrong schrieb: Quite coincidentally, I've been playing around with this stuff myself in an attempt to develop further the theming API. I've been having trouble trying to sort out some of these problems as well. I was going to develop further what I was working on for submitting it, but I may as well share it now to avoid duplication. Find attached a patch against the gnustep-gui theming branch in SVN (please note it contains some extra API's I've been prototyping but haven't used yet, plus some documentation for NSScroller that I need to separate out and submit as a different patch). Thank you for that code. I took it as the base for a slightly simpler implementation. I will now start testing it and if things work out well will commit it later today. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Questions to NSButtonCell
While I working on NSButtonCell I stumbled over a few questions that I am not able to solve myself. Perhaps one of you knows some of the answers. 1. Gradients I tried to get gradients for a button to display on my Mac, but failed to see any difference. How do I enable gradient display? I want to get this displayed to decide if the method drawGradientWithFrame:inView: does the correct thing. Even then this method would need to be renamed or moved to GSTheme, but I suspect that it does the wrong thing. The code here fills the whole button with the gradient, I would expect that only the border needs to be shaded. 2. Cell Frame All my previous test on MacOSX suggest, that the cell frame being passed into drawInteriorWithFrame:inView: is exactly the same that did get passed into drawWithFrame:inView:. But in the current GNUstep implementation this frame gets reduced by the size of the bezel border. This solution is a lot more elegant, but it will break porting between Cocoa and GNUstep, if there is indeed a difference. I think what we need to do is correct drawingRectForBounds: to ask the theme for the size of the border. 3. border and bezel Now NSCell has two different concepts for its border. It is either a simple line, in which case it is called border, or a more complex thing, then it is called bezel. For NSButtonCell these two seem to be merged. Our code only checks the border flag, but it will draw a bezel. I think that our code is correct, but we should get it better in sync with the cell code. 4. show state Why are we in the case of highlighted button cells subtracting the shows state by mask from the highlight mask? This may be fully correct, I just don't get the reasoning behind it. There are more questions, but these are the ones, where I have given up finding a solution myself. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep subversion statistics
Andrew Ruder schrieb: I was browsing freshmeat.net earlier tonight and came across a package called 'svnstat.' Since I keep local mirrors of all the gnustep stuff (with svk), I generated some statistics of some gnustep stuff. It is pretty neat to look through. http://dump.aeruder.net/gnustep-stats/gdl2 http://dump.aeruder.net/gnustep-stats/base http://dump.aeruder.net/gnustep-stats/gui http://dump.aeruder.net/gnustep-stats/back http://dump.aeruder.net/gnustep-stats/make It should be fairly accurate with the exception of the actual revision numbers (they are slightly skewed with the svk mirroring process, i.e. revision 23457 might be 26500 on my machine). Great stuff, I specially like the heat diagram, where you can see what has been changed over the last 30 days. To bad GNUstep is changing at a much slower rate, so most of the fields stay black. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSMatrix keyboard stuff
Now this looks like a nice and simple patch. If this replaces all your
previous patches then just go ahead and apply it. Or should I or Greg do
it for you? I think it is fine to have this one in, even if Greg will be
doing his stable release any time now.
Greg, are you actually? I just cannot remember what the result of that
discussion was. Currently I am keeping back my bigger changes and
waiting for you to give a sign when commits are welcome again.
Cheers.
Fred
Matt Rice schrieb:
On 2007-01-10 09:17:49 -0800 Matt Rice [EMAIL PROTECTED] wrote:
On 2007-01-10 09:04:57 -0800 Matt Rice [EMAIL PROTECTED] wrote:
On 2007-01-10 07:59:16 -0800 Fred Kiefer [EMAIL PROTECTED] wrote:
HI Matt,
could you please explain this patch a bit? Only the last bit is about
selecting the right cell in NSTrackModeMatrix. Are the other change a
result of this?
It looks like you intent to prevent the setting of the cell state for
this mode. Is this correct?
Yes, you understand the patch correctly,
I've just noticed the difference between -keyCell and -selected*,
which seems to be what i need/the reason for my confusion.
this one is much cleaner :D
ok... so this one isn't going to be correct either.. because
_selectCellAtRow:column: sets the state..
alright sorry for the barrage of emails.
I hadn't noticed the above because _selectCell:atRow:column: sets it to
NSOnState.
and the button i tested it with was on, so it was set to On then to Off
by the setNextState.
_selectCell:atRow:column: isn't right because the selected cell can have
an NSOffState.
for track/highlight mode and NSOnState for list/radio...
hopefully this patch takes care of it :D
matrix-kbd3.diff
Index: NSMatrix.m
===
--- NSMatrix.m(revision 24334)
+++ NSMatrix.m(working copy)
@@ -1211,7 +1211,14 @@
_selectedColumn = column;
_selectedCells[row][column] = YES;
- [_selectedCell setState: NSOnState];
+ if (_mode == NSListModeMatrix || _mode == NSRadioModeMatrix)
+{
+ [_selectedCell setState: NSOnState];
+ }
+ else
+{
+ [_selectedCell setNextState];
+ }
if (_mode == NSListModeMatrix)
[aCell setHighlighted: YES];
@@ -3695,25 +3702,17 @@
[self _altModifier: character];
else
{
- NSCell *cell;
-
switch (_mode)
{
case NSTrackModeMatrix:
case NSHighlightModeMatrix:
- cell = _cells[_dottedRow][_dottedColumn];
-
- [cell setNextState];
- [self setNeedsDisplayInRect: [self cellFrameAtRow: _dottedRow
- column: _dottedColumn]];
+ case NSRadioModeMatrix:
+ [self selectCellAtRow:_dottedRow column: _dottedColumn];
break;
case NSListModeMatrix:
if (!(modifiers NSShiftKeyMask))
[self deselectAllCells];
-
- case NSRadioModeMatrix:
- [self selectCellAtRow: _dottedRow column: _dottedColumn];
break;
}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test fro overridden method
Richard Frith-Macdonald schrieb:
On 29 Dec 2006, at 01:26, Fred Kiefer wrote:
Could somebody please verify that this method does what I expect it to
do?
I need such a test within NSDocument. Here Apple takes special care that
if somebody has implemented the old interface methods for NSDocument in
a subclass, then these methods are actually called instead of the new
interface methods.
/*
* Private helper method to check, if the method given via the
selector sel
* has been overridden in the current subclass.
*/
- (BOOL)_hasOverridden: (SEL)sel
{
// The actual signature is not important as we wont call the methods.
IMP meth1;
IMP meth2;
meth1 = [self methodForSelector: sel];
meth2 = [[NSDocument class] instanceMethodForSelector: sel];
return (meth1 != meth2);
}
I'm not sure what you mean by 'verify' ... but unless someone has
overridden any of the three methods you use, I would expect the code to
return 1 if the method for _sel has been overridden, 0 otherwise.
You can bypass issues with those methods being overridden by calling the
appropriate runtime functions, however if someone has overridden the
methods they probably did so for a reason, and bypassing them could
also cause problems. So while using the runtime directly can help, it
can also (if less likely) cause problems. I would guess it is less
likely to cause problems than cure them, so runtime use is probably
better, but it's by no means certain.
I suppose the most efficient implementation one could do would be
something like ...
BOOL
GSObjCHasOverridden(Class baseClass, NSObject *instance, SEL selector)
{
Class instanceClass = GSObjCClass(instance);
if (instanceClass == baseClass
|| GSGetMethod(instanceClass, selector, YES. YES) ==
GSGetMethod(base, selector, YES. YES))
{
return YES;
}
return NO;
}
which might be a candidate for inclusion in GSObjCRuntime.[hm]
Of course, it might be worth being able to test overriding of class
methods too, depending on whether you pass an instance or a class
BOOL
GSObjCHasOverridden(Class baseClass, id object, SEL selector)
{
if (GSObjCIsClass(object))
{
if ((Class)object == baseClass
|| GSGetMethod((Class)object, selector, NO. YES) ==
GSGetMethod(base, selector, NO. YES))
{
return YES;
}
}
else
{
Class instanceClass = GSObjCClass(object);
if (instanceClass == baseClass
|| GSGetMethod(instanceClass, selector, YES. YES) ==
GSGetMethod(base, selector, YES. YES))
{
return YES;
}
}
return NO;
}
Thank you very much for this code. This uses some fast but GNU runtime
specific functions. I will stick with my slower method of testing until
this implementation makes it into GSobjCRuntime and we also have an
abstraction that allows similar tests with the Apple runtime.
Cheers,
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Test fro overridden method
Richard Frith-Macdonald schrieb:
On 30 Dec 2006, at 16:09, Fred Kiefer wrote:
BOOL
GSObjCHasOverridden(Class baseClass, id object, SEL selector)
{
if (GSObjCIsClass(object))
{
if ((Class)object == baseClass
|| GSGetMethod((Class)object, selector, NO. YES) ==
GSGetMethod(base, selector, NO. YES))
{
return YES;
}
}
else
{
Class instanceClass = GSObjCClass(object);
if (instanceClass == baseClass
|| GSGetMethod(instanceClass, selector, YES. YES) ==
GSGetMethod(base, selector, YES. YES))
{
return YES;
}
}
return NO;
}
Thank you very much for this code. This uses some fast but GNU runtime
specific functions. I will stick with my slower method of testing until
this implementation makes it into GSobjCRuntime and we also have an
abstraction that allows similar tests with the Apple runtime.
Actually, it doesn't use ANY GNU runtime specific functions, it's
entirely runtime independent code!
It uses functions from GSObjCRuntime.h and GSObjCRuntime.m ... which are
wrappers round either GNU runtime functions or Apple runtime functions
depending on which system you build.
The equivalent GNU runtime specific code would use object_is_class()
rather than GSObjCIsClass() and would use class_get_instance_method()
and class_get_class_method() rather than GSGetMethod()
Oops, thank you for pointing this out. I should have checked in the code
before making this statement. The used functions are in the Additions of
base and would thereby be valid to be used in gui. Still I think this
function looks too serious to be thrown into a gui class as a helper. It
would confuse people like me. :-)
Cheers,
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Test fro overridden method
Could somebody please verify that this method does what I expect it to do?
I need such a test within NSDocument. Here Apple takes special care that
if somebody has implemented the old interface methods for NSDocument in
a subclass, then these methods are actually called instead of the new
interface methods.
/*
* Private helper method to check, if the method given via the selector sel
* has been overridden in the current subclass.
*/
- (BOOL)_hasOverridden: (SEL)sel
{
// The actual signature is not important as we wont call the methods.
IMP meth1;
IMP meth2;
meth1 = [self methodForSelector: sel];
meth2 = [[NSDocument class] instanceMethodForSelector: sel];
return (meth1 != meth2);
}
If the code stays that simple, I might even make a macro of it.
Cheers,
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Yen-Ju Chen schrieb: I guess this is the reason why transparency does not work in Cairo backend: cairo backend draw everything directly on xwindow. In -gui, an image is often draw on a hidden window, then composite on the destination. Because cairo backend draw directly on xwindow first, it loses the alpha value. Then when it is composited to the destination, the transparent part becomes the background of the hidden window. I have a copy of cairo backend in Etoile project: http://svn.gna.org/viewcvs/etoile/branches/yjchen/etoile_back/ It basically draw on the x11/XWindowBuffer first as what art backend does. Therefore, it keeps the alpha value for composition. The modification is very little. You can check out README.etoile_back. A simple diff is sufficient to see the difference of source code. There are some minor issues here and there, though. Great, this resolves the transparency issue! I added your changes for this to the official GNUstep cairo backend. I did not take over your changes to x11, on which I need to take another look. You also have a change to add the freetype2 libraries and settings to the configuration. This should not be needed if cairo is configured correctly. Could you please type in pkg-config --libs cairo at a command prompt to see if this includes freetype or not? I also added you endianess change, hope I did get it correct. As you have the unbuffered code commented out yourself, I did not take it over. And the NSClipView change is clearly a hack. We need to resolve the actual issue behind it. With images now drawn transparent you will see that many images get flipped. I will have to take another look into the horrible compositeGState:... method to sort this out. If we are lucky the clip view issue will get resolved by that as well. The next thing to investigate will than be the text drawing, as the metrics seem to be wrong here. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal to deprecate Xlib backend
Gregory John Casamento schrieb: Richard, The reasons behind the move to Cairo are as follows: 1) Cairo is being used by a number of other projects. It is very stable and well maintained. 2) Cairo has been ported to a number of other operating systems, including windows and has a large number of output targets. This way, Cairo would do much of the heavy lifting for us with regards to getting things to render acceptably on other platforms. I agree with what Richard is saying here as well. Looks like everybody agrees with Richard:-) So let's focus on the cairo backend for now and when it is finished deprecate xlib and art, but let them stick around for some time afterwards. Things to be done for the cairo backend: - Test with the latest cairo release. - Sort out copying from one cairo GState onto itself. - Get transparent images working. There is more, but these I remember from the top of my head. Cheers, Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Menu Proposal
Matt Rice schrieb: On 2006-11-29 04:19:25 -0800 Christopher Armstrong [EMAIL PROTECTED] wrote: Hi all I wish to make a proposal regarding NSMenu. There has been alot of debate about GNUstep's stacked menus in the past. It is clear that alot of people like GNUstep's stacked menus, but alot of people also have different ideas about how menus should be displayed. I want to propose one pragmatic solution that should make it easier to support multiple menuing paridigms. I have been looking at the code in NSMenu, and at the moment NSMenu is reponsible for creating an NSMenuView and the NSPanel object that it is housed in. As a result, this code makes the assumption that a menu is always in a separate window, and that there is only one displayed representation of a menu. It also assumes that the menu representation is drawn in the same process with an NSMenuView object. In order to support different paridigms, such as the (addmittedly broken but popular) one-menu-per-main-window on Win32/Gtk/Qt or Etoile's menu server, I believe that programmers currently need to modify NSMenu through means such as subclassing or overriding using categories. These methods are prone to breakage as they often depend on internal implementations. I am proposing that we separate the visual representation of a menu (which includes the window it is drawn in (NSMenuPanel), the view (NSMenuView) and the item cells (NSMenuItemCell)) from the abstract representation of a menu (NSMenu). I am suggesting we do this allowing people to supply an object which will receive menu update notifications (such as items being added, removed, etc.) and be responsible for coordinating the drawing of the menus and handling events. It should be different from the current use of the NSMenuRepresentation which assumes that the menu representation is a subclass of NSView. This object should implement some sort of protocol for communication between itself and NSMenu, the protocol supplying methods which inform the object of changes in the NSMenu, something like the interaction between a Model and Controller in MVC. For example, you may wish to place a menu on each of your document windows, but this breaks the current assumption that there is only one visual representation (view) of the menu. In this case, the intermediary object would sit between NSMenu and the associated set of NSMenuViews which reside in each document window. It would be responsible for receiving update messages from the NSMenu object and forwarding them to each of the NSMenuViews. These views in turn would somehow notify the NSMenu when they are clicked/selected. I think this may be a reasonably opportune time to play with the current design, as Apple have deprecated the usage of NSMenuView and NSMenuItemCell along with the -menuRepresentation property of NSMenu (according to the Cocoa docs). Before I possibly attempted to implement such a solution, I wanted to discuss it with the list as I fear this solution may be too complex where simpler solutions exist, and I know it has implications for some other areas in the AppKit (especially popup buttons). I don't wish to engage anyone in debate about the merits or disadvantages of stacked vs horizontal menus; I think this has been discussed enough on these mailing lists before. I believe we should be pragmatic and offer people a choice. It would be helpful to gain some feedback about this idea, particularly its feasibility. I think it is not too difficult to implement and I do think it is necessary if we want to be flexible in supporting different kinds of menu paridigms. Cheers Chris another thing to consider is context sensitive menus, which regardless of main menu implementation want a vertical menu i for one would like to see NSPopUpButtons cleaned up, as it is theres NSPopUpButton has a NSPopUpButtonCell has a NSMenu has a NSMenuView has a NSMenuPanel, there seems to be more code for pop-up buttons in the NSMenu* classes than NSPopUpButton* (seems like it'd be cleaner to have just a window with a matrix in NSPopUpButtonCell).. also it seems like this class has been updated sequentially to conform to apples NSMenu implementation of the day and its sort of a hodge podge of characteristics from all the different NSMenu implementations so i'm basically indifferent twords support of different menu paridigms, i definately think NSMenu* needs an audit I like the original idea, although I currently don't see to much benefit from it. Perhaps we should have the interface for the new implementation first, before we get any new code. As for the second mail on NSPopUpButton I totally seem to miss the point here. What is the problem here? I have been involved in the development of NSPopUpButtonCell, so I may be blind to the fact that the code here is hodge podge. Cheers, Fred ___ Gnustep-dev mailing list
Re: [Gnustep-cvs] r24007 - in /libs/gui/trunk: ChangeLog Source/GSDragView.m Source/NSCell.m Source/NSTableView.m
matt rice schrieb: Author: ratmice Date: Wed Nov 1 10:50:00 2006 New Revision: 24007 URL: http://svn.gna.org/viewcvs/gnustep?rev=24007view=rev Log: * Source/NSTableView.m: Add new private methods. (-mouseDown:): Reorganize and don't track cells until dragging has been ruled out. * Source/NSCell.m (trackMouse:inRect:ofView:untilMouseUp:): Handle events no longer in the queue. * Source/GSDragView.m: Change NSLog to NSDebugLLog. Hi Matt, first of all, thank you for doing all this great work in cleaning up the behaviour of NSTableView. This is a very complex class and it is so unbelievable hard to get things right there. A few comments to this specific change. - It looks like you are not using the standard GNUstep formatting rules. I must admit that I am not following them all the time, but the way you place your blanks or rather leave them out, should be adopted to the to be more readable. One space character after a colon should be used :-) - The new method _startDragOperationWithEvent: should pass on the offset for the dragging and not mix this with the start position. - In the new tracking method, we only check if the column is editable, shouldn't we use the method that checks for the cell to be editable? (BTW in this the comments are still wrong) - A bit more comments in the mouseDown: method would be helpful. This is so complex and there are so many different things we tried before, that we really need to explain what is happening and why. I still don't understand if the dragging is stealing events from the tracking or the other way around or even both may happen. You see, this are less things that are wrong, but rather stuff that needs to be clearer to guarantee that the progress you are making here will last. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r23971 - in /libs/back/trunk: ChangeLog Source/x11/XGServerWindow.m Source/x11/XIMInputServer.m
David Ayers schrieb: Fred Kiefer schrieb: Author: fredkiefer Date: Fri Oct 27 14:25:26 2006 New Revision: 23971 URL: http://svn.gna.org/viewcvs/gnustep?rev=23971view=rev Log: Small correction to adopt to base change also remove annoying warning. Modified: libs/back/trunk/ChangeLog libs/back/trunk/Source/x11/XGServerWindow.m libs/back/trunk/Source/x11/XIMInputServer.m This makes the log in XIMInputServer is multilingual in non english locale's... I still feel that GetEncodingName (or GSEncodingName, or GSNameFromEncoding()) is generally useful. Does anyone else agree? I don't have any opinion what so ever on this. :-) What I did was just to adjust the code on back to a change that was done in base some time before, without changing the affected code in back. :-( What seems odd to me is that Apple did only define a localized version of this method. Having a non-localized as well would seem more natural to me. Perhaps we should add one as a GNUstep extension? But in this code in back I would still prefer the localized output. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: exception panel userInfo browser
Hi Matt, hope I did not block you by not replying. I was away this week and gave up on reading mails while travelling some time ago. To me this patch looks great so go ahead. What could be added is translatability of the texts, but this is missing in the whole file. We need to add this at some point in time, not now. Cheers Fred Matt Rice schrieb: alright i did this stuff, and managed to get it working in an external panel, so no more exception panel resizing and ugly box hack ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: exception panel userInfo browser
Matt Rice schrieb: not sure if anyone is opposed to adding something like this... it provides a userInfo browser to the exception panel which gets shown when you click on the icon in the upper left hand corner. i find it very useful when doing key value coding stuff and you have dictionaries with arrays of dictionaries and stuff it isn't the most polished looking but it does the job. Hi Matt, the idea of the panel itself seems nice, but why do you add it via getSomePanel(). As you did not change NSReleaseAlertPanel() you wont have a benefit from this. For me it would seem easier, if you just created the panel manually without caching. This will reduce the size of your patch. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
Adam Fedor schrieb: Test results for GNUstep as of Wed Oct 18 06:34:16 EDT 2006 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to be a part of this automated testfarm, see http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F Success Compile i386-unknown-netbsdelf3.0 Wed Oct 18 03:56:28 CEST 2006 Success Compile powerpc-apple-darwin7.9.0 Wed Oct 18 03:09:24 MDT 2006 Fail Compile sparc-sun-solaris2.7 Wed Oct 18 01:21:03 EDT 2006 Success Compile x86_64-unknown-linux-gnu Wed Oct 18 04:09:57 BST 2006 Looking at the output of the failed solaris compilation I would say the the missing UNICODE_HEADERS varaible is causing this. Does anybody have an idea, what may have changed this and more importantly if the code in Makefile.postamble intalling these header would be of any real value? I would recommend to remove these lines. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fwd: Versioning/release policy proposal
I like this proposal very much, there is one area, where I see problems, but we could wait until we actually face them. This is the question, who will be willing to work on the bugfix releases? Most developers will spend their time and efforts on the new unstable release, then somebody needs to decide that some change to the unstable release is worthwhile to be ported back to the last stable release, integrate it there and make a release. The procedure itself sounds fine, but as long as nobody volunteers to actually follow it, it wont help. Any volunteers? Fred Richard Frith-Macdonald schrieb: 4. Release stability policy We advertise a 'stable' release *every* time we break backward compatibility. Doing this requires making two releases pretty much at the same time and bumping the minor version number for each. Eg. if the last release was 1.3.24 then we release 1.4.0 as 'stable' and 1.5.0 as 'unstable', each with the appropriate change in the SONAME. All releases (if any) in the 1.4 family would be bugfix releases. I suspect the vast majority of people would just use the 'unstable' releases (largely defeating the point of having 'stable' ones), but the overhead of doing a 'stable' release is very low, so I don't see why we shouldn't do it. We can make 'stable' releases be those with even subminor version numbers. 5. Standard release procedure (backward compatible with previous version) a. tag the version for release using the name_major_minor_subminor convention. b. make tarballs and installation packages c. bump the subminor version number in trunk d. put release on ftp site and publicise 5. Standard release procedure (NOT backward compatible with previous version) a. bump the minor version number and SONAME and reset the subminor number to zero b. tag the version for release as 'stable' using the name_major_minor_subminor convention. c. make tarballs and installation packages d. bump the minor version number and SONAME and reset the subminor number to zero e. tag the version for release as 'unstable' using the name_major_minor_subminor convention. f. put releases on ftp site and publicise 6. Bugfix release procedure a. if this is the first bugfix release of a package version, make a branch from the tagged release using the tag name as the branch name eg. if the release was tagged in svn as foo/tags/foo_1_2_0 then the branch is foo/branches/foo_1_2_0 b. apply bugfixes to the branch c. tag the branch as foo_1_2_0-1 d. make tarballs and installation packages e. put on ftp site and publicise NB. we only ever make 'bugfix' releases in 'stable' release families, and these are the only sort of releases we make in those families. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r23599 - in /libs/gui/trunk: ChangeLog Source/NSTableView.m
HI Matt, could you please explain this change? When writing this method I took great care to implement it the way Quentin did describe the behaviour of Cocoa in his mail from the 8th of September. Was the description wrong or just my implementation? Cheers Fred matt rice schrieb: Author: ratmice Date: Sat Sep 23 23:53:25 2006 New Revision: 23599 URL: http://svn.gna.org/viewcvs/gnustep?rev=23599view=rev Log: * Source/NSTableView.m (_isCellEditableColumn:row:): Allow delegate to limit editablility of editable columns. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/NSTableView.m ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: question to backend/gui guru...
I would agree with Adams answer, go for a dummy graphics backend. Perhaps we could even rewrite the back makefile to have gsc usable as such? As I understand it you will need a window, or rather event server based on SDL. Put that into back and perhaps somebody may later add code to make this a full backend. I love to see huge things being build up by people only requiring small parts of it. Fred Adam Fedor schrieb: As long as you don't call [NSApplication sharedApplication] (or, in fact, initialize NSApplication at all), you can use classes in the gui without a backend. But you have to be careful not to use any classes/methods that cause any display or drawing. Also you could create a dummy backend (something like gsc in gnustep-back). That does nothing or does what you want it (see documentation for GSDisplayServer and NSGraphicsContext). On Sep 10, 2006, at 2:09 PM, [EMAIL PROTECTED] wrote: Gregory, Thanks for your answer. I dont want to make a 'gnustep application', but an 'application using gnustep' ;-) Actually i want to make a tiny 3D game in objective C. You may see that as a training (for me) and a test of the efficiency of objective c for that kind of application. SDL is imho a good choice for a game, and gnustep is a good choice for objective C. Basically i need a simple cross-platform multimedia library, with _joystick_support_, fullscreen display, custom resolution... Gnustep cant do that, but can do many other useful things. And I'd like to write some code that might be run/resuse later on a full gnustep system, and then i have to write some NS-compatible classes. In brief I need something like a NSApplication class that does not need any NSWindow object. I could (try to) write it from scratch, but i'd prefer reuse gnustep classes if i can : they are better than anything i could make... TIA Xavier Selon Gregory John Casamento [EMAIL PROTECTED]: Xavier, You've given little information about what you're actually trying to do. Your email details how you would like to solve the issue, but doesn't clearly define what the issue is. Based on the fact that you briefly mention OpenGL, I assume you want to make a GNUstep application which displays OpenGL graphics. GNUstep has an implementation of NSOpenGLView which allows OpenGL to be directly displayed in the view. GNUstep does this by creating an OpenGL window and reparenting it to the view, thus not incurring any overhead. Is there some issue with using this? Later, GJC --Gregory Casamento - Original Message From: [EMAIL PROTECTED] To: gnustep-dev@gnu.org Sent: Sunday, September 10, 2006 11:59:00 AM Subject: question to backend/gui guru... Hello I intend to write a SDL+OpenGL application based on gnustep. I can use gnustep-base without problem, but i'd like to use some parts of gnustep-gui (event management, ...) without any graphic or window class/function. SDL dont provides any graphic function, and I dont want to write à full SDL+OpenGL backend !! I dont want to rewrite gnustep in any way. I only want to compile the classes i need in gnustep-gui. But I understand I would have to write a partial backend, a SDL-server, like win32 or X11 ones (i hope i can do that...) I wonder if it would be easy (or at least feasible) to split/compile gnustep-back and gnustep-gui in two parts : server and system on one side, and graphics and gui on the other side. (and then use only (SDL-)server/system) Any informations about dependances between classes will be welcome ! Its quite obscur for me... :o\ In brief : feasible or not ? thnks in advance ! ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [NSButton sendActionOn:]
In reply to this bug report I have finally changed NSControl's method
mouseDown: to no longer fiddle with the action mask of the cell and also
not to capture the mouse any more. The later is needed to allow the cell
to start any modal windows.
I regard this as a rather deep change and have tested it for some time
now, still there may be special cases that I have overlooked. I would
like to ask all developers of GNUstep to test their gui applications, if
the still function as expected. I am sure it will be fairly simple to
resolve any remaining issues.
Cheers
Fred
Marc Brünink schrieb:
[NSButton sendActionOn:] does not work at all. This is because of
if ([_cell isContinuous])
{
oldActionMask = [_cell sendActionOn: NSPeriodicMask];
}
else
{
oldActionMask = [_cell sendActionOn: 0];
}
in [NSControl mouseDown:]. If I comment these lines out and kill the
last 3 lines of the method
//[_cell sendActionOn: oldActionMask];
// if (mouseUp)
// [self sendAction: [self action] to: [self target]];
everything works as expected. Why does NSControl just ignore my settings
and resets everything back to 0 before handling the event?
Please send me a CC.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: How to indicate API version properly (taking in account next release)?
Hi Quentin, I may not understand your problem correctly, but if you only want to make sure that the new functionality is available and you know that it was not available at a certain release version of GNUstep, but will be in what ever version comes next. Then it should be possible to just use the next possible micro number, independent of the fact if this number ever gets used. What ever release number will be chosen, it will be higher than the one you check for. Cheers Fred Quentin Mathé schrieb: I would like to know whether there is any way to indicate the next GNUstep release for GS_API_VERSION macro. For example, when you add a new method, it will be available only with the next release, but at the time you commit header/implementation update related you cannot know for sure what will be the next version number of the library. The maintener can decide to do either a minor release or a major release then the release number will vary. If the latest release is related to the macro: #if GS_API_VERSION(011300,GS_API_LATEST) The next release could be either 1.0, 0.12 or 0.11.4… Here is the prGNUoblem :-) That means you have to guess the next release number (where your new features will be introduced). Some kind of macro like GS_NEXT_RELEASE associated with a script run to replace at release time could prove to be useful. #if GS_API_VERSION(GS_NEXT_RELEASE, GS_API_LATEST) Any already available solutions or suggestions? By the way, it's not easy to find the macros GS_API_VERSION and OS_API_VERSION in the documentation because there is no links to them in the -base Intro section (where API versioning is introduced). Some examples in the documentation would be useful too. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
NSController and subclasses
I am still trying to get the Books application to compile with GNUstep. Amongst many other things that are still missing, we also need NSController and the two subclasses NSObjectController and NSArrayController. All these classes have been added to AppKit in MacOSX 10.3 and extended in 10.4. GNUstep still doesn't have them. These classes need key-value coding and observing to be fully functional and NSObjectController also uses some classes from the coredata framework. This lets me doubt, if we really should put these classes into gui. What about having a coredata framework in the GNUstep SVN and add these classes as an extension to that? Any opinions? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GCC 4.1 problem?
While trying to reproduce a problem with the xlib backend on my newly installed SuSE 10.1 system, I found that menus get only partially displayed, also the knob in horizontal sliders was missing. With this few hints I set off to drag down the bug behind it. It took my quite some time, but now I think I found it. The affine transform used to compute the state transformation suddenly had a NaN component as TY. How could this ever happen? I put in a few NSLog statements into [NSAffineTransform scaleXBy:YBy:] and the problem was gone. For me this proves that there is a gcc problem (gcc (GCC) 4.1.0 (SUSE Linux)), but how to deal with it? The simplest thing is surely to switch off some optimisation for this file. As far as I remember, there is even a switch for this in GNUmake. The danger is that the same problem may show up in other places as well. How could we prepare for that? What I don't understand is why this problem doesn't show up for other backend and why I am the first one affected? Many of you should already use gcc 4.1, what is so special about the SuSE version? Perhaps nobody ever uses the xlib backend any more? Could those using gcc 4.1 on a 32 bit Intel machine try at least once? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Fontconfig in GNUstep
Quentin Mathé wrote: Le 15 mai 06 à 04:06, BALATON Zoltan a écrit : - CGFont: Enough to get fonts from Fontconfig for CGContextSelectFont Is there any code to support Fontconfig in GNUstep right now ? To answer just this question: Yes! For the xlib backend it is in GSXftFontInfo.m and for the cairo backend in CairoFontEnumerator.m. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Nib compatibility progress
Hi Gregory, that is a great step for GNustep. Thank you for achiving it. Fred Gregory John Casamento wrote: I just wanted to post some screenshots here of progress thusfar on nib compatibility efforts. Here is a gui done in IB, the GNUstep one is running in a live app and the Cocoa one is in IB. This is using a nib file called busybox.nib which is checked in on the NibCompatibility branch along with all of the other changes. GNUstep appears to be reading nibs quite well at this point. I am considering merging this on Saturday or Sunday. I have tested it extensively and have kept up to date with all of the changes on the trunk. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r22892 - in /libs/gui/trunk: ChangeLog Documentation/GuiUser/DefaultsSummary.gsdoc Source/GSDragView.m Source/NSApplication.m
Tim McIntosh wrote: On May 11, 2006, at 5:41 PM, Fred Kiefer wrote: Quentin Mathé wrote: I think it could be better to phrase the key 'GSDontShowAppIcon' in an affirmative way, just 'GSShowAppIcon'. It seems to be the usual rule with boolean choice in UI and API. But then it was not the only reason, it is also easier to check that way, as the default, when the option is no specified at all, should be to show the icon. This also means that when you want to show the icon, you don't have to provide a setting, an option is only needed to switch it off. That's why I did stick with the way Saso decided to do it. How about something like one of the following? GSHideAppIcon GSDisableAppIcon GSInhibitAppIcon GSSuppressAppIcon OK, I did selecte GSSuppressAppIcon out of this list. It really is the better name. Thanks Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r22850 - in /libs/gui/branches/NibCompatibility: ChangeLog Source/NSLayoutManager.m Source/NSTextContainer.m Source/NSTextView.m
Hi Gregory, when seeing your regular updates to the NIB compatibiltiy branch, I am wondering, when you will decide that it is time to merge this branch back into the main trunk. In my opinion the time will be right, when this branch is stable enough to not break other GNUstep code. It does not require that all GNUstep GUI classes get correctly loaded and stored. People are more likely to help out with implementing special cases for keyed coding when the code is visible. Cheers Fred Gregory Casamento wrote: Author: gcasa Date: Wed May 3 07:00:56 2006 New Revision: 22850 URL: http://svn.gna.org/viewcvs/gnustep?rev=22850view=rev Log: Improved keyed archiving for nib support. Modified: libs/gui/branches/NibCompatibility/ChangeLog libs/gui/branches/NibCompatibility/Source/NSLayoutManager.m libs/gui/branches/NibCompatibility/Source/NSTextContainer.m libs/gui/branches/NibCompatibility/Source/NSTextView.m ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r22843 - in /libs/gui/trunk: ChangeLog Source/NSMenu.m
Hi Richard, I just checked this change and found that you have hard coded the value of NSCommandKeyMask as the modifier. If I see correctly, the modifier could be changed on the menu item, so it looks better to use [item keyEquivalentModifierMask]. Most likely this error was already in the old code and you just moved it around. Cheers Fred Richard Frith-Macdonald wrote: Author: rfm Date: Sun Apr 30 22:29:30 2006 New Revision: 22843 URL: http://svn.gna.org/viewcvs/gnustep?rev=22843view=rev Log: Fix longstanding bug in key equivalents handling which was previously masked by a bug in NSApplication. Modified: libs/gui/trunk/ChangeLog libs/gui/trunk/Source/NSMenu.m ___ Gnustep-cvs mailing list Gnustep-cvs@gna.org https://mail.gna.org/listinfo/gnustep-cvs ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] Minor fix in NSWindowController
Quentin Mathé wrote: I have done new tests with other applications today like Notebook, Ink and ToolbarExample (which is document based). With the two last ones, the result is a segmentation fault on a document window close :-/. It's retain/release issue. Now I think that's the extra 'retain' I removed in NSWindowController is just covering another bug (may be more). I would say it's probably related to - isReleasedWhenClosed value not properly ignored everywhere when NSWindowController is used in NSDocument architecture context. What's your take on this ? Most likely this segmentation fault was the reason I introduced the retain call in the first place. Now with the new explanation from Apple we need to change some code. I would insist, that what ever you change it should not break existing applications. Apart from that feel free to bring our code closer to what should be done. From my point of view the whole code in [NSWindowController _windowWillClose:] could go away, but I am not deep enough into this any more. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] Minor fix in NSWindowController
Hi Quentin, Quentin Mathé wrote: Le 28 mars 06 à 00:57, Fred Kiefer a écrit : I am rather unsure about this patch.I don't quite remember, who did put in these commetn lines on retaining the window, but I would expect that there were reasons for it at that time. Still they may have been the now redundant solution of an already resolved problem. I think you wrote the comments, here is the ChangeLog entry which introduced this 'retain' line : 2003-08-30 Fred Kiefer [EMAIL PROTECTED] * Source/NSWindowController.m Changed [setWindow:] to manage the notification connection to the window. [initWithWindow:], [dealloc] and [_windowWillClose:] now use [setWindow:]. [setDocument:] now no longer retains the document, as this is already retaining the window controller. Simplified [loadWindow] by using the method [windowNibPath]. Oops, I must admit that I don't have any memory of this change any more. If your new code works for document based applications as well as for others, then it should be fine to submit it. Could you please test with Ink as well? The previous comment makes a bit more sense (unlike the most recent one) : /* * If the window is set to isReleasedWhenClosed, it will release * itself, so nil out our reference so we don't release it again * * Apple's implementation doesn't seem to deal with this case, and * crashes if isReleaseWhenClosed is set. */ */ _window = nil; However I think it's not needed because there is no 'retain' or 'release' calls on _window in NSWindowController.m (not even in - dealloc method). This is not completly true, the retaining and releasing of _window gets done in setWindow:. This seems to have been the core of that patch, to move all code which changes the _window ivar into one place. This change was related to the bug report #4840, which was about a similar problem as the one you are facing now. If I only could remember... Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Italian and lojban Localizable.strings
Hi Maurizio, don't get us wrong, we all started to learn lojban right after getting your mail with the GNUstep translations. This is what is keeping us from submitting your patch. As soon as the whole GNUstep mailing list has been converted to lojban we will resume working and your patch will be the first one to submit. :-) In reality we are just waiting for Adam Fedor to state, if this patch could be included without a writen copyright assignment or if we have to wait for one. Sorry, this is the process. But we should have told you about it. And thank you for the great work you did! Fred Maurizio Boriani wrote: On 2006-03-27 15:46:19 +0200 Maurizio Boriani [EMAIL PROTECTED] wrote: Hi, While working on gui theme integration fix and write a bit about Localizable strings. noman want's to put then in svn ? :) no comments ? are so orrible :) bye ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Italian and lojban Localizable.strings
OK, I submitted both files, now back to learning lojban. :-) Cheers Fred Maurizio Boriani wrote: On 2006-03-29 19:29:48 +0200 Fred Kiefer [EMAIL PROTECTED] wrote: Hi Maurizio, don't get us wrong, we all started to learn lojban right after getting your mail with the GNUstep translations. This is what is keeping us from submitting your patch. As soon as the whole GNUstep mailing list has been converted to lojban we will resume working and your patch will be the first one to submit. :-) it's a really simple (and very regular) language :)) fast to learn :)) In reality we are just waiting for Adam Fedor to state, if this patch could be included without a writen copyright assignment or if we have to wait for one. Sorry, this is the process. But we should have told you about it. already working on gui theme implementation, so returned and confirmed (by FSF) the assignment too :) And thank you for the great work you did! only a dummy and fast work (done in a spare time from spare time used for gui theme implementation :)) ) bye ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] Minor fix in NSWindowController
Hi Quentin, I am rather unsure about this patch.I don't quite remember, who did put in these commetn lines on retaining the window, but I would expect that there were reasons for it at that time. Still they may have been the now redundant solution of an already resolved problem. Did you do sufficent tests with your patch? As there aren't that many document based applications for GNUstep, we really shoud try all of them, before releasing the patch. Cheers Fred Quentin Mathé wrote: Here is a little patch to have proper window controller deallocation when used in document architecture context. It is based on an initial bug report by Saso Kiselkov. I'm going to briefly summarize Cocoa documentation… When you are using a window controller within the document achitecture context (NSDocument + NSDocumentController), - -releasedWhenClosed value isn't taken in account : when a window is closed, the window is always released by the window controller, itself released by the document object. That's not true for a window controller used alone. To enter in the details, in our case, the current NSWindowController code includes a dubious retain call on its window ivar (within _windowWillClose: private method). This prevents the window to be correctly deallocated unlike its window controller. The -retain call currently presents code is unbalanced, that results in a memory leak and sometimes in a segmentation fault. For example… You decide to use a toolbar with your document window and the document object plays the role of the toolbar delegate. When the document window is closed, the window controller and the document object are released, but the document window is not (and its toolbar neither). The next time you are going to open or create an identical document, a new document window will be created with a fresh toolbar. When you are going to manipulate this toolbar, it will try to propagate its state to other toolbars still in use with the same identifier. At this moment, the undeallocated toolbar will try to ask its delegate for items, but the delegate (document object) has already been deallocated, this invalid pointer access will then trigger a segmentation fault. The fix just consists to remove the -retain call, then everything is properly deallocated on document window closing. Since I don't really understand the explanation in the comment related to the offending line), I'm perhaps missing an important detail in with this patch, yet I have experienced no issue in my tests with this fix. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Missing class in gui.
Sorry, this was my fault. When submitting the patch for NSStepperCell this other change went through unnoticed. Thank you for fixing it. I will now submit these files although they are still not complete, but otherwise I may produce the same problem once more. Cheers Fred Gregory John Casamento wrote: I removed references to NSSearchField.m and NSSearchFieldCell.m since they don't current exist in the repo, once they are checked in please add them back into GNUmakefile. - Original Message From: Gregory John Casamento [EMAIL PROTECTED] To: GNUstep Developers gnustep-dev@gnu.org Sent: Thursday, March 23, 2006 9:07:31 PM Subject: Missing class in gui. Compiling file NSSavePanel.m ... make[2]: *** No rule to make target `shared_debug_obj/NSSearchField.o', needed by `shared_debug_obj/libgnustep-gui_d.so.0.10.3'. Stop. make[1]: *** [libgnustep-gui.all.library.variables] Error 2 make[1]: Leaving directory `/home/heron/Development/gnustep/core/gui/Source' make: *** [internal-all] Error 2 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: GNUstep Base 1.12.0
Adam Fedor wrote: On Mar 14, 2006, at 3:11 PM, Fred Kiefer wrote: Adam Fedor wrote: The GNUstep Base Library, version 1.12.0, is now available. After a SVN update and a rebuild of make and base, I get the follwoing error message when rebuilding gui (make distclean; ./configure; make; make install): Creating GSspell.service/Resources/Info-gnustep.plist... ././shared_obj/make_services: error while loading shared libraries: libgnustep-base.so.1.12: cannot open shared object file: No such file or directory I don't really have any idea. Perhaps a stale link, but I think that would clear up after a while. True, now the problem is gone again. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo as common graphics context
Hi Stefan, Stefan Urbanek wrote: On 15/03/06, Adam Fedor [EMAIL PROTECTED] wrote: On 2006-03-15 07:53:12 -0700 Stefan Urbanek [EMAIL PROTECTED] wrote: Looks like all necessary code is already in GNUstep, it is just a matter of rewiring it. But well ... I do not see much into the internals... Oh yes, actually doing the work - well that's the hard part :-) Excuse me, but I take this from you as a little offence with the meaning:do not talk, just code. Following text is not going to be only about the issue, but about general attitude on this list. This attitude is repeating on this list again and again... I think you mail has already been answered by Richard most appropriatly. There was a misunderstanding and surely no offence. When I do answer to your mail it is not about that, but because I should have answered to your mails in the first place. It looks like I am currently the only GNUstep developer working on back and the interaction between back and gui and also specifically on the cairo backend. As Adam already stated some of your ideas are quite interesting and it would be worthwhile to extend GNUstep in that direction. But this will only happen if somebody takes the time to do this. It is not, as your mail may suggest, that Adam as the project lead could just tell some available resource to start working on that. There is nobody available at the moment and even then it would be up to that person to decide itself, what task to work on. Why did I not reply to your mails yesterday and the day before? Because then you would have expected me to actually work on this problem. All that new graphic stuff that Apple did for 10.4 is surely interesting and it would be great to have it in GNUstep as well and cairo may be a way to get there, but somebody has to implement all that. I already have to many open ends in GNUstep development, which I need to finish off first. It surely is not your fault, but currently GNUstep dearly requires developers working on the core libraries. Just look at the amount of changes done this year on gui. In the first three months it was less than on any of the first month of the previous year. Discussions and ideas are important, we all agree on that, but coding also is. And at the moment we don't have enough of the later. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ANN: GNUstep Base 1.12.0
Adam Fedor wrote: The GNUstep Base Library, version 1.12.0, is now available. After a SVN update and a rebuild of make and base, I get the follwoing error message when rebuilding gui (make distclean; ./configure; make; make install): Creating GSspell.service/Resources/Info-gnustep.plist... ././shared_obj/make_services: error while loading shared libraries: libgnustep-base.so.1.12: cannot open shared object file: No such file or directory make[2]: *** [GSspell.service/Resources/Info-gnustep.plist] Fehler 1 make[1]: *** [GSspell.all.service.variables] Fehler 2 make[1]: Leaving directory `/usr/src/svn-gnustep/gnustep/devmodules/core/gui/Tools' make: *** [internal-all] Fehler 2 Any idea, where this comes from and how to work around? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Source code move to SVN
Andy Ruder wrote: Gregory and I have been working together to figure out a problem with the svn repos. We have discovered that several hundred of the files in CVS have been added without the -kb flag (binary files). We are working to correct this problem, and I think I have made a patch to cvs2svn that will mostly correct the conversion issues, but I fear a reimport may be needed. If you do a reimport, could you please make sure to preserve the changes I already made inside of SVN? It would be a shame if my changes would be the victim of the initial SVN problems. Please remember I was the one that warned that some smaller problems are very likely to pop up in the first two weeks and that we should not be using SVN without a test phase. This was voted down, but now I seem to be the only one actually using SVN :-) BTW, will we have mails for SVN code changes again? It was a rather nice feature just to see if an update was worthwhile or not. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
Hi Tim, thank you for this long explaination. You did convince me, I am now all in favour for your patch. Your patch seems to make scenarios possible, that didn't work before. But this is not my area of expertice, perhaps Adam and Richard have something to say here? Fred Tim McIntosh wrote: Sorry for the confusion. The specific case that I want to work is as follows: I have a machine running GNUstep (call it 'localhost'). I log into this machine from another non-GNUstep machine (call it 'remotehost') using 'Xnest' (display :1) to connect to the xdm on 'localhost'. Thus, DISPLAY is 'remotehost:1.0' and the GNUstep processes are running on 'localhost'. This sort of works without the patch. The initial processes that are launched _without_ the '-NSHost' argument will correctly display on 'remotehost:1.0', while printing the warning NOTE: Only one display per host fully supported. However, the 'NSHost' default will be (incorrectly) set to 'remotehost' by the code I've proposed deleting. As I understand it, this default causes the programs to look for 'gdnc', 'gpbs', etc. on 'remotehost', instead of 'localhost', where they are actually running. The problem gets worse when one of those initial processes (e.g. GWorkspace) launches another GNUstep application via the NSWorkspace methods. Since the parent process has the 'NSHost' default set, the new process will be launched with the '-NSHost' argument (see NSWorkspace.m). When the -NSHost argument is specified, the code in the patched method (_initXContext) ignores the DISPLAY settings. Thus, the launched applications will use 'remotehost:0.0' for the display. This leads to some surprising results when 'remotehost:0.0' is a valid display. From looking at the code, I think you would also see a similar problem if you attempted to use display :1 (or any nonzero display) on 'localhost', though I haven't tried this. I think it makes sense for the '-NSHost' argument to override the DISPLAY setting, as it does today. I think the problem is the assumption that the 'NSHost' default should be set according to DISPLAY if -NSHost was not explicitly specified. As I see it, the '- NSHost' argument says that I want to connect to a remote GNUstep session. If I don't specify -NSHost, I'm saying I want to run GNUstep on the local host and display according to the DISPLAY setting. I realize that this is slightly less convenient in the case where you want to use a remote GNUstep session on 'remotehost:0.0' and would like to rely on the DISPLAY setting, but I'd rather have more control over the display. Having to specify the -NSHost argument seems reasonable, especially considering that you had to do this under OPENSTEP and you'd have to do it anyway if you weren't using X11. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
Hi Tim, I read through your mail and your patch, but still don't quite get the issue you have. It is a know problem that GNUstep will complain about multiple displays and it even may not work fully correctly in that case, but what is causing you problems? What value are you using for DISPLAY? :0.3 or :1.0 or localhost:1.0? And in what way does it harm your application that NSHost gets automatically set? What value does it get set to? I would expect that having NSHost set to something like localhost would result in the same behaviour as not having it set at all. If this is not the case, we need to look into that. I am not sure, if your solution, forcing people to set two environment variable to matching values, is a great idea. It most likely will result in additional problems. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Graceful termination again
Roman Belenov wrote: 1) How to get a list of all running GNUstep applications ? launchedApplications seems to return only the list of apps launched from the current one. For now I just use a list of message ports obtained by examining corresponding subdirectory and treat everythying as a proxy for application. We really should get [NSWorkspace launchedApplications] working. Some years ago I suggested a solution for this involving some extensisons to gdomap. Now with gdomap being used less often we will need a more general way to implement it. Perhaps there is the possibility to extend NSPortnameServer (or rather its subclasses) to return a list of all known ports. The NSWorkspace method would then only need to filter out the no longer working ports and restict the returned list to the ones representing applications. Richard, do you like that concept and would you be willing to implement the base part of it? More or less it would be an official implementation of what Roman is doing anyway. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 06/01/08 17:48:34 Modified files: core/gui : ChangeLog core/gui/Source: NSTableView.m Log message: Intercell spacing change for NSTableView. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2642tr2=1.2643r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSTableView.m.diff?tr1=1.120tr2=1.121r1=textr2=text
[Gnustep-cvs] gnustep/core/base ChangeLog Source/NSPropertyLi...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 06/01/07 00:52:20 Modified files: core/base : ChangeLog core/base/Source: NSPropertyList.m Log message: Improve binary property list creation. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2690tr2=1.2691r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/base/Source/NSPropertyList.m.diff?tr1=1.37tr2=1.38r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSSliderCell.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 06/01/04 12:41:05 Modified files: core/gui : ChangeLog core/gui/Source: NSSliderCell.m Log message: Protect against knob image being nil. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2641tr2=1.2642r1=textr2=text http://cvs.savannah.gnu.org/viewcvs/gnustep/gnustep/core/gui/Source/NSSliderCell.m.diff?tr1=1.35tr2=1.36r1=textr2=text
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Hi Matt, matt rice wrote: Log message: * Source/NSTableView.m (-mouseDown:): Copy the selected cell before tracking mouse, add comment. (patch previously reverted 2005-05-30) (-mouseDown:): Check for pointer equality in addition to isEqual: which doesn't work with nil. (fix for bug #15316) did you test this new code with GNUmail and Gworkspace? I had to revert the copying the last time because of problems with these two applications. I agree fully on cell copying, but we need to asure that it has no negative effects on these widely used applications. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Enrico Sersale wrote: On 2005-12-31 17:54:35 +0200 Fred Kiefer [EMAIL PROTECTED] wrote: matt rice wrote: Log message: * Source/NSTableView.m (-mouseDown:): Copy the selected cell before tracking mouse, add comment. (patch previously reverted 2005-05-30) (-mouseDown:): Check for pointer equality in addition to isEqual: which doesn't work with nil. (fix for bug #15316) did you test this new code with GNUmail and Gworkspace? I had to revert the copying the last time because of problems with these two applications. I agree fully on cell copying, but we need to asure that it has no negative effects on these widely used applications. It seems that both the apps have no problems. Great to hear. Sorry for asking at all. I did only see your previous mail on the subject after sending mine :-( I had to catch up with a bigger backlog of mails and I tend to read the CVS changes first. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: nib2gmodel on Debian GNU/Linux
Adam Fedor [EMAIL PROTECTED] wrote: If you are using Cocoa and your nibs are in the newer XML format, it might be possible for GNUstep to read them directly. This is not a complete project so I would expect some troubles there as well. Effetivelly. The files I downloaded contains directories named xxx.nib. These directories contain three files: - classes.nib (long ASCII) - info.nib (short XML) - objects.nib (data) The NIB files that GNUstep is (partly) supporting are keyed encoded (XML format or binary), but these files come from the old direct encoded format. This means that you will need somebody with access to an OpenStep or Cocoa machine to convert the NIB files for you. I remember that years ago somebody offert this as a service on his Apple machine. Perhaps it is best to ask on the GNUstep discussion mailing list. I am very sure you will find somebody to do the nib2gmodel conversion for you. Cheers Fred -- GMX DSL-Flatrate 1 Jahr kostenlos* + WLAN-Router ab 0,- Euro* Bis 31.12.2005 einsteigen! Infos unter: http://www.gmx.net/de/go/dsl ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/back ChangeLog Source/art/ARTConte...
Adam Fedor wrote:
CVSROOT: /cvsroot/gnustep
Module name: gnustep
Branch:
Changes by: Adam Fedor [EMAIL PROTECTED] 05/12/20 20:36:59
Modified files:
core/back : ChangeLog
core/back/Source/art: ARTContext.m
core/back/Source/x11: XGServer.m
core/back/Source/xdps: NSDPSContext.m
Log message:
* Source/art/ARTContext.m ([ARTContext -beep]): Respect user setting
of bell volume.
* Source/x11/XGServe.m: Idem.
Hi Adam,
I am surprised that you had to change all these places. Judging from the
code in NSGraphicsContext.m,
/** Play the System Beep */
- (void) NSBeep
{
[GSCurrentServer() beep];
}
I would expect that it is the obligation of the display server, not the
display context to handle the beep. From this reasoning I would call the
art method totally obsolete, as it will never be called and the one in
NSDPSContext a duplicate, as it copies code from the super class
implementation (although optimised).
Looks to me like this is one of the places in GNUstep, where the origin
of the code goes too far back to be easily touched any more. Even by
you, who probably wrote most of it :-)
Cheers
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/back ChangeLog Source/x11/XGServer...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/12/10 17:41:06 Modified files: core/back : ChangeLog core/back/Source/x11: XGServerWindow.m Log message: Use UTF8 window title for X where possible. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.400tr2=1.401r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/x11/XGServerWindow.m.diff?tr1=1.55tr2=1.56r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTabView.m S...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/11/29 00:16:10 Modified files: core/gui : ChangeLog core/gui/Source: NSTabView.m NSTextField.m Log message: GUI patches by Andreas Höschler. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2627tr2=1.2628r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSTabView.m.diff?tr1=1.49tr2=1.50r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSTextField.m.diff?tr1=1.62tr2=1.63r1=textr2=text
Re: GNUstep ROADMAP
Hi Gregory, Gregory John Casamento wrote: --- Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento wrote: If you are a maintainer, please make any changes for your section that you deem appropriate. as far as I know we currently don't have a maintainer for GUI, so we all should comment on that part. And some of us already did in previous mail exchanges. I remember two points from my mail (yes one tends to remember ones own entries best) which are not addressed by your list. One being the stable memory layout of the GUI classes. Why would we call a release 1.0 if it does not garranty some sort of stable interface? Could you elaborate on this point? Sorry, I should have been more explicit. I was refering to missing or obsolete ivars for the GUI classes. Have a look at NSResponder, here you find a bunch of boolean variables, most of them only used in the NSView subclasses. We could decide now to move these ivars to NSView, but we should not do so after release 1.0. On the other hand are we missing quite some ivars for NSCell, if we want to get fully compatible with Cocoa. Richard posted some ideas on how we could still extend classes after the 1.0 relase, but we need to prepare them now. The other being the problems with the matrix classes. If we want a complete coding here, we will probably have to wait for GNUstep GUI 1.0 for another year, or even more. Is this what you want? No. I would rather have a 1.0 release sooner rather than later. All multiple cell classes are only partial usable, they work for simple exmaples, but when put in general use they seem to fail. Could you go ahead and add details of what needs to be done to the cell classes to the Roadmap where you think it needs to be? I don't have Wiki write access, yes, I should just register. The problem itself is obvious, just by looking into the bug database, or following the mailing list. The classes NSMatrix, NSBrowser, NSTableView and NSOutlineView are usable, but not much more. We may be able to improve them, but I don't see a complete implementation for the 1.0 release. Removing classes? Which classes are you talking about. At least after Richards question you should have given an example. There are classes in GUI that have currently no actual benefit, like NSMovie, but we will surely implement them later on. Do you want to remove these classes? I'm only advocating removal of shell classes which currently exist as placeholders for things that are entirely unimplemented. I'm not saying that we should remove a class that has an incomplete implementation. In my view, if we're not going to make a class somewhat usable (i.e. even a skeletal/simply implementation), then we should remove it until the next release. This is because it's confusing to the developer who ports an app. If the header is there, I'll naturally assume that the class is available. If it's not, then I know it's yet to be implemented. NSMovieView and NSMovie, as you pointed out, are excellent examples of this. I'm not sure if anyone is going to have the time to do it before we want to make a 1.0 release. I had a similar discussion with Nicola almost five years ago. At that time it was about what unimplemened methods should do, raise a condiontion or silently ignore the fact that there is no code. We came to the conclusion that outputting a warning would be best. When we remove these classes any application that refers to object of these classes, even if they are not critical to the overall behaviour of the application, wont compile with GNUstep. If we leave the classes in, but put warning messages (printed only once) into the empty methods, these application work, with minimal functionality missing. That's why I used NSMovie as an example. You surely wont be able to implement a movie player with GNUstep at the time being, but if your application sport only a gimmick movie in the about box, it should still work with GNUstep, without displaying the movie of course. Or what if I wanted to contribute a simple minded implementation of NSearchField in the next weeks? Would we drop that class again, as the implementation would not be complete? So long as the class works on some level, it's okay to leave it in. I'm referring mainly to those classes which are in GNUstep which are simply shells awaiting some kind of implementation and do not work at all. works on some level, what if I think that not raising an exception is already some sort of working? When I started with GNUstep, most of the GUI classes where empty declarations, which needed filling out and that was what I did. If we would have removed all classes without implementation at that time, GNUstep would still be rather empty. I really would prefer warning messages at runtime from removing classes as a whole. Will it be a problem that some applications will compile, but later fail to run correctly? I don't think so, as long as we
Re: GNUstep ROADMAP
Hi Gregory, Gregory John Casamento wrote: If you are a maintainer, please make any changes for your section that you deem appropriate. as far as I know we currently don't have a maintainer for GUI, so we all should comment on that part. And some of us already did in previous mail exchanges. I remember two points from my mail (yes one tends to remember ones own entries best) which are not addressed by your list. One being the stable memory layout of the GUI classes. Why would we call a release 1.0 if it does not garranty some sort of stable interface? The other being the problems with the matrix classes. If we want a complete coding here, we will probably have to wait for GNUstep GUI 1.0 for another year, or even more. Is this what you want? All multiple cell classes are only partial usable, they work for simple exmaples, but when put in general use they seem to fail. GNUstep 1.0 1. it says current base/make/back ... but what about ms-windows support ... I'm guessing we want base/make/back fixes/improvements for windows as it's not nearly such a good state as unix-style systems. I'm not sure this is a 1.1 issue rather than 1.0 This also ignores the fact that window manager interaction (focus in particular) is undoubtedly the biggest problem with current apps, and is a backend issue at least as much as a gui issue. Here I agree with Richard, we need to solve the focus problem, even if it may require big changes in back. We should not freeze back for the 1.0 release, rather have all interfaces between gui and back investigate if these are suited for what we may need later on. 2. gui seems wildly ambitious (complete coding on all existing classes) . By this I simply mean that we should try to bring all of the classes currently in GNUstep GUI up to spec. Many of them are already there. I am *not* saying that we should implement all of the Cocoa classes, but only that we should finish the classes which have already been started in the repository. You may also notice that I say that we should remove those classes which will likely never get finished or will not be finished for the 1.0. Is this still too ambitious?? Removing classes? Which classes are you talking about. At least after Richards question you should have given an example. There are classes in GUI that have currently no actual benefit, like NSMovie, but we will surely implement them later on. Do you want to remove these classes? Or what if I wanted to contribute a simple minded implementation of NSearchField in the next weeks? Would we drop that class again, as the implementation would not be complete? You surely remember that missing this class was one of the points that made the porting of Book impossible about one and a half year ago. For this application even a very simple implementation would have been sufficent. Taking your words litarally we would need to decide to remove NSCell, as I don't see anybody implementing the setEntryType: method for the 1.0 release. Having a roadmap again is great, but the current state of it does not help much. To end a bit more constructive let me list the bug numbers of bugs that I think should be resolved for 1.0: #5871 (Will require a complete redesign of cursor rect handling) #6152 (Focus problem) #10825 (I have a patch for this, but need to test with all different backends) #10856 (With this bug I have a very bad feeling, it may be a lot worse than it looks like) There are of course a lot of other important bug reports, but these I would call severe. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSSliderCell....
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/11/21 13:33:59 Modified files: core/gui : ChangeLog core/gui/Source: NSSliderCell.m NSTextField.m Log message: Two small patches from the current mailing list discussion. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2599tr2=1.2600r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSSliderCell.m.diff?tr1=1.34tr2=1.35r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSTextField.m.diff?tr1=1.60tr2=1.61r1=textr2=text
[Gnustep-cvs] gnustep/core/back ChangeLog Source/x11/XGServer...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/11/18 17:53:53 Modified files: core/back : ChangeLog core/back/Source/x11: XGServerWindow.m Log message: Don't user NET WM icon on Window Maker. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.397tr2=1.398r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/x11/XGServerWindow.m.diff?tr1=1.54tr2=1.55r1=textr2=text
Re: Possible future Gorm name change
Gregory John Casamento wrote: P.S. I personally like the Gorm name, but I wanted to poll the community before the next major version of the application comes out. I actually like the old name as well. Do we really need to change it? There will always be people complaining about every possible name. Did somebody come up with a reall argument against GORM? Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSButtonCell doc [OpenStep release]
Fabien VALLON wrote: - -performClick: is not implemented This aint no problem, deviating from the OpenStep/Apple specification we introduced the method performClickWithFrame:inView: on NSCell, which gets called by performClick:. NSButtonCell now overwrites this method instead of performClick:. You'll find an explanation for this in the file Changelog.3 in the entry from Quentin Mathe on 2004-04-02. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSApplication...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/11/06 19:37:27 Modified files: core/gui : ChangeLog core/gui/Source: NSApplication.m NSImage.m Log message: Take care that images render to the correct screen. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2580tr2=1.2581r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSApplication.m.diff?tr1=1.284tr2=1.285r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSImage.m.diff?tr1=1.89tr2=1.90r1=textr2=text
Re: The goal of GNUstep 1.0
David Ayers wrote: Fred Kiefer schrieb: On the more down to the bits side, I would like to see a stable memory layout for all GUI classes. This has two aspects, we are still missing some ivars that will be needed for full OpenStep/Cocoa compliance. The other side is that we could use more bit fields to make these classes more compact. After a 1.0 release it will get pretty hard to change the memory usage of these classes, so we need to do it now. I'm curious, if you have some measurements to show that using bit fields is a good idea. I have the feeling that -gui does not really create enough instances for the compactness of these instances to outweigh the performance hit due to the fact that the compiler actually has to generate more code for accessing bit fields than more naturally aligned ivars. I've hacked into -base's Testing/benchmark a little test to show the difference. (Note I'm not planing to commit this, it was just a convenient place to put it.) Thank you for the nice test code. On my i586 machine this gives a 5% slowdown for a 1/3 memory reduction. Other machines may give totally different results. But as Richard already pointed out, bitfields or not isn't the big question, it is more important to have a stable memory layout for the GUI classes. On the other hand there are a few classes where hundreds if not thousands of instances are rather common, NSCell (and its subclasses) being the most prominent example, NSEvent a not so prominent one. We don't need to go as far as Apple did with bitfields, but we should at least go through all the classes in GUI and have another look at the memory layout: Could it be improvied by reordering ivars? Do we need space to grow for this class? Are we missing ivars needed for full Openstep or Cocoa compatibility? Should we use bit fields? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. Here I have to agree with you. GNUstep is for some time now actually usable, but progress and contributions have slowed down a lot. I can only talk about my own reasons for contributing less. Now idea, why other core developers like Alexander Malmberg, who was responsible for the great progress on gui in the previous year, no longer contributes. But the same is true for Quentin and even for Adrian in recent months. To be honest, there never were more than just a few people working on gui at the same time. We just need to find new people taking up the orphaned work, or get the old ones back again. For example it is great to see Nicola working on make again! I've been doing a lot of thinking and have compiled a list of things I believe that GNUstep needs to address to stay on top of things. The list follows: 1) More apps. Many of the following points will help with this, but this is very important. 2) Better theme support. Integration of Camaelon into the core gui library if possible 3) Better win32 support. Many companies are really eager to port their legacy NeXTSTEP/OPENSTEP or Cocoa apps to GNUstep under Windows. The prospect of Linux and BSD support appeals to them as well, but not as much as Windows. I currently have two companies with whom I am talking about this. 4) Better distro support. We really need to get GNUstep into as many distributions as possile, this will ramp up exposure of GNUstep to more people and help us get more developers and users. All of this is true. It would increase the general preception of GNUstep. Make it a better usable system. But who should be doing this? We will need to motivate developers first. In my view, the bounties that Adam presented some time ago, are a desparate step in this direction. But I know of no better one. Perhaps one, I remember when joining GNUstep there were these list Adam had set up on the GNUstep web site, listing open tasks, classes to do and time frames for all of this. Of course this was somewhat ridicules, how could you set up a schedule, when you don't ahve any resources to control? Still, for me this was a motivation to join and to do my part to keep the schedule. We as a project need to be more adaptive and less resistant to change. More than anything right now we need to consider the audience we are playing to. GNUstep needs to be better able to integrate with other environments. I am not sure, if GNUstep is really that much against change. I for my part would like to see GNUstep integration with DBUS and other new hot technologies. Perhaps I might even start to work on that. Do you have any specific examples of change resistence in GNUstep? My feeling is rather that new stuff in GNUstep gets ignored until the person working on that gets bored. To me this happend with the win32 stuff, the keyed-encoding and currently again with the cairo backend. Additionally, I've noticed recently a trend for certain people to constantly query the list asking for permission to make this or that change. It seems that what we need more than anything right now is more action and less talk. If you are interested in doing something, please do it! :) True! Please think about what I've said and let me know your thoughts. I say the above out of concern for the community. GNUstep is and always has been a true labor of love for me. I want to see it thrive. Same for me :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Headers/AppKit/NSInp...
David Ayers wrote:
--- gnustep/gnustep/core/gui/Source/GSTitleView.m 2005/05/26 02:52:43
1.11
+++ gnustep/gnustep/core/gui/Source/GSTitleView.m 2005/10/19 23:54:22
1.12
@@ -351,7 +351,7 @@
}
// We do not need app menu over menu
-- (void) rightMouseDown: (NSEvent*)theEvent
+- (NSMenu *) rightMouseDown: (NSEvent*)theEvent
{
}
Doesn't this give you a warning about control reaching the end of a
non-void function? If it doesn't, then that looks like a gcc regression.
Oops, I did change the wrong method here. I wanted to change the next one.
Thank you for pointing out
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Headers/AppKit/NSInp...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/10/19 23:54:27 Modified files: core/gui : ChangeLog core/gui/Headers/AppKit: NSInputManager.h core/gui/Source: GSTitleView.m NSColor.m NSImageCell.m NSMenuView.m NSResponder.m NSSavePanel.m NSTabView.m NSTableHeaderView.m Log message: Removed gcc 4.02 compiler warnings. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2572tr2=1.2573r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/AppKit/NSInputManager.h.diff?tr1=1.3tr2=1.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/GSTitleView.m.diff?tr1=1.11tr2=1.12r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSColor.m.diff?tr1=1.55tr2=1.56r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSImageCell.m.diff?tr1=1.27tr2=1.28r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSMenuView.m.diff?tr1=1.105tr2=1.106r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSResponder.m.diff?tr1=1.41tr2=1.42r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSSavePanel.m.diff?tr1=1.87tr2=1.88r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSTabView.m.diff?tr1=1.47tr2=1.48r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSTableHeaderView.m.diff?tr1=1.30tr2=1.31r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSApplication.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/10/18 07:46:25 Modified files: core/gui : ChangeLog core/gui/Source: NSApplication.m Log message: Don't call NSDocumentController on application termination, if not needed. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2571tr2=1.2572r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSApplication.m.diff?tr1=1.283tr2=1.284r1=textr2=text
[Gnustep-cvs] gnustep/core/base ChangeLog Source/NSNumberForm...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/10/17 10:47:54 Modified files: core/base : ChangeLog core/base/Source: NSNumberFormatter.m Log message: Small improvements on NSNumberFormatter to get it workable with different decimal separators. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2617tr2=1.2618r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Source/NSNumberFormatter.m.diff?tr1=1.16tr2=1.17r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSSavePanel.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/10/17 11:50:04 Modified files: core/gui : ChangeLog core/gui/Source: NSSavePanel.m Log message: Accept dragged file names in NSSavePanel. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2570tr2=1.2571r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSSavePanel.m.diff?tr1=1.86tr2=1.87r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSRulerView.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/10/14 10:57:09 Modified files: core/gui : ChangeLog core/gui/Source: NSRulerView.m Log message: Adjust mark display for vertical rulers. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2569tr2=1.2570r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSRulerView.m.diff?tr1=1.17tr2=1.18r1=textr2=text
[Gnustep-cvs] gnustep/usr-apps/examples/gui/Ink ChangeLog Doc...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/10/14 11:06:25 Modified files: usr-apps/examples/gui/Ink: ChangeLog Document.m Log message: Added vertical ruler view. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/examples/gui/Ink/ChangeLog.diff?tr1=1.11tr2=1.12r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/usr-apps/examples/gui/Ink/Document.m.diff?tr1=1.17tr2=1.18r1=textr2=text
Re: Core release
Adam Fedor wrote: On 2005-09-13 10:51:18 -0600 Adam Fedor [EMAIL PROTECTED] wrote: I hope to make a new core libraries release this week (sub-minor revision). Assuming I get the time. Also, anyone opposed to making the art back end the default? It's been this way in Startup for a while and there's automatic support for switching back to the x11 backend if the libs are not found. No, go ahead. I was hoping that I get the cairo backend up and running early enough, so that we could switch to that directly, but this step will take quite a bit longer. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Cairo backend
Nicolas Roard wrote: On 8/28/05, Fred Kiefer [EMAIL PROTECTED] wrote: Some of you may have noticed that this week the release 1.0 of cairo has been published. For quite some time GNUstep has had a backend based on this graphics library. But this has always been incomplete and also cairo has changed a lot over the months. In the last few weeks I cleaned up the code for this backend and extended it a bit. Basically it is now ready to try it, although many features are still missing. Wow, excellent news ! Known limitations: - fonts are still hard coded - text in NSTextView sometimes doesn't get displayed - images are often displayed incorrect - copying from one GState to another uses wrong transformation - some minor operations are missing or untested I hope to solve these problems within the next month and will make a public announcment for the cairo backend after that. If you find other bugs, feel free to report them, or even better help to resolve them. I'll try to install cairo and test that :-) I did forget to mention that you have to hack the cairo library for now. The GNUstep backend uses some cairo functions that are not exported by cairo. These are: _cairo_toy_font_face_create _cairo_scaled_font_text_to_glyphs What I did to get cairo to export these functions was to redefine cairo_private in cairoint.h to be empty. I will set up a mail to the cairo maintainer and ask for a better solution. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/back ChangeLog Headers/cairo/Cairo...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/08/28 00:48:13 Modified files: core/back : ChangeLog core/back/Headers/cairo: CairoFontInfo.h CairoSurface.h core/back/Source/cairo: CairoContext.m CairoFontInfo.m CairoGState.m CairoSurface.m XGCairoGlitzSurface.m XGCairoSurface.m XGCairoXImageSurface.m Log message: Get cairo surfaces working for resized windows. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.387tr2=1.388r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/cairo/CairoFontInfo.h.diff?tr1=1.4tr2=1.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/cairo/CairoSurface.h.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoContext.m.diff?tr1=1.5tr2=1.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFontInfo.m.diff?tr1=1.5tr2=1.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoGState.m.diff?tr1=1.6tr2=1.7r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoSurface.m.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/XGCairoGlitzSurface.m.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/XGCairoSurface.m.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/XGCairoXImageSurface.m.diff?tr1=1.2tr2=1.3r1=textr2=text
Cairo backend
Some of you may have noticed that this week the release 1.0 of cairo has been published. For quite some time GNUstep has had a backend based on this graphics library. But this has always been incomplete and also cairo has changed a lot over the months. In the last few weeks I cleaned up the code for this backend and extended it a bit. Basically it is now ready to try it, although many features are still missing. Known limitations: - fonts are still hard coded - text in NSTextView sometimes doesn't get displayed - images are often displayed incorrect - copying from one GState to another uses wrong transformation - some minor operations are missing or untested I hope to solve these problems within the next month and will make a public announcment for the cairo backend after that. If you find other bugs, feel free to report them, or even better help to resolve them. If you want to compile the cairo backend, use the command: ./configure --enable-graphics=cairo --disable-glitz We probably should switch glitz off by default, as this is not offically supported by cairo at the moment Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/back ChangeLog Source/cairo/CairoF...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/08/19 23:42:55 Modified files: core/back : ChangeLog core/back/Source/cairo: CairoFaceInfo.m CairoFontInfo.m Log message: Adopted to Cairo changes. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.385tr2=1.386r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFaceInfo.m.diff?tr1=1.4tr2=1.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFontInfo.m.diff?tr1=1.4tr2=1.5r1=textr2=text
[Gnustep-cvs] gnustep/core/back ChangeLog Source/cairo/CairoG...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/08/20 00:10:35 Modified files: core/back : ChangeLog core/back/Source/cairo: CairoGState.m Log message: Sort colours in bitmap as expected by Cairo. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.386tr2=1.387r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoGState.m.diff?tr1=1.5tr2=1.6r1=textr2=text
[Gnustep-cvs] gnustep/core/back ChangeLog Headers/cairo/Cairo...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/07/27 23:25:32 Modified files: core/back : ChangeLog core/back/Headers/cairo: CairoFaceInfo.h CairoFontEnumerator.h CairoFontInfo.h CairoSurface.h XGCairoSurface.h core/back/Source/cairo: CairoContext.m CairoFaceInfo.m CairoFontEnumerator.m CairoFontInfo.m CairoGState.m CairoSurface.m GNUmakefile NSBezierPathCairo.m XGCairoGlitzSurface.m XGCairoSurface.m XGCairoXImageSurface.m Log message: Changed to compile with latest cairo interface changes. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.383tr2=1.384r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/cairo/CairoFaceInfo.h.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/cairo/CairoFontEnumerator.h.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/cairo/CairoFontInfo.h.diff?tr1=1.3tr2=1.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/cairo/CairoSurface.h.diff?tr1=1.1tr2=1.2r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/cairo/XGCairoSurface.h.diff?tr1=1.1tr2=1.2r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoContext.m.diff?tr1=1.4tr2=1.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFaceInfo.m.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFontEnumerator.m.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFontInfo.m.diff?tr1=1.3tr2=1.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoGState.m.diff?tr1=1.4tr2=1.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoSurface.m.diff?tr1=1.1tr2=1.2r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/GNUmakefile.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/NSBezierPathCairo.m.diff?tr1=1.2tr2=1.3r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/XGCairoGlitzSurface.m.diff?tr1=1.1tr2=1.2r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/XGCairoSurface.m.diff?tr1=1.1tr2=1.2r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/XGCairoXImageSurface.m.diff?tr1=1.1tr2=1.2r1=textr2=text
[Gnustep-cvs] gnustep/core/back/Source/cairo CairoFaceInfo.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/07/27 23:29:51 Modified files: core/back/Source/cairo: CairoFaceInfo.m Log message: Small tweak forgotten in last update. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/cairo/CairoFaceInfo.m.diff?tr1=1.3tr2=1.4r1=textr2=text
Re: Core release, Wed
Adam Fedor wrote: I'm mostly satisfied with the libraries now, which is to say, I don't really have any time to make any significant changes. So I'll plan on freezing the release this Wednesday. Unless there are any objections. Fine for me. I am still investigating on how best to implement the pattern colours, so this will only go into the release after. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Hi Alexander, thank you for that feedback and more important: Great to have you back here! Your comment on PSGsave and PSGrestore is correct. The problem here is that we only know in the GState that we are going to draw a pattern image, while the PSGsave and PSGrestore operations should be applied on the context level. Not sure, if we should decorate every fill operation with a save/restore combination. You are propably correct about the drawToPoint call. Its just that this fails on xlib sometimes that I didn't want to use that method, Cheers Fred Alexander Malmberg wrote: Fred Kiefer wrote: Fred Kiefer wrote: What I was planning to do was add a simple (and of course slow) pattern drawing mechanism for the gsc classes and perhaps overwrite this with a faster one for the xlib backend. [snip] [colour_pattern compositeToPoint: NSMakePoint(x, y) operation: NSCompositeSourceOver]; I think this should be -drawToPoint:fromRect:operation:fraction: in order to handle transformations correctly; would have to check the PLRM to be sure about pattern semantics, though. [snip] All of this works fine. Of course EOFill is currently not supported, but simple to do (would require a call to DPSeoclip instead of DPSclip). And the clipping is what stops me from merging this code into CVS. As I need to change the clipping, and restore it afterwards, I could either implement this separately for each backend and not share any code or implement that clipPath method, used in the current implementation, for all backends. As this method is also not that easy, I could fake it by storing the current clip path in another slot of the GState (and keep the EO state within this path, as we need that as well when reseting the old clip). But perhaps somebody out there has a better idea for this? PSgsave/PSgrestore are the only portable methods for saving and restoring the clipping path, and I'd suggest using those. The current clipping path is the intersection of all paths passed to PSclip/PSeoclip (since the path was last reset, etc.; also, note that the filling rule merely specifies how the path to be intersected with the clipping path should be interpreted, the clipping path doesn't have any such property), so for a backend to be able to return the clipping path as an actual path, it would have to be able to compute arbitrary bezier curve intersections, and that's a nasty problem. - Alexander Malmberg ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Adrian Robert wrote: On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. Is there an easy way to test it? Is there something in the new test suite that exercises this facility? Here is the simple application I tested with. But I am not even sure if the different operators have been implemented correctly for xlib, but thenm only one of the images I use has alpha values. Perhaps I should test with to transparent images. composite.tgz Description: application/compressed-tar ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GUI/back changes in CVS
Nicolas Roard wrote: On 7/11/05, Fred Kiefer [EMAIL PROTECTED] wrote: Adrian Robert wrote: On Jul 8, 2005, at 8:17 PM, Fred Kiefer wrote: I just added changes to GUI and back that will in the end allow pattern images for GNUstep and the new MacOSX composite operator that uses an addtional alpha value. I wanted these changes to go into the next release as this will break binary compatibility between GUI and back. I have tested this change with xlib. It would be great, if somebody could test it before the release with art and winlib. Is there an easy way to test it? Is there something in the new test suite that exercises this facility? Here is the simple application I tested with. But I am not even sure if the different operators have been implemented correctly for xlib, but thenm only one of the images I use has alpha values. Perhaps I should test with to transparent images. This test is only for composition, but what about the pattern images ? The filling patterns you are talking about, is setting an image to a color and then fill something with this color, right ? I'm asking because when I profiled Camaelon, pattern filling was one of the thing that took lots of time, and i'm hoping that by having the possibility to use filling pattern directly it will be faster (as you shouldn't need context switching during the filling). And, does it properly follow the current path mask ? (actually I think that doesn't work on xlib, only with art, anyway...) Sorry, some things seem to have gotten mixed here. I wrote that in the end this will allow pattern images. They are not already there after the first patch. Support for pattern colours requires two steps in the backend: It needs to know, which image pattern to use, which is what I implemented (the result of a pattern colour set command). And it needs to draw this image, when a fill operation happens. I did not even work on this second bit. Now art has an implementation of the very powerfull shfill PS command. This allows, amongst other things, a pattern fill. So here the second bit is already persent, while the first bit was missing. It should be rather simple to implement full pattern colours drawing for the art backend now. But this is nothing I am planning to do. The whole structure of the art backend is very foreign to me. I don't dare to touch anything here, because I may easily break things in an environment that is so contrary to the way I normally program. What I was planning to do was add a simple (and of course slow) pattern drawing mechanism for the gsc classes and perhaps overwrite this with a faster one for the xlib backend. Perhaps you could add the art pattern fill bit and I provide the rest? Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Headers/AppKit/NSGra...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/07/08 23:51:49 Modified files: core/gui : ChangeLog core/gui/Headers/AppKit: NSGraphicsContext.h core/gui/Source: NSColor.m NSGraphicsContext.m NSImage.m Log message: Added methods for pattern colour and alpha image composition. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2547tr2=1.2548r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/AppKit/NSGraphicsContext.h.diff?tr1=1.4tr2=1.5r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSColor.m.diff?tr1=1.54tr2=1.55r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSGraphicsContext.m.diff?tr1=1.77tr2=1.78r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSImage.m.diff?tr1=1.88tr2=1.89r1=textr2=text
[Gnustep-cvs] gnustep/core/back ChangeLog Headers/gsc/GSGStat...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/07/09 00:10:08 Modified files: core/back : ChangeLog core/back/Headers/gsc: GSGState.h core/back/Source/gsc: GSContext.m GSGState.m GSStreamContext.m core/back/Source/xlib: XGGState.m Log message: dded partial implementation for pattern colour and alpha image composition. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/ChangeLog.diff?tr1=1.379tr2=1.380r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Headers/gsc/GSGState.h.diff?tr1=1.5tr2=1.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/gsc/GSContext.m.diff?tr1=1.14tr2=1.15r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/gsc/GSGState.m.diff?tr1=1.25tr2=1.26r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/gsc/GSStreamContext.m.diff?tr1=1.19tr2=1.20r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/back/Source/xlib/XGGState.m.diff?tr1=1.31tr2=1.32r1=textr2=text
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSMenu.m
Adam Fedor wrote: From: Fred Kiefer [mailto:[EMAIL PROTECTED] The code for the later change now implicitly sets the menu windows frame to the stored one (or a scaled version of that, when the screen has a different size), this could cause a problem if the menu window would be resizable, as then some menu entries might become unreachable (either because the screen is smaller or because we have new entries in the menu). At the moment this isn't a problem as menu windows don't allow resizing, but it is a hidden dependency, which may break later on. Any idea, if and what we should do here? What about when the developer changes the menu around in a new version of the app? Does that pose the same problem? Probably we should just set the origin. Also no problem as long as we have the menu marked as non-resizable. The other change also has a slight problem. The visible frame of the screen excludes a possible top menu and, if we ever have this, we must of course position the menu there. Again currently this is a no issue, I just wanted to state all these potential problems on the mailing list, so that somebody will be able to dig them up again, when this ever becomes an issue. Yep. Maybe some comments in the code would help with future changes. I add them, when I get arround to code again. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Keyed nibs
Gregory John Casamento wrote: I'm going to start working more seriously on keyed nibs. Although this isn't something which will be ready for 1.0, I want to start focusing on it more. I'm giving the heads up, so expect changes soon. :) Great, if you need some help on it, feel free to ask. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSMenu.m
Fred Kiefer wrote: CVSROOT: /cvsroot/gnustep Module name: gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/06/21 22:48:21 Modified files: core/gui : ChangeLog core/gui/Source: NSMenu.m Log message: Corrected handling of screen size for menu. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2541tr2=1.2542r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSMenu.m.diff?tr1=1.128tr2=1.129r1=textr2=text Sorry for having to reply to my own change mail, but when I woke up this morning I had second thoughts about the change I made last night. I made this change in NSMenu as a response to the Debian bug report #315274. Actually these are two changes, one switches from using [screen frame] to [screen visibleFrame] (and also from using the main screen to the actual screen, but this seems still correct) and the other change tries to correct the reported behaviour of the menu being off screen, when used on a smaller monitor. The code for the later change now implicitly sets the menu windows frame to the stored one (or a scaled version of that, when the screen has a different size), this could cause a problem if the menu window would be resizable, as then some menu entries might become unreachable (either because the screen is smaller or because we have new entries in the menu). At the moment this isn't a problem as menu windows don't allow resizing, but it is a hidden dependency, which may break later on. Any idea, if and what we should do here? The other change also has a slight problem. The visible frame of the screen excludes a possible top menu and, if we ever have this, we must of course position the menu there. Again currently this is a no issue, I just wanted to state all these potential problems on the mailing list, so that somebody will be able to dig them up again, when this ever becomes an issue. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Quentin Mathé wrote: Le 20 juin 05 à 00:05, Fred Kiefer a écrit : I did not see any further reply to this mail from Matt, apart from my own. Does this mean that the patch is generally accepted or is just nobody interested? As I uggested I would like to see the cell tracking code as a new method on NSTableView. Something like: - (void) trackColumn: (int) columnIndex row: (int) rowIndex withEvent: (NSEvent *) theEvent I fully agree because I must admit I'm unable to understand current code in this method (I'm not talking about Matt's patch). I have to admit that I still con't quite understand the event handling concept. Let me try to rephrase it in my words and you may correct me later on: When getting a mouseDown event in the NSTableView, we need to find out if this is starting a dragging. Only if not we send on the event to the cell to start tracking. My main concern is the fact currently table view handles selection and tracking on mouseUp for cells by default… but selection and tracking should be handled on mouseDown event with cells, except when dragging is turned on and the clicked cell returns NO for trackMouse:inRect:ofView:untilMouseUp: or startTrackingAt:inView: methods I think. That would match moreover current Cocoa behavior (except the minor difference decided by Matt for dragging, I think it is a better choice that Apple's one) To illustrate current issues with examples: - you have no selection change on mouseDown currently when you click on a table view with standard cells and dragging turned off (this feedback absence is really problematic for a combobox because its popup window is closed on mouseUp before the clicked row highlighting becomes visible in table view) - popup button cell doesn't show its menu on mouseDown (only on mouseUp) - combobox cell doesn't support editing with current delayed tracking model (but it could involve other issues too) As we may have missed a few events whlie determining if this is a drag operation, the cell and the table view needs to get one more event to process from the application directly. If I understand you correctly you say that this is the behavour on Cocoa. Still it looks rather strang to me. On the other hand we should try to get dragging from table views working again for the next release and your patch is currently the only one. If nobody disagrees, I would submit this patch, with the separate tracking method and a few comments added. My objection to the patch would be it is introducing duplicated code between NSLeftMouseDragged and NSLeftMouseUp handling with the new 'if (draggingPossible == YES)' statement, without implementing true custom cell support as a counterpart. Anyway I think we can apply the patch, it works well in my test (dragging seems to be fixed) even if it's probably a temporary solution in my opinion… May be when code will be reorganised, we may start to clean mouse events handling in a definitive way in order to support any kind of cells correctly. Just one still unclear idea: Dowe really have to dequeue the events we get in mouseDown:? If we would first get the event and see if there is a draggging event coming, we would let the cell do the dragging, if this is allowed, with the event still in the queue. And if there isn't an upcoming drag event we could dequeue the event and do normal processing in the table view. As I wrote, just an idea... Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSMenu.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/06/21 22:48:21 Modified files: core/gui : ChangeLog core/gui/Source: NSMenu.m Log message: Corrected handling of screen size for menu. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2541tr2=1.2542r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSMenu.m.diff?tr1=1.128tr2=1.129r1=textr2=text
Re: image and scroll view quirks
Riccardo wrote: after Fred fixed the problem scrolling of an image inside a scroll view I noticed the introduced (or exposed) a bug. It is not fatal, but may be worth investigation. a quick note: the original problem was that when the image was larger than the view and scrlling was needed, only a part of the picture actually displayed, scrollbars were there and scrolled, but only a lower left rect showed the contents. This on xlib. As an example I am referring to how images are displayed inside the PRICE main window. right now, a strange shadow happens: the whole window is drawn, the image correctly filing all the window area and in the correct size, but a shadow appears in form of a rect where formerly with the old bug the image was displayed. I can clearly see the borders super-impressed to the correct image, then after a time, the image gets probably re-drawn again and the final result is correct. This is particularly evident with big images (like 1024x768 or greater). I wonder if this is a bug and that it makes display slower and more inefficient than what it should be, redrawing things twice. PS: I haven't filed a bug yet, I wanted to know other peoples comments and maybe Fred or someone has a rapid fix. I tried to reproduce this behaviour with different GNUstep image drawing applications (including the version of PRICE that I am using), but failed. GNUstep surely is slow in drawing large images, especially when scaled, but that is all that I could see. could you provide an image to demonstrate the behaviour and if possible also a screen shot of the wrong display? Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSColor.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/06/18 11:24:03 Modified files: core/gui : ChangeLog core/gui/Source: NSColor.m Log message: +colorFromString: make sure to always release scanner. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2540tr2=1.2541r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSColor.m.diff?tr1=1.53tr2=1.54r1=textr2=text
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
Matt Rice wrote:
--- Enrico Sersale [EMAIL PROTECTED] wrote:
Just to be more precise :) ... I'm not referring to
this; I've fixed it implementing -copyWithZone: in
my cell class when I've seen that gworkspace
segfaults trying to release an ivar of this class.
The real problem is that it is not possible anymore
to start a drag from a cell (this is visible in
GNUMail, too). Making -startTrackingAt:inView: to
return NO in the cell class fixes this problem too,
but I think that there is something wrong in
-mouseDown: because, before theese changes, both the
apps worked well.
indeed I don't think that should be required either.
(though looking at the docs i noticed that
-startTrackingAt:inView:... returns NO if the view
doesn't send actions on dragging or periodic events
it isn't clear whether this affects the return value
of trackMouse:inRect:...
anyhow a little testing shows you are correct.
this changes the behaviour of trackMouse:inRect:..
slightly to cope with an event that happened in the pa
in a dragging source table view
trackMouse:mouseDownEvent will be sent after the mouse
has gone up (when it is clear that no dragging has
been started).. though this severely limits the cells
which will work with one
sure isn't pretty though, that's probably fixable..
This is a rather huge patch, could you please describe in more detail,
what you are aiming at with it? What did you test and how does MacOSX
differ from the current GNUstep behaviour?
Most of what changed looks like just a reformatting, which should be
harmless, but this makes it hard to see the actual change itself. Would
it be possible to provide a different patch, which tries to keep the old
formatting (perhaps by using some dummy {} combination)? Even the old
mouseDown: method here was unreadable, but the patch realy is
incomprehensible for me in its current form.
Fred
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSPopUpButton...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/05/27 13:41:46 Modified files: core/gui : ChangeLog core/gui/Source: NSPopUpButtonCell.m Log message: Make sure popup button cells wont get notifications after being dealloceated. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2529tr2=1.2530r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSPopUpButtonCell.m.diff?tr1=1.67tr2=1.68r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/05/26 13:38:11 Modified files: core/gui : ChangeLog core/gui/Source: NSTableView.m Log message: Improved mouseDown call handling for table view. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2528tr2=1.2529r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSTableView.m.diff?tr1=1.116tr2=1.117r1=textr2=text
Re: Building in a separate directory
Adam Fedor wrote: On May 26, 2005, at 12:04 PM, David Lázaro Saz wrote: On 26/05/2005, at 1:00, Adam Fedor wrote: It might be nice to fix autoconf, but then you'll run into make. 'make' doesn't like spaces in directories either - and this is a fundamental design issue. But doesn't make always run in the same directory? Anyway I'm placing this on the back burner for some time, and it's been a long time since I read the GNU make manual. But I think that this issue needs to be solved someday because directories with spaces are very common this days (Windows' C:\Program Files, for example). I'm now deeply immersed in cross-compiling, though. I'm also reviewing how Autoconf works and how it's applied through GNUstep. My knowledge of Autoconf is somewhat superficial right now. The first problem I've detected is that the macro AC_FUNC_SETPGRP prevents cross-compiling because it always needs to run the test program that it constructs in order to check the signature of setpgrp. I haven't found how to circumvent it yet. if test $cross_compiling = no; then AC_FUNC_SETPGRP else #set a default value fi I was working on that, but the default for MingW is not what the normal default would be, but I wasn't entirely sure. Autoconf is rather easy to work around, as long as you have the informations on the correct settings for the traget system. Perhaps it would even be possible to run autoconf on the target system and transfer the results to the actual build environment? For simple settings like AC_FNUC_SETGRP it is sufficent to set an environment variable stating the presense/absense of the feature. Here the settings I used to cross compile for an ARM system: export cl_cv_c_longlong=yes export ac_cv_func_setpgrp_void=yes ./configure --prefix=/home/zaurus/gnustep --disable-flattened \ --host=arm-linux --build=ix86-linux \ --libdir=/home/zaurus/gnustep/System/Library/Libraries/arm/linux-gnu \ --includedir=/home/zaurus/gnustep/System/Library/Headers/gnu-gnu-gnu \ --disable-do For me this looks easier than trying to guess the correct default value for all the systems and hard coding that in the .ac file. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSComboBoxCell.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/05/22 10:27:24 Modified files: core/gui : ChangeLog core/gui/Source: NSComboBoxCell.m Log message: Improved combobox layout. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2524tr2=1.2525r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSComboBoxCell.m.diff?tr1=1.36tr2=1.37r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSWindow.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/05/20 14:33:43 Modified files: core/gui : ChangeLog core/gui/Source: NSWindow.m Log message: Implemented animate resize. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2523tr2=1.2524r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSWindow.m.diff?tr1=1.325tr2=1.326r1=textr2=text
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSImageCell.m
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/05/19 11:45:54 Modified files: core/gui : ChangeLog core/gui/Source: NSImageCell.m Log message: Treat nil as image unsetting in setObjectValue:. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2521tr2=1.2522r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSImageCell.m.diff?tr1=1.24tr2=1.25r1=textr2=text
Apple binar property lost format
I did just commit the writing of property lists in the Apple binary format. This should make it easier to write NIB files that may be used on Apple systems. But of course we will need full keyed encoding first. There are two known limitations to this implementation. First NSNumber objects containing char values with 0 or 1 are treated as NO and YES. This wont make much of a difference for the applications reading this data, but is not strictly correct. I could not find any way to handle this better, apart from checking for an internal class name. After all this is still a lot better than the XML output format code, which treats all char numbers as boolean. The other limitation is that when reading in a binary property list and storing it again in the same format, the number of objects decreses. I am not sure what is causing this, it also only happens with big NIB files. My only idea is that my code in [BinaryPLGenerator indexForObject:] removes duplicate occurences of objects. Maybe Apple stores them each anew. If somebody can confirm this, I would adjust my code. But then the code would no longer be able to handle recursive property list. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSPopUpButton...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Fred Kiefer [EMAIL PROTECTED] 05/04/17 21:25:32 Modified files: core/gui : ChangeLog core/gui/Source: NSPopUpButton.m NSPopUpButtonCell.m Log message: Fixed bug #12680 and further clean up of NSPopupButtonCell. CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2513tr2=1.2514r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSPopUpButton.m.diff?tr1=1.55tr2=1.56r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSPopUpButtonCell.m.diff?tr1=1.65tr2=1.66r1=textr2=text
