[Gnustep-cvs] gnustep/core/base ChangeLog Documentation/Base....
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Richard Frith-Macdonald [EMAIL PROTECTED] 05/06/05 05:24:45 Modified files: core/base : ChangeLog core/base/Documentation: Base.gsdoc core/base/Headers/Foundation: NSArchiver.h NSObject.h core/base/Tools: AGSHtml.m AGSParser.m Log message: Documentation tweaks CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/ChangeLog.diff?tr1=1.2536tr2=1.2537r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Documentation/Base.gsdoc.diff?tr1=1.16tr2=1.17r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Foundation/NSArchiver.h.diff?tr1=1.5tr2=1.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Headers/Foundation/NSObject.h.diff?tr1=1.10tr2=1.11r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Tools/AGSHtml.m.diff?tr1=1.89tr2=1.90r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/base/Tools/AGSParser.m.diff?tr1=1.72tr2=1.73r1=textr2=text
bug #13183
I don't really know how to deal with this cygwin bug ... If I use windows I use mingw rather than cygwin as I consider it by far the better way to go ... licensing means people could actually deploy proprietory GNUstep apps with mingw where they can's using cygwin, and the mingw approach of using the native api means the code can be a lot more efficient and we avoid the extra layer of code where things can go wrong. I'm not sure any GNUstep developer uses cygwin (though several, myself included, have done so in the past)... which is probably why cygwin is tagged as 'needs testing' on the website, rather than being a fully supported platform. Perhaps we should have another support classification meaning that a platform is unsupported (ie we won't commit to fixing anything), but that we accept bugfixs for it from anyone who wants to contribute them? The description of the existing 'needs testing' classification says 'are not actively tested by developers and need someone to help with reporting problems and fixes' ... That might be an accurate/inmformative description for the cygwin platform, but I suspect it implies more activity on the platform than actually exists. Perhaps a more accurate description would be to say that bug reports are unlikely to be addressed unless accompanied with fixes. Of course, I may be completely wrong, and someone may be looking into this, but if not, it's a bug report which could hang around for ages simply because it's specific tio an unsupported platform ... and that looks bad. Any thoughts? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: bug #13183
Hey all, I submitted that bug. On Sunday, June 5, 2005, at 10:21 AM, Richard Frith-Macdonald wrote: I don't really know how to deal with this cygwin bug ... If I use windows I use mingw rather than cygwin as I consider it by far the better way to go ... licensing means people could actually deploy proprietory GNUstep apps with mingw where they can's using cygwin, and the mingw approach of using the native api means the code can be a lot more efficient and we avoid the extra layer of code where things can go wrong. well, I know, but cygwin is quite widespread. In my case I had it on the computers in the research lab and I gave gnustep a spin, it would have been fun to have my standard gnustep tools under windows... To be really honest, I have never seen minigw with shell, some use it because it ships as a library with some rporgam, but really most people I know use cygwin. Many commercial laboratory tools (typically those which have a unix counterpart) use cygwin and in most labs were the unix env. is big, there is cygwin because it is just more unix. Using X11 and typical libraries most programs really recompile in a breeze and blend with unix tools exported from say a solaris system very well. It might be worth to support both. Unfortunately the minigw inside cygwin isn't a good solution (even while passing the correct flags to gcc) since the environment is still recognized by configure as a cygwin system. Of course, I may be completely wrong, and someone may be looking into this, but if not, it's a bug report which could hang around for ages simply because it's specific tio an unsupported platform ... and that looks bad. Not me sorry, my windows knowledge is = 0.0. I just wanted to give it a spin on the environment I had available and I reported the problem to share my experience, maybe there are other cygwin users out there. I could have used the environment myself and I would have tested my own programs there but every fix which touches the window guts is far beyond my knowledge. That -base doesn't even link is a bit bad. Thus the future of gnustep on cygwin is uncertain, you may close the bug if you are concerned with it sticking around... but there are many others who hang there since ever, so I wouldn't worry. Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Sun Jun 5 06:34:08 EDT 2005 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 add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf2.0.2 Sun Jun 5 03:58:08 CEST 2005 Success Compile powerpc-apple-darwin7.9.0 Sun Jun 5 04:26:51 MDT 2005 Success Compile sparc-sun-solaris2.7 Sun Jun 5 02:09:29 EDT 2005
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
Re: [Gnustep-cvs] gnustep/core/gui ChangeLog Source/NSTableView.m
--- Fred Kiefer [EMAIL PROTECTED] wrote:
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?
it differs quite a bit but I didn't test very much..
just what happens wrt dragging source table views wrt
trackMouse:...
(which i'll reiterate) they don't send the mouse down
until mouse up has been sent and it is determined that
a drag operation hasn't started.
also that starting dragging operation in no way
affects the selection, though (to state the obvious...
starting a dragging operation on a selection drags the
selection). I personally prefer the GNUstep behaviour
of starting a drag operation modifies the selection.
so the trackMouse: code has basically been moved into
3 places...
1) after it has been determined there is no dragging
operation in progress..
2) when the delegate returns no for
shouldEditTableColumn: in a double click event
and this was changed a bit to handle more than just
double click but 1 so that each successive click
for instance with a switch button changes the state.
3) if table view isn't a dragging source send
trackMouse:... immediately
and the double click code brought into the loop (since
its looping over the events -mouseDown: was not
getting called with a clickCount over 1...)
and after the trackMouse:... code set the
getNextEvent: flag if the current event isn't the
lastEvent so that it'll loop again and handle any
mouse down event so next time mouseDown: is called it
doesn't think we're extending the selection or
something... this happens for all but the first case,
where it doesn't matter since we're at a mouse up
event and it'll never get to the point of looking at
the getNextEvent flag.
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.
yes sorry about that, I accidentally overwrote my code
i had before the formatting changes, and wasn't
exactly ecstatic about that...
__
Yahoo! Mail
Stay connected, organized, and protected. Take the tour:
http://tour.mail.yahoo.com/mailtour.html
Index: NSTableView.m
===
RCS file: /cvsroot/gnustep/gnustep/core/gui/Source/NSTableView.m,v
retrieving revision 1.118
diff -u -r1.118 NSTableView.m
--- NSTableView.m 30 May 2005 17:01:21 - 1.118
+++ NSTableView.m 6 Jun 2005 00:12:24 -
@@ -3332,7 +3332,32 @@
{
NSPoint initialLocation = [theEvent locationInWindow];
NSPoint location;
- int clickCount;
+ // Selection
+ unsigned int modifiers = [theEvent modifierFlags];
+ unsigned int eventMask = (NSLeftMouseUpMask
+ | NSLeftMouseDownMask
+ | NSLeftMouseDraggedMask
+ | NSPeriodicMask);
+ unsigned selectionMode;
+ NSPoint mouseLocationWin;
+ NSPoint mouseLocationView;
+ NSDate *distantFuture = [NSDate distantFuture];
+ NSEvent *lastEvent;
+ NSIndexSet *oldSelectedRows;
+ BOOL startedPeriodicEvents = NO;
+ BOOL mouseUp = NO;
+ BOOL done = NO;
+ BOOL mouseMoved = NO;
+ BOOL draggingPossible = [self _isDraggingSource];
+ BOOL getNextEvent = YES;
+ NSRect visibleRect = [self
[Gnustep-cvs] gnustep/core/gui ChangeLog Headers/AppKit/NSApp...
CVSROOT:/cvsroot/gnustep Module name:gnustep Branch: Changes by: Adrian Robert [EMAIL PROTECTED] 05/06/06 04:05:05 Modified files: core/gui : ChangeLog core/gui/Headers/AppKit: NSApplication.h NSEvent.h core/gui/Source: GSServicesManager.m NSApplication.m NSFont.m Log message: filled in various gsdoc CVSWeb URLs: http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/ChangeLog.diff?tr1=1.2535tr2=1.2536r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/AppKit/NSApplication.h.diff?tr1=1.5tr2=1.6r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Headers/AppKit/NSEvent.h.diff?tr1=1.3tr2=1.4r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/GSServicesManager.m.diff?tr1=1.59tr2=1.60r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSApplication.m.diff?tr1=1.279tr2=1.280r1=textr2=text http://savannah.gnu.org/cgi-bin/viewcvs/gnustep/gnustep/core/gui/Source/NSFont.m.diff?tr1=1.82tr2=1.83r1=textr2=text
