If you plan for three months, it will take nine months, so you should plan for
three months. If you plan for six months it will take over a year.
Feynman's Law: Everything takes twice as long as you expect it will, even when
you take into account Feynman's Law.
Best,
-- Bill
Would it be too troublesome to call this release that will just
finish things that have started, as 2.0.X series, instead of a 2.2 ?
Yes. Only bug-fixes in a stable release series.
And for a more practical reason, it can't be done without branching, and
you don't want to call both branches
Hi,
I have been thinking about how to improve the consistency of the
user interface for plug-ins, and have come up with a tentative plan
and the mechanism for implementing it, which I will outline here to
see if people think it is reasonable and workable.
First, though, a little terminology.
From: Carol Spears [EMAIL PROTECTED]
would it be reasonable to have plug-ins that change the drawable to work
on a copy of the drawable? that would take away the need to
differentiate between the two.
The point is that things like Cancel and Okay buttons are only relevant
to a subset of
1) Every filter should produce a dialog when called interactively.
At the moment, some just do their thing without showing any dialog:
this is bad.
Why is this bad? There are plug-ins that are supposed to be completely
non-interactive. You call them from the menu, they do their job. What
is
The problem is that the blurb and help strings as they are
registered with the PDB are (a) not meant to be user help and (b)
missing or not helpful in almost all plug-ins. Also these strings
would have to be translatable. This could be easily changed but before
you call for translation there
You have valid points Bill. However, popping up unnecessary dialogues will
also undesirably slow down and get in the way of many users. If you proceed
with your suggested changes, then I would strongly suggest an option to
bypass the dialogue for plug-ins that don't really need one.
Well, the
a) Menu entries have a rule about Only those that request extra
interaction must have the dots. Non interactive things have no dots.
Interesting. I just automatically assumed that the dots meant that the
name was truncated, and never paid attention to them again.
c) Maybe over menu? Maybe
From: Sven Neumann [EMAIL PROTECTED]
You didn't address point (a). Really, these strings are meant as a
description for developers, not for users. They don't explain what the
plug-in does when being called interactively, they explain what the
particular PDB function does. There are plug-ins that
Hi. I'm starting a writeup of the basic structure of the Gimp 2 interface,
for the user manual / help system. I have made a list below of the names
I propose to use for the various parts. If any of them are erroneous or
ill-chosen, please let me know.
Thanks,
-- Bill
Toolbox Dialog:
Sven Neumann [EMAIL PROTECTED] wrote:
I am not sure if it makes sense to speak of a Layers dialog here. This
is just a dock that happens to contain the Layers tab (which should
probably be called Layers dialog). What you describe here is the
default setup but you cannot assume that the user
On Fri, Apr 02, 2004 at 01:03:43AM +0200, Baard Ove Kopperud wrote:
I must shamefully admit that I have yet to try GIMP 2.0, so
if adjustments-layers is part of it, then I appolegize for
post.
This falls into the category of frequently asked questions.
They are often called effect layers; the
Well, I just tried it a couple of different ways, the the result is perfectly
symmetrical every time. Are you using 2.0.1?
Best,
-- Bill
__ __ __ __
Sent via the KillerWebMail system at primate.ucdavis.edu
Aargh, what a mess. Okay, to sum up: it's Edit-Copy Visible, which
is exactly where it should be, in the Edit menu with Copy. Possibly a
name like Copy All Visible would be better, and possibly it should be
next to Copy instead of at the bottom, but still inevitably many people
will take a
Dave Neary wrote:
I owe Markus a public apology for forwarding this on to the list.
Bravo! I was confident that you would do the right thing, and you
have not disappointed me.
Best,
-- Bill
__ __ __ __
Sent via the KillerWebMail system at
Sven wrote:
But it looks as if I introduced a bug when cleaning up the code and
porting to GTK+-2.4.
I am classifying this one as NEEDINFO. What is the bug, please?
Could you submit it to Bugzilla so that there is a place to put a
fix should somebody happen to come up with one?
Best,
--
Geert Jordaens wrote:
I've modified the unsharp plugin and added a preview
functionality to it. How do I share it, do I sent it to
someone for review?
Branko Collin wrote:
You should probably check first to see if a bug report
for this has already been opened, and if people have
Hi,
I'd like to bring up what appears to be a conflict between 2.0 and
2.1 that will become relevant as soon as a tarball of 2.1 is released.
Building 2.1 causes the version info in pkgconfig/gimp-2.0.pc to
be set to 2.1. This means that any plug-in built thereafter will be
installed in 2.1,
Browser
=
Copyright (C) 2004 William Skaggs [EMAIL SUPPRESSED]
This is a Gimp 2.0 plug-in that permits the user to view EXIF data
from jpeg files. EXIF data is meta-data created by many digital
cameras, containing information about the image and the circumstances
under which
1) When the jpeg loader finds EXIF data, it creates a parasite
called jpeg-exif-data. EXIF data is not specific to jpeg files,
though, and having differently named parasites for tiff-exif-data,
etc, makes things unnecessarily difficult, as far as I can see. Can
this be renamed as simply
Hi,
This is an announcement that I've placed in the Gimp PlugIn
Registry a plug-in for viewing and interacting with image
parasites. It can be found in the 2.0 category, under the
name meta-data. I have only tested it in Linux. There is
no obvious reason why it should fail to work in other
Dave Neary wrote:
You cannot use this plug-in to work with EXIF data, unfortunately: it
is stored in a binary format that requires special handling.
Any plans to add this in the future?
There have been (long) discussions on this before...
[ . . . ]
Somewhere in there you might find
Michael Schumacher wrote:
3) It might be possible to attach a color profile to an image and have
it included when you save a TIFF file -- I haven't been able to
test this, though, so don't get excited yet.
Maybe someone could give some tips on how this is done? Might make some
of the
Hi,
I have added a plug-in to the registry (http://registry.gimp.org/plugin?id=4177)
that some may find useful: it does edge detection using the difference
of Gaussians method, which is widely used in computational vision.
Basically it works by calculating two Gaussian blurs with different
Sven Neumann wrote:
IIRC Dave did a change to the edge plug-in somewhen in the 1.3.x
development cycle that incorporated code from the thinline
plug-in. Doesn't that mean that it can produce similar results?
Also I remember that the plan was to move all edge algorithms into
edge.c in order
I would like to point out that even if you feel compelled to
respond to a rude comment (usually it is better to be silent),
you still have the choice whether to be more rude or less rude.
Being more rude will almost always escalate the problem.
At this point the evolution of this discussion is
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
Sven Neumann wrote:
Ughh, We are running on a temporary server and I wanted to let the
mirrors pick up the package before announcing it here. You could have
waited for the announcement at least :(
Sorry, it never even occurred to me that there might be such
a problem.
Best,
-- Bill
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
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
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
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
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
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
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
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
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
__ __
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
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
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
__ __ __
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
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
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
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
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 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
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:
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
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
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
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
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
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.
[
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.
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
__ __
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
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
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
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
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
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
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
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
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
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.
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:
- (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
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:
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
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:
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
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:
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
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:
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
1 - 100 of 227 matches
Mail list logo
