1. Easy Gnome Development

This document is still in the brain storming phase. Please drop comments generously. -- MikkelKamstrup 2007-11-11 13:48:08

The purpose of this page is to facilitate the creation of a strategy to lower the barrier of entry for would-be Gnome contributors.

The primary focus is on development with GObjects in C, but problems in other languages is also welcome.

Sorry if this sounds harsh, but what a waste of a goal for a page about making Gnome development easy for beginners. GObjects != GNOME; perhaps you should rename the wiki page if GObject is your primary goal? I don't think beginners should bother learning GObject at all until they've done several other things first. In fact, I never bothered learning it and am still the (co-)maintainer of libwnck and metacity. -- Elijah

1.1. The Plan

5 step plan to world dominance:

Pin point the exact areas and cases people have difficulties with. These could be on specific projects, collections of related projects, general concepts, or development tools used in Gnome. These items are collected in the ProblemAreas section.
Brain storm a list of proposed solutions to the identified problems. These items are collected in the ProblemAreas section.
Choose which of the identified problem areas to address and go for a pragmatic solution that requires minimal work from maintainers or other people contributing the needed work. This is collected in the Actions section.
Implement actions.
Profit.

Points 1 and 2 can be addressed more or less at parallel, Step 5 should be more or less automatic when we've nailed 1 through 4.

1.1.0.1. Format

Entries on problems/solutions should be formatted as follows

==== Problem Title ====
Description of problem.
 ''Solutions:''
   * Proposed solution 1
   * Propsed solution 2
 ''Comments:''
   * Comment 1
   * Comment 2
   ...

1.2. Problem Areas

The initial list was compiled from the issues raised in the following thread: http://mail.gnome.org/archives/desktop-devel-list/2007-November/msg00103.html

1.2.0.1. Boring Gnome Love Bugs

While Gnome Love bugs are generally a good idea, some love bugs are just too boring. Some people like challenges and more bling for the buck.

Solutions:
- Add a challenge rating to (love) bugs
- Communicate to package maintainers that they should keep an eye out for more exciting love-work
Comments:

1.2.0.2. Hard To Understand How the Stack is Structured

It is hard to understand how the Gnome stack as a whole is structured. Legacy stuff like Orbit and Bonobo are known to confuse people.

Solutions:
- A white paper explaining the overall stack. How do the libaries fit together etc. This is a good start already http://developer.gnome.org/doc/guides/platform-overview/platform-overview.html
- Point people at http://library.gnome.org/devel/platform-overview/stable/. Is it too hard to find?
- Add OpenSearch plugins to API pages so people can use these. I made a few over here
- Make it asolutely clear on the Bonobo page that you want to use DBus in 98% of all cases (it is somewhat implied in the bottom)
- More tutorials on how to use certain parts of the stack in the recommended way. Some tutorials are listed already on the GnomeLove page
Comments:

1.2.0.3. Missing API Docs

Some parts of the API is not properly documented. Here follows a list of under documented libraries - please add to the list if you know more:

libpanel-applet - this is bad because people often end up implementing tray icons because it is a lot easier to do
Solutions:
- Write the documentation
Comments:
- Maybe shall we enhance devhelp so that it is not only able to display docs, but also allow editing of docs and automatic submission of the changes ?

1.2.0.4. Code Under Commented

The actual code is not very generously commented (which modules; it's not fair to tar all modules with this same brush). This makes it harder for new people to jump in and contribute.

Solutions:
- Atleast one comment line per private function to document its intent.
Comments:
- This is too broad to actually fix in a reasonable time frame. We need to locate specific libs/apps (and maybe specific parts of these) to target. -- MikkelKamstrup 2007-11-11 14:33:10

1.2.0.5. GObjects Are Conceptually Difficult

People with a Java or C# background often find GObject implementation mystifying because they find it hard to understand how GObjects compare to Java/C# objects

Solutions:
- Pimp Anjuta's GObject helper more
- Take Anjuta's GObject helper from good to *excellent*
- Create a document describing GObjects relative to C# and/or Java objects. This may be better of in two documents.
- Just don't use it; program in a higher level language or deal with other parts of the stack.
Comments:

1.2.0.6. Autotools are Tricky

Autotools are both tricky to get started with and hard to use correctly. See fx the discussion here: http://mail.gnome.org/archives/desktop-devel-list/2007-November/msg00075.html

Solutions:
- Pimp Anjuta's autotools integration more.
- Take Anjuta's autotools support from good to excellent
- There is a lot of documentation. Make sure we have links to good docs in the relevant places
- Just avoid it. I contributed for years just letting other people deal with this. I even had other people handle autotools when I *was* the module maintainer.
Comments:

1.2.0.7. Some Apps or Libs are Hard to Get an Overview Of

The design of some applications or libraries are not always easy to get an overview of.

Solutions:
- Generate UML diagrams to go with usual gtk-doc. Anjuta can do this - can gtk-doc do it?
- Convince selected module maintainers to write down half a page of design documentation
Comments:
- This is too broad in scope. We need to identify specific packages that can use better design docuemtnation -- MikkelKamstrup 2007-11-11 14:33:10
- This problem is related to the Under Commented Code problem

1.2.0.8. It is Hard to Set Up A Good Build Environment

It is hard to get set up with a comfortable development environment

Solutions:
- See Owen's blog post from a few months ago (Sept 2007 I think?) about making building with jhbuild easier.
- Lobby for distributions to create a gnome-developer package containing all needed headers, documentation, helper tools, version control systems, and an IDE (such as Anjuta)
Comments:

1.2.0.9. It is Hard to Spot the Good Examples

When hacking about it is very common to check out existing modules and see how they do stuff. The problem is that many modules do things in different ways (and not always "the correct ways" TM).

Solutions:
- Stamp one (or a few) of the official Gnome components as example modules - ie. use a real life module as an example and polish it off to make sure it is a good source to look at.
Comments:

1.2.0.10. Fear of asking questions

People are afraid to make a fool of them selves by asking trivial questions, and are uncertain where to direct them when they do.

Solutions:
- A #gnome-school channel like Ubuntu has a packaging school
Comments:
- If there are not competent people to staff an IRC channel it will quickly deteriorate. Besides we already have #gnome-love -- MikkelKamstrup 2007-11-11 15:09:26

1.3. Actions

This section should remain empty until the initial brainstorm is done. See the plan.