Changes I've been thinking of...
Guys, There are a number of things which need to change on the project: We need to: 1) improve our website. It's been the same for years and doesn't reflect our progress. 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, I believe it's one way for us to spark interest in the project is to update it's look. The current look should always be available, but not necessarily the default. 3) Improve our ability to market ourselves in general. One thing that GNUstep has been lacking in is marketing. I've been trying to improve things on that front, but I'm not the best marketer to say the very least. Does anyone have any questions or comments regarding this? I would like to hear any and all input people have. Later, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 7 Oct 2009, at 20:24, Gregory Casamento wrote: Guys, There are a number of things which need to change on the project: We need to: 1) improve our website. It's been the same for years and doesn't reflect our progress. I've been dissatisfied with it too. Not the basic appearance, which is generally a pleasantly clean/simple design, but more in function ... a. If we can figure out what key areas of interest there are, we can link to them from the home page in a manner which makes it easy for people to find them. For instance, I recently noticed there was no link to the windows installer from the home page, so I added one. b. Some inspiring news ought to be frequently updated on the front page. c. links should be kept up to date ... old code which is no longer supported should be flagged as such or moved away from more current downloads. d. the navigation links on the right should be highlighted in some way ... we read from left to right, and it's easy to fail to notice those links. Look at http://www.apache.org/ for a clearer presentation with a broadly similar layout. 3. we should have a site search field on the home page! The lack of a search facility is really annoying when someone is looking for something specific 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, Then why did you say it? ... that's rather foolhardy. I believe it's one way for us to spark interest in the project is to update it's look. That's not a reason to change the default theme. It's a reason to try to develop at least one good alternative theme. You should not be proposing a change which will provoke argument when the alternative would achieve the same in a relatively non-contentious way/ If/when a genuinely better theme can be produced, people will WANT to adopt it as the default. The objective should be to develop a good theme (or multiple good themes). The current look should always be available, but not necessarily the default. 3) Improve our ability to market ourselves in general. Can't argue with that. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
RE: Changes I've been thinking of...
> Date: Wed, 7 Oct 2009 15:24:01 -0400 > From: greg.casame...@gmail.com > To: discuss-gnus...@gnu.org; gnustep-dev@gnu.org > CC: > Subject: Changes I've been thinking of... > > Guys, > > There are a number of things which need to change on the project: > > We need to: > 1) improve our website. It's been the same for years and doesn't > reflect our progress. For item 1, I like to suggest move the web site over to sourceforge.net. If advertisement on web page is a concern/annoying, we can use Trac like software to host GNUStep site. Trac can even support auto-build feature(bitten). Check out http://trac.edgewall.org yourself. > 2) improve GNUstep's default theme as well as theming in general. > While I know some people will respond negatively to changing the > default theme from a NeXT-like look to something more modern, I > believe it's one way for us to spark interest in the project is to > update it's look. The current look should always be available, but > not necessarily the default. > 3) Improve our ability to market ourselves in general. To me theme is not an important issue, issue is GNUStep community is not as active as other projects. Apache,Firefox,extjs just to name a few. Also there is no killer app in GNUStep. All the software people need is on Windows, GNOME or KDE. I like to suggest we come up with a killer app to demonstrate GNUStep's write once run everywhere feature. If GNUStep have a killer app, people will install GNUStep system on their OS. Pick a most used software(maybe FireFox ?) and port the source code into objc language and GNUStep framework. tj yang, a GNUStep lurker > > One thing that GNUstep has been lacking in is marketing. I've been > trying to improve things on that front, but I'm not the best marketer > to say the very least. > > Does anyone have any questions or comments regarding this? I would > like to hear any and all input people have. > Later, GC > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. http://clk.atdmt.com/GBL/go/171222985/direct/01/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Wed, Oct 7, 2009 at 3:57 PM, Richard Frith-Macdonald wrote: > > On 7 Oct 2009, at 20:24, Gregory Casamento wrote: > >> Guys, >> >> There are a number of things which need to change on the project: >> >> We need to: >> 1) improve our website. It's been the same for years and doesn't >> reflect our progress. > > I've been dissatisfied with it too. Not the basic appearance, which is > generally a pleasantly clean/simple design, but more in function ... > > a. If we can figure out what key areas of interest there are, we can link to > them from the home page in a manner which makes it easy for people to find > them. For instance, I recently noticed there was no link to the windows > installer from the home page, so I added one. > > b. Some inspiring news ought to be frequently updated on the front page. > > c. links should be kept up to date ... old code which is no longer supported > should be flagged as such or moved away from more current downloads. > > d. the navigation links on the right should be highlighted in some way ... > we read from left to right, and it's easy to fail to notice those links. > Look at http://www.apache.org/ for a clearer presentation with a broadly > similar layout. > > 3. we should have a site search field on the home page! The lack of a > search facility is really annoying when someone is looking for something > specific I agree with all of these. >> 2) improve GNUstep's default theme as well as theming in general. >> While I know some people will respond negatively to changing the >> default theme from a NeXT-like look to something more modern, > > Then why did you say it? ... that's rather foolhardy. Because the current look is a source of constant criticism from people outside the community and I hear it all of the time. Also, I mention it because I feel like the look (even though I, personally, like it) may send the wrong message about the project. Some people look at how it looks and don't see that GNUstep is so much more than OpenStep. They look at it and they see NeXTSTEP and they think it's nothing more than that. This is a shame since GNUstep is SO much more. What I don't want to happen is for people to look at the current theme and think "it's just NeXTSTEP/OpenStep" and don't think twice about it. >> I believe it's one way for us to spark interest in the project is to >> update it's look. > > That's not a reason to change the default theme. It's a reason to try to > develop at least one good alternative theme. You should not be proposing a > change which will provoke argument when the alternative would achieve the > same in a relatively non-contentious way/ > If/when a genuinely better theme can be produced, people will WANT to adopt > it as the default. The objective should be to develop a good theme (or > multiple good themes). Indeed, I agree with this. >> The current look should always be available, but >> not necessarily the default. >> 3) Improve our ability to market ourselves in general. > > > Can't argue with that. > :) Later, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
I'll just give my opinion on each topic... On Wed, Oct 7, 2009 at 2:24 PM, Gregory Casamento wrote: > 1) improve our website. It's been the same for years and doesn't > reflect our progress. > I agree here. A while back, myself an Jesse from the Etoile project started, but I had to divert my attention to other things and I'm guessing so did Jesse. I think the move to link the Software Index was great, but, at this point, GNUstep has 3 different sources for software look-up: 1. Software Index 2. Wiki 3. Website (which links to the wiki and freshmeat) That's just plain confusing! I personally like the Software Index better but it will require application developers to be more active in maintaining they're projects up to date. Also, I think there needs to be a real content "audit". If I want to get to the developer docs I need to go Developers -> Manuals and Documentations... and when I get there need to scroll through quite a few links, which may or may not be outdated and redudant... only then will I find the actual API docs. This is just an example. One this issue (content) I think the core developers need to take a step back and ask "who do we want to reach" and "what to we want to convey". 2) improve GNUstep's default theme as well as theming in general. > While I know some people will respond negatively to changing the > default theme from a NeXT-like look to something more modern, I > believe it's one way for us to spark interest in the project is to > update it's look. The current look should always be available, but > not necessarily the default. > I agree with Richard on this one! Windows, QT, GTK and FLTK (to name a few) all come default with a very bland theme (except Windows, but you still have the option). Square buttons, grey everything, etc. At most, I'd say the theme can be a little more subtle... the buttons just feel very raised for my taste. In my opinion, and that's all it is, the problem here is a little deeper. The first, and most obvious, is that GNUstep theming is still very young. Apart from Camaleon (does it still work?) and some of Riccardo's themes there's nothing out there. The second, which is a little deeper, is that there's no way to globally define defaults. If I'm out there creating a GNUstep package (and I mostly do for Slackware, I just need to get on it for 13.0) there's not way for me to set a default, "preferred" theme--which is what the GUI toolkits above allow you to do--there is just no way for me to do that. I know it's been brought up a few times in the past, and if I remember correctly it's because of the way NSUserDefaults is setup, so (again, in my opinion) that's where the problem lies. 3) Improve our ability to market ourselves in general. > A new, targeted website would definitely get you off on the right foot. Let me know if I can help in anyway. My help will be limited, at best, because I just started grad school. Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey I believe it's one way for us to spark interest in the project is to update it's look. That's not a reason to change the default theme. It's a reason to try to develop at least one good alternative theme. You should not be proposing a change which will provoke argument when the alternative would achieve the same in a relatively non-contentious way/ If/when a genuinely better theme can be produced, people will WANT to adopt it as the default. The objective should be to develop a good theme (or multiple good themes). Indeed, I agree with this. A SystemPrefernces panel to set the theme, much like the current one in the InfoPanel, but working in the global domain... would help a lot! it would make a switch with a click and a revert with the same... and not for each application. What do you think? A small preview would be even more awesome. Maybe to simply things it could be faked with an included TIFF of a screenshot of a predefined palette Richard, could you add the ability to change the theme icon in Thematic? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Wed, Oct 7, 2009 at 2:28 PM, Stef Bidi wrote: > 13.0) there's not way for me > to set a default, "preferred" theme--which is what the GUI toolkits above > allow you to do--there is just no way for me to do that. I know it's been > brought up a few times in the past, and if I remember correctly it's because > of the way NSUserDefaults is setup, so (again, in my opinion) that's where > the problem lies. I believe you are mistaken, NSUserDefaults handles global settings fine, you just need to add the default to the NSGlobalDomain, unless you mean on more than a per-user basis, e.g. on a system basis extending the defaults system into the Local/ directories? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi On Wed, Oct 07, 2009 at 03:24:01PM -0400, Gregory Casamento wrote: > Guys, > > There are a number of things which need to change on the project: > > We need to: > 1) improve our website. It's been the same for years and doesn't > reflect our progress. For me, the one thing that really lowers GNUstep credibility is the super high 'bitrot factor' : a lot of the software found in the wiki is outdated, or it's website disappeared, or it won't compile or it's almost useless. Building the core librairies is good (thanks guys !) but we need a good set of working applications, easily found and easily built. One example I ran recently is AddressManager and the VCFViewer inspector. There is one version in GAP, one version in Etoile. One version of VCFViewer in AddressManager tree and one in GWorkspace website and wiki page. There are multiple terminal applications (gap, backbone, etoile ?) but none really usable (to my knowledge, maybe I missed something). There is Preferences and SystemPreferences. GNUMail doesn't work for me and seems stalled. What I'm trying to say is that I think we should try to centralize things (one repository for all !) and work on a set of defined applications instead of collecting random stuff. One last thing about stable/unstable : the website frontpage advertize gnustep startup 0.23.0 as a stable release with make 2.2.0, base 1.19.1, gui 0.17.0 and back 0.17.0. In the download page, stable startup version is 0.22.0 and unstable 0.19.3. Stable base is 1.18.0 which for me means that base 1.19.1 included in startup 0.23.0 is not stable. Same thing for gui and back. Question is : what should I download ?! I hope this doesn't sound too negative, really. I really like GNUstep and wish to use a GNUstep desktop one day :o). Thanks, Philippe -- Unix _IS_ user friendly - it's just selective about who its friends are! ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 7 Oct 2009, at 22:38, Matt Rice wrote: On Wed, Oct 7, 2009 at 2:28 PM, Stef Bidi wrote: 13.0) there's not way for me to set a default, "preferred" theme--which is what the GUI toolkits above allow you to do--there is just no way for me to do that. I know it's been brought up a few times in the past, and if I remember correctly it's because of the way NSUserDefaults is setup, so (again, in my opinion) that's where the problem lies. I believe you are mistaken, NSUserDefaults handles global settings fine, you just need to add the default to the NSGlobalDomain, Unless I have missed something, NSGlobalDomain is a per-user thing. There is no sensible way of setting a default value for a user default globally. Apps can do this via the standard APIs, but there is no way for packagers to provide a default value for a default. For example, we can put Camaelon and Nesedah in a package, but there is no way to make it the default theme for any users who have not selected a theme as part of the package installation. This question has been asked on the list before and no one replied with a way, so I assume it is still impossible. It would be nice to have a standard directory for plists which are merged together to provide the default user default values. I looked at doing this a while ago, but it required implementing whiteout in the per-user defaults (so you could delete a default that exists in this directory). This is something else that we need to address. The OpenStep style of distribution is to provide drag and drop application bundles, which are great for single-user system but not ideal for multi-user systems like a typical *BSD or Linux distribution. There are probably quite a few things that we could do to make it easier to package GNUstep and GNUstep apps / frameworks that we miss because we all build from source, which would help a lot with adoption. David -- Sent from my Apple II ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, The first, and most obvious, is that GNUstep theming is still very young. Apart from Camaleon (does it still work?) and some of Riccardo's themes there's nothing out there. Thank you for citing the effort. It is indeed very young. I was also amazed at the little response it got, given the amount of time usually spent talking/writing about theming. My themes are just a beginning because they are pixmap themes that go 1:1 with Thematic capabilities. Code themes can bemore powerful but more complex to write, I think we should be able to do a good simple scheme by playing with pixmaps and colors only. If you look for something more subtle, look at the "Neos" theme. The second, which is a little deeper, is that there's no way to globally define defaults. If I'm out there creating a GNUstep package (and I mostly do for Slackware, I just need to get on it for 13.0) there's not way for me to set a default, "preferred" theme--which is what the GUI toolkits above allow you to do--there is just no way for me to do that. I know it's been brought up a few times in the past, and if I remember correctly it's because of the way NSUserDefaults is setup, so (again, in my opinion) that's where the problem lies. From a packager point of you that is understandable. Maybe an init script wwhich sets defaults, a bit like windowmaker does? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Wed, Oct 7, 2009 at 2:59 PM, Philippe Roussel wrote: > Hi > What I'm trying to say is that I think we should try to centralize > things (one repository for all !) and work on a set of defined > applications instead of collecting random stuff. Yuck. first of all, this is impossible, because not everything out there is copyright assigned. IMO the way to go is decentralized, that doesn't mean we can't have a central repository to collect all the various decentralized projects in one easy to grab location. doing this would also allow for the various forks out there to usurp one another, if one repository dies, and someone picks it up, just update the location in the 'central collection' to point to a new repository maintained by whomever. then the GNU FSF-copyright assigned collection only references GNU FSF copyright assigned code, and someone else (e.g. the gap project) could create a project which references the copyright assigned code, + the other non assigned projects ideally you'd be able to build all the sub-projects i one go, something that we don't get in our existing build system. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Philippe Roussel wrote: For me, the one thing that really lowers GNUstep credibility is the super high 'bitrot factor' : a lot of the software found in the wiki is outdated, or it's website disappeared, or it won't compile or it's almost useless. Building the core librairies is good (thanks guys !) but we need a good set of working applications, easily found and easily built. True... applications need love and care just not to "bit rot". Whiich gives the user a terrible impression. One example I ran recently is AddressManager and the VCFViewer inspector. There is one version in GAP, one version in Etoile. One version of VCFViewer in AddressManager tree and one in GWorkspace website and wiki page. I am working on that, you are helping me too there. The GAP version is the official Addresses, Bjoern "donated" it to us. GAP has become a kitchen-sink for apps not loved by their owners anymore... I try my best to keep them going and added in the last years several applications! When a core developer like Enrico leaves, it leaves a lot of stuff... I don't think everybody realized how much Enrico did for GNUstep. With the releases, the wiki pages will be corrected, etc etc. We're gettign there, just slowly. You yourself are helping me out lately! There are multiple terminal applications (gap, backbone, etoile ?) but none really usable (to my knowledge, maybe I missed something). These are harsh words? I don't know of etoile, but the one in GAP works. I use it every single day! It may miss some features but works. ANd I assume backbone's does too, the code bae is essentially the same, but the philosophies about releases, makefiles etc. differ. There is Preferences and SystemPreferences. It is lecit to have more applications that do similar things! Happens on windows too... SystemPreferences is from Enrico, it is Apple compatible. Preference's is more limited in the UI, has different modules but looks better :) GNUMail doesn't work for me and seems stalled. That is sadly very very true. TIm Kack found out what makes it crash, made a partial patch... but it is left there. He can tell us the details. But furthermore Ludovic should accept the patch, commit and make a new beta tarball. What I'm trying to say is that I think we should try to centralize things (one repository for all !) and work on a set of defined applications instead of collecting random stuff. That is not striclty necessary, but things should be clearly linked from the gnustep main site. One last thing about stable/unstable : the website frontpage advertize gnustep startup 0.23.0 as a stable release with make 2.2.0, base 1.19.1, gui 0.17.0 and back 0.17.0. In the download page, stable startup version is 0.22.0 and unstable 0.19.3. Stable base is 1.18.0 which for me means that base 1.19.1 included in startup 0.23.0 is not stable. Same thing for gui and back. Question is : what should I download ?! Our downloads are terribly confusing! I hope this doesn't sound too negative, really. I really like GNUstep and wish to use a GNUstep desktop one day :o). It is honest, which is what counts. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 7 Oct 2009, at 22:28, Stef Bidi wrote: The second, which is a little deeper, is that there's no way to globally define defaults. If I'm out there creating a GNUstep package (and I mostly do for Slackware, I just need to get on it for 13.0) there's not way for me to set a default, "preferred" theme-- which is what the GUI toolkits above allow you to do--there is just no way for me to do that. Actually, you can define global defaults in the GobalDefaults.plist file, which lives in the same directory as the GNUstep configuration file (and you can also put simple string values directly in GNUstep.conf using GNUSTEP_EXTRA if you don't want the overhead of loading GlobalDefaults.plist). See http://www.gnustep.org/resources/documentation/Developer/Base/Reference/index.html and the NSUserDefaults documentation. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 7 Oct 2009, at 23:37, Riccardo Mottola wrote: Richard, could you add the ability to change the theme icon in Thematic? It's already there ... just click on it, and an open panel will come up for you to select the new icon image. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 7 Oct 2009, at 23:00, David Chisnall wrote: On 7 Oct 2009, at 22:38, Matt Rice wrote: On Wed, Oct 7, 2009 at 2:28 PM, Stef Bidi wrote: 13.0) there's not way for me to set a default, "preferred" theme--which is what the GUI toolkits above allow you to do--there is just no way for me to do that. I know it's been brought up a few times in the past, and if I remember correctly it's because of the way NSUserDefaults is setup, so (again, in my opinion) that's where the problem lies. I believe you are mistaken, NSUserDefaults handles global settings fine, you just need to add the default to the NSGlobalDomain, Unless I have missed something, NSGlobalDomain is a per-user thing. Yes. There is no sensible way of setting a default value for a user default globally. GlobalDefaults.plist does that. Apps can do this via the standard APIs, but there is no way for packagers to provide a default value for a default. GlobalDefaults.plist does that. For example, we can put Camaelon and Nesedah in a package, but there is no way to make it the default theme for any users who have not selected a theme as part of the package installation. GlobalDefaults.plist does that. This question has been asked on the list before and no one replied with a way, so I assume it is still impossible. Maybe nobody bothered to answer, or they did and you missed it. It would be nice to have a standard directory for plists which are merged together to provide the default user default values. I looked at doing this a while ago, but it required implementing whiteout in the per-user defaults (so you could delete a default that exists in this directory). The per-user defaults override the global ones ... what we don't have is a mechanism for having global defaults which can't be overridden but I'm not sure we want to do that (it seems to be against the spirit of free software). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Thu, Oct 08, 2009 at 02:08:35AM +0200, Riccardo Mottola wrote: >> There are multiple terminal applications (gap, backbone, etoile ?) but >> none really usable (to my knowledge, maybe I missed something). >> >> > These are harsh words? I don't know of etoile, but the one in GAP works. > I use it every single day! It may miss some features but works. ANd I > assume backbone's does too, the code bae is essentially the same, but > the philosophies about releases, makefiles etc. differ. Ok, I went too far, Terminal works. But I doesn't answer to 'Terminal/Open shell here' service needed by GWorkspace for example. Running midnight commander inside it is... interesting. But yes, it works as a terminal for most things. Sorry :o) >> There is Preferences and SystemPreferences. >> >> > It is lecit to have more applications that do similar things! Happens on > windows too... SystemPreferences is from Enrico, it is Apple compatible. > > Preference's is more limited in the UI, has different modules but looks > better :) Don't get me wrong : I'm not opposed to multiple applications having the same goal. I just think the GNUstep project should select a set of applications and promote them as the minimal environnement. If I want to add a settings module, should I add it to Preferences, SystemPreferences or both ? Not necessarily a big deal but it might be confusing for users. Philippe -- If nested functions are answer, you've got the wrong question. Al Viro ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 07:29, Richard Frith-Macdonald wrote: GlobalDefaults.plist does that. Two questions then: - Is this actually documented anywhere? I see a vague reference to it in NSUserDefaults, but packagers are absolutely not going to read API docs (and should not be expected to. - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 10:32, David Chisnall wrote: On 8 Oct 2009, at 07:29, Richard Frith-Macdonald wrote: GlobalDefaults.plist does that. Two questions then: - Is this actually documented anywhere? I see a vague reference to it in NSUserDefaults, but packagers are absolutely not going to read API docs (and should not be expected to. With the documentation for GNUstep.conf in the main base library documentation (I put a link in an earlier email). I think you have to be realistic ... a packager *does* have to read some documentation in order to package a big system like GNUstep properly. It would undoubtedly be good to have some packager-specific documentation, but obviously the target readership is a very small group - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? This is a text property list ... a packager would manage it in exactly the same way as any other text file they install/uninstall with their packaging system. Probably something as simple as 'rm -rf /etc/GNUstep' when you are removing GNUstep from your system. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 11:50, Richard Frith-Macdonald wrote: - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? This is a text property list ... a packager would manage it in exactly the same way as any other text file they install/uninstall with their packaging system. Probably something as simple as 'rm -rf /etc/GNUstep' when you are removing GNUstep from your system. You misunderstand the question. Here's a concrete example: Camaelon, EtoileBehavior and EtoileMenu all provide appkit user bundles. They are each installed as separate packages. A person creating a package for them wants to make them default for every user. This requires: 1) When the package is installed, each needs to be added to the NSGlobalDomain GSUserAppKitBundles array. 2) When the package is uninstalled, each needs to be removed from the array. Step 1 can, I believe, be accomplished with plmerge. How would you go about doing step 2? David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 12:00, David Chisnall wrote: On 8 Oct 2009, at 11:50, Richard Frith-Macdonald wrote: - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? This is a text property list ... a packager would manage it in exactly the same way as any other text file they install/uninstall with their packaging system. Probably something as simple as 'rm -rf /etc/GNUstep' when you are removing GNUstep from your system. You misunderstand the question. Here's a concrete example: Camaelon, EtoileBehavior and EtoileMenu all provide appkit user bundles. They are each installed as separate packages. A person creating a package for them wants to make them default for every user. This requires: 1) When the package is installed, each needs to be added to the NSGlobalDomain GSUserAppKitBundles array. 2) When the package is uninstalled, each needs to be removed from the array. Step 1 can, I believe, be accomplished with plmerge. How would you go about doing step 2? You are right, I did misunderstand ... I understood the term 'packager' to refer to the person/people responsible for providing GNUstep with a distribution ... ie for a set of packages which are all intended to work together as part of an entire system (such as Ubuntu) and where the 'packager' would reasonably be expected to set policy for all users of the system. I think what you are suggesting is probably (usually at least) undesirable ... a person providing a single package of their own piece of software should probably *not* be setting policy for the system and therefore should not be setting global defaults. However, for the scenario you are suggesting the answer is still pretty much the same ... the packager could do it the same way as with most other software ... edit the file using standard unix tools such as sed and awk. Of course, we could provide specific utilities like plmerge, but 'standard' unix techniques of marking sections of the file with comments and removing/inserting stuff between those comments would work just fine. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 12:22, Richard Frith-Macdonald wrote: You are right, I did misunderstand ... I understood the term 'packager' to refer to the person/people responsible for providing GNUstep with a distribution ... ie for a set of packages which are all intended to work together as part of an entire system (such as Ubuntu) and where the 'packager' would reasonably be expected to set policy for all users of the system. On most systems I've looked at, the same person is responsible for maintaining the core GNUstep packages and a number of application / bundle packages. I think what you are suggesting is probably (usually at least) undesirable ... a person providing a single package of their own piece of software should probably *not* be setting policy for the system and therefore should not be setting global defaults. Not at all. If a person installs a theme, for example, or something like WildMenus then it is generally understood that they will want to use it. If this person is installing it systemwide, then it is generally understood that they will want to use it for all users. If you install any systemwide GNUstep bundle then the package should enable it by default for all users. I am not talking about someone installing a bundle in their home directory after compiling from source, I am talking about someone installing a package. Someone wanting to install a GNUstep-based environment will typically just select a metapackage in their package manager and install everything (GNUstep core, bundles, frameworks, and apps) in one blob; they should not then be expected to configure things by hand, and they especially should not be expected to configure things by hand per user. However, for the scenario you are suggesting the answer is still pretty much the same ... the packager could do it the same way as with most other software ... edit the file using standard unix tools such as sed and awk. Of course, we could provide specific utilities like plmerge, but 'standard' unix techniques of marking sections of the file with comments and removing/inserting stuff between those comments would work just fine. Adding an entry to a dictionary that may or may not already exist in a plist file is... nontrivial with sed / awk. You will note that other software these days generally does not modify files like this. Instead, they provide a configuration directory. A good example is Apache, where various modules are generally installed as separate packages. In the bad old days, things worked exactly as you describe. Packages modified the configuration file, and if you were lucky installing or removing a module package would not trash your httpd.conf (although good luck if you ever tried to upgrade a module package). Now, each module installs a separate configuration file. I used the appkit user bundles as an example, but this problem equally applies to any app that supports plugins which might be distributed in separate packages. David -- Sent from my brain ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 12:46, David Chisnall wrote: On 8 Oct 2009, at 12:22, Richard Frith-Macdonald wrote: You are right, I did misunderstand ... I understood the term 'packager' to refer to the person/people responsible for providing GNUstep with a distribution ... ie for a set of packages which are all intended to work together as part of an entire system (such as Ubuntu) and where the 'packager' would reasonably be expected to set policy for all users of the system. On most systems I've looked at, the same person is responsible for maintaining the core GNUstep packages and a number of application / bundle packages. Yes ... that's what I was thinking of. I think what you are suggesting is probably (usually at least) undesirable ... a person providing a single package of their own piece of software should probably *not* be setting policy for the system and therefore should not be setting global defaults. Not at all. If a person installs a theme, for example, or something like WildMenus then it is generally understood that they will want to use it. If this person is installing it systemwide, then it is generally understood that they will want to use it for all users. If you install any systemwide GNUstep bundle then the package should enable it by default for all users. I am not talking about someone installing a bundle in their home directory after compiling from source, I am talking about someone installing a package. Someone wanting to install a GNUstep-based environment will typically just select a metapackage in their package manager and install everything (GNUstep core, bundles, frameworks, and apps) in one blob; they should not then be expected to configure things by hand, and they especially should not be expected to configure things by hand per user. OK ... we just have different perceptions here then. In those circumstances I expect a package to be *available* to all users, but NOT to be automatically forced on them. Certainly *I* don't want to have something like that imposed on *ME* just because someone else installs a package globally. That's what I mean about 'policy' ... I don't mind policy being set by the person who managed the distribution (I wouldn't be using the distribution if I didn't think its managers policy was a good one), but I would hate to have it set just because someone else sharing the system with me decides to install a package and make it available to me. We can probably agree to differ on this ...it's not really very relevant. However, for the scenario you are suggesting the answer is still pretty much the same ... the packager could do it the same way as with most other software ... edit the file using standard unix tools such as sed and awk. Of course, we could provide specific utilities like plmerge, but 'standard' unix techniques of marking sections of the file with comments and removing/inserting stuff between those comments would work just fine. Adding an entry to a dictionary that may or may not already exist in a plist file is... nontrivial with sed / awk. You will note that other software these days generally does not modify files like this. Instead, they provide a configuration directory. A good example is Apache, where various modules are generally installed as separate packages. In the bad old days, things worked exactly as you describe. Packages modified the configuration file, and if you were lucky installing or removing a module package would not trash your httpd.conf (although good luck if you ever tried to upgrade a module package). Now, each module installs a separate configuration file. Well I really don't see your problem ... It *is* trivially easy for someone familiar with unix tools (awk in particular) to add entries to a property list using those tools, especially if you (as the package manager) control what's in there anyway. If you don't happen to like doing it that way (I tend to agree with you there, but I gave the sed/awk example as the method most frequently used historically), you can use the mechanism in the example you gave yourself (from apache) and just build the plist by merging plists from the installed packages (in which case you handle uninstall by uninstalling your package and rebuilding the global defaults plist from the remaining installed packages with plmerge). Either way, my point remains the same ... it's up to the packaging systems used by the distribution how they do things, the task is much the same as with any other software, not a GNUstep specific issue, and it's really not our concern how packagers for different distributions do things. If you are putting together a package for Debian, you ask the Debian maintainers how they want things done rather than asking the developers. We can certainly give advice, but it's not our job to dictate this. ___
Re: Changes I've been thinking of...
On 8 Oct 2009, at 13:30, Richard Frith-Macdonald wrote: it's up to the packaging systems used by the distribution how they do things, the task is much the same as with any other software, not a GNUstep specific issue, and it's really not our concern how packagers for different distributions do things. I think this reinforces my original point. GNUstep, at the moment, is not friendly towards packagers. FreeBSD is about the only platform that has well-maintained up-to-date GNUstep packages (and, here, I include stuff built on top of GNUstep), although a few Linux distros have recently started updating their old GNUstep packages, so that may change soon. It is not our concern how packagers choose to distribute things, but it should be our concern to make things easy for packagers. Currently, it is not, and the result is that people interested in developing with GNUstep find that they have no recent GNUstep package for their distribution of choice and then give up. You are right that this is not a GNUstep-specific issue. It is an issue that all software faces and successful projects tend to be the ones that make life easy for packagers. At the end of the day, it doesn't matter how good GNUstep is if it's too much effort for people to install, because they simply won't ever try it. David -- Sent from my STANTEC-ZEBRA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 13:38, David Chisnall wrote: On 8 Oct 2009, at 13:30, Richard Frith-Macdonald wrote: it's up to the packaging systems used by the distribution how they do things, the task is much the same as with any other software, not a GNUstep specific issue, and it's really not our concern how packagers for different distributions do things. I think this reinforces my original point. GNUstep, at the moment, is not friendly towards packagers. ??? So in what way is it unfriendly to packagers, and how do we improve it? FreeBSD is about the only platform that has well-maintained up-to- date GNUstep packages (and, here, I include stuff built on top of GNUstep), although a few Linux distros have recently started updating their old GNUstep packages, so that may change soon. It is not our concern how packagers choose to distribute things, but it should be our concern to make things easy for packagers. Currently, it is not, and the result is that people interested in developing with GNUstep find that they have no recent GNUstep package for their distribution of choice and then give up. You are right that this is not a GNUstep-specific issue. It is an issue that all software faces and successful projects tend to be the ones that make life easy for packagers. At the end of the day, it doesn't matter how good GNUstep is if it's too much effort for people to install, because they simply won't ever try it. True in principle of course but ... As I recall, 1. we have Adam's work on packaging for ms-windows which makes it easy to install stuff there. 2. we have support for .rpm packaging built into gnustep-make 3. we have considered putting support for .deb packaging into gnustep- make but apparently it's debian policy to specifically NOT want automated packaging, and to want packages built by hand. That probably covers the popular packaging forms. I'm still not happy about (3) ... (even if they want hand-built packaged, I'd have thought that having automatically built ones as a starting point would be useful), but it's hard to argue with the packagers themselves. It looks to me like GNUstep is actually much more friendly to packagers than most projects are, and it's certainly not less friendly to packagers than most... but of course we still need ideas on how to improve. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
We need to: 1) improve our website. It's been the same for years and doesn't reflect our progress. 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, I believe it's one way for us to spark interest in the project is to update it's look. The current look should always be available, but not necessarily the default. 3) Improve our ability to market ourselves in general. One thing that GNUstep has been lacking in is marketing. I've been trying to improve things on that front, but I'm not the best marketer to say the very least. Does anyone have any questions or comments regarding this? I would like to hear any and all input people have. I think all of these are really important, and I would love to make myself available on any or all of those fronts. Let me know what I can do to help. J. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
That's not a reason to change the default theme. It's a reason to try to develop at least one good alternative theme. You should not be proposing a change which will provoke argument when the alternative would achieve the same in a relatively non-contentious way/ If/when a genuinely better theme can be produced, people will WANT to adopt it as the default. The objective should be to develop a good theme (or multiple good themes). Also, document (in an easy to find place) how to select alternatives. The website should show similar screenshots with each theme so one can decide what to use. A section for package maintainers with things to tweak (such as the theme) on the website would be nice too. While it's nice to have a consistent look and feel, different OS projects have different goals. Some might target end users who like a little eye candy or "modern" look. I would argue Ubuntu falls into that category and I know we'll probably have to do that in MidnightBSD at some point. Luke ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi! 1) improve our website. It's been the same for years and doesn't reflect our progress. IMHO the GNUstep wiki main page currently is more informative than the plain www.gnustep.org front page. The wiki does a good job of showing project progress, too. 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, I believe it's one way for us to spark interest in the project is to update it's look. The current look should always be available, but not necessarily the default. As much as I love GNUstep base, I do not like GNUstep gui. Don't get me wrong, I still burst in tears of agony if I have to use another GUI library than GNUstep gui, because everyone still treats GUI as code, even C# and WindowsForms. GNUstep gui still lacks in polishing. Using a graphical GNUstep application on Gnome/KDE/Xfce ist still a pain because: 1. it simply does not integrate with the rest of the desktop 2. lots of bugs in window handling (minimise, maximise, ordering, ...) 3. the look belongs back to the 80's Simply put, GNUstep gui needs an associated desktop to fit in. And please spare me with the default excuse, namely "WindowMaker integrates with GNUstep" :) Maybe this sounds a little harsh, but most people out there don't care for WindowMaker. Be it users or potential developers, they prefer a more modern Desktop/Window manager. Another issue is code quality. For example, the code in GNUstep back is one hell of an ugly mess. I had to touch it, but I felt a chill running down my spine in doing so. Everything in XGServerEvent and associates looks like a mass of hacks piled on top of each other. It's such a chaos, I do not want to touch it anymore in fear of breaking somthing completely unrelated. Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. 3) Improve our ability to market ourselves in general. Yep. IMHO Distributed Objects alone is one hell of a feature, making it worth to use Foundation just because of that. A modern look wouldn't hurt, too. You could talk to the Etoile people if you need fancy images from a GNUstep based desktop :) My 2 cents Cheers TOM ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, 2009/10/7 : > Simply put, GNUstep gui needs an associated desktop to fit in. And please > spare me with the default excuse, namely "WindowMaker integrates with > GNUstep" :) Maybe this sounds a little harsh, but most people out there > don't care for WindowMaker. Be it users or potential developers, they prefer > a more modern Desktop/Window manager. I don't think so. The Window Maker Window Manager (it's a Desktop Environment too) is much better for me than any other Desktop Environment (GNOME or KDE). -- Regards, Paul Chany http://csanyi-pal.info ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 7 Oct 2009, at 22:12, ici...@mail.cg.tuwien.ac.at wrote: Hi! 1) improve our website. It's been the same for years and doesn't reflect our progress. IMHO the GNUstep wiki main page currently is more informative than the plain www.gnustep.org front page. The wiki does a good job of showing project progress, too. While I think the wiki is a good idea, it's not a substitute for an official project page, which needs to say: - This project is alive. - This project is shiny. - This project is actively used by some people. Currently the site says to me: - This project was alive once. - It's based on a thing people thought was shiny once. 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, I believe it's one way for us to spark interest in the project is to update it's look. The current look should always be available, but not necessarily the default. As much as I love GNUstep base, I do not like GNUstep gui. Don't get me wrong, I still burst in tears of agony if I have to use another GUI library than GNUstep gui, because everyone still treats GUI as code, even C# and WindowsForms. GNUstep gui still lacks in polishing. Using a graphical GNUstep application on Gnome/KDE/Xfce ist still a pain because: I don't completely disagree here. I think -gui has improved a huge amount in the last year, mostly due to Fred's work. Nicolas, Fred and Quentin worked a bit on live resizing at the Étoilé hackathon, which makes things look a lot more modern. Things are still slower than they should be and we need to do some profiling to work out why that is. There are also some plainly embarrassing bugs, like the fact that underlining still doesn't work. Much of the text system code is in need of an overhaul, because it's currently a mess of premature optimisation that none of the current developers actually understands. Another issue is code quality. For example, the code in GNUstep back is one hell of an ugly mess. I had to touch it, but I felt a chill running down my spine in doing so. Everything in XGServerEvent and associates looks like a mass of hacks piled on top of each other. It's such a chaos, I do not want to touch it anymore in fear of breaking somthing completely unrelated. Back also frightens me. At the hackathon, I talked to Fred a bit about refactoring it so that, long term, all that -back will do is create drawing contexts and handle events. We will then use a CoreGraphics implementation, probably based on Opal (which was just copyright assigned to GNUstep, I believe) to handle drawing using Cairo. This would let us use the same drawing code on X11, Win32 and on any of the other platforms Cairo supports (e.g. Zeta, OS/2, DirectFB), with just a small amount of new code for turning the platform's native events into NSEvents and for calling the cairo functions for creating graphics contexts. Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. Completely agree. Good coding conventions are picked because they make things that are wrong look wrong or generate compiler errors / warnings. The GNU coding conventions were picked by selecting at random various bits from all existing coding conventions in the hope that that would make everyone happy. They are a horrible mash of things. The indenting style is horrible, for example, and only works if you have your editor set up in exactly the same way as RMS; mixing tabs and spaces for indenting is one of the most stupid ideas I've ever seen. The convention of putting a space after function names and before the open bracket makes code harder to read because it makes it difficult to tell without reading the context that something is an argument list rather than a subexpression. In fact, almost everything about the GNU coding conventions looks painfully stupid to anyone with a basic understanding of how the human visual system works, but as an official GNU project we are stuck with it. When we designed the Étoilé coding standards, we made sure that every one of our style guidelines could be justified. Given the number of novice contributors who have contributed changes to core parts of Étoilé, I'd say they work well. Unfortunately, every time I submit a diff in a sane coding style, someone goes and reformats it in GNU style. I even find my own code difficult to read when it's been reformatted in the GNUstep style, so it's not surprising other people find it difficult. 3) Improve o
Re: Changes I've been thinking of...
> It would undoubtedly be good to have some packager-specific > documentation, but obviously the target readership is a very small > group We *do* have packager documentation, in core/make/README.Packaging Feel free to add a short section about what was discussed here. :-) >> - How does this allow a packager to install and remove defaults as >> part of package installation / uninstallation? Presumably you can >> use plmerge to install them (again, is this documented anywhere?), >> but how do you uninstall them? I agree with Richard's later suggestion that the package system might deal with that by having a directory where each package installs a .plist upon installation, and removes it upon deinstallation. At the end of each package installation/deinstallation, the package scripts could do a plmerge so that all the currently existing .plists in the directory are plmerged to create the global default plist, which is hence kept up-to-date. :-) That said, it should probably be used with restrain ;-) Presumably you have a specific example in mind where it makes particular sense (Etoile ?); but in general, I personally don't see a reason why installing a package should change some system defaults. Installing a package doesn't necessarily mean enabling it. Eg, I could be installing 10 or 20 themes or other GNUstep GUI-changing bundles, but that doesn't mean every theme that is installed must be trying to force all users to switch to it. I'd expect to have a Preferences panel somewhere where I can change my own user defaults and activate/deactivate the bundles or themes I want/don't want. Different users might activate/deactivate different bundles. So I think it is more important to have a very good preference application that allow real users to configure their environment to suit their needs, including turning on/off bundles or extensions. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 16:45, Nicola Pero wrote: It would undoubtedly be good to have some packager-specific documentation, but obviously the target readership is a very small group We *do* have packager documentation, in core/make/README.Packaging Yes, but I was meaning on the website ... Maybe it would be enough to copy that file onto the website and link to it? Feel free to add a short section about what was discussed here. :-) OK. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
[trimmed out the discuss list] On Thu, Oct 08, 2009 at 03:42:38PM +0100, David Chisnall wrote: [on gui] > There are also some plainly embarrassing bugs, like the fact that underlining > still doesn't work. Useful to know, I was about to try using it :-) > Much of the text system code is in need of an overhaul, because it's > currently a mess of premature > optimisation that none of the current developers actually understands. Because of the program I'm hacking on, I've been reading through quite a bit of the Text System code lately. I did notice a lot of SEL/Imp caching going on. I seem to recall that your new runtime was/is supposed to improve this. Would it allow these optimisations to be reverted? .pdf ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Thu, Oct 8, 2009 at 5:30 AM, Richard Frith-Macdonald wrote: > > OK ... we just have different perceptions here then. In those circumstances > I expect a package to be *available* to all users, but NOT to be > automatically forced on them. > Certainly *I* don't want to have something like that imposed on *ME* just > because someone else installs a package globally. there is no enforcing here, people could easily set defaults write NSGlobalDomain GSAppKitUserBundles '()' to get no theme bundles, I do this e.g. for using themes in every application except Gorm It just pushes the burden of setting defaults onto those that don't want to follow the global installation instead of those that do, I am completely fine with installing defaults system wide (as long as the system domain doesn't override the global domain) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 17:16, Derek Fawcus wrote: [trimmed out the discuss list] On Thu, Oct 08, 2009 at 03:42:38PM +0100, David Chisnall wrote: [on gui] There are also some plainly embarrassing bugs, like the fact that underlining still doesn't work. Useful to know, I was about to try using it :-) Apparently it wasn't done because doing it 'the right way' is hard, and although just using an NSBezierPath to draw a line under the glyph run would be trivial for anyone who understands the text system, it wasn't done because it's not 'the right way.' No one who knows what 'the right way' of doing it is was available for comment, unfortunately. Much of the text system code is in need of an overhaul, because it's currently a mess of premature optimisation that none of the current developers actually understands. Because of the program I'm hacking on, I've been reading through quite a bit of the Text System code lately. I did notice a lot of SEL/Imp caching going on. I seem to recall that your new runtime was/is supposed to improve this. Would it allow these optimisations to be reverted? SEL caching is always pointless from a performance perspective. @selector() directives are evaluated at load time and are uniqued on a per-compilation-unit basis. The only reason for caching @selector() expressions is to eliminate the kind of bug where you make a typo in @selector() in an infrequently-used code path and a frequently-used one, then fix it in one place and not the other. IMP caching is a bit more complicated. The new runtime supports a means of invalidating IMP caches, which means that the compiler will be able to automatically insert (polymorphic) IMP caching and even speculatively inline methods. Doing this well will require profiling (I have written an LLVM pass that adds profiling information to the code, but not one that uses this information to add the caching yet). To use this in the text system, we'd want to add a set of automated test programs using a null back end that would generate profiling information for how the text system is typically used and then compile an optimised version. To be honest, I suspect that most of the places where the text system currently does IMP caching are completely irrelevant. I've been playing with implementing some of the algorithms from LaTeX in Objective-C recently, and the overhead from message sends is largely irrelevant, especially when you compare it to the overhead in drawing an antialiased glyph (although, if you're lucky, the GPU will do most of that for you). There are lots of places where GNUstep is guilty of premature optimisation. Another example is that a lot of classes call NSDeallocateObject(self) rather than [super dealloc], which has a negligible performance impact but breaks any category that tries to replace NSObject's dealloc method. David -- Sent from my IBM 1620 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 17:29, Matt Rice wrote: On Thu, Oct 8, 2009 at 5:30 AM, Richard Frith-Macdonald wrote: OK ... we just have different perceptions here then. In those circumstances I expect a package to be *available* to all users, but NOT to be automatically forced on them. Certainly *I* don't want to have something like that imposed on *ME* just because someone else installs a package globally. there is no enforcing here, people could easily set defaults write NSGlobalDomain GSAppKitUserBundles '()' to get no theme bundles, I do this e.g. for using themes in every application except Gorm It just pushes the burden of setting defaults onto those that don't want to follow the global installation instead of those that do, I am completely fine with installing defaults system wide (as long as the system domain doesn't override the global domain) Perhaps 'forced' was too strong a word, but the basic issue for me is that I don't want other people changing the way my applications behave. Having them make a behavior change which I couldn't set back would be intolerable. Having them make a change which I then need to figure out how to revert, is annoying/undesirable. The second case is what we are talking about here. If behavior of the system just suddenly changes because a package someone installed has changed a global default, It's going to take me time and effort to figure out what happened and how to reverse it So, IMO global defaults should be used very sparingly, and should be used by the managers of distributions, not by people making individual app/library/bundle packages (except where the defaults only effect those specific packages of course). The very last thing you want is for every theme developer to set a global default to make their theme the one everyone uses... that decision should belong to the person who supplies the distribution, not the individual theme packages. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
ToÂ: Developer GNUstep
On Thu, Oct 08, 2009 at 05:43:55PM +0100, David Chisnall wrote:
>On 8 Oct 2009, at 17:16, Derek Fawcus wrote:
>> On Thu, Oct 08, 2009 at 03:42:38PM +0100, David Chisnall wrote:
>>> There are also some plainly embarrassing bugs, like the fact that
>>> underlining still doesn't work.
>> Useful to know, I was about to try using it :-)
>
> Apparently it wasn't done because doing it 'the right way' is hard,
> and although just using an NSBezierPath to draw a line under the glyph
> run would be trivial for anyone who understands the text system,
> it wasn't done because it's not 'the right way.'
> No one who knows what 'the right way' of doing it is was available for
> comment, unfortunately.
Well, having just glanced at a few docs, depending upon the desired
level of compatibility, the approach outlined above seems reasonable.
Most underline styles seem to have appeared with OSX 10.3 - i.e. the following:
NSUnderlineStyleNone/* zero */
NSUnderlineStyleSingle /* one */
NSUnderlineStyleThick /* non zero */
NSUnderlineStyleDouble /* non zero */
NSUnderlinePatternSolid /* zero */
NSUnderlinePatternDot /* non zero */
NSUnderlinePatternDash /* non zero */
NSUnderlinePatternDashDot /* non zero */
NSUnderlinePatternDashDotDot/* non zero */
from OSX 10.0 we have the following (where the styles are deprecated in favour
of the above):
enum {
NSNoUnderlineStyle = 0,
NSSingleUnderlineStyle
};
unigned NSUnderlineByWordMask;
where NSUnderlineByWordMask allows one to omit underlines from whitespace.
all being defined in NSAttributedString.h
So it seems to me the minimal implementation would just be the two deprecated
enum constants without the NSUnderlineByWordMask since this seems to be what
Rhapsody provided.
.pdf
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 18:22, Pablo Giménez wrote: Why Etoile and gnustep? I think that know etoile and gnustep should be working together in the same project, so you guys can provide a global computing environment, like Mac basically. Étoilé and GNUstep have different goals. The aim of GNUstep is to produce a first-rate set of modern, object- oriented, developer tools and APIs based around the OpenStep specification, tracking changes from Cocoa, and incorporating extensions where required. The aim of Étoilé is to produce a modern user environment using a service- and document-driven model with ubiquitous persistence, versioning, and collaboration support, with ideas from THE and Smalltalk, as well as from OPENSTEP and various other places. You can use GNUstep without using any of Étoilé. You can use some bits of Étoilé without using GNUstep (although we haven't ported some of the best bits to OS X as they mostly rely on things that aren't present there). Most of the Étoilé core team also have commit access to GNUstep. When things make more sense in GNUstep, we try to make sure that they go there and when Étoilé code exposes bugs in GNUstep we try to fix them (or, in my case, moan to Fred about them, which generally has the same result). When things are not part of GNUstep's more focussed goals, we put them in Étoilé. Sometimes code flows from Étoilé to GNUstep, as GNUstep's goals broaden. Not everybody who uses or contributes to GNUstep agrees with the directions Étoilé is taking, and there are projects like GAP and Backbone to produce more traditional, application-oriented, desktops. GNUstep's goals include supporting these developers too. Choice is good when it doesn't lead to duplication of effort, and because Étoilé builds on top of GNUstep this duplication usually doesn't occur. David -- Sent from my Difference Engine ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 8 Oct 2009, at 20:25, Derek Fawcus wrote: So it seems to me the minimal implementation would just be the two deprecated enum constants without the NSUnderlineByWordMask since this seems to be what Rhapsody provided. There isn't much difference between implementing single underline and implementing all of the various dot-dash styles. All of that stuff is implemented by NSBezierPath, so once you know where the underline is meant to go you just set a pattern on the path and draw. David -- Sent from my PDP-11 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Ok, I went too far, Terminal works. But I doesn't answer to 'Terminal/Open shell here' service needed by GWorkspace for example. Running midnight commander inside it is... interesting. But yes, it works as a terminal for most things. Sorry :o) If you want we can work on that. Don't get me wrong : I'm not opposed to multiple applications having the same goal. I just think the GNUstep project should select a set of applications and promote them as the minimal environnement. If I want to add a settings module, should I add it to Preferences, SystemPreferences or both ? Not necessarily a big deal but it might be confusing for users. Well, GNUstep hosts one implementation: SystemPreferences. Etoile or Backbone projects can choose to have their own. Each project has its freedom to pick or replace the apps provided by gnustep. GAP chooses to use GNUstep's SystemPreferences. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 09, 2009 at 12:32:42AM +0200, Riccardo Mottola wrote: > Hi, > >> Ok, I went too far, Terminal works. But I doesn't answer to >> 'Terminal/Open shell here' service needed by GWorkspace for example. >> Running midnight commander inside it is... interesting. But yes, it >> works as a terminal for most things. Sorry :o) >> >> > If you want we can work on that. Well, it would be easier if I had any idea how a terminal emulator works but why not. Philippe -- Engineers don't grow up, they grow sideways. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Well, having just glanced at a few docs, depending upon the desired level of compatibility, the approach outlined above seems reasonable. Most underline styles seem to have appeared with OSX 10.3 - i.e. the following: The real problem is not if it is dotted or continuous the problem is stopping for example the line between words or even around glyphs. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Forgot to reply to all! On Thu, Oct 8, 2009 at 10:45 AM, Nicola Pero < nicola.p...@meta-innovation.com> wrote: > > > It would undoubtedly be good to have some packager-specific > > documentation, but obviously the target readership is a very small > > group > > We *do* have packager documentation, in > > core/make/README.Packaging > > Feel free to add a short section about what was discussed here. :-) > I saw Richard committed something there. This is really the first time I've ever heard of GlobalDomain.plist, and will not forget it. > >> - How does this allow a packager to install and remove defaults as > >> part of package installation / uninstallation? Presumably you can > >> use plmerge to install them (again, is this documented anywhere?), > >> but how do you uninstall them? > > I agree with Richard's later suggestion that the package system might deal > with that > by having a directory where each package installs a .plist upon > installation, and removes > it upon deinstallation. At the end of each package > installation/deinstallation, the > package scripts could do a plmerge so that all the currently existing > .plists in the > directory are plmerged to create the global default plist, which is hence > kept up-to-date. :-) > > That said, it should probably be used with restrain ;-) > > Presumably you have a specific example in mind where it makes particular > sense (Etoile ?); but > in general, I personally don't see a reason why installing a package should > change some system defaults. > Installing a package doesn't necessarily mean enabling it. > > Eg, I could be installing 10 or 20 themes or other GNUstep GUI-changing > bundles, but that doesn't mean > every theme that is installed must be trying to force all users to switch > to it. I'd expect to have > a Preferences panel somewhere where I can change my own user defaults and > activate/deactivate the bundles > or themes I want/don't want. Different users might activate/deactivate > different bundles. > I agree with you, but the packager/distribution developers need to know what they want. For example, in Debian when I install "gnome-core" I get nothing but a plain GNOME desktop with no theming (default GTK theme), but when I install "gnome" I also get a few themes and theme engines installed but only 1 is sets Clearlook as the default theme. If the themes are installed separately (outside the "gnome" package) nothing happens, they're just installed and it's up to you to do something. Similarly, a "gnustep" package might want to install some core packages and an "etoile" package install Camaleon and it's themes and set 1 of them as default, setup horizontal menus, etc. So I think it is more important to have a very good preference application > that allow real users > to configure their environment to suit their needs, including turning > on/off bundles or extensions. :-) > > Thanks > By the way, is anyone keeping notes so that this won't all disappear after the discussion dies down? What I've gotten so far is: * Seems to be a consensus in keep GNUstep with it's default theme. GlobalDomain.plist allows packagers or distributions to global define their theme if it pleases them. * Everyone seems to want a new website. Content needs to be looked over because there is a lot of old and outdated information out there confusing newcomers. ** On the same topic, people also seem to be getting detracted by the decentralized information about GNUstep. * Packages, packages, packages. Last I heard we lost the person who did the packages for the Debian project (which is really bad). I've also been slacking on the Slackware packages (lack of time and a dedicated "play" computer). * Code beautification? Anything I missed so far? Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Am 08.10.2009 um 12:50 schrieb Richard Frith-Macdonald: On 8 Oct 2009, at 10:32, David Chisnall wrote: On 8 Oct 2009, at 07:29, Richard Frith-Macdonald wrote: GlobalDefaults.plist does that. Two questions then: - Is this actually documented anywhere? I see a vague reference to it in NSUserDefaults, but packagers are absolutely not going to read API docs (and should not be expected to. With the documentation for GNUstep.conf in the main base library documentation (I put a link in an earlier email). I think you have to be realistic ... a packager *does* have to read some documentation in order to package a big system like GNUstep properly. It would undoubtedly be good to have some packager-specific documentation, but obviously the target readership is a very small group A small but nevertheless very important group of people. Those people are our link to average-joe-users, who don't bother compiling stuff themselves. Nowadays the majority of users installs software using a package manager or a port system, only the most advanced users will still compile software "by hand". So if we want GNUstep to be used we have to get it into the package systems of those distros. For that to happen we need the help of packagers. So we should make sure that packaging is as easy and painless as possible. One part of this is to teach the packagers the basic principles about GNUstep's architecture so they understand how to build GNUstep without banging their heads against the wall first. I already talked about this here: http://groups.google.com/group/ gnu.gnustep.discuss/browse_thread/thread/11c448aa294cdee9 As a first measure we should probably just link http://svn.gna.org/ svn/gnustep/tools/make/trunk/README.Packaging from the frontpage so that this information is available on our website too. That link should be prominently visible from the front page of our website. Later we can create a dedicated web page for this, if it might be a FAQ, a wiki page or a beefed up HTML-version of README.Packaging with some useful links, for instance to one of the guides from http:// wiki.gnustep.org/index.php/User_Guides#Installing_GNUstep (why are there so many?) and maybe http://wiki.gnustep.org/index.php/ Dependencies remains to be discussed. regards, Lars ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. Completely agree. Good coding conventions are picked because they make things that are wrong look wrong or generate compiler errors / warnings. The GNU coding conventions were picked by selecting at random various bits from all existing coding conventions in the hope that that would make everyone happy. They are a horrible mash of things. The indenting style is horrible, for example, and only works if you have your editor set up in exactly the same way as RMS; mixing tabs and spaces for indenting is one of the most stupid ideas I've ever seen. The convention of putting a space after function names and before the open bracket makes code harder to read because it makes it difficult to tell without reading the context that something is an argument list rather than a subexpression. In fact, almost everything about the GNU coding conventions looks painfully stupid to anyone with a basic understanding of how the human visual system works, but as an official GNU project we are stuck with it. I didn't know you have to stick to the GNU coding guidelines if you are an official GNU project. Now I understand all the people complaining about gcc being unreadable... Just to clarify for the non-developers, GCC being unreadable is a completely different problem, not particularly due to the coding style. ;-) Having a standard coding style for the whole GNUstep project is really important as it makes it easier to copy/move code from one part of the project to the other. Using a "standard" coding style that is documented and used by many other projects is also good as contributors will be immediately familiar with it. The GNU coding standards are used by a large number of projects with a lot of contributors and popularity so can't really be blamed if GNUstep is less popular than, say, GIMP (which also happens to follow the GNU coding standards) or any of the other million projects that use the GNU coding standards or some variants of them. While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. If it's a burning issue for many developers, I guess changing the coding style to something else could be discussed. There would be *lots* of reformatting to do if we ever reach an agreement on some other coding style. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Gregory. Hi, guys.
I can't resist expressing my opinion on GNUstep changes as I see it.
I've defined several problem areas of GNUstep:
1. Maturity of GNUstep code for developers (functionality, docs, stability)
2. GUI appearance
3. Portability
4. Applications
Gregory, behind all things you've mentioned I see a goal that can be
expressed by the
following phrase: "World (all stuff outside of GNUstep) acceptance of
GNUstep as alternative
developer framework that will help creating of alternative desktop
environment."
Do you really think that improving website, theme (argh!) lead us to rise
of user attention
to GNUstep? I don't think so. I see a lot of people comparing GNUstep with
GNOME/KDE ("What's
Etoile? Another desktop environment? Why we should use it?"). IMHO it's
not our target audience.
In my strong opinion our target audience could be:
- NeXTSTEP/OPENSTEP users who misses NS/OS look, feel and user experience
in general (I'm one of them);
- developers who knows what OpenStep and Cocoa are;
- technical people who loves WindowMaker;
- researchers, students who can use GNUstep as basement for it's works.
In my opinion GNUstep project needs more forcible approach to reach the
goal I've phrased above.
I propose to discuss the following approach:
1. Select reference platform for GNUstep development. Make GNUstep work
ideally on one platform and
then port it to another. My choice is FreeBSD (Xorg 7.4, ART GUI
backend) despite the fact that I'm
Linux user for over 13 years. I have set of strong reasons for this, we
can discuss it later.
2. Stop chasing MacOS functionality. Let's set our target to for example
MacOS 10.5 for a several years.
In other words - polish and finish current implementation.
3. Stop trying to work everywhere. Let's make it working good at one
place, then go to another. Let's
speak frankly - we can't compete with Qt. Despite the existing of DO,
Objective-C and other great things.
4. Make work good ONE FINISHED gui backend on reference platform with all
needed functionality (OpenGL,
Fonts, Graphics).
5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts,
graphics to name a few.
6. Create working destop environment for developers at least. Some day I
realized that I'm working
inside mess of not interacting things. My plan is:
- Create Login application
- Create Preferences
- Create Workspace Manager (Workspace + WindowMaker), excellent
integration of GNUstep with it (focus,
app management, dock interaction).
- Create Terminal application based on Alex Malmberg application.
- Create Mail application (GNUmail can be used as starting point).
- Finish ProjectCenter (anyway it's my responsibility).
7. Make it clean, fast and simple as NS/OS. Personally I'm tired of
bloated desktop environments (KDE/GNOME).
I want improved (at reasonable degree) OPENSTEP.
It's not a plan targeting on world domination. It's plan to make
comfortable development environment as I see it.
And if it will be comfortable to me it can be useful to somebody else.
Summarizing this long email: we should focus on achievable goals by
narrowing down portability and loosing
competition with MacOS for now. Let's agree on strong, clean, simple
vision of project future and users will
come.
On Wed, 07 Oct 2009 22:24:01 +0300, Gregory Casamento
wrote:
Guys,
There are a number of things which need to change on the project:
We need to:
1) improve our website. It's been the same for years and doesn't
reflect our progress.
2) improve GNUstep's default theme as well as theming in general.
While I know some people will respond negatively to changing the
default theme from a NeXT-like look to something more modern, I
believe it's one way for us to spark interest in the project is to
update it's look. The current look should always be available, but
not necessarily the default.
3) Improve our ability to market ourselves in general.
One thing that GNUstep has been lacking in is marketing. I've been
trying to improve things on that front, but I'm not the best marketer
to say the very least.
Does anyone have any questions or comments regarding this? I would
like to hear any and all input people have.
Later, GC
--
Sergii Stoian
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 09, 2009 at 12:52:34AM +0200, Riccardo Mottola wrote: > Hi, > > Well, having just glanced at a few docs, depending upon the desired > > level of compatibility, the approach outlined above seems reasonable. > > > > Most underline styles seem to have appeared with OSX 10.3 - i.e. the > > following: > > The real problem is not if it is dotted or continuous > the problem is stopping for example the line between words or even around > glyphs. Which is why I suggested initially only implementing Rhapsody compatibility here, since it did not support skipping the underlying of whitespace. This would at least provide _some_ underlying, and the 'problem' could be tacked later. .pdf ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 13:03, Felix Holmgren wrote: While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. Given that part of the aim of GNUstep is to track Cocoa, might it not make sense to use the Apple coding guidelines for everything that's written in Objective-C? http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html Those guidelines ARE pretty much consistently used in GNUstep. The coding style issues we are probably talking about here are those to do with the use of: indentation brackets white-space Generally, whenever someone comes along and complains about the style used, they have their own 'good reasons' why their style is preferred/ justified. Certainly, when I started working on the GNUstep project, my style was very different from the GNU style, and I could have provided reasons why my style was better :-) None of those arguments carry any weight whatsoever ... because there are always plenty of people with other preferred styles and their own reasons for using them. We use the GNU style almost solely because of the value of consistency (the fact that we are a GNU project probably explains why it was originally chosen) ... once you are used to it, you can work on any part of the code without finding the style hard to read. While there are a few 'religious' people who are convinced that everyone else should adopt their style, almost everyone accepts that a consistent standard is useful and that any attempt to change the style, once adopted, would be severely counterproductive. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi! While I think the wiki is a good idea, it's not a substitute for an official project page, which needs to say: - This project is alive. - This project is shiny. - This project is actively used by some people. I'm with you there :) As much as I love GNUstep base, I do not like GNUstep gui. Don't get me wrong, I still burst in tears of agony if I have to use another GUI library than GNUstep gui, because everyone still treats GUI as code, even C# and WindowsForms. GNUstep gui still lacks in polishing. Using a graphical GNUstep application on Gnome/KDE/Xfce ist still a pain because: I don't completely disagree here. I think -gui has improved a huge amount in the last year, mostly due to Fred's work. Nicolas, Fred and Quentin worked a bit on live resizing at the Étoilé hackathon, which makes things look a lot more modern. Things are still slower than they should be and we need to do some profiling to work out why that is. Currently I don't work that much with gui, all I need is a window with an OpenGL context and in some cases an additional window with some settings. I am still using the art backend as I had issues with cairo (window and contents didn't display correctly, black polygons all over the place), but I am still using Ubuntu 8.04, so maybe the cairo package is rather outdated. What comes to my mind regarding GNUstep applications is that for a long time now my perception is that Gorm is the only serious GNUstep application. It works, it does it's job and it is maintained. No other GNUstep application fulfilling those criteria comes to my mind. There are also some plainly embarrassing bugs, like the fact that underlining still doesn't work. Much of the text system code is in need of an overhaul, because it's currently a mess of premature optimisation that none of the current developers actually understands. Ouch. Another issue is code quality. For example, the code in GNUstep back is one hell of an ugly mess. I had to touch it, but I felt a chill running down my spine in doing so. Everything in XGServerEvent and associates looks like a mass of hacks piled on top of each other. It's such a chaos, I do not want to touch it anymore in fear of breaking somthing completely unrelated. Back also frightens me. At the hackathon, I talked to Fred a bit about refactoring it so that, long term, all that -back will do is create drawing contexts and handle events. We will then use a CoreGraphics implementation, probably based on Opal (which was just copyright assigned to GNUstep, I believe) to handle drawing using Cairo. This would let us use the same drawing code on X11, Win32 and on any of the other platforms Cairo supports (e.g. Zeta, OS/2, DirectFB), with just a small amount of new code for turning the platform's native events into NSEvents and for calling the cairo functions for creating graphics contexts. Sounds reasonable :) Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. Completely agree. Good coding conventions are picked because they make things that are wrong look wrong or generate compiler errors / warnings. The GNU coding conventions were picked by selecting at random various bits from all existing coding conventions in the hope that that would make everyone happy. They are a horrible mash of things. The indenting style is horrible, for example, and only works if you have your editor set up in exactly the same way as RMS; mixing tabs and spaces for indenting is one of the most stupid ideas I've ever seen. The convention of putting a space after function names and before the open bracket makes code harder to read because it makes it difficult to tell without reading the context that something is an argument list rather than a subexpression. In fact, almost everything about the GNU coding conventions looks painfully stupid to anyone with a basic understanding of how the human visual system works, but as an official GNU project we are stuck with it. I didn't know you have to stick to the GNU coding guidelines if you are an official GNU project. Now I understand all the people complaining about gcc being unreadable... 3) Improve our ability to market ourselves in general. Yep. IMHO Distributed Objects alone is one hell of a feature, making it worth to use Foundation just because of that. Yup, DBUS is a horribly hacky clone of DO and people seem to get excited about it. DO could be a killer feature, if more people were aware of it. I do love Foundation because it provides me with a lot of stuff which I need every day. I do not have to care about strings, I do not have to care about file management, all the containers are pretty si
Re: Changes I've been thinking of...
Well as I really new GNUstep user, at least for the last week :) I will try to put my two cents here: As a new user I ahve to say I have been trying to use GNUstep for a while but two weeks ago I found the time to compile and install everything. So for a new user is not easy to get GNUstep, there are tw problems: - Distributions don't have a good support, I am usign fedora and I have to built everything from scratch no packages at all. - The webstie is old, it doesn't give you the information to get the proper packages and give you a clear idea of waht is the best process and understand how GNUstep works and should be installed, I found this document, is a bit old but more useful than the docs in the web: http://gnustep.made-it.com/BuildGuide/index.html#BUILDING.GNUSTEP About what gnustep need, I a magree with the people that thinks it really need applications. Themes are good, but apps are more important, first a good development environment needs good apps so people thinks this is a good one. So I think affort should be directed to get a good set of tools to have a good working environment. Why Etoile and gnustep? I think that know etoile and gnustep should be working together in the same project, so you guys can provide a global computing environment, like Mac basically. This is the development environment. This is the working environment. And finally here are some core applications. That the things people needs. The development environmetn seems to be there (I haven't develop nothing using gnustep), the working environment is pretty just some polish and some updates, like haveing the owrkspace in a menubar (at least as an option) like in the mac, the current toolchest model is a little bit old I think, things like that. But the area that needs more work is some core apps, really good core apps. Is the formula used by Ubuntu, they give you some apps, not too much as many other distros used to do, only some the most useful but really good. What can be put as core apps is probably another discussion. Onece gnustep has some core apps I think the next step is the theming thing to make the whole environment more good looking and modern (althogh I still prefer the old NExT look), and the intalling and packaging. An install process for every platform, somebody probably remember the gnome version launched by Ximian some time ago. You can go to the Ximian'swebsite and download an install script with gui that automates the whole process of installing gnome from the sources. And in the other hand ease the packaging process for distros. Finally is the marketing thing. I think there is no point toi spend time in marketing and good looking website whereas there aren't good apps, people probably is going to try gnustep but withouta good and complete working environment peoplr will give up, but in the time there is a good working environment istime to show and maket it like crazy.; My two cents. PD: I am still trying to get a complete gnustep working desktop, I haven't gave up yet :) 2009/10/7 Gregory Casamento > Guys, > > There are a number of things which need to change on the project: > > We need to: > 1) improve our website. It's been the same for years and doesn't > reflect our progress. > 2) improve GNUstep's default theme as well as theming in general. > While I know some people will respond negatively to changing the > default theme from a NeXT-like look to something more modern, I > believe it's one way for us to spark interest in the project is to > update it's look. The current look should always be available, but > not necessarily the default. > 3) Improve our ability to market ourselves in general. > > One thing that GNUstep has been lacking in is marketing. I've been > trying to improve things on that front, but I'm not the best marketer > to say the very least. > > Does anyone have any questions or comments regarding this? I would > like to hear any and all input people have. > > Later, GC > -- > Gregory Casamento > Open Logic Corporation, Principal Consultant > yahoo/skype: greg_casamento, aol: gjcasa > (240)274-9630 (Cell) > > > ___ > Discuss-gnustep mailing list > discuss-gnus...@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnustep > -- Un saludo Best Regards Pablo Giménez ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 2009-10-08 02:08:35 +0200 Riccardo Mottola wrote:
Hi all,
I have not had much time to look at GNUMail, but I just set the
delegat to nil in the controllers to avoid the crashes when the
toolbar is trying to dealloc.
I have attached the diff to this mail - but I guess someone (Ludovic)
should really review it since I am really not a top coder (just want
to fix things when they are broken).
Hope it helps,
Tim
Hi,
Philippe Roussel wrote:
For me, the one thing that really lowers GNUstep credibility is the
super high 'bitrot factor' : a lot of the software found in the wiki
is outdated, or it's website disappeared, or it won't compile or it's
almost useless. Building the core librairies is good (thanks guys !)
but we need a good set of working applications, easily found and
easily built.
Trgives the user a terrible impression.
One example I ran recently is AddressManager and the VCFViewer
inspector. There is one version in GAP, one version in Etoile. One
version of VCFViewer in AddressManager tree and one in GWorkspace
website and wiki page.
I the official Addresses, Bjoern "donated" it to us.
GAP has become a kitchen-sink for apps not loved by their owners
anymore... I
try my best to keep them going and added in the last years several
applications!
When a core developer like Enrico leaves, it leaves a lot of stuff...
I don't
think everybody realized how much Enrico did for GNUstep. With the
releases,
the wiki pages will be corrected, etc etc. We're gettign there, just
slowly.
You yourself are helping me out lately!
There are multiple terminal applications (gap, backbone, etoile ?)
but
none really usable (to my knowledge, maybe I missed something).
ThI use it every single day! It may miss some features but works. ANd
I
assume backbone's does too, the code bae is essentially the same, but
the
philosophies about releases, makefiles etc. differ.
There is Preferences and SystemPreferences.
Itwindows too... SystemPreferences is from Enrico, it is Apple
compatible.
Preference's is more limited in the UI, has different modules but
looks
better :)
GNUMail doesn't work for me and seems stalled.
Thmade a partial patch... but it is left there. He can tell us the
details.
But furthermore Ludovic should accept the patch, commit and make a
new beta
tarball.
What I'm trying to say is that I think we should try to centralize
things (one repository for all !) and work on a set of defined
applications instead of collecting random stuff.
Ththe gnustep main site.
One last thing about stable/unstable : the website frontpage
advertize
gnustep startup 0.23.0 as a stable release with make 2.2.0, base
1.19.1,
gui 0.17.0 and back 0.17.0.
In the download page, stable startup version is 0.22.0 and unstable
0.19.3. Stable base is 1.18.0 which for me means that base 1.19.1
included in startup 0.23.0 is not stable. Same thing for gui and
back.
Question is : what should I download ?!
Our downloads are terribly confusing!
I hope this doesn't sound too negative, really. I really like GNUstep
and wish to use a GNUstep desktop one day :o).
It is honest, which is what counts.
Riccardo
___
Discuss-gnustep mailing list
discuss-gnus...@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
diff -rupN GNUMail/Framework/GNUMail/EditWindowController.m GNUMail.tk/Framework/GNUMail/EditWindowController.m
--- GNUMail/Framework/GNUMail/EditWindowController.m 2007-04-23 10:04:51.0 +0200
+++ GNUMail.tk/Framework/GNUMail/EditWindowController.m 2009-08-22 22:06:04.0 +0200
@@ -364,7 +364,7 @@
- (void) dealloc
{
NSDebugLog(@"EditWindowController: -dealloc");
-
+ [[self window] setDelegate:nil];
[[NSNotificationCenter defaultCenter] removeObserver: self];
#ifdef MACOSX
diff -rupN GNUMail/Framework/GNUMail/MailWindowController.m GNUMail.tk/Framework/GNUMail/MailWindowController.m
--- GNUMail/Framework/GNUMail/MailWindowController.m 2007-04-09 10:03:46.0 +0200
+++ GNUMail.tk/Framework/GNUMail/MailWindowController.m 2009-08-25 16:17:24.0 +0200
@@ -310,7 +310,7 @@
- (void) dealloc
{
NSDebugLog(@"MailWindowController: -dealloc");
-
+ [[self window] setDelegate: nil];
[[NSNotificationCenter defaultCenter]
removeObserver: mailHeaderCell
name: @"NSViewFrameDidChangeNotification"
diff -rupN GNUMail/Framework/GNUMail/MessageViewWindowController.m GNUMail.tk/Framework/GNUMail/MessageViewWindowController.m
--- GNUMail/Framework/GNUMail/MessageViewWindowController.m 2007-03-12 10:03:42.0 +0100
+++ GNUMail.tk/Framework/GNUMail/MessageViewWindowController.m 2009-08-22 22:05:13.0 +0200
@@ -129,7 +129,7 @@
- (void) dealloc
{
NSDebugLog(@"MessageViewWindowController: dealloc called for message window: %@", [message subject]);
-
+ [[self window] setDelegate: nil];
[[NSNotificationCenter defaultCenter] removeObserver: mailHeaderCell
name: @"NSViewFrameDid
Re: Changes I've been thinking of...
Thanks for the clarification David. Now looking at the GNGUstep panorama I must say that probably which needs an improvement to make GNUstep more appeal is the GAP project. The set of tools there are what could be considered as the core applications (except for GWorspace, SystemPreferences and the dev tools provided by GNUstep otself). El 8 de octubre de 2009 20:33, David Chisnall escribió: > On 8 Oct 2009, at 18:22, Pablo Giménez wrote: > > Why Etoile and gnustep? I think that know etoile and gnustep should be >> working together in the same project, so you guys can provide a global >> computing environment, like Mac basically. >> > > > Étoilé and GNUstep have different goals. > > The aim of GNUstep is to produce a first-rate set of modern, > object-oriented, developer tools and APIs based around the OpenStep > specification, tracking changes from Cocoa, and incorporating extensions > where required. > > The aim of Étoilé is to produce a modern user environment using a service- > and document-driven model with ubiquitous persistence, versioning, and > collaboration support, with ideas from THE and Smalltalk, as well as from > OPENSTEP and various other places. > > You can use GNUstep without using any of Étoilé. You can use some bits of > Étoilé without using GNUstep (although we haven't ported some of the best > bits to OS X as they mostly rely on things that aren't present there). > > Most of the Étoilé core team also have commit access to GNUstep. When > things make more sense in GNUstep, we try to make sure that they go there > and when Étoilé code exposes bugs in GNUstep we try to fix them (or, in my > case, moan to Fred about them, which generally has the same result). When > things are not part of GNUstep's more focussed goals, we put them in Étoilé. > Sometimes code flows from Étoilé to GNUstep, as GNUstep's goals broaden. > > Not everybody who uses or contributes to GNUstep agrees with the directions > Étoilé is taking, and there are projects like GAP and Backbone to produce > more traditional, application-oriented, desktops. GNUstep's goals include > supporting these developers too. > > Choice is good when it doesn't lead to duplication of effort, and because > Étoilé builds on top of GNUstep this duplication usually doesn't occur. > > David > > -- Sent from my Difference Engine > > > > -- Un saludo Best Regards Pablo Giménez ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
100% agree
2009/10/9 Sergii Stoian
> Hi, Gregory. Hi, guys.
>
> I can't resist expressing my opinion on GNUstep changes as I see it.
>
> I've defined several problem areas of GNUstep:
>
> 1. Maturity of GNUstep code for developers (functionality, docs, stability)
> 2. GUI appearance
> 3. Portability
> 4. Applications
>
> Gregory, behind all things you've mentioned I see a goal that can be
> expressed by the
> following phrase: "World (all stuff outside of GNUstep) acceptance of
> GNUstep as alternative
> developer framework that will help creating of alternative desktop
> environment."
>
> Do you really think that improving website, theme (argh!) lead us to rise
> of user attention
> to GNUstep? I don't think so. I see a lot of people comparing GNUstep with
> GNOME/KDE ("What's
> Etoile? Another desktop environment? Why we should use it?"). IMHO it's not
> our target audience.
> In my strong opinion our target audience could be:
> - NeXTSTEP/OPENSTEP users who misses NS/OS look, feel and user experience
> in general (I'm one of them);
> - developers who knows what OpenStep and Cocoa are;
> - technical people who loves WindowMaker;
> - researchers, students who can use GNUstep as basement for it's works.
>
> In my opinion GNUstep project needs more forcible approach to reach the
> goal I've phrased above.
> I propose to discuss the following approach:
>
> 1. Select reference platform for GNUstep development. Make GNUstep work
> ideally on one platform and
> then port it to another. My choice is FreeBSD (Xorg 7.4, ART GUI backend)
> despite the fact that I'm
> Linux user for over 13 years. I have set of strong reasons for this, we
> can discuss it later.
> 2. Stop chasing MacOS functionality. Let's set our target to for example
> MacOS 10.5 for a several years.
> In other words - polish and finish current implementation.
> 3. Stop trying to work everywhere. Let's make it working good at one place,
> then go to another. Let's
> speak frankly - we can't compete with Qt. Despite the existing of DO,
> Objective-C and other great things.
> 4. Make work good ONE FINISHED gui backend on reference platform with all
> needed functionality (OpenGL,
> Fonts, Graphics).
> 5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts,
> graphics to name a few.
> 6. Create working destop environment for developers at least. Some day I
> realized that I'm working
> inside mess of not interacting things. My plan is:
> - Create Login application
> - Create Preferences
> - Create Workspace Manager (Workspace + WindowMaker), excellent
> integration of GNUstep with it (focus,
> app management, dock interaction).
> - Create Terminal application based on Alex Malmberg application.
> - Create Mail application (GNUmail can be used as starting point).
> - Finish ProjectCenter (anyway it's my responsibility).
> 7. Make it clean, fast and simple as NS/OS. Personally I'm tired of bloated
> desktop environments (KDE/GNOME).
> I want improved (at reasonable degree) OPENSTEP.
>
> It's not a plan targeting on world domination. It's plan to make
> comfortable development environment as I see it.
> And if it will be comfortable to me it can be useful to somebody else.
>
> Summarizing this long email: we should focus on achievable goals by
> narrowing down portability and loosing
> competition with MacOS for now. Let's agree on strong, clean, simple vision
> of project future and users will
> come.
>
> On Wed, 07 Oct 2009 22:24:01 +0300, Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
> Guys,
>>
>> There are a number of things which need to change on the project:
>>
>> We need to:
>> 1) improve our website. It's been the same for years and doesn't
>> reflect our progress.
>> 2) improve GNUstep's default theme as well as theming in general.
>> While I know some people will respond negatively to changing the
>> default theme from a NeXT-like look to something more modern, I
>> believe it's one way for us to spark interest in the project is to
>> update it's look. The current look should always be available, but
>> not necessarily the default.
>> 3) Improve our ability to market ourselves in general.
>>
>> One thing that GNUstep has been lacking in is marketing. I've been
>> trying to improve things on that front, but I'm not the best marketer
>> to say the very least.
>>
>> Does anyone have any questions or comments regarding this? I would
>> like to hear any and all input people have.
>>
>> Later, GC
>>
>
> --
> Sergii Stoian
>
>
>
> ___
> Discuss-gnustep mailing list
> discuss-gnus...@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnustep
>
--
Un saludo
Best Regards
Pablo Giménez
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
> While I sympathize with David who prefers (or is used) to some other coding > style, > the GNUstep project needs a consistent coding style and the GNU coding > standard > are as good a choice as any. Since GNUstep is a GNU project, it's a natural > choice. > Given that part of the aim of GNUstep is to track Cocoa, might it not make sense to use the Apple coding guidelines for everything that's written in Objective-C? http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html /F ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Am 09.10.2009 um 11:27 schrieb Sergii Stoian: "World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment." Now I can't resist to comment either ;-) "Platforms" aren't just a set of kernel and appropriate drivers these days, they are full functioning desktops already. So, while an alternative to Xfce / KDE / Gnome might be desireable for some people, the very most open source OS users won't bother on GNUstep applications if they don't fit into their preferred desktop environment. As a Ubuntu user I can seamlessly install (packaged) KDE apps and use them next to Gnome apps. The same should be true for GNUstep apps. Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. Strongly preferring WindowMaker is plain counter productive. Insisting on a own clipboard system will do nothing but confuse users. Those dock- like miniwindows are simply annoying (for Gnome users). Command line stuff is - well many users don't know what a command line is, after all. Integration with the neighbor's desktop is the state of the art. Even the biggies like KDE or Gnome can't afford to ignore the others. Markus P.S.: Currently I'm using Cocotron. Much less matured, but integrates much better. Braindead simple porting from Cocoa, standalone applications ! P.P.S.: Sorry for ranting so much. I just wanted to add another perspective. - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
See below... On Fri, Oct 9, 2009 at 11:06 AM, Markus Hitter wrote: > > Am 09.10.2009 um 11:27 schrieb Sergii Stoian: > >> "World (all stuff outside of GNUstep) acceptance of GNUstep as alternative >> developer framework that will help creating of alternative desktop >> environment." > > Now I can't resist to comment either ;-) > > "Platforms" aren't just a set of kernel and appropriate drivers these days, > they are full functioning desktops already. So, while an alternative to Xfce > / KDE / Gnome might be desireable for some people, the very most open source > OS users won't bother on GNUstep applications if they don't fit into their > preferred desktop environment. > > As a Ubuntu user I can seamlessly install (packaged) KDE apps and use them > next to Gnome apps. The same should be true for GNUstep apps. Absolutely agreed. > Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are > two dozen other terminal apps out there already. Strongly preferring > WindowMaker is plain counter productive. I believe we need to start integrating better with other desktops/window managers. > Insisting on a own clipboard system > will do nothing but confuse users. The unfortunate truth here is that there are still some features of the other guys pasteboard servers which don't server our needs at all. > Those dock-like miniwindows are simply > annoying (for Gnome users). You can turn them off. > Command line stuff is - well many users don't > know what a command line is, after all. ?? I'm not sure what you mean here. > Integration with the neighbor's desktop is the state of the art. Even the > biggies like KDE or Gnome can't afford to ignore the others. Indeed. > > Markus > > > P.S.: Currently I'm using Cocotron. Much less matured, but integrates much > better. Braindead simple porting from Cocoa, standalone applications ! I'm sorry to hear this. GNUstep, in my opinion, does need something similar to Cocotron's SDK. Dr. Schaller has already made something similar for ARM so that he can cross compile for the ARM platform so it's not terribly difficult... it's just not something we've done for Windows yet. > P.P.S.: Sorry for ranting so much. I just wanted to add another perspective. That's fine. > - - - - - - - - - - - - - - - - - - - > Dipl. Ing. Markus Hitter > http://www.jump-ing.de/ > > > > > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 16:34, Gregory Casamento wrote: I'm sorry to hear this. GNUstep, in my opinion, does need something similar to Cocotron's SDK. Dr. Schaller has already made something similar for ARM so that he can cross compile for the ARM platform so it's not terribly difficult... it's just not something we've done for Windows yet. Apple, unfortunately, branched clang for XCode 3.2 just before I put a lot of fixes in. Their next release, however, will include a version of clang that can target the GNU runtime properly. To cross-compile for Windows / Linux / whatever you will just need copies of the relevant headers and to set the include paths and target triple correctly, so we can probably provide a plugin that does that quite easily. That said, if you use svn or some other version control system from XCode, then it's trivial to automate building on a native platform already with GNUstep; just check out your svn repository and run pbxbuild; put this in an hourly cron job in a VM or a real machine, and you've got an automated build. David -- Sent from my PDP-11 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, 09 Oct 2009 18:06:45 +0300, Markus Hitter wrote: Am 09.10.2009 um 11:27 schrieb Sergii Stoian: "World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment." Now I can't resist to comment either ;-) "Platforms" aren't just a set of kernel and appropriate drivers these days, they are full functioning desktops already. So, while an alternative to Xfce / KDE / Gnome might be desireable for some people, the very most open source OS users won't bother on GNUstep applications if they don't fit into their preferred desktop environment. Markus, why do you think that users of Xfce/KDE/GNOME should bother on GNUstep applications at all? I guess user first tries to find app that is native to it's DE. Second he looks for neighbor variants. If you want GNUstep apps to fit into Xfce/KDE/GNOME then you need to change not only look (scrollbars, menu style, etc.) but also FEEL of applications. Generally speaking, GNUstep application should look and feel as user's preferred desktop application. Finally it leads to bloating of code and problems with maintenance (considering our developer resources). Does GNUstep applications should look & feel as Qt and GTK+ apps? This is a dead end for GNUstep project I guess. As a Ubuntu user I can seamlessly install (packaged) KDE apps and use them next to Gnome apps. The same should be true for GNUstep apps. Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. And browsers, file managers, IDEs, mail clients, editors... That's what I'm trying to say about. There will be no charm in such approach. NS/OS has charm even today I think. Strongly preferring WindowMaker is plain counter productive. Using GNUstep applications in, for example, GNOME is stupid. I see no sense in using 'TextEdit' instead of 'gedit' and so on. Sorry, It's not an argument. I see WindowMaker as: 1. part of Workspace Manager 2. reference window manager for GNUstep applications. Insisting on a own clipboard system will do nothing but confuse users. Those dock-like miniwindows are simply annoying (for Gnome users). Command line stuff is - well many users don't know what a command line is, after all. Integration with the neighbor's desktop is the state of the art. Even the biggies like KDE or Gnome can't afford to ignore the others. GNOME and KDE has similar point of view on how desktop should be organized. NS/OS has different philosophy. It's not only about look&feel. Markus P.S.: Currently I'm using Cocotron. Much less matured, but integrates much better. Braindead simple porting from Cocoa, standalone applications ! P.P.S.: Sorry for ranting so much. I just wanted to add another perspective. I guess everybody agreed that this is not dispute - it's exchange of opinions. -- Sergii Stoian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
See below... On Fri, Oct 9, 2009 at 11:45 AM, David Chisnall wrote: > On 9 Oct 2009, at 16:34, Gregory Casamento wrote: > >> I'm sorry to hear this. GNUstep, in my opinion, does need something >> similar to Cocotron's SDK. Dr. Schaller has already made something >> similar for ARM so that he can cross compile for the ARM platform so >> it's not terribly difficult... it's just not something we've done for >> Windows yet. > > Apple, unfortunately, branched clang for XCode 3.2 just before I put a lot > of fixes in. Their next release, however, will include a version of clang > that can target the GNU runtime properly. To cross-compile for Windows / > Linux / whatever you will just need copies of the relevant headers and to > set the include paths and target triple correctly, so we can probably > provide a plugin that does that quite easily. > > That said, if you use svn or some other version control system from XCode, > then it's trivial to automate building on a native platform already with > GNUstep; just check out your svn repository and run pbxbuild; put this in an > hourly cron job in a VM or a real machine, and you've got an automated > build. > > David Well, yeah... I do know about pbxbuild since I helped develop it. The point is that the majority of mac devs expect things to be done completely from the mac. -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Stef, This does seem to be the consensus Now we need help to actually make it happen. GC On Thu, Oct 8, 2009 at 7:30 PM, Stef Bidi wrote: > Forgot to reply to all! > > On Thu, Oct 8, 2009 at 10:45 AM, Nicola Pero > wrote: >> >> > It would undoubtedly be good to have some packager-specific >> > documentation, but obviously the target readership is a very small >> > group >> >> We *do* have packager documentation, in >> >> core/make/README.Packaging >> >> Feel free to add a short section about what was discussed here. :-) > > I saw Richard committed something there. This is really the first time I've > ever heard of GlobalDomain.plist, and will not forget it. > >> >> >> - How does this allow a packager to install and remove defaults as >> >> part of package installation / uninstallation? Presumably you can >> >> use plmerge to install them (again, is this documented anywhere?), >> >> but how do you uninstall them? >> >> I agree with Richard's later suggestion that the package system might deal >> with that >> by having a directory where each package installs a .plist upon >> installation, and removes >> it upon deinstallation. At the end of each package >> installation/deinstallation, the >> package scripts could do a plmerge so that all the currently existing >> .plists in the >> directory are plmerged to create the global default plist, which is hence >> kept up-to-date. :-) >> >> That said, it should probably be used with restrain ;-) >> >> Presumably you have a specific example in mind where it makes particular >> sense (Etoile ?); but >> in general, I personally don't see a reason why installing a package >> should change some system defaults. >> Installing a package doesn't necessarily mean enabling it. >> >> Eg, I could be installing 10 or 20 themes or other GNUstep GUI-changing >> bundles, but that doesn't mean >> every theme that is installed must be trying to force all users to switch >> to it. I'd expect to have >> a Preferences panel somewhere where I can change my own user defaults and >> activate/deactivate the bundles >> or themes I want/don't want. Different users might activate/deactivate >> different bundles. > > I agree with you, but the packager/distribution developers need to know what > they want. For example, in Debian when I install "gnome-core" I get nothing > but a plain GNOME desktop with no theming (default GTK theme), but when I > install "gnome" I also get a few themes and theme engines installed but only > 1 is sets Clearlook as the default theme. If the themes are installed > separately (outside the "gnome" package) nothing happens, they're just > installed and it's up to you to do something. > > Similarly, a "gnustep" package might want to install some core packages and > an "etoile" package install Camaleon and it's themes and set 1 of them as > default, setup horizontal menus, etc. > >> So I think it is more important to have a very good preference application >> that allow real users >> to configure their environment to suit their needs, including turning >> on/off bundles or extensions. :-) >> >> Thanks > > > By the way, is anyone keeping notes so that this won't all disappear after > the discussion dies down? What I've gotten so far is: > > * Seems to be a consensus in keep GNUstep with it's default theme. > GlobalDomain.plist allows packagers or distributions to global define their > theme if it pleases them. > * Everyone seems to want a new website. Content needs to be looked over > because there is a lot of old and outdated information out there confusing > newcomers. > ** On the same topic, people also seem to be getting detracted by the > decentralized information about GNUstep. > * Packages, packages, packages. Last I heard we lost the person who did the > packages for the Debian project (which is really bad). I've also been > slacking on the Slackware packages (lack of time and a dedicated "play" > computer). > * Code beautification? > > Anything I missed so far? > > Stefan > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 19:19, Gregory Casamento wrote: Well, yeah... I do know about pbxbuild since I helped develop it. The point is that the majority of mac devs expect things to be done completely from the mac. My point was that this is something we could automate pretty trivially. I managed to get Darwine building (but not running) Windows versions of GNUstep apps, and it would be pretty simple to package up a virtual appliance that people could open with VirtualBox on their Mac and just point at an svn repository and get automated builds. Same with Darwine; we could package up a .wine directory containing GNUstep with this. If someone is interested in cross developing from OS X (I'm not especially), then it's the kind of project that someone without much programming experience could put together. David -- Sent from my Difference Engine ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Sergii, please see below. Am 09.10.2009 um 17:34 schrieb Gregory Casamento: Command line stuff is - well many users don't know what a command line is, after all. ?? I'm not sure what you mean here. Well, malfunctions in GNUstep are often answered by a few text commands which fix things. For example, Wolfgang Lux explained just yesterday how to fix services in Terminal.app. While Terminal.app is a special case in this regard, you can't expect users to fix things by typing commands in a shell. Things are either figured by the app without user interaction (preferred), or need a GUI. Am 09.10.2009 um 18:15 schrieb Sergii Stoian: Markus, why do you think that users of Xfce/KDE/GNOME should bother on GNUstep applications at all? Because quite a few nice applications are written in GNUstep. Think about GNUmail, it has just the right design for users used to Apple Mail. Think about TextEdit, which roughly matches Apple's TextEdit and can (well, should be able to) handle the RTF format. Think about all those Cocoa apps out there just waiting to be ported to Linux or *BSD. There are plenty. If you want GNUstep apps to fit into Xfce/KDE/GNOME then you need to change not only look (scrollbars, menu style, etc.) but also FEEL of applications. For now I think it would be a big step forward if GNUstep wouldn't conflict with other desktops. If the dock-like miniwindows can be turned off, please do so by default in a Gnome or KDE environment. For the window containing the menu, respect the bars on top and on bottom of the screen. If the current desktop has scroll bars on the right, put them there in GNUstep apps as well. Does GNUstep applications should look & feel as Qt and GTK+ apps? There's no need to give up on the traditional behaviour for those prefering it. Using GNUstep applications in, for example, GNOME is stupid. Ouch. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero wrote: >> Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. >>> >>> Completely agree. Good coding conventions are picked because they >>> make things that are wrong look wrong or generate compiler errors / >>> warnings. The GNU coding conventions were picked by selecting at >>> random various bits from all existing coding conventions in the hope >>> that that would make everyone happy. They are a horrible mash of >>> things. The indenting style is horrible, for example, and only works >>> if you have your editor set up in exactly the same way as RMS; >>> mixing tabs and spaces for indenting is one of the most stupid ideas >>> I've ever seen. The convention of putting a space after function >>> names and before the open bracket makes code harder to read because >>> it makes it difficult to tell without reading the context that >>> something is an argument list rather than a subexpression. In fact, >>> almost everything about the GNU coding conventions looks painfully >>> stupid to anyone with a basic understanding of how the human visual >>> system works, but as an official GNU project we are stuck with it. >> >> I didn't know you have to stick to the GNU coding guidelines if you are >> an official GNU project. Now I understand all the people complaining >> about gcc being unreadable... > > Just to clarify for the non-developers, GCC being unreadable is a completely > different problem, > not particularly due to the coding style. ;-) > > Having a standard coding style for the whole GNUstep project is really > important as it makes > it easier to copy/move code from one part of the project to the other. > Using a "standard" coding > style that is documented and used by many other projects is also good as > contributors will > be immediately familiar with it. > > The GNU coding standards are used by a large number of projects with a lot > of contributors > and popularity so can't really be blamed if GNUstep is less popular than, > say, GIMP (which also > happens to follow the GNU coding standards) or any of the other million > projects that use the > GNU coding standards or some variants of them. > > While I sympathize with David who prefers (or is used) to some other coding > style, > the GNUstep project needs a consistent coding style and the GNU coding > standard > are as good a choice as any. Since GNUstep is a GNU project, it's a natural > choice. > > By the way the GNU coding standards are not bad, in fact I personally like > them (mostly because > my eyesight is really bad and whitespace is much more effective at > separating tokens than > brackets or commas). There are some details I'd change, but they certainly > are not an unusual > or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... > If it's a burning issue for many developers, I guess changing the coding > style to something else > could be discussed. There would be *lots* of reformatting to do if we ever > reach an agreement > on some other coding style. ;-) consider me on fire then, the reformatting is no issue for me, since I generally reformat the code i'm looking at anyways then I fix whatever i'm doing, and to send a patch to GNUstep do a clean checkout then uglify my code to fit the GNUstep style... I did a quick google code search on some random method and counted up how the arguments were formatted 92: with space between colon and argument 265: without space between colon and argument not really a scientific study of developer preference... (considering some of my code showed up in the with-space list which i can't stand), there is also bound to be duplicates of code between different versions of the same software... so if you're going to insist on one true whitespace, don't insist on one only a minority of developers use, or people are bound to complain, and call the gnustep code ugly. so just in case i haven't made my stance on the subject clear, I'd have to Ditto what icicle and David are saying. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey, As a new user I ahve to say I have been trying to use GNUstep for a while but two weeks ago I found the time to compile and install everything. So for a new user is not easy to get GNUstep, there are tw problems: - Distributions don't have a good support, I am usign fedora and I have to built everything from scratch no packages at all. Richard Stonehouse provides them. I used to provide source-RPMs which are easy to build and install. Right now we both lost a bit touch with the effort, but are as you read this trying to regain lost time. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Le 9 oct. 2009 à 20:48, Matt Rice a écrit : On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero wrote: By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... Well it's possible to argue in the opposite way :-) The first version is more readable than the second, because it's very easy to spot each 'colon + white space' combination. Then you know the left part is a method keyword and the right part is the argument. In the second case, 'colons' without white space seems slower to find because they are lost in the middle of other characters. The first version is also closer to the spirit of Smalltalk, in the sense the punctuation related spacing is similar to a real sentence. imo Smalltalk code with this spacing style is clearer than Smalltalk code without a space between each method keyword and argument pair. This point is less important in Objective-C given the whole language syntax is far less clean (C syntax + brackets everywhere). But it still matters a bit I think. I agree I'm getting really subjective here :-) Cheers, Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 9, 2009 at 12:51 PM, Quentin Mathé wrote: > Le 9 oct. 2009 à 20:48, Matt Rice a écrit : > >> On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero >> wrote: >>> By the way the GNU coding standards are not bad, in fact I personally >>> like >>> them (mostly because >>> my eyesight is really bad and whitespace is much more effective at >>> separating tokens than >>> brackets or commas). There are some details I'd change, but they >>> certainly >>> are not an unusual >>> or weird choice for a large free software project. >> >> To me it is about separating groups of tokens, e.g. if you are going >> to separate like this >> >> [thing foo: arg1 bar: arg2]; >> >> and insist on including that space between the 'foo:arg1' group, >> the whole message send looks androgynous with parts of the selectors >> mixed in with their arguments... >> >> compared with >> [thing foo:arg1 bar:arg2]; >> >> it is very easy for me to pick out which args go with which parts of >> the selector, and >> which message is being sent... > > Well it's possible to argue in the opposite way :-) > The first version is more readable than the second, because it's very easy > to spot each 'colon + white space' combination. > Then you know the left part is a method keyword and the right part is the > argument. > In the second case, 'colons' without white space seems slower to find > because they are lost in the middle of other characters. > > The first version is also closer to the spirit of Smalltalk, in the sense > the punctuation related spacing is similar to a real sentence. > imo Smalltalk code with this spacing style is clearer than Smalltalk code > without a space between each method keyword and argument pair. > This point is less important in Objective-C given the whole language syntax > is far less clean (C syntax + brackets everywhere). But it still matters a > bit I think. I agree I'm getting really subjective here :-) of course... each language is different in scheme (+(+ 1 2) 3) looks horrible compared to (+ (+ 1 2) 3) I'm assuming that RMS being a lisp programmer, this must be the reason why the GNU coding standards do it this way, but that doesn't make it right for objective-c. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Am 09.10.2009 um 20:23 schrieb David Chisnall: On 9 Oct 2009, at 19:19, Gregory Casamento wrote: Well, yeah... I do know about pbxbuild since I helped develop it. The point is that the majority of mac devs expect things to be done completely from the mac. My point was that this is something we could automate pretty trivially. I managed to get Darwine building (but not running) Windows versions of GNUstep apps, and it would be pretty simple to package up a virtual appliance that people could open with VirtualBox on their Mac and just point at an svn repository and get automated builds. Same with Darwine; we could package up a .wine directory containing GNUstep with this. Does this mean GNUstep cross-development can be done from within Xcode already or do you want to use Darwine to run ProjectCenter/Gorm for development? For the later, I fear this isn't exactly what developers mean with "completely on the Mac". An ability to run/debug GNUstep/Windows executables on the Mac would be a nice addition, though. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey,
I think you have many good points there. However, GNUstep is a wide
project and targets many different users.
Many things you want do not clash with other goals, they only divert
manpower. But keep in consideration that in an opensource project people
do whatever they deem interesting or useful, there isn't a central planning.
1. Maturity of GNUstep code for developers (functionality, docs,
stability)
2. GUI appearance
3. Portability
4. Applications
Gregory, behind all things you've mentioned I see a goal that can be
expressed by the
following phrase: "World (all stuff outside of GNUstep) acceptance of
GNUstep as alternative
developer framework that will help creating of alternative desktop
environment."
This statement is true, though, do you agree? The problem is that it is
reductive, but I think it is true. GNUstep is perhaps more.
Do you really think that improving website, theme (argh!) lead us to
rise of user attention
to GNUstep? I don't think so. I see a lot of people comparing GNUstep
with GNOME/KDE ("What's
I think so. We may argue about theming, but a good, informative and
usable website is really useful!
3. Stop trying to work everywhere. Let's make it working good at one
place, then go to another. Let's
speak frankly - we can't compete with Qt. Despite the existing of
DO, Objective-C and other great things.
I disagree here. Being portable is a big asset and we can do that!
5. Finish gnustep-gui as it is. Problem areas are: text subsystem,
fonts, graphics to name a few.
Agreed...
6. Create working destop environment for developers at least. Some day
I realized that I'm working
inside mess of not interacting things. My plan is:
- Create Login application
working on that, check GAP
- Create Preferences
what's wrong with SystemPreferences? Recently also GWorkspace's indexing
panel got fixed.
- Create Workspace Manager (Workspace + WindowMaker), excellent
integration of GNUstep with it (focus,
app management, dock interaction).
That's fine, but I'd put it lower priority. I care that we need to work
well with other windowmanagers too. The best I see medium term is to
enable/disable duplicate components and create a gnsutep-based
configuration tool
- Create Terminal application based on Alex Malmberg application.
it can be improved indeed. It works well, but I miss some features. ON
the todo list.
- Create Mail application (GNUmail can be used as starting point).
This is a sensible point. GNUmail is unmaintained sadly. Also in some
sense it is "too much" having features here and there, while it lacks
certain things i'd like.
- Finish ProjectCenter (anyway it's my responsibility).
Oh I hope that! I want to be able to maintain most projects in GAP with
PC. You knwo I am a long-time PC user. Before even you started
maintaining it...
7. Make it clean, fast and simple as NS/OS. Personally I'm tired of
bloated desktop environments (KDE/GNOME).
I want improved (at reasonable degree) OPENSTEP.
Totally agreed! Even Mac is not clean anymore. I'd like something along
mac 10.2/10.3 in terms of features, but with a more consistent, less
shiny interface, more NeXTstep...
It's not a plan targeting on world domination. It's plan to make
comfortable development environment as I see it.
And if it will be comfortable to me it can be useful to somebody else.
Sure, it needs to be somethign useful and clean. I don't want to aim at
GNOME or KDE; but something along the line of Xfce.
Summarizing this long email: we should focus on achievable goals by
narrowing down portability and loosing
competition with MacOS for now. Let's agree on strong, clean, simple
vision of project future and users will
come.
Agreed. We need both users and developers.
But I can also tell you that most development in the past 2 years was
good. GNUstep improved (much more than it broke). But a bit "too little"
unfortunately in some areas and thus they are unfinished...
Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey, Gregory Casamento wrote: Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. Strongly preferring WindowMaker is plain counter productive. I believe we need to start integrating better with other desktops/window managers. Maybe, But from my point of view we need to integrate better with Windowmaker itself! If I have focus problems, windows ordering problems, event problems, window and menu placement problems with WIndowMaker, then it is really crap!! Insisting on a own clipboard system will do nothing but confuse users. The unfortunate truth here is that there are still some features of the other guys pasteboard servers which don't server our needs at all. TO each one its ow. We can have ours :) Those dock-like miniwindows are simply annoying (for Gnome users). You can turn them off. Well, SystemPreferences has a convenient panel for defaults. If only people would install and use it... I don't know Ubuntu, but debian doesn't ship it. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Riccardo.
2009/10/9 Riccardo Mottola
> Hey,
>
> I think you have many good points there. However, GNUstep is a wide project
> and targets many different users.
> Many things you want do not clash with other goals, they only divert
> manpower. But keep in consideration that in an opensource project people do
> whatever they deem interesting or useful, there isn't a central planning.
Sure, you're right! I'm start thinking that fork of gui+back for some period
of time is not such silly thing...
>
>
>> 1. Maturity of GNUstep code for developers (functionality, docs,
>> stability)
>> 2. GUI appearance
>> 3. Portability
>> 4. Applications
>>
>> Gregory, behind all things you've mentioned I see a goal that can be
>> expressed by the
>> following phrase: "World (all stuff outside of GNUstep) acceptance of
>> GNUstep as alternative
>> developer framework that will help creating of alternative desktop
>> environment."
>>
>> This statement is true, though, do you agree? The problem is that it is
> reductive, but I think it is true. GNUstep is perhaps more.
Sure, I agree! Considering the statement above making 'modern' themes,
integrating apps into foreign DE is not the first thing we should focus on.
>
> Do you really think that improving website, theme (argh!) lead us to rise
>> of user attention
>> to GNUstep? I don't think so. I see a lot of people comparing GNUstep with
>> GNOME/KDE ("What's
>>
> I think so. We may argue about theming, but a good, informative and usable
> website is really useful!
>
>> 3. Stop trying to work everywhere. Let's make it working good at one
>> place, then go to another. Let's
>> speak frankly - we can't compete with Qt. Despite the existing of DO,
>> Objective-C and other great things.
>>
> I disagree here. Being portable is a big asset and we can do that!
Sure it's great asset for mature project. The problem is in spreading the
efforts of developers, code becomes hard to read... and code is not become
more mature then before.
>
> 5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts,
>> graphics to name a few.
>>
> Agreed...
>
>> 6. Create working destop environment for developers at least. Some day I
>> realized that I'm working
>> inside mess of not interacting things. My plan is:
>> - Create Login application
>>
> working on that, check GAP
>
>> - Create Preferences
>>
> what's wrong with SystemPreferences? Recently also GWorkspace's indexing
> panel got fixed.
Probably I just don't like it... But it's personal, never mind.
> - Create Workspace Manager (Workspace + WindowMaker), excellent
> integration of GNUstep with it (focus,
> app management, dock interaction).
> That's fine, but I'd put it lower priority. I care that we need to work
> well with other windowmanagers too. The best I see medium term is to
> enable/disable duplicate components and create a gnsutep-based configuration
> tool
Don't get me wrong but I don't care about support of other window managers
until Window Maker support is weak.
> - Create Terminal application based on Alex Malmberg application.
> it can be improved indeed. It works well, but I miss some features. ON the
> todo list.
>
>> - Create Mail application (GNUmail can be used as starting point).
>>
> This is a sensible point. GNUmail is unmaintained sadly. Also in some sense
> it is "too much" having features here and there, while it lacks certain
> things i'd like.
>
>> - Finish ProjectCenter (anyway it's my responsibility).
>>
> Oh I hope that! I want to be able to maintain most projects in GAP with PC.
> You knwo I am a long-time PC user. Before even you started maintaining it...
>
>> 7. Make it clean, fast and simple as NS/OS. Personally I'm tired of
>> bloated desktop environments (KDE/GNOME).
>> I want improved (at reasonable degree) OPENSTEP.
>>
> Totally agreed! Even Mac is not clean anymore. I'd like something along
> mac 10.2/10.3 in terms of features, but with a more consistent, less shiny
> interface, more NeXTstep...
>
I can understand people who want new modern look. But then we need designers
for that. Look at the Project Center icons - they're just ugly! Keith Ohlfs
is a professional designer and I'm afraid we can't create something like
that. So just let's use it!
>
>> It's not a plan targeting on world domination. It's plan to make
>> comfortable development environment as I see it.
>> And if it will be comfortable to me it can be useful to somebody else.
>>
>> Sure, it needs to be somethign useful and clean. I don't want to aim at
> GNOME or KDE; but something along the line of Xfce.
>
>> Summarizing this long email: we should focus on achievable goals by
>> narrowing down portability and loosing
>> competition with MacOS for now. Let's agree on strong, clean, simple
>> vision of project future and users will
>> come.
>>
>
> Agreed. We need both users and developers.
>
> But I can also tell you that most development in the past 2 years was good.
> GNUst
Re: Changes I've been thinking of...
I'm not a huge fan of the gnu coding standards. To me if the code is good and makes sense the formatting is secondary. On Friday, October 9, 2009, Matt Rice wrote: > On Fri, Oct 9, 2009 at 12:51 PM, Quentin Mathé wrote: >> Le 9 oct. 2009 à 20:48, Matt Rice a écrit : >> >>> On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero >>> wrote: > By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. >>> >>> To me it is about separating groups of tokens, e.g. if you are going >>> to separate like this >>> >>> [thing foo: arg1 bar: arg2]; >>> >>> and insist on including that space between the 'foo:arg1' group, >>> the whole message send looks androgynous with parts of the selectors >>> mixed in with their arguments... >>> >>> compared with >>> [thing foo:arg1 bar:arg2]; >>> >>> it is very easy for me to pick out which args go with which parts of >>> the selector, and >>> which message is being sent... >> >> Well it's possible to argue in the opposite way :-) >> The first version is more readable than the second, because it's very easy >> to spot each 'colon + white space' combination. >> Then you know the left part is a method keyword and the right part is the >> argument. >> In the second case, 'colons' without white space seems slower to find >> because they are lost in the middle of other characters. >> >> The first version is also closer to the spirit of Smalltalk, in the sense >> the punctuation related spacing is similar to a real sentence. >> imo Smalltalk code with this spacing style is clearer than Smalltalk code >> without a space between each method keyword and argument pair. >> This point is less important in Objective-C given the whole language syntax >> is far less clean (C syntax + brackets everywhere). But it still matters a >> bit I think. I agree I'm getting really subjective here :-) > > > of course... each language is different in scheme > (+(+ 1 2) 3) looks horrible compared to > (+ (+ 1 2) 3) > > I'm assuming that RMS being a lisp programmer, this must be the reason > why the GNU coding standards do it this way, but that doesn't make it > right for objective-c. > > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > http://lists.gnu.org/mailman/listinfo/gnustep-dev > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
David Chisnall schrieb: > IMP caching is a bit more complicated. The new runtime supports a means > of invalidating IMP caches, which means that the compiler will be able > to automatically insert (polymorphic) IMP caching and even speculatively > inline methods. Doing this well will require profiling (I have written > an LLVM pass that adds profiling information to the code, but not one > that uses this information to add the caching yet). To use this in the > text system, we'd want to add a set of automated test programs using a > null back end that would generate profiling information for how the text > system is typically used and then compile an optimised version. > > To be honest, I suspect that most of the places where the text system > currently does IMP caching are completely irrelevant. I've been playing > with implementing some of the algorithms from LaTeX in Objective-C > recently, and the overhead from message sends is largely irrelevant, > especially when you compare it to the overhead in drawing an antialiased > glyph (although, if you're lucky, the GPU will do most of that for you). > As far as I remember, the text system uses IMP caching at two places. In GSHorizontalTypesetter and in NSGlyphGenerator. These two are central parts of the layout system that need to be fast. But of course GNUstep has changed since the time these bits were written. Perhaps the three method calls that had been optimized into function calls don't make that much difference any more. At least at the time when the optimisation was done there were hard figures that suggested this to be worth while. Do you have any numbers that say so or is this just general ranting against premature optimisation? The later I support whole heartedly. > There are lots of places where GNUstep is guilty of premature > optimisation. Another example is that a lot of classes call > NSDeallocateObject(self) rather than [super dealloc], which has a > negligible performance impact but breaks any category that tries to > replace NSObject's dealloc method. I never understood why we do this. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... My personal preference is to do [thing foo: arg1 bar: arg2] (Note the double-space between the two parts of the selector). That way, I can easily visually tokenize it when I read it. Of course, it's my personal preference and it's as good as any. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 23:45, Fred Kiefer wrote: David Chisnall schrieb: Another example is that a lot of classes call NSDeallocateObject(self) rather than [super dealloc], which has a negligible performance impact but breaks any category that tries to replace NSObject's dealloc method. I never understood why we do this. A lot of what looks like premature optimisation nowadays was benchmarked or profiled and found to be worthwhile on slower CPUs ten years ago. I can't believe that more than a few dozen cases of this particular issue exist anymore in GNUstep (perhaps I'll try grepping and fixing). I definitely think it should go (I hated the fact that it was totally pervasive in Cocotron when I looked at their code). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 21:29, Markus Hitter wrote: Am 09.10.2009 um 20:23 schrieb David Chisnall: On 9 Oct 2009, at 19:19, Gregory Casamento wrote: Well, yeah... I do know about pbxbuild since I helped develop it. The point is that the majority of mac devs expect things to be done completely from the mac. My point was that this is something we could automate pretty trivially. I managed to get Darwine building (but not running) Windows versions of GNUstep apps, and it would be pretty simple to package up a virtual appliance that people could open with VirtualBox on their Mac and just point at an svn repository and get automated builds. Same with Darwine; we could package up a .wine directory containing GNUstep with this. Does this mean GNUstep cross-development can be done from within Xcode already or do you want to use Darwine to run ProjectCenter/ Gorm for development? For the later, I fear this isn't exactly what developers mean with "completely on the Mac". Currently, pbxbuild doesn't run under Darwine, so I had to generate the GNUmakefile by hand, but I did set up one project with an 'external build system' step in XCode that ssh'd to a VM and ran pbxbuild there. It's not how I'd want to work, but it does work for producing Linux / *BSD binaries. We could quite easily produce a VirtualBox appliance that had a small Linux / GNUstep install and a build script that can be used from XCode to rsync the project into the VM and then run pbxbuild on it. An ability to run/debug GNUstep/Windows executables on the Mac would be a nice addition, though. Unfortunately, for some reason, GNUstep/Windows apps didn't work at all in WINE for me. David -- Sent from my PDP-11 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 23:45, Fred Kiefer wrote: As far as I remember, the text system uses IMP caching at two places. In GSHorizontalTypesetter and in NSGlyphGenerator. These two are central parts of the layout system that need to be fast. But of course GNUstep has changed since the time these bits were written. Perhaps the three method calls that had been optimized into function calls don't make that much difference any more. At least at the time when the optimisation was done there were hard figures that suggested this to be worth while. Do you have any numbers that say so or is this just general ranting against premature optimisation? The later I support whole heartedly. Mainly it's a general rant; I haven't looked closely at the text system for a little while, but last time I tried I found it completely incomprehensible and most of the things that were causing that seemed to be microoptimisations on poor algorithms, which could have been offset by using better algorithms. David -- Sent from my Difference Engine ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
El 9 de octubre de 2009 21:39, Riccardo Mottola escribió: > Hey, > > As a new user I ahve to say I have been trying to use GNUstep for a while >> but two weeks ago I found the time to compile and install everything. >> So for a new user is not easy to get GNUstep, there are tw problems: >> - Distributions don't have a good support, I am usign fedora and I have to >> built everything from scratch no packages at all. >> >> >> > Richard Stonehouse provides them. > Would be worth to have any link in the website > > I used to provide source-RPMs which are easy to build and install. > > Right now we both lost a bit touch with the effort, but are as you read > this trying to regain lost time. > > Riccardo > > -- Un saludo Best Regards Pablo Giménez ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Sergii Stoian schrieb: > 2009/10/9 Riccardo Mottola >> Many things you want do not clash with other goals, they only divert >> manpower. But keep in consideration that in an opensource project people do >> whatever they deem interesting or useful, there isn't a central planning. > > Sure, you're right! I'm start thinking that fork of gui+back for some period > of time is not such silly thing... A fork of an open source project is almost always a bad thing. Especially in the case where you haven't tries to get your ideas into the main project first. I think that I will be glad to integrate most of the things that you come up with into gui and back. So why talk about a fork first? Sometimes it is worthwhile to test a few ideas on a branch before integrating them into the trunk of a project, but that is a completely different approach. You made great contributions to GNUstep, it would be hard to loose you to a fork. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 9, 2009 at 5:33 PM, Sergii Stoian wrote: > Sure, you're right! I'm start thinking that fork of gui+back for some period > of time is not such silly thing... Forking would be bad for the project in general. In my opinion a fork would only cause confusion. If what you're referring to here is a branch within the GNUstep repo, then that's fine... but I fork of the project isn't really going to be productive. Also, I'm wondering what the reason for the fork would be. GC -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Fred Kiefer wrote: Sergii Stoian schrieb: 2009/10/9 Riccardo Mottola Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... A fork of an open source project is almost always a bad thing. Especially in the case where you haven't tries to get your ideas into the main project first. I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. I think that I will be glad to integrate most of the things that you come up with into gui and back. So why talk about a fork first? Sometimes it is worthwhile to test a few ideas on a branch before integrating them into the trunk of a project, but that is a completely different approach. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); - move general code 'back' to 'gui' (gsc if I remember correctly); - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. You made great contributions to GNUstep, it would be hard to loose you to a fork. Thank you for good words. But please try to understand me: it's sad to see how people talks about changing appearance of GNUstep while must work functionality is far from 'Right Thing' even with current look. -- Sergii Stoian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Gregory Casamento wrote: On Fri, Oct 9, 2009 at 5:33 PM, Sergii Stoian wrote: Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... Forking would be bad for the project in general. In my opinion a fork would only cause confusion. If what you're referring to here is a branch within the GNUstep repo, then that's fine... but I fork of the project isn't really going to be productive. Sure, this time it's better to say as branch not fork. Also, I'm wondering what the reason for the fork would be. See my mail to Fred. GC -- Sergii Stoian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 12 Oct 2009, at 10:50, Sergii Stoian wrote: Fred Kiefer wrote: Sergii Stoian schrieb: 2009/10/9 Riccardo Mottola Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... A fork of an open source project is almost always a bad thing. Especially in the case where you haven't tries to get your ideas into the main project first. I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. I understand the frustration with having to deal with breakage like that, but I'm going to ask you to think about it a bit more before deciding to branch. Where I work we had the problem with changes to the gnustep code breaking our production code, so we took a stable snapshot and worked with that for a long time. This was all OK until we wanted to use some new features, so we updated to using a more recent version, and used that version on our test system from some weeks before making a release and rolling out to live systems. But then on the live systems our customers managed to find/trigger bugs which had been missed on our test system ... so I'm now thinking that it's probably actually a lot safer to update the test/development systems as frequently as possible so that we maximise the amount of time during which any bugs can be discovered and fixed. My current feeling is that it makes sense to branch, and work with the branch to make big changes, but the aim should be to merge that branch back into trunk as quickly as possible (and I mean within days or at most a couple of weeks, not several weeks or months). That way, your branch doesn't end up depending on behaviors which have changed (usually been fixed) in trunk, and you don't get to a state where it's a horrible job to merge again. I think that I will be glad to integrate most of the things that you come up with into gui and back. So why talk about a fork first? Sometimes it is worthwhile to test a few ideas on a branch before integrating them into the trunk of a project, but that is a completely different approach. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); Sounds good. - move general code 'back' to 'gui' (gsc if I remember correctly); Or perhaps into a library that the backends can link with if they need it? - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). That's really great X and window manager interaction are the biggest technical problem areas I see in GNUstep. These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. You made great contributions to GNUstep, it would be hard to loose you to a fork. Thank you for good words. But please try to understand me: it's sad to see how people talks about changing appearance of GNUstep while must work functionality is far from 'Right Thing' even with current look. I don't think you need to worry about that ... frankly, whatever people say about appearance is largely irrelevant since it doesn't really effect the coding you do. The only impact is that we want to design/implement things so that theming is possible, but as far as the backend code goes, that really just means following good design principles of making code modular, clean, and simple .. and that's clearly what you want to do anyway. Certainly nobody is going to try to force you to work on changing the appearance of the GUI when you want to work on improving the backend. I, for one, am very glad to know that you want to work on the backend code as I think the lack of polish in the X interaction (focus, fonts, clipping, cut and paste, drag and drop, menu handling, etc) is the main technical issue making GNUstep apps look bad in comparison with Gnome apps for instance. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Richard Frith-Macdonald wrote: On 12 Oct 2009, at 10:50, Sergii Stoian wrote: Fred Kiefer wrote: Sergii Stoian schrieb: 2009/10/9 Riccardo Mottola Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... A fork of an open source project is almost always a bad thing. Especially in the case where you haven't tries to get your ideas into the main project first. I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. I understand the frustration with having to deal with breakage like that, but I'm going to ask you to think about it a bit more before deciding to branch. Where I work we had the problem with changes to the gnustep code breaking our production code, so we took a stable snapshot and worked with that for a long time. This was all OK until we wanted to use some new features, so we updated to using a more recent version, and used that version on our test system from some weeks before making a release and rolling out to live systems. But then on the live systems our customers managed to find/trigger bugs which had been missed on our test system ... so I'm now thinking that it's probably actually a lot safer to update the test/development systems as frequently as possible so that we maximise the amount of time during which any bugs can be discovered and fixed. My current feeling is that it makes sense to branch, and work with the branch to make big changes, but the aim should be to merge that branch back into trunk as quickly as possible (and I mean within days or at most a couple of weeks, not several weeks or months). That way, your branch doesn't end up depending on behaviors which have changed (usually been fixed) in trunk, and you don't get to a state where it's a horrible job to merge again. I think that I will be glad to integrate most of the things that you come up with into gui and back. So why talk about a fork first? Sometimes it is worthwhile to test a few ideas on a branch before integrating them into the trunk of a project, but that is a completely different approach. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); Sounds good. - move general code 'back' to 'gui' (gsc if I remember correctly); Or perhaps into a library that the backends can link with if they need it? Backends already linked against gui library, why we need another? Do you mean separating all GS* classes (from back and gui) into separate library? If so it may have sense to separate AppKit code from GNUstep specific one. - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). That's really great X and window manager interaction are the biggest technical problem areas I see in GNUstep. ...and no documentation for how it works. These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. You made great contributions to GNUstep, it would be hard to loose you to a fork. Thank you for good words. But please try to understand me: it's sad to see how people talks about changing appearance of GNUstep while must work functionality is far from 'Right Thing' even with current look. I don't think you need to worry about that ... frankly, whatever people say about appearance is largely irrelevant since it doesn't really effect the coding you do. The only impact is that we want to design/implement things so that theming is possible, but as far as the backend code goes, that really just means following good design principles of making code modular, clean, and simple .. and that's clearly what you want to do anyway. Certainly nobody is going to try to force you to work on changing the appearance of the GUI when you want to work on improving the backend. I, for one, am very glad to know that you want to work on the backend code as I think the lack of polish in the X interaction (focus, fonts, clipping, cut and paste, drag and drop, menu handling, etc) is the main te
Re: Changes I've been thinking of...
Hey, I mean for for "some period of time". I gives me some freedom to brake things without bothering people. One of the reason that drove me to idea of forking gui+back is when I'm developing Project Center I need to fix some things after GNUstep svn update. I need some stable basement for PC development. I tired fix things that was not broken before. To achieve what you want, ou can jsut install the latest release instead of tracking SVN trunk for svn. Since I have several computers, I arrange to have one with stable release and one with the latest stuff. Actually some of the ideas are: - remove old/unused code from 'back' (xdps, xlib); xlib is far from unused, so leave it in. xdps can indeed be removed, since the X11 extension never worked... I read that it was removed, but it is still there. But inany case Fred should look at that and do things correctly not to break anything. - move general code 'back' to 'gui' (gsc if I remember correctly); Discuss that with Fred, which is the maintainer. - finish font, image, drawing, events in GUI and ART backend (blurred lines, text positioning, focus issues with WindowMaker, start of first app in session, handling of X server events, text selection etc.). I give you 100% reason here. Things should work well and reliable on WindowMaker, so that you have a reference implementation. These are the basic things that MUST work correctly. Until then developing applications for GNUstep is a pain in back (fix things that was not broken before). I intentionally focus on UNIX, X11 and ART backend. I want at least one combination of components to work best of all (reference platform). I understand that other people has different tastes but spreading efforts never lead us to success. Understandable. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
A fork is pointless. All of the points you made are things that would be welcome changes in GNUstep. On Mon, Oct 12, 2009 at 5:52 AM, Sergii Stoian wrote: > Gregory Casamento wrote: >> >> On Fri, Oct 9, 2009 at 5:33 PM, Sergii Stoian wrote: >> >>> >>> Sure, you're right! I'm start thinking that fork of gui+back for some >>> period >>> of time is not such silly thing... >> >> Forking would be bad for the project in general. In my opinion a fork >> would only cause confusion. If what you're referring to here is a >> branch within the GNUstep repo, then that's fine... but I fork of the >> project isn't really going to be productive. > > Sure, this time it's better to say as branch not fork. > >> Also, I'm wondering what the reason for the fork would be. > > See my mail to Fred. > >> GC > > -- > Sergii Stoian > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 12 Oct 2009, at 23:21, Riccardo Mottola wrote: Hi, Germán Arias wrote: El lun, 12-10-2009 a las 19:33 +0200, Michael Thaler escribió: But so far my experiences weren't that great. I tried to create a project with project center. No icons are shown at all, so Project Center is not useable. Well with stable release (startup 0.23.0) ProjectCenter and Gorm are usable. I have many projects made with these. But you are using GNUstep from SVN, and of course there are bugs. They do work also from svn trunk I'm using them right now. NSX11HandleWindowDecoration = YES. But today I tested this with 0.23.0 startup, and does not work. Maybe it's a bug or my memory fails. it is GS* If you run systempreferences, you will find both the preference for letting X11 or GNUstep handle the windowmaker (the cited one) and also GSSuppressAppIcon which inhibits the cretion of the small application icons. You need then another tracker, on windows the taskbar works fine, the same goes for mwm. IN the long term you might want to extend GSUseWMTaskBar for your windowmanager perhaps? GNUstep has quite a lot of defaults for adjusting behavior (and we are not averse to adding more to control interaction with other non- gnustep software) such as how manus are drawn and whether app icons are shown. It seems to me that a lot of issues people have are with the fact that there are no native packages with themes/defaults set up to integrate GNUstep with the native look. Perhaps people who like a a particular look could record what they found out about how to achieve it so that people can see and download it from the website or wiki. You could have a screenshot (so people can see what it looks like), and a file containing the defaults settings to reproduce the appearance (and a theme bundle for the more ambitious works). People could then download the file and/or bundle, and could install for themselves. Really, it would be nice if people who like a particular look could provide that look for other people to enjoy. Going back to Greg's idea of improving the website ... it would be good to provide a repository for people to provide this sort of thing for view and download. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Terminal Services (was: Rec: Changes I've been thinking of...)
Philippe Roussel wrote: On Thu, Oct 08, 2009 at 02:08:35AM +0200, Riccardo Mottola wrote: There are multiple terminal applications (gap, backbone, etoile ?) but none really usable (to my knowledge, maybe I missed something). These are harsh words? I don't know of etoile, but the one in GAP works. I use it every single day! It may miss some features but works. ANd I assume backbone's does too, the code bae is essentially the same, but the philosophies about releases, makefiles etc. differ. Ok, I went too far, Terminal works. But I doesn't answer to 'Terminal/Open shell here' service needed by GWorkspace for example. The services do work. However, you first must change one of the services in Terminal's preferences or add a new one before Terminal will save the necessary file to $GNUSTEP_USER_HOME/Library/Services. It took me a while until I found that out. Probably I should file a bug report, but it is not clear to me whether to file this bug report at Backbone or at GAP (plus I'm a bit too busy at the moment ...) Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Terminal Services (was: Rec: Changes I've been thinking of...)
On Thu, Oct 08, 2009 at 02:10:31PM +0200, Wolfgang Lux wrote: > The services do work. However, you first must change one of the services > in Terminal's preferences or add a new one before Terminal will save the > necessary file to $GNUSTEP_USER_HOME/Library/Services. It took me a > while > until I found that out. > > Probably I should file a bug report, but it is not clear to me whether to > file this bug report at Backbone or at GAP (plus I'm a bit too busy at > the > moment ...) Thanks Wolfgang, it did the trick ! This makes Terminal a lot more useful for me. Philippe -- The box said Windows XP or better, so I installed Linux ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
