Martin Nordholts wrote:
I will work on some more detailed diagrams, these were just less
detailed overviews to illustrate what kind of classes I plan on using
and what they do.
* The sequence diagrams should be on the class interface i.e. method
They are independent as long as we don't want to preserve aspect ratio.
Ok I guess I mixed two different use cases there ;). However, I plan on
using only signals for two entries to communicate with each other. I
thought the "emit" showed that. And the signals are getting emitted no
matter the other entry does not do anything with it. The first entry
can't know who does something in reaction to its signal, it just sends
it whenever the user modifies the value.
What I want to avoid by that is the entries having some sort of pointer
to each other, because it's more flexible for future enhancements (I'm
thinking of the "one-entry-for-width-and-height", as written in my
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.
Will do, as I said the diagrams are just a rough overview.
Ok I haven't thought about the "entry_a = entry_b + 100" case. If that
should be considered then we indeed need a form of abstraction...
* 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 *
I try to come up with a design that incorporates that. If we have that
then it shouldn't be much work to do the actual implementation. I still
think it's possible during that summer ;)
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).
I didn't make them finer-grained because I can't yet estimate how long
each step will take. Will update as soon as the design is more complete.
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.
This has nothing to do with my project, I already created a new thread
for that. I just thought I maybe could provide OSX binaries as a
byproduct of the day I spent compiling Gimp on Mac ;)
> 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.
Gimp-developer mailing list