[Gimp-developer] Proposal of GSoc 2011: Replace the GimpSizeEntry widget

Hi, I have submitted a proposal for Gsoc on line - Proposal: Replace the GimpSizeEntry widget http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/jake007/1# Last year, I have talked with Martin about

Re: [Gimp-developer] Proposal for composition rendering

hi, peter sikking schrieb: > [..] the rest is technical detail > and for actually contributing developers to figure out. Of course, non-devs thinking about technical issues are at high risk of generating bogus discussion. On the other hand, the project has traditionally been open to thoughts from

Re: [Gimp-developer] Proposal for composition rendering

(peter) yahvuu wrote: > hi all, > > here's a (totally unbiased ;-) summary from the previous > "composition rendering" > thread, intended as a discussion base: I must say that I have been watching this discussion with increasing amazement. if you just start with some unbreakable UI principles

[Gimp-developer] Proposal for composition rendering

hi all, here's a (totally unbiased ;-) summary from the previous "composition rendering" thread, intended as a discussion base: 1. Rendering happens on demand: a) when a composition gets displayed on screen (of course) b) on export. Here usually the full resolution gets rendered. => no

Re: [Gimp-developer] Proposal for 2.6 splash screen.

A splash screen proposal from me, too: http://i262.photobucket.com/albums/ii93/peculiarapparat/Gimpsplashy.png Done (obviously) fully in GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/

Re: [Gimp-developer] Proposal for 2.6 splash screen.

2008/8/29 Alexia Death <[EMAIL PROTECTED]>: > After an idea on IRC (thanks Martin!) the text on it got reworked into this: > http://a.death.pri.ee/gimp-splash3.png that seems better. That looks really nice! One thing I suggest is to make the GIMP logo a bit brighter, I don't think it stands out qu

Re: [Gimp-developer] Proposal for 2.6 splash screen.

After an idea on IRC (thanks Martin!) the text on it got reworked into this: http://a.death.pri.ee/gimp-splash3.png that seems better. On Friday 29 August 2008 23:26:57 Alexia Death wrote: > Hi, > > I noticed that there was a lack of splashes for 2.6 so I made one for an > option. Here it is for

[Gimp-developer] Proposal for 2.6 splash screen.

Hi, I noticed that there was a lack of splashes for 2.6 so I made one for an option. Here it is for your appraisal: http://a.death.pri.ee/gimp-splash2.png Best, Alexia PS: This is a photo manipulation, not a painting. The base image is a photo of a sand sculpture altered with some processing a

Re: [Gimp-developer] Proposal new default layout starting 2.6

IN RESPONSE to "Photoshop like" idea : "... it should not look like Photoshop" -> SHOULD NEVER LOOK LIKE Photoshop - because Photoshop even with the new UI additions on CS3 look horrible - GUI for *Smurfs*. I see noone talk here about Corel Draw or Corel Photopaint GUI. For a new user, from the

Re: [Gimp-developer] Proposal new default layout starting 2.6

I agree with you, Alexia. maybe we can also look at Macromedia user interface, such as: Flash, Fireworks or Dreamweaver UI, their UI is different from Photoshop but still easy to learn, simple to manage, and extensible. Even i think Macromedia have better UI than Adobe. this is my suggestions for

Re: [Gimp-developer] Proposal new default layout starting 2.6

On Fri, 2008-08-22 at 20:22 +0300, Alexia Death wrote: [...] > My proposal is basically this: > http://a.death.pri.ee/2.6_default_layout_proposal.png I think there's some good here, although I also think changes here might be better targeted at 2.8. I like the Z-brush and RawTherappee style of do

Re: [Gimp-developer] Proposal new default layout starting 2.6

Alexia Death wrote: On Saturday 23 August 2008 22:51:51 [EMAIL PROTECTED] wrote: that's the second time you propose "familiarity" for a first time user.   How can a first time user be familiar with anything? Or is this another   "Gimp should look and behave like Photoshop" proposal

