Re: [Gimp-developer] GSoC GimpUnitEntry: Review round 2
Hi Martin I implemented your suggestion to follow the GtkSpinButton pattern: The UnitAdjustment now is to be created manually by the client and then set via gimp_unit_entry_set_adjustment(). I removed the majority of functions in GimpUnitEntry which mirrored GimpUnitAdjustment. Only set/get_pixels and set/get_bounds is remaining. I also added gimp_unit_entries_get_adjustment() in addition to gimp_unit_entries_get_entry() so that clients can access the adjustment easily. Have a look at the new API and tell me what you think (especially what part of GimpUnitAdjustment we still should mirror in GimpUnitEntry for convenience). I think I like it better now ;) But I made it a separate commit so we could rewind painlessly... Best regards Enrico Am 30.07.2011 um 13:30 schrieb Martin Nordholts: Hi Here are my review comments from a rather detailed review round. I've looked carefully at the GimpUnitAdjustment and GimpUnitEntry APIs, as I believe we can get the API in a state good enough for inclusion in the GIMP 2.10 plug-in API (that will also survive into GIMP 3.0). GimpUnitEntries should still be kept around, but not as part of a backwards compatible public API, only as a private convenience for us. Same goes for your new gimp_prop_*()-functions and GimpUnitParser. I did't look very closely at the GimpUnitEntries implementation or API this time. I didn't look very close at GimpUnitParser either since it's a small internal helper which is always nice. The diff with comments can be found here: http://files.chromecode.com/gimp/gimp-soc-2011-gimpunitentry-review-2011-07-17.txt Your focus now should be on fixing the review comments (and coding style and documentation) rather than continuing to port GIMP app to use GimpUnitEntry as there is not much time left in the project. Keep up the good job :) / 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 GimpUnitEntry: Review round 1
Hi Martin! Am Freitag, 15. Juli 2011 um 16:17 schrieb Martin Nordholts: 2011/7/14 Enrico Schröder enni.schroe...@gmail.com (mailto:enni.schroe...@gmail.com): Hi I've adressed most of your comments by now. I have a few comments myself though, which I wrote directly in the file. I marked them with '##' so you can search for them. The file with the comments is to be found here: http://userpage.fu-berlin.de/enni/soc-2011-gimpunitentry-comments-2011-07-16.txt Moving discussion out of the text file: String literals to identify entries is a bit too runtime-ish (still better than a numeric literal though), would be better to allow the compiler to tell you when you made a typo. When/if you have time, perhaps add a gimp_unit_entry_table_add_default_entry (table, GIMP_UNIT_ENTRY_TABLE_WIDTH) ? The problem with that is that you are limited in how to name your entries. What if you want to use GimpUnitEntryTable for, say, the radius of a circle. Sure you can define additional enums/defines, but that yould result in longer code (and we would be back to using int for id's, I bet people would just use 1 and 2 instead of defining their own constants). If you make a typo, there is a g_warning() in place which tells you that that entry doesn't exist. But maybe we need to discuss further ;) Let's use the best of both worlds, keep gimp_unit_entries_add_entry() but provide #defines for the common ones: #define GIMP_UNIT_ENTRY_WIDTH width ... so that the compiler catches typos. For entry IDs used once, #defines are not needed. Ok, I will define the defines ;-) Should the common ones be declared in gimpunitentries.h or should each class/file define them themselves when needed? + gimp_unit_entry_table_add_label (options-size_se, GIMP_UNIT_PIXEL, width, height); I don't understand what this line does, what label? Maybe there is a better function name? That function-call automatically adds a label below height to the table, which displays the value of width and height in pixels (see the new layer dialog). Maybe gimp_unit_entry_table_add_preview_label would be a better name? I figured that it might be a good feature to be able to preview the value in pixels while inputting another unit. I can see the label being useful for debugging, but if a user inputs a value in inches, he is likely not interested in the value in pixels. The few that are can temporarily switch to pixels to see. But, since most are not interested, we should not clutter the UI with that info. So IMO the function should be removed. The prototype is gimp_unit_entry_table_add_label (GimpUnitEntryTable *table, GimpUnit unit, const gchar *id1, const gchar *id2) The function automatically adds a preview label to the table, showing the value of the entries with id1 and id2 in the given unit. I noticed that the new image dialog (and a couple of others) were using a kind of preview label (provided by GimpPropWidgets), so I thought it was nice to have for other use-cases as well. Since GimpUnitEntries is a convenience class, I wanted to provide an easy way to create such a preview label. Maybe some plugin could use it someday. Since it's already there and working, why remove it? It doesn't harm anybody, and we don't have to use it in the standard gimp dialogs. If we keep it, we'd need a better name though, e.g. _add_preview_label. Another thing: Add a timeout on the red background that is shown on invalid input. When typing in normal speed, the intermediate state should not flash error, becuase no error has been made. For example, if I type 10 in in normal pace, the entry will flash in red while in the 10 i state, which is annoying and distracting. Makes sense, I will implement that. GimpEevl even provides the position at which an error occurred, don't know how accurate it is though. I will look into maybe providing a little better error indication than just painting everything read. I'm going to make another full review of your code now that you've addressed many of the comments, and I will think extra on the fate of GimpUnitEntries, as we discussed on IRC yesterday. I must say separating the entry-management from creating the UI-container sounds a bit cleaner than it is now. But you had your concerns with that, right? Nice job so far! Thanks :-) Best 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 GimpUnitEntry: Review round 1
And now, ladies and gentleman, I present the same mail in hopefully human-readable formatting: Hi Martin! Am Freitag, 15. Juli 2011 um 16:17 schrieb Martin Nordholts: 2011/7/14 Enrico Schröder enni.schroe...@gmail.com (mailto:enni.schroe...@gmail.com): Hi I've adressed most of your comments by now. I have a few comments myself though, which I wrote directly in the file. I marked them with '##' so you can search for them. The file with the comments is to be found here: http://userpage.fu-berlin.de/enni/soc-2011-gimpunitentry-comments-2011-07-16.txt Moving discussion out of the text file: String literals to identify entries is a bit too runtime-ish (still better than a numeric literal though), would be better to allow the compiler to tell you when you made a typo. When/if you have time, perhaps add a gimp_unit_entry_table_add_default_entry (table, GIMP_UNIT_ENTRY_TABLE_WIDTH) ? The problem with that is that you are limited in how to name your entries. What if you want to use GimpUnitEntryTable for, say, the radius of a circle. Sure you can define additional enums/defines, but that yould result in longer code (and we would be back to using int for id's, I bet people would just use 1 and 2 instead of defining their own constants). If you make a typo, there is a g_warning() in place which tells you that that entry doesn't exist. But maybe we need to discuss further ;) Let's use the best of both worlds, keep gimp_unit_entries_add_entry() but provide #defines for the common ones: #define GIMP_UNIT_ENTRY_WIDTH width ... so that the compiler catches typos. For entry IDs used once, #defines are not needed. Ok, I will define the defines ;-) Should the common ones be declared in gimpunitentries.h or should each class/file define them themselves when needed? + gimp_unit_entry_table_add_label (options-size_se, GIMP_UNIT_PIXEL, width, height); I don't understand what this line does, what label? Maybe there is a better function name? That function-call automatically adds a label below height to the table, which displays the value of width and height in pixels (see the new layer dialog). Maybe gimp_unit_entry_table_add_preview_label would be a better name? I figured that it might be a good feature to be able to preview the value in pixels while inputting another unit. I can see the label being useful for debugging, but if a user inputs a value in inches, he is likely not interested in the value in pixels. The few that are can temporarily switch to pixels to see. But, since most are not interested, we should not clutter the UI with that info. So IMO the function should be removed. The prototype is gimp_unit_entry_table_add_label (GimpUnitEntryTable *table, GimpUnit unit, const gchar *id1, const gchar *id2) The function automatically adds a preview label to the table, showing the value of the entries with id1 and id2 in the given unit. I noticed that the new image dialog (and a couple of others) were using a kind of preview label (provided by GimpPropWidgets), so I thought it was nice to have for other use-cases as well. Since GimpUnitEntries is a convenience class, I wanted to provide an easy way to create such a preview label. Maybe some plugin could use it someday. Since it's already there and working, why remove it? It doesn't harm anybody, and we don't have to use it in the standard gimp dialogs. If we keep it, we'd need a better name though, e.g. _add_preview_label. Another thing: Add a timeout on the red background that is shown on invalid input. When typing in normal speed, the intermediate state should not flash error, becuase no error has been made. For example, if I type 10 in in normal pace, the entry will flash in red while in the 10 i state, which is annoying and distracting. Makes sense, I will implement that. GimpEevl even provides the position at which an error occurred, don't know how accurate it is though. I will look into maybe providing a little better error indication than just painting everything read. I'm going to make another full review of your code now that you've addressed many of the comments, and I will think extra on the fate of GimpUnitEntries, as we discussed on IRC yesterday. I must say separating the entry-management from creating the UI-container sounds a bit cleaner than it is now. But you had your concerns with that, right? Nice job so far! Thanks :-) Best 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 GimpUnitEntry: Review round 1
Hi, GimpUnitEntryTable is not a GtkWidget, hence the change. I know, the name is not very good, but we're working on it ;) GimpUnitEntryTable derives from GObject and just holds, among other things, a GtkTable with the entries. So should I change these variables to GObject? Regards, Enrico Michael Natterer schrieb: I have an additional comment: All these changes: - GtkWidget*size_se; + GimpUnitEntryTable*size_se; The variable must stay a GtkWidget, it a convention for all widgets, since the widget_new() functions also by convention return a GtkWidget. --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC GimpUnitEntry: Review round 1
Hi I've adressed most of your comments by now. I have a few comments myself though, which I wrote directly in the file. I marked them with '##' so you can search for them. The file with the comments is to be found here: http://userpage.fu-berlin.de/enni/soc-2011-gimpunitentry-comments-2011-07-16.txt Regards, Enrico On Thu, 2011-07-14 at 14:26 +0200, Martin Nordholts wrote: Hi Enrico, I've made a first review-round of some of your new code. It's not a complete review, but it's a start. I hope the to-the-point comments are OK, I don't mean to be rude. Note that I'm CCing gimp-developer to keep our correspondence public. I've done the review by diffing origin/master with origin/soc-2011-gimpunitentry (after locally merging master to your branch) and put the result in a text file, then adding comments inline. The patch has been indented 8 spaces to make the comments stand out more. The diff with comments is found here: http://files.chromecode.com/gimp/soc-2011-gimpunitentry-comments-2011-07-04.txt If you have comments on my comments, just continue this email thread. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GSOC] GimpUnitEntry - integration into grid editor
Hi all, during the integration of the new UnitEntry widget into Gimp I came across the grid editor. At the moment it uses two rows, one for entering the value in pixels, one for entering it in another unit (cm, inch etc). Both display the same value. Is there a reason for not using just one row and letting the user select if he/she wants to enter pixels or other units? I don't see one and would just implement the dialog that way, if you don't say hold on, we need it the way it is... ;-) 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
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
[Gimp-developer] native osx version
Creating a new thread as this has nothing to do with my Summer of Code project... 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 I can try, but it was such a mess... I'm not sure I can remember all the steps I did, let alone if I'm able to document them ;) A lot of dependencies needed to be built and installed separately from the gtk-osx versions (and I'm not only talking about the usual suspects babl and gegl), then paths and makefiles had to be hacked for everything to point to the right place... That would be cool. Perhaps you can work together with Simone from Gimp for OS X. On his website he is writing something about a bug in gnome regarding tablets which prevents him from releasing 2.7.2 and probably 2.8. I'm afraid I can't do much about it because I don't have a tablet and the time to fix bugs right now. Maybe after Summer of Code. I was just thinking about releasing binaries with the current limitations (apparently tablets not usable, no twain, no dbus) for those people who want to use it anyways. 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... It's not my patch (I just modified it a little bit), but I think every modification is guarded by GDK_WINDOWING_QUARTZ and __x86_64__ so there should be no problem. Can't test 32-bit though, but I'm not sure which osx versions this affects. Also it uses some deprecated stuff in gtkosxapplication.h so it needs some modifications there, will look into that. The other thing is that we need to link against an additional library, but I don't have any experience with modifying autotools build systems. What is to be modified to do that properly? ___ 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 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
[Gimp-developer] GSoC application overview
Hello Gimp developers, I finished my applications for summer of code. 1) Replace GimpSizeEntry widgethttp://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/enrico_schroeder/1 2) Dynamically resizeable layershttp://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/enrico_schroeder/2001 Originally, I'd thought my preference would be the GimpSizeEntry project, but after a bit of evaluation I also find the resizable layers very interesting. Especially to work on the internals of Gimp and get a deeper understanding of that. And I could imagine that the usability of Gimp would benefit a bit more from that. Also I saw that it is on the official roadmap. Anyways, I'd be very happy to do one of the projects and am confident to be able to finish either of them. Regards, Enrico ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC 2011 - Replace GimpSizeEntry widget
Hello Gimp developers, I'm currently applying for the GimpSizeEntry project for Summer of Code. To keep my application short and to allow further discussion and feedback, I decided to post the detailed description of my proposal on the mailing list instead of in the application itself. My application will contain a link to this mail. Regards, Enrico - Detailed description: I will describe briefly the issues of the current implementation of the GimpSizeEntry widget and how I suggest to address them: Currently, the unit is selected through an external combo box. The new GimpSizeEntry will not have that external combo box. Instead, the unit is entered directly into the text entry. The input will then be evaluated making use of the existing parser (gimpeevl.c) which will allow input of simple mathematical terms and sizes in different units (for example 1024px + 2 in). The result including the unit will then be displayed in the text entry. The unit will be defined through either the entered unit or context sensitive: When there is no unit entered, the previous unit is assumed, or the unit of a related SizeEntry. The second issue is size and flexibility. Being based on GtkTable, the current solution consumes too much space and is not flexible enough. The new GimpSizeEntry will be based on GtkEntry. It will have the necessary interfaces to work together with other SizeEntries or elements such as GimpChainButtons or preview labels. This allows adjusting the SizeEntry for every use case: be it the use in the new image dialog or in the settings of a tool, with or without a button to fix aspect ratio etc. while still being able to make it as compact as possible wherever screen space needs to be conserved. I even imagine the use of just a single GimpSizeEntry for input of height and width together (in the form of ³1024x768 px²). That would especially be useful in the tool¹s settings, where space needs to be conserved. For example the Scale tool: We now have a pop-up with basically only a GimpSizeEntry and Ok/Cancel buttons. Having just a single entry field would allow to move that into the settings and not having to use the pop-up. Designing the new GimpSizeEntry with that flexibility in mind would make it easy to extend it that way. There might not be enough time for all of that in the scope of Summer of Code, but I¹d be happy to continue developing afterwards to ensure Gimp gets the most out of the new GimpSizeEntry widget. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC 2011 - Replace GimpSizeEntry widget
Hello Gimp developers, I'm currently applying for the GimpSizeEntry widget for SummerOfCode. To keep my application short and allow further discussion and feedback, I've decided to post the detailed description of my proposal on the mailing list instead of in the application itself. My application will contain a link to this mail. Regards, Enrico PS. this time hopefully in human-readable formatting, sorry for the first mail. --- Detailed description: I will describe briefly the issues of the current implementation of the GimpSizeEntry widget and how I suggest to address them: Currently, the unit is selected through an external combo box. The new GimpSizeEntry will not have that external combo box. Instead, the unit is entered directly into the text entry. The input will then be evaluated making use of the existing parser (gimpeevl.c) which will allow input of simple mathematical terms and sizes in different units (for example 1024px + 2 in). The result including the unit will then be displayed in the text entry. The unit will be defined through either the entered unit or context sensitive: When there is no unit entered, the previous unit is assumed, or the unit of a related SizeEntry. The second issue is size and flexibility. Being based on GtkTable, the current solution consumes too much space and is not flexible enough. The new GimpSizeEntry will be based on GtkEntry. It will have the necessary interfaces to work together with other SizeEntries or elements such as GimpChainButtons or preview labels. This allows adjusting the SizeEntry for every use case: be it the use in the new image dialog or in the settings of a tool, with or without a button to fix aspect ratio etc. while still having the possibility to make it as compact as possible wherever screen space needs to be conserved. I even imagine the use of just a single GimpSizeEntry for input of height and width together (in the form of “1024x768 px”). That would especially be useful in the tool’s settings, where space needs to be conserved. For example the Scale tool: We now have a pop-up with basically only a GimpSizeEntry and Ok/Cancel buttons. Having just a single entry field would allow to move that into the settings and not having to use the pop-up. Designing the new GimpSizeEntry with that flexibility in mind would make it easy to extend it that way. There might be not enough time in the scope of Summer of Code, but I’d be happy to continue developing afterwards to ensure Gimp gets the most out of the new GimpSizeEntry widget. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSoC 2011 - GimpSizeEntry widget
Hello, my name is Enrico Schröder. I'm studying computer science at Freie Universität Berlin, but am currently studying abroad in Paris at Université Paris Diderot. I would like to apply for the Replace the GimpSizeEntry widget project for Summer of Code 2011. I have strong experience in C and am also familiar with UI programming using different APIs (QT, Cocoa, GTK+, Swing). For my understanding a complete replacement for the GimpSizeEntry widget is required. It is supposed to be more user-friendly (for example the unit should appear in the entry field rather than in an external control and there should be support for input of different units and simple mathematical terms) while at the same time beeing more compact. My general idea would be to base it on the regular GtkEntry instead of GtkTable and letting it handle the input, parsing and calculation of sizes in different units. If it would be helpful, the SizeEntry will be able to accept height and width in a single entry (for example 1024x768px). That way it would be possible to use only one instead of two input fields (I'm thinking of usage in the toolbar where screen space needs to be conserved). However, in the majority of cases it makes sense to treat width and height with seperate input fields, so the new SizeEntry will have the neccessary interface for working together and interacting with other SizeEntries. It will be possible to combine different entries in a GtkTable and add for example a GimpChainButton or preview labels. I'm thinking of designing it in a flexible way so that it can be used in a variety of forms wherever it makes sense to do so, while still being consistent to not confuse users. I hope you like my ideas and am seeing foreward to further discuss them and get feedback. Enrico ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
