Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-28 Thread Sven Neumann

Hi,

Adam D. Moss [EMAIL PROTECTED] writes:

 Michael Natterer wrote:
  
  Nick Lamb [EMAIL PROTECTED] writes:
   NB I am not blind and I don't write code in Hebrew
  
  I respect your extraordinary tolerance regarding this, so please
  respect that the people actually working on a project tend to make the
  decisions.
 
 Uh, that's pretty harsh if I read it right.  Nick is a seasoned
 and consistant GIMP contributor.

right, but the statement he made was unacceptable. I'm in no way a friend
of political correctness, but I didn't believe my eyes when I read this
sentence. Mitch probably overreacted here, but be assured that I wouldn't 
have found nicer words.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-28 Thread Sven Neumann

Hi,

Simon Budig [EMAIL PROTECTED] writes:

 Ok, I think we had a lot of arguments now. Could we try to agree on the
 following:
 
   1) Currently Gimp CVS depends on Gtk+ CVS, because the improvements
  made in Gtk+ CVS (over 1.3.6) are very important for the lead
  developers.
 
   2) When the first release of GTK+ with the fixed api appears
  (aka 1.3.7) Gimp CVS will depend on the earliest possible
  GTK+-Tarball.
 
   3) When a bug in all GTK+-tarballs *massively* disturbs the GIMP
  developers and this bug is fixed in CVS we could make an exception
  to rule No. 2. However, this should be discussed on the Mailinglist.

Yes, please.

I don't understand why the discussion about depending on the CVS HEAD 
version of GTK+ came up in the first place. Of course we will try our
best to be compatible with a GTK+ developers release. Noone will have
to recompile his GTK+ each day just to take part in Gimp development.
I wonder what made Kelly think this would be the case. It's probably 
bad experience with GTK+ ports back in the old days. GTK+ development
as it happens now is a very strictly organized process and I'd say we
can take the risk to trust Owen  Co.

I do believe that after the port is finished (very soon now) it will 
be much easier to work with the GIMP code. Large parts of the core will 
not even be dependant on GTK+ and the clean separation between different 
parts of the core will make it easier for one developer to concentrate 
on hacking on just one of those parts. This alone should make it way 
easier for developers with limited time to participate.


Salut, Sven


PS: I would like to mention that we all have to work for a living and 
noone of us can spend 120 hours a week on GIMP development.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Malcolm Tredinnick

On Fri, Jul 27, 2001 at 02:12:05AM +0100, Nick Lamb wrote:
 On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote:
  For CVS gimp, it is definitely not a problem to require the current
  bleeding edge GTK.
 
 Malcolm did you ask me first? If you didn't, how did you come to the
 conclusion that it wouldn't be a problem for me (a developer, even if
 not one who's able to dedicate many hours to Gimp right now) to
 install and tend a GTK+ HEAD tree just to keep my Gimp builds green?

Get a grip! I'm not the one making the decision; what I posted was an
opinion.

That said, if you want to do development and gimp chooses to track
gtk+'s main branch, then there is a once off effort to get the gtk setup
working and port your stuff. Then it's minor updating and rebuilding.
For many months now I, personally, have not had problems keeping a gtk+
CVS installation running for my development work. They are in API freeze
(more or less) now, so things are only going to get better.

 How will this make things better for me?

Apparently you've decided it won't. Deal with it.

NB I am not blind and I don't write code in Hebrew

So pango is not included specifically for you. You are lucky. However,
the i18n team will make use of pango to get decent display and widget
layout. I admit that a visually impaired version of the Gimp would be,
well, interesting, but a version allowing alternate input methods would
be useful (e.g. somebody who cannot use their hands). Incorporating
these toolkits means that _other_ people can come along and make your
plugins work well for everybody.

Malcolm

-- 
How many of you believe in telekinesis? Raise my hand...
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Seth Burgess

As an occasional developer, I ran into a problem trying to get CVS pango
working - errors on link with the qt libraries.  Anyone else expereienced
these?  Not at my machine now, or I'd include the errors.   

I didn't see any obvious switches in the configure.  I'm a bit annoyed that qt
is keeping me from compiling gtk...

Seth

