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
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
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
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
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
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
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,
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
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,
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
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
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
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
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
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
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
201 - 227 of 227 matches
Mail list logo
