Re: [Gimp-developer] A new

On 09/19/2009 08:20 PM, Sven Neumann wrote: > On Sat, 2009-09-19 at 15:38 +0200, Martin Nordholts wrote: > >> But SIOX is supposed to be more than a selection tool, isn't it? Isn't >> it about extracting foreground objects? A selection is not enough for that >&g

Re: [Gimp-developer] A new

On 09/20/2009 08:19 AM, Gerald Friedland wrote: >> A good foreground selection tool would need to get rid of the red in the >> pixels with both red and green and only leave slightly transparent green >> pixels. > > Absolutely. And this is exactly what Jenny has implemented as part of > the Google

Re: [Gimp-developer] are there other occurences of the %s part of "_Undo %s" ?

On 09/20/2009 09:56 AM, Cristian Secară wrote: > There are several strings that become part of these strings: > _Undo %s > _Redo %s > _Fade %s... > > My question is if those strings that replaces %s are unique for this > combination, or they may appear in other places too. Hi, No, there is no gu

Re: [Gimp-developer] Where to post rotate brushes bugfix?

On 09/28/2009 10:06 AM, Michael Natterer wrote: > On Fri, 2009-09-25 at 12:42 -0800, Tal wrote: >> I found and solved a new bug in the bilinear rotate transform algorithm that >> sometimes caused artifacting on brush edges for brushes rotated 90, -90, >> -180, 180 degrees. >> >> Since the previou

Re: [Gimp-developer] Can I have tabs and Apply button in the plugin GUI?

On 09/28/2009 02:21 PM, Louise Hoffman wrote: > Dear developers, > > Can someone tell if this GUI design is possible? > > http://pastebin.com/m1ccbcd06 > > The reason I would like to have tabs is because of the work flow, and > the values in the Modify tab will be different depending to the load

Re: [Gimp-developer] Can I have tabs and Apply button in the plugin GUI?

On 09/28/2009 06:46 PM, Louise Hoffman wrote: >> Yes it's possible, you can create any GTK+ interface in plug-ins. >> To get tabs you'd use GtkNotebook. You can hook any code to an >> Apply button, including code that takes the active tab into >> account. > > Is it possible that my plugin can be o

Re: [Gimp-developer] C plug-in call

Hi, On 09/30/2009 03:01 PM, alfredo.gar...@ludis.info wrote: > Is it possible to call an other plug-in in a C plug-in ? Yes, with gimp_run_procedure() [1] Do git grep gimp_run_procedure in the GIMP source for examples on how it can be used. Regards, Martin [1] http://developer.gimp.org/api

Re: [Gimp-developer] Icons for layer modes

On 10/01/2009 06:40 PM, peter sikking wrote: > peter (yahvuu) wrote: > > first: let me say that there is some real innovative stuff in this > post, it is surely intriguing me. I can only agree, really nice work yahvuu > > >

Re: [Gimp-developer] Invoking custom Gimp module from Web (Apache)

On 10/02/2009 05:47 PM, Vio wrote: > gimp --no-interface --batch='(python-fu-pdf2jpg RUN-NONINTERACTIVE > "/path/to/image/to/proces.pdf" )' --batch='(gimp-quit 1)' > > doesn't get executed. Or it does but fails silently - which is not > very helpful here !! Does it help if you set the GIMP2_DIRE

Re: [Gimp-developer] Icons for layer modes

On 10/01/2009 07:46 PM, peter sikking wrote: > meanwhile, can the overlay thing be repaired file-backward-compatible? If you refer to the Overlay layer mode being different when using GEGL compositing compared to legacy compositing, then yes I'm sure it's repairable, and we don't have much choice

Re: [Gimp-developer] Content distribution system

On 10/04/2009 11:34 AM, Stephen wrote: > I would like to work on Bug 306713 - Write a GIMP plug-in and resource > distribution system > https://bugzilla.gnome.org/show_bug.cgi?id=306713 Cool! > -instead of providing downloads ourselves, we could make third parties > the download providers and jus

Re: [Gimp-developer] Save + Export proposal

Hi, On 10/05/2009 02:10 AM, photoco...@gmail.com wrote: > But even if conceptually different in practice , both operation are always > needed for the every edited image: > is needed to Save the original AND to export as jpg or png . This assumption is wrong. Complex compositions will need to be

