Re: [Gimp-developer] Re: Gimp 1.3.22
Sven Neumann writes: > I am not sure about the purpose of libgimpbase/gimpwin32-io.h. Is it > used only in the GIMP source tree or is it supposed to be installed so > external plug-ins can use it as well? I assume it is to be used only in the source tree. > Anyway, it should certainly be added to libgimpbase_1_3_la_SOURCES. > Can you remove the empty EXTRA_HEADERS line from > libgimpmodule/Makefile.am while you are on it? Sure, done. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 4.3.23
Gimp-Print 4.3.23, released November 4, 2003, is a development release of this package. Like all development releases, this version is considered unstable and should only be used by those individuals tolerant of the likelihood of problems. Individuals desiring a stable release of Gimp-Print should use the latest 4.2 release. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and newer) and Linux systems in many cases equal to or better than proprietary vendor-supplied drivers, and can be used for many of the most demanding printing tasks. This software includes the Print plug-in for the Gimp, and Ghostscript and CUPS drivers, including Foomatic data. The Print plugin for the Gimp requires the Gimp 1.2 (later versions of the Gimp are not supported). You may need to install a package named "gimp-devel" or the like on many distributions. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named "cups-devel" or the like on many distributions. We strongly recommend using CUPS with Gimp-Print as a general-purpose printing solution. We do not currently recommend using Foomatic, as the Foomatic data generator included with Gimp-Print offers very limited capabilities. This will be fixed in a future release. The Foomatic data will work with either Foomatic 2.x or 3.x. Foomatic 3.x has additional capabilities that this package detects and takes advantage of. The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53 or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or later. Users of Macintosh OS X 10.2 and above can use this package, as the printing system is based on CUPS, which is supported by Gimp-print. Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use this package. Please read the README file for full instructions on installing this package. Gimp-Print 4.3.23 contains the following major changes over Gimp-Print 4.3.22: 1) A failure to compile with gcc 2.x that was introduced in 4.3.22 as part of making inlining work correctly in gcc 3.x has been fixed. 2) The Epson driver now allows a choice of weave patterns. Depending upon the printer, paper type, and/or resolution you may find that a weave pattern other than the default works better. -- Robert Krawitz <[EMAIL PROTECTED]> 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 Gimp Print --http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpDialog API change
Hi Mitch, Michael Natterer wrote: > GtkWidget * > gimp_dialog_new (const gchar*title, > const gchar*role, > GtkWidget *parent, > GtkDialogFlags flags, > GimpHelpFunchelp_func, > const gchar*help_id, > ...); This looks good to me. > I'll start hacking this today but would like to get some ACKs or EEKs > before I start porting the plug-ins (which have many many GimpDialogs). One question... do you think it would be worthwhile to make the API change, document what needs to be done to change from the old API to the new, and then have a number of people work on porting the plug-ins? Each plug-in in itself would probably be a small job, but the lot of them might take you a while. Would this be worthwhile? I would certainly do a few plug-ins, are there others who would be able to help out here? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GimpDialog API change
On Tue, Nov 04, 2003 at 12:28:09PM +0100, Michael Natterer wrote: > Hi, > > As you may know, GimpDialog from libgimpwidgets badly needs an > API change for GIMP 2.0. > > The relevant bugzilla entry: > http://bugzilla.gnome.org/show_bug.cgi?id=125143 > > The plan is to just remove our own action_area API and use GtkDialog's > one, which involves making use of the dialog's "response" signal > instead of connecting to each button's "clicked". > > The old API is just way too complicated and does things nobody > really needs. The new stuff boils down to one function: > > /** > * gimp_dialog_new: > * @title:The dialog's title which will be set with > *gtk_window_set_title(). > * @role: The dialog's @role which will be set with > *gtk_window_set_role(). > * @parent: The @parent widget of this dialog. > * @flags:The @flags (see the #GtkDialog documentation). > * @help_func:The function which will be called if the user presses "F1". > * @help_id: The help_id which will be passed to @help_func. > * @...: A %NULL-terminated @va_list destribing the > *action_area buttons. > * > * Creates a new @GimpDialog widget. > * > * This function simply packs the action_area arguments passed in "..." > * into a @va_list variable and passes everything to gimp_dialog_new_valist(). > * > * For a description of the format of the @va_list describing the > * action_area buttons see gtk_dialog_new_with_buttons(). > * > * Returns: A #GimpDialog. > **/ > GtkWidget * > gimp_dialog_new (const gchar*title, > const gchar*role, > GtkWidget *parent, > GtkDialogFlags flags, > GimpHelpFunchelp_func, > const gchar*help_id, > ...); > > > Of course there will be a _valist() variant. > > I'll start hacking this today but would like to get some ACKs or EEKs > before I start porting the plug-ins (which have many many GimpDialogs). > You have my bless on this. As I've said I can help you converting some of the plug-ins. DindinX -- [EMAIL PROTECTED] #include b;main(c,v)char**v;{for(c=0;v[1][c];c++){**v=v[1][c];putchar(islower(**v)? 97+(**v-97*2+v[2][(c-b)%strlen(v[2])])%26:(b++,**v));}putchar(10);} ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp 1.3.22
Hi, Tor Lillqvist <[EMAIL PROTECTED]> writes: > > and also libgimpbase/gimpwin32-io.h > > That probably should be added to libgimbase/Makefile.am's EXTRA_DIST? > The EXTRA_HEADERS macro doesn't seem to be used for anything in the > generated Makefile? I don't think EXTRA_HEADERS is a valid automake macro at all. I am not sure about the purpose of libgimpbase/gimpwin32-io.h. Is it used only in the GIMP source tree or is it supposed to be installed so external plug-ins can use it as well? Anyway, it should certainly be added to libgimpbase_1_3_la_SOURCES. Tor, will you take care of this? Can you remove the empty EXTRA_HEADERS line from libgimpmodule/Makefile.am while you are on it? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] jobs for the boys: RIP coders wanted
Hi GIMPers, I know this is a little off-topic, but it's definitely interesting to anyone looking for a job in the pre-press software industry. Ben Hobbs (from Idealpeople, a recruitment firm) is looking for people with experience of RIPs, and other pre-press issues. I've put a message from him below. Thanks, Austin --- Hi Austin, I have been enjoying your explanations on FM Screening and dithering, They have helped me understand one of our specs a great deal more, Thanks. We have recently set up a division (me) to focus exclusively on recruitment for the pre-press/print technology industry and are finding it hard to come by candidates. We are currently after: * RIP Coder with experience of Colour Management (ICC Profiles etc...) - Australia Permanent position with full help in re-location, work permit and immigration issues. * Screening Consultant for a RIP company in Europe * RIP Coders for a UK based company (London) Do you know anyone who would be interested in any of these positions, If so then please let me know! Basically we are interested in all coders with experience of RIP's, PCL and digital print technologies overall. This is really very appreciated, its actually been very refreshing for me trying to source these vacancies. The help people have given me I have not seen in any other area of software development, Oh and we are particularly interested in Linux guys for the Australian role. Regards, Ben Hobbs Idealpeople ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpDialog API change
Hi, As you may know, GimpDialog from libgimpwidgets badly needs an API change for GIMP 2.0. The relevant bugzilla entry: http://bugzilla.gnome.org/show_bug.cgi?id=125143 The plan is to just remove our own action_area API and use GtkDialog's one, which involves making use of the dialog's "response" signal instead of connecting to each button's "clicked". The old API is just way too complicated and does things nobody really needs. The new stuff boils down to one function: /** * gimp_dialog_new: * @title:The dialog's title which will be set with *gtk_window_set_title(). * @role: The dialog's @role which will be set with *gtk_window_set_role(). * @parent: The @parent widget of this dialog. * @flags:The @flags (see the #GtkDialog documentation). * @help_func:The function which will be called if the user presses "F1". * @help_id: The help_id which will be passed to @help_func. * @...: A %NULL-terminated @va_list destribing the *action_area buttons. * * Creates a new @GimpDialog widget. * * This function simply packs the action_area arguments passed in "..." * into a @va_list variable and passes everything to gimp_dialog_new_valist(). * * For a description of the format of the @va_list describing the * action_area buttons see gtk_dialog_new_with_buttons(). * * Returns: A #GimpDialog. **/ GtkWidget * gimp_dialog_new (const gchar*title, const gchar*role, GtkWidget *parent, GtkDialogFlags flags, GimpHelpFunchelp_func, const gchar*help_id, ...); Of course there will be a _valist() variant. I'll start hacking this today but would like to get some ACKs or EEKs before I start porting the plug-ins (which have many many GimpDialogs). ciao, --mitch ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer