On Thu, 26 Jul 2001 05:13:09 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said:
>because that's what they do, what gimp does, what every other project
>does.
Gimp 1.1.x, as I recall, was set up to work with any GTK 1.1.y for
sufficiently large y. We bumped y as it became necessary. The H
On Wed, Jul 25, 2001 at 04:40:41PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote:
> Why should we expect the GTK+ developers to keep their HEAD revision
> compilable at every moment?
because that's what they do, what gimp does, what every other project
does. if the head revision isn't compilable
Hi,
Kelly Martin <[EMAIL PROTECTED]> writes:
> Why can't we just use 1.3.6? That's a frozen release that should be
> reasonably close to the eventual 2.0.0 release.
who said, we couldn't do this? I do know that the current CVS HEAD works
and has some smaller improvements but that could of cour
On 26 Jul 2001 00:17:03 +0200, Sven Neumann <[EMAIL PROTECTED]> said:
>you are obviously not well informed about the current state of
>GTK+-2.0.
No, I don't _care_ about the current state of the development of an
unreleased package. We should not be using unreleased code.
Why can't we just u
Kelly Martin wrote:
>
[snip]
> If GTK stable release (1.2) is not acceptable for further development
> in the GIMP (which it probably is not), I would strongly urge picking
> a relatively stable snapshot of GTK+ current development (possibly,
> but not necessarily HEAD today) and use that. We mi
Hi,
Kelly Martin <[EMAIL PROTECTED]> writes:
> Why should we expect the GTK+ developers to keep their HEAD revision
> compilable at every moment? That is a completely unreasonable
> expectation in the first place. If I were a GTK+ developer I would be
> asking that you NOT do what you're prop
On Wed, 25 Jul 2001 22:59:11 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said:
>It's more of a social problem: do we *trust* the gtk development
>model to be stable most of the time? I did trust the gimp developers
>that they want working code as well, and it worked fine. If gtk+ is
>as ch
Hi,
Nick Lamb <[EMAIL PROTECTED]> writes:
> * Can you 100% guarantee that Gtk+ HEAD builds and runs?
> If not, every time it's red we stall work on Gimp. That's no good.
we are using it for production work every day. We are doing this for
more than half a year now and it has indeed been a probl
On Wed, Jul 25, 2001 at 03:43:51PM -0500, Kelly Martin <[EMAIL PROTECTED]> wrote:
> If you have to use a "development" version at least pick a fixed point
> in development and use that. Otherwise you're coding to not one, but
> two moving targets: your own code PLUS the moving code in the library
On Wed, 25 Jul 2001 21:41:03 +0200, <[EMAIL PROTECTED] ( Marc) (A.) (Lehmann )> said:
>There is cvs, so knowledge about "HEAD doesn't work, try last week's
>version" will spread soon through developer circles.
This qualifies as one of the worst excuses I've heard yet.
If you have to use a "dev
On 25 Jul 2001 20:12:28 +0200, Michael Natterer <[EMAIL PROTECTED]> said:
>IMHO the pro's outweigh the con's by far, as it's simply not possible
>without grand hacks to write an internal object model and a nice
>generic GUI with Gtk 1.2.
If this is the real reason, then I can understand the desi
At 20:12 25.07.01 +0200, Michael Natterer wrote:
> [..., removed everything I totally agree with]
>
>And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a
>stable version (which will be in not too distant future).
>
>IMHO the pro's outweigh the con's by far, as it's simply not
>possi
On Wed, Jul 25, 2001 at 07:43:12PM +0100, Nick Lamb <[EMAIL PROTECTED]> wrote:
> * Can you 100% guarantee that Gtk+ HEAD builds and runs?
> If not, every time it's red we stall work on Gimp. That's no good.
There is cvs, so knowledge about "HEAD doesn't work, try last week's version"
will spread
And finally... I had to address this:
Michael Natterer wrote:
> This is unstable development.
This is a fairy tale that developers like to spread
to keep the unwary users' expectations down. The reality
is that labelling the trunk an 'unstable' tree is not a
license to actively go about doing
On Wed, Jul 25, 2001 at 08:12:28PM +0200, Michael Natterer wrote:
> And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a
> stable version (which will be in not too distant future).
Yes, these sound like excellent reasons to port Gimp to Gtk+ 2.0 as soon
as possible after the Gtk+ t
Michael Natterer wrote:
> And BTW, GIMP 1.4 will be released _after_ Gtk 2.0 is released in a
> stable version (which will be in not too distant future).
I assumed nothing less.
> IMHO the pro's outweigh the con's by far, as it's simply not
> possible without grand hacks to write an internal obj
Hi,
answering both mails in one...
Kelly Martin <[EMAIL PROTECTED]> writes:
> On Wed, 25 Jul 2001 17:57:50 +0100, "Adam D. Moss" <[EMAIL PROTECTED]> said:
>
> >* What are pango and atk, and why do we suddenly require them (if
> >indeed we do)?
Pango is the font layout and rendering system use
On Wed, 25 Jul 2001 17:57:50 +0100, "Adam D. Moss" <[EMAIL PROTECTED]> said:
>* What are pango and atk, and why do we suddenly require them (if
>indeed we do)?
>* Are there compelling advantages to using CVS-GTK which outweigh the
>cons of forcing developers and users to upgrade? Is GTK 1.3 not
"Adam D. Moss" wrote:
> Is GTK 1.3
(or GTK 1.9, or 2.0, or whatever the GTK HEAD is!)
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Michael Natterer wrote:
> after some hours of torturing it with perl and some manual hacking,
> i got gimp running on current CVS glib/gtk+.
...
> (applying it means that if you want to hack or simply use gimp 1.3,
> you will need glib, pango, atk and gtk+ HEAD from CVS too).
I few questions:
*
[EMAIL PROTECTED] (2001-07-25 at 1140.55 +0300):
> > but I don't see any way of detaching the gimp process from the
> > controlling terminal so that I can background it without terminating the
> > gimp. Any suggestions, or is this a feature which may be added at a
> > later date? ;)
With control
On Tue, 24 Jul 2001, Brian Richardson wrote:
> well, I have things working, but it's a bit of a hack.
>
> What I really want to do is launch Perl-Server, running as user nobody,
> from my init scripts (I use the Perl-Server extensively in my CGI
> development). So, I put together a setuid wrappe
22 matches
Mail list logo