Has anybody come to a consensus about whether or not the no-image dialog
should persist after an image is opened?
Actually, yes, the mere fact that it is called a no-image window means that
a consensus has been reached. Your points are reasonable, but when there
are several reasonable
From: Fredrik Alstromer [EMAIL PROTECTED]
As requested, I'm moving this discussion to the mailing list...
for the history, see the bugzilla entry 76616.
I don't have anything to say about how this should work, but
I'd like to make some suggestions about the approach to
development. Mostly
From: Sven Neumann [EMAIL PROTECTED]
Well, we have that for 2.6. We didn't put publish it. But we discussed
these points and agreed on a roadmap for 2.6. The question is, do we
gain anything if we published such a roadmap officially? I am afraid
that the only result would be that people will
From: Sven Neumann [EMAIL PROTECTED]
Perhaps if we could first decide what the purpose of the roadmap/task
list should be. I tried to raise that question when we started with this
topic. But no one ever attempted to answer it. So before we start this
again, can we have this discussion,
From: Sven Neumann [EMAIL PROTECTED]
8. improve the text tool
Evaluation: Most of the points mentioned here would be relatively
simple to implement. One of them -- the ability to have multiple
text items within a single layer -- might not be simple, and it should
be considered
From: Sven Neumann [EMAIL PROTECTED]
I don't think we want to publish something and call it a roadmap. But we
had the plan to make a list of important tasks that outline where GIMP
is heading and what we consider important to work on. Since there
doesn't seem to be enough interest among the
From: peter sikking [EMAIL PROTECTED]
I see the list below of what needs input and they are all
worthy problems to solve. But they look to be in part
different problems than the ones discussed for the roadmap
two months ago. There lies the problem.
I will give direction for the small
As promised in my previous email, I would like to look at the
priorities that Peter presented in his LGM talk (at which I
was not present), and try to give a sense of my impression
of how much work each one involves. You can find a web
version of Peter's talk at
From: Nnyah Nyah [EMAIL PROTECTED]
I have a feature request. Let me explain it with an example.
This is a longstanding request, see bug #76616 (Size entry widgets
could use some simple math):
http://bugzilla.gnome.org/show_bug.cgi?id=76616
I'm a little scared of this myself, because it
I guess the reason I'm in such a fog is that all of the tag-using
systems I know about are cumbersome, and allow methods
other than tags to be used to help. Google, for example, is
in some sense a tag-based navigation system -- and it's
great, but you wouldn't want to depend entirely on it for
From: Devin Watson [EMAIL PROTECTED]
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. [...]
This sort of got sidetracked by all the traffic. I'm not sure whether
there is a need for
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
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 the
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
From: Jean-Luc Coulon (f5ibh) [EMAIL PROTECTED]
- I've loaded a tif file (43M)
- called Colors - Curves
- got a SIGSEGV
You can expect some instability for a while, because of the
introduction of gegl into the tools. It probably isn't useful
to file bug reports or send messages to this list
From: Csar Rolln [EMAIL PROTECTED]
Please, don't remove the Wrap and Smear options,
because it are useful (tileable patterns is a example).
Removing the functionality of GIMP isn't usability.
As I tried to explain, Wrap is not useful with edge detection.
It is very useful with blurring,
Sven wrote:
You have a point here. But you also need to look at the costs of
renaming a menu item. The documentation needs to change and
users need to learn the new name. With the amount of plug-ins that
we have it is rather difficult to keep track of changes so IMO we should
try to avoid
Michael Schumacher wrote:
And you do feel that the way to do this is to just commit things, and
everyone else has to keep up with the changes without knowing what
others are to be expected, and if something isn't right, we'll just have
to revert it?
No! The way I did it was broken. But
I think I probably would be able to come pretty close to turning
the list that Chris Mohler created into a more-or-less complete
2.6 roadmap, with one exception: I haven't been following the
developments concerning gegl. I wonder, then, whether the
people involved in developing gegl and
John Marshall has written a new psd-load plug-in, based
on the old one but rewritten from scratch, with several
new features added. To us (Sven and me) it looks pretty nice,
but neither of us are expertson the PSD format, or have huge
numbers of files to test it on. We would like to commit it
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
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
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
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
(I've changed the subject line, since changing the shape of a text layer
no longer applies.)
Sven wrote:
But that code is all in SVN already. Just pass --disable-toolbox-menu to
configure. Note that you need to do a full rebuild and a fresh install
to make sure that the menu files are
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
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
From: Sven Neumann [EMAIL PROTECTED]
Or is this just about merging the toolbox and image window menus?
Yes, that's what I meant. From a user's point of view, that's
a pretty major restructuring.
-- Bill
___
Gimp-developer mailing list
Excuse me, but I'm finding this whole roadmap process very
confusing. When I look at Peter's web page, I find only one
actual spec, for selection tools. There are lots of other partial
specs, but this is the only one that seems to be completed. Does
this mean that nothing else is ready to have
Peter,
I would like to restate that I would prefer to work under
the guidance of your team. If you can specify the most
important change that you think can be made now, and if
Sven agrees to let me work on it, and if I can see how to
do it, I'll probably be willing to take a shot at it. I
From: Eckhard M. Jger [EMAIL PROTECTED]
there is a thing that i don't understand, my script is opening the
file and so the thumbnail is generated by Gimp automaticly when
closing gimp. ...
Unless a file contains an internal thumbnail (as jpeg files sometimes
do), there is no way to
From: [EMAIL PROTECTED]
I like the idea of having this functionality available. I have tried the
patch and it seems very capable. There appears to be bug which presented
itself when I did the following: ...
Thanks for the bug report. I'll take a look at it. As a general comment, I
would
From: Martin Nordholts [EMAIL PROTECTED]
The administrative overhead would fall on me to the extent possible, and
as long as patches are GPL and taxes etc are handled, what legal
problems would there be? Maybe these problems are bigger than I
currently see
The problems are bigger than you
Jesper de Jong wrote:
Is Gaussian blur not a standard algorithm that has a well-defined meaning
for the radius? See for example http://en.wikipedia.org/wiki/Gaussian_blur
The answer is no, there is not a single well-defined meaning. From
a mathematician's point of view, the equation contains
From: Isaque Profeta [EMAIL PROTECTED]
Date: Sat, 17 Nov 2007 16:00:34 -0200
Hi guys,
I'm a user and now starting read the gimp developers site and looking
API and other things to see what I can do to help.
So, I have a question: I'ts too hard to make a full support of GIH
(Animated Brushes)
From: Lionel Tarazon Alcocer [EMAIL PROTECTED]
Is there a function which exports paths/vectors to a SVG file or string?
No, but it would be easy to add, since the functionality exists in
the core. If you need this, probably the best thing to do, to start
with, is to file an enhancement
Maybe these ones ?
http://developer.gimp.org/api/2.0/app/app-GimpVectors-export.html
Those functions are only available from within the GIMP program
itself, not from plug-ins.
-- Bill
__ __ __ __
Sent via the CNPRC Email system at
From: peter sikking [EMAIL PROTECTED]
Well, this topic is not so clear cut. There are many factors:
- the relationship with vector apps, especially inkscape.
we saw during the user scenario weekend that live update
of linked-in svgs as they are saved by inkscape would fit
a symbiosis
One of the things that GIMP badly needs is a vectorial tool for
drawing lines and arrows. This also would make sense as a first
usable implementation of vector layers.
Here is how I think it could be structured:
1) For UI, there should be a GimpLineTool interface, modeled after
As GIMP moves toward vector layers and layer groups, it will more and
more need a capability for vector selection -- that is, for the
kind of selection capability found in vector graphics programs like
Inkscape, whose target is a set of objects rather than a spatial
region -- a vector selection
From: Sven Neumann [EMAIL PROTECTED]
I don't see GIMP moving towards vector layers, at least not for 2.6.
Layer groups are also not on the near-term roadmap. Perhaps we can
target them for 2.8 but that remains to be seen.
Oh well, consider my suggestions as early contributions to the
2.8
From: Raphaël Quinet [EMAIL PROTECTED]
So here is a short list of what I think makes sense to include in XCF
files:
- All image parasites and layer/drawable parasites. They should all
be persistent - no reason to have exceptions.
The problem is that when a parasite gets saved, it becomes
From: Karl Günter Wünsch [EMAIL PROTECTED]
EXIF in an edited image has little resemblance with the original anyway, so I
would suggest stripping that except for the IPTC tags. I would also be happy
if the IPTC tags were settable in the GIMP, instead of having to resort to
other programs.
From: Evan Designs [EMAIL PROTECTED]
... I was wondering if you guys had some advice or any interest in making a
GDi+
api for us?? We would pay, of course.
Anyway, mull it over, any reply is appreciated,
Did NOT mean to offend anyone with the question in any way!!!
THANKS
Shelly
From: Raphaël Quinet [EMAIL PROTECTED]
+ remove the prompt for EXIF orientation: it should always be done
I agree with this idea now. The problem I had with it before is
that it would do bad things to people whose EXIF images had incorrect
rotation information, and that would have
To my understanding, switching to Cairo for the canvas (and switching
away from XOR drawing) will involve two things:
1) Porting GimpCanvas to Cairo instead of raw GDK. That should be pretty
straightforward: I think virtually all of the relevant code lives
in app/display/gimpcanvas.c.
2)
My congratulations as well, great to see the release out!
From: peter sikking [EMAIL PROTECTED]
From my UI-redesign point of view, we need to get GEGL and Cairo
in GIMP, else there is little chance of innovation in the UI.
Also what the GIMP project needs right now is a short ( 6 months)
My understanding is that it is never too late for translation improvements,
even well after a stable release, and that the correct place to send them
is to the person responsible for your language. Often translators don't
even *begin* to work until the string freeze that comes shortly before
a
no spam [EMAIL PROTECTED] wrote:
I plan to hire a famous, professional software development company/team for
porting GIMP into a new Operating System, on a new type of CPU and new
hardware,
with fixed budget and time limit.
What is the name of the excellent software development
It would be helpful to get more input from yosh.
-- Bill
__ __ __ __
Sent via the CNPRC Email system at primate.ucdavis.edu
___
Gimp-developer mailing list
From: Luis A. Florit [EMAIL PROTECTED]
For Bill:
[...]
Well, I am really tired about reporting bugs at Bugzilla
and not even getting an answer, specially for Fedora bugs.
[...]
Fedora maintainance sucks. Please don't judge GIMP's bug handling
by Fedora.
For gg:
I suspect it got ignored
From: G Bulmer [EMAIL PROTECTED]
I am attempting to write a gimp plugin to 'bridge' between the gimp
and a 3rd party piece of technology, under Linux.
[...]
My users need to stay with their currently deployed versions of
software including the gimp (2.0.5) [...]
If the code for your
From: Mark Lowry [EMAIL PROTECTED]
I'm working on a script in which it would be
advantageous to use the mouse to click on an image and
have the pixel coordinates captured as an input.
Right now I have to manually enter the coordinates for
four points, which is a tedious process.
Is there a
From: [EMAIL PROTECTED]
There is an underlying issue where both origin and offset of a region are
stored as gint before any processing is done. This means two rounding
and/or trucation errors can easily end up producing a one or two pixel
error.
Yes, but there are other basic coding errors
From: Luis A. Florit [EMAIL PROTECTED]
I reported this bug in this list some time ago . . .
For philosophical questions, it is good to bring them up first
on this list. But for actual bugs, in the sense of the
program doing something that is clearly incorrect, it is
best to file a
From: peter sikking [EMAIL PROTECTED]
Guys and gals,
For our presentation at the LGM meeting we would like to show some
results from our UI redesign projects. [...] Please help us to make
this list by suggesting these top-10 bugs.
Here are 11 I have seen requested multiple times, and this is
From: Nancy Parsons [EMAIL PROTECTED]
I'm not sure if I am approaching this in the correct way, but we are a
non-profit
organization looking for developers fluent with the GIMP programming language
to
create a customized version of GIMP.
[...]
So would anyone be able to point me in the
From: Nancy Parsons [EMAIL PROTECTED]
I didn't want to bother everyone with the detailed specs of our project, just
hoping
for the URL of a few places to search for GIMP developers for hire.
This is the right place.
If you, or any other developer would like more detailed information on
From: Helmut Jarausch [EMAIL PROTECTED]
Date: Sat, 31 Mar 2007 13:10:19 +0200 (CEST)
We had some discussions here 5 weeks, ago.
I had a look at the current implementation (in the development version).
There I found the reference to a paper by T. Georgiev (from Adobe).
The current
Jim Sabatke wrote:
I've just compiled a plugin based on a denoising program that attracted
slashdot's attention a short while ago. [...]
Jim, there is already a GREYCstoration gimp plugin, which you can find
out about by googling greycstoration gimp plugin. Is yours better?
In any case, the
What fun!
Curiosity piqued, I tried to do some quasi-controlled analysis, using
the following method. For various values of foo, I did a Google
search for foo developers rude and then for foo developers
friendly, and computed the ratio of the number of hits, yielding the
RQ or rudeness quotient
Acually the thing that struck me was that the answer from Mitch
was not only a little rude (which is unusual for Mitch), it was
also a bad answer -- it doesn't make sense to download the source
code just to find out what language it is written in.
Now if the first thing that occurs to *Mitch* is
From: Luis A. Florit [EMAIL PROTECTED]
[ . . . ]
My questions: When to use one and when two iterators? Which one
should I use for a procedure like the one described in my plugin?
Is this indeed faster than the method I implemented based in myblur5.c?
You probably shouldn't do this at all.
[...] The thing I did not
expect was that it had well over a gig of ram left unused, no swap used,
30 gig of unused drive, and it still thought the hard drive was full.
[...]
It might help if I explain a little more about how GIMP handles
memory. GIMP does not rely on the operating system
From: Federico Alcantara [EMAIL PROTECTED]
I am interested in knowning if Gimp is written in
C/C++, and which tools are needed to compile, debug,
and test it?
You can find a brief overview at
http://wiki.gimp.org/gimp/SummerOfCode
and a lot more detailed information at
I think you have hit an actual bug, and that it doesn't have anything
to do with python, because I have encountered a similar thing in a
modified version of gimpressionist that I worked up, written purely
in C. I believe that there is some sort of memory leak that causes
gimp in some situations
Anton Slesarev wrote:
I would like to improve performance or quality of image processing
algorithms.
Try to describe some specific targets. [...]
Hi Anton,
I think all of these are good ideas, to varying degrees.
If you would like to do some of these things for SoC, it would
be a good
Concerning the plug-in example, if you want to see the proper way
to do it, you can look at the real blur plug-in, in plug-ins/common/blur.c.
However, as Sven suggests, that plug-in only does a 3x3 blur, and a
proper implementation for NxN, as in the example, would be pretty hard to
read -- too
From: Claus Cyrny [EMAIL PROTECTED]
Date: Tue, 06 Mar 2007 18:10:10 +0100
Hi all,
I would like to know if 'gfig' is supposed to
be included in Gimp 2.4? The handling is
really so uncomfortable that I would rather
like to see the text tool improved, the way it
is already realized in Paint Shop
This discussion seems to be going astray a bit. Let me try
to supply some suggestions and information.
Item: Peter is, no doubt unintentionally, getting into questions
of implementation, as opposed to user interface, when he writes
about rectangles. The brush only specifies the area to which
This discussion goes on too long and distracts too much. I am
one who would prefer the plugin to work differently, but it is
clear that no solution will be good for everybody, and the approach
Sven has taken is certainly reasonable.
It would also be reasonable, I think, to separately distribute
Gg,
Google Scholar only finds one paper by RG Keys on this topic:
Cubic Convolution Interpolation for Digital Image Processing
RG KEYS
IEEE TRANSACTIONS ON ACOUSTICS, SPEECH, AND SIGNAL PROCESSING,
VOL. ASSP-29, NO. 6, DECEMBER 1981
I was able to download a pdf of that paper using my
Sven wrote:
(3) Should gimp-remote still be built and installed even if the d-bus
functionality is built into the gimp exectuable? The patch currently
doesn't change this, it just removes the reference to gimp-remote from
the gimp.desktop file.
My understanding is that d-bus doesn't work on MS
Re the issues that Akkana mentioned:
The margins can be handled within gimp, and probably the
paper size too -- I was unable to test this when I was sorking
on it so didn't try to handle it. The two Page Setup functions,
the bad placement of the layout stuff, and the disappearing
dialog when
GG wrote: [**]
I agree that it would be helpful to have more guidance
for new contributors, but my own experience is that most
of my trouble has come from trying to understand the
high-level structure -- the overall architecture, the
core objects and the principles for using them. The
Mitch has just made a commit to HEAD that imho is important
enough to justify a message to this list, on the basis of how
commonly the equivalent feature is used in PhotoShop. From
the ChangeLog:
2006-10-21 Michael Natterer [EMAIL PROTECTED]
Added Edit - Fade which allows to modify
From: Scott [EMAIL PROTECTED]
[...lots of stuff...]
I don't know if this is the proper place to post this sort of thing,
but I do hope that you developers will consider listening to some of
us casual users, as the interface has gotten way too overloaded and
user-unfriendly. I seriously am
It seems that for consistency the Move tool should act like a
transform tool --- because after all, it *is* a transform tool.
That is, if there is a selection, it should move the contents
of the selection, otherwise it should move the layer.
-- Bill
__ __
Bill, to you it *is* a transform tool because you are close to the code
and you know the way is it implemented. To the user it *is not* a
transform tool. It's just a tool off the palette like any other that is
called Move and that carries the hint move layers, selections and other
From: Rapha�l Quinet [EMAIL PROTECTED]
As a side note, it would be nice if the rectangle and ellipse
selection tools (not the base rectangle tool) would take Alt into
account before the selection is confirmed and behave as if the
selection had been confirmed: Alt = move selection mask,
From: Michael Natterer [EMAIL PROTECTED]
While doing so I noticed they are all bad and inconsistent.
Here is what I think should happen:
No brushes available for use with this tool. (brush core)
No patterns available for this operation. (clone)
doesn't matter, these will almost never
From: Paul L Daniels [EMAIL PROTECTED]
Hello everyone,
This is my first ever GIMP related programming project.
I've written a stand-alone converter for Adobe Illustrator palette
files (.ai)
to GIMP palette files.
Hi Paul,
Thanks for the contribution. Probably the
From: [EMAIL PROTECTED]
Thanks for your ideas. If you want to play around with Lanczos, you
might benefit by looking over the enhancement requests and bug reports
relating to it:
Bug 162250 Feature Request: Better image scaling algorithms.
http://bugzilla.gnome.org/show_bug.cgi?id=162250
From: Alexander Rabtchevich [EMAIL PROTECTED]
Some plug-ins (edge detection for example) provide images as a result.
If their result is required as a selection, I new only one way to make
it: create layer mask, copy the image into the mask and convert the mask
into selection. Is there a
From: Des [EMAIL PROTECTED]
I am new GIMP. We are looking to extend GIMP to
fulfill some functionality required by our users, and
one of the them is to be able to open an image in
three windows, where one window will be the active
image which allows the users to add additional paths,
and other
From: Shlomi Fish [EMAIL PROTECTED]
I'm afraid to say that http://layers.gimp.org/ is incredibly ugly, and makes
us look very bad. As people who develop an image editing software we should
have at least a bit of rudimentary aesthetic sense.
If this were a bug report, the first thing we would
From: Juhana Sadeharju [EMAIL PROTECTED]
The handles may confuse users if really the grabbing can be done by
clicking in anywhere on the edge. (That is the preferred way to do it
since the first interactive graphics system was written.)
The handles should be removed.
What you are saying makes
From: Juhana Sadeharju [EMAIL PROTECTED]
Date: Mon, 14 Aug 2006 21:12:05 +0300
If I have multiple views to the same image, is the rectangle tool,
the crop tool, etc. visible in each view?
For example, I may have one view to the entire 5000x5000 image,
and second view of size 500x500 in which
GIMP 2.0 was released on March 23, 2004, and then GIMP 2.2 on December 19, 2004.
This was a 9 month release cycle, which is quite reasonable. Howver, it has
been over a year and a half since the 2.2 release, and we are still not visibly
nearing a 2.4 release. This slow progress is holding up
Thanks for the comments. I have changed the code so that when
a user is modifying an existing rectangle, in Replace mode, the
marching ants for the previous selection are no longer shown --
this seemed to confuse almost everybody.
Concerning the options gui, it seems clear that improvements
We are working toward cleaning up for a 2.4 release, and one of the
things that needs to be cleaned up is the new tools, including the
ones based on GimpRectangleTool, that is, the new rectangle select,
ellipse select, and crop tools. In order to fix problems, we need bug
reports that describe
Jimmac,
Thanks for your detailed, thoughtful, and very helpful critique.
I see the hard work you've put into this. I'm happy to see you learn
your way around GIMP codebase. I like the cooperation effort involved.
But expect some harsh reactions from existing userbase.
Well, my experience has
Okay, the old rectangle select tool has finally been removed from
cvs and the new, adjustable, one has taken its place. It is hopefully
in something very close to its final form now.
The rectangle tool project has been a rather long and quite
cooperative effort. I started it, using the old crop
SOC students, if you don't already have a Gnome CVS account, you
should apply for one. You can find instructions on how to apply
at:
http://developer.gnome.org/doc/policies/accounts/requesting.html
Before you apply, you should familiarize yourself with:
A few notes now that things have settled down a bit.
SOC students and their mentors should have discussed things by now,
and be well on their way to working out a plan. My understanding is
that Google should soon be sending the initial $500 payments to
students. The next established deadline is
We welcome seven students who will be supported this summer by the
Google Summer of Code 2006 program. Here is a shapshot of who they
are and what they will be working on:
Hendrik Boom, Vector layers in GIMP, with Simon Budig as mentor.
Hendrik will be starting as an undergraduate in Computer
I have just committed a set of major changes to the UI of the alignment
tool, which make it work mostly like alignment tools found in vector
graphics programs, and hopefully make it esier to use.
The way to use it now is to select layers by clicking on them or sweeping
out a rubber-band
Florent Monnier wrote:
What are these funny connotations in the English language ?
Could someone explain me ?
The results returned from Googling for define: gimp include these:
# lameness: disability of walking due to crippling of the legs or feet
# limp: walk impeded by some physical
I think most of the people in the GIMP community would find this
obnoxious -- but if LPI were willing to offer consulting fees in
the $10,000+ range, there might be some curiosity.
Best wishes,
-- Bill
__ __ __ __
Sent via the CNPRC Email
Michael J Hammel wrote:
1. Developer Wishlist
A lng time ago there was a wish list of features for GIMP. Is there
any such thing now, specifically as seen from the developers point of
view?
The real wishlist is the collection of enhancement requests on Bugzilla.
You can also look at
1 - 100 of 227 matches
Mail list logo
