Re: [gimp-devel] Re: Edit File behaviour change?
Sven Neumann ([EMAIL PROTECTED]) wrote:
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 accept a change as
it was done the last time. All scripts and other affected spots have to
be changed!
Here is a list of probably all affected files:
[simon@vmax:~/cvs/gimp] find . -exec /usr/local/bin/grep \
-l "edit.fill" \{\} \;
./ChangeLog # no need to fix :-)
./README.perl # probably no need to fix
./app/commands.c # Just callbacks
./app/commands.h
./app/edit_cmds.c # Autogenerated
./app/menus.c # Just menu-generation
./app/global_edit.c # This needs to be adjusted to use the fg-color
./app/global_edit.h
./docs/script-fu.tex # Some example scripts need to be adjusted.
# BTW: Do they work in Gimp 1.2 ???
./help/C/image/edit/fill.html # Not yet documented
./plug-ins/perl/README
./plug-ins/perl/scm2scm
./plug-ins/perl/examples/Create_Images
[15 files deleted]
./plug-ins/perl/examples/translogo
# Marc?
./plug-ins/script-fu/scripts/3d-outline.scm
[64 files deleted]
./plug-ins/script-fu/scripts/xach-effect.scm
# Raphael already volunteered... Contact me, if you need assistance.
./plug-ins/pygimp/doc/procedural-database.html # no need to fix
./plug-ins/pygimp/doc/pygimp.sgml# example needs fixing
./plug-ins/pygimp/doc/structure-of-plugin.html # example needs fixing
./plug-ins/pygimp/plug-ins/clothify.py # needs fixing.
./plug-ins/pygimp/plug-ins/foggify.py # needs fixing.
./plug-ins/pygimp/plug-ins/sphere.py # needs fixing.
./tools/pdbgen/pdb/edit.pdb# Documentation string needs to be fixed.
# I can do this.
Did I miss a Pattern? I think "edit.fill" is good enough?
Bye,
Simon
--
[EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Edit Fille behaviour change?
On Sun, Feb 13, 2000 at 09:24:54PM -0500, Kevin Cozens [EMAIL PROTECTED] wrote: From some of the other comments on the mailing list here, perhaps its something that should be changed after 1.2 is out. Many scripts may have to I don't think so: if you need to do an incompatible change, do it as early as possible. If we break it now, people will need to change things for 1.2, but the devel version and the released version will act the same. In other words: each such change, done early, will remove one further source for incompatibility between gimp-1.2 and 1.3. This is valid when a) the change can be made before 1.2 (including required fixes) and b) gimp-1.2 will stay as long as 1.0 did. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Patch for print plugin
Here is a patch for the print plugin. The patch fixes an anoyance with the
print dialog: If you have lots of printers (we have about 50 here), it takes
*several minutes* to open. Fix: Just use lpstat -d -v (just list the names of
the printers instead of checking if they are enabled; the information is
discarded anyway). Later, when it becomes clear that we can use that info,
we can reenable it again (including some kind of caching and a progress
report which shows that Gimp is still doing something).
*** gimp-1.1.16/plug-ins/print/print.c~ Mon Jan 31 03:32:25 2000
--- gimp-1.1.16/plug-ins/print/print.c Tue Feb 8 15:51:56 2000
***
*** 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
{
char name[17];
--- 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
{
char name[17];
***
*** 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL
plist_count MAX_PLIST)
{
! if (sscanf(line, "printer %s", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--- 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL
plist_count MAX_PLIST)
{
! if (sscanf(line, "system for %[^:]s:", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--
Dipl. Inf. (FH) Aaron "Optimizer" Digulla
"(to) optimize: Make a program faster by
improving the algorithms rather than by
buying a faster machine."
Re: Patch for print plugin
Date: Tue, 15 Feb 2000 13:50:27 +0100
From: Aaron Optimizer Digulla [EMAIL PROTECTED]
Here is a patch for the print plugin. The patch fixes an anoyance
with the print dialog: If you have lots of printers (we have about
50 here), it takes *several minutes* to open. Fix: Just use lpstat
-d -v (just list the names of the printers instead of checking if
they are enabled; the information is discarded anyway). Later, when
it becomes clear that we can use that info, we can reenable it
again (including some kind of caching and a progress report which
shows that Gimp is still doing something).
That patch AS IS isn't going to work. On my system (using
PrintPro/CUPS), lpstat -d -v prints out in a slightly different
format:
$ lpstat -d -v
system default destination: epson
device for epson: parallel:/dev/lp0
device for epson-big: parallel:/dev/lp0
device for foo: /tmp/out
device for null: /dev/null
Note that it uses "device" rather than "system". If you want to
figure out how to make it work in general, go ahead -- it's a
reasonable idea for 3.0.
In the intermediate term, we're considering getting rid of all of this
stuff and using some kind of printer definition dialog, partly because
we haven't found any robust programmatic way of determining the list
of printers on the system and partly because it's reasonable for users
to want to define virtual printers with different combinations of
settings. Something like that's likely to make it into 3.2 (after
having been in 3.1 for a while) as part of a general overhaul of the
UI.
In the longer run, a more general solution to the printing problem is
needed.
*** gimp-1.1.16/plug-ins/print/print.c~ Mon Jan 31 03:32:25 2000
--- gimp-1.1.16/plug-ins/print/print.c Tue Feb 8 15:51:56 2000
***
*** 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
{
char name[17];
--- 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
{
char name[17];
***
*** 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL
plist_count MAX_PLIST)
{
! if (sscanf(line, "printer %s", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--- 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL
plist_count MAX_PLIST)
{
! if (sscanf(line, "system for %[^:]s:", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
Re: Patch for print plugin
On Tue, Feb 15, 2000 at 08:09:37AM -0500, Robert L Krawitz wrote:
Here is a patch for the print plugin. The patch fixes an anoyance
with the print dialog: If you have lots of printers (we have about
50 here), it takes *several minutes* to open. Fix: Just use lpstat
-d -v (just list the names of the printers instead of checking if
they are enabled; the information is discarded anyway). Later, when
it becomes clear that we can use that info, we can reenable it
again (including some kind of caching and a progress report which
shows that Gimp is still doing something).
That patch AS IS isn't going to work. On my system (using
PrintPro/CUPS), lpstat -d -v prints out in a slightly different
format:
$ lpstat -d -v
system default destination: epson
device for epson: parallel:/dev/lp0
device for epson-big: parallel:/dev/lp0
device for foo: /tmp/out
device for null: /dev/null
Ok, then only the second word (for) seems to be stable (the third always seems
to be the printer name). Any other systems around ?
Note that it uses "device" rather than "system". If you want to
figure out how to make it work in general, go ahead -- it's a
reasonable idea for 3.0.
In the intermediate term, we're considering getting rid of all of this
stuff and using some kind of printer definition dialog, partly because
we haven't found any robust programmatic way of determining the list
of printers on the system and partly because it's reasonable for users
to want to define virtual printers with different combinations of
settings. Something like that's likely to make it into 3.2 (after
having been in 3.1 for a while) as part of a general overhaul of the
UI.
In the longer run, a more general solution to the printing problem is
needed.
I agree. But the patch should be included nonetheless because it makes
printing with Gimp possible :-)
*** gimp-1.1.16/plug-ins/print/print.c~Mon Jan 31 03:32:25 2000
--- gimp-1.1.16/plug-ins/print/print.c Tue Feb 8 15:51:56 2000
***
*** 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
{
char name[17];
--- 3146,3152
#endif /* LPC_COMMAND */
#ifdef LPSTAT_COMMAND
! if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
{
char name[17];
***
*** 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL
plist_count MAX_PLIST)
{
! if (sscanf(line, "printer %s", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--- 3153,3159
while (fgets(line, sizeof(line), pfile) != NULL
plist_count MAX_PLIST)
{
! if (sscanf(line, "system for %[^:]s:", name) == 1)
{
strcpy(plist[plist_count].name, name);
sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
--
Dipl. Inf. (FH) Aaron "Optimizer" Digulla
"(to) optimize: Make a program faster by
improving the algorithms rather than by
buying a faster machine."
Re: [gimp-devel] Probably a FRF: Dialogs should remember
Aaron Optimizer Digulla ([EMAIL PROTECTED]) wrote: (a Frequently Requested Feature): When I close a dialog and open it again (e.g. a plugin), it should *not* reset its values to the defaults. This is a per plugin issue. AFAIK most plugins do this already. Where did you notice it? Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Patch for print plugin
Date: Tue, 15 Feb 2000 14:18:37 +0100 From: Aaron Optimizer Digulla [EMAIL PROTECTED] On Tue, Feb 15, 2000 at 08:09:37AM -0500, Robert L Krawitz wrote: Here is a patch for the print plugin. The patch fixes an anoyance with the print dialog: If you have lots of printers (we have about 50 here), it takes *several minutes* to open. Fix: Just use lpstat -d -v (just list the names of the printers instead of checking if they are enabled; the information is discarded anyway). Later, when it becomes clear that we can use that info, we can reenable it again (including some kind of caching and a progress report which shows that Gimp is still doing something). Ok, then only the second word (for) seems to be stable (the third always seems to be the printer name). Any other systems around ? On our specific systems, yes. I don't trust that something else won't be different. If you can test on Linux with a wide variety of different print systems (there are quite a few out there), different versions of Solaris and AIX, and if there's a BSD system running a SysV spooler, and demonstrate that it works on all of them, I will accept the patch. Otherwise, I won't accept this. In the longer run, a more general solution to the printing problem is needed. I agree. But the patch should be included nonetheless because it makes printing with Gimp possible :-) It helps you, but at the risk of breaking other people and hence regressing from 3.0.6 and 2.0 (== Gimp 1.0). As the maintainer of the plugin, I consider this patch too high risk to accept. As I said, though, if you can arrange for system testing and prove that it works on all of them without being overly convoluted, I will consider accepting it, but not otherwise. -- 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] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
