gimp-print-devel

[Gimp-print-devel] change log

[Robert L K. <rl...@al...>]

I wrote my mkchlog script (I didn't name it mkchangelog because emacs
thought it was a change log!  Bletch).  I updated the change log, and
I'll periodically rerun mkchlog to update it before a release.

Speaking of which, it's been a while since 3.1.2, and it occurs to me
that a fair bit of new stuff is in (new dithering and UI code).  We
might be able to do something later this week.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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

[Gimp-print-devel] dither button

[S. M. <sm...@rn...>]

Robert, I just commited a gtk_color_window.c with the dither option menu
in it.  In print.c you'll need to fill in the dither name array and
current dither name, and add what you need to the callback in
color_window (it's the very last one in the file).

Steve
-- 
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

[Gimp-print-devel] Dither problem with stc740

[S. M. <sm...@rn...>]

Is anyone else having problems with their epson 740?  Since about a week
ago I'm getting prints with the black horizontally offset quite a bit
from the other colors.  At first I thought it was my printer, which
behaved oddly for a few days after I used it from windows with the black
cartridge almost empty.  But I just tried to print the same image from
Star Office, and it printed fine.

Steve
-- 
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

[Gimp-print-devel] Dithering

[Robert L K. <rl...@al...>]

I have some new dithering code that I've just committed (it's the code
I've been yakking about lately).  This code seems to give much more
even results, better color matching, and less ink consumption.  It
probably works best for printers with variable dot sizes/ink types,
such as the Epson Stylus Photo series (6 colors, and in some cases
variable dot sizes) and the Stylus Color 740 and 900.  It's certainly
a lot easier to tune, and it's possible to actually understand what's
going on.  I've slapped on two tags "dither2-premerge" and
"dither2-postmerge" in case people dislike it and we want to rip it
out easily.

My tests are a little suspect right now because the cartridge in my
printer right now is contaminated with alcohol that I used to try to
clean it, so the colors are all washed out.  Despite that, however,
it's promising enough so I want more people to get a shot at it.

Note that this doesn't preclude using the Even Toned screening
algorithm, or anything else.  I want to have different dithering
algorithms available for different purposes (e. g. Even Tone doesn't
currently support variable dot sizes).  That's why I've been pushing
for alternate dithering algorithm support.

I have a pretty good backlog of stuff here -- look at rinkj, document
how to add a new family of printers, write a script to generate a
change log from the CVS commit messages.  I need to take a break from
coding long enough to get to all this.  I know I won't get to it all,
though.  The family illness is still there, and won't be entirely
going away any time soon.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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

Re: [Gimp-print-devel] print.c

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
>    Date: Thu, 13 Apr 2000 20:36:51 -0700
>    From: "S. Miller" <sm...@rn...>
> 
>    Mitch, this is incomplete, so you might want to wait until Robert fills
>    in the guts of the dither selection before incorporating it.  Any
>    changes will be in *_color_window.c.
> 
> Don't wait for me on this.  I have a lot of code to merge before this
> will do anything useful.
> 
> --
> Robert Krawitz <rl...@al...>      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 lp...@uu...
> 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


I guess its good to go then.  I'll wait for Mitch's changes for the dual
menu entries, then remerge the dither menu.  It will just sit there as a
ghosted button until there is something for it to do.  I have an
unexpected trip this afternoon, so I hope I can get to it this evening.

Steve

-- 
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

Re: [Gimp-print-devel] print.c

[S. M. <sm...@rn...>]

Michael Natterer wrote:
> 
> 
> Ehm, no, please not !-)
> 
> I just meant to register 2 different PDB calls within one plugin
> and leting the run() function decide which ui to call depending on
> the name of the function passed. This is a frequently used technique
> in Gimp plugins.
Oh, that's better!  I still don't know how, so I'll let you go ahead
with it - then I'll know.

