discuss-gnustep
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNUstep theming (was Re: Objective-C 2.0 and other new features in L


From: Gregory John Casamento
Subject: Re: GNUstep theming (was Re: Objective-C 2.0 and other new features in Leopard)
Date: Tue, 27 Nov 2007 18:41:57 -0800 (PST)

Tomaz,

> I do appreciate your position. I also appreciate that it is your call  
> to make!
> 
> However, even if some (or a lot of) people are saying that GnuStep  
> must change its look and "move forward", that does not make it either  
> the right technical decision or the right business decision. You put  
> it well in another thread yourself:
>
>> Because everyone else is doing it certainly is NOT a compelling  
>> reason. I prefer to think for myself.

Occasionally, thinking for yourself brings you to the same conclusion that 
others have reached.   Being a significant contributor to GUI and the 
maintainer or Gorm (and now the project), you can trust the fact that I do not 
make the decision to make GNUstep themable lightly because it effects both of 
these parts of GNUstep fairly heavily.   The idea behind theming is not to 
"sell out" or to give up our identity, but to make themes sort of like fonts... 
something you can just plug in and customize to your hearts content.  

I'm trying to emphasize to you that we're loosing NOTHING by doing this.

> Furthermore it does not mean that changing the appearance of GNUstep  
> will result in more people using GNUstep. Where is your business case  
> for that - what evidence do you have that this will happen? 
A number of things:

1) No less than four companies have come to me regarding porting their 
applications to GNUstep and *ALL* have complained about the look.   I won't 
give a list out because I'm assuming that these companies don't want it 
generally known that they are considering this move for market reasons.
2) Every time GNUstep is posted on OSNEWS or Slashdot, people compain about how 
grey it is and say that if it would update it's look it would be awesome.
3) People have assumed that GNUstep is dead because it looks like something out 
of 1985.  They come to the website and see the screenshots or they see the 
screenshots on other sites and assume, based on the look, that the project is 
no longer active.

The funny thing is that, in no way am I exaggerating any of the above examples.

> Changing the GUI will not come for free - there is the cost of work  
> involved in implementing it and the much greater still cost of  
> increased future work and complexity involved in maintaining several  
> different looks and feels. Indeed, I'm willing to bet that not all  
> themes will be properly maintained, that possibly none of them will  
> be properly maintained, and that this will lead to many tedious my- 
> app-doesn't-look-right-in-xyzzy-theme bugs that will take forever to  
> fix.

One of the rules that will be associated with theming when it is implemented is 
that if a widget has a specific size, the theme shouldn't disturb that size... 
that is to say... if a button is 50x20 it's 50x20, period.  The theme shouldn't 
cause the button to become larger.  So the situation you're talking about is 
possible, but unlikely.  Also, if there is a bug, given the above rule, it's 
the bug of the person who made the theme.

The idea is to make GNUstep easily themable so that themes can be created by 
third parties.

> There are also risks involved - you're more likely than not to make a  
> dog's breakfast of it. The people who designed the NeXT look and feel  
> were very good, and nobody has yet succeeded in bettering them. Apple  
> tried, and failed spectacularly. "Modern" is not always better, and  
> "moving forward" does not necessarily mean "improving". If you get it  
> wrong, you'll end up not only not attracting new developers, you're  
> also likely to drive away your core NeXT afficionados.

The proposed changes are that we would update the existing NeXT look to 
something more modern in the NeXT sprirt.   Also, please don't forget, the 
classic look will always be available, even if it's not the default.  It's not 
like we're going to force something that you don't want on you.  What we are 
going to do is open the door so that people who want a more "modern" theme can 
have it if they want to.

> Worse still, you might get it "right" and attract lots of low quality  
> developers of the sort who cannot see beyond screenshots and skins,  
> who will fail to understand GNUstep in the same way that Apple  
> engineers have failed to understand OpenStep. More developers is not  
> always better for the platform - there is no platform in the world  
> with more developers developing for it than Windows; NeXT had 500  
> people working for them at their peak - who had the better software?  
> Apple has 10,000 people - did they improve OpenStep, or make a dog's  
> breakfast of it? What you want to attract is more *quality*  
> developers. Trying to change the look and feel to attract the sort of  
> developers who make their decisions as to whether to adopt a platform  
> or not primarily on the basis of the look of its widgets and on  
> screen shots is taking you into the domain of Apple-land, in my
 opinion.

Indeed.  Right now we're only attracting a few developers at the time.   Your 
argument is based on a fallacy... that is that if a developer is attracted by 
pretty guis, he/she must be not be any good because they're obviously very 
shallow or can't see past their nose.

This is one of the reasons I'm thankful that GNUstep is an FSF project which 
requires an assignment to contribute.   It raises the bar a little.   Also, the 
maintainers of each component and myself are ultimately responsible for the 
pieces of GNUstep we maintain and their quality.   I'm not given to accepting 
any and all patches that come my way and neither is anyone else on this team.  
So long as we're watchful of who we allow to contribute to the core codebase 
and, once someone is a member of the team, we watch what they contribute to 
make sure it's of good quality, I don't think we'll have an issue with respect 
to "poor developers" piling bad code into GNUstep.  

>
> Both people make precisely the right point although Renauld, in my  
> view, mentions two problems and focuses on the wrong one. The reason  
> GNUstep is not taking off, has nothing to do with its look and feel.  
> Its look and feel is spectacularly good - why try to look more like  
> everyone else when you already look better than them? You'll end up  
> like Apple who has been trying to look more like Windows (very  
> successfully) and has been getting worse and worse for it. There is  
> no room for another Wintel/Apple clone in the market - look the same  
> and it means certain death, look unique and different, and you might  
> just find your niche.
> 

Last time I checked, Vista is a dead on clone of the Mac, not the other way 
around.   I once used a Mac which had Vista installed and was wondering what 
theme they had used over Cocoa because it looked very Aqua-esque.

>
> The reason, in my opinion, that GNUstep is not taking off is  
> blindingly obvious and much more mundane: the damn thing is  
> IMPOSSIBLE to install. Who's going to use it if they can't install  
> it? If you want to win the lottery, rather than worry what's wrong  
> with you and "fix" what is already perfect, why don't you try buying  
> a ticket?
>

Leaving GNUstepStartup which is a two step process:

1) untar it... it contains all dependencies.
2) run the InstallGNUstep script which builds everything and installs it for 
you if you do it as root..

.. aside.   I'll address this.

We should probably create some rpms and DEB files for debian systems to make it 
easier for the average user to install.  But, if we did so I guarantee we would 
have the same issues as we do now with people complaining that it's too hard.  
GNUstep, when compared to some other systems, has a small set of dependencies 
which it needs to be installed.   These rpms would need specific versions of 
these external libraries to be installed based on what the rpms themselves were 
built against.   So, as you can see... the problem is a complex one no matter 
what perspective you try to take it from.

> Perhaps not on Linux, but on an Apple installing GnuStep is  
> impossible. Why isn't there a .dmg installer somewhere with a .mpkg  
> in it which just installs the thing on a Mac? Such a thing should  
> contain all the development tools (gnu c with Gnu runtime, and all  
> GnuStep software etc.), should run on any Mac OS X (10.3, 10.4, 10.5)  
> and be fully multi-architecture (ppc,i386,x86_64 at a minimum). I  
> just spent nearly 2 weeks trying to build GnuStep from scratch,  
> hoping to produce such a .dmg, put it on my web site and offer it to  
> you. I had to give up! I did not want to use DarwinPorts initially  
> (for various reasons) but my only conclusion from that experience is  
> that building the whole thing from scratch is just not a viable  
> proposition. I'd built up all the prerequisites 5-way fat (ppc/ 
> ppc7450/ppc64/i386/x86_64) only to realize that if I want to build  
> GnuStep itself 5-way fat, I have to build 5 different versions of GCC  
> and build everything else again with Gnu runtime ... and then rebuild  
> GnuStep again. It's several more weeks' worth of work!

MAB files are only supported by apple's version of GCC and GCC is not under the 
control of the GNUstep project (obviously).   Fat binaries would be nice as 
would better cross platform compilation support.  Also, keep in mind, the only 
system that supports MABs (now known as "Universal Binaries"... same bloody 
thing) is Mac OS X/Darwin.

