Re: [Gimp-developer] Example: Vala as code generator
2011/5/3 Simon Budig si...@budig.de: Martin Nordholts (ense...@gmail.com) wrote: I'm trying hard to find time hacking on GIMP, and not having to waste time on GObject C boiler plate means a lot to me. At first I was thinking what the hell, I'll just come up with the the damn boilerplate code manually then. But right after I began doing that I started to feel like I was wasting my time, and I can't stand that feeling. Hm. This paragraphs leaves me a bit perplexed, because it gives the impression that the most important thing about including vala is to make you more comfortable with our codebase. You blame mitch for a blunt dismissal, but this reads a lot like bluntly forcing down something through mitchs throat. Not sure if that is any better. You are right, that isn't any better. I should just give up on these patches, I clearly don't have the support for them I hoped for. Obviously, in my opinion we increase the quality of our codebase by using Vala for this helper class mostly because the number of readable and documented version controlled lines of code is less than if we would also version control the GObject C boiler plate. That is not the only measurement of code quality however and we are simply weighting the pros and cons differently. / 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/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
[Gimp-developer] gimp
i downloaded gimp and wanted to try it out. I ran into two problems right away so I had to uninstall it. First off, i live and work in China. I am an American English teacher over here and believe when I say this, not everyone in China speaks and reads Chinese, just like not everyone who lives in Japan speaks and reads Japanese. I went to your help page on the web and it covers language change but not for windows 7. There has got to be a simpler way to change the language then what is in your help section. most programs i download give me the option of language before downloading. You really need to fix this. jerry ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Thesis about managing Open source projects-informantions about GIMP
Dear GIMP developpers, My colleague's students are processing theses dealing with open source project management methods but they fail to get contact to any open source project leader as well as for GIMP leader. I wolud like to help them by providing contact to GIMP leader project. Is it possible to be sent contact to project leaders or their mailing list, please? I look forward hearing form you Yours Faitfully -- Ing. Peter Fodrek, PhD. Research scientist Department of Informatics and Communication Technology Institute of Control and Industrial Informatics Faculty of Electrical Engineering and Information Technology Slovak University of Technology at Bratislava, Slovakia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
On Tue, May 3, 2011 at 2:06 PM, jerry chaney jerry.cha...@gmail.com wrote: You really need to fix this. ITs been fixed in the development version and you will be able to change the language in the preferences starting 2.8. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
thank you On Tue, May 3, 2011 at 20:10, Alexia Death alexiade...@gmail.com wrote: On Tue, May 3, 2011 at 2:06 PM, jerry chaney jerry.cha...@gmail.com wrote: You really need to fix this. ITs been fixed in the development version and you will be able to change the language in the preferences starting 2.8. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thesis about managing Open source projects-informantions about GIMP
On Tue, May 3, 2011 at 2:46 PM, Peter Fodrek peter.fod...@stuba.sk wrote: My colleague's students are processing theses dealing with open source project management methods but they fail to get contact to any open source project leader as well as for GIMP leader. Send your people to #gimp IRC channel on gimpnet. However you seem to be looking for a rather mythical beast. What makes you think open source projects necessarily have project leaders? We have lead developers, we have one guy who does office manager stuff but I cant say we have a project manager... -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
On 03.05.2011 14:10, Alexia Death wrote: On Tue, May 3, 2011 at 2:06 PM, jerry chaney jerry.cha...@gmail.com wrote: You really need to fix this. ITs been fixed in the development version and you will be able to change the language in the preferences starting 2.8. But will you be able to navigate (even to) the preferences if it's all in Chinese? Then again - at least the GIMP 2.6 installer for Windows allows you not to install any translations, which in turn means all you'll ever get from GIMP will be the built-in, i.e. English, messages... -- Kurt Bernhard Pruenner --- Haendelstrasse 17 --- 4020 Linz --- Austria ...It might be written Mindfuck, but it's spelt L-A-I-N... ___ 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] Thesis about managing Open source projects-informantions about GIMP
On Tuesday 03 May 2011 14:15:08 Alexia Death wrote: On Tue, May 3, 2011 at 2:46 PM, Peter Fodrek peter.fod...@stuba.sk wrote: My colleague's students are processing theses dealing with open source project management methods but they fail to get contact to any open source project leader as well as for GIMP leader. Send your people to #gimp IRC channel on gimpnet. However you seem to be looking for a rather mythical beast. What makes you think open source projects necessarily have project leaders? We have lead developers, we have one guy who does office manager stuff but I cant say we have a project manager... I think project founders, lead developers and code reviewers acts as project distributes leaders managers. Students task is to found how open source projects are organized. I am open source develloper but only in very smal OSS project HeeksCAD (3 founders/reviewers, 42 ever time commiters), HeeksCNC (3 founders/reviewers, 8 commiters) with centralized SCM systems. I am to think branch maintainers are managers as well. Thank for your answer I look forward hearing from you Yours faithfully Peter Fodrek ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] native osx version
On May 3, 2011, at 8:22 PM, Enrico Schröder wrote: 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... I wrote a small article about how to build gimp at https://sites.google.com/site/httimchen/2011_imagesvn/build-gimp-on-mac And I will port it onto wiki with further detail in these days. Will let you guys know when I am done and maybe Enrico can provide further comments and details on that :D thanks, -Tim ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] nonlinear revision control system for GIMP
On May 3, 2011, at 12:49 AM, Martin Nordholts wrote: I'm convinced (others are not) we should use the proven http://en.wikipedia.org/wiki/Command_pattern and http://en.wikipedia.org/wiki/Composite_pattern for macro recording and wrote some patches a while ago that introduced a GimpCommand and a GimpGroupCommand class. I didn't have time to even turn it into a working prototype however. Hi Martin, It sounds like that there are other thoughts about how to implement the macro system? During my GIMP hack last year, my impression was that macro recording should be done in PDB. And I did not do so because not every functions went through PDB, e.g. those stroke functions (please correct me if my memory did not serve me right). This is not a trivial refactoring, but we need to do it eventually. Yes, this is non-trivial and I am certainly not the best one to do such heavy duty stuff. And I still don't feel too comfortable seeing all those GObject and Glib stuffs...I guess I will first release my hacked and messy GIMP version for researchers first... In any case, the GIMP community helps me a lot and I do like to contribute something back, i.e. integrate my system into GIMP core. Regards, -Tim ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thesis about managing Open source projects-informantions about GIMP
On 5/3/11, Peter Fodrek wrote: Dear GIMP developpers, My colleague's students are processing theses dealing with open source project management methods but they fail to get contact to any open source project leader as well as for GIMP leader. Well, I know nearly everyone in multimedia field. Who do you need to contact to? Also, why do they fail to contact leaders when all it takes is mail anyone from existing dev team? Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp
On 5/3/11, jerry chaney wrote: i downloaded gimp and wanted to try it out. I ran into two problems right away so I had to uninstall it. First off, i live and work in China. I am an American English teacher over here and believe when I say this, not everyone in China speaks and reads Chinese, just like not everyone who lives in Japan speaks and reads Japanese. I went to your help page on the web and it covers language change but not for windows 7. There has got to be a simpler way to change the language then what is in your help section. most programs i download give me the option of language before downloading. You really need to fix this. If you don't speak and read Chinese, then why do you have system locale set to it? :) But, as Alexia already noted, the language switch is there in upcoming 2.8. Alexandre Prokoudine http://libregraphicsworld.org ___ 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] nonlinear revision control system for GIMP
2011/5/3 Tim Chen ht.timc...@gmail.com: Hi Martin, It sounds like that there are other thoughts about how to implement the macro system? During my GIMP hack last year, my impression was that macro recording should be done in PDB. And I did not do so because not every functions went through PDB, e.g. those stroke functions (please correct me if my memory did not serve me right). There have been discussions of other approaches than the Command design pattern. Making use of the PDB somehow probably is a good idea, although that won't work for things that a use can do but that w don't have PDB calls for yet. In any case, the GIMP community helps me a lot and I do like to contribute something back, i.e. integrate my system into GIMP core. That sounds great. The best way to take in a large thing like this is by doing it step by step. Divide your work into small commits that we can take in upstream piece by piece without introducing any bugs or regressions. Eventually you'll have the platform you need to land the final parts that enables your work for users. / 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 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