Re: Changes I've been thinking of...
Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. Completely agree. Good coding conventions are picked because they make things that are wrong look wrong or generate compiler errors / warnings. The GNU coding conventions were picked by selecting at random various bits from all existing coding conventions in the hope that that would make everyone happy. They are a horrible mash of things. The indenting style is horrible, for example, and only works if you have your editor set up in exactly the same way as RMS; mixing tabs and spaces for indenting is one of the most stupid ideas I've ever seen. The convention of putting a space after function names and before the open bracket makes code harder to read because it makes it difficult to tell without reading the context that something is an argument list rather than a subexpression. In fact, almost everything about the GNU coding conventions looks painfully stupid to anyone with a basic understanding of how the human visual system works, but as an official GNU project we are stuck with it. I didn't know you have to stick to the GNU coding guidelines if you are an official GNU project. Now I understand all the people complaining about gcc being unreadable... Just to clarify for the non-developers, GCC being unreadable is a completely different problem, not particularly due to the coding style. ;-) Having a standard coding style for the whole GNUstep project is really important as it makes it easier to copy/move code from one part of the project to the other. Using a standard coding style that is documented and used by many other projects is also good as contributors will be immediately familiar with it. The GNU coding standards are used by a large number of projects with a lot of contributors and popularity so can't really be blamed if GNUstep is less popular than, say, GIMP (which also happens to follow the GNU coding standards) or any of the other million projects that use the GNU coding standards or some variants of them. While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. If it's a burning issue for many developers, I guess changing the coding style to something else could be discussed. There would be *lots* of reformatting to do if we ever reach an agreement on some other coding style. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 09, 2009 at 12:52:34AM +0200, Riccardo Mottola wrote: Hi, Well, having just glanced at a few docs, depending upon the desired level of compatibility, the approach outlined above seems reasonable. Most underline styles seem to have appeared with OSX 10.3 - i.e. the following: The real problem is not if it is dotted or continuous the problem is stopping for example the line between words or even around glyphs. Which is why I suggested initially only implementing Rhapsody compatibility here, since it did not support skipping the underlying of whitespace. This would at least provide _some_ underlying, and the 'problem' could be tacked later. .pdf ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 13:03, Felix Holmgren wrote: While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. Given that part of the aim of GNUstep is to track Cocoa, might it not make sense to use the Apple coding guidelines for everything that's written in Objective-C? http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html Those guidelines ARE pretty much consistently used in GNUstep. The coding style issues we are probably talking about here are those to do with the use of: indentation brackets white-space Generally, whenever someone comes along and complains about the style used, they have their own 'good reasons' why their style is preferred/ justified. Certainly, when I started working on the GNUstep project, my style was very different from the GNU style, and I could have provided reasons why my style was better :-) None of those arguments carry any weight whatsoever ... because there are always plenty of people with other preferred styles and their own reasons for using them. We use the GNU style almost solely because of the value of consistency (the fact that we are a GNU project probably explains why it was originally chosen) ... once you are used to it, you can work on any part of the code without finding the style hard to read. While there are a few 'religious' people who are convinced that everyone else should adopt their style, almost everyone accepts that a consistent standard is useful and that any attempt to change the style, once adopted, would be severely counterproductive. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi! While I think the wiki is a good idea, it's not a substitute for an official project page, which needs to say: - This project is alive. - This project is shiny. - This project is actively used by some people. I'm with you there :) As much as I love GNUstep base, I do not like GNUstep gui. Don't get me wrong, I still burst in tears of agony if I have to use another GUI library than GNUstep gui, because everyone still treats GUI as code, even C# and WindowsForms. GNUstep gui still lacks in polishing. Using a graphical GNUstep application on Gnome/KDE/Xfce ist still a pain because: I don't completely disagree here. I think -gui has improved a huge amount in the last year, mostly due to Fred's work. Nicolas, Fred and Quentin worked a bit on live resizing at the Étoilé hackathon, which makes things look a lot more modern. Things are still slower than they should be and we need to do some profiling to work out why that is. Currently I don't work that much with gui, all I need is a window with an OpenGL context and in some cases an additional window with some settings. I am still using the art backend as I had issues with cairo (window and contents didn't display correctly, black polygons all over the place), but I am still using Ubuntu 8.04, so maybe the cairo package is rather outdated. What comes to my mind regarding GNUstep applications is that for a long time now my perception is that Gorm is the only serious GNUstep application. It works, it does it's job and it is maintained. No other GNUstep application fulfilling those criteria comes to my mind. There are also some plainly embarrassing bugs, like the fact that underlining still doesn't work. Much of the text system code is in need of an overhaul, because it's currently a mess of premature optimisation that none of the current developers actually understands. Ouch. Another issue is code quality. For example, the code in GNUstep back is one hell of an ugly mess. I had to touch it, but I felt a chill running down my spine in doing so. Everything in XGServerEvent and associates looks like a mass of hacks piled on top of each other. It's such a chaos, I do not want to touch it anymore in fear of breaking somthing completely unrelated. Back also frightens me. At the hackathon, I talked to Fred a bit about refactoring it so that, long term, all that -back will do is create drawing contexts and handle events. We will then use a CoreGraphics implementation, probably based on Opal (which was just copyright assigned to GNUstep, I believe) to handle drawing using Cairo. This would let us use the same drawing code on X11, Win32 and on any of the other platforms Cairo supports (e.g. Zeta, OS/2, DirectFB), with just a small amount of new code for turning the platform's native events into NSEvents and for calling the cairo functions for creating graphics contexts. Sounds reasonable :) Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. Completely agree. Good coding conventions are picked because they make things that are wrong look wrong or generate compiler errors / warnings. The GNU coding conventions were picked by selecting at random various bits from all existing coding conventions in the hope that that would make everyone happy. They are a horrible mash of things. The indenting style is horrible, for example, and only works if you have your editor set up in exactly the same way as RMS; mixing tabs and spaces for indenting is one of the most stupid ideas I've ever seen. The convention of putting a space after function names and before the open bracket makes code harder to read because it makes it difficult to tell without reading the context that something is an argument list rather than a subexpression. In fact, almost everything about the GNU coding conventions looks painfully stupid to anyone with a basic understanding of how the human visual system works, but as an official GNU project we are stuck with it. I didn't know you have to stick to the GNU coding guidelines if you are an official GNU project. Now I understand all the people complaining about gcc being unreadable... 3) Improve our ability to market ourselves in general. Yep. IMHO Distributed Objects alone is one hell of a feature, making it worth to use Foundation just because of that. Yup, DBUS is a horribly hacky clone of DO and people seem to get excited about it. DO could be a killer feature, if more people were aware of it. I do love Foundation because it provides me with a lot of stuff which I need every day. I do not have to care about strings, I do not have to care about file management, all the containers are pretty
Re: Changes I've been thinking of...
Well as I really new GNUstep user, at least for the last week :) I will try to put my two cents here: As a new user I ahve to say I have been trying to use GNUstep for a while but two weeks ago I found the time to compile and install everything. So for a new user is not easy to get GNUstep, there are tw problems: - Distributions don't have a good support, I am usign fedora and I have to built everything from scratch no packages at all. - The webstie is old, it doesn't give you the information to get the proper packages and give you a clear idea of waht is the best process and understand how GNUstep works and should be installed, I found this document, is a bit old but more useful than the docs in the web: http://gnustep.made-it.com/BuildGuide/index.html#BUILDING.GNUSTEP About what gnustep need, I a magree with the people that thinks it really need applications. Themes are good, but apps are more important, first a good development environment needs good apps so people thinks this is a good one. So I think affort should be directed to get a good set of tools to have a good working environment. Why Etoile and gnustep? I think that know etoile and gnustep should be working together in the same project, so you guys can provide a global computing environment, like Mac basically. This is the development environment. This is the working environment. And finally here are some core applications. That the things people needs. The development environmetn seems to be there (I haven't develop nothing using gnustep), the working environment is pretty just some polish and some updates, like haveing the owrkspace in a menubar (at least as an option) like in the mac, the current toolchest model is a little bit old I think, things like that. But the area that needs more work is some core apps, really good core apps. Is the formula used by Ubuntu, they give you some apps, not too much as many other distros used to do, only some the most useful but really good. What can be put as core apps is probably another discussion. Onece gnustep has some core apps I think the next step is the theming thing to make the whole environment more good looking and modern (althogh I still prefer the old NExT look), and the intalling and packaging. An install process for every platform, somebody probably remember the gnome version launched by Ximian some time ago. You can go to the Ximian'swebsite and download an install script with gui that automates the whole process of installing gnome from the sources. And in the other hand ease the packaging process for distros. Finally is the marketing thing. I think there is no point toi spend time in marketing and good looking website whereas there aren't good apps, people probably is going to try gnustep but withouta good and complete working environment peoplr will give up, but in the time there is a good working environment istime to show and maket it like crazy.; My two cents. PD: I am still trying to get a complete gnustep working desktop, I haven't gave up yet :) 2009/10/7 Gregory Casamento greg.casame...@gmail.com Guys, There are a number of things which need to change on the project: We need to: 1) improve our website. It's been the same for years and doesn't reflect our progress. 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, I believe it's one way for us to spark interest in the project is to update it's look. The current look should always be available, but not necessarily the default. 3) Improve our ability to market ourselves in general. One thing that GNUstep has been lacking in is marketing. I've been trying to improve things on that front, but I'm not the best marketer to say the very least. Does anyone have any questions or comments regarding this? I would like to hear any and all input people have. Later, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Un saludo Best Regards Pablo Giménez ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 2009-10-08 02:08:35 +0200 Riccardo Mottola mul...@ngi.it wrote:
Hi all,
I have not had much time to look at GNUMail, but I just set the
delegat to nil in the controllers to avoid the crashes when the
toolbar is trying to dealloc.
I have attached the diff to this mail - but I guess someone (Ludovic)
should really review it since I am really not a top coder (just want
to fix things when they are broken).
Hope it helps,
Tim
delegatenil.patch
Hi,
Philippe Roussel wrote:
For me, the one thing that really lowers GNUstep credibility is the
super high 'bitrot factor' : a lot of the software found in the wiki
is outdated, or it's website disappeared, or it won't compile or it's
almost useless. Building the core librairies is good (thanks guys !)
but we need a good set of working applications, easily found and
easily built.
Trgives the user a terrible impression.
One example I ran recently is AddressManager and the VCFViewer
inspector. There is one version in GAP, one version in Etoile. One
version of VCFViewer in AddressManager tree and one in GWorkspace
website and wiki page.
I the official Addresses, Bjoern donated it to us.
GAP has become a kitchen-sink for apps not loved by their owners
anymore... I
try my best to keep them going and added in the last years several
applications!
When a core developer like Enrico leaves, it leaves a lot of stuff...
I don't
think everybody realized how much Enrico did for GNUstep. With the
releases,
the wiki pages will be corrected, etc etc. We're gettign there, just
slowly.
You yourself are helping me out lately!
There are multiple terminal applications (gap, backbone, etoile ?)
but
none really usable (to my knowledge, maybe I missed something).
ThI use it every single day! It may miss some features but works. ANd
I
assume backbone's does too, the code bae is essentially the same, but
the
philosophies about releases, makefiles etc. differ.
There is Preferences and SystemPreferences.
Itwindows too... SystemPreferences is from Enrico, it is Apple
compatible.
Preference's is more limited in the UI, has different modules but
looks
better :)
GNUMail doesn't work for me and seems stalled.
Thmade a partial patch... but it is left there. He can tell us the
details.
But furthermore Ludovic should accept the patch, commit and make a
new beta
tarball.
What I'm trying to say is that I think we should try to centralize
things (one repository for all !) and work on a set of defined
applications instead of collecting random stuff.
Ththe gnustep main site.
One last thing about stable/unstable : the website frontpage
advertize
gnustep startup 0.23.0 as a stable release with make 2.2.0, base
1.19.1,
gui 0.17.0 and back 0.17.0.
In the download page, stable startup version is 0.22.0 and unstable
0.19.3. Stable base is 1.18.0 which for me means that base 1.19.1
included in startup 0.23.0 is not stable. Same thing for gui and
back.
Question is : what should I download ?!
Our downloads are terribly confusing!
I hope this doesn't sound too negative, really. I really like GNUstep
and wish to use a GNUstep desktop one day :o).
It is honest, which is what counts.
Riccardo
___
Discuss-gnustep mailing list
discuss-gnus...@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
diff -rupN GNUMail/Framework/GNUMail/EditWindowController.m GNUMail.tk/Framework/GNUMail/EditWindowController.m
--- GNUMail/Framework/GNUMail/EditWindowController.m 2007-04-23 10:04:51.0 +0200
+++ GNUMail.tk/Framework/GNUMail/EditWindowController.m 2009-08-22 22:06:04.0 +0200
@@ -364,7 +364,7 @@
- (void) dealloc
{
NSDebugLog(@EditWindowController: -dealloc);
-
+ [[self window] setDelegate:nil];
[[NSNotificationCenter defaultCenter] removeObserver: self];
#ifdef MACOSX
diff -rupN GNUMail/Framework/GNUMail/MailWindowController.m GNUMail.tk/Framework/GNUMail/MailWindowController.m
--- GNUMail/Framework/GNUMail/MailWindowController.m 2007-04-09 10:03:46.0 +0200
+++ GNUMail.tk/Framework/GNUMail/MailWindowController.m 2009-08-25 16:17:24.0 +0200
@@ -310,7 +310,7 @@
- (void) dealloc
{
NSDebugLog(@MailWindowController: -dealloc);
-
+ [[self window] setDelegate: nil];
[[NSNotificationCenter defaultCenter]
removeObserver: mailHeaderCell
name: @NSViewFrameDidChangeNotification
diff -rupN GNUMail/Framework/GNUMail/MessageViewWindowController.m GNUMail.tk/Framework/GNUMail/MessageViewWindowController.m
--- GNUMail/Framework/GNUMail/MessageViewWindowController.m 2007-03-12 10:03:42.0 +0100
+++ GNUMail.tk/Framework/GNUMail/MessageViewWindowController.m 2009-08-22 22:05:13.0 +0200
@@ -129,7 +129,7 @@
- (void) dealloc
{
NSDebugLog(@MessageViewWindowController: dealloc called for message window: %@, [message subject]);
-
+ [[self window] setDelegate: nil];
[[NSNotificationCenter defaultCenter] removeObserver: mailHeaderCell
Re: Changes I've been thinking of...
100% agree 2009/10/9 Sergii Stoian stoyan...@gmail.com Hi, Gregory. Hi, guys. I can't resist expressing my opinion on GNUstep changes as I see it. I've defined several problem areas of GNUstep: 1. Maturity of GNUstep code for developers (functionality, docs, stability) 2. GUI appearance 3. Portability 4. Applications Gregory, behind all things you've mentioned I see a goal that can be expressed by the following phrase: World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment. Do you really think that improving website, theme (argh!) lead us to rise of user attention to GNUstep? I don't think so. I see a lot of people comparing GNUstep with GNOME/KDE (What's Etoile? Another desktop environment? Why we should use it?). IMHO it's not our target audience. In my strong opinion our target audience could be: - NeXTSTEP/OPENSTEP users who misses NS/OS look, feel and user experience in general (I'm one of them); - developers who knows what OpenStep and Cocoa are; - technical people who loves WindowMaker; - researchers, students who can use GNUstep as basement for it's works. In my opinion GNUstep project needs more forcible approach to reach the goal I've phrased above. I propose to discuss the following approach: 1. Select reference platform for GNUstep development. Make GNUstep work ideally on one platform and then port it to another. My choice is FreeBSD (Xorg 7.4, ART GUI backend) despite the fact that I'm Linux user for over 13 years. I have set of strong reasons for this, we can discuss it later. 2. Stop chasing MacOS functionality. Let's set our target to for example MacOS 10.5 for a several years. In other words - polish and finish current implementation. 3. Stop trying to work everywhere. Let's make it working good at one place, then go to another. Let's speak frankly - we can't compete with Qt. Despite the existing of DO, Objective-C and other great things. 4. Make work good ONE FINISHED gui backend on reference platform with all needed functionality (OpenGL, Fonts, Graphics). 5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts, graphics to name a few. 6. Create working destop environment for developers at least. Some day I realized that I'm working inside mess of not interacting things. My plan is: - Create Login application - Create Preferences - Create Workspace Manager (Workspace + WindowMaker), excellent integration of GNUstep with it (focus, app management, dock interaction). - Create Terminal application based on Alex Malmberg application. - Create Mail application (GNUmail can be used as starting point). - Finish ProjectCenter (anyway it's my responsibility). 7. Make it clean, fast and simple as NS/OS. Personally I'm tired of bloated desktop environments (KDE/GNOME). I want improved (at reasonable degree) OPENSTEP. It's not a plan targeting on world domination. It's plan to make comfortable development environment as I see it. And if it will be comfortable to me it can be useful to somebody else. Summarizing this long email: we should focus on achievable goals by narrowing down portability and loosing competition with MacOS for now. Let's agree on strong, clean, simple vision of project future and users will come. On Wed, 07 Oct 2009 22:24:01 +0300, Gregory Casamento greg.casame...@gmail.com wrote: Guys, There are a number of things which need to change on the project: We need to: 1) improve our website. It's been the same for years and doesn't reflect our progress. 2) improve GNUstep's default theme as well as theming in general. While I know some people will respond negatively to changing the default theme from a NeXT-like look to something more modern, I believe it's one way for us to spark interest in the project is to update it's look. The current look should always be available, but not necessarily the default. 3) Improve our ability to market ourselves in general. One thing that GNUstep has been lacking in is marketing. I've been trying to improve things on that front, but I'm not the best marketer to say the very least. Does anyone have any questions or comments regarding this? I would like to hear any and all input people have. Later, GC -- Sergii Stoian ___ Discuss-gnustep mailing list discuss-gnus...@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep -- Un saludo Best Regards Pablo Giménez ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. Given that part of the aim of GNUstep is to track Cocoa, might it not make sense to use the Apple coding guidelines for everything that's written in Objective-C? http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/CodingGuidelines/CodingGuidelines.html /F ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Am 09.10.2009 um 11:27 schrieb Sergii Stoian: World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment. Now I can't resist to comment either ;-) Platforms aren't just a set of kernel and appropriate drivers these days, they are full functioning desktops already. So, while an alternative to Xfce / KDE / Gnome might be desireable for some people, the very most open source OS users won't bother on GNUstep applications if they don't fit into their preferred desktop environment. As a Ubuntu user I can seamlessly install (packaged) KDE apps and use them next to Gnome apps. The same should be true for GNUstep apps. Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. Strongly preferring WindowMaker is plain counter productive. Insisting on a own clipboard system will do nothing but confuse users. Those dock- like miniwindows are simply annoying (for Gnome users). Command line stuff is - well many users don't know what a command line is, after all. Integration with the neighbor's desktop is the state of the art. Even the biggies like KDE or Gnome can't afford to ignore the others. Markus P.S.: Currently I'm using Cocotron. Much less matured, but integrates much better. Braindead simple porting from Cocoa, standalone applications ! P.P.S.: Sorry for ranting so much. I just wanted to add another perspective. - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
See below... On Fri, Oct 9, 2009 at 11:06 AM, Markus Hitter m...@jump-ing.de wrote: Am 09.10.2009 um 11:27 schrieb Sergii Stoian: World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment. Now I can't resist to comment either ;-) Platforms aren't just a set of kernel and appropriate drivers these days, they are full functioning desktops already. So, while an alternative to Xfce / KDE / Gnome might be desireable for some people, the very most open source OS users won't bother on GNUstep applications if they don't fit into their preferred desktop environment. As a Ubuntu user I can seamlessly install (packaged) KDE apps and use them next to Gnome apps. The same should be true for GNUstep apps. Absolutely agreed. Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. Strongly preferring WindowMaker is plain counter productive. I believe we need to start integrating better with other desktops/window managers. Insisting on a own clipboard system will do nothing but confuse users. The unfortunate truth here is that there are still some features of the other guys pasteboard servers which don't server our needs at all. Those dock-like miniwindows are simply annoying (for Gnome users). You can turn them off. Command line stuff is - well many users don't know what a command line is, after all. ?? I'm not sure what you mean here. Integration with the neighbor's desktop is the state of the art. Even the biggies like KDE or Gnome can't afford to ignore the others. Indeed. Markus P.S.: Currently I'm using Cocotron. Much less matured, but integrates much better. Braindead simple porting from Cocoa, standalone applications ! I'm sorry to hear this. GNUstep, in my opinion, does need something similar to Cocotron's SDK. Dr. Schaller has already made something similar for ARM so that he can cross compile for the ARM platform so it's not terribly difficult... it's just not something we've done for Windows yet. P.P.S.: Sorry for ranting so much. I just wanted to add another perspective. That's fine. - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On 9 Oct 2009, at 16:34, Gregory Casamento wrote: I'm sorry to hear this. GNUstep, in my opinion, does need something similar to Cocotron's SDK. Dr. Schaller has already made something similar for ARM so that he can cross compile for the ARM platform so it's not terribly difficult... it's just not something we've done for Windows yet. Apple, unfortunately, branched clang for XCode 3.2 just before I put a lot of fixes in. Their next release, however, will include a version of clang that can target the GNU runtime properly. To cross-compile for Windows / Linux / whatever you will just need copies of the relevant headers and to set the include paths and target triple correctly, so we can probably provide a plugin that does that quite easily. That said, if you use svn or some other version control system from XCode, then it's trivial to automate building on a native platform already with GNUstep; just check out your svn repository and run pbxbuild; put this in an hourly cron job in a VM or a real machine, and you've got an automated build. David -- Sent from my PDP-11 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, 09 Oct 2009 18:06:45 +0300, Markus Hitter m...@jump-ing.de wrote: Am 09.10.2009 um 11:27 schrieb Sergii Stoian: World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment. Now I can't resist to comment either ;-) Platforms aren't just a set of kernel and appropriate drivers these days, they are full functioning desktops already. So, while an alternative to Xfce / KDE / Gnome might be desireable for some people, the very most open source OS users won't bother on GNUstep applications if they don't fit into their preferred desktop environment. Markus, why do you think that users of Xfce/KDE/GNOME should bother on GNUstep applications at all? I guess user first tries to find app that is native to it's DE. Second he looks for neighbor variants. If you want GNUstep apps to fit into Xfce/KDE/GNOME then you need to change not only look (scrollbars, menu style, etc.) but also FEEL of applications. Generally speaking, GNUstep application should look and feel as user's preferred desktop application. Finally it leads to bloating of code and problems with maintenance (considering our developer resources). Does GNUstep applications should look feel as Qt and GTK+ apps? This is a dead end for GNUstep project I guess. As a Ubuntu user I can seamlessly install (packaged) KDE apps and use them next to Gnome apps. The same should be true for GNUstep apps. Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. And browsers, file managers, IDEs, mail clients, editors... That's what I'm trying to say about. There will be no charm in such approach. NS/OS has charm even today I think. Strongly preferring WindowMaker is plain counter productive. Using GNUstep applications in, for example, GNOME is stupid. I see no sense in using 'TextEdit' instead of 'gedit' and so on. Sorry, It's not an argument. I see WindowMaker as: 1. part of Workspace Manager 2. reference window manager for GNUstep applications. Insisting on a own clipboard system will do nothing but confuse users. Those dock-like miniwindows are simply annoying (for Gnome users). Command line stuff is - well many users don't know what a command line is, after all. Integration with the neighbor's desktop is the state of the art. Even the biggies like KDE or Gnome can't afford to ignore the others. GNOME and KDE has similar point of view on how desktop should be organized. NS/OS has different philosophy. It's not only about lookfeel. Markus P.S.: Currently I'm using Cocotron. Much less matured, but integrates much better. Braindead simple porting from Cocoa, standalone applications ! P.P.S.: Sorry for ranting so much. I just wanted to add another perspective. I guess everybody agreed that this is not dispute - it's exchange of opinions. -- Sergii Stoian ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Stef, This does seem to be the consensus Now we need help to actually make it happen. GC On Thu, Oct 8, 2009 at 7:30 PM, Stef Bidi stefanb...@gmail.com wrote: Forgot to reply to all! On Thu, Oct 8, 2009 at 10:45 AM, Nicola Pero nicola.p...@meta-innovation.com wrote: It would undoubtedly be good to have some packager-specific documentation, but obviously the target readership is a very small group We *do* have packager documentation, in core/make/README.Packaging Feel free to add a short section about what was discussed here. :-) I saw Richard committed something there. This is really the first time I've ever heard of GlobalDomain.plist, and will not forget it. - How does this allow a packager to install and remove defaults as part of package installation / uninstallation? Presumably you can use plmerge to install them (again, is this documented anywhere?), but how do you uninstall them? I agree with Richard's later suggestion that the package system might deal with that by having a directory where each package installs a .plist upon installation, and removes it upon deinstallation. At the end of each package installation/deinstallation, the package scripts could do a plmerge so that all the currently existing .plists in the directory are plmerged to create the global default plist, which is hence kept up-to-date. :-) That said, it should probably be used with restrain ;-) Presumably you have a specific example in mind where it makes particular sense (Etoile ?); but in general, I personally don't see a reason why installing a package should change some system defaults. Installing a package doesn't necessarily mean enabling it. Eg, I could be installing 10 or 20 themes or other GNUstep GUI-changing bundles, but that doesn't mean every theme that is installed must be trying to force all users to switch to it. I'd expect to have a Preferences panel somewhere where I can change my own user defaults and activate/deactivate the bundles or themes I want/don't want. Different users might activate/deactivate different bundles. I agree with you, but the packager/distribution developers need to know what they want. For example, in Debian when I install gnome-core I get nothing but a plain GNOME desktop with no theming (default GTK theme), but when I install gnome I also get a few themes and theme engines installed but only 1 is sets Clearlook as the default theme. If the themes are installed separately (outside the gnome package) nothing happens, they're just installed and it's up to you to do something. Similarly, a gnustep package might want to install some core packages and an etoile package install Camaleon and it's themes and set 1 of them as default, setup horizontal menus, etc. So I think it is more important to have a very good preference application that allow real users to configure their environment to suit their needs, including turning on/off bundles or extensions. :-) Thanks By the way, is anyone keeping notes so that this won't all disappear after the discussion dies down? What I've gotten so far is: * Seems to be a consensus in keep GNUstep with it's default theme. GlobalDomain.plist allows packagers or distributions to global define their theme if it pleases them. * Everyone seems to want a new website. Content needs to be looked over because there is a lot of old and outdated information out there confusing newcomers. ** On the same topic, people also seem to be getting detracted by the decentralized information about GNUstep. * Packages, packages, packages. Last I heard we lost the person who did the packages for the Debian project (which is really bad). I've also been slacking on the Slackware packages (lack of time and a dedicated play computer). * Code beautification? Anything I missed so far? Stefan ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Sergii, please see below. Am 09.10.2009 um 17:34 schrieb Gregory Casamento: Command line stuff is - well many users don't know what a command line is, after all. ?? I'm not sure what you mean here. Well, malfunctions in GNUstep are often answered by a few text commands which fix things. For example, Wolfgang Lux explained just yesterday how to fix services in Terminal.app. While Terminal.app is a special case in this regard, you can't expect users to fix things by typing commands in a shell. Things are either figured by the app without user interaction (preferred), or need a GUI. Am 09.10.2009 um 18:15 schrieb Sergii Stoian: Markus, why do you think that users of Xfce/KDE/GNOME should bother on GNUstep applications at all? Because quite a few nice applications are written in GNUstep. Think about GNUmail, it has just the right design for users used to Apple Mail. Think about TextEdit, which roughly matches Apple's TextEdit and can (well, should be able to) handle the RTF format. Think about all those Cocoa apps out there just waiting to be ported to Linux or *BSD. There are plenty. If you want GNUstep apps to fit into Xfce/KDE/GNOME then you need to change not only look (scrollbars, menu style, etc.) but also FEEL of applications. For now I think it would be a big step forward if GNUstep wouldn't conflict with other desktops. If the dock-like miniwindows can be turned off, please do so by default in a Gnome or KDE environment. For the window containing the menu, respect the bars on top and on bottom of the screen. If the current desktop has scroll bars on the right, put them there in GNUstep apps as well. Does GNUstep applications should look feel as Qt and GTK+ apps? There's no need to give up on the traditional behaviour for those prefering it. Using GNUstep applications in, for example, GNOME is stupid. Ouch. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero nicola.p...@meta-innovation.com wrote: Additionally I really dislike the coding style, not because it's not mine, but because it fails to make the code more readable. On the other hand, there was code by Fred which looked really ok, so maybe it's just about using the coding style in a sane way All I wanted to say is, that it's not that easy to start hacking inside the GNUstep core libraries. Completely agree. Good coding conventions are picked because they make things that are wrong look wrong or generate compiler errors / warnings. The GNU coding conventions were picked by selecting at random various bits from all existing coding conventions in the hope that that would make everyone happy. They are a horrible mash of things. The indenting style is horrible, for example, and only works if you have your editor set up in exactly the same way as RMS; mixing tabs and spaces for indenting is one of the most stupid ideas I've ever seen. The convention of putting a space after function names and before the open bracket makes code harder to read because it makes it difficult to tell without reading the context that something is an argument list rather than a subexpression. In fact, almost everything about the GNU coding conventions looks painfully stupid to anyone with a basic understanding of how the human visual system works, but as an official GNU project we are stuck with it. I didn't know you have to stick to the GNU coding guidelines if you are an official GNU project. Now I understand all the people complaining about gcc being unreadable... Just to clarify for the non-developers, GCC being unreadable is a completely different problem, not particularly due to the coding style. ;-) Having a standard coding style for the whole GNUstep project is really important as it makes it easier to copy/move code from one part of the project to the other. Using a standard coding style that is documented and used by many other projects is also good as contributors will be immediately familiar with it. The GNU coding standards are used by a large number of projects with a lot of contributors and popularity so can't really be blamed if GNUstep is less popular than, say, GIMP (which also happens to follow the GNU coding standards) or any of the other million projects that use the GNU coding standards or some variants of them. While I sympathize with David who prefers (or is used) to some other coding style, the GNUstep project needs a consistent coding style and the GNU coding standard are as good a choice as any. Since GNUstep is a GNU project, it's a natural choice. By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... If it's a burning issue for many developers, I guess changing the coding style to something else could be discussed. There would be *lots* of reformatting to do if we ever reach an agreement on some other coding style. ;-) consider me on fire then, the reformatting is no issue for me, since I generally reformat the code i'm looking at anyways then I fix whatever i'm doing, and to send a patch to GNUstep do a clean checkout then uglify my code to fit the GNUstep style... I did a quick google code search on some random method and counted up how the arguments were formatted 92: with space between colon and argument 265: without space between colon and argument not really a scientific study of developer preference... (considering some of my code showed up in the with-space list which i can't stand), there is also bound to be duplicates of code between different versions of the same software... so if you're going to insist on one true whitespace, don't insist on one only a minority of developers use, or people are bound to complain, and call the gnustep code ugly. so just in case i haven't made my stance on the subject clear, I'd have to Ditto what icicle and David are saying. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Le 9 oct. 2009 à 20:48, Matt Rice a écrit : On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero nicola.p...@meta-innovation.com wrote: By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... Well it's possible to argue in the opposite way :-) The first version is more readable than the second, because it's very easy to spot each 'colon + white space' combination. Then you know the left part is a method keyword and the right part is the argument. In the second case, 'colons' without white space seems slower to find because they are lost in the middle of other characters. The first version is also closer to the spirit of Smalltalk, in the sense the punctuation related spacing is similar to a real sentence. imo Smalltalk code with this spacing style is clearer than Smalltalk code without a space between each method keyword and argument pair. This point is less important in Objective-C given the whole language syntax is far less clean (C syntax + brackets everywhere). But it still matters a bit I think. I agree I'm getting really subjective here :-) Cheers, Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
On Fri, Oct 9, 2009 at 12:51 PM, Quentin Mathé qma...@gmail.com wrote: Le 9 oct. 2009 à 20:48, Matt Rice a écrit : On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero nicola.p...@meta-innovation.com wrote: By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... Well it's possible to argue in the opposite way :-) The first version is more readable than the second, because it's very easy to spot each 'colon + white space' combination. Then you know the left part is a method keyword and the right part is the argument. In the second case, 'colons' without white space seems slower to find because they are lost in the middle of other characters. The first version is also closer to the spirit of Smalltalk, in the sense the punctuation related spacing is similar to a real sentence. imo Smalltalk code with this spacing style is clearer than Smalltalk code without a space between each method keyword and argument pair. This point is less important in Objective-C given the whole language syntax is far less clean (C syntax + brackets everywhere). But it still matters a bit I think. I agree I'm getting really subjective here :-) of course... each language is different in scheme (+(+ 1 2) 3) looks horrible compared to (+ (+ 1 2) 3) I'm assuming that RMS being a lisp programmer, this must be the reason why the GNU coding standards do it this way, but that doesn't make it right for objective-c. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Am 09.10.2009 um 20:23 schrieb David Chisnall: On 9 Oct 2009, at 19:19, Gregory Casamento wrote: Well, yeah... I do know about pbxbuild since I helped develop it. The point is that the majority of mac devs expect things to be done completely from the mac. My point was that this is something we could automate pretty trivially. I managed to get Darwine building (but not running) Windows versions of GNUstep apps, and it would be pretty simple to package up a virtual appliance that people could open with VirtualBox on their Mac and just point at an svn repository and get automated builds. Same with Darwine; we could package up a .wine directory containing GNUstep with this. Does this mean GNUstep cross-development can be done from within Xcode already or do you want to use Darwine to run ProjectCenter/Gorm for development? For the later, I fear this isn't exactly what developers mean with completely on the Mac. An ability to run/debug GNUstep/Windows executables on the Mac would be a nice addition, though. Markus - - - - - - - - - - - - - - - - - - - Dipl. Ing. Markus Hitter http://www.jump-ing.de/ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey, I think you have many good points there. However, GNUstep is a wide project and targets many different users. Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. 1. Maturity of GNUstep code for developers (functionality, docs, stability) 2. GUI appearance 3. Portability 4. Applications Gregory, behind all things you've mentioned I see a goal that can be expressed by the following phrase: World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment. This statement is true, though, do you agree? The problem is that it is reductive, but I think it is true. GNUstep is perhaps more. Do you really think that improving website, theme (argh!) lead us to rise of user attention to GNUstep? I don't think so. I see a lot of people comparing GNUstep with GNOME/KDE (What's I think so. We may argue about theming, but a good, informative and usable website is really useful! 3. Stop trying to work everywhere. Let's make it working good at one place, then go to another. Let's speak frankly - we can't compete with Qt. Despite the existing of DO, Objective-C and other great things. I disagree here. Being portable is a big asset and we can do that! 5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts, graphics to name a few. Agreed... 6. Create working destop environment for developers at least. Some day I realized that I'm working inside mess of not interacting things. My plan is: - Create Login application working on that, check GAP - Create Preferences what's wrong with SystemPreferences? Recently also GWorkspace's indexing panel got fixed. - Create Workspace Manager (Workspace + WindowMaker), excellent integration of GNUstep with it (focus, app management, dock interaction). That's fine, but I'd put it lower priority. I care that we need to work well with other windowmanagers too. The best I see medium term is to enable/disable duplicate components and create a gnsutep-based configuration tool - Create Terminal application based on Alex Malmberg application. it can be improved indeed. It works well, but I miss some features. ON the todo list. - Create Mail application (GNUmail can be used as starting point). This is a sensible point. GNUmail is unmaintained sadly. Also in some sense it is too much having features here and there, while it lacks certain things i'd like. - Finish ProjectCenter (anyway it's my responsibility). Oh I hope that! I want to be able to maintain most projects in GAP with PC. You knwo I am a long-time PC user. Before even you started maintaining it... 7. Make it clean, fast and simple as NS/OS. Personally I'm tired of bloated desktop environments (KDE/GNOME). I want improved (at reasonable degree) OPENSTEP. Totally agreed! Even Mac is not clean anymore. I'd like something along mac 10.2/10.3 in terms of features, but with a more consistent, less shiny interface, more NeXTstep... It's not a plan targeting on world domination. It's plan to make comfortable development environment as I see it. And if it will be comfortable to me it can be useful to somebody else. Sure, it needs to be somethign useful and clean. I don't want to aim at GNOME or KDE; but something along the line of Xfce. Summarizing this long email: we should focus on achievable goals by narrowing down portability and loosing competition with MacOS for now. Let's agree on strong, clean, simple vision of project future and users will come. Agreed. We need both users and developers. But I can also tell you that most development in the past 2 years was good. GNUstep improved (much more than it broke). But a bit too little unfortunately in some areas and thus they are unfinished... Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hey, Gregory Casamento wrote: Accordingly, work on e.g. a GNUstep terminal app is pointless, as there are two dozen other terminal apps out there already. Strongly preferring WindowMaker is plain counter productive. I believe we need to start integrating better with other desktops/window managers. Maybe, But from my point of view we need to integrate better with Windowmaker itself! If I have focus problems, windows ordering problems, event problems, window and menu placement problems with WIndowMaker, then it is really crap!! Insisting on a own clipboard system will do nothing but confuse users. The unfortunate truth here is that there are still some features of the other guys pasteboard servers which don't server our needs at all. TO each one its ow. We can have ours :) Those dock-like miniwindows are simply annoying (for Gnome users). You can turn them off. Well, SystemPreferences has a convenient panel for defaults. If only people would install and use it... I don't know Ubuntu, but debian doesn't ship it. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
Hi, Riccardo. 2009/10/9 Riccardo Mottola mul...@ngi.it Hey, I think you have many good points there. However, GNUstep is a wide project and targets many different users. Many things you want do not clash with other goals, they only divert manpower. But keep in consideration that in an opensource project people do whatever they deem interesting or useful, there isn't a central planning. Sure, you're right! I'm start thinking that fork of gui+back for some period of time is not such silly thing... 1. Maturity of GNUstep code for developers (functionality, docs, stability) 2. GUI appearance 3. Portability 4. Applications Gregory, behind all things you've mentioned I see a goal that can be expressed by the following phrase: World (all stuff outside of GNUstep) acceptance of GNUstep as alternative developer framework that will help creating of alternative desktop environment. This statement is true, though, do you agree? The problem is that it is reductive, but I think it is true. GNUstep is perhaps more. Sure, I agree! Considering the statement above making 'modern' themes, integrating apps into foreign DE is not the first thing we should focus on. Do you really think that improving website, theme (argh!) lead us to rise of user attention to GNUstep? I don't think so. I see a lot of people comparing GNUstep with GNOME/KDE (What's I think so. We may argue about theming, but a good, informative and usable website is really useful! 3. Stop trying to work everywhere. Let's make it working good at one place, then go to another. Let's speak frankly - we can't compete with Qt. Despite the existing of DO, Objective-C and other great things. I disagree here. Being portable is a big asset and we can do that! Sure it's great asset for mature project. The problem is in spreading the efforts of developers, code becomes hard to read... and code is not become more mature then before. 5. Finish gnustep-gui as it is. Problem areas are: text subsystem, fonts, graphics to name a few. Agreed... 6. Create working destop environment for developers at least. Some day I realized that I'm working inside mess of not interacting things. My plan is: - Create Login application working on that, check GAP - Create Preferences what's wrong with SystemPreferences? Recently also GWorkspace's indexing panel got fixed. Probably I just don't like it... But it's personal, never mind. - Create Workspace Manager (Workspace + WindowMaker), excellent integration of GNUstep with it (focus, app management, dock interaction). That's fine, but I'd put it lower priority. I care that we need to work well with other windowmanagers too. The best I see medium term is to enable/disable duplicate components and create a gnsutep-based configuration tool Don't get me wrong but I don't care about support of other window managers until Window Maker support is weak. - Create Terminal application based on Alex Malmberg application. it can be improved indeed. It works well, but I miss some features. ON the todo list. - Create Mail application (GNUmail can be used as starting point). This is a sensible point. GNUmail is unmaintained sadly. Also in some sense it is too much having features here and there, while it lacks certain things i'd like. - Finish ProjectCenter (anyway it's my responsibility). Oh I hope that! I want to be able to maintain most projects in GAP with PC. You knwo I am a long-time PC user. Before even you started maintaining it... 7. Make it clean, fast and simple as NS/OS. Personally I'm tired of bloated desktop environments (KDE/GNOME). I want improved (at reasonable degree) OPENSTEP. Totally agreed! Even Mac is not clean anymore. I'd like something along mac 10.2/10.3 in terms of features, but with a more consistent, less shiny interface, more NeXTstep... I can understand people who want new modern look. But then we need designers for that. Look at the Project Center icons - they're just ugly! Keith Ohlfs is a professional designer and I'm afraid we can't create something like that. So just let's use it! It's not a plan targeting on world domination. It's plan to make comfortable development environment as I see it. And if it will be comfortable to me it can be useful to somebody else. Sure, it needs to be somethign useful and clean. I don't want to aim at GNOME or KDE; but something along the line of Xfce. Summarizing this long email: we should focus on achievable goals by narrowing down portability and loosing competition with MacOS for now. Let's agree on strong, clean, simple vision of project future and users will come. Agreed. We need both users and developers. But I can also tell you that most development in the past 2 years was good. GNUstep improved (much more than it broke). But a bit too little unfortunately in some areas and thus they are unfinished... I've never said that all
Re: Changes I've been thinking of...
I'm not a huge fan of the gnu coding standards. To me if the code is good and makes sense the formatting is secondary. On Friday, October 9, 2009, Matt Rice ratm...@gmail.com wrote: On Fri, Oct 9, 2009 at 12:51 PM, Quentin Mathé qma...@gmail.com wrote: Le 9 oct. 2009 à 20:48, Matt Rice a écrit : On Fri, Oct 9, 2009 at 1:37 AM, Nicola Pero nicola.p...@meta-innovation.com wrote: By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... Well it's possible to argue in the opposite way :-) The first version is more readable than the second, because it's very easy to spot each 'colon + white space' combination. Then you know the left part is a method keyword and the right part is the argument. In the second case, 'colons' without white space seems slower to find because they are lost in the middle of other characters. The first version is also closer to the spirit of Smalltalk, in the sense the punctuation related spacing is similar to a real sentence. imo Smalltalk code with this spacing style is clearer than Smalltalk code without a space between each method keyword and argument pair. This point is less important in Objective-C given the whole language syntax is far less clean (C syntax + brackets everywhere). But it still matters a bit I think. I agree I'm getting really subjective here :-) of course... each language is different in scheme (+(+ 1 2) 3) looks horrible compared to (+ (+ 1 2) 3) I'm assuming that RMS being a lisp programmer, this must be the reason why the GNU coding standards do it this way, but that doesn't make it right for objective-c. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
David Chisnall schrieb: IMP caching is a bit more complicated. The new runtime supports a means of invalidating IMP caches, which means that the compiler will be able to automatically insert (polymorphic) IMP caching and even speculatively inline methods. Doing this well will require profiling (I have written an LLVM pass that adds profiling information to the code, but not one that uses this information to add the caching yet). To use this in the text system, we'd want to add a set of automated test programs using a null back end that would generate profiling information for how the text system is typically used and then compile an optimised version. To be honest, I suspect that most of the places where the text system currently does IMP caching are completely irrelevant. I've been playing with implementing some of the algorithms from LaTeX in Objective-C recently, and the overhead from message sends is largely irrelevant, especially when you compare it to the overhead in drawing an antialiased glyph (although, if you're lucky, the GPU will do most of that for you). As far as I remember, the text system uses IMP caching at two places. In GSHorizontalTypesetter and in NSGlyphGenerator. These two are central parts of the layout system that need to be fast. But of course GNUstep has changed since the time these bits were written. Perhaps the three method calls that had been optimized into function calls don't make that much difference any more. At least at the time when the optimisation was done there were hard figures that suggested this to be worth while. Do you have any numbers that say so or is this just general ranting against premature optimisation? The later I support whole heartedly. There are lots of places where GNUstep is guilty of premature optimisation. Another example is that a lot of classes call NSDeallocateObject(self) rather than [super dealloc], which has a negligible performance impact but breaks any category that tries to replace NSObject's dealloc method. I never understood why we do this. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Changes I've been thinking of...
By the way the GNU coding standards are not bad, in fact I personally like them (mostly because my eyesight is really bad and whitespace is much more effective at separating tokens than brackets or commas). There are some details I'd change, but they certainly are not an unusual or weird choice for a large free software project. To me it is about separating groups of tokens, e.g. if you are going to separate like this [thing foo: arg1 bar: arg2]; and insist on including that space between the 'foo:arg1' group, the whole message send looks androgynous with parts of the selectors mixed in with their arguments... compared with [thing foo:arg1 bar:arg2]; it is very easy for me to pick out which args go with which parts of the selector, and which message is being sent... My personal preference is to do [thing foo: arg1 bar: arg2] (Note the double-space between the two parts of the selector). That way, I can easily visually tokenize it when I read it. Of course, it's my personal preference and it's as good as any. ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