> 
> > For everyone's enlightenment (even if you don't use gnome), I am
> > currently working on shifting the entire gui into a GtkNotebook.  It is
> > fairly slow going, as I'm having to restructure the entire table based
> > gui into multiple chunks.  I'm hoping that the result will allow printer
> > specific additional notebook pages, as well as hide some detail from
> > casual users.
> 
> That's a really cool idea. Do you mean to integrate the color settings back
> in the main notebook then?
> 
> Personally, I like notebooks very much (can't say why, they just feel
> "natural" for me).
> 
Yes, the color settings will have their own page.  The initial page will
have the printer selection, media size/source/etc, resolution.  I'm
debating whether to put the preview stuff on that page or on its own
page.  Suggestions welcome.  Another page will have things like dither
selection, image type (color - the default, greyscale, line), and other
miscellaneous things that a casual or new user won't change much.  It
shouldn't be too hard to check the printer type and add any extra stuff
on a new page if the driver maintainer wanted to.  We just need to be
careful not to go too wild.

Steve


-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

Re: [Gimp-print-devel] print.c

[Robert L K. <rl...@al...>]

   Date: Thu, 13 Apr 2000 20:36:51 -0700
   From: "S. Miller" <sm...@rn...>

   Mitch, this is incomplete, so you might want to wait until Robert fills
   in the guts of the dither selection before incorporating it.  Any
   changes will be in *_color_window.c.

Don't wait for me on this.  I have a lot of code to merge before this
will do anything useful.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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

Re: [Gimp-print-devel] print.c

[Michael N. <mit...@cs...>]

"S. Miller" wrote:
> 
> Robert L Krawitz wrote:
> >
> > As it happens, the reason I want the selectable dither algorithm stuff
> > is mostly so people can experiment, although there would be a bit more
> > reason to have that in a production release.
> >
> 
> Ok, I just grabbed the latest CVS with Dave's changes, and I have some
> merge errors.  I'll try to get this back out Friday afternoon.  I'll
> leave the ifdefs the way Mitch put them in so if you want to use the gtk
> gui you'll have to change 2 lines in print.c: find where a #ifndef
> GIMP_1_0 switches between gtk_* and gimp_*.  Change those to #ifdef and
> you'll force the use of the gtk gui. More tomorrow once I get things
> working again.  This will be more or less the original gui layout.  It
> will be a while before the notebook version is out, and I will try to
> incorporate any interim changes as they occur (if I miss something I'm
> sure I'll hear about it :))

If nobody objects I'll commit some code which adds a second menu entry
so Gimp 1.1.x users can choose which ui they want.

I was also thinking about naming the 2 procedures "file_print_gtk" and
"file_print_gimp", so it installs nicely with the print plugin
which ships with CVS gimp and which of course registers as "file_print".

Currently we seem to share the same problem, as I have to rename
the 3.1.x procedure to "file_print2" and revert this change before I
commit something...

Ok, so what about:

"gimp_print_gtk"  --> "<Image>/File/Print (Gtk)"
"gimp_print_gimp" --> "<Image>/File/Print (Gimp)"
 
> Mitch, this is incomplete, so you might want to wait until Robert fills
> in the guts of the dither selection before incorporating it.  Any
> changes will be in *_color_window.c.

Ok, I will wait for Robert's commit then.

bye,
--Mitch

Re: [Gimp-print-devel] print.c

[Michael N. <mit...@cs...>]

"S. Miller" wrote:
> 
> Michael Natterer wrote:
> >
> > Yep, I'm aware of the problem. As we are in a development cycle, what
> > about registering 2 PDB functions, one for the old and one for the
> > new ui. When it comes to a release we will of course have to remove
> > the second one :)
> >
> > Gnu make doesn't take gcc's -D into account when it calculates the
> > dpeendencies, that's evil (TM).
> >
> > bye,
> > --Mitch
> 
> You mean 2 different plugins?  That should work, but seems ugly.  If its
> ok with Robert, I can live with it.  I have no idea how to go about it
> though.

Ehm, no, please not !-)

I just meant to register 2 different PDB calls within one plugin
and leting the run() function decide which ui to call depending on
the name of the function passed. This is a frequently used technique
in Gimp plugins.