Re: [Gimp-developer] obtain a Windows DIB handle to a GIMP selection

On 10/06/2009 10:55 AM, Lucian Sabo wrote: > Hello all, > > I want to create a plugin for Windows only that makes use of a windows DLL. > The function from the DLL I need to call requires a DIB Handle as parameter > and the original file name. > I did not found any method to get active selection

[Gimp-developer] The mailing list uptime

Hi everyone! It is great to see the gimp-developer list up and running again, but it has had two rather long downtimes recently and it is not unreasonable to assume that these problems will continue. What do people think about asking GNOME to host the list [1]? Personally I would be fine with tha

[Gimp-developer] The mailing list uptime; ask GNOME to host?

Hi everyone! It is great to see the gimp-developer list up and running again, but it has had two rather long downtimes recently and it is not unreasonable to assume that these problems will continue. What do people think about asking GNOME to host the list [1]? Personally I would be fine with tha

Re: [Gimp-developer] The mailing list uptime; ask GNOME to host?

2009/10/20 Sven Neumann : > On Tue, 2009-10-20 at 18:22 +0200, Martin Nordholts wrote: >> What do people think about asking GNOME to host the list [1]? Personally >> I would be fine with that. > > I don't quite understand why we don't pull the problem at its roots

Re: [Gimp-developer] Would single-window fix usability nightmares?

On 10/22/2009 04:15 PM, Nicolas Robidoux wrote: > > On Thu, Oct 22, 2009 at 1:50 PM, peter sikking wrote: > >> another 'external' area where we really can use some help is gegl, >> to get that from its bumbling experimentation speed to production >> speeds that are same or even better that curren

Re: [Gimp-developer] The mailing list uptime; ask GNOME to host?

On 10/22/2009 07:37 PM, Michael Schumacher wrote: > Martin Nordholts wrote: > >> It is exactly that that is our root problem, we don't have such an admin. One >> way to solve this is to move the list to a place that has sysadmins. > > A place like XCF at Berkeley? &g

Re: [Gimp-developer] Would single-window fix usability nightmares?

On 10/22/2009 09:58 PM, jcup...@gmail.com wrote: > 2009/10/22 Martin Nordholts : >>> I have the impression that the least painful way to make GEGL fast >>> SOON may be to build its desired API on top of VIPS. >> >> We can't use VIPS in GIMP because we need a d

Re: [Gimp-developer] Progressive escalation of help

On 10/25/2009 04:13 PM, photocomix wrote: >> On Thu, Oct 22, 2009 at 7:03 PM, Alexandre Prokoudine wrote: >> >>> IMO the real solution is to shop documentation with GIMP. >> >> Ship, that is :) >> >> Alexandre > > YES !! I agree, distributing documentation separately for a program like GIMP never

Re: [Gimp-developer] Progressive escalation of help

On 10/25/2009 05:26 PM, Sven Neumann wrote: > On Sun, 2009-10-25 at 16:19 +0100, Martin Nordholts wrote: >> On 10/25/2009 04:13 PM, photocomix wrote: >>>> On Thu, Oct 22, 2009 at 7:03 PM, Alexandre Prokoudine wrote: >>>> >>>>> IMO the

Re: [Gimp-developer] Progressive escalation of help

On 10/25/2009 08:13 PM, Sven Neumann wrote: > We only show this dialog once. If you confirm that you want to use the > online version, then you won't see that dialog again. I don't think > that's too bad. The dialog makes it clear what's happening and it serves > as a hint that the manual can also

Re: [Gimp-developer] Progressive escalation of help

On 10/25/2009 11:35 PM, Ilya Zakharevich wrote: > If you think the dialogue is nagging, it is better to make a checkbox > "do not show this again, show online help directly". AND, maybe, > never show the same dialogue in the same session. It won't nag me less just because I can dismiss it for the

Re: [Gimp-developer] Progressive escalation of help

On 10/26/2009 01:42 PM, g...@catking.net wrote: > Maybe you'd see it better if the checkbox (AHH shoot this man , he said > the "C" word!!) was labelled "remember this choice". > > You can't presume what the "correct" answer is and impose it on everyone > since the answer depends on the user himse

