Hi,
Nathan Carl Summers <[EMAIL PROTECTED]> writes:
> Also, I'll again repeat my objection to the idea that the scheme
> extension be packaged separately from GIMP. We have always had
> Script-Fu as a universal -- the one scripting system you could count
> on for all gimp installations on every
Hi,
Alan Horkan <[EMAIL PROTECTED]> writes:
> I fear having to rewrite some of my scripts having already written
> gimp 1.2 and gimp 2.0 versions. Compatibility is important to me,
> even if only small changes are necessary it causes problems. I dont
> relish the prospect of new scripts I write
Hi,
while we are talking about Script-Fu and Tiny-Fu, I think we should
also bring up the question of what should happen about pygimp.
According to Yosh quite some build problems could be solved by having
pygimp in it's own source tree. The idea is to use a typical Python
build setup instead of a
Hi,
Sven Neumann wrote:
> Why wouldn't that be the case any longer? It would only be packaged
> in a separate source tree. Of course every GIMP installation would
> include it.
How would you enfore the dependency? I don't understand how
removing script-fu from the source tree and having it presen
Hi,
David Neary <[EMAIL PROTECTED]> writes:
> > Why wouldn't that be the case any longer? It would only be packaged
> > in a separate source tree. Of course every GIMP installation would
> > include it.
>
> How would you enfore the dependency? I don't understand how
> removing script-fu from the
Hi Sven,
Sven Neumann wrote:
> If we want to get rid of
> the Script-Fu dependency in the long run, then we need to make it
> optional at some point. Now seems to be a good time to do that. It
> would allow people who want to switch to Tiny-Fu to install GIMP w/o
> Script-Fu while the vast majorit
Hi again,
Sven Neumann wrote:
> I am not going to allow the source tree
> to be clobbered with more stuff simply because we are too lazy to add
> some simple notes to our web-site and FTP server. In the long run we
> will want to split GIMP into even more packages.
On another note, I'm not sure t
Hi
I am a relatively new user of the GIMP and am experimenting with writing my
own plug-ins. I am still having trouble working out when it is most
appropriate to use layers and when to use channels. I understand that
channels are to do with RGBA values, but I have discovered that sometimes it
is
Hi,
David Neary <[EMAIL PROTECTED]> writes:
> It's not just a documentation issue. The fact that perl-fu has
> been moved out of the source tree is pretty well documented.
It is what? Well documented? I don't think so. You already mentioned
yourself what would have to be done to document this pr
Hi,
David Neary <[EMAIL PROTECTED]> writes:
> On another note, I'm not sure this is a desirable goal. splitting
> stuff off feels an awful lot like putting it out to pasture. The
> goal of just having the core application, with no plug-ins, no
> image data structures, no scripts, and a minimum nu
Hi,
Cathy Irwin <[EMAIL PROTECTED]> writes:
> I am a relatively new user of the GIMP and am experimenting with
> writing my own plug-ins. I am still having trouble working out when
> it is most appropriate to use layers and when to use channels. I
> understand that channels are to do with RGBA
Sven Neumann wrote:
> Channels are
saved selection masks. They consist of what could be seen as grayscale
data and are used to store the selection. The top three or four
"channels" that you see in the Channels tab in the user interface
aren't really channels. They just appear there for historical
r
Hi,
"Adam D. Moss" <[EMAIL PROTECTED]> writes:
> I bet to differ -- the top three or four 'channels' ARE channels,
> and the rest AREN'T. The rest are, as you describe, 'saved selection
> masks'. I guess they're historically in the same dialog because
> Photoshop liked to pretend that saved sel
Sven Neumann wrote:
> I am not going to allow the source tree
> to be clobbered with more stuff simply because we are too lazy to add
> some simple notes to our web-site and FTP server. In the long run we
> will want to split GIMP into even more packages.
Dave Neary wrote:
> On another note, I'm
Cathy Irwin writes:
>Can anybody point me to some documentation that explain
> the differences between the various drawables comprehensively?
At a conceptual level, the difference is very simple: A layer is a
visible part of an image. A channel is not: it is a grayscale
drawable that acts to m
Hi,
William Skaggs wrote:
> Dave Neary wrote:
> > Splitting
> > stuff off feels an awful lot like putting it out to pasture. The
> > goal of just having the core application, with no plug-ins, no
> > image data structures, no scripts, and a minimum number of brushes,
> > patterns and gradients doe
On Wed, 8 Sep 2004, Sven Neumann wrote:
> to be clobbered with more stuff simply because we are too lazy to add
> some simple notes to our web-site and FTP server. In the long run we
> will want to split GIMP into even more packages.
Slimming down the core by moving things out to other package
> On another note, I'm not sure this is a desirable goal. splitting
> stuff off feels an awful lot like putting it out to pasture. The
that does seem like a valid risk to consider
> goal of just having the core application, with no plug-ins, no
> image data structures, no scripts, and a minimum
Kevin Cozens wrote:
> Replacing Script-Fu with Tiny-Fu could help push Tiny-Fu along a bit
> (ie. with translations) if it isn't fully ready yet by exposing it to
> more users but what is in the best interest of GIMP and its users?
I'm actually quite sympathetic, but it doesn't seem to me that y
Hi,
David Neary <[EMAIL PROTECTED]> writes:
> This is what I understand Sven wants, eventually. As I understand
> it, if you're building from source, you're a developer.
> Otherwise, get the binaries, which will have everything packaged
> in. If I misunderstand Sven's point of view, I'm sure that
Hi,
Sven Neumann wrote:
> David Neary <[EMAIL PROTECTED]> writes:
> > If that's the case, we're working towards needing a jhbuild or a
> > garnome for the GIMP
[snip...]
> > If everything ended up in one tarball, with a single-step build,
> > that would be grand. But I don't believe that's the in
Hi,
David Neary <[EMAIL PROTECTED]> writes:
> If that's the case, we're working towards needing a jhbuild or a
> garnome for the GIMP, which just doesn't seem right - we're a
> desktop application, not a suite of developer libraries and
> desktop applications. We have one set of developers, not s
Hi Sven
Sven Neumann wrote:
> I don't see what's wrong with needing a jhbuild type of script to ease
> compilation (not that I have ever felt the need to use jhbuild). GIMP
> is not a desktop application. It is (or should become if it isn't yet)
> an image manipulation suite. We have several sets
hello,
long ago when i had a job and a home and friends who were gimp
developers i had an idea of a plug-in building environment.
in the time that this environment was designed, i lost all of those
things previously listed. the environment i helped to design is now
being used successfully at ora
more,
On Wed, Sep 08, 2004 at 06:02:16PM -0700, Carol Spears wrote:
>
> my experience with gimp is different than dave neary is talking about.
> he is saying that if you dont get everything at one time, you will not
> get it. when i first started to use gimp, it was so much fun to go
> online and
25 matches
Mail list logo