> For everyone's enlightenment (even if you don't use gnome), I am
> currently working on shifting the entire gui into a GtkNotebook.  It is
> fairly slow going, as I'm having to restructure the entire table based
> gui into multiple chunks.  I'm hoping that the result will allow printer
> specific additional notebook pages, as well as hide some detail from
> casual users.

That's a really cool idea. Do you mean to integrate the color settings back
in the main notebook then?

Personally, I like notebooks very much (can't say why, they just feel
"natural" for me).

> As for the trademarked evil, are you sure?  I thought evil was
> trademarked by Microsoft :)

Heh :)

--Mitch

Re: [Gimp-print-devel] print.c

[S. M. <sm...@rn...>]

Robert L Krawitz wrote:
> 
> As it happens, the reason I want the selectable dither algorithm stuff
> is mostly so people can experiment, although there would be a bit more
> reason to have that in a production release.
> 

Ok, I just grabbed the latest CVS with Dave's changes, and I have some
merge errors.  I'll try to get this back out Friday afternoon.  I'll
leave the ifdefs the way Mitch put them in so if you want to use the gtk
gui you'll have to change 2 lines in print.c: find where a #ifndef
GIMP_1_0 switches between gtk_* and gimp_*.  Change those to #ifdef and
you'll force the use of the gtk gui. More tomorrow once I get things
working again.  This will be more or less the original gui layout.  It
will be a while before the notebook version is out, and I will try to
incorporate any interim changes as they occur (if I miss something I'm
sure I'll hear about it :))

Mitch, this is incomplete, so you might want to wait until Robert fills
in the guts of the dither selection before incorporating it.  Any
changes will be in *_color_window.c.

Steve
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

[Gimp-print-devel] Open Discussion forum

[Robert L K. <rl...@al...>]

Somebody posted a request for a suggestion about which HP printer to
buy in the Open Discussion forum.  Could someone check that out and
get back to him?

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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

Re: [Gimp-print-devel] print.c

[Robert L K. <rl...@al...>]

   Date: Thu, 13 Apr 2000 19:20:34 -0700
   From: "S. Miller" <sm...@rn...>

   Michael Natterer wrote:
   > 
   > Yep, I'm aware of the problem. As we are in a development cycle, what
   > about registering 2 PDB functions, one for the old and one for the
   > new ui. When it comes to a release we will of course have to remove
   > the second one :)

   You mean 2 different plugins?  That should work, but seems ugly.  If its
   ok with Robert, I can live with it.  I have no idea how to go about it
   though.

Well, development is the time to do this.  I wouldn't want to go into
a release like that, but for development I have no problem.

As it happens, the reason I want the selectable dither algorithm stuff
is mostly so people can experiment, although there would be a bit more
reason to have that in a production release.

   For everyone's enlightenment (even if you don't use gnome), I am
   currently working on shifting the entire gui into a GtkNotebook.  It is
   fairly slow going, as I'm having to restructure the entire table based
   gui into multiple chunks.  I'm hoping that the result will allow printer
   specific additional notebook pages, as well as hide some detail from
   casual users.

Don't worry.  Time is one thing we have plenty of.  We'll do the
release when *we* think it's good and ready.  If there's one mistake I
don't want to make it's to rule out interesting and useful ideas in a
rush to get something out the door.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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

Re: [Gimp-print-devel] print.c

[S. M. <sm...@rn...>]

Michael Natterer wrote:
> 
> Yep, I'm aware of the problem. As we are in a development cycle, what
> about registering 2 PDB functions, one for the old and one for the
> new ui. When it comes to a release we will of course have to remove
> the second one :)
> 
> Gnu make doesn't take gcc's -D into account when it calculates the
> dpeendencies, that's evil (TM).
> 
> bye,
> --Mitch

You mean 2 different plugins?  That should work, but seems ugly.  If its
ok with Robert, I can live with it.  I have no idea how to go about it
though.

