Re: Improve Shotwell Slideshow - Weekly Report #2
- From: Lucas Beeler <lucas yorba org>
- To: Alexandre Rosenfeld <alexandre rosenfeld gmail com>
- Cc: Adam Dingle <adam yorba org>, gnome-soc-list gnome org, Jim Nelson <jim yorba org>
- Subject: Re: Improve Shotwell Slideshow - Weekly Report #2
- Date: Mon, 13 Jun 2011 14:57:44 -0700
> No problem doing the diff, but I was thinking about
> pushing my changes to a repository in Gitorious as
> well. If you want I can send you the diff or I can
> push once or twice a week to this repository.
We're kinda old school here at Yorba in that our workflow revolves
around sending diffs back-and-forth to each other for review, so don't
sweat setting up a Gitorious repo. We actually prefer diffs!
> Ok, great. It will be much less trouble for me to
> implement this directly on Shotwell, but won't
> it be difficult to split it later as a plugin?
One of the things I've learned as a developer is that doing API design
up-front is extremely hard. Let's say for the sake of argument that
you were to build your new slideshow infrastructure as a plugin from
day one. In this case, one of the first things we'd have to do is work
out an API through which your new slideshow plugin and the Shotwell
core executable would communicate. Of course, since we're doing this
API design up front, we haven't spent a lot of time working with the
problem yet: we're more-or-less flying blind. So we design an API that
we think is complete without having worked with the problem. This API
is likely to have some serious flaws. But we code to it anyway, going
through backflips to force our code to work through the flawed API.
This probably results in code that is difficult understand and
So I prefer to work the other way. In this case, "the other way" means
building your slideshow functionality into Shotwell as a first step.
Once you've done this, you've worked with the problem and you
understand it more -- you understand what classes collaborate through
what interfaces and what their responsibilities are. Now, at this
point, you're in a much better place to design an API. In this case,
the API follows naturally from the responsibilities and collaborations
already present in your code. This (hopefully) results in an API that
is well-suited to the problem and easy for others to use, maintain,
On another note, I just took a look at your diff and it seems to be
coming along well. Let's get a little more functionality into it, then
I'll give it a formal review.
Thanks for all your hard work, Alexandre!
] [Thread Prev