> Eventually I got so exasperated trying to do it myself that I  
> conceded defeat and tried the DarwinPorts route - on a brand new,  
> cleanly installed machine, with just a /usr/local and an / 
> Applications/Local added. First thing, DarwinPorts failed to install  
> at all because it didn't like something in my /usr/local. Sigh, OK,  
> so I archived /usr/local into a .dmg and removed it, just so I could  
> try GNUstep. Try again! But even with a completely clean machine,  
> DarwinPorts failed, like this:

<snipped details of failed build>

If it's failing to build from the archives (the one's on the GNUstep site) then 
that's certainly a problem that should be looked into.  Did you submit a bug on 
savannah regarding this issue.  If you haven't, then please do.

> You know, I am awfully motivated to use GNUstep but having to fight  
> this hard just to install is too much!

Understandable.

> Rather than focussing your efforts on changing the GUI with risk and  
> no certainty of return, would you not be better off on focussing your  
> energy into producing a nice self-contained .mpkg to install it  
> easily on a Mac, and keep those updated? I think you would be MUCH  
> better off. Do this, give it a bit of time and give the current look  
> another chance - see if it catches on once people are actually given  
> a chance to try GnuStep out.

No one is focusing just yet on anything.  Also.. this is a free software 
project so, by definition, people focus on what they feel is important.

> You can do this with absolutely no risk of alienating anybody,  
> probably with not too much work, and you are virtually guaranteed to  
> win more users and more developers. Is this not a better business  
> proposition than changing the theme?

I agree that packaging is a problem.   What we need are package maintainers who 
are willing to help us build the RPMs/DEBs and get gnustep running on a Mac and 
create the dmg and so on for it.  Currently we have people who do that for 
various distributions.   GNUstep is currently packaged for debian and ubuntu, 
although those packages tend to be somewhat behind.

We are currently looking for someone as a package maintainer for RedHat.  I 
remember mentioning this on the list a while back after a discussion with Greg 
DeKoenigsburg (a fedora contributor and a redhat employee).

So, packaging is a known issue.

> This brings me on to the next question: who are you targeting? *You  
> cannot appeal to everybody*. You try to appeal to everybody, and you  
> will end up appealing to nobody. You have to pick your target  
> audience. Is it Linux/KDE/Gnome developers or former NeXT/current Mac  
> OS X developers? It looks to me like you're de facto targeting the  
> former (all comparisons are with KDE/Gnome, all effort is going into  
> having GnuStep bundled with Linux; but on a Mac, there isn't even a  
> simple way to install the system).

As I said before, our current audience is former NeXT and current Cocoa/Mac 
users.   As maintainer, I would like GNUstep to have the widest appeal 
possible.  Making it more adaptable is one way of accomplishing that goal.

That being said... GNUstep is not going to be all things to all people.   There 
will always be those who want to change it to be "like everything else" that 
won't happen.  What makes GNUstep special is the fact that we do things 
somewhat different than everyone else... I believe I said in one of my previous 
threads that when we do things on this project we generally do them better than 
the other guys.   

> I think this is a big mistake. There is a much greater barrier to  
> entry coming from the KDE/Gnome world, and much more effort will be  
> required to develop new applications from scratch. A much better goal  
> for you is to persuade existing Cocoa/Apple developers (and mostly  
> former NeXT developers, many of whom are now doing just that -  
> developing for Cocoa) to port their apps to GnuStep. And to attract  
> ANY of those, you absolutely MUST have a simple installer for GnuStep  
> on Mac OS X. Moreover, trying to go after Linux developers has  
> another disadvantage - those developers are less likely to understand  
> what OpenStep is all about and are more likely to push it in the  
> wrong direction. You can pander to their every demand, and GnuStep  
> will never be good enough - until it's the same as KDE/Gnome.

As I've outlined above... I've been contacted by companies which want to do 
just that.  Some of them are old NeXT development shops which want to port 
their apps to GNUstep.   ALL have complained about the look.

All fo the above having been said... I believe I've outlined the problems 
GNUstep is facing before...  on the top of the list is applications, then the 
theme and so on.   Themeing is by no means a panacea for all that ails us, but 
it is one of the things.

One other, rather mundane thing that is costing GNUstep users is the website.  
It is nowhere near informative or active enough.   There are people currently 
working on changing it so that it reflects the activity of the community.

