Menu
▾
▴
gimp-print-devel
|
From: S. M. <sm...@rn...> - 2000-04-13 00:17:56
|
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 ------------------------------------------ |
|
From: Dave H. <da...@mi...> - 2000-04-13 11:08:24
|
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! |
|
From: Michael N. <mit...@cs...> - 2000-04-13 12:18:30
|
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 |
|
From: Robert L K. <rl...@al...> - 2000-04-13 13:14:39
|
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. |
|
From: Dave H. <da...@mi...> - 2000-04-13 19:20:33
|
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! |
|
From: Michael N. <mit...@cs...> - 2000-04-13 12:23:38
|
"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 |
|
From: S. M. <sm...@rn...> - 2000-04-14 02:21:09
|
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 ------------------------------------------ |
|
From: Robert L K. <rl...@al...> - 2000-04-14 02:40:03
|
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 |
|
From: S. M. <sm...@rn...> - 2000-04-14 03:37:45
|
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 ------------------------------------------ |
|
From: Michael N. <mit...@cs...> - 2000-04-14 11:35:38
|
"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 |
|
From: Robert L K. <rl...@al...> - 2000-04-14 12:08:21
|
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 |
|
From: S. M. <sm...@rn...> - 2000-04-14 19:46:24
|
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 ------------------------------------------ |
|
From: Michael N. <mit...@cs...> - 2000-04-14 11:19:31
|
"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 |
|
From: S. M. <sm...@rn...> - 2000-04-14 19:38:16
|
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 ------------------------------------------ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X