Re: GNUstep moving forward
Le 29 janv. 06 à 13:18, Guilhem BONNEFILLE a écrit : On Mon, 24 Oct 2005 11:08:02 +0200 Sašo Kiselkov [EMAIL PROTECTED] wrote: Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. The site is no more accessible. Perhaps could you try to open a project page on a open platform (like Savannah, Gna or SourceForge). Project Manager has been moved to SourceForge. Here is the new project page : http://sourceforge.net/projects/pmanager Cheers, Quentin. -- Quentin Mathé [EMAIL PROTECTED] ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
On Mon, 24 Oct 2005 11:08:02 +0200 Sašo Kiselkov [EMAIL PROTECTED] wrote: Currently I'm working 100% on http://student.fiit.stuba.sk/~kiselkov04/ProjectManager - an new IDE completely from scratch. The site is no more accessible. Perhaps could you try to open a project page on a open platform (like Savannah, Gna or SourceForge). -- Guilhem BONNEFILLE -=- #UIN: 15146515 JID: [EMAIL PROTECTED] MSN: [EMAIL PROTECTED] -=- mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] -=- http://nathguil.free.fr/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Quoting Serg Stoyan [EMAIL PROTECTED]: On Monday 24 October 2005 21:40, Sašo Kiselkov wrote: Quoting Adrian Robert [EMAIL PROTECTED]: 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. All you mentioned before has already implemented in ProjectCenter or planned to be implemented. You can see in Documentaion/TODO file. I know I have to post new ProjectCenter development plans and current state. In short, now I've almost finished redesign bunle management (on-deman loading of bundles). I come to this decision after I started to work on editor. Next week I'll be offline(business trip). After that I plan to commit changes to UNSTABLE_0_5 branch. Do you still have no time to see what the ProjectCenter is now? If you have working fast editor with features toy mentioned before I'll be glad to redesign ProjectCenter (if it would be sane) and integrate it. That's my opinion. -- Serg Stoyan The code editor is rather fast (I know, I have a slow computer) and quite well separated, basically just two classes: SourceEditorDocument and EditorTextView. There is currently no support for code coloring, however, which is why it's _just_ two classes. After I add support for that, it will be of course more. As for work on PC: I'm sorry, but currently I want to continue PM. I plan to get into a releasable 0.1 state within a week. 0.1 in my terms means: most of it is implemented, though some bits here and there still remain, but what is implemented should be already stable and not crash - of course this is often just a fantasy :-) But in order to make it mostly true, before releasing an app, I reserve a day or two and tease it around - while running in a debugger, I do stuff lots and lots of times repeatedly, do unexpected stuff, do nonsence, and in general try hard to crash it. :-) I learned this at work, where thanks to that my apps don't segfault and throw out unexpected exceptions anymore. Also following the KISS rule (Keep It Simple, Stupid!) helps a lot. -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
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
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
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: GNUstep moving forward
Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. I am observing the same thing and realised few reasons (ordered how they comeunder my fingers on keyboard): External issues: 1. GNUstep desperately lacks an attractor for developers 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. I sort of agree with this. I feel it's more a symptom than a cause. We need better documentation and better support tools. To some degree these become self generating when the project is moving well with momentum. 2. GNUstep lacks attractor for users (this adds to the impact on 1.) We need more apps to make this happen. If you build it, they will come. Better dev environment means better dev, a precursor to the apps. Internal issues: 4. GNUstep has no project management, nor resources management, nor task management 5. GNUstep has no single achievable goal, neither short therm nor long term Both of these can be taken care of by the creation of a roadmap to show what the project is and will be doing in the future. I disagree. Completely. A roadmap is not project management. It's not resource management. It's not even task management. It's an idea of where things are going, not an implementable plan of how to get there. I do agree entirely that project management is a key issue. Probably THE issue. The size and complexity have grown beyond simple, organic organisation. You have already mentioned some solutions that I have removed from this email, as they are already being discussed. Your suggestions address mainly points 2,3 and somehow point 1. But there is still problem 4 and 5. GNUstep developers and friends are pulling the rope on the same end, but to thousands of different directions :-) This reminds me a story for children by Czech writer Josef Capek in a book Of Dog and Cat. Dog (the dog) and Cat (the cat) wanted to bake a cake. They were putting in a pot everything they liked and they thought that would be good to have in the cake... I like this, so I add it there Ok, that would be fine. I'll at that, because I like that and it is good ... The cake was mixture only of all good things, however at the end it was uneatable. We are baking similar cake too... Lack of larger picture, roadmap and kind of management affects development. Also lack of requirements specifications is making development of GNUstep much difficult and slow. Potential developers do not know what should be implemented, not speaking about how it should be developed. From management point of view, first step that should be done in GNUstep is detailed roadmap with very good task breakdown and expressend depencencies. For this I would suggest to either revive the 'Tasks' on savannah or use Wiki. With savannah one would have better task tracking, however on the wiki there would be better public visibility and accessibility, even it would be in a plain- text. I would vote for the wiki option. I'd vote for savannah unless we have a better solution. The one I'd really like to see is one written around oOGO/gsweb... Tasks should be laid in a tree-like structure with good breakdown. 'CORBA' is an example of very bad task. Yes, one should start with taks like 'Windows support', but then it should be broken into 'Installation', 'Pasteboard', 'UI', 'Distributed Objects', etc. It is still not enough, because neither current nor new developer would know, what should be implemented for 'pasteboard'. Therefore one who knows should write: 'implement handling of type XY this or that way'. Now back to the project, people, resources and time. Many, if not all, core gnustep developers complain that they do not have time. Ok, me neither. But I ask: WHO IS GOING TO IMPLEMENT MISSING GNUSTEP PARTS, IF THE ONLY KNOW-HOW HOLDER IS YOU?. Answer is: noone. Solution: GET THE KNOW HOW OUT OF YOUR HEAD AND SHARE IT!. Please, if every core developer was able to find just a little bit of time to write unordered bulleted list of his observations or knowledge about GNUstep that would be really helpful. And most importantly, write what is missing. GNUstep developers do not even know what they do not know, not to say that they do not know what they do not know and they need to know. This sort of thing would be very useful. If you take a look at NSTimeZone there is a lengthy comments section at the start which talks about the module and what it does. I wrote that original lengthy spiel. I should contribute such discussions to other modules. I'd say, though, that a better solution is to identify those with the knowledge and interest/dedication for a particular module. Give
Re: GNUstep moving forward
I've been with GNUstep over several years now and I agree that it is currently encountering a state of slow stagnation. Quoting Gregory John Casamento [EMAIL PROTECTED]: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. I've been doing a lot of thinking and have compiled a list of things I believe that GNUstep needs to address to stay on top of things. The list follows: 1) More apps. Many of the following points will help with this, but this is very important. I'm working on this, but I've only got one life and a day only has 24 hours. :-) I'd propose making a list of things being developed (I mean _actively_ developed, as in _work_really_being_done_) so that a person willing to do some app/framework/tool/feature for GNUstep could simply have a look at what is being currently done and possibly contact the person in charge so that they can collaborate, or simply find out what's already being done so that several people don't work on the same thing. 2) Better theme support. Integration of Camaelon into the core gui library if possible I agree, looks does matter. 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. 1000% agree: my company too would profit from GNUstep being nice and smooth under Windoze (although our primary target is UNIX-like systems). 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. Yes, and I'd like to add to this: we need to simplify the way people report bugs. Remember the BugNeXT application? (http://www.levenez.com/NeXTSTEP/Demos.html) It's was a simple and fast way how to bug the developers at NeXT about their. If others agree, I'll hack a BugStep together in a few moments. 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. Additionally, I've noticed recently a trend for certain people to constantly query the list asking for permission to make this or that change. It seems that what we need more than anything right now is more action and less talk. If you are interested in doing something, please do it! :) Got it! :-) Please think about what I've said and let me know your thoughts. I say the above out of concern for the community. GNUstep is and always has been a true labor of love for me. I want to see it thrive. Sincerely, Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. -- Saso ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. Here I have to agree with you. GNUstep is for some time now actually usable, but progress and contributions have slowed down a lot. I can only talk about my own reasons for contributing less. Now idea, why other core developers like Alexander Malmberg, who was responsible for the great progress on gui in the previous year, no longer contributes. But the same is true for Quentin and even for Adrian in recent months. To be honest, there never were more than just a few people working on gui at the same time. We just need to find new people taking up the orphaned work, or get the old ones back again. For example it is great to see Nicola working on make again! I've been doing a lot of thinking and have compiled a list of things I believe that GNUstep needs to address to stay on top of things. The list follows: 1) More apps. Many of the following points will help with this, but this is very important. 2) Better theme support. Integration of Camaelon into the core gui library if possible 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. 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. All of this is true. It would increase the general preception of GNUstep. Make it a better usable system. But who should be doing this? We will need to motivate developers first. In my view, the bounties that Adam presented some time ago, are a desparate step in this direction. But I know of no better one. Perhaps one, I remember when joining GNUstep there were these list Adam had set up on the GNUstep web site, listing open tasks, classes to do and time frames for all of this. Of course this was somewhat ridicules, how could you set up a schedule, when you don't ahve any resources to control? Still, for me this was a motivation to join and to do my part to keep the schedule. 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. I am not sure, if GNUstep is really that much against change. I for my part would like to see GNUstep integration with DBUS and other new hot technologies. Perhaps I might even start to work on that. Do you have any specific examples of change resistence in GNUstep? My feeling is rather that new stuff in GNUstep gets ignored until the person working on that gets bored. To me this happend with the win32 stuff, the keyed-encoding and currently again with the cairo backend. Additionally, I've noticed recently a trend for certain people to constantly query the list asking for permission to make this or that change. It seems that what we need more than anything right now is more action and less talk. If you are interested in doing something, please do it! :) True! Please think about what I've said and let me know your thoughts. I say the above out of concern for the community. GNUstep is and always has been a true labor of love for me. I want to see it thrive. Same for me :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep moving forward
Fred, --- Fred Kiefer [EMAIL PROTECTED] wrote: Gregory John Casamento wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. Here I have to agree with you. GNUstep is for some time now actually usable, but progress and contributions have slowed down a lot. I can only talk about my own reasons for contributing less. Now idea, why other core developers like Alexander Malmberg, who was responsible for the great progress on gui in the previous year, no longer contributes. But the same is true for Quentin and even for Adrian in recent months. To be honest, there never were more than just a few people working on gui at the same time. We just need to find new people taking up the orphaned work, or get the old ones back again. For example it is great to see Nicola working on make again! I believe that many of the developers who are not contributing might be busy with some things in Real Life[tm]. I know, for me, sometimes real life intrudes and I have little time to do what I wanted for GNUstep. So, in short, I don't think it's lack of interest, only lack of time. I've been doing a lot of thinking and have compiled a list of things I believe that GNUstep needs to address to stay on top of things. The list follows: list of things deleted... see previous email... All of this is true. It would increase the general preception of GNUstep. Make it a better usable system. But who should be doing this? We will need to motivate developers first. In my view, the bounties that Adam presented some time ago, are a desparate step in this direction. But I know of no better one. Perhaps one, I remember when joining GNUstep there were these list Adam had set up on the GNUstep web site, listing open tasks, classes to do and time frames for all of this. Of course this was somewhat ridicules, how could you set up a schedule, when you don't ahve any resources to control? Still, for me this was a motivation to join and to do my part to keep the schedule. I believe that what GNUstep needs most of all right now is a Road Map. Some goals which basically illustrate what the future holds and where GNUstep is heading. 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. I am not sure, if GNUstep is really that much against change. I for my part would like to see GNUstep integration with DBUS and other new hot technologies. Perhaps I might even start to work on that. Do you have any specific examples of change resistence in GNUstep? My feeling is rather that new stuff in GNUstep gets ignored until the person working on that gets bored. To me this happend with the win32 stuff, the keyed-encoding and currently again with the cairo backend. Well, there is, for some reason, a perception that the core devs are against change. We should work to get rid of this perception. Some examples from long ago include some of the points I made above, which include the integration of a theme engine. In some cases, people have suggested that GNUstep conform to the FHS, which I find to be a little odd, but the frustration comes from the fact that some of these arguments were dismissed out of hand. As well as various other things over the years. Most recently, it's the discussion concerning SVN, which I really don't believe is over by any stretch given that RMS has said it's okay for us to move to GNA. Additionally, I've noticed recently a trend for certain people to constantly query the list asking for permission to make this or that change. It seems that what we need more than anything right now is more action and less talk. If you are interested in doing something, please do it! :) True! :) Please think about what I've said and let me know your thoughts. I say the above out of concern for the community. GNUstep is and always has been a true labor of love for me. I want to see it thrive. Same for me :-) Later, GJC Gregory John Casamento -- CEO/President 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 moving forward
On 10/22/05, Gregory John Casamento [EMAIL PROTECTED] wrote: GNUstep has been relatively stagnant over the last several months and it hasbecome a cause for concern for me. yes, many people seems to be quite busy irl lately :-/ I've been doing a lot of thinking and have compiled a list of things I believe that GNUstep needs to address to stay on top of things. The list follows:1) More apps.Many of the following points will help with this, but this isvery important.2) Better theme support.Integration of Camaelon into the core gui library if possible that's possible, and I must say that's what I was supposed to do, more or less.. but I was really busy these last months, so I didn't do as much work on camaelon that I wanted :-/ Note that you can get the current sources from étoilé's cvs: http://www.etoile-project.org it wouldn't be that much work to properly integrate camaelon in -gui, but.. it needs to be done. I need to encapsulate the current -gui drawing in the GSDrawFunctions class, and integrate camaelon's modifs to -gui so that the widgets call GSDrawFunctions. Then Camaelon can simply provide its own implementation of GSDrawFunctions, enabling a pixmap theme, or you can have programmed themes containing normal code (for the default NeXTSTEP look, or anything else) Partly I didn't do it yet because I wanted to freeze the GSDrawFunctions api before starting to do that ... but well perhaps it would have been better to commit whatever was ready instead of waiting (retrospectively, it seems as a better idea). 3) Better win32 support.Many companies are really eager to port their legacyNeXTSTEP/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.Completely agree ! A good Windows port is really important, and I'm quite thrilled by what happend during this last year.. 4) Better distro support.We really need to get GNUstep into as manydistributions as possile, this will ramp up exposure of GNUstep to more people and help us get more developers and users.We as a project need to be more adaptive and less resistant to change.Morethan anything right now we need to consider the audience we are playing to.GNUstep needs to be better able to integrate with other environments. Additionally, I've noticed recently a trend for certain people to constantlyquery the list asking for permission to make this or that change.It seemsthat what we need more than anything right now is more action and less talk. If you are interested in doing something, please do it! :) I completely agree :-) And I think that svn/svk could really help for that... hopefully we'll be able to use svn, now that RMS gave its approval... Please think about what I've said and let me know your thoughts.I say theabove out of concern for the community. GNUstep is and always has been a true labor of love for me.I want to see it thrive. I think we're all here because we love the project; and we need to come up with a good direction.. I think what's missing is a clearer distinction between gnustep the framework and gnustep the rest of the frameworks, the dev apps, the user apps.. I think having separate projects (GNUstep Development Environment, GNUstep Desktop), even if it only amount to just changes on the website, would be helpful. Also, GNUstep could be slightly modular (say, use -foundation but not DO..); and probably the important thing for the user would be a better separation/modularization of the desktop parts, eg, like Alex Malmberg once proposed with Desktop Bundles, where the desktop functionalities could be implemented/extended by desktop bundles (you'd want a GNUstep bundle to have the current behavior, but a KDE or GNOME bundle to have proper integration, etc.) Anyway, as always, talk is cheap, but I think thoses are the directions that would be helpful.. To summarize, cleaner separations and modularization... but anyway, what will happen only depends on who will do the job -- so if you're interested by working on that, do it :-) -- Nicolas RoardAny 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: GNUstep moving forward
Nicolas, --- Nicolas Roard [EMAIL PROTECTED] wrote: On 10/22/05, Gregory John Casamento [EMAIL PROTECTED] wrote: GNUstep has been relatively stagnant over the last several months and it has become a cause for concern for me. yes, many people seems to be quite busy irl lately :-/ Yes, myself included to some degree. I've been doing a lot of thinking and have compiled a list of things I believe that GNUstep needs to address to stay on top of things. The list follows: 1) More apps. Many of the following points will help with this, but this is very important. 2) Better theme support. Integration of Camaelon into the core gui library if possible that's possible, and I must say that's what I was supposed to do, more or less.. but I was really busy these last months, so I didn't do as much work on camaelon that I wanted :-/ Note that you can get the current sources from étoilé's cvs: http://www.etoile-project.org it wouldn't be that much work to properly integrate camaelon in -gui, but.. it needs to be done. I need to encapsulate the current -gui drawing in the GSDrawFunctions class, and integrate camaelon's modifs to -gui so that the widgets call GSDrawFunctions. Then Camaelon can simply provide its own implementation of GSDrawFunctions, enabling a pixmap theme, or you can have programmed themes containing normal code (for the default NeXTSTEP look, or anything else) I think we should start working on this ASAP. Partly I didn't do it yet because I wanted to freeze the GSDrawFunctions api before starting to do that ... but well perhaps it would have been better to commit whatever was ready instead of waiting (retrospectively, it seems as a better idea). 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. Completely agree ! A good Windows port is really important, and I'm quite thrilled by what happend during this last year.. Me too, things will continue to improve. 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. 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. Additionally, I've noticed recently a trend for certain people to constantly query the list asking for permission to make this or that change. It seems that what we need more than anything right now is more action and less talk. If you are interested in doing something, please do it! :) I completely agree :-) And I think that svn/svk could really help for that... hopefully we'll be able to use svn, now that RMS gave its approval... Indeed. Please think about what I've said and let me know your thoughts. I say the above out of concern for the community. GNUstep is and always has been a true labor of love for me. I want to see it thrive. I think we're all here because we love the project; and we need to come up with a good direction.. A Road Map is what's needed. I think what's missing is a clearer distinction between gnustep the framework and gnustep the rest of the frameworks, the dev apps, the user apps.. I think having separate projects (GNUstep Development Environment, GNUstep Desktop), even if it only amount to just changes on the website, would be helpful. I believe that one thing that GNUstep needs to focus on is a Desktop environment. We need to be both an API *AND* a Desktop environment. Also, GNUstep could be slightly modular (say, use -foundation but not DO..); and probably the important thing for the user would be a better separation/modularization of the desktop parts, eg, like Alex Malmberg once proposed with Desktop Bundles, where the desktop functionalities could be implemented/extended by desktop bundles (you'd want a GNUstep bundle to have the current behavior, but a KDE or GNOME bundle to have proper integration, etc.) I agree with this. It might be a good thing to have themes which imitate other environments so that GNUstep can more easily integrate with them. Anyway, as always, talk is cheap, but I think thoses are the directions that would be helpful.. To summarize, cleaner separations and modularization... but anyway, what will happen only depends on who will do the job -- so if you're interested by working on that, do it :-) We need more people involved in this than just one. I'm trying to motivate the community to take some action as a whole on these things. Later, GJC Gregory John Casamento -- CEO/President Open Logic
Re: GNUstep moving forward
On Oct 22, 2005, at 5:53 AM, Sašo Kiselkov wrote: Yes, and I'd like to add to this: we need to simplify the way people report bugs. Remember the BugNeXT application? (http://www.levenez.com/NeXTSTEP/Demos.html) It's was a simple and fast way how to bug the developers at NeXT about their. If others agree, I'll hack a BugStep together in a few moments. I'd really like to get something like the CrashReporter program. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
