Re: [Gimp-developer] glib/gtk+ 2.0 port
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
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
On Thu, Jul 26, 2001 at 12:01:35PM +0200, Michael Natterer <[EMAIL PROTECTED]> wrote: > 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. In addition, gimp is a very nontrivial application. Porting gimp before gtk-2.0 makes it possible to correct problems in gtk+, if there are any. afetr 2.0 is released it's more difficult. -- -==- | ==-- _ | ---==---(_)__ __ __ 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
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
[Gimp-developer] Small change in the "New" dialog
Hi, I hope this is the right place to post this suggestion. In the "New" dialog (Ctrl+N), there should be a image size drop-down with the following options: - (custom size) - (clipboard size) - 1024 x 468 - 800 x 600 - 640 x 480 - 468 x 60 (full banner) - 234 x 60 (half banner) - 160 x 600 (wide skyscraper) - 120 x 600 (skyscraper) - 125 x 125 (square button) - 120 x 240 (vertical banner) Changing the selection would adjust the width/height text fields with the right values automagically. Simple but effective! :) I suppose it won't take much time to implement this feature, and most developers will find it very useful. Best wishes, Nelson P.S.: Gimp is Great!!! _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Small change in the "New" dialog
Hi, I hope this is the right place to post this suggestion. In the "New" dialog (Ctrl+N), there should be a image size drop-down with the following options: - (custom size) - (clipboard size) - 1024 x 468 - 800 x 600 - 640 x 480 - 468 x 60 (full banner) - 234 x 60 (half banner) - 160 x 600 (wide skyscraper) - 120 x 600 (skyscraper) - 125 x 125 (square button) - 120 x 240 (vertical banner) Changing the selection would adjust the width/height text fields with the right values automagically. Simple but effective! :) I suppose it won't take much time to implement this feature, and most developers will find it very useful. Best wishes, Nelson P.S.: Gimp is Great!!! _ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] glib/gtk+ 2.0 port
"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