--- Malcolm Tredinnick [EMAIL PROTECTED] wrote:
 On Fri, Jul 27, 2001 at 02:12:05AM +0100, Nick Lamb wrote:
  On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote:
   For CVS gimp, it is definitely not a problem to require the current
   bleeding edge GTK.
  
  Malcolm did you ask me first? If you didn't, how did you come to the
  conclusion that it wouldn't be a problem for me (a developer, even if
  not one who's able to dedicate many hours to Gimp right now) to
  install and tend a GTK+ HEAD tree just to keep my Gimp builds green?
 
 Get a grip! I'm not the one making the decision; what I posted was an
 opinion.
 
 That said, if you want to do development and gimp chooses to track
 gtk+'s main branch, then there is a once off effort to get the gtk setup
 working and port your stuff. Then it's minor updating and rebuilding.
 For many months now I, personally, have not had problems keeping a gtk+
 CVS installation running for my development work. They are in API freeze
 (more or less) now, so things are only going to get better.
 
  How will this make things better for me?
 
 Apparently you've decided it won't. Deal with it.
 
 NB I am not blind and I don't write code in Hebrew
 
 So pango is not included specifically for you. You are lucky. However,
 the i18n team will make use of pango to get decent display and widget
 layout. I admit that a visually impaired version of the Gimp would be,
 well, interesting, but a version allowing alternate input methods would
 be useful (e.g. somebody who cannot use their hands). Incorporating
 these toolkits means that _other_ people can come along and make your
 plugins work well for everybody.
 
 Malcolm
 
 -- 
 How many of you believe in telekinesis? Raise my hand...
 ___
 Gimp-developer mailing list
 [EMAIL PROTECTED]
 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


__
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Lourens Veen

Alright, this is turning into a flamewar and that's the least productive
of all. Let me try to wrap up this discussion:

The question: Will the gimp-1.3 developer releases depend on Gtk-1.3
HEAD CVS, or do we make certain every gimp-1.3.x release compiles with
gtk-1.3.y?

Arguments for depending on HEAD:

- The Gtk-1.3 API is frozen, so using the latest won't break anything,
it will only be better code
- These releases are for developers only, normal users don't need to
have anything to do with CVS.
- Gtk will be tested well prior to release, avoiding the possible need
of major changes after release of Gtk-2.0.

Arguments against depending on HEAD, and just using the latest Gtk-1.3.y
release to work with:

- Gtk HEAD may not always compile, making it difficult for users to try
out the development releases in the gimp-1.3 branch
- If there are major advantages of CVS HEAD over the latest development
release they will probably do a new release anyway, and besides, this is
unlikely as Gtk-2.0 is late in its development cycle already.

I might have missed one or two arguments, apologies in advance if that's
the case.

I think we need to ask ourselves why users would want to try the latest
developer releases of Gimp. If they want to have the latest because of
having the latest, I don't think they'll mind getting CVS HEAD branches
and weeding out possible compile problems. But I think for gimp-1.1
there was a different reason. Gimp-1.1 had a whole lot of features that
weren't in gimp-1.0. In fact, to me (as a user) Gimp-1.1 was a good
graphics program, while Gimp-1.0 was hopelessly limited.

So my question is, will Gimp-1.3/2.0, in the early stages of
development, add much functionality? It seems to me it won't be an
advantage, as for now it's basically the functionality of gimp-1.2 with
a whole new implementation. But if there are no functional advantages
the average user will be happy to keep using 1.2 for a while (I know I
will at least). So in that case, it doesn't really matter, as long as
the developers are happy.

Once gimp-1.3 actually starts being a useable graphics package with more
features than gimp-1.2 I think we need to worry about users being able
to compile things easily, and I do believe simply depending on a fixed
Gtk-version (which will then probably be at 2.0.x anyway) is a part of
that.

As for pango and atk, if I understand correctly they are simply part of
Gtk-2.0, or at least standard companions to it. In that case why not use
them? I'm sure there are gimp-users in Israel who'd like a Hebrew
translation, and if that work is done already by the pango developers,
why not make use of it? With Gtk-2.0, people will have it anyway. The
same goes for atk.


Please, try hitting the ball and not your opponent. It's not a nice
thing to do, and given that your opponent is on your own team, pretty
stupid as well.

Lourens
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Adam D. Moss

Michael Natterer wrote:
 
 Nick Lamb [EMAIL PROTECTED] writes:
  NB I am not blind and I don't write code in Hebrew
 
 I respect your extraordinary tolerance regarding this, so please
 respect that the people actually working on a project tend to make the
 decisions.

Uh, that's pretty harsh if I read it right.  Nick is a seasoned
and consistant GIMP contributor.

--Adam
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Lourens Veen

Kelly Martin wrote:
 
 Think plugin authors.  These people are going to want to start
 working on porting their plugins to 2.0 well in advance of 2.0's
 release but are not likely to want to cope with being GTK debuggers on
 top of being GIMP debuggers.
 
 Kelly

I may be misunderstanding, I'm not a project expert, but if the Gtk API
is frozen, the only difference between the CVS HEAD branch and the
latest developer release is bugfixes right? So then there should be
actually less bugs in the CVS HEAD. The only risk you are running is of
it not being compilable, well, as we saw today, that might happen with a
release as well ;).

In the end it's a matter of trusting the Gtk developers, or rather the
CVS maintainers. Do we trust them not to break things too often, and if
the compile is broken, fix it quickly.

I have no experience with the Gtk CVS, so I can't say anything about it.
Maybe we should ask them?

Lourens
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Kelly Martin

On Fri, 27 Jul 2001 22:18:32 +0200, Lourens Veen [EMAIL PROTECTED] said:

I may be misunderstanding, I'm not a project expert, but if the Gtk
API is frozen, the only difference between the CVS HEAD branch and
the latest developer release is bugfixes right? So then there should
be actually less bugs in the CVS HEAD. The only risk you are running
is of it not being compilable, well, as we saw today, that might
happen with a release as well ;).

99 bugs in the code, in the code.
 99 bugs in the code.
 Fix one bug, compile again.
 100 bugs in the code, in the code.

Bugs get introduced during debugging quite frequently.  Sometimes they
things get worse before they get better.

In the end it's a matter of trusting the Gtk developers, or rather
the CVS maintainers. Do we trust them not to break things too often,
and if the compile is broken, fix it quickly.

It's not a matter of trust.  It's a matter of recognizing that the
development branch is under development and may break at any time.
Rather than trusting the GTK developers not to break the head branch
of their development code, we should simply abstain from demanding
that promise from them in the first place.  I don't want them going
Well, we can fix this bug the right way or the wrong way, but the
right way will probably break something those GIMP people are doing
and the wrong way won't.  And we promised not to break their stuff.
I want them to be able to do the right thing and not have to worry
about whether that inconveniences us for a few hours, days, or weeks.

Kelly

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Simon Budig

Kelly Martin ([EMAIL PROTECTED]) wrote:
 On Fri, 27 Jul 2001 22:18:32 +0200, Lourens Veen [EMAIL PROTECTED] said:
 I may be misunderstanding, I'm not a project expert, but if the Gtk
 API is frozen, the only difference between the CVS HEAD branch and
 the latest developer release is bugfixes right?
 
 No, because the HEAD branch could contain preliminary attempts at
 bugfixes that don't actually fix the bug or which introduce new bugs.
 I expect things like that to appear (and subsequently disappear) from
 time to time on the development head.  In my experience, a bugfix will
 appear on the head branch once the developer who found the bugfix has
 verified that the code compiles with the fix and appears to fix the
 bug, but before the bugfix has been thoroughly tested by other
 developers.  

Ok, I think we had a lot of arguments now. Could we try to agree on the
following:

  1) Currently Gimp CVS depends on Gtk+ CVS, because the improvements
 made in Gtk+ CVS (over 1.3.6) are very important for the lead
 developers.

  2) When the first release of GTK+ with the fixed api appears
 (aka 1.3.7) Gimp CVS will depend on the earliest possible
 GTK+-Tarball.

  3) When a bug in all GTK+-tarballs *massively* disturbs the GIMP
 developers and this bug is fixed in CVS we could make an exception
 to rule No. 2. However, this should be discussed on the Mailinglist.

Personally I think it would have been nice, when the port to the new
api had been happened after the release of GTK+ 1.3.7. However, I don't
think, reverting the port now is necessary.

Maybe we could ask the GTK+-Team for the 1.3.7 - release? I am a little
bit astonished that this has not yet happened.

And please stop getting personal.

Bye,
Simon
-- 
  [EMAIL PROTECTED]   http://www.home.unix-ag.org/simon/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-27 Thread Michael Natterer

Adam D. Moss [EMAIL PROTECTED] writes:

 Michael Natterer wrote:
  
  Nick Lamb [EMAIL PROTECTED] writes:
   NB I am not blind and I don't write code in Hebrew
  
  I respect your extraordinary tolerance regarding this, so please
  respect that the people actually working on a project tend to make the
  decisions.
 
 Uh, that's pretty harsh if I read it right.  Nick is a seasoned
 and consistant GIMP contributor.