For everyone's enlightenment (even if you don't use gnome), I am
currently working on shifting the entire gui into a GtkNotebook.  It is
fairly slow going, as I'm having to restructure the entire table based
gui into multiple chunks.  I'm hoping that the result will allow printer
specific additional notebook pages, as well as hide some detail from
casual users.

As for the trademarked evil, are you sure?  I thought evil was
trademarked by Microsoft :)

Steve

-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

[Gimp-print-devel] Re: Gimp-print

[Robert L K. <rl...@al...>]

   Date: Thu, 13 Apr 2000 13:39:45 -0400
   From: James Moger <ja...@tr...>

   After trying out several of the different printing systems I have
   concluded that the gimp-print package gives me the highest quality for
   the printers I am testing with.  I am trying to choose a printing system
   for a project of mine - I've played with PDQ, lpd, CUPS, etc.  I really
   like the internal support for HP Laserjets and Deskjets you've got in
   your plug-in.  Is there an easy way to modify your source to make it a
   stand-alone program?  I downloaded the latest stable and latest devel
   release - I saw the Makefile.standalone - but that is not what I want,
   right?  The goal is to use your code almost like a Win print dialog.  At
   least for files.  Maybe it could be extended to include window handles
   or something.  Is this feasible or should I keep going with PDQ or lpd
   or whatever?

It is designed to work with other clients, but I wouldn't suggest that
approach.  The Epson driver is already buildable as a Ghostscript
driver, and I would suggest doing that with the PCL driver as well
(probably do a single unified driver for both, actually).  There's
already a PDQ description included; see the Ghost subdirectory for
information.

So what I'd suggest is bringing the PCL (and Canon) drivers into the
Ghostscript driver, and using that with PDQ or CUPS as your front
end.  Since the Epson driver's already done, it shouldn't be very hard
to fit the PCL driver into the same framework.  It's just a matter of
deciding how to do it.

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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

Re: [Gimp-print-devel] print.c

[Dave H. <da...@mi...>]

Michael Natterer wrote:
> 

[snip]

> Please do it.
> 

It has been done!

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

Re: [Gimp-print-devel] print.c

[Robert L K. <rl...@al...>]

   Date: Thu, 13 Apr 2000 14:12:08 +0200
   From: Michael Natterer <mit...@cs...>

   BTW, I'm about to commit stuff to gimp-print and I'm not quite sure
   about the project's ChangeLog policy.

   Where are the changes logged? The ChangeLog looke quite unused right
   now.

We've been sloppy about change logs per se.  The best thing for now is
to simply use a good cvs commit message.

Re: [Gimp-print-devel] Error compiling gimp-print

[Jean-Jacques de J. <jea...@hp...>]

Dave Hill wrote:
> 
> The current CVS will not compile with GIMP 1.0.4. I have some
> patches "ready to roll" to fix this, if it OK with the UI chaps
> to submit them.
> 
> Dave
> 
> --
> Dave Hill, Kempston, Bedford UK         da...@mi...
>                                 davehill at users.sourceforge.net
> Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!


OK, I installed gimp-1.1.19, and gimp-print compiled fine.

But now when I "make install", I get the following:

