Re: [GSoC] GimpSizeEntry widget

[Enrico Schröder <enni.schroeder@xxxxxxxxx>]

Hi Martin!

Martin Nordholts wrote:

* The sequence diagrams should be on the class interface i.e. method
level. 

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.

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?)

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 application).

 * 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.

 * 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". 

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...

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 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 ;)

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.

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.

> 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.

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 ;)

Regards,
Enrico

_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer