Re: [Gimp-developer] Re: Win GIMP
On 4 Feb 2004, at 0:15, Tor Lillqvist wrote: (Cc:ing to the gimp-developer list.) [EMAIL PROTECTED] writes: I just wanted to add an SDI type view of GIMP, that way when you don't have all the floaty windows. In GIMP 2, there are already the possibilities of showing the main menu in the image window (I believe it's on by default), and of docking most other windows, so that you don't have too many floaty windows. There has also been discussion about some MDI type interface, although the main developers seem dead against it, mainly on account of that they feel this is something that should be solved using the window manager, not the application. Please check the bug database (http://bugs.gimp.org), the archives of this mailing list and perhaps anything you can find in Google. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Update
Hi, raymond ostertag wrote: Julien wrote : - french translation of main tools - english and french doc for color tools - english and french doc for the fisrt part of the filters : Blur/ color / Noise / Edge / Enhance / Generic (some filters are still not committed in CVS) - english translation for my path tool and corrections of my dialogs doc I only wrote : - doc for path tool in french, layer (not in CVS) and channel doc in french and english (And also many works on fr.po) I have looked at the changelog for the docs, and indeed between yourself and Julien, you've written over half of the English docs in there. I really do apologise for the omission - until yesterday I wasn't aware of the work ye had done. Would it be possible for the dcs team to do occasional update reports like I've tried to do over the past few months? It's easy to forget about ye, because all too often we don't look at the docs until there's a release. Roman did an update recently, and it would be nice if this became a regular feature, just to let us know who to thank :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
Hi, Branko Collin [EMAIL PROTECTED] writes: I just wanted to add an SDI type view of GIMP, that way when you don't have all the floaty windows. In GIMP 2, there are already the possibilities of showing the main menu in the image window (I believe it's on by default), and of docking most other windows, so that you don't have too many floaty windows. There has also been discussion about some MDI type interface, although the main developers seem dead against it, mainly on account of that they feel this is something that should be solved using the window manager, not the application. Please note that GIMP does MDI (multiple document interface) already, it just doesn't folllow the WiW (window in window) approach that some people seem to prefer for obscure reasons. A good window manager makes the window-in-window concept unnecessary. However if someone wanted to develop such an approach for all the poor users that are forced to use a not so advanced window manager, then it should probably be addressed at the toolkit level. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
There has also been discussion about some MDI type interface, although the main developers seem dead against it, mainly on account of that they feel this is something that should be solved using the window manager, not the application. Please note that GIMP does MDI (multiple document interface) already, it just doesn't folllow the WiW (window in window) approach that some people seem to prefer for obscure reasons. A good window manager makes the window-in-window concept unnecessary. However if someone wanted to develop such an approach for all the poor users that are forced to use a not so advanced window manager, then it should probably be addressed at the toolkit level. What Sven is saying, is that it is basically impossible to get Window in Window support working on linux. You can do it, but is sucks a whole, whole lot. On Windows, the best approach will be to add support for Window-in-Window to gtk+ our gui toolkit, as that kind of feature shouldn't be implemented in the gimp. -- Daniel pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Re: Win GIMP
Daniel Rogers wrote: A good window manager makes the window-in-window concept unnecessary. However if someone wanted to develop such an approach for all the poor users that are forced to use a not so advanced window manager, then it should probably be addressed at the toolkit level. What Sven is saying, is that it is basically impossible to get Window in Window support working on linux. Just a small precision - it is impossible to do WiW with gtk+. QT does it OK. And in fact, there is a project (I don't recall the name) which does just that - creates a window, and then embeds GIMP windows in it, using QT. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
Hi, Dave Neary [EMAIL PROTECTED] writes: Just a small precision - it is impossible to do WiW with gtk+. I woulnd't say it's impossible; it would be cumbersome though. QT does it OK. And in fact, there is a project (I don't recall the name) which does just that - creates a window, and then embeds GIMP windows in it, using QT. That project was a stupid hack and stopped working months ago. Xnest on the other hand works perfectly well for this task. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi all, Some people thought it was ridiculous to fix dates on events when we had GIMPCon at the CCC in August - after all, we haven't done that in the past, and it'll be done when it's done is almost a motto for some people around. The thing is that we did make a roadmap, though - and we've deviated from it quite a bit. But I think that without it, we wouldn't have come as far as we have in so little time. We're now on the cusp of 2.0.0, and the time has come to put some realism back in the old roadmap. We expected 2.0 before Christmas, and it looks like we will have it in February. We need to start thinking about 2.2 (not just about what we will do for it, but what we will not do). I still think we should stick with a target of the end of June for 2.2.0 - this will be a short release cycle (4 months), but the goal of the 2.2 release has not changed - we should stabilise the codebase, adding some stuff which we would have liked to have in 2.0 (but not everything that we would have liked in 2.0), and work on building the community. That means that the 2.1 series will be always buildable, always usable, (almost) always releasable (following the example of the GNOME release team, my idols). This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like. So, without further ado, here's the updated roadmap... are there any comments? Cheers, Dave. Updated GIMP development Roadmap: = Aug 6-10 2003: CCC Jan 7th: 2.0 pre1 release Jan 19th: 2.0 pre2 Feb 4th: 2.0 pre3 *** WE ARE HERE *** Feb 18th: 2.0pre4 (or 2.0 rc1) Feb 25th: 2.0.0 March 10th: 2.0.1, creation of gimp-2-0 branch March 13th: Final feature list for inclusion in 2.2.0 (prioritised) March 25th: 2.0.2 (possibly final 2.0 release) April 2nd: 2.1.0 April 16th: 2.1.1 End of April: 2.1.2, Feature freeze for 2.2 (anything on the above list that's not done isn't in 2.2) Around May 15th: 2.2 pre1 (2.1.3) Pre-releases to follow every 2 weeks. Late June 2004: 2.2.0 (just before GIMPCon) August 2004: The Great Pain - the GeGL migration. I suspect that parts of this will start in February/March, and that this will not be complete until Summer 05. Summer 05: 3.0 or 4.0 (depending on how we go about versioning). -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2 preperations for our 1st release
On Tue, Feb 03, 2004 at 08:50:27PM -0500, Daryl Lee wrote: On Tue, 2004-02-03 at 18:22, Niklas Mattisson wrote: Hey again, ... * src/toolbox/tool-*.xml should change the line Tool Call to something else. This is not correct english and I can't seem to find good translation for the words either. Has anyone considered Tool Menu Navigation? It's a bit cumbersome, but has the advantage of being fairly common usage. I have no idea how it would translate to non-English languages. I'm not sure if this is an improvement of the tool call. Don't get me wrong, but your suggestion covers only tool menu and is not very generic. This section should show the user how he uses the tool or start the dialog. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] signature.asc Description: Digital signature
[Gimp-developer] Vector-valued regularization PDE's for Image Processing
Hi, I just found this page and I thought it might be of interest to plug-in authors: http://www-sop.inria.fr/odyssee/research/tschumperle-deriche:02d/appliu/ Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Win GIMP
From: Sven Neumann [EMAIL PROTECTED] Date: 04 Feb 2004 15:08:43 +0100 Please note that GIMP does MDI (multiple document interface) already, it just doesn't folllow the WiW (window in window) approach that some people seem to prefer for obscure reasons. Every reference I've ever seen to MDI refers to window in window. I don't understand the purpose of that at all (and I happen to really detest it, in any event, since it wastes a lot of screen space). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Misnamed structure element in SFScript structure?
Daniel Rogers ([EMAIL PROTECTED]) wrote: Simon Budig wrote: IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well). I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him drop this file in that directory and invoke it and I don't have to care whats his platform and what interpreters are installed. This is, I think, really shooting ourselves in the foot. By making this choice, we are choosing to use a broken, out-of-date, scheme interpreter when _much_ superior alternatives exist, because we don't want to force installers in have to install another library. I think you missed my point. I am not advocating for script-fu over guile (or that is not my main point), I am advocating for a simple self-contained language, that is included with the GIMP sources. Lets call it Gimp-Basic. Isn't that what installers do!? Guile is specifically designed to be an extension language for applications. It is a shared library. It is a perfect replacement for the gimp's soid bundle. The problem I see with this argument is: You are turning a packaging problem into a design choice. Suppose, for example, we choose to make siod a seperate dynamically linked library (included in the gimp sources, even). What is the difference between forcing you to install soid, and forcing you to install guile? The difference of course is, that Gimp is most likely the only application using SIOD and we would have full control over the version we deliver. I have no idea how GUILE usually is distributed, I was assuming that GUILE gets distributed similiar to Perl or Python. [Assuming this is true, I might be wrong here:] When we'd use GUILE (as the Gimp-Basic) and the user uses Guile for different tasks he obviously would expect that GIMPs Guile is the same as his GUILE. Having our own Guile in the Installer would be a bad idea then, either because of e.g. Windows DLL hell or because of two different versions. The not-creating-another-depency argument is an illusion. soid is already a dependency. It is just a dependency we choose to include in the sources. Why did we do this? Is jpeglib included in the gimp source tarball? What about libppm? libpng? These are all dependencies. Should we include those in the tarball as well? Well, supposing SIOD were a library, it is perfectly natural to include SIOD, because it is not as universally available as the other libraries. Having libraries in the GIMPs tarball already has happened... It is true enough that you can argue that jpeglib is not as important as siod because you can disable the jpeg plugin on the configure command line. But this can be true for soid as well. While I don't immediatly see a ./configure option to disable script-fu, there is no technical reason why we can't have a configure option that disables script-fu. In fact, because you can disable script-fu, you cannot gaurentee that there exists a script system at all, let alone script-fu. [there used to be a dependency on the SIOD interpreter for parsing batch commandlines, but IIRC this is gone now] All true and well, but my point is: I *want* to have a scripting system that is available almost universally. And this is the reason why siod is much more important than libjpeg right now. The scripting system not necessarily has to be Script-Fu, but it did the trick for at least six or seven years now... Basically, the only real way to ensure that every single instance of the gimp has a scripting language installed is to package the gimp for every platform ourself. Not moving to something besides siod is *crippling* to our supported, which should be the best, extension language. So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates. Guile is in all ways superior to siod, and is even self contained. We could even include a version of Guile in the tarball, which is what we do now with soid anyway. I indeed would be very happy if I could write all my scripts in Python, but this is not an option, since I cannot assume that Python is available on all gimp installations. Thats why I write most of my scripting stuff in Script-Fu, and it works. Ok, sometimes it is a pain to debug (I think most of the debugging problems could be solved by evaluating errobj instead of displaying a silly see errobj message), but when the script is completed it is plug'n'play. Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the
[Gimp-developer] ANNOUNCE: GIMP 2.0 pre3
Hi all, The latest pre-release of the upcoming 2.0 GIMP is hot off the presses and available for download now at ftp://ftp.gimp.org/pub/gimp/v2.0/testing/ or from one of the mirrors listed at http://gimp.org/download.html Screenshots of some of the features available in the shiny new GIMP are at http://developer.gimp.org/screenshots.html We fixed a bunch of bugs, and we have another bunch to fix, and we're sure we haven't found them all yet. If you find any for us, please report them to http://bugzilla.gnome.org, against the GIMP product. We really do appreciate it. A special mention goes out to the GIMP Animation Package from Wolfgang Hofer, available here ftp://ftp.gimp.org/pub/gimp/plug-ins/v2.0/gap/testing/ The plug-in has recently had a 2.0 pre-release of its own. This plug-in is the best thing sinced sliced cheese. Screenshots are available (in French) at http://gimp-fr.org/html/mongimpfr/gap/gap2.html Happy GIMPing, Dave. Bugs fixed in GIMP 2.0pre3 == - 127451: Anchor floating selection when creating a text layer (Mitch) - 50649: Allow to call script-fu scripts from plug-ins (Mitch) - 132617: Improved gimp-remote behaviour (Sven) - 132036: Fixed issues with libart scan conversion (Simon) - 132041: Made info window not grab the focus (Mitch) - 132077: Redraw layer boundary when using transform tools (Mitch) - 132089: Flip tool misbehaviours (Mitch) - 132032: User interface issues with Plugin Details (David Odin) - 132145: Use default values when stroking from the PDB (Mitch) - 132162: Anchoring a floating selection on a channel (Mitch) - 132271: Mosaic filter on selections (Simon) - 132322: gimp-levels on grayscale images (Mitch) - 132329: Info window doesn't show inital values (Shlomi Fish) - 118084: Info window not updated in automatic mode (Shlomi Fish) - 132495: Positioning of glyphs that extend the logical rectangle (Sven) - 108659: Use g_spawn in postscript plug-in (Peter Kirchgessner) - 132508: Problems with path tool in Edit mode (Simon) - 132504: Fixed unsharp mask script (Mitch) - 132595: Don't draw the selection if it's hidden (Sven) - 132027: Crash in gimpressionist (Sven) - 132596: Use default values for color DND (Mitch) - 132493: Tuned Comic Logo script (Pedro Gimeno) - 132649: Allow to fill the whole selection using bucket-fill (Mitch) - 131902: Improved handling of missing tags in TIFF loader (Andrey Kiselev) - 93806: Validate script-fu input (Yosh) - 132214: Differentiate writable and readonly data directories (Mitch) - 131964: Zoom ratio problem (Simon) - 132969: Set help-id for tool on tool options dock (Mitch) - 132999: Make assembler code PIC safe (Yosh) - 119878: Use the same keyboard shortcuts in all GIMP windows (except the toolbox window) (Mitch) - 131975 - 132297: Disable some warnings while loading TIFFs (Raphael) - 129529: Add a randomize toggle to random number widget (Dave Neary) - 133099: Duplicate PDB entries problem (Mitch) - 133122: Disallow renaming of layer masks and some floating selections (Mitch) - 130118: Allow non-UTF8 characters in the GIMP home directory (Mitch) - 122026: Workaround a bug in gdk_draw_segments() (David Odin) - 133280: Remove deleted scripts from the menu (Mitch) - 133270: Replace deprecated enum values in scripts (Kevin Cozens) - 133180: Sort menu entries for save and load procedures (Mitch) - 131563: Use percentages for zoom ratios (Simon, Sven) Other contributions: Manish Singh, Tor Lillqvist, Jakub Steiner, Michael Natterer, Sven Neumann, Kevin Cozens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
