[Gimp-developer] XCF spec
Hi, Could we get Henning's XCF spec committed to CVS before any of the freezes for 2.4 come into effect, please? It's a vast improvement over the existing version, and has been improved since his first draft to include a detailed definition of layer modes. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] XCF spec
Hi, Sven Neumann wrote: On Thu, 2006-08-31 at 20:56 +0200, David Neary wrote: Could we get Henning's XCF spec committed to CVS before any of the freezes for 2.4 come into effect, please? It's a vast improvement over the existing version, and has been improved since his first draft to include a detailed definition of layer modes. Didn't you already commit it? I somehow remember that you did. If not, please do so. Nope - I did ask, but you asked that we wait until it was complete. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: SoC mentors students: mid-term evaluations!
Hi, Sven Neumann wrote: On Mon, 2006-07-03 at 11:03 +0200, Dave Neary wrote: For mentors, it is not just recommended to be subscribed here, it is a requirement - as in this case, important information about the program is sent to this list, and I have been working on the assumption that all GIMP mentors are subscribed there. Sorry, but the amount of traffic coming in due to this list is not acceptable, especially since it can hardly be managed using the lousy gmail interface. I stopped using my gmail account when they subscribed me there. The appropriate place for this type of comment is on the summer administrators list - silently unsubscribing yourself means you're risking missing important info. If that's an acceptable risk for you, then so be it. The choice is yours, and I can't force you to sign up. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Who are you all?
Hi all, I happened on this page today: http://www.frappr.com/GIMP It's a map for all people GIMP - developers, users, passionate advocates, etc. It would be great to know who (and where) you/we all are - go sign up now! (I also found out that there's a parallel universe at http://www.frappr.com/thegimp - it would be great if everyone on the second map (12 people) could put themselves on the first one.) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp-developer Digest, Vol 44, Issue 6
Hi, elf said: I want to know if I can write this plug-in in the context of Summer of Code? Please make a proposal based on this idea via the SoC interface - it seems a little light to me for a 3 month project, but perhaps the other developers will see things differently. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Accepting GSOC Students
Hi, Michael Schumacher said: 1. They must be able to compile the software (a few students ended loosing time by not having a propper dev environment) They must be able to build current CVS. This should not be a prerequisite. Someone who knows the details of compiling software can learn how to build from CVS in a couple of days (for info: I say a couple of days because there are *lots* of prerequisites, and because using CVS itself is not obvious for someone who has never done so). Don't set the bar too high. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Travel costs requests - last call
Hi all, We're getting pretty close to the conference now (just over a month away), and I'll probably not have much time from the middle of February right up until the conference to take care of on-site things like t-shirts and posters, and I'll have no time for travel expenses. So anyone who would like to go, and needs their ticket paid for, should speak now, or forever hold their peace. I'll be asking that refunds be sent to people who have sent me some kind of information on how much they paid, if they sent their bank details, this week. So please, if you want to go, and need a hand with travel costs, contact me by Friday, because afterwards I won't have the time to take care of you. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [Fwd: GUADEC logo and theme contest]
Hi all, The GUADEC logo theme competition is open, and we're looking for entries - the prize is an expenses paid trip to GUADEC. We are also looking for jury members, and would like the jury to include a GIMP developer. Could anyone interested in being a juror please contact me? Thanks, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ---BeginMessage--- Hello Dave, could you please forward this invitation to the rest of GIMP developers? This is an invitation to be part of the jury that will decide the winner of the GUADEC logo and theme design contest. We would like to have a member of the GIMP community in this jury. We are inviting: * GNOME Foundation - the owners of the brand * GUADEC committee - the contest organisers * art.gnome.org - main source of contributors (I) * gnome-look.org - main source of contributors (and II) * GIMP development team - experts in creative GTK+ tools (I) * Inkscape development team - experts in creative GTK+ tools (II) * Drupal.org - experts in themes * GNOME Catalan translation team - the local perspective * The community - vote based on a poll We are sending all the invitations today, since yesterday the GUADEC beta site was soft-released: http://beta.guadec.org We have designed a procedure to decide the winner that shouldn't take much time, nor debates. It is based on a first round of nominations and a second round of votes. The whole decision process will last one week, starting on Feb 1st. More information about the contest: http://beta.guadec.org/?q=contest More information about the jury: http://beta.guadec.org/?q=node/27 We will be honoured if you accept this invitation! :) -- Quim Gil - http://desdeamericaconamor.org signature.asc Description: OpenPGP digital signature ---End Message--- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] LGM update
Hi all, I have been hard at work getting sponsors for LGM, and we're at a point where I have a very good idea what the budget for teh conference will be. Any of you who have asked for travel expenses previously, and who haven't yet bought tickets, should go ahead and do so soon. We have some administrative issues with the GNOME Foundation at the moment, but they'll be worked out shortly. I'd like to that all of the conference sponsors so far - HP, Xara, the FSF, O'Reilly and Flock. Thanks to them, we should have a great conference, and there's no excuse for people coming from abroad not to be there (well, except maybe family, work,...). Anyone who hasn't yet contacted me about travel expenses should do so as soon as possible, please. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Libre Graphics Meeting website
Hi all, The Libre Graphics Meeting website is online at http://www.libregraphicsmeeting.org - it's still pretty sparse, and is powered by spip. If anyone would like to be a writer or editor for the site, please contact me off-list, and I'll sort you out. People with some design sense especially appreciated :) Proposed edits to existing pages are welcome too, but I'm a bit busy at the moment, so becoming a writer or editor's probably quicker :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Libgimp newbie development path
Hi, s s said: I'm hoping to develop an application that leverages the Gimp's functionality, but uses its own GUI and some other libraries. My ideal situation would be this: - The user opens my application and the only reference to the Gimp that can be directly seen by them are Gimp licensing requirements, while my application would be using the Gimp behind the scenes for basic image manipulation handling. You might want to look at Seashore, a Mac application which uses some of the GIMP internals (notably the file format image structure). That might give you some ideas. My current idea is to develop a plugin for the Gimp which uses my GUI(not using GTK). I'm basing this off of the Gimp pluggin development samples and tutorials available. However, is this the correct path I should be taking? Will I be able to start the pluggin from my app without having the user manually open it from the Gimp? No - plug-ins are standalone apps that communicate with an already running GIMP. Finally, is there a better way to use libgimp so that I can just use Gimp functionality from my application without having to startup the full Gimp application and use a pluggin? Afraid not - short of cutting pasting code (which is possible). Lots of libgimp has no GTK+ dependency - adding a different GUI should be doable, but hard. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon dates
Carol wrote: perhaps Mr. Neary can publish a list of people he will allow to attend so that those people who are not allowed will not waste their time? Open to the public means open to the public. I'd love you to come, but not as [EMAIL PROTECTED] Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp Conference 2006
Eat Frog's Legs and snails in garlic butter! Enjoy the refreshing taste of duck liver! Eat baked pig intestines (a local speciality)! Come to Lyon for the GIMP Conference, 2006! We're in the early stages of the planning - and now's the time to stand up be counted. The GIMP conference, which may become a more general Free Graphics conference, if other people like the idea, will be held in CPE, Lyon, in March or April 2006. We have 4 possible weekends (Friday/Saturday/Sunday) available. The first is the weekend of St. Paddy's Day (the patron saint of Guinness), and David Odin's birthday - 17/18/19 March. The second is the weekend afterwards, when there's not much on - 24/25/26 March The third is the birthday of Dave Neary (me!), and April Fool's Day (think of the press release possibilities!) - 31 march/1/2 April. The last one - 7/8/9 April. We need to decide when the conference will be on soon, to reserve space in the university, get in contact with youth hostels, figure out what's going to happen, and work up some sponsorship. Once the dates are fixed, I'll send a follow-up announcement (if there are dates that are definitely out for you, let us know now). Everyone's welcome! Spread the word! Bring your dog! (But tie them on a leash outside) Bring your partner! (Lyon's lovely in March) We're looking forward to having you all. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Krita news
Hi, So since planet.gnome.org was down, I went over to planetkde.org to see what was happening over there, and I saw this blog entry: http://www.valdyas.org/fading/index.cgi/hacking/krita/16bits.html Yesterday, Krita reached a major milestone. We can now load, manipulate and save rgba images with 16 bits to the channel. I thought that might interest some of you - we're not the only game in town anymore, I think. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code - urgent
Hi, Sven Neumann wrote: I can do the news item. Could someone else please volunteer to do the web changes. I feel too old to install PHP. If cvs write access is missing, I can also apply the patch for you. We're too late for anyone to get the projects into google, but it's probably worthwhile announcing just to stake our claim for next time... http://www.gnome.org/bounties/Google.html http://www.gnome.org/bounties/GIMP.html Thanks to Michael Schumacher for updating the bounties. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Google Summer of Code - urgent
Hi, Nathan Summers wrote: On 6/13/05, Dave Neary [EMAIL PROTECTED] wrote: we need a mentor for the plug-in system. There is a related resource distribution project for gDesklets in the bounties already - some coordination might be possible. I'm willing to be a mentor for that one. Thanks for the offer (yosh too). It looks like no-one picked up the task of adding the projects to the Google bounties (yet). The closing date for submissions is tomorrow, so we're probably a bit late now. Still, we should add them, and put up the news item in the hope that next time around we get contacted earlier to take part. Who can do this today? (If the answer is me then don't bother answering, Just Do It ;) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2.3.1 crash
Sven Neumann wrote: Campbell Barton writes: It always crashes on startup, even if I dont load data. But works if I load the gimp with no UI. Tried removing all the libgimp libs and my prefs for a fresh install but no good. You are running gimp-2.3 linked against the libraries from gimp-2.2 (or 2.0). Fix your linker setup. To elaborate a bit on what Sven has said: You can tell whether you're linking to the right GIMP libs by running ldd on the gimp-2.3 binary. If you're seeing libs like /usr/local/lib/gimp/2.0/libgimp-2.0.so or /usr/lib/gimp/2.0/libgimp-2.0.so instead of $prefix/lib/gimp/2.0/libgimp-2.0.so then you're linking to the wrong libraries. This could be because the directory where the older GIMP libraries are installed is in /etc/ld.so.conf - I seem to recall that this plays havoc with link-time linking (which libtool does) and definitely does with runtime linking. I'm not sure what the solution might be if you've installed an official 2.2 or 2.0 GIMP in /usr, and you want to install 2.3.1 in /usr/local or /some/special/prefix - perhaps someone else can give ideas how to get around that problem. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposing projects for the Summer of Code
Hi, Dave Neary wrote: - Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it Photoshop is up to version ten now?? Bloody hell... and I remember when we felt all clever for figuring out some of the new PS4 PSD features... I'm guessing I skipped a version - PS 8 CS or 9 seem to be the most recent. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP merchandising
Hi, Sven Neumann wrote: I've thought more about the whole thing and I would like to propose the following solution: We add a page about GIMP merchandising to www.gimp.org. This page (GIMP Stuff ?) gets linked from the sidebar and from the Donations page and it is mentioned on the front page at the time it is added (and perhaps every once in a while). On that page we give links to all places where people can obtain GIMP stuff but only if the GIMP project also gets a fair share of the bargain. That's grand with me. It's a fair middle line between having nothing (current state) and having an integrated merchandising line. This is the model that KDE use already, by the way. It's worth noting that what KDE gets in stuff is pretty tiny - it's measured in hundreds of euros a year. I think this is a fair compromise between the concerns that GIMP is selling out, and the desire to have GIMP merchandising for sale. Unless there are objections to this, I'll figure out the details with all concerned over the next couple of weeks. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP merchandising
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: For their part, they would like to continue having their logo on the arm (which I'm OK with) The logo on the arm is definitely what keeps me (and probably others) from buying this stuff. I wouldn't dare to leave home wearing one of these shirts. It also gives me a very bad feeling about this merchandising arrangement. This seems to be a common point and I'll discuss this with Federico. I don't think a prominent place on the front page is appropriate. Integrating it into the sidebar might be. At least announcing its existence when we add the link to the sidebar might be nice. What exactly does this arrangement involve? We can hardly decide anything w/o knowing what we are talking about. Does it mean that sourcewear will be the only official merchandiser? It would be a non-exclusive agreement to produce wilber goods, with an agent identified for the GIMP project who would have control over product quality and designs. Exact details need to be worked out. And I'm not going to spend time doing that if the idea is not workable in principle. The only exclusive part would be that the link Buy GIMP stuff on gimp.org would go to wilber merchandise on sourcewear.com. They're getting placement - people who want to buy gimp merchandise go to gimp.org, where we currently don't cater for them. They don't go to sourcewear.org, so they don't sell many t-shirts, and we don't get much money from the arrangement. If we add a link to wgo, we are providing a service to people who want to buy wilber stuff and don't know where to go, they get more referrals, more sales, and we get a bigger slice of a bigger cake to spend on things that we want - for example, paying for the publishing of the GIMP manual (why not?) and a GIMP conference (when someone around here decides they want to put the time into arranging one). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUADEC cheap accommodation
Hi, David Neary wrote: Murray and I are currently looking around for more people. The option will be confirmed or otherwise this evening or tomorrow. Definitely cancelled. Youth hostel is now the only cheap accommodation option. Dave. -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUADEC cheap accommodation
Hi, Murray and I are currently looking around for more people. The option will be confirmed or otherwise this evening or tomorrow. Dave. Sven Neumann wrote: Hi, Dave Neary [EMAIL PROTECTED] writes: I know that a fair number of you (us) are going to GUADEC, and from IRC chatter, it seems that some people wanted to go for the cheap accommodation option (8 per night for a kind of dormitory). Murray Cumming ([EMAIL PROTECTED]) is looking after this, and would like to hear from people, either by adding their names to the wiki page http://live.gnome.org/Stuttgart2005/Accommodation or mailing him directly (with a preference for the wiki). There is a requirement for a minimum number of people before we can book, so get back quickly if this is an option you want. AFAIK this option has been cancelled in the meantime due to lack of interest. Sven -- Dave Neary [EMAIL PROTECTED] Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Organising a conference
Hi Marc, On Apr 23, 2005, at 8:00 PM, Marc Lehmann wrote: On Thu, Apr 21, 2005 at 01:17:41PM +0200, Dave Neary [EMAIL PROTECTED] wrote: Blender people involved and make it a Free Graphics Con. One might want to change the text on http://www.gimp.org/donating/ then, which explicitly talks about gimp developers. While I am sure most donators don't care, some might, and it would be only fair to be straight about the usage of the money they donate. People donating money to the GIMP are donating it to the GIMP. I was making a suggestion about the scope of the event (if there is to be one), and not how the money people donate would be spent. In fact, my understanding is that since the money was donated to the GNOME Foundation for use to support the GIMP, the GNOME Foundation can only free up the funds for that use. Any such event would surely attract interest from companies willing to sponsor it. What having money does is give us a cushion to get people to the event that need to be there to keep the GIMP going forward. Cheers, Dave. -- David Neary Lyon, France [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] T-shirt sales donation (Modified by David Neary)
Hi all, As most of you know, there are some GIMP t-shirts for sale on http://www.sourcewear.com, and for the sale of each shirt, the GIMP gets a donation. We just got the first installment from t-shirt sales (I'd like to thank Federico Lara from Mayopi for that), which includes a summary. In short, sourcewear sold $130 worth of t-shirts (in other words, 8 or 9 t-shirts), which (after costs) brings us just over $19. Given that there is a profit sharing agreement in place, it might be an idea to install a more permanent link on the front page to Buy GIMP stuff - I know that Postgres have been doing this, and have sold considerably more t-shirts. I had attached the sales summary from Federico, but it seems it prevented my mail from getting through to the list the first time Cheers, Dave. -- David Neary Lyon, France [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp icon copyright?
Hi Cam, Wilber is a Tuomas Kuosmannen (sp?) (better known as tigert) creation. Cheers, Dave. -- David Neary Director, GNOME Foundation [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: floating layers
Hi, GSR - FR wrote: [EMAIL PROTECTED] (2005-02-16 at 0828.38 +0100): can floating layers go away now? the arguments for them have ceased to have meaning. What UI do you suggest? 1) If we are pasting a selection which was made from a layer then create a new layer How do I paste (adjusting if necesary) layer-A data into layer-B's mask then? Refinement - if we're pasting into a mask or channel. Pasting from a channel to a layer could Just Work. It might be decided it shouldn't which is, of course, valid, but it could. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] floating layers
Hi, Carol Spears wrote: if i try to New Layer a floating layer that has been pasted onto a mask, gimp refuses with an error message. This is not new behaviour. for my limited understanding of the reason for floating layers to still exist, this behavior tells me that the need for them has gone. This is the only behaviour which justifies floating selections, actually. if gimp can tell the difference between a drawable or an image Actually, it's the difference between a GimpLayer and a GimpLayerMask (which are both drawables). can floating layers go away now? the arguments for them have ceased to have meaning. What UI do you suggest? 1) If we are pasting a selection which was made from a layer then create a new layer 2) If we are pasting a selection which was made from a mask or a channel, create a floating selection, but don't display it in the layers dialog, and only allow anchor selection Does that sound like what you would like to happen? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Feedback on new rect select tool
Hi, Just tried out the new rect select tool and I have a few comments which I thought might be appreciated. First off, thanks to Bill for the work - this is already an improvement over the old rect select tool, IMHO, apart from one thing (which I'll get to later). First, Show dialog must go. I'm sure that there are people who use this dialog, both in the crop tool and here, but it's a nightmare. Second, Adjustable should be the default. It was very confusing to me that I saw the shading + handles à la crop tool, and then as soon as I released, just had a rectangular selection. The big lacking functionality is the aspect ratio/fixed size functionality from rect select. Being able to constrain the ratio of selections during their creation, and also while editing them, is very useful. One usability change which would be great, but I know that it is a lot trickier, is to have the selection be both a selection and adjustable at the same time. It would be great to be able to drag the corners (or even, why not, the edges) of a selection to move it around resize it dynamically, but have it actually be a selection if I do something like apply a filter. The question is whether the adjustableness would only apply to the last element added to the selection (ellipse, rectangle, or why not, freehand?) or to the bounding box of the entire active selection. I haven't thought a whole lot about it. In short, I think it's good, and if the tool can pick up the last remaining bits of functionality from the rect select tool, and the other selection tools behaved similarly (at least the ellipse tool), I'd be in favour of it being the 2.4 rect select tool. Of course, if something better comes along in the meantime... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Jury member sought for a Paris free software competition
Hi all, I was contacted over the weekend by the organiser of a Paris based free software contest, who wanted to know whether I knew anyone in the GIMP project who was prepared to be a jury member for the competition. The competition was also help last year, and this year will have a multimedia section. The competition is the 26th and 27th of May, near Paris, France. The organisers have a budget, and can eventually pay for air fare from the US. Since GUADEC is the week afterwards in Stuttgart, this might be a good way to get over to that and have your travel expenses paid - fly into Paris, hitch a lift with a Parisian GNOMEr going to Stuttgart, and then fly back from Paris the week after on the 2nd or 3rd of June. They're hoping to organise the jury pretty quickly, so if this interests you, please get back to me pretty quickly. They're not necessarily limited to Americans - if any of our distinguished Germans were prepared to come to Paris on an expenses paid trip, let me know. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Jury member sought for a Paris free software competition
Hi, Joao S. O. Bueno Calligaris wrote: On Monday 31 January 2005 09:03, David Neary wrote: I was contacted over the weekend by the organiser of a Paris based free software contest, who wanted to know whether I knew anyone in the GIMP project who was prepared to be a jury member for the competition. What exactly is the contest about? Coding flor a new project? Fixing bugs on existing projects? Or just using some free software at all? It's a contest for rwarding individual efforts in free software. Here's a site in French describing the competition: http://www.toolinux.com/news/communaute/trophees_du_libre_2e_edition_ar5784.html The website is in French, but the contest is intended to be international - so far, confirmed jurors include one of the main PHP and one of the main MySQL programmers. This page: http://www.sil-cetril.org/trophees/ has a description of the contest: Two types of projects can be presented: Emerging projects which need a maturing phase, but also more established projects. The goal is simply to encourage free software development, as far as I can tell. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Hi Jay, Jay Cox wrote: On a more practical note, gimp seems to completely throw away any exif data when saving as a jpg(tested in 1.3,24, and 2.2.2). Perhaps this is less of a problem than it has been made out to be (or perhaps I have weird cvs versions of gimp installed). You need libexif installed before exif data will be saved. Perhaps this dependency will go away with Bill's new stuff, but I think he uses it too. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] xtns-extras ?
Hi, Joao S. O. Bueno Calligaris wrote: What do you say about renaming Xtns to Extras? I think it would be a good change to the GIMP's general look and feel. I agree. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Color Management was GEGL development/gimp integration
Hi Gerhard, Gerhard Gaußling wrote: I'm not a Programmer, but isn't it possible to make a plug-in which load's the icc information at a first step, to offer the user the ability to decide in which way he wants to handle the file regarding it's color space? It would be possible to do the following: - load image's raw data, and ICC profile - During display, convert from source colorspace to display colorspace - During saving, save the originally loaded ICC profile back to file, if the format supports it, or convert to sRGB if it doesnt. The problems with that approach are - Lots of elements in the GIMP are not colorspace aware - for example, you would have to modify the paint tools to detect whether there was an ICC profile associated with a display they were painting to, and color convert the (sRGB) data that they are painting. This is not possible currently, and Sven has expressed a desire that color management be kept out of the core in the past. - Data which enters the image from other sources (copy paste from another image, for example) may have been in a different colorspace, requiring convertion or some other funkiness to keep things coherent inside the image After this step the file will be converted into the choosed colorspace[*] and then loaded into the gimp, displayed in the working colorspace, corrected by the monitor profile, with the possibility to choose a color proof view with a selectable icc profile for the soft proof. We currently have the ability to do color proofs with external ICC profiles. THe interface to the loading of the profiles isn't perfect yet, but it's there. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Hi, Sven Neumann wrote: Robert L Krawitz [EMAIL PROTECTED] writes: Something that forces me to do an extra gratuitous step for loading every portrait I ever shoot is a massive pain in the butt however you slice it. Assuming your camera adds EXIF info, are you seriously telling me that you do not run 'exiftran -a -i' on each and every image you ever shoot and instead use GIMP to rotate them? A what? I didn't know the tool existed. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] cvs gimp depends on jade?
Hi, Sven Neumann wrote: It would probably be a good idea to make jade optional for the build of gtkdoc so that people like you, who are for whatever reason not able to get it installed, can still build and install a version of gtkdoc that would work with GIMP. One small addition... since gtkdoc only requires jade at build-time, and a binary installation of it works fine without jade when only using xml mode, the alternative is to not build gtkdoc from source at all, and install a binary. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A way to do 16 bits?
Hi, William Skaggs wrote: Well, the most recent ChangeLog entry for gegl is dated 3-25-04, and if it is nearly ready to use, then the CVS archive and the gegl web page are very misleading. Am I missing something? No. Step 1 to using gegl is working on gegl. The needs for gegl before we can start using it are: 1) at least one concrete implementation of all of the abstract interfaces 2) An application that uses gegl. Something that just does a file load and file save (something like convert) would be enough - it just needs to work :) Once we have both of those, the GIMP can start migrating to those interfaces (even if they change regularly), and we can get more people working on alternative back-ends for the abstract stuff. For example, there were several people interested in optimising images in memory - that's a research project for gegl, but it's not a requirement for us before we start using it (nor, honestly, is a tile-based model - a flat big block of memory would do to start off with). Nor do we need a CMYK data model to start with - RGB8 is fine. We just need something behind those interfaces we're going to migrate to. It would be great to let people loose on gegl and that was the plan 6 months ago - get 2.2 out the door, and then put the GIMP into maintenance mode (feature chill or whetever you want to call it) until gegl had reached a stage where it could be used. That means all the people currently putting code into the GIMP would be putting code into GEGL. It may not work like that - there were a couple of features I would really have liked to see in 2.2 that didn't get in there, things like text boxes and text on a path, color management. So perhaps there will be a GIMP 2.4 after all. But we should get as many as people as possible working on gegl as soon as possible. And we need an updated design doc to do that. The unit tests and the template code that's there is a good start, but what we could do with is someone writing an update to the 1998 design docs. I've CCed gegl-developer, since that's where this belongs. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] panel and winning splash
Hi Carol, Carol Spears wrote: make a decision. was their any discussion here of the panel needing the approval of these artists? the panel was put together to make a recommendation to the developers. you need additional handholding? was anyone interested in being on this panel who can make a decision on their own? I appreciate that you would like to see a winner quickly. And I know that you think that such a decision should be easy to make. If there were one person choosing the winner, it would have been done last Monday. However, the panel are conscious of a responsibility they have - they are picking the splash screen that will be on the GIMP for at least 6 months, and perhaps as long as 3 years (hopefully not, but that's how long tigert's splash was on a stable GIMP). If the panellists want to ask for the opinion of outside people, or give weight to mukund's page, so be it. When their decision is made, it will be final. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Not quiting just changing status
Hi Niklas, Niklas Mattisson wrote: I have had some time to think now and it seems that maybe I should not be incharge of the website. snip Thanks for offering what little time you had, at a time where it wasn't a job a lot of people wanted to have. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Judging panel for splashes
Tomas Mraz wrote: And what about the About image? Given that there are so many splash contest entries couldn't be some one of them used as background for About? Oooh - we have a troublemaker. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scissors tool
Hi, Tomas Mraz wrote: If anyting, I'd make it easier to undo the last point added and make it easier to close the curve when done +1 And that annoying bug where you can't have anchor points within 8 pixels of the left or top edges (and possible the other edge too). I am sure I've seen it in CVS, but can't find it right now. Am I imagining things? A hint for closing the curve - you can zoom in and out with + and - while editing a curve, which is handy for getting those clicks right if there are a number of points (or if you miss the first time). Also very handy for adding points or dragging anchors when the curve is closed. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scissors tool
Hi, Joao S. O. Bueno Calligaris wrote: But nowadays, who seriously uses it? I use it all the time to get a first rough draft when cutting out shapes. It's miles quicker than using bezier, and since selections are just masks, I convert the selection to a mask and fine-tune it afterwards. I have found that for me (low-end power user if such a thing exists) this is the way I get decent results quickest. That said, I raise the question: Should the scissors tool be visible by default in the toolbox? I think it is a more useful tool to beginners (and thus the target audience of defaults) than the path tool. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Judging panel for splashes
Hi all, The judging panel for the splash contest is Simon Budig, Alan Horkan, Michael Schumacher, Joao Bueno and Adam Moss. Since they were in the first 5 but aren't in the final panel, if there is a need (for whatever reason) for a replacement judge, the replacements are Joseph Heled and Roman Joost. The results will be announced (and the splash committed) before the end of Friday next week (to give the judges time to judge). Many thanks to FlamingText.com and sourcewear.com for offerring to sponsor the competition. Since there can be only one winner, the prize will be a GIMP t-shirt or polo shirt from http://sourcewear.com and FlamingText will surely help us out on another occasion. Thanks to everyone who entered splashes so far (and those who haven't yet but will over the weekend), and to our judging panel for volunteering - I don't envy them ;) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
Hi Bill,
[EMAIL PROTECTED] wrote:
I am having difficulties enumerating, and identifying layers in a Gimp
Plug-in. Is there
a good source for code that shows how to do this?
Not really - the usual way is to do something like this:
gint nlayers, i;
gint *layers = gimp_image_get_layers(image_id, nlayers);
/* layers[0] is the top layer */
for (i = 0; i nlayers; i++)
{
/* Do stuff with layers[i] */
/* layer is a text layer if the parasite gimp-text-layer has been
* set */
GimpDrawable *layer = gimp_drawable_get (layers[i]);
GimpParasite *text_parasite = gimp_drawable_parasite_find
(layers[i], gimp-text-layer);
if (text_parasite != NULL)
/* We have a text layer */
}
All the standard GIMP parasites are listed in the gimp sources,
in devel-docs/parasites.txt. There are also docs for things like
debugging plug-ins, overviews of many of the GIMP's internal
formats including xcf, and some documentation for important
subsystems like undo, as well as gtkdocs for the libgimp API.
To do this, I need to iterate through all of the layers, find the
text ones, get the text
and save it to a file.
I'm not sure how the text is stores in a gimp-text-layer
parasite. It is a GimpText object serialised to a string, if that
helps any. UTSL (Use the Source, Luke) or ask Sven :)
Hope this helps,
Cheers,
Dave.
--
David Neary,
Lyon, France
E-Mail: [EMAIL PROTECTED]
CV: http://dneary.free.fr/CV/
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Plug-in for Retrieving Text Layers
Hi, Sven Neumann wrote: OK, now I will have to kill you both. Well, perhaps not but I can only strongly discourage to do it this way. You must not rely on the text parasite and it's content. Sorry - wrote that before I got your reply :) I know you were hoping to implement text transforms this week before 2.2, aside from that, is there any (good) reason why the parasite's format would change? Cheers, Dave. -- David Neary, E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ Tél: 04 72 33 95 35 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] python-fu Referesh Scripts
Hi, Sven Neumann wrote: Sven Neumann [EMAIL PROTECTED] writes: It isn't needed. If you change your python script, GIMP will use the updated version next time you start it. Next time you call the script, of course. This could have been misinterpreted as next time you start GIMP. That said, all the scripts are read and installed at start-up, so if you add a new script, you will need to restart the GIMP (same as if you add a new plug-in). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.2 splash screen competition
Hi, Manish Singh wrote: The news was fixed last night. The contest will be worked on soon. In case you hadn't noticed, we're due a release next week. How soon is soon? Please take the current contest down. It should be on www.gimp.org. No. It seems that few people learned from the mistakes of the last contest. Once again, it is slashdotted. The framework on wgo was designed to handle that load. Wikis aren't. It'll do, it's better than nothing. Why did nobody wait for any real input? (remember, there was a holiday weekend in the US that just finished). This is shameful. I didn't know. I'm an Irishman living in France - how am I supposed to know about USA holidays? We have different definitions of shame. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.2 splash screen competition
Hi, Manish Singh wrote: On Tue, Nov 30, 2004 at 08:01:20PM +0100, David Neary wrote: In case you hadn't noticed, we're due a release next week. How soon is soon? Today. If you want to do the work of changing all the places that things have been said now, be my guest. Let me know, I'll blog the new location. Otherwise, the wiki will do for the week. It's not like we're going to get hundreds of entries. Why did nobody wait for any real input? (remember, there was a holiday weekend in the US that just finished). This is shameful. I didn't know. I'm an Irishman living in France - how am I supposed to know about USA holidays? Cause they are mentioned in gimp forums, just like european holidays are (and respected). Were you expecting us to wait for some comments from *you* specifically before starting something? You *are* expected to know about timezones, and at least wait till Pacific Standard Time for comments. The initial (wrong) announcement was last evening at 19h CET, 11h PST which certainly gave you enough time to comment before we had to sort something out. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.2 splash screen competition
Hi, Manish Singh wrote: On Tue, Nov 30, 2004 at 08:37:00PM +0100, David Neary wrote: If you want to do the work of changing all the places that things have been said now, be my guest. Let me know, I'll blog the new location. Otherwise, the wiki will do for the week. It's not like we're going to get hundreds of entries. Sure. I'll also demphasize the current wiki bit. Don't forget to migrate all of the images that have already been submitted from the wiki. This was all said in the wee hours of the morning here. It couldn't wait 12 hours? Given that (unfortunately) I had already made an announcement, since (unfortunately) this thing got left to the last minute and there was no time left to wait for some kind of group approval, it was important that we put something in place today. The contest is only going to run for 6 days. Waiting until tomorrow or Thursday was unacceptable. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] image growing size - is it true? is it normal?
Hi Joseph, Joseph Heled wrote: The caption below the image says 46.9 MB I add a layer with Layer/New Layer. The caption says 70.3 MB I delete the layer. Caption stays 70.3 MB I Layer/New Layer again. The caption says: 93.7 MB I delete the layer. Caption stays 93.7 MB Should I believe the numbers or not? I understand the gimp might be allocating memory and keeping it, but it does not mean the size of the image keep growing indefinitely? What am I missing? When you delete the layer, the delete step is registered in the undo stack. The undo stack is stored with the image in memory, so the layer actually moves from the layer stack to the undo stack. To change this behaviour, you could reduce the minimum number of undo steps saved to 1, say, which will discard the old data as soon as the undo stack goes past that number of steps (if you're making small changes like visibility changes, for example, your undo stack will grow much more, since the second undo parameter is the memory limit of the undo stack once you go past the minimum number of undo steps). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi, Alan Horkan wrote: Would it be difficult to query the operating system and to automatically set the tile cache size to some percentage (50%?) of available RAM? In a portable way, impossible. Having different routines for each platform, perhaps. It would be nice if glib did something like this... The other problem is that 50% of RAM (or even more) is reasonable for a simple-user machine, but for a multi-user machine (a terminal server, for example) that might be completely inappropriate. You would set it to maybe 20 or 25% of RAM in that case, since you expect to have several instances of the GIMP open at the same time. Increasing the default size sounds sensible given that even most low end computers come with at least 256MB of RAM. Computers which were low to mid range 2 years are still pretty common - that's a more reasonable target audience. But even 2 years ago 128M was usual and 256M was common. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: new gfig [Re: [Gimp-developer] canvas background options]
Hi Alan, Alan Horkan wrote: On Sun, 14 Nov 2004, David Odin wrote: and as I already said before, using the 2.0 version of gfig would mean to at least port the old version to the HIG standards, I was suggesting shipping the old unmodified version because it was more stable. I just wanted to point out that the 2.0 API is completely backwards compatible from 2.2 to 2.0. That means that you can simply copy the old 2.0 gfig from lib/gimp/2.0/plug-ins to lib/gimp/2.2/plug-ins and it will work just fine. For a user installation, you might want to check, but I believe that plug-ins in the $HOME/.gimp-2.2/plug-ins directory are loaded before the global ones, so copying lib/gimp/2.0/plug-ins/gfig there would do the same job for an unprivileged user. Personally I'm happy to see someone working on gfig. I wasn't aware dindinx was working on it, and given the track record he's built up, I'm sure that the plug-in will be very stable and much more usable in short order. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] comparing gimp speed
Hi, Daniel Egger wrote: It would be really cool if the pixel data addressing was pluggable so one could easily write a different storage backend. On top of my head there would be several schemes I'd like to try: - A simple linear memory segment with COW for new layers - dito but with RLE compression (and thus more complex addressing) - Line based addressing with COW and aliasing for duplicate lines, with LUT for each line - Planar memory segments (Shoot now! ;)) I don't know what GEGL will buy us exactly because we certainly need a change from store those 32bit RGBA values to something more variable but IIRC GEGL is only about pixel composition, not storage. There are better people to talk about this than me (Dan, are you reading?) but part of gegl is about data representation, and that includes its representation in memory (tiles, scanlines, whatever). I know that Dan Rogers was working on a GeglTiledImage structure at one stage, which had its own tile manager. Given the object structure, perhaps some of the alternate schemes you describe could be accomplished by inheriting from GeglImage and implementing the extra bits. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bugzilla privileges
Hi Joao, Joao S. O. Bueno Calligaris wrote: Through this e-mail I am formally asking the GIMP team to be granted with some bugzilla privileges. I've added some permissions for you now. The mail usually should go to [EMAIL PROTECTED], but that's OK (it's a formality to ask, anyone who asks gets permissions to edit bugs). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bounty for PyGimp
Hi Kent, Kent Tenney wrote: As someone who would dearly love to see PyGimp a reality, I was interested to see at: FYI, PyGIMP exists, and has done for quite some time. It appears to be lacking an active maintainer at the moment, and it's not quite a first class binding (that would require some changes in the library code to allow bindings to happen more easily), but it is used. For the GIMP 2.0 or 2.1, run configure with --enable-python to generate python-fu bindings. There are some example scripts showing its usage. http://www.ubuntulinux.org/community/bounties Bounties will be offered on Python scripting interfaces for the following tools: * The GIMP This is great news (well, not really news, since the same bounty is on Mark Shuttleworth's site as well), and hopefully this will help reward someone who chooses to work on the bindings. I am still undecided whether bounties (especially ones without a sum attached) provide the motivation to do the work, or are simply a nice way to thank someone who would have done it anyway after the fact. Maybe it will raise the item's priority in someone's TODO stack? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] adding a help button to GimpDialog
Hi, Sven Neumann wrote: We can of course add a gimprc option for the Help button but my question is if it is a good idea to add such a button per default. I think it's a good idea having a help button by default. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Console window on Win32
Hi, Tor Lillqvist wrote: Could we have a raise-of-hands here? Who thinks GLib shouldn't bother doing that console window allocation stuff at all? Me too. I hate threads that degenerate into this, but it's the most annoying thing possible in a GUI app :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi jimmac, Jakub Steiner wrote: It's an interesting task that indeed exposes a problem of the current UI. I have one usage pattern that would suffer if we implement the behavior you propose though: 1) Select A4 from templates. Millimeters is selected as a unit (makes sense). 2) Change to pixels as units to see how much that is really (me no maths please) 3) Oops, 210x297 pixels? The change you propose does make sense in the workflow you propose. The above + consistency with how units behave elsewhere in the interface speak against the change. Good point - speaking for myself, what I understood was on the table was the following: Template: [A4 (300dpi)] Units: [mm] Width: [210] Height: [297] Now if I change the unit to px, the width and height will change, as you expect. However, if I am starting from the defaults: Template: [(None)] Units: [px] Width: [377] Height: [233] Now, if I want an image 130x100 mm in size, I set unit mm (changes width and height), then set the width and height I want. (forget for a moment that I could pick the template). The point is, if I want to change all 3 boxes, the one which changes the other two should be first. Otherwise I end up doing Width: [130] Height: [100] [px] (change unit to mm) Width: [45.86] Height: [35.28] [mm] and I have to change width height again. Cheers, Dave. PS. Just for the record, I think this is a pretty superficial thing, I'm not passionnate about it either way. I can see the point of Nathan and the original bug reporter, because this has happened to me a few times too. But if the decision is no change, well, I guess that's OK. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] on splitting things off
Hi, William Skaggs wrote: Dave Neary wrote: Splitting stuff off feels an awful lot like putting it out to pasture. The goal of just having the core application, with no plug-ins, no image data structures, no scripts, and a minimum number of brushes, patterns and gradients doesn't seem to be the direction that people want to see the GIMP taking, from what I can tell. I think I agree with Dave here. Instead of a simple download; untar; configure; make; make install, it wouldn't be an improvement to make people go through that multiple times, making sure to do it in the right order and ldconfig after each step, matching all the versions and configurations properly. And that's just for Linux. This is what I understand Sven wants, eventually. As I understand it, if you're building from source, you're a developer. Otherwise, get the binaries, which will have everything packaged in. If I misunderstand Sven's point of view, I'm sure that he'll correct me. If that's the case, we're working towards needing a jhbuild or a garnome for the GIMP, which just doesn't seem right - we're a desktop application, not a suite of developer libraries and desktop applications. We have one set of developers, not several dozens. If everything ended up in one tarball, with a single-step build, that would be grand. But I don't believe that's the intention, given the precedents of GAP and gimp-perl. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] on splitting things off
Hi Sven Sven Neumann wrote: I don't see what's wrong with needing a jhbuild type of script to ease compilation (not that I have ever felt the need to use jhbuild). GIMP is not a desktop application. It is (or should become if it isn't yet) an image manipulation suite. We have several sets of developers already and I hope that sooner or later it will be several dozens of them. If you are lacking this vision, you are effectively stalling GIMP development. So do I (hope that some day we will have dozens of developer groups). I like the idea of splitting the project up in terms of domains of responsibility. That was the whole idea behind having plug-in maintainers. I'm just not sure we have the same ideas about how to get there. Then again, my ideas on the issue are pretty blurred right now. I should maybe sit down and try to clarify the way I think things might happen. Dave, it was you who only yesterday complained about the time that it takes to build GIMP. Small correction - IO was complaining about how shit my computer is. The GIMP's compile time is simply a symptom of that. Now imagine how much time it would take if GAP and gimp-perl were still in there. We are already way beyond the point where the GIMP tarball is handable. It takes hours to run make distcheck in this beast. It takes hours to check it out of CVS and build it. It takes hours to do a release, most of this due to the huge size of the tarball and the shear amount of files that need to be tagged and committed. I agree, build time is a big issue. But you've said that most people will have everything anyway, so how does build time improve? Is the idea that if we don't change the API or API for libgimp that you could recompile the core without recompiling gimp-plug-ins? I guess that idea could work... But compile time has doubled over the past couple of years without a huge change in the size of the source code. It seems to me that the build tools we use have gotten more i/o and more processor intensive. Is it possible we could make improvements there? I'm not opposed to having stuff split off, but I am worried about the stuff getting a bit lost. Most gimp 2.0 installs (the vast majority, I would say) don't have GAP or the perl bindings installed. That's not a trend we should be encouraging, IMHO. In fact, I think we need to work out ways to actively discourage it, and make sure most people have those packages (and others) installed. I'm just not sure how to do that (as I said before). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Article on GIMP in upcoming O'Reilly Windows Digital
Media Hacks book Reply-To: In-Reply-To: [EMAIL PROTECTED] Hi Joli, Joli Ballew wrote: I am Joli Ballew, coauthor of the upcoming O'Reilly book Windows Digital Media Hacks. I wrote a hack on GIMP, but my editor would like it to be beefed up a bit. It needs a hack angle, something that users won't readily recognize as something that's possible with the program, or something that's really unusual or off the wall. Well, what are you starting from? When you say you wrote a hack, do you mean something in script-fu, or perl-fu, or perhaps a C plug-in? I was hoping you could forward this email to someone at the company who can add the spice it needs to make it into the book. It shouldn't involve too much - the hack is written - it only needs the hack angle. Sorry - no company here. We're all volunteers. I'm forwarding your mail to the developers list, perhaps you can follow up with some more detail on what you've done so far. Cheers, Dave. -- David Neary, E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ Tél: 04 72 33 95 35 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, Sven Neumann wrote: No, that would be wrong. Non-interactive means that there's no user interaction, it doesn't mean that there's absolutely no feedback such as a progress bar. Some plug-ins used to behave the way you argue and we have hopefully found and changed them all to do the right thing which is to always indicate progress. How does gimp-console handle plug-ins then? I assume it doesn't bring up progress curses windows... Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
Hi, Sven Neumann wrote: one or two things for GIMP 2.2 that I forgot: Script-Fu vs. Tiny-Fu We should come to a conclusion whether and how Tiny-Fu can replace Script-Fu. I'd suggest we make separate packages gimp-script-fu and gimp-tiny-fu and remove Script-Fu from the gimp tree. I think we could include both in the standard distribution, making tiny-fu the default and having script-fu as a fall-back. Despite all the testing it has had so far, it's inevitable that tiny-fu will have some teething problems when it gains very wide exposure in a stable GIMP. Python bindings IMO we should move pygimp out of the gimp tree into a gimp-python package. That would make it easier to give it a proper python-like build environment and would make it easier for packagers. Yosh also had some great plans on improving pygimp. Would probably be a good idea to make these improvements independent of the GIMP release cycles. Given that this has happened for gimp-perl already, I can see the logic in that. Who is maintaining gimp-python right now, by the way? yosh? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Linux Journal Editors Choice Award
Hi, Alan Horkan wrote: The Gimp has won the Linux Journal Editors choice Award for Best Graphics software, they seemed particularly pleased by the improved EXIF support. Cool :) With the OSI award, and the O'Reilly reader's choice award from last year, it's cool to see us winning awards again. It'd be great to see some kind of trophy cabinet section on the site where we collect our favourite awards. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, Sven Neumann wrote: Alastair M. Robinson [EMAIL PROTECTED] writes: Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)? The plug-in can attach a persistent parasite to gimp. Are parasites ever saved across sessions? I didn't think they were. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Color management: conclusions?
Hi, Sven Neumann wrote: I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? I would. I assumed you were asking Alastair, though. Also, I found another color management plug-in for the GIMP (pretty old, and I haven't looked at it in depth yet, but it's someone else who has looked into the issue and might save us some work): http://www.khk.net/color/color_manager.html Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 16 bit Gimp?
Hi, Sven Neumann wrote: Joseph Heled [EMAIL PROTECTED] writes: (repeat) I am developing a plugin which loads raw images from digital cameras (CRW,NEF etc). I might be wrong, but doesn't such a plug-in exist already? One exists for dcraw (Canon's raw format). Don't know if that would work on the other formats. Shouldn't we consider including that in the main distribution for 2.2, since that type of format is now more more widespread? Who's the author? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-plugin-template: install
Hi Joseph, Joseph Heled wrote: Can someone tell me how to configure gimp-plugin-template so that it installs locally(~/gimp-2.0) instead of the global /usr/local? configure --prefix=~/gimp-2.0 should work. But if you would like to install your plug-in in the GIMP user directory (in $HOME/.gimp-2.0/plug-ins), I don't know how to do that. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developing a GIMP plugin (2 questions)
Hi Javi, javi palau wrote: Two questions: 1º When i execute my plug-in for 2nd time, i'd like to configure the parameters like the user introduce the first time. Is there any gimp memory to save the values introduced by the user? You can tell when a plug-in is re-run by testing the run mode (parameter 0 of the input parameters of every plug-in). If it is GIMP_RUN_WITH_LAST_VALS, the plug-in has been run with that menu item, if it's run GIMP_RUN_INTERRACTIVE it has been run through a menu entry. The usual way that you get back last used values is to call gimp_set_data(plug_in_name, pointer_to_option_struct, sizeof(option_struct)); So the first thing that you can do after starting the plug-in is to call gimp_get_data(plug_in_name, pointer_to_option_struct); 2ºHow i can know the language used by GIMP?. I've been searching in the gimprc file, but i haven't found anything. The GIMP is written in C, primarily, but you can write plug-ins in any language which wraps libgimp (if it wraps gtk+ as well, all the better). That currently includes perl, python and scheme (script-fu), but there is no reason not to have others. The gimprc file format is a readable serialisation of internal configuration stuff, I don't think you could call it a language. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Color management: conclusions?
Hi all, So as I was saying on gimp-user, we have had a really good chat about this now, but it seems that we are still unclear about what we hope to do in the area of colour management between now and 2.2. Who is prepared to put some time (perhaps a lot) into implementing this? What exactly would they implement? There seem to be 2 solid propositions coming out of the discussions, which agree on a number of points. The points of agreement are: 1) Color management should be disablable. 2) The monitor's profile should be applied to the projected image as a last step before displaying. The monitor profile could also be applied pretty much everywhere that the GIMP exposes colour in its interface. The two propositions are (or seem to be): 1) Apply embedded profiles (after prompting the user whether they would like to do that) at load time, or attach the profile to the image at load time and use the raw image data, assuming that sRGB (or some other colourspace) is the internal colourspace all the time. 2) Allow the user to set the internal colourspace, and warn when an attached colourspace does not match the current internal one, allowing the user to either apply the profile to convert to the current colourspace, set the internal colourspace to the new one, or not use the colour profile for the image. I was talking to Sven on IRC, and he seemed to believe that neither of these would be done for 2.2, and that only the infrastructure which would allow these to be done easily post-2.2 (when we hope to have higher bitdepths internally for image data). At least, that's what I think he said, but I didn't really follow. So - back to the essential - who, what (and when)? :-) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] What is really used in CMYK ?
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: So - back to the point I mentioned above - does anyone want to draw up a what and how of colour correction as they would implement it for 2.2? Shouldn't we have that discussion on gimp-developer? Or at least include gimp-developer on it? Yes, of course. My mistake. But then, aren't all the developers subscribed to gimp-user too? ;-) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OSCon attendance
Hi, Shlomi Fish wrote: On Wednesday 14 July 2004 05:49, Nathan Carl Summers wrote: Heh, my vote is for Valgrind. :) Well, valgrind is a very nice and useful tool. (I know becuase I'm also using it extensively) However, I think that perhaps GNU Arch deserves to win because: And what about the GIMP and its 10 years of being a core Free Software application? We were the first poster-boy application that said that Linux could be a desktop OS, the project which spawned GTK+ and arguably GNOME, and are still the best Free image manipulation program around, despite being 4 years behind the 2000 schedule for some major features. I think we deserve a good decent award. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Alastair, Alastair M. Robinson wrote: Given the limitations we're trying to work within, I think the best compromise is likely to be something like this: snip some very good suggestions - Change the GIMP's working profile to match this image. This will leave the image data untouched. (This should disable the display filter for existing images, since they are presumably using a different profile.) So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time 2) We stop using the profile and propose the dialog with the 4 options the next time the image is activated (basically allowing us to change the working colorspace on demand, but this could get annoying, I guess) 3) Something else I hadn't thought of? - the user just needs to be made aware that colour-space transformations are a destructive change, and have an opportunity to avoid them. That sounds sane. I'm not quite sure how it would be implemented, but it probably involves having a color profile parasite attached to an image, with some kind of configuration parameter for the working colorspace and the monitor profile. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, Sven Neumann wrote: David Neary [EMAIL PROTECTED] writes: 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image at save time That doesn't sound feasible to implement. How would the other image get notified about this change? There isn't any notification about parasite changes. Yeah - fair point. The changing colorspace has to get taken into account next time we activate the image, then - and we're back to option 2. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Alastair, Alastair M. Robinson wrote: Dave Neary wrote: Assuming we're using lcms, the internal conversion will be applied in full precision - the problem is that the destination data, by necessity of the GIMP's current limitations, must be 8-bit RGB. Converting 8-bit RGB data from one profile to another will not be a 1:1 mapping, so some colour information will be lost - I haven't yet conducted empirical tests for the severity of this effect, but I suspect that the 8-bit source data will be downgraded to something like 7 - 7.25 bit. I may be misunderstanding things, but if the conversion from the source colourspace to sRGB is done in lcms losslessly, then all we're losing is the out-of-gamut colours from the colourspace conversion. And, of course, the cost of discarding precision in the data we get after the application of the profile. But I think we still get the full 8 bits of data (they may not have the exact colours in the source file, though). First of all, a profile on its own is worthless for rendering accurate colour - they must be used in pairs, source and destination, to create a colour transform. Thus, if the GIMP is using sRGB internally, then at projection time you feed the RGB image data through an sRGB-Monitor Profile transformation. Yes, but since this profile is applied once, on the projection drawable, as the final step, its application doesn't present any problems. But I see what you mean - we can go from the source colourspace directly to the monitor's with one transformation. This, however, poses problems for say the checkerboard pattern (which will be transformed differently with different source profiles), and for any occasion where different profiles get mixed (cut paste operations, for example). I would have thought you would still have to have the 2 profiles applied though... I'm sure I just don't know how lcms works. I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. Great - quantitative data will really help. I can certainly see the appeal of a simplistic approach, but if a little extra effort can prevent unnecessary destructive changes to the image data, I think it's worth exploring. Sure. I think this is probably a very bad idea. Could you expand on why you think this? Confusion? Difficulty of implementation? Something else? The this was referring to a passage that you cut - I think it is probably a bad idea to have lots of image data in different colorspaces. I can't put my finger on why, but I just have this feeling that we will end up with a certain amount of confusion when it comes to colour stuff (as you pointed out, the colour picker is a good example, so is cut paste). I'm more than willing to defer to the many experts we have, though. I wish I knew enough about the subject to consider myself one. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rearranging ToolboxXtns Menu
Hi Carol, Carol Spears wrote: the bug report suggests this rearrangement of the Xtns menu (which is a huge mess if you install all of the difference scripting options that the linux gimp has): Agreed :) The New Structure Toolbox/Xtns/: * Perl -- snip * Script-Fu -- snip * Python -- snip One thing I would really like to see is plug-ins installing themselves according to their function, rather than what language they are written in. This is more work, of course (or perhaps not - maybe it's just a case of removing the Perl, Python and Script-fu menus and keeping all the structure underneath). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] rearranging ToolboxXtns Menu
Moin Mlle Spears, Carol Spears wrote: there are things that belong directly to the scripting things that get used when writing scripts. if you are writing script-fu, the python console is of no use to you, for instance. i put only things that would be useful for writing scripts into these Xtns menu options. That has a certain logic. How about Console-Perl, Console-Python and Console-Script-fu instead? Then again, if the actual plug-ins are in more functional positions, I'm happy. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Read/write plugin
Hi Soren, Soren Hauberg wrote: I'd like to be able to read and write this kind of images in gimp, but how do I get started? I did a presentation on writing plug-ins in GUADEC - *very* basic but there is a sample plug-in included. The paper is online at http://dneary.free.fr/gimp I guess I have to write a plugin but the docs a rather outdated (at least the ones I can find). Any hints on how to get started would be appreciated. Your best bet, once you know the basics of a plug-in, is to pick an existing file plug-in that does a simple format. The one I usually reccommend is pnm - in the GIMP sources, this is in plug-ins/common/pnm.c. This is good because it shows the basics of saving and writing an image without having the overhead of using a 3rd party library, or having file format overhead involved. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Donation
Hi all, I got home today, and was surprised and happy to see a large donation to the project from distrowatch.com. They apparrently have a policy of contributing regularly to various open-source projects, and this month it was us. A big thank you goes out to the DistroWatch guys, sizeable unsolicited donations are always great news, and bring a smile to people's faces :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] CV: http://dneary.free.fr/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview widgets, wiedermal
Hi Bill, William Skaggs wrote: My personal feeling is that it would be best to work from the preview widget developed by Shawn Amundson and Ernst Lippe. It certainly has some issues, but I think they are fixable, and it would be a shame to waste the huge amount of effort Ernst put into it. I've been working with Ernst's code, and can put it into CVS if that would be useful. I agree with you on this. And currently the blockage to Ernst's code getting committed seems more personality than technical. I'm not sure what Sven thinks of committing this into the main CVS, perhaps you could attach your modified version of Ernst's widget to the relevant bugzilla report, so that we can have a look at it? It would certainly be worth getting the few people who have been working on this (yourself, Geert, David Odin and Ernst) into a virtual room to hammer out any issues... Cheers, Dave. -- 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] Confirmation for GUADEC accomodation?
Hi Tor, I'm forwarding your mail to guadec-list, so that someone there can answer. I have no idea what the story is with the student flats, I'm afraid. Dave. Tor Lillqvist wrote: Has anybody else received an confirmation after booking a student flat when registering for the conference? I haven't. I did get a confirmation for the conference registration, but on the other hand no charge has showed up on my credit card yet. And no reply to my inqury to the FiloNova address. (The address that the conference registration confirmation was sent from didn't work...) Odd. --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] O'Reilly sponsorship deal
Hi all, More good news. O'Reilly and Associates have agreed to be a major sponsor of the conference, and with some luck (and a few more donations) we will have enough money to pay some of the travel expenses of most people coming to GIMPCon (try decoding that). In exchange, ORA are asking that we give them space for a targetted Safari bookshelf, which we would offer as a service on the website. I'm not sure what exactly is involved in integrating this, I expect that I will get the info I need from ORA soon. We will also have some ORA marketting materials for the conference. Cheers, Dave. -- 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] O'Reilly sponsorship deal
Hi, Carol Spears wrote: On Fri, Jun 04, 2004 at 08:16:03PM +0200, David Neary wrote: We will also have some ORA marketting materials for the conference. also, does marketing tools mean tee-shirts? whee! No, it means books and banners, and some posters. But books are still OK... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Funding news
Hi all, I have a few bits of great news today. First, the FSF have agreed to be a major supporter of the conference again (they have been our largest supporter for each of the 3 GIMP Conferences so far). Second, we have just won a Merit award from the OSI, which results in a cash donation of $500 to the project. Third, in the week after the donating paypal link was added to the www.gimp.org page, there were 10 donations via paypal, for a sum total of $250 after deductions. Now that the website is back up (thanks yosh), it would be great to announce that we need money to get people to the conference, and get as many donations as possible from that route. We now have a total of almost $5000 in funding, including the leftovers from last year. I think that with a decent drive between now and the conference, we could get that up to perhaps $7000, which by my rough estimate would pay roughly 60% of the total travel costs. That said, if people from the US or Australia need more than 60% to get there, and people from Europe need less, it will be distributed according to need. Cheers, Dave. -- 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] Refactoring code from GPL to LGPL
Hi, Manish Singh wrote: snip But it's pretty clear that you never bother to do any research before posting. snip You must have some weird sort of logic goes on in your head that made you conflate these things. snip But your postings leave the impression that you do not understand it. Then again, this disjoint thinking is probably one of the reasons there hasn't been much progress on your project. Was there any reason to be this unpleasant, yosh? This thread was long finished, and you certainly didn't contribute anything meaningful to it - wouldn't it have been easier to say nothing than be an asshole? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Absence of a web team
Hi, Earlier on in the week I asked if someone would volunteer to add some information to the website, and unfortunately to date that hasn't happened. I would do it myself, if I had the time. But I won't have the time until the week after next, probably. And then we'll be under 5 weeks from GUADEC. It seems like we don't have a web team any more (please, if someone is looking after www.gimp.org, correct me here). If that's the case, are there other people willing to fill this void? There are people who would like to contribute to the GIMP, and they currently can, tax-deductibly in the US, in 3 different ways. Can we please get this information up on the site this weekend, and get it publicised early next week so that we can finally see where we are in relation to paying expenses? For the moment, we are stuck around $1400 which won't pay 1 plane ticket from the US at this stage (although it would have 2 weeks ago). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GPL discussion (was something else)
Hi, Marc A. Lehmann wrote: On Wed, May 12, 2004 at 03:55:31PM +0200, Dave Neary [EMAIL PROTECTED] wrote: big snip So I hope it's very clear now that it depends. Ummm.. no. And getting unclearer all the time. Get used to it. The unclearness is *precisely* :) what this is about. Thanks for the explanation. I think I understand things better now. (Dave furrows brow pensively...) Cheers, Dave. -- 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] Refactoring code from GPL to LGPL
Hi Robin, Robin Rowe wrote: How do you get permission to move GIMP code from GPL into LGPL? Basically we do this so rarely that is hasn't been a problem so far to get permissions from everyone who touched the code in question. For years you have been saying that something that makes GIMP great is that you have taken the code through a major clean-up process. [...] However, you say above you rarely do refactoring. Your definition of refactoring is rather limited. Refactoring is a whole big fioeld and lots of it is imposing order on something without that order. A classic example is the creation of the GIMP object hierarchy which exists now, from essentially flat code as it was in 1.2. It seems like you're limiting refactoring to code re-use via extraction to libraries. This is a very small part of what is known as refactoring. Cheers, Dave. -- 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] reporting bugs on builds
Hi, Henrik Brix Andersen wrote: in GNOME Bugzilla. The GIMP developers have no way of fixing a bug even if they know how it should be done. Personally I consider anyone who contributes their time to furthering the GIMP (including Jernej) a GIMP Developer. But seeing the waste amount of bugs filed primarily for win32 installers since we released 2.0.0 I am slowly starting to change my mind. Perhaps a '3rd party installer' or similar component should be added to the GIMP product. Bugs can then be re-assigned to that component instead of being resolved NOTGNOME. So - will I create the Windows-installer component with Jernej and the module owner? Cheers, Dave. -- 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] Re: reporting bugs on builds
Hi Jernej, Jernej Simon?i? wrote: Not sure about what kind of proprietary scripts are you talking about - the installer scripts were always available... I'm glad you joined the thread, because there's one question that hasn't been answered yet. Would you like to have your installer's problems tracked in bugzilla? Or would you prefer us to refer the bug reporters to your page? If so, where should we send them? Cheers, Dave. -- 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] Plug-in howto
Hi Nathan, Nathan Carl Summers wrote: On 3 May 2004, Sven Neumann wrote: Well, dgo was started to finally give an alternative to this outdated sourceforge site, so please consider to help with dgo instead. It's in CVS, you have write access, feel free to improve it. Do you have to run any weird scripts after you make changes, like you did with the old wgo? CCed to the list in the intrest of making the answer public knowledge. You don't *have* to run any scripts with the new wgo, by the way (although you probably should as a sanity check), the rebuild is done as a check-in hook. The same thing is true of the dgo site, but it helps to have a docbook XML set-up working, since this allows you to check for mistakes before committing. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Screenshots
Hi all, I was just looking for some nice looking screenshots to show off on the GUADEC GIMP pages, and the best ones are all on developer.gimp.org It would be really cool to have lots lots of screenshots of the GIMP on www.gimp.org. Could someone from the web team take responsibility for this and publish an e-mail address where screenshots can be sent to be included on the site, please? In the meantime, I will link to screenshots on dgo. The current content to go on guadec (which will also probably end up on dgo when the dust settles) is here (as usual, all corrections comments are welcome, that's what wikis are for): http://wiki.gimp.org/gimp/GimpCon2004 Cheers, Dave. -- 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 Menu Reorganization
Hi, Nathan Carl Summers wrote: The forward direction (menu XML to wiki text) should be trivial with xslt - the other way would probably be easier with perl or something. That's funny, I think of wiki - menu as being the forward direction. :) Weird. Perhaps you're sufferring an LSD flashback? Turning wiki into XML looks like it should be trivial with Perl. I think there may even be a whatchummacall that does it already. Cheers, Dave. -- 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 Menu Reorganization
Hi, Sven Neumann wrote: Nathan Carl Summers [EMAIL PROTECTED] writes: You don't need a special account or anything -- just visit http://wiki.gimp.org/gimp/GimpMenuReorganization and hit EditText to edit the page. You can move things around, rename items, or just add commentary! Here is your chance to help make gimp more usable. Very nice. I wonder if there's a way to convert between the menu XML files and the Wiki content. That would make it possible to easily try the suggested menu layout. The forward direction (menu XML to wiki text) should be trivial with xslt - the other way would probably be easier with perl or something. I don't have time to do this right now, though - if it's still up for grabs in a couple of weeks, I'll have a go. Cheers, Dave. -- 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] Joining the GNOME Foundation
Hi, Marc A. Lehmann wrote: On Sat, May 01, 2004 at 06:06:54PM +0200, David Neary [EMAIL PROTECTED] wrote: For the moment, I am working under the supposition that the best option available to us is to join the GNOME Foundation. That means that when we do fundraising, the donations would go to the GNOME Foundation, and when we have expenses we would ask the GNOME Foundation for money. In what way would this be different to we give the donations to the FSF and ask them nicely if we want money? The FSF has made it clear that they won't accept donations on behalf of GNU projects. They have always been very generous, and the only argument I can see against partnering with the GNOME Foundation is that it might annoy RMS and the FSF - it would be nice to know if this is the case *before* we do anything. It is possible that we could have an arrangement with the GNOME Foundation that priority be given to the GIMP for allocation of funds that were raised by us. The original idea behind a seperate gimp foundation was that begging would be necessary (even if the GNOME foudation might be rather open to giving money...) True. It's also true that the FSF has never let us down when we asked for funds. The only effect of this is that people will be able to give money to the GIMP, and be fairly sure that the money will go towards the GIMP (not certain, mind - the details of a partnership would need to be hammered out). Also, the GNOME Foundation has a track record handling bounty type donations, which the FSF does not, and since many of the proposals for funding that we get are of that type, it is in our interest to have some way to reply yes, thank you, how much were you planning to donate, and what features do you want? Currently we don't have that. Are there any people opposed to closer ties with the GNOME Foundation? Well, GIMP is not part of GNOME, and this assertion was made repeatedly over the years. Apart from labeling GIMP more of a GNOME program, I wouldn't oppose (but I don't count much anyway :) I know, We could even change the name of the GIMP to the GINPOG it's been repeated so much. But this is a bunch of people with really close ties to the gimp (we use their toolkit and infrastructure, a few years ago they used to use our toolkit), who really want to help us both short term and long term. And why wouldn't you count? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Joining the GNOME Foundation
Hi all, Myself and Dan Rogers will be meeting with someone from the GNOME Foundation this week with the intention of having greater co-operation with them on things like money. For the moment, I am working under the supposition that the best option available to us is to join the GNOME Foundation. That means that when we do fundraising, the donations would go to the GNOME Foundation, and when we have expenses we would ask the GNOME Foundation for money. It would also be an idea to allow the Foundation to make wilber and GIMP T-shirts and the like to generate revenue. The alternative is that Dan continue with the work involved in creating an independent GIMP Foundation. As was discussed in Berlin last year, the initial powers and responsibilities of the foundation would be limited to a bank account and a federal tax ID, and the board would basically work on fundraising and spreading the message of GIMPLove (press releases and the like). The short term effects of doing this would be that we wouldn't have any way to accept tax-deductible donations in the US for this year, and it is unlikely (given Dan's current availability) that the foundation would have cleared up all paperwork issues and elected a board before the end of the year. On the other hand, a partnership with the GNOME Foundation would give us federal tax exempt status in the US now. We could probably work out an arrangement where contributions made to the GIMP get used for GIMP events. Are there any people opposed to closer ties with the GNOME Foundation? Cheers, Dave. -- 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] more GIMP foundation stuff
Hi, Daniel Rogers wrote: Instead of all this though, I've been talking to Tim Ney about having the GNOME Foundation take a more active role in supporting the GIMP. If GNOME was willing to do this, this would probably be a good option for us. Gnome already has the infrastruction and ability to act as a non-profit, as well as plenty of corporate suppport. What do people think of this plan? Again, to be a little more clear. GNOME would like to support us more than just in name. All we (e.g. more than just me) have to do is say yes. It is unclear, at this point, how exactly GNOME would be involved with The GIMP, but those details could be worked out. Does this interest anyone? Is anyone outright opposed (and why)? For the record, I'm in favour of this approach. There is no real benefit in setting up a foundation structure which will just be a fundraising structure, causing some people lots of work and cost, when there is an organisation prepared to partner us which already has all of this in place. Of course, that does mean that we will be taking a small piece of a bigger pie, rather than having our own independent revenue source, but since we currently have no revenue source, that won't make a big difference. Cheers, Dave. -- 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] Image Info Dialog
Hi, Carol Spears wrote: another one that i stop and think about is the Layers --Transparency --Add Alpha Channel. while it is true that it only works on one layer at a time, it is also true that there is only one layer for it to work on. you could have it run from Image Menu or from the Layers Dialog or from the Layers Menu and have it add transparency to the only layer (the background layer) that doesnt have it. I tend to agree with you on this. Are there any good arguments for having this in the Layer menu? Cheers, Dave. -- 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] Image Info Dialog
Hi, Carol Spears wrote: is it impossible to have it show up in both menu locations? No, not at all. You register the same callback twice for two different menu locations. Cheers, Dave. -- 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] Unsharp plug-in
Hi Geert, geert jordaens wrote: I've modified the unsharp plugin and added a preview functionality to it. How do I share it, do I sent it to someone for review? As you have seen by now, there are lots of ways. The easiest way is to make a unified diff of your sources with those in CVS or in your release, and attach the patch to a bug report. Alternatively, you could mail your patch to the list, or to a developer, and he might do that for you :) Cheers, Dave. -- 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] Re: Gimp usability tests
Hi, Simon Budig wrote: Sven Neumann ([EMAIL PROTECTED]) wrote: This would, of course, make selection CSG operations more difficult. Simon said that implementing CSG operations on vectors would be not feasible. Ok, maybe you misunderstood me or I expressed it the wrong way: It would of course would be very good to have CSG operations available, but I am not particularily eager to implement them: I hope I'm not the only one asking myself this question... what is a CSG operation? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
