Hi,
> My experience is that this does not work in practice. I spent a lot
> of time last summer trying to get Grokking the GIMP onto gimp.org and
> just could not convince anyone to allow me to do it. That's why I
> created Gimp-Savvy.com.
Who did you ask then? Took me a little luck and a few
Hi,
> I don't know. Graphics samples don't really fall under my vision of the
> plug-in site, but they can go there if they need a home, I guess. I can
> add it to the task list, and I'll give access to the web server (at
> sourceforge) to anyone who wants to implement it and demonstrates half
Hi,
> > stuff to sourceforge is a bad idea from the very beginning since it is
> > confusing to the users.
>
> another thing: why is this confusing to users? Has anybody complained
> to you? At least on this list (or the sourceforge lists) no sign
> of confusion was in sight. The web-pages make
Hi,
> > We have all the possibilities on gimp.org and we should use them.
>
> But who will do all the necessary work?
Aren't you facing that problem on every server ?
> > IMHO the whole plugin project should move back to
>
> Well :( Then we will have to find somebody who does it first.
Yep.
Hi,
> > Alternatively, it might be easy to create a source forge page
> > for it, though I dont see where that would make it easier to upload.
>
> The plug-ins sourceforge project might be a nice place for that. Given
> a bit of pressure, Kevin Turner might even create some kind of upload
>
Hi,
> >Even though -Wall is specified, gcc accepts it without even a warning. I
> >don't know offhand if this behaviour is allowed by the standard. My
> >personal coding style would put the declaration with initial values before
> >the first use which would eliminate the two lines at the top of t
Hi,
We are proud to be able to announce the first official
GIMP Developers Conference which will take place
June 2nd - 4th 2000 in Berlin.
The goal of this conference is to bring together GIMP
developers to chart the features of the next generation
GIMP. There are lots of decisions to be made
Hi,
while the signal crew is trying to bring the pieces together again,
GIMP is getting closer to its 1.2 release. Since we'd like to ship
with a set of well supported languages, it's time again for a
translation status report. There's still lots of work pending here.
Please help the translator
Hi,
> having only used canned tools (like the ones in
> photoshop and that come with graphics drivers) i made
> a script to help calibrate monitors. im trying to
> gather info on color matching to make a free
> implementation of ICC profiles. i already got the c
> code for reading/writing profile
Hi,
myself wrote:
> I have however noticed that perl i18n is totally broken at the moment (at
> least on my box) and I couldn't figure out why. This was broken before my
> changes and I have double-checked that the gimp-perl text-domain gets
> passed to menus_create_item...() correctly. Later I
Hi,
> For 1.2, the solution should be clear: find out why perl plug-ins get
> specialcased (maybe because menus.c doesn't know about them but about the
> c-plug-ins? or maybe because the i18n code handles them differently?) and
> sort everything alphabetically (source language, e.g. english).
Th
Hi,
> AXV is a new image viewer that is much faster than GIMP
Well, viewing images is another thing than editing them...
So there's yet another image viewer being developed now. And it
has choosen yet another format to store its thumbnails. Sorry,
but that aren't good news actually.
Salut,
Hi,
Raphael wrote:
> But I also noticed that something else has changed in the Perl-Fu
> scripts: in the previous versions that I tried (under Solaris), these
> scripts were always registered at the bottom of the menus, instead of
> being mixed with the C plug-ins. Now it seems to be the contra
Hi,
some comments:
> The layer named "Background" is special. You can't add
> transparency or a layer mask to it. To add transparency, you
> must first "add alpha" to the layer by right-clicking in the
> layers dialog and selecting "Add Alpha Channel".
see Garrys mail
> A Floating Selecti
Hi,
> I suppose that the text you posted is the final or semifinal version. Is
> there a Spanish translator? How do I know it? I have been a bit out of phase
> latelly.
Check the source and the translation status report at
http://sven.gimp.org/1.1/i18n.html
I'd say there's a lot of work
Hi,
> But I also noticed that something else has changed in the Perl-Fu
> scripts: in the previous versions that I tried (under Solaris), these
> scripts were always registered at the bottom of the menus, instead of
> being mixed with the C plug-ins. Now it seems to be the contrary: the
> Perl-F
Hi,
the rotate90 routines could need a little optimization, but to do so, we'd
have to move them into the core (they are performed in a plug-in now). This
will probably happen in the next development cycle, but not before 1.2.
Salut, Sven
> I know that gimp has the x,y coord box in the bottom left corner of an
> image window. I know that they worked at one time, but they no longer
> do. The coordinate appear, but they don't get erased and replace for new
> ones upon mouse movement. I end up getting two black boxes of mess where
> t
Hi,
> OK, here's my first cut at a PDB general 2d transform. It provides
> rotation, scaling (with separate x and y factors), and translation.
> General enough to be useful, but still easier to use than a full
> perspective operation.
>
> Sorry, not in patch format; but it all goes in tool_cmds.
> BTW, the display of the cursor coordinates doesn't work well when using
> pixmap themes. With Theme Engines (including the default theme) it works
> OK. Does anybody knows what is the source of this problem and how to fix it?
Upgrading gtk-engines to version >= 0.10 should fix this problem.
S
Hi,
> > > Where are you experts??? We are two at minimum discovering this behaviour
> > > and if it's a misconfiguration it has to be described somewhere.
> >
> > It is a misconfiguration on your part. I'm running gimp 1.1.19 from
> > debian and GDynText appears to be working fine. I typed te
Hi,
> jade errors when running 'make html':
> gimpmatrix.sgml:
> these lines get errors for having [ characters in their attributes:
> 17: typedef GimpMatrix3[3][3];
> 18: typedef GimpMatrix4[4][4];
> 72: GimpMatrix3[3][3]
> 79: GimpMatrix4[4][4]
>
> parasite[PF].sgml:
> IDs need to be
Hi,
> Could you Please advise me where can i get some Reference or Tutorial
> about gtkxmhtml (widgets,functioms and etc.)
My advice: Do not even consider using it. gtkhtml is supposed to be much nicer
and I guess it is better documented too. As soon as it will become available
more wildly,
Hi,
> Another idea might be some more questions when you first install.
You should probably update your gimp, delete your .gimp-1.1 directory and
try the new user installation...
Salut, Sven
Hi,
> I propose that we make a few changes to the default gimprc (either the
> system-wide or user one, whichever the options fit best).
The changes should be done in app/gimprc.c. The systemwide gimprc should
be changed too to reflect those changes.
> The main thing is that session management
> I'm using the GIMP (1.1.17; debian unstable) to create some mockups for
> our prepress guys. They want to use some of the things I've done, but I
> don't want to give them a non-flexible image. I realize that I can do
> this already, but I thought it would be a nice feature (that seems like
>
Hi,
> The interesting thing is: While I was told that the .gmo files should be
> in cvs, I don't see any other .gmo files in the CVS.
Huh, who told you this?
> So _I_ am utterly confused about the supposed way to do i18n in Gimp (as
> opposed to doing i18n in other gnu projects), since the cvs
Hi,
> Hello, i'm new in this mailing list, and speaking with a friend of mine last
> week end, i'm think about making a plug-in for gimp dealing with splitting an
> image into several images, for web site (for example) like this:
>
> source image:
>
>
> | 1 | 2 | 3 |
>
Hi,
On Mon, Apr 10, 2000 at 05:20:03PM -0700, Kevin Turner wrote:
> Goal: Make an image with a transparent background for your web-page,
> clip-art, etc.
> Issue: PNG file size is bloated by losslessly saving "invisible" data.
IMHO, this should be handled completely inside the PNG plug-in.
Hi,
On Fri, Apr 07, 2000 at 06:27:27AM +0100, Nick Lamb wrote:
>
> Instead, I propose to change Export to recommend "Flatten" when it
> notices that the bottom layer has no alpha channel AND is visible,
> when it would current recommend "Merge Visible".
>
> This will improve compression ratios
Hi,
we are trying to fix all bugs that have been reported through
the bugtracker. However there a few reports that have been
hard to reproduce from the very beginning and now it's very
hard to figure out if they are still present in currect
versions of The GIMP. I therefore ask everyone to hav
Hi,
a lot of ideas and comments about the problems we have with
gettext have appeared in this thread (among them a few nice
ones), but I want you to recognize that we will stay with
gettext until something better is developed. It makes no sense
to create a gimp-specific solution to a problem all
Hi,
On Sat, Apr 01, 2000 at 05:29:49AM +0100, Nick Lamb wrote:
> * Is the end-user installation stuff broken, or is it just me? On my
> system, cleaning out all old Gimp installs, installing latest CVS and
> then trying to install Gimp as a new user (ie to create .gimp-1.1 and
> all the rest) doe
Hi,
On Thu, Mar 30, 2000 at 01:19:44AM +0200, Michael Natterer wrote:
>
> The netscape method of communicating over the X protocol seems a bit
> overkill to me.
>
IMHO using X makes much more sense than abusing the filesystem.
Both ways of doing it (that were discussed so far) won't work on no
Hi,
On Mon, Mar 27, 2000 at 09:34:35PM +0200, Simon Budig wrote:
> I see, that Gimp can be crashed very easily when trying to use multiple
> tools at the same image/layer. Michael adressed this: from the changelog:
>
[ snip ]
>
> Well - unfortunately this disables "user multitasking" with worki
Hi,
On Mon, Mar 27, 2000 at 01:18:27PM -0500, Kevin Cozens wrote:
> > > Why colour brushes can be animated and grayscale can not ?
> > > (Telling me to stop using the colours is not the answer:).
> >
> > This is definitely a design mistake in the animated brushes. We will
> > however not change
Hi,
On Mon, Mar 27, 2000 at 05:26:41PM +, Ar't wrote:
> 5
> When I click the arrows in image space (navigator or so) I get:
> initial_sub_region:: error :: src->w * (src->bytes + 1) > 512
Huh? Could you please try to explain that in more words?
Eventually I might get what you are talking
Hi,
On Sat, Mar 25, 2000 at 09:17:54PM +0100, Simon Budig wrote:
> First congratulations for the new User-Installation Dialogs.
> But I cannot resist to comment on it :-)
>
> * There seems to be a problem with the big titles. As you can see
> at http://www.home.unix-ag.org/simon/gimp/GimpUserI
Hi,
> I'm looking for a simple way to export a Gimp image as a GdkRGB to a
> plugin. Any good solutions? The ImageMap plugin seems to have a nice
> interface along the lines of what I want to do, but it seems like it
> takes an awful lot to get the data from the Gimp to the preview widget.
> I'
Hi,
> I do not mind if some people (like Raphael) make suggestions based on a wrong
> understanding of the situation. I am, however, astonished that even people
> like Sven, who _does_ _know_ _better_ takes it so lightly:
>
> On Wed, Mar 08, 2000 at 06:29:18PM +0100, Sven
Hi,
On ftp.gimp.org a whole bunch of patches appeared over the last years and
lived together in an overly crowded place called /pub/gimp/patches. I have
just finished the first round of a cleanup. I have applied a few patches
(newer ones) and moved a bunch of patches into a directory called "obs
Hi,
> I just uploaded the second part of my gimp_edit_fill patches to
> ftp.gimp.org. As soon as it is moved out of the incoming directory,
> you should be able to get it as gimp-quinet-000310-0.patch.
Sorry for not moving the patches earlier, but both patches are now
accessible at ftp://ftp.
Hi,
> Why can't those scripts just _not_register_themselves_ if the required
> modules are not available? gimpmagick does this and the only problem
> is that it has to be re-probed every time the GIMP starts. The only
> reason I can think of to not install these scripts is to avoid the
> delay at
Hi,
> This has been suggested before, but I would like to bring it up
> again... I think that it would be better to disable the installation
> of all Perl-Fu scripts if any of the required modules (Gtk, PDL,
> Data::Dumper, Parse::RecDescent) are not detected by the configure
> script or, more e
Hi,
> I started building Gimp using the CVS repository a little while back (2-3
> months). Just recently, I tried to build all the target specified in the
> Makefile. I tried the "make release" but it stops after a while looking for
> a program db2html. Does anybody know where I can find this?
Hi,
> If you have a layer that is smaller than the image size and you
> do a select-by-color using a point outside the layer's area, it
> gives a segfault. The assertion in image_get_color_at is
> wrong ... it's impossible to make it fail actually :-).
> Here's the fix:
[...]
Garry checked in ex
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
Oops, just had to move the documentation, the correct link is now:
http://sven.gimp.org/1.1/docs/libgimp/
Salut, Sven
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 h
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
> wou
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 your
Hi,
> > (1) What does IPTC mean?
>
> IPTC is short for "International Press Telecommunications Council".
> They made a standard for incorporating information about images within
> the image files.
Sounds like an interesting and useful extension.
> > (2) Can it be considered important enough
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,
> 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,
> 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 /Filters/verynew/stupidtool.
> Now we first check:
> - Is there a menu /Filters/verynew
>-> if not continue ripping off until we found
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
Hi,
> Would it make sense to you to enable keyboard access to
> the menuentries in the toolbox?
>
> I find it quite irritating that I can't get the File dialog
> with Alt-F resp. Alt-D (German Datei). At least for beginners
> not yet familiar with the shortcuts or the do-it-yourself-
> sho
Hi,
SHIRASAKI Yasuhiro <[EMAIL PROTECTED]> noticed:
> some paths like:
>
> /Video
> /Script-Fu/*
>
> are not translated with "The i18n solution"(TM).
> Shell we move dummy_entries[] items from app/menus.c
> to each appropriate plug-ins?
Eek, yes of course, that does not work any more. There
Hi,
the new i18n implementation supports localisation of
plugins outside the gimp distribution. I'm pretty sure
that it works. I have however not yet tested if it
really does what we expect and if it solves the problems
it targets. Is there anyone out there maintaining a
seperate plugin who is
Hi,
> I am trying to get batch mode working with script-fu-old-photo. However I
> cannot get it working despite my attempts to follow the docs on
> adrian.gimp.org. Does anyone have any suggestions on how I can get this
> working or of another program which will allow me to do this. I need to
> e
Hi,
> Back to work:
>
> New patch, also containing a proper cleanup function and the necessary
> call in app_procs.c appended.
One of us defintely works too much and too fast. I have just checked in a
working solution which gets rid of the annoying iterate-through-all-domains
problem.
Sor
Hi,
> I'd recommend gimp_plugin_domain_add (gchar *domain_name)
> and gimp_plugin_domain_add_with_path (gchar *domain_name,
> gchar *domain_path)
>
> because it IMHO fits better into the namespace and is more obvious
> than to have just 1 function with tw
Hi,
> I added a few lines to your modified gimprc.c to support that.
No, that won't work. Of course you need to hook somewhere into plug_in.c
or at least use the plug_in_defs list. Otherwise plug-ins won't be able
to register their domain on the first call.
> The only thing missing now is the
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 b
Hi,
> I think I know why Michael got his solid black output, and it had
> nothing (really) to do with the bug fixes I did for 3.0.7. The
> problem was that someone ripped out the calc_rgb_to_hsv and
> calc_hsv_to_rgb functions I put in print-util and replaced them with
> gimp_calc_rgb_to_hsv4 wi
Hi,
Ok, one shouldn't just bitch about other people's code, so here is my patch
that adds an optional locale_domain and locale_path to the plugin structure
and extends the pluginrc code to read and write that information from/into
the pluginrc. This code is obviously a few lines longer than what
Hi,
> It was meant such, but from your description it seemed to me that
> you'd like to add those entries to ALL plugins. From your answer
> I can see that this was just a misunderstanding. Sorry, Sven.
>
> But this make it even harder to modify the parser like you'd like
> since it's only
Hi,
I have thought about the problem a little more and there's one
question that has not been addressed until now. How should the
plugin now where its mo-file will be installed? If we want to
stay with the existing procedure that the plug-in may be
installed in a configured list of paths, it do
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 entr
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 line
Hi,
well there seems to be a consensus that your changes make sense.
I have however a few questions about the implementation:
You want the plug-ins to register their domain and a path to the
catalog. If I understand you correctly, this is done by calling
gimp_domain_add () in the query function
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 strict
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 n
Hi,
> I have a question: what standard do the po-filenames follow? In the
> current gimp, we have a en_GB translation, however, GB is not a toplevel
> domain, but the iso-3166 code for the UK.
>
> On the other hand, we also have uk (which is a toplevel domain, but not
> for ukraine), however, th
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 sur
> I've had trouble compiling gimp 1.1.17 on Solaris 8 with the native
> compiler (Workshop 5.0).
> Here's the list of problem :
Fixed in CVS together with a few more places that had the same problem.
Thanks for the report. If you have access to CVS, please update your tree
and give it another t
> > > 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 sta
> BTW: Has something changed in the handling of the icons/toolbox buttons?
> If I move the mouse over a button (current CVS) just a rectangular frame
> around the image gets highlighted. Did the transparency of the imaged
> disappear?
Eeek, my fault. I somehow forgot about the importance of the m
Hi,
> Mind, based on my own DTP experience, I'm not entirely convinced that
> this is all that useful, anyway. When I did newsletters, I had to fit
> photos and other graphics to the page; nominal image size meant very
> little beyond being careful not to enlarge things too much. The 3.1
> plug
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
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 g
Hi,
> I'm experimenting with gimp_image_get_resolution(). It appears (in
> 1.1.17, at any rate) that whatever I set the units to I always get a
> resolution back that's expressed in dots per inch. Is this behavior
> correct? If so, did it work this way in 1.0 also? This is so I can
> investig
> 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
Hi,
> * How to change RGBA image to an RGB image ?, because it's not
> intuitive enough. New option in "Remove Alpha" menu would be
> more helpful than explaining this and that.
Removing Alha from a multilayered image is not possible since
gimp insists on having alpha on each layer but the back
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 som
Hi,
I'm forwarding this to the list since I can't do anything about this,
but hopefully someone who can listens...
--- Start of Forwarded Message
> I guess you are having trouble with the anoncvs servers. There are
> four servers and I have the strong feeling that at least one of them
> is
> What happened to ChangeLog in CVS? The newest entry
> is dated January 26th (the revision date in my
> gimp/CVS/Entries says it is rev. 1.2137, dated Feb, 17th).
I guess you are having trouble with the anoncvs servers. There are
four servers and I have the strong feeling that at least one of th
> 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 pre
> > 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 a
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, an
Hi,
> A1) Do not change anything in these calls to gimp-edit-fill, which
> means that these scripts would now create a background layer
> that is filled with the current foreground color.
> A2) Keep the current behavior by adding something like
> (gimp-palette-set-foreground (car (gi
> I agree with marc here. Nobody expects Gimp 1.0 / 1.2 compatibility.
> If we change this right after the 1.2 release we would force people
> who want to use new plugins to a probably really unstable developers
> version. IMHO this is bad.
Ok, so who is going to do it? We will certainly not acce
> 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 "/Image/Alp
> Looking at selection.c, I think I notice that there is some dead code
> in there. As USE_XDRAWPOINTS is #defined (and apparently always has
> been?), the gc_in field (GdkGC*) in GSelection structs doesn't seem to
> be actually used for anything. It is created, and various attributes
> of it are
>
> Fill in 1.1.15 filled with the foreground colour. Its a bug, out and
> out, and should be fixed.
???
> shift-click in 1.0.x fills with background colour.
> ctrl-click in 1.1.15 fills with background colour.
>
I think we were not discussing the Bucket Fill tool, but Edit->Fill
in the imag
> 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 ba
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 ru
> > 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
> 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 a
> Will we unmark printer names N_() tagging in print.c?
I'm not sure. I have done it once, but didn't check it in after I
realized that lots of translators had already provided localisation
for those strings. I don't know if an "EPSON Stylus Color" is called
like this all over the world, so ther
101 - 200 of 331 matches
Mail list logo