Yes, this was an overreaction and *slightly* too personal.

My apologies for that.

The statement about neither being blind nor coding in hebrew was
just too beyond a serious discussion and hit me in a bad mood :)

ciao,
--Mitch
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-26 Thread Michael Natterer

Adam D. Moss [EMAIL PROTECTED] writes:

 We had an adequately generic GUI and most users couldn't
 give a whit about the internal object model, but I can
 see an attraction to hackers.

Well I find GIMP 1.2's UI not at all generic. The whole GIMP is a huge
pile of global variables and dialogs which are not generic views but
are hardcoded each-for-each, requiring making the same error-prone
changes to many files at the same time if something has to change.

   * For those of us with pieces of the tree's core which diverge
   somewhat from the trunk, how much of a no-brainer is converting our
   code to GTK 1.3-isms?
  
  The changes made for 2.0 migration are much less of a structural change
  than what happens in two weeks of usual HEAD-reorganizing. Not a single
  file was moved and almost only the object stuff was touched.
 
 It was an honest and straightforward question, not a
 rhetorical one; what is involved?  Are the changes largely
 syntactic, or deeper?

Ok, I simply got it wrong. Porting to GLib2 is totally straightforward.
If there are no selfmade objects or widgets involved, it's almost 100%
source compatible, so code will compile smoothly (except for a few warnings
because glib/gtk+ return much more const string now).

Porting code which only uses the object model can be done step-by-step as
there are compatibility wrappers around the new GLib object ans signal stuff.

It's mostly:

gtk_signal_connect()- g_signal_connect()
gtk_signal_connect_object() - g_signal_connect_swapped()
gtk_signal_connect_while_alive()- g_signal_connect_object(..., 0)
gtk_signal_connect_object_while_alive() - g_signal_connect_object (..., 
G_CONNECT_SWAPPED)

This is the olny change in Gtk user code that actually needs thinking
because g_signal_connect_object() does NOT correspond to
gtk_signal_connect_object()

Everything else is mostly like s/gtk_object_ref/g_object_ref/,
s/GTK_SIGNAL_FUNC/G_CALLBACK/

Objects and Widgets however need manual hacking, not just sed/perl voodoo.
After porting some of them, it takes about 10 minutes each.

  What's a no-brainer BTW ?
 
 Something that does not require brain.  =)

Hehe, true. Most of this stuff is slave work :-)

  After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's
  bleeding edge version? This is unstable development.
 
 No, I *really* don't see the logic there at all.  That's
 bleeding for bleeding's sake.  GTK took a life of its own
 millenia ago and their destinies are no longer entwined.

You're right, this is not an argument. I said this _after_ explaining things.

Porting GIMP to Gtk2 will need a substantial amount of time and hacking
and if we'd start it _after_ GTK 2.0 is final, we will need another 12-24
months until it's stable.

IMHO porting it now was 100% right at this point of time, otherwise
the goal of releasing GIMP 1.4 by the end of this year cannon be reached.

 But the deed is done.  :)

Yes.

ciao,
--Mitch
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-26 Thread pcg

On Wed, Jul 25, 2001 at 11:18:58PM -0500, Kelly Martin [EMAIL PROTECTED] wrote:
 sufficiently large y.  We bumped y as it became necessary.  The HEAD
 revision was only occasionally required, and usually only for a short
 time until GTK+ released a new unstable version.

so what? nobody requires the head revision all the time. please calm down!
if you think about then you'd see that requiring the head revision as
you interpret it makes no sense.

 I don't know what every project you've worked on.

Probably because I didn't mention any. Why should I? Am I required to work
on a project before I can tell which libraries they use?

 This is a completely INSANE model for any project of any size that wants
 to actually get anything done.

It works fine, thank you. Do you have any _reasons_ to object, apart from not
personally liking that model?

 (Of course, project leadership in most open-source projects is almost
 completely nonexistent

You really escape me here. Project leadership is quite strong in most
open-source projects IMHO. Gimp is the exception, and worked exceptionally
well so far. To the contrary, many projects with strong leadership (glibc,
gnome, even gcc althoguh I am not that sure about strong leadership ;) had
a lot of problems. Look at all the BSD projects.

 reason why GIMP development has to be that way.  It wasn't in 1.0, at
 least.  I wasn't as involved in 1.2.)

I don't think the pre-1.0 development model (if you could call it a
model) is a goal to go for, actually.

  if the head revision isn't compilable nobody can wotk with it.
 
 Which is precisely why GIMP developers should not rely on it.  GIMP
 developers are developing GIMP, not GTK+.

GTK+ is gimp's toolkit, and breaking ties even more than already is the
case is a bad thing for both projects.

 If an individual developer WANTS to work with the head revision,
 that's fine, but development should not REQUIRE it,
   
why?
   
 should be wary of introducing dependencies on features not yet
 stabilized.

why do you think they aren't? why do you not trust mitch?

 You should require the OLDEST version that suffices, not
 the newest.

but that might well be the current head revision. your logic is this: we
could write gimp using motif and it is stable. let's not move to gtk.
progress can only be made by using newer gtk and esp. glib versions. what
yo you expect from developers: develop a second glib because glib itself
is not released yet, or just plain WAIT until it comes out so they cna
finally make progress?

 usage of GTK+.)  Application authors should NEVER assume that their
 users like to live on the cutting edge.

Are you remotely aware of the fact that we are talking about development
versions here? Obviously not. EVERY free software project progresses by
using other people's work. Otherwise linux would still require gcc-2.5.2,
gimp would sitll require motif and Xfree would still have no 3d.

 Most users do not.

Most users use unstable alpha versions of gimp? Hello?

 upgrade the Linux systems that I'm paid to maintain when something
 breaks, and we should not force users to upgrade a nonbroken library
 unless the upgrade provides essential (or at least strongly desirable)
 functionality.

Hello? Development version?

 totally unreasonable to expect non-compilability on a regular
 base. How often couldn't you compile gimp-1.1.2x?
 
 I broke 0.99.x and 1.1.x on several occasions. 

Too bad. Nobody would veer had found out if there weren't some savy users
out there who, indeed, like to be on the cutting edge and used unstable
development versions of gimp.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-26 Thread Malcolm Tredinnick

On Wed, Jul 25, 2001 at 05:57:50PM +0100, Adam D. Moss wrote:
 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:
 
 * What are pango and atk, and why do we suddenly require them (if
 indeed we do)?

Pango is the text layout foundation for gtk (to abuse terminology
slightly). It provides a uniform way to do things like multi-lingual
layouts (coupling left-to-right and right-to-left text using different
character sets on the same line). This may not seem like such a huge win
for gimp, but it is a necessary requirement for Gtk 2.0 now.

The atk package is the accessibility toolkit and provides ways for
non-visual and non-keyboard/mouse interaction with gtk-based
application. This is one of the concrete results of Sun's input into the
Gnome community. They both advocated the need for such an elephant and
produced the code.

 * Are there compelling advantages to using CVS-GTK which outweigh
 the cons of forcing developers and users to upgrade?  Is GTK 1.3
 not backwardly compatible with the GTK 1.2 API?  My concern is
 that with such a casual-user oriented application as GIMP we
 can easily lose users by the wayside with each additional
 stipulation.

Gtk 1.3 is the development branch, so it can't be relied upon for
release verisons of other software. It will eventually metamorph into
Gtk 2.0, which will be the stable branch. It has never been a secret
that this will not be backwards compatible with Gtk 1.2. If you look in
the gtk source code, there is a file called Porting-2.0.txt (or
something like that) that explains the changes needed to go from 1.2 -
1.3/2.0 to make an application simply run. This does not cover the new
gee-whiz features that have been added to the 1.3 branch -- it is simply
a porting guide. The required changes are reasonably mechanical and not
overly difficult (based on my experience of porting about four apps so
far).

For CVS gimp, it is definitely not a problem to require the current
bleeding edge GTK. Casual users should not be using this if they are not
interested in tracking dependencies. When Gtk-2.0 is released, it will
be rapidly shipped with all the distributions and requiring/requesting
users to upgrade should not be an issue.

Until that time, it would be crazy for 1.2 versions of the Gimp to
depend on this version of gtk, since it is still only in slightly-frozen
API stages and many bug fixes, etc are still occurring.

 * For those of us with pieces of the tree's core which diverge
 somewhat from the trunk, how much of a no-brainer is converting
 our code to GTK 1.3-isms?

