Re: Call for Layers Channels Testing
Tino Schwarze wrote: After all, I got around to test it. Though the patch got a bit messed up by sending it via mail, I managed to apply it. It works. At least, I checked that selecting a layer within LC does indeed change the active layer indicated within the image. Ibelieve the patch fixes only one of a number of possible ways that suspend_gimage_notify can get out of sync, so I'm not closing the related bug reports; see http://idt.net/~gosgood/gimp-patch/patch04.html, I believe you may see this again, particularly running scripts. Keep us posted by submitting any suspicious behaviour to http://www.xach.com/gimp/news/bugreport.html Thanks for your help. Be good, be well Garry Osgood.
Re: Remove the Stack Trace...
Manish Singh [EMAIL PROTECTED] writes: 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. That's it. jtl
Re: Speaking of additional plug-ins
On Tue, Jan 25, 2000 at 12:03:43PM -0500, "Garry R. Osgood" [EMAIL PROTECTED] wrote: For the record, I think a plug-in CVS tree independent of Gimp is a good idea. "Let's focus, people!" At the time this was discussed, the office of a "plugin-maintainer" was also posed, I don't think this is a good idea. Ok, it is a good idea, but I fear you won't find somebody, despite being such an honourable position. GCC is without release manager and will likely stay without one, simply because nobody wnated that most honourable position (and the work ;). The issue is: who has the time? Without people, good ideas remain abstract. I have no time, but I would nevertheless devote part of on merges between the two cvs trees. I could also set up a cvs server, but I firmly believe that it should be related to the gimp.org domain, and I would first have to ask my "boss" wether abusing a machine at the university would be ok (this is a space issue). So my first wish would be to set up an empty cvs on some reliable server, and I would try to populate it with the gimp tree, with (say) nightly updates from main cvs = gimp plug-in cvs (for the core), so that plug-in developers can just check out the tree from the plg-in server and work there. Failing that, I will set up a gimp server on a local machine (in germany), but I can't promose that (I iwll need to find a free disk, but maybe in one or two weeks I can spare 2GB for it). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Speaking of additional plug-ins
From: Dean Johnson [EMAIL PROTECTED] Date: Tue, 25 Jan 2000 16:00:23 -0600 (CST) Cc: [EMAIL PROTECTED] (Garry R. Osgood), [EMAIL PROTECTED] (Gimp Developer's Newslist) Marc Lehmann spontaneously blurts out: Failing that, I will set up a gimp server on a local machine (in germany), but I can't promose that (I iwll need to find a free disk, but maybe in one or two weeks I can spare 2GB for it). This has SourceForge written all over it! Its easy an convenient to start projects and manage stuff. I heartily endorse it! Indeed. I've been using SourceForge for about a week for the Print plugin (the gimp-print project), and it's really good. It takes some time to learn, though. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Re: Speaking of additional plug-ins
On Tue, Jan 25, 2000 at 04:00:23PM -0600, Dean Johnson [EMAIL PROTECTED] wrote:
Failing that, I will set up a gimp server on a local machine (in germany),
but I can't promose that (I iwll need to find a free disk, but maybe in
one or two weeks I can spare 2GB for it).
This has SourceForge written all over it! Its easy an convenient to start
projects and manage stuff. I heartily endorse it!
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 gimpforge should
be automatic and regular, while updates in the other direction should be
enabled for specific files (plug-ins/common/snoise.c) or subdirectories
(e.g. plug-ins/perl).
That will effectively implement some kind of access-model, and it will
(hopefully) make it possible to *select* a fileset for distribution.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
Re: Speaking of additional plug-ins
For the record, I think a plug-in CVS tree independent of Gimp is a good idea. "Let's focus, people!" [snip] The issue is: who has the time? Without people, good ideas remain abstract. I have no time, but I would nevertheless devote part of on merges between the two cvs trees. I could also set up a cvs server, but I firmly believe that it should be related to the gimp.org domain, and I would first have to ask my "boss" wether abusing a machine at the university would be ok (this is a space issue). delurk People should feel free to ask for a CVS account on the cvs.gnome.org box. If they have something cool they are working on for the GIMP, we can certainly give them access, provided they are willing to follow the standard GNOME CVS etiquette. As far as the GIMP is concerned, people could maintain their own experimental plug-ins in little CVS modules and later, when the plug-in is Done(tm), they could ask a CVS maintainer to physically move it to the main GIMP module. Or it could be linked as a virtual module, which also is a nice solution. This way you can have branches for particular plug-ins. In particular, I would love to see the fantastic Print plug-in on the GNOME CVS :-) Of course, that is up to Robert to decide. If there is anything the CVS maintainers can do to make Robert's life easier, I'd love to hear about it. /delurk Federico
Re: Speaking of additional plug-ins
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 gimpforge should
be automatic and regular, while updates in the other direction should be
enabled for specific files (plug-ins/common/snoise.c) or subdirectories
(e.g. plug-ins/perl).
That will effectively implement some kind of access-model, and it will
(hopefully) make it possible to *select* a fileset for distribution.
This all sounds nice, but I hope you are aware that once gimp-1.2 is out
there will unlikely be another stable release (despite bug-fix releases
of course) before gimp-2.0 and the plug-in interface for 2.0 will certainly
be incompatible with what he have now.
I don't want to say that plugin development should stall until the
new interface has settled, but it would probably be a good idea to take
this into account from the beginning and split the tree from ground up.
This means having two branches (stable and devel) on the plugin CVS. That
way we could throw all plug-ins out when work on 2.0 starts and include
them later out of the 2.0 compatible plug-in branch. However I haven't
thought much about this yet, is it a good idea ...?
I also want to point out that IMHO setting up a CVS server will not be
enough. Ideally, this project should completely replace the registry.
A web interface to the repository together with tips for installation
will be essential. Plug-ins should be released on a regulary basis,
since working with stuff out of CVS is not what our users want to do
and it always buries the risk of checking stuff out that just doesn't
work at the moment.
...just my 2 cents...
Salut, Sven
Re: Speaking of additional plug-ins
Marc Lehmann spontaneously blurts out:
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 gimpforge should
be automatic and regular, while updates in the other direction should be
enabled for specific files (plug-ins/common/snoise.c) or subdirectories
(e.g. plug-ins/perl).
That will effectively implement some kind of access-model, and it will
(hopefully) make it possible to *select* a fileset for distribution.
I guess I wasn't advocating moving the whole tree over, just the plug-ins.
I don't know anything about the GIMP development process, or the internal
intrigue that seems to surface from time to time, so I can't ascertain
whether the whole thing should move.
-Dean Johnson
Tool Hooligan
Cluster Admin Tools Jessie Project
Silicon Graphics Inc.Eagan,MN (651) 683-5880
"I am Dyslexic of Borg, Your Ass will be Laminated"-- unknown
gimp 1.0.4 compile on DEC unix 4.0e
getting this error when compiling 'install' .. Making install in app /bin/sh ../mkinstalldirs /usr/local/bin /bin/sh ../libtool --mode=install .././install-sh -c gimp /usr/local/bin/gimp .././install-sh -c gimp /usr/local/bin/gimp cc -g -std1 install.c -o install cc: Severe: gdk/gdkx.h, line 30: Cannot find file gdk/gdkprivate.h specified i n #include directive. (noinclfile) #include gdk/gdkprivate.h -^ *** Exit 1 Stop. *** Exit 1 Stop. --- any ideas ?? have glib-1.2.6 and gtk+-1.2.6 installed ok .. Thanks, Kevin ...
Re: Speaking of additional plug-ins
On Tue, Jan 25, 2000 at 07:17:31PM -0500, Federico Mena Quintero [EMAIL PROTECTED] wrote: People should feel free to ask for a CVS account on the cvs.gnome.org box. If they have something cool they are working on for the GIMP, we As a matter of fact, it is very difficult ot get a cvs account, for various reasons. We do not want to have every plug-in author have writing rights to the gimp tree, but we _do_ want every plug-in author to have them. For other reasons, giving them access to a "shielded cvs" could be done much easier (just let him prove he can do it), than having to persuade a lot of people to get a cvs account (for good reasons). On Tue, Jan 25, 2000 at 06:37:17PM -0600, Dean Johnson [EMAIL PROTECTED] wrote: I guess I wasn't advocating moving the whole tree over, just the plug-ins. No, the way it'l be done is to mirror the whole tree, so people can just check out the _whole_ gimp from sourceforge, and work in it. The difference to the anonymous server is that they can write to the cvs, but they will not be able to change any files not marked for changing. On Wed, Jan 26, 2000 at 01:24:44AM +0100, Sven Neumann [EMAIL PROTECTED] wrote: this into account from the beginning and split the tree from ground up. This means having two branches (stable and devel) on the plugin CVS. That I think we should just do the same as we do on the main cvs server: once 1.2 is out, make a 1.2 branch, do the same on the plug-ins server. them later out of the 2.0 compatible plug-in branch. However I haven't thought much about this yet, is it a good idea ...? I haven't thought about that myself, but having two barnches (then) makes very much sense to me. The mirror script would be almost the same. I also want to point out that IMHO setting up a CVS server will not be Oh ;) SourceForge gives us all that, web, ftp, cvs etc.. As a matter of fact, there already is a sourceforge project named "gimp-plug-ins" since a few hours ;) My (better thought-pout plan) is to add these two files to the main gimp cvs: PLUGIN_CVS # control what gets mirrored, when ChangeLog.plug-ins # the changes for the plug-in tree the first one declares some files/directories to be part of the "plug-ins" cvs enough. Ideally, this project should completely replace the registry. A web interface to the repository together with tips for installation will be essential. Plug-ins should be released on a regulary basis, since working with stuff out of CVS is not what our users want to do and it always buries the risk of checking stuff out that just doesn't work at the moment. I fully support this. Alas, it's much work, so I suggest that I first create the project, add the mirroring (so the cvs is functional) and then gather _existing_ plug-in maintainers without cvs access to find out wether they want an account on ther sourceforge net. After that, some files (i.e. the "externally managed" plug-ins) are read-only in the main cvs tree, and writable in the plug-in cvs tree, and all the rest is read-only in the plug-in cvs, and read-write in the main gimp directory. This is the only solution that makes it possible to do automatic merges back into the main tree. It also complicates things for the main developers, so it should be given thought (in any case, the mirror script that I have allows to specify "file in original server", "file in copied/plug-in server" and "file is not getting mirrored" (i.e. it's part of gimp-plug-in-cvs but NOT part of the main gimp tree). [before you misunderstand the above paragraph, ask!] If this is in place we/I should seek out for help to get more automatic registrations etc.. (i.e. registering plug-in "space", having nicer packaging etc..) Having a seperately managable tree would it also make it possible to experiment with new ways of plug-in distribution, binary packages etc.. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel
On Mon, Jan 24, 2000 at 03:29:53PM +0100, Simon Budig [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: So what? Sven obviously has not enough time to care for everything in the Gimp. Critical bugs in Script-Fu have not been fixed for over a year, despite a considerable number of good bug-reports. PLUGIN_MAINTAINERS is just a file... fatc is that bugs _do_ _not_ _get_ _fixed_, so script-fu is basically unmaintained. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Speaking of additional plug-ins
On Mon, Jan 24, 2000 at 04:10:46PM -0500, Michael Taylor [EMAIL PROTECTED] wrote: 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. I think the issue is independent of the type of the plug-in. However, I don't believe in the "we accept no more useful plug-ins, since we already have so many useless ones in the tree" argument. Falks: what about that "secondary cvs server for plug-ins"-idea? I only remember a few posotive responses, but no really negative ones. Is it only that nobody has the time to set one up? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel
On Tue, 25 Jan 2000, Marc Lehmann wrote: So what? Sven obviously has not enough time to care for everything in the Gimp. Critical bugs in Script-Fu have not been fixed for over a year, despite a considerable number of good bug-reports. That is VERY vague. What are these 'critical bugs'? Obviously we do not know about them or someone would already have given Sven a list of bug IDs. If re-reporting the bug is so painful that you can't do it, why don't you at least send the list of IDs to the mailing list? What's a "considerable number" of bug reports? Have these bugs been reported multiple times? If so, they should be condensed to one ID -- again, WHAT bug reports are you talking about? They are not SO critical that I have been unable to use script-fu -- there was a time when there were many that were, but they have been getting fixed rather regularly. PLUGIN_MAINTAINERS is just a file... fatc is that bugs _do_ _not_ _get_ _fixed_, so script-fu is basically unmaintained. Marc, I realize you must be frustrated with the bugs you report not getting fixed, and whatever this bug is in particular, but if you would just take the time to re-report it I am sure that Sven would find the time to repair it or at least get back to you. When I have reported script-fu bugs in the past, Sven has contacted ME personally and fixed the bug (sometimes noting that it was similiar to a previously-reported bug). Turnaround time was about two weeks or so each time, which I do not feel is unreasonable for something that he is working on in his spare time. Rather than all the fire and brimstone about script-fu's shortcomings, why don't you (a) help out and fix it or (b) allow Sven (and others) to do his job and re-report bugs occasionally if they do not get fixed. Finally, I really don't believe that you contacted him personally, or that if you did it was only with one brief email during a busy time for him, just so you could say that you DID try to contact him and offer it as proof. Everything you have said so far on this listabout script-fu and its maintainer is completely antithetical to my experience with them.
Re: Remove the Stack Trace...
On Tue, 25 Jan 2000, Marc Lehmann [EMAIL PROTECTED] wrote: On Mon, Jan 24, 2000 at 11:05:35AM -0500, Glyph Lefkowitz [EMAIL PROTECTED] wrote: Since the only advantage of this is the stack-trace for non-developers, The consensus was to remove it in release versions. So if the only advantage is for non-developers, why not remove it altogether? There is a difference between having the stack trace and having the program asking you if you want a stack trace... The latter is more useful for developers because you can also choose to start gdb and attach to the process, but you also have some potential problems with pointer grabs and so on. Here is how I see it: - I like Yosh's suggestion to have a configure option that allows to choose between "yes/no/query" for the stack trace. The "yes" option triggers a direct call to g_on_error_stack_trace() when a SIGSEGV is received, the "no" option exits immediately, and the "query" option calls g_on_error_query() as it does now. The same choices would be available on the command-line regardless of the default value choosen while compiling. The main advantage of the configure option would be to set the default so that it is not necessary to use the command-line option every time, and this could help those who build binary packages. - The default for the code in CVS would always be "query". This ensures that all developers (those who use the CVS code) can easily debug the code without having to re-start with different options if they forgot to enable the stack trace (some heisenbugs can be difficult to reproduce). - The default for the "released" code (in tar files) for the "unstable" versions would be "--enable-stack-trace=yes", so that the users would get a stack trace that they could easily report (if they have gdb) without having any nasty problems with pointer grabs. - The default for the "released" code for the "stable" versions (1.2.x) would be "--enable-stack-trace=no" because we expect that the GIMP would never crash (ha!) and we hope that any crash occuring while running the program could be reproduced by running it a second time with the command-line option that enables the stack trace. Note that this means some additional work for the person who builds the releases, because it will be necessary to remember to change configure.in before building the tar file. Hmmm... Now that I think about it, maybe "make dist" could take care of this automatically. Tricky, but possible, I think. (It must be removed from the plug-in anyway, since it cribbles over the signal handlers prepared by the plug-in, rendering signal handling useless). What is the problem exactly? Most plug-ins do not install a special handler for SIGSEGV (actually, I don't remember any plug-in doing that) so it should not be a problem. Also, using sigaction() instead of signal() could ensure that all signals are propagated correctly, even if there was a handler installed previously. If you have a more specific problem, please explain it because I do not see what is wrong with the current plug-ins. BTW: the stacktrace option has never worked on my machine(s), unless you call "endless loop" working. Also, I could never get out of that signal handler. Gimp just started to suck 100% cpu time when I tried to "e"xit. I doubt that this thing is useful for anybody (I tried it even on a stock redhat 6.1 system). It is a constant annoyance. Hmmm... I had these endless loop problems some time ago with 0.99.x and an old version of glib, but I haven't seen any similar problem in the past year. Also, the stack trace and the option to attach the debugger have both been very useful for me when I had some crashes under Solaris. Anyway, you could use the new command-line option to disable the stack trace if this is causing some problems. -Raphael
Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel
On Tue, Jan 25, 2000 at 11:30:05AM -0500, Kelly Lynn Martin [EMAIL PROTECTED] wrote: PLUGIN_MAINTAINERS is just a file... fatc is that bugs _do_ _not_ _get_ _fixed_, so script-fu is basically unmaintained. You could, of course, fix them yourself. :) As a matter of fact, I couldn't. Why do you think I could? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel
On Tue, 25 Jan 2000 20:53:30 +0100, Marc Lehmann [EMAIL PROTECTED] said: As a matter of fact, I couldn't. Why do you think I could? Anybody can do anything, with enough effort. :) Kelly
Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel
If re-reporting the bug is so painful that you can't do it It is so painful because I re-reported it at least three times (so many mails are in my saent-folder, but I know I sent more that got lost during a crash). They are not SO critical that I have been unable to use script-fu They are ciritcal enough that some plug-ins (like the logulator) never worked because of it. Could you provide the subject line of any one of the messages when you reported the problems with script-fu which you say have not been fixed and/or a date when one of the messages was posted to the list? I am searching the mailing list archives but there are so many messages I haven't found it yet. Using "script-fu" as a search criteria only 206 messages were found. I haven't found one yet which seems to mention script-fu problems in the subject line. I did find the following message from around May of 1999: 1. Gimp segfaults on the first PDB call to gimp_paintbrush. The reason is that the pointer "paintbrush_options" (app/paintbrush.c) is NULL as it isn't initialized automatically. I haven't checked but if other tools use a similar technique these also won't work. (I also haven't checked wether this depends on the global paint options setting). 2. Also, could somebody tell me how I can set the tool options? I seem unable to use gradients from my scripts. 3. How do I use the ink tool? There seems to be now way of using it from scripts. 4. --with-mp=yes slows down the paintbrush tool by approximately 5791%, if not more. (seriously, drawing a line takes 5 seconds instead of 0.2), this was tested with the Circle (01) brush. The same is true for the pencil tool but NOT for the ink tool, which is still fast. I don't the above is script-fu related as such. This is all I was able to find so far. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
