Re: Lowering the barrier (was: Re: build systems)

[Emmanuele Bassi <ebassi gmail com>]

hi;

On Sat, 2007-11-10 at 23:33 +0100, Mikkel Kamstrup Erlandsen wrote:
> On 10/11/2007, Emmanuele Bassi <ebassi gmail com> wrote:
>         On Sat, 2007-11-10 at 15:06 +0100, Mikkel Kamstrup Erlandsen
>         wrote:
>         
>         >  * GObjects are conceptually difficult when you have
>         standard
>         > knowledge of C# or Java
>         
>         you know you don't have to use GObjects with C, right? you can
>         write 
>         native C# and Java applications.
> 
> I realize that I could have been more clear here. What I find
> problematic is that the barrier to contributing native code is to
> high.

if by "contributing native code" you mean contributing to the platform
then yes: the barrier is high. the required quality is also high. if you
want to start contributing you might *not* want pushing patches to, say,
gtk+ or evolution, but maybe start with something easier, to get
acquainted with the platform, the policies and the libraries.

that's why we have GNOME Love, with bug days, an IRC channel and a
mailing list.

> I have been putting a lot of time into deskbar in the past and I can
> not tell you how many times I've heard "oh, great - yet another Python
> daemon", or "why did you not wrote it in C?".  Setting up a PyGTK
> project with Python distutils is extremely easy, and about as low
> barrier to entry as humanly possible. 

not every application has to be in the desktop. writing python (as well
as C++, Perl, Java, C#, Ruby, Ada, whatever) applications is encouraged
nevertheless.



> Yes, it takes ten minutes to autotool a *basic* setup if you know how
> to do. But doing things that are expected for packages like, passing
> make distcheck, building gtk-doc, build a few test/examples, install
> headers or other files correctly takes a long time if you are not
> comfortable with autotools. 

then I guess what you need is getting comfortable with autotools,
instead of avoiding them.

when I say "basic" setup I mean a basic setup for a GNOME library or
application: gtk-doc, distcheck, examples, tests, pkg-config, etc.. it
takes me now less than 10 minutes because I created a set of templates,
which I guess is what happens with every tool. I usually don't fight
with autotools unless I need to port some arcane setting.

>         >  * Some parts of the Gnome API are just plain hard to use.
>         Ever tried
>         > implementing a panle applet? Wonder why we have to many apps
>         using
>         > tray icons?
>         
>         from a cursory glance in my chat logs of #gnome on
>         irc.gimp.org and
>         gtk-list archives it seems that everybody start with panel
>         applets; I 
>         started with those as well. it's not hard to write a panel
>         applet: it's
>         hard to *debug* a panel applet - but that's because of the way
>         panel
>         applets work.
> 
> Yes, everybody starts with panel applets - but I can name three
> projects of the top of my head that ended up resorting to tray icons
> even though an applet would be the right solution. I shall not point
> any fingers though. 

if a project chooses to use a tray icon is usually because we don't have
an inter-desktop standard for panel applets, and not because
libpanel-applet is "hard".

writing a panel applet requires some magic incantations (mostly, putting
an XML file in the right place), and libpanel-applet is severely
underdocumented.

>         >  * Write a "GObjects for Java/C# Developers" document (or
>         maybe two 
>         > separate docs) meticulously explaining the concepts of
>         classes and
>         > object instances compared to Java/C# objects for the lay
>         hacker
>         
>         this is a false problem: since you can avoid writing GObjects
>         in C and 
>         use native data types instead, what you need to do is refresh
>         the
>         GObject tutorial.
> 
> I do not understand what you are trying to say here. That people can
> just use plain old structs or that they can use bindings like Java,
> Python, Mono? 

no, I mean: since people can avoid thinking about GObjects at all and
use native data types in their language of choice, the only time they
need to know how a GObject works is because they are writing something
in C. this means that the GObject native C tutorial must be fixed,
expanded or clarified. if you do not know C, or don't use it, then
there's no need to write a document for understanding a GObject from a
Java perspective - simply because a user of the Java bindings will be
exposed to Java objects.

if you want to contribute to platform libraries you need to understand
of GObject works, not how GObject compares to Perl blessed types, or C#
objects: a GObject is a GObject, it's a different implementation of a
OOP environment.


> I think there is no denying that Gnome development (in native C) has a
> high barrier to entry, and from this thread's subject I think that is
> what we are trying to lower.

yes, it's high. for what I'm now - after three or four years - able to
understand is because GNOME is quite a huge project, and some of its
bits are incredibly complicated (or are getting there). hence the high
barrier. it's not an application, or a library.

the point I'm trying to make is: attacking GNOME's complexity as a whole
will not cut it. you need to identify the high barriers of entry of
single projects, or single bundles of projects (for instance: the
applets involve gnome-panel and different applications).

> Saying to each of the points that I raise "this is FOSS, you can just
> send patches", amounts to claiming that the way things have been done
> till now is fine. Then I wonder how we ended in this position in the
> first place... 

the whole point of this thread is not clear to me in the first place; it
started as one of the cyclic discussions that open on desktop-devel and
now it reached a meta-discussion about the barriers of entry for GNOME.
I don't see the barriers. I did not see them when I started
contributing, and I don't see them now. what I see is enhancements we
need to make, patches we need to write, documentation we need to
publish.

>  1) Pin down a list of problematic points
>  2) Create a list of actions to address these points in a pragmatic
> way
> 
> 
> 
> As I read your mail you have just waived every point I tried to raise
> in 1). That is fair to do, as I may be wrong, but does not really help
> further the subject of this thread. 

if you sent an email to get everyone to sycophantically agree with you
then you didn't want a discussion in the first place, and you could
start fixing the points you had in mind instead of writing a long email.

I replied telling you what I think it's wrong in your premises, in your
approach and in the actions you deducted from your premises; this is
usually "discussing".

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net