Regarding SoC, the deadline for applications comes in a few hours, and
then we have to get down to the business of figuring out which ones we
want to support. Theoretically we have until May 22, but we should
try to do it quickly, for several reasons: first, you may need some
discussion to decide
I'm considering creating a new brush system for the GIMP as part of the
Summer of Code in order to make GIMP more suitable to digital painting.
Adding new painting tools that use a different type of brush is
definitely a realistic project for somebody with your knowledge and
abilities (as I
New tools? Why not improving the basic brush system (sometimes with
artificial limits, see animated brushes workflow or pixmap scaling)
and let all tools make use of it? Erase, airbrush and so on...
To refresh people's memory, Philip is the person who wrote
the code that lets the transform
GSR - FR wrote:
I am just pointing that new tools sound silly, when a more general brush
system seems the solution. Take ink tool, I think it could have been done
by just set the brush tip to react to things like speed and angle,
The ink tool is actually a good example, because it works in
Okay, we are now on Google's list and have begun to put together
a project page, which you can find at http://wiki.gimp.org/gimp/SummerOfCode .
A couple of important points:
1) Ideally, a mentor for a project would be somebody who is capable
of doing the project him/herself without a lot of
Dave Neary wrote:
I have registered the GIMP as a mentoring organisation for the Summer of
Code (I had been in contact with Google before the announcement), we
should be up on the page over the next couple of days.
Thanks Dave for taking the initiative. Does this mean that you are
Artur Rataj wrote:
Hello, can anyone point me to some reference of the algorithm?
I don't know the exact source that the programmers were referring
to, but if you google for fast gaussian blur you will find
plenty of references.
Why the translation radius - std dev is so strange?
My
Roberto Winter wrote:
tried to build the cvs gimp on debian unstable and got this:
Please file a Bugzilla report about this. There are several
possible explanations, and it would be good to be able to deal
with them in a more systematic way than this mailing list.
Also, in your bug report,
Craig M. Houck wrote:
I get this set of error messages and cannot find anything when goggling.
[...]
It looks like something in one of the include files on your system
is #define'ing the string GrayScale. This is causing a problem
with the following code from gifload.c:
static struct
{
Hey folks,
Before you send a message to this list, please give a moment of thought
to whether the entire GIMP development community really needs to read
what you are writing. If not, how about using private email?
Thank you,
-- Bill
__ __ __
Giles wrote:
I don't think the list can afford to lose the input of either one of you.
I wouldn't worry too much about it. Compared to flame-fests of the
past, this one is pretty much a yawner. At least they're arguing
about questions of fact.
-- Bill
The one advantage of playing with
Jean-Luc Coulon wrote:
The screen capture pug-in doesnt take account if capture the
decoration is checked or not. The window is always captured with the
decoration.
Hmm. Very odd. This was of course tested before I committed it, but
as far as I can tell from ViewCVS, the code for this
There is now a new layer alignment tool in HEAD, whose function is
to align layers with other layers in various ways. It should show up
in the toolbox by default. The functionality can probably be
discovered by looking at the tool options and playing around, but here
is a quick overview. To use
Dave Neary wrote:
Should we make the proposals?
Doing this means that somebody is going to have to invest quite
substantial energy in evaluating candidates, defining a specific
project, handholding during the project, and evaluating the results.
The only people capable of doing this,
Jean-Luc Coulon wrote:
The plugin crash with a popup :
Plud-in crashed: screenshot
I get the same result. Looking at the man pages, this apparently happens
if the key being grabbed has already been grabbed by something else --
but there does not seem to be any way to tell whether a given
Simon Budig wrote:
If XGrabKey might fail you can wrap it similiar to this:
gdk_error_trap_push ();
XGrabKey (GDK_DISPLAY_XDISPLAY (data-display),
data-hot_keycode,
AnyModifier,
GDK_WINDOW_XWINDOW (data-root),
TRUE,
GrabModeAsync,
Seems okay with me, except that I think the advertising part should
be strengthened a bit: such a prominent presence calls for a fixed
payment in addition to a cut (or a click-through payment if that can
be implemented). I am assuming that it would show up as a text link:
if not, it needs to be
You probably have older versions of glib and gtk on your system,
appearing earlier in your LD_LIBRARY_PATH than the versions that
GIMP needs.
-- Bill
__ __ __ __
Sent via the CNPRC Email system at primate.ucdavis.edu
Hi Jean-Sébastien,
Probably the code you are looking for can be found in
app/paint-funcs/paint-funcs-generic.h.
Also you might find it helpful to take a look at this
bug report:
http://bugzilla.gnome.org/show_bug.cgi?id=162395
Best,
-- Bill
__ __
Hi, David!
You can get a view of the sort of traffic this list gets by looking at
http://www.mail-archive.com/gimp-developer%40lists.xcf.berkeley.edu/
And for a lot of information on GIMP development, take a look at the
develper's web page:
http://developer.gimp.org/
The best ways of
Just to add a bit to Sven's response:
balachandran c [EMAIL PROTECTED] writes:
I am writing a plugin which requires comparing one row of pixels with
the one following it. . . . how should it be done?
There are lots of examples in the GIMP source that you can look at.
Among the
Thanks to Dave, Joao, Michael, Sven, and others for feedback on the
tentative new rectangle select tool I recently put in cvs. I would
like now to consider where to go from here.
As Sven has said, it is desirable to make things simple and consistent
by forming a base GimpRectangleTool from
Hi,
A little while ago I asked if anybody was interested in volunteering
to work together on menu reorganization. A couple of people have
expressed interest, and that is perhaps a good number to let us
actually get something done, but I thought it might be worth
asking once more so that
Hi,
I've been trying to come up with a way to get the clone tool
to show a message in the status area saying Ctrl-click to
set source whenever the source needs to be set. It isn't
easy, because gimp_paint_tool_oper_update() is not written
to handle the status area in a cooperative way. Here is
Pepster wrote:
My plugin have various user selectable configuration settings.
Right now, I use ~/.gimp-2.2/gimprc to store the defaults.
I am not sure if it is correct to fill up gimprc in this way, and no
setting is saved between sessions.
So, Is there a better/recommended way for
Jon Cruz wrote:
Just to let you know... there are a few different ways things might be
embedded.
In general they can get three different types of metadata: EXIF, XMP and IPTC.
(I'm just getting up to speed on EXIF and IPTC and with jpeg, since my initial
focus was with SVG and XMP).
Marc Lehmann wrote:
On my screen, there isn't. It doesn't matter to the user how something
is implemented internally, and that it is hidden but there. by default,
it's not there (displayed), and it's hard to imagine why a uI element
that is hidden and not used in many cases should require the
Sven wrote:
Since I haven't got around to write up how I think the next-generation
selection tools should work, it will probably be best if you commit
your changes and we discuss them based on the code in CVS.
Okay, it is there now, and the new tool will show up in the toolbox if
you build
Michael Schumacher wrote:
Reimplementing libexif in gimp wouldn't be too wise, would it?
Libexif is a lot cruftier than it needs to be but I don't have
any ambition to reimplement it.
-- Bill
__ __ __ __
Sent via the CNPRC Email system
Sven wrote:
This is also akward. The crop tool shouldn't have a dialog, nor should
we add one to a possible new rectangle tool. The current rect-select
tool shows how the tool-options can be used for this.
I'll defer responding to your other points until I see your proposal,
but I would
Sven wrote:
I want to suggest that we implement this by moving most of the
GimpConfig functionality from the core to libgimpbase or, alternatively,
to a new library, maybe called libgimpconfig.
[ . . . ]
There are a few things that we will need to decide upon, like in which
library
Hi Raphael, glad to hear from you.
Although I am a bit late to the party, here are my 2 cents: I think
that the jpeg plug-in should automatically rotate the image when
opening it without marking it as dirty. The default setting should
be to do that automatically without asking, both for
Raphael wrote:
Yes to both, although the basic stuff hasn't changed much. I never
managed to finish the code that generates the EXIF block from XMP,
though, so that's still work-in-progress.
The most important thing is the XMP parsing/formatting code. Once
that is in place, I can help
Hi,
I have been working on a new rectangle-select tool to meet some
of the deficiencies of the existing one, and would like to commit
what I have to cvs if it is okay.
Here is an overview of what I have currently:
The New Rect Select is implemented as a separate tool, which
does not
Sven wrote:
It's just an argument, not a requirement. Simply something that might
be worth keeping in mind. Is this really only relevant to file
plug-ins? A metadata editor would need to use these functions as well,
wouldn't it?
Raphael's plan, which makes sense to me, is that the metadata
Sven:
I agree that for a C plug-in a library is easier to use but we will
also have to care about plug-ins written in other languages. Making
the functionality available in the PDB solves this nicely. What we
usually do is to provide wrappers that let the procedure call appear
as a simple
Gerhard Gau�ling wrote:
I subscribed today to gimp-developers, and I need at least the archives
for January 2005 in mbox format (b- or gziped).
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer has got
only the archives until 2003.
It's broken. See
Sven wrote:
Sorry, but before I continue reading, why is Raphaels' metadata code
not available? You certainly wrote him a mail asking for it, didn't
you? So why is he holding the code back? Does it even make sense to
continue discussing this w/o Raphael?
The code is available from
Me:
(Raphael's plan has them implemented as plug-ins, but I think that's too
awkward.)
Sven:
What is akward about it?
Passing, say, an ExifData struct to a plug-in is awkward. Calling a function
and giving it a pointer is simpler, and much faster too. And then there's
all the extra
Okay, following up on earlier discussion: I think I have a reasonable
way of dealing with the jpeg-exif stuff until Raphael's metadata code
arrives. Raphael's plan is to turn everything into XMP and store it
all in a single parasite. The interface between the jpeg plug-in and
the metadata
Sven wrote:
- (re)configuring keyboard shortcuts (using Dynamic Shortcuts, the
new Shortcut Editor or simply by editing the menurc
- the new file-chooser dialogs and how to use them best (explain
keybindings and the use of bookmarks)
- copy and paste between GIMP and other apps (what
Daniel Egger wrote:
What I've seen just recently and deem as a good idea would be a
possibility to make dialogs translucent (better yet, only if not
currently focused) to reduce the screen estate necessary to manipulate
an image. Anyone having an idea of the feasibility and complexity
of an
I wrote:
6) Allow data items such as brushes, patterns, etc to be organized
into categories. (Not implemented.)
I see #6 as far and away the most important, and I would like
it to be the main focus of my effort, assuming we can come up with
a good plan. We have discussed this on #gimp
Sven wrote:
Actually, no code should be committed to CVS at the moment until we
have made up a roadmap that outlines what we want to achieve with GIMP
2.4.
Here is my personal roadmap of things I would like to be able to
put into 2.4, assuming all goes well:
1) New rectangle select tool
Shlomi Fish wrote:
Now due to #3, what we have in CVS now (which is a cleaned-up version of
before that) is incompatible with what he sent me. So either we clean-up/add
some minor features (a better PDB entry, for example, which I added) to his
version or we similarly engineer the CVS code.
Sven wrote:
A) Artist: Ascii, name of the image creator, in parasite
gimp-artist.
ASCII isn't a reasonable encoding for names. I strongly hope the EXIF
spec doesn't define this as ASCII.
The spec defines it as ASCII. Before you get too outraged, please bear
in mind that the EXIF
Robert Krawitz wrote:
4) When the exif specifies that an image is rotated, the plug-in
pops up a query asking the user whether to rotate it into
standard alignment. I thought it was better to ask rather than
do it automatically, because there are probably a substantial
Carol wrote:
is the proper EXIF file requirement that the name ends in .JPG case
sensitive?
Well, that was my point -- we're certainly not going to pay any
attention to such an absurd specification.
Best,
-- Bill
__ __ __ __
Sent via the
Hi,
I just made a one-line change in cvs head, suggested by Dave Ahlswede,
that inverts the relationship between pressure and brush size for the
airbrush, on the grounds that this more accurately reflects the behavior
of a real airbrush. People who use tablets should try it and see if they
Hi,
I have added a new procedure to the pdb in CVS head by making some
modifications to plug-ins/common/compose.c.
It is called Recompose, and is accessible from Filters-Colors and
Image-Mode. It can be run on any of the grayscale images produced by
Decompose, and runs without asking any
Dennis Gnad wrote:
I saw the flame plug-in isn't updated by the orginial author since a long
time, but he continued his work as seen at http://www.flam3.com . He just did
not continue work on the gimp plug-in. What I simply did was merging
code together. . . . Apply the patch to the
Sven wrote:
Let's see. We have GIMP 2.2 done and are preparing to switch to GEGL.
At this point you are trying to propose a kludge? Sorry, but I am not
going to read any further...
Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and
if it is nearly ready to use, then the CVS
I've been thinking about three things that are highly desired but
have been waiting for the migration to gegl: support for 16 bits,
layer groups, and procedural layers. It seems to me that all of
them can be achieved in GIMP 2 without major infrastructure changes,
not perhaps in the most ideal
I wrote:
The change is almost trivial, if my suggestion of simply using the
selection without asking any questions is acceptable. The status of
this, as far as I can see, is that the bug report (
http://bugzilla.gnome.org/show_bug.cgi?id=72959 ) is waiting for
somebody to say that it is
Joseph Heled [EMAIL PROTECTED] writes:
In 2.2, the histogram always takes the full image. I thought that in
the past it took the selection if there was one. Am I imagining
this?
Sven writes:
Yes, I think you are imagining this. There's a rather old bug report
about it and basically we
Joseph Heled wrote:
In 2.2, the histogram always takes the full image. I thought that in the
past it took the selection if there was one. Am I imagining this? Is there
a way to get the histogram for just the selection?
Carol wrote:
it is easy enough to make a new layer of the selection
Joao wrote:
That said, I raise the question: Should the scissors tool be visible
by default in the toolbox?
Well, the real problem with it is that the edge-hugging algorithm
sucks. It would be a very useful tool if it actually worked. So
I suppose my attitude is:
a) It's too late in the
If people need to work with text layers in plugins, then clearly the
right approach is to add new functions gimp_layer_is_text(),
gimp_layer_get_text(), and gimp_layer_set_text() to libgimp.
I expect this wouldn't even be very difficult.
Best,
-- Bill
__ __
Sven wrote:
You obviously didn't understand me. Adding such an API would be a
major undertaking and we are not going to add such a framework for
anyone unless that someone has at least built a prototype in the
core. I do simply not believe that there is serious interest for
developing other
Sven wrote:
If you had a look at the Ink tool you would have noticed that all
paint tools are extraordinarily simple. I agree that other tools
(those that draw to the display) are a lot more complex but all paint
tools are identical except that they register different GimpPaintCore
objects.
Michael Schumacher wrote:
Currently, a user can't really figure out what this setting does, at
least by reading the docs.
http://www.gimp.org/unix/howtos/tile_cache.html
This is part of the problem - some useful information is kept from users
of other platforms.
[
Joao wrote:
I did not had a good night, and am filling to sleepy to fill a proper
report - I am just trying to use the lightning effects and it seens broken -
It seems that when trying to use more than one light source (by
setting light 2 to other than None ) the location and direction
Hi,
I have thrown together a tentative list of new user-visible features
coming in 2.2, aiming for comprehensiveness rather than good presentation
or good organization, and placed it on the Wiki, at
http://wiki.gimp.org/gimp/WhatsNew2
Please use it in whatever way seems best.
-- Bill
Hi,
GIMP has its share of annoying features, and its share of great features,
but there are two features that I find especially annoying, and wish I could
make go away.
1) The fact that selection tools move things if you click inside the
selection. Even knowing this perfectly well, I am
Sven wrote:
Oh? I don't remember to have heard complaints about this before.
Well, somebody has to be first :-).
I wish at least I could set a
preference so that all tool options would be reset to their defaults
at the beginning of each session.
This preference option was planned
No. The user is not supposed to see them, never. Actually no such
messages should ever be emitted. If it does, there's a programming
error. It would not help to show these messages to the user.
What about a user who wants to file a bug report? Surely
they are relevant in that case?
Best,
Sven, Tor, Michael, Nathan, thanks for all the information. I've
tried to synthesize it into something both correct and helpful. The
result should show up at http://docs.gimp.org/en/ within a couple of
days, in section 2.4.11: maybe you can look it over to see if there's
anything I've screwed
On this issue I think I agree with Sven that the gain of reducing
annoyance for new users does not offset the costs of (a) reducing
the consistency of size-entry areas and (b) annoying the mass of
existing users who know how it works and don't expect it to change.
It's especially bad to change
Hi,
I would like to add some information about fonts to gimp-help-2, but I'm
hampered by lack of knowledge. Here is what I know: In Linux, you can
add a Truetype or Freetype font by putting it in your ~/.fonts directory
or your .gimp-2.0/fonts directory.
Here is what I would like to know:
Sven Neumann wrote:
I am not going to allow the source tree
to be clobbered with more stuff simply because we are too lazy to add
some simple notes to our web-site and FTP server. In the long run we
will want to split GIMP into even more packages.
Dave Neary wrote:
On another note, I'm not
Cathy Irwin writes:
Can anybody point me to some documentation that explain
the differences between the various drawables comprehensively?
At a conceptual level, the difference is very simple: A layer is a
visible part of an image. A channel is not: it is a grayscale
drawable that acts to
Kevin Cozens wrote:
Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit
(ie. with translations) if it isn't fully ready yet by exposing it to
more users but what is in the best interest of GIMP and its users?
I'm actually quite sympathetic, but it doesn't seem to me that
Sven wrote:
Please comment on this proposal if you disagree with it or think there
are important features missing that you are already working on.
I don't disagree with it, but I wish you had mentioned specifically what I
consider the biggest issue of all: bug #143668 (performance problems
Sven Neumann wrote:
I don't think this needs any further discussion. I doubt that anyone
would seriously disagree that floating selections should be removed or
at least reduced. The point is that it needs an experienced GIMP
hacker who wants to tackle this task.
There is an almost trivial
Nathan Carl Summers wrote:
I can't honestly think of a good reason to disable color management, but
couldn't we just have an option for this monitor's colorspace instead of
having two choice to choose from?
The first time I tried to use PhotoShop with color management, I was
totally
Joseph Heled wrote:
I would argue that non interactive plugins (or interactive plugin
run in non interactive mode, which I presume to be the same thing),
should not bring up any progress bars.
You would argue incorrectly, then. Even if a plugin is noninteractive,
bad things usually happen
Steve Siverling wrote:
just curious, what is involved for developing for gimp? What would
I need to do? I know a C++ would be good, and a compiler.
I think the best way to answer this question is to point you to
the Gimp Developers web site, http://developer.gimp.org , where
it is answered
Actually I would go about this differently: Start by
making a list of all of the triangles, recording their
vertices. Then go through the image, and for each pixel,
figure out which triangle is visible there, and render
its color. I think this would be a lot faster, and it
lets you work with a
Hi,
I have been putting some stuff into gimp-help-2 recently, and one
thought I have is that it would be a good idea to make use of
material from the old Gimp 1.2 GUM to the extent possible. In
the old GUM there was a pretty nice chapter about using Gimp with
tablets, but it is seriously out
Philip Lafleur writes:
I don't think there's much of a point in rewriting what's already
maintained and much more complete in the HOWTO at
http://linuxwacom.sourceforge.net .
Well, the whole point of trying to use material from GUM is to
avoid unnecessary rewriting, but if that HOWTO is the
Philip Lafleur wrote:
In Linux that is indeed the case, unfortunately, and as far as I know
that document is probably the best source of help. I don't think the
material from GUM, which is pretty outdated, suggests anything different
- in fact, from looking it over, it appears that things are
Steve Siverling wrote:
I was wondering, if anyone would be interested in developing this.
Also what motivation it would take to make this happen.
For a month of work? I would say about $5000 - $1 worth of
motivation.
Best,
-- Bill
__ __ __
Joseph Heled writes:
I might be wrong, but this will not solve it either. I assume the
AB (color information) might be in the same units, but I don't
think Luminosity is. (and I can make the argument that Hue and
Saturation are in the same units as well, the problem being how
to fit Value
Sven Neumann wrote:
Huh? At the moment compose doesn't know anything about decompose.
Why shouldn't it work on layers not produced by decompose?
Well, I'm a bit behind the times on this one. I haven't used
compose much for the past 3-4 months, and as I recall this issue
was there then, but
So at the most concrete possible level, here is a suggestion on
how to start:
Step 1: Add a Color Management page to the Preferences.
Step 2: Add enable/disable color management and working
colorspace options to the page. To start with, sRGB will
be the only option for the latter, but the
Here is what I would do, and it wouldn't be very hard to code up:
1) Make decompose attach a parasite called decompose-info to
each layer it produces, specifying the type of decomposition
and listing the source layer and the layers that are created.
2) Split compose into two PDB
Joseph Heled writes:
How (or can you) combine errors/noise in HSV into one error/noise
figure which reflects the total human visual error perception.
HSV is the wrong colorspace to use for this purpose. The LA*B*
colorspace was designed to do what you are trying to accomplish:
supposedly,
Joseph Heled writes:
It turned out to be as simple as attaching a gimp-comment and
jpeg-exif-data parasites to the image.
Note that in Gimp 2.1 the exif data parasite has been renamed
exif-data, because it is not specific to jpeg files.
Best,
-- Bill
__ __
It really isn't all that complicated. Here is all you need to do
(this is basically what Sven outlined with a couple of extra details.)
1) Gimp uses the same color space internally for all images. This
could be either sRGB or a user-selected one (in which case it is
specified by a
Alastair M. Robinson wrote:
In short, though, if we use this method, we don't need to agree on what
to call our working space, because it will simply be whatever is
appropriate for the image being edited!
Dave Neary wrote:
I think this is probably a very bad idea.
I agree with Dave on
Alastair M. Robinson writes:
I beg to differ!
A silently applied destructive change to the image data is in my
opinion a very important factor!
It should definitely not be silently applied. When you open an image
that uses a different colorspace from the standard one, you should
get a
Christof Lutz writes:
Could your help me in that point? I just need to know how to grab the
point-coordinates of a click to an image!
If you go into the plug-ins/common directory of the source and grep
for GDK_BUTTON_PRESS, you will find plenty of examples that will
quickly show you how to do
Christof Lutz writes:
yes, that's true and it's a pity that there is no way :-) So what
do you suggest:
I want to mark particular points in one or more images and use the
marked coordinates in my plugin-dialog. Do you think it's the best to
create picture-buttons with more or less small
Wolfgang Mader wrote:
I have read that one is able to use the library with the imagemanipultion
funktions of gimp in a standalone application. What do I need to read/learn
to take advance of this funktionalities? I have never coded gimp realted
things.
The functions in libgimp almost all
Scott,
First, it's not clear whether you are bothered by the resources
Gimp consumes in creating lots of layers, or by the nuisance of
managing them. If it's the former, don't worry about it: text
layers are very lightweight, and you can create hundreds of them
without putting much of a burden
Dave Neary wrote:
To my knowledge, Ernst (who has written the only preview widget currently out
there) won't be at the conference. David Odin will be, though - and he had
started working on a preview widget before the 2.0 release, but hasn't had time
since then to work on the GIMP.
Does this
With the coming of summer and hints of a feature freeze for
2.2 starting to shadow the horizon, one of the things I see
as most important to get into the code is some kind of preview
widget.
Actually it is not so important to establish the code as to
establish the API. The specific
GSR - FR wrote:
Well, what would you call a script that just puts a menu entry and
calls convolution matrix with a fixed matrix?
The main reason not to use convmatrix is that internally it always
does a 5x5 convolution, regardless of the matrix entries. This means
it should take almost three
Sven Neumann wrote:
So the question is, is anyone actually using this
functionality? Are there scripts out there that rely on
plug-in-blur-randomize to be available?
Christopher Curtis wrote:
Is it possible to remove the dialog without removing the options?
Yes, it is possible, that's why
Nice to see the first tarball of the new round come out. There are a couple of things
I notice, though. First, the INSTALL file says:
2. You need to have installed GTK+ version 2.2.2 or better. Do not
try to use an older GTK+ version (1.2.x), it will not work.
GTK+-2.2 itself needs
101 - 200 of 227 matches
Mail list logo
