Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
2011/5/30 Enrico Schröder enni.schroe...@gmail.com: Martin Nordholts mailto:ense...@gmail.com 30. Mai 2011 11:04 Hi again How's it going? Best regards, Martin Hi Martin, sorry for the long pause, finished my exams last week (with moderate success...) ;) Been working on the widget again to get it ready for the initial upload. Many things are missing and incomplete, but basic parsing and communication between two entries is functional. Right now I'm working on integration of the GimpUnit system into the GimpEevl unit resolver callback. I also updated the schedule on TaskTaste into smaller steps. Not everything is listed there, but I will add tasks as soon as they come to my mind. Maybe I will do the initial commit later today. Will my repository be set up or can I do that manually? Best regards, Enrico Hi I hope the exams went well after all ;) You got your GNOME git keys, right? If so, you can create a feature branch yourself in the GIMP git. # create your local branch git checkout -b local-branch origin/master # Do some changes... # Create/push to the feature branch git push origin local-branch:soc-2011-gimpsizeentry # Every now and then git merge origin/master I would like task sizes at http://tasktaste.com/projects/enni/gimpsizeentry to be at most 1 week so we have a chance to follow up on the progress. Once you have created your branch, I will set up our nightly builder at http://gimptest.flamingtext.com:8080/ to create nightly tarballs of your branch so people can easily try it out. Looking forward to look at your first pushed commit :) Note that I CC:ed gimp-developer Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
2011/5/14 Enrico Schröder enni.schroe...@gmail.com Hi Martin! Parsing is done via GimpEevl which is called from the UnitEntry. I think it makes sense because the entry is responsible for input and output, the UnitAdjustment holds the value. GimpEevl does not require any UI. Or did you mean our get_unit method? Maybe it would make sense to modify GimpEevl to also determine the unit? Hi! Yep I meant the get_unit() method on GimpUnitEntry, it should be possible to get_unit() also in the non-UI layer. Yes it probably is a good idea to let gimp_eevl_evaluate() return the unit of the expression. It shouldn't know anything about the unit itself though, like today, where the knowledge of units is abstracted away through a GimpEevlUnitResolverProc parameter. * Have you thought about how the image resolution comes into the picture? Would it be ok to have our UnitAdjustment hold the resolution along with the actual value? It does belong together. However, the problem then would be if we want our entry to be used to input a resolution. We could make that work by using just the resolution field of our adjustment, but that would not be a very elegant solution. So another class GimpResolutionAdjustment? It's fine to keep the current resolution in GimpUnitAdjustment. As far as I know we haven't had problems with gimp_size_entry_set_resolution() and a similar interface for GimpUnitAdjustment will make it easier to port code to use the new classes. To use GimpUnitEntry for resolution input, a good solution would be based on yet another abstraction, perhaps GimpUnitEntryBehavior, with subclasses GimpSizeBehavior and GimpResolutionBehavior. We don't want to end up with lots if cases on some mode variable (like GimpSizeEntry has for GIMP_SIZE_ENTRY_UPDATE_SIZE and GIMP_SIZE_ENTRY_UPDATE_RESOLUTION). However, the details of GimpUnitEntryBehavior is hard to predict, so let's focus on a size-only GimpUnitEntry first. When we're done with that we can see what of the code we should move out in a GimpUnitEntryBehavior abstraction to also support resolution input. Resolution input is in many ways similar to size input, it's just a different set of units and slightly different constraints. I think we have thought enough about design matters for now, and it's time to start writing some code (I suspect you already have started doing that ;) ). Before doing that though, please update http://tasktaste.com/projects/enni/gimpsizeentry with as small tasks as you can. The smaller tasks we have, the better can we track project progress and discover when we need to do something in order to meet our deadlines. Don't worry if you can't yet split them up as much as you'd like to though; we're still early in the project. As we move along, exactly what we need to do will become more and more clear, and we can update the schedule accordingly. Very good job so far! Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ GIMP 2.8 schedule on tasktaste.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
Hi Martin! Martin Nordholts 11. Mai 2011 08:01 * The parsing should also be perfomed by a non-UI layer and not in GimpUnitEntry so the parsing code can be used in e.g. a script interpreter with no UI dependencies. Parsing is done via GimpEevl which is called from the UnitEntry. I think it makes sense because the entry is responsible for input and output, the UnitAdjustment holds the value. GimpEevl does not require any UI. Or did you mean our get_unit method? Maybe it would make sense to modify GimpEevl to also determine the unit? * GimpUnitEntryTable shouldn't derive from GtkTable, because there is no is-a relationship. To convince yourself of that: Can you always replace a GtkTable with a GimpUnitEntryTable? Nope, so you should use composition instead of inheritance. Yeah maybe GimpUnitEntryTable could just be a set of (static) functions that set up certain commonly used combinations of UnitEntries, Labels etc. But i guess there is time to discuss that in detail later, first I'd want to work on the UnitEntry itself ;) * I've recomended a test-case based development approach before, and now that most of the code will have no UI-dependencies I recomend it even more, as non-UI classes generally are very easy to unit-test. An example of a commit that introduces a non-UI class along with appropriate propotions of documentation and unit tests is this commit: http://git.gnome.org/browse/gimp/commit/?id=9fefa22efe70e484fc7c92708ed8efe023e4d219 By writing unit tests along with your code, productivity goes up a lot when you (or anyone in the lifetime of the project) refactor code, because verifying the class still works takes seconds. Will look into that. * Regarding the use case of entering "1 cm" and getting the result in px, we could use an 'in' keyword like Google. Analogous to "100 SEK in USD", we would have "1 cm in px". That is a future extension though, don't spend time on that yet. Ok, should not be hard to implement this later. * Have you thought about how the image resolution comes into the picture? Would it be ok to have our UnitAdjustment hold the resolution along with the actual value? It does belong together. However, the problem then would be if we want our entry to be used to input a resolution. We could make that work by using just the resolution field of our adjustment, but that would not be a very elegant solution. So another class "GimpResolutionAdjustment"? * Regarding your get_unit() method, an interesting question is what unit an _expression_ like "10px + 1cm" has. I'd say use the first unit, px in that case. A user would enter an _expression_ like that if a) the 10 px are already in the entry and he just adds the "+1 cm", so we can assume he wants the unit to stay px, or b) he enters that term into an empty entry, in which case he could have entered "1cm + 10px" if he wanted to have cm * Have you thought about how to connect GimpUnitEntry to the existing GIMP code like the various props helper functions? (See how GimpSizeEntry currently is used) Have to look into that as well. * I don't like how constraints currently are applied, in particular that you require two instance of a constraint when there is only one equation that shall hold. I don't think it is a good idea to make GimpUnitAdjustment (or GimpUnitEntry for that matter) be aware of constraints, because they can potentially be rather complex. It is probably a better idea to take care of constraints one one architectural level above GimpUnitAdjustment (they don't know about constraints, constraints are just being applied to them). * Regarding the contraint case, for a good design, consider how you would support constraints between three numbers (e.g. a = b + c). * Again, I would advice you to focus on the basics. Once the basic functionality is in place, meaning it is
Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
Hi everybody, I've come up with a updated (and more detailed) version of class and sequence diagrams for the new widget. http://enni.userpage.fu-berlin.de/GimpUnitEntry.pdf I tried to incorporate some of the comments. Note that all names are subject to change ;-) Our now called GimpUnitEntry will be derived from GtkSpinScale and use a subclass of GtkAdjustment to store its value including the unit (GimpUnitAdjustment). All synchronisation and live updating of associated UnitEntries will happen directly between their GimpUnitAdjustments, thus completely separating everything value-related from the gui and input. The GimpUnitEntry itself will be just responsible for display and parsing of entered terms. See use cases and class diagram for details. Regards, Enrico ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
2011/5/3 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: 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. Looks interesting:) 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. Try poking mitch on IRC. He has the keys to the keep but he only looks when he knows there is something pending :) 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. Im wondering if that menu patch could be formated into a build switched thing that could be integrated. Being consistent with mac paradigm sounds pretty important to me personally... -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
2011/5/2 Enrico Schröder enni.schroe...@gmail.com: 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), It would be nice, if you can document the steps to compile Gimp for MacOS in the Wiki: http://wiki.gimp.org/index.php/Users:Beginner_Developer%27s_FAQ 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? Right, the gimp team doesn't provide any binary builds. Not for MacOS, Windows or Linux. But there are Distribution like the one from Gimp for OS X: http://gimp.lisanet.de/Website/News/News.html 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. That would be cool. Perhaps you can work together with Simone from Gimp for OS X. Regards, Tobias ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
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: 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
Re: [Gimp-developer] [GSoC] GimpSizeEntry widget
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@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GSoC] GimpSizeEntry widget
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. 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. 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. Regards, Enrico ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
