The following is not a real solution, but it I think it would make the user
understand the necessary internals better:
Add a second dialog to the "User Installation" process that explains the user
Gimp's way of handling memory and allows him to choose the size of the
tile-cache-size and the
The Export functionality slowly creeping into CVS Gimp is really nice,
but it leaves me with a dilemma somewhat related to my last set of
changes (ie fixing Save As... list of save formats)
Should plug-ins which have working Export declare themselves capable of
all image formats for the
Hi,
would somebody cry and whine if I check this in:
http://sven.gimp.org/files/lc_new_icons.png
IMHO a little facelift can't hurt and the anchor does fit better with
the Gnome icons.
Salut, Sven
Hi,
Uh, Gimp users/developers are so conservative ...
I am not sure. Gimp is a drawing application and thus colors are important
part of the work being done. I kinda like the fact that the icons in the
gui are not colored. I dont know, what do others think?
It wasn't the lack of colors that
Hi,
There are some major inconsistency or more precisely hard to use functions
in the eraser, the sharpen/blur and dodge/burn tools.
Pressing Ctrl will change the tool behavior from eraser -- anti-eraser,
blur -- sharpen and dodge -- burn.
Pressing Ctrl will in combination with Shift
I've been hacking at the internals of the transform tool, but until
now I hadn't looked at how it worked from the outside. It's just not
right! You need to be able to set the transform by swapping between
modes (rotate/shear/scale/perspective - plus move), adding to the
existing transform at
Hi,
Except it doesn't seem to work on systems without GtkXmHTML installed. I
don't have that on my systems Would it be possible for the build to recognize
this and remove the Help option from the File menu? The current dialog that
pops in these cases (no GtkXmHTML) is fairly confusing to
Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally
systems without thread support) because it needs the threaded version of
strok() strtok_r(). The latter one is new in glibc2 (aka libc6) an for the
gnome system it is doubled in gnomesupport. So to make
If it is, the german de.po is broken too, since I experience the same weird
problem here.
What menuitems are replaced by Datei? I could not reproduce the
problem.
As far as I can see all menu-items that are provided by plug-ins. Additionally
the Dialogs entry in the image menu (not the
Hi,
Now I download sources for mpeg.c and have found that plugin crashes after
gimp_progress_update (1.0);
on line 320. I am not specialist in GIMP sources but it seems to me that this
call invoked "for illustration only". Thus I comment this line. After this
GIMP loads mpeg
Daniel Eggert wrote:
On 1 Nov, David Monniaux wrote:
The stupid I18N behaviour of the week: when menus are translated, any
string for which the system finds no translation gets translated to
"Fichier" (in French), which means "File".
I don't know the innards of the translation
Marc Lehmann wrote:
My very own personal opinion on this is:
- either make gimp a gnome application (puke!). This would be honest, as we
are kind-of forcing gnome on people anyway (wanna help? use gnome!)
Marc, please! You know that the situation we have now is not what we want it
to be
Hi,
The idea of a help system as part of GIMP sounded interesting and I had
hoped to try it out and comment on it but I now discover I won't be able
to do so.
There are many things you can do about this:
- Install the gnome-libs package. This will not change your desktop into
a gnome
Eduardo Perez [EMAIL PROTECTED] wrote:
What about a central site, where developers send their files to be
translated, and a group of volunteers translates them to as many
languajes as they can? Perhaps there could even exists a database of
common expresions ('Yes', 'Save as', 'Are you
Hi,
Why not allow the user to choose his/her browser of choice ?
With Netscape, Mozilla, the Gnome Help Browser, kfm, or even
Lynx in an xterm as possible choices, I don't see any problem with this...
So Gimp help should be a set of HTML files and a small exec to launch the
preferred
Here is my list of minor things to clean up and make better (Without
breaking the freeze). First the list and then the discussion below it.
YES!!
I do especially like the new menu hierarchy you suggested. Any volunteers
for this job?
PS: Sven I think
Except... gimpenv.c...
Well, I have looked at it know, but it should be fairly easy to make a
cleanroom implementation of the functionality in that file only by looking at
the code that calls it. The header is under the LGPL. Would that count? ;-)
Salut, Sven
After a little testing, using my button creator, I did notice that The
Gimp's memory usage did increase after each execution. I found during
testing that if I temporarily displayed the new image and then deleted
it that the Layers Channels Image list did not retain the image
created.
I hope Adam will forward the mail he sent me (it would be rude to pass it
on without permission) and address the "tested this patch heavily" remark
If Adam thinks there are problems with the code, it would indeed be nice
if he could tell us about it.
Can I get agreement to revert
Hi all,
I just studied the GtkItemFactory code...
It seems we're doing _many_ useless translations in the menu system.
For example all calls to menus_set_sensitive() et.al. are using strings
which are marked with N_().
However it's totally sufficient to pass the untranslated (english)
For me at least, i686 based RH 6.1 on two machines (one more "out of box"
than the other, but neither of them's been extensively hacked) builds a
working and i18n'd Gimp no problem.
In French I can say "Fichier-New"
and then choose "Type d'image RVB, OK"
Resulting image is called
Mitch wrote:
My installation suffered from the old problem and still is not able to
look up translations from "gimp-std-plugins"
So my question to the deveopers: Does anyone have the plugin names
(not the paths) correctly translated in the menu hierarchy???
It seems your latest commit
I have thought of this for a while now, but now I decided to put it into
ascii form...
Would it be possible to implement a "VCR Console" for GAP plugins?
I think it would be very useful and from what I understand it might
even be easy?
Something with [ | ] [
Hi,
Tigert wrote:
Well there is now the gimp/plug-ins/perl/examples/gap-vcr in cvs that is
implemented in gnome-perl. It is very basic, but it somewhat works.
Oh, how much do I love when new features that would be really useful but
would need some good thoughts and probably even the redesign
Hi,
I suggest the following generalisation:
a thingy (for lack of a good name) which:
- activates a certain tool on the toolbox
and has its own settings for that tool
- picks a certain color/pattern/gradient
- picks a certain brush
- etc...
Every image can
Hi,
A new version of the GDynText plugin is available.
I've fixed an undo related bug, now you can undo layer changes and parasites
changes in one step (only one ctrl+z). ;)
You can download it from the plugin registry or at:
http://www.geocities.com/Tokyo/1474/gimp/
Will you provide a
I built 1.1.14 with gtkxmhtml and the browser seems to work fine, but there
doesn't appear to be any documentation included. All the pages say "Sorry
but the help file for xxx is not ready yet."
The help pages are only partly done so far. But you should be able to find
some that have more
Hi,
on our way from 1.0 to 1.2 we included a few plug-ins that were
considered not to be stable enough to be included with a stable
release. This was done in the hope that the inclusion into the
1.1 developement tree would encourage people to work on those
plug-ins so that they would become
Matt.Wilkie writes:
I'm getting this weird display problem with some PNG
images, a sample is attached. Please let me know if
you do/don't have similar problems.
The PNG apparently claims to have the display (and print) resolution
of 0 pixels/inch... Set it with ImageScale
I have changed the core so that it does not accept zero resolutions.
Additionally I have changed all plug-ins that try to set the resolution
to check the value and simply don't set it at all if it is invalid. Gimp
will then use the default set up by the user.
Please make sure that XCF
Hi,
I have changed the core so that it does not accept zero resolutions.
Additionally I have changed all plug-ins that try to set the resolution
to check the value and simply don't set it at all if it is invalid. Gimp
will then use the default set up by the user.
Perl, IIRC
Hi,
Nobody (I mean it ;) uses the gserialize feature, for example (which has
problems of its own)
Do you know of any probelms with geserialize? I use the functions for a
project at university and would like to hear about problems I have not yet
been able to observe (the ones I found were
I don't see your problem. I do get my errors in the error-console. All
that's missing IMO is a way to set the error_console as the default
error_handler in the preferences. That should be easy and is definitely worth
the effort.
Well, I think you hit the nail right on the head, I have
I've been checking CVS Gimp with some "real users" lately.
One complaint was that there is no obvious way to rotate the image. Of
course, WE all know it's the transform tool in rotation mode, but it's not
trivial to guess: the tip for the tool just says "Transform".
Do you agree to some
I was alerted by Stanislav Brabec about a problem with menu
translations. In his translation of Logulator to czech, he properly
changed all occurences of "Logulator", but, while the gimp displays the
menus _within_ the Filters/Logulator menu correctly, the Logulator menu
itself NOT being
Adding the Logulator to app/menus.c is the correct fix (at least for now).
No, it definitely is not. For people not having gimp-perl this just means
an empty menu.
No, it does not! You just add "Logulator" to the list of dummy_entries in
menus.c that only exists for the purpose of adding
Hi,
I just received a mail from SHIRASAKI Yasuhiro [EMAIL PROTECTED]
that he will not be able to complete the job of gettextizing all plug-ins.
He has done a great job so far as all plug-ins in the common directory seem
to be finished (I haven't checked, but I think they really are all done).
A
On Mon, Jan 17, 2000 at 02:59:26PM +0100, Michael Natterer
[EMAIL PROTECTED] wrote:
While this has no effect in normal plugins, it causes a "save failed"
message box to appear for all save plugins. I find this really annoying,
because pressing cancel is just a normal mode of operation,
Hi,
Well, STATUS_CANCEL would be a way to cleanly cancel a plugin. And pressing
"Cancel" in the "Save as Whatwver" dialog of course causes the plugin to
exit cleanly without leaving any garbage
This is wrong! Pressing cancel will simply drop the connection to the
plug-in, which will
Well I feel that the "new" button is a bit too much. The plug-in should
just create the layer when it is needed eg. when you've written your
text and applied (or pressed ok) it.
In that case the OK and Apply buttons would be grayed out and only New
would be available.
There is no need to
Hi,
tonight two new plug-ins were checked into the tree. I now that we have not
officially declared a plug-in freeze, but I think it was somehow clear that
it is too late to add new plug-ins. The CVS ChangeLog claims:
Thu Jan 20 23:28:35 CET 2000 Stanislav Brabec [EMAIL PROTECTED]
This afternoon I downloaded and attempted to install the latest Gimp.
./configure failed to detect that I am running the latest versiong of
gtk and bombed.
The instructions given for those who know they have the latest version
of gtk were not helpful.
I'm still stuck using an ancient
As part of my sawmill theme tool gimpmill, I need to save individual layers
to disk. The way I currently do it involves creating an image of the same
dimensions, doing a gimp_edit_copy and then a gimp_edit_paste. This is fine
provided the layer's content spans the full width and height of the
Marc,
don't take this too personally, it is not and was never meant to be!
I won't unless someone tells us what he thinks is broken.
Well, telling "us" about it didn't help in the past, so why should it now?
"us" should mean "the script-fu maintainer", and not me nor you.
Well, since
Hi jtl,
I would like to kindly suggest that we at least give a configure
option to avoid the stacktrace stuff that happens when gimp crashes.
I also remember having big problems with a segfaultet gimp started
from the gnome panel (or any other non-shell commandline means) and
gimp
Hmm... sounds sensible. Unless somebody comes up with something better
I'll start it in a week or so.
My idea is to copy the full cvs tree of gimp to (lets call it gimpforge)
and give any intersted plug-in author write access.
Updates from the gimp-cvs-tree/{libgimp,app,tools...} to
Well, here's the updated translation status report. This might be
of interest for people who want to help finishing the translations
for 1.2. Before you start to work on one of the files, please get in
contact with the maintainer (his/her address should be in the po-file).
po:
Well, here's the updated translation status report. This should be
of interest for people who want to help finishing the translations
for 1.2. Before you start to work on one of the files, please get in
contact with the maintainer (his/her address should be in the po-file).
po:
cs.po 1391
Hi,
Ok. I've just enabled automatic mirroring from the sourceforge cvs back
to the gimp cvs.
The file gimp/PLUGIN_CVS in the cvs tree controls which paths are mirrored
and which are not. If anything goes havoc just delete that file and the
script will stop doing anything.
At the
The Translation Status Report is now available nicely formatted and
daily uptodate at:
http://sven.gimp.org/1.1/i18n.html
Hopefully this motivates people to contribute to the translations...
Salut, Sven
Martin Weber wrote:
The flame plugin especially the gradient / megawidget part has to be
redone.
It would help a lot if you could be a little more precise about what
you think has to be redone and why. Of course you are right and I am
aware of the problems in the flame plug-in, but others
I think the megawidget has changed a lot in other plugins. So why not
use it.
If you have not yet noticed: The use of megawidget is strongly discouraged
and our goal is to get rid of it. The flame plug-in that includes its own
version of the library is of course doing the worst.
Salut, Sven
Hi,
I just looked into GDynText-1.4.4. It fixes a bug that was reported in the
bug-tracking system and I have included that bug-fix into the CVS version.
However GDynText starts to diverge from the CVS version distributed with
The GIMP. IMHO we should overwork the code a little for 1.2. This
Does translation of filter help tips make any sense ?
Or would it be like with internal function help tips
and they are going to be excluded ? (1.1.6-1.1.10).
I'm not really sure. It surely creates lots of work for the
translators and I don't know if it is worth it. If we could
agree on
Hi,
as pointed out before, we have an inconsistency between the core and the
plugins when it comes to the point if PDB blurb and PDB help should be
translated or not.
The situation right know is:
In the core the short description and the longer help strings for the PDB
functions are not
Hi,
Same impression here. I can't remember that I installed Gnome on
my desktop. And although I use Gimp for a long time now I never got
the impression that I was working with Gnome.
Eeek, even if we we use gnome-libs you will not have to install Gnome
on your desktop. People should have
The function gimp-drawable-type-with-alpha wasn't
completely guarded. Calling it with a non-existent
drawable would cause a crash.
We force a crash in that place (by using a g_assert) since
something has gone wrong. With your patch we would return a
perfectly valid image_type and gimp would
Daniel, do you know how to modify the Makefiles to do that, and where
a good place to store these files is (probably just besides the .mo
files)? There must be a simple way to find them though (a gimptool switch,
maybe)?
Sven??
Sorry, Gimp-1.2 first.
Salut, Sven
Hi,
Before you start to go crazy about post-1.2 i18n issues,
wouldn't it be nice to first clean up the situation for
gimp-1.1 a bit? I'm speaking about the UI and translation
of the perl plug-in.
The po directory has a totally different mechanism for
storing and building the po and mo files
The function gimp-drawable-type-with-alpha wasn't
completely guarded. Calling it with a non-existent
drawable would cause a crash.
The fact that you can feed gimp with a bad drawable through the PDB and
make it crash, is indeed a bug. I have looked into the code in
app/drawable_cmds.c and
Hi,
I have some experience documenting the C/C++ source of a project. For
the DODS project (http://unidata.ucar.edu/packages/dods) I use a
package called doc++ which is barely supported, but works well. Doc++
has a home page, and we support a slightly modified (i.e. debugged)
version of
Hi,
ok, I've added the necessary framework, so we can start to work on the
documentation. If you have any problems with configure/Makefiles, please
mail me.
If you check the source out of CVS, you will find a new directory named
devel-docs. There's a README, _read it_ !! You will need gtk-doc
1) The x-y mouse coordinate data and image name information
that appears to the left of the progress meter are
not working right for me. The data seems to be written
on top of old data that is never erased so it just looks
like a big black smudge after a while.
I think it's time to remove that useless pencil before the release
of the magic version 1.2. Did anyone use it in the last time?
It contains no functionality that paintbrush doesn't have except of
hard edges (anyone needing that "feature"?)...
It is a very important feature, believe me!
Hi,
Daniel, please, do you follow the discussions on this list?
At the moment we have got 2 Pathtools in GIMP. One which is called
Bezierselect in the Toolbox but has a Path dialog
(in the Layers/Channels dialog???) and another one called Path tool.
The latter works a lot nicer IMHO
I'm all for removing the Path Tool, the Xinput Airbrush and and merging
Pencil and Paintbrush. If I counted correctly this would reduce the
number of tools to 24. This is a perfect number of tools since
24 % [2|3|4] == 0 which means we always get a nicely layed out toolbox.
core and
Hi,
Ok. I've just enabled automatic mirroring from the sourceforge cvs back
to the gimp cvs.
The file gimp/PLUGIN_CVS in the cvs tree controls which paths are mirrored
and which are not. If anything goes havoc just delete that file and the
script will stop doing anything.
At the
I'd really like to see the setting for default brush reappear. So
much so that I'd do it myself.
Hows this fit with the freeze? I hate to violate the freeze, esp
since its been getting better. But I'm SO SICK OF THAT CALIGRAPHIC
BRUSH (10x10)! Comments?
I always use "Save device
Since about two weeks, setting LANG to any value results on a segmentation
fault on startup.
Program received signal SIGSEGV, Segmentation fault.
0x4015822d in g_strdup (str=0x81e8273 "help_page") at gstrfuncs.c:56
gstrfuncs.c:56: No such file or directory.
(gdb) bt
#0 0x4015822d in
Hi,
So it is basically Gradient Map on steroids?
The option to use a gradient as colorsource is an extra goodie. The normal
usage is colorizing grayscale photos with the use of color photos as color
source. Ever tried to colorize human skin using standard techniquees like
painting in color
Hi,
Marc wrote:
So... I am not against this change, but I also see no reason to do it,
especially since that makes gimp different to other apps, and I think
there should be a very good reason for this.
Since all GNOME apps have the help menu rightmost but not seperated from
the other menus,
I've had problems with the toolbox ever since it became re-sizable. I can
size it exactly the way I want it, three vertical rows of tools with
colors, brushes, patterns, and gradients below but the brushes, patterns,
and gradients are always pushed outside the window, invisible and
Hi,
I did not ignore the menu problem. If the "Help" bug is fixed (it is
a one-line change in app/menu.c to make it last-from-left), then only
the "File" menu is visible. But when I work with very large images, I
do not need the "Xtns" menu at all, so I can live without it until I
finish
Hi, I'm new to gimp and I just compiled and installed the unstable version of
gimp (1.1.17). I noticed some graphics problems with the co-ordinate listings
in the bottom left hand corner of the drawing window. Who or where do I send
email to report this bug. I've noticed that this bug also
Maybe we should make it our problem.
I agree ... as programs have gotten higher-level, "blame it on the
hardware" has gone to "blame it on the operating system" to "blame it on
the standard" to "blame it on the implementation" to "blame it on the
toolkit".
As someone who works with
Hi,
So one thing that springs to mind here is if the Gimp itself were to
warn if you attempt to exit while a plug-in is in progress of
execution. Gimp folks, would that be feasible? That would seem
useful for other long-running things (and some of the filters take a
long time to run).
Hi,
I'd suggest testing for existance of the parent menu first and
if it's not there extracting the correct translation for it from
the full path and initialize it together with the tearoff menu.
On the first thought the idea looks promising, but I fear it is
not that easy. GTK+ wants to
Hi,
Yes. That's why I thought of ripping off a slice from both the
translation AND the original.
Consider this:
Plugin wants to create a menu Image/Filters/verynew/stupidtool.
Now we first check:
- Is there a menu Image/Filters/verynew
- if not continue ripping off until we
Hi,
Look at the code we already have to add the tearoff menus. A similar
thing could be used to create the branches itself.
Don't waste your time at that. I already did that and I tried to explain
you why there is no way to hook into that place since GTK+ creates the
submenu on the fly.
Hi,
I got the CVS version of The Gimp and I am ready to start.
The Idea is to introduce an IPTC... button to the file filters
for the file types that support IPTC data somehow (JPEG, TIFF)
and to implement an filter to write .iptc image files.
My questions so far:
Is someone else
Hi,
just do make my position clear: I was not critizing your decision. My
feeling was just that we could have built a similar framework on
available resources with substantial interest and a little effort.
As long as it helps Gimp development I'm all for it. (That's why I
pointed Dirk to
Hi,
If a properly named Targa file is not correctly loaded by GIMP, then
another plug-in (for example faxg3) uses a file magic that fits this
targa file. So which plug-in should load the file ? The one that has the
correct file magic or the one that handles the correct extension ? I
would
Hi,
On Sat, Feb 26, 2000 at 02:37:02AM +0100, Sven Neumann wrote:
(1) Add an online version of the Libgimp documentation to your website.
You might even want to help us to improve it further. The whole
purpose of generating this documents was to help plugin developers.
Hmm
Hi,
OK, I should have read the e-mail with the patch more carefully. This
handling looks good.
So the patch actually has a good chance to get included. The probability
would be even better if you could upload it to ftp://ftp.gimp.org/incoming
as described in the README in that directory.
At
So I am not the only one that has the usage pattern with fill listed above.
I don't know if its from other graphics programs I have used or just what
made sense to me but I expected fill to use the foreground colour. I mean
after all, you don't expect the pencil tool to draw with the
Hi,
Well, thus far we've had very little trouble supporting 1.0. Even the
configure script works properly. 1.0 is still the stable release of
the Gimp.
I really don't understand your development cycle. We are approaching the
1.2 release but you insist on keeping the code that is going
Hi,
I have some working code that does use the pluginrc to store the additional
locale info for plugins (as described in my earlier mail). Additionally
the framework for setting the domain (and optionally a path) from a plugin
through a PDB call is complete and tested.
The new PDB call would
Cleaning up the scripts and providing a more consistent set of parameters
looks like a very important job to me and I'm glad that Raphael wants to
take it. I'm not yet convinced that changing the Edit-Fill behaviour is
really useful. Probably we should keep the current behaviour as it
My 0.02 Euro: I would like to change the Edit-Fill behaviour globally
and at the same time provide a three-lines script (or code in the
core) that would register itself as "Edit-Fill with BG" and would
swap the colors, call gimp-edit-fill and restore the colors again. So
those who prefer
I just spoke to someone who tried to get rid of the alpha channel on
their image before saving it (his gimp was pre-export stuff).
It's true that, even though I knew what I was looking for, it took me
a while to find the flatten option.
The deceiving thing is that while
Glyph Lefkowitz send this message privately, but I'd like to move
the discussion back onto the list. I hope that OK with him...
Why are you bothering to change this behavior (edit/fill) when it makes
sense to 1/2 of the people who use GIMP, it's a historical precedent in
terms of the UI, and
Hi,
the response to this mail was very small when I sent it to the list
a month ago, but I want to give it another try...
So, here comes the next call for help: This one is targeted especially
at people who always wanted to contribute, but couldn't due to the lack
of coding skills. There's
It's a little confusing to me sometimes to use the gradient tool, thinking
the gradient at the bottom of the toolbar will be used, and finding out that
it's actually using the FG-BG colors (or vice versa). I do know how to
change it, but sometimes I forget which is in effect.
It would be
Hi,
While scripts are in the air, should we remove mkbrush.scm before 1.2?
This script takes a bunch of parameters and makes a new brush, almost
exactly like the "New" or "Edit" features of the brush dialog, but
it's a Script-Fu. Do we need it for anything? Otherwise we should
remove it
Maybe best would be to have a magic entry in the gradient editor
"FG-BG" and "BG-FG" which would change accordingly, and remove the
selection from the gradient tool.
Even better: have a reverse gradient toggle so that all gradients can
be easily reversed...
Before anyone starts to
Hi,
if you have time, would it be possible to get someone with better
bandwidth than i to download a clean copy of CVS gimp and see if it
builds? i've done distclean and autogen, etc, etc - apps/pathsP.h is still
not in CVS (and there still seem to be dependancies on it,)
I'm pretty sure
Hi,
This idea will cirumvent most of the problems which gettext alone
just can't deal with. It's little and as such not very likely to
introduce many new bugs.
With the usage of static array and buffer lengths you demonstrated in
your patch it will most likely introduce one or two new
Hi,
While we are on the subject of coding style, there are two areas of
the Gimp that are not using a consistent coding style: the Script-Fu
scripts and, to a lesser extent, the Perl scripts. Is there a
recommended style for these?
Oh well, there are more areas. Not even the core strictly
Hi,
[ ... many thought about localerc deleted ... ]
Well, you are right in all your points. I just decided
to use a new file because I don't need much functionality
and therefore could keep it simple as well as the functions
in GIMP and libgimp to deal with it.
IMHO adding lines
Hi,
Actually I don't see hundreds
of internationalized plugins in addition to the ones that come with
gimp
But even those will have their own entry. One entry per plugin.
Considering the amount of plugins we ship with GIMP nowadays this
would alone lead above hundred entries.
Why
1 - 100 of 222 matches
Mail list logo
