gimp.m4 problem
If the initial attempt to run the test program fails, the smaller
program that is then compiled and linked to try to diagnose the error
needs to have PLUG_IN_INFO so that it will link properly.
--- /usr/local/Libraries/share/aclocal/gimp.m4 Fri Feb 11 18:04:05 2000
+++ /usr/local/share/aclocal/gimp.m4Fri Feb 11 22:34:47 2000
@@ -134,6 +134,13 @@
AC_TRY_LINK([
#include
#include
+GPlugInInfoPLUG_IN_INFO = /* Plug-in information */
+{
+ NULL,/* init_proc */
+ NULL,/* quit_proc */
+ NULL, /* query_proc */
+ NULL, /* run_proc */
+};
], [ return 0; ],
[ echo "*** The test program compiled, but did not run. This usually means"
echo "*** that the run-time linker is not finding GIMP or finding the wrong"
Patch for print 3.0.6
I'm having to release a Print 3.0.6 due to a fairly serious bug found
by Panos Katsaloulis. The specific bug is that monochrome printing in
grayscale does not work properly. The patch is enclosed below.
cvs diff: Diffing .
Index: README
===
RCS file: /src/repository/rlk/print/README,v
retrieving revision 1.6.2.2
retrieving revision 1.6.2.3
diff -u -r1.6.2.2 -r1.6.2.3
--- README 2000/01/13 23:41:34 1.6.2.2
+++ README 2000/02/11 23:44:39 1.6.2.3
@@ -1,4 +1,4 @@
-Print plugin for the Gimp. Version 3.0.5 by Robert Krawitz
+Print plugin for the Gimp. Version 3.0.6 by Robert Krawitz
<[EMAIL PROTECTED]> based on version 2.0 by Michael Sweet
<[EMAIL PROTECTED]>.
Index: print-escp2.c
===
RCS file: /src/repository/rlk/print/print-escp2.c,v
retrieving revision 1.39.2.1
retrieving revision 1.39.2.2
diff -u -r1.39.2.1 -r1.39.2.2
--- print-escp2.c 2000/01/13 03:32:34 1.39.2.1
+++ print-escp2.c 2000/02/11 23:44:39 1.39.2.2
@@ -1,5 +1,5 @@
/*
- * "$Id: print-escp2.c,v 1.39.2.1 2000/01/13 03:32:34 rlk Exp $"
+ * "$Id: print-escp2.c,v 1.39.2.2 2000/02/11 23:44:39 rlk Exp $"
*
* Print plug-in EPSON ESC/P2 driver for the GIMP.
*
@@ -31,6 +31,15 @@
* Revision History:
*
* $Log: print-escp2.c,v $
+ * Revision 1.39.2.2 2000/02/11 23:44:39 rlk
+ * 3.0.6
+ *
+ * Revision 1.13 2000/01/26 16:00:47 neo
+ * updated print plug-in
+ *
+ *
+ * --Sven
+ *
* Revision 1.39.2.1 2000/01/13 03:32:34 rlk
* silliness
*
@@ -1040,7 +1049,11 @@
if (output_type == OUTPUT_GRAY)
{
dither_black(out, x, image_height, out_width, black);
-escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
+ if (use_softweave)
+ escp2_write_weave(prn, length, ydpi, model, out_width, left, xdpi,
+ cyan, magenta, yellow, black, lcyan, lmagenta);
+ else
+ escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
}
else if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))
{
@@ -1128,7 +1141,11 @@
if (output_type == OUTPUT_GRAY)
{
dither_black(out, y, image_width, out_width, black);
-escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
+ if (use_softweave)
+ escp2_write_weave(prn, length, ydpi, model, out_width, left, xdpi,
+ cyan, magenta, yellow, black, lcyan, lmagenta);
+ else
+ escp2_write(prn, black, length, 0, 0, ydpi, model, out_width, left);
}
else if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))
{
@@ -1564,6 +1581,7 @@
/* quality) */
static int vmod; /* Number of banks of passes */
static int oversample; /* Excess precision per row */
+static int is_monochrome = 0;
/*
* Mapping between color and linear index. The colors are
@@ -1867,7 +1885,7 @@
{
for (j = 0; j < 6; j++)
{
- if (lineoffs[k].v[j] == 0)
+ if (lineoffs[k].v[j] == 0 || (j > 0 && is_monochrome))
continue;
if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))
fprintf(prn, "\033(r\002%c%c%c", 0, densities[j], colors[j]);
@@ -2145,6 +2163,10 @@
cols[3] = y;
cols[4] = M;
cols[5] = C;
+ if (!c)
+is_monochrome = 1;
+ else
+is_monochrome = 0;
initialize_row(lineno, width);
@@ -2201,5 +2223,5 @@
}
/*
- * End of "$Id: print-escp2.c,v 1.39.2.1 2000/01/13 03:32:34 rlk Exp $".
+ * End of "$Id: print-escp2.c,v 1.39.2.2 2000/02/11 23:44:39 rlk Exp $".
*/
Index: print-pcl.c
===
RCS file: /src/repository/rlk/print/print-pcl.c,v
retrieving revision 1.14
retrieving revision 1.14.2.1
diff -u -r1.14 -r1.14.2.1
--- print-pcl.c 2000/01/08 23:30:56 1.14
+++ print-pcl.c 2000/01/15 14:33:02 1.14.2.1
@@ -1,5 +1,5 @@
/*
- * "$Id: print-pcl.c,v 1.14 2000/01/08 23:30:56 rlk Exp $"
+ * "$Id: print-pcl.c,v 1.14.2.1 2000/01/15 14:33:02 rlk Exp $"
*
* Print plug-in HP PCL driver for the GIMP.
*
@@ -32,6 +32,9 @@
* Revision History:
*
* $Log: print-pcl.c,v $
+ * Revision 1.14.2.1 2000/01/15 14:33:02 rlk
+ * PCL and Gimp 1.0 patches from Dave Hill
+ *
* Revision 1.14 2000/01/08 23:30:56 rlk
* Y2K copyright
*
@@ -426,6 +429,7 @@
char *resolution = v->resolution;
char *media_size = v->media_size;
char *media_type = v->media_type;
+ char *media_source = v->media_source;
int output_type = v->output_type;
int orientation = v->orientation;
floatscaling = v->scaling;
@@ -687,15 +691,15 @@
else if (strcmp(media_type, "Transparency") == 0)
fputs("\033&l4M", prn);
-
Re: An experiment (was Re: Move help menu item...)
Raphael Quinet wrote: > 1. Use WM hints to ensure that the toolbox has a minimum width. This ... > 2. Try to take corrective measures in the Gimp when it detects that ... > 3. Make it possible to split the toolbox in several independent ... > 4. Use some tricks in Gtk to make sure that the full menu bar pops out Why not let the menu items wrap to next line? It might not be possible with Gtk+ now, but it would certainly solve the problem. This is how MS windows behave, though :-) Example: -- |File| |Xtns| |Help| -- Edheldil
ANNOUNCE: GIMP 1.1.17
1.1.17 is out there. Grab it at: ftp://ftp.gimp.org/pub/gimp/unstable/v1.1.17/ The usual cadre of bugfixes is there, plus a nifty new splash from Raphael Quinet. -Yosh
Re: Toolbox layout and Help menu
On Fri, 11 Feb 2000, Sven Neumann wrote: > Alternatively we can of course merge all menus into one GIMP menu... It seems like this is really the only reasonable option -- I think that there should be a 'menu' spot in the tools, like the top-left menu in the image windows, since the toolbar is frequently too thin for the menus anyway (vertical layout, try using a large font in your gtk theme sometime...) and if it's not (horizontal layout), then the menubar is taking up far too much screen real estate for no reason. I think that a menubar on that window looks dumb... since it is essentially a palette. --- Even if you can deceive people about a product through misleading statements, sooner or later the product will speak for itself. - Hajime Karatsu
Re: Toolbox layout and Help menu
> Loosing access to a menu may be acceptable to you, but I think it is > in no way acceptable for a program that wants to reach a larger audience. > I see the bugreports coming in daily. Additionally I don't know how the > color-selector should fit into a one-column layout. > In other word: unacceptable for the masses, but you may always change the > 2 to a 1 in the spinbutton creator for your own personal pleasure. > > Alternatively we can of course merge all menus into one GIMP menu... What about the possibilitie of a tear off menu a-la gnome? Would this require all the gnome libs or can it be implemented in straight gtk? This way the user has the option of a thin toolbar and a mushed menu or a thin toolbar and a floating menu. Or even better, have the toolbar automatically detach when the width of the toobox gets below a certain width? Ok, not a great idea but something to throw into the stew. Regards, alan -- Arcterex -=|=- [EMAIL PROTECTED] -=|=- http://arcterex.ufies.org '... I was worried they were going to say "you don't have enough LSD in your system to do UNIX programming."' -- Paul Tomblin in a.s.r
Re: Toolbox layout and Help menu
Hi, > I did not ignore the menu problem. If the "Help" bug is fixed (it is > a one-line change in app/menu.c to make it last-from-left), then only > the "File" menu is visible. But when I work with very large images, I > do not need the "Xtns" menu at all, so I can live without it until I > finish working on full-screen images and go back to a more traditional > layout for the Gimp toolbox. > > That being said, I also like the columns-spinbutton idea, as long as > the minimum is 1 column. I agree with the other parts of your > message, and with your suggestion to move the Measure tool in the View > menu or Info window. Loosing access to a menu may be acceptable to you, but I think it is in no way acceptable for a program that wants to reach a larger audience. I see the bugreports coming in daily. Additionally I don't know how the color-selector should fit into a one-column layout. In other word: unacceptable for the masses, but you may always change the 2 to a 1 in the spinbutton creator for your own personal pleasure. Alternatively we can of course merge all menus into one GIMP menu... Salut, Sven
Re: Toolbox layout and Help menu
On Fri, 11 Feb 2000, Sven Neumann <[EMAIL PROTECTED]> wrote: > Your list looked interesting. But, you seem to ignore the menu problem. > IMHO 2 columns is the absolute minimum since even then get problems with > the Help menu. If we'd allow less than 2 columns, not even Xtns will be > accesible any longer. Hey, don't prevent me from using one of my favourite layouts! :-) Really, having all icons on a single column is quite useful sometimes. As I mentioned in my previous message, this fits perfectly on a Sun screen (1152x900) because the height of the single-column toolbox is 880 pixels + the WM title. And since it is so thin, I can configure my WM to make the Gimp toolbox appear on all workspaces. I like this when I work with large images and I put one very large window in each workspace. I did not ignore the menu problem. If the "Help" bug is fixed (it is a one-line change in app/menu.c to make it last-from-left), then only the "File" menu is visible. But when I work with very large images, I do not need the "Xtns" menu at all, so I can live without it until I finish working on full-screen images and go back to a more traditional layout for the Gimp toolbox. That being said, I also like the columns-spinbutton idea, as long as the minimum is 1 column. I agree with the other parts of your message, and with your suggestion to move the Measure tool in the View menu or Info window. -Raphael
Re: Toolbox layout and Help menu (again)
> > Just to clarify, in my prev msg when refering to the selectors I was > > refering to the pattern/gradient/brush one > > ... which can be turned off via a preferences option already, Bah... must have slipped in w/o me being consulted :) Thanks for the pointer. alan... in desparate need of his morning quad-damage mocha -- Arcterex -=|=- [EMAIL PROTECTED] -=|=- http://arcterex.ufies.org '... I was worried they were going to say "you don't have enough LSD in your system to do UNIX programming."' -- Paul Tomblin in a.s.r
Re: Toolbox layout and Help menu
> Sorry, but I disagree. IMHO, there are more than two useful layouts. > Maybe I am sick or strange or something, but actually I use different > layouts for the toolbox on different computers, depending mostly on > the screen size and window manager used. That's why I actually send this mail at all. There are always people who can think of other ways of doing things... Your list looked interesting. But, you seem to ignore the menu problem. IMHO 2 columns is the absolute minimum since even then get problems with the Help menu. If we'd allow less than 2 columns, not even Xtns will be accesible any longer. Right now, I'm favorising the columns-spinbutton idea. With a minimum of 2, we'd have a bunch of useful layouts: the vertical group: 2 - 4: selectors packed vertically below the tools the square group: 5 - 8: selectors packed horizontally, but still below the tools the horizontal group: 9 - : selectors packed horizontally at the right side of the tools My absolute favourite solution would be to reduce the number of tools to 24 and only allow the numbers 2,3,4,6,8,12 in the spinbutton. However since the idea to merge Pencil and Paintbrush was smashed, all I can think of is either merging rectangular and ellipse select or moving the Measure tool out of the toolbox. Either put it into the View menu or make it accessible through the info-window. Salut, Sven
Re: Toolbox layout and Help menu
On Thu, 10 Feb 2000, Sven Neumann <[EMAIL PROTECTED]> wrote: > I'd vote for the following solution: Completely get rid of the interactive > resizing (since it obviously can't be fixed to work correctly) and offer > two alternative layouts (as described above) which are switchable from the > preferences dialog. The horizontal layout would have a Help menu and probably > even a Dialogs menu, while the vertical layout would add these as entries to > the File menu (or probably Xtns for the Help menu). Sorry, but I disagree. IMHO, there are more than two useful layouts. Maybe I am sick or strange or something, but actually I use different layouts for the toolbox on different computers, depending mostly on the screen size and window manager used. Here are the layouts that I found useful: * 86 x 376 3 columns of icons, selectors at the bottom. "Traditional" * 58 x 516 2 columns of icons, selectors at the bottom. A bit narrower and taller than the default layout. The selection tools are nicely sorted but it would look better without the last three icons (odd number). * 30 x 880 1 column of icons, selectors at the bottom. Everything on a single column, like some well-known office toolbar. This fits very nicely on the side of a Sun screen (1152x900) and leaves a lot of desktop space for large images. The pattern selector does not fit, but I can live without it since I can open the dialog from the menu when I need it (not often). * 170 x 262 6 columns of icons, selectors at the bottom. Similar to the old Gimp 0.54. All selection tools are on one row. As with all other layouts, it would even be nicer without the last three icons (170 x 234) and if the two selectors could be side-by-side (approx. 170 x 182 which would be almost square) Unfortunately, this layout is broken for the moment (1.1.16) because the selectors insist on going to the right. Why? * 289 x 68 3 columns of icons, selectors to the right. Current default. It wastes a bit more space than the previous one. * 516 x 81 2 rows of icons, selectors to the right. Useful if you like to have the toolbox near the top or bottom of the screen. * 880 x 53 1 row of icons, selectors to the right. Very handy if you have configured your window manager to display the toolbox without window title. The gradient selector does not fit, unfortunately. I did not like the layouts in which one selector was on the right and the other one at the bottom, because this wastes too much space. Please try to resize your Gimp toolbox to each of the sizes mentioned above (that was for 1.1.16), so that you can get an idea of their usefulness. I think that all of them can be useful, depending on how you work. The "traditional" layout is a good compromise in most cases (much better than the current default). But when I work with a single large image, I tend to prefer the "thin" layouts (everything on 1 or 2 rows or columns) and when I work with multiple small images, I prefer the "square" layouts (6 columns) because it is easier to locate the toolbox when multiple windows overlap. Choosing a vertical or horizontal layout is a matter of taste, but also depends on the window manager you are using (the size of the title bar and decoration varies). -Raphael
Re: Toolbox layout and Help menu
Hi, the discussion about the placing of the Help menu and shortening some of the names in the toolbox menubar made me wonder: I have a script that registers itself under "/MyScripts" and this creates a new menu-item "MyScripts" on the RIGHT side of the Help menu. Is this a small glitch (because Help should be the rightmost) or is registering under non-existing paths something that just accidentally works? (I would suspect the first is the case) Regards, Paul -- [EMAIL PROTECTED]
Re: An experiment (was Re: Move help menu item...)
One suggestion would be to not have the toolbox user-resizeable via the window manager at all, but to have in the Preferences a setting where you use a spinbutton to set the number of columns. If you start from, say, three columns, and keep increasing the number, at the point where the number of rows is less than the number of columns, the colour, brush, pattern and gradient selectors could automagically jump to be at the right side instead of the bottom. --tml
Re: Toolbox layout and Help menu (again)
> Just to clarify, in my prev msg when refering to the selectors I was > refering to the pattern/gradient/brush one ... which can be turned off via a preferences option already, Salut, Sven
Submitting Patches To The Gimp [Was Re: Some update to gimp sources]
Cosmin Truta wrote: > > It is the very first time when I try to send a patch to some GNU software, > so I don't know exactly how to do it. I sent this message to this List > now; if there is another, better way to contribute to contribute to GIMP, > I would like to know about it :-) First of all, thank you for the contribution. The current submission procedure for The Gimp is kind of in two different places. First, unstable developer distributions should have a file called HACKING; it contains the submission procedure [gimp/HACKING CVS-1.9 Jan 21 1999]: > Please submit patches to the [EMAIL PROTECTED] > mailing list. All kinds of contributions are accepted. Patches > that you wish to go into the distribution should also be uploaded > to ftp://ftp.gimp.org/incoming. Follow the rules there for > naming your patches. The ftp site accepts anonymous logins. The second half of the procedure is there: >> >> *** IMPORTANT NOTE (please read): >> >> If you put patches in the incoming directory you must follow the following >> format or I will just delete it. You must include the README with a >> minimum of what the patch does. The maintainers of the distributions >> will decide whether your patch will be applied in an upcoming release. >> >> (gtk|gimp)--.patch.gz >> (gtk|gimp)--.patch.README >> >> The "n" in the date indicates a unique number (starting from 0) >> of patches you uploaded that day. It should be 0, unless you >> upload more than one patch in the same day. >> >> Example: >> >> gtk-amundson-970801-0.patch.gz >> gtk-amundson-970801-0.patch.README >> >> We prefer greatly prefer unified diffs, if possible (diff -u for GNU diff) >> >> Once you upload *anything*, send the README to [EMAIL PROTECTED] >> >> I REPEAT. EVEN IF IT IS NOT A PATCH, SEND MAIL TO [EMAIL PROTECTED] >> with the README. EVERYTHING MUST HAVE A README! >> The README that you submit with the patch would detail what feature the patch introduces (note: we're in "feature freeze" at the moment) or what bug the patch fixes. Current known bugs are at http://bugs.gnome.org/db/pa/lgimp.html, so if you are patching a known bug, it helps to explicitly reference the bug number listed there. As an aside, if you encounter something that appears to be a bug, you can report the behavior at http://www.xach.com/gimp/news/bugreport.html If this seems a bit complicated, its because The Gimp is volunteer-supported with limited resources; the extra steps ensure that patches get noticed and handled. Be good, be well Garry Osgood
