Re: So, honestly, is GNUStep a viable development option?
On Nov 15, 6:58 pm, Nat! [EMAIL PROTECTED] wrote: Am 15.11.2007 um 17:44 schrieb Gregory John Casamento: Cool. I think this is an excellent idea. -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Jesse Ross [EMAIL PROTECTED] To: GNUstep Discuss [EMAIL PROTECTED] Sent: Thursday, November 15, 2007 11:26:51 AM Subject: Re: So, honestly, is GNUStep a viable development option? Does anyone have any suggestions of a good place to create a forum? (i.e which website?) I was thinking we would just run our own, and have it live within the new site structure, hence my request for a good PHP-drivenforum package. J. Since I am probably the one developer Helge mentionend, who uses forums, I think I can somewhat usefully recommend phpBB3 (RC7 currently). If you run aforum, you need to have a maintainer at least. Forums also get a lot of spam. They also need constant surveillance for vulnerabilities. Don't install it on a machine that mustn't ever get owned :) Active forums need active moderation. It's not setup and forget. But it's worth it IMO. Ciao Nat! -- I suppose I live in a fantasy world, but at least they know me there. -- DLR Hi, I am also a forum guy/developer for nearly 10 years. But since I get into this development things for last 2-3 years I have to use also mailing lists :) And I can say that a well prepared forum is very very handy compared to mailing lists. I might suggest to code your own forum if you have coders to do that and have also plenty time. It is the best option. If you can code your own forum then you can maybe get together all the necessary features for mailing list guys and forum guys together, for example. Maybe a hybrid of mailing list and a forum :) Also if you code it for yourself then you can adapt it more easily to your web site, both in point of view of design and substructure. But usually teams don't have time for that that's why they use pre- coded forums. If it will be the case then I might suggest using a different, not well-known but well coded forum script so that the forum is a little bit different then other forums out there. There are some forums like that called UseBB or PunBB. Also I suggest not to use over-featured forums for beginning (for example like vBulletin). A plain and chick forum would be better for such a system. I would suggest the forum I coded if it was not coded in ASP language :D ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
I think everybody on this mailing list knows that there are GNUstep users that do not really care about that. However there are people who care on the list, and the outside world cares about it too. Our architecture makes it difficult to implement this. Each widget in GNUstep draws itself using a set of postscript like functions. It is also possible for subclasses to alter how the widgets are drawn. There are a number of apps on Mac OS X and on GNUstep which make use of this capability. So, it's not about us not caring it's about: how do we use native widgets without sacrificing functionality? I know about this. I program with OpenStep everyday. and done this thousands of time. If you read my previous posts, I'm not advocating the use of native widgets, I think there should be theme that closely look like the platform it runs on. Essentially, on Windows it should look like it. If you can come up with a productive method of using native widgets where we don't lose the functionality, then I would be more than happy to hear about it, but pontificating that we should without offering a concrete solution is fairly pointless. You're right, and therefore I am investigating. The problem is, I opened a Visual C++ book years ago and thought Oh my god, WinApi is not for you and decided to keep it closed and dusty till I die. So I really don't know at all. However, I did GTK+ a little. After all, the only UI kit I know is AppKit... Personally I don't think we should use native widgets, but only look like them. This should be easier. Maybe it could be possible to automatically generate a theme that matches the environment. (for example by creating native widgets and drawing them into images that are then used to draw the controls). Actually, I started a themer for GNUstep ~4 years ago that was to use GTK+ themes (I was using gnome a lot) but never got time to finish it and it has been deleted when I got rid of the pc. I'd prefer create a NIB for X11, Windows and Mac OS X so that it looks good on these platform than not being able to look good on anyone. People discarding GNUstep for wxWidgets, GTK+, Qt are ready to code more for their interface, so they wouldn't be afraid if they needed to redo a NIB file. Actually, this is the same with localization, you have to duplicate NIBs and maintain them, but reaching more users is at stake. These are all good points. The issues are what I pointed out above. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
I agree. We should try to come up with themes which are close to the host operating system/window manager. -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Renaud Molla [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED]; discuss-gnustep@gnu.org Sent: Friday, November 16, 2007 9:34:30 AM Subject: Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?) I think everybody on this mailing list knows that there are GNUstep users that do not really care about that. However there are people who care on the list, and the outside world cares about it too. Our architecture makes it difficult to implement this. Each widget in GNUstep draws itself using a set of postscript like functions. It is also possible for subclasses to alter how the widgets are drawn. There are a number of apps on Mac OS X and on GNUstep which make use of this capability. So, it's not about us not caring it's about: how do we use native widgets without sacrificing functionality? I know about this. I program with OpenStep everyday. and done this thousands of time. If you read my previous posts, I'm not advocating the use of native widgets, I think there should be theme that closely look like the platform it runs on. Essentially, on Windows it should look like it. If you can come up with a productive method of using native widgets where we don't lose the functionality, then I would be more than happy to hear about it, but pontificating that we should without offering a concrete solution is fairly pointless. You're right, and therefore I am investigating. The problem is, I opened a Visual C++ book years ago and thought Oh my god, WinApi is not for you and decided to keep it closed and dusty till I die. So I really don't know at all. However, I did GTK+ a little. After all, the only UI kit I know is AppKit... Personally I don't think we should use native widgets, but only look like them. This should be easier. Maybe it could be possible to automatically generate a theme that matches the environment. (for example by creating native widgets and drawing them into images that are then used to draw the controls). Actually, I started a themer for GNUstep ~4 years ago that was to use GTK+ themes (I was using gnome a lot) but never got time to finish it and it has been deleted when I got rid of the pc. I'd prefer create a NIB for X11, Windows and Mac OS X so that it looks good on these platform than not being able to look good on anyone. People discarding GNUstep for wxWidgets, GTK+, Qt are ready to code more for their interface, so they wouldn't be afraid if they needed to redo a NIB file. Actually, this is the same with localization, you have to duplicate NIBs and maintain them, but reaching more users is at stake. These are all good points. The issues are what I pointed out above. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
I think everybody on this mailing list knows that there are GNUstep users that do not really care about that. However there are people who care on the list, and the outside world cares about it too. Our architecture makes it difficult to implement this. Each widget in GNUstep draws itself using a set of postscript like functions. It is also possible for subclasses to alter how the widgets are drawn. There are a number of apps on Mac OS X and on GNUstep which make use of this capability. So, it's not about us not caring it's about: how do we use native widgets without sacrificing functionality? If you can come up with a productive method of using native widgets where we don't lose the functionality, then I would be more than happy to hear about it, but pontificating that we should without offering a concrete solution is fairly pointless. I'd prefer create a NIB for X11, Windows and Mac OS X so that it looks good on these platform than not being able to look good on anyone. People discarding GNUstep for wxWidgets, GTK+, Qt are ready to code more for their interface, so they wouldn't be afraid if they needed to redo a NIB file. Actually, this is the same with localization, you have to duplicate NIBs and maintain them, but reaching more users is at stake. These are all good points. The issues are what I pointed out above. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Renaud Molla [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Friday, November 16, 2007 1:57:53 AM Subject: Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?) (...) I personally have no problem with non-native look of an application in an environment as long as the application itself is cool and powerful. I think everybody on this mailing list knows that there are GNUstep users that do not really care about that. However there are people who care on the list, and the outside world cares about it too. I'm afraid that changing widgets would require additional porting effort when switching to another platform. I'd prefer create a NIB for X11, Windows and Mac OS X so that it looks good on these platform than not being able to look good on anyone. People discarding GNUstep for wxWidgets, GTK+, Qt are ready to code more for their interface, so they wouldn't be afraid if they needed to redo a NIB file. Actually, this is the same with localization, you have to duplicate NIBs and maintain them, but reaching more users is at stake. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
Nicolas Roard wrote: On Nov 13, 2007 2:16 PM, Mark Grice [EMAIL PROTECTED] wrote: But dialog boxes are a prime example of what would be better if it were native. For example: Ubuntu has Samba, which allows me to get to the windows drives on my network. It also allows me to view thumbnails of the graphic images. Their file dialog box supports these out of the box... As a developer, it would be nice if my file chooser automatically gave these kinds of options to my end users. I am assuming that the native GNUStep does not, because when I run the examples, I can neither see thumbnails of images, nor can I access my SMB files... But that may be ignorance on my part... Yes, file chooser should use the native one. I don't agree here. Using native file chooser or other common dialog panels will be break the look and feel of a GNUstep application. OK, you may not like this look and feel, but at least within an application it should be consistent. Using native dialog panels would also inhibit the accessory view mechanism, not that we are doing that great with it currently. It would be fairly easy to add native dialog panels on windows, but how would you do it on Unix systems? We have different ones for KDE and Gnome, other environments don't even provide a shared one. What kind of consistency would we gain by using a KDE (or QT) file chooser in a Gnome environment? What we could try to do is move the gui code for these dialog panels into NIB files (or Gorm files if you are a bit old fashioned :-) and thereby offer the opportunity to replace them with layouts more suited for the current environment. Anybody interested in taking this task? It will be a great chance to learn more about Gorm. Fred ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
Hi Fred, On Nov 15, 2007 9:00 AM, Fred Kiefer [EMAIL PROTECTED] wrote: Nicolas Roard wrote: On Nov 13, 2007 2:16 PM, Mark Grice [EMAIL PROTECTED] wrote: But dialog boxes are a prime example of what would be better if it were native. For example: Ubuntu has Samba, which allows me to get to the windows drives on my network. It also allows me to view thumbnails of the graphic images. Their file dialog box supports these out of the box... As a developer, it would be nice if my file chooser automatically gave these kinds of options to my end users. I am assuming that the native GNUStep does not, because when I run the examples, I can neither see thumbnails of images, nor can I access my SMB files... But that may be ignorance on my part... Yes, file chooser should use the native one. I don't agree here. Using native file chooser or other common dialog panels will be break the look and feel of a GNUstep application. OK, you may not like this look and feel, but at least within an application it should be consistent. In that particular case, you'd break the feel, not the look -- the rest of the UI would supposedly use theming to match the host platform. Using native dialog panels would also inhibit the accessory view mechanism, not that we are doing that great with it currently. Yes, we'd break the accessory views. But as you said, it's not really used by applications, and I think in the case of file dialogs it probably is better to keep the consistency with other applications on the system than to keep consistency within the app itself. It could evidently and easily be a choice as well -- you could choose to distribute your app using native dialogs or not. It would be fairly easy to add native dialog panels on windows, but how would you do it on Unix systems? We have different ones for KDE and Gnome, other environments don't even provide a shared one. What kind of consistency would we gain by using a KDE (or QT) file chooser in a Gnome environment? Obviously my main target here would be GNUstep on Windows, where such integration would really be great for GNUstep (and frankly I think would help tremendously attracting developers). GNUstep integration on linux is much less important I think, but I do believe that some people would like to have their GNUstep app integrated as much as possible within their KDE environment or their Gnome environment (imagine a company standardising on ubuntu, with some custom apps done in gnustep -- it would obviously make sense for them to have the gnustep apps looking/feeling as much as possible the same as a gnome app). I'm not saying we should _only_ use native file dialogs -- because then we'd have the problem of deciding what's a native dialog on platforms that use more than one toolkit -- as you say, a KDE file chooser in GNOME would be pointless. What I'm simply advocating is having the choice to use native dialogs rather than the GNUstep ones :) Eg, load a bundle that will provide native dialogs facilities, a bundle implementing Win32 dialogs, or KDE dialogs, or GNOME dialog, etc. We don't lose anything, just become a tiny bit more flexible and useful for users/developers that don't want a full GNUstep environment but want to use a GNUstep app along native apps. Now, although I guess it could be doable to simply write a bundle that replace with categories or poseAs the existing classes, there's possibly a couple of things we can do to the actual code to simplify things -- I don't know, the best test would be to try adding a native dialog and see what are the problems :) What we could try to do is move the gui code for these dialog panels into NIB files (or Gorm files if you are a bit old fashioned :-) and thereby offer the opportunity to replace them with layouts more suited for the current environment. Anybody interested in taking this task? It will be a great chance to learn more about Gorm. Well... that certainly would be good anyway for gnustep (I actually had the impression the dialogs we had were already put in nibs at some point ?), but it would only partially answer the problem -- eg you'd have maybe a look closer to the native dialogs, but without the feel ! and I think it's the actual worst solution we can do, because if you have a dialog that /looks/ like a native dialogs but doesn't behave like one, it's going to be _really_ annoying. For instance, some (native) file dialogs provides you with: - favorites - network access - previews - etc. Are we going to implement all that in subtly different ways each time ? and how do you get access to the favorites ? etc. Basically at this point I think it would be better to use directly the native file dialog. -- Nicolas Roard La perfection, ce n'est pas quand il n'y a plus rien à ajouter, c'est quand il n'y a plus rien à enlever. -- Antoine de St-Exupéry ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
Please excuse the interference, but I really do not understand why you waste time and effort on this discussion. It reminds me somewhat of the wheel inventing committee in the Hitchhiker's trilogy (which is stuck in the discussion about the colour before having made any step forward). IMHO widgets mean lots of work without any gain. And why start a debate about redesigning a software system between version 0.13 and 1.0? That is a topic for between 0.1 and 0.2 or maybe between 3.x and 4.0. No offense meant, I am just bewildered you are so open to the idea of knocking the whole design and all your work on the head. Bye, Ingolf ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
I don't agree here. Using native file chooser or other common dialog panels will be break the look and feel of a GNUstep application. OK, you may not like this look and feel, but at least within an application it should be consistent. Honestly? If an application has a look and feel that is completely different from every other application breaking it's look and feel is probably a good thing. It would be fairly easy to add native dialog panels on windows, but how would you do it on Unix systems? We have different ones for KDE and Gnome, other environments don't even provide a shared one. What kind of consistency would we gain by using a KDE (or QT) file chooser in a Gnome environment? This is more than just WIndows, though. You can add Mac to the mix. Yeah, I know that most people who develop only on Mac would use Cocoa not GNUStep... but I think a lot of people who will choose GNUStep want a cross-development platform. And if I HOPE to get my application accepted by a Mac-Bigot (read that almost anyone who uses a MAC) it DAMN well better look like the apps they are used to seeing. I'm not much of a hard-core coder, and I have not looked at your libraries. But it SEEMS to me that I can have an API call that abstracts me from the back-end, and then I can switch it either by a runtime flag, or a compile time flag. When I was with Neuron Data, our cross-platform GUI could emulate any look on any system (if using our widget set) or switch to using the native look and feel -- all with a run-time flag. It ran on Mac, Windows, Unix, and even OS/2! Isn't something like this possible? Then I could have Gnome Look and feel on Gnome, QT Look and feel there, Mac look and feel on a mac...etc. Nicolas Roard wrote: I'm not saying we should _only_ use native file dialogs -- because then we'd have the problem of deciding what's a native dialog on platforms that use more than one toolkit -- as you say, a KDE file chooser in GNOME would be pointless. What I'm simply advocating is having the choice to use native dialogs rather than the GNUstep ones :) Eg, load a bundle that will provide native dialogs facilities, a bundle implementing Win32 dialogs, or KDE dialogs, or GNOME dialog, etc. [snip] For instance, some (native) file dialogs provides you with: - favorites - network access - previews - etc. I couldn't agree with this more. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
On Nov 15, 2007 12:54 PM, Ingolf Jandt [EMAIL PROTECTED] wrote: Please excuse the interference, but I really do not understand why you waste time and effort on this discussion. It reminds me somewhat of the wheel inventing committee in the Hitchhiker's trilogy (which is stuck in the discussion about the colour before having made any step forward). IMHO widgets mean lots of work without any gain. I thought my previous mails were clear.. but I'm only advocating native widgets for some specific dialogs like the file chooser. And the gain would be a better integration with the host platform; main target beeing gnustep on windows. And why start a debate about redesigning a software system between version 0.13 and 1.0? That is a topic for between 0.1 and 0.2 or maybe between 3.x and 4.0. Er... it's not like the idea would consist in a lot of redesign, and it has very narrow impact and can be easily isolated.. No offense meant, I am just bewildered you are so open to the idea of knocking the whole design and all your work on the head. It's _far_ from knocking the whole design -- the file dialogs in GNUstep are pretty simple, api-wise and functionality-wise: you just want to call it, and get a list of files. The only advanced feature (a very cool one, mind you) is rarely used if ever (accessory views). Therefore it should be easy to support native file dialogs, and I put forward in my previous emails the advantages of doing so. -- Nicolas Roard ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
I think that anyone thinking that GNUstep can be successful without a look that appears traditional to users within their environment and a behavior that somewhat closely mimic it too is deluding himself. To anyone doubtful about this I'll give the following examples: - Apple after buying NeXT created Rhapsody which adopted a look and feel more natural to Mac OS 9 users than NeXT. - Apple worked hard on making Java application integrate the best they could in the desktop environment - Apple made OpenStep and Carbon application coexist in such a fashion that's it's sometimes hard to tell a Carbon app from a Cocoa one - Sun created Windows themes for Swing a long time ago - Apple/NeXT had a special theme for Yellow Box on windows - Qt application look standard on windows (look like crap on Mac OS X) - Microsoft Office for Mac was at the beginnning a major failure because of an interface too close from the windows one, now it has a really different interface - Any mac users out there to have run OpenOffice? You just don't want to use it. - etc, etc. So if anyone thinks environment integration is unnecessary, then why would companies do their best at it? I know this might be a lot of work, still this is true. Regards. On Nov 15, 2007, at 4:41 PM, Wolfgang Lux wrote: Nicolas Roard wrote: It's _far_ from knocking the whole design -- the file dialogs in GNUstep are pretty simple, api-wise and functionality-wise: you just want to call it, and get a list of files. The only advanced feature (a very cool one, mind you) is rarely used if ever (accessory views). Therefore it should be easy to support native file dialogs, and I put forward in my previous emails the advantages of doing so. Err, sorry, but you probably should have a closer look at the API before saying such things. Getting just a file or a list of files may be sufficient for simple applications, but there are some more advanced uses of the panels, e.g., setting options for a particular file type if the file format supports variants (e.g., compression algorithm for TIFF files), which is commonly selected with some widgets in an accessory view. The panels also support a few useful delegate methods (e.g., controlling the visibility of filenames). In addition, there is also the treatsFilePackagesAsDirectories attribute (which is poorly supported in GNUstep at the moment, though). Wolfgang ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep --- Orange vous informe que cet e-mail a ete controle par l'anti-virus mail. Aucun virus connu a ce jour par nos services n'a ete detecte. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
Nicolas Roard wrote: It's _far_ from knocking the whole design -- the file dialogs in GNUstep are pretty simple, api-wise and functionality-wise: you just want to call it, and get a list of files. The only advanced feature (a very cool one, mind you) is rarely used if ever (accessory views). Therefore it should be easy to support native file dialogs, and I put forward in my previous emails the advantages of doing so. Err, sorry, but you probably should have a closer look at the API before saying such things. Getting just a file or a list of files may be sufficient for simple applications, but there are some more advanced uses of the panels, e.g., setting options for a particular file type if the file format supports variants (e.g., compression algorithm for TIFF files), which is commonly selected with some widgets in an accessory view. The panels also support a few useful delegate methods (e.g., controlling the visibility of filenames). In addition, there is also the treatsFilePackagesAsDirectories attribute (which is poorly supported in GNUstep at the moment, though). Wolfgang ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Does anyone have any suggestions of a good place to create a forum? (i.e which website?) -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Helge Hess [EMAIL PROTECTED] Cc: GNUstep Discuss Discuss discuss-gnustep@gnu.org Sent: Wednesday, November 14, 2007 10:43:36 PM Subject: Re: So, honestly, is GNUStep a viable development option? Having both is certainly a good thing, by only having one of the two you lock out quite a percentage of the other group. [and this doesn't mean that mailing list guys need to support forums, just having a forum for forums users is a good thing :-)] I support the idea of an official GNUstep forum. :-) It generally seems like a good idea - particularly for new users who want to browse information and discussions. :-) And it's not either mailing lists or a forum, as you say we can have both. We can keep most developer discussions on mailing lists, but also have a forum which we (mailing list guys) visit from time to time (depending on personal taste) but where the forum users can discuss happily. ;-) Finally, if we don't create an official GNUstep forum I imagine we'll just end up with many GNUstep forums. Starting a forum is quite easy and there seem to be people that are really keen on it, so the obvious consequence is that they will start GNUstep forums ... probably more than one, in competition. That would be bad because then the material gets fragmented. It would seem much better to just start an official one :-) Thanks ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
On Nov 15, 2007 12:46 AM, Gregory John Casamento [EMAIL PROTECTED] wrote: Also, I'm not convinced that having a forum will go very far to solving our problems. Yes, exposure is important. But another project called gcc, you may have heard of it, has used and still uses a mailing list. People don't seem to have a problem with it. And they don't seem to suffer for being different. So, incidentally, does Linux. It's called the kernel-dev mailing list. Linux CERTAINLY hasn't suffered for it. What I'm saying is that, you haven't proven to me any correlation between success and having a forum. Perhaps it will help, perhaps it won't... but applications will help more. Just playing devil's advocate here, as I don't necessarily support the idea of a forum... GCC and Linux are not toolkits/frameworks! GCC also has an extra blocking point to forums in that it's an application, not a large library of reusable software. The fact is that GNUstep is a very different beast and as such would need to be treated differently. Also, one of your previous points were that we shouldn't be doing/not doing things because other projects are/aren't. Stefan ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Does anyone have any suggestions of a good place to create a forum? (i.e which website?) I was thinking we would just run our own, and have it live within the new site structure, hence my request for a good PHP-driven forum package. J. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
On 15 Nov 2007, at 16:23, Gregory John Casamento wrote: Does anyone have any suggestions of a good place to create a forum? (i.e which website?) An official GNUstep forum should be hosted on the GNUstep site. Anything else looks unprofessional. David ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
On Nov 15, 2007 11:23 AM, Gregory John Casamento [EMAIL PROTECTED] wrote: Does anyone have any suggestions of a good place to create a forum? (i.ewhich website?) Me and Jesse (actually just Jesse since I'm dead weight on this issue) are looking into it. From previous e-mails, it looks like it's going to be at gnustep.org. You might want to track his latest e-mails titled: Forum http://lists.gnu.org/archive/html/discuss-gnustep/2007-11/msg00204.html Stefan ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Am 15.11.2007 um 17:44 schrieb Gregory John Casamento: Cool. I think this is an excellent idea. -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Jesse Ross [EMAIL PROTECTED] To: GNUstep Discuss discuss-gnustep@gnu.org Sent: Thursday, November 15, 2007 11:26:51 AM Subject: Re: So, honestly, is GNUStep a viable development option? Does anyone have any suggestions of a good place to create a forum? (i.e which website?) I was thinking we would just run our own, and have it live within the new site structure, hence my request for a good PHP-driven forum package. J. Since I am probably the one developer Helge mentionend, who uses forums, I think I can somewhat usefully recommend phpBB3 (RC7 currently). If you run a forum, you need to have a maintainer at least. Forums also get a lot of spam. They also need constant surveillance for vulnerabilities. Don't install it on a machine that mustn't ever get owned :) Active forums need active moderation. It's not setup and forget. But it's worth it IMO. Ciao Nat! -- I suppose I live in a fantasy world, but at least they know me there. -- DLR ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Cool. I think this is an excellent idea. -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Jesse Ross [EMAIL PROTECTED] To: GNUstep Discuss discuss-gnustep@gnu.org Sent: Thursday, November 15, 2007 11:26:51 AM Subject: Re: So, honestly, is GNUStep a viable development option? Does anyone have any suggestions of a good place to create a forum? (i.e which website?) I was thinking we would just run our own, and have it live within the new site structure, hence my request for a good PHP-driven forum package. J. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
I don't agree here. Using native file chooser or other common dialog panels will be break the look and feel of a GNUstep application. OK, you may not like this look and feel, but at least within an application it should be consistent. Using native dialog panels would also inhibit the accessory view mechanism, not that we are doing that great with it currently. It would be fairly easy to add native dialog panels on windows, but how would you do it on Unix systems? We have different ones for KDE and Gnome, other environments don't even provide a shared one. What kind of consistency would we gain by using a KDE (or QT) file chooser in a Gnome environment? Integration is worth a lot. A whole lot. There's two modes Gnustep gets used in, and supporting both is something I'd say is pretty smart: Gnustep as a main environment -- probably using Windowmaker as a window manager. The other is under whatever environment the user already uses. Sensing that and adjusting, so that apps feel right no matter where they are would be excellent. Both KDE and GTK's file browser widgets, as an example, can be extended. Some of the APIs to do so will be a bit unpleasant to meld with Gnustep, but there's a win there: Making the user feel at home. Stop keeping the reputation as stuck-in-the-80s-purists, and get on to being user-focused. Then when there are sufficient apps that a fully native desktop starts to feel right, let users start switching. This runs deeper, too, and into the theming issue. Providing a GNUstep GTK theme and QT theme might be a win too, though plenty of work. Add all the tools to make things feel integrated, and then embrace and extend. What we could try to do is move the gui code for these dialog panels into NIB files (or Gorm files if you are a bit old fashioned :-) and thereby offer the opportunity to replace them with layouts more suited for the current environment. Anybody interested in taking this task? It will be a great chance to learn more about Gorm. That'd be smart. I wonder how hard it would be to add a library or protocol that lets one use NSNativeFileChooser or whatever, as a widget in those files. Absolute positioning can be a small issue there, but I think it's solvable. It might add some constraints to the file chooser widget, but ultimately, I think that's a low price to pay. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
RE: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
Fried Kiefer wrote: Nicolas Roard wrote: Yes, file chooser should use the native one. I don't agree here. Using native file chooser or other common dialog panels will be break the look and feel of a GNUstep application. I agree with Fred here. I personally have no problem with non-native look of an application in an environment as long as the application itself is cool and powerful. On the other hand I'd see a huge value in fact that application won't require porting: it will work, say, on Windows, exactly same way as it was polished, say, on Linux. I'm afraid that changing widgets would require additional porting effort when switching to another platform. Thank you, Tima ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
(...) I personally have no problem with non-native look of an application in an environment as long as the application itself is cool and powerful. I think everybody on this mailing list knows that there are GNUstep users that do not really care about that. However there are people who care on the list, and the outside world cares about it too. I'm afraid that changing widgets would require additional porting effort when switching to another platform. I'd prefer create a NIB for X11, Windows and Mac OS X so that it looks good on these platform than not being able to look good on anyone. People discarding GNUstep for wxWidgets, GTK+, Qt are ready to code more for their interface, so they wouldn't be afraid if they needed to redo a NIB file. Actually, this is the same with localization, you have to duplicate NIBs and maintain them, but reaching more users is at stake. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Critical mass can be improved by making the gnustep site a hub for listing current gnustep applications, and even for downloading them. It will give a better idea to the visitors that GNUStep other than a programming platform, is also a user environment with a set of integrated tools. Besides the developers of those applications are the best positioned ones to become GNUStep contributors. If they are invited to add their work on the site, teir interest may increase. Daniel Santos markjoel60 wrote: The worst part of the flame, to me, was it completely missed the point. I wasn't saying that Ubuntu should be held up for all to admire and emulate... My point was that Ubuntu's success is a based mostly on mass and momentum. Because SO many people use it, it has an incredible user base which gives it more mass and more momentum. More users means better testing, a larger community to get answers and more people working in improving the code. Sadly, in our business Brute Force often succeeds where elegance and innovation has failed. Helge Hess wrote: On 13.11.2007, at 20:04, Riccardo wrote: flame steal the work of others, Wow, how do you steal *free software*? Sigh ... Helge -- Helge Hess http://www.helgehess.eu/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Am 13.11.2007 um 14:37 schrieb Mark Grice: 1. Stop the mailing list and put up a forum. That is the preferred method of communication for most people these days. Perhaps it's the method of communication currently in fashion, but Forii are so incredibly complex to handle (compared to a local mail reader), you'd immediately get rid of users like me. There are systems combining a forum and a mailing list, though. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Using a forum is incredibly complex? It is odd how these incredibly complex forums continue to be adopted by virtually every other OS, Language and development system out there... http://www.gtkforums.com/ http://www.qtforum.org/ http://www.cairoshell.com/forum/ http://discussions.apple.com/index.jspa (I could give you 1000 examples, really...) And yet I keep hearing from the GNUStep group that forums are complicated , useless for regular use, and terribly time consuming. This kind of response leaves me shaking my head and wondering... On Nov 14, 2007 11:59 AM, Markus Hitter [EMAIL PROTECTED] wrote: Am 13.11.2007 um 14:37 schrieb Mark Grice: 1. Stop the mailing list and put up a forum. That is the preferred method of communication for most people these days. Perhaps it's the method of communication currently in fashion, but Forii are so incredibly complex to handle (compared to a local mail reader), you'd immediately get rid of users like me. There are systems combining a forum and a mailing list, though. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Mark, I, personally, could take or leave forums... I don't care one way or the other. The issue I have with this discussion is that you have yet to show any valid and compelling reason to change *beyond* that's what everyone else is doing. If you could enumerate some advantages, aside from that, that forums have over mailing lists, I would be glad to consider it. The advantages of mailing lists, as I see it are: * It actually comes to you. You always know when there's a new message because it appears in your inbox. You don't need to go and check on a webpage for it * You can easily locate your last read message. With a forum, you need to browse backwards until you find the last read message. * There tend to be more help me messages on a forum. (Probably more...) Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Mark Grice [EMAIL PROTECTED] To: Markus Hitter [EMAIL PROTECTED] Cc: GNUstep Discuss Discuss discuss-gnustep@gnu.org Sent: Wednesday, November 14, 2007 1:49:00 PM Subject: Re: So, honestly, is GNUStep a viable development option? Using a forum is incredibly complex? It is odd how these incredibly complex forums continue to be adopted by virtually every other OS, Language and development system out there... http://www.gtkforums.com/ http://www.qtforum.org/ http://www.cairoshell.com/forum/ http://discussions.apple.com/index.jspa (I could give you 1000 examples, really...) And yet I keep hearing from the GNUStep group that forums are complicated , useless for regular use, and terribly time consuming. This kind of response leaves me shaking my head and wondering... On Nov 14, 2007 11:59 AM, Markus Hitter [EMAIL PROTECTED] wrote: Am 13.11.2007 um 14:37 schrieb Mark Grice: 1. Stop the mailing list and put up a forum. That is the preferred method of communication for most people these days. Perhaps it's the method of communication currently in fashion, but Forii are so incredibly complex to handle (compared to a local mail reader), you'd immediately get rid of users like me. There are systems combining a forum and a mailing list, though. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Hi all, I think Mark and Daniel is talking a lot of sense. ... put up a forum. That is the preferred method of communication for most people these days. Critical mass can be improved by making the gnustep site a hub for listing current gnustep applications, and even for downloading them. Personally, I find it easier to follow a 'forum style' conversation; it makes it easier to skim and get a quick overall impression of the thread. It also makes GNUstep more accessible and targeted for potential new developers: accessible because it sucks to sign-up to a mailing list if your only want to ask a first exploratory question, the targeted because you can sub-divide forums into in smaller work packages, e.g. Make, Base, GUI, Back, Apps, GNUstep on Windows, GNUstep on ... etc. Forums are a very open way of communicating. --DFJ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Mark, I, personally, could take or leave forums... I don't care one way or the other. The issue I have with this discussion is that you have yet to show any valid and compelling reason to change *beyond* that's what everyone else is doing. If you could enumerate some advantages, aside from that, that forums have over mailing lists, that would be nice. The advantages of mailing lists, as I see it are: * It actually comes to you. You always know when there's a new message because it appears in your inbox. You don't need to go and check on a webpage for it * You can easily locate your last read message. With a forum, you need to browse backwards to find the last unread message. GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Mark Grice [EMAIL PROTECTED] To: Markus Hitter [EMAIL PROTECTED] Cc: GNUstep Discuss Discuss discuss-gnustep@gnu.org Sent: Wednesday, November 14, 2007 1:49:00 PM Subject: Re: So, honestly, is GNUStep a viable development option? Using a forum is incredibly complex? It is odd how these incredibly complex forums continue to be adopted by virtually every other OS, Language and development system out there... http://www.gtkforums.com/ http://www.qtforum.org/ http://www.cairoshell.com/forum/ http://discussions.apple.com/index.jspa (I could give you 1000 examples, really...) And yet I keep hearing from the GNUStep group that forums are complicated , useless for regular use, and terribly time consuming. This kind of response leaves me shaking my head and wondering... On Nov 14, 2007 11:59 AM, Markus Hitter [EMAIL PROTECTED] wrote: Am 13.11.2007 um 14:37 schrieb Mark Grice: 1. Stop the mailing list and put up a forum. That is the preferred method of communication for most people these days. Perhaps it's the method of communication currently in fashion, but Forii are so incredibly complex to handle (compared to a local mail reader), you'd immediately get rid of users like me. There are systems combining a forum and a mailing list, though. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
On 15.11.2007, at 00:04, Gregory John Casamento wrote: If you could enumerate some advantages, aside from that, that forums have over mailing lists, that would be nice. We've found that people either like forums or mailing lists. Its a matter of preference and the spread seems to be ~ 50/50. Though I would tend to assume that *developers* are usually not using forums (though I know some [one ;-)]). Having both is certainly a good thing, by only having one of the two you lock out quite a percentage of the other group. [and this doesn't mean that mailing list guys need to support forums, just having a forum for forums users is a good thing :-)] Greets, Helge PS: The advantages of forums should be pretty obvious ... ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
OK... This is my last post on the subject, because there is no sense in beating a dead horse. But... 1) Because everyone else is doing it -- should be a compelling reason. I guess no one looks at it like this, but GNUStep competes with other IDEs and Foundations sets. In order to grow, you need new mindshare and new blood. You need more people working on the code, testing it, and building new apps. If you deliberately choose to appear different to people who come by looking at the state of things, you will turn them off, and they will choose something else. Apparently that doesn't bother a single soul on this list. But it should... 2) Every argument against a forum is outdated. Forums can be set to automatically email you. You can have a setting to show you all threads of interest to you, and to only show you unread posts. There is NOTHING you can do through a mailing list that cannot be done through a good forum. 3) Because a forum is widely used, navigation through it is simple. A new user can easily search it, and view posts that are of interest. Generally, the posts are grouped into categories which make finding information much easier. Browsing through the Nabble Archives, by comparison, is horrible. I can find something MUCH faster in the archives of a forum than I can in a nabble based archive. And if I came into a group late I don't have the advantage of old emails. 4) Forums allow information to be presented in a strategic way. In the masthead above, and the space beside the threads, you can put information. You can even (if the group grows) sell advertising space. You can have quick links to FAQs and installation guides. It becomes a one stop portal to all things GNUStep. And if you can't find it, you can ask...right there, without needing to go somewhere else and subscribe to something. 5) Believe it or not, some of us don't LIKE having things emailed to us. I get a hundred emails a day. I have had to set up a separate account just for GNUStep -- which I end up checking just like I would a forum. A lot of users who are casually interested would not sign up for daily emails... but they might find themselves checking a forum daily. More exposure to more people benefits GNUStep. And... This just kills me: * There tend to be more help me messages on a forum WHAT IS WRONG WITH THAT??? Do we not want to help people who are new and trying to use GNUStep? This seems to me to be THE MOST compelling reason for a Forum. Lord yes! Let us HOPE there are people who come and say: Help Me. Let's hope that as the answers known by a few become shared in a public forum it beomes knowledge shared by all. After time, the WHOLE community can share in helping new people get started. I'm sorry, I don't get this at all... it SEEMS like you are saying: You know what, my friends and I are busy coding and things. We like emailing each other. It's what we do. We really don't want to be bothered with questions by people like you. If you find something wrong, post a bug and we'll fix when we find time. Otherwise, take what we give you and be grateful... Maybe this isn't what you mean... but that is what it seems like to me. On 11/14/07, Gregory John Casamento [EMAIL PROTECTED] wrote: Mark, I, personally, could take or leave forums... I don't care one way or the other. The issue I have with this discussion is that you have yet to show any valid and compelling reason to change *beyond* that's what everyone else is doing. If you could enumerate some advantages, aside from that, that forums have over mailing lists, that would be nice. The advantages of mailing lists, as I see it are: * It actually comes to you. You always know when there's a new message because it appears in your inbox. You don't need to go and check on a webpage for it * You can easily locate your last read message. With a forum, you need to browse backwards to find the last unread message. GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Mark Grice [EMAIL PROTECTED] To: Markus Hitter [EMAIL PROTECTED] Cc: GNUstep Discuss Discuss discuss-gnustep@gnu.org Sent: Wednesday, November 14, 2007 1:49:00 PM Subject: Re: So, honestly, is GNUStep a viable development option? Using a forum is incredibly complex? It is odd how these incredibly complex forums continue to be adopted by virtually every other OS, Language and development system out there... http://www.gtkforums.com/ http://www.qtforum.org/ http://www.cairoshell.com/forum/ http://discussions.apple.com/index.jspa (I could give you 1000 examples, really...) And yet I keep hearing from the GNUStep group that forums are complicated , useless for regular use, and terribly time consuming. This kind of response leaves me shaking my head and wondering... On Nov 14, 2007 11:59 AM, Markus Hitter [EMAIL PROTECTED] wrote: Am 13.11.2007 um 14:37 schrieb Mark Grice: 1. Stop the mailing
Re: So, honestly, is GNUStep a viable development option?
On Nov 14, 2007, at 11:49 AM, Mark Grice wrote: Using a forum is incredibly complex? It is odd how these incredibly complex forums continue to be adopted by virtually every other OS, Language and development system out there... http://www.gtkforums.com/ http://www.qtforum.org/ http://www.cairoshell.com/forum/ http://discussions.apple.com/index.jspa And yet all the meaningful discussion happens on mailing lists like xdg-devel and on IRC. There's a reason. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Le mercredi 14 novembre 2007 à 17:14 -0700, Aria Stewart a écrit : On Nov 14, 2007, at 11:49 AM, Mark Grice wrote: Using a forum is incredibly complex? It is odd how these incredibly complex forums continue to be adopted by virtually every other OS, Language and development system out there... http://www.gtkforums.com/ http://www.qtforum.org/ http://www.cairoshell.com/forum/ http://discussions.apple.com/index.jspa And yet all the meaningful discussion happens on mailing lists like xdg-devel and on IRC. There's a reason. All meaningful discussions between established developers and users, maybe. If you want to reach other people, or at least let them talk about GNUstep and help each other, using other means could be a good idea. Just my 2 cents, Philippe ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Having both is certainly a good thing, by only having one of the two you lock out quite a percentage of the other group. [and this doesn't mean that mailing list guys need to support forums, just having a forum for forums users is a good thing :-)] I support the idea of an official GNUstep forum. :-) It generally seems like a good idea - particularly for new users who want to browse information and discussions. :-) And it's not either mailing lists or a forum, as you say we can have both. We can keep most developer discussions on mailing lists, but also have a forum which we (mailing list guys) visit from time to time (depending on personal taste) but where the forum users can discuss happily. ;-) Finally, if we don't create an official GNUstep forum I imagine we'll just end up with many GNUstep forums. Starting a forum is quite easy and there seem to be people that are really keen on it, so the obvious consequence is that they will start GNUstep forums ... probably more than one, in competition. That would be bad because then the material gets fragmented. It would seem much better to just start an official one :-) Thanks ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Forum (was Re: So, honestly, is GNUStep a viable development option?)
Having both is certainly a good thing, by only having one of the two you lock out quite a percentage of the other group. [and this doesn't mean that mailing list guys need to support forums, just having a forum for forums users is a good thing :-)] I support the idea of an official GNUstep forum. :-) It generally seems like a good idea - particularly for new users who want to browse information and discussions. :-) And it's not either mailing lists or a forum, as you say we can have both. We can keep most developer discussions on mailing lists, but also have a forum which we (mailing list guys) visit from time to time (depending on personal taste) but where the forum users can discuss happily. ;-) Finally, if we don't create an official GNUstep forum I imagine we'll just end up with many GNUstep forums. Starting a forum is quite easy and there seem to be people that are really keen on it, so the obvious consequence is that they will start GNUstep forums ... probably more than one, in competition. That would be bad because then the material gets fragmented. It would seem much better to just start an official one :-) I agree, and think it makes sense to add one to the new site. Does anyone have recommendations on a good PHP-based, MySQL-backed forum solution (preferably one that allows receiving and replying to posts via email)? J. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
backed) is a volunteer effort. Emailing the mailing list or forum with bugs is, generally, counter productive because we cannot categorize and track them. I, typically, react to Gorm and gui issues very quickly and others if I can when they are posted. While it's true there are some longstanding, minor issues, major issues, when reported, are squashed very quickly. I'm not sure if you're aware of it, but it does seem like you're trying to provoke a flamewar for no reason. All I was trying to do is get some answers beyond everyone else is out of you. And you react, quite honestly, very rudely. You really have been quite rude since the beginning. Rudeness has the effect of making people unwilling to listen to you... EVEN WHEN YOU ARE RIGHT (I'm not saying you are in this case).Some people will disagree with you, simply because you're being rude... to spite you. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Mark Grice [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: Markus Hitter [EMAIL PROTECTED]; GNUstep Discuss Discuss discuss-gnustep@gnu.org Sent: Wednesday, November 14, 2007 6:53:43 PM Subject: Re: So, honestly, is GNUStep a viable development option? OK... This is my last post on the subject, because there is no sense in beating a dead horse. But... 1) Because everyone else is doing it -- should be a compelling reason. I guess no one looks at it like this, but GNUStep competes with other IDEs and Foundations sets. In order to grow, you need new mindshare and new blood. You need more people working on the code, testing it, and building new apps. If you deliberately choose to appear different to people who come by looking at the state of things, you will turn them off, and they will choose something else. Apparently that doesn't bother a single soul on this list. But it should... 2) Every argument against a forum is outdated. Forums can be set to automatically email you. You can have a setting to show you all threads of interest to you, and to only show you unread posts. There is NOTHING you can do through a mailing list that cannot be done through a good forum. 3) Because a forum is widely used, navigation through it is simple. A new user can easily search it, and view posts that are of interest. Generally, the posts are grouped into categories which make finding information much easier. Browsing through the Nabble Archives, by comparison, is horrible. I can find something MUCH faster in the archives of a forum than I can in a nabble based archive. And if I came into a group late I don't have the advantage of old emails. 4) Forums allow information to be presented in a strategic way. In the masthead above, and the space beside the threads, you can put information. You can even (if the group grows) sell advertising space. You can have quick links to FAQs and installation guides. It becomes a one stop portal to all things GNUStep. And if you can't find it, you can ask...right there, without needing to go somewhere else and subscribe to something. 5) Believe it or not, some of us don't LIKE having things emailed to us. I get a hundred emails a day. I have had to set up a separate account just for GNUStep -- which I end up checking just like I would a forum. A lot of users who are casually interested would not sign up for daily emails... but they might find themselves checking a forum daily. More exposure to more people benefits GNUStep. And... This just kills me: * There tend to be more help me messages on a forum WHAT IS WRONG WITH THAT??? Do we not want to help people who are new and trying to use GNUStep? This seems to me to be THE MOST compelling reason for a Forum. Lord yes! Let us HOPE there are people who come and say: Help Me. Let's hope that as the answers known by a few become shared in a public forum it beomes knowledge shared by all. After time, the WHOLE community can share in helping new people get started. I'm sorry, I don't get this at all... it SEEMS like you are saying: You know what, my friends and I are busy coding and things. We like emailing each other. It's what we do. We really don't want to be bothered with questions by people like you. If you find something wrong, post a bug and we'll fix when we find time. Otherwise, take what we give you and be grateful... Maybe this isn't what you mean... but that is what it seems like to me. On 11/14/07, Gregory John Casamento [EMAIL PROTECTED] wrote: Mark, I, personally, could take or leave forums... I don't care one way or the other. The issue I have with this discussion is that you have yet to show any valid and compelling reason to change *beyond* that's what everyone else is doing. If you could enumerate some advantages, aside from that, that forums have over mailing lists, that would be nice. The advantages of mailing lists, as I see it are: * It actually comes to you. You always know when there's a new
Re: So, honestly, is GNUStep a viable development option?
I agree. -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Nicola Pero [EMAIL PROTECTED] To: Helge Hess [EMAIL PROTECTED] Cc: GNUstep Discuss Discuss discuss-gnustep@gnu.org Sent: Wednesday, November 14, 2007 10:43:36 PM Subject: Re: So, honestly, is GNUStep a viable development option? Having both is certainly a good thing, by only having one of the two you lock out quite a percentage of the other group. [and this doesn't mean that mailing list guys need to support forums, just having a forum for forums users is a good thing :-)] I support the idea of an official GNUstep forum. :-) It generally seems like a good idea - particularly for new users who want to browse information and discussions. :-) And it's not either mailing lists or a forum, as you say we can have both. We can keep most developer discussions on mailing lists, but also have a forum which we (mailing list guys) visit from time to time (depending on personal taste) but where the forum users can discuss happily. ;-) Finally, if we don't create an official GNUstep forum I imagine we'll just end up with many GNUstep forums. Starting a forum is quite easy and there seem to be people that are really keen on it, so the obvious consequence is that they will start GNUstep forums ... probably more than one, in competition. That would be bad because then the material gets fragmented. It would seem much better to just start an official one :-) Thanks ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Forum (was Re: So, honestly, is GNUStep a viable development option?)
On Nov 15, 2007 5:25 AM, Jesse Ross [EMAIL PROTECTED] wrote: I agree, and think it makes sense to add one to the new site. Does anyone have recommendations on a good PHP-based, MySQL-backed forum solution (preferably one that allows receiving and replying to posts via email)? PHP- or Post-Nuke. But that's just personal preference. -- Chris ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Being gnustep an API and development environment, its foundation is the open step specification, and has as an objective to follow the state of the Cocoa APIs. But the openstep spec also specifies a set of applications and user interface guidelines that make NextStep and consequently GNUStep look and feel the way it does. It is radically different than any other desktop environment that I know. The application is the menu, that manages a set of documents. Most applications are multi-document windows with a menu bar. The integration of these into gnustep is an illusion. Besides, the framework has a powerful design philosophy. Applications have a way to provide services to users and to applications, which makes them more powerful and resembles the unix style of shell programming. Not to mention that is supports transparent object oriented remote method invocations. One other point that is of great value is that its all written in objective C, a truly object oriented language (this is a selling point). You can change the way it looks, but if you change the way it works, seems to me that the value is lost, and it turns into yet another desktop environment. This difference may be a barrier to new users. For example the menu and a window for each document clutters the screen. You can solve this with virtual desktops (windows has some free ones). But this is practical for lengthy tasks. About the fact that you may be keeping a fossil alive, this is a misconception. In what way are current desktops evolved from their earlier versions ? Perhaps they look nicer. But it is still all about windows, menus, icons, etc. Next at the time, was sold as a machine, with an operating system and a basic set of applications. It was a common-denominator all-in-one, ideal for those who didn't know how to buy computer systems, and needed usability and power. To the user, GNUStep can only be as good as that. Applications that integrate well in the framework, and that span the most common daily tasks. Linux users are mostly developers or at least computer literate. The killer apps they need are already there. Development environments, compilers, text processors, etc. My point is, that if its good, why does it need to keep up with others, if its reason to exist is to be better that them. The fact is that or it isn't known, or that most people simply don't want it. Those that do, use it. Daniel Santos Gregory John Casamento wrote: Mark, Hi All... I don't mean to come on and be a flame thrower my first post. Believe me, I am hoping to be convinced that GNUStep is a great choice... but my three weeks of poking and playing makes me wonder... I'm not going to try to win you over, only give you the facts about where we are and what our intentions are. Here's the thing: I am getting ready to start a pretty big project in Linux and I am trying to decide what to use as a GUI/Framework. I did a lot of research and came across the GNUStep project and thought: Aha! This sounds great! Just what I was looking for! :) I downloaded it and ran through the couple of (old) tutorials I could find. It's enough to get a SENSE of what is possible... but not enough to persuade me to commit my future to it. And the look and feel of it is -- I'm sorry -- very tired and worn. I know from reading the archives that apparently a lot of the GNUSTEPPERS look longingly at the bland square icons and widgets of GNUStep getting nostalgic warm fuzzies (the way my father does when he looks at a '54 Buick)-- but trust me no user I'm building an app for will have the same reaction. While it's true that some people like the older look, there is a consensus that it really needs to be changed. The theme-engine available in the Etoile project (a desktop project based on GNUstep) currently allows great flexibility in GNUstep's look. Please see previous posts on this mailing list regarding the themes available for it. 1) Adopt a more modern look. Umm... no... it still looks like it did in 1999. There is a branch which contains theme related changes and the beginnings of integration of Camaelon (Etoile's theme engine) into GNUstep directly. 2) Make regular releases. Start courting different distributions to include GNUstep in their package set. Can' comment on this... I don't know how frequently the releases were before, but it appears that UBUNTU releases new versions of their whole distro more frequently than GNUSTEP releases updates. We currently have two live CDs and GNUstep is available on Debian, Ubuntu and, soon, Redhat. As for release frequency, I believe we release more frequently than Ubuntu releases their entire distro. skipped reply to 3, since it didn't seem terribly relevant 4) Start appealing more to the Mac OS X/Cocoa crowd. I honestly don't know how important that is, or what is meant by it... but appealing to the Mac
Re: So, honestly, is GNUStep a viable development option?
Hi Mark, First, as an Étoilé developer, I can answer the question in your subject line with a definite 'yes.' I recently did a Cocoa tutorial for OS X users where we developed a simple app in XCode and Interface Builder. In the last five minutes of the session, I copied the code that we had written across to my FreeBSD box, wrote a simple GNUmakefile, compiled it, and showed exactly the same application running on FreeBSD. On 13 Nov 2007, at 04:54, Mark Grice wrote: 1) Adopt a more modern look. Umm... no... it still looks like it did in 1999. Nicolas wrote Camaelon some years back. It is maintained in Étoilé svn and packaged by some distros (it's in ports for FreeBSD, although a somewhat old version). The current default theme for Camaelon users is Nesedah, which looks like this: http://www.roard.com/screenshots/screenshot_theme48.png This will eventually be replaced as the default in Étoilé with Narcissus, which looks roughly like this (mockup): http://jesseross.com/clients/etoile/ui/interface/800x480.png We support Mac-style horizontal menu bars as well as the OPENSTEP- style vertical menus. There was a bundle floating around a while back that attached menus to windows in Redmond-style (apparently there are still people who haven't worked out what a terrible idea that is), but I don't know if it's maintained. 2) Make regular releases. Start courting different distributions to include GNUstep in their package set. Can' comment on this... I don't know how frequently the releases were before, but it appears that UBUNTU releases new versions of their whole distro more frequently than GNUSTEP releases updates. GNUstep releases are roughly every six months. Distribution packages lag behind them somewhat, which is a shame and something the project still needs to work on. 3) Eliminate the need for GNUstep.sh... Well, this one wasn't a biggie for me... but I still had to run the GNUStep.sh to get things to compile. GNUstep.sh is still needed to compile, but not to run GNUstep applications. The new GNUstep.conf contains the configuration files needed to run things. Getting rid of GNUstep.sh completely would be nice, but as long as it only affects developers, not users, I don't consider it a major problem. 4) Start appealing more to the Mac OS X/Cocoa crowd. I honestly don't know how important that is, or what is meant by it... but appealing to the Mac OS Users by updating the look and feel would be a wonderful place to start. I believe this is targeted more at developers than users (GNUstep is an SDK, after all). Currently, OS X has a large pool of Objective-C/ OpenStep developers that are a good potential market for GNUstep. 5) Focus and concentrate on one and only one set of display technologies per platform. Not sure where this is... but it seems reasonable. Having a way of using the native look and feel would also be a huge plus for those of us who don't WANT to look different than every other app on a Distro... As Gregory mentioned, this was about adopting Cairo and deprecating the art/xlib backends. Fred has done a lot of work on the Cairo code recently, and it's now useable (but still officially a beta). By the way, if you want UIn consistency, there is also a GTK version of the Nesedah theme. 6) Decide what we are. Yes, that's right. Some people view GNUstep as a desktop, others view GNUstep as a development environment. I see this still being debated today... Someone in charge needs to stick a stake in the ground and move on already... I don't think there is any debate here. GNUstep is a development environment, Étoilé is a desktop. Some people contribute to both, but I don't think anyone mixes them up. 7) Make GNUstep friendly with other environments like GNOME, KDE, Windows and etc. Make sure that GNUstep functions sanely in these environments. Oh yeah, you betcha. This is a biggie. And not done. I can run a GNUStep app in Gnome, but if I hit the wrong key, suddenly find myself in a non-responsive wmaker session! Yikes! No idea how you did this. Yen-Ju and others have been working on things like NETWM compliance recently. GNUstep apps now behave a lot better with window managers that haven't been specifically written for GNUstep. Selling GNUStep is hard enough... having to sell Window Maker on top of it is a real stretch... We use Azalea, rather than Window Maker, for Étoilé. There are not Window Maker dependencies in GNUstep. I guess what I'm asking is this: Is GNUStep a living, breathing project that wants to be useful in 2007 and beyond, or are you guys the Computer version of the SCA (Society of Creative Anachronism) -- happy to be the caretakers of a historical moment in time, extolling the virtues of a system that has lost its effectiveness, but was really cool way back when? OpenStep is still the easiest development system I've come across and Objective-C
Re: So, honestly, is GNUStep a viable development option?
3) Eliminate the need for GNUstep.sh... Well, this one wasn't a biggie for me... but I still had to run the GNUStep.sh to get things to compile. GNUstep.sh is still needed to compile, but not to run GNUstep applications. The new GNUstep.conf contains the configuration files needed to run things. Getting rid of GNUstep.sh completely would be nice, but as long as it only affects developers, not users, I don't consider it a major problem. Technically, it's all done, even if we need packagers/everyone to take advantage of it and present/document it nicely for users. At the moment, for a confused user trying to get started quickly, sourcing GNUstep.sh might be simpler than editing PATH or library paths. Anyway I suppose this is using the default flattened GNUstep filesystem layout ? :-) In which case, the following comment (from core/make/FilesystemLayouts/gnustep) applies: # If the layout is flattened, it's still a good idea to source # GNUstep.sh if it's not too much trouble for you, else you can # manually add /usr/GNUstep/System/Tools and /usr/GNUstep/Local/Tools # to your PATH, /usr/GNUstep/System/Library/Libraries and # /usr/GNUstep/Local/Library/Libraries to your LD_LIBRARY_PATH (or # /etc/ld.so.conf + ldconfig). # # To use gnustep-make in this environment, source GNUstep.sh or use # 'export GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles'. In other words, you can avoid sourcing GNUstep.sh if you add your program paths to your PATH, add your library paths to your LD_LIBRARY_PATH (or equivalent on your operating system), and use export GNUSTEP_MAKEFILES=/usr/GNUstep/System/Library/Makefiles before compiling. Btw, if the GNUmakefile has been updated to use gnustep-config, this last step is not even required. Thanks PS: If you use the fhs layout, then you don't even need to set PATH or LD_LIBRARY_PATH, but you need to remember to run ldconfig (or equivalent on your operating system) each time you compile a library. If gnustep-config is also used in the GNUmakefiles, then you have to do absolutely nothing - everything should just work (except for having to run ldconfig after you compile a library) ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Thanks for the replies. It was a relief to wake up this morning and see that the mailing list is active, I sent an email to the Etoille list days ago (a lot less flammatory, btw) and still have not seen any reply. So maybe at least part of my tone came from frustration. A couple of things, but let me start with this one: The WMAKER link I described is more than a misconception, I think. It happens when following the tutorial for Project Center and Gorm! Let me tell you what I did, and you tell me what I did wrong... (I am working in UBUNTU Gnome 7.10) Following the tutorial script: I run Project Center. Create a new project. Click on Interfaces and then double click on the Convertor.gorm file... and I find myself staring at a WindowMaker screen that is pretty much non functional. I have to CTRL-ALT-DEL and log off my session to get control back. This tells me that I cannot really run GNUStep in Gnome. Things function as the tutorial says they will if I run them in Window Maker. I assumed that this was expected behavior, since the GNUStep home page pretty much tells you to use Window Maker... so I didn't want to call it a bug. If it is a bug, I will be happy to enter it as such... ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
OK. So, I have a couple of thoughts. If the goal is to bring GNUStep into use to as many developers as possible, there is only one solution: Critical Mass. The history of our industry shows us that the best product rarely wins. (Anyone think that Windows Vista is the best windowing system?) Building a better mousetrap is not enough. You have to build critical mass and get enough people using your product that it becomes easy for the late-adopters to follow suit. If UBUNTU has shown us nothing, it has shown us that. It would be nice if a billionaire would decide to advertise the hell out of GNUStep, but assuming that won't happen... what else can be done? First, you have to lower the barrier for noobs (such as myself). I get a sense that most GNUStep developers today were NEXTStep (or OpenStep) developers in the past. That is fine, but you have to realize that you started into GNUStep with a lot more understanding of what it can and should do than a guy like me. Instead of getting frustrated by the KDE fanboys who come on here and say: Hell, KDevelop does everything GORM does... you need to see that as a failure to get the message out. Yeah, some fanboys are hopeless, but some are simply ignorant, not Kool-Aid impaired. I have gone on Amazon and found used books on NEXTStep development. I've ordered them and hope they will help fill the gaps I am missing to understanding exactly what GNUStep gives me. That isn't a viable strategy for everyone though. (For one thing, the source of used books will one day dry up...) So, here is what I suggest (and you will be happy to note that none of these steps require any programming changes :-) 1. Stop the mailing list and put up a forum. That is the preferred method of communication for most people these days. This takes about one day to do, and costs little or nothing. I would be happy to set up the basic structure for this if anyone wants me to, but I obviously can't fill in all of the information. I'd even be willing to register the domain and pay for the first year (and maybe more, but I can easily commit to a year...) 2. Detailed installation instructions. PLEASE. I actually had very little trouble getting GNUStep on Ubuntu. I used the Synaptic Package manager, clicked everything even resembling GNUSTEP, and had no problems at all. HOWEVER -- The GNUStep.org page still includes a link for UBUNTU that is almost 3 years old! I read that and was so confused, I almost gave up! And, I still read that some people can't manage to get it installed. This is a real problem. We need instructions that even a Linux/Unix noob can follow. These people are a GREAT source of new converts because a lot of them haven't made their mind up yet about GNOME vs. KDE, and are open to new development environments. 3. Update the examples. It's nice to have them, but with no document to describe them, and virtually no comments in the code, they aren't very helpful. And make sure they work on the main Distros. (i.e. Debian, Ubuntu, and Redhat) My PC/GORM problem is the prime example of something that should never happen to someone following a script. 3. More tutorials. More examples. My suggestion: Scour the net for the new KDevelop and GLADE examples. Take one and re-do it in GNUStep. SHOW people why working with GORM and GNUSTEP cuts down on their programming time. I'll be happy to help out here -- but first I need to learn this myself... A lot of this work doesn't require heavy lifting, but will bring in a lot of results, I think. Then, moving forward: A) Update the look and feel. If that means Cameleon, great. If it is Etoille. Fine. But there should be ONE PLACE to get this. That should be the MAIN ROOT, not a branch. If someone wants to keep the old style NEXTStep look and feel THAT should be a branch. The main code has to move forward in this area or no one will take GNUStep seriously. B) Native widgets. Why not? I used to work for Neuron Data about 15 years ago. We had a product called Open Interface that provided a cross-platform GUI. It was great when we started -- a superset of all windowing environments... but we couldn't keep up. Critical mass was against us. Our developers kept telling us that there was no way to use native toolkits then... suddenly... there was. It made a difference. Now if I opened a file dialog box it looked like everyone else's. That is HUGE to a user. I can't emphasize it enough... C) Once the look and feel is ready, and the thing is well tested, we need articles written for the magazine and journals. The goal would be to have a product exciting enough, and an article compelling enough, that we can get them to include our LiveCD with the Magazine. D) Someone needs to see about getting the old NextStep books rewritten for GNUStep. I honestly think that the idea of a RAD development environment that crosses UNIX/LINUX/MAC and WINDOWS boundaries has HUGE play. Microsoft has made a huge mistake with VIsta. It comes at a time when Leopard is
Re: So, honestly, is GNUStep a viable development option?
Hi, On Nov 13, 2007 1:13 PM, Mark Grice [EMAIL PROTECTED] wrote: Thanks for the replies. It was a relief to wake up this morning and see that the mailing list is active, I sent an email to the Etoille list days ago (a lot less flammatory, btw) and still have not seen any reply. So maybe at least part of my tone came from frustration. A couple of things, but let me start with this one: The WMAKER link I described is more than a misconception, I think. It happens when following the tutorial for Project Center and Gorm! Let me tell you what I did, and you tell me what I did wrong... (I am working in UBUNTU Gnome 7.10) Following the tutorial script: I run Project Center. Create a new project. Click on Interfaces and then double click on the Convertor.gorm file... and I find myself staring at a WindowMaker screen that is pretty much non functional. I have to CTRL-ALT-DEL and log off my session to get control back. It _may_ be that something (ProjectCenter ? Gorm ? ...) crashes your current gnome windowmanager (or the gnome session manager ?) -- which would results in what you describe, as iirc ubuntu uses windowmaker as a failsafe wm if the current one crashes. I vaguely remember it happening to me (though not because of gnustep). So basically your session crashes and windowmaker is started. This tells me that I cannot really run GNUStep in Gnome. Things function as the tutorial says they will if I run them in Window Maker. I assumed that this was expected behavior, since the GNUStep home page pretty much tells you to use Window Maker... so I didn't want to call it a bug. If it is a bug, I will be happy to enter it as such... I'm not sure a lot of people uses gnustep under gnome, but if that's reproducible we should definitely investigate. -- Nicolas Roard ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
On Nov 13, 2007 1:37 PM, Mark Grice [EMAIL PROTECTED] wrote: B) Native widgets. Why not? I used to work for Neuron Data about 15 years ago. We had a product called Open Interface that provided a cross-platform GUI. It was great when we started -- a superset of all windowing environments... but we couldn't keep up. Critical mass was against us. Our developers kept telling us that there was no way to use native toolkits then... suddenly... there was. It made a difference. Now if I opened a file dialog box it looked like everyone else's. That is HUGE to a user. I can't emphasize it enough... It's not that is it impossible to achieve, but it would bring little value; bear with me... The reason why people say we can't support native widgets is because of our architecture -- everything displayed by a gnustep app is done through the toolkit (obviously), in a vector form, and with a common widget ancestor. Implementing native widgets could possibly be done by having one window per widget that would be remapped at the right position; but 1) it's rather inefficient 2) it would also need quite some work to work around the native widgets so that we'd still work with them following the gnustep api (I mean, sure for a button it's easy, but what about NSTableView ? you'd end up reimplementing half of NSTableView logic as a wrapper around a native tableview widget, and it likely may not even be doable because of lack of capacities from the native widgets). It would break any consistency -- how to inherits from a native widget to specialize it ? And what to do when a gnustep widget does not have an equivalent on the platform (eg, NSBrowser) ? So really, native widgets... not such a good idea. But on the other hand, we should strive for platform integration, if GNUstep's goal of beeing a cross-platform api wants to be met (sure, there's a school of thought saying we could just be exactly the same on any platform, and that may be true or good enough for some use cases, but I do believe the majority of developers and users would love more integration with the host platform). As explained above, using native widgets is not a good idea -- it would be a tremendous effort for nothing much more than getting a WxWidgets clone, with important loss of consistency and capacities. But what we can /easily/ do is to use theming facilities to at the very least integrates better visually -- and on Windows for instance, there is a theming api ready to be used for just this kind of case. And theming can be a bit more than a different look -- swapping scrollbars position (from left to right) is doable as well (there was a bundle that did that), etc. To be thorough, there IS some widgets/facilities where we indeed should use the native ones, like the file chooser, etc. , but they are more an exception than the rule. So for me the proper route is to 1/ use host theming api (when present) to integrate visually 2/ use native widgets for a few selected things like the file chooser 3/ pasteboard integration ... Note that this is _exactly_ what NeXT did with OpenStep for Windows. It's not a perfect solution but it's a good compromise. -- Nicolas Roard ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
OK, valid points. One thing I want to emphasize is that I am NOT suggesting that GNUStep supports MDI. Lord forbid! I don't think that is necessary for widespread adoption (Mac seems to have done OK without it :-) But a single horizontal menu bar seems to be the accepted practice of all non-Redmond users, and the direction of Cocoa. So.. maybe a good compromise would be dialog boxes and not widgets? I can live with different widgets... (Maybe even some sort of a widget editor where I can recreate the widgets used if I want to?) But dialog boxes are a prime example of what would be better if it were native. For example: Ubuntu has Samba, which allows me to get to the windows drives on my network. It also allows me to view thumbnails of the graphic images. Their file dialog box supports these out of the box... As a developer, it would be nice if my file chooser automatically gave these kinds of options to my end users. I am assuming that the native GNUStep does not, because when I run the examples, I can neither see thumbnails of images, nor can I access my SMB files... But that may be ignorance on my part... On Nov 13, 2007 9:05 AM, Nicolas Roard [EMAIL PROTECTED] wrote: On Nov 13, 2007 1:37 PM, Mark Grice [EMAIL PROTECTED] wrote: B) Native widgets. Why not? I used to work for Neuron Data about 15 years ago. We had a product called Open Interface that provided a cross-platform GUI. It was great when we started -- a superset of all windowing environments... but we couldn't keep up. Critical mass was against us. Our developers kept telling us that there was no way to use native toolkits then... suddenly... there was. It made a difference. Now if I opened a file dialog box it looked like everyone else's. That is HUGE to a user. I can't emphasize it enough... It's not that is it impossible to achieve, but it would bring little value; bear with me... The reason why people say we can't support native widgets is because of our architecture -- everything displayed by a gnustep app is done through the toolkit (obviously), in a vector form, and with a common widget ancestor. Implementing native widgets could possibly be done by having one window per widget that would be remapped at the right position; but 1) it's rather inefficient 2) it would also need quite some work to work around the native widgets so that we'd still work with them following the gnustep api (I mean, sure for a button it's easy, but what about NSTableView ? you'd end up reimplementing half of NSTableView logic as a wrapper around a native tableview widget, and it likely may not even be doable because of lack of capacities from the native widgets). It would break any consistency -- how to inherits from a native widget to specialize it ? And what to do when a gnustep widget does not have an equivalent on the platform (eg, NSBrowser) ? So really, native widgets... not such a good idea. But on the other hand, we should strive for platform integration, if GNUstep's goal of beeing a cross-platform api wants to be met (sure, there's a school of thought saying we could just be exactly the same on any platform, and that may be true or good enough for some use cases, but I do believe the majority of developers and users would love more integration with the host platform). As explained above, using native widgets is not a good idea -- it would be a tremendous effort for nothing much more than getting a WxWidgets clone, with important loss of consistency and capacities. But what we can /easily/ do is to use theming facilities to at the very least integrates better visually -- and on Windows for instance, there is a theming api ready to be used for just this kind of case. And theming can be a bit more than a different look -- swapping scrollbars position (from left to right) is doable as well (there was a bundle that did that), etc. To be thorough, there IS some widgets/facilities where we indeed should use the native ones, like the file chooser, etc. , but they are more an exception than the rule. So for me the proper route is to 1/ use host theming api (when present) to integrate visually 2/ use native widgets for a few selected things like the file chooser 3/ pasteboard integration ... Note that this is _exactly_ what NeXT did with OpenStep for Windows. It's not a perfect solution but it's a good compromise. -- Nicolas Roard ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: Native widgets (was: Re: So, honestly, is GNUStep a viable development option?)
On Nov 13, 2007 2:16 PM, Mark Grice [EMAIL PROTECTED] wrote: OK, valid points. One thing I want to emphasize is that I am NOT suggesting that GNUStep supports MDI. Lord forbid! I don't think that is necessary for widespread adoption (Mac seems to have done OK without it :-) But a single horizontal menu bar seems to be the accepted practice of all non-Redmond users, and the direction of Cocoa. So.. maybe a good compromise would be dialog boxes and not widgets? I can live with different widgets... (Maybe even some sort of a widget editor where I can recreate the widgets used if I want to?) But dialog boxes are a prime example of what would be better if it were native. For example: Ubuntu has Samba, which allows me to get to the windows drives on my network. It also allows me to view thumbnails of the graphic images. Their file dialog box supports these out of the box... As a developer, it would be nice if my file chooser automatically gave these kinds of options to my end users. I am assuming that the native GNUStep does not, because when I run the examples, I can neither see thumbnails of images, nor can I access my SMB files... But that may be ignorance on my part... Yes, file chooser should use the native one. For horizontal menus embedded in windows, there was a bundle providing that automatically, but it was kinda of a hack. I would prefer to let the developers create different nibs for different platforms, so that each could follow properly the platform guidelines.. -- Nicolas Roard ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
A window maker screen?? I'm still extremely unclear about what you're talking about here. WindowMaker was the preferred window manager, but it's not the ONLY window manager GNUstep works with. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Mark Grice [EMAIL PROTECTED] To: Gregory John Casamento [EMAIL PROTECTED] Cc: discuss-gnustep@gnu.org Sent: Tuesday, November 13, 2007 8:13:28 AM Subject: Re: So, honestly, is GNUStep a viable development option? Thanks for the replies. It was a relief to wake up this morning and see that the mailing list is active, I sent an email to the Etoille list days ago (a lot less flammatory, btw) and still have not seen any reply. So maybe at least part of my tone came from frustration. A couple of things, but let me start with this one: The WMAKER link I described is more than a misconception, I think. It happens when following the tutorial for Project Center and Gorm! Let me tell you what I did, and you tell me what I did wrong... (I am working in UBUNTU Gnome 7.10) Following the tutorial script: I run Project Center. Create a new project. Click on Interfaces and then double click on the Convertor.gorm file... and I find myself staring at a WindowMaker screen that is pretty much non functional. I have to CTRL-ALT-DEL and log off my session to get control back. This tells me that I cannot really run GNUStep in Gnome. Things function as the tutorial says they will if I run them in Window Maker. I assumed that this was expected behavior, since the GNUStep home page pretty much tells you to use Window Maker... so I didn't want to call it a bug. If it is a bug, I will be happy to enter it as such... ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Le Lundi 12 Novembre 2007 23:54:03 EST, Mark Grice [EMAIL PROTECTED] a écrit: Hi All... I don't mean to come on and be a flame thrower my first post. Believe me, I am hoping to be convinced that GNUStep is a great choice... but my three weeks of poking and playing makes me wonder... Here's the thing: I am getting ready to start a pretty big project in Linux and I am trying to decide what to use as a GUI/Framework. I did a lot of research and came across the GNUStep project and thought: Aha! This sounds great! Just what I was looking for! Hi Mark, GNUstep has a wonderful API, but the gui part is seriously lacking in stability and features. Also the mention of theming and of a more modern look has been around for years and nothing changed. Therefore, if your projet needs a GUI, you are probably better with wxWidgets, which is cross-platform (using the native GUI) and has bindings for many languages. However, if you are looking to make a command-line application (or a server app.), then GNUstep is possibly very mature. GNUstep's killer non-gui app is probably SOGo: http://sogo-demo.inverse.ca/ (hint hint), using a WebObjects derivative named SOPE (sope.opengroupware.org). But this would be useful only if you consider writing web-based applications. Good luck! Wolfgang ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Wolfgang, GNUstep has a wonderful API, but the gui part is seriously lacking in stability and features. Also the mention of theming and of a more modern look has been around for years and nothing changed. Therefore, if your projet needs a GUI, you are probably better with wxWidgets, which is cross-platform (using the native GUI) and has bindings for many languages. The problem is that no one has really had the time to devote to revamping the theme. This is a huge undertaking. I, personally, am hoping to have some time to devote to this soon. There are plenty of features the fact that Gorm works seamlessly and uses most of the features of GUI is a testament to GUI's current stability. If GUI were as seriously lacking as you seem to suggest, I would expect to see it crash at least once in a while. Also, we have almost all of the classes available under Cocoa which are practical to implement on Linux. We're missing the scripting classes and some of the controller classes are not complete, but everything else used by most applications is there. And what's not there for certain apps should be added as we implement more apps using GUI. By suggesting that he not use GNUstep GUI, you're suggesting that he throw the baby out with the bathwater and, at the same time, not encouraging contribution back to the community. Later, GJC -- Gregory Casamento -- OLC, Inc # GNUstep Chief Maintainer - Original Message From: Wolfgang Sourdeau [EMAIL PROTECTED] To: discuss-gnustep@gnu.org Sent: Tuesday, November 13, 2007 12:48:46 PM Subject: Re: So, honestly, is GNUStep a viable development option? Le Lundi 12 Novembre 2007 23:54:03 EST, Mark Grice [EMAIL PROTECTED] a écrit: Hi All... I don't mean to come on and be a flame thrower my first post. Believe me, I am hoping to be convinced that GNUStep is a great choice... but my three weeks of poking and playing makes me wonder... Here's the thing: I am getting ready to start a pretty big project in Linux and I am trying to decide what to use as a GUI/Framework. I did a lot of research and came across the GNUStep project and thought: Aha! This sounds great! Just what I was looking for! Hi Mark, GNUstep has a wonderful API, but the gui part is seriously lacking in stability and features. Also the mention of theming and of a more modern look has been around for years and nothing changed. Therefore, if your projet needs a GUI, you are probably better with wxWidgets, which is cross-platform (using the native GUI) and has bindings for many languages. However, if you are looking to make a command-line application (or a server app.), then GNUstep is possibly very mature. GNUstep's killer non-gui app is probably SOGo: http://sogo-demo.inverse.ca/ (hint hint), using a WebObjects derivative named SOPE (sope.opengroupware.org). But this would be useful only if you consider writing web-based applications. Good luck! Wolfgang ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
HI, this discussion is a bit sidestepping and taking up precious time to reply, still, let me make some short commrents. On 2007-11-13 14:37:39 +0100 Mark Grice [EMAIL PROTECTED] wrote: If UBUNTU has shown us nothing, it has shown us that. flame steal the work of others, make up some bad packages which are often broken, hide everything behind some shiny desktops and setups and call it a distro? /flame I get a sense that most GNUStep developers today were NEXTStep (or OpenStep) developers in the past. That is fine, but you have to realize that you started into GNUStep with a lot more understanding of this is pretty wrong. Although some people here used NeXT, I come from the Mac and Unix world. One day I wanted to develop. Also, I was tired of that shiny, bloggy, yummy look that most linux stuf has and which just wastes my resources. I was happy with apple but found it just un-professional looking, furthermore the more macos evlolved the less I could share some of its choices. I speak for myself, but I know of others. And I was a total newbie. I fo und installing gnustep extremely easy on debian: just install the packages and start the stuff from windowmaker menu. Sure that was the beginning. Quickly I wanted my own environment and reading the tutorial from Dennis I set up my environment. Easy. Easier than compiling gnome or kde! just get the release tarballs, configure, make install. Once you need to source that file or you can put it in yor shell script. But if you want to develop, you better master these small tricks. I have gone on Amazon and found used books on NEXTStep development. I've ordered them and hope they will help fill the gaps I am missing to understanding exactly what GNUStep gives me. That isn't a viable strategy for everyone though. (For one thing, the source of used books will one day dry up...) OpenStep would have been better. But many tutorials for the old Rhapsody or early macOS just apply 1:1! The dev. environment is a bit different, but gorm operates like interface builder and once you get that make is needed (but ProjectCenter hides that for you) you can just redo them. Also this appears a world where you need to feed everybody. Gnustep has an example package with some apps which cover many aspects of development. Furthermore being most applications opensource you can just take them and dissect them. Bootrap is easy, you need just a couple of things - understanding Objc. The NeXT or Apple book is perfect for that and freely available - knowing your dev. environment. Either ProjectCenter+Gorm or your makefiles with vi/emacs. - get a general grasp of Foundation and AppKit then just start coding, the rest comes by itself. 1. Stop the mailing list and put up a forum. That is the preferred method of communication for most people these days. This takes about one day to do, and costs little or nothing. I would be happy to set up the basic structure for this if anyone wants me to, but I obviously can't fill in all of the information. I'd even be willing to register the domain and pay for the first year (and maybe more, but I can easily commit to a year...) forums are terribly time consuming. A mailing list is really better. And I use forums elsewhere, so I know what they are. If the mailing list bothers you you can use the gmane news gateway. There is also an IRC channel. 2. Detailed installation instructions. PLEASE. I actually had very little trouble getting GNUStep on Ubuntu. I used the Synaptic Package manager, clicked everything even resembling GNUSTEP, and had no problems at all. HOWEVER -- The GNUStep.org page still includes a link for UBUNTU that is almost 3 years old! I read that and was so confused, I almost gave up! help updating the wiki. Or think before giving up. And, I still read that some people can't manage to get it installed. This is a real problem. We need instructions that even a Linux/Unix noob can follow. These people are a GREAT source of new converts because a lot of them haven't made their mind up yet about GNOME vs. KDE, and are open to new development environments. a developer is never a noob, so the instructions just need to be up to date. But this consumes time and resources. Users should just be able to use packages form their distro, but this requires them to be well set up. 3. Update the examples. It's nice to have them, but with no document to describe them, and virtually no comments in the code, they aren't very helpful. And make sure they work on the main Distros. (i.e. Debian, Ubuntu, and Redhat) My PC/GORM problem is the prime example of something that should never happen to someone following a script. I commented that above. Your problem is related to some setup or a bug or both. Gnustep runs on a much more diversified environment than KDE :) 3. More tutorials. More examples. My suggestion: Scour the net for the new KDevelop and GLADE examples. Take one and re-do it in GNUStep. SHOW
Re: So, honestly, is GNUStep a viable development option?
On 13.11.2007, at 20:04, Riccardo wrote: flame steal the work of others, Wow, how do you steal *free software*? Sigh ... Helge -- Helge Hess http://www.helgehess.eu/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
The worst part of the flame, to me, was it completely missed the point. I wasn't saying that Ubuntu should be held up for all to admire and emulate... My point was that Ubuntu's success is a based mostly on mass and momentum. Because SO many people use it, it has an incredible user base which gives it more mass and more momentum. More users means better testing, a larger community to get answers and more people working in improving the code. Sadly, in our business Brute Force often succeeds where elegance and innovation has failed. Helge Hess wrote: On 13.11.2007, at 20:04, Riccardo wrote: flame steal the work of others, Wow, how do you steal *free software*? Sigh ... Helge -- Helge Hess http://www.helgehess.eu/ ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep -- View this message in context: http://www.nabble.com/So%2C-honestly%2C-is-GNUStep-a-viable-development-option--tf4795771.html#a13739591 Sent from the GNUstep - General mailing list archive at Nabble.com. ___ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
Re: So, honestly, is GNUStep a viable development option?
Mark, Hi All... I don't mean to come on and be a flame thrower my first post. Believe me, I am hoping to be convinced that GNUStep is a great choice... but my three weeks of poking and playing makes me wonder... I'm not going to try to win you over, only give you the facts about where we are and what our intentions are. Here's the thing: I am getting ready to start a pretty big project in Linux and I am trying to decide what to use as a GUI/Framework. I did a lot of research and came across the GNUStep project and thought: Aha! This sounds great! Just what I was looking for! :) I downloaded it and ran through the couple of (old) tutorials I could find. It's enough to get a SENSE of what is possible... but not enough to persuade me to commit my future to it. And the look and feel of it is -- I'm sorry -- very tired and worn. I know from reading the archives that apparently a lot of the GNUSTEPPERS look longingly at the bland square icons and widgets of GNUStep getting nostalgic warm fuzzies (the way my father does when he looks at a '54 Buick)-- but trust me no user I'm building an app for will have the same reaction. While it's true that some people like the older look, there is a consensus that it really needs to be changed. The theme-engine available in the Etoile project (a desktop project based on GNUstep) currently allows great flexibility in GNUstep's look. Please see previous posts on this mailing list regarding the themes available for it. 1) Adopt a more modern look. Umm... no... it still looks like it did in 1999. There is a branch which contains theme related changes and the beginnings of integration of Camaelon (Etoile's theme engine) into GNUstep directly. 2) Make regular releases. Start courting different distributions to include GNUstep in their package set. Can' comment on this... I don't know how frequently the releases were before, but it appears that UBUNTU releases new versions of their whole distro more frequently than GNUSTEP releases updates. We currently have two live CDs and GNUstep is available on Debian, Ubuntu and, soon, Redhat. As for release frequency, I believe we release more frequently than Ubuntu releases their entire distro. skipped reply to 3, since it didn't seem terribly relevant 4) Start appealing more to the Mac OS X/Cocoa crowd. I honestly don't know how important that is, or what is meant by it... but appealing to the Mac OS Users by updating the look and feel would be a wonderful place to start. Indeed... as stated before... there is a theme engine available the the default look is set to change. 5) Focus and concentrate on one and only one set of display technologies per platform. Not sure where this is... but it seems reasonable. Having a way of using the native look and feel would also be a huge plus for those of us who don't WANT to look different than every other app on a Distro... Your assumption is incorrect. It has nothing to do with the look, but how the graphics are rendered. GNUstep's look is consistent across all platforms today. This goal discusses moving away from older technologies such as Xlib and art onto the Cairo graphics library. This refers, in case you're unaware, to the back-end library of GNUstep which handles basic drawing and events. We have a version of this backend that is currently in beta. Using native widgets is a different issue altogether and has been discussed before. 6) Decide what we are. Yes, that's right. Some people view GNUstep as a desktop, others view GNUstep as a development environment. I see this still being debated today... Someone in charge needs to stick a stake in the ground and move on already... I have said many times on this list in the past year: GNUstep is an API and development environment. Period. Desktops such as Etoile are built on top of it. 7) Make GNUstep friendly with other environments like GNOME, KDE, Windows and etc. Make sure that GNUstep functions sanely in these environments. Oh yeah, you betcha. This is a biggie. And not done. I can run a GNUStep app in Gnome, but if I hit the wrong key, suddenly find myself in a non-responsive wmaker session! Yikes! (further, untrue, rants regarding the mistaken assumption that GNUstep is tied to wmaker or somehow dependent deleted) GNUstep is not tied to WindowMaker. This is an extremely common misconception. What this point refers to is interoperability with freedesktop and, themes. Many changes have been made in the backend to make GNUstep play better with freedesktop based window managers. Also, I'd be interested in what wrong key you're hitting in GNOME that lands you in a wmaker session. That certainly is a bug if it's severe enough to cause you to quit one Window Manager and land you squarely in antoher. ;) If it is happening, I invite you to, please, submit a bug on savannah to help us squash it as soon as