If you've been reading the recent posts (which I gather you have) you should 
know that we are attacking this problem on multiple fronts.

I liked your idea regarding Wolfram research.   That might be one aspect that's 
worth looking into.  The only issue that I can see is that they've had a Linux 
version of Mathematica for some time now.  Still it might be a good thing to 
look into.

Thanks for your feedback, please know that it's not falling on deaf ears.

Thanks, GJC

--
Gregory Casamento -- OLC, Inc 
# GNUstep Chief Maintainer

----- Original Message ----
From: Dr Tomaž Slivnik <T.Slivnik@haldev.com>
To: Gregory John Casamento <greg_casamento@yahoo.com>
Cc: discuss-gnustep@gnustep.org
Sent: Tuesday, November 27, 2007 12:16:54 PM
Subject: Re: GNUstep theming (was Re: Objective-C 2.0 and other new features in 
Leopard)


> But, as project maintainer, I'm sure you can appreciate my  
> position. I can't say unilaterally that I want to appeal to one  
> group over the other.
>
> GNUstep currently most appeals to former NeXT people who are into  
> Mac OS X. However, a lot of these people also say that it's time  
> for GNUstep to move forward with it's GUI look. A friend of mine  
> owns a software company that was once fairly well known in the NeXT  
> world and he's said the same thing.

I do appreciate your position. I also appreciate that it is your call  
to make!

However, even if some (or a lot of) people are saying that GnuStep  
must change its look and "move forward", that does not make it either  
the right technical decision or the right business decision. You put  
it well in another thread yourself:

> Because everyone else is doing it certainly is NOT a compelling  
> reason. I prefer to think for myself.


Furthermore it does not mean that changing the appearance of GNUstep  
will result in more people using GNUstep. Where is your business case  
for that - what evidence do you have that this will happen?

Changing the GUI will not come for free - there is the cost of work  
involved in implementing it and the much greater still cost of  
increased future work and complexity involved in maintaining several  
different looks and feels. Indeed, I'm willing to bet that not all  
themes will be properly maintained, that possibly none of them will  
be properly maintained, and that this will lead to many tedious my- 
app-doesn't-look-right-in-xyzzy-theme bugs that will take forever to  
fix.

There are also risks involved - you're more likely than not to make a  
dog's breakfast of it. The people who designed the NeXT look and feel  
were very good, and nobody has yet succeeded in bettering them. Apple  
tried, and failed spectacularly. "Modern" is not always better, and  
"moving forward" does not necessarily mean "improving". If you get it  
wrong, you'll end up not only not attracting new developers, you're  
also likely to drive away your core NeXT afficionados.

Worse still, you might get it "right" and attract lots of low quality  
developers of the sort who cannot see beyond screenshots and skins,  
who will fail to understand GNUstep in the same way that Apple  
engineers have failed to understand OpenStep. More developers is not  
always better for the platform - there is no platform in the world  
with more developers developing for it than Windows; NeXT had 500  
people working for them at their peak - who had the better software?  
Apple has 10,000 people - did they improve OpenStep, or make a dog's  
breakfast of it? What you want to attract is more *quality*  
developers. Trying to change the look and feel to attract the sort of  
developers who make their decisions as to whether to adopt a platform  
or not primarily on the basis of the look of its widgets and on  
screen shots is taking you into the domain of Apple-land, in my
 opinion.

These costs and risks do not mean you shouldn't go ahead with changes  
- but they do mean you need a pretty compelling business case that  
there are good reasons to believe (not just "some people think/say")  
that there is real potential substantial return to be had by pursuing  
this course. Who will switch to using GnuStep/developing for GnuStep  
because you've "modernized" its theme? What evidence do you (and  
others who claim that) have they will?

Mark Grice wrote:

> And, I still read that some people can't manage to get it  
> installed. This is a real problem.


Renauld Molla wrote:

> When you say that people interested about GNUstep won't care about  
> a new UI, this is definitely wrong. ... a friend of mine ... needed  
> an interface ... I advocated GNUstep ... why wasn't it retained?  
> Because for him, GNUstep is too hard to install ... and it looks  
> terrible. And this guy is no newbie. And there are loads of them.

