Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Wed, 7 Nov 2007 04:03:51 +, Karl Günter Wünsch [EMAIL PROTECTED] wrote: So you suggest that the GIMP is changing the orientation tag when it is loading the image. This is mandatory according to the EXIF specification. A program that supports EXIF and wants to display the image correctly must load the image according to the orientation specified in the EXIF Orientation tag (this may involve rotation and/or mirroring) and must then clear the tag to indicate that pixel data is now having the same orientation as the image that it represents. Section 7.4 Application Software Guidelines of the EXIF specification explains that several tags must be updated by any software that saves an image containing EXIF information: Orientation must be set to 1 (the default top-left orientation) after rotating or mirroring the pixel data as appropriate, Software must be set to the name of the program that saves the image, DateTime must be set to the current date and time, YCbCrPositioning must be set according to how the data is saved, etc. If the resolution of the image has changed, then tags like XResolution, YResolution and ResolutionUnit may also have to be updated. What then happens if later I decide to rotate the image again manually? If you want to go there, you are opening up a whole new set of possible scenarios which will end up confusing users and other programs. This is not confusing at all. This is how all programs should behave. If the Orientation tag is set to any value other than 1 (top-left), then it means that the pixel data is not in the same orientation as the image that it represents, and any EXIF-compatible software that loads the image must rotate it. To simplify things a bit, the Orientation tag is just a way for a camera to say: hey, I'm a camera with limited memory buffers and I could not save the pixel data correctly, so please rotate the pixel data as appropriate when you load it so that you can display the image as intended. I always understood the question so that I either want to ignore the rotation flag or not but that the EXIF would stay untouched, no matter what I decide there... No, that's wrong. And that's one of the reasons why I want to remove this confusing question. The EXIF standard defines precisely the list of tags that must be updated and the list of tags that must be copied unchanged. Unfortunately, older GIMP versions were violating that standard by copying the whole EXIF block unmodified and this caused many problems, including images having the wrong orientation. EXIF in an edited image has little resemblance with the original anyway, so I would suggest stripping that except for the IPTC tags. I would also be happy if the IPTC tags were settable in the GIMP, instead of having to resort to other programs. IPTC tags are not part of EXIF. They are a different set of tags that are stored in another JPEG APP marker. The ability to edit and save them may be included in GIMP 2.6. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
Von: Raphaël Quinet [EMAIL PROTECTED] This is mandatory according to the EXIF specification. Just as a side note: it's Exif, not EXIF. http://en.wikipedia.org/wiki/Exchangeable_image_file_format Not really important for the discussion, but I do suggest that we do it right from the beginning. SCNR, Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.6 roadmap: metadata and jpeg plug-in enhancements
On Friday 09 November 2007, Raphaël Quinet wrote: No, that's wrong. And that's one of the reasons why I want to remove this confusing question. The EXIF standard defines precisely the list of tags that must be updated and the list of tags that must be copied unchanged. Unfortunately, older GIMP versions were violating that standard by copying the whole EXIF block unmodified and this caused many problems, including images having the wrong orientation. If the current version behaves correctly in this regard (which I gather it is from your comments) then I am all in favour of dropping the dialog and always rotate the image accordingly. EXIF in an edited image has little resemblance with the original anyway, so I would suggest stripping that except for the IPTC tags. I would also be happy if the IPTC tags were settable in the GIMP, instead of having to resort to other programs. IPTC tags are not part of EXIF. They are a different set of tags that are stored in another JPEG APP marker. The ability to edit and save them may be included in GIMP 2.6. That would be very nice and is important for me and probably a whole host of people out there that rely on the IPTC tags. -- mfg Karl Günter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Problems using some API functions
Hi, I am trying to use some functions of the application API, for example: gimp_text_layer_new gimp_image_get_by_ID I have included in my plug-in code the following two header files: #include libgimp/gimp.h #include libgimp/gimpui.h But I am still getting a compilation error saying unreference functions. Am I missing a header file that I should include? any idea about the cause of the problem? Thanks in advance. Dani ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requests for curves for photo retouching
Hi, On Fri, 2007-11-09 at 13:02 +0100, Andrea Olivotto wrote: - Please, a more dense curve. Better if user can select 4 or 8 lines. It would be nice if you could explain why the current grid isn't dense enough and how exactly a more dense grid would be useful. - Please, draw in the background the baseline (45°). It's a very useful reference, more visible than looking to the vertex of the grid. In my opinion this would be very distracting. I can imagine that a denser grid would also make it easier to see the diagonal. So perhaps just adding a few more grid lines would make this obsolete? - Like levels, when you pass the mouse over the current image, show the luminosity position on the curve, something like a small circle running thru the curve (like Photoshop). This is very very very useful, to see where are some particulas ares of the image on the curve. Without the feature, it's not so simple to design a correct curve. GIMP already does this. Just click into the image with the Curves tool active. Also try using the Shift and Ctrl modifier keys. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Requests for curves for photo retouching
Hello to everyone! I'm Andrea from Italy, this is my first post. I'm an amateur photographer, and I'm using GIMP to retouch my photos. I wrote some articles in italian on the argument, and I'm here to suggest some hints for this beautyful program. Histogram: - It's an invaluable tool for photo retouching, for valuating contrast, brightness, clipping (even channel by channel), posterization. - Should be upgraded in real time, when doing levels, curves, ... (I know it done on the 2.4.1 release) better if during correction the original histogram is grayed in the background, and the histogram of the current correction is black in the front. - Like other photo retouching programs (take a look to UFRaw), there could some checkboxes to enable clipping areas blinking. This is very useful to see clipping, even better if could be updated in real time during correction (as the entire histogram). - Linked to the previuos hint, on the histogram window there could be shown the percentage of clipping towards the white e the black (see UFRaw). Levels: - When you pass the mouse over the current image, show in the histogram on the levels window the luminosity position, something like a small circle running thru the orizzontal line. Curves: - Please, a more dense curve. Better if user can select 4 or 8 lines. - Please, draw in the background the baseline (45°). It's a very useful reference, more visible than looking to the vertex of the grid. - Like levels, when you pass the mouse over the current image, show the luminosity position on the curve, something like a small circle running thru the curve (like Photoshop). This is very very very useful, to see where are some particulas ares of the image on the curve. Without the feature, it's not so simple to design a correct curve. If you want to see some GIMP and Photoshop histogram, levels and curves images, take a look to my articles (they are in italian, but the important thing are the images): http://www.andreaolivotto.com/photo_retouch_03.html http://www.andreaolivotto.com/photo_retouch_04.html http://www.andreaolivotto.com/photo_retouch_05.html Thanks a lot in advance. GIMP has the chance to be one of the best tool to retouch photos. It's already the best in the open source world. Andrea http://www.andreaolivotto.com -- Andrea Olivotto http://www.andreaolivotto.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problems using some API functions
Hi, On Fri, 2007-11-09 at 13:13 +0100, Dani Perez wrote: I am trying to use some functions of the application API, for example: gimp_text_layer_new gimp_image_get_by_ID You can't use the application API from your plug-in. This is the internal API that is used in the GIMP core. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] XCF saving all state = no more temporary parasites
Here is a brain dump about XCF and state persistence. It is just food for thought and does not require immediate action for 2.6, except maybe for the handling of the flag GIMP_PARASITE_PERSISTENT: Some time ago, Peter mentioned that he would like the XCF file format to save all state associated with the image, so that you can reload the file later and continue exactly where you left off. This implies that each XCF file would have to save the state of the image as well as a bit of the GIMP state but we still have to discuss how far we want to go with that. For example: do we save the state of all tools in each XCF file? Do we save the current settings for all plug-ins? Do we allow the user to remove that information before sharing the XCF file with other users? But besides the state of the environment (GIMP tools and plug-ins), we should also ensure that the state of the image is correctly saved. With the current GIMP, this is not perfect because some information about the image exists only in internal (temporary) data structures and some other data is stored in image or layer parasites that are not persistent so these things are not saved in the XCF file. For example, if you save a work-in-progress as XCF and come back to it later, then you may have lost the original file name, you may not be able to recompose layers that were decomposed from another layer and you may get different settings if you save the image as TIFF or JPEG (because the parasites decompose-data or tiff-save-options are not persistent). If we want to solve some of these problems in 2.6 or later releases, then a first step would be to make all parasites persistent (as if GIMP_PARASITE_PERSISTENT was always included in the flags). We will also have to ensure that all binary parasites handle byte ordering correctly because any XCF file could be loaded later on a different platform. Would there be any objection to making all parasites persistent by default? -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 Roadmap: GEGL integration
Hey all, GIMP 2.6 will include some bits of GEGL, not the full-blown package with GEGL everywhere, but some selected spots that are easy to handle and unlikely to break anything in the planned short development cycle. The tentative plan is pretty simple: * write adapter/proxy functions/objects which enable a GEGL graphs to read/write from/to GIMP PixelRegions. This should be fairly easy to do. * remove all color correction code from app/base and use GEGL operators instead. This involves changes to GimpImageMapTool and all its subclasses, including making all their dialogs views on the properties of the resp. GEGL operators. * if feasible in the time frame, abstract some common color correction base API out of the above step and implement a simple color correction paint tool (something like dodge/burn, but with the choice of all the color correction power we have). * if the above goes well and integrates nicely, look for more isolated spots that would allos us to get rid of legacy code in favor of GEGL operators. That's basically it. Please comment or correct me if i missed something in these first basic steps. ciao, --Mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requests for curves for photo retouching
Sven Neumann wrote: Hi, On Fri, 2007-11-09 at 13:02 +0100, Andrea Olivotto wrote: - Please, a more dense curve. Better if user can select 4 or 8 lines. It would be nice if you could explain why the current grid isn't dense enough and how exactly a more dense grid would be useful. - Please, draw in the background the baseline (45°). It's a very useful reference, more visible than looking to the vertex of the grid. In my opinion this would be very distracting. I can imagine that a denser grid would also make it easier to see the diagonal. So perhaps just adding a few more grid lines would make this obsolete? The grid and the baseline are useful reference. Curves corrrections are very small, because small deviations from the baseline have great impact on the image change. So, when I made a simple S curve to increase contrast, I'm playing... within some pixels! A denser grid and a baseline is useful. I'm using Photoshop as well (check th figures of my article on curves http://www.andreaolivotto.com/photo_retouch_05.html), and when you are used to its curve window... I think it's a simple improvement. If you think it could be distracting (for an inexperienced used), make it configurable via two checkboxes. - Like levels, when you pass the mouse over the current image, show the luminosity position on the curve, something like a small circle running thru the curve (like Photoshop). This is very very very useful, to see where are some particulas ares of the image on the curve. Without the feature, it's not so simple to design a correct curve. GIMP already does this. Just click into the image with the Curves tool active. Also try using the Shift and Ctrl modifier keys. Ops! I will try as soon as possible! Many thanks again, Andrea -- Andrea Olivotto http://www.andreaolivotto.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF saving all state = no more temporary parasites
After the quick feedback that I got on IRC, I think that I should clarify a few things... If I understood correctly what Peter was suggesting some time ago, this was about making sure that the XCF files contain all the information necessary to continue your work in such a way that it would make no difference if you close GIMP and reload the XCF file(s) or if you just continue working without closing GIMP in the meantime. Of course there are some conflicting goals here: XCF was not designed as a save workspace format that would include all open images (not just one) and the complete state of the user interface including window positions, tool state, etc. And personally, I do not think that we should go in that direction because that would belong to a new GIMP workspace file format that would not be an image file format like XCF is supposed to be. I deliberately included the examples about tools and plug-ins in my previous mail because I wanted to see how other developers would react. And it looks like mitch reacted strongly on IRC. ;-) However, if you consider only the information that is directly related to each image, then it would make sense to save as much of it as possible in the XCF file so that it makes (almost) no difference if you close GIMP and re-open the XCF file or if you just continue editing it. So here is a short list of what I think makes sense to include in XCF files: - All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions. - All settings of file plug-ins, because these settings should be associated with each image (e.g., using image parasites) instead of using global last vals. It does not make sense to save the settings of other plug-ins (filters) because these are usually shared globally and would change if you load/save several images. - Some other image data that is currently in internal data structures and not in parasites. For the file name, the best solution may be to keep the current get/set_filename() functions using the internal file name (which would change once the file is reloaded from XCF) but add a new gimp-file-name or gimp-original-file-name parasite so that it is still possible to associate an image with its original file. -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requests for curves for photo retouching
Hi, you might want to have a look at http://sven.gimp.org/misc/gimp-curves.png which is a screenshot of the Curves widget from SVN trunk. As you can see we already incorporated some of your suggestions. And of course the widget benefits a lot from being drawn with Cairo... All this is still open for discussion and will probably undergo further changes. Your input is appreciated. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.4 and how to continue from here
A Monday 29 October 2007 16:24:11, Sven Neumann escreveu: I suggest that we keep brainstorming for the 2.6 roadmap for another week and then collect the ideas. It would be nice if we could end with a list of well-defined tasks. When that list is collected, I would like to discuss which of these tasks should be put on the roadmap for 2.6. Hi Sevn and others, I have been obn the process of moving myself to another city over the last few weeks (almost complet now, just waiting for my mobile nad main machinne to get here). ] As soons as that happens I should consolidate my work hours and spare a few of then for GIMP. The feature I'd like to work on is a brush stroke pannel to be able to set up stroking with curves for relating pressure, speed, angle, etc with opacity, size, jitter, color, etc... One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requests for curves for photo retouching
Sven Neumann wrote: you might want to have a look at http://sven.gimp.org/misc/gimp-curves.png which is a screenshot of the Curves widget from SVN trunk. As you can see we already incorporated some of your suggestions. And of course the widget benefits a lot from being drawn with Cairo... It's very nice! Could be perfect if you'll add the baseline. All this is still open for discussion and will probably undergo further changes. Your input is appreciated. Will the Cairo libray be ported in Windows? Or is a strict Linux library? -- Andrea Olivotto http://www.andreaolivotto.com ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requests for curves for photo retouching
On Nov 9, 2007 6:50 PM, Andrea Olivotto wrote: Will the Cairo libray be ported in Windows? Or is a strict Linux library? It's already ported and used by varios crossplatform applications for quite a while (e.g. Inkscape). Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requests for curves for photo retouching
On Friday, November 9, 2007, 16:50:58, Andrea Olivotto wrote: Will the Cairo libray be ported in Windows? Or is a strict Linux library? GTK+ has used Cairo since 2.8, which is why Windows 9x/ME support was dropped then. -- Jernej Simončič http://deepthought.ena.si/ If God had intended for us to go to concerts, He would have given us tickets. -- Farrow's Finding ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] finishing the roadmap for 2.6 and beyond
On Fri, 2007-11-09 at 17:05 +0100, Sven Neumann wrote: Hi, I'd say we close the submission of proposals for the roadmap at this point and proceed to the next step. Which is collecting the tasks that have been described and putting them into a list for further discussion. Do we have a volunteer for collecting the ideas that have been sent to the mailing-list and putting them onto a nicely formatted web-page? I can do that. I'll Group ideas by contributor and put the page in the wiki. Is that OK? by the way, this s completely unrelated, but today was the first time I tried to seriously work with paths in Gimp - I used them to create a selection around a complex object - and it's so much easier than using the paths in Photoshop for the same purpose, it's ridiculous. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] 2.6 roadmap items
Hi, Here is the list of proposed changes in 2.6 that Sven asked for: Tools - IWarp as tool (Tor) - finishing rectangle tools (Enselic) - full use of cairo for the select/crop tools (?) - add support for color jitter in the paint tools (Adrian Likins) - paint tools should support smudging as they paint (Adrian Likins) - brush stroke panel for stroking with curves (Joao) - color-neutral toolbox icons that are quick to recognise and work with (?) GUI - arbitrary angle guidelines (Joao) - Cairo rendering (Sven) Metadata - migrate some parts of the metadata core to a library for the whole app (raphael) - convert EXIF to XMP, XMP to EXIF, IPTC to XMP, XMP to IPTC (raphael) - rewrite the XMP parser and the internal data model (raphael) - implement the user-friendly tabs in the metadata editor (raphael) - easy merging of XMP presets from a drop-down list or something similar (raphael) - implement history tracking for XMP Media Management (raphael) - allow creative editing of the embedded thumbnail (raphael) Plug-ins - simplify the user interface of jpeg plug-in (raphael) - all file plug-ins handle metadata correctly (raphael) - make sure that the last used settings are saved in a parasite attached to the image instead of using global save_vals, etc (raphael) GEGL integration - write adapter/proxy functions/objects which enable a GEGL graphs to read/write from/to GIMP PixelRegions (?) - remove all color correction code from app/base and use GEGL operators instead (?) - if feasible in the time frame, abstract some common color correction base API out of the above step and implement a simple color correction paint tool (?) Layers - vector layers (Henk Boom?) PDB - new text tool API (Marcus Heese?) - cleaning up metadata related part of PDB (raphael) The ? character after a name means that exact intentions of that person are unknown. Let me know if I missed something. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Requests for curves for photo retouching
It would be nice if the curves dialog becomes semi-transparent when user clicks image if the dialog overlays the image. Currently the dialog size is so large, than it is hard to preview the whole image with the dialog not overlaying it at 1024:768 monitor resolution. Some backward interaction would be nice to see too. I posted a feature request some time ago to be able to select some range (abscissa) at the curves dialog and to see the result blinking or other pixels shaded. That could help deciding curve editing. Sven Neumann wrote: Hi, you might want to have a look at http://sven.gimp.org/misc/gimp-curves.png which is a screenshot of the Curves widget from SVN trunk. As you can see we already incorporated some of your suggestions. And of course the widget benefits a lot from being drawn with Cairo... All this is still open for discussion and will probably undergo further changes. Your input is appreciated. Sven -- With respect Alexander Rabtchevich ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Angled guides - was Re: 2.4 and how to continue from here
A Friday 09 November 2007 13:01:06, você escreveu: Hi, On Fri, 2007-11-09 at 12:36 -0300, Joao S. O. Bueno wrote: One other smallf eature I will want to add is the ability to add free- angled guides. I have this almost complete on my codebase, just .XCF saving for it is missing. I should commit that early on 2.6 cycle. I would like to get some feedback from the UI team and from some artists on this. And of course the patch would have to be reviewed before it is committed. I am not yet convinced that this is an important feature and I also have the impression that it's just added ad-hoc without seeing the big picture. It certainly has the potential to cause a lot of problems. I had never added a UI for it - I add then through scripts. And except for bugs with the guides thenselves (which i ironed out as I developed then), I never had any side effect from using them. Snapping to these guides or intesections of these guides and others works fine. If tehre are potential greater problems, just a larger userbase would be able to detect it, and then we just fix it, or remove the feature if it needs very large changes to other program areas to work properly. And rest assured I would not commit it without having an ok from you first. Of course I'd like more feedback from users and the UI team, but nearly everyone I had mentioned this had liked the idea. It is of little use in a program like GIMP where free handed drawing is not emphasized, but sometimes it is just nice it is there. (like for stamping a brush repeating it at a gven angle). My idea for UI is just writing some code for the rotate tool to be able to rotate guides, just as the move tool can move guides. i think that once tested this won't get in anyone's path and will be a little nice feature for GIMP. regards, js -- Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Angled guides - was Re: 2.4 and how to continue from here
On Nov 9, 2007 7:54 PM, Joao S. O. Bueno wrote: My idea for UI is just writing some code for the rotate tool to be able to rotate guides, just as the move tool can move guides. i think that once tested this won't get in anyone's path and will be a little nice feature for GIMP. Arbitrary angle guides would be really useful for visual aligning layers/selections along imaginary angled line. But only if precise rotation of the guide is possible. And there might be a technical challenge to implement visual moving of angled guideы same way we do it now with hor/vert guides. Anyway, expect a lot of feedback from me if this feature will have green light :) and please share your scripts if it's not ;) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] finishing the roadmap for 2.6 and beyond
Hi, On Fri, 2007-11-09 at 18:31 +0200, Michael Grosberg wrote: I'll Group ideas by contributor and put the page in the wiki. I don't think we want to use the GIMP Wiki for this (or for anything else). The roadmap should eventually be put on www.gimp.org so we don't we just put it there from the beginning? I also don't think that grouping by contributor makes sense. This is supposed to be a task list. If we put a name next to each task, then there is nothing left for interested developers to work on. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] roadmap items from the UI team...
Sven wrote: On Thu, 2007-11-08 at 00:06 +0100, peter sikking wrote: Where we are back at the point where this is not likely going to be ever possible on all supported platforms using the toolkit that we use and will continue to use. I am used to development teams telling me 'can't do that', but I am not used to them refusing to sit down with me to find a work around solution. We aren't refusing to find a work around solution. But so far we only talked about the short-term plans and we have not sat down at all to talk about the long-term goals for the user interface. Perhaps we should do that before we put these things on our roadmap. So for now it is probably best if we concentrate on the short-term goals that we agreed on and that can be implemented. Perhaps we can discuss the long-term GIMP UI vision at the next LGM then. fair enough. I am also uncomfortable with the fact of having to convince people of putting on the roadmap rather deep-going paradigm changing solutions without writing first a couple of white-paper type of blog entries where I show how all this stuff hangs together in a deep, complicated way. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Angled guides - was Re: 2.4 and how to continue from here
Hi, On Fri, 2007-11-09 at 13:54 -0300, Joao S. O. Bueno wrote: I had never added a UI for it - I add then through scripts. And except for bugs with the guides thenselves (which i ironed out as I developed then), I never had any side effect from using them. Snapping to these guides or intesections of these guides and others works fine. If tehre are potential greater problems, just a larger userbase would be able to detect it, and then we just fix it, or remove the feature if it needs very large changes to other program areas to work properly. Without a user interface for it, there is zero user base. And most problems are detected only after a feature is released in a stable release. And at that point it is too late to fix a fundamental design problem. Perhaps I should just review the patch before we continue. But in the meantime someone should think about the user interface for this. Without one, it is pointless to add this. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF saving all state = no more temporaryparasites
From: Raphaël Quinet [EMAIL PROTECTED] So here is a short list of what I think makes sense to include in XCF files: - All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions. The problem is that when a parasite gets saved, it becomes in effect a part of the API that must be supported forever. For example, in a GFig layer, the contents of the figure are contained in a layer parasite. If the parasite is permanent, then (1) every future version of GFig must be able to read it without borking, and (2) every future version must write parasites that don't cause past versions to bork. This sort of thing may make sense for stable releases, but during development it is often a great convenience to be able to experiment with formats without every attempt being a commitment that will bind you forever. -- Bill __ __ __ __ Sent via the CNPRC Email system at primate.ucdavis.edu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF saving all state = no more temporary parasites
On Fri, 9 Nov 2007 10:15:42 -0800, William Skaggs [EMAIL PROTECTED] wrote: From: Raphaël Quinet [EMAIL PROTECTED] - All image parasites and layer/drawable parasites. They should all be persistent - no reason to have exceptions. The problem is that when a parasite gets saved, it becomes in effect a part of the API that must be supported forever. [...] This sort of thing may make sense for stable releases, but during development it is often a great convenience to be able to experiment with formats without every attempt being a commitment that will bind you forever. Well, the developer releases are not supposed to be stable. And as long as the development tree is still far from any feature freeze, then it is not wise to expect that its APIs will be supported forever. The format of some persistent parasites has been changed during the 1.3.x development cycle in a way that was not backwards-compatible (maybe during other cycles as well, I didn't check). So I don't think that we have a real problem here. If you really think that unstable releases should never save stuff that may be changed before the stable release, then we could add a new flag GIMP_PARASITE_UNSTABLE or GIMP_PARASITE_EXPERIMENTAL and define that flag only if GIMP_UNSTABLE is defined. That would do exactly the opposite of what we have now: parasites would be saved unless marked as unstable. But that's a bit overkill... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GEGL is now being developed under LGPLv3+
From the ChangeLog: 2007-11-09 Øyvind Kolås [EMAIL PROTECTED] Upgraded GEGL from (L)GPLv2 to (L)GPLv3. The library itself and the operations are under LGPLv3 and the sample programs using the GEGL library are licensed under GPLv3. Copyright statements in all files have been updated to reflect this change, the permission to use leter versions of the GNU licenses have been retained in all instances.) * COPYING: changed to GPLv3 * COPYING.LESSER: added (LGPLv3 's exceptions over GPLv3) This has no impact on GIMPs usage of GEGL as since GIMP is licensed under GPLv2+ and can thus start adopting GEGL before deciding whether to upgrade from from GPLv2+ to GPLv3+. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Angled guides
Hi, I've just sent in two gimp ui brainstorm pictures for angled guides to that gimp brainstorm blog, where casual comments are discouraged, so I thought I'd summarize here: 1. Angled Linear Guides Double click on a line defines a center of rotation. Drag anywhere else on the line, and the guide rotates around that point. Pressing shift, control, or shift+control can change the precision of the rotation. Double click also undefines the center, or redefines it. When there is no center defined, plain dragging will move the line. Dragging with shift, control, or shift+control, will still rotate the line, but rotates it around where the button was clicked down at. The amount of rotation in this case could be, for instance, based on moving horizontally back and forth, or perhaps have the rotation center be arbitrarily assigned to be a little ways away from the click point (but still on screen). 2. Guides based on any path This would make precisely aligned touch-ups easy, especially with tablet pressure effects when painting, when Stroke path just doesn't cut it. Double clicking could enter and exit a path editing mode. Think Inkscape engraving tool for potential expansions of this sort of thing. So anyway, Tom http://www.tomlechner.com http://www.laidout.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