Re: [Gimp-developer] Proposal new default layout starting 2.6

> This has been addressed in GIMP 2.5. And the change is even explained in > the release notes. Oh, I didn't read that part. Great news. Thanks! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailma

Re: [Gimp-developer] Proposal new default layout starting 2.6

Hi, On Sat, 2008-08-23 at 22:29 +0300, Alexia Death wrote: > I think I need to state that my image was not an "exactly like this" > proposal. > There are altogether three points it tries to make. First, the image window > needs to be incorporated into the default layout. Care to explain how

Re: [Gimp-developer] Proposal new default layout starting 2.6

Hi, On Sat, 2008-08-23 at 16:44 -0300, Guillermo Espertino wrote: > They tell us that this layout is better for new users, but every new > user I know (mostly when they come from windows) the first thing they do > is closing the right docker (trying to close the program). And they > loose it fore

Re: [Gimp-developer] Proposal new default layout starting 2.6

On Saturday 23 August 2008 22:51:51 [EMAIL PROTECTED] wrote: > that's the second time you propose "familiarity" for a first time user.   > How can a first time user be familiar with anything? Or is this another   > "Gimp should look and behave like Photoshop" proposal? No it should not look like P

Re: [Gimp-developer] Proposal new default layout starting 2.6

On Sat, 23 Aug 2008 21:29:40 +0200, Alexia Death <[EMAIL PROTECTED]> wrote: > and third, a bit of familiarity for the first time > users(separate, 2 line toolbox) can not hurt. -- Hi, that's the second time you propose "familiarity" for a first time user. How can a first time user be fami

Re: [Gimp-developer] Proposal new default layout starting 2.6

If you check this list's log you'll learn that the layout you suggest has already been proposed about a year ago. I know because I did it. Later I proposed that layout again in my brainstorm entry about the no-image-open dialog. I used that layout for several months, but I changed my mind. And now

Re: [Gimp-developer] Proposal new default layout starting 2.6

On Saturday 23 August 2008 13:19:35 Sven Neumann wrote: > Hi, > > On Sat, 2008-08-23 at 11:18 +0300, Alexia Death wrote: > > In my opinion this layout(thin toolbox, one large dock) is preferable to > > first time users. It has familiarity. They wont feel lost when GIMP loads > > for the first time.

Re: [Gimp-developer] Proposal new default layout starting 2.6

Hi, On Sat, 2008-08-23 at 11:18 +0300, Alexia Death wrote: > In my opinion this layout(thin toolbox, one large dock) is preferable to > first > time users. It has familiarity. They wont feel lost when GIMP loads for the > first time. For a new GIMP user it is crucial that the tool-options are

Re: [Gimp-developer] Proposal new default layout starting 2.6

On Saturday 23 August 2008 01:22:18 you wrote: > Hi, > > On Fri, 2008-08-22 at 20:22 +0300, Alexia Death wrote: > > My proposal is basically this: > > http://a.death.pri.ee/2.6_default_layout_proposal.png > > IMO the tool-options should definitely be part of the toolbox. My opinion is exactly oppo

Re: [Gimp-developer] Proposal new default layout starting 2.6

Hi, On Fri, 2008-08-22 at 20:22 +0300, Alexia Death wrote: > My proposal is basically this: > http://a.death.pri.ee/2.6_default_layout_proposal.png IMO the tool-options should definitely be part of the toolbox. I would even go as far as locking the tool-options under the toolbox in the default s

Re: [Gimp-developer] Proposal new default layout starting 2.6

On Friday 22 August 2008, Alexia Death wrote: > Good morning ladies and gentlemen, > >... > My proposal is basically this: > http://a.death.pri.ee/2.6_default_layout_proposal.png I like my dialogs to be higher than 1/2 the screen height. And I like similar tool icons next to each other. This do

[Gimp-developer] Proposal new default layout starting 2.6