Both people make precisely the right point although Renauld, in my  
view, mentions two problems and focuses on the wrong one. The reason  
GNUstep is not taking off, has nothing to do with its look and feel.  
Its look and feel is spectacularly good - why try to look more like  
everyone else when you already look better than them? You'll end up  
like Apple who has been trying to look more like Windows (very  
successfully) and has been getting worse and worse for it. There is  
no room for another Wintel/Apple clone in the market - look the same  
and it means certain death, look unique and different, and you might  
just find your niche.

The reason, in my opinion, that GNUstep is not taking off is  
blindingly obvious and much more mundane: the damn thing is  
IMPOSSIBLE to install. Who's going to use it if they can't install  
it? If you want to win the lottery, rather than worry what's wrong  
with you and "fix" what is already perfect, why don't you try buying  
a ticket?

Perhaps not on Linux, but on an Apple installing GnuStep is  
impossible. Why isn't there a .dmg installer somewhere with a .mpkg  
in it which just installs the thing on a Mac? Such a thing should  
contain all the development tools (gnu c with Gnu runtime, and all  
GnuStep software etc.), should run on any Mac OS X (10.3, 10.4, 10.5)  
and be fully multi-architecture (ppc,i386,x86_64 at a minimum). I  
just spent nearly 2 weeks trying to build GnuStep from scratch,  
hoping to produce such a .dmg, put it on my web site and offer it to  
you. I had to give up! I did not want to use DarwinPorts initially  
(for various reasons) but my only conclusion from that experience is  
that building the whole thing from scratch is just not a viable  
proposition. I'd built up all the prerequisites 5-way fat (ppc/ 
ppc7450/ppc64/i386/x86_64) only to realize that if I want to build  
GnuStep itself 5-way fat, I have to build 5 different versions of GCC  
and build everything else again with Gnu runtime ... and then rebuild  
GnuStep again. It's several more weeks' worth of work!

Eventually I got so exasperated trying to do it myself that I  
conceded defeat and tried the DarwinPorts route - on a brand new,  
cleanly installed machine, with just a /usr/local and an / 
Applications/Local added. First thing, DarwinPorts failed to install  
at all because it didn't like something in my /usr/local. Sigh, OK,  
so I archived /usr/local into a .dmg and removed it, just so I could  
try GNUstep. Try again! But even with a completely clean machine,  
DarwinPorts failed, like this:

> --->  Extracting gnustep-base
> --->  Configuring gnustep-base
> Error: Target org.macports.configure returned: configure failure:  
> shell command " cd "/opt/local/var/macports/build/ 
>
 _opt_local_var_macports_sources_rsync.macports.org_release_ports_gnust 
> ep_gnustep-base/work/gnustep-base-1.14.0" && ./configure --prefix=/ 
> opt/local CC=gcc-mp-4.2 GNUSTEP_MAKEFILES=/opt/local/share/GNUstep/ 
> Makefiles " returned error 1
> Command output: configure: error: cannot find install-sh or  
> install.sh in /opt/local/share/GNUstep/Makefiles "."//opt/local/ 
> share/GNUstep/Makefiles
>
> Error: The following dependencies failed to build: ArtResources  
> gnustep-core gnustep-back gnustep-gui gnustep-base gnutls libgcrypt  
> libgpg-error gettext libtasn1 lzo opencdk readline ncurses ncursesw  
> libpng libungif tiff jpeg libart_lgpl GMastermind GMines GNUMail  
> Etoile SQLClient Performance sqlite3 gawk dbus docbook-xml-4.1.2  
> xmlcatmgr xmlto docbook-xml-4.2 docbook-xsl getopt oniguruma5  
> poppler cairo gtk2 atk glib2 pango poppler-data Pantomime PRICE  
> TalkSoup netclasses Yap.app ImageMagick bzip2 a2ps psutils  
> gworkspace system-preferences PreferencePanes windowmaker
> Error: Status 1 encountered during processing.


You know, I am awfully motivated to use GNUstep but having to fight  
this hard just to install is too much!

Rather than focussing your efforts on changing the GUI with risk and  
no certainty of return, would you not be better off on focussing your  
energy into producing a nice self-contained .mpkg to install it  
easily on a Mac, and keep those updated? I think you would be MUCH  
better off. Do this, give it a bit of time and give the current look  
another chance - see if it catches on once people are actually given  
a chance to try GnuStep out.