Re: [Gimp-developer] 2.7 tarball

On 10/27/2009 01:49 PM, Rob Antonishen wrote: > How often are the 2.7 tarballs at ftp://ftp.gimp.org/pub/gimp/v2.7/ updated? A release of a new version of GIMP is always made _after_ the tarball has been uploaded there. We want to get a 2.7.1 release out asap, hopefully within a couple of weeks.

Re: [Gimp-developer] 2.7 tarball

On 10/27/2009 06:08 PM, Martin Nordholts wrote: > On 10/27/2009 01:49 PM, Rob Antonishen wrote: >> How often are the 2.7 tarballs at ftp://ftp.gimp.org/pub/gimp/v2.7/ updated? > > A release of a new version of GIMP is always made _after_ the tarball has been > uploaded there.

Re: [Gimp-developer] The name "Gimp"

On 10/31/2009 09:26 PM, Alexandre Prokoudine wrote: > The question you really have to ask is: will actual GIMP developers > agree to work on rebranded GIMP? Because, you see, there are just 3,7 > of them. And only Martin (correct me if I'm wrong) once said he > wouldn't mind having GIMP rebranded.

Re: [Gimp-developer] operation logging

On 11/10/2009 06:27 AM, Tim Chen wrote: > Than I come across this feature requirement > "https://bugzilla.gnome.org/show_bug.cgi?id=51937"; about script recording. > > So, I was wondering > > 1. What's the current progress about script recording? is there any API > for such function atm? Exactly

Re: [Gimp-developer] Antialiasing method used in round corners

On 11/13/2009 11:26 PM, Денис Черемисов wrote: > It seems to be adequate enough -- definitely better than one used in > photoshop and simple approaches I've tried to use in my task. So, what > method do they used? If you mean the round corners for rectangle select you can study the implementation

Re: [Gimp-developer] animation-play

Mircea Purdea wrote: > Source code can be downloaded from: > http://nothing.exhalus.net/misc/animation-play.zip Hi Mircea! Modifications to software is generally distributed as patches, look at [1] for basic instructions on how to generate a patch with git. > The source file is modified from th

Re: [Gimp-developer] animation-play

Martin Nordholts wrote: > Modifications to software is generally distributed as patches, look at > [1] for basic instructions on how to generate a patch with git. I forgot to add: [1] http://gimp.org/bugs/howtos/submit-patch.html / Martin -- My GIMP Blog: http://www.chromeco

Re: [Gimp-developer] Fixes for memory leaks

Nelson A. de Oliveira wrote: > Hi! > > While giving a look at bug #595605 (from Gimp Bugzilla), I have > remembered about cppcheck. > I have created a patch available at > > http://people.debian.org/~naoliv/misc/gimp-mememleak.diff Hi! Please generate the patch as a commit according to these in

Re: [Gimp-developer] Scope of variables

Nelson A. de Oliveira wrote: > Hi! > > Is it interesting to limit the scope of the variables to where they > are only used? Hi! Yes, but this is the kind of changes you'd do when you have commit access. It would be too much work to review a big inflow of these kinds of patches. Regards, Marti

[Gimp-developer] Making dockable tab style a global setting

Hi, It is already possible to change the Tab Style for dockable dialog tabs. Right now however, this needs to be done on a per-tab level, using 'Tab Style' in the Tab menu for each dockable. It is cumbersome to manage the tab style on a per-tab level, so I suggest we make this a global setting

Re: [Gimp-developer] Making dockable tab style a global setting

peter sikking wrote: > Martin wrote: > >> It is cumbersome to manage the tab style on a per-tab level, so I >> suggest we make this a global setting. That is, changing the tab style >> for "one" tab changes the tab style for all tabs. We could also have it >> in Edit -> Preferences -> Interface, b

Re: [Gimp-developer] Making dockable tab style a global setting

peter sikking wrote: > well, I am thinking about why docks get organised in rows of tabs, > together, > and why in different rows, paralleling. and then I _can_ see that it > makes > sense for some users to have (like in your shot) layers+channels+paths > +undo > in text for calmness and brush

Re: [Gimp-developer] some current 2.7 issues

Hi Liam Liam R E Quin wrote: > (1) The file->export dialogue action button says save, not export > (sounds really minor but given the save/export changes, can actually > be confusing) Fixed: commit 5819c3c83a25de4b56360b9d9aa486433c7eaac4 Author: Martin Nordholts Date:

Re: [Gimp-developer] Making dockable tab style a global setting

Alchemie foto\grafiche wrote: > yahvuu > > I'm sure you are not a average user that may need a hint to discover the > very useful options buried in the Gimp preference > > But ,in case you will be forced to kill a single message , only visible once > after a new install This had been said be

Re: [Gimp-developer] Making dockable tab style a global setting

GSR - FR wrote: > Hi, > ense...@gmail.com (2009-12-05 at 1330.57 +0100): >> I don't understand who would want a UI where tabs doesn't have the same >> style, what a mess > > I use icons for things that have true info in visual sense (colour, > pattern, brush, palete, gradient) and text for the re

Re: [Gimp-developer] some current 2.7 issues

Liam R E Quin wrote: > (1) File->New, make an RGB image, e.g. 377x233px in size. > paint a smiling face in red. > > (2) File->New, choose Advanced Options and make a grayscale image > (I made mine 377x233px). > > (3) Notice how the smile in the first image is now gray - you can make >

Re: [Gimp-developer] some current 2.7 issues

yahvuu wrote: > > Martin Nordholts wrote: >> Liam R E Quin wrote: >>> (1) File->New, make an RGB image, e.g. 377x233px in size. >>> paint a smiling face in red. >>> >>> (2) File->New, choose Advanced Options and make a grayscale image &

Re: [Gimp-developer] Secure logging of GIMP actions

meetthegimp.org wrote: > I just had an interesting phone conversation with someone (sorry, I > can't be more specific) who needs to log all actions that have been used > to change an image. One should be able to reproduce all the steps that > have been done. > > Is this possible to implement in

Re: [Gimp-developer] Non-destructive layer scaling -> patch!

Joseph Miller wrote: > I have to work with a lot of website images so I end up doing a lot of > resizing. I kept running into problems though where I would resize a > whole set of layers, then find out I made them to large or too small. > But I wouldn't be able to know this until I had them la

Re: [Gimp-developer] Non-destructive layer scaling -> patch!

Joseph Miller wrote: > > Interesting patch, but it is unfortunately in the wrong direction. > Non-destructive scaling needs to be implemented with GEGL and not by > hijacking layer group semantics. > > > Thanks for the link on the patch format. I'll look over that straight > away.

Re: [Gimp-developer] Non-destructive layer scaling -> patch!

Joseph Miller wrote: > > > > With GEGL, this will be done through a scale node, like > "gegl:transform", in the image graph. The code to manage this > probably will not end up in about the same size as what you have > already, except it will use GEGL API instead of GIMP's pixel

Re: [Gimp-developer] Non-destructive layer scaling -> patch!

Joseph Miller wrote: > > I hope that we can motivate you to work on the GEGL graph in GIMP so > that it can not only be used to project the image data, but also to do > some of the image processing. > > > I would like to try. I have not been able to access www.gegl.org >

Re: [Gimp-developer] [Bug 605366] OpenRaster support

Jon Nordby wrote: > Picking up this right now. As stated in the report, there is a Python > input handler plug-in (written by me) available that provides OpenRaster > support. Are you be interested in shipping this for 2.8? What would it > take? Personally I think we should accept a sane patch

Re: [Gimp-developer] Plugin that can open a drawable on screen. What am I doing wrong?

Louise Hoffman wrote: Dear developers, I am trying to make a GIMP plugin that can open a new drawable on the screen. Just like when you make one from File->New. Hi! You can't show a drawable by itself, it needs to be in an image. Also, an image can't show itself, you must create a display fo

Re: [Gimp-developer] Plugin that can open a drawable on screen. What am I doing wrong?

Louise Hoffman wrote: > hello-world.c:73: warning: passing argument 1 of > ‘gimp_drawable_set_pixel’ makes integer from pointer without a cast > /usr/include/gimp-2.0/libgimp/gimpdrawable_pdb.h:89: note: expected > ‘gint32’ but argument is of type ‘struct GimpDrawable *’ As I said, in the plug-in

Re: [Gimp-developer] Plugin that can open a drawable on screen. What am I doing wrong?

Louise Hoffman wrote: > Now I don't get any errors, but I don't see the pixel either... > > /* Trying to set a pixel at x=5,y=5 with value 150 in 24 bit color */ > const guint8 *pixel; > pixel = (guint8 *) "150"; > gboolean s; > s = gimp_drawable_set_pixel (layer, 5, 5, 24, pixel); > p

Re: [Gimp-developer] Plugin that can open a drawable on screen. What am I doing wrong?

Sven Neumann wrote: > On Sun, 2009-12-27 at 11:18 +0100, Louise Hoffman wrote: >>> I strongly suggest that you read the tutorial on developer.gimp.org >>> then: >>> >>> http://developer.gimp.org/writing-a-plug-in/1/index.html >> I read that one, and it was from that, I copied a lot of the code. I

Re: [Gimp-developer] Just a reminder of 48 bit color support

Asiga Nael wrote: > After some googling, I found there have been some requests of 48 bit support > in Gimp, but it doesn't seem to have high priority. Hi! We know very well that support for higher bit depths is a crucial feature. The reason we have decided not to implement it for 2.8 is that i

Re: [Gimp-developer] GIMP 2.7 and Single Window Mode

Gino D wrote: > Hi. > > Inside a web page, I've read that the release of GIMP 2.7 already > anticipates several features of the stable version 2.8, including the > ability to activate the Single Window Mode. Nevertheless, I guess the > article was referring only to the Linux version of the prog

Re: [Gimp-developer] Just a reminder of 48 bit color support

Omari Stephens wrote: > On 12/31/2009 10:57 AM, Sven Neumann wrote: > ::snip? SNIP!:: >> You are free to start working on it today. GEGL needs more contributors >> and there is also a lot that can be done in GIMP today working towards >> the goal of better GEGL integration. > > As the GEGL website

Re: [Gimp-developer] config -> display dependency

Sven Neumann wrote: > Hi Martin, > > I've found your last commit message quite confusing and so is the FIXME > that you added to gimpdisplayconfig.c. I'd very much welcome if such > texts would not be added to the code without prior discussion here. > > Your comment states: > > /* FIXME: If we c

Re: [Gimp-developer] config -> display dependency

Hi again, Sven Neumann wrote: > Since there is no GTK+ dependency in the two files, nor any dependency > on code that has a GTK+ dependency, there is no dependency from core to > the UI here. The files are just better located in app/display as that is > where they are used. I don't understand why

[Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()

From: Martin Nordholts As an experiment, use Glade + GtkBuilder for the save dialog in the PNG plug-in. The layout is as good as identical. Mnemonics work and strings are still translated. --- configure.ac |1 + plug-ins/Makefile.am |1 + plug-ins/common/file

Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()

Hi, Right now GIMP has virtuall all of the UI imperatively constructed with code. This has a few problems: * Tweaking the UI requires re-building the app * A lot of code duplication * Not very modern The patch I am replying to ports the PNG save dialog to Glade and uses GtkBuilder to construct

Re: [Gimp-developer] config -> display dependency

Sven Neumann wrote: > When we split up the GIMP core into sub-directories, we also split the > code into UI and core. You will find a few files in the UI > sub-directories that hold nothing but config settings. Since the non-UI > GIMP should be able to read the same config files that the UI-enabled

Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()

The conclusion was to go ahead so I will commit the patch soon after changing "glade" to "ui" as per Sven's comment. In response to Akira's comment on performance: We need to be aware of that we are introducing extra disk IO which can give us problems, especialy during startup if we have to loa

Re: [Gimp-developer] [PATCH] Use Glade + GtkBuilder for file-png.c save_dialog()

Aurimas Juška wrote: > Why not to convert XML's to C code when compiling distribution ? XML's > are large and not very fast to parse. This approach would have all the > benefits of XML's while developing and would not cause additional > penalties for release distribution. That's also a good opt

Re: [Gimp-developer] A big thank you

Steve Moeckel wrote: > i just will say you a big thanks for the implementation of the single > window mode. I compiled the dev version of The Gimp to try this feature, > and it's really great. Now The Gimp is usable with much less pain on my > portable computer. Thank you! We're glad you like what

[Gimp-developer] GIMP 2.8 schedule

I have made a schedule for GIMP 2.8 with the main purpose of being a tool to help us decide what features to include or exclude. The schedule will also let us track project progress and assist "third parties" in their planning, such as the documentation team and distro package maintainers. The

Re: [Gimp-developer] GIMP 2.8 schedule

last time I tried. The first step is to merge 'master' to 'soc-2009-siox-drb' so we get a small diff when we eventually merge 'soc-2009-siox-drb' to 'master'. Thanks for any help! Best regards, Martin Nordholts _

Re: [Gimp-developer] GIMP 2.8 schedule

Alexia Death wrote: > In general, its wonderful. A few notes tho. The format. It does not really > facilitate discussion and is a bit inconvenient to follow. Perhaps a wiki > format, tho I assume calc was selected because of the eta math? Versioning is > a good idea regardless. > > Next, It cur

Re: [Gimp-developer] A big thank you

>> Yes I can, I would love it, any suggestion? I would like a user driven gimp.org. With our current static web page only the ones with commit access can improve the web page. With more wiki-like site we could have a website that is alive. There are of course benefits of having a static site su

Re: [Gimp-developer] GIMP 2.7 (git) crashes with Gtk error

phanisvara das wrote: > - > Gtk:ERROR:gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion failed: > (tree) > .gimp/bin/gimp-2.7: terminated: Aborted > > (script-fu:15893): LibGimpBase-WARNING **: script-fu: gimp_wire_read(): > error > - > > i don'

Re: [Gimp-developer] GIMP 2.8 schedule

Liam R E Quin wrote: > "clean up on-text editing", is there a better description? Not yet, but everyone is free to look into exactly what we need to do and come up with more detailed tasks. On-canvas text editing simply needs to work a bit better than it currently does. Just by using it it's po

Re: [Gimp-developer] GIMP 2.7 (git) crashes with Gtk error

phanisvara das wrote: > On Wednesday 13 January 2010 12:27:20 am Martin Nordholts wrote: >>> Gtk:ERROR:gtkrbtree.c:1098:_gtk_rbtree_find_offset: assertion >>> failed: (tree) >>> .gimp/bin/gimp-2.7: terminated: Aborted >>> >>> (scr

Re: [Gimp-developer] GIMP 2.8 schedule

Alexandre Prokoudine wrote: > On 1/11/10, Martin Nordholts wrote: > >> Then the ETA of GIMP 2.8 becomes 2010-12-02 which is more >> reasonable. > > And still somewhat scary :) > > The plan however does not seem to mention Python scripting > improvements branch.

Re: [Gimp-developer] GIMP 2.8 schedule

Nelson A. de Oliveira wrote: > Can donations (money) to GIMP somehow speed up its development, please? Currently, money donated to GIMP as a project will not be used to pay people for writing code, but is instead used for doing things like paying flight tickets to e.g. Libre Graphics Meeting. I

Re: [Gimp-developer] 2.8 schedule, donations and krita

Sven Neumann wrote: > I don't think that donations can speed up GIMP development. On the > contrary, paying some developers for their work is more likely going to > demotivate others. Since I think this is an important issue and since we are not that many developers, we don't need to guess, we ca

Re: [Gimp-developer] 2.8 schedule, donations and krita

Alexia Death wrote: >> Why aren't you just asking if you can have this hardware paid from the >> GIMP account? We are getting several hundred dollars of donations per >> week and can easily afford buying developers the hardware they need. > > Well, I didn't know it was an option, and my interest i

Re: [Gimp-developer] 2.8 schedule, donations and krita

Martin Nordholts wrote: >> Well, I didn't know it was an option, and my interest in such device >> is not limited to just developing gimp, so I've been plotting to get >> one on my own... But it would help a lot if me and someone else, like >> Martin or Mitch

Re: [Gimp-developer] 2.8 schedule, donations and krita

Sven Neumann wrote: > Having someone work on GIMP full-time is something entirely different > than paying for features. It has my full support. Ok then it seems like we're on the same page, I am also skeptical about bounties for features, there's just to much potential problems with that. / Ma

Re: [Gimp-developer] GIMP 2.8 schedule

Martin Nordholts wrote: > I have made a schedule for GIMP 2.8 with the main purpose of being a > tool to help us decide what features to include or exclude. I've commited the schedule now, it can be downloaded from http://git.gnome.org/browse/gimp/plain/devel-docs/gimp-sche

[Gimp-developer] Minimal color management strategy for GIMP 2.8

Hi Right now we don't have a clearly defined color management strategy for GIMP. I would like us to settle a minimal color management strategy for GIMP so that we can fix some inconsistencies in our color management, in particular for PNG [1], for 2.8. In short the problem with PNG is that th

Re: [Gimp-developer] Minimal color management strategy for GIMP 2.8

Omari Stephens wrote: >> I had naively signed up for the "work on color management" job. That >> said, do you happen to know where the sRGB thingie is added by default? >>(if not, I can probably find it, but if you know offhand, I'm not >> beyond laziness ;o) > It was actually trivial to find.

Re: [Gimp-developer] GIMP 2.8 schedule

On 01/25/2010 12:00 PM, Alexandre Prokoudine wrote: > The somewhat scary thing about this schedule is that neither 2.8, nor > 2.10-3.0 section mentions GEGL at all :) Hi Alexandre! There will be no further integration of GEGL for GIMP 2.8, and the 2.10/3.0 section does not contain things planned

[Gimp-developer] [PATCH] app: Get rid of config -> display module dependency

Hi,, Here is the patch that removes the config -> display dependency, as discussed in this thread: http://lists.xcf.berkeley.edu/lists/gimp-developer/2010-January/023955.html / Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.

Re: [Gimp-developer] [PATCH] app: Get rid of config -> display module dependency

On 01/31/2010 06:27 PM, Martin Nordholts wrote: > Here is the patch that removes the config -> display dependency ... I thought. It was >40kb and requires moderator approval, so we'll have to wait for that. / Martin ___ Gimp-develope

[Gimp-developer] Improving the UI, removing the dockable drag handles

Hi everyone, I just attached a patch to Bug 346881 - Remove redundant title of tab and move menu button up that removes the drag handles in dockables and moves the dockable menu button up to the row of tabs. A screenshot based comparison between 2.6 and git with the patch applied can be fou

Re: [Gimp-developer] [PATCH] app: Get rid of config -> display module dependency

On 02/01/2010 08:50 PM, Sven Neumann wrote: > As far as I can see there are no enums with translations left in > display-enums.h after your patch. So you could remove it from > po/POTFILES.in. Well spotted. I have adjusted POTFILES.in and commited the patch. / Martin ___

Re: [Gimp-developer] Gimp-developer Digest, Vol 89, Issue 1

On 02/02/2010 08:26 AM, Mathias Lindner wrote: >> http://www.chromecode.com/temp/gimp-no-dockable-drag-handle.png > > Maybe not what you intended to know but is the checkbox for locking layers > removed in Git? Instead I can see a brush symbol at this place. No the feature is still left, but in

Re: [Gimp-developer] Improving the UI, removing the dockable drag handles

On 02/02/2010 02:40 PM, yahvuu wrote: > Hi, > > Martin Nordholts wrote: >> I just attached a patch to >> >> Bug 346881 - Remove redundant title of tab and move menu button up > > works fine with a small nit: > when there's only one tab, the "T

Re: [Gimp-developer] Improving the UI, removing the dockable drag handles

On 02/03/2010 07:16 PM, yahvuu wrote: > while re-reading, i had a look at how CS4 looks like, and i now > understand what Peter meant by calmness of text: > http://www.softpedia.com/screenshots/Adobe-PhotoShop-Trial_1.png > - très chic. and really guides the attention to the dialog. > > But i don't

Re: [Gimp-developer] image dimension(s) instead of pixel dimensions (Image Properties)

On 02/04/2010 09:08 PM, Liam R E Quin wrote: > Let's use plain English, > "Size in pixels": 10864 pixels wide, 50921 pixels wide. 'pixel dimensions' is more confusing than it needs to be, so I changed to 'size in pixels': commit 43c0cfedbd50ffa425982e66

Re: [Gimp-developer] TAB in single-window mode

2010/2/5 David Gowers <00a...@gmail.com>: > TAB normally toggles the visibility of the docks, including toolbox. > In single window mode it doesn't (and IMO it would be good if it did > -- single non-fullscreen window is a lot more cooperative with other > app windows than simply toggling fullscree

Re: [Gimp-developer] GIMP color-management spec and further discussion

On 02/07/2010 04:55 AM, Omari Stephens wrote: > Hi, all > > I wrote up a quick spec for how GIMP should deal with color profiles > associated with files and images. The spec is attached, and is also > attached to bug 608961. If you have any general thoughts/comments, I > would love to hear them, bu

Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

On 02/08/2010 07:07 PM, yahvuu wrote: > From the User Scenarios [1], i'd like to pick "Creating Original Art", > short name: "create a collage". This seems to be the clearest case, > and perhaps the others can be modelled after this one. > > Compositing several images into one image requires that a

Re: [Gimp-developer] Google Summer of Code 2010 - Step 1: Looking for mentors

On 02/11/2010 10:44 PM, Michael Schumacher wrote: > So, if you'd like to be mentor, please reply to this mail on the > gimp-developer mailing list (Reply-To is set). I am interested in being a mentor > 1. Please describe potential project(s) in your reply A. JavaScript scripting in the core and

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

On 02/12/2010 06:27 PM, Omari Stephens wrote: > On 02/12/2010 04:55 PM, yahvuu wrote: >> Hi, >> >> here are some diagrams depicting selected configurations for colormanagement: >> http://yahvuu.files.wordpress.com/2009/08/dataflow.png > > I believe number 1 is incorrect: > All images in GIMP will h

Re: [Gimp-developer] Google Summer of Code 2010 - Step 1: Looking for mentors

One more: >> 1. Please describe potential project(s) in your reply F. Replace the GimpSizeEntry widget, right now both the code and the UI is a mess. The unit should for example be in the text entry itself instead of in a combo box. >> 2. Describe the optimal student for the project(s) F) Wi

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

On 02/12/2010 07:18 PM, Omari Stephens wrote: > If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a > display profile and opens an image-without-profile, what do we display? >We can't apply the display profile unless the image has some source > color profile to link to the t

Re: [Gimp-developer] moving windows in the git version

When I come back, the windows have moved to > a different place, always the same. Sorry about that, hopefully fixed forever with this commit and a regression test I added: commit 45efd8407938e1f7487b9b372c195aab32a4f90a Author: Martin Nordholts Date: Thu Feb 18 07:21:20 2010 +0100

Re: [Gimp-developer] Introduction & Questions about GSoC2009 Idea: "Plugin for image segmentation"

On 02/17/2010 04:50 AM, Thiago Spina wrote: > = Questions = > > I know there is already a segmentation tool in GIMP, but I feel it could > co-exist with this plugin. I don't think we should have two tools for this, rather one tool that does a great job > * I like to use SSE intrinsics to optimiz

Re: [Gimp-developer] UI Proposal for GIMP 2.8 color management

Hi Peter On 02/17/2010 09:58 PM, yahvuu wrote: > Import: > - Open non-XCF: working space = file's color profile if exists; else > sRGB. > - Open as layers: convert new layer to working space > > The user can override these default choices immediately after import: > http://y

Re: [Gimp-developer] Toolbox UI/Docking

On 02/22/2010 02:17 PM, Jerry Baker wrote: > For discussion... > > https://bugzilla.gnome.org/show_bug.cgi?id=610344 > > Add docking capabilities to the toolbox so it would be possible to dock > another > dialog to the top, bottom, left or right of the toolbox or dock the > toolbox on > the top, bo

Re: [Gimp-developer] thanks for your docs!~

On 03/01/2010 04:02 PM, GimpHammer wrote: > I can hardly find the entrance to the GIMP project. > Also I find that there is less useful stuff in the project main web page > to help analyze the source code to me > Maybe it's a good idea to get a glimpse of the GIMP's code framework. > So it will be

Re: [Gimp-developer] Introduction & Questions about GSoC2009 Idea: "Plugin for image segmentation"

On 03/01/2010 11:57 PM, Gerald Friedland wrote: > Hi all, > > I agree that we should first merge the GSOC code from this year before > we start thinking of a new segmenter. Let me know if you need any > help. IMHO this is work you as a mentor should have done a long time ago. Best regards, Martin

<    1   2   3   4   5   6   7   8   >