Read the porting document i mention above. It's not that difficult --
truly just search and replace in most cases.

Cheers,
Malcolm

-- 
Quantum mechanics: the dreams stuff is made of.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-26 Thread Nick Lamb

On Thu, Jul 26, 2001 at 01:27:59AM -0400, Malcolm Tredinnick wrote:
 For CVS gimp, it is definitely not a problem to require the current
 bleeding edge GTK.

Malcolm did you ask me first? If you didn't, how did you come to the
conclusion that it wouldn't be a problem for me (a developer, even if
not one who's able to dedicate many hours to Gimp right now) to
install and tend a GTK+ HEAD tree just to keep my Gimp builds green?

How will this make things better for me?

NB I am not blind and I don't write code in Hebrew

Nick.
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Adam D. Moss

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:

* 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 backwardly compatible with the GTK 1.2 API?  My concern is
that with such a casual-user oriented application as GIMP we
can easily lose users by the wayside with each additional
stipulation.

* For those of us with pieces of the tree's core which diverge
somewhat from the trunk, how much of a no-brainer is converting
our code to GTK 1.3-isms?

Ta,
--Adam
-- 
Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/   co:3
But one of the funny things with very pretty girls is that ... men
think they won't have a chance with them, so they don't ask them out.
I do ask.  And... quite often, they come out with me.  Probably out of
curiosity, or something. -- Sir Clive Sinclair
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Adam D. Moss

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



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Kelly Martin

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
backwardly compatible with the GTK 1.2 API?  My concern is that with
such a casual-user oriented application as GIMP we can easily lose
users by the wayside with each additional stipulation.

* For those of us with pieces of the tree's core which diverge
somewhat from the trunk, how much of a no-brainer is converting our
code to GTK 1.3-isms?

I would add:

* are there Windows versions of pango and atk?
* do we reasonably expect Windows ports of the HEAD versions of all of
  these libraries before 1.4 is released?

Kelly
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Michael Natterer

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 used by gtk+. It allows
for fancy stuff like bidirectional text and makes an end to the X font
mess. ATK is the accessibility toolkit which allows e.g. voice control
of programs.

Both are required by gtk+ HEAD and everything compiles 100% smoothly
most of the time.

 * Are there compelling advantages to using CVS-GTK which outweigh the
 cons of forcing developers and users to upgrade?  Is GTK 1.3 not
 backwardly compatible with the GTK 1.2 API?  My concern is that with
 such a casual-user oriented application as GIMP we can easily lose
 users by the wayside with each additional stipulation.

There are lots of advantages with Glib/Gtk 2.0. One of them is the
clean core/ui separation they provide because the object system
has been moved to GLib. We get sane Xinput support and support for
new platforms (because GDK is frontend/backend separated now).
We get a much improved object system, better looking widgets, better
user preferences for widgets classes. We can strip tons and tons
of evil hacks because we also get rid of lots of gtk 1.2 brokenness.

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
possible without grand hacks to write an internal object model
and a nice generic GUI with Gtk 1.2.

The biggest pro of GLib 2.0's object system is it's great degree
of dynamism which will bring us e.g. pluggable tools almost for
free.

Also, it will simply not be possible to include a Gtk+ header from
app/core/, which is great for enforcing core/ui separation.

 * For those of us with pieces of the tree's core which diverge
 somewhat from the trunk, how much of a no-brainer is converting our
 code to GTK 1.3-isms?

The changes made for 2.0 migration are much less of a structural change
than what happens in two weeks of usual HEAD-reorganizing. Not a single
file was moved and almost only the object stuff was touched.

Gtk 2.0 is _very_ source compatible compared to Gtk 1.2 except for the
object system (which is much more consistent and powerful than before)

What's a no-brainer BTW ?

 I would add:
 
 * are there Windows versions of pango and atk?
 * do we reasonably expect Windows ports of the HEAD versions of all of
   these libraries before 1.4 is released?

This is a misunderstanding: _only_ GLib/Gtk 2.0 exist for windows, the
current hack to compile GIMP for windows with a Gtk 1.3 snapshot which
is almost a year old is the reason for all those windows bugreports.

Pango and ATK of course compile under windows and the folks porting GIMP
to windows will love to use a sane version of Gtk.

After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's
bleeding edge version? This is unstable development.

ciao,
--Mitch
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Adam D. Moss

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 object model
 and a nice generic GUI with Gtk 1.2.

