
Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

Gimp Traffic #27 For 15 Jan 2001

By Cris Flagg

The GIMP Homepage | The GIMP News Archive | The GIMP Mailing Lists | The GIMP FAQ

Table Of Contents

Printer-Friendly Format
Text Format
XML Source
Mailing List Stats For This Week

Threads Covered

1.	28 Dec 2000 - 1 Jan 2001	(4 posts)	Using GIMP Non-Interactively
2.	3 Jan 2001 - 5 Jan 2001	(14 posts)	GTK-Perl And Windows
3.	4 Jan 2001	(1 post)	GIMP 1.2.0 RPM Files
4.	6 Jan 2001 - 8 Jan 2001	(4 posts)	Suggestions For GIMP
5.	6 Jan 2001	(4 posts)	MDI Interface For GIMP
6.	7 Jan 2001 - 8 Jan 2001	(6 posts)	Submitting Patches
7.	8 Jan 2001 - 9 Jan 2001	(2 posts)	Histogram Tool

Mailing List Stats For This Week

We looked at 63 posts in 216K.

There were 38 different contributors. 9 posted more than once. 8 posted last week too.

The top posters of the week were:

7 posts in 29K by Albert Chin-A-Young <china@thewrittenword.com>
7 posts in 18K by Kevin Cozens <kcozens@interlog.com>
4 posts in 21K by Marco Lamberto <lm@geocities.com>
4 posts in 12K by Marc Lehmann <pcg@goof.com>
3 posts in 7K by Sven Neumann <sven@gimp.org>
Full Stats

1. Using GIMP Non-Interactively

28 Dec 2000 - 1 Jan 2001 (4 posts) Archive Link: "gimp 1.2.0--a few questions"

People: Chetan Dhavse, Marc Lehmann,

Chetan Dhavse upgraded from 1.1.04 to 1.2.0 and had two questions, the first of which was:

for the information my old programs "used Gimp and Gimp::Fu"
The same programs do not run on newer 1.2.0. I had to change it to
use Gimp qw(:auto __ N_);
use Gimp::Fu;

[...]

and then I keep getting the following warnings
Subroutine gimp_text_get_extents_fontname redefined at /opt/other/src/perl-5.6.0/lib/site_perl/5.6.0/i686-linux/Gimp.pm line 539.
Subroutine gimp_bucket_fill redefined at /opt/other/src/perl-5.6.0/lib/site_perl/5.6.0/i686-linux/Gimp.pm line 539.

Marc Lehmann thought this was strange and thought the problem may be in the script itself. He asked Chetan to post a copy of the scripts, which Chetan did. There were no more posts regarding this problem

Chetan had a second question about "plug_in_autocrop"

The plug in "plug_in_autocrop" gives the following error if I use
plug_in_autocrop(1,$img,$layer); (as mentioned in DB browers)
rot: argument type Gimp::Drawable, Gimp::Layer or Gimp::Channel expected (not Gimp::Image) at ./rot line 32 (DIE)
but works fine if I use plug_in_autocrop(1,$layer);

Marc Lehmann pointed out that it was better to use RUN_NONINTERACTIVE or RUN_INTERACTIVE than 1 or 0 because 1 is a valid image id. He suggested using " plug_in_autocrop($img,$layer); plug_in_autocrop($layer); or even $layer->autocrop; " He also stated " This could also solve your problems above, since 5.6.0 is rather broken with regards to error handling (this has been fixed in later snapshots, so best use 5.005_03 or a current perl snapshot if you want sensible error reporting) so the above could just be the effect of a runtime error that doers not get reported but instead garbles perl's internal state. "

There were no more posts to this thread.

2. GTK-Perl And Windows

3 Jan 2001 - 5 Jan 2001 (14 posts) Archive Link: "perl script in gimp for Windows : is it possible ?"

People: Mark Lehmann, Marc Lehmann, Tor Lillqvsit, Tor Lillqvist, Tor Lillvqist, Hans Brauer,

Eric Coutier asked if it was possible to run a perl script in GIMP for Windows.Marc Lehmann didn't think anyone had attempted to compile GIMP-perl. He said "I am quite sure it will not compile out of the box, but I only expect a relatively small number of unixisms in the Makefile to make problems." Tor Lillqvist had tried this before and thought the first hurdle was porting the GIMP-Perl module.

Peter Dove suggested looking at the MKS Toolkit perl distribution

Wandered Inn suggested checking out UWin from att.research.

Marc Lehmann saw 2 problems, GTK (which would require gygwin) and GIMP-perl (which "is not that demanding, yet it still requires being able to successfully run a configure fragment. If we could hardwire the configuration somehow, the makefile itself should not be very dependent on unix utilities." )

Marc thought cygwin-ported perl would be the easiest because the makefile was unix-like and activestate perl would be the most difficult since it is ported more closely to windows. Tor Lillqvist tried this again and found some problems:

What Perl to use? I decided to go the easy way, and use ActiveState's prebuilt one. Let's see where that takes us.
Makefile.PL wants to use gtk-config. No such on Win32. (How could there be one? On Win32, people typically don't build GTK+ themselves, but fetch the headers and libraries, and just unzips them in some suitable location. Compare to Unix, where people (or their sysadmins) either configure GTK+ themselves, and thus decide where it will be installed, or use prebuilt package that drops stuff into fixed locations. Of course, I could start requiring that the headers and import libs are placed in a fixed location (C:\gnu\include, C:\gnu\lib for instance.)
Anyway, even if one hacks a suitable gtk-config shell script, it will be called from a Perl running on pure Windows, and system('gtk-config --libs') won't work (there is nothing to recognise that the (extension-less) gtk-config file somewhere in PATH is executable, and needs interpretation by a shell), and one thus needs a wrapper .bat file, or even an .exe, to start a (cygwin) bash or sh to actually interpret the gtk-config shell script. Hmm. Some issues passing parameters to the shell script through the command.com (or cmd.exe) -interpreted .bat file.

Marc Lehmann thought that most people building GIMP would be able to build GTK as well. He thought gtk-perl would require cygwin unix-like functionality. Tor Lillqvist said " The problem is producing a glib-config or gtk-config for people who download the headers and prebuilt libs (in a zipfile), and install them in some random place, and then would like to build some application." Marc argued that building a downloadable binary for windows should be possible, but was beginning to see the win32 problems. Tor pointed out that a potential developer could using the h:\ or a complex directory such as "\\redmond42\lusers\b\billgates." . Paolo Molaro agreed that cygwin would be the easiest route. Paolo also offered to integrate any patches generated if they are based against the cvs HEAD.

Tor Lillqvist also posted the problems:

While hacking that gtk-config script, for completeness's sake add a --toolset option to choose between mingw (gcc) and MSVC (cl). They both understand the same syntax for -I switches, but for libs, gcc uses the normal Unix-like -LX:/xxx/xxx -lxxx, while cl wants just the .lib file names X:/xxx/xxx/xxx.lib .
ActiveState's Perl is built with MSVC. Its MakeMaker thus produces a Makefile for nmake, that uses cl to compile and link to link. Oh well, that is not so bad in itself, I have MSVC available at work, and, ehh, I might have a copy at home also.

Marc Lehmann thought this problem was unsolvable if the compiler was changed due to autodetect stuff going wrong. he thought the key was to use the same compiler for gtk+, gimp, and gtk-perl. Tor didn't think this should matter since " Nothing prevents mixing MSVC- and gcc-compiled DLLs and EXEs of GLib, GTK+. I don't think Gtk-Perl or Gimp-Perl should need to care either." Marc mentioned that there may be command line format issues with unix-like and win32 compilers. He admitted "What's even worse is the config-trickery I do in the makefile to increase the chances of libtool and perl coexisting. It *is* a crual world, even under unix...." Hans Brauer said "Mixing allocators between binaries from different compiler (c-runtimes) does no good as well ... The common case to build gtk+, etc. on win32 are hand-written makefiles. "

Tor Lillqvist also posted the problems:

However the Makefile.PL in Gtk-Perl assumes that the Makefile will be run on a Unix-like system, and needs some tweaking. Oh well, not anything impossible, change to use $^X, $Config{obj_ext}, $Config{exe_ext) etc as appropriate. Also change not to generate Unix shell -specific commands (test -f ... && ...). Also, the command line syntax for cl is not Unix-like, no -o outputfile switch.
Glib on Win32 has an emulation for the dirent functions, defines the DIR struct, and #defines opendir etc to g_win32_opendir etc. Perl has its own emulation for these. Hmm. To avoid clashes will have to include <glib.h> early in the Gtk-Perl .xs files, do some ugly #defines and stuff to hide the GLib versions. Unfortunately there are lots of those .xs files that need to have the same stuff inserted. Oh well, just manual work.

Marc Lehmann said the better option would be to make glib compilable against perl. He was unsure as to the current state of activestate's perl, in regards to compatibility and compiler requirements. Tor commented that direct emulation in GLib had caused problems before and stated "I think it was wrong to include dirent emulation in libmingw32, and a <dirent.h> header, as that breaks being able to compile the same code with either gcc or MSVC."

Tor Lillqvist posted a final problem:

GdkTypes.h in Gtk-Perl clashes with gdktypes.h in GTK+. (Case-insensitive filenames.) Have to rename it to GdkTypesPerl.h, for instance. Rename also GtkTypes.h to GtkTypesPerl.h for stylistic reasons.
Some X11-backend specific stuff present in Gtk-Perl. Have to #ifdef those out, but in a way that is still compatible with GTK+ 1.2, which didn't have several backends, and doesn't define GDK_WINDOWING_X11. Gtk-Perl also uses some GDK functions that don't exist any longer.

At this point I bailed out again... I have better things to do, like, eh, sleep?

Marc Lehmann thought the gtk-perl people would be interested any patch generated from the discussion, even if it only solved part of the problem. He noticed many unix-like things in the gimp-perl makefile, but they were limited to installation. He closed by saying "Even trying to build and fail (and you did more) should be very helpful to them I think. Just as I would expect that somebody whotried to build gimp-perl on win32 would end up saying "it bails out during Makefile.PL because it calls ./configure", and I would be happy with that ;)" Tor Lillqvist assumed a working Gtk-Perl was a prerequisite to GIMP-Perl. Tor pointed out "One problem I can think of right now is that the gimp modules want to use entry points in the gimp executable, and for that to work on Win32 you must mark those entry points for export when building the exe. I.e. build the exe kinda like you would build a DLL. There is no mechanism in auto* or libtool to handle that, I think. " Marc thought this would be a problem since the next version of the GIMP makes extensive use of modules.

Tor agreed that it seemed easier to use a perl running on cygwin to generate makefiles for GTK-Perl and GIMP-Perl. Marc agreed that Perl should be ported to mingw32, expect the windows environment and a unix build environment. Tor also pointed out that cygwin was an operating system, in a way, which would lead to cross-compilation (bad for Perl modules). Marc thought mingw32 + cygwin should work.

Hans Brauer mentioned he has ported pygtk and pygimp, which are located at http://hans.breuer.org/ports

Paolo Molaro requested any patches generated from the discussion.

There were no more posts to this thread.

3. GIMP 1.2.0 RPM Files

4 Jan 2001 (1 post) Archive Link: "GIMP 1.2.0 RPM files"

People: Kevin Cozens,

Kevin Cozens uploaded GIMP 1.2.0 RPM files to http://fantasia.galaxynet.com/~casey/gimp/v1.2/
He commented " You will find both .src.rpm files and .i386.rpm files. These files were created using the original 1.2.0 tar.gz file. The binary RPM files were built on a Redhat 6.2 machine. At the above site is a .tar.gz file which has the update spec file and two patch files for those who like to roll their own."

4. Suggestions For GIMP

6 Jan 2001 - 8 Jan 2001 (4 posts) Archive Link: "Suggestions for gimp"

People: Sven Neumann, Sven Neumann , , Daniel Egger, Austin Donnelly

Orson Jones had a few ideas for the GIMP.

Select Within: Adds to the selection everything that is fully contained within the selection (An option for this) Leave large areas unselected (checkbox with slider for minimum large size)
Select Gradient: This is hard to explain. It acts like the magic wand, but it keeps going as long as there is a smooth change. It doesn't care about the originating pixel, just as long as there is little change from pixel to pixel, it will keep going.
WrapAround: This would be VERY useful when creating backgrounds. When you (paint|select|etc.) near an edge, effects are automatically applied on the other side of the image.
Background Remover: Used for defringing. Makes an edge partially transparent and removes the background color from the semi-transparent area. (Imagine a black area blurring onto a white background) In this example the gray area would be made black, and the transparency would be adjusted to give the same appearance of gray

Sven Neumann pointed out " This is exactly what the "Color To Alpha" plug-in shipped with Gimp-1.2 does." Austin Donnelly posted that "Select Within" was like his pre-christmas patch to add a "tighten selection" item to the selection menu.

Daniel Egger suggested that bugtracker would be a good place to track this sort of thing.

There were no more posts to this discussion

5. MDI Interface For GIMP

6 Jan 2001 (4 posts) Archive Link: "Optional background window ?"

People: Guillermo S. Romero, , Steinar H. Gunderson

Matts Kivik asked for an MDI interface to gimp, citing the learning curve for photoshop users. Steinar H. Gunderson thought this would be a big task under GTK+. Guillermo S. Romero suggested opening an Xnest server with the GIMP launched inside. He also suggested using a desktop to serve the same function, and finished by saying "Of course, I guess patches are welcomed. :]"

6. Submitting Patches

7 Jan 2001 - 8 Jan 2001 (6 posts) Archive Link: "Submitting Patches"

People: , Sven Neumann, Austin Donnelly

Oliver posted a unified diff against the current CVS (v1.3 source) for "dodge and burn" and asked the best way to submit patches. Sven Neumann said short patches may be submitted though the gimp-developer list or uploaded to ftp.gimp.org. He reminded oliver to update cvs before creating a diff, since his patch reverted a change to the preferences dialog. Austin Donnelly suggested this info be put in the HACKING file so it didn't need to be repeated. Sven applied the patch and asked Oliver to email his full name so it could be added to the changelog.

7. Histogram Tool

8 Jan 2001 - 9 Jan 2001 (2 posts) Archive Link: "Histogram patch"

People: Nick Lamb, , Sven Neumann

Nick Lamb suggested a potential patch for the histogram tool in 1.2.x to address several problems in the 1.2.0 release tool. He suggested: "

Don't say "Blue" when you're displaying "Value" etc.
Give accurate stats FOR THE SELECTED CHANNEL, not for Value
Try to survive stuff changing underneath us
# of pixels is a (large) integer => %1.f not %8.1f in display

" Sven Neumann said the patch was available at ftp://ftp.gimp.org/pub/gimp/patches

Sharon And Joy

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech