2011/5/2 Enrico Schröder <enni.schroeder@xxxxxxxxx>: > 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: > http://enni.userpage.fu-berlin.de/GimpSizeEntry.pdf > 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. Hi Enrico 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. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ "GIMP 2.8 schedule on tasktaste.com" _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