We had an adequately generic GUI and most users couldn't
give a whit about the internal object model, but I can
see an attraction to hackers.

  * For those of us with pieces of the tree's core which diverge
  somewhat from the trunk, how much of a no-brainer is converting our
  code to GTK 1.3-isms?
 
 The changes made for 2.0 migration are much less of a structural change
 than what happens in two weeks of usual HEAD-reorganizing. Not a single
 file was moved and almost only the object stuff was touched.

It was an honest and straightforward question, not a
rhetorical one; what is involved?  Are the changes largely
syntactic, or deeper?

 What's a no-brainer BTW ?

Something that does not require brain.  =)

 After all, isn't is just natural for GIMP HEAD to use the GIMP Toolkit's
 bleeding edge version? This is unstable development.

No, I *really* don't see the logic there at all.  That's
bleeding for bleeding's sake.  GTK took a life of its own
millenia ago and their destinies are no longer entwined.

But the deed is done.  :)
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread pcg

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
 you depend on.  Or, in this case, five.  
 
 If your goal is to make development as chaotic and difficult as
 possible, you are on the right track.

I am sorry, but what you describe is reality for most plug-in authors. Did
plug-in developers develop for gtk-1.0 and gimp-1.0 a year ago?

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 chaotic as you
think it is, it is evry bad and gimp shouldn't use the HEAD revision.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Sven Neumann

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 proposing because it creates
 pressure on them to keep their HEAD workable at all times instead of
 doing what they need to do in order to further their own development.

you are obviously not well informed about the current state of GTK+-2.0.
The announcement of the latest releases (1.3.6 is the latest, 1.3.7 should 
be out pretty soon) had the following note:

  This release is meant for:

   * Those interested in the development of GTK+. 
   * People planning to port to the upcoming GTK+-2.0 version of GTK+.

 Note: the API is mostly frozen at this point. Major API changes
 beyond the remaining open '2.0 API freeze' bugs in bugzilla are
 unlikely to occur before GTK+-2.0 is released.

Now this is about five weeks ago and the API has been frozen in the
meantime. The 1.3.7 release should give everyone a working and reasonably 
stable version to work with.

As said, we use it every day for months now and I can only vaguely remember 
the one or two days when GLib, Pango, ATK and GTK+ from CVS HEAD didn't 
built out of the box.


Salut, Sven

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Lourens Veen

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 might have to adjust
 later to any changes GTK+ makes to its HEAD after that snapshot, but
 at least we won't have to adjust to them willy-nilly as they make
 them.
 
 Kelly

Sorry for jumping into this discussion in the middle, but I happen to
have an opinion on this :). What about all the bugs in the chosen
snapshot? I mean they get ironed out during the GTK+ development, but
the Gimp developers are stuck with them during development.

Lourens
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Kelly Martin

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 use 1.3.6?  That's a frozen release that should be
reasonably close to the eventual 2.0.0 release.  Why should we
introduce this sort of instability to GIMP development when we don't
have a good reason to?  When 1.3.7 comes out, we can advance to that.
There is simply NO good reason to be dependent on the CVS HEAD, no
matter how stable the GTK developers think it might be.

Kelly
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread Sven Neumann

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 course have changed 
since I last checked (yesterday). You are probably right that we should 
suggest using a release instead of CVS HEAD.

 There is simply NO good reason to be dependent on the CVS HEAD, no
 matter how stable the GTK developers think it might be.

I think we do not really depend on it and 1.3.6 should work fine. At the
moment our configure script wants 1.3.7 which has not yet been released.
We can simply change this but I hope that anyway 1.3.7 will be out soon. 

There is a reason why we waited until the API freeze and a few weeks 
longer before we even considered starting the port.


Salut, Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer



Re: [Gimp-developer] glib/gtk+ 2.0 port

2001-07-25 Thread pcg

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 nobody can wotk with it.

 That is a completely unreasonable

It's completely reasonable ;)

 expectation in the first place.  If I were a GTK+ developer I would be
 asking that you NOT do what you're proposing because it creates

I am not proposing anything.

 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 might have to adjust
 later to any changes GTK+ makes to its HEAD after that snapshot, but
 at least we won't have to adjust to them willy-nilly as they make

As sven has said, they made an API freeze recently. That means they
are already pretty late in the development phase. I think it's totally
unreasonable to expect non-compilability on a regular base. How often
couldn't you compile gimp-1.1.2x?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer