All I have to do right now is learning how to make my text follow the path.
Help would be warmly appreciated.
I'm pretty sure that it isn't currently possible. The text along
path function is basically a hack, and was never intended to be a
final product. A proper text-along-path function
Well, my memory of the dynamic text plug-in is pretty fuzzy, but in
any case the code that is out there seems to date from around 2001,
and I doubt that anybody will want to go to the effort of updating it.
-- Bill
___
Gimp-developer mailing list
It is likely that the problem comes from using a version of the ffmpeg
library different from what gegl expects -- possibly due to having
multiple versions of the library on your system. If you don't want to
spend time figuring out how to solve that, the simplest solution, I
believe, is to
The dynamic text plugin is many years out of date. It was created as
a way of allowing text to be changeable before Gimp's text tool
supported that. For the past ten years or so the plugin has been
completely useless and therefore hasn't been maintained. I'm not sure
whether that explains the
The best way to think of this, I believe, is as an enhancement of
copy-and-paste. We are all familiar with the problem that if you make
your selection large enough to include all of an object, you often get
a fringe of unwanted colors. If you make the selection small enough
to lose the fringe,
I think it would be pretty difficult to figure out the algorithm by looking
at the Gimp source code. The algorithm that Gimp uses is based on
papers by Todor Georgiev, and you can find a description of the algorithm
in a paper he wrote called Photoshop Healing Brush: a Tool for
Seamless Cloning
It compiles because Gimp plug-ins (unlike PhotoShop plug-ins) are
separate executables, which
communicate with the main Gimp app via a shared memory channel. As
separate executables,
they are compiled separately and don't necessarily need to avoid
function namespace conflicts with
the main app.
Pdbgen is part of the gimp application core. Libgimp is an interface
library designed to
be used by plug-ins -- it is not and cannot be used inside the core. The
functions that
can be used inside the core are documented at
http://developer.gimp.org/api/2.0/app/index.html .
In many cases they
Um, let me say that a little more precisely. Pdbgen itself is not part of
the core, but the C code
it generates to implement its functions goes into app/pdb in the source code
tree, which is part of
the core and can only use functions that are accessible in the core.
-- Bill
The term layer effects should be used carefully. PhotoShop uses it for a
set of modifications
that can be applied nondestructively to a layer, including blurring, color
adjustments, and a limited
number of other specific things.
-- Bill
___
On Tue, Mar 1, 2011 at 1:52 PM, LightningIsMyName
lightningismyn...@gmail.com wrote:
Hello,
The nearly finalised project list for GSoC 2011 is available at the
wiki: http://gimp-wiki.who.ee/index.php/Hacking:GSoC_2011/Ideas
Users who have a comment on the list should raise it now. The
For some reason my text disappeared when I hit send for the previous message
-- sorry! Here
is what I wrote:
It is very important to make sure that each project in the list has a
developer who is prepared
to sign up to mentor it. There are two reasons for this. First, because it
is a waste of
Let me start by noting that although I was once pretty familiar with the
Gimp code, I haven't
looked at it in a couple of years. That being said, this discussion is not
making sense to
me. Plug-ins do not access Gimp core functionality directly, they use an
interface library
known as libgimp.
On Sat, Feb 12, 2011 at 12:01 AM, Ulysses Levy levy.ulys...@gmail.comwrote:
I'm poking around plug-ins/metadata/metadata.c and I want to get
gimp_image_parasite_find (image_ID, METADATA_PARASITE) to work.
I'm pretty sure gimp_image_parasite_find expects a parameter of type
GimpImage, so I
Also I should have pointed you to the documentation at:
http://developer.gimp.org/api/2.0/libgimp/libgimp-gimpimage.html#gimp-image-parasite-find
-- Bill
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
On Mon, Feb 7, 2011 at 4:57 AM, Nicolas Brack
nicolas.br...@student.uclouvain.be wrote:
As I already stated, I'm not confident with gimp's architecture ! (and the
list of class is not very intuitive to dip in)
I prefer to fix bugs at the beginning, it softer for me either. (Besides,
what
On Tue, Jan 25, 2011 at 12:35 AM, Stephen Greenwalt
stephengreenw...@gmail.com wrote:
Where can I help? Here's an ultra-short overview of my background: ...
Here's one suggestion that you could probably work on immediately, and would
prepare
you to work on other things if you are interested.
There is no way to manipulate the undo stack in a plug-in. If you want to
do something
with it in the main program, please explain more about what you want to do.
-- Bill
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
On Thu, Nov 18, 2010 at 6:19 AM, Alexandre Prokoudine
alexandre.prokoud...@gmail.com wrote:
2010/11/18 Łukasz Czerwiński wrote:
Another limitation of using GIMP for a 3 color image is that GIMP does
not
use what are known in Photoshop as Adjustment Layers.
How about adding this
On Sat, Nov 13, 2010 at 9:13 AM, Martin Nordholts ense...@gmail.com wrote:
You can't know for sure that no one uses this plug-in in some script
somewhere, and if we don't have a good reason to break our plug-in API,
we don't do it. Impatience is not a good reason :)
Here is a better reason,
That's actually supposed to be supported already. You should be able to use
a guide
with the alignment tool exactly as though it is an infinitely long layer of
zero width. I
don't have a working gimp at the moment though, so I can't check. My memory
is that
it used to work.
My recollection is
I just looked over the code -- if I understand it correctly, it creates an
arc of the specified angle
passing through each point of the image, generates a set of points equally
spaced along the arc,
uses interpolation to get the color for each of these points, and then
averages all the colors
Given that decisions made about layer modes will have consequences
for years to come, it strikes me that there is an urgent need for a
formal specification of what is to be done. A natural place to write
one would be the wiki, but since that isn't functioning, maybe it
would be possible to create
It would be much better not to use the word toolin this way. In Gimp, a
tool
is an element of the user interface. When the user applies a tool, the end
result is to perform a series of operations on the image. Thus, a tool is a
user interface element that allows the user to interactively
It wouldn't be much harder to support html layers than to support text
layers, if it
were possible to link to a library that would do the rendering. The
problem, as somebody
pointed out earlier, is that html was never designed to be rendered in a
definite way. The
idea is really misguided --
Pluggable tools would be nice, but the tool system is already set up to make
it
easy to add new ones. It's one of the easiest places in the gimp code for a
new
developer to work, although it would be a lot easier if there were more
developer
documentation. The problem with the iwarp tool wasn't
Let me respond to the points that have been made in this thread. The first
thing
to say is that there are solid arguments in both directions, and any
decision is a
trade-off, so there is no need to insult one side or the other.
The global popup menu is certainly useful; I have used it very
It wouldn't be that hard to implement a tool that would scale in a way that
feels fluid. But
I question whether it is worth the effort. It's hard to see what user
interaction would be
easier with smooth scaling than with scaling in 10% steps.
-- Bill
It isn't as bad as it looks. The im_menu stuff all relates to a special
submenu, and
you can discard it. The rest you can replicate as is (with the obvious
changes).
Here is a quick summary of how to create a context menu for a tool:
1) Create a get_popup handler similar to
If you want to do this for your new tool, you might benefit from looking at
gimptexttool.c --
the function gimp_text_tool_get_popup is what sets up the context menu for
the text
tool. It is invoked in the gimp_text_tool_class_init function, in the line
that reads
tool_class-get_popup =
At a minimum, you need to add your new tool to the list in
app/tools/gimp-tools.c, so that it
will be registered. You'll also have to rename some things to avoid
duplicate names -- maybe
you've already done this but you didn't say so.
-- Bill
___
Parasites are a mechanism for attaching arbitrary binary data to an image or
layer,
so they will support just about anything you can imagine. The main thing to
think
about is compatibility: if you want your plug-in to generate persistent
parasites and
read them later, the process needs to work
On the whole it's probably better to use the existing layer, because that
way you automatically
keep its properties such as transparency, mode, etc. If you create a new
layer, you will have to
set all those things by hand. In terms of computational load it probably
doesn't make much
difference
The real problem with script-fu is that it is archaic. Few people in this
modern age want to deal with Lisp-derived languages, with all those
ridiculous strings of parentheses. It's like going back to the dark ages of
programming. Even a scripting language derived from BASIC would make more
That error message comes from groff, a text-formatting program. But I don't
know why gimp would be invoking groff. The most common time it is invoked
is in printing man pages, but that doesn't seem likely to apply here.
-- Bill
___
Gimp-developer
,
-- Bill Skaggs
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
It looks like this bug has already been reported, at
https://bugzilla.gnome.org/show_bug.cgi?id=605617
-- Bill
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
What you want is probably either a GimpColorSelection
( http://developer.gimp.org/api/2.0/libgimpwidgets/GimpColorSelection.html )
or a GimpColorButton
( http://developer.gimp.org/api/2.0/libgimpwidgets/GimpColorButton.html ),
which pops up a GimpColorSelection when pressed. I don't think there
On Mon, Aug 31, 2009 at 9:05 AM, Martin Nordholts ense...@gmail.com wrote:
On 08/31/2009 10:30 AM, Eckhard M. Jäger wrote:
Do we get the permission promoting GIMP in TORCS-NG in general?
Hi,
Personally I am totally fine with you promoting GIMP and find it hard
imagine anyone being against
On Mon, Aug 31, 2009 at 10:33 AM, Michael Schumacher schum...@gmx.dewrote:
Bill Skaggs wrote:
To clarify the issue here, some names, such as PhotoShop and Linux,
are trademarked and require permission in order to be used. Gimp,
however, is not trademarked, so no permission is needed
GimpVS is not associated with the main Gimp project, and it looks like
development on it came to a stop in March 2008, so you will probably have to
do a lot of work to make this happen. Regarding the original problem,
PhotoShop PSD files are designed to support PhotoShop's internal file
format,
Yes, see http://library.gnome.org/devel/gtk/stable/GtkFileChooserButton.htmland
the associated pages.
-- Bill
On Thu, Aug 27, 2009 at 7:44 AM, rfks97...@sneakemail.com wrote:
Hi,
I hope this is the right mailing list I am asking this question in.
I am written a sound processing GIMP
On Tue, May 12, 2009 at 6:55 AM, peter sikking pe...@mmiworks.net wrote:
I have big apprehensions that a machine script need to touch the
users' undo history. I would like to know from David Hodson what
he is trying to achieve manipulating the undo stack.
I have some doubts myself about the
On Fri, Jan 30, 2009 at 12:33 PM, Glimmer Labs glimme...@gmail.com wrote:
I have been developing a plugin that involves users editing files and I need
to be able to prompt them to save when the gimp closes.
[...]
I don't think there is any way to do this using current functionality.
On Mon, Oct 6, 2008 at 12:05 AM, Sven Neumann [EMAIL PROTECTED] wrote:
So, what are your plans for 2.8?
I think I'm going to focus mainly on integrating Skalle's on-canvas
text code, which
should be ready for merging into trunk immediately after the
branching, if you and
Mitch approve. I'd
On Sat, Jul 26, 2008 at 3:28 PM, Theodore Imre [EMAIL PROTECTED] wrote:
...
It's unpleasant when people take this sort of angry and demanding tone for free
software that they haven't contributed to. It's hard to give a calm response
without feeling like a wimp.
-- Bill
On Fri, Jul 18, 2008 at 12:32 AM, Sven Neumann [EMAIL PROTECTED] wrote:
Hi,
if you have questions on using GTK+, please ask on gtk-list or
gtk-app-devel-list. Thanks.
Um, GtkWrapBox is part of Gimp, not GTK+, in spite of its name. (I have
no doubt that Sven knows that, and was reacting
Here is to me the most important question. Suppose the user wants
to switch back and forth among a few brushes that don't have any
natural relationship. Suppose for example that the user wants to draw
with a pencil brush, and then erase parts of the drawing with a round
parametric brush, and
pampryl wrote:
In the Gimp, there is a toolbar which contains exclusively icons.
Is this kind of toolbar a specific component of GTK+ ?
Where can I find the source code of this component either
in GTK+ or the Gimp ?
The code makes use of a widget called GtkWrapBox, from which two
other
The root of the problem, really, is that gimp currently shows every
brush in its search path. There won't be any major improvement
until that basic problem is fixed, and the user is given control over
which brushes are available at any given moment. Fortunately,
there is an ongoing Summer of
On Sun, Jul 6, 2008 at 9:41 PM, Rogier Wolff [EMAIL PROTECTED] wrote:
But then why, on a machine with 700Mb RAM, does EVERYTHING take
so very long? My image is only 50Mpixel.
The minimum memory usage for a 50 Mpixel RGBA image is 400 MB, and that's
if you only have a single layer. So given
On Sat, Jun 14, 2008 at 10:34 AM, Sven Neumann [EMAIL PROTECTED] wrote:
One open question: Can menus/image-toolbar.xml currently be stored
inside ~/.gimp directory, i.e. is there a way to customize those .xml
files without messing around with the systemwide Gimp installation?
No, there
Jim Sabatke [EMAIL PROTECTED] wrote:
It seems that in 2.4.6 that exif data are missing when saving as a
compressed jpg. They are not missing on jpgs with no compression.
There is no such thing as a jpg with no compression, so it is pretty
much impossible to make sense of what you are saying.
Torsten Neuer [EMAIL PROTECTED] wrote:
I've been working on re-animating the old User Filter plug-in by Jens
Restemeier lately and it is now in a state where it begins to be usable.
You an find things at http://gimpuserfilter.sf.net/
I'm not announcing this to the general public yet . . .
Gimp handles all this with its own special code, which you most
definitely don't want to try to replicate.
There are several ways to handle this. Basically the thing you have
to know is that widget drawing happens in response to expose events,
and what you need to accomplish is to make the large
Erik Jonsson [EMAIL PROTECTED] wrote:
I'm interested in applying for Google's Summer of Code for gimp (yes,
I know I'm in the last minute :) ), and the project that seems to suit
me best is On-canvas text editing. I have a question though...
Hi Erik,
We already have an application for
Andrei Simion [EMAIL PROTECTED] wrote:
I run Gimp 2.2 on a Red Hat machine. The Perl scripts delete the images
that are created by using gimp_image_delete. Even so, the swap file is
created and it inflates significantly. For instance, after creating 250
images its size is of 2.7 MB. If
Joshua Stratton [EMAIL PROTECTED] wrote:
Does anyone have any comments about this proposal?
If you can build the svn-trunk version of gimp (which by the way
is a very useful thing to do if you are interested in soc), you
can find there a new gegl tool that allows a long list
of operations to be
Lorelei [EMAIL PROTECTED] wrote:
Hi everyone, my name's Lorelei Kelly, and I'm interested in applying for a
GIMP summer of code project. [...]
Hi Lorelei, thanks for the information. The ideas on the Wiki page are only
suggestions, and you shouldn't take them as the only possibilities. My
Ruben Vermeersch [EMAIL PROTECTED] wrote:
A GSoC would free me from the proverbial burger flipping, no better
way to do it than to help implementing a much requested feature in the
GIMP.
Maybe you were trying to make a joke, but this line does not suggest
a very high level of enthusiasm.
The script can be made to work in Gimp by adding one line:
...
(define (script-fu-exp-medit inFileName inPas)
(define (subscript tour p)
(set-output-port p) ;;; THIS IS THE ADDED LINE
(cond
((= tour 0)
...
I came up with this by looking at the tinyscheme source
Thanks for the positive response, and I apologize for the
harshness on my part. If you had said these things in
the initial email, I would not have replied in that way.
Best wishes,
-- Bill
___
Gimp-developer mailing list
rafael mesquita [EMAIL PROTECTED] wrote:
Well, If you change your mind and decide to go ahead with this, or any
similar idea, please contact me, i am disposed to talk.
That isn't quite how GSOC works. Students apply, then
people from the project rank their proposals. Google looks
at the
Tom Bass [EMAIL PROTECTED] wrote:
I'm no linux-geek, I'm based on Windows, so I'm interested in helping
out in the Win-Parts of Gimp - if there's still some help needed ;-) I
checked the bugtracker and found interesting starting tasks, that I'd
like to work on - but some problems occured
rafael mesquita [EMAIL PROTECTED] wrote:
Hi everyone,
My name is Rafael, I am an Brazilian student of Computer Engineering from
Universidade de Pernambuco and about one year ago i have been
studying image processing, so i become interested in working in an
gimp project. [...]
Hi Rafael,
David G. [EMAIL PROTECTED] wrote:
Add a option to rotate brushes to compliment the scaling.
I don't know if this has been requested but it would be very
helpful than creating a layer + using the rotation tool.
Wouldn't be all that hard to do. How often do you think this
would be used?
David G. [EMAIL PROTECTED] wrote:
I proposed this because it will actually boost the simplicity
of managing brushes to adapt in effects and splashes, instead
of doing the layer and rotation technique. ...
I gather from this that you would like to be able to pick
an arbitrary rotation, and
On Thu, Mar 13, 2008 at 8:06 AM, Souichi TAKASHIGE [EMAIL PROTECTED] wrote:
patch will be much easier to track in Bugzilla.
I submitted this request (Bug 56 – PaintBrush extension framework .)
I'm about to post a longer comment, but just as a quick
response to this: I think it's a
Joern P. Meier [EMAIL PROTECTED] wrote:
Maybe someone with more insight into the code could give
an outline of how it currently works? I am willing to invest
some time studying the code myself, but unfortunately it is
very scarcely documented and so I am not sure how the
various components
On Mon, Mar 10, 2008 at 8:34 PM, Andrei Simion [EMAIL PROTECTED] wrote:
Can somebody point to the list of functions that can be used on Gimp 2.2?
It's all at:
http://developer.gimp.org/api/2.0/libgimp/index.html
The API for existing functions does not change within the 2.x releases.
Leendert Visser [EMAIL PROTECTED] wrote:
The members of our Dutch GIMPclub (http://www.dutchgimpers.nl/) have made
splashscreens for GIMP 2.6 in a battle.
It's great to see all this talent and enthusiasm going into creating
Gimp stuff. The Gimp web page doesn't really have a place to put
On Sat, Mar 8, 2008 at 5:06 AM, Martin Nordholts [EMAIL PROTECTED] wrote:
But what you currently have seems to be very far from the spec [1].
Is this intentional or have you just not been able to steer your
current work into the direction of the spec? Just asking since it
would be sad if
On Sat, Mar 8, 2008 at 5:21 AM, Sven Neumann [EMAIL PROTECTED] wrote:
Resorting the menus is something that we should avoid to do
again. And I don't think that the current menu is too wide. Just
make the image window wider. A typical application window
nowadays takes 2/3 of the screen width
To keep the ball rolling, I thought it might be useful to show a
copy of my current experimental version of a no-image-open
window. Most features should be obvious from the picture, but
a couple of notes:
1) The toolbar shows most of the things a user might want to
do with no image open, but not
On Sun, Mar 2, 2008 at 4:44 AM, Luis A. Florit
[EMAIL PROTECTED] wrote:
Sorry, I thought I was clear enough (did I specify the solution??)
What I want to do is what is pretty standard in these cases:
You were certainly clear enough, but there is no way to do that
using script-fu. If you
It isn't tile *allocation* that matters here, it is tile *locking*,
and locking only happens in one place, tile_lock() in
app/base/tile.c. It should be pretty straightforward for
you to throw some debugging code in there.
As I wrote before, though, tile locking happens *a lot*.
Many internal
when I exit GIMP, I often (~90% of the time) get the following error:
Gimp-Base-WARNING **: tile ref count balance: 1858
We probably would need to see the code (or have a way of replicating
the problem) to get anywhere. The warning means that tiles are
getting locked without afterward
On Feb 17, 2008 5:07 PM, Tor Lillqvist [EMAIL PROTECTED] wrote:
Perhaps for the rotation tool it doesn't mean much, but at least for
the perspective tool it would be nice if one could undo the
incremental changes one does to the control points. Probably this
wouldn't be hard to implement? I
Let me just add a pointer to bug #394687 (g_get_home_dir
documentation confusing) --
http://bugzilla.gnome.org/show_bug.cgi?id=394687
The gist is that apparently g_get_home_dir works as it does in
order to get the right behavior when a program is run as
a different user. Since this will very
On Feb 16, 2008 10:11 AM, Akkana Peck [EMAIL PROTECTED] wrote:
I got to thinking some more about this discussion about the mode
list UI. What I've really always wanted for the mode list (but
didn't want to say because it didn't seem like a good general
UI model) is a sort of mode tool: a way
On Feb 16, 2008 11:01 AM, Akkana Peck [EMAIL PROTECTED] wrote:
A tear-off Mode menu from the Layers dialog would be lovely, and
would solve every problem I've ever had with that menu.
One possible problem: would Modes from drawing tool options also be
tear-off, and would that be a different
On Feb 16, 2008 11:16 AM, Sven Neumann [EMAIL PROTECTED] wrote:
There are very good reasons why tear-off menus are deprecated. They
don't solve usability issues but introduce them. Please let us not even
consider such ugly workarounds.
Hmm, well, you may be right. It may be that, even though
On Feb 16, 2008 2:08 PM, Tor Lillqvist [EMAIL PROTECTED] wrote:
But isn't each stroke with a tool a separate GimpPaintCore object?
No, a GimpPaintCore is basically an object that creates brush-marks.
A paint tool creates its paint core when it comes into existence, and
uses the paint core as
On Fri, Feb 15, 2008 at 2:57 AM, Tor Lillqvist [EMAIL PROTECTED] wrote:
Unfortunately now that I have had time to think a bit harder, I
understand that there is a fundamental difference in how my
initial effort to implement a warp tool works compared to how
the IWarp filter does.
Do you
Well, it's clear that the idea is not generating a great deal
of enthusiasm. Before dropping it, though, I'd like to take one
more shot at clarifying the problem -- I'm attaching a screenshot
showing a typical incarnation of the Paint Mode menu, using
the Default Gimp theme and Ubuntu's default
One of the minor annoyances of using Gimp is that the Layer Mode
menu (and paint mode menu, etc) is unpleasantly long -- for me, it
nearly extends from the top to the bottom of the screen. It
would actually be very easy to change the code so that these menus
are laid out in two columns, and in my
To follow up for people who don't necessarily look at Bugzilla, this
change has been committed to trunk at Mitch's request, and
Mitch converted it into a style property, defaulting to no relief as
shown in the screenshot, so that, should there happen to be
anybody who wants the button relief, they
On Feb 10, 2008 1:18 PM, peter sikking [EMAIL PROTECTED] wrote:
There are some deeper problems with those buttons (why are they there,
allt the time, so prominently?), the ones in the layer dialog excepted.
I agree with this. I too think it would be best to have buttons only
for the
On Feb 10, 2008 4:16 PM, peter sikking [EMAIL PROTECTED] wrote:
right-click is a shortcut for a primary way to do things. So in
this case I see good chances for the not-so-often-used options
to go in their own little menu that gets accessed from a
small-no-relief-low-contrast-icon button in
Actually, if plug-in means something like a fill pattern that could
be user-specified in the same way as the splash screen, I think it
would be possible to implement everything Peter has specified here --
including the opacity slider -- using the scratch image framework
I've been experimenting
On Feb 4, 2008 1:27 PM, Alastair M. Robinson
[EMAIL PROTECTED] wrote:
Hi,
I may be missing something obvious here, but I'm trying to understand
the workings of the Gaussian Blur plugin, since I need to implement
something similar myself, and either there's something screwy here, or
there's
[EMAIL PROTECTED] wrote:
I suspect it got ignored since one pixel offset errors are
pretty much to be expected.
One pixel offset errors are *not* to be expected. If they occur, they
are important bugs.
-- Bill
___
Gimp-developer mailing
92 matches
Mail list logo
