Re: GNUstep moving forward
Quoting Gregory John Casamento [EMAIL PROTECTED]: Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. It currently still lacks many features, but what is done: - bundle extensible project type - allows for arbitrary file layout (through grouping files in abstract `categories' (sort-of like directories, but not really on disk)) - build error interpretation - errors are grouped in a table, double click on a row and the error file opens, highlighting the error line. - fully functional code editor (except for colouring... but I'm working on it) + line/character indication and Go To Line... + autoindentation + customizable external command output piping + customizable tab to space conversion Comments are welcome, though please still consider the code practically a tech-demo, I would not have released it for another two weeks (currently working on it about two weeks already) if this discussion would not have come up. As to the other developer tools: - after I finish ProjectManager at least to some degree (or somebody takes over for me, since a day only has 24 hours...) I'm back off to GNUstep Core Data (http://gscoredata.nongnu.org) and over there is an app called DataBuilder which allows users to easily assemble data models for use with GSCoredata. - if there's interrest in an app like ObjectAlloc (a real-time object allocation monitor) I can assemble it in a day or two. I already did it some years ago (though never got to releasing it...), but the idea is still in my head, so it should be a matter of a couple of moments. Regards -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Hello, On Saturday, October 22, 2005, at 12:46 PM, Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. for me too, it has become sometimes a cause of frustration. Since I have put it as only graphical environment on my NetBSD/ppc computer and as the default one on my laptop for months now, I feel all the problems, missing things even more. 1) More apps. Many of the following points will help with this, but this is very important. I think this is of uttermost importance. We had many talks of dedicated distributions, special desktop environments, but everybody seems to forget applications. ALso many persons, including developers, might be more attracted by having a more complete environment where for example choices exists. Some people like to have the ability to choose between different programs that do task X. And, remember, for some tasks we don't even have a single choice. 2) Better theme support. Integration of Camaelon into the core gui library if possible I agree that we need better theme support, especially when thinking about impure platforms like running gnustep applications inside windows, motif or gnome environments. I would strongly dislike a direct integration of camaleon or equivalents in gnustep itself directly, but I'd like it to be a no-brainer installation. That is something that can be built and installed without efforts (thinking for example that in a linux distribution it may be a theme support package that can be installed and removed with no harm) 3) Better win32 support. Many companies are really eager to port their legacy NeXTSTEP/OPENSTEP or Cocoa apps to GNUstep under Windows. The prospect of Linux and BSD support appeals to them as well, but not as much as Windows. I currently have two companies with whom I am talking about this. I too had people almost catching interest in gnustep but when they heard about essentially non-existent windows support... interest waned. Some people wouldn't even care for linux or solaris, but just about windows and mac for their applications. We might not like this, but it is the truth out there. 4) Better distro support. We really need to get GNUstep into as many distributions as possile, this will ramp up exposure of GNUstep to more people and help us get more developers and users. I agree here. Currently I know we are in Debian and Gentoo and NetBSD. I don't know the state of the latter, but the first two are in terrible shape. For example my own PRICE is on both many minor and major releases old... Why? serious problems compiling new versions? Or lack of care? It is bad publicity essentially. And yes we all know that guys at Debian have serious brain problems... but well... What about Redhat, suse, yellowdog and madriva? I know they are very very popular. RPM. based. And OpenBSD and FreeBSD? How is the status there? Also having packages for sunfreeware for solaris 2.5 and up might be quite cool too. The site recently started accepting user contributions. Getting into a distribution gets us exposure, but it is also a double-bladed axe: we get to the public, but if we give out a bad impressions.. well you know how people react if too many things are missing, broken... people installing from distributions won't question the quality of the framework, but just the sheer amount of applications available and their look and workings. Thus... staying in a distribution but remaining there unupdated is dangerous. Also most of the usable applications should be immediately available. We as a project need to be more adaptive and less resistant to change. More than anything right now we need to consider the audience we are playing to. GNUstep needs to be better able to integrate with other environments. even more than that the gnustep community should be able to collaborate. As I noted above, many persons work on their own pet-projects (as is often natural in volunteer efforts) but the common parts of projects may be overseen thus duplicating the effort and spreading our already thin coding efforts. So although I think it is important that we integrate with other environments (windows, gnome and kde come to my mind), I wouldn't put this item very high in our priority list, at least not now. But I wouldn't cancel it either: I mean that if an incompatibility can be easily avoided or integration can be done without a bigger cost of complexity or bloat in gnustep it should be done. Cheers, R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Proposal: Subversion Migration
Hey, On Friday, October 21, 2005, at 10:50 PM, Adam Fedor wrote: Plus we can't say, 'just update from CVS' to everyone who has a problem anymore. Most people won't have svn, even if they knew how to do that stuff. We need to update things like the daily snapshots. I wonder if we could still mirror the repository on CVS? Either at gna or savannah. Even if it is read-only. Yes, I would find this very positive. That the mainstream of svn got mirrored back in CVS. Although still, we are fine with CVS on savannah. It's nice being there, despite all the problems. -R ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Andriy Gapon schrieb: In my opinion what NSSearchPathForDirectoriesInDomains() does now is incorrect. I don't have an opportunity to verify how this function behaves in original NeXTStep or how it behaves in OS X framework, but I think GNUstep behavior is unreasonable. I see two possible ways of improving NSSearchPathForDirectoriesInDomains(): 1. just return the names and let calling code worry if the directories actually exist 2. try to create non-existing directories in the list and only if that fails that remove them from the list I personally am torn between simplicity and elegance of #1 and user-friendliness of #2. I remember looking into this exact issue once but I can't remember that I came to a conclusion of what the right thing to do is. I don't have OS X but IIRC I was told that the directory was created together with the account. So what ever the behavior is, I guess it can be viewed as undefined as it doesn't really exist on OS X without manipulation of the expected setup. If we chose #1 then it would be the application's (or non-core library's) job to create the directory if it doesn't exist before writing to it. I think that would just push the bug to different place. Yet if we chose #2 then we could be cluttering the home directory of say a packaging user who implicitly runs gnustep programs during the build process... But I think we already do that for user defaults anyway and that's what I thought could be handled by setting GNUSTEP_USER_DIR. So I would lean toward #2 right now... but I have a gut feeling I'm still missing some implication. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
David Ayers schrieb: Andriy Gapon schrieb: In my opinion what NSSearchPathForDirectoriesInDomains() does now is incorrect. I don't have an opportunity to verify how this function behaves in original NeXTStep or how it behaves in OS X framework, but I think GNUstep behavior is unreasonable. I see two possible ways of improving NSSearchPathForDirectoriesInDomains(): 1. just return the names and let calling code worry if the directories actually exist 2. try to create non-existing directories in the list and only if that fails that remove them from the list I personally am torn between simplicity and elegance of #1 and user-friendliness of #2. I remember looking into this exact issue once but I can't remember that I came to a conclusion of what the right thing to do is. Nothing is quite as effective at refreshing ones memory as the send button :-) Actually the bug is in NSColorList writeToFile: because there is clear documentation at: http://developer.apple.com/documentation/Cocoa/Conceptual/LowLevelFileMgmt/Tasks/LocatingDirectories.html which states: However, don’t make any assumptions as to the number of paths returned. Some domains or locations might be made obsolete over time, or other new domains or locations might be added (while preserving the older ones); in either case, the number of paths in the returned array might increase or decrease. ... I suppose that writeToFile: http://developer.apple.com/documentation/Cocoa/Reference/ApplicationKit/ObjC_classic/Classes/NSColorList.html which states: If path is nil, this method saves the file as listname.clr in the user’s private colorlists directory. should simply return NO in that case. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Project Manager/Center (Was: Re: GNUstep moving forward)
Citát Sašo Kiselkov [EMAIL PROTECTED]: Quoting Gregory John Casamento [EMAIL PROTECTED]: Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. It currently still lacks many features, but what is done: snip Comments are welcome, though please still consider the code practically a tech-demo, I would not have released it for another two weeks (currently working on it about two weeks already) if this discussion would not have come up. Just few links that can contain either ideas or pieces of code: IDE: http://ide.roard.com/wakka.php?wiki=Main IDE GUI: http://ide.roard.com/wakka.php?wiki=BasicOrganization DevelKit: http://mediawiki.gnustep.org/index.php/DevelopmentKit (feel free to use/reuse/integrate develkit) Images for inspiration: Actors in Gorm: http://camaelon.blogspot.com/2005/06/it-works.html Ambrai Smalltalk: http://ambrai.com/smalltalk/screenshots/index.html Regards, Stefan Urbanek -- 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
why do we need change?
Hello, I will put my thoughts down very bluntly thus try to get the meaning and don't stop too much on the form. My question is essentially... why do we need a change in gnustep? The pope recently said continuous change is evil. ANd I agree, it is one of the things that in computing is disturbing me most. You need to accomplish task X and are using tool Y. Tool Y requires library A and B. Now you have a bug in Y. Suddenly you realize that there is no bug fix, but you need to upgrade Y to Y2... but Y2 does require version A2 which.. stupidly requires a tool Z2 to just get (any hint to svn is purely coincidental) it and it might even happen you might need a new compiler to build the whole thing. And you end up discovering that things changed too much, you need to relearn everything, your preferences are lost and at the end you are just frustrated. I am not advocating to stop every change, but just to ponder changes and additions carefully, the more they are low level and at the end gnustep core itself is the foundation of everything. This to write that personally I don't feel all that urgent change in -core of gnustep! People seem to hint we need a revolution and powerful tools to do it, but I think -core is already in a powerful shape that could lead to the writing to a whole OS with applications (aren't we almost openstep?). What I think we need most now is an evolutionary approach in fixing and stabilizing the core itself and providing the best tools for development and a desktop environment. This is a way to get exposure, to stabilize things and getting a good release on which to build upon later without spreading our resources too thin. Also, the only way of finding weak spots in a library is to actually use it to build a lot of serious stuff and not just dreaming of integrating the latest and coolest technology we have heard of. Once we have done our gnome 1 with gtk1 step using current tools we might think what to do next. I personally would think weary about a step like doing gtk2/gnome2 at the beginning, but it is too easy to speak now. Since we have a cousin which gets developed and is called macosx it can be wise to keep an eye on it too.. but the current approach which is try to do a bit of everything is not proving out well with our current limited set of resources. Of course, this too, may change. So it might be interesting not only to think about a gnustep roadmap but a gnustep environment roadmap trying to think in a broader view. Cheers, Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
On Oct 24, 2005, at 5:08 AM, Sašo Kiselkov wrote: Quoting Gregory John Casamento [EMAIL PROTECTED]: Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. Hi, Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. It currently still lacks many features, but what is done: Why not help out on ProjectCenter? Instead of having two halfway-useful IDE's, maybe we could have one powerful one.. Specific comments below.. - bundle extensible project type Project Center has this. - allows for arbitrary file layout (through grouping files in abstract `categories' (sort-of like directories, but not really on disk)) Project Center could use this. XCode has it, so users that also develop on Apple will grok it (and indeed, would like it). - build error interpretation - errors are grouped in a table, double click on a row and the error file opens, highlighting the error line. XCode (and I think ProjectBuilder) had this. It would be nice to enhance ProjectCenter to have it too. - fully functional code editor (except for colouring... but I'm working on it) + line/character indication and Go To Line... + autoindentation + customizable external command output piping + customizable tab to space conversion You can try writing an editor from scratch, but unless you pump a LOT of time into it you'll end up with something that someone will shift away from once they have some real work to do. Project Center has Emacs integration via gnuclient, and in my opinion this is the most sensible way to go. Add Vim integration or your other favorite editor, improve the richness of the interface between IDE and editor, etc.. I talked to the maintainer of ProjectCenter about this a year and a half ago, and he had some ideas to move forward, but neither of us got the time to do it. If you are still insistent on this, take a look at http://www.nongnu.org/codeeditor/ , or TextEdit here: http://www.nongnu.org/backbone/apps.html . Both would be good starting points. Alternatively, an idea I had was to bundle http://emacs-on-aqua.sf.net into a framework so you could have an emacs pane wherever you needed an editor panel. This would be a bit of work, but a whole lot less than writing your own editor, and the result would be truly excellent. (Also, I think the emacs-20-based emacs-on-aqua is a good base, lighter-weight than the upcoming emacs-23-based port -- http://emacs-app.sf.net.) Comments are welcome, though please still consider the code practically a tech-demo, I would not have released it for another two weeks (currently working on it about two weeks already) if this discussion would not have come up. I strongly encourage you to think about working on Project Center. Much of the grunt work that you'll have to redo is already done, it has a nice clean interface so far, with plenty of scope for extension, and it's design is fundamentally familiar to Apple developers, so more widespread adoption is likely. If you still want to explore making your own IDE for a while, please at least consider integrating some of your code into ProjectCenter at some point. thanks, Adrian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
snip, very good analyiss Suggested next steps: snip - define project roles (and use person redundancy) and last, but not least: - observe and copy behaviour of successful players (*) Stefan I like to comment on your final next steps on mainly on Cbjective-C language. IMO, from a sysadmin's perpective. Objective-C is not popular is becuase it is not easy to get a project done. not like perl(or python), there are tons of library/classes can be used already on CPAN. when I need to write a script or program, what I need to do is really just assemble lego blocks, find the object library and put them together. break it apart and reassemble it to different structure that I like. If I choose to use objective-C to implement my project, I need to write all the classess(modules, in perl's term). there are no existing classes in public domain that I can use to avoid the wheel reinvention. I kow we have misckit, kits from omniweb etc. but we need a central repository to store all those object kit or IC pak. I still have hope for objective-C lanauage and GNUStep. I like to see and help them propser. T.J. Yang Regards, Stefan Urbanek (*) there are many inferior projects that have great success compared to their alternatives. If it is not in the idea behind, then whay it is? Go, find out and apply to GNUstep. Reasons are various, including: community suppport, poject management, knowledge management, publicity and visibility (if it is visible, it should be good, no?), friendliness, openness, flashiness, coolness, colourfulness -- 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 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Quoting Adrian Robert [EMAIL PROTECTED]: On Oct 24, 2005, at 5:08 AM, Sa#65533;o Kiselkov wrote: Quoting Gregory John Casamento [EMAIL PROTECTED]: Although we have Gorm and ProjectCenter, I believe we do need more to make GNUstep attractive to devs. Some debugging (think MallocDebug) tools and other things might be nice in this regard. Also, a fully working ProjectCenter would be good as well. Hi, Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. It currently still lacks many features, but what is done: Why not help out on ProjectCenter? Instead of having two halfway-useful IDE's, maybe we could have one powerful one.. Specific comments below.. - bundle extensible project type Project Center has this. - allows for arbitrary file layout (through grouping files in abstract `categories' (sort-of like directories, but not really on disk)) Project Center could use this. XCode has it, so users that also develop on Apple will grok it (and indeed, would like it). - build error interpretation - errors are grouped in a table, double click on a row and the error file opens, highlighting the error line. XCode (and I think ProjectBuilder) had this. It would be nice to enhance ProjectCenter to have it too. - fully functional code editor (except for colouring... but I'm working on it) + line/character indication and Go To Line... + autoindentation + customizable external command output piping + customizable tab to space conversion You can try writing an editor from scratch, but unless you pump a LOT of time into it you'll end up with something that someone will shift away from once they have some real work to do. Project Center has Emacs integration via gnuclient, and in my opinion this is the most sensible way to go. Add Vim integration or your other favorite editor, improve the richness of the interface between IDE and editor, etc.. I talked to the maintainer of ProjectCenter about this a year and a half ago, and he had some ideas to move forward, but neither of us got the time to do it. If you are still insistent on this, take a look at http://www.nongnu.org/codeeditor/ , or TextEdit here: http://www.nongnu.org/backbone/apps.html . Both would be good starting points. Alternatively, an idea I had was to bundle http://emacs-on-aqua.sf.net into a framework so you could have an emacs pane wherever you needed an editor panel. This would be a bit of work, but a whole lot less than writing your own editor, and the result would be truly excellent. (Also, I think the emacs-20-based emacs-on-aqua is a good base, lighter-weight than the upcoming emacs-23-based port -- http://emacs-app.sf.net.) Comments are welcome, though please still consider the code practically a tech-demo, I would not have released it for another two weeks (currently working on it about two weeks already) if this discussion would not have come up. I strongly encourage you to think about working on Project Center. Much of the grunt work that you'll have to redo is already done, it has a nice clean interface so far, with plenty of scope for extension, and it's design is fundamentally familiar to Apple developers, so more widespread adoption is likely. If you still want to explore making your own IDE for a while, please at least consider integrating some of your code into ProjectCenter at some point. thanks, Adrian I know that extending ProjectCenter might be a nice and great way to reuse it's code, but personally I'd like to redesign some of it's aspects from grounds up and integrating those changes in PC would be basically redoing much of it, introducing new bugs and a lot of headche than if I did it from scratch. As for the editor: having interfaces to various user-configurable editors is great, but it would be ok to have a usable one in the base package as well... Just have something, extensions can be added later. That's my opinion. -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Riccardo, --- Riccardo [EMAIL PROTECTED] wrote: Hello, On Saturday, October 22, 2005, at 12:46 PM, Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. for me too, it has become sometimes a cause of frustration. Since I have put it as only graphical environment on my NetBSD/ppc computer and as the default one on my laptop for months now, I feel all the problems, missing things even more. 1) More apps. Many of the following points will help with this, but this is very important. I think this is of uttermost importance. We had many talks of dedicated distributions, special desktop environments, but everybody seems to forget applications. ALso many persons, including developers, might be more attracted by having a more complete environment where for example choices exists. Some people like to have the ability to choose between different programs that do task X. And, remember, for some tasks we don't even have a single choice. We are in agreement here. 2) Better theme support. Integration of Camaelon into the core gui library if possible I agree that we need better theme support, especially when thinking about impure platforms like running gnustep applications inside windows, motif or gnome environments. I would strongly dislike a direct integration of camaleon or equivalents in gnustep itself directly, but I'd like it to be a no-brainer installation. That is something that can be built and installed without efforts (thinking for example that in a linux distribution it may be a theme support package that can be installed and removed with no harm) The problem is that unless it is directly integrated, it's capabilities are relatively limited. It is architecturally cleaner to separate out all of the gui drawing code into a theme and have a theme manager built in. Direct integration also forces developers to take into account that their apps might run with many different looks. While these looks shouldn't effect the basic layout of the app (i.e. position and size should be constants in any theme) the fact that the theme engine is now PART of GNUstep might make them think a little more about how apps are designed in the first place. 3) Better win32 support. Many companies are really eager to port their legacy NeXTSTEP/OPENSTEP or Cocoa apps to GNUstep under Windows. The prospect of Linux and BSD support appeals to them as well, but not as much as Windows. I currently have two companies with whom I am talking about this. I too had people almost catching interest in gnustep but when they heard about essentially non-existent windows support... interest waned. Some people wouldn't even care for linux or solaris, but just about windows and mac for their applications. We might not like this, but it is the truth out there. I have a couple of potential jobs pending in this direction. There is *GREAT* interest among the Mac community in getting thier apps running on Windows. It would be a shame if we miss an opporunity like that to get more developers and users. 4) Better distro support. We really need to get GNUstep into as many distributions as possile, this will ramp up exposure of GNUstep to more people and help us get more developers and users. I agree here. Currently I know we are in Debian and Gentoo and NetBSD. I don't know the state of the latter, but the first two are in terrible shape. For example my own PRICE is on both many minor and major releases old... Why? serious problems compiling new versions? Or lack of care? It is bad publicity essentially. And yes we all know that guys at Debian have serious brain problems... but well... What about Redhat, suse, yellowdog and madriva? I know they are very very popular. RPM. based. And OpenBSD and FreeBSD? How is the status there? Also having packages for sunfreeware for solaris 2.5 and up might be quite cool too. The site recently started accepting user contributions. Getting into a distribution gets us exposure, but it is also a double-bladed axe: we get to the public, but if we give out a bad impressions.. well you know how people react if too many things are missing, broken... people installing from distributions won't question the quality of the framework, but just the sheer amount of applications available and their look and workings. Thus... staying in a distribution but remaining there unupdated is dangerous. Also most of the usable applications should be immediately available. The more exposure the more people who will come to help. It's a vicious cycle. Unless we get the exposure GNUstep will continue to remain in one place. We as a project need to be more adaptive and less resistant to change. More than anything right now we need to consider the audience we are playing to. GNUstep needs to be
Re: NSSearchPathForDirectoriesInDomains and non-existing directories
Andriy Gapon wrote: Let me shoot the question first - what is the rationale behind NSSearchPathForDirectoriesInDomains not returning directory name if the directory does not exist ? Esp. so if NSUserDomainMask is used ? This is the way the function was defined to work a long time ago. In other words, it behaves as specified. The idea in general terms is that you are asking for a location. If that location doesn't exist, it returns nil rather than an exception. The location may not exist because you're running on an old or new version where it doesn't exist anymore. Things change. Calling code is supposed to know and respect this. In my opinion what NSSearchPathForDirectoriesInDomains() does now is incorrect. I don't have an opportunity to verify how this function behaves in original NeXTStep or how it behaves in OS X framework, but I think GNUstep behavior is unreasonable. I see two possible ways of improving NSSearchPathForDirectoriesInDomains(): 1. just return the names and let calling code worry if the directories actually exist 2. try to create non-existing directories in the list and only if that fails that remove them from the list I personally am torn between simplicity and elegance of #1 and user-friendliness of #2. I think you've mis-diagnosed the behaviour problem. It isn't in NSSearchPath() but rather the calling code. Creation of a path isn't and shouldn't be the responsibility of NSSearchPath(). That needs to be handled elsewhere. Generally it is, by the way. There is some sense in (1) but the question arises: what do you do when the specified directory doesn't make sense on the current system? You'd end up needing to handle an exception or error return anyway. Regards, Sheldon ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: why do we need change?
Riccardo, --- Riccardo [EMAIL PROTECTED] wrote: Hello, I will put my thoughts down very bluntly thus try to get the meaning and don't stop too much on the form. My question is essentially... why do we need a change in gnustep? We need change in GNUstep to make it more palatable to a wider audience. While most of us are perfectly content to use a gui which was designed in the late 80's and early 90's, most people want something more. They want themeability and they want the freedom to endlessly customize thier desktop. This is something that people have been able to do on Windows for years. But this is about more than themeability, among other things it's also about the fact that we also need to make it so that GNUstep is friendlier to people who aren't experts. Currently installing GNUstep is much harder than it should be. Most novices are unable to install all of the dependencies. I think a better question is Why should GNUstep sit still. The nswer is, of course, that it shouldn't. The pope recently said continuous change is evil. ANd I agree, it is one of the things that in computing is disturbing me most. You need to accomplish task X and are using tool Y. Tool Y requires library A and B. Now you have a bug in Y. Suddenly you realize that there is no bug fix, but you need to upgrade Y to Y2... but Y2 does require version A2 which.. stupidly requires a tool Z2 to just get (any hint to svn is purely coincidental) it and it might even happen you might need a new compiler to build the whole thing. And you end up discovering that things changed too much, you need to relearn everything, your preferences are lost and at the end you are just frustrated. Change is a fact of life in this industry more than any other. I have heard the expression if airplane technology had advanced as fast as computing technology, we would all be flying around at lightspeed in little boxes the size of a matchbox many many times. So, if you dislike change, the computing industry will deal you much disappointment. I am not advocating to stop every change, but just to ponder changes and additions carefully, the more they are low level and at the end gnustep core itself is the foundation of everything. Most of the things currently being considered have been on the table for a while. The changes will not happen overnight, but gradually. This to write that personally I don't feel all that urgent change in -core of gnustep! People seem to hint we need a revolution and powerful tools to do it, but I think -core is already in a powerful shape that could lead to the writing to a whole OS with applications (aren't we almost openstep?). We are, but we need to be more than OpenStep, if the project is to survive. I, for one, am not satisfied with just a few users liking our stuff. We need to make GNUstep appeal to a larger audience. As I said before there are some companies I have spoken to which are interested in porting applications from Mac OS X to GNUstep on Linux or Windows. I have seen people hesitate in using GNUstep because of it's interface. In some cases, this might mean integrating features that not everyone will like, but if it means more users, then it will mean more developers, and thus more apps. What I think we need most now is an evolutionary approach in fixing and stabilizing the core itself and providing the best tools for development and a desktop environment. This is a way to get exposure, to stabilize things and getting a good release on which to build upon later without spreading our resources too thin. Also, the only way of finding weak spots in a library is to actually use it to build a lot of serious stuff and not just dreaming of integrating the latest and coolest technology we have heard of. I'm not saying that we shouldn't stablize core. And Camaelon is hardly new technology. No one is advocating integrating the latest and greatest buzzword technology into GNUstep. The only thing that's being discussed here is what we need to do to get GNUstep out of the current state of stagnation that it's been in (and is hopefully now getting out of). Once we have done our gnome 1 with gtk1 step using current tools we might think what to do next. I personally would think weary about a step like doing gtk2/gnome2 at the beginning, but it is too easy to speak now. Since we have a cousin which gets developed and is called macosx it can be wise to keep an eye on it too.. but the current approach which is try to do a bit of everything is not proving out well with our current limited set of resources. Of course, this too, may change. So it might be interesting not only to think about a gnustep roadmap but a gnustep environment roadmap trying to think in a broader view. I broader view is always good. Cheers, Riccardo Later, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of
