Re: [Gimp-developer] Blog article about Scheme usage in GIMP
2011/9/5 Ofnuts ofn...@laposte.net: On 09/05/2011 07:57 PM, Martin Nordholts wrote: If we look at what programming languages that are popular [1], we can see that the vast majority of languages in use today have a syntax where 1 + 1 is written 1 + 1 and not (+ 1 1). If we want to have a main scripting language that as many as possible can use with as little effort as possible, Scheme is simply not an alternative. For most programmers, Scheme is an odd language. In the long term I think it is inevitable that we need to replace Scheme with something that has a syntax that is more mainstream. I wholeheartedly agree with that. However, doing the switch is a huge task and we have other things that are more important to work on, so I don't see this happening any time soon. Haven't we got a quite nice Python interface already? Yes we do, which is nice, but Scheme still has higher status. In particular, the format of gimprc files etc are Scheme-ish, and the default batch interpreter is Script-Fu. / Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tool presets
2011/9/5 Alexia Death alexiade...@gmail.com: Since when does adding default resources counts as a feature or involves significant amount of coding and risk of breakage? I would agree if this was a coding task. It is not. If it was, there would be something very wrong with the setup. We sort of promised our users better resources with this release but nobody has take it up... The very least we could do is to provide some defaults for the new things so people know what it does. What I call feature is something that makes GIMP better and that we don't _have_ to do. Having default tool presets is better than not having default tool presets, but it is not something we _have_ to do before releasing 2.8, so adding default tool presets is a feature. When I say that we should not do this to 2.8, I say that because I want us to make a 2.8 release as soon as possible. However, people are of course, as always, free to work on whatever they want to. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tool presets
2011/9/5 Alexia Death alexiade...@gmail.com: Of course, but I see no reason to actively discourage resource changes at a point when we dont even have a new splash set yet... Well, the reason we don't have a splash is because nobody had time to get us one yet. From the point of view of making a 2.8 release happen, it would be better if you took the lead in finding a 2.8 splash rather than adding default tool presets. But then there is the point of view of fun, and if you get a kick out of giving users default tool presets in 2.8, which is perfectly sensible, please do that. I get a kick out of trying to make a 2.8 release happen as soon as possible as well as improving the way we work so that we can shorten our release cycles, so that's what I do. Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Blog article about Scheme usage in GIMP
2011/9/5 Michael Schumacher schum...@gmx.de: I'd like to comment on the blog post, or see comments by someone else, but I'd like to clarify our plans for Scheme in GIMP first. If we look at what programming languages that are popular [1], we can see that the vast majority of languages in use today have a syntax where 1 + 1 is written 1 + 1 and not (+ 1 1). If we want to have a main scripting language that as many as possible can use with as little effort as possible, Scheme is simply not an alternative. For most programmers, Scheme is an odd language. In the long term I think it is inevitable that we need to replace Scheme with something that has a syntax that is more mainstream. However, doing the switch is a huge task and we have other things that are more important to work on, so I don't see this happening any time soon. / Martin [1] http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tool presets
2011/9/5 Alexandre Prokoudine alexandre.prokoud...@gmail.com: Hi, We currently have the new Tool Presets dockable dialog that has zero factory preset. Maybe we should should opulate it a bit? Some cropping presets for popular photo paper formats, DVD and whatnot? Steal some presets for painting tools from G-P-S? This is not something that blocks a 2.8 release and we badly badly need to make a release. This should wait until after 2.8. / Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] tool presets
2011/9/5 Alexandre Prokoudine alexandre.prokoud...@gmail.com: On Mon, Sep 5, 2011 at 9:00 AM, Martin Nordholts wrote: This is not something that blocks a 2.8 release and we badly badly need to make a release. This should wait until after 2.8. How does it prevent you from releasing 2.8? Any feature we add at this point will delay the 2.8 release because someone needs to actually write the code, test the feature, fix bugs, take feedback into account etc. Even if we get a patch from the outside, a core developer basically needs to do all of the above except writing the initial code. With limited resources, we have to prioritize. And releasing 2.8 has higher priority than having default tool presets. We can always add those later. And with the shorter development cycles we aim for, it's not a big deal if a feature makes it into x.y or x.(y + 2). / Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC-2011 - Gimp plug-ins to Gegl operations
2011/8/26 Robert Sasu sasu.rob...@gmail.com: Hello, Here is the list of op's I ported (made): 1. Color rotate 2. Color to alpha 3. Convolution matrix 4. Cubism 5. Deinterlace 6. Emboss 7. Fractal-trace 8. Lens correct (with Lensfun library) 9. Lens-distortion 10. Plasma 11. Polar-coordinates 12. Red-eye-removal 13. Ripple I also made a showcase: http://sasurobert.github.com/GSoC-2011/ It was a really amazing experience, and I will continue to port plug-ins and/or make some tools (anything you need) after GSoC. Thanks for everything. Hi Robert I must say, really great work! This will be very useful as we fully transition to GEGL. Nice presentation too. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.7.3 released
2011/8/22 Thales Oliveira - WeAreLinux.com tha...@wearelinux.com: I'm sorry, hasn't it been available for a while? At least I have been using 2.7.3 for months. Great news anyway. There is lot of confusion regarding this, which is why I think we should start with GEGL-like version numbering, i.e. odd micro numbers for code in git, even micro numbers for releases. / Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Tab in Single Window-Mode
2011/8/15 Jeremy Morton ad...@game-point.net: Speaking of tab in single-window mode, does Ctrl-Tab work for switching tab yet? If not, is this planned? Ctrl+Tab will continue to cycle between layers, at least in GIMP 2.8. / Martin -- My GIMP Blog: http://www.chromecode.com/ Single-window mode feature complete ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockables aren't disposed when closing floating dock window
2011/8/13 P S psweb...@gmail.com: This is my first post in gimp-dev so forgive me if I happen to miss out context or interfere with current work in progress. It turns out dockables aren't disposed after a gimp_dock_dispose() call in the current master. gimp_dock_dispose() only removes dockbooks which will not be disposed if references are still held by attached dockables. The behavior is particularly notable on singleton dockables when closing a floating dock window: 1. Add a new tab Tool Options to main dock 2. Drag out or detach Tool Options tab to a floating dock window 3. Close the floating dock window 4. Try to re-insert Tool Options tab in main dock. Doesn't work - as floating dock's dockbook hasn't been disposed and Tool Options dockable is still attached to it You don't happen to be running Ubuntu 11.04 are you? Their GTK+ installation seems to be broken. Try building GTK+ yourself, preferably GTK+ 2.24.5 and see if the problem goes away. BR, 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] SingleWindowMode-Issue
2011/8/6 Robert Hildebrandt roberts_k...@gmx.de: Hello Guys, I love the new singlewindow mode. But there'se still (today fetched, merged and compiled) got one issue in the current version: I like to work with the single Window mode when it's maximized, but everytime I open a new Image or close an opened one, the window returns to normal mode. Hi Thank you for your feedback. It is indeed quite annoying and I will fix it before we release GIMP 2.8. There is already a bug report for it: Bug 650348 - Window unmaximizes when a document is closed https://bugzilla.gnome.org/show_bug.cgi?id=650348 / 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] prerequisites not building on F14
2011/8/2 Michael J. Hammel mjham...@graphics-muse.org: Gdk-2.0.gir: error: Type reference 'GdkPixbuf' not found I've built and installed the prerequisites, including gdk-pixbuf, to /usr/local/gimpgit. I've tried building gobject-introspection but that doesn't build either. I didn't think that was required for pre-3.0 anyway (side note: should latest GIMP GIT build with 3.0?). I was under the impression that the gir stuff was from the introspection stuff, but maybe not. Is the .gir file for GdkPixbuf installed? If not, that's probably why you get the error. If you have problems building the introspection files, try passing --disable-introspection to configure for all dependencies. And no, GIMP git master doesn't build with GTK+ 3.0, but mitch's gtk3-port branch does. / 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 2
2011/8/1 Enrico Schröder enni.schroe...@gmail.com: Hey Martin, just a small status update: starting on documentation and fixing your review comments now. (Have been busy with moving to my new apartment last week). By going through your review comments I noticed that your diff file incorporates some old code (e.g. all that gimp_prop_coordinates_*2 stuff) which I already removed. Have you used an old revision? BTW: Of course I will continue working on GimpUnitEntries and maybe other parts of Gimp after GSOC, but since there is roughly a month left of official project time, what do you think needs to be done for my project to be rated successful? Anything major except documentation and fixing your review comments? How about porting (which is ~75% done I guess), does that need to be complete until end of august? Best regards, Enrico Hi (Keeping gimp-developer on CC) I had trouble finding time to do the review, so the snapshot I was reviewing is quite old by now, but hopefully most comments still apply. It would be great you could keep contributing also after GSoC. Regarding being rated successful, just do your best addressing the review comments. Your project basically already is successful :) Porting all GIMP to use the new widget is not as important as having the GimpUnitEntry widget itself fully completed, tested and documented, so focus on the latter. BR, 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] Gimp should be GIMP, but have no idea about GimpCageConfig (translation related)
2011/8/2 Michael Muré batolet...@gmail.com: #: ../app/gegl/gimpoperationcagecoefcalc.c:82 #: ../app/gegl/gimpoperationcagetransform.c:118 msgid A GimpCageConfig object, that define the transformation For now, this string won't go to the UI, but it might happen in the future, when gegl will be integrated, so I keep it marked for translation. Hi Michael, I strongly doubt it would make sense to bother our users with names of GObject classes, could you elaborate on why we should do this? 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
[Gimp-developer] Small nightly builds-tool update
Hi,
This is a small update on some changes I have made on our continuous
integration tool Jenkins that is hosted here:
http://gimptest.flamingtext.com:8080/
With the addition of nightly tarball builds of feature branches, in
particular for some of our GSoC projects, there is a new naming
convention for jobs:
project-jobtype-branch
Examples:
* The name of the distcheck job for the master branch of babl is
'babl-distcheck-master'
* The name of the distcheck job for the soc-2011-gimpunitentry branch
of GIMP is 'gimp-distcheck-soc-2011-gimpunitentry'
Also, I have stopped using the GNOME Project Builder plug-in for all
our jobs and started using plain shell commands instead. This makes
job configuration more straightforward and adaptable. For reference, I
have included the commands used to build and publish the nightly GIMP
git master tarball at the bottom of the mail.
/ Martin
#
# Constants for this build
#
PREFIX=$HOME/prefix/babl-gegl-gimp
TARBALL_NAME=gimp-git-master.tar.bz2
#
# Clean up distdir from previously failed distchecks to prevent make
# check from being confused
#
package=`grep '^PACKAGE = ' Makefile | awk '{print$3}'`
version=`grep '^VERSION = ' Makefile | awk '{print$3}'`
distdir=${package}-${version}
test ! -d $distdir || \
{ find $distdir -type d ! -perm -200 -exec chmod u+w {} ';' \
rm -fr $distdir; }
#
# Build
#
./autogen.sh --prefix=${PREFIX} --enable-gtk-doc
make
make check
make install
make distcheck
#
# Rename built tarball so it always have the same name
#
ls -1t *.tar.* | head -n 1 | xargs -I fff mv fff ${TARBALL_NAME}
#
# Publish to ftp
#
cp ${TARBALL_NAME} /var/ftp/pub/nightly-tarballs
--
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
[Gimp-developer] GSoC GimpUnitEntry: Review round 2
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
2011/7/16 Enrico Schröder enni.schroe...@gmail.com: 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? Put them in gimpunitentries.h for now. Later we will move gimpunitentries away from libgimpwidgets anyway until we have a GimpUnitEntries interface we believe in. 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. Ok let's keep it, but don't add such a label where there wasn't one (like in the New Layer Dialog). 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. Sounds good. I would like to remind again though about that our main focus right now is to get a basic GimpUnitEntry to work and integrate it in GIMP, so unless you don't have other things to do, don't work on error indication. 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? Don't know yet :) Let me get back on that. / 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
[Gimp-developer] GIMP 2.8 schedule update, one month slip
Hi everyone, I just went through our GIMP 2.8 schedule at http://tasktaste.com/projects/Enselic/gimp-2-8 and made some adjustments and about a month was added to the release date estimate because of it. I would like to describe the adjustments I did, check the status of the various tasks, and discuss if we can do anything to get 2.8 out faster, or if there maybe is more work left to do on 2.8 than the schedule reflects. Changes I did: * Removed Bug 647834 - Stop using deprecated API in plug-ins because the problem doesn't exist in stable versions, only in development versions * Lowered size of Bug 631934 - Interaction between Old text parameters and new region specific text attributes from 8 to 5 working days because that seemed to me like a better estimate. mitch? * Added Make window mode switching less destructive, because we (I) need to prevent dock windows from being placed on top of each other when switching from single-window mode to multi-window mode * Added Single-window mode related bugfixing buffer because I expect some single-window mode related bugs to pop up that I need to fix * Added Bug 645120 - Disable color tools overlay dialogs Status of tasks: * I'm going to take care of all single-window mode related tasks + Bug 596410 - gimp-image-get-filename returns NULL for imported files. * Regarding Bug 642728 - Use cairo to draw Gfig, I don't think this blocks 2.8, we can use the old way of drawing in 2.8. Objections to me removing it from the schedule? I know Mikachu has started the porting. If he finishes before 2.8 is released that's great, but not having GFig ported to cairo in 2.8 isn't a blocker IMO. * Regarding Bug 304798 - Painting brush outline is slow, is this still a big problem? I know Alexia and mitch has worked on this. * Regarding our biggest tasks, Bug 612931 - Moving individual layer in layer group not possible with Move Tool and Bug 51112 - clipping groups or masking groups (like in Photoshop files), maybe I have over-estimated these? What do you think mitch? Any other tasks you'd like to discuss? Any tasks you'd like to add to the GIMP 2.8 schedule? Overall the progress on tasks have been good. The reason we have a small slip is only because new things have been added to the schedule that was not originally included. Thanks to everyone that has helped out completing tasks so far! Keep it up. / 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
2011/7/14 Enrico Schröder 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. + 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. 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. 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. Nice job so far! BR, 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
[Gimp-developer] GSoC GimpUnitEntry: Review round 1
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. BR, 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] new color system ready for GIMP
2011/7/8 GiveLifeCS gabr...@givelifecolorsystem.com: Hi Martin Nordholts , I will try to explain your questions: I have invested approx. 4 years to do this color system It was a very manual I mean, that was without using any type of mathematical algorithm, but one by one watching and analyzing the colors and noting that these colors are expressed in C, M, Y, K had not other colors systems in the world today. The composition or organization of special colors is not governed like other color systems have done in different ways, but it has its explanation only thing I like is not to comment further. Something really important thing I've seen these years is that any color system in the world has sought and continues to seek equivalence with Pantone, now is that everyone knows. GiveLifeCS has never followed any time the color matching with other color systems, so I think it has something to offer. To me, all color systems are good but working with GiveLifeCS and other color systems is making an awesome way to enrich the color variations making it as simple as this is a tool for the creative -designer with new shades and one software design like GIMP needs a unique color system. Givelife CS is currently online for only 4 months, I mean it's actually doing is new to users. Actually, I have not invented anything new, in the world there are some color systems ,they are good for me. and the color palettes for any software design you need to pay it, but with GiveLifeCS never , because the color palette of GiveLifeCS will be free always. I am currently working on another palette and will continue with the same philosophy as for ubuntu , gimp, linux etc. .. I was inspired in the way of distribution of GIMP. Givelife CS is from the south of Europe (SPAIN) For This reason it is the first color system Latino Hispanic in the world ,than i am aware. the software design should have a system of color or multiple color systems that really helps the user design software By default when a designer does not work with color systems standardized way, without wanting to use always or almost always the same colors, but it is a contradiction and I say so pure experience. greetings and good luck Gabriel GiveLifeCS please very sorry if my english is not so good i use google to translate i hope you will understand all ,but if you have any question else please contact me. Thank you in advance i wait for your news Hi I am afraid going through Google Translate creates too much ambiguity. To to discuss this we need to be able to communicate efficiently. I am sharing your reply with gimp-developer anyway for completeness... please keep the mailing list in this email thread if you make a reply. BR, 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] new color system ready for GIMP
2011/7/7 GiveLifeCS gabr...@givelifecolorsystem.com: Hi developers of GIMP my name is Gabriel Vano I created a NEW COLOR SYSTEM with 2265 new shades, the color palette is free for various design software including GIMP. MY QUESTION FOR THE DEVELOPERS IS: Someone can help me to get in touch with the developers of GIMP to try out this new color system and to study the possibility of including it in GIMP by default? I have been in contact with you, precisely because I think than this new color system will be right for GIMP and of course for all users of GIMP this is a new tool for the Creative-Designer. My thanks in advance. Hi Could you elaborate a bit on how you have chosen the colors you have chosen and how they are defined? / 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 - integration into grid editor
2011/7/1 Enrico Schröder enni.schroe...@gmail.com: 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... ;-) Hi, No reason is mentioned in the initial commit (edd5c33923a574a278a74d56ca770f6072e0ffc6), the referenced bug (Bug 65198 - Ability to show a grid) or the manual (http://docs.gimp.org/en/gimp-image-configure-grid.html). I don't see a good reason either, it just seems silly. So feel free to have only one row when you port to GimpUnitEntry. BR, 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] Isn't this behaviour unintuative?
2011/6/30 Jeremy Morton ad...@game-point.net: My suggestion is an export (to the original file name and file type), but with a 'are you sure you want to overwrite?' dialog before the export happens, with the focus automatically on the cancel so 'enter' will cancel the export. The popup is good when the user did in fact not want to overwrite the file, whenever the user *do* want to overwrite the file, that popup will be very annoying. Imagine a are you sure you want to save-dialog each time you press Ctrl+S. / 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] Isn't this behaviour unintuative?
2011/6/30 peter sikking pe...@mmiworks.net: I wrote: I will update the spec now to formalise this. done, and it was not a one-liner. Martin (prime suspect for implementing the change): please do a careful diff in the wiki to see the changes. It looks straightforward and I expect to be able to update the code for 2.8. One gripe: The spec says give secondary support to workflows where the input and output are the same non-xcf file and you just made this a bit harder (OK-ing the Export to dialog) For the record: Would you still want the new approach in the spec if Ctrl+E would previously have been an unused keyboard shortcut? BR, 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] Isn't this behaviour unintuative?
2011/6/30 peter sikking pe...@mmiworks.net: no, nothing changed in the Overwrite workflows. today's changes can be summarised as: - in the cases where before Export to was insensitive, it is now sensitive and mapped to invoke Export... (the dialog) - in the cases where Overwrite blocks Export to out of the File menu, the shortcut of Export to is still active and mapped to invoke Export... everything else works like before Thanks for the clarifications, I've made this change now: commit c73bdc097188a926f01062a009f9f22ff32dad4e Author: Martin Nordholts mart...@src.gnome.org Date: Thu Jun 30 23:44:50 2011 +0200 app: Make 'Export to' fall back to 'Export...' Make 'Export to' always sensitive (as long as there is an image at all). And make it fall back to 'Export...' if no export target has been set yet. Note that it is not necessarily visible at all times, sometimes 'Overwrite' shadows it. It shall still be invokable though. Reference: [Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html @Jeremy: Does this work better? / 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] Isn't this behaviour unintuative?
2011/6/26 Jeremy Morton ad...@game-point.net: When I open a non-GIMP format file, like a PNG, by drag-dropping it into GIMP, and then I edit it, I go to export it, by pressing ctrl+E... and nothing happens. This is because what I actually have to do is select File | Overwrite (filename.png). Wouldn't it be more intuative to behave as if you'd just exported (filename.png), or whatever file you've just imported into GIMP, so that once you've edited it you can just press ctrl+E and easily export it back to its native format? Yes it would be more intuitive, and that was also the initial design. The reason it works the way it works today is to avoid data-loss. In GIMP 2.6, the keyboard shortcut Ctrl+E invokes the harmless View - Shrink Wrap action. In GIMP 2.8, it overwrites an original file. In other words, this sequence of events is harmless in GIMP 2.6: 1. File - Open file-I-dont-want-to-lose.jpg 2. Make some significant changes 3. Press Ctrl+E while in GIMP 2.8 the file-I-dont-want-to-lose.jpg would be lost if we made Ctrl+E invoke Overwrite by default and a user, quite reasonable, expects Ctrl+E to still be Shrink Wrap. The idea was that by forcing users to manually assign Ctrl+E to Overwrite, they would confirm that ok I know Ctrl+E will potentially destory my originals. That file-overwrite and file-export can't have the same keyboard shortcut is a bug, that is meant to work. Quite an oversight that it doesn't... Once people have learned that Ctrl+E is export and not Shrink Wrap, we can make Ctrl+E be the default keyboard shortcut for both Overwrite and Export. Until then, I just made a commit so that you can use Alt+F, W instead at least: commit 9ae0dc034b7791c15479649f71ef4cda8caaf34e Author: Martin Nordholts mart...@src.gnome.org Date: Tue Jun 28 08:53:45 2011 +0200 Make 'w' a mnemonic for File - Overwrite ... See [Gimp-developer] Isn't this behaviour unintuative? http://lists.xcf.berkeley.edu/lists/gimp-developer/2011-June/026885.html 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/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] 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/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] nonlinear revision control system for GIMP
2011/5/2 Tim Chen ht.timc...@gmail.com:
Hi all,
Recently we have published a paper on SIGGRAPH 2011 about nonlinear revision
control system for images. You can find the abstract and videos at
https://sites.google.com/site/httimchen/2011_imagesvn
Hi Tim
That's great stuff.
1) is there anyone implementing the macro/script system
Nope there isn't, so you are more than welcomed to start doing that.
FYI, macro recording is on our roadmap found at
http://wiki.gimp.org/index.php/Roadmap.
2) can anyone give me a head start on how should I modify my hack so that it
is more readable to others? Spreading the log function into tens of files
certainly breaks most guideline one should follow when writing
object-oriented program :D
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.
It will be necessary to make some extensions to the above patterns.
For example, you may have noticed that GIMP is quite quick to Undo and
Redo, in particular for time consuming pixel processing operations.
That's because the undo stack contains the tiles with the resulting
pixels, not only parameters used to get that result. When Redoing, the
tiles with the result can quickly be applied.
I'm imagining that we'd have code that would look something like this:
gimp_expensive_command_execute (...)
{
if (gimp_expensive_command_result_cached (...))
gimp_expensive_command_apply_cached_result (...);
else
// Do time-consuming stuff
}
We don't want to start each GimpCommand with that if case though, so
an abstraction will be needed.
This is not a trivial refactoring, but we need to do it eventually.
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] Example: Vala as code generator
2011/5/2 Michael Natterer mi...@gimp.org: On Sun, 2011-05-01 at 17:15 +0200, ense...@gmail.com wrote: Hi all, We have discussed the possibility to use Vala as a code generator. What follows is a set of patches so we all can see what that would look like. Any objections to me pushing these commits? Yes, and I'm currently on vacation and can't respond in detail, but IIRC I have made myself very clear about vala. Hi Michael, 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. I find your blunt dismissal of these two patches really discouraging. Can't we at least push them to master and have them in for a while and see if we can discover some real problems? If it really doesn't work out, we can just reformat the generated .h and .c files and discard the .vala file. If you are on vacation and don't have time to properly review or test these patches, please take your time to do so. I'm not going to push these patches without your OK, and if you're busy for a few weeks, then I'll have to wait. I can work on other items on the GIMP 2.8 schedule in the meantime... 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
2011/4/27 Enrico Schröder enni.schroe...@gmail.com: Hi Martin, thanks for choosing me for the Summer of Code. I will start working on the specification details of the widget at the end of the week. At the end of may I have exams, so I hope I can manage to start a little before the official coding period. My first step would be to write a little test app for developing the widget. Integration into Gimp will then be the last step after finishing the widget. Do I get a Git repository for my work or what are the next steps? Regards, Enrico Hi Enrico! It's great to have you as a GSoC student! A small test app that can quickly be rebuilt sounds sane. You'll get your own feature branch in GIMP's git. Have you applied for a GNOME git account yet? If not, you should do that. The next step is to come up with a class diagram with the main components involved, for example GimpUnit. You should also draw sequence diagrams for the main uses cases so we can verify that the design we're going to have will work. We should also create a schedule of this project before we start to write code so we can act early if things don't go as expected and we risk becoming late. I suggest you add a schedule to http://tasktaste.com/. A schedule is a simple list of tasks to do and the size of each task. The site then sums this up and shows project progress as we complete tasks. I'm adding the gimp-developer mailing list to CC and would prefer if all our communication went through gimp-developer unless there content is very private. Again, great to have you on board! Let's get started :) 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] GIMP 2.8 schedule update
On 04/15/2011 09:57 AM, Alexia Death wrote: On Fri, Apr 15, 2011 at 9:08 AM, Martin Nordholtsense...@gmail.com wrote: Hi Two new items on the 2.8 schedule has been added: * Bug 647835 - Handle deprecated GTK+ API * Bug 647834 - Stop using deprecated API in plug-ins And one item has been fixed: * Include UI tests in nightly Jenkins builds Bug 304798 - Painting brush outline is slow Work on this bug has progressed considerably. It now performs very well in most cases. There have been plans to have an alternate simplified brush indicator, but that is not the subject of this bug. As far as I'm concerned this bug can be closed. You and mitch are the paint and brush masters, so if it's good enough for you, it's good enough for 2.8. Can you or mitch close the bug report then or at least move it off the 2.8 milestone please? It's just that when I do 1. new image 2. move around the default brush outline on the canvas then one of my CPUs work 100% in 2.7.2 and about 50% in 2.6.11. That it not necessarily a problem, just wanted to point it out. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Continuous update of the NEWS file
Hi, Now that 2.7.2 has been released and NEWS is up to date (thanks mitch!), let's make sure to keep it up to date from now on. That means that whenever you make a commit that is worth being mentioned in NEWS, add it to NEWS along with the other changes in the commit. That way making a new release will require less effort since whoever makes a release don't have to go through months of commits history first. Making frequent releases is something we want to be as easy as possible. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP 2.8 schedule update
Hi Two new items on the 2.8 schedule has been added: * Bug 647835 - Handle deprecated GTK+ API * Bug 647834 - Stop using deprecated API in plug-ins And one item has been fixed: * Include UI tests in nightly Jenkins builds The last fixed item means that we run all our tests each night now, including UI tests. The estimated release date is now 2011-11-21. To track development progress and get an up to date release date estimate, simply visit http://tasktaste.com/projects/Enselic/gimp-2-8 . / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.8 schedule update
2011/4/15 Kevin Cozens ke...@ve3syb.ca: Martin Nordholts wrote: The last fixed item means that we run all our tests each night now, including UI tests. Um... ok... How does a buildbot run UI tests? If the backend is X, you use http://en.wikipedia.org/wiki/Xvfb. Although it is often more convenient to use a common wrapper script called xvfb-run, which is also what our bulidbot uses. xvfb-run is actually used by default always (detected during configure-time), so if you have xvfb-run installed and runs make check, you won't see any GIMP UI while the UI tests are run, they will run in Xvfb. / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GsoC - 2011 - Porting GIMP plugins to GEGL operations
2011/4/7 Robert Sasu sasu.rob...@gmail.com: After writing the code reviews I ported the emboss plug-in to gegl. Should I upload to GIMP bugzilla ? Yes please, and don't forget to reference the patch in your GSoC 2011 application. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Sample implementation of a new GEGL op
On 04/06/2011 06:14 PM, sourav de wrote: I tried to implement the blur operation in GEGL. The algorithm is same as of the blur plug-in in GIMP. The patch file for GEGL operation and the blur.c file for the plug-in are attached below. Kindly let me know if there is any mistake in my implementation. Please attach the patch to GIMP bugzilla and reference the patch in your application. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New schedule for GIMP 2.8
Den 3 apr 2011 23:46 skrev Łukasz Czerwiński lc277...@students.mimuw.edu.pl: I'd like to suggest time profiling as another task to be done before the release. Once I started to optimize Gimp's startup time (especially scheme interpreter) and I'd like to return to that task in the near future (when I find at last some time for it :) ). What do you think about it? Łukasz Improved startup-time is a nice-to-have, but hardly a must-have, especially since our startup-time is not awfully bad. Most of the things on our roadmap [1] is more important than improved startup time. From a GIMP project point if view, it would be better if you worked on items on the roadmap instead. But you are of course free to work on whatever you want. We're not going to ignore a high-quality patch that improves startup time. Regards, Martin [1] http://wiki.gimp.org/index.php/GIMP_Roadmap -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] New schedule for GIMP 2.8
Hi all, I have created a schedule for GIMP 2.8 and put it here: http://tasktaste.com/projects/Enselic/gimp-2-8 Please review the list of tasks and let me know if there are other things than those listed there that you know we need to do before we can release 2.8. In that case I will add those tasks to the schedule. Ideally, all commits pushed to git master should be related to one of the tasks listed there. Being able to make a reasonable estimate for when we can make a GIMP 2.8 release is good for many reasons; one of them is that we need to know when we should enter a string freeze. If no tasks are added and if my estimates are correct, we will release GIMP 2.8 on 2011-10-20. As we all know however, making estimates is hard and 2011-10-20 will not be our release date, but it is the best estimate we have right now. The nice thing with having our schedule on tasktaste.com is that anyone interested in when GIMP 2.8 will be released just needs to visit that web page linked to above to get an overview of how GIMP 2.8 development is progressing and get an updated estimate for when we can make a GIMP 2.8 release. As a side note, I have developed tasktaste.com from scratch during the last few months and the source code is available under the Apache Licence 2.0: https://github.com/Enselic/task-taste / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New schedule for GIMP 2.8
On 04/03/2011 10:31 PM, Eric Grivel wrote: I added a proposed patch to fix Bug 596410 to the bug report a while ago. Do I need to look at that again? Nope, I just haven't had time to look at the patch yet Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] http://wiki.gimp.org/
On 03/31/2011 02:40 PM, Michael Natterer wrote: Hi all, I'm pleased to announce that the new GIMP developer wiki has found its way home and is reachable as wiki.gimp.org now. That's great! I have removed 'GIMP' from the roadmap title now since the domain itself has enough GIMP-weight, the roadmap can now be found at: http://wiki.gimp.org/index.php/Roadmap Thanks a lot to LightningIsMyName and Alexia for starting, hosting, and taking care of the wiki. Indeed, thank you Alexia and LightningIsMyName. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
2011/3/29 LightningIsMyName lightningismyn...@gmail.com: ** Re-Discussing GIMP's programming language ** For core (non-UI), continue using GObject, use code generators (such as turbine) and do copy/paste/replace for existing GObject classes (for the rare case where the generator won't be enough). Hi, Unfortunately I couldn't attend the meeting and affect the outcome of the discussion, but I still want to comment on it: GObject C boilerplate is a general productivity problem not bound to any specific kind of code, it doesn't make sense to treat core and UI code differently. Regarding code generators: that's basically how we will use Vala, I don't see why e.g. turbine would be better to use for this. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
2011/3/27 Michael Natterer mi...@gimp.org: On 03/27/2011 04:45 PM, Martin Nordholts wrote: On 03/27/2011 02:12 PM, Michael Natterer wrote: As to the actual iussue of introducing whatever *additional* language in GIMP, I strongly doubt that it would help us in any way. It would increase the complexity of both building and programming because there would be two languages to learn, it would complicate the build system (new contributors would also have to learn to deal with autofoo makefiles dealing with both C and vala code). It would increase the barrier of getting new contributors into the project, not lower it. It's funny, because I see it the other way around. With infrastructure for and knowledge about how to use Vala in GIMP, the barriers of getting new contributors is lowered, because they don't need to learn GObject C boilerplate before writing code. Assuming of course that most of our code is in Vala already... And this is *exactly* the problem. We would end up with programmers that quickly learnt vala, having no clue about GObject. That's absolutely horrible. Just like the people who only know how to write java or #C code. They know how to use all the fancy classes, but they have never implemented a list or anything lowlevel themselves. I don't want people who know vala, but don't had to learn GObject. Absolutely not. Knowing the foundations is an absolute prerequisite for any serious programming. How is it a problem that our code becomes so easy that even dumb programmers can understand and improve it when we are not forced to include patches from such dumb programmers? Why would an open source project have as a goal to keep its code complex in order to limit the set of people that are able to help out, especially a project that wants more people to contribute? Besides, it is not only dumb programmers that uses higher-level languages such as C# and Java. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
2011/3/27 Kevin Cozens ke...@ve3syb.ca: LightningIsMyName wrote: *** Optional topic: Re-Discussing GIMP's programming language *** Some developers that weren't present in the last meeting, highly disagree on the attempt to introduce vala into gimp, claiming that it will scare off developers (more than the simple C GObject code). Before talking about which new programming language is needed(?) in GIMP we should make sure the problem is clearly defined as to *why* we need something new. What problem is the new language going to solve? IIRC, it had something to do with creation of GUI stuff (such as dialog boxes?). If that is the case, the language should be irrelavant. There are other tools that can be used to more easily make a GUI. One that comes to mind is a tool like Glade that can generate a file that can be used with with a library (GtkBuilder?) to show the contents of the file. I may be completely off base here because I haven't heard a clear definition of the problem. The problem with using C for everything is that we have to spend time on managing boilerplate GObject C code, like manually initialize vtables for example. We could spend this time doing things that benefits our users instead. When I get time, I will port GimpTag to Vala so we can see how the introduction of Vala affects our codebase, autotools etc. If we bump into a lot of problems, we can drop the idea of using Vala in GIMP, but if it turns out we can become more productive by using Vala, we should start using Vala more. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/27/2011 02:12 PM, Michael Natterer wrote: So when you write code, how much time do you spend writing the boilerplate? 10%? I would say it's much much less, because writing the code is a small fraction of the time actually spent on the code, the rest is debugging, refactoring, reading and reading it over and over again. The percentage of writing the actual boilerplate rapidly drops to a few percent. I don't have any exact figures, but it takes enough time to make it annoying. Also don't forget to look at this from the point of view from someone who doesn't know anything about GObject boilerplate code. It is quite an obstacle to climb over, not only to be able to write GObject boiler plate fluently, but also to read it fluently. This becomes especially problematic in the context of temporary contributions such as GSoC, where a substantial amount of the initial time in a project is spent on getting students up to speed on how GObject works. And what are things that benefit our users we could do instead? Thats a complete non-statement. Programming a complex thing like GIMP is hard, no matter how supposedly easy you make the programming language. I meant that instead writing boilerplate, we and others can write code that adds actual functionality. The problem is not the programming language, or GObject, it's simply the complexity of GIMP's object system, and that complexity is unfortunately unavoidable, and is not going to decrease by adding another layer to it. Vala is not another layer, it's just another way to write GObject code where the boiler plate is taken care of by the valac compiler. And I don't see the GIMP object system as very complex, it is what you'd expect for a program like GIMP. I actually often find myself reluctant to add new classes because of all the extra work the boiler plate requires. This isn't a healthy situation; adding new classes should be effortless. I often hear how well the GIMP source is structured, and people point others to GIMP as an example of properly done code. That's a reputation which is not going to improve by adding another fringe language. The GIMP code *is* well structured, but I don't see how that is an argument either way. I don't want to add Vala to bring structure into the code, I want to add Vala to get rid of all the boiler plate code. As to the actual iussue of introducing whatever *additional* language in GIMP, I strongly doubt that it would help us in any way. It would increase the complexity of both building and programming because there would be two languages to learn, it would complicate the build system (new contributors would also have to learn to deal with autofoo makefiles dealing with both C and vala code). It would increase the barrier of getting new contributors into the project, not lower it. It's funny, because I see it the other way around. With infrastructure for and knowledge about how to use Vala in GIMP, the barriers of getting new contributors is lowered, because they don't need to learn GObject C boilerplate before writing code. Assuming of course that most of our code is in Vala already... / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Developer Meeting #3 - March 28, 2011
On 03/25/2011 02:31 PM, LightningIsMyName wrote: *** Other topics *** Any other suggestions should be suggested by replying to this email, or adding it directly to the wiki (if you have permissions to edit the wiki). Hi, What's the status of making wiki.gimp.org resolve to gimp-wiki.who.ee so e.g. the roadmap URL becomes http://wiki.gimp.org/index.php/GIMP_Roadmap rather than the current http://gimp-wiki.who.ee/index.php/GIMP_Roadmap ? Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK file export plug-in
On 03/22/2011 01:37 AM, Jacek Poplawski wrote: On Mon, Mar 21, 2011 at 11:30 PM, gespert...@gmail.com gespert...@gmail.com wrote: Most of the people ask for CMYK because: I need CMYK support for photo retouch, to create better colors. CMYK is no different than LAB, HSV or RGB. It is colorspace like others, but uses 4 channels instead 3. CMYK is fundamentally different than LAB, HSV and RGB. In order for RGB values to make colorimetric sense, meaning that the CIEXYZ tristimulus values are known, all you need to know are the primaries and the white point used. The tristimulus values for a set of CMYK values depends on the characteristics of the pigmets, the pattern in which the colorants are arranged on paper, the order in which they are applied, the illuminant used, the characteristics of the paper they are applied on, and even the age of the print. Another difference of the CMYK color space compared to e.g. RGB is of course it's subtractive nature, meaning that as you increase CMYK values, the resulting color will be darker, whereas with RGB, larger values means a brighter color. HSV is just a different representation of RGB values, and LAB values makes colorimetric sense by themselves, without any additional information. That CMYK is fundamentally different than light based additive color spaces is the reason why GIMP developers considers CMYK somewhat of a special case we can take care of later, we first need to make a program that is powerful in the additive color space world. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK file export plug-in
On 03/22/2011 08:25 AM, Jacek Poplawski wrote: On Tue, Mar 22, 2011 at 8:19 AM, SorinNnemes.so...@gmail.com wrote: Jacek - you don't need CMYK for photos [I need CMYK support for photo retouch, to create better colors]. I am familiar with this opinion. I don't want to continue offtopic discussion in this thread, so I just give one example: curves. You can get more interesting retouch when using curves in CMYK and in LAB and in RGB than using only RGB curves. You can get more data from shadows by using K curve in CMYK for instance. You can increase contrast without touching the colors by using L curve. etc We are talking about techniques to retouch photos on a mailing list for the development of an image editing application, so this is not offtopic. Why would you transform to CMYK to lose color information just so you can increase the K value, rather than making a lossless transformation into LAB and decrease the L value? Note that with GEGL, we will easily be able to have adjustment layers that work on the L component in CIELAB. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK file export plug-in
On 03/22/2011 08:20 AM, Martin Nordholts wrote: LAB values makes colorimetric sense by themselves, without any additional information. Correction: For CIELAB values to make colorimetric sense, it is necessary to also know the reference white point. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK file export plug-in
2011/3/22 Jacek Poplawski jacekpoplaw...@gmail.com: CMYK is also best colorspace for skin color retouch by numbers, No it isn't, because unless you go through a lot of extra work to avoid it, colors in the image that the used CMYK color space is unable to represent will get lost. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] How to best use Bugzilla
Hi, I think we should discuss how we make best use of Bugzilla. Except for tracking bugs, I'd like us to use bugzilla for a) Keeping track of what is important to fix for a given release b) Keeping track of what bugs among all our bugs we consider important to fix, but not more important than working on things on our roadmap I'd like to use milestones [1] for a) , and priorities [2] for b). Does this sound reasonable to everyone? Would be good to agree on this before we start updating lots of bugs. / Martin [1] https://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=2.8 [2] https://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDpriority=Highpriority=Urgent -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode Color
2011/3/16 Carol Spears ca...@gimp.org: martin, if in, oh, lets say 3 days, March 18, 2011 the majority of your list items are not commited, perhaps you should consider stepping aside. releases don't attract developers. look at the history! gimp-1.0 - gimp-1.2, 1997 thru 2000. lots of contributors, lots of development, lots of ideas, lots of bug fixing. it was a lot of fun. sometimes, you gotta quit -- and see if that helps things. i sure didn't like what was going on, i needed to be forced to quit. so, okay fine, i quit for more than two years, maybe more than three and you know what? the problem wasn't me because all of the things that i did not like persisted and there was no improvement in involvement -- in fact, involvement (especially by people who can fix bugs and have some knowlege of gimps innards) dropped off. i cannot force you to quit the way i was forced to quit. i can only ask you to consider this and also that before you quit, that you removed the buildbot stuff from gimp's source and put it into eh, lets say buildbots source on the same server. that way, other projects can become rejuvinated with buildbot product the way that gimp has been. i was told that it was a gnome project afterall... Hi Carol, Thank you for sharing your concerns. I will quit when the majority of contributing members of the GIMP community wants me to quit. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode Color
2011/3/16 Charlie De charlieco...@yahoo.com: Martin, with all due respect, your focus in releasing 2.8 ASAP should be on integrating fixes that are completed, not battling to bring in new functionality such as layer groups. What's the point of layer groups if the layer transfer modes don't work correctly? More important than that is that a promise is being broken - a promise made to an excellent new talent who came out of nowhere and worked and behaved to the highest standard. The least you could do to encourage his further participation is to fulfill your part of the bargain and let his work see the light of day in the 2.8 release. In preference to layer groups, which could wait till 2.10. My criticism is for the whole team involved in these decisions, I don't wish to single out Martin or ask anyone to quit. Layer groups are already in 2.8, but we can't release 2.8 without fixing some things that users will expect to work and that must work, for example layer masks on a layer group. In other words, this is not about bringing in some new features not including others, it is about bringing our git master branch to a state where there are no incomplete features on it. Avoiding incomplete features on the master branch is crucial if we want to get in control of our currently very long development cycles. And regarding the patch itself: It is not quite as easy as just commiting what we have now and be done with it. Before we can commit a patch like this, it needs thorough review of experienced developers. And by my standards, the patch also needs to come with a test case that verifies that it works, and that it keeps working. So, there is a substantial amount of work left before that bug report can be closed as fixed. It was more than 3 years ago we made a stable release. Just as you point out, we must stop bringing in new features, finish work in progress, and make a release. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release
On 03/14/2011 11:59 AM, Joao S. O. Bueno wrote: Hi, This decision, as I see it, change the release date from within months to within some weeks - May I ask for the calculations that led you to the conclusion that we are weeks away from a release? I haven't done the math yet, but I still expect us to be months away from a release. I hope you have in mind that Translators have to know about so they can update translations as possible, as well. At some reasonable point before the release, a string freeze status for GIMPshould be set (even if a few string chanegs are to happen after that). Thanks for the reminder. We should probably enter a soft string freeze soon... Other than translation, we have to work the Python bindings so there are no functionality regressions, (whch includes the ability to work with layer groups) - so to the above list of bugs, we shuld at least have one more about this task. (this also depends on being able to transform layer groups). Not including API to work with layer groups in Python is not a regression, it's just missing functionality in one of the scripting languages. It is unfortunate if GIMP 2.8 will be released without layer groups support in Python, but the alternative is worse: not releasing GIMP 2.8 at all. And we should arrange for the Python bindings to be automatically generated from the PDB rather than wasting man-weeks on manually keeping it up to date. Not an easy task perhaps, but the only sensible one. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release
On 03/15/2011 10:44 AM, Jon Nordby wrote: On 15 March 2011 07:43, Martin Nordholtsense...@gmail.com wrote: Not including API to work with layer groups in Python is not a regression, it's just missing functionality in one of the scripting languages. It is unfortunate if GIMP 2.8 will be released without layer groups support in Python, but the alternative is worse: not releasing GIMP 2.8 at all. And we should arrange for the Python bindings to be automatically generated from the PDB rather than wasting man-weeks on manually keeping it up to date. Not an easy task perhaps, but the only sensible one. Long term, bindings should of course be generated (or rather be dynamic using pygobject, when/if possible). However I need layer groups exposed for the Python API in order to support layer groups in OpenRaster, so I will probably do these bindings for 2.8. Just need to find the time. Do we have a bug open about this issue? Take a look at Bug 624303 - Introduce an item class in PyGIMP https://bugzilla.gnome.org/show_bug.cgi?id=624303 / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release
On 03/15/2011 12:35 PM, Joao S. O. Bueno wrote: Scripts which previously interated through layers are currently not working. That is a regression. It sure sounds like one, please file a bug report and put it on the 2.8 milestone with a scripts that allows the regression to be easily reproduced. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release
On 03/15/2011 02:12 PM, Alexandre Prokoudine wrote: On Mon, Mar 14, 2011 at 1:59 PM, Joao S. O. Bueno wrote: Hi, This decision, as I see it, change the release date from within months to within some weeks - I hope you have in mind that Translators have to know about so they can update translations as possible, as well. At some reasonable point before the release, a string freeze status for GIMPshould be set (even if a few string chanegs are to happen after that). Speaking of which, I'd love to know what on Earth the reasoning behind putting https://bugzilla.gnome.org/show_bug.cgi?id=556884 off the milestones is supposed to mean. The prerequisite is in place, making the messages translatable is very little work. So why are we going to ship 2.8 with the horrible mix of English/localized UI once again? There are thousands of other small things we could spend time on rather than working on the highest prioritized features dictated by our roadmap. But if we do, it might very well go another 9 years without any support for high bit depths in GIMP. Let's please focus on what's important, and compared to high bit depths, that is not important. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release
On 03/15/2011 06:38 PM, Alexandre Prokoudine wrote: On Tue, Mar 15, 2011 at 8:25 PM, Martin Nordholts wrote: Speaking of which, I'd love to know what on Earth the reasoning behind putting https://bugzilla.gnome.org/show_bug.cgi?id=556884 off the milestones is supposed to mean. The prerequisite is in place, making the messages translatable is very little work. So why are we going to ship 2.8 with the horrible mix of English/localized UI once again? There are thousands of other small things we could spend time on rather than working on the highest prioritized features dictated by our roadmap. But if we do, it might very well go another 9 years without any support for high bit depths in GIMP. It looks like you didn't even bother looking at the bug report in question. Right now all it takes is green lights for someone (e.g. me) to enable the messages for translation and then let translators do their work. With all respect due, what 9 years are you talking about? I did look at it, and I saw that mitch said there was a problem, then you said there wasn't a problem, and now developer needs to verify that there maybe isn't a problem. It is harder to ignore small things like this, but they add up, and as I said: we need to stop working on what is not important and not be trapped in working on things like this. I was referring to the age of Bug 74224 - Add support for 16 bits per channel... / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Bug 325564] Use CIE LCH instead of HSL for layer mode Color
On 03/15/2011 08:47 PM, Charlie De wrote: Why?? Rupert Weber finished this last September and you promised it would be in 2.8. Is this how you show respect for the most stellar effort by a new talent? Shame, truly, shame on you. It's now been 5 years since the issue was first reported, you're going to add another year even though the work is done. That is, if you don't break your promise again. Where's your integrity? If we never make releases, we won't get new contributors either. We really need to make a release ASAP, and we simply don't have time to fix this before the 2.8 release. In modern software development, uncomfortable decisions like this sometimes needs to be made. I am sorry that it upsets you. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Enabling a 2.8 release: planning for a 2.10 release
Hi everyone, As you all know, getting 2.8 out is highest priority right now. There are however some things that we want to fix before we make a 3.0 release. Thus, we must plan for a 2.10 release. I have updated our milestones in bugzilla with this. After the update, there are only 7 bugs on the 2.8 milestone: 642728 - Function `gdk_gc_new' implicitly converted to pointer causes build failure 631766 - Bad performance when moving brush outline on canvas 612931 - Moving individual layer in layer group not possible with Move Tool 603848 - Single-window mode is not properly session managed yet 600554 - Implement layer group transforms 596410 - gimp-image-get-filename returns NULL for imported files 51112 - clipping groups or masking groups (like in Photoshop files) Let's focus our efforts and smash these last bugs so we can make a 2.8 release as soon as possible. To see what we should fix for the 2.10 release, refer to the 2.10 milestone and our roadmap: 2.10 milestone: https://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=2.10 Roadmap: http://gimp-wiki.who.ee/index.php/GIMP_Roadmap / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP vs Photoshop
On 03/08/2011 07:50 PM, Bogdan Szczurek wrote: On Tue, Mar 8, 2011 at 3:12 PM, Bogdan Szczurekthebod...@gmail.com wrote: I also have high hopes for GEGL, but I'd rather have it use some more abstract color model for that. I know it's not so simple—maybe even undoable–that way, but I do like the idea of color model that has complete coverage of visible spectrum. Using a color model with full coverage of the visual spectrum would be an extension along the lines of RGB and the responses of the human visual system/physics, entirely additive. Not entirely along the lines I'm afraid. First of all it strongly depends which RGB we're talking about. Even if we take scRGB into account there's still some considerable parts of visible spectrum that can not be described by scRGB's triad. I know scRGB is tempting for it's quite broad and seems easy to implement in RGB dominated world, but I've got a premonition that using device agnostic color space would pay off more. But again–I don't know that :). If all you want is a color space that can encode all visible colors, i.e. the entire CIEXYZ color space, RGB is fine. Transforming from CIEXYZ to RGB (and vice versa) is a simple matrix multiplication, where the matrix depends on the primaries and white point chosen. It's just that sometimes the RGB components will be negative and sometimes greater than 1.0, but each color that can be perceived by a human can be encoded in such a boundless RGB color space. If you want a color model that doesn't lose the information about the spectral power distribution of the stimulus, then RGB won't do, but from your reply above it doesn't sound like that is what you meant. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding a layer mode
On 03/03/2011 06:03 PM, Jörn P. Meier wrote: very cool. Is this a patch against the git version? Yes, and help with reviewing and testing it for inclusion in GIMP 2.8 would be appreciated. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP plugins to GEGL operations
On 03/03/2011 03:46 PM, Andreas Plath wrote: I started to compile a list of which were implemented, but I think I'd better ask: are all the plugins in the default GIMP bundle already implemented as GEGL operations? If not, is there an easy way to find which are already done? There is no such list yet, it would be great if you could create one which we can put up on our wiki. The only way to find out if a plug-in has a GEGL operation version is to look for that GEGL operation in the GIMP and GEGL source trees. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Adding a layer mode
On 03/03/2011 02:00 AM, Jörn P. Meier wrote: Hi, I would like to implement the following layer mode in the GIMP: 1) Transform destination and source pixels to HSL space. 2) Note original destination pixel saturation. 3) Set luminance component of destination pixel to luminance component of source pixel. 4) Transform destination to HSV color space. 5) Set saturation of destination pixel to original saturation of destination pixel. I'm assuming destination is also the result of the operation. Not sure how GIMP handles this, though. The purpose of the mode is to colorize a greyscale image while keeping both the saturation and hue data of the color layer and the luminance data of the greyscale image. Existing modes (as far as I see) unfortunately either mess up the color information or the luminance information. So, the question is, what changes would I need to make to add this layer mode? I would be very grateful for any hints. :) There is already a patch for that (using the CIELCH space instead), see the most recent patch in https://bugzilla.gnome.org/show_bug.cgi?id=325564 / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Porting GIMP plugins to GEGL operations
On 03/03/2011 07:21 AM, Bill Skaggs wrote: Let me start by noting that although I was once pretty familiar with the Gimp code, I haven't looked at it in a couple of years. That being said, this discussion is not making sense to me. Plug-ins do not access Gimp core functionality directly, they use an interface library known as libgimp. Hi Bill You got it all wrong: porting GIMP plug-ins to GEGL operations is about exactly that: replacing GIMP plug-ins with GEGL operations. It is not about making libgimp GEGL-aware. Instead of http://git.gnome.org/browse/gimp/tree/plug-ins/common/pixelize.c we want http://git.gnome.org/browse/gegl/tree/operations/common/pixelise.c Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/01/2011 03:23 PM, Michael Grosberg wrote: Congrats! this is a much-needed step. Can I ask what non-destructive editing is? According to Adobe, this includes: * Color adjustment layers (such as levels, hue/saturation, threshold, etc) * filter layers (such as blur, sharpen, emboss, etc) * smart objects (i.e., ability to scale / rotate a layer as a single object, without changing its pixel data) Maybe this could be expanded upon and prioritized. I also have a couple of suggestions for things to put on the roadmap: * change the floating selection behavior so that float and un-float can be automatic and not need user's explicit input. * Automate layer boundary management so that the user can draw on any point at any time and not worry about increasing the boundary * unified transform tool (I remember seeing plans for that last item on Peter sikking's Blog) So, what do people here think? I believe all three are essential in making GIMP a faster and more hassle free tool. I can expand on these subjects if needed. Thanks, I've added your items as well as mapped features into GIMP releases up to GIMP 3.8. (I implicitly include both 'color adjustment layers' and 'filter layers' under Adjustment layers.): http://gimp-wiki.who.ee/index.php/GIMP_Roadmap / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/02/2011 04:33 AM, GSR - FR wrote: Hi, ense...@gmail.com (2011-03-01 at 2214.48 +0100): Thanks, I've added your items as well as mapped features into GIMP releases up to GIMP 3.8. (I implicitly include both 'color adjustment layers' and 'filter layers' under Adjustment layers.): http://gimp-wiki.who.ee/index.php/GIMP_Roadmap Please pick a different name that trully combines both things then, assuming they are combinable. Adjustment layers is already a standard term (de facto from another app, yeah, impossible to change that now) for a layer that only has a mask and applies per pixels changes like hue or level changes. Not only confusing, but hard to see the relation between adjusment and render grid, for example, which is probably what you mean with filter. Thanks. I've changed Adjustment layers to 'Layer filters' for now, and added Layer effects. Ideas for better names are welcomed. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP developer meeting
On 02/28/2011 07:02 PM, Sven Neumann wrote: On Mon, 2011-02-28 at 19:38 +0200, Alexia Death wrote: Wiki needs an admin that cares, a database and php installed on the server. AFAIK there is no gimp host that meets all those requirements, specially the admin part. Well, the machine that hosts www.gimp.org meets all those requirements. It has database and PHP installed and if anyone volunteers to become the admin that cares, it's no problem to add accounts on the machine. Why don't we migrate gimp-wiki.who.ee to gui.gimp.org and call it wiki.gimp.org instead? Seems unnecessary to administer two wikis. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Roadmap - wiki page
On the developer meeting I got an action to create a draft of a roadmap. It can be found here: http://gimp-wiki.who.ee/index.php/GIMP_Roadmap It has has a list of features we prioritize, as well as a list of at what GIMP release we expect features to be available. It is quite influenced by my personal opinions of what we should prioritize, please take a look and add things you miss. If you disagree on priorities, please bring it up here so we can discuss it and reach consensus. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP developer meeting
On 02/28/2011 12:07 AM, LightningIsMyName wrote: Hello, Today (February 28, 2011), at 10pm CET (for time zone conversions, see http://www.timeanddate.com/worldclock/fixedtime.html?month=2day=28year=2011hour=22min=0sec=0p1=48 ) a meeting of GIMP developers is scheduled on the GIMP developer IRC. On the list of topics: - GSoC 2011 - ORG Application deadline is in 11 days! - Bug fixing priorities - Future development? Good initiative. I'd like to add to the agenda: - Create a roadmap at http://gimp-wiki.who.ee/ - Make http://gimp-wiki.who.ee/ the official wiki, e.g. make wiki.gimp.org point to it / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Development environment
Tool: Emacs + https://github.com/Enselic/enselic-home/tree/master/elisp Direct compilation: Yes, with M-x compile and M-x flymake-mode Code completion: Kind of, Emacs supports tab-completion for symbols in all buffers, so if I have the relevant headers open, I have tab-completion for e.g. all gtk_ functions. Not the best code completion, but you come pretty far with it. Documentation browser: I use exuberant-ctags for symbol definition lookup, so to get to the documentation of a function, I usually go to the declaration/definition of it using the exuberant-ctags indexes. I also occasionally use devhelp, but that's an external program. Debugging: Yes, M-x gdb Refactoring: No, unfortunately not. / Martin -- My GIMP Blog: http://www.chromecode.com/ Why GIMP 2.8 is not released yet ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code 2011 - Project Ideas/Suggestions
On 02/13/2011 12:04 AM, LightningIsMyName wrote: I'm starting this thread to list ideas for Google Summer of Code 2011, for the GIMP project. Since in the last year collecting ideas was done partially by the mailing list, let's try it again this year and keep most ideas here. Thanks for a good start on this Barak I would like to add: Port UI code to a non-low level language Hacking UI code in C is a resource eater for us, we should use C for quick and efficient pixel processing but not for creating buttons. It would be interesting to make changes to the GIMP codebase that would allow us for example write the Pointer Information Dialog in JavaScript. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Nightly builds moved to Jenkins (Hudson)
Hi everyone I got tired of managing our BuildBot(s), so I decided to switch our continuous integration tool to Jenkins (formerly known as Hudson). You find our Jenkins at http://gimptest.flamingtext.com:8080/ The main benefits are: * An order of magnitude easier to configure and maintain. All configuration happens through the web interface. * Has its own account and login system, no need for accounts on the host machine. * One Jenkins for all our projects vs one buildbot per project * Mails with last build log lines and list of changes since last build works out of the box. That is quite a bit of work to get working with buildbot, so much that I gave up on it. In a few days I will make failures be posted to gimp-developer, I think that is good to do if the mails contains logs and list of changes. The nightly tarballs can now be reached both through HTTP and FTP with permanent URLs: babl: ftp://gimptest.flamingtext.com/pub/nightly-tarballs/babl-git-master.tar.bz2 http://gimptest.flamingtext.com:8080/job/babl-distcheck/lastSuccessfulBuild/artifact/babl-git-master.tar.bz2 GEGL: ftp://gimptest.flamingtext.com/pub/nightly-tarballs/gegl-git-master.tar.bz2 http://gimptest.flamingtext.com:8080/job/gegl-distcheck/lastSuccessfulBuild/artifact/gegl-git-master.tar.bz2 GIMP: ftp://gimptest.flamingtext.com/pub/nightly-tarballs/gimp-git-master.tar.bz2 http://gimptest.flamingtext.com:8080/job/gimp-distcheck/lastSuccessfulBuild/artifact/gimp-git-master.tar.bz2 To simplify configuration, I wrote a simple 'GNOME Project Builder' Jenkins plug-in that can be found here: https://github.com/Enselic/gnome-project-builder Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] Where can I help?
On 02/07/2011 01:33 PM, Patrick Horgan wrote: On 02/06/2011 10:52 PM, Martin Nordholts wrote: On 02/07/2011 04:48 AM, Patrick Horgan wrote: I'm trying to come up to speed on gegl and built the hello-world.c example from the examples directory. The text from that example doesn't show up on the output, although the mandelbrot zoom works wonderfully. Is there anything I can do to figure it out? Can someone point me toward something to read to understand where things are going on? One thing you can do is to run with the env var GEGL_DEBUG set to process. That will give some output on how things are processed in the graph. Does the output for the text node look weird? / Martin btw, forgot to say this is on Ubuntu using gegl and babl from git trunk and gcc 4.6 Could it be where it says: Using cache for pad 'output' on gegl:text 0x9017e90 Yes maybe, caches don't always work like they should. If you disable that code, does it become better? You can also set a breakpoint in process() for text and see that the thread of execution looks reasonable when you single-step through the code. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] application
On 02/04/2011 07:59 PM, Nicolas Brack wrote: Hello, I'm responding about the advertisement Plans for 2.8 and beyond to help the team to freely code gimp. Here is a little resume : Hi Nicolas! Thank you for your mail. However, you're not applying to a job, and a resume won't help us much. What matters is that you write good code ;) So I suggest you look for something you'd like GIMP to do better, then start working on that. If you bump into problems, feel free to ask for advice on this list. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] application
On 02/06/2011 05:51 PM, Michael Grosberg wrote: Martin Nordholtsenselicat gmail.com writes: So I suggest you look for something you'd like GIMP to do better, then start working on that. If you bump into problems, feel free to ask for advice on this list. Isn't there some prioritized task list for Gimp? I believe GEGL integration is currently the highest priority task, isn't it? Almost; it's second. Getting 2.8 out is number one. But to recommend our friend Nicolas specific tasks to work on, I need to get to know him as a coder first. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gegl-developer] Where can I help?
On 02/07/2011 04:48 AM, Patrick Horgan wrote: I'm trying to come up to speed on gegl and built the hello-world.c example from the examples directory. The text from that example doesn't show up on the output, although the mandelbrot zoom works wonderfully. Is there anything I can do to figure it out? Can someone point me toward something to read to understand where things are going on? One thing you can do is to run with the env var GEGL_DEBUG set to process. That will give some output on how things are processed in the graph. Does the output for the text node look weird? / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Wrong tools contour
On 02/03/2011 05:59 PM, Alexia Death wrote: On Thursday, February 03, 2011 18:10:21 Nelson A. de Oliveira wrote: On Thu, Feb 3, 2011 at 2:32 PM, Alexia Deathalexiade...@gmail.com wrote: On Thu, Feb 3, 2011 at 2:50 PM, Nelson A. de Oliveiranao...@gmail.com wrote: I don't know if it's a know issue, Im sorry, but I find this question a bit annoying. It's a big issue smack in the middle where you cant miss it. Of course its known. So users will have to always stay in doubt if one issue is known or not, because it annoys to ask? Users arent supposed to use GIT versions. Git versions are for developers and often conain incomplete features. This is how it _has_ been, but to make GIMP more fun for both developers and users, this needs to change. The change we need to make is to develop things on feature branches and merge them to git master when they are ready. That way we can make releases much more frequently than every 2 or 3 years. Making frequent releases is one important part in attracting contributors. How fun is it to contribute a feature to a project when the feature won't be widely used until after 3 years? So to be a bit harsh: the error here was that git master broke, not that a user wanted to help by pointing it out. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
On 01/27/2011 10:43 PM, Eric Grivel wrote: I am getting the impression that the Gimp project is trapped in a chicken-and-egg problem with regard to attracting new contributors, where the few core developers are too busy maintaining the product to spend a lot of time helping new developers come on board. To be honest, I don't recall a single instance of when a question about the code has not been answered (when developers have been around). If you are unable to get in touch with core developers on IRC, feel free to use our mailing list instead. It's just that it has to be new contributors driving the core developers, not the other way around. Gimp is an extremely large and complex system. I am a fairly experienced coder myself, and have recently submitted patches for two open bugs. But those were easy ones, not really related to any Gimp structures but basic C bug fixing. I have looked at some of the other outstanding bugs and for most don't have a clue where to start, or how to make sure that my fix fits in the vision, or that it doesn't break something else. This is exactly why I have been setting up a nightly builder and trying to get everyone to write more regression tests: to make GIMP a less scary project to work on. If people can be confident that if they break something, our nightly builder will discover that, then people wouldn't be so afraid. I believe our biggest development-technical mistake right now is that people don't write regression tests for new functionality they add. It is kind of boring and sometimes hard, but the long term effects of consistently doing this is priceless. Our nightly builder is found at http://gimptest.flamingtext.com:8012/waterfall which curiously enough failed this night to my changes yesterday, but I fixed that already... At this point, knowing how busy the core Gimp developers are, and recognizing that it will take more time for them to walk me through a problem and a solution than it would take them to just fix the issue themselves, I am hesitant to ask for a lot of help. On the other hand, the idea of just delving in and figuring it out myself is quite daunting. Please please please don't hesitate asking for help, the worst thing that can happen is that you are ignored ;) But don't underestimate the value of being able to understand code all by yourself. It takes some practice, but that skill is generic and will make you a better programmer in general. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
On 01/28/2011 12:56 AM, Stephen Greenwalt wrote: It is huge. Incredible, actually. Who wrote all of this? Wow. To see who wrote all this, visit https://www.ohloh.net/p/gimp/contributors A few comments: * It seems to work best to put the entire project (all source, and all build product) under a project folder in the Home directory. * If possible, that should include a /copy /of any external dependencies . . . with environment variables (etc) adjusted accordingly * The project ought to be able to exist in a *bubble* . . . so as to avoid confusion . . . regarding copies of dependencies that might exist in the OS. I've tried quite a few different setups, and I find this to be the best: http://www.chromecode.com/2009/12/best-way-to-keep-up-with-gimp-from-git_26.html * Multiple different project versions ought to be able to exist on the same machine without stepping over each other. As have already been pointed out, you can already do that, just use different --prefix:es * If we do it right, compiling for Linux vs. Windows vs. OSx ought require no more than the flip of a switch. The Blender folks, and others, are moving in that direction. I agree, we should make nightly .rpm, .deb, .exe and .dmg builds. Quite a bit of work left to get there though. * Shouldn't we standardize on a common development IDE (like Eclipse)? If I am missing something in that area . . . let me know. If you want a good IDE I recommend Qt Creator. If I were to start fresh today, I would probably use Qt Creator instead of Emacs. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer Boot Camp?
On 01/28/2011 05:01 AM, Michael J. Hammel wrote: * Shouldn't we standardize on a common development IDE (like Eclipse)? If I am missing something in that area . . . let me know. IDE's are crutches. Based on the source tree I don't think the developers use them but I could be wrong. I don't even use IDEs for Java programming. Unless you include cscope as an IDE. Don't bog down in the tools. Open the file and read it. That's how you learn code. Hi Hmm I don't understand your reasoning. So you rather waste time manually refactoring Java code than using Eclipse' excellent integrated reafactoring features? Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
On 01/25/2011 09:35 AM, Stephen Greenwalt wrote: Where can I help? It would be great to get help with bugs put on the 2.8 milestone: https://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=2.8 Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC 2011 announced
On 01/25/2011 05:52 AM, Alexandre Prokoudine wrote: Google has just announced GSoC2011. Schumaml: Will you be our GSoC master this year too? If so, that would be great. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Where can I help?
On 01/26/2011 06:55 AM, Stephen Greenwalt wrote: Here's one suggestion that you could probably work on immediately, and would prepare you to work on other things if you are interested. Gimp has a plug-in called Lighting Effects Thanks for the info. I have used that filter many times, and I will take a look at what you describe. Thank you for the offering. I would like to point out though that it would be even more helpful in the long term if the plug-in was ported to a GEGL operation so that we can use it when GIMP does its processing in linear light 32-bit RGBA. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Team Organization?
On 01/26/2011 08:15 AM, Stephen Greenwalt wrote: I have been reviewing Gimp / GEGL source code . . . to get familiar with everything . . . so that I have some context to understand where I might help the project. But I am operating in a void because I don't understand: * How the development effort is organized. o Is there a team leader? Strategic decisions are taken in concert, although due to human nature, the opinions of some individuals have more weight depending on their reputation. We have two official maintainers, cat MAINTAINERS. o What tools, etc. are being used to manage things such as: + Feature requests, bug reports, etc. We prefer feature requests on this mailing list, so that they can be discussed and evaluated, in particular in the context of our product vision [1] Bug reports are managed in GNOME Bugzilla [2] + Component development. In general, all development happens on the git master branch directly, although personally I think we should review our development methodology for GIMP 3.0 because we have problems in our 2.8 development cycles due to this. + Testing. I have a long term goal of improving the GIMP development environment, and have lately put efforts into writing regression tests for both old and new functionality, and I have been setting up a nightly builder that runs all our tests [3]. Curiously enough, you'll notice make distcheck failed tonight due to changes yesterday, but I already fixed that... * What the development priorities are, and where programmer resources are needed. Right now, the priority is getting GIMP 2.8 out. The two major work areas left is finishing the implementations of layer groups and single-window mode, see [4] for the main missing bits. After that, we will start working on GIMP 3.0, which will be GIMP 2.8 running on GTK+ 3.0 and using GEGL-buffers for all data. That is, we will throw out our 8-bit only image/tile data structures. For GIMP 3.2 we will start looking into serious support for non-destructive editing. The main Gimp website says that the new priority is expansion of the GEGL engine. But, does that mean that major feature development for main Gimp app is being stopped until the GEGL engine is ready? See above I, for one, love Gimp but would really like to see one or new features such as: * Support for sub-layers (i.e. nesting of layers in tree-style control). Fundamental support for that is already in place in git master * Ability to delete multiple layers at the same time, rather than one-by-one. Yes that would be nice, but support for higher bit depths and non-destructiveness has higher priority * Layer-by-layer history . . . so that you can undo changes within the current layer only. Sounds like a work-around for GIMP not having non-destructive editing yet Should I offer help in those areas? Any help is greatly appreciated. Best regards, Martin [1] http://gui.gimp.org/index.php/GIMP_UI_Redesign#product_vision [2] http://bugzilla.gnome.org/browse.cgi?product=GIMP [3] http://gimptest.flamingtext.com:8012/waterfall [4] https://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDtarget_milestone=2.8 -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Submitted patches for bug 596410
On 01/23/2011 09:11 PM, Eric Grivel wrote: Hi, I submitted a series of patches to bug 596410. This is my first time working on Gimp and I'm new to git at well. I am very open to suggestions on how to do things differently (better). Hi and thanks, I'll review them soonish. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP icon quot; stolenquot; by commercial Symbian software on sale at Nokia app store
On 01/21/2011 06:37 AM, Ilgaz Ocal wrote: I got my lesson second time for attempting to help an open source project in a positive manner. Hi Ilgaz Don't take one unfriendly reply from an arbitrary person as a representative reply from everyone. There are many of us that appreciate that you want to help us out. Thank you for that. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why GIMP is Inadequate
On 01/13/2011 01:39 AM, Malix wrote: Hi all, on this blog there is a post about Gimp that generate a lot of user comments. http://troy-sobotka.blogspot.com/2011/01/why-gimp-is-inadequate.html I think that someone of you that can replay to false things must post a replay. Bye Massimo To me, most of his criticism is legitimate. I don't agree with all of it, but it's not all false. I don't see the point in treating him as hostile; it just help him prove his point that we can't take criticism. If we keep improving GIMP and stick to our plan, I am confident we will eventually address all of the shortcomings he points out. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On 01/06/2011 08:32 AM, Olivier wrote: 2011/1/5 Martin Nordholts ense...@gmail.com mailto:ense...@gmail.com That is not necessary, the reason I haven't hacked on GIMP the last two months is that I am working on a website which will allow people to easily track progress of GIMP development (or any project for that matter). I expect to be back working on single-window mode in 1-3 months. What could be the implications on the date of the future release of version 2.8? We want GIMP 2.8 out as soon as possible. Achieving that goal with be easier with a tool which will allow us to track progress of development, since problems can be spotted early, making them easier to resolve or mitigate. The effect on GIMP 2.8 development as well as future GIMP versions will be positive. It will also be easier for external parties, for example book authors that tries to align book publishing with releases of new GIMP versions, to see if development is progressing as expected. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] donations for GIMP 2.8
On 01/06/2011 11:01 PM, Sven Neumann wrote: I just wanted to let you know that we have seen a dramatic increase in donations since then. More than 120 people donated over the last 8 days and sent us about 2,500 dollars. Perhaps it would be a good idea to discuss how we can actually use this money to make the GIMP 2.8 release happen soon... Here are some examples of what I think blocks a GIMP 2.8 release: * Finish single-window mode * Make layer masks work with layer groups * Bug 596410 - gimp-image-get-filename returns NULL for imported files * Bug 597117 - impossible to drop a group as a sibling inside a group * Bug 612931 - Moving individual layer in layer group not possible with Move Tool * Bug 600554 - Implement layer group transforms * Bug 624303 - Introduce an item class in PyGIMP * Bug 630748 - display filters do not work * Bug 631766 - Bad performance when moving brush outline on canvas One natural use of money donated specifically to speed up a GIMP 2.8 release would be in the form of bounties for fixing bugs that blocks GIMP 2.8 from being released. I know we have a history of disliking bounties, but as far as I know we never really tried, and now we have money more or less ear-marked for this purpose. We must not put bounties on things with vague scope like Finish single-window mode, that won't work. We can only put bounties on things where the work to be done is well-defined, like for * Bug 596410 - gimp-image-get-filename returns NULL for imported files If the work to be done in order to get the bounty is unclear, we *will* get into problems. I also think bounties shall only be claimable by people who would not do the work if there wasn't a bounty. For example, I won't and can't claim the bounty if I fix bug 596410, since I would have fixed it long ago if my spare time was infinite. One tricky question is what the size of the bounty should be for each bug... Let's discuss that if we can agree on that we want to try bounties at all. I think it is also worth to contemplate why we are in this situation where we want to make release, but can't because there's too much work left to do. The reason we are in this situation is because we develop features on the branch we make releases from. If things don't go as expected, like the case has been for single-window mode for example, we don't have any place to make releases from. The solution to this is of course to develop big features on feature branches. Basically, it should not be allowed to commit code to git master that is known to put the branch in an unreleasable state. We'll have good reasons to revisit this topic when we start working on GIMP 3.0... / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On 01/05/2011 07:19 PM, Simon Budig wrote: What currently is needed is some more work on the single-window mode. AFAIK there are some bugs in there and Martin (Enselic) can no longer dedicate as much of his time to it as he used to. It would be awesome if this work could be picked up and continued, That is not necessary, the reason I haven't hacked on GIMP the last two months is that I am working on a website which will allow people to easily track progress of GIMP development (or any project for that matter). I expect to be back working on single-window mode in 1-3 months. / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On 01/04/2011 08:25 AM, しげっち wrote: Hi, all. I'm recently implementing a GUI features that is inspired by the ideas of the GIMP UI brainstorming. I hope these features to be included or merged into the master branch in some future. So I inform you the patch here. If you're interested in the patch, please discuss about it. The patch is maintained by git, and published at following site. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=summary This patch implement several features like: * horizontal toolbar with many tool options. (http://gimp-brainstorm.blogspot.com/2009/07/blog-post.html or http://gimp-brainstorm.blogspot.com/2009/07/gimpscape.html) * much sophisticated brush panel (http://gimp-brainstorm.blogspot.com/2009/12/brush-panel.html) * dynamics editor with side tabs (http://gimp-brainstorm.blogspot.com/2009/12/brush-dynamics-curves.html) * vertical dock and image tabs for single window mode. (http://gimp-brainstorm.blogspot.com/2010/10/vertical-menu.html) * dock folding features. I think this feature is necessary for single window mode. This patch is based on the current master branch of the git://git.gnome.org/gimp. It modified many source code of the existing codes, but it does not delete any features that is available in the master branch. Thanks, -- sigetch. Hi sigtech That's some very interesting work and we should work on merging what makes sense to merge to GIMP git master. A word of warning though: not everything posted on the gimp-brainstorm blog is suitable to be actually implement in GIMP, so all your patches might not make sense to merge. A couple of early comments on your code: Add toolbar for tool-options to GimpImageWindow. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=13c321f2db36bae52b23d4264dee242827bb801c Rather than adding a widgets at the top of the GimpImageWindow taking up precious horizontal image space, we should work on moving tool options to on-canvas in an elegant way. Adding another tool-options area gives less space for image content and more space is taken by widgets, which is not the best trend. - G-Pen algorithm is ported into GIMP trunk. Now smoothing function works for Ink... http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=070fc064271f0b359ccdc9ad06466eeb3c1bc3ed Looks like something we might want, some paint tool hacker should look closer at it. Alexia? Mitch? Initial import of color blending function for smudge tool. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=1b83ecae173641b0b08bccd0b207457bb549f9e6 It doesn't look like you change shade_pixels() and shade_region() in a backwards compatible way. Don't you break other things with that change? Otherwise it looks like a change we would want to merge. It would be a good idea to split this commit up so that there is one commit per bullet-point in your commit message. * Some parameters in the toolbar can be edited using popup editor. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=2d5edbfe2fbba08ab4cf456586d5344a3c3a49cc If I understand your code correctly, you are replacing big widgets with smaller widgets that expand when you use them. Worth looking into further. * GimpDock: GIMP dock column folding is implemented. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=01c5590e9566d7f9f7fe2b8112e570a26cb3ac4c Another interesting change, I'll look closer at it when I get back at hacking on single-window mode. [various bug fixes and additions to earlier commits] For review purposes, it would be good if you squashed fixup-commits with commits they fix, so upstream reviewers just need to review one patch. Best regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] nightly builds of the manual (buildbot)
On 12/07/2010 03:39 AM, Roman Joost wrote: Hi, I've got a positive reply to include a nightly build of the manual on the GIMP buildbot a few weeks ago. In the mean time I created a snipped and tested it on my own machine: f1 = factory.BuildFactory() f1.addStep(buildbot.steps.source.Git(repourl=git://git.gnome.org/gimp-help-2, mode=update)) f1.addStep(ShellCommand(command=[./autogen.sh, --without-gimp])) f1.addStep(ShellCommand(command=[make, html])) Note: This will occupy quite a bit of disk space. On my buildbot where I tested the snippet it was occupying about 710 MB. Questions: * Is it possible to synchronise the build artifacts (the generated HTML or other formats) with wilber? If so it would make sense to add more steps. Hi It seems a bit too risky to push every build to wilber, at least in the beginning. Assuming we don't do that for now, is the important thing for you just to see if the build completes without errors? Just double-checking. If that is the case, I'll set up a buildbot doing the steps above. I can't promise to do it immediately though. Cheers, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a reset...
On 11/27/2010 05:02 AM, Alexandre Prokoudine wrote: On 11/23/10, peter sikking wrote: GIMPsters, just FYI, but to escape out of a backlog of 641 GIMP devlist emails waiting for me with ever more not-so-trivial-as-one-thinks UI issues waiting for me, I had to set them all to read, and jump in again. on a more positive note, in order to get some UI work moving for GIMP again, I am in the process of creating (and paying for) two internships at my company. These two apprentices will work by default on GIMP under my direction. Hi Peter, I'm a bit surprised nobody commented so far :) All I had to say was That's great! and I figured peter already knew that so I didn't bother :) / Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Is anyone interested in aforementioned gradient editor improvements?
On 11/19/2010 11:14 PM, Bart Kelsey wrote: I joined this ML because I was advised that there would be interest in discussing the gradient editor UI. Understand that I'm not trying to put pressure on anyone to talk about it, but no one seems particularly interested in picking this up, and, as I said, it's a suggestion that I (as a regular user with a huge project of my own) don't personally have time to flesh out into a full spec. I'd be happy to stay if someone would like to discuss it, but in general there isn't much point in me being on this mailing list apart from this particular bug report, so if there's no interest I'm going to unsubscribe. If any devs would like to pick this up, please let me know and I'll stick around. I'm a bit ashamed to not pick this up now that the topic is current again, but I feel there are more important things I need to focus on. I'll be sure to let you know when an improved gradient editor is high on the list of priorities again. Regards, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Major UI issues with gradient editor (and suggestions for fixing them)
On 11/16/2010 07:16 PM, Bart Kelsey wrote: While I appreciate that GIMP's gradient editor is highly capable, the advanced features are set up in such a way that creating a simple gradient quickly is next to impossible. This is a major usability problem. I would suggest the following changes in order to remedy this: Hi Just a hint: Suggestions for UI improvements will be a lot more punchy if you provide mockups and other graphical diagrams. The most preferable form is a complete UI spec like the ones found at gui.gimp.org. BR, Martin -- My GIMP Blog: http://www.chromecode.com/ Nightly GIMP, GEGL, babl tarball builds ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
