Re: Saving a layer
On Mon, Jan 24, 2000 at 08:55:17PM +0100, Sven Neumann wrote: > > 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 layer - > > if it does not, then the content will be centered on the new image and will > > be out of line. Whats the right way of saving a layer to disk? > > Most save plug-ins only support single-layer images. If you call them >non-interactively on a multi-layer image they will only save the drawable > you passed it. Where's your problem? Gone now actually :) That completely solved my problem. Thank you very much. Ian -- Ian McKellar | Email: yakk(a)yakk.net | Web: http://www.yakk.net/ Fax: +61 (8) 9265 0821 / +0 (775) 205 0307 | Home: +61 (8) 9389 9152 If God didn't want us to eat animals, he wouldn't have made them out of meat.
Re: Remove the Stack Trace...
On 24 Jan, Raphael Quinet wrote: > Any suggestions for the name of the new option? It could be something > > like "--disable-stack-trace" or "--disable-crash-query", assuming > that the default behaviour would be to have it enabled in unstable > releases. Note that I also support the idea posted some time ago on > this list that suggested to enable most debugging options in the > unstable releases, but to disable them by default in the stable > releases (so that you would have to use the opposite option > --enable-crash-query if you wanted that feature). And maybe the > people building RPMs or other pre-compiled packages should disable > these options as part of the build rules also for unstable releases if > they think that it is better. I will check the behaviour and if it really blocks when not called from a terminal I will remove this "feature" for our next distribution otherwise it will stay because it gives a good start for bugreports even if compiled without debugging information -- Servus, Daniel
Re: Remove the Stack Trace...
On Mon, Jan 24, 2000 at 06:31:24PM +0100, Raphael Quinet wrote: > On Mon, 24 Jan 2000, Austin Donnelly <[EMAIL PROTECTED]> wrote: > > On Monday, 24 Jan 2000, Glyph Lefkowitz wrote: > > > Since the only advantage of this is the stack-trace for non-developers, > > > why don't we just have it dump stack, then die, by default. > > > > This sounds sensible, but also add a check on istty(stdout) being > > true. No point taking forever doing a backtrace if no-one's going to > > see it. > > If I am not mistaken, the call to isatty() is already done inside glib. > In glib (gerror.c), if the current terminal is not a tty, then the > program will immediately exit instead of asking for a stack trace or > whatever. Yep. > I know a bit of configure, so if nobody else is interested in > implementing this simple change (a couple of lines, I think), then I > will do that tomorrow. > > Any suggestions for the name of the new option? It could be something > like "--disable-stack-trace" or "--disable-crash-query", assuming that > the default behaviour would be to have it enabled in unstable releases. > Note that I also support the idea posted some time ago on this list > that suggested to enable most debugging options in the unstable > releases, but to disable them by default in the stable releases (so > that you would have to use the opposite option --enable-crash-query if > you wanted that feature). And maybe the people building RPMs or other > pre-compiled packages should disable these options as part of the > build rules also for unstable releases if they think that it is better. How about --enable-stack-trace=[yes/no/query] and set it to query by default. We'll set the default to no for stable releases. This should just set the default setting that gimp uses at runtime. There should be runtime options that parallel to override. -Yosh
Speaking of additional plug-ins
I have a couple of image format plug-ins available for the GIMP one is included with the GIMP (pix) and one of them (formerly tdi, now MayaIFF) has been in the unstable tree since before 1.0 was released. The latest version, as always, is in the plug-in registry. It's not likely that many people on this list will be very interested in files of the MayaIFF variety. You would either have to be using Maya (http://www.aliaswavefront.com/entertainment/index.html) or Shake (http://www.nothingreal.com/). And would probably put you in the film or video game industry. >From the number of e-mails I get, there are a lot of people using GIMP with Maya, primarily on SGI's. I distribute a binary of my plug-in for IRIX via my web page. But, unfortunate differences in which cut of GIMP and IRIX they have make it difficult to make my plug-in work on all SGI's. Most Maya/SGI users don't have a compiler installed either, so when it doesn't work, they are out of luck. It would be much less frustrating for users and less time consuming for me if I could get my plug-in into the main tree. It looks like I've missed the deadline for another version of GIMP. I read that people are concerned about the number of plug-ins currently shipping with the GIMP. I have previously tried to elicit an opinion about whether that concern applies to format plug-ins, but I didn't get any responses. If it is a concern, then I'd say that the MayaIFF plug-in is more useful than the Pix plug-in that I submitted in time for 1.0. Also, I'm behind a firewall and I haven't managed to get CVS working through it. I'm not sure what would be involved in getting it moved over. So, I would be ever so grateful if someone could comment on: 1. would it be appropriate to add yet another format plug-in to the main branch 2. when should I add it 3. what's involved in moving it (it's a single file plug-in) I've been maintaining the plug-in for over two years now and I will continue to do so. Nobody has ever logged a bug against it that wasn't related to getting it working on their particular cut of IRIX or GIMP. Any help or discussion would be greatly appriciated! /\/\ike -- Mike Taylor ([EMAIL PROTECTED]) Alias|Wavefront, Toronto http://reality.sgi.com/mtaylor
Re: Remove the Stack Trace...
On 24 Jan, Jens Lautenbacher wrote: > 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'm currently developping a distributed perlfu server and it would > make life much much easier if gimp would simply crash without hanging > still around only due to a segfault handler. Starting it with gdb will avoid the handler -- Servus, Daniel
Re: Remove the Stack Trace...
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 crashing while still having grabed the mouse. It wouldn't help to start from a terminal in that situation, since the mouse is grabbed. But I do like to be able to switch to a console and use gdb to attach to the running gimp process in order to find out what went wrong actually. Salut, Sven
Re: End-user feedback: Perl logulator & innerbevel
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 nobody wanted to take the job and I do like Script-Fus I registered myself as Script-Fu maintainer a while ago. I have since then (and before) tried to fix all Script-Fu related bugs that I knew of. Have a look at the bug-tracking system. IIRC there's not a single open Script-Fu bug listed there. I do however see some Perl-related bugreports, but I'm starting to get off-topic... > I, for example, reported that bug and how to reproduce it in minute detail > at least 3 times (maybe even more) during the last 15 months(!). Oops, then I must have thought it was related to the other bugs that got fixed. I can't remember a detailed bugreport however. You should know that to be sure that a bug gets attention and isn't forgotten there is only one proper way to report it: use the bug-tracker on bugs.gnome.org. > If you look through the archives of gimp-developers and gimp-users you > will find that this bug is being reported quite regularly. I don't read gimp-users, sorry! > So yes, I do not believe that script-fu will work in 1.2. I also believe > that script-fu needs a real maintainer who cares for it, not somebody like > you who should better do other things. Ehhh, I hope you didn't meant to say what I read out of this sentence... I really don't know what bug you are talking about actually, so please, would you take the time to file a proper bugreport? Salut, Sven
Re: Saving a layer
> 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 layer - > if it does not, then the content will be centered on the new image and will > be out of line. Whats the right way of saving a layer to disk? Most save plug-ins only support single-layer images. If you call them non-interactively on a multi-layer image they will only save the drawable you passed it. Where's your problem? Salut, Sven
Re: Remove the Stack Trace...
On Mon, 24 Jan 2000, Austin Donnelly <[EMAIL PROTECTED]> wrote: > On Monday, 24 Jan 2000, Glyph Lefkowitz wrote: > > Since the only advantage of this is the stack-trace for non-developers, > > why don't we just have it dump stack, then die, by default. > > This sounds sensible, but also add a check on istty(stdout) being > true. No point taking forever doing a backtrace if no-one's going to > see it. If I am not mistaken, the call to isatty() is already done inside glib. In glib (gerror.c), if the current terminal is not a tty, then the program will immediately exit instead of asking for a stack trace or whatever. I know a bit of configure, so if nobody else is interested in implementing this simple change (a couple of lines, I think), then I will do that tomorrow. Any suggestions for the name of the new option? It could be something like "--disable-stack-trace" or "--disable-crash-query", assuming that the default behaviour would be to have it enabled in unstable releases. Note that I also support the idea posted some time ago on this list that suggested to enable most debugging options in the unstable releases, but to disable them by default in the stable releases (so that you would have to use the opposite option --enable-crash-query if you wanted that feature). And maybe the people building RPMs or other pre-compiled packages should disable these options as part of the build rules also for unstable releases if they think that it is better. -Raphael
Re: Remove the Stack Trace...
On Monday, 24 Jan 2000, Glyph Lefkowitz wrote: > Since the only advantage of this is the stack-trace for non-developers, > why don't we just have it dump stack, then die, by default. This sounds sensible, but also add a check on istty(stdout) being true. No point taking forever doing a backtrace if no-one's going to see it. Austin
Re: Remove the Stack Trace...
On 24 Jan 2000, Jens Lautenbacher wrote: > I also remember having big problems with a segfaultet gimp started > from the gnome panel (or any other non-shell commandline means) and > gimp crashing while still having grabed the mouse. YES. Especially with the grabbed mouse. I am casting my vote for this 100%, little as it may be worth =) > I know that the stack trace thing is useful, I only want to have an > option to avoid it WITHOUT the need to always fiddle the source code. Since the only advantage of this is the stack-trace for non-developers, why don't we just have it dump stack, then die, by default, unless you're running it under GDB or with a --do-annoying-stack-trace-crap option? I usually launch GIMP from a button, although nowadays I am actually running xterm -iconic -e gimp, so that when it dies I can just kill the xterm. (and hope that it wasn't grabbing the pointer...) The Tao is like a glob pattern: It is masked but always present. used but never used up. I don't know who built to it. It is like the extern void: It came before the first kernel. filled with infinite possibilities. [[EMAIL PROTECTED]]
Saving a layer
Hi, 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 layer - if it does not, then the content will be centered on the new image and will be out of line. Whats the right way of saving a layer to disk? Ian -- Ian McKellar | Email: yakk(a)yakk.net | Web: http://www.yakk.net/ Fax: +61 (8) 9265 0821 / +0 (775) 205 0307 | Home: +61 (8) 9389 9152 If God didn't want us to eat animals, he wouldn't have made them out of meat.
Remove the Stack Trace...
Hi Folks, 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'm currently developping a distributed perlfu server and it would make life much much easier if gimp would simply crash without hanging still around only due to a segfault handler. I also remember having big problems with a segfaultet gimp started from the gnome panel (or any other non-shell commandline means) and gimp crashing while still having grabed the mouse. I know that the stack trace thing is useful, I only want to have an option to avoid it WITHOUT the need to always fiddle the source code. If I knew a bit more about configure (I know next to nothing) I would do it myself IF we could reach consensus that it woudl be a Good Thing(TM). jtl
Re: [gimp-devel] Re: End-user feedback: Perl logulator & innerbevel
Marc Lehmann ([EMAIL PROTECTED]) wrote: > On Mon, Jan 24, 2000 at 01:52:40AM +0100, Sven Neumann <[EMAIL PROTECTED]> >wrote: > > 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. >From PLUGIN_MAINTAINERS: --- NAME : script-fu AUTHOR : Spencer Kimball & Peter Mattis MAINTAINER : Sven Neumann <[EMAIL PROTECTED]> SIZE : 463.2 kB in 11 files (only C files counted) COMMENT: --- Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: End-user feedback: Perl logulator & innerbevel
On Mon, Jan 24, 2000 at 01:52:40AM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > 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. > Of course it will get fixed then since it would be stupid to release 1.2 > if there are any known Script-Fu bugs in there. I, for example, reported that bug and how to reproduce it in minute detail at least 3 times (maybe even more) during the last 15 months(!). If you look through the archives of gimp-developers and gimp-users you will find that this bug is being reported quite regularly. So yes, I do not believe that script-fu will work in 1.2. I also believe that script-fu needs a real maintainer who cares for it, not somebody like you who should better do other things. Fact is, however, that script-fu is basically unmaintained. The bugs that I reported during the last year did not get fixed (with rare exceptions when you, mitch or me did it), and it is less then clear who is "responsible" for that plug-in. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: bug #2355
On Sun, 23 Jan 2000, Kelly Lynn Martin wrote: > Anybody understand what the guy in #2355 is asking for? It looks like > he wants DynText layers to rerender on layer scale, which would be > a major architectural change (not impossible, just not something that > should be squeezed in under a freeze). Is this just a user > misunderstanding? No, it's a bug report somewhat unrelated to gimp. The problem is that the X font spec allows to pass the size of the font in points instead of pixels. GDynText and the standard gtk font selector support this. However, to compute the pixel size corresponding to the point size, X uses it's own monitor resolution value which is (1) wrong in most cases and (2) has definitely nothing to do with gimp's image resolution. I've updated the text tool some time ago to fill the X font spec's "resolution" field correctly for "points" (app/text_tool.c:text_set_resolution()). I guess doing the same for GDynText will fix the problem. If I find the time, I'll have a look at it. bye, --Mitch
Article on UI design in free software.
Not bad. Quite pertinent to GIMP. http://sendmail.net/?feed=interviewkuniavsky Not that I think GIMP's UI is bad (lately) or that we have a particular reason to actively innovate as opposed to more of less cribbing, ahem, someone's UI. --Adam
