Re: How much longer do I have to put up with this shit? (This is NOT atroll)

2000-12-11 Thread Andrew J Fortune

LOL.

- Original Message -
From: "Lourens Veen" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, December 11, 2000 6:03 PM
Subject: Re: How much longer do I have to put up with this shit? (This is
NOT atroll)


 Hmm, never thought about gimp as a marital aid. Don't really feel
 inclined to use it that way either. But hey, if you want to, I'm not
 stopping you...

 Lourens :)

  * I see completely fucking useless tearoff menus on top of every

general seem to be designed to annoy the fuck out of the user

  * Configurable menu shortcut keys?  Who the fuck uses that?  I would

  fucking use "Quit", its E-X-I-T, not QUIT.  Look at any professional




Compiling GIMP

2000-08-02 Thread Andrew J Fortune

All,

I am trying to compile v1.1.24 of the GIMP, and I am getting many
problems -- as follows :

(1) I downloaded the file gimp-1.1.24.tar.gz;
(2) Created a temp directory;
(3) Copied the abovementioned tar.gz file into the temp directory;
(4) In the temp directory, I performed 'gunzip gimp-1.1.24.tar.gz';
(5) I then expanded the resulting tar file using 'tar gimp-1.1.24.tar'.
First problem - I was flooded with errors along the lines "Cannot chown to
uid 39902 gid 39902: Operation not permitted". Obviously a permissions
problem. What makes this more confusing is that I am logged on as root (I
always log on as root - a bit naughty maybe :)).
(6) In spite of these messages, a new folder gimp-1.1.24 was created,
containing a whole lot of files  - including a file called configure. So I
tried "configure" and "make", and got more error messages as follows :

[root@localhost gimp-1.1.24]# ./configure
./configure: re: command not found
./configure: line 502: syntax error near unexpected token `|s'
./configure: line 502: `|sed 's%/[^/][^/]*$%%'`'
[root@localhost gimp-1.1.24]# make
make: *** No targets.  Stop.
[root@localhost gimp-1.1.24]#

If this helps ... I am on Linux Mandrake v7, and have recently rebuilt this
system using the "customized" and "developers" options (hence, in theory, I
should have all of the associated development software that I need).

Can anyone suggest what is going on here ?

regards,
Andrew J Fortune




Perl Scripting

2000-07-29 Thread Andrew J Fortune



Hi all,

I currently have the latest developers' version of GIMP 
(v1.1.24). Can someone tell me if Perl scripting is still available ? (...there 
used to be any entry called "Perl-FU" on the Xtns menu).

I'd like to run a Perl script called perlotine that was 
written by Seth Burgess (http://registry.gimp.org/detailview.phtml?plugin=perlotine). 
This script achieves functionality that I have been looking for in GIMP for a 
while (i.e.slicing up an image and creating a group of gifs and an HTML file as 
output).

I can't find anywhere in the v1.1.24 version of GIMP menus 
that allow any use ofPerl scripts...can someone help ? 

(...as mentioned in a previous EMail, I am a newbie 
developer so please be gentle with me)

thanks,
Andrew J Fortune


Re: Perl Scripting

2000-07-29 Thread Andrew J Fortune

Hi Daniel,

I didn't say that the Perl scripting tool didn't work for me. I said that I
couldn't find it on GIMP's menus.

regards,
Andrew

- Original Message -
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, July 30, 2000 1:52 AM
Subject: Re: Perl Scripting


 On 30 Jul, Andrew J Fortune wrote:

  I currently have the latest developers' version of GIMP (v1.1.24). Can
  someone tell me if Perl scripting is still available ? (...there used
  to be any entry called "Perl-FU" on the Xtns menu).

  Perl normally should be there. But since the Perl plugin has never
  really worked (greetings Marc! :) it's not a big phenomenon that
  it doesn't work for you... Maybe the compiler gave up at the
  try to compile the plugin.

  If you tried to build it on your own, please have a look at the
  problem and then tell us some details. Otherwise just email the
  producer of your package for some explaination...

 --

 Servus,
Daniel






gtk_xmhtml_new ???

2000-04-18 Thread Andrew

What is gtk_xmhtml_new as compaired to gtkxmhtml ??? I'm confused.

I'm tring to compile gimp1.1.17 or 19 and I get this error, could you take a
little time to maybe explain what I need to do too get 'help'
pulldowns under gimp to operate? I'm not running the gnome desktop,
I'm using the Solaris CDE. SunOS5.6 the calls for netscape work but the
others don't??

I have built these with not much trouble GTK1.2.7 but gtk did not come
with libgtkhtml.so. I found gtkxmhtml-0.99.8?? and I compiled it just fine.
But I'm still having trouble with gimp configure. What libgtkxmhtml version
do I need?

below is a snipit from the configure.log file




configure:7445: checking for gtk_xmhtml_new in -lgtkxmhtml
configure:7464: gcc -o conftest -g -O2 -Wall   conftest.c -lgtkxmhtml   15
Undefined   first referenced
 symbol in file
gtk_entry_get_type  /home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_widget_realize  /home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_menu_append /home/ssd/templates/X11/lib/libgtkxmhtml.so
inflateEnd  /home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_widget_size_allocate/home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_entry_get_text  /home/ssd/templates/X11/lib/libgtkxmhtml.so
g_free  /home/ssd/templates/X11/lib/libgtkxmhtml.so
gdk_gc_set_font /home/ssd/templates/X11/lib/libgtkxmhtml.so
gdk_display /home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_widget_set_parent   /home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_file_selection_new  /home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_adjustment_get_type /home/ssd/templates/X11/lib/libgtkxmhtml.so

SNIPED

XpmCreateXpmImageFromData   /home/ssd/templates/X11/lib/libgtkxmhtml.so
gdk_root_parent /home/ssd/templates/X11/lib/libgtkxmhtml.so
gtk_scrolled_window_get_type/home/ssd/templates/X11/lib/libgtkxmhtml.so
ld: fatal: Symbol referencing errors. No output written to conftest
configure: failed program was:
#line 7453 "configure"
#include "confdefs.h"
/* Override any gcc2 internal prototype to avoid an error.  */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply.  */
char gtk_xmhtml_new();

int main() {
gtk_xmhtml_new()
; return 0; }



-- 
Andrew
   ,(   ,(   ,(   ,(   ,(   ,(   ,(   ,(   ,(   ,(   ,(  
`-'  `-'  `-'  `-'  `-'  `-'  `-'  `-'  `-'  `-'  `-'  `-
   ([EMAIL PROTECTED]) LockHeedMartinCorporation
([EMAIL PROTECTED]) VandenbergAFB,Ca



Re: Re: Performance

2000-02-03 Thread Andrew Kieschnick


On Thu, 3 Feb 2000, Martin Weber wrote:

 I use SuSE Linux 6.2. I have 128 MB RAM. I use the default values for
 tile caching. I have a EIDE IBM 6,4 GB and 10 GB. I use on both a 128
 MB partition as swap.

You should definitely increase your tile cache size from the default 10mb. 
It should help performance.


later,
Andrew Kieschnick







Re: Plugins at Sourceforge

2000-01-29 Thread Andrew Kieschnick


On Fri, 28 Jan 2000, Michael J. Hammel wrote:

 Thus spoke Marc Lehmann
  This is not at all a distribution issue. Linux is a *multi*-user system, so
  there is not much sense in tailoring the number of installed plug-ins to the
  needs of, say, the admin.
 
 Playing the devils advocate here, you could also say there is not much
 sense in tailoring it for a multi-user system if many of your users are
 using it on a single user box.  It's a reasonable argument, but there isn't
 a good answer for it.  From my point of view, Gimp is not a multi-user tool
 (even if it can run happily on multi-user systems) so should be packaged
 for single users.  University admins would probably argue otherwise.

Why yes, admins (like me) generally don't like things that are packaged
for single users. I suppose I don't care much about whatever packaging
changes are made, as long as I can still install the gimp (and plug-ins, 
and data, and whatever else) in some system-wide location, and as long as
users can still put extra bits and pieces in their .gimp directory. 

Being an admin lets me see a variety of interesting things, such as the
guy who ran gimp for the first time, and chose [Ignore] in the gimp
installation dialog, and then told me that gimp didn't work right. Why is
ignore an option? It doesn't seem to provide anything other than a quick
way to make the gimp not work; unless it has some sort of use, it should
probably be taken out.


later,
Andrew Kieschnick

















Re: GIMP Plug-ins for other Apps? - LGPL for some GIMP modules?

1999-11-14 Thread Andrew Kieschnick


On Sat, 13 Nov 1999 [EMAIL PROTECTED] wrote:

  Right, until now I haven't cared too much about those things...
  Sorry for any inconvenience

No inconvenience. Anyways, I came across as rather rude/insulting in that
last message; I didn't mean to - sorry about that. 

later,
Andrew





Re: GIMP Plug-ins for other Apps? - LGPL for some GIMP modules?

1999-11-12 Thread Andrew Kieschnick


On Fri, 12 Nov 1999 [EMAIL PROTECTED] wrote:

 On 11 Nov, Andrew Kieschnick wrote:
 
  Hmm, that sure as hell looks like an LGPL to me. I seriously doubt
  your copy of gimp is different than mine...
 
  LGPL stands for "Lesser GNU Public Licence". Now do me a favour and
  count the word lesser in this COPYING file... Then do this again 
  for the COPYING file in your Gtk distribution in the subdir gtk...

LGPL previously stood for "GNU Library General Public License". It was
changed to be the "Lesser GNU Public License" at some point not all that
long ago.

Read http://www.gnu.org/philosophy/why-not-lgpl.html if you'd like to know
why its name was changed.

LGPL version 2 is the GNU Library General Public License.
LGPL version 2.1 is the Lesser GNU Public License.

The COPYING file in libgimp is the LGPL, version 2.
The COPYING file in gtk+-1.2.6 is also the LGPL, version 2.

Its becoming obvious to me that you just don't know what you're talking
about.

later,
Andrew








Re: GIMP Plug-ins for other Apps? - LGPL for some GIMP modules?

1999-11-11 Thread Andrew Kieschnick


On Thu, 11 Nov 1999 [EMAIL PROTECTED] wrote:

 On  9 Nov, Andrew Kieschnick wrote:
 
  libgimp and libgimpui are LGPLed, so that isn't a problem.
 
  Really? Not mine
  Serious: If it'd be LPGLed it would have had such a header in every
  source file and in the COPYING file which isn't the case...

beelzebub:~$ head ~/gimp/libgimp/COPYING
  GNU LIBRARY GENERAL PUBLIC LICENSE
   Version 2, June 1991

 Copyright (C) 1991 Free Software Foundation, Inc.
59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

[This is the first released version of the library GPL.  It is
 numbered 2 because it goes with version 2 of the ordinary GPL.]
beelzebub:~$

Hmm, that sure as hell looks like an LGPL to me. I seriously doubt your
copy of gimp is different than mine...

later,
Andrew




Re: GIMP Plug-ins for other Apps? - LGPL for some GIMP modules?

1999-11-09 Thread Andrew Kieschnick


On Tue, 9 Nov 1999 [EMAIL PROTECTED] wrote:

 On  2 Nov, Andrew Kieschnick wrote:
 
  Gimp plug-ins are not linked into the calling program (they are run as
   separate processes), so you can call them from any program you like 
  without violating the GPL.
 
  However you have to link Plug-ins against libgimp and possibly
  libgimpui and here you've got your problem. If you just have a Plug-in
  which computes everything internally and then just uses the standard way
  of exchanging data with GIMP you'll be on the safe side...

libgimp and libgimpui are LGPLed, so that isn't a problem.

later,
Andrew





Re: Re: Tile Cache Size

1999-11-08 Thread Andrew Kieschnick


On Tue, 9 Nov 1999, David Bonnell wrote:

 On Tue, 9 Nov 1999, Ewald R. de Wit wrote:
 
  Anyway, today I went over the Gimp sources and noticed how complicated
  the tile architecture makes things and I couldn't help wondering why
  the heck it was put in. All it seems to do is to give you an order of
  magnitude slower speed when dealing with large images. And large
  images were supposed to be the very reason for a tiling architecture.
  
 I'm afraid I have to agree with you on the performance WRT large images.
 I tried editing a couple of large images yesterday (10MB/600dpi) and it
 was painfully slow (Dual 300MHz PII, 128MB RAM).  I've got a 20MB/1200dpi
 one I want to edit and I'm not looking forward to it!

Hmm. Are you setting the tile cache size to something reasonable? It will
definitely suck with the default 10mb tile cache...

later,
Andrew Kieschnick