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
Re: Delay of release....
On 2007-01-22 04:34:00 -0800 Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento schrieb: My sincerest apologies on the recent delay of the release. I have been working on correcting a few bugs prior to the release and other events have delayed me as well. The release should be made in either Monday or Tuesday. Thanks for your patience, Oops, are you talking about a release of gui trunk or are you planing a bug fix release for gui? The late case should be alright, but there might be a problem, if you are going to push out the current trunk of gui as a release. I made some changes that will break backward compatibility and am about to make a lot more of such changes. Well, backwards compatibility I believe is already pretty much shot as I have added an ivar to NSTableView, and I believe that Richard has added one to NSControl, so it would be good if we could get these added now, (even if the code to use them is omitted from the release due to instability or whatever) :D ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Delay of release....
On 23 Jan 2007, at 10:22, Matt Rice wrote: On 2007-01-22 04:34:00 -0800 Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento schrieb: My sincerest apologies on the recent delay of the release. I have been working on correcting a few bugs prior to the release and other events have delayed me as well. The release should be made in either Monday or Tuesday. Thanks for your patience, Oops, are you talking about a release of gui trunk or are you planing a bug fix release for gui? The late case should be alright, but there might be a problem, if you are going to push out the current trunk of gui as a release. I made some changes that will break backward compatibility and am about to make a lot more of such changes. Well, backwards compatibility I believe is already pretty much shot as I have added an ivar to NSTableView, and I believe that Richard has added one to NSControl, Not that I recall. so it would be good if we could get these added now, (even if the code to use them is omitted from the release due to instability or whatever) :D Not to mention the move of NSAffineTransform out of gui and in to base to match Apple ... which means that whenever we make a new unstable release of gui we also need to make one of base. Wouldn't it be good to backport bugfixes and make a stable release of gui (and back) without all the incompatible changes asap though? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Delay of release....
On 2007-01-23 02:30:26 -0800 Richard Frith-Macdonald [EMAIL PROTECTED] wrote: On 23 Jan 2007, at 10:22, Matt Rice wrote: On 2007-01-22 04:34:00 -0800 Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento schrieb: My sincerest apologies on the recent delay of the release. I have been working on correcting a few bugs prior to the release and other events have delayed me as well. The release should be made in either Monday or Tuesday. Thanks for your patience, Oops, are you talking about a release of gui trunk or are you planing a bug fix release for gui? The late case should be alright, but there might be a problem, if you are going to push out the current trunk of gui as a release. I made some changes that will break backward compatibility and am about to make a lot more of such changes. Well, backwards compatibility I believe is already pretty much shot as I have added an ivar to NSTableView, and I believe that Richard has added one to NSControl, Not that I recall. sorry it was NSResponder added the has_tooltips flag so it would be good if we could get these added now, (even if the code to use them is omitted from the release due to instability or whatever) :D Not to mention the move of NSAffineTransform out of gui and in to base to match Apple ... which means that whenever we make a new unstable release of gui we also need to make one of base. Wouldn't it be good to backport bugfixes and make a stable release of gui (and back) without all the incompatible changes asap though? *shrug* pretty much indifferent on this. It be nice if this were done proactively as bugfixes were introduced though ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Delay of release....
On 23 Jan 2007, at 10:56, Matt Rice wrote: so it would be good if we could get these added now, (even if the code to use them is omitted from the release due to instability or whatever) :D Not to mention the move of NSAffineTransform out of gui and in to base to match Apple ... which means that whenever we make a new unstable release of gui we also need to make one of base. Wouldn't it be good to backport bugfixes and make a stable release of gui (and back) without all the incompatible changes asap though? *shrug* pretty much indifferent on this. It be nice if this were done proactively as bugfixes were introduced though I agree with that, but the fact is that we haven't done that in the past, so if we are going to start we need a policy decision that bugfixes are to be backported from trunk to the stable branch immediately, and we need the developers working on svn to buy in to the idea and actually do it. In an ideal world we would get new developers (who aren't confident to leap in and do bigger jobs) to do the backporting, but if we don't have any such volunteers we would need to be prepared to do it ourselves. The advantage of immediately backporting bugfixes (apart from making the process of doing a new bugfix release a whole lot easier because you don't have to try to backport a whole lot of changes in one go) is that it would make it worthwhile to set up an automated snapshot of the stable branch so that people could easily download something with latest bugfixes in it. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Registry problems on Win32 with NSMessagePortNameServerWin32
We have occasional problems using DO on windows.
Now we have tracked down at least one of the reasons and it is
in the file win32/NSMessagePortNameServerWin32.m
There are two strange things:
1 - A bug
-
In the method -registerPort:forName:
there is a call to RegSWetValueExW that looks like:
rc = RegSetValueExW (
key,
UNISTR (n)
0,
REG_BINARY,
[[(NSMessagePort*) port name] UTF8String],
25);
Now the 25 is of course wrong. It points to the length of the byte
array that is the result of the UTF8String call in the line above it.
So if the string is less than 25 bytes (including the 0 byte) it
will read from undefined memory, which will lead to an occasional crash :-(.
2 - Other (potential) bug
-
This is where I assume the value written above is read.
It is in the method: +_query:
The offending code in question is:
unsigned char buf[25];
DWORD len = 25;
// skipped code
rc = RegQueryValueExW (
key,
UNISTR (n),
(LPDWORD) 0,
type,
(LPBYTE) buf,
len);
n = [NSString stringWithUTF8String: buf];
p = [NSString stringWithFormat: @., n];
h = CreateFileW ( with lots of paremeters);
if (h == INVALID_HANDLE_VALUE)
{
RegDeleteValueW (key, UNISTR(n));
Well there seem to be two obvious problems with this code:
1 - If the retun value in buf is not zero terminated
the n = [NSString ...] will read beyond the buffer.
2 - If h == INVALID_HANLE_VALUE the idea is to remove
the entry from the registry. But the variable n
is not the same anymore as the one used in the query.
So I think the removal does not work.
Also the weird hack comment is, well, let me put it this way,
I would be happier if the weird hack was not needed.
Wim Oudshoorn.
P.S.: I am a little busy right now, so don't expect a fix
very soon. But eventually I will come around to it.
And oh, it is quite annoying, it quite regularly happens
that the first try of starting our application fails,
perhaps due to this.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep Testfarm Results
Test results for GNUstep as of Tue Jan 23 06:34:20 EST 2007 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.1 Tue Jan 23 03:56:39 CET 2007 Fail Compile powerpc-apple-darwin8.8.0 Mon Jan 22 20:25:49 CET 2007 Fail Compile sparc-sun-solaris2.7 Tue Jan 23 01:26:01 EST 2007 Success Compile x86_64-unknown-linux-gnu Tue Jan 23 04:09:15 GMT 2007 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Mailing list subscriptions
I have just subscribed to a handful of GNUStep mailing lists which went more or less smoothly (webmasters was a bit of a pain). Every list to which I sent a subscribe email (ie. every one other than webmasters) sent me two confirm requests. That is - all the lists I subscribed to on gnu.org. Of course this is not a problem for me because I could just ignore one but it indicates a problem somewhere which may need to be fixed. Cheers, Matthew -- I must take issue with the term a mere child, for it has been my invariable experience that the company of a mere child is infinitely preferable to that of a mere adult. -- Fran Lebowitz ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Delay of release....
Here's the procedure for actually making a release: http://wiki.gnustep.org/index.php/GNUstep_release_procedure Ok ... thanks. I suppose for gnustep-make I can do all the steps up to tagging the release, then you or Gregory will send out announces and manage the release publishing ? I'd plan to do the release in a couple of weeks, so I might get time to write a bit of documentation for it first. here's the policy for version numbering and when to make a release (applies more to libraries, though): http://wiki.gnustep.org/index.php/GNUstep_release_policy It doesn't seem to apply that easily to gnustep-make. ;-) But since 1.13.0 we have dropped the library suffixes and changed the ./obj directories ... if you have stuff compiled with 1.13.0 on your machine when you install the new gnustep-make you might need to recompile everything. :-) That seems to deserve at least bumping up the minor number to 1.14.0! ;-) Thanks PS: When we complete the Linux/general FHS support (which is not far, I'm getting there, a last big effort [involving also gnustep-base] and it will be done) I'd like to bump the gnustep-make version number straight up to 2.0.0. Which will be deserved because of the massive psychological/practical impact of the change. ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Delay of release....
On Jan 23, 2007, at 4:03 PM, Nicola Pero wrote: Ok ... thanks. I suppose for gnustep-make I can do all the steps up to tagging the release, then you or Gregory will send out announces and manage the release publishing ? Sure, that's fine. But since 1.13.0 we have dropped the library suffixes and changed the ./obj directories ... if you have stuff compiled with 1.13.0 on your machine when you install the new gnustep-make you might need to recompile everything. :-) That seems to deserve at least bumping up the minor number to 1.14.0! ;-) Definitely. 1.14 is the current (unreleased) unstable version of base so it should at least be bumped to that. I always like to at least keep these two packages in sync with release numbers as well. The only issue is that the current policy states that 'stable' release have an even sub-minor version number, but perhaps we could just clean that up with the next stable/unstable release (or change the policy). PS: When we complete the Linux/general FHS support (which is not far, I'm getting there, a last big effort [involving also gnustep- base] and it will be done) I'd like to bump the gnustep-make version number straight up to 2.0.0. Which will be deserved because of the massive psychological/practical impact of the change. ;-) That sounds grand. Advertising that GNUstep now automatically integrates with standard systems might make people take notice... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
