Re: GNUstep ROADMAP
Richard Frith-Macdonald schrieb: I'm with Fred on this one ... certainly on partially implemented classes, but also (though less strongly) on completely empty ones. I think there is absolutely zero risk of someone wasting loads of time porting only to find something critical missing... as long as our documentation does not tell lies (and little chance of it even then). We do need to make sure that the documentation is up to date, so it says which methods of which classes are unimplemented. IMO partially implemented classes tell people that there is some hope of the classes being done in future ... or at least that the GNUstep project would look favourably upon people contributing in those areas. In fact it would probably be good if unimplemented methods actually generated an NSLog explicitly asking for an implementation to be contributed. Maybe I should add a macro to NSDebug.h to do that? Having a completely unimplemented class there gives us a good placeholder for the documentation that tells people that the class is unimplemented, and maybe what the current plans are for it. I can see the argument here for removing the class (people aren't likely to think the class exists if there is no trace of it), but I think that a header file that's clearly a shell, and documentation that states that the class is unimplemented, is equally clear. We could document such empty classes with a note to say that someone (or nobody) is working on them, and a pointer to the task list on the website for current status. FWIW, I agree. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
Citát David Ayers [EMAIL PROTECTED]: Richard Frith-Macdonald schrieb: snip Having a completely unimplemented class there gives us a good placeholder for the documentation that tells people that the class is unimplemented, and maybe what the current plans are for it. I can see the argument here for removing the class (people aren't likely to think the class exists if there is no trace of it), but I think that a header file that's clearly a shell, and documentation that states that the class is unimplemented, is equally clear. We could document such empty classes with a note to say that someone (or nobody) is working on them, and a pointer to the task list on the website for current status. FWIW, I agree. How difficult it would be to hack autogsdoc objective-c parser to parse GNUstep sources and generate a list of unimplemented methods (either marked as not implemented or being only in @interface)? Simple html table (with css): | Class | Method | Description | Stefan -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
On 28 Nov 2005, at 09:17, Stefan Urbanek wrote: How difficult it would be to hack autogsdoc objective-c parser to parse GNUstep sources and generate a list of unimplemented methods (either marked as not implemented or being only in @interface)? Simple html table (with css): | Class | Method | Description | Easy to get the parser to recognise empty implementations ... but what to do about it is not clear. I like the idea though. How about ... if the parser could warn about empty implementations, so we know when something needs doing, and if no documentation comment is provided for the method, it could generate standard stuff about the method not being implemented yet (in the place where is currently generates the 'documentation forthcoming' message. Generally, if a class is abstract/semi-abstract then subclasses are supposed to override methods ... so an empty implementation here could be quite OK ... but we could get the parser to check to see if it has seen the override-subclass / markup in the comment for the method, and accept an empty implementation as OK in that case. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
Citát Richard Frith-Macdonald [EMAIL PROTECTED]: On 28 Nov 2005, at 09:17, Stefan Urbanek wrote: How difficult it would be to hack autogsdoc objective-c parser to parse GNUstep sources and generate a list of unimplemented methods (either marked as not implemented or being only in @interface)? Simple html table (with css): | Class | Method | Description | Easy to get the parser to recognise empty implementations ... but what to do about it is not clear. Put on the webpage: development wanted. I like the idea though. How about ... if the parser could warn about empty implementations, so we know when something needs doing, and if no documentation comment is provided for the method, it could generate standard stuff about the method not being implemented yet (in the place where is currently generates the 'documentation forthcoming' message. It can be good for documentation where target would be GNUstep-core developers. However, for GNUstep users (developers of gnustep frameworks or applications) it would be a noise in the documentation. On the other hand, it can serve as a signal for developers that are willing to contribute... Generally, if a class is abstract/semi-abstract then subclasses are supposed to override methods ... so an empty implementation here could be quite OK ... but we could get the parser to check to see if it has seen the override-subclass / markup in the comment for the method, and accept an empty implementation as OK in that case. Sounds good. Stefan -- http://stefan.agentfarms.net First they ignore you, then they laugh at you, then they fight you, then you win. - Mahatma Gandhi ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
Richard, --- Richard Frith-Macdonald [EMAIL PROTECTED] wrote: I'm with Fred on this one ... certainly on partially implemented classes, but also (though less strongly) on completely empty ones. I think there is absolutely zero risk of someone wasting loads of time porting only to find something critical missing... as long as our documentation does not tell lies (and little chance of it even then). We do need to make sure that the documentation is up to date, so it says which methods of which classes are unimplemented. IMO partially implemented classes tell people that there is some hope of the classes being done in future ... or at least that the GNUstep project would look favourably upon people contributing in those areas. In fact it would probably be good if unimplemented methods actually generated an NSLog explicitly asking for an implementation to be contributed. Maybe I should add a macro to NSDebug.h to do that? Having a completely unimplemented class there gives us a good placeholder for the documentation that tells people that the class is unimplemented, and maybe what the current plans are for it. I can see the argument here for removing the class (people aren't likely to think the class exists if there is no trace of it), but I think that a header file that's clearly a shell, and documentation that states that the class is unimplemented, is equally clear. We could document such empty classes with a note to say that someone (or nobody) is working on them, and a pointer to the task list on the website for current status. Okay, you've convinced me. I agree. :) So long as the documentation is clear, I see no issue. Later, GJC Gregory John Casamento -- Principal Consultant, Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
On Nov 26, 2005, at 11:23 AM, Adrian Robert wrote: GNUstep 1.1 Integrate camaelon into gui ... I think this should be in 1.0 as a matter of practicality ... as far as I can see, this is an easily achievable target, so why not do it soon. I really think this needs to go into 1.0. Judging by the amount of discussion themes ALWAYS get whenever there is ANY external publicity about GNUstep, I think initial reception will be far better if we can just say, "download and switch on this theme" instead of "someday we'll have Camealon in GNUstep". Let's not be impatient for the 1.0 release and then have lots of people dismissing it with "great, but too 80's for me".. Integration of WildMenus ... I haven't looked at this, so i don't know, but seems reasonable. This on the other hand, we rarely hear about on the lists, so I think it's a much lower priority than Camaelon. I'm new here, and obviously, much genuflection to everyone involved... but I just wanted to say from an outsider's standpoint, camaelon IMO is an absolute requirement to have in 1.0. I'm sure there's lots of arguments on why not to do it, but from an outsider standpoint, it's a must-have.WRT WildMenus - WildMenus is useful if one is coming from a Mac, and wants Mac style menus... I'd argue that alone makes it worthwhile - but the thing that would make it really killer would be if it could also attach the menus to whatever main window there is currently (ala Windows etc) to make GNUstep apps not look like the "odd man out" when mixing on other window managers/desktops. I know this is not a trivial task. WildMenus - though cool, and I obviously use it myself, I think is not vital for a 1.0. 1.1 sure... when it gets a nice overhaul with a clock and little status applets like the mac menu, or if it gets the ability to do windows-like menus... (:: sounds of screams from GNUstep purists ::) -- Jiva DeVoe http://www.devoesquared.com PowerCard - Intuitive Project Management for Mac OS X ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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
Fred, --- Fred Kiefer [EMAIL PROTECTED] wrote: 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. I see what you mean. Our ivar layout should be stable before we release a 1.0, I agree. 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. Okay. 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. But we're being inconsistent. What if my application uses NSInputStream, which currently is not implemented in GNUstep? Should it not work by the same token as above? 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? I believe you know what I
Re: GNUstep ROADMAP
On 28 Nov 2005, at 02:17, Gregory John Casamento wrote: Fred, --- Fred Kiefer [EMAIL PROTECTED] wrote: When I started with GNUstep, most of the GUI classes where empty declarations, which needed filling out and that was what I did. Having empty declarations is okay for something that's in beta, however, for a 1.0, I'm not sure that we should include those classes which are simply empty declarations. 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 output honest warnings about missing code. Having a method not implemented macro in some GNUstep header file could help here. (What about using GSOnceMLog for that?) I really would rather save the developer time and expense of porting an application only to have it say NSException: This functionality is not currently implemented at runtime. If it were me, I would be supremely frustrated that I spent hours porting something only for it to fail at runtime. I'm with Fred on this one ... certainly on partially implemented classes, but also (though less strongly) on completely empty ones. I think there is absolutely zero risk of someone wasting loads of time porting only to find something critical missing... as long as our documentation does not tell lies (and little chance of it even then). We do need to make sure that the documentation is up to date, so it says which methods of which classes are unimplemented. IMO partially implemented classes tell people that there is some hope of the classes being done in future ... or at least that the GNUstep project would look favourably upon people contributing in those areas. In fact it would probably be good if unimplemented methods actually generated an NSLog explicitly asking for an implementation to be contributed. Maybe I should add a macro to NSDebug.h to do that? Having a completely unimplemented class there gives us a good placeholder for the documentation that tells people that the class is unimplemented, and maybe what the current plans are for it. I can see the argument here for removing the class (people aren't likely to think the class exists if there is no trace of it), but I think that a header file that's clearly a shell, and documentation that states that the class is unimplemented, is equally clear. We could document such empty classes with a note to say that someone (or nobody) is working on them, and a pointer to the task list on the website for current status. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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
Re: GNUstep ROADMAP
Richard Frith-Macdonald wrote:
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
In my opinion it's definitely a 1.0 issue. A short explanation why:
* it's high-lighting assumptions and specifications made in the codebase for
unix generally and window maker specifically.
* focus issues are, to varying degrees, problems on KDE, GNOME etc as well
* add to that window manager interaction. We're not doing well with other
window managers.
I'd but back with gui because the two really do go together. We should consider
base, make and GUI as three separate categories and focus on what needs to be
done on each.
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.
Hear, hear!
2. gui seems wildly ambitious (complete coding on all existing classes) .
I'm not sure what 'improve printing support' entails
The 'fix major bugs' is obviously required, but we should decide on
what those bugs are
I haven't heard anyone suggesting removal of classes before, and I
don't approve of the idea ... rather we should have *big* warnings
about works in progress so that people don't try to use them unless
they are also willing to work on improving them. (ie clear information
in the docs and warnings generated at runtime).
Complete coding on all existing classes.
Remove any classes which are not going to be finished for or included in the
1.0 release.
These two seem to be contradictory: we'll complete everything except those we
don't be completing which we'll remove instead so we can say its all complete.
I think the map should really be *much* more specific about what needs to be
done:
- Documentation
- alpha/compositing support
- themes
- panel auto-sizing and layout
- architectural changes to improve platform/desktop support work
Breakup of gui and base into component libraries ... I've never heard
of this and haven't seen anything saying why it would be at all
desirable, let alone worth making into a target.
Well I can see why some things may be worth separating out. For example,
Openstep actually had a separate pdo library. Headers in Foundation, linking
and using not a problem. It could help contain areas of functionality. This may
help in a few ways technically, but also might make maintenance easier in that
we could allocate a maintainer to a smaller code-base. It may also encourage
competing implementations or people assisting in the more specific arenas of
interest to them. Right now trying to get involved is somewhat daunting because
of the size and complexity of the libraries.
I definitely think that the IconApp (aka 'fiend') code should be entirely
separated out and become a loadable-bundle/whatever. It is NeXT desktop
specific and should be packaged accordingly. Just as other features may be
specific to other desktop environments.
I can see some cause for separating parts of image support so that the imaging
can rely on different libraries. More front-end/back-end stuff.
Some are interested in, for example, NSNetService and friends. We should be
able to add those in as base extensions.
Anyway, I don't remember any proposals being put forward and this is definitely
a dicussion for a different thread.
Make GNUstep more compliant with the FHS as an option ... this ought to
be quite easy ... so why not make it part of 1.0 if it's actually a
good 'selling' point?
I've done much on this. Some parts are easier but we can get a whole lot more
compliant without breakage or significant inconvenience. The level of
compliance we can achieve is pretty close to Debian.
{If we can make it there we can make it anywhere...}
The only problem in doing this is the amount of configuration involved to
tailor the installation. My idea was always for this to be for package
maintainers ony.
Again, specifics should be a different thread.
Better Windows support ... yes ... but we need to get windows users to
define what they need improving
I have a long list (of not just my own items) so I guess I should put together
the Road to Windows?
Regards,
Sheldon
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
Fred, --- Fred Kiefer [EMAIL PROTECTED] wrote: 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? Could you elaborate on this point? 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? 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. I agree with this. 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? 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. 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. 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. I'm sure that you know I don't mean that. :) I'll clarify the Roadmap to indicate shell classes with no implementation at all. My fault for not being clear enough. 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)
