Re: The goal of GNUstep 1.0
On Oct 27, 2005, at 9:06 AM, Fabien VALLON wrote: On Mer 26 octobre 2005 17:45, Adam Fedor wrote: What bugs are you talking about? Perhaps we should prioritize the bugs in the bug database... Maybye a TODO list ( Roadmap ) before a 1.0 ? Or maybye put all this TODO list in the bug system with a special entry/status ? I checked quickly some classes in AppKit ( with the OpenStep specs ) to see if all methods are implements : Great post. This is exactly what we need (IMHO). Then we put them into a task list and prioritize them according to must-have-by-1.0 and otherwise.. In Foundation, NSNumberFormatter still needs work (Fred just recently started on it), and perhaps we should add the NSMessagePort implementation on Windows that Richard has talked about to the 1.0 list? I don't know if someone is willing to work on it, but I feel a fully functional Make/Base (not GUI/Back) on Windows should be prerequisite to 1.0 release. There are a number of other "FIXME"s in the Base code, but assumedly most of these are icing-on-the-cake that can wait (as, hopefully, are many of the ones in GUI): --- ./Additions/GCArray.m: /* FIXME: Check if malloc return 0 */ -- ./Additions/GCArray.m: /* FIXME: Check if malloc return 0 */ -- ./Additions/GSCategories.m: /* FIXME: implement this better */ -- ./Additions/Unicode.m:// FIXME check is uni_cop good for this -- ./cifframe.m: /* FIXME: in cifframe_type, return values/arguments that are structures ./cifframe.m- have custom ffi_types with are allocated separately. We should allocate -- ./GSFFCallInvocation.m: See the avcall or vacall man pages for more info. FIXME: I'm betting ./GSFFCallInvocation.m- this won't work if a structure contains another structure */ -- ./GSFFCallInvocation.m:* FIXME ... if we have a typed selector, it probably came ./GSFFCallInvocation.m-* from the compiler, and the types of the proxied method -- ./GSFFCallInvocation.m: /* FIXME ... evil hack ... where the compiler did not know ./GSFFCallInvocation.m- * selector types, if may have had to assume a method returning -- ./GSFFIInvocation.m: * FIXME ... if we have a typed selector, it probably came ./GSFFIInvocation.m- * from the compiler, and the types of the proxied method -- ./GSFormat.m: FIXME: I wasn't brave enough to include floating point formatting - ./GSFormat.m- glibc has CPU dependent routines and also uses gmp. So floating point -- ./GSFormat.m: FIXME: This needs to use length, not '\0', when dealing with format ./GSFormat.m- and %@ -- ./GSFormat.m: grouping = ""; // FIXME: grouping info missing in locale? -- ./GSFormat.m:* FIXME - hack to rewrite decimal separator into correct locale ./GSFormat.m-* if necessary. -- ./GSFormat.m:* FIXME - hack to rewrite decimal separator into correct locale ./GSFormat.m-* if necessary. -- ./GSLocale.m: /* FIXME: Get currency format from localeconv */ -- ./NSCalendarDate.m: /* FIXME What if the two dates are in different time zones? ./NSCalendarDate.m-How about daylight savings time? -- ./NSCharacterSet.m:// FIXME ... deprecated ... remove after next release. -- ./NSCharacterSet.m:// FIXME ... deprecated ... remove after next release. -- ./NSConnection.m: // FIXME thread safety -- ./NSDecimal.m: // FIXME: this is too small -- ./NSDecimal.m: // FIXME: this is too big -- ./NSDecimal.m: // FIXME: Here we need a check if the string fits into a GSDecimal, ./NSDecimal.m- // if not we must round some limbs off. -- ./NSDecimal.m: // FIXME: Make sure result is big enougth -- ./NSDecimal.m: // FIXME: I don't understand how to do this -- ./NSDecimalNumber.m: // FIXME: What exception to raise? ./NSDecimalNumber.m- [NSException raise: @"NSDecimalNumberException" -- ./NSFileManager.m: /* FIXME: On unix, directory accessable == executable, so we simulate that ./NSFileManager.m- here for Windows. Is there a better check for directory access? */ -- ./NSFileManager.m: * FIXME ... not sure there is any way to get a creation date :-( ./NSFileManager.m- * Use the earlier of ctime or mtime -- ./NSInvocation.m: /* FIXME: This only appears on sparc and ppc machines so far. ./NSInvocation.m- structures appear to be aligned on word boundaries. -- ./NSKeyedArchiver.m:// FIXME ... exactly what classes are stored directly??? -- ./NSKeyedArchiver.m: _format = NSPropertyListXMLFormat_v1_0; // FIXME ... should be binary. -- ./NSKeyValueObserving.m: * FIXME ... should store an object containing context and options. ./NSKeyValueObserving.m- * For simplicity right now, just store context or a dummy value. -- ./NSKeyValueObserving.m: * FIXME ... support structures ./NSKeyValueObserving.m- * Unsupported types are quietly ignored ... is that right? -- ./NSNumbe
Re: The goal of GNUstep 1.0
On Jeu 27 octobre 2005 18:33, Adrian Robert wrote: > > On Oct 27, 2005, at 9:06 AM, Fabien VALLON wrote: > >> On Mer 26 octobre 2005 17:45, Adam Fedor wrote: >> >> >>> What bugs are you talking about? Perhaps we should prioritize the >>> bugs in >>> the bug database... >>> >> >> Maybye a TODO list ( Roadmap ) before a 1.0 ? >> Or maybye put all this TODO list in the bug system with a special >> entry/status ? >> >> I checked quickly some classes in AppKit ( with the OpenStep >> specs ) to >> see if all methods are implements : > > Great post. This is exactly what we need (IMHO). Then we put them > into a task list and prioritize them according to must-have-by-1.0 > and otherwise.. > > In Foundation, NSNumberFormatter still needs work (Fred just recently > started on it), and perhaps we should add the NSMessagePort > implementation on Windows that Richard has talked about to the 1.0 > list? I don't know if someone is willing to work on it, but I feel a > fully functional Make/Base (not GUI/Back) on Windows should be > prerequisite to 1.0 release. > > There are a number of other "FIXME"s in the Base code, but assumedly > most of these are icing-on-the-cake that can wait (as, hopefully, are > many of the ones in GUI): I updated my tests/checks and put it here : http://www.sonappart.net/gnustep/TODO_AppKit.txt I think we should check the ref. manuals and the OpenStep compliance documentations : http://gnustep.org/resources/documentation/Developer/Gui/Reference/index.html http://gnustep.org/resources/documentation/Developer/Base/Reference/index.html http://gnustep.org/resources/documentation/Developer/Gui/General/OpenStepCompliance.html http://gnustep.org/resources/documentation/Developer/Base/General/OpenStepCompliance.html It would be nice to have an OpenStep only output or at least methods in a different color. I saw that some classes have no documentation and some other are an OpenStep copy ( is it safe ? ) Some/lot of methods have availabilty flag at : "Not in OpenStep/MacOS-X" Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0
> In Foundation, NSNumberFormatter still needs work (Fred just recently > started on it), and perhaps we should add the NSMessagePort > implementation on Windows that Richard has talked about to the 1.0 > list? I don't know if someone is willing to work on it, but I feel a > fully functional Make/Base (not GUI/Back) on Windows should be > prerequisite to 1.0 release. Thanks - I personally think that make/base are ready for 1.0, in fact they are already well over release 1.0 ... eg, make is at 1.11.1 (and btw, OT, I'd suggest when we complete the configure changes and all the other stuff in the roadmap we bump that to gnustep-make version 2 to mark a clear jump). :-) IMO the gui is not ready because it only works with Window Maker. :-( If someone was willing to test the GUI with different window managers and make sure GNUstep applications are usable and behave well with different window managers (which is not necessarily trivial), the gui would be certainly ready for 1.0. :-) In other words, the only thing that is really missing is someone taking Gorm and making sure it works and is usable on all the platforms -- first and foremost the widespread GNU/Unix desktops ... KDE and GNOME (and probably third target is Windows, but I agree we shouldn't be holding 1.0 because of that). Last time I looked at it, anyone downloading GNUstep apps on his/her KDE/GNOME desktop would immediately go crazy with focus issues and get the impression that nothing works and that GNUstep apps are totally unusable and give up. But once that is fixed, I don't see anything stopping us from putting our flag in the ground and declaring that we do have a 1.0 release! :-) The 1.0 GNUstep Release would be a great marketing event so one of the most important things is being ready, marketing-wise, to take advantage of it. And, obviously, we ought to celebrate ... it took 10 years to get here ... to a 1.0 release ...! :-) (and test, test and test a lot). Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0
Now that everybody publishes his private wish list, I will write down my secret agenda for GNUstep 1.0 as well. Of course the main goal is to finish the cairo backend and have it as the offical backend for GNUstep. :-) 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. Simple things that I would like to see in GUI and back to support theming are pattern colours (here I had a patch some months ago which still requires some work) and colour gradients. There are also a few bug reports that look rather serious to me and should be fixed for 1.0. For example, I am thinking of the cursor bug, where the wrong cursor may be left over after closing a window. Also the window manager interaction is on this list. For the GUI classes themselves, I am mostly concerned about the matrix classes. (NSMatrix, NSTableView, NSOutlineView) all of them are not up to a 1.0 release and there is currently nobody working on them. We also should give the text system another polishing and look at the performance issue with window redraws (I published a profining on this). All of this is doable, not even too hard, but take a look at the change log of GUI for the last few months and you will doubt that it is going to happen this year. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0
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.)
Cheers,
David
? bitfields.patch
Index: benchmark.m
===
RCS file: /cvsroot/gnustep/gnustep/core/base/Testing/benchmark.m,v
retrieving revision 1.21
diff -u -r1.21 benchmark.m
--- benchmark.m 25 Sep 2005 17:36:14 - 1.21
+++ benchmark.m 30 Oct 2005 16:08:20 -
@@ -65,6 +65,71 @@
}
@end
[EMAIL PROTECTED] BitField : NSObject
+{
+ struct _bfield {
+unsigned flag1:1;
+unsigned flag2:1;
+unsigned flag3:1;
+unsigned flag4:1;
+unsigned flag5:1;
+ } _flags;
+}
+-(BOOL)flag1;
+-(void)setFlag1:(BOOL)fl;
+-(BOOL)flag2;
+-(void)setFlag2:(BOOL)fl;
+-(BOOL)flag3;
+-(void)setFlag3:(BOOL)fl;
+-(BOOL)flag4;
+-(void)setFlag4:(BOOL)fl;
+-(BOOL)flag5;
+-(void)setFlag5:(BOOL)fl;
[EMAIL PROTECTED]
[EMAIL PROTECTED] BitField
+-(BOOL)flag1 { return _flags.flag1; }
+-(void)setFlag1:(BOOL)fl { _flags.flag1 = fl; };
+-(BOOL)flag2 { return _flags.flag2; }
+-(void)setFlag2:(BOOL)fl { _flags.flag2 = fl; };
+-(BOOL)flag3 { return _flags.flag3; }
+-(void)setFlag3:(BOOL)fl { _flags.flag3 = fl; };
+-(BOOL)flag4 { return _flags.flag4; }
+-(void)setFlag4:(BOOL)fl { _flags.flag4 = fl; };
+-(BOOL)flag5 { return _flags.flag5; }
+-(void)setFlag5:(BOOL)fl { _flags.flag5 = fl; };
[EMAIL PROTECTED]
[EMAIL PROTECTED] NoBitField : NSObject
+{
+ BOOL flag1;
+ BOOL flag2;
+ BOOL flag3;
+ BOOL flag4;
+ BOOL flag5;
+}
+-(BOOL)flag1;
+-(void)setFlag1:(BOOL)fl;
+-(BOOL)flag2;
+-(void)setFlag2:(BOOL)fl;
+-(BOOL)flag3;
+-(void)setFlag3:(BOOL)fl;
+-(BOOL)flag4;
+-(void)setFlag4:(BOOL)fl;
+-(BOOL)flag5;
+-(void)setFlag5:(BOOL)fl;
[EMAIL PROTECTED]
[EMAIL PROTECTED] NoBitField
+-(BOOL)flag1 { return flag1; }
+-(void)setFlag1:(BOOL)fl { flag1 = fl; };
+-(BOOL)flag2 { return flag2; }
+-(void)setFlag2:(BOOL)fl { flag2 = fl; };
+-(BOOL)flag3 { return flag3; }
+-(void)setFlag3:(BOOL)fl { flag3 = fl; };
+-(BOOL)flag4 { return flag4; }
+-(void)setFlag4:(BOOL)fl { flag4 = fl; };
+-(BOOL)flag5 { return flag5; }
+-(void)setFlag5:(BOOL)fl { flag5 = fl; };
[EMAIL PROTECTED]
+
void
bench_object()
{
@@ -736,6 +801,43 @@
AUTO_END;
}
+void
+bench_bitfield()
+{
+ BitField *bf = [[[BitField alloc]init]autorelease];
+ NoBitField *nbf = [[[NoBitField alloc]init]autorelease];
+ unsigned i;
+
+ AUTO_START;
+
+ printf("bitfields\n");
+ START_TIMER;
+ for (i = 0; i < MAX_COUNT*10; i++)
+{
+ [bf setFlag1: [bf flag1]];
+ [bf setFlag2: [bf flag2]];
+ [bf setFlag3: [bf flag3]];
+ [bf setFlag4: [bf flag4]];
+ [bf setFlag5: [bf flag5]];
+}
+ END_TIMER;
+ PRINT_TIMER("bitfields \t\t\t\t");
+
+ START_TIMER;
+ for (i = 0; i < MAX_COUNT*10; i++)
+{
+ [nbf setFlag1: [nbf flag1]];
+ [nbf setFlag2: [nbf flag2]];
+ [nbf setFlag3: [nbf flag3]];
+ [nbf setFlag4: [nbf flag4]];
+ [nbf setFlag5: [nbf flag5]];
+}
+ END_TIMER;
+ PRINT_TIMER("no bitfields \t\t\t\t");
+
+ AUTO_END;
+}
+
int main(int argc, char *argv[], char **env)
{
id pool;
@@ -761,6 +863,11 @@
bench_maptable();
bench_date();
bench_data();
+ bench_bitfield();
+ bench_bitfield();
+ bench_bitfield();
+ bench_bitfield();
+ bench_bitfield();
AUTO_END;
return 0;
}
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0
On 30 Oct 2005, at 16:13, 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 agree that using bitfields may not generally be a good idea, but a stable memory layout certainly is. For many classes, Apple hide the instance variables pretty much entirely, thus allowing instance variable layout to be changed from release to release without break,ing binary compatibility. I think we should consider adopting the same approach. So, we would only have a limited set of instance variables declared (basically those that we want subclasses to be able to access directly), and have all others hidden. a. This can be done by overriding allocWithZone: to call NSAllocateObject() with a non-zero argument for extra space, and storing the hidden instance variables in the extra space. The disadvantage of this is that it makes it difficult/impossible for subclasses to use the same trick of overriding allocation, since they don't know how much extra memory to allocate for the superclass hidden ivars. b. Another possibility is to have a single pointer ivar that we can use to point to a separately allocated chunk of memory containing hidden ivars.The disadvantage of this approach is that each allocation/deallocation requires an extra malloc/free for this additional memory ... that would be a major performance overhead on frequently created/destroyed objects (like cells), but is a negligible issue for big, infrequently allocated objects like windows. c. The third possiblity is to have a load of dummy ivars, and expand into the space occupied by them ... wastes a bit of memory and is less flexible (what if we want to expand the class in a way the dummy ivaars don't allow room for). d. You can also store the extra variables in an NSMapTable keyed on the instance ... but that's really an inefficient variant of option b. I guess we should use a combination of the first three mechanisms (I think Apple do), trying to pick the best scheme for each class. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
Hi Richard, Richard Frith-Macdonald wrote: On 2005-10-26 08:49:52 +0100 Dennis Leeuw <[EMAIL PROTECTED]> wrote: I think it is a clear goal. Something we can all agree on, I don't think there isn't anybody who doesn't want GNUstep to become 1.0. We just need a list of things to be done and a timeframe. Personally I see three, largely independent targets that I think, we should be aiming for ... Target one: As already identified, gui/back reliability/polish/10.0-release ... proibably the most important target ... The two gui/back issues that really annoy me are ... 1. window manager interaction ... I want clicking on windows to work *reliably*, so that when I click on any GNUstep window a. The application activates (shows its menu and panels, and raises the window clicked on). b. The clicked winbdow starts accepting keyboard input c. any other GNUstep application deactivates (hides its menu and panels) 2. popup/pulldown menu operation ... sometimes (often) popup menus seem to fail to track the mouse, so you can't select their buttons. These points seem to me are THE goals for a 1.0 release. My question is about the next one. How much I would want to have Camaelon integrated I think it would be wise to move it to e.g. 1.1. What do you think? And the one new development I'd really like to see is ... Camaelon integration into the gui. I have no particular need for it myself, but it's a good selling point and it's needed for my third main target. Target three: ms-windows support ... we've made a lot of progress on this, but we *should* be taking it a lot further. Personally I want to run GNUstep on windows (when I have to use windows) and have it look/feel like GNUstep/NeXTstep. However, a lot of people want it to look/feel like windows, so we need to have a windows theme (and Camaeleon built into the gui as I mentioned above). We need windows backend/gui development work, and we need to be able to support both windows and OpenStep style inter-application communications (cut/paste, DnD, services, notifications, workspace/session management etc), though this isn't going to happen quickly and must be viewed as a long term goal. Here my question is also, is Windows a 1.0 goal or should it be post-1.0? Of course, there are many other things we want to do, but even concentrating on three main targets is a LOT of work, and I don't think having more than three formal goals is a good idea. I think you are very right. We have to take little steps at a time. Thank you so much for this input. I think a task list is now emerging for a clear defined goal. Let's here some more input! With kind regards, Dennis Leeuw ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On 2005-10-26 12:13:41 +0100 Dennis Leeuw <[EMAIL PROTECTED]> wrote: 1. window manager interaction ... I want clicking on windows to work *reliably*, so that when I click on any GNUstep window a. The application activates (shows its menu and panels, and raises the window clicked on). b. The clicked winbdow starts accepting keyboard input c. any other GNUstep application deactivates (hides its menu and panels) 2. popup/pulldown menu operation ... sometimes (often) popup menus seem to fail to track the mouse, so you can't select their buttons. These points seem to me are THE goals for a 1.0 release. My question is about the next one. How much I would want to have Camaelon integrated I think it would be wise to move it to e.g. 1.1. What do you think? Well I *think* that Camaeleon integration should be a relatively straightforward task, and while I have no personal need for it, the topic of themes interests a lot of people, so I would *like* to see it real soon. Here my question is also, is Windows a 1.0 goal or should it be post-1.0? I don't think so ... my feeling is that it would be a lot of work to get to the level of polish needed for a 1.0 release ... so unless we are setting this 1.0 release target quite a long time away, I think it's impractical to include windows as part of the 1.0 gui release. I suggested three targets as general medium term project aims (a general roadmap if you like), in the order that's my best guess as to priority for the purposes of popularising GNUstep. I think we should concentrate on the first, but keep the others in mind. So, to get back to the 1.0 release idea ... Highest priority ... fixing bugs that annoy people when they are using the gui (I'm sure other people use different apps and have different annoyances) ... I view that as essential for a release ... but it doesn't mean we shouldn't be improving documentation and testsuite and adding things like Camaeleon too. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On Mer 26 octobre 2005 15:29, Richard Frith-Macdonald wrote: > On 2005-10-26 12:13:41 +0100 Dennis Leeuw <[EMAIL PROTECTED]> wrote: >> Here my question is also, is Windows a 1.0 goal or should it be >> post-1.0? > > I don't think so ... my feeling is that it would be a lot of work to get > to > the level of polish needed for a 1.0 release ... so unless we are setting > this 1.0 release target quite a long time away, I think it's impractical > to > include windows as part of the 1.0 gui release. > > I suggested three targets as general medium term project aims (a general > roadmap if you like), in the order that's my best guess as to priority for > the purposes of popularising GNUstep. I think we should concentrate on > the > first, but keep the others in mind. > > So, to get back to the 1.0 release idea ... > Highest priority ... fixing bugs that annoy people when they are using the > gui (I'm sure other people use different apps and have different > annoyances) > ... I view that as essential for a release ... but it doesn't mean we > shouldn't be improving documentation and testsuite and adding things like > Camaeleon too. I agree. For the 1.0 release, what do you think about an "OpenStep-compliant release" ? - This is the first goal of GNUstep. - There is already some bugs to fix for "OpenStep-compliants" classes. - There is already documentation for "OpenStep-compliants" classes. I think developpers can only target on it for the 1.0. 1.2 could be Windows / OpenStep + bug fix About Cocoa ( the Cocoa in MacOS 10.1 for example ) could be a 2.0 target. Can we create a GNUstepAppleExtentions in a separate framework for it ? Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On Wed, Oct 26, 2005 at 04:55:22PM +0200, Fabien VALLON wrote: > On Mer 26 octobre 2005 15:29, Richard Frith-Macdonald wrote: > > > > So, to get back to the 1.0 release idea ... > > Highest priority ... fixing bugs that annoy people when they are using the > > gui (I'm sure other people use different apps and have different > > annoyances) > > ... I view that as essential for a release ... but it doesn't mean we > > shouldn't be improving documentation and testsuite and adding things like > > Camaeleon too. > > > I agree. > > For the 1.0 release, what do you think about an > "OpenStep-compliant release" ? > > - This is the first goal of GNUstep. > - There is already some bugs to fix for "OpenStep-compliants" classes. > - There is already documentation for "OpenStep-compliants" classes. > > I think developpers can only target on it for the 1.0. > > 1.2 could be Windows / OpenStep + bug fix > > About Cocoa ( the Cocoa in MacOS 10.1 for example ) could be a 2.0 target. > Can we create a GNUstepAppleExtentions in a separate framework for it ? Version 1.0 doesn't have to be perfect for each platform, just for one (at least ;-) In terms of features - I think the GNUstep community can now stand on it's own when deciding what's in and out of a 1.0. Some features we'd all really like may just get deferred. That's ok. My favourite platform might not make the cut as a "featured platform", that's ok too, as long as we have good release notes describing the open issues. You might market 1.0 as being QA'd on several variants of Linux, FreeBSD and NetBSD (with per-platform native binaries/installers, setup documentation, release notes, LiveCDs etc). Cooperation with distributions and software packagers needs to be fairly tight. Other platforms might be marked as "preview release" but also have the per-platform native binaries, setup documentation etc, or not, depending on resources and stability. As the date for the release draws closer, and expected features completed or deferred, the serious bugs-list squashed we need to be ready to really polish a couple of platforms and at least one LiveCD. Non-developers will be especially necessary for these activities: testing documentation, configuration, tweaking for look and feel. A lot of this stuff could be usefully coordinated by a release team or release manager, and it's a great way of getting the broader GNUstep community involved. Regards Peter ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
> -Original Message- > From: Fabien VALLON > > For the 1.0 release, what do you think about an > "OpenStep-compliant release" ? > > - This is the first goal of GNUstep. > - There is already some bugs to fix for "OpenStep-compliants" classes. > - There is already documentation for "OpenStep-compliants" classes. > > Well, it's a bit boring. People will say, 'hey, you've caught up with 1999'. Anyway, we're pretty much OpenStep compliant except for some trivial methods. What bugs are you talking about? Perhaps we should prioritize the bugs in the bug database... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On 10/26/05, Adam Fedor <[EMAIL PROTECTED]> wrote: > > -Original Message- > > From: Fabien VALLON > > > > For the 1.0 release, what do you think about an > > "OpenStep-compliant release" ? > > > > - This is the first goal of GNUstep. > > - There is already some bugs to fix for "OpenStep-compliants" classes. > > - There is already documentation for "OpenStep-compliants" classes. > > Well, it's a bit boring. People will say, 'hey, you've caught up with 1999'. > Anyway, we're pretty much OpenStep > compliant except for some trivial methods. I agree; OpenStep-compliance shouldn't be anymore the definitive goal anyway.. By that I mean that if there are some obscure deprecated methods that we don't have yet, I'm not sure it's worth implementing them/delay a 1.0 just to claim "hey we're _fully_ OpenStep compliant !" -- it's not like many people care about that (they care about OSX compatibility if anything else). Same way, I don't think it's a good idea to orientate the 1.0 as "Finally OpenStep-compliant", because as you say, the epidermic reaction will be "yeah, good job guys, only 11 years to do it !". It would be more interesting to say something along the line of "we're OpenStep compliant, we have our own additions, plus we are x% compatible with Panther/Tiger ...", etc. -- Nicolas Roard "Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On 2005-10-26 15:55:22 +0100 Fabien VALLON <[EMAIL PROTECTED]> wrote: For the 1.0 release, what do you think about an "OpenStep-compliant release" ? - This is the first goal of GNUstep. - There is already some bugs to fix for "OpenStep-compliants" classes. - There is already documentation for "OpenStep-compliants" classes. I think developpers can only target on it for the 1.0. I wouldn't get hung up about compliance ... some OpenStep stuff may not be implemented for years (if ever) as nobody uses it ... if it was dropped from OPENSTEP 4.? or early MacOS-X for instance. Part of the reason I think having a centralised set of applications under the GNUstep umbrella is that they could consitute a gui testbed of sorts ... what I think we want to see from a 1.0 release is not necessarily complete implementation of a particular API, but rather a core library distribution which gives us a *delightful* (not just workable) user experience with common applications on at least one core platform (eg. gnu/linux, X, windowmaker) more if we can manage it. That is to say, the parts of the library we want to work 'perfectly' are those parts used by the apps most people will want to use. 1.2 could be Windows / OpenStep + bug fix About Cocoa ( the Cocoa in MacOS 10.1 for example ) could be a 2.0 target. Can we create a GNUstepAppleExtentions in a separate framework for it ? I think a set of API compliance targets is probably not good except as a rough guideline ... there is a mixture of good stuff and rubbish in the moving target that is MacOS-X, so I think we should try to make sure that we are compatible where we implement the same methods/classes, but not try to do everything. As far as separate frameworks go (I prefer simple libraries unless there is actually a good reason to use a framework), I do think it would be good to have a structured approach. I'd like to see at least the following non-core library or framework packages - 1. base extras, gnustep specific eg. linked list implementation of NSMutableArray, a cache class, perhaps the classes I put in the SQLClient library etc. 2. base extras, apple specific eg.apple core data if anyone is interested in contributing it. 3. gui extras, gnustep specific eg. the equivalent of the MiscKit stuff 4. gui extras, apple specific apple stuff that we don't want to support as 'core', but would like someone to contribute. The main reason I've not done anything about this is that I don't know what to do about access control and copyright assignment issues. Perhaps we need to have two lots of each library ... one for code where people have assigned copyright to the FSF and one where they haven't. I'd like things like this to be as readily accessible as possible (ie mean write access to the source code repository), but we obviously grant free access for people who haven't done an FSF copyright assignment to code that's signed over to the FSF. Ideally we'd combine both FSF and non-FSF classes in the same library, but have the SCM control who could access which class ... but I don't know if any SCM gives us that sort of control ... the gnu arch stuff looks interesting for that sort of customisability, maybe svn can do it too? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On Mer 26 octobre 2005 17:45, Adam Fedor wrote: > > >> -Original Message- >> From: Fabien VALLON >> >> For the 1.0 release, what do you think about an >> "OpenStep-compliant release" ? >> >> - This is the first goal of GNUstep. >> - There is already some bugs to fix for "OpenStep-compliants" classes. >> - There is already documentation for "OpenStep-compliants" classes. >> > > Well, it's a bit boring. People will say, 'hey, you've caught up with > 1999'. Anyway, we're pretty much OpenStep > compliant except for some trivial methods. Good, you can release 1.0 now ( "OpenStep-compliant" ;-) Before that I think developers should : * Check if all OpenStep methods/classes are implemented and if not, implement them or add it in documentation ( ex: in http://gnustep.org/resources/documentation/Developer/Gui/General/OpenStepCompliance.html Nothing about NSBTreeBlock and some others ( removed because they are no longer part of OpenStep standard ) ) * Check if STRICT_OPENSTEP preproc condition is used everywhere ( when required ) * IMO autogsdoc should clearly mark methods "supported" for 1.0 (OpenStep-compliance) ( with a different color for html output for example ) * Fix some classes in -gui : NSColorPanel / Printing / NSWorkspace / Events loop troubles and Window Manager "integration" * Check if all methods for 1.0 are fully documented * Choose a default backend (?) * Maybye add a test suite for the 1.0 * Test 1.0 in predifined OS target ( Linux / *BSD for example ) and backend ( XFree86 / X.org ) Then release a Release condidate and find packagers ( marketing ;) Cheers Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On Mer 26 octobre 2005 18:00, Nicolas Roard wrote:
> On 10/26/05, Adam Fedor <[EMAIL PROTECTED]> wrote:
>> > -Original Message-
>> > From: Fabien VALLON
>> >
>> > For the 1.0 release, what do you think about an
>> > "OpenStep-compliant release" ?
>> >
>> > - This is the first goal of GNUstep.
>> > - There is already some bugs to fix for "OpenStep-compliants" classes.
>> > - There is already documentation for "OpenStep-compliants" classes.
>>
>> Well, it's a bit boring. People will say, 'hey, you've caught up with
>> 1999'. Anyway, we're pretty much OpenStep
>> compliant except for some trivial methods.
>
> I agree; OpenStep-compliance shouldn't be anymore the definitive goal
> anyway..
The first goal.
Probably not the definitive, I agree.
I think it is a good, short, way to relase 1.0.
Focus on BSD/Linux/Cups/XFree/OpenStep only can help to :
- Finally have a release
- Finish some classes
- Finish some doc
> By that I mean that if there are some obscure deprecated methods that
> we don't have yet, I'm not sure it's worth implementing them/delay a
> 1.0 just to claim "hey we're _fully_ OpenStep compliant !" -- it's not
> like many people care about that (they care about OSX compatibility if
> anything else).
Of course,
But it is not the case, and it will never be OSX ( current version )
compatible.
You will never release GNUstep if you follow Apple.
Having a 2.0 release with Cocoa ("10.2 compliance") or windows will take
longer.
I believe at the "Release early release often".
> Same way, I don't think it's a good idea to orientate the 1.0 as
> "Finally OpenStep-compliant", because as you say, the epidermic
> reaction will be "yeah, good job guys, only 11 years to do it !".
And ?
who cares.
It was hard work for the GNUstep developpers.
Those guys are just stupid, don't listen to them.
>It would be more interesting to say something along the line of "we're
> OpenStep compliant, we have our own additions, plus we are x%
> compatible with Panther/Tiger ...", etc.
That not exclusiv.
Having ref. doc saying what should work and what should not would be great.
But not a "Panther compliant" release ( not for 1.0 ).
Fabien
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
> -Original Message- > From: Fabien VALLON > * Check if all OpenStep methods/classes are > implemented and if not, > implement them or add it in documentation > ( ex: in > http://gnustep.org/resources/documentation/Developer/Gui/Gener al/OpenStepCompliance.html Nothing about NSBTreeBlock and some others ( removed because they are no longer part of OpenStep standard ) ) See also http://gnustep.org/resources/documentation/Developer/Base/General/OpenStepCompliance.html ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On 10/26/05, Fabien VALLON <[EMAIL PROTECTED]> wrote:
> > By that I mean that if there are some obscure deprecated methods that
> > we don't have yet, I'm not sure it's worth implementing them/delay a
> > 1.0 just to claim "hey we're _fully_ OpenStep compliant !" -- it's not
> > like many people care about that (they care about OSX compatibility if
> > anything else).
>
> Of course,
> But it is not the case, and it will never be OSX ( current version )
> compatible.
Yes, but an important point is an easy for a developer to see what is
implemented is what isn't. We lack a bit of clarity here (that could
probably be resolved via the doc system).
> You will never release GNUstep if you follow Apple.
Of course, I didn't advocate to hold GNUstep until we're 100%
compatible with current Cocoa.. I was merely pointing that "OpenStep"
compliance is not really relevant today.
> Having a 2.0 release with Cocoa ("10.2 compliance") or windows will take
> longer.
>
> I believe at the "Release early release often".
I completely agree with you.
> > Same way, I don't think it's a good idea to orientate the 1.0 as
> > "Finally OpenStep-compliant", because as you say, the epidermic
> > reaction will be "yeah, good job guys, only 11 years to do it !".
>
> And ?
> who cares.
> It was hard work for the GNUstep developpers.
> Those guys are just stupid, don't listen to them.
Well, my wording was perhaps not right; what I meant is, you can't
boast a lot on OpenStep compliance when releasing a 1.0 when this
actually has very little importance for most of the people -- it's
counter-productive if you want to attract people. Of course, it is
important; just not a good "attraction" argument, and can even be
turned into a bad argument. I was just pointing that.
> >It would be more interesting to say something along the line of "we're
> > OpenStep compliant, we have our own additions, plus we are x%
> > compatible with Panther/Tiger ...", etc.
>
> That not exclusiv.
Of course. I don't care even about % of compatibility, but it's just
that we should have clearer presentation of what's actually
available/possible with GNUstep and the degree of compatibility with
OSX (imagine a cocoa dev going to gnustep.org for the first time and
trying to figure if its cocoa software can be ported to gnustep, and
what difficulties he can encounteer).
> Having ref. doc saying what should work and what should not would be great.
> But not a "Panther compliant" release ( not for 1.0 ).
yep.
--
Nicolas Roard
"Any sufficiently advanced technology is indistinguishable from magic."
-Arthur C. Clarke
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On Mer 26 octobre 2005 17:45, Adam Fedor wrote:
> What bugs are you talking about? Perhaps we should prioritize the bugs in
> the bug database...
Maybye a TODO list ( Roadmap ) before a 1.0 ?
Or maybye put all this TODO list in the bug system with a special
entry/status ?
I checked quickly some classes in AppKit ( with the OpenStep specs ) to
see if all methods are implements :
This is what I found ( from NSActionCell to NSImage )
* NSActionCell:
setFont:
// TODO: This should also set the font of the text object, when selected
* NSApplication :
activateIgnoringOtherApps:
// TODO: Currently the flag is ignored
/* We need give input focus to some window otherwise we'll never get
keyboard events. FIXME: doesn't work. */
deactivate
// FIXME: main window is not saved for when the app is activated again.
// This is not a problem if it is also key, and I'm not sure if it
// is a problem at all. May be annoying in the case of workspace switch.
makeWindowsPerform: inOrder:
// FIXME flag ignored
preventWindowOrdering
//TODO
* NSBitmapImageRep :
TIFFRepresentationOfImageRepsInArray:
//FIXME: This only outputs one of the ImageReps
TIFFRepresentationOfImageRepsInArray: usingCompression: factor:
//FIXME: This only outputs one of the ImageReps
* NSBox:
setTitle:
// TODO: implement the macosx behaviour for setTitle:
( Note : not now )
* NSBrowser :
- (float) titleHeight
{
// Nextish look requires 21 here
return 21;
}
(Note : looks strange ?)
frameOfInsideOfColumn:
// xxx what does this one do?
tile: // FIXME: in some cases the column is not loaded
* NSButtonCell :
setImagePosition: // In the GNUstep NSButtonCell implementation, the
cell type depends only on the image position. ( is it correct ? )
setType: Ditto
* NSCachedImageRep :
initWithSize: depth:separate: alpha:
// FIXME: Only create new window when separate is YES
* NSCell :
cellSizeForBounds: // TODO: Resize the text to fit
Sets whether the NSCell's text is word-wrapped. : Does it work ??
editWithFrame: inView:editor: delegate: event:
* FIXME/TODO make sure this is correct. */
selectWithFrame: inView: editor: delegate: start: length:
/* FIXME/TODO make sure this is correct. */
setEntryType: // TODO: This should select a suitable formatter
setFloatingPointFormat: left: right:
// TODO: Pass this on to the formatter to handle
drawInteriorWithFrame: inView:
//FIXME: Check if this is also neccessary for images,
// Add spacing between border and inside
highlight: withFrame: inView:
/* FIXME - This looks like potentially generating an
* infinite loop! The control asking the cell to draw
* itself in the rect, the cell asking the control to draw
* the rect, the control asking the cell to draw itself in
* the rect, the cell ...
*
* I think we should remove it. The control is responsible
* for using the cell to draw, not vice versa.
*/
- (void) getPeriodicDelay: (float*)delay interval: (float*)interval
{
*delay = 0.1;
*interval = 0.1;
}
( Note no configuration ? )
setRepresentedObject:
/* Ahm - not nice - the RETAIN here could cause retain cycles - anyway. */
* NSClipView :
setDocumentView:
/* TODO: Adjust the key view loop to include the new document view */
initWithCoder: // FIXME setCopiesOnScroll: setDrawsBackground:
NSCoderAddition : Pre OpenStep ( check the doc )
* NSColor:
CMYK color ( ? check doc ) : Retrieving a Set of Components methods
colorUsingColorSpaceName: device:
// FIXME: If the deviceDescription is nil, we should get it from the
// current view or printer
// Is there a cache hit?
// FIXME How would we detect that the cache has become invalid by a
// change to the colour list?
colorWithAlphaComponent: // FIXME: We cannot convert to named color space.
colorFromPasteboard: // FIXME: This should better use the description
format
writeToPasteboard: // FIXME: We should better use the description
encodeWithCoder: // FIXME: Missing handling of alpha value
* NSColorList:
initWithName: fromFile:
// TODO [Optm]: Rewrite to initialize directly without unarchiving
// in another object
writeToFile:
// FIXME the standard path for saving color lists?
_loadAvailableColorLists:
/*
* Load color lists found in standard paths into the array
* FIXME: Check exactly where in the directory tree we should scan.
*/
_readTextColorFile:
//FIXME- replace this by switch on method to different
// NSColor initializers
* NSCursor :
hotSpot // FIXME: This wont work for the standard cursor
image // FIXME: This wont work for the standard cursor
encodeWithCoder: // FIXME: This wont work for the two standard cursor
initWithcoder: // FIXME
* NSCustomImageRep:
initWithDrawSelector:delegate:
/* WARNING: Retaining the delegate may or may not create a cyclic graph */
* NSDataLink: Does it work ?
* NSDataLinkManager
addLinkAsMarker: at: // FIXME: Marker?
* NSDataLinkPanel
accessoryView // not yet implemented.
setAccessoryView: // not yet implemented.
NSFont
widths: not implemented (
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On Mer 26 octobre 2005 20:32, Nicolas Roard wrote: > On 10/26/05, Fabien VALLON <[EMAIL PROTECTED]> wrote: >> You will never release GNUstep if you follow Apple. > Of course, I didn't advocate to hold GNUstep until we're 100% > compatible with current Cocoa.. I was merely pointing that "OpenStep" > compliance is not really relevant today. It is. Do you think that glib ( gnome ) is better than Foundation As well documented, and constant Ditto for gtk ? Do we need to be bloat as Java-SWING to release something ? There is lot of nice app based on OpenStep implementations. And GNUstep already have lot of Apple extensions ! > Well, my wording was perhaps not right; what I meant is, you can't > boast a lot on OpenStep compliance when releasing a 1.0 when this > actually has very little importance for most of the people -- it's > counter-productive if you want to attract people. You will never attract people because you will never release something. Cocoa dev don't care about GNUstep if it does not work on Windows ( I completly agree with greg Casamento on that ) I think GNUstep can release seomething every 6 months with true goals I just sugest: 1- 1.0 == "OpenStep compliant" on Linux/BSD/Cups/XFree 2- 1.X ( or 2.0 ) == "OpenStep compliant" on Windows too ( it is already lot of work : NSWorkspace=>ie.exe ( integration ) / backend / Themes more or less Windows compliant ( Camaleon ? ) / Windows menu style . ) 3- 2.X ( or 3.0 ) == "Cocoa ( Panther ) compliant" with nib loading xCode project loading etc etc. Developers need to have a real Roadmap with a TODO list for each release. I think they can even have intemediate release between (1) and (2) - ex : 1.2 Themes engine ( with a Windows theme engine ) 1.4 Backend working + Windows menu style ( with nice screenshots :) 1.6 NSWokspace / ie.exe integration ( + help + printing ? ) and so on ... This means more noise for other developpers ( to attract people ) And more "short" goal for GNUstep developpers ( this is the current state, this is where we go ) I think it is less frustating. Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
On Mer 26 octobre 2005 19:50, Adam Fedor wrote: > > >> -Original Message- >> From: Fabien VALLON > * Check if all OpenStep methods/classes are >> implemented and if not, >> implement them or add it in documentation >> ( ex: in >> http://gnustep.org/resources/documentation/Developer/Gui/Gener > al/OpenStepCompliance.html > Nothing about NSBTreeBlock and some others ( removed because they are no > longer part of OpenStep standard ) ) > > See also > > http://gnustep.org/resources/documentation/Developer/Base/General/OpenStepCompliance.html True. I think it should be fix here : http://gnustep.org/developers/documentation.html (OpenStep and OS X Compliance) Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: The goal of GNUstep 1.0 (Why Unanimous Consent Doesn't Work)
i'll just pick a random post, and reply to this one...
--- Richard Frith-Macdonald <[EMAIL PROTECTED]>
wrote:
> On 2005-10-26 12:13:41 +0100 Dennis Leeuw
> <[EMAIL PROTECTED]> wrote:
>
> >
>
> >> 1. window manager interaction ... I want clicking
> on windows to work
> >> *reliably*, so that when I click on any GNUstep
> window
> >> a. The application activates (shows its menu and
> panels, and raises the
> >> window clicked on).
similar to application activation is re-activation
currently when activating a hidden application windows
are stacked in the order they were created no the
order when they were hidden
possible with wm's supporting
_NET_CLIENT_LIST_STACKING, actually have a patch
somewhere for this i'll attempt to dig up...
then default to the current re-activate in the order
created
> >> b. The clicked winbdow starts accepting keyboard
> input
> >> c. any other GNUstep application deactivates
> (hides its menu and panels)
> >>
> >> 2. popup/pulldown menu operation ... sometimes
> (often) popup menus seem to
> >> fail to track the mouse, so you can't select
> their buttons.
> >
> >
> > These points seem to me are THE goals for a 1.0
> release. My question is
> > about
> > the next one. How much I would want to have
> Camaelon integrated I think it
> > would be wise to move it to e.g. 1.1.
> > What do you think?
>
> Well I *think* that Camaeleon integration should be
> a relatively
> straightforward task, and while I have no personal
> need for it, the topic of
> themes interests a lot of people, so I would *like*
> to see it real soon.
>
documentation stuff,
it'd be nice if autogsdoc could be able to group
methods into alphabetically sorted groups
so set/ret methods could be near each other etc...
while yeah i understand this would require extra
markup
heres some stuff i noticed when running my app with
Camaelon which needs work on the -gui side of things
summary:
a) switch button image affects themes
b) i'm lazy and don't think i should have to have 2
images with opposite colors for switch buttons in
columns and table column header..
my typical extra long explaination:
background: app with a table view, with lots of
columns of switch buttons each column has a specific
non-checkmark image as the switch button 'on state'
and the table column header image.
common_{SwitchOn,SwitchOff}.tiff are used in place of
drawing the image inside the button...
attempting to use a normal button with an image and
you get a button the entire size of the column not
centered in it,
i believe that NSButtonCell should be respecting
NS*ControlSize and switch buttons should be of
NSSmallControlSize button type and draw centered in
the cell frame, if the frame is larger than the set
control size.
then common_SwitchOff.tiff can just go away
because currently when theming my app the switch
button image has to be created with the switch button
background.. switch themes and it looks gross
similar issue with NSTableColumnHeaderCell where our
table column header background color is dark, and the
control color is light
so i need 2 images, one for the table column header
image (light with no background), and one for the
switch button dark with a switch button background...
on macs/openstep the colors aren't so different and
switch button images don't contain the switch button
frame/bezel style, so you can use the same image for
both...
other random stuff,
i'd also like to see lots of graphs
not just class diagrams, but stuff like state diagrams
of events coming out of the backends and how they're
handled by various controls for example...
NSCell's working better outside of their various views
can't think of anything though...
matt
__
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