make[1]: Entering directory `/home/jj/print'
/bin/sh ./mkinstalldirs /usr/local/bin
  /usr/bin/install -c  unprint /usr/local/bin/unprint
  /usr/bin/install -c  escp2-weavetest /usr/local/bin/escp2-weavetest
  /usr/bin/install -c  pcl-unprint /usr/local/bin/pcl-unprint
/usr/bin/gimptool --install-admin-bin print
/usr/bin/install -c print /plug-ins/print
/usr/bin/install: cannot create regular file `/plug-ins/print': No such
file or directory
make[1]: *** [install-libexecPROGRAMS] Error 1
make[1]: Leaving directory `/home/jj/print'
make: *** [install-am] Error 2

JJJ

Re: [Gimp-print-devel] print.c

[Michael N. <mit...@cs...>]

"S. Miller" wrote:
> 
> I'm ready to commit some changes with the skeleton for selection of
> dither algorithms.  However, I ran into a slight problem with the
> changes for slection of gimp vs gtk gui code.  It appears that Mitsch
> added some switches based on whether you're compiling for gimp 1.0.x.
> The problem is that all of us are using 1.1.x and the gtk code is never
> used. I can get around this in my sandbox by changing the 2 "#ifndef
> GIMP_1_0" lines to "#ifdef GIMP_1_0", which then shifts the else to be
> true, and gtk stuff is used. But this will break the gimp code.  The
> switch needs to be done on both gimp 1.1 vs 1.0 as well as gimp vs
> standalone.  I tried to pass an argument in, but gnu make apparantly
> doesn't understand the -D flag.  I'm assuming here that we're delivering
> the gimp version with gimp and keeping the gtk version towards working
> the generalized solution.

Yep, I'm aware of the problem. As we are in a development cycle, what
about registering 2 PDB functions, one for the old and one for the
new ui. When it comes to a release we will of course have to remove
the second one :)

Gnu make doesn't take gcc's -D into account when it calculates the
dpeendencies, that's evil (TM).

bye,
--Mitch

Re: [Gimp-print-devel] print.c

[Michael N. <mit...@cs...>]

Dave Hill wrote:
> 
> Hi
> 
> The current defines in gtk*.c and gimp*.c don't work anyway, because
> the only definition of GIMP_1_0 is in print.c. To make them work
> this definition needs moving to print_gimp.h.

Eek, I've messed this up when adding the gimp_* files because I don't have
Gimp 1.0.x here, sorry.

> Also, in gtk*, the whole code should be surrounded by
> #ifdef GIMP_1_0, otherwise you will be compiling both sets for
> gimp 1.1.x.

Also true.

> The reason I note this is because I am still using gimp 1.0.4,
> I haven't "upgraded" to the development version.
> 
> I have a set of patches ready to submit for these changes,
> also to fix a couple of minor bugs:-

Please do it.

BTW, I'm about to commit stuff to gimp-print and I'm not quite sure
about the project's ChangeLog policy.

Where are the changes logged? The ChangeLog looke quite unused right
now.

bye,
--Mitch

[Gimp-print-devel] Experimental stuff

[Robert L K. <rl...@al...>]

I've put some new dithering stuff in the dither2-branch branch that
I'd like people to try and comment on.  This uses a hybrid of
Floyd-Steinberg and ordered dither.  It should work much better with
variable dot size printers.  Although I've only tested it on my Stylus
Photo EX, it uses the same principles on that printer (different ink
colors) as on printers with variable dot sizes.

It seems to be smoother, but more banding is visible.  I think I need
a matrix that is not a power of 2 in dimension to get rid of the
banding.

I've been working on it off and on for about a month now.  Thanks to
Thomas Tonino for lots of discussion on this topic.

To try this out:

cvs update -r dither2-branch

-- 
Robert Krawitz <rl...@al...>      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 lp...@uu...
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

[Gimp-print-devel] Fwd: [gimp-print - Open Discussion] willing to cut a deal

[Karl H. K. <kh...@kh...>]

Did somebody answer to this request? I just tried to access
sourceforge.net without any success. I don't know if the 
problem is on sourceforge or on my side of the net (we are
in the middle of a major network up/down/side-grade right
now). 

Karl Heinz

Forwarded From: no...@so...

> Read and respond to this message at: 
> http://sourceforge.net/forum/message.php?msg_id=21566
> By: tidd
> 
> I am running Caldera OpenLinux 2.3 exclusively on my PC.  I have an
Epson Stylus Color 900, which I can't seem to get to print anything
but plain ascii text.  I would like to make a deal.  I saw on this
site that my printer requires testing.  I would like to trade testing
on my printer for having my hand held through making the printer work
at all.  As an added bonus, I have a masters degree in Machine Vision,
so I know a little something about image processing.  I would also
like to offer my services in whatever capacity I can be of assistance.
 

Re: [Gimp-print-devel] Error compiling gimp-print

[Dave H. <da...@mi...>]

The current CVS will not compile with GIMP 1.0.4. I have some
patches "ready to roll" to fix this, if it OK with the UI chaps
to submit them.

Dave

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

Re: [Gimp-print-devel] print.c

[Dave H. <da...@mi...>]

Hi

The current defines in gtk*.c and gimp*.c don't work anyway, because
the only definition of GIMP_1_0 is in print.c. To make them work
this definition needs moving to print_gimp.h.

Also, in gtk*, the whole code should be surrounded by
#ifdef GIMP_1_0, otherwise you will be compiling both sets for
gimp 1.1.x.

The reason I note this is because I am still using gimp 1.0.4,
I haven't "upgraded" to the development version.

I have a set of patches ready to submit for these changes,
also to fix a couple of minor bugs:-

"Adjust" is spelt wrong in gtk_color_window.c

The PPD file box and browser button appear when they shouldn't.

If you select a printer from the list and select an option for
it (e.g. media source), then select a printer with no media
source selections, the previous source is used instead of
it being reset. This applies to media_types, media_sources,
ink_types and resolutions.

Dave
-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
				davehill at users.sourceforge.net
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[Gimp-print-devel] Error compiling gimp-print

[Jean-Jacques de J. <jea...@hp...>]

When I compile the latest cvs, I get:

gcc -DPACKAGE=\"print\" -DVERSION=\"3.1.2\" -DYYTEXT_POINTER=1
-DSTDC_HEADERS=1 -DHAVE_UNISTD_H=1 -DRETSIGTYPE=void  -I. -I. 
-I.-I/usr/X11R6/include -I/usr/lib/glib/include
-I/usr/local/include -DLOCALEDIR=\"""\" -Wall                        
-DLPR_COMMAND=\"/usr/bin/lpr\" -g -O2 -c gimp_color_window.c
gimp_color_window.c: In function `gimp_create_color_adjust_window':
gimp_color_window.c:77: warning: implicit declaration of function
`gimp_dialog_new'
gimp_color_window.c:78: `gimp_plugin_help_func' undeclared (first use in
this function)
gimp_color_window.c:78: (Each undeclared identifier is reported only
once
gimp_color_window.c:78: for each function it appears in.)
gimp_color_window.c:85: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:100: warning: implicit declaration of function
`gimp_scale_entry_new'
gimp_color_window.c:104: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:118: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:132: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:146: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:160: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:174: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:188: warning: assignment makes pointer from integer
without a cast
gimp_color_window.c:202: warning: assignment makes pointer from integer
without a cast
make: *** [gimp_color_window.o] Error 1

This happens on a Mandrake 6.1 or 7.0 distro, with gimp-1.0.4.

JJJ

[Gimp-print-devel] print.c

[S. M. <sm...@rn...>]

I'm ready to commit some changes with the skeleton for selection of
dither algorithms.  However, I ran into a slight problem with the
changes for slection of gimp vs gtk gui code.  It appears that Mitsch
added some switches based on whether you're compiling for gimp 1.0.x. 
The problem is that all of us are using 1.1.x and the gtk code is never
used. I can get around this in my sandbox by changing the 2 "#ifndef
GIMP_1_0" lines to "#ifdef GIMP_1_0", which then shifts the else to be
true, and gtk stuff is used. But this will break the gimp code.  The
switch needs to be done on both gimp 1.1 vs 1.0 as well as gimp vs
standalone.  I tried to pass an argument in, but gnu make apparantly
doesn't understand the -D flag.  I'm assuming here that we're delivering
the gimp version with gimp and keeping the gtk version towards working
the generalized solution.

I'm looking for a solution to this - I don't have a good answer. 
Robert, the changes I made are to print.c (adding some dither related
variables) and the selection menu and callbacks in gtk_color_window.c -
if you want I can just email them to you.  You will need to add a
function in print.c or somewhere to fill in the dither name array and
then put whatever code you need in the callback to select the dither
function.

Steve
-- 
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------