2011/5/2 Enrico Schröder <enni.schroe...@gmail.com>:
> Hi all,
> i've come up with the first concept for the rewrite, including a class
> diagram and sequence diagrams for a few use cases:
> Note that it mainly shows how the different components work together,
> not how each component does its work internally. If I forgot something
> (and I probably have ;-) ) please tell me.
> Martin: I planned on integration the keep-aspect-ratio functionality
> right away, because I don't think it's to much additional work.
That's a good start! A couple of comments
* As this project is not about refactoring GimpSizeEntry but instead
write a new widget from scratch so we can get it right this time, we
need a new name. I could think of GimpDimensionEntry and
GimpUnitEntry, feel free to come up with something better.
* The sequence diagrams should be on the class interface i.e. method
level. For example, in the "simply entering two values" sequence
diagram, what classes and method calls will be involved in order to
let GimpSizeEntry b know about GimpSizeEntry a? (I don't understand
why in that use case they need to know about each others value at all
though, they are independent, aren't they?)
* You should put some thought into what exactly happens during
"enters value a", "enter value in a new unit" etc. You'll get a
GtkEditable::insert-text signal, but then what? Some kind of parsing
needs to take place. Take a look at GimpEevl which is a unit parser we
already have, resuing that would be ideal.
* In the "Changing aspect ratio" sequence diagram, a good design
would have an abstraction for the aspect ratio constraint, so that it
would be equally easy to have a constraint between two entries that
said "entry_a = entry_b + 100" as it is to have "entry_a = entry_b *
1.33". Think a base class GimpUnitConstraint with GimpOffsetContrainst
and GimpAspectRatioConstraint sub classes. In order to verify a design
for the aspect ratio preservation use case, what GimpUnitEntry classes
and method calls are involved in the following situation (which is the
main use case for aspect ratio preservation):
The current image has a pixel size of 200x100. The user does Image ->
Scale Image that brings up a dialog with two GimpUnitEntries, one for
width and one for height. The user can toggle between preserving and
not preserving aspect ratio. With aspect ratio preserved, the user
focuses Width (= 200) and erases one of the zeroes. At the same time,
the Height (= 100) entry changes to "10". What method calls were
involved to make that happen? When you have a sequence diagram that
answers that, you have a design.
But, don't put too much time into aspect ratio preservation. In fact,
I would prefer if you put as little effort as possible into this right
now (except making sure not to make it impossible to extend the design
with it later). Let me explain why: There are a lot of things that
could be done on GimpUnitEntry. Let's list a few things:
A The basic use case 'Enter a string in the form "<number> <unit>"
and have an interface that allows the pixel value with a given
resolution to be returned.
B The GimpSizeEntryTable you talked about
C Aspect ratio preservation between two GimpUnitEntries
At the end of the project, it is much better if you are 100% done with
A, and 0% on B and C, than if you hare 60% done with A and 20% done
with B and C. Code that is not delivered during the end of a GSoC
project has a tendency to either take a long time to hit upstream or
never does it at all. So we should work incrementally, first focus on
the basic use case A, then we can spend time on B and C.
To summarize, there are some things to sort out before we can say we
have a design. Once we have a design, we can start looking at writing
code. Now, of course, we probably won't get the design 100% right the
first time, it's an iterative process, but we should at least have an
initial design before we start coding.
> Additionally I set up a task schedule on
> http://tasktaste.com/projects/enni/gimpsizeentry and applied for a gnome
> git account, but it probably takes some time for it to be activated.
Good, being able to track progress is essential if we want this to be
a successful GSoC project. I do think however that you should increase
the resolution of the tasks. It will be hard to follow up progress on
an 8 week big task. Let's settle on an initial design before creating
more detailed tasks though.
> Also, since I'm using a Mac and tried to not having to use a virtual
> machine, I built git-gimp natively on osx (without X11) and with a patch
> that moves the menubar from the main window to the top of the screen
> (like other mac apps). It really was a horrible experience (took me a
> whole day), so I thought it would be nice to have a precompiled
> app-bundle. As far as I know, there are no official mac binaries, right?
> The only ones I found where using X11, which isn't very good. I could
> try to provide osx binaries of the current 2.7.2 and then 2.8 including
> patches for the menu bar and a nice theme.
Not quite sure I follow, how would precompiled binaries help? You'll
need to compile the code yourself anyway,won't you? Btw, as soon as we
have a feature branch, I am going to set up our continuous integration
server Jenkins (http://gimptest.flamingtext.com:8080/) to build
nightly tarballs of your work. That way it will be rather easy for
anyone to test your code.
My GIMP Blog:
"GIMP 2.8 schedule on tasktaste.com"
Gimp-developer mailing list