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