Re: GNUstep ROADMAP
On 26 Nov 2005, at 06:05, Gregory John Casamento wrote: Here is the Roadmap: http://mediawiki.gnustep.org/index.php/Roadmap If you are a maintainer, please make any changes for your section that you deem appropriate. Rather than changing anything, I'd like to query some things because things on that page differ from my impressions of what's been discussed on the mailing list, so I guess I'm missing out on stuff. 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. 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). 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. Integration of WildMenus ... I haven't looked at this, so i don't know, but seems reasonable. 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. 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? Better Windows support ... yes ... but we need to get windows users to define what they need improving Nib support in gui and Gorm ... you know best on this ... very good if you can do it in time for a 1.1 release ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
[Gnustep-cvs] GNUstep Testfarm Results
Test results for GNUstep as of Sat Nov 26 06:34:25 EST 2005 If a particular system failed compilation, the logs for that system will be placed at ftp://ftp.gnustep.org/pub/testfarm If you would like to add your machine to this list, set up a cron job (make sure you set up your PATH and other environment variables correctly) to run the Startup/scripts/test-gnustep script (see the script comments for more info). Success Compile i386-unknown-netbsdelf2.1.0. Sat Nov 26 03:58:21 CET 2005 Success Compile powerpc-apple-darwin7.9.0 Sat Nov 26 03:27:43 MST 2005 Success Compile sparc-sun-solaris2.7 Sat Nov 26 02:08:03 EST 2005
Re: GNUstep ROADMAP
On Sam 26 novembre 2005 9:16, Richard Frith-Macdonald wrote: > > On 26 Nov 2005, at 06:05, Gregory John Casamento wrote: > >> Here is the Roadmap: >> >> http://mediawiki.gnustep.org/index.php/Roadmap >> >> If you are a maintainer, please make any changes for your section >> that you deem >> appropriate. > > Rather than changing anything, I'd like to query some things because > things on that page differ from my impressions of what's been > discussed on the mailing list, so I guess I'm missing out on stuff. > > 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. I think we should separated base/make/back. back on MS-Window is not for 1.0. base/make is probably ok ? > 2. gui seems wildly ambitious (complete coding on all existing > classes) . I agree. I think an OpenStep classes are enough if you want to release at the first quarter of 2006. I started to write/improve documentation for OpenStep Gui classes/method and there is a lot of work to do ( doc / some fixes ) >The 'fix major bugs' is obviously required, but we should decide on >what those bugs are I agree. We should also add a "1.0" Status into Tasks / bugs at savannah. What about documentation requirement ? I think it a must to attracked developpers. Fabien ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep ROADMAP
Richard, See below... --- Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: > > On 26 Nov 2005, at 06:05, Gregory John Casamento wrote: > > > Here is the Roadmap: > > > > http://mediawiki.gnustep.org/index.php/Roadmap > > > > If you are a maintainer, please make any changes for your section > > that you deem > > appropriate. > > Rather than changing anything, I'd like to query some things because > things on that page differ from my impressions of what's been > discussed on the mailing list, so I guess I'm missing out on stuff. > > 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. Windows support is coming along, but I don't think it's realistic to expect 1.0 level support soon. > 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?? > I'm not sure what 'improve printing support' entails Me neither, but this is something I would consider to be essential for a 1.0 release. > The 'fix major bugs' is obviously required, but we should decide on > what those bugs are Yes. > 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). > > 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. > > Integration of WildMenus ... I haven't looked at this, so i don't > know, but seems reasonable. > > 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. > > 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 wanted to keep the 1.0 as simple as possible. > Better Windows support ... yes ... but we need to get windows users > to define what they need improving We've already had some comment on the theme. > Nib support in gui and Gorm ... you know best on this ... very good > if you can do it in time for a 1.1 release It may or may not make it for a 1.1 release. Thanks, 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 10:21 AM, Gregory John Casamento wrote: Richard, See below... --- Richard Frith-Macdonald <[EMAIL PROTECTED]> wrote: On 26 Nov 2005, at 06:05, Gregory John Casamento wrote: Here is the Roadmap: http://mediawiki.gnustep.org/index.php/Roadmap If you are a maintainer, please make any changes for your section that you deem appropriate. ... 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. Agreed. ... 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. Something that's not mentioned in the list but I think is important for smoothing the entry of new users is a Preferences app. There are all of these half-started preferences projects, it shouldn't take long for a motivated person to gather these pieces and produce something that puts up a graphical front for most of the gui/back defaults and perhaps assists with Camaelon theme setting. GNUstep is supposed to be easy to develop with, and we have GORM, so this shouldn't be rocket science. Finally, TextEdit and Terminal out of backbone should be made part of the release. I'm not saying backbone shouldn't remain a separate project. But, just like GNOME ships a bunch of basic apps in its distribution, I think these utilities should be part of a "base gnustep install". Both are probably sufficiently stable now, although supporting background color changing in Terminal and fixing some miscellaneous unimplemented areas in TextEdit would probably go far towards improving the perceived polish. It would be nice to include the PDF and image viewers as well, but these are further from 1.0 state. What about GNUMail? What about documentation requirement ? I think it a must to attracked developpers. I agree here -- the documentation should at least not have large blank and "description forthcoming" areas. I'll try to find some time to help work on this. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Notification once a minute - for a clock...
So I'm sorta hacking on WildMenus this weekend, and have implemented a primitive clock in the menubar... I'm wondering what's the best way to get my clock to redraw once a minute? Obviously the menu code itself gets linked into each application, so having 20 applications all launching their own little background timers to update the menubar clock sounds kinda cruddy. What would be the best way to do this? I imagine some kind of NSNotification but that also seems cruddy.(ps: For those who want said functionality - I have been sending patches to Michael Hanni, the WildMenus maintainer, so look for a release from him eventually.) -- 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: DO compatibility with Apple DO
Jiva DeVoe wrote: > What're the technical barriers that prevent GS DO from being compatible > with Apple DO? > > What's the chances of those being overcome? > I know this is not the most polite answer, but this question is on our FAQ. As I needed some time to find the Developer FAQ on our web site myself, I will share the answer with you: 1.1.4 Can I transfer archived data from GNUstep to Cocoa? Apple's archiving format is proprietary and not documented, so this poses a problem for anyone wanting to implement compatibility with it. However, even if we reverse engineered the format, there are enough differences between the class and ivar layouts to make this sort of compatibility difficult. Not to mention the fact that we would constantly have to keep up with the changes Apple made. Also Apple's archiving format, as far as we know, would not be compatible between different machines because of endiness issues, although GNUstep doesn't have this problem. Your best bet is to implement your own archiving format that would work both with GNUstep and Cocoa. Fortunately, you don't have to start from scratch, since this has been essentially done for you in the nib2gmodel tool, which has an archiver that works both on GNUstep and Cocoa. It might be nice to split this off into a separate project to make it easier for other people to do the same thing. 1.1.5 Does distributed objects work between GNUstep and Cocoa? See the answer to the previous question (on archive compatibility) for why this won't work either. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: DO compatibility with Apple DO
Fair enough, sorry for asking a Q already answered there.I wonder if the change to OS X 86 + their XML format for archiving holds any new hope for compatibility... does it? I suppose not.On Nov 26, 2005, at 8:10 PM, Fred Kiefer wrote:Jiva DeVoe wrote: What're the technical barriers that prevent GS DO from being compatiblewith Apple DO?What's the chances of those being overcome? I know this is not the most polite answer, but this question is on ourFAQ. As I needed some time to find the Developer FAQ on our web sitemyself, I will share the answer with you:1.1.4 Can I transfer archived data from GNUstep to Cocoa? Apple's archiving format is proprietary and not documented, so thisposes a problem for anyone wanting to implement compatibility with it.However, even if we reverse engineered the format, there are enoughdifferences between the class and ivar layouts to make this sort ofcompatibility difficult. Not to mention the fact that we wouldconstantly have to keep up with the changes Apple made. Also Apple'sarchiving format, as far as we know, would not be compatible betweendifferent machines because of endiness issues, although GNUstep doesn'thave this problem. Your best bet is to implement your own archiving format that would workboth with GNUstep and Cocoa. Fortunately, you don't have to start fromscratch, since this has been essentially done for you in the nib2gmodeltool, which has an archiver that works both on GNUstep and Cocoa. Itmight be nice to split this off into a separate project to make iteasier for other people to do the same thing. 1.1.5 Does distributed objects work between GNUstep and Cocoa? See the answer to the previous question (on archive compatibility) forwhy this won't work either. -- 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: >>> 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: DO compatibility with Apple DO
On 11/27/05, Jiva DeVoe <[EMAIL PROTECTED]> wrote: > Fair enough, sorry for asking a Q already answered there. > > I wonder if the change to OS X 86 + their XML format for archiving holds any > new hope for compatibility... does it? I suppose not. Well, if Cocoa uses XML for DO exchanges, I guess it could be possible in theory to have a compatible DO between GNUstep and OSX. But I really don't know if they use (or can be set up to use) XML instead of binary serialization for DO.. could be worth checking. -- 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: DO compatibility with Apple DO
Yeah, the problem is, you'd have to be SURE Apple was using the XML format for all DO operations - and I'd bet you couldn't do that.Oh well.Again, sorry for bringing up a topic that's in the FAQ.On Nov 26, 2005, at 9:01 PM, Nicolas Roard wrote:On 11/27/05, Jiva DeVoe <[EMAIL PROTECTED]> wrote: Fair enough, sorry for asking a Q already answered there.I wonder if the change to OS X 86 + their XML format for archiving holds anynew hope for compatibility... does it? I suppose not. Well, if Cocoa uses XML for DO exchanges, I guess it could be possiblein theory to have a compatible DO between GNUstep and OSX. But Ireally don't know if they use (or can be set up to use) XML instead ofbinary serialization for DO.. could be worth checking.--Nicolas Roard"Any sufficiently advanced technology is indistinguishable from magic." -Arthur C. Clarke -- 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
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: DO compatibility with Apple DO
Jiva DeVoe wrote: Yeah, the problem is, you'd have to be SURE Apple was using the XML format for all DO operations - and I'd bet you couldn't do that. Oh well. Again, sorry for bringing up a topic that's in the FAQ. Actually, although quite a challenge I think it should be possible get a reasonable degree of inter-operability by installing a daemon on MacOS which will do GDO over the wire and call out to PDO... Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: DO compatibility with Apple DO
H - now that's an interesting idea...But how to differentiate between identically named classes on GNUstep vs Mac OS in the bridge server?Would also be pretty slow too I'd bet.On Nov 26, 2005, at 9:56 PM, Sheldon Gill wrote:Jiva DeVoe wrote: Yeah, the problem is, you'd have to be SURE Apple was using the XML format for all DO operations - and I'd bet you couldn't do that.Oh well.Again, sorry for bringing up a topic that's in the FAQ. Actually, although quite a challenge I think it should be possible get a reasonable degree of inter-operability by installing a daemon on MacOS which will do GDO over the wire and call out to PDO...Regards,Sheldon -- 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
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
Re: GNUstep ROADMAP
Sheldon,
--- Sheldon Gill <[EMAIL PROTECTED]> wrote:
> 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.
Agreed.
> > 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.
Hehe. :) This is my fault for not being clear.
In GNUstep there are some class files which are just placeholders, such as
NSMovie and NSMovieView, which have no implementation. We need to decide which
of these placeholder classes will get implementations and which ones will be
pushed off into the next release. Those that will be pushed off to the next
release will be removed from the repository.
I just think that it's wrong to call something 1.0 and deliver classes which
are entirely empty.
> 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
Re: GNUstep ROADMAP
I think Fred and other's have said similar things, but I'd like to echo that the 1.0 release should emphasis user visible changes: focus issues windows compatibility stable interface packaging basic user apps (Preferences.app has been on my wish list for eons!) I also agree with Greg that the release should happen soon. I know that's tough, but that just means we need to think hard about what really needs to be done. I don't think we'll solve these issues perfectly, but we should make things look reasonably nice. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
