Re: [Gimp-user] get toolbox to stay on top
Bill Kenworthy wrote: Is there a way to get the toolbox to stay on top. If I am editing a window fullscreen, everytime I do something in the window, the toolbox disappears underneath. The common answer to this is this is a window manager issue. We don't actually decide where windows get placed on the screen, or how, aside from doing things properly with respect to WM hints and session properties. So you should check with your window manager to see if there is a way to indicate that a particular window will always stay on top. That said, I can't find such an option on mine... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: [Gimp-developer] GIMP at COMDEX
Hi, Henrik Brix Andersen wrote: On Thu, 2003-11-13 at 08:13, Daniel Rogers wrote: cl0kd already sent me a screenshot of gimp 1.3.x running on macos 10.3! One of the cool thing about The GIMP is that it is cross-platform. The exact same source code can be built on a variety of platforms. I often meet people who think The GIMP is a GNU/Linux-only thing - maybe it is worth mentioning that it runs on a large number of platforms? It is true that it's less stable on Win32 though... partially because of a shortage of people building it from source on that platform, yielding a smaller pool of potential bug-fixers. I regularly crash the GIMP on Win32... and crashes aren't nice for demos. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: [Gimp-developer] GIMP at COMDEX
Hi Daniel, Daniel Rogers wrote: Gimp demos. Show off some of our killer features. Any ideas as to what these might be? (layers, brushes, plugins, script-fu) He might not forgive me for this, but here's jimmac's list of user visible changes in 2.0 when compared to 1.2: http://jimmac.musichall.cz/stuff/private/gimp-2/html/index.xhtml The biggies are of course docks, the path tool, the text tool, the themability (I like showing off the small interface - do we have a big chunky interface too?), the grid, fullscreen mode, and tool contexts. There are also the colour pickers for the levels tool (amazingly useful) and GAP. But Jakub's the man to talk to about that stuff... If you're doing a general gimp demo, then the stuff that impresses people is the clone tool, selections/masks, channel layer manipulations. A good thing to do is search through your collection for a few shitty photos that you are fairly certain can be hugely improved with one technique, and then do that. Here, I'm thinking of Jakub's tutorial in Berlin where he had, for example, one image with a contre-jour, one image with a red cast at sunset, another image with the tourist walking across the wall, another with the bright red plane, and no other red in the picture, another with a good clear red-eye, etc. Tips for working with the gimp in a corporate enviroment. (examples of previous corporate help would be great). Buy a programmer to add features. Strenths of open source, weaknesses of open source. This kind of philosophical stuff is interesting, but the FSF and OSI have lots of stuff on this. But getting someone to buy a programmer for a year or two would rock. Future gimp plans (gegl, high bit depths, color management). Personally, I'd tend to avoid future plans until there's something to present. If someone asks about CMYK, pre-press, color profiles, etc then by all means go into the details, but I wouldn't include it in a presentation. Good luck in Vegas, and don't lose too much money :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] favicon
Hi, Henrik Brix Andersen wrote: On Tue, 2003-11-11 at 22:32, Bob Lockie wrote: I want to creat an icon file so that I can specify a shortcut icon in my HTML but apparently the gimp (1.2.5) I have cannot read or write (Windows?) icon files. There is a plug-in for gimp-1.2 called winicon which can load/save MS Windows .ico files. You can find it on http://registry.gimp.org/plugin?id=2223 I thought that .ico files were (more or less) BMPs with size limitations (16x16, 32x32, etc), in which case you could save your file with the extension .ico selecting the type to be BMP. Just checking that works... Yup. Works fine. You can't get transparency though - the bmp plug-in doesn't support it. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] setting Dynamic text colour
Hi, David Selby wrote: When I use dynamic text, and I need it a certain colour to match in, is there an easier way than matching by eye or adjusting the sliders individually (bit of a nightmare) There's the colour picker... I'm not sure I understand the question. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] setting Dynamic text colour
Hi, David Selby wrote: The colour picker gives me a RGBA a hex tripplet for the colour I want. Thats OK but I need to change my text colour for my dynamic text. Ah. I see. In the dynamic text dialog I hit the coloured square, get lots of sliders a colour circle, I end up moving the selector in the colour circle untill I get as good a match as I can, judged by eye. I then set the text to that colour. Its never perfect. Ignore this completely. Create a text layer black on alpha, create a second layer which you fill with the desired colour, and set the layer mode to Screen. Then merge down. Perhaps this isn't ideal, but it's what I use. You can also drag drop the colour into the text after it's rendered, after checking Keep transparency. Is there an easier way of setting the dynamic text colour. It does not have a dialog bog for a hex triplet. The dynamic text plug-in is something of a disaster. It doesn't use the standard widgets for font or colour selection, and has been deprecated in 1.3. You should use it for rendering text only, and do the colour stuff afterwards. Better for the sanity :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Bugs?
Hi, Sven Neumann wrote: David Neary [EMAIL PROTECTED] writes: The contents of the image window and the status bar are now customisable in the preferences. The %D format string gives you the dirty flag. %D* will add a * to the title if the image is dirty, %D@ will add a @. This is not very well documented at the moment... This is very well documented in the gimprc manpage. I stand corrected. There is also complete documentation in the system gimprc file. However, those are probably not places that people will go to look for docs on the preferences dialog. I think we can agree that while there are lots of docs for the preferences, there is no way to know where to look at them from looking at the preferences dialog. Perhaps context help (gimp-help project?) would help here. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] ANNOUNCE: The GIMP 1.3.21
Hi all, The next release in the development series of the GIMP, version 1.3.21, is now available for download from ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.21/ or from one of the mirrors listed at http://gimp.org/download.html This is an extra unstable release before we officially go into pre-release mode, because there are still some outstanding API changes to make for plug-in authors which we would like to set in stone for the 2.x series. This is the most stable development release we have had to date, and there are also a few very nice features which have been added since the last release. So tell your friends, get testing, and keep those bug reports coming in to http://bugzilla.gnome.org. Happy GIMPing, Dave. Overview of Changes in GIMP 1.3.21 == - Allow to save tool options as named presets [Mitch]. - Stroke paths using libart [Simon, Bolsh, Mitch, Sven, Ville] - Better looking and more accessible dockables [Mitch] - Fixes for right-to-left rendering [Sven, Mitch] - Rewritten webbrowser plug-in [Brix] - Much improved path tool [Simon, Mitch] - Export GIMP paths to SVG [Sven, Simon] - Import SVG paths as GIMP paths [Sven, Simon] - Added SVG file plug-in from librsvg and improved it [Sven] - Store new vectors in XCF [Simon, Mitch] - Allow to toggle visibility of paths in path list [Mitch] - Move tool now also moves paths [Mitch] - Some progress towards gimp-console, a gtk-less GIMP for batch mode [Mitch] - Improved Decompose/Compose plug-ins [Alexey Dyachenko, Sven] - More SIMD compositing code [Helvetix] - Right mouse buttons now also cancels paint operations [Mitch] - More internal code cleanup and documentation [Mitch, Sven] - Documented libgimpmath [DindinX] - Lots of bug fixes Other contributors: Adam D. Moss, Dom Lachowicz, Manish Singh, Jakub Steiner, Christian Neumair, Seth Burgess, Maurits Rijk, David Necas, Tor Lillqvist, Ville Pätsi -- David Neary, Lyon, France. E-Mail: [EMAIL PROTECTED] -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Coding for Gimp
Eric Pierce wrote: Forgive my naivety, but what would be a good way to plunge into some Gimp code and maybe even help out someday? We need lots of people, for everything from bug fixing to plug-in maintenance, and core development. Plug-ins are smaller, so getting into those is somewhat easier than attacking the core, although since it's been re-structured, the core is nicely objectified and readable too (except for a couple of places). Some information on getting started is here... http://mmmaybe.gimp.org/develop/ and a page I wrote for the wiki, which I hope will eventually make its way onto the website, is here: http://wiki.gimp.org/gimp/GettingStartedWithGimp This also contains lots of information on how non-programmer types can wet their feet and help out with the website, bugzilla, testing, documentation and general helping out support. For more developer type profiles, you could look here... http://developer.gimp.org Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Update on pre-release schedule
Hi all, As any of you who have been following CVS know, we have been working towards a 2.0 pre1 release for the end of this month, and there are now very few blockers to that release left. However, there are more blockers than are going to be done in the next week. So we're going to have another release (1.3.21). This should come out sometime during the next week. And the 2.0 pre1 release will be pushed back about 2 weeks, to (give or take) the 15th of October. Just to keep ye up to date, the list of blockers for the 2.0 release (which is mostly a filled out list of the things mentioned at camp), and their current status, is below. Blockers for 2.0 prereleases: - Path tool: 1) moving of strokes/paths,*DONE* 2) being able to connect two strokes, *DONE* 3) dragging on curve segments, *DONE* 4) libart stroking,Mostly done 5) im/export into files. *DONE* Text tool features missing: 1) GUI for text boxes Back-end done 2) Implementation of text transforms 3) Font list/selector improvements 4) Text outlineNot a blocker Help browser features missing: 1) Symbolic references for every core function *DONE* 2) Mechanism for cross-referencing with 3rd party *DONE* documentation 3) Registering of documentation files with the core *DONE* at startup, with references. libgimp API changes missing: 1) libgck must die *RESOLVED* 2) Thumbnail API exposedNeary done 3) libgimpmisc API changes 4) gimp_dialog_new () 5) 64 bit clean libgimp All in all, on that list there are 2 or 3 worrying things that might not be done in 2 weeks time, but most of them look like they will be done by then. We do need to clean up Bugzilla a little again. There are now 75 bugs with milestone --, it would be nice to get these sorted to the right place before we hit pre-releases. http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=REOPENEDtarget_milestone=---cmdtype=doitorder=%27Importance%27form_name=query There are also 159 bugs open against the 2.0 release (milestone 1.3.x or 2.0). We need to start reducing this number now. So if you have a little spare time, please have a look at these bug reports, either to help close them or to reduce the amount of time needed to fix them. http://bugzilla.gnome.org/buglist.cgi?product=GIMPbug_status=UNCONFIRMEDbug_status=NEWbug_status=ASSIGNEDbug_status=NEEDINFObug_status=REOPENEDtarget_milestone=1.3.xtarget_milestone=2.0cmdtype=doitorder=%27Importance%27form_name=query Thanks for your time, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: [GUG] IE chokes on Gimp-created jpegs
Hi, Carol Spears wrote: I am forwarding this to the gimp-user list. Without looking too closely at this, it doesn't seem like the same issue. The only thing we add to jpegs now that we didn't before (or rather, that we don't remove, whereas we did before) is an exif header. This doesn't seem to break on IE 6 for me. An XML type header implies more something like IPTC or XMP, which the GIMP doesn't do. Also the fact that this is in the GIMP 1.2.4 and later implies more funny stuff - between 1.2.3 and 1.2.4, the jpeg plug-in only changed 4 times, and in each of those changes, there were only very small changes which don't affect the data written to the file at all. Perhaps the jpeg plug-in on Win32 got more of a going over, though... In any case, I will commit a patch this evening to allow you to throw away exif data, even if it's present. Just in case that'll help. Cheers, Dave. Keith and Cecile wrote: a bug I've found. Images I've created on Gimp 1.2.4 for Windows and saved as jpegs hang MSIE when downloading from a web server. The problem is the same as what is being described here: http://www.photo.net/bboard/q-and-a-fetch-msg?msg_id=003j8d about Photoshop 7 images. I resaved the images as gifs and the problem disappears, but the file sizes are about 5x larger. Has anyone found/reported this bug? Is there any way to tell Gimp not to send the information that chokes IE? Is the problem fixed in 1.3.20? -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: [GUG] IE chokes on Gimp-created jpegs
Carol Spears wrote: My gut instinct is to throw out IE. :) Not always an option, unfortunately. Would it be possible to get a jpeg that does this to IE 6 so that I can have a look at it? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: CinePaint and Film Gimp
Hi Robin, Robin Rowe wrote: Despite the code reuse in some areas, CinePaint and GIMP are actually diverging. CinePaint has a very different vision for the future than GIMP. We're pulling in features that further our mission, rejecting others as irrelevant, and building new designs that have no counterpart in GIMP. That's somewhat unfortunate - perhaps you guys are having some problems that we've already solved or thought about, and we can get talking? CinePaint won't go back to being Film Gimp and can't ever rejoin the GIMP project. That irreversible decision was made -- or not made according to Sven -- in 2000, long before I came on the scene. GIMP misplaced three man-years of Hollywood-funded open source work. That's an immense amount of time and money to lose, especially for an open source project. There can be no going back. Please, stop repeating this myth as if it were fact. Yes, some people were employed to work on the gimp, and yes, much of the work they did was not integrated into the gimp core. There, I said it, we can agree. Now, for the good of both our projects, and for inter-project relationships, please stop saying it. It really doesn't help matters. Actually, a lot of lessons were learned while doing HOLLYWOOD which have now been absorbed into gegl's design by calvin and yosh. While there was no conscious decision not to integrate the code, there was perhaps an unconscious decision (if such a thing exists) that there was a better way to do things. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: CinePaint and Film Gimp
Hi Marc, Michael, Calm it down a bit. Marc A. Lehmann wrote: On Tue, Sep 16, 2003 at 10:33:39AM -0500, Michael J. Hammel [EMAIL PROTECTED] wrote: Obviously I did my homework better than you for example. No, I don't hate boards. I hate people who argue unfarily (like you, this is not the first ad hominem argument). Can't you just keep to non-personal arguments? I think that you're probably more guilty of going ad hominem in here Marc. That said, both of ye are going to wake the children. No one is going to get the rights to the code if its under the GPL. It's called copyright, and the GPL is based on it. Please do a little research on that topic and you'll see that you are wrong. It was made clear at camp that many coders weren't prepared to hand over copyright, no-one can force them to, I wouldn't ask them to. And having a steering committee or a board or whatever you want to call it wouldn't change that. This sounds like FUD. Yes, because you don't understand the GPL and how it works, it seems. Also, it's not me who is constantly spreading FUD here, but you :( Actually, it did sound like fud. The implication was Board = you sign over copyright on your code. This is not the case. You now seem to be saying Board + GPL = you sign over your copyright, and that's incorrect too. Perhaps I'm misunderstanding you though. Well, you are mixing up board, foundation, central authority all the time. It's difficult to argue with somebody who constantly changes his propositions. central authority is quite a different concept as board is, for example. Actually, Michale seems to be implying that a board/steering committee would be a central authority and a face on the project. I think this is correct. You are saying that this type of central authority might not be desirable. I think you're probably right too, certainly with respect to several of the current developers. For me, foundation and board are the same thing - the foundation is the organisation, the board are its elected representatives. That board can have as much or as little responsibility as its members decide. It can also evolve to fill needs as they arise. That is why we decided to create the gimp foundation and elect a board (as a public face to the gimp), while at the same time having rules sufficiently wide that the board could eventually, if it were felt reasonable, be a steering committee for the project, or ake release schedules, etc. But that was not the intention when creating the foundation, and any such change would probably need to be debated at a conference. I'll bring the boxing gloves. By lighting the fire of interest in the non-technical community that often sparks motivation and interest in the project itself. Well, at least in the case of the gimp, interest is extremely high in the non-technical community, in case you missed that. And again: how does that help the developers? As you said earlier, Marc, XFree is losing developers, and new ones aren't coming in. I think that a few of the ideas we had at camp which are now being put in place will help with that, but we also need more people involved in the project. More non-technical people means more time for the technical people to do other stuff. It also means more future technical people, as the non-techs start working and get a bit braver :) Well, that works fine. Remember the big discussion about the 2.0 version number exactly because directions and plans on development _have_ been known outside the dveeloper community? Actually, most of that discussion stayed inside the developer community. The fact that there was a fight was bigger news than the version change itself. This is exactly what is wrong about the idea. A foundation (like the one that is planned), as a mere instrument to collect money, maybe do publicity or similar tasks, is quite fine. It's when people want to take the power away from the developers where I say no. A steering committee (which is what we all seem to be talking about, albeit with different names) is usually developer driven. It would not make sense to have it any other way, as you rightly say. If we look at gnome, there are several committees - the foundation board, the release team, the web team, the i18n project, the bugsquad, all of whom have their own domain of knowledge and competency The foundation board benefits developers by keeping all the organisational crap out of their way, the release team by creating and sticking to a release schedule, and forcing all the sub-projects to do the same, and so on. In each of these teams, people come and go, but the team goes on. That's the benefit of a team. Perhaps if the GIMP oriented itself a little more towards this idea of sub-teams with responsibility, we would not have so much reliance on one or two core individuals. And perhaps that would benefit the developers. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL
Re: [Gimp-user] CinePaint and Film Gimp
Eric Pierce wrote: Robin, there is really no point in being personally offended here. Sven, no need to apologize. I said I wasn't offended. So the merge is on? Perhaps, a year ago, if someone had proposed re-merging the extra colordepth code from cinepaint into the gimp, with the idea that it would eventually be replaced by gegl post-2.2, it might have happened for 2.0. However, that didn't happen, and as we can see there has now been some personal animosity (if not offense) that has built up between the 2 projects (or at least, between key people on the two projects). It definitely is not something that's on the cards before 2.0, and 2.2 should be a stabilising release with some feature additions, but nothing as major as a code merge from a project which actually doesn't share that much code with us any more from what I can see... if we were to attempt such a merge, it would definitely delay 2.2, and would thus delay the merging of gegl into the GIMP (which is due to happen, if all goes well, after 2.2). Given that, I'd say it's unlikely. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] filmgimp and gap
Carol Spears wrote: what is the difference between these two things? Filmgimp (now Cinepaint) is a branch of the gimp. That is, it's a complete image processing application. The framemanager (perhaps what you're thinking of) is a plug-in for that application. GAP is a plug-in for unstable gimp, which shares a lot of functionality with the frame manager. By the way, for those who don't know, the GAP plug-in is available in CVS (CVSROOT= :pserver:[EMAIL PROTECTED]:/cvs/gnome, module gimp-gap). Note that you will need your gimp development stuff on the search paths of the applications we use to build from CVS (notably, gimp-2.0.m4 should be in the path specified in ACLOCAL_FLAGS and gimp-2.0.pc should be on PKGCONFIG_PATH). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Testing 1.3.20
Tom Williams wrote: Sven Neumann wrote: Hi, BandiPat [EMAIL PROTECTED] writes: The new Gimp compiled fine today and installed. Upon trying to run it though, it got to a load point and just died. I ran it from the shell to check for more messages and found it doing a Segmentation fault See http://bugzilla.gnome.org/show_bug.cgi?id=121752 Updating fontconfig to version 2.2 should fix the problem for like it fixed it for everyone else who reported this problem so far. Sven Thanks for posting a link to this bug report. I'm seeing a similar problem at startup but it's not font related and is related to the tool-safe-mode plugin: This is another commonly reported bug - see http://bugzilla.gnome.org/show_bug.cgi?id=118517 To find bugs like this, you should probably add CLOSED and RESOLVED to the default set of bug statuses, and search for the most prominent word - in this case, searching for tool-safe-mode turned up 3 links :) In brief, that's an old plug-in that was removed in version 1.3.10, so if you had an older devel gimp installed and you didn't make uninstall of that, it's an old file left lying around. Delete it, and all will be well. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] WikiWordOfTheDay
Hi all, I had a few ideas about collaborative content creation for the website and the documentation project recently, and thanks to Carol's forethought, we have the means to do this at our fingertips. Problem: Writing docs takes ages, and there are not enough people to do it all, and docs often need little retouching at the end that has to be communicated to the original author, and takes time to integrate, and so on. Solution: For a given topic, create a wikipage. Make a start on it (sketch paragraphs/sections, basically set up the bare bones of what is needed). And then propose that lots of people make small contributions to it. We have a wiki (many people might not know that - it's at http://wiki.gimp.org/gimp), which allows just such collaborative effort to take place. On every page in the wiki, there is a link at the bottom to edit the page. Pages are plain text formatted by the wiki motor afterwards into nice looking html. Formatting is very easy - for example, the equivalent of h2Header/h2 in the wiki is == Header == Simple. The problem becomes how to let people know what docs need work at that particular moment, and how to get people working on it. Suggestions to address this point are welcome. My idea is to have a WikiWordOfTheDay. A WikiWord is a word made up from joining several words together with capitalisation - the word automatically becomes a link to a newly created (empty) wiki page. The wiki word of the day (which might not change every day, and might die as an idea if no-one adds any content) would be posted as part of the topic in IRC, and mailed (perhaps only once a week) to the mailing lists to encourage contributions. So there's the idea. To work, it'll need the cooperation of the documentation team, the web team and the user and developer communities. One of the things that we need in the web-pages and the docs now is content - and this is one way of distributing the load. As I said, any other ideas how to address this problem are welcome. Objections, for whatever reason, and suggestions for wikiwords of the day to get things started, are also welcome. To get things started, here's a first WikiWordOfTheDay: http://wiki.gimp.org/gimp/WikiWordOfTheDay And a second, as an example of the kind of content I'd like to see: http://wiki.gimp.org/gimp/GettingStartedWithGimp Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] ANNOUNCE: GIMP 1.3.20
Hi all, The next release in the development series of the GIMP, version 1.3.20, is now available for download from ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.20/ or from one of the mirrors listed at http://gimp.org/download.html This release marks the start of the GIMP Bug Week. The idea of the bug week is to get as many people as possible involved in reporting, categorizing and fixing bugs in the run-up to our 2.0 releases. More information about bug week is available at http://gnomedesktop.org/article.php?sid=1318 and information on the kinds of jobs we would like help with is here... http://wiki.gimp.org/gimp/GettingStartedWithGimp Have fun, help out, and happy GIMPing, Dave. Overview of Changes in GIMP 1.3.20 == - Improved documentation of the app directory [Mitch, Sven] - Image update optimizations [Mitch] - font-map script improvements [Sven] - PDB API to access fonts [Sven] - Portability fixes for x86-64 [Yosh] - Enabled SSE and SSE2 compositing code [Helvetix] - GimpSelection class added [Mitch] - Pullout parameter added to RGB-CMYK conversions [Sven] - Basic framework for future help system in place [Mitch] - Screenshot plug-in rewritten [Brix] - Font list updates on the fly [Yosh] - Generic interface for stroking selections and paths [Mitch] - Further improvements to the path tool [Simon] - Remove libgck from public API [Mitch] - Lots of bug fixes Other contributors: Maurits Rijk, Ville Pätsi, Larry Ewing, Dmitry G. Mastrukov, Pedro Gimeno, Raphael Quinet, S. Mukund, Andy Wallis, Carl Adams, Tino Schwarz, Tor Lillqvist, Emmet Caulfield, Guillermo S. Romero, Dave Neary, Wolfgang Hofer -- David Neary, Lyon, France. E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] What's Wrong with this Image?
Nick Wilson wrote: These images will not show up in a browser? http://www.cookaholics.com/images/ I just saved by extension to .gif and .jpg but they will not show as you can see from this page: http://www.cookaholics.com/test.html Sorry - works fine for me (Mozilla 1.4 on Linux). Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Colour - Alpha
chris.danx wrote: Hi, Is it possible to make all pixels of a given colour transparent? I've just started playing with the gimp and am a bit stuck. Basically I want to duplicate a selection in the background layer, put it in a transparent layer with only the non-white pixels opaque. Maybe there's a better way to do this? Add layer mask, Select by colour on layer, activate mask, fill selection with black. Or, select by colour, quickmask, copy the mask (in the channels dialog), and apply that mask as a layer mask. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Firmed out roadmap
Hi, Sven Neumann wrote: David Neary [EMAIL PROTECTED] writes: Here is a roadmap with some meat on it (solid dates for milestones and other stuff) - it's pretty aggressive, particularly with respect to a 2.2 release next year. I really like the idea of setting a date for a feature freeze early. This allows people to prepare the code they want to get in and it makes it easy to reject stuff that comes to late. However I don't like the idea of setting release dates. While I think that your schedule is reasonable it should probably not be communicated outside this list and IMO the worst thing we could do would be to publish it on any web-site. This is a volunteers project. We don't know if we will be able to get 2.0 out in this timeline. There are too many unforseeable things that might happen. And who would benefit from any promised release-dates? IMO we can only hurt ourselves by doing such promises. Don't get me wrong. I think your schedule is reasonable and we should definitely publish a roadmap but IMO it shouldn't include any dates. Perhaps I should explain my reasoning behind putting firm dates behind things. Fair enough, setting release dates on a volunteer project is a recipe for disappointments when they are eventually missed, but if you look at the troubles we have had, they are echoed in other projects around the free software world - mozilla and GNOME being the two that come to mind immediately. When you say that the stable release will come whenever, then it really is whenever. I feel that dates create a sense of urgency... 2.0 in December gets people thinking in the back of their minds that there's 4 months left to release. Put solid dates on there, and suddenly if a bug isn't classified by September 8th, it's not going to be fixed by 2.0, there are events associated with the near future. I think that the dual goals of getting a release as soon as possible and getting as many people as possible working towards that release are served by setting dates. I'm not saying that these dates are set in stone - indeed, I expect them to slip because certain things are going to crop up - bugs that are blockers to 2.0, real life getting in the way of the blockers for the pre-release, and so on. The basic idea I have is to (1) have rough dates when people can expect certain things to happen, and (2) maintain the roadmap so that those rough dates are never unrealistic. So when I say release 26th of August, well if the release is on the 28th, I won't be disappointed, but I know that the bug week can't happen without the release. The idea of the roadmap is just to lay out the events that cannot happen in parallel. Fixing dates shows perhaps the most reasonable scenario. If we want a release before Christmas, then, we should be aware that there are only really 2 weeks of slack that we can play with. I'm not saying that release dates solve lots of problems. They address a couple of problems. And they don't, in my opinion, create any, as long as the roadmap is updated to reflect reality. Having said all that, if the general concensus is that we should not publish a roadmap with firm dates on it, I will modify what I have to be a bit fuzzier. But please note that a release schedule is not a stick I will use to beat people with. It is a tool to help us get to where we want to be. And to let people outside our little community know when we can expect to get there :) Cheers, Dave. -- David Neary, E-Mail: [EMAIL PROTECTED] Tél: 04 78 58 08 83 CV: http://www.redbrick.dcu.ie/~bolsh/CV/ ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] ANNOUNCE: GIMP 1.3.19
Hi all, The next release in the development series of the GIMP, version 1.3.19, is now available for download from ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.19/ or from one of the mirrors listed at http://gimp.org/download.html We think this is good enough for daily use. We are now very close to a 2.0 prerelease, so we particularly appreciate testing efforts. New bugs can be reported to us at http://bugzilla.gnome.org/ We at the GIMP would like to take this opportunity to thank all our sponsors for GIMPCon, which completed a couple of weeks ago. Special thanks go to the Free Software Foundation (http://fsf.org), who funded the majority of the costs incurred for the event. Thanks are also due to our other sponsors, O'Reilly and Associates, Germany (http://oreilly.de), MacGimp (http://macgimp.org) and FlamingText (http://ftgimp.com). Overview of Changes in GIMP 1.3.19 == - Migration towards new gimp-help system [Mitch] - Deletion of anchor points on a path [Simon] - Path stroke moving [Simon] - Path stroke splitting by deleting an edge (Ctrl-click while in Delete mode) [Simon] - Drag path edges modifies curve [Simon] - DInsertion of points on path edges [Simon] - Joining two stroke paths is possible (Shift-Ctrl-Alt-Click on the second end-point) [Simon] - Polygonal paths [Simon] - Improved new composite functions and enabled them by default [Helvetix] - UTF-8 validate all strings coming in from the PDB [Yosh, Mitch] - Paint-core improvements and bug-fixes [Jay Cox] - Added more mnemonics [Brix] - Lots of bug fixes Other contributors: Adam D. Moss, Tor Lillqvist, Jakub Steiner, Alan Horkan, Avi Bercovich, S. Mukund, Maurits Rijk, Guillermo S. Romero, Seth Burgess, Wolfgang Hofer, Ville Pätsi, Sven Neumann Happy GIMPing, Dave. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Firmed out roadmap
Hi all, Here is a roadmap with some meat on it (solid dates for milestones and other stuff) - it's pretty aggressive, particularly with respect to a 2.2 release next year. I think experience has shown us that we will probably have a 2 to 3 month pre-release cycle where we only concentrate on bug fixing so for a 2.2.0 release to be sane for next Summer we need to think about going into pre-release mode in March or April, which means avoiding feature seapage around January and February, which means knowing what's going into 2.2.0 more or less straight after the 2.0 release :) Some things need fleshing out - for instance, I'm not completely clear on the outstanding features to be implemented in the text tool before 2.0, or about the exact libgimp api changes that have been foreseen. Likewise, the recent thread on gimp-help-2 only served to confuse what little grasp I had on what was required before a release with respect to the help structure. It would be nice for people who know a little bit more about these things to address them specifically. Also, it would be nice to have this marked up for the website, and I'm not sure I will have the time to do that in the near future. A volunteer to do that very small task would be appreciated :) Preferably using the stylesheets from mmaybe or developer.g.o. You probably see that I had anticipated doing a release tomorrow (as anticipated at camp) as a prelude to a bug week... I just had a look, and make distcheck just failed on me in the po files, so I'm going to need to look more closely at that, and might not have a release until Wednesday or Thursday. I will keep track of the actual dates stuff gets done by as well :) Anyway, comments are welcome. Is any of this unreasonable? Cheers, Dave. Roadmap for GIMP development: Aug 6-10 2003: CCC Aug 10th: 1.3.18 release Aug 26th: 1.3.19 release Sept 1st to Sept 8th: Bug week Sept 27th: 2.0 pre1 Blockers for 2.0 prereleases: - Path tool features missing: 1) moving of strokes/paths, 2) being able to connect two strokes, 3) dragging on curve segments, 4) libart stroking, 5) im/export into files. Text tool features missing: Help browser features missing: libgimp API changes missing: Oct 18: 2.0 pre2 Nov 1: 2.0 pre3 (Halloween release) Nov 22: 2.0 pre4 (possibly 2.0 final) Around Dec 10th: 2.0.0 Jan 15th 2004: Final feature list for inclusion in 2.2.0 March 2004: Feature freeze June/July 2004: 2.2.0 (just before GIMPCon) August 2004: The Great Pain - the GeGL migration. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] cropping to pre-set aspect ratio
Bertie Coopersmith wrote: I attempted David Neary's workaround which was to first use the rectselect tool specifying the required aspect ratio. Unfortunately I cannot do this and I think my gimp is a bit broken. This is what I get:- --- /usr/lib/gimp/1.2/plug-ins/aa: error while loading shared libraries: libaa.so.1: cannot open shared object file: No such file or directory LibGimp-WARNING **: gimp: wire_read: unexpected EOF I don't know what you're doing - is this when the gimp is starting up that you get this? In which case, either install libaa (ASCII art) or remove the plug-in. It's an optional plug-in which requires a 3rd party library - if you don't have it it's not dramatic. It just means that you can't save your images as text files... Anyway, that shouldn't stop the gimp from operating. Does it do so? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] cropping to pre-set aspect ratio
Bertie Coopersmith wrote: Actually, I may have been wrong in my previous reply about this. That error may have occurred on gimp startup without my being aware of it. Therefore its not clear to me whether it had any connection with the fact that rectselect was a do-nothing. (It did not take me into any further dialog to do with entering an aspect ratio). There is no further dialog - there is a tool options dialog however which opens when you double click on the tool in the toolbox. The rect select tool is the dotted rectangle - the tool which is selected by default at startup. Double click on it, and a dialog opens up (in 1.2) In 1.3, this dialog is active by default, and docked in the main toolbox window. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] cropping to pre-set aspect ratio
David Neary wrote: Bertie Coopersmith wrote: Actually, I may have been wrong in my previous reply about this. That error may have occurred on gimp startup without my being aware of it. Therefore its not clear to me whether it had any connection with the fact that rectselect was a do-nothing. (It did not take me into any further dialog to do with entering an aspect ratio). There is no further dialog - there is a tool options dialog however which opens when you double click on the tool in the toolbox. The rect select tool is the dotted rectangle - the tool which is selected by default at startup. Double click on it, and a dialog opens up (in 1.2) In 1.3, this dialog is active by default, and docked in the main toolbox window. Oh - and if you'd like to get your idea about cropping limited by aspect ratio considered at some future date for inclusion, you should open a report for it in bugzilla (http://bugzilla.gnome.org - click on Create a bugzilla account, follow the instructions, and then click on Enter a new bug). Otherwise, it is likely to get forgotten again... sorry :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] transparent PNGs in IE
Mukund wrote: On Wed, Jul 23, 2003 at 02:27:19PM +0200, David Neary wrote: | The GIMP's png support is limited somewhat by its core support | for indexed images - you can have one index entry completely | transparent, but partial transparency (which is supported by png) | is not supported for indexed images in the gimp. Dave, does IE support the alpha channel with indexed PNG images? I would also like to know about the differences between IE/Win and IE/Mac w.r.t this feature. No, that's a big bad for IE. They support RGB pngs, but not RGBA, and they support Indexed PNGs with GIF style transparency, but not multiple palette entries with different alpha values. I'm afraid I know nothing about IE/Mac. I have never been a mac user. For example images to test IE against this, have a look at this enhancement request... http://bugzilla.gnome.org/show_bug.cgi?id=86627 Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp 1.3.17
Mogens Jæger wrote: I just downloaded the new version, and I have managed to get all working. But I have one - for me anyway - major complaint. In the 1.2 series of the Gimp, it was possible to change the shortcuts/keyboard assignments, so that the features you were using the most, has the easyest keys. Or is there a way to change it - I mean in the 1.2 you just found the function in the menu, pressed your wanted hotkey, and it worked - simple and genius. Why has that been changed. This is now a preference in 1.3 - the idea, as I understand it, is that being able to dynamically chane keymappings may interfere with shortcuts. So how the general idea is that you enable dynamic shortcuts in your preferences, then change some shortcuts, then re-disable dynamic shortcuts. I may not understand this perfectly... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] State of play, and stage 2
Hi again, There are now only about 25 bugs with the -- milestone - thanks to everyone who filtered these, there were several people involved, in the end about 10 people helped filter these bugs in the past couple of days. Thanks guys. Anyway, before this starts sounding too American (apologies to our US friends), there's stage 2 to be handled. http://makeashorterlink.com/?N47413065 This is a list of the bugs now marked with the 1.3.x milestone. Some of these are feature requests which have just been added to the milestone. Others are bugs which have been on this milestone for some time. Yet more are feature requests which have been on the milestone for months or years. Yet again, these need to be filtered. As before, bugs which should be addressed for the stable release should be set to the 2.0 milestone, features which are easy to do (for example with source code attached) or important should stay in this milestone, and other features should be bumped to the Future milestone. Currently, there are 106 bugs in that list. I would like to see it reduced to somewhere around 30 so that we can start actually getting features coded :) So, once again, your help is needed. If you missed them the last time, the instructions are simple. Go to bugzilla.gnome.org. If you don't already have an account there, get one. If you need permissions to modify milestones, please mail me directly. And then pick a bug or two from this list, and if it needs moving, move it to the right place. Thanks again for all your help. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Update from the road to 2.0
Hi again all. This is getting amusing, almost... Before you read on, there's an important part that you shouldn't miss about 3 paragraphs down... make sure to read it before you send this to the trashcan/rubbish bin/waste paper basket//dev/null. Understandably, the going has been a little harder on bugs milestoned for 1.3? but we have brought the total down from over 100 to under 80. The list is still available at this URL... http://makeashorterlink.com/?N47413065 We still need to get this list smaller - somewhere around 30 would be workable. Many of these bugs really are low-hanging fruit - there are patches outstanding to be considered and committed in several bugs, several are no longer valid against the 1.3 series, and more are straightforward bug reports which can be moved to the 2.0 target. The tough ones to get rid of are the feature requests which are still valid against the 1.3 series. There is a certain amount of judgement to be made as to whether a feature gets bumped or kept. So if you get a second to help out, there's still some work to be done (oh, by the way, there are now no bugs without a milestone, you guys rock). Now - here's the important bit. There are several features which are definitely going to be considered before the feature freeze. Over the next couple of days I am going to start posting these to the devel list and asking for volunteers to take on the coding. If a given feature is unclaimed, or no-one expresses an interest in it, after 48 hours the bug will be bumped to Future. If someone says they'd like to try to do the bug, they should add a comment saying so to the bug in bugzilla, and change the status of the bug to ASSIGNED (so that it can be filtered from features which are not being worked on). Hopefully this will lead to some features which are actually quite straightforward getting done in the next couple of weeks, and hopefully some of these bugs will be a nice introduction to gimping for some coders who haven't worked on the gimp yet. Thansk for your time, and don't forget, we still need your help. 15 minutes of your time filtering bugs makes a huge difference to someone working on a big feature. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] transparent PNGs in IE
Andrew Langdon-Davies wrote: I know there's already been a lot of discussion on this subject and I've read pages and pages, but I'm still unclear. I realise that just about all recent browsers support PNGs. But, is it or is it not possible for IE (v. 5, for example) to correctly display a PNG with a fully transparent background so that anything behind it shows through? My PNGs are OK in Yes. To do so, you need to make sure that your png is saved as an indexed image, rather than rgb (which png supports, but gif doesn't - this is why when you save as gif, you get a dialog asking you if it's OK to index the image sometimes). To do this, go into the Image-Mode menu, and select Indexed as the mode of the image. Then choose a palette to use (automatic is usually OK), and save as png as you do normally. The GIMP's png support is limited somewhat by its core support for indexed images - you can have one index entry completely transparent, but partial transparency (which is supported by png) is not supported for indexed images in the gimp. Cheers, Dave. -- David Neary, E-Mail: [EMAIL PROTECTED] Tél: 04 78 58 08 83 CV: http://www.redbrick.dcu.ie/~bolsh/CV/ ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Bug triage guides
Hi, I just found this page... http://developer.gnome.org/projects/bugsquad/triage/ ...which explains the ideas behind filtering bugs. It's actually quite a simple explanation, and applies quite well to the gimp when you substitute #gimp for #bugs :) Anyone who wants to contribute to the gimp bug triage, but who doesn't have permission to change milestones, please mail me, and I will either get you sorted, or give you a list of people who can change milestones (more likely the former). Be warned, the pointy stick approach will be in effect - if you make changes that you shouldn't (for example, to bugs in other products than the gimp), you will lose your rights. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