You can do this with absolutely no risk of alienating anybody,  
probably with not too much work, and you are virtually guaranteed to  
win more users and more developers. Is this not a better business  
proposition than changing the theme?

This brings me on to the next question: who are you targeting? *You  
cannot appeal to everybody*. You try to appeal to everybody, and you  
will end up appealing to nobody. You have to pick your target  
audience. Is it Linux/KDE/Gnome developers or former NeXT/current Mac  
OS X developers? It looks to me like you're de facto targeting the  
former (all comparisons are with KDE/Gnome, all effort is going into  
having GnuStep bundled with Linux; but on a Mac, there isn't even a  
simple way to install the system).

I think this is a big mistake. There is a much greater barrier to  
entry coming from the KDE/Gnome world, and much more effort will be  
required to develop new applications from scratch. A much better goal  
for you is to persuade existing Cocoa/Apple developers (and mostly  
former NeXT developers, many of whom are now doing just that -  
developing for Cocoa) to port their apps to GnuStep. And to attract  
ANY of those, you absolutely MUST have a simple installer for GnuStep  
on Mac OS X. Moreover, trying to go after Linux developers has  
another disadvantage - those developers are less likely to understand  
what OpenStep is all about and are more likely to push it in the  
wrong direction. You can pander to their every demand, and GnuStep  
will never be good enough - until it's the same as KDE/Gnome.

Mark Grice wrote:

> If someone wants to keep the old style NEXTStep look and feel THAT  
> should be a branch. The main code has to move forward in this area  
> or no one will take GNUStep seriously.


I disagree. People look at substance, not form. We use computers to  
work. We ask: what can it do for me, not: does it look nice? I hate  
Apple's Aqua gummy, but that doesn't make me want to quit Apple.  
Apple's flakiness and lack of functionality does.

I think, on the contrary, it is GNUstep that should not take  
seriously people who decide against using GNUstep on the basis of its  
icons, and skins. Such developers are the sort who have made the mess  
of OpenStep at Apple; the value they will add to the project is  
negative.

In this spirit, rather than focus on the skin, what about some of my  
other suggestions:

> Strengths of GnuStep you can leverage:
>
> a) Objective C/OpenStep frameworks on non-Apple hardware (cheaper,  
> more robust/reliable than Apple);
> b) open source (could be important to users not wanting to be tied  
> to a proprietary solution);
>
> Forget - to start with - *everyone* wanting to use GnuStep, if they  
> want to. You need a niche that you cater for - to which you offer  
> something nobody else can, or, at least, to offer it 10x better  
> than anyone else.
>
> Niches you could potentially appeal to:
>
> 1) former NeXT users
> 2) technical / mathematical users (as NeXTStep)
> 3) Apple is not terribly solid and reliable. If you can be more  
> solid/reliable, you could potentially target users from the  
> "mission critical" market - like financial institutions.
>
> Here are some suggestions:
>
> #1: (i) more development frameworks. (ii) Reliable/bullet-proof/ 
> debugged frameworks. (iii) Faster/optimized frameworks.
>
> #2: applications. How about:
>      - to appeal to mathematical/technical market:
>        - a GnuStep clone of Mathematica notebook interface / do a  
> deal with Wolfram to develop one for GnuStep;
>        - GnuStepTeX
>        - ? etc. ?
>      - to appeal to the mission critical / finance market:
>        - an Objective C framework for derivatives pricing
>        - a Lotus Improv/Quantrix clone
>        - ? etc. ?
>      - educational software - to target schools
>
> #3: how about producing an install DVD which formats a PC's disk  
> and automatically installs a GnuStep/Linux distribution?
>      Or doing a deal with a PC manufacturer to sell - or for you to  
> sell - cheap PCs with GnuStep/Linux preinstalled?
>      Or doing a package deal to sell PCs with GnuStep/Linux pre- 
> installed cheaply to schools? Can you get a computer company to  
> donate equipment to schools and the GnuStep team installs the OS  
> and the GUI?


_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep







reply via email to

[Prev in Thread] Current Thread [Next in Thread]