Good morning ladies and gentlemen, I'm here to propose a new default layout for 2.6 series of GIMP. Why now you may ask... The reason is that the UI has changed. There is a whole new window always on users desktop. And this gives us the opportunity to present a lot more familiar and, in my optio

[Gimp-developer] proposal update

I appreciate all the feedback I've received on the tear-away interface. I've decided to "tear" that part out of the proposal and focus strictly on the gallery/batch-processing idea that seemed to be of more interest from the comments I received. Those with access can read my rewritten proposal "GI

Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc

Ok, here are my 2¢... On Thursday 17 January 2008, Joao S. O. Bueno wrote: > Besides, yes, gimp would need some kind of scanning through resource > folders, and possibly group all resopurces tehre under an "all" flag. > That is needed so that one can download resources and add then to > GIMP throu

Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc

On Thursday 17 January 2008 14:45, William Skaggs wrote: > From: peter sikking [EMAIL PROTECTED] > > > chiming in here (getting back to speed). [...] > > Peter! Great to hear from you again! > > I absolutely agree about the virtues of a tagging system, but > I fear that the difficulties are not be

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

On Jan 17, 2008 7:45 PM, William Skaggs <[EMAIL PROTECTED]> wrote: > > 2) If they are stored in a separate database, keyed by file > names, then there is a great danger of losing the linkage > between tags and object. If, for example, the user renames > the directory holding some brushes, all of t

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

From: peter sikking [EMAIL PROTECTED] > chiming in here (getting back to speed). [...] Peter! Great to hear from you again! I absolutely agree about the virtues of a tagging system, but I fear that the difficulties are not being appreciated well enough. Here, for example, is just one of the pr

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

Scott wrote: > The whole > 'tags' idea is fine too, but if I understand what is being said there > would only be one tag per brush. nah, that is the same as sticking them in folders. the power of tags is that you can associate as many concepts with a resource as you like. and find it back via as

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

On Thu, Jan 17, 2008 at 05:39:29PM +0100, peter sikking wrote: > There are some traits that make Bill's idea obsolete. First one > is the hierarchical organisation of resources. A tagging system > allows multiple ways to find a resource again (instead of a unique > one) by attaching many different

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

On Thu, Jan 17, 2008 at 08:37:34AM +0100, Sven Neumann wrote: > > > And, to repeat, even if there is tags support, there must be, > > at least from the user's point of view, something like a workspace -- > > a set of brushes that are immediately available. > > Sure. That is the set of brushes tha

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

Hi all, chiming in here (getting back to speed). There are some traits that make Bill's idea obsolete. First one is the hierarchical organisation of resources. A tagging system allows multiple ways to find a resource again (instead of a unique one) by attaching many different properties to it (a

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

I'm sorry to jump in on this so late. I was working on a new GIMP Plug-In Registry. It had been put on pause by me because of certain life-altering events. At one point I had put forward the idea of a backend XML-RPC or SOAP connectivity service that would allow GIMP to access the re

Re: [Gimp-developer] proposal for managing resources such as brushes , gradients, etc

Hi, On Thu, 2008-01-17 at 01:50 +, William Skaggs wrote: > These are interesting ideas, but they are fantasies at this point. > The whole tags thing is a fantasy at this point. There is no > infrastructure in Gimp to support it, so everything would have > to be written from scratch. That's

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

Hi, On Wed, 2008-01-16 at 20:42 +, William Skaggs wrote: > This mixes together two separate issues. No, it doesn't. Absolutely not. > Tags are, as I have already agreed, > an excellent way of doing a search mechanism. They don't get rid of the > need to have a workspace, though. Suppose I

Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc

On Thu, 17 Jan 2008 02:50:36 +0100, William Skaggs <[EMAIL PROTECTED]> wrote: > And, to repeat, even if there is tags support, there must be, > at least from the user's point of view, something like a workspace -- > a set of brushes that are immediately available. The proposal > I made -- simpl

Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc

From: Joao S. O. Bueno [EMAIL PROTECTED] > What about using...tags... for that? [etc] These are interesting ideas, but they are fantasies at this point. The whole tags thing is a fantasy at this point. There is no infrastructure in Gimp to support it, so everything would have to be written from

Re: [Gimp-developer] proposal for managing resources s uch as brushes , gradients, etc

On Wednesday 16 January 2008 17:42, William Skaggs wrote: > This mixes together two separate issues.  Tags are, as I have > already agreed, an excellent way of doing a search mechanism.  They > don't get rid of the need to have a workspace, though.  Suppose I > want to switch back and forth between

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

From: Sven Neumann [EMAIL PROTECTED] > Right. We have discussed this in the past and we have come up with a > simple and IMO very good solution that has several advantages over the > approach that you are suggesting now. The solution is to allow tags to > be assigned to data files. This allows th

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

Hi, On Wed, 2008-01-16 at 17:03 +, William Skaggs wrote: > This problem has been discussed several times in the past, and > proposals have been made about how to address it. I have been > thinking about it recently, and have come up with a somewhat > different, and I believe simpler approach

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

From: Akkana Peck [EMAIL PROTECTED] > You didn't mention fonts, but your idea would work equally well for > managing an unweildy list of fonts. If there was a way to add > hierarchies into the workspace, we could even solve the much- > discussed problem of font categorization (these are my script

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

>> At the level of programming, the only relatively difficult thing is to >> create the GimpDataChooser widget. Even this is simple in principle, >> although complicated in practice because it involves a lot of rather >> complex Gimp code. I have been experimenting with writing a Chooser, >> a

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

William Skaggs writes: > 1) You have a "workspace", holding the brushes that you are currently [ ... ] > 2) You have a set of extra folders, specified in Preferences. The >brushes in these folders don't automatically belong to the >workspace. To get at them, you invoke a Brush Chooser, wh

Re: [Gimp-developer] proposal for managing resources such as brushes, gradients, etc

> At the level of programming, the only relatively difficult thing is to > create the GimpDataChooser widget. Even this is simple in principle, > although complicated in practice because it involves a lot of rather > complex Gimp code. I have been experimenting with writing a Chooser, > and I be

[Gimp-developer] proposal for managing resources such as brushes, gradients, etc

One of the most important usability problems with Gimp is the inability to organize resources such as brushes, gradients, patterns, and palettes. For each of these, you can designate a set of folders in Preferences, but everything inside those folders is automatically loaded at startup, and presen

Re: [Gimp-developer] Proposal to modify ftx.c to correct foreign_filetype function's use of g_file_test on *ux machines

david wrote: > My proposal to correct this in Linux is as follows, it adds the overhead > of a second call to g_file_test but retains the return code structure > >if (g_file_test(filename, G_FILE_TEST_IS_REGULAR) && !g_file_test > (filename, G_FILE_TEST_IS_SYMLINK) ) > retcode = F

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

From: Daniel Falk [EMAIL PROTECTED] > From a user perspective, I think the ideal solution would be to treat > strokes on vectors similar to how Inkscape does it. For those not > familiar with Inkscape, it works by attaching line and fill properties > to the vector, which can be changed at any

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

Sven Neumann wrote: > Hi, > > On Sat, 2007-12-08 at 17:51 +, William Skaggs wrote: > > >> 1) The most important is that the dialog should not go away after the Stroke >> button is pushed. It often takes several tries to get the settings right, >> and >> it is very annoying to have to bring

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

From: William Skaggs [EMAIL PROTECTED] I think I need to follow up on my last message, because it was read incorrectly by some people. I should say that the English skills of most of the people who contribute to GIMP are so strong that I normally don't worry about how I say things, but in this

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

Sven wrote: > I don't see though why it requires massive changes to implement a > preview of paint strokes. It should be possible to do this after some > refactoring of the code. Stroking with a paint tool is implemented in gimppaintcore-stroke.c, by gimp_paint_core_stroke() or gimp_paint_core_st

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

Hi, On Sun, 2007-12-09 at 03:32 +, William Skaggs wrote: > Okay, I can see that a preview would go a long way toward > making the dialog more usable. I looked over the relevant code, > though, and I'm not sure it would be very easy to set one > up. Previewing libart stroking wouldn't be very

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

Okay, I can see that a preview would go a long way toward making the dialog more usable. I looked over the relevant code, though, and I'm not sure it would be very easy to set one up. Previewing libart stroking wouldn't be very hard, because basically all you need is a set of tiles to do the str

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

Hi, On Sat, 2007-12-08 at 19:39 +, William Skaggs wrote: > How could it be made easier? Well, for plug-ins this is already quite easy. You use Undo and then "Reshow" the filter dialog. It's rather confusing though that this only works for operation implemented as plug-ins. It would perhaps b

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

>> I agree with all of your suggestions. I would assume that changes made >> in the dialog would update the stroke interactively and, hopefully, that >> the path could be reshaped while the dialog remained open. This would be >> very useful. > > Those are both feasible, but they go beyond the scope

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

From: Sven Neumann [EMAIL PROTECTED] > We don't do this kind of "Apply" thing anywhere in GIMP. I think it > would be rather inconsistent and confusing if we start to do it for some > dialogs. Since the dialog already remembers all settings, I don't really > see what you want to achieve with this

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

Hi, On Sat, 2007-12-08 at 10:10 -0800, Akkana Peck wrote: > Certainly a full-size preview would be quite useful. Like you, I > find that I usually Stroke several times trying to find the right > brush size (I usually stroke with the paintbrush tool, for its > antialiasing). > > It wouldn't have

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

From: [EMAIL PROTECTED] > I agree with all of your suggestions. I would assume that changes made in > the dialog would update the stroke interactively and, hopefully, that the > path could be reshaped while the dialog remained open. This would be very > useful. Those are both feasible, but they

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

I agree with all of your suggestions. I would assume that changes made in the dialog would update the stroke interactively and, hopefully, that the path could be reshaped while the dialog remained open. This would be very useful. > I find myself doing Edit->Stroke pretty often, and there are a few

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

Hi, On Sat, 2007-12-08 at 17:51 +, William Skaggs wrote: > 1) The most important is that the dialog should not go away after the Stroke > button is pushed. It often takes several tries to get the settings right, and > it is very annoying to have to bring the dialog back each time. The gain

Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog

William Skaggs writes: > I find myself doing Edit->Stroke pretty often, and there are a few easy > changes > that I think would make it signficantly better. > > 1) The most important is that the dialog should not go away after the Stroke > button is pushed. It often takes several tries to get th

[Gimp-developer] proposal for usability enhancements for Stroke dialog

I find myself doing Edit->Stroke pretty often, and there are a few easy changes that I think would make it signficantly better. 1) The most important is that the dialog should not go away after the Stroke button is pushed. It often takes several tries to get the settings right, and it is very ann

Re: [Gimp-developer] proposal for libgimpmetadata API

Raphaël Quinet wrote: /* decode the given XMP packet (read from a file) and merge it into the metadata parasite. */ gboolean gimp_metadata_decode_xmp (gint32image_ID, const gchar *xmp_packet); /* generate an XMP packet from the metadata parasite */ const gch

Re: [Gimp-developer] proposal for better status bar messages (long)

Hi, On Fri, 2006-06-23 at 11:49 -0700, Carol Spears wrote: > what is the purpose of a toggle that says "Background"? There is no toggle that says "Background" in the options of this tool. That's why I will not try to answer the rest of your mail. You would better look at the tool options again a

Re: [Gimp-developer] proposal for better status bar messages (long)

Hi David! > As far as I know, foreground and background are still objectively different from the computer's point of view and our point of view; they have different characteristics. A background tends to > be less detailed than a foreground; also, the definition of background is further muddied

Re: [Gimp-developer] proposal for better status bar messages (long)

On Fri, Jun 23, 2006 at 03:27:19PM +0200, Gerald Friedland wrote: > > I do not quite understand your problems. I am an aloof developer who > has serious problems to understand user's problems. Please help me > out, maybe I am misunderstanding something? So please do not get me > wrong here. > he

Re: [Gimp-developer] proposal for better status bar messages (long)

.. I replied to the wrong address again; argh.On 6/24/06, David Gowers <[EMAIL PROTECTED]> wrote: On 6/23/06, Gerald Friedland < [EMAIL PROTECTED]> wrote: I do not quite understand your problems.  I am an aloof developer whohas serious problems to understand user's problems. Please help me out, may

Re: [Gimp-developer] proposal for better status bar messages (long)

> I guessed from what Sven said, inverting the image colors first might help, and I was right. > I made my second try by: > > * Inverting the image > * Selecting the entire image in the initial 'lasso' pass. > * Disabling 'Contiguous' > * Setting L,a,b sensitivity to 0,707,555 respectively. (a,b w

Re: [Gimp-developer] proposal for better status bar messages (long)

... AARRGH. Accidentally sent this to Sven instead of the list! Sorry Sven.On 6/23/06, David Gowers <[EMAIL PROTECTED]> wrote: The tool only does foreground extraction (hence its name). There's no toggle that would turn it into a background extraction tool. Makes sense, actually -- the characteri

Re: [Gimp-developer] proposal for libgimpmetadata API

Hi, On Thu, 2006-06-22 at 13:33 +0200, Raphaël Quinet wrote: > Well, let's say that it makes it a bit easier if the code is at least > split in separate directories (even if a library is not required for that). > As for the lower overhead, it does make a difference if the file plug-ins > can link

Re: Re: [Gimp-developer] proposal for better status bar messages

On Thu, Jun 22, 2006 at 02:56:36PM +0200, Michael Schumacher wrote: > Von: Carol Spears <[EMAIL PROTECTED]> > > > On Thu, Jun 22, 2006 at 12:49:22AM +0200, Michael Schumacher wrote: > > > Carol Spears wrote: > > > > > > > it would not stay toggled and it seemed to be blind to the colors no > > >

Re: [Gimp-developer] proposal for libgimpmetadata API

On Thu, 22 Jun 2006 08:10:19 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > On Thu, 2006-06-22 at 00:35 +0200, Raphaël Quinet wrote: > > Cleaner code (core/GUI separation, maintainable by different people), > > lower overhead (especially when changing many properties) and more > > importantly pro

Re: [Gimp-developer] proposal for better status bar messages

On Thursday, June 22, 2006, 8:21:46, Sven Neumann wrote: > This wouldn't have happened to you if you have had a look at the cursor > changes. BTW, does anyone object to removing the possibility of turning > context dependant cursors off? They are very important and I can't > really imagine that so

Re: [Gimp-developer] proposal for better status bar messages (long)

On Wed, 2006-06-21 at 15:36 -0700, Carol Spears wrote: > i really tried to use siox this weekend. it is so confusing, i have no > idea what to expect from it or if what happened to me was a bug. > > the default is foreground extraction. i wanted it to background extract > and toggled this tool

Re: [Gimp-developer] proposal for better status bar messages (long)

Hi, On Thu, 2006-06-22 at 00:08 +0200, Raphaël Quinet wrote: > Anyway, my main argument is that it would be more consistent with the > other tools: the other selection tools, the transform tools and the > zoom tool only consider the state of the modifiers before the first > click. Subsequent cha

Re: [Gimp-developer] proposal for better status bar messages (long)

Hi, On Thu, 2006-06-22 at 12:09 +0930, David Gowers wrote: > It looks like there is a bug in the SIOX tool/gui that causes it to > return to the foreground setting unexpectedly, until the Control key > is first pressed, then it works as expected. That's not a bug. You cannot mark background unle

Re: [Gimp-developer] proposal for libgimpmetadata API

Hi, On Thu, 2006-06-22 at 00:35 +0200, Raphaël Quinet wrote: > > The file plug-ins could as well use the functions via the PDB then. > > What's the benefit of linking to them? > > Cleaner code (core/GUI separation, maintainable by different people), > lower overhead (especially when changing man

Re: [Gimp-developer] proposal for better status bar messages (long)

On Thu, Jun 22, 2006 at 12:09:24PM +0930, David Gowers wrote: > On 6/22/06, Carol Spears <[EMAIL PROTECTED]> wrote: > > > >http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png > well, i did not use the tool on that image. that image is my desktop and what is wrong with some of the thir

Re: [Gimp-developer] proposal for better status bar messages (long)

On 6/22/06, Carol Spears <[EMAIL PROTECTED]> wrote: http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png Okay. It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expe

Re: [Gimp-developer] proposal for better status bar messages (long)

On Wed, Jun 21, 2006 at 03:36:53PM -0700, Carol Spears wrote: > > also, the tooltips are popping up some freaking huge tool tips. it is > the long help that is in the script-fu? i think it was some of the > third party scripts i have installed that were doing this -- i did not > find it at all h

Re: [Gimp-developer] proposal for better status bar messages

On Thu, Jun 22, 2006 at 12:49:22AM +0200, Michael Schumacher wrote: > Carol Spears wrote: > > > it would not stay toggled and it seemed to be blind to the colors no > > matter what values i gave it. it only selected what i selected which, i > > could have used quickmask for and it would have been

Re: [Gimp-developer] proposal for better status bar messages (long)

Carol Spears wrote: > it would not stay toggled and it seemed to be blind to the colors no > matter what values i gave it. it only selected what i selected which, i > could have used quickmask for and it would have been a lot less toggling > and such. > > is the tool broken or are my expectation

Re: [Gimp-developer] proposal for better status bar messages (long)

On Thu, Jun 22, 2006 at 12:08:34AM +0200, Rapha?l Quinet wrote: > > Anyway, my main argument is that it would be more consistent with the > other tools: the other selection tools, the transform tools and the > zoom tool only consider the state of the modifiers before the first > click. Subsequent

Re: [Gimp-developer] proposal for libgimpmetadata API

On Thu, 22 Jun 2006 00:13:13 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > On Wed, 2006-06-21 at 23:53 +0200, Raphaël Quinet wrote: > > > The file plug-ins would not use these functions via the PDB because they > > could use the library directly. > > The file plug-ins could as well use the func

Re: [Gimp-developer] proposal for libgimpmetadata API

Hi, On Wed, 2006-06-21 at 23:53 +0200, Raphaël Quinet wrote: > The file plug-ins would not use these functions via the PDB because they > could use the library directly. The file plug-ins could as well use the functions via the PDB then. What's the benefit of linking to them? > That covers the

Re: [Gimp-developer] proposal for better status bar messages (long)

On Wed, 21 Jun 2006 22:45:55 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote: > > [...] However, for > > greater consistency with other tools I think that it would be better > > to consider the state of the modifiers _before_ the first click >

Re: [Gimp-developer] proposal for libgimpmetadata API

On Wed, 21 Jun 2006 22:54:32 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: > On Wed, 2006-06-21 at 21:15 +0200, Raphaël Quinet wrote: > > [...] After moving these functions in the new > > libgimpmetadata library, they would still be exported to the PDB but > > probably renamed gimp-metadata-* in

Re: [Gimp-developer] proposal for libgimpmetadata API

Hi, On Wed, 2006-06-21 at 21:15 +0200, Raphaël Quinet wrote: > Most of the functions listed above are currently implemented in the > metadata plug-in and exported in the PDB. So you can find a slightly > longer description of these functions by looking in the Procedure > Browser and searching fo

Re: [Gimp-developer] proposal for better status bar messages (long)

Hi, On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote: > Here is a proposal for improving the messages that are shown in the > status bar. Such messages would be very useful for describing some > hidden features of the paint tools (bug #124040) but also for the > other tools. > > Basically

[Gimp-developer] proposal for better status bar messages (long)

Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools. Basically, I followed this approach: anything that causes a tool to change its beha

[Gimp-developer] proposal for libgimpmetadata API

In order to improve the support for metadata (XMP and EXIF), I would like to move some of the code that is currently located in the plug-ins/metadata directory into a new library, "libgimpmetadata". This library would be linked with all file plug-ins that support metadata. This includes JPEG, PNG,

Re: [Gimp-developer] Proposal for a GIMP metadata viewer/editor (EXIF/IPTC/XMP/...)

> The relatively new thing is that I based almost everything on the XMP > model (Extensible Metadata Platform from Adobe, based on RDF/XML) > because XMP supersedes IPTC (used by Photoshop 6 and earlier) and > includes EXIF (used by almost all digital cameras and supported by > many programs).

Re: [Gimp-developer] proposal

Hi, "Endre Gagyi" <[EMAIL PROTECTED]> writes: >Do you have any idea show to solve this with GIMP? Is there any >chance to implement this feature in the next version? An action recorder is planned for the future. Not sure though if it will make it into the next version since it's quite a

[Gimp-developer] proposal

Dear All,   I’m writing on the behalf of Budapest based Visual Ingenium Ltd. We have started a cooperation last year with the ECDL Foundation in order to develop a new ECDL module for image processing, using GIMP, Photoshop and Corel Photopaint. I think this is a great opportunity for

Re: [Gimp-developer] Proposal for a GIMP metadata viewer/editor (EXIF/IPTC/XMP/...)

On Tue, 17 Aug 2004 15:58:20 +0200, Raphaël Quinet <[EMAIL PROTECTED]> wrote: > As some of you may remember, I started working on a metadata/parasite > editor a long time ago (bug #61499, bug #56443, bug #94416) but lost > most of it in a disk crash during a backup (doh!). Since my new > digital c

[Gimp-developer] Proposal for a GIMP metadata viewer/editor (EXIF/IPTC/XMP/...)

Hi all, As some of you may remember, I started working on a metadata/parasite editor a long time ago (bug #61499, bug #56443, bug #94416) but lost most of it in a disk crash during a backup (doh!). Since my new digital camera is begging for better metadata support in the GIMP (starting with the E

Re: [Gimp-developer] Proposal: cache directory tagging convention

Rapha and Sven: Thanks for bringing the xdg-list to my attention; let's move further follow-up discussion there. Rapha: Thanks for your comments - I've already considered some of those issues a bit, but you're right, they need to be addressed in the proposal. I'll work on it. Sven: > The poi

Re: [Gimp-developer] Proposal: cache directory tagging convention

Hi, we should really move this discussion to xdg-list. Bryan Ford <[EMAIL PROTECTED]> writes: > While thumbnails aren't necessarily ephemeral, they certainly are > automatically regenerable - it is the standard behavior for all > applications I know of that use them to regenerate them > automati

Re: [Gimp-developer] Proposal: cache directory tagging convention

Hi, Quoting Sven Neumann <[EMAIL PROTECTED]>: > Bryan Ford <[EMAIL PROTECTED]> writes: > > I'm soliciting feedback, discussion, and hopefully ultimately > > support for a very simple proposal that I've written up in > > preliminary form at this page: > > > > http://www.brynosaurus.com/cachedi

Re: [Gimp-developer] Proposal: cache directory tagging convention

On Tuesday 20 July 2004 15:12, Sven Neumann wrote: > Bryan Ford <[EMAIL PROTECTED]> writes: > > I'm soliciting feedback, discussion, and hopefully ultimately > > support for a very simple proposal that I've written up in > > preliminary form at this page: > > > > http://www.brynosaurus.com/cach

  1   2   >