Re: [Gimp-developer] gimp-cvs on msys/mingw

[michael chang]

On 6/28/05, Manish Singh <[EMAIL PROTECTED]> wrote:

> Changing stuff outside of gimp should be considered last resort.
> 
> > which is still not perfect: I modified python.m4 to replace "\"es by "/"es:
> >
> >[am_cv_python_pythondir=`$PYTHON -c "from distutils import sysconfig;
> > print
> > sysconfig.get_python_lib(0,0,prefix='$PYTHON_PREFIX').replace('\\','/')"
> > 2>/dev/
> > null ||
> 
> Why is this needed at all? gimp doesn't use $pythondir anywhere.
> 
> -Yosh
> ___
> Gimp-developer mailing list
> Gimp-developer@lists.xcf.berkeley.edu
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
> 

I don't know, but maybe this has something to do with python-fu or
whatever it is [scripting in The GIMP with Python, as opposed to e.g.
Perl or Script-Fu].  IIRC, some info about Python-Fu building on Win32
just came through the gimp-devel list, so... *shrugs*

-- 
~Mike
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Layer locking proposal

[michael chang]

On 6/27/05, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Simon Budig <[EMAIL PROTECTED]> writes:
> 
> > A way to overcome this is to have e.g. two lines per layer. A sample
> > mockup is available at
> >   http://www.home.unix-ag.org/simon/files/layer-dialog-many-properties.png
> 
> This might work from a user's point of view but I am afraid that it
> will be a nightmare to implement. There's absolutely no support from
> GTK+ for this kind of UI. Probably even for good reasons.

So you can't do something like a two boxes with columns, in a box, and
then have a list of those boxes?  Something like the way Java Swing
does GUIs? [I'm sorry, but I have no idea how GTK+ works, so it's just
my two cents.]  I don't suppose this would be something to ask the
GTK-Development team about how to implement, would it?  [Similar to
how we're discussing how to implement this here.]
-- 
~Mike
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] gimp-cvs on msys/mingw

[michael chang]

On 7/5/05, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> lode leroy writes:
>  > ftruncate is not present in my version of mingw, so I changed it to make it
>  > compile.
> 
> Why don't you upgrade to a more recent version then? (Or have they
> dropped their inline ftruncate() implementation in unistd.h from
> bleeding-edge versions?)
> 

MinGW/MSYS comes in about 20 or so different packages, which can be
confusing to install.  Did you install everything binary from
MSYS/MinGW?  If not, then we might have to go figure out which
MinGW/MSYS components are prequesites to installing The GIMP.

-- 
~Mike
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Script-Fu Script Progress

[michael chang]

Hi,

I've been experimenting with writing Script-Fu scripts in Gimp 2.2.27
on Debian Linux.  The particular script I'm working on is based on a
script that "rotoscopes" a selection on single frame, except that it
has been modified to use glob to find a list of files, and
select-by-color to select the area to "rotoscope", as well as to go
into the Xtns menu as opposed to the Image-Script-Fu menu.  [I also
remember reading about the menu reorganization in CVS, and when that
version comes out and I upgrade, I will try and update the script as
necessary.]   Anyways, when running the script, it takes a while, and
I notice that at the bottom of the Script-Fu dialogue for that script
(and many others) there is a "Script Progress" indicator that lists
the current command being executed and the percentage display for any
plugins that run.

What I'm wondering is if there is any function that allows me to
display a percentage back to the user using that percentage bar when
it's not in use by a plugin, because the script does take a while to
run.  I'm aware of the gimp-message output functions, but I find these
aren't feisable when simply reporting the percentage complete to the
user (me).  In particular, I simply wish to report which frame is
complete, for example if I'm rotoscoping using the glob "image???.png"
and the glob returns 180 files, and I work on all of them and I'm
keeping count, I want to be able to report I'm done e.g. file 20 of
180 as a percentage on the bar and/or through a status line
[preferably either the former or both as opposed to just the latter].

I would greatly appreciate any feedback, including a reference to any
documentation.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Fwd: [Gimp-developer] Question about the plug-in system.

[michael chang]

[My apologies, I forgot to CC to the list. ^^"]

On 8/4/05, Joao S. O. Bueno Calligaris <[EMAIL PROTECTED]> wrote:
> On Thursday 04 August 2005 18:43, Axel Philipsenburg wrote:
> > What I'd like to do is to write a plug-in that would make the Gimp
> > a nice tool for 3D artists by showing a 3D object in a seperate
> > window with the currently selected Gimp image as UV mapped texture.
> >
> > The 3D object would be loaded from a Wavefront OBJ file with all UV
> > mapping coordinates and been displayed by using OpenGL.
> >
> > The only thing that gives me worries about this, is if the Gimp
> > plug-in system would allow a seperate window to be constantly
> > displayed and updated whenever a tool operation is finished so that
> > the artist can practically see each brush stroke (or other tool
> > usage) instantly on the 3D object once the tool has been used.

> Offically it is not possible.
>
> That is: there is no way for the GIMP to call back your plug-in
> whenever an action is performed.

Either way, the idea of redoing this every time an action is finished
sounds very scary.  What happens when I don't want to use it, or if I
run a script-fu or something?  I'd rather be able to preset the
settings, and then just click an "Update Preview" function.  This _IS_
a preview type thing, isn't it?  Otherwise it would be kind of
weird...

> However nothing but the extreme deselegance of it can stop your
> plug-in of pooling the GIMP for image data every few seconds.

I believe you mean polling.  And while this doesn't sound impossible,
would GIMP allow for a Plugin to open a window, poll, and still let
the user continue working?  If memory serves me right, every other
plugin I know of, GIMP hands total control over to the plugin, and
"freezes" (if you will) while the plugin is running.  So if the window
stays open, will I even be able to make a change in the meantime?

If you can't get an autoupdating one working, at least one that
doesn't auto-update would be nice.  [Especially if you're willing to
maintain it through the versions.  *ahem*]  Just a thought, how are
you going to set the camera angle though?

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.


-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp as UV mapping tool.

[michael chang]

On 8/5/05, Axel Philipsenburg <[EMAIL PROTECTED]> wrote:
> Michael mentioned that Gimp Plug-Ins might not be able to allow further
> manipulation to the image while running because they hog the dialog focus.

I guess I should have mentioned I wasn't 100% sure with this. 
However, I will note, on my 2.4 GHz Intel Celeron, it has been nearly
impossible for me to multitask when running a plugin (they're too CPU
intensive) -- and OpenGL wouldn't be feisable for me either because I
don't have a high-end graphics card.  That said, most people who would
use this kind of plugin, I'd assume, wouldn't use this kind of low-end
system anyways (if I want to wrap an image around an object, I'll use
POV-Ray and raytrace it anyways; so there is no such thing as a
real-time preview to me regardless of rendering method, and I know how
to use POV-Ray).

> If that's truely the case, then the plug-in approach on this tool seems doomed
> anyway. There is not much sense if you need to call the plug-in from a menu
> everytime you changed the texture somewhat.

I don't see why I can't float the plug-in's menu and keep clicking the
button though.

I still wonder how you're gonna export the data to OpenGL, and what
happens if something goes wrong.  How will you handle OpenGL's
settings, etc... so maybe moving this elsewhere is an idea.  What
about as a seperate utility? [e.g. Use a filename with e.g. a png or
xcf file and load, then open a window with a preview, setting OpenGL
settings and the image's filename in it -- when I want an update, I'll
save my image in GIMP, and click a button in the app which will update
the preview.]

Good luck with your project, should you continue to persue it.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: Gimp as UV mapping tool.

[michael chang]

On 8/5/05, Pasi Savolainen <[EMAIL PROTECTED]> wrote:
> * michael chang <[EMAIL PROTECTED]>:
> > On 8/5/05, Axel Philipsenburg <[EMAIL PROTECTED]> wrote:
> >> Michael mentioned that Gimp Plug-Ins might not be able to allow further
> >> manipulation to the image while running because they hog the dialog focus.
> >
> > I guess I should have mentioned I wasn't 100% sure with this.
>
> FWIW, I was able to run a gaussian blur plugin _and_ draw onto image at
> the same time. Changes also propagate into plugin preview (if only I
> draw into different cache block than what is shown in preview, this
> could be a bug?).

Run Gaussian Blur, have it back in the plugin view; but would you be
able to click "apply" or whatever and draw at the same time?  I can't
think how. *shrugs*  Then again, maybe there won't be a "Apply" button
here.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] AGEIA PhysX chip physX SDK(NovodeX v2.2 SDK) AGEIA PhysX chip physX SDK

[michael chang]

On 8/6/05, Gottfried Zojer <[EMAIL PROTECTED]> wrote:
> But is anybody aware if there is somebody working on a project to bring
> Gimp to run with the AGEIA PhysX chip ( is there any documentation about
> how to use the NovodeX v2.2 SDK in combination with a Gimp plugin
> Thanks for any feedback

The GIMP performs 2D image manipulation, not 3D physics manipulation.
None of the features in the PhysX chip apply to what GIMP does, so
it's highly unlikely that any of the filters or plugins use this chip.

He is probably referring to the 3D effects that can be done via plug-ins.

If you wish to speed up the performance of The GIMP, get a faster CPU,
and more, faster memory.  A faster hard disk (maybe small, high-speed
SCSI disk) [or a partition of such a disk, used when the disk is not
being used for other activities] used exculsively for The GIMP may or
may not also improve performance.

None of these statements are guaranteed to be true, and are merely
speculation.  Take with a grain of salt.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New to list--curious about progress of 'Resources'

[michael chang]

On 8/15/05, Leon Brooks <[EMAIL PROTECTED]> wrote:
> On Tuesday 16 August 2005 04:10, Carol Spears wrote:
> > I am curious what you must do before you can see the upload page?
> 
> Register and log in.
> 
> > do you know what it is written in?
> 
> The project is linked from the lower left of each gallery page:
> 
>http://gallery.sf.net/
> 
> It lists "PHP4" as a requirement, so that's probably what it's written
> in.

*sighs* PHP4, though, requires parsing *EVERY* page as it goes out of
the server.  Not exactly efficient -- it could put a toll on the
server.  *sighs*

> > it is interesting that you start with a very plain page and then
> > click through to a stylized page.

I think this is the recommended design in one of the HTML design books I read...

> The plain page is essentially a lightweight splash, the rest is the
> "real" gallery. The gallery is designed to be embeddable in several
> CMSes.

I'm sorry, what's a CMS?
-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP print dialog issues

[michael chang]

On 8/15/05, Brian Thomason <[EMAIL PROTECTED]> wrote:
> I am packaging up gimp 2.2.8 for Linspire and have noticed some strange

> When the print dialog is open, the orientation is set to "Auto", which
> is good, but none of the default position indentions are set. (Left,
> Right, left Border, etc...)  For the common user, he will just hit print
> when presented with the dialog, and this will simply fail as it is.

Which printing system does Linspire use? (e.g. CUPS, BSD, etc.)  Does
it make one of it's own to make it similar to Windows?

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP print dialog issues

[michael chang]

On 8/15/05, Brian Thomason <[EMAIL PROTECTED]> wrote:
> michael chang wrote:
> >On 8/15/05, Brian Thomason <[EMAIL PROTECTED]> wrote:
> >>I am packaging up gimp 2.2.8 for Linspire and have noticed some strange
> >
> >>When the print dialog is open, the orientation is set to "Auto", which
> >>is good, but none of the default position indentions are set. (Left,
> >>Right, left Border, etc...)  For the common user, he will just hit print
> >>when presented with the dialog, and this will simply fail as it is.
> >
> >Which printing system does Linspire use? (e.g. CUPS, BSD, etc.)  Does
> >it make one of it's own to make it similar to Windows?
> >
> We use CUPS.  (No modifications, other than cosmetics)

With or without BSD daemons?

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP print dialog issues

[michael chang]

On 8/15/05, Brian Thomason <[EMAIL PROTECTED]> wrote:
> michael chang wrote:
> >On 8/15/05, Brian Thomason <[EMAIL PROTECTED]> wrote:
> >>I am packaging up gimp 2.2.8 for Linspire and have noticed some strange
> >>Right, left Border, etc...)  For the common user, he will just hit print
> >>when presented with the dialog, and this will simply fail as it is.

At odd times, if the user doesn't flatten the image before printing,
it will only print the current layer.  And he'll wonder why half his
image is gone.  [I can't remember what version of GIMP/GIMP-Print this
is in.]  Some who are prompted for auto-flattening-export think it
will perminantly flatten their image, and look for a work around.

Are you packing gutenprint/gimpprint also?

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP print dialog issues

[michael chang]

On 8/15/05, Robert L Krawitz <[EMAIL PROTECTED]> wrote:
> That shouldn't have any effect here.  Gimp-Print doesn't really care
> what the underlying spooling system is.

How does it contact the spooling system?  Or does it use specific
methods for each printing system?
-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New to list--curious about progress of 'Resources'

[michael chang]

On 8/16/05, Leon Brooks <[EMAIL PROTECTED]> wrote:
> On Tuesday 16 August 2005 07:04, michael chang wrote:
> > *sighs* PHP4, though, requires parsing *EVERY* page as it goes out of
> > the server.
> 
> No, just the PHP pages. I run mixed sites, and it's quite efficient as
> an Apache module, no significant performance penalty for a HTML page
> parsed through it (ie, no PHP code in it, just named .php or .phtml or
> whatever so that it gets feed to PHP).

Altight, PHP4, requires parsing *EVERY* PHP4 page as it goes out of the server.

If the entire site is PHP4, or PHP4 generated, though... *shrugs*

I know SSI is similar to PHP4, IIRC, although it's less "complicated",
built in to the server, etc.  Dunno how it differs in load, but it's
about the same, last I checks.  I've tried PHP4 before, but I
personally like perl better.

> > I'm sorry, what's a CMS?
> 
> Content Management System (slight variations on the acronym, but the
> idea is common): a way for dumb or busy users to easily manage website
> content. A wiki is a kind of CMS. Zope or Plone are common and more
> typical examples.

Thanks.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp_image_delete and adding text layers

[michael chang]

On 8/15/05, Jared Whiting <[EMAIL PROTECTED]> wrote:
> machine because in the process of creating images the GIMP keeps holding
> on to more and more memory.  As an example, I can run the following

> $img->gimp_image_undo_enable;
> gimp_image_delete($img);
> Gimp::end;

> the GIMP instance grabs on to more memory and holds on to it
> permanently.  Deleting the image and disabling undo do not result in the
> GIMP releasing memory for the new layer it created.  I would prefer not

What about putting "$img = undef;" at the end -- does this change anything?

Also, in the Perl Docs, "perlfaq3":

=

How can I free an array or hash so my program shrinks?

(contributed by Michael Carman)

You usually can't. Memory allocated to lexicals (i.e. my() variables)
cannot be reclaimed or reused even if they go out of scope. It is
reserved in case the variables come back into scope. Memory allocated
to global variables can be reused (within your program) by using
undef()ing and/or delete().

On most operating systems, memory allocated to a program can never be
returned to the system. That's why long-running programs sometimes re-
exec themselves. Some operating systems (notably, systems that use
mmap(2) for allocating large chunks of memory) can reclaim memory that
is no longer used, but on such systems, perl must be configured and
compiled to use the OS's malloc, not perl's.

In general, memory allocation and de-allocation isn't something you
can or should be worrying about much in Perl.

See also ``How can I make my Perl program take less memory?''

=

How can I make my Perl program take less memory?

When it comes to time-space tradeoffs, Perl nearly always prefers to
throw memory at a problem. Scalars in Perl use more memory than
strings in C, arrays take more than that,
... 
[I suggest you read the entirety of this question in the actual FAQ,
it might be helpful.]

=

Hope this helps.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New to list--curious about progress of 'Resources'

[michael chang]

On 8/16/05, Leon Brooks <[EMAIL PROTECTED]> wrote:
> On Tuesday 16 August 2005 22:35, michael chang wrote:
> > Altight, PHP4, requires parsing *EVERY* PHP4 page as it goes out of
> > the server.
> 
> As does mod_perl every .pl page, no?

Indeed it does (I do even worse; I usually call the perl executable
from CGI, on my system at least, when testing); but I usually go to
the trouble of writing my pages and scripts so that static pages are
generated from CGI scripts wherever possible.

For example, http://starglassstudios.netfirms.com/mirrors.html was
dynamically generated by a CGI script, but the only bits being called
as CGIs are the OK status buttions (-- these scripts reside on my PC
at the moment, so aren't available 24/7 though).  The whole page used
to be CGI generated on the fly, and I still have that version, but I
like this one better.

When, and if, I get around to trying to write a resource-a-day script
in perl, I'd use this technique, unless instructed otherwise.

Although, at the moment, I believe I'll let Carol keep her script
maintained -- I'd rather not have the pressure on me, just in case I
never get around to writing the script.  If I finish it, I'll letchall
know.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New to list--curious about progress of 'Resources'

[michael chang]

On 8/16/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 16, 2005 at 11:05:59PM +0200, Sven Neumann wrote:
> >
> > > I've been watching the (Gimp)web site for some time.  Is there some
> > > realistic date when we can expect to see the 'Resources' section
> > > updated??
> >
> > Since there is absolutely no progress whatsoever with the GIMP
> > website, this isn't likely to happen ever. Perhaps you want to help
> > us to get the website back to live?
> >
> the gimp developers seem to be plagued by low self esteem.  one good way
> to get people involved is to perhaps offer something that builds
> confidence and displays good faith in an individuals ability to take on
> a project like that like a publisher.

Where is the GIMP Website located (in terms of making changes)?  If
someone wants to help e.g. do one page, but not take over the whole
project, how would s/he go about propagating the changes to the GIMP
website (if approved)?

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New to list--curious about progress of 'Resources'

[michael chang]

On 8/17/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 17, 2005 at 03:58:34PM +0200, Michael Schumacher wrote:
> >
> > On as side not, it is strongly recommended to take Carol's rumbling with a
> > (huge) grain of salt - she like to overexaggerate and to play with other
> > people, although she will disagree on the latter :)
> >
> sure.  don't let me do all the telling.  you wanted to work with the
> wiki.  can you tell how that progressed?

I it rather amusing you two both said the same thing -- although
Michael managed to say it in one message, whereas Carol used two. ^^

I suppose it could have been worse...

And no, I'm not backed by any corporation -- I don't even have a job
at the moment (this is all hobby work and speculation; I'm a
high-school student).

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp_image_delete and adding text layers

[michael chang]

On 8/17/05, Jared Whiting <[EMAIL PROTECTED]> wrote:

> increase, but the cgi I'm using in production does a lot more than this
> and can be generating a few thousand images in one day.

Are any of these concurrently, and if so how many; could this make a difference?

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] script fu and image file support?

[michael chang]

On 8/23/05, woc <[EMAIL PROTECTED]> wrote:
> I do not want to write a .c plugin, because portability is more
> important to me than speed.  

Gimp itself is written in some variant of C, isn't it?

The only "portability" issue here is that you'd need to compile it on
all target OS's.  No big deal -- that's how GIMP is made anyways.  Use
MinGW for Windows, and Linux uses the GCC and related tools.  Easy
enough.

Script-Fu only has the "advantage" of not requiring compilation before
execution, but it doesn't handle Raw IO or pixel-based image creation
IIRC (for good reason, too, proally).

Perl probably has similar limitations, to a certain extent.  Perl
handles text best -- binary data, it's best at simply passing... I
believe the term is ad verbatim or something.

Try copying a C image format plugin that already exists, maybe (e.g. xbm)?  

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] script fu and image file support?

[michael chang]

On 8/24/05, woc <[EMAIL PROTECTED]> wrote:
> On 8/24/05, Manish Singh <[EMAIL PROTECTED]> wrote:
> > Yeah, and you contradicted this statement when you said that C wasn't
> > portable enough for you. There are differing definitions of what
> > "portability" means.
> 
> C is definitely less portable than I'd like.

I presume you mean this in the sense that you'd want to write it and
distribute it as-is for your users in this cases?  If you want, you
can always cross compile for Windows on a Linux system, and develop on
Linux.  (Not sure about vice-versa.)

Mac OS X, IIRC, comes with a compiler; Linux might, if you specify it,
but various people use deb binaries or rpms.  *sighs*

If Windows compatability isn't a issue immediately (future problem)
then, of course, Python would be the way to go for your circumstance. 
>From what I gather, many people seem to use the Python bindings.

> I really do appreciate you helping me get oriented.  That is quite
> useful -- I'm sure you've saved me days or weeks of searching the docs
> for how to make script fu work when basically I would have been wrong
> to try that route.

At least that got straightened out.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]

[michael chang]

On 8/26/05, Michael Schumacher <[EMAIL PROTECTED]> wrote:
> As promised on IRC, my suggestions for the registry. Originally sent to
> the maintainer of the registry.

Sounds awesome.

> 1. Make it possible to indicate that a plug-in requires GIMP 2.2

2.3, and 2.4 options would be nice here too, I suppose.  And also,
change the list of links of types to a drop down box, maybe?  (Dunno.)

> 2. Compress the recent changes list
> 3. Make the recent changes available as a RSS feed

Very useful, then I can add the RSS feed to my browser. ^^

> 4. Add a way to indicate the availability of binaries for a specific
> platform

Something similar to the way tucows.com does their listings would be a
good idea.
Eg:

=
[Plugin name] . [Win] [Linux RPM] [Linux Deb] [Mac OS X] [Source]
  [Plugin catagories] [User based rating (maybe, maybe not)]
  [Language/format] [Requirements (optional/if specified)]
  [Plugin description summary]... [more info link to full description]
=

This could be unified, as well (e.g. anywhere plugins are listed this
format would go there).

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] authors.xml, volunteer needed

[michael chang]

On 8/26/05, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> Sven Neumann <[EMAIL PROTECTED]> writes:
> 
> >  http://cvs.gnome.org/viewcvs/gimp/authors.xml?view=markup
> >
> > I am now looking for a volunteer to go over authors.xml and check
> > what roles apply to the people listed there. Perhaps also check that
> > noone important is missing (last time we did that was before the 2.2
> > release). No coding skills required, you don't even need to know
> > anything but the mere basics about XML.  Some knowledge of the GIMP
> > history will definitely help though...
> 
> No response whatsoever. So there isn't even interest in helping with
> the simple tasks any longer? This is becoming somewhat frustrating...

I wasn't sure if I should attempt the task or not, and was kinda
hoping someone else would take the task (because I'm fiddling with
some other things in POV-Ray and Perl, among other things).  But I
believe I could attempt this, if you can point me generally at the
document sources I might want to look up, and what special
instructions I'd need for "submitting" the finished product.

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] authors.xml, volunteer needed

[michael chang]

On 8/26/05, Simon Budig <[EMAIL PROTECTED]> wrote:
> Sven Neumann ([EMAIL PROTECTED]) wrote:
> > Sven Neumann <[EMAIL PROTECTED]> writes:
> > >  http://cvs.gnome.org/viewcvs/gimp/authors.xml?view=markup
> > >
> > > I am now looking for a volunteer to go over authors.xml and check
> > > what roles apply to the people listed there. Perhaps also check that
> > > noone important is missing (last time we did that was before the 2.2
> > No response whatsoever. So there isn't even interest in helping with
> > the simple tasks any longer? This is becoming somewhat frustrating...
> I am pretty sure that it is *not* simple and that there are very few
> people being able to do that. And no, I don't think I could do this.

I believe that compared to coding C++, this is supposed to be
considered simple - the generic, old, mundane task of compiling a list
of names. ^^  I believe that in the "olden days" this used to be the
sort of job an entry level worker would do in a corporation.

> There are too many names in that file I've never heard of and I have no
> interest at all go digging through ancient maillogs or changelogs just
> to figure out if someone was a contributor or doc-writer or whatever.

What about a collaborative effort?  E.g. someone goes and checks
through these things, and then someone can double check.  Or the list
can be split in half, and then if there's ones we're unsure about we
send them to the other person (and vice versa).

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]

[michael chang]

On 8/26/05, Nathan Summers <[EMAIL PROTECTED]> wrote:
> On 8/26/05, Sven Neumann <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > michael chang <[EMAIL PROTECTED]> writes:
> >
> > >> 1. Make it possible to indicate that a plug-in requires GIMP 2.2
> > >
> > > 2.3, and 2.4 options would be nice here too, I suppose.  And also,
> > > change the list of links of types to a drop down box, maybe?  (Dunno.)
> >
> > 2.3 is a development version with no API guarantees whatsoever. The
> > API is constantly changing and noone should be developing any plug-ins
> > for it.
> 
> If you have such a closed Gimp Club attitude, why make developer
> releases at all?  After all, all the members of the Gimp Club have cvs
> accounts.  One of the most important reasons that we have preview
> releases is so that when 2.4 is released, third-party plugins are
> already available for it.  It's abundantly obvious that 2.3 is a
> developer edition, with all that entails, and both users and plugin
> developers are aware of the fact that things can break, but that
> doesn't mean that it's counterproductive to track development and to
> test the new features.  Would you prefer that serious problems in
> newly added plug-in apis not be discovered until after they are
> frozen?

Oh pah, stop arguing, I wasn't intending to get you guys angry. Geez. 
It was a suggestion.  If you don't like it, that's perfectly fine --
but adding them now would prevent us having to go and bug Mr. Web
Developer again when 2.4 is released.  (If he has to add all plugins
manually at the moment, then there isn't much point, but if it's
semi-automated or automated, adding them now but placing some sort of
consensus not to put things there works too.)

If it helps, why not have a (2.3/beta) or (current open beta) section,
and then wipe it when 2.4 is released?  Obviously, if you don't like
it, that's fine...

> Since 2.3 cvs contains a plugin that was originally maintained
> separately, and GIMP was developed against gtk 1.3 long before API
> freeze, it's obvious that you already know this, which makes me ask
> the question: why did you say this in the first place?  Seriously, it
> served no other purpose than discouraging people from testing the 2.3
> series.  GIMP isn't exactly overwhelmed with volunteers. We should be
> doing everything we can to encourage more people to try out 2.3, and
> more people to be testing its new features.  Yes, that even includes
> those features that have to be accessed programmatically.  Anyone who
> is capible of developing a plugin against 2.3 is capible of fixing any
> breakage if we change a non-frozen API.
> 
> > And 2.4 shouldn't be added before the 2.4 release.
> 
> That's a matter of taste.  After all, if 2.4 is backwards compatible
> with 2.0 plugins, there are a ton of plugins that are already 2.4
> compatible.  What's not a matter of taste is that plug-ins shouldn't
> be marked as 2.4 compatible if they use non-frozen APIs.  After the
> API is frozen is a different matter.

I presume that this statement is made assuming 2.4 doesn't become 3.0...

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] [Fwd: Some suggestions for the plug-in registry]

[michael chang]

On 8/27/05, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
> 
> I am not going to respond on your mail in detail, mainly for lack of
> time. Lots of good points being made and taken. However I would like

Time is always an important issue, and a lack of it may cause
curtness.  It'd be nice if everyone always took this into
consideration, but sometimes we forget from time to time.  Reminders
are sometimes necessary, and this one was well placed.

> to state that I am not at all unwilling to mentor new developers. I

That is very reassuring, yes.

> also think that our (and that includes mine) attitude towards new
> ideas and requests for changes has become a lot better over the last
> years. You are right that we are lacking active developers but we

Indeed.

> gained quite a few new ones recently and I am not sure if they receive
> GIMP development as bad as you put it. Quite a few people are rather
> enthusiastic about it and I would love to have more time to help them
> get into it.

Hopefully, so would everyone else... ^_^

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Using GIMP for Paper Prototyping the Colors Menu

[michael chang]

On 8/27/05, Akkana Peck <[EMAIL PROTECTED]> wrote:
> card-sorting app to help with distributed paper prototyping. But it
> occurred to me (based on an offhand comment I read on slashdot, of
> all places) that GIMP itself could be a pretty good paper
> prototyping system.  After all, you can have lots of text layers and

As a side note, this is actually a very good way of using the GIMP --
I used it myself when trying to solve a puzzle I was given by a
teacher.  Quite handy!

It might help if you bind the text layers to a coloured layer, (either
white, or white with an outline, or something), so they're easier to
see. [Especially if trying to create a layout that fills multiple
conditions.]

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Using GIMP for Paper Prototyping the Colors Menu

[michael chang]

On 8/27/05, michael chang <[EMAIL PROTECTED]> wrote:
> It might help if you bind the text layers to a coloured layer, (either
> white, or white with an outline, or something), so they're easier to
> see. [Especially if trying to create a layout that fills multiple
> conditions.]

Sorry, said this before looking at the script.  Very nice!  [I don't
believe it would be sane to say maybe considering optionally having
coloured backgrounds/background outlines per layer (to catagorize
items, maybe), nor to allow for all the pieces to be stuck in a pile
in the corner -- but then again I believe I'm a very insane person. 
Although that's what I meant, on reconsideration, that would be too
much work and looping IMO for such a simple script.]

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: R: [Gimp-developer] Error compiling gimp 2.3.3 with mingw on winxp

[michael chang]

On 9/15/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Hi, thanks for your help, I commented out the #include_next thing in
> d:/mingw/include/unistd.h (don't know if it is the right way ...) and it
> compiled fine with:
> ./configure --disable-print --disable-python --prefix=/d/gimp233
> 
> Now, do you know how to make it print in windows?

You have to be able to compile the files that are compiled when
./configure is run with --enable-print.  I believe Gutenprint may
help; but I'm not sure (not even close).

> Also is python scripting supported on windows?

AFAIK, It's doable, although it will be easier (afaik, meaning that it
might be in the binaries) in the final 2.4 release -- try checking the
archives (a success with gimp 2.3.3 + win + python is there
somewhere).

-- 
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.3.4

[michael chang]

On 9/23/05, Lance Dockins <[EMAIL PROTECTED]> wrote:
> Actually... I was trying to figure out what the best way to do that
> would be...  mostly because I run GIMP in a Win32 environment, so
> compiling GIMP isn't quite as straightforward as it is in Linux.  If I

Solution: Linux/POSIX emulation layer.  Cygwin is usually used.

MinGW/MSYS is also workable, IIRC.  I've never compiled GIMP on either, though.

> could figure out how to compile from CVS on Win32, I definitely would.
> Of course, I'm just going on the info I found at wiki.gimp.org that said
> that compiling from CVS required additional software.  Then again, maybe

Cygwin or MinGW/MSYS, as I said.

You'll also need the development codes for various graphics libraries,
e.g. libpng-dev.  These are provided in sepearte packages (e.g. select
in the Cygwin Installer) or available by compiling the libraries from
source.

> I'm just overcomplicating this.  Is it as simple as downloading the
> source from CVS and compiling it?  And for that matter, if that's the

Almost.

> case, is there an easy way to download the source from CVS?  Thanks in

The cvs tool. ;)

> advance for any feedback you can offer.
>
> Sven Neumann wrote:
> > Hi,
> >
> > Lance Dockins <[EMAIL PROTECTED]> writes:
> >
> >
> >> I've been testing GIMP 2.3.3 and I noticed that some of the changes of
> >> late have indicated we're nearing a 2.3.4 release.  Does anyone know
> >> what timeframe we're looking at for the 2.3.4 release?
> >>
> >
> > Whenever I get around to do it, which will hopefully be this weekend.
> > But, seriously, why don't you just use CVS?

Of course, at the end of the day, I think it'd be nicest if they made
an installer for the Windows binaries for the development releases,
but I'm quite sure that's probably more work than it's worth.

One of these days, I know I'll get around to compiling GIMP from CVS
myself.  Just need to clear out some working space first.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.3.4

[michael chang]

On 9/23/05, Michael Schumacher <[EMAIL PROTECTED]> wrote:
> michael chang wrote:
> > Solution: Linux/POSIX emulation layer.  Cygwin is usually used.
> > MinGW/MSYS is also workable, IIRC.  I've never compiled GIMP on either, 
> > though.
> For GIMP, I'd say that MinGW is preferred - not that there shouldn't any

I prefer MinGW myself, but I believe that if the guy knows how to
compile on Linux, it might be more familliar to him to emulate
Linux/POSIX on Windows with Cygwin than figure out MSYS/MinGW.  But
then again, I found it easier to get used to MSYS/MinGW than Cygwin,
so... *shrugs*

> > Of course, at the end of the day, I think it'd be nicest if they made
> > an installer for the Windows binaries for the development releases,
> > but I'm quite sure that's probably more work than it's worth.
>
> Problem: how to keep each of the places distributing GIMP (some net
> magazines, other random websites, users) from mistaking it as a new
> stable release.

How about not releasing it on the standard page (e.g. "hiding" it in
the developer website somewhere)?

I like the timeout idea too, personally -- POV-Ray (www.povray.org)
has monthly timeouts for its various beta versions (and they have a
new "beta RC" every month).  The problem is that when the timeout
dies, then should be a new version; if there isn't one, it's kinda
silly to have to re-install the same version to extend the timeout. 
In that case, determining a timeout would be hard...

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.3.4

[michael chang]

On 9/25/05, Michael Schumacher <[EMAIL PROTECTED]> wrote:
> michael chang wrote:
> > On 9/23/05, Michael Schumacher <[EMAIL PROTECTED]> wrote:
> >
> >>michael chang wrote:
>
> > The problem is that when the timeout dies, then should be a new
> > version; if there isn't one, it's kinda silly to have to re-install
> > the same version to extend the timeout.
>
> Reinstalling the same version wouldn't help, I'm talking about a hard
> timeout there - created when the release tarball is made, for example,
> and set to e.g. 60 or 90 days into the future.

What I mean is lets say the software times out after 70 days the
RC/beta is made.  That means that there has to be a new RC/beta after
70 days, or otherwise no one can use it post those 70 days.  If there
isn't, then someone might just rebuild the current RC for another 70
days, which is pointless.

E.g. if there was a 2.3.5 today, and it expires in 60 days.  So that
means 2.3.6 has to be released within 60 days.  How do we know 2.3.6
will be ready in 60 days?

If you want to force yourself on such a release cycle, by all means,
but last I checked, GIMP doesn't used fixed release cycles.  I could
be wrong though; I'm not a GIMP developer.  I mean, it's not like
fixed release cycles are all that bad of a thing.  Then again, you
might want to give yourself some leeway (e.g. trying to release a
version of GIMP 15 days before the last RC/beta expired or something;
that way delays can be absorbed into the 15 days that remain from the
last RC/beta/devel release).

> > In that case, determining a timeout would be hard...
>
> Not really. Running development releases is only useful up to a certain
> time anyway - once current CVS has advanced considerably, there is not
> much to be gained from using an outdated one. Also, this should
> encourage people to keep the latest stable release installed - after
> all, this one will not time out.

Well, that's very true.  I believe the 2.2.8 version of gimp is really
a 2.2.7+cvssomething on Debian - and those are offical packages.

> And finally, if anyone insists on using a development release longer
> than the timeout lets him, he can alwyys use the source and disable the
> timeout at compile time - and we can assume that if someone pops up with
> an outdated release he know what he's doing.

True.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Designing a Better Font Selection Widget for use in Open Source Software

[michael chang]

On 9/27/05, Edward H. Trager <[EMAIL PROTECTED]> wrote:
> ... regarding a proposal for an improved font selection drop-down
> widget that would be ideal for use in professional-quality Open Source
> word processing, desktop publishing, and graphic design programs

> http://eyegene.ophthy.med.umich.edu/unicode/fontdialog/

As a user, this sounds like a very awesome proposal, and if
implemented, would revolutionize font GUIs for users.  I don't know
whether it could cause a problem with Usability (e.g. Text to Speech
systems) though...

Just a note (and yes, I'm nit-picking), but there is no such thing as
'a Chinese pangram'.  Chinese uses individual characters for every
word (AFAIK), so you'll just have to choose some sample text that is
representative of the language, or make some up.  IIRC, Japanese has
an alphabet, though, and Chinese has a sort of 'proununciation'
alphabet (but that's seperate).

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Survey of usability in open source software development

[michael chang]

On 10/3/05, Bill Kendrick <[EMAIL PROTECTED]> wrote:
> On Mon, Oct 03, 2005 at 09:01:46PM +0200, [EMAIL PROTECTED] wrote:
> > On Monday, October 3, 2005, 9:59:40, Simon Ormholt Schrøder wrote:
> >
> > > Right now we are conducting an electronic survey to get an overview of
> > > current usability effort within the open source community. We encourage
> > > you to participate at  
> > > http://www.sieker.dk/survey/survey.php?sid=28
> > > (the survey takes approx. 15-20 minuttes)
> >
> > I tried to participate in the survey, but it won't let me past the 1st page
> > of questions (Country, City, Age, Occupation) - when I click Next Page, the
> > page just reloads (with my answers inserted).
>
> It worked fine for me.  I filled out the survey from my Tux Paint leadership
> role. :^)
>
> Perhaps reloading the same page is its way of saying "you haven't filled
> out the required fields"...?
>
> I used Mozilla on WinXP (ugh) with JavaScript (ugh) enabled, in case it
> matters.

I haven't filled out the survey (I don't consider myself a GIMP
developer yet per-se, as I haven't actually contributed code to the
GIMP or even done major testing), but I can go back and forth on the
first few pages... Mozilla Firefox 1.0.6 on Debian Linux Unstable,
both with Javascript Enabled and Disabled.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [EMAIL PROTECTED]: Re: [Gimp-developer] GIMP 2.3.4]

[michael chang]

On 10/4/05, Bill Kendrick <[EMAIL PROTECTED]> wrote:
> Lance wrote:
> > * A spare hard drive
> > * A reliable partition manager (instead of a drive)
> > * Perhaps an alternate computer entirely
>
> Just to be a weenie, I'll mention live CDs like Knoppix.

There'll be a DVD version too, at one point...

> Or even USB-bootable systems.  (I got to play with one of those this past
> weekend at a friend's workplace.  Full desktop Linux system stuck in a
> bootable 1GB USB memory stick.  Sweet!)

Just to note, live systems on optical media won't preserve data
between reboots without storing it somewhere, e.g. on a file or
partition (Knoppix does this with some scripts somewhere IIRC).  I
don't know about USB systems.

They're fun to play with, of course, but doing serious work is usually
easiest with a perminant install; you only need ~1-3 GB to get the
base and GIMP running (I'd suggest more if you're going to do major
work in it).  Note that NTFS support in linux is patchy at best,
although FAT is supported pretty well.  (So if you're moving files,
you may want a small FAT partition to move stuff in between Lin/Win.)

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.3.4

[michael chang]

On 10/4/05, Lance Dockins <[EMAIL PROTECTED]> wrote:
>
> > this is so interesting.  Win32 has succeeded in making linux expensive.
> >
> > you are asking that the Win32 environment not work the way it was
> > designed to work -- at least i think this is what you are saying.
> >
> > i am very impressed that it was able to make free software expensive,
> > this is a simply amazing accomplishment!
> >
> Carol,
>  Where in my e-mail did your read that *Linux *was going to cost me
> money?  Read that sentence again.  Or, better yet, I'll quote it.  "I
> should also clarify that I have considered switching to Linux to make
> this easier, *but I just don't have the time, money, and hardware to do
> so without destroying the Win32 environment I'm required to use in the
> professional world.*"  Did I say that the money, time, and hardware I
> was going to invest was going to be invested in buying Linux or did I
> just say that I would have to invest money, time, and hardware into a
> Linux setup? Here's a few things that cost money that fit perfectly into
> that sentence.
>
> * Time
> * A spare hard drive
> * A reliable partition manager (instead of a drive)
> * Perhaps an alternate computer entirely
> * Potential other hardware for those components that Linux drivers
>   don't function well on.
>
> Before I sign off on this, let me quote the second half of that sentence
> again.  *"*But I just don't have the time, money, and hardware to do so
> *without destroying the Win32 environment I'm required to use in the
> professional world.*" So that pretty much eliminates installing over top
> of my current OS.

Nonsense.  Debian's installer can resize ALL Win32 partitions (NTFS +
FAT) and make room for itself nondestructively.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.3.4

[michael chang]

On 10/4/05, Tor Lillqvist <[EMAIL PROTECTED]> wrote:
> lode leroy writes:
>  > The thing is that for compiling gimp from cvs, you need quite some 
> expertise
>  > in the autotools, libtool, aclocal, pkg-config etc to fix those
>  > not-100%-working-together- distributed binaries...
>
>  > Would it be feasible to create a big zip-file that contains everything for
>  > gimp for download?
>
> It would be possible, but wouldn't such a zipfile just create open up
> the possibility for even more confusion when there would then be yet
> another distribution of these libs? (A long time ago I *did*
> distribute self-built jpeg, tiff, zlib and whatnot, but stopped doing
> that as there were other distributions, too, that were just as good,
> or even more directly from the source, like zlib.)

Since you've found these better sources, I know it'd be a pain, but
could you include links to them somewhere?  That way, we can use the
same DLLs built that you do.  (I'm presuming you don't already; if you
do, my apologies.)

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] ScriptFu upgrading

[michael chang]

On 10/11/05, Helmut Jarausch <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've noticed that some ScriptFu scripts run just fine under 2.2.x but
> produce error messages under 2.3.5 (CVS)
> Is there a summary of API changes, possibly with hints for upgrading?

A) I have not heard this, but if it's anywhere, it probably is in the
changelog.  This is a hunch (meaning, not verified), but I'd presume
deprecated functions (stuff from the 1.x era) may have been removed,
at the very least.

B) Some people use Tiny-Fu instead of Script-Fu in 2.3.5 or so - in
this case, see the Tiny-Fu page for some recommendations.  IIRC,
Tiny-Fu hasn't, however, officially replaced Script-Fu.

An actual developer probably would have a better and/or more specific answer.
--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.3.5 cvs compile fails

[michael chang]

On 10/22/05, Timo Gerke <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I just checked out cvs gimp 2.3.5. As I tried to compile it,
> it complained that gimp-print isn't installed. So far this is
> right but I know that gutenprint (yes, the developement files
> too) is installed on my system.
>
> So configure has stopped running.
>
> I guess that gutenprint is not yet supported by gimp.
> I'd like to print in gimp.

Very Untrue!  Gutenprint is very much supported by GIMP.

> Is gutenprint palnned to be supported in the next time?

Did you install the gutenprint development libraries/packages?  Or did
you install it from scratch (a.k.a from sources)?  If neither, then
GIMP won't find gutenprint's sources (which it needs to link with in
order to make the print plugin).

If you're in a rush, you can also disable the print plugin.  (But you
won't be able to print).

Do note you'll also need the python development libraries unless you
explicitly disable python support.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP 2.3.5 cvs compile fails

[michael chang]

On 10/23/05, Timo Gerke <[EMAIL PROTECTED]> wrote:
> michael chang schrieb:
> > On 10/22/05, Timo Gerke <[EMAIL PROTECTED]> wrote:
> >
> >>Hi all,
> >>
> >>I just checked out cvs gimp 2.3.5. As I tried to compile it,
> >>it complained that gimp-print isn't installed. So far this is
> >>right but I know that gutenprint (yes, the developement files
> >>too) is installed on my system.
> >>
> >>So configure has stopped running.
> >>
> >>I guess that gutenprint is not yet supported by gimp.
> >>I'd like to print in gimp.
> >
> >
> > Very Untrue!  Gutenprint is very much supported by GIMP.
> >
> >
> >>Is gutenprint palnned to be supported in the next time?
> >
> >
> > Did you install the gutenprint development libraries/packages?  Or did
> > you install it from scratch (a.k.a from sources)?  If neither, then
> > GIMP won't find gutenprint's sources (which it needs to link with in
> > order to make the print plugin).
>
> I'm wondering gutenprint development (version 5.0-rc1, debian
> package) are insatlled on my system.
>
> I just installed libgnomeprint/libgnomeprintui 2.10.3
> developement files. They are detected by configure.

That's not the same as gutenprint or gimp-print...

Try installing libgutenprint-dev and libgutenprintui2-dev packages
(and their dependencies) and then try again.

aptitude install libgutenprint-dev libgutenprintui2-dev
as root should do the trick.

> >
> > If you're in a rush, you can also disable the print plugin.  (But you
> > won't be able to print).
> >
> > Do note you'll also need the python development libraries unless you
> > explicitly disable python support.
> >
>
> I also installed python development files. May be 2.3 is too
> old?

I doubt it - either way, python has nothing to do with printing (last
I checked).

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] PDB access to tools

[michael chang]

On 10/27/05, Jon Niehof <[EMAIL PROTECTED]> wrote:
> Haven't found anything recent in the archives regarding this--is
> it possible to access the toolbox in some way via scheme
> scripts? I want to batch-crop a bunch of images--i.e. write a
> script that'll load an image, display it, pull up the crop tool,
> and wait for the user to approve the crop. Then, once the crop
> is done, save the image, close the window, go to the next one.

IIRC, The tools simply provide a gui interface to simplified pdb
functions that can be called directly in scripts, such as
gimp_image_crop.  Also, IIRC, there isn't really a good way of
prompting the user for confirmation with that kind of instance in
script functions.  In addition, loading multiple images looks like
either you're using GLOB or having them "hard-coded" (*shivers in
ugliness*).  Finally, it is worth noting that there is an autocrop
option in one of the image menus (and PDB has plug_in_autocrop and
plug_in_autocrop_layer).

In my experinece, unless you're processing, say, 500+ images, it looks
like it'd be more work to get a script to simply open, show, and close
those images, let alone do anything with them, especially in
Scheme/Script-fu, than to do it by hand.  (Once it *is* done, however,
it is nice to have, I'm sure.)

One "tool" that may be of help if you do proceed with this - in GIMP,
there is a "Procedure browser" in the Xtns menu in 2.2.8 and 2.3.4
(probably in various others; has this moved yet in CVS?), sometimes
you can search for the action you want to do (e.g. crop) and you'll
get a list of script-fu/pdb procedures, which parameter lists.  (Avoid
ones marked deprecated!)  Note that, IIRC, script-fu seperates words
with the - (dash) not the _ (underscore) last I checked, although the
PDB shows it the other way around.

Please note that there may be errors in my answer, if so, someone else
may be able to correct them.  Take my response with caution.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] 16bit channels, doh

[michael chang]

On 10/31/05, Brannon King <[EMAIL PROTECTED]> wrote:
> So I was told to see the GEGL info.
>
> That website (gegl.org) drastically needs a FAQ.
> Perhaps someone can answer these questions for me:
>
> 1. Is GEGL made to replace a certain core piece of
> GIMP or is it made to reroute data somehow?
> 2. Why is it not part of the GIMP core currently?
> 3. Is it activelly being worked on? Is its mailing
> list still used?
> 4. It appears to just be an API. Why would using this
> be better than changing the current GIMP core to
> support 16bit channels directly? Or are we planning to
> do just that and just use the GEGL API data structures
> and constructs?
> 5. How close is the GEGL code to usable?
> 6. Will it even work with the current GIMP codebase?

If memory serves me right, 8-bit support is pretty mostly hard-coded
(or something akin to that) in the current GIMP base, unfortunately. 
Past talk of adding 16-bit support has sounded as though it requires a
major revamping of even core underlying systems that comprise GIMP
(sounds like a re-write, almost, even).  GEGL (Generic Graphical
Library) apparently has something to do with the new-fangled
underlying framework for such a project. But I have no idea on the
subject, I'm just trying to recall what others have said on this list
from memory.

> 7. Has anyone worked on a merge plan for combining
> GEGL work with the current GIMP codebase?

I believe it's planned for some future release somewhere, but has been
continually put off due to a lack of manpower.  Or something of that
sort.  That said, I'm myself wondering whether a 16-bit capable gimp
requires a fork, and if so, how much support that fork would get.
Should you go forward with this (and I hope you do, as many have been
asking for this), then I do wish you good luck, and hope that it comes
out quite well.

Because I haven't been following development long enough (I'm afraid),
someone else probably has a lot of details to add that I may have
missed.

--
~Mike C
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] the expanding gimp web

[michael chang]

On 11/4/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 04, 2005 at 09:28:05PM +0100, Sven Neumann wrote:
> > Carol Spears <[EMAIL PROTECTED]> writes:
> >
> > > there are a few new gimp.org web sites lately.  i have been playing with
> > > the software available from planet.org and the results have been almost
> > > instant.
> > >
> >
> > Very nice. I am not sure how useful it is to have different
> > aggregators for developers and users but we will see. What I am
> > missing is a note on the individual sites explaining what feeds they
> > are collecting and perhaps links to the other aggregators?
>
> i considered what sort of collections of blogs i would find useful.  i
> also considered what could happen if only a small fraction of the gimp
> users added their blog to the feed.  the developers would be lost.  if
> there was only one feed, the news would get lost as well.
>
> i agree that some explanation would help, i got a little confused myself
> by the gimp object scheme this week while making them.  after a short
> break in working with them, i will see what i can do about adding a
> little more information.

Quite nice, the clean interface makes it easy on the eyes, and it
looks like it'll break down nicely if someone's using a console-based
browser (e.g. Lynx).

Since it's already set up like that, I don't know if you want to
change it, but maybe a unified header + description at the top,
followed by a selection for Layers | Pixels | Paths would be
interesting... http://blogs.gimp.org/layers,
http://blogs.gimp.org/pixels, and http://blogs.gimp.org/paths URIs
would make sense (although that's less creative, i suppose, than your
current offerings).  If you did do something like that,
http://blogs.gimp.org would maybe also have the same main header as on
the above three sites, and then split the three aggregated feeds into
individual columns with mini-headers... maybe similar to the column
layout at http://www.google.com/ig (except not so interactive and
messy...)... each column would be headed b the individual "Layers",
"Pixels" and "Paths" blogs headings respectively.

Hopefully the suggestion sounds clear... and maybe it's something
worth considering, but take it with a grain of salt.  I won't be
offended if you don't like it.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] the expanding gimp web

[michael chang]

On 11/5/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 05, 2005 at 04:33:08PM +, michael chang wrote:
> > On 11/4/05, Carol Spears <[EMAIL PROTECTED]> wrote:
> > >
> > > i considered what sort of collections of blogs i would find useful.  i
> > > also considered what could happen if only a small fraction of the gimp
> > > users added their blog to the feed.  the developers would be lost.  if
> > > there was only one feed, the news would get lost as well.
> > >
> > > i agree that some explanation would help, i got a little confused myself
> > > by the gimp object scheme this week while making them.  after a short
> > > break in working with them, i will see what i can do about adding a
> > > little more information.
> >
> > Quite nice, the clean interface makes it easy on the eyes, and it
> > looks like it'll break down nicely if someone's using a console-based
> > browser (e.g. Lynx).
> >
> thank you.  the very first thing they did when i showed my first gimp
> web site on the irc was to try it in lynx.  this is a fact for anyone
> trying to design a gimp web site.
>
> > Since it's already set up like that, I don't know if you want to
> > change it, but maybe a unified header + description at the top,
> > followed by a selection for Layers | Pixels | Paths would be
> > interesting... http://blogs.gimp.org/layers,
> > http://blogs.gimp.org/pixels, and http://blogs.gimp.org/paths URIs
> > would make sense (although that's less creative, i suppose, than your
> > current offerings).  If you did do something like that,
> > http://blogs.gimp.org would maybe also have the same main header as on
> > the above three sites, and then split the three aggregated feeds into
> > individual columns with mini-headers... maybe similar to the column
> > layout at http://www.google.com/ig (except not so interactive and
> > messy...)... each column would be headed b the individual "Layers",
> > "Pixels" and "Paths" blogs headings respectively.
> >
> one of my irc friends (i always forget that he is one of the people who
> actually does the work running the gnome computers -- that kind of
> friend, they are great to make and a rare human who is a friend more
> than a superhuman ruler of an actual internet domain) does not like the
> word blog.  he said that he doesn't mind the idea of it but would prefer
> that people call them web journals or web logs.
>
> the planet software suggests the word planet.  it is implied that the
> planets show developer web logs.  i almost missed this implication and
> called the user aggregation a planet.  there are a bunch of "planets"
> already.
>
> blogs.gimp.org -- what if the gimp computers started to have more than
> just me on the computer with a blog?

*shrugs* To me, blog doesn't sound right either -- it is a sort of
made-up word anyway.  But the idea of a quasi-unified interface was
just that, an idea.  The concept of a whatever.gimp.org/section seemed
to make sense to me since the content ... source-type is the same?  I
have no clue now...

Planet would sound nice, except, yes, it is way too common, and I
don't think it sounds GIMPy enough (if that's a word).

> two thoughts about putting the feeds all on one page.  1) is that
> useful? and 2) gimp is making new images for two of them everyday.
> they are random in content (somewhat) and also size.  a unified look
> more than what there is now is not more important than how cool those
> random images are, in my opinion.

Hm.  Very true, since I guess the whole purpose of the layout is to
not detract from the actual content in and of itself.  [Well, at least
I didn't suggest DHTML sliding menus or panels or something. ;)]

> i think a short text explaining whose web logs should be enough.

Well, it was just an idea -- whatever works, I say.  In any case, good luck.

--
~Mike
 - Just my two cents
 - No man is an island, and no man is unable.
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GetMinGWBat.bat Failure

[michael chang]

On 12/11/05, Chris Share <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm trying to setup my Windows build environment.
>
> I've tried using the GetMinGWBat.bat file however there's a problem with
> one of the files: wget cannot be found.
>
> I've had a look at the .bat file and I think the problem is that it
> searches for the file at sunsite.dk however this site has moved.
>
> The .bat file contains the following:
>
> echo> getwget.tmp open sunsite.dk
> echo>>getwget.tmp binary
> echo>>getwget.tmp get /pub/projects/wget/windows/wget-complete-stable.zip
> echo>>getwget.tmp close
> echo>>getwget.tmp quit
>
> Any idea what I should change this to to make it work.

Hi,

This site works perfectly fine for me.

In any case, you can manually download
ftp://sunsite.dk/pub/projects/wget/windows/wget-complete-stable.zip
and save it in the same folder, and then get rid of the lines that
access FTP and hope it works.

However, the MOTD explicitly states that there is a "Max Load Limit of
30" (whatever that means) so "If this limit is exceeded downloads will
be disallowed.".

You should try again later, or try installing MinGW manually (just
make sure you get everything specified in the .bat file so your thing
doesn't break).

The other possiblity is that sunsite.dk may be blocked for you from
upstream.  (Read: proxy server, firewall, filtering squid proxy, etc.)
 If that's the case, then I don't know how you'd circumvent that (or
if it's even a good idea).

--
~Mike
 - Just the crazy copy cat.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer