keynote

intro from some andalucian government person
speaking about the need to incorporate open source into the government
strategies for computing and handling things with open source and speaking
with open source people.

president of the spanish linux users association wishes us a fun ans happy
hacking conference

havoc intorduced the gnome foiundation board of directors, jim gettys, telsa,
george leigl (?) etc

timothy ney introduced a lot of the people who assisted with the conference

Miguel keynote
gnome 2.0, accessibility, uncode, usable
- almost there
  making it a good desktop push, not just making a desktop for unix but a good
  desktop, tradition from eazel days.
- progressing fast, getting more stable/less buggy by the day.
- gnome 2.0 is a platform switch, once it is out the door they wil go back to
  more regular releases.
- new gtk, new rendering engine, etc (see web)
- our duty, interact, meet new people, get lots of email addresses


Owen Taylor
GTK 2.0 how we got here

Gobject, object mechanism moved from gtk to bottom layer in Glib and used
everywhere in gtk and gnome now.
GDK improvements, win32 and linuxfb, 32 bit coords, double buffering

Pango and unicode integrated to the centre of it all (gtk)

New widgets, TextView, TreeView etc (see slides if possible)

wanted to make gtk a world class toolkit, meets all needs can be used for many
many things.

Half the questions on the gtk mailing lists were about the list widgets (there
are currently 4 tree widgets them) so the new TreeView widget has made it a
lot better.

Originally gnome was written by hackers for hackers so there was no need
to support internationalisation and accessibility because all the hackers
spoke english and were not disabled in an overt manner, if gnome is to be
used by everyone they need to make this stuff work, they put the effort in for
2.0

2000 was the year they put in all the big shiny features, they added in all
the major stuff to gtk 2.0 then and since have been refining it a lot.

the stats are rather impressive (changelog size, loc, bugs fixed etc)

The idea menationed of having at least two people look at eny change to the
codebase is goodk sort of approaching the extreme programming mentality

using bugzilla, new thing to use, they are tracking bugs, issues (things that
need to be done that are noticed) and enhancements tracking (things they want
to do (wishlist/toodolist) in the future)
this gives a record of what was done, closed bugs are in there so you can see
what was done and when, a form of documentation of the project, how it
happened.

prject documentation is treated as a design document of sorts, it is created
as it goes, so the cvs history, changelog, bugzillla annd list archives
combined create a design.
Cross referencing between bugzilla and mailing lists and changelog and such
make it easy to work out what happened/is happening.

What they think went poorly is
schedule, though they dont think the amount of work done could be done in less
time, the prediction they made was about a year less than how long it took
design work was somewhat private
division of labour was poor, most work done by few people.
users and developers were stuck with one gnome and one api/library set for
three years which could be seen as a bit long
Their plans to fix the above problems are shorter release cycles, public
design documents and seperaton of roles more.

I wonder does the rendering for the gnome stuff sit on top of gdk pixbuf now
(or is this what they mean by java2d style rendering)

future roadmap (no time scale, but plans for the releases
2.2 multihead, official win32 (a few months from now maybe)
2.4 file selection, combo widgets, new menu api
2.x icon list, sheet widget (what does this mean), help api, enhanced geometry
    management
3.x java2d like rendering, new theme system, who knows what else

questions
with the amount of feedback they got on the file selection why do they not try
to get it out in time for 2.2, the response was that the design of a new api
to get it right is going to take more then the few month time scale for the
2.2 release, they would prefer to get it right rather than rush it.


Developing plugins for the gimp, Simon Budig
slides?
script-fu, using scheme not perl, accessing pdb from scheme, plugins in c

Procedural DataBase, stores image manipulation routines
all image manipulation routines already in there from gimp are prefixed with
gimp_ plugins can use anything there already and add their own to it.
Scripting languages, maps to a language (pdb syntax and syntactic sugar),
Script-Fu scheme, Gimp::Perl, Gimp-Python, others maybe

trying to do access to parts of images from the pdb can be slow so
manipulating images on a pixel by pixel basis one would want to write a plugin.

the pdb entries contain all the infomation about how to use the given plugin
calls and describe what they do to some extent.

the functional programming abilities of scheme are usually not used inside the
gimp apparently, functional programming can be used for more complex things

Script-Fu console accessible in gimp from <Toolbox>/Xtns/scrript-fu/console

Siod interpreter, no idea if it is lazy, other wise looks a lot like one
would expect, the siod interperator is what is used internally in the gimp for
the scheme stuff

he did an intro to scheme, pretty basic intro, very much like lisp or various
other functional languages, from the audeience there was a question about the
need for so many braces, hah, lets throw lisp at them <beg>

some example scripts on the gimp of applying curves to an image using arrays
can be read for how the array (list) stuff can be used in script-fu

all pdb functions return lists, no matter what, so a function that returns one
value is a list with one element, need to get the head of the list

the numbers returned for things like layers and such in pdb functions are
reference things, they willl not actually return the contents of the real
thing they are referencing generally.

The reason to use c based plugins for direct pixel manipulation is because the
scripting interface only allows access to functions and similar stuff,
although there are functions that can return individual pixels or similar
there is a huge overhead doing this for large scale pixel manipulation so the
c plugins are used as they can get regions as normal sort of image data (4
gchars, 8 byte R G B and Alpha)

the shadow and dirty flags to region_get call work as expected, dirty is true
if you will modify the pixels in the region, shadow is true if you wish to
allow a user to undo changes you make (I guess it keeps a copy of the
unmodified stuff somewhere)

it is faster to modify the regions directly rather than copy the region out
and back into gimp, see slides for the stuff about row stride and functions
for this sort of access

look at existing samples to get a good idea about how all this works


Jeff Waugh, 2.0 Debrief

was going to be a gnome 2.0 the making of, then the story so far, however too
much back story and possibly too much known by others in audience, so he is
instead just going to talk about how the release has gone so far and point at
various people.

Bonobo everywhere has not happened, it kind of has kind of hasnt, ie not
everywhere, now of course Miguel is working trowards similar ideas with mono

Gnome 2.0 desktop has changed somewhat, for people new to gnome 2.0 it
will maybe be hard to find some things, otherwise it is probably going to be
easier for new people. New icons and other cool sexy new stuff.

split up into the developer platform, the interface system, and other
parts. The fifth toe (is the collection of random cool stuff), office stuff, and
developer tool kit.

the desktop will probably be released in may (on top of the new api)

introduction of the release team


Recent advances in gstreamer - Erik W and Wim T

see slides
what GMF became
infrastructure for multimedia, not a media player

gui graph based pipeline, apply filters and format loaders and such, elements
inside of elements
elements have connection points where sources connect to sinks
elements are what do the real work, all the rest is just the scheduling and
making sure it all runs together
elements may be written either with one big buffer or being given new data at
certain points (where scheduling comes in)

buffers can be split, joined, replicated, the setup is designed to minimise
data movement (copying)

Pipelines handle scheduling, scheduling is hard (well known fact)
The goal is to ensure everything runs, in order, easiest is chains where
each element simply calls the next, rather than running more then one at once.
(question from floor, what is an element, it is a codec, or filter, or file
format reader or whatever, like applications in piped commands on command
line)

Copies are avoided by the passing of pointers to data between elements rather
than copying, all the memory is shared memory and all the elements run in
place if possible (faster), the locking has to be dealt with between threads
when using anything more complex than a chain of elements.
Single elements may have multiple sources or sink pads, this is difficult and
not working again yet.

No concept of video or audio in gstreamer, it all has to be done dynamically,
the type negotiation is what takes care of this, so when run every linkage has
to talk to things it is linked to to make sure they are compatible, plugins
that all accept one form of audio can negotiate with each other to ensure they
are compatible.
This is based on a mime style type for all data processed by plugins. (with a
bit of other attributes or something thrown oon)
(this is the Pad connections stuff)
On connect time caps of both connecting pads (on source and sink) tell each
other their types they can process, matching types are then seen at each end
and each plugin can configure itself to use the types it will be speaking
across the pipeline negotiated.

The connnection may be delayed if necessary, eg, if there are no headers to
work out what you wish to do yet, so you delay until you learn what you need
to process.

This Pad stuff for connection and configuration of plugins is the largest
single non processing part of each plugin, the rest of the standard sort of
code is pretty much boiler plate (may be easily cut and pasted with little
changes) however due to the complexity of this it is large and not so trivial.

Events in gstreamer, why? seeking for data, EOS signalling, QOS information,
down or upstream signalling between plugins. (simply signals between plugins)
Bytestream discussion, somewhat complex, for data that has byte oriented data
of various sizes, they moved this into a library that elements can run under
as it was complex and ugly to deal with. (so making all element authors deal
with it is silly if avoidable)
This is for use when there are groups of bytes of varying size coming in and
you need to get buffers that cross over parts coming in from the streams, it
works by trying to have larger buffers that you can get parts of easily
without copying any data (this is a bad description of this I think)
(possible this bytestream is because you need to decode smaller parts of large 
buffers, in mpeg or something) and this bytestream code handles grabbing the 
smaller parts and does it cleanly.

gstreamer good, others such as xmms, real, etc not so good, they follow the
same sort of api (different to gstreamer) their plugin mechanism is too
limited, like file plugins are file plugins, you can not use other plugins
or something.

a demo of gstreamer being used to create a dvd player that displays dvds in
text rather than normal video written in a few lines (using aalib), change one
line and it does it with SDL output in normal video
they have no really good player, there are three basic players which showcase
different parts of gstreamer however someone needs to sit down and write a
really good player using gstreamer, the players are really simple to make as
the gstreamer code underlies them all, this is why it has been so easy for
people to create many different players.
Next was a demo of rythym box, an iTunes clone


Luis Villa, Using GNOME bugzila

5500 open bugs, 100-300 new bugs a day, this is not fun according to luis
a few months ago peoplle were in general not getting involved in the bug
process and people were ignoring it and not dealing with it and many people
were becoming frusrtrated with reporting or dealing with bugs

what people want from bugzilla, fix bugs, do so with minimum possible hassle

rule 1, he suggests learning to love bugzilla and it will love you back,
natural response to a bug such as "it crashed" is to ignore it, should not
ignore the spam^Wemail from the bug system, if it is a report like this get
more details.  if you put in the time each day to do the bug handling and
assigning the appropriate status to bugs then when you sit down to spend a
weekend working on code you dont have it full of clutter, ismply the stuff to
do, so take the time and your life will be simpler.

rule 2, constancy (x3), find bugs, categorise bugs, use bugzila fields, put the
effort into classifcation of bugs here and you can find the specific bugs you
need/want to work oon at a given time with ease, rather than reports of
thousands of vvarious bugs that can not be searched.

a lot of this does not apply to geleon possibly as they get 10000 bugs a day
with no real useful information so maybe just harder for the galeon team to do
all this than other people

developers should use easyfix tag so that new people who wish to help out can
do that and search for these bugs. Clear titles on bugs is good also, his
example is "gegl is funny loooking" is a bad compared to "gegl has 6 legs and
should have 4"

rule3, queries and reports are useful, horrible ui in bugzilla, however once
used to it getting lists of exactly wehat bugs you wish to see is easy.

luis suggests going into #bugs (irc.gnome.org) if you need help of any sort
with the bugzilla system for gnome bugs.

users love it when developers pay attention to bugs, even telling people a
bug is crap is a big thing for many people, being nice to people can in rare
times give so much positive karma to gnome and your project that it is
probably worth being nice in bug responses all the time.

For people who file bugs (users)
remember "The Developer is a Volunteer". How to make the life of a developer
easy as a user/bug filer
File bugs well, the spectrum of easy to hard bugs, easy is attach a patch,
hard is simply saying "jeff has no pants" (this got all the developers 
laughing so we australians must be notorious for not having pants)

try to be clear, how to reporduice a bug, good description, keywords etc.
exlain why you care aboout the bug after you have decribed it, why is it
important to you, this may assist with ranking by the developer.

work with the developer, communicate early and often (if you catch a developer
wanting to spend itme oon your bug work with then and it will get it doen
quicker, and everyone will be happier)

if a maintainer does not think something is a bug, dont go around flaming
them, instead explain in detail why it is a bug to them.

one other thing to remember, bug triage, trying to figure out how important a
bug is, claims like no one will ever use this unless you fix my bug, this
pisses developers off, dont be adverserial, explain to them why a given bug is
important and what it affects.