Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
Hi, Manish Singh a écrit : I think policing it at all is silly. That's unacceptable. And it's not your decision to make. One really should evaluate emails on the actual *content*, and not what the From address says. There are several active contributors who do not use gimp.org addresses, assuming their comments should have less weight is rather rude. I *am* judging the content. The content is crap, often abusive, and to my mind obviously unacceptable behaviour for a community member. But someone coming to the project for the first time doesn't have the same ability to make that judgement. Can we please stop cluttering the development mailing list with this now? There's an easy way to do that - ban Carol from the list and remove her gimp.org email address alias. Or get out of the way and let someone else do it. Cheers, Dave. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
Hi Sven, Sven Neumann a écrit : That was probably the most stupid direction that you could have steered this discussion into. Thanks for ruining an effort to actually discuss a problem that we seem unable to deal with. Right - because otherwise we would surely have dealt with the problem. As long as yosh defends carol's use of the gimp.org email address, and refuses to answer any mails asking him to remove that address, then all we're doing by talking about it is wasting everyone's time. I sent a mail last week publicly asking for yosh to talk about his policies for gimp.org domains and email addresses, and he hasn't answered. We have both publicly asked for carol's email address to be removed. What do you think will change the situation? If yosh is the blockage, then we need to convince yosh to remove carol's gimp.org email address, or route around him. If routing around him means changing name domain name, why shouldn't that be brought up as a possibility? The other way to route around him is to move the domain somewhere else, and have our mailing lists hosted somewhere where the archives work. But that would need the domain owner (yosh) to make the change, and that's not going to happen soon. I'm open to suggestions if you have any other ideas. Cheers, Dave. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Are @gimp.org aliases needed at all?
Following up to myself, with a minor correction: Dave Neary a écrit : But that would need the domain owner (yosh) to make the change, and that's not going to happen soon. The domain is owned by Shawn Amundson (snorfle), but he hasn't been involved in the GIMP for a long time and yosh is the man who controls the domain. I'm open to suggestions if you have any other ideas. So another idea is to persuade Shawn to move everything gimp.org to another server (perhaps somewhere in gnome.org/RedHat's colo to take advantage of their sysadmin team?), update the DNS records and move on with our lives with new sysadmins. Cheers, Dave. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp.org email addresses (was: Re: requesting a change in the defaults)
Hi, Manish Singh said: On Fri, Sep 22, 2006 at 11:03:48AM +0200, Alex Fernandez wrote: i cannot give any kind of logical reason for it and probably you should do the right thing and trash this suggestion of mine. Yes, it is the usual email pollution. You're guilty of the same. Looking at the archives, you speak up far more often to criticize others than to contribute constructively. Heed your own words and stop being a hypocrite. Alex (and others who don't know), Yosh is the maintainer of the gimp.org domain, including subdomains and email addresses. He holds all the power over our DNS, SSH access, IRC, mail servers and so on. He also remains somewhat connected to XCF in Berkeley, where our mail servers continue to be housed. So if there seems to be a lack of coherence in the gimp.org policies, yosh is the man to talk to (in fact, I would like to hear his opinions on that subject on-list). Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ 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 48, Issue 12
Hi, Sven said: Correction: the vector layer code is in its own branch and it is not going to be part of the 2.4 release. It will not be merged to HEAD until after the 2.4 release. Simon said: That is not correct, the code is in the soc2006-vector-layers branch in CVS and will not be merged with HEAD before 2.4, since this is such a drastic change, that needs way more user testing before we release it in the wild. That having said, I am really glad about this project, it works quite nicely already, although there is of course a lot of room for polishing. Thanks for the corrections. Alexander asked: Divyanshu's blog has no download links, registry.gimp.org knows nothing about wavelet and it's not clear if his code is going to make its way to 2.4 or after 2.4, or will be available as plug-ins at registry.gimp.org sometime later. Any updates on this please? Plug-ins are typically developped outside CVS, so they're not in the repository. They didn't get put into the registry either, but, well, the registry sucks a bit and badly needs replacing. http://www.home.unix-ag.org/simon/gimp/soc-2006-wavelet.tgz Simon listed this tarball as the place to get the source code in the Google SoC report. about resources repository project Considered he started well, is there some initial code for others to start from? No idea. You could ask Andrey himself, or his mentor, Michael Schumacher. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] On holidays, and summary of GIMP money
Hi all, From this evening (in about an hour) I will be on vacation, and away from a computer (yes, 100%) until August 28th. I've disabled mail from the lists, but if anyone urgently needs approval for a GIMP expense, Sven and mitch can both approve expenditure from the GIMP fund at GNOME. As I said on IRC last night, in case anyone is wondering, the GIMP currently has roughly $21,000 in the GNOME fund. It was donated for the development of the GIMP, and should be used for expenditures which further the goals of the GIMP project. I was pressed for an answer on what I thought that kind of expenditure might be, and here's a subset of the answers I gave: 1. Paying for the GIMP user manual to get into a publishable state, and get it published 2. Paying for travel/participation in certain conferences which have the potential to bring attention, money or people to the project 3. Paying to improve our infrastructure (reminder: there's a $500 cheque waiting for yosh, and I'm waiting for a quote for off-site back-up) 4. Paying for GIMP conferences and get-togethers (although I really think we should fundraise for conferences, as I did this year and in Kristiansand Things I don't think we should spend money on: 1. Hardware for individual developers (computers, scanners, cameras, tablets, etc). We should try to fundraise for this when people can fill a specific need (working on GIMP support for a tablet, for example), but in general buying people toys isn't useful 2. A server - in spite of what I said in point 3 above, I think we should be using our great contacts with GNOME, RedHat, HP, Canonical and others to get hosting, get use of servers and services outside of XCF, and make our sysadmin process more transparent, rather than spending money on hardware which could be donated 3. Sending people to any old conference - in general, if you're giving a talk on the GIMP in a conference, we should ask the conference organiser first, the GIMP second for sponsorship. And I don't think it's appropriate to pay for travel from London to Boston for someone to man a stand, even though I was prepared to do this last month. We should instead work on building up a good group of people worldwide who can give GIMP presentations and man GIMP stands, and make sure they're co-ordinating. So that's my summary of GIMP money - there may be some opposition to some of these things, so let's have at 'em. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Perspective Clone Tool
Hi Pedro, Pedro Alonso said: I am developing Gimp Perspective Clone Tool in the context of SOC. Currently the status of the project is: snip - Now I have to develop a gui so the user may define the perspective plane in a similar way that they do via perspective tool. Using GimpTransformTool. I don't know how to do that :S How about a GUI similar to the SIOX tool, with a first step where you set the perspective, and a second where you paint? Workflow would go like this: 1. choose perspective tool 2. In image, clicking brings up a perspective tool wireframe (not preview). I manipulate the wireframe as I would for the perspective tool. To finish, I double-click the image. 3. The wireframe stays on the image (perhaps there needs to be a reset button in the tool options to allow me to reset and choose another perspective?) - this probably isn't necessary, but might be useful. 4. I choose a source as with the clone tool (Ctrl-click) 5. I draw (the active brush is used), and the source I take from the image is transformed using the transformation matrix of the transform tool. This seems like a pretty tricky interface to use, but it's an idea - and it sounds like there's lots of opportunity to reuse existing functionality to get your transformation matrix. I remember that Cameron Barton was asking for similar functionality to this some years ago. Cam, are you still around? Want to give some interface ideas? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Building healthy community
Hi, http://www.oreillynet.com/conferences/blog/2006/07/oscon_how_open_source_projects.html During OSCon, Ben Collins-Sussman and Brian Fitzpatrick of Subversion fame gave a talk which was apparently very interesting on how free software projects can survive poisonous people. There's lots of good advice in there, including: * Document your community, decisions and processes * Have healthy collaboration practices * Avoid names in source code - use revision history for documenting who did what, to avoid ownership of code/modules Anyway, it seems pertinent for the GIMP developers community, and perhaps a starting point for putting in place some better practices. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] fact roundup
Bratsche said: Since nobody has provided that information yet, consider these two possibilities: Correction, I gave that information. http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg11430.html http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg11432.html Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp-developer Digest, Vol 46, Issue 16
Hi, Carol Spears wrote: i keep looking for some sign of competence in this letter. dave is my friend and i am certain that he is competent to conduct this GIMP business, but i am looking for actual evidence of this in this email in particular. Pray tell - what evidence is there to the contrary? personally, i would feel more confident in dave's competency in this position if he would feel passionate enough about it to actually read the gimp mail lists and even quit a few times since he feels strongly about things. So reading a mailing list through a digest is not reading a list? I don't understand. And I did quit, remember? I'm feeling all this aggression Carol - is there something you'd like to get off your chest? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp-developer Digest, Vol 46, Issue 16
Carol Spears wrote: the letter has been deleted from the reply. maybe you could paste the email and be real clear about what i am missing. http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg11413.html it is less than participating in a real exchange. it screws up threading. Is that my problem, or yours? I change the subject line usually - didn't this time, since the subject was the digest. i believe that if you look at the letter i wrote again, you will see that i am asking nicely and with a little bit of humor that you work with a little more honesty. I missed that. So can you clarify, please, in what sense I'm being dishonest? Also, if you could be very precise and explain to me why you think that I am somehow making GNOME eat Wilber, that would be helpful. how could this be aggressive? So - for clarification for my little brain: you're calling me dishonest, incompetent, you're implying that somehow I'm stealing GIMP money (if that's not the case, please explain what you mean by Carol said: in fact, perhaps jimmac can find the time to make a tee shirt that states that wilber is dead. gnome can just steal gimps money and get it over with. ) Now, in the light of all that, can you explain to me how that's not aggressive? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Gimp-developer Digest, Vol 46, Issue 16
Answering the two questions asked. Carol Spears wrote: i have the expectation that you and others working with things here have at least some familiarity with the community and a consistent presence. can you tell me clearly what is wrong with this expectation? On the one hand, nothing. On the other hand, since this mailing list has consistently gone down in quality in recent years, and since most of what I would like to see happen on this list appears to happen on IRC (or so I'm told), perhaps being subscribed to this list doesn't count as a consistent presence. Oh - and I do have at least some familiarity with the community. for instance, in your plans, are there any GIMP people involved yet? No - Mukund volunteered to go, but will not be able to get a visa for the US. No-one from the US on gimp-user or gimp-developer has offered to go and man the stand. I know that both yosh and pippin will be around, but neither will be available for the stand, apparently. Help would be appreciated. Particularly from US based artists. Which is why I posted my initial request on gimp-user, not gimp-developer. But then, this particular call for help is probably useless, since I suspect that you I are the only two people interested in this thread anymore. Although even that is probably not true. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] XCF format specification
Hi, http://henning.makholm.net/xcftools/xcfspec.txt Wow! When you said you were putting it on your TODO list, I wasn't expecting it this quick, or this complete. This is amazing work. The only think that I can see which is obviously missing is a definition of the effect of layer modes and masks on compositing. I would like to contribute it as a replacement for xcf.txt, but I would like it to be correct first. While that's an admirable goal, it's already vastly better than what's there already. So I think the sooner we get this into devel-docs the better. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: SoC mentors students: mid-term evaluations!
Hi, Michael Schumacher wrote: to every mentor of our Summer of Code (GSoC) projects: please do not forget to submit the mid-term evaluations for the Google Summer of Code. They are due on July 5th, 2006. Thanks Michael for sending this reminder. Google's main communications channel towards the SoC admins and mentors is the group/list Summer-Administrators-2006, to be found at http://groups.google.com/group/Summer-Administrators-2006 It is recommended to be subscribed there. 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. In fact, I had understood that mentors were automatically subscribed to the list on being accepted as mentors - this is what happened for me. Are there any mentors not on this list? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Getting the GIMP to work well on a OLPC laptop
Hi, As the SoC administrators probably know, the OLPC project is entering a phase soon, where they will be making a very limited amount of laptops (no more than 1 per project requesting) to free software application developers. I thought maybe someone here might be interested in getting one, and would have the time to do profiling and memory work with a small screen laptop to reduce the footprint and increase the speed of the GIMP in that kind of environment. One other constraint, you don't have any (or much) hard disk - swapping times out is an expensive operation. Is anyone interested? If you don't have time to spend on this, the greater good is probably best served by letting another project have one, but it would be great to have a faster smaller GIMP. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Possibility of a stand in Siggraph
Hi, There's a decent possibility of having a stand very cheap (proper island stand, partially sponsored, in the main conference area) which we would share with Blender and some other projects (Ton from Blender's co-ordinating). I would love to have the GIMP represented at a top flight conference like this, and think it's worth the money - the GIMP's part of the pie would be between $1K and $2K, depending on the levels of sponsorship, whether we bed in with the GNOME guys, etc. I think this is the kind of thing we should be doing more, and we definitely have some budget to spend on it. What say ye? And if we do join up, who would like to represent us, do some demos, etc? Someone in the Boston area would be best, but we can probably afford to contribute to the costs of the most appropriate people if there aren't good candidates in the area. Siggraph is in Boston from August 1st to August 3rd. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimptool-2.0 installed on Windows XP?
Hi A.J., A.J. Bobo wrote: I am interested in learning how to write plug-ins for GIMP without having to use script-fu. I found your tutorials and really like them. Unfortunately, I cannot seem to find gimptool-2.0 on my computer. I'm using Windows XP and GIMP 2.2.11. Was this file (and the required header files) not installed on Windows, or did I miss something? Where can I find the files I need to write and compile plug-ins? Thanks for your help. Thanks for your praise - I always like hearing back about the articles. I'm forwarding your mail on to the GIMP developers list, since honestly I've never developped anything for the GIMP on Windows, and I don't know where you might be able to get a hild of a gimptool-2.0 for the platform. The build environment for GIMP development on Windows is a bit tricky - I've bailed out a couple of times after getting all the dependencies installed because of some linking issues - but if anyone can point you in the right direction, they're probably on the gimp-dev list. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP and Google SoC (from digest)
Hi, Michael Schumacher wrote: Von: Dave Neary [EMAIL PROTECTED] Hi all, I have registered the GIMP as a mentoring organisation for the Summer of Code (I had been in contact with Google before the announcement), we should be up on the page over the next couple of days. It would have been nice to know this a bit earlier. As you can see in the other thread, we were already preparing stuff... I was away for the weekend, when the announcement was made, but the contact I made was last year when the GIMP wasn't in the mentoring organisations, because no-one had asked. This year, I got in early. I'm not taking this over, by any means. I'd like to have as little as possible to do with it, but I'm happy being an initial point of contact. Bill Skaggs said: Thanks Dave for taking the initiative. Does this mean that you are volunteering to be the coordinator, as described in the SoC FAQ? I'm the coordinator - I have received the information we need to sign up mentors, and anyone who would like to be a mentor for an SoC project should contact me. The role of mentors is to be present in the soc groups during the start-up phase, commenting on GIMP project ideas, helping people refine those ideas, and after project selection, to supervise someone's work, be their shoulder to cry on when things are going badly, their wall to bounce ideas off, their interface to the greater GIMP community. We will need 3 or 4 of these, at least, perhaps more. We should settle on half-a-dozen well-defined project ideas, because having too many choices leads to brain freeze, and people who want to work with GIMP but don't like any of the suggestions are always free to come up with ideas of their own. And it would be nice to put them on a page on the developer web site as opposed to the Wiki. It is much the same thing - the important thing is to have the ideas available quickly. Either way is fine with me. I would go for 10 or 12 decent ideas. I would rule out anything that starts finish Outside of that, there's no need to provide specs, and ideas are there to inspire. They should be realistic, but make people go wow at the same time. I think this timeline is unrealistic, and that it would be better to aim for the results of the student projects being incorporated in the 2.4 release. You're probably right. But we'll need to be a bit slushy about hardening features - 2.4 will be feature frozen when SoC finishes. We can release a slightly buggier than usual 2.4 of course. 2) Resource management. Currently resources such as brushes, gradients etc are shown to the user in an unstructured way, which greatly limits the number of items a user can deal with. People love to make collections of things, so this would greatly enhance the user experience. This and a decent plug-in distribution system are great ideas. Sven Neumann said: - Plug-ins: Save for web for example (too small to be a project, but could be part of one) IMO Save for Web is complex enough for a project. I may be underestimating the effort involved, but I think I could throw together a prototype fairly quickly. - Effect layers - I think this is fairly straightforward with the GIMP as it is, it's a nice chunk of a project, and would be a nice feature for users How is this fairly straightforward with the current architecture? I would rather say that it is currently almost impossible to implement sanely. Ah, but I'm insane. Add a layer type for effect layers, and define 3 operations that you can associate with the layer (to start): curves, levels and colour balance. All the operations are pixel-by-pixel, which should make things easier. Then hack the projection code to add a special case for an effect layer. We'd need to evolve the xcf version number, and it probably wouldn't be possible to do anything useful with the effects layers in earlier versions of the GIMP (ignore seems about the best option). I don't see why we should wait with GEGL integration. There are people waiting for the 2.4 release to start this work. It would be a huge mistake to postpone this. The amount of GEGL integration that is planned for the next release is small anyway and is unlikely going to delay the 2.6 release. I'm not proposing delaying gegl integration. I'm just saying that to get the most benefit out of SoC, you need to release people's code soon after the Summer, and the gegl integration isn't going to ship until next Summer probably. So it seems sane to me that gegl integration start on a branch (made straight after 2.4), and gets merged back into HEAD *after* we ship a stable release with SoC projects included. That said, Bill suspects that 2.4 might not get released until after the Summer (seems pessimistic to me, but I'm a bit far from things to be able to say for certain), and in that case, he has a point. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp
[Gimp-developer] Re: [Gimp-user] 2.4 schedule estimate?
Hi Simon, Selon Simon Roberts [EMAIL PROTECTED]: Having written some software in the past, I know this is an unfair question, but I'm interested in the color management that's slated for 2.4. Can anyone point me at a time (rough waving damp fingers in the air) estimate for when that might be released? gimp-developer is a more appropriate forum for the question (although I hope that everyone there is also here). I haven't been involved in GIMP development for a while now, so I can't really tell. Alternatively and also, anyone using the 2.3 version (described as unstable) which is available? Is it reasonable to try to use that? I would say yes. It's not feature frozen, but it's already quite usable. Does the color management part of it work? And is the CM part likely to remain constant, or is it subject to total rewrite, rendering my learning and calibrations/profiling wasted? It's pretty much finished, as far as I know. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Travel subsidies
Hi all, Wisdom tells us that the best time to book flights is around 3 months before you travel - so I would like to start booking flights for people coming to the Libre Graphics Meeting, who are in need of a travel subsidy, in about a month. For people coming from other projects, I'm going to hold off a little to see what the sponsorship situation looks like, but since the GIMP has built up a donation stockpile over the last year, I don't need to wait for sponsor approval for GIMPers. Please let me know if you need a subsidy, do me a favour and price your tickets before you let me know, so that I know how much they cost, and I will do my best to get tickets sorted ASAP. A reminder for those who have been asleep: the libre graphics meeting will bring together users and developers of free software graphics programs, and the GIMP development community will be there in force. The conference will be on the 17th, 18th and 19th of March, in CPE Lyon. You should probably arrange to arrive on the 16th, since we have an early start Friday morning with the conference because of the students. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Feedback on Summer of Google
Hi all, Someone (Michael Schumacher, I think) pinged me on IRC asking if I had any news on the google projects awards. As you know, we weren't in the list of sponsoring projects, so we added some ideas at the very end (the day before the closing date) to the GNOME proposals. Since GNOME kind of fumbled the ball on the Google thing too, there are (to my knowledge) no GIMP related projects chosen as part of GNOME's quota, and there are no standalone GIMP projects either. I've been in touch with Chris DiBona, and hopefully next time we'll be involved, and both GIMP and GNOME will be better represented. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ 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,
Dave Neary wrote:
Add these two bounties to www.gnome.org (module gnomeweb-wml in
GNOME CVS, directory www.gnome.org/bounties edit bounties.xml, run
mono build.exe
for i in *.php; do php $i ${i#php}html; done
Seriously??
Yeah, seriously. The bounties are a Novell thing at the origin,
remember? You could of course create/modify the HTML files by hand as an
alternative, but then the next time someone runs that mono script, those
changes will get overwritten.
Cheers,
Dave.
--
David Neary
[EMAIL PROTECTED]
___
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 Jay, Jay Cox a écrit : On Thu, 2005-06-02 at 18:41 +0200, Dave Neary wrote: - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) Persistent parasites can easily be used for this. Parasites are not the ideal solution and I'm not sure how many plugins use them. Parasites are not an ideal solution for this. You would idieally want a GimpPluginSettings object which you can then save/load with gimp_plugin_settings_save|load(). The storage should be a file, or part of the existing gimprc file (given RML's talk on many small files, this might be better). Persistent parasites have a problem - either they're per session or per (image|drawable). If they're per session, then the next time you start up all your plug-ins have reverted to their defaults. If they're per image, then you have to change your defaults for each application. The main point to bear in mind is that this should be trivial for a plug-in author. PS: I think you would need a time machine to get photoshop 10 by this summer :) OK, so I've made enough of a fool of myself :) I'm not a Photoshop user, okay? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ 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, Manish Singh a écrit : There are also persistent parasites that can be attached to the app. This is how the png plugin stores its default settings currently. They are backed by gimpdir/parasiterc. Jay pointed this out too. Thanks for the info. The main point to bear in mind is that this should be trivial for a plug-in author. The most convenient way would be to handle it transparently, but I can't think of a way that doesn't involve larger infastructure changes. It's a 3 month project, infrastructure changes are possible :) The hard part is a simple API that handles portable data serialization. We have that, don't we? At least, that was my understanding of the gimprc objects. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Proposing projects for the Summer of Code
Hi, There are lots of Summer project sized tasks around the GIMP that we could propose to Google. As a start: - Add text boxes to the text tool - Write a heal tool and an intelligent eraser tool (sharing as much code as possible between them) - Work on a framework to make plug-in settings saveable across sessions (this might be done now, is it?) - Convert all the GIMP utility code to real GObject widgets, and then complete the Python binding for libgimp* - Design and write a shapes tool - Reverse engineer PSD format for PS 10 and write the load/save plug-in (or adapt the existing one) to it - Add save for web plug-in - (Re)write a plug-in distribution system which integrates with the GIMP There are lots more. I'm not sure what timetable Sven's working on for 2.4, but I believe we're almost at feature freeze, which means that people can start working on these projects, and integrate into CVS once 2.4.x comes out - project deadlines are September 1st, and we should have a release to integrate against by then. Some of these are small, and are probably only a week or two of work. Others will have trouble being finished after 3 months solid work. Should we make the proposals? Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ 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, Jay Cox a écrit : Has anyone here seen the quality of their shirts? Are they screen printed or heat transfered? I prefer screen printed tshirts, but gradients like the ones we have in the gimp logo dont usually screen print very well. I'll let Federico answer the question about whether they're screen printed or not - I seem to recall that he told me that they are. And there is a Wilber without gradients. They seem like a good company and I have no reason to doubt their quality, but if I were making the decision I would want to know beforehand. And rightly so. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ 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 Simon, Simon Budig a crit : And what is involved with being the official merchandiser? How would we handle other companies trying to sell Gimp merchandise and want similiar exposure? Do we need an official merchandiser? Essentially, this is what it comes down to (de we need an official merchandiser?). Or more to the point, do we want a GIMP store. Clearly we don't *need* anything. Currently, there is next to no GIMP stuff, and what little there is is not profiting the GIMP project at all. This agreement would be a formal agreement whereby sourcewear gets exposure from gimp.org, and in return we get money, and a variety of other nice stuff (t-shirts printed at cost for sale at conferences, for example). So what is involved in being the official merchandiser is that they would be the only company with a prominent presence on gimp.org. Other companies who want to produce GIMP merchandise can do so (with the permission of the copyright holder on Wilber , namely tigert) independently of gimp.org. If the project as a whole decides that we don't want to have a relationship like this with a merchandiser, then fine. We won't, and we will continue not to have GIMP stuff for sale which will generate money to pay for stuff. Right now, we're not paying for mych stuff as it is, in spite of my recent mails on our financial situation. But as I also said, the relationship in its current state is a non-starter. Federico is selling almost no GIMP t-shirts, and until there is some link bringing GIMP fans to sourcewear, that's not going to change. Which means we continue to sit on our high horse, and people who want to buy t-shirts don't know where to go to find them. I would love to be able to buy GIMP stuff online, and know that for every 20 that I spend, the GIMP is getting 5. Frankly, making www.gimp.org a platform for a single merchandiser, so that he can ship Gimp-T-Shirts which also serve as a platform for said merchandiser does sound like a bad deal for me. Also the stuff currently available does not catch my fancy. We will ask to validate product lines, and I don't think Federico would oppose printing designs which GIMP community members come up with. The t-shirts are a very high quality, so the only issue is the designs. The deal would be non-exclusive for GIMP goods, but would be exclusive (with a limited lifetime) for placement on gimp.org. One requirement I'd like Federico to satisfy is the ability to link directly to the GIMP products rather than going through the main page. The idea of doing things this way is that it's the path of least resistance to getting a GIMP store. We control the product line, get regular updates on sales (we can even consult the sales database in real-time), and regular payments. We don't have to worry about credit cards, deliveries, customer service, stock management or any of the other things that make an online store hard work. I believe the hassle which will come up when other merchandisers become aware of this deal is not worth it. I've talked to a few, the reason I'm suggesting Federico is that he has already been making and selling high quality GIMP t-shirts for several months. And why would there be hassle when other merchandisers find out? None have even approached us to try something like this. In any case, if it's the bother of other merchandisers you are worried about, I am willing to be the front-man for this and take all such requests. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP merchandising
Hi all, As many of you know, we have an informal merchandising arrangement with Sourcewear.com which has raise a few dollars this year (not much, though). I would like to improve on this relationship, and I know that Federico at sourcewear feels the same. For my part, I'd like to see better products, and more products, as well as formalising the cut we get from merchandising (this is currently an informal arrangement, I think that we should get an engagement on paper). For their part, they would like to continue having their logo on the arm (which I'm OK with), and they would like to be our official merchandiser - that is, have a place in the sidebar on every page, and a place of prominence on the front page. That's why I'm writing here. Is this arrangement OK with people? I will firm things up quickly with Federico if it is, but I didn't want to start negociating something without running it past the communtiy that has stuck with the GIMP. Lazy approval is in effect - if you haven't replied in 3 days, I'll assume everyone's happy with this. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GUADEC cheap accommodation
Hi all, 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. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Large donation
Hi all, I just found out from Tim Ney that the GIMP has received a donation of over $5000 from Hiroyuki Ikezoe in Japan. I really don't know what to say - individual donations of this size are rare, and I am flattered that we have been the recipîents of such generosity. I will do the sums of the donations which we have received over the past year, and let everyone know approximately how much money the GNOME Foundation is holding for us. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Organising a conference
Hi all, A separate mail to talk about what we can do with the money we have now. It is certainly enough to start planning a GIMPCon, if someone is willing to put the work into doing that. If we do plan a GIMPCon, though, I would recommend being a little more open about it than the summit type events which we had in Berlin and at GUADEC. We should try to organise a couple of days of talks and demos open to the public, and why not get some Inkscape, Scribus, OO Draw and Blender people involved and make it a Free Graphics Con. One candidate, if people are interested, would be to join up with Blender Con, which is planned for October, in Amsterdam. Just to be clear, I am not in a position to put time into this. If we are to have a GIMPCon this year, someone else will have to organise it. I have no problem being an intermediary with the GNOME Foundation for money, though. Cheers, Dave. -- David Neary [EMAIL PROTECTED] ___ 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, Selon Michael Schumacher [EMAIL PROTECTED]: William Skaggs wrote: Sven wrote: But isn't it accessible from http://wilber.gimp.org/~raphael/metadata/ ? No, that doesn't exist any more. And I don't think it ever had the source code anyway -- but I may be wrong about that. There seems to be at least a bit of source code: http://wilber.gimp.org/~raphael/metadata/src/ When that's ready to commit, it may well supercede part of what Bill has done, but I'm in favour of this code (which works, and does something which is often requested) going into CVS. An awful lot of the code in CVS is going to be replaced and has been like that for year - we should not wait for a module which is in the works, when there is code written already which gives people features now. We're not talking about someone duplicating effort, since the effort is already done. I thought it was amusing that someone said to Bill that storing metadata in lots of little parasites is not the right thing - 2 years ago, people told me exactly the opposite. Cheers, Dave. -- Dave Neary Lyon, France ___ 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, Selon Daniel Egger [EMAIL PROTECTED]: On 05.01.2005, at 18:27, Dave Neary wrote: Before people get high-horsey about this, consider that 90% of digital cameras have embedded DOS as their OS, and are thus unable to generate files which are not 8.3. I don't think it is pretty safe to assume that FAT support means that anything close to DOS could be the operating system of a camera; Excuse me, I was confusing the FAT filesystem and DOS, which is not a good thing to do. And the 8.3 requirement is also a FAT thing, not DOS. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL development/gimp integration
Hi Sven, Selon Sven Neumann [EMAIL PROTECTED]: Hal V. Engel [EMAIL PROTECTED] writes: it appeared to me that this approach had been rejected, or at least discredited, at that time. At the very least there were sound reasons put forward that called this approach into question and the only arguments on the other side were that it made programming the color management stuff a little easier. But I am also aware that there were many involved in the earlier thread on this subject that did not seem to think there was an issue with this approach. I don't think we rejected this part. IIRC we said that it should be optional and that we want to allow people to disable color management entirely. Anyway, whatever we decide to do is just a matter of user interface and doesn't affect the GEGL operators involved. The short summary of the entire discussion is something like this: We should allow a colour profile to be associated with an image if possible, and only apply it (that is, change the colorspace of an image) if explicitly requested. There will be issues with things which aren't colorspace dependent (like the color picker) as well as copying and pasting between images, which will cause problems, but for the moment the damage caused by these would be less than applying color profiles on load. However, we should have a default working colourspace, and the user should be able to convert to that colourspace on load. This should be configurable. There should also be an option to disable colour management altogether - in which case, we work in the default colourspace, don't do any conversion at all, and simply load and save the colour profile as a parasite attached to the image. My understanding was that the solution which Alastair Robinson was working on was to have a plug-in to apply a color profile, but also to have the idea of a (per-image) working colourspace, and a configurable (global) display colour profile and default working colourspace. That is, every image loaded which doesn't have an attached profile will be assumed to be in that default colourspace. If it has an attached profile, the user will be offered the choice of (1) applying the profile to get to the default colorspace, (2) working in the embedded profile's colorspace or (3) disabling color management for the image, in which case we work in the default colorspace, but don't apply the profile. Again, this is a synthesis of my understanding of that discussion, the archives are the best reference for what was said, though. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS branch gimp-2-2
Hi, Sven wrote: - New features go into the HEAD branch. We may consider to merge certain smaller things back into the stable branch, but new stuff always first goes into the HEAD branch. I haven't seen a message from Mitch about it yet, but he mentioned to me recently that he wanted to depend on gtk+ 2.6 very rapidly after the release. I don't know what features are in 2.6 that will be used in the GIMP (perhaps mitch is better able to answer that than me), but I'm sure the gtk+ guys got lots of stuff in there which we would be interested in. I persuaded him that an outright dependency should wait a couple of weeks after branching, to allow people working on outstanding stuff that didn't make it in time for 2.2 (meadata editor, for example?) who might have problems updating the dependency stack to gtk+ 2.6 to get their outstanding stuff committed. I think that a couple of weeks is reasonable for that, and if the changes that we pull in from gtk+ 2.6 don't use any of the new APIs, perhaps we could reccommend gtk+ 2.6 rather than require it, in the short term. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Judging panel for splashes
Hi, Quoting Roman Joost [EMAIL PROTECTED]: On Sun, Dec 05, 2004 at 06:42:10PM +0100, David Neary wrote: I have no objections as long as people are happy with this. I would be a little worried about some splashes not getting a fair whack because they were submitted late, but sure, why not. When do you think it would be fair to call a result? Well, if I understand you correctly, the core developers have to make the decision which splash screen will be in the next gimp release. I disagree. It should be a user community decision primarily. Of course, the core developers belong to the user community. If this all is to complicated from now on and you guys want a splash screen fast, I'm very fine with your solution Dave. I don't have to make the decision which splash screen will be the winner, so I can shut up if you already figured out how to judge :) Dunno what the others think about this ... One of the advantages of the panel system is that a few people can be conscientious and look at all the entries, whereas a larger pool of people is more likely to pick their favourites froml the first 100 or 150 splashes, and ignore the last 300, which would be a shame, since there are some really nice ones down there. Another consideration is that a panel can ignore splashes that we can't ship for one reason or another (copyright material, other people's trademarks, etc) and can also use agreed guidelines (no photos, for example) whereas that's harder for a much larger collective. In either case, we need some kind of resolution on this today or we run into the other thing I was worried about, which is time. I suggest that - Mukund wipes the existing votes - We give people on the mailing lists until Thursday to vote - Please try to avoid getting mukund's page slashdotted - On Thursday evening, if the top choice is not invalid for some reason, we're done. If it is, we go onto second choice. Etc. Is there any way to close the contest page now and not have any more entries until we have chosen a winner? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Judging panel for splashes
Hi all, Quoting Roman Joost [EMAIL PROTECTED]: On Sun, Dec 05, 2004 at 06:42:10PM +0100, David Neary wrote: I have no objections as long as people are happy with this. I would be a little worried about some splashes not getting a fair whack because they were submitted late, but sure, why not. If this all is to complicated from now on and you guys want a splash screen fast, I'm very fine with your solution Dave. I don't have to make the decision which splash screen will be the winner, so I can shut up if you already figured out how to judge :) Dunno what the others think about this ... I have followed this thread during the day, and I am afraid I'm going to go back on what I said above - I think we have a very good panel set up (although I understand that some people might not like all of the people on it), and I think we should let them judge. Of course, the GIMP is a community project and lots of people have CVS access, but I think that the idea of a panel is the best way to go. So - Simon, Alan, Michael, Joao and Adam, please judge away, and whatever decision you come to will have my support, and that of a large number of people around here. To address one legitimate point which was raised, there are no artists on the panel. One of the judges has already proposed soliciting the ideas of our resident artists, and I think that is good enough to address that concern. Apologies for the huge inconvenience all of this rucus has caused. I really want to clear things up as quickly as possible, and let the judges get on with it. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-user] Re: [Gimp-developer] Judging the splash contest (mark 2)
Hi, Quoting Dave Neary [EMAIL PROTECTED]: So far only 2 people have said they would like to judge the splash contest, so we need more volunteers. We now have 5 volunteers, and I think that's a nice sized panel. Thanks a lot to everyone for their answers. (should I say who the judges are? one of them replied to me off-list, so perhaps he wanted to stay anonymous...) Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: [Gimp-developer] Judging the splash contest (mark 2)
Hi all, Quoting Dave Neary [EMAIL PROTECTED]: We now have 5 volunteers, and I think that's a nice sized panel. Thanks a lot to everyone for their answers. It's been pointed out to me that because of the times when I started looking for people, earlier timezones have been favoured somewhat. Since people further West haven't had a proper chance to volunteer, I'll hold off on getting a judging panel together until this evening. If you want to help judge, and you haven't said anything yet, speak up. In about 5 or 6 hours, I will send a mail to the panel of 5. Apologies to the people who I already mailed to say they would be judging. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-developer] writing plug-ins
Hi, Quoting Simbul [EMAIL PROTECTED]: Unluckily I can't read french. Could you point me to some of the sources you used for your articles? I'll ask my professor for the open licence, I hope he'll agree ;) It looks like you have them already - I relied heavily on Kevin Turner's article. I did a paper and presentation for GUADEC last year on the subject which is online here: http://dneary.free.fr/guadec-paper/ http://developer.gimp.org contains the full API docs for libgimp. Finally, I learned a lot from the existing plug-ins. If you were to pick one of each main type (file plug-in, image plug-in and informational plug-in), I would reccommend pnm, edge and colorcube respectively. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] adding option to crop tool
Hi, Quoting Olivier [EMAIL PROTECTED]: snip gboolean blank_outer_region; snip GIMP_CONFIG_INSTALL_PROP_BOOLEAN (object_class, PROP_BLANK_OUTER_REGION, blank-outer-region, NULL, FALSE, 0); snip options-blank_outer_region = g_value_get_enum (value); g_value_set_enum (value, options-blank_outer_region); This looks rather suspicions - you're declaring a gboolean as a BOOLEAN property, and then using get_ and set_enum to get and set its value. Try changing these to get_ and set_boolean and see what happens. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New Image dialog usability bug
Hi, Quoting Sven Neumann [EMAIL PROTECTED]: Since you admit that it is useful, I don't understand why you don't want to learn that you need to select the unit first. Because this isn't the afforded way of doing it. We should aim for affordance where possible. If people use the width, height and unit to create 5x3 postcards, then the way to enter 5 inches by 3 inches should be natural. This isn't something I do a lot myself, but I accept that this might be something people want to do. IMO there are two solutions, none of them involve any change in the dialog layout: (a) Don't set a resolution on the size entry. (b) Explain the behaviour in the documentation, close as WONTFIX. You forgot a third solution, proposed in bugzilla, which you said yourself wouldn't be too bad, and that is rearranging the frame with the units in it to look like this: Units: [mm] Width: 210 Height: 297 That provides the affordance for people who want to create images by unit, and also allows us to keep the current behaviour for unit changing without confusing people too much. I think that this is a reasonable way to organise things. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] on splitting things off
Hi, Quoting Sven Neumann [EMAIL PROTECTED]: Dave Neary [EMAIL PROTECTED] writes: Do automake and libtool have any upcoming improvements that might help with the pre-configure and linking stages that I should know about? Well, what versions are you using at the moment? 1.7 and 1.5 respectively. The improvements I was asking about were particularly performance improvements, by the way. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2
Hi, Quoting Sven Neumann [EMAIL PROTECTED]: I do think however that we should give us a little bit more time and try to get the following done during the next weeks: - add more plug-in previews - try to make the previews scale with the dialog - implement color management as was discussed earlier - fix unit handling and resize / scale dialogs - allow for better layer positioning / alignment - integrate the metadata editor that Raphael is working on - finish and fix whatever is unfinished or broken I would suggest we attempt to get a 2.2 prerelease out by the end of this month or early in october. Given the fact that the tree is fairly stable, we should then be able to deliver 2.2.0 by the end of october. Sounds good. I think that we will be in a good position to see in a couple of weeks time whether these features are going to be in 2.2 or not - if there haven't been any commits in a 2.1.5 release or whatever for color management, for example, it is probably best not to wait for it. A pre-release in a month or so sounds good. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] programming classes with gimp
Hi Steve, Quoting Steve Siverling [EMAIL PROTECTED]: I was thinking it would be cool if their were classes that people did gimp development in, and gained experience that way. Any thoughts? Sure, that would be great. Do you have any specific suggestions about how that would work? Usually things like that happen without our knowledge, but it would be cool to have us in the know. If someone asked for people to give a course for a specific reason, I'm sure that someone around here would be able to help out... Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-plugin-template: install
Hi, Quoting Sven Neumann [EMAIL PROTECTED]: I don't think we should change this behaviour but we could very easily add another install target (for example called install-user) that installs the plug-in to the user's plug-in directory. This will only work for a small subset of plug-ins though. Most plug-ins handled by a gimp-plugin-template framework are complex plug-ins that install more than just a single plug-in. Usually there will be help files, translations, perhaps data files loaded at runtime. The extra installation target may make people think that the plug-in has been successfully installed with all its additional files while really only the exectuable has been installed. I am not convinved that it would be a good idea to do such a change. This brings up an interesting question... is it possible to install a plug-in in the user's directory, and have translations managed by gettext? Where do the .mo files get installed in this case, and how can one make gettext aware of them? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 16 bit Gimp?
Hi, Quoting Joseph Heled [EMAIL PROTECTED]: There is actually lots of the functionality I need support (and some I need to do) in the gimp already, if only the gimp was 16 bits ready. So, I wonder, any estimate how far in the future it is? Any estimate that you get will be unreliable, most likely, given the track record of the project. That said, I'll give you one. End of 2005. That is, 2.2.0 in September 2004, GEGL 1.0 (the minimum of functionality the GIMP core needs to use it) sometime around February 2005 (pure guess), and then 6 months to actually use it, followed by a 3 month pre-release cycle. That gives a release around Christmas 2005. Of wourse, this might well be complete fiction. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Howto: store comments in image from plugin?
Hi, Joseph Heled wrote: I would like to attach to the image some of the parameters of the conversion. The GIMP uses a mechanism we call parasites to attach data to an image. A good example of their use is in the jpg plug-in, for example, where we attach exif data, a comment and also save parameters. A complete list of standard parasites, and a short description of teh parasite mechanism, is in devel-docs in the GIMP sources. I am not sure , - How do I add this info to the image (I open it with gimp_image_new(...) ) - Which file formats support this kind of comment/data? png, tiff, jpg all support exif, iptc is supported by tiff and jpeg as well, there are lots of other metadata formats which are supported by various formats. I'm not quite sure. On a related issue, how can I add EXIF data to the image? Perhaps I can add some data in the EXIF comment? We link to libexif already, and use it in the jpeg plug-in. You can construct an exif header and write it to a file in the same way as we write the exif header back to the file now. libexif is available here: http://sourceforge.net/projects/libexif Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
Joseph Heled wrote: Perhaps this is nitpicking, but would like your comments. (gimp 2.0.3) After decomposing an image to HSV (in layers mode), Filters/Colors/Compose brings up the following dialog: (*) RGB Red - image-HSV.jpg-3/value-8 Green - image-HSV.jpg-3/value-8 Blue - image-HSV.jpg-3/value-8 i.e. assumes RGB, and gives all channels the same layer. 1. If it possible to infer somehow that what I want (by default) is HSV, i.e the reverse? Even cluing on the layer names would work for the case where I make some changes in one layer and want to convert back. I don't see how this could be done reasonably. I guess that if you do a decompose that compose could get at the information if you attached a parasite or something... 2. Even assuming I have to check HSV manually, why not give the first 3 layers (when they exist) as the default? (for that to work, the order of the dialog has to match the order of created layers. right now it is the reverse) That sounds sane, and shouldn't be too difficult to do. Please open a bug report for it so that it doesn't get forgotten about :) Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
Hi, Sven Neumann wrote: It's probably more useful to remember the last used mode (which is what the plug-in does already). I think it would be even more useful to set the compose mode to the last used decompose mode, rather than the last used compose mode (if you get my meaning). As I said, IIRC there's already some code that attempts to select the layers called hue, value, saturation if you select HSV mode. It doesn't seem to work very well though. We would happily accept a patch that improves this. What should it do? Set the layers in function of the compose mode? If the mode is RGB to start with and I choose HSV, should I then re-set the layers I'll use? Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] compose - decompose nitpicking
Hi, Sven Neumann wrote: Well, this is doable but it would require closer interaction between the two plug-ins. compose could read the last-used-parameters set by decompose. A prerequisite for this would be to let the two plug-ins share a common header. Or merge the two plug-ins into one... Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Color management (addendum)
Hi all, Here's how cinepaint is doing color management: http://cinepaint.bigasterisk.com/CinePaintColourManagementUserDocumentation The page is a number of usecases, explaining what happens in each case. It is basically similar to many of the things that we have been saying, perhaps a little complicated to configure, but it seems from the feedback that I have seen that several people are quite happy with it. This is for informational purposes, since we are talking about usecases for this. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Proposal: cache directory tagging convention
Hi, Quoting Sven Neumann [EMAIL PROTECTED]: Bryan Ford [EMAIL PROTECTED] writes: I'm soliciting feedback, discussion, and hopefully ultimately support for a very simple proposal that I've written up in preliminary form at this page: http://www.brynosaurus.com/cachedir/ Since GIMP doesn't put swap files into a dedicated directory your proposal will also not work for GIMP swap files (which are admittedly not worth to be archived). If there were some way to tell that the tile cache was ephemeral data, then the proposal would work, wouldn't it? Bryan, is there any demand for something like this in archiving programs? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi, Quoting Sven Neumann [EMAIL PROTECTED]: All we are discussing here is whether it makes sense to use display filters to color-correct the image display (and optionally color selector displays). I don't think there is any argument about that. It does make sense to apply the monitor's profile as the last step in the projection. The other point that we are discussing is how file plug-ins should handle embedded color profiles, i.e. whether to attach the profile to the image or not. I may be listening to a different conversation. The other point was whether embedded profiles should be applied at load time or be factored into the projection. In this scheme, the core would have to be at least aware of color profiles attached to images. It's not simply a question of attach or apply, since one has implications for the core, and the other doesn't. So this isn't just about the file plug-ins. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] color management
Hi Alastair, I'm no colourspace expert (far from it), but there were a couple of things which I spotted in this which prompted questions. Quoting Alastair M. Robinson [EMAIL PROTECTED]: In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded, scanned or whatever, it is converted from its source colour space into a working colour space (sRGB, AdobeRGB, etc.). Of course, the source colour-space and working colour-space can be the same. The advantage of this method is that the working data is always normalised, so plugins and the like have perceptually identical results, whatever the image's native colour space. The workflow for an sRGB Image might be: Image (AdobeRGB) - Working data (convert to sRGB) - Editing - Save (convert back to AdobeRGB) Yes, this is what was discussed at the conference, with one important difference. We don't convert back to AdobeRGB or whatever at save time, we simply save the working image data, with the sRGB color profile. Personally, I don't think this method is appropriate for the GIMP until such time as we have support for 16-bit or float pixels, because if we convert from the source space to a working space with only 8 bits per sample we're going to lose some information through quantization errors. I see your point. Perhaps there could be some kind of pre-loading where we apply the color profile in floating-point, and quantise afterwards? Just thinking out loud, this may be completely unfeasible. The second method, which I think we should use for the time being, is just to keep track of the source profile for each image (and have a user-selectable default profile - sRGB, AdobeRGB or whatever). snip The equivalent workflow would be: Image (tagged with AdobeRGB) - Working data (8-bit RGB, unmodified) - Editing - Save (AdobeRGB) How does this fit in with display calibration? If we work on the unmodified image data as we read it in, then on what data should the monitor's calibration profile work during projection? Should it work on the raw RGB data, or should we apply the input profile at projection time? Would a color profile be a per-layer thing? I think these are the kinds of issues that Sven thought about before, and they make adding color management considerably more complicated. I think that the simplicity of applying a color profile on imput and not having to worry about it in the rendering code outweighs the down side of any quantisation that occurs. In short, though, if we use this method, we don't need to agree on what to call our working space, because it will simply be whatever is appropriate for the image being edited! I think this is probably a very bad idea. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] what's required to develop GIMP
Hi Chamal, Quoting Chamal De Silva [EMAIL PROTECTED]: 1. What is the programming language used to develop gimp. The GIMP is almost entirely coded in C. There are plug-ins in python, perl and scheme too, and there are some hardware specific routines in assembler, designed to speed up rendering on certain common platforms. 2. What are the tools and compilers that i need to compile gimpe source code. Any C compiler should do. You will also need automake, autoconf, cvs, intltool, gettext and some other tools if you wouyld like to build from CVS. The details are in the files HACKING and INSTALL. You will also need a working installation of GTK+ 2.4.x (for the HEAD or development releases), and Xft, fontconfig and friends. And helper libraries for all the file formats you would like to see compiled in (there is a longish list, again this is in INSTALL. 3. What is the latest version of GIMPs source code. This is always HEAD in CVS. However, the latest released source code is version 2.1.1. The latest stable version is 2.0.2. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS updates?
Hi Brion, Quoting Brion Vibber [EMAIL PROTECTED]: Is Gimp anonymous CVS on a delayed copy? Yes. The delay shouldn't be any more than about 12 to 24 hours, though. Although I have memories of anoncvs being up to 48 hours out of date. Would it be possible to fix the RSS changelog to point at viewcvs, which works, instead of bonsai, which doesn't? I don't know, to be honest... Sven? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
Hi Zack, Quoting Zack [EMAIL PROTECTED]: The first is, how intimately is the GIMP tied to GTK+? Very. Although the GUI code has been separated out from the internals, the GIMP depends on GTK+ to a huge extent. It is inextricably linked to glib and gobject too. The second is, I haven't looked at the code at all, but is the GIMP multithreaded and/or does it absolutely require a multitasking OS? I wouldn't say so. I don't believe there is threading code in the GIMP, but I am not sure. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] OSCon attendance
Hi all, As everyone knows (hopefully), the GIMP won an OSI award recently. Part of the results of that is that the GIMP is one of the candidates for the annual golden award (with a large cash prize) which will be presented to the winning project in Portland at the O'Reilly Open Source Conference in a couple of weeks. Is anyone here planning to go to OSCon already? And to answer the question before it's asked, there will be no cash to pay for travel or accommodation expenses. But if someone were already going they could be our official representative at the awards dinner. Alternatively, there are several GNOME developers going and presenting papers that I noticed - if no-one here wants to go, I suggest that we ask one of them to represent us and pick up the prize (if we get one). What do people think? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] easy questions
Hi, Quoting David Odin [EMAIL PROTECTED]: The second is, I haven't looked at the code at all, but is the GIMP multithreaded and/or does it absolutely require a multitasking OS? You won't be able to use any plugin without a multitasking OS... Won't the plug-in just become modular over the main app? Oh, no - we use shared memory, so the two apps need to be running at the same time... Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] OSCon attendance
Hi, Quoting Carol Spears [EMAIL PROTECTED]: On Wed, Jul 07, 2004 at 04:06:38PM +0200, Dave Neary wrote: Part of the results of that is that the GIMP is one of the candidates for the annual golden award (with a large cash prize) which will be presented to the winning project in Portland at the O'Reilly Open Source Conference in a couple of weeks. awesome. We're a long way from winning - we're up against the Valgrind guy, Pango, VideoLAN, GNU arch and a couple of other really good projects. We have a shot, though. who are the people who live in this area? Do people live near Portland? (Joke!) AFAIK, no-one is actually here and living in Portland. yosh is in the bay area, and has said he will be able to go if the conference registration fee is waived (which I think it should be). So I guess our search is over :) lets look to find a gimp person first. That was the point of mailing here. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Fwd: guadec-list Digest, Vol 2, Issue 17
Hi, Given the number of Germans around, I thought this might tempt one or two late-comers: Forwarded message: From: Frank Rehberger [EMAIL PROTECTED] Subject: Caravan: Karlsruhe - Hamburg - Kristiansand To: [EMAIL PROTECTED] Hi, we (2 guys from Berlin and 3 from Hamburg) are travelling from LinuxTag by train to Hamburg on Saturday (June 26th) evening. We continue travelling by car from Hamburg to GUADEC. Seats in car are vacant. You are welcome to join us in train from Karlsruhe to Hamburg at 26th June: departure Karlsruhe: 19:01 ICE-502 arrival Mannheim: 19:24 departure Mannheim: 19:31, ICE-592 arrival Göttingen: 21:58 departure Göttingen: 22:03 ICE-782 arrival Hamburg: 00:06 total time: 5 hours Next day in the morning we continue travelling by car from Hamburg to Kristiansand to GUADEC, taking ferry from Hiltshals to Kristiansand. http://www.colorline.com/ Seats in car are vacant: 27.6. Hamburg-Hiltshals-Kristiansand: 2 seats vacant 1.7. Kristiansand-Hiltshals-Hamburg-Berlin: 1 seat vacant. costs for gas and ferry will be shared. If you want to join the caravan, give me a note. Regards, Frank -- Frank Rehberger [EMAIL PROTECTED] GNOME Deutschland The Twelve Networking Truths - http://www.faqs.org/rfcs/rfc1925.html -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preview widgets, wiedermal
Hi, Quoting William Skaggs [EMAIL PROTECTED]: I know that everybody dreads another go-around on this topic, but it really needs to happen in the near future. Maybe, since it has proven so difficult to come to a consensus by email, this can be put on the list as something to be settled at GimpCon. To my knowledge, Ernst (who has written the only preview widget currently out there) won't be at the conference. David Odin will be, though - and he had started working on a preview widget before the 2.0 release, but hasn't had time since then to work on the GIMP. Does this mean that you're going to be in Norway? Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Reminder: Register for GUADEC
Hi all, This is a quick reminder that if you are coming to the GIMP Conference in GUADEC, that you should register for that conference. See http://2004.guadec.org for details. If you want free accommodation, it is important to do this as soon as possible. Even if you don't, the organisers are resourcing things based on registration numbers, and since you will have to register at some stage (even if it's when you arrive), you might as well register now. Cheers, Dave. -- Dave Neary Lyon, France ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] Blur plug-in
Hi, Sven Neumann wrote: I'd like to get some feedback on the following plan for the Blur plug-in (details are in http://bugzilla.gnome.org/show_bug.cgi?id=142318): The plan is to remove the randomize and repeat functionality. That would allow us to also remove the (quite confusing) dialog. Sounds OK to me. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Conference stand?
Hi all, Do people think that it is worthwhile for the GIMP to have a stand at GUADEC? It would perhaps be a way to sell some t-shirts, have a couple of computers with people doing demos, and have an easy popint-of-contact for people when they were on their down-time. The problem is that it would need to have some work done for it - posters and banners, for example, and I will not be able to do that. Are there people who thionk this is a very good idea, who are prepared to put some time into preparing the stand and putting it up when we get to Norway? Please reply on the list, we can decide before the end of the week whether to do this depending on the response we get. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GUADEC updates for dgo
Hi all, I have made some updates to the GUADEC content on dgo, but I have not had time to do it properly - I basically copied in some xhtml from the guadec site, but dgo is docbook based. I've attached the current state of affairs - I replaced all the uls and lis with itemizedlists and listitems, but I'm not sure what to do with the as, the ps, the divs and the imgs. Could someone who has a few minutes please tidy this up and either commit it in gimp-web-devel or send it back to me? Also, if someone who knows how could add a link to this on the front page of the (temporary) www.gimp.org, that would be great too. Thanks a lot, Dave. -- Dave Neary [EMAIL PROTECTED] ?xml version='1.0'? !DOCTYPE webpage PUBLIC -//Norman Walsh//DTD Website V2.4.1//EN dtd/website.dtd webpage id=gimpcon2004 lang=en head titleThe GIMP Developers Conference 2004/title titleabbrevGIMPCon 2004/titleabbrev summaryPlanning the next GimpCon/summary /head h1The GIMP at GUADEC/h1 para The GIMP Developers Conference 2004 will be held as a sub-event of ulink url=http://2004.guadec.org;GUADEC 5/ulink in Kristiansand, Norway, on the 28th, 29th and 30th of June, 2004. /para h2GIMP related talks at GUADEC/h2 div class=paper div class=figureleft p img src=http://2004;guadec.org/schedule/Dave_Neary.jpg; width=160 height=200 alt=Dave Neary/ /p pDave Neary/p /div pProgramming a GIMP Plug-in/p pbDave Neary/b/p p Dave Neary's been hanging around free software for about 6 years. He started off as a leech, and then decided to turn into a leechee sometime around 1999, when he started working on the GIMP. His main interest in the GIMP is revitalising the relationship betweek the user and developer communities. He has also helped out a little now and again on other things, and is listed as a co-author of gnect. /p p He is currently living and working in Lyon, France. /p /div div class=paper div class=figureleft p img src=http://2004.guadec.org/schedule/Oyvind_Kolas.png; width=200 height=200 alt=Oslash;yvind Kolaring;s/ /p pOslash;yvind Kolaring;s/p /div pCustom widgets in GtkCairo/p pbOslash;yvind Kolaring;s/b/p p Oslash;yvind is working on an application called Bauxite, which uses a node-based data structure similar to GEGL This application is both a standalone video editor and a comprehensive test bed of GEGL's node structrues. /p p Oslash;yvind is also working on the next generation XCF format. /p p His primary interests in the GIMP is graph compositing. /p /div h2Other graphics talks at GUADEC/h2 div class=figureright itemizedlist listitem Typography and graphic design for programmersbr/ bLiam Quin/b /listitem listitem The future of rendering in GNOMEbr/ bOwen Taylor/b /listitem listitem GStreamer Internalsbr/ bBenjamin Otte/b /listitem listitem Digital Photography in a GNOME Environmentbr/ bHubert Figuieacute;re/b /listitem /itemizedlist h2Sponsors/h2 div class=thanks p Many thanks to our generous sponsors, without whom GIMPCon would not be possible: /p p a href=http://www.fsf.org; img src=http://www.fsf.org/graphics/gnu-head-sm.jpg; alt=The Free Software Foundation/ /a bThe Free Software Foundation/b: The Free Software Foundation has consistently been the greatest supporter of the GIMP project, and has been the primary sponsor of each of the three GIMP Conferences which we have held. Many thanks go out to RMS and everyone else at GNU. /p p a href=http://www.macgimp.com; img src=https://www.archei.com/macgimp/images/mac_gimp_logo4.png; alt=MacGIMP height=30 width=60/ /a bMacGIMP/b: Mat Caughron sells the GIMP commercially with support and documentation, and has been generous on each occasion we have asked for his support. /p p The GIMP is also fortunate to have a community of supporters who have donated smaller amounts to the project. Many thanks go out to all those supporters. More information on how to donate to the GIMP is available on a href=http://www.gimp.org/donating/;the GIMP home page/a. /p /div h2GIMP conference activities/h2 p The GIMP Developers Conference, also known as GIMPCon, is a gathering of GIMP and GEGL developers from all over the World. It is a vital opportunity for the GIMP developers to meet each other and discuss the direction which the software will take over the coming years. /p p There have been two GIMP Conferences previously, both in Berlin, and both graciously hosted
[Gimp-developer] Final call: travel assistance
Hi all, Sorry to keep harping on about this, but things need to start moving pretty quickly now, if people need money in advance for travel. I have a fair idea now how much money we will have available, and I would like to be able to let people know by the start of next week whether they will be funded to come to the conference or not. Could anyone who needs travel assistance contact me immediately saying how much they need to get there? Also, please specify if you will need money in advance, or if you will require me to buy you an e-ticket. If you can afford part of your ticket, please say this as well. Thanks a lot, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Who's coming to GIMPCon?
Hi Roman, Roman Joost wrote: I'll come. If someone registered for the student flats and received a reply from the GUADEC organisation, let me know. I still didn't received anything. After asking in may, they said, they'll send the confirmation mails in few days, which didn't happen. This is becoming something of a FAQ for guadec - I've forwarder on your mail to guadec-list so that someone who knows more can fill you in on the details. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Who's coming to GIMPCon?
Hi Simon, Simon Budig wrote: I want to come. I tried to register for the free floor space, but they present a form that the CGI is not willing to accept (it has no entry field for the invoice thingie the CGI is requesting for). However, I hope my registration to the event itself went well. If we want/need floorspace, it is available to us. I have brought it up already with the guadec organisers, so I just need to let them know how much we need. We should let them know soon though. I'm not sure what exactly needs to be arranged in terms of set-up to use the floorspace, though - this will be my first GUADEC. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Yet another GIMPCon mail
Hi, This is an important one though. If you are planning on coming to GUADEC, but are waiting for confirmation fo support, please register for the conference as soon as possible at http://2004.guadec.org/register/ and request a travel subsidy there too. Since GIMPCon is a sub-event, it is unlikely that your full travel costs will be covered, but it is possible that a portion will be paid which will ease some of the pressure on the GIMP coffers. Since GUADEC travel subsidy requests will be considered next week at the latest, it is important to register immediately. As I said before, if you are paying your way, you can register for the Hobbyist caregory, and request that youre registration fee be refunded to you as well. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Conference update
Hi all, It's been a while since I've given an update on the conference situation, so here it is. We have got some funding. A huge amount of thanks for this situation go out to the FSF, who have once again agreed to be our principal sponsor for the event, and to the many donors who have contributed via paypal over the last couple of weeks. We should be able to pay some expenses of some people. It is unlikely that we will pay all expenses of anybody, but it's a start. Since there is lots of free housing being offered by the Norwegians, we will not pay any hotel expenses. Slumming it is more fun anyway (unless you have back problems). Expenses will be given in priority to people who *need* the money to get to Norway. So could people who would like to come to Norway, and need assistance to get there, please contact me with the following information - - the cost of getting to Kristiansand and home - How much of that you think you can pay - whether you need money in advance, or can pay for the full cost of the ticket and get some back afterwards. - Where you're coming from. Given the relative high costs of getting to Norway from outside Europe, I think it's fair to give priority to Americans who need support, and perhaps a New Zealander living in Australia, if he can make it (?). I know we're cutting it tight with this, but I did not have a confirmation of any real funding until this week. And I don't yet have a lot of money, but there is some. So if people need some money in advance, it can be arranged. I have also been looking into getting t-shirts printed. We have a generous offer from a new online clothing company (who contacted us a few weeks ago asking for permission to use Wilber on shirts) to print silk-screen on good cotton t-shirts for $5 per shirt (cost price), including the cost of the plates, excluding delivery duty. I am also looking into sharing t-shirt printing with the GNOME Foundation since they will be printing shirts for the conference as well. Currently, we're aiming for about 40 shirts, most of which will be sold to cover some costs. This will involve a cash outlay beforehand, which might be a problem for me, but we will work something out. Cheers, Dave. -- Dave Neary [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: Dave, ask yourself why you replied to this. The thread was long finished, and *you* certainly didn't contribute anything meaningful to it. And if you must reply to this, don't clutter the list with it further. My contribution was limited to showing that there is at least one person around here who doesn't think it's acceptable to treat people the way that you did. And since when are you the lord and master of what gets to clutter the list or not? Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Edit --Copy confusion
Hi Carol, Carol Spears wrote: 2) a cvs command that will request a version from a calendar date and not only the version (as bex and i documented fairly well on wgo) cvs up -D -mm-dd HH:MM gimp You might prefer sticking with the gimp-2.0 branch, though cvs up -r gimp-2-0 gimp I usually have 2 copies checked out of CVS in different directories: cvs co -r gimp-2-0 -d gimp-2.0 gimp cvs co -d gimp-2.1 gimp That'll give you a CVS HEAD version and a stable branch version, in gimp-2.1 and gimp-2.0 respectively. Cheers, Dave. -- David Neary Phenix Engineering 110 ave Jean Jaures, 69007 Lyon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Spamcop problem
Hi all, I just sent a mail to a gimp.org alias, and it bounced with the following problem: This message was created automatically by mail delivery software (Exim). A message that you sent could not be delivered to one or more of its recipients. This is a permanent error. The following address(es) failed: [EMAIL PROTECTED] (generated from [EMAIL PROTECTED]) SMTP error from remote mailer after RCPT TO:[EMAIL PROTECTED]: host mail1.iha.dk [130.225.184.39]: 554 Service unavailable; Client host [128.32.112.247] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?128.32.112.247 128.32.112.247 is shill.xcf.berkeley.edu, which is presumably some kind of gateway for gimp.org mail. So getting onto spamcop's blacklist probably means that gimp.org mails aren't going to be too reliable for a while. Does anyone know what's wrong with beta.gimp.org at the moment? It's mostly down, but it was up for a while yesterday evening. Cheers, Dave. -- David Neary Phenix Engineering 110 ave Jean Jaures, 69007 Lyon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Spamcop problem
Hi, Carol Spears wrote: On Tue, May 18, 2004 at 10:21:51AM +0200, Dave Neary wrote: 128.32.112.247 is shill.xcf.berkeley.edu, which is presumably some kind of gateway for gimp.org mail. So getting onto spamcop's blacklist probably means that gimp.org mails aren't going to be too reliable for a while. great. what does this mean about seemingly good information about cvs versions coming from gimp.org addresses? Presumably it means that your ISp doesn't use spamcop to block spam, unlike brix's university. When I said that they would be unreliable, I meant that it may be difficult to send mail to gimp.org addresses - since the ISPs/company servers/university servers may be using spamcop. Cheers, Dave. -- David Neary Phenix Engineering 110 ave Jean Jaures, 69007 Lyon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Volunteer needed
Hi, Update on the paypal details. The form to be added to the web page to allow one-click donations is this: form method=post action=https://www.paypal.com/cgi-bin/webscr; input value=_xclick name=cmd type=hidden input value=[EMAIL PROTECTED] name=business type=hidden input value=Donation to GIMP Project name=item_name type=hidden input value=106 name=item_number type=hidden input value=http://www.gimp.org/sponsors/thanks.html; name=return type=hidden input value=1 name=no_shipping type=hidden input alt=Support the GIMP name=submit border=0 src=donate.png type=image /form Is anyone currently working on the web pages? A reply from someone who is with a yes, but I don't have time would be fine, but the absence of response to my last mail is worrying me. I'm quoting the entire previous mail, in case anyone missed it. Do we have a web team any more? If so, who's on it? Cheers, Dave. Dave Neary wrote: So - here's the request: The following information needs to be added pretty quickly (and prominently) to the webpage, so that we can start advertising the ways to fund the GIMP around community sites. Is there anyone with the time to do this today or tomorrow? I won't have time to do this (even if it's pretty small) until next week, at the earliest. Thanks, Dave. = Fundraising info to add to the webpage === Donating money to the GIMP is easy! The guys at the GNOME Foundation have graciously agreed to act as fiscal agents for us, which means we can offer tax deductible donations in the US. There are 3 ways to support the GIMP financially, and get as many of the GIMP Developers as possible to the GIMP Developers Conference, taking place in Norway as a sub-event of GUADEC at the end of June, as well as expenses associated with the establishment of the GIMP Foundation: 1) Cheque, made payable to the GNOME Foundation, and sent to GNOME Foundation c/o Novell, Inc. 8 Cambridge Center Floor 5 Cambridge, MA 02142, USA with a cover-letter (or a note in the memo field) saying it is for the GIMP. You can additionally send a mail saying that you have donated to [EMAIL PROTECTED], if you want to. 2) Wire transfer Send an email to [EMAIL PROTECTED], requesting bank details, and specifying that you are donating to the GIMP. 3) Paypal Donate to [EMAIL PROTECTED], this will notify us, and the GNOME board, that funds have been donated to the GIMP. Credit card donations are also accepted via this route. Please indicate whether you would like your donation to remain anonymous, as otherwise you will be listed as a sponsor of the GIMP on the gimp.org web-pages. Note: The following can be added to allow a paypal donation to be just one click from the website (the page http://www.gimp.org/sponsors/thanks.html should exist with a short thank you message, otherwise the return field should be omitted): form method=post action=https://www.paypal.com/cgi-bin/webscr; input value=_xclick name=cmd type=hidden input value=[EMAIL PROTECTED] name=business type=hidden input value=The GIMP name=item_name type=hidden input value=108 name=item_number type=hidden input value=http://www.gimp.org/sponsors/thanks.html; name=return type=hidden input value=1 name=no_shipping type=hidden input alt=Support the GIMP name=submit border=0 src=donate.png type=image /form I've attached donate.png, which is directly taken from www.gnome.org/friends. Alternatively, we can use the paypal icon like this... input alt=Make payments with PayPal - it's fast, free and secure! name=submit border=0 src=https://www.paypal.com/images/x-click-but04.gif; type=image ...but since we're not getting anything from paypal, perhaps the neutral one is better. Thanks a lot, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- Dave Neary [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 Rowe wrote: Refactoring is a disciplined technique for restructuring an existing body of code, altering its internal structure without changing its external behavior. - Martin Fowler on http://www.refactoring.com/ This is exactly what happened to the code in /app between 1.2 and 2.0 - its internal structure changed drastically, without reducing its external behaviour. Although of course, not only was the code refactored, quite a few features were implemented with the new structure too. What I am saying is that moving redundant code out of application space into libraries is a significant component of refactoring. I would rather say that the modularising of an architecture, the separation of distinct functionality into distinct modules, is an essential part of refactoring. Putting this functionality into a library is simply a matter of passing the linker the right flags. Sven has answered that question. The client-server design of the PDB sidesteps the license issue by exposing functionality in app (which includes the PDB) without linking (instead using sockets). Actually, shared memory. But it amounts to the same thing. It's all IPC. Appreciate the clarification. No problem :) Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GPL discussion (was something else)
Tor Lillqvist wrote: [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: According to you, this shouldn't be. Additionally, one would assume that these are additional restrictions that are explicitly forbidden by the GPL itself. But these restrictions are placed by the MySQL copyright holders themselves, aren't they? It's those who *copy* (download, install) and redistribute MySQL that the license applies to, and it's they who can't add any additional restrictions. Or am I confused...? For a licence to be considered GPL, it can impose no further restrictions beyond what is in the GPL, excluding exceptions which are explicitly allowed (linking to library X, for example). Of course, the copyright holders can place the software under any licence they see fit. Including the GPL, but also including weird GPL hybrids. But since the MySQL copyright holders say that the licence is GPL, I suppose they get to have some say in what they consider to be a derived work. Cheers, Dave. -- Dave Neary [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, Sven Neumann wrote: Robin Rowe [EMAIL PROTECTED] writes: I honestly am not sure what the process for moving code to libgimp is... essentially it is just moving the code to a library, and then adding a wrapper (if required) around those functions to expose them to the PDB. Good technical anwer, thanks. Well, the answer was technically incorrect since it's the PDB and libgimp that's a wrapper around code in the core, not the other way around. Oops. At least I qualified it by saying I wasn't sure what was involved :) My understanding came from looking at libgimpthumb, which was added into 2.0 - what's in libgimpthumb looks to me like a complete implementation of the thumbnail spec, as opposed to PDB wrapper code. Ah - looking at the gimp-2.0 binary it looks like we just link libgimpthumb into gimp-2.0, and let plug-ins link with it if they want, so it is pure implementation. 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. Following what you (Sven) said in the previous mail, it also seems like the libgimp parts are independent of the original code, and calls the original functions via a PDB proxy, so licence issues wouldn't come into it. May I ask why you are asking these questions? I imagine it's because he wants to do the same thing... just a wild guess. Cheers, Dave. -- Dave Neary [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: Good technical anwer, thanks. Apparently I got it wrong. Anyway - I just improved my understanding with a concrete example. Let's take gimp_layer_add_alpha() as the example (the function adds an alpha channel to an RGB background layer that doesn't have one yet). The implementation is in app/core/gimplayer.c. In app/pdb/layer_cmds.c (still in application space), we have a wrapper function (layer_add_alpha_invoker), and a procedure which we register with the PDB (layer_add_alpha_proc), which registers the _invoker function as the run callback. Finally, in libgimp/gimplayer_pdb.c, we have the wrapper function which is called in plug-ins. This calls gimp_run_procedure on the procedure above, and invoked the core code as a direct result, as with a normal user-defined PDB function. Core types and enums are wrapped automatically by the perl scripts in tools/pdbgen (although this is somewhat black magic to me). I'm also wondering from a license standpoint. The code in app is GPL, but libgimp is LGPL. Given the above, the core code is GPL, the app/pdb code is GPL, and libgimp/* is LGPL, so there are no licence issues. Hope this clears everything up, Dave. -- Dave Neary [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, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: Following what you (Sven) said in the previous mail, it also seems like the libgimp parts are independent of the original code, and calls the original functions via a PDB proxy, so licence issues wouldn't come into it. Well, there are license issues when a non-GPL application makes calls to GPL-ed code by whatever means. I don' think this is an accurate representation of the issue. It certainly doesn't tally with my understanding. That said, I'm no expert. But let's take an example... I write a GPL network daemon (say red carpet). Someone write a non-GPL compliant client (say an LGPL encapsulation of the RedCarpet XML-RPC protocol to allow proprietary implementations). Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? How about if the relationship is via an ORB? A GIMP plug-in is a completely different process space than the GIMP core. Information is passed via a wire protocol which is implemented at both ends using LGPL code. I don't see how this is different from viewing the GIMP as a server, and the plug-in as a client. Or alternatively, the PDB as a broker and both the plug-ins and the rest of the core as clients. This is a difficult subject and it's hard to judge if a plug-in should be considered part of the GIMP application (which would mean that the GPL applies) or if it's a mere aggregation as per section 2 of the GNU General Public License. Our position on this is outlined in the file LICENSE which is included with the GIMP source tree. While the exemption in the LICENCE file does indeed clear up any possible confusion, I'm not sure it's necessary. What it also clears up, though, is that there are no licence issues with exporting a core procedure to the PDB, and wrapping that procedure in libgimp, which was the case in point. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GPL discussion (was something else)
Hi, I guess since we explicitly exempt libgimp and plug-ins, this discussion is purely of academic interest. Anyway - it interests me enough to ask a couple of questions. [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: On Wed, May 12, 2004 at 01:12:03PM +0200, Dave Neary [EMAIL PROTECTED] wrote: Now that library is calling GPL code, albeit via a network protocol. Is the client library in breach of the GPL? Well, that's what the license says: The Program, below, refers to any such program or work, and a work based on the Program means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term modification.) I've read and re-read this, and I'm having trouble figuring out how anyone can consider a network client as being a derivative work of the server. The client does not contain any of the server. The server exposes an API using an open protocol, and the client formulates requests to the server, and gets a response (still using xml-rpc as the example). At no stage does the client contain part of the server. The client can exist with an alternate, non-GPL implementation of the same server with no change (similarly, someone could conceivably use libgimpwire to implement a simple plugin-based batch processor and use the existing farm of GIMP plug-ins with no changes). The client and the server are distinct entities. Somewhere along the line, I don't get it. But that's OK :) So I hope it's very clear now that it depends. Ummm.. no. And getting unclearer all the time. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2 Questions
Sven Neumann wrote: Hi, Stephan Menzel [EMAIL PROTECTED] writes: 1. Whenever I click on the 'Insert Text' Button, the foreground color as well as the color for the text itself changes to black. Though it is possible to use another color it is much more complicated than before (1.2.2). Why? I often pick a color out of the picture with this little colorpickertool and then insert text in this color that matches another in the picture. Black is the least I would use. But now this is complicated and rather a pain. Does this change have any purpose I just don't see? Anyway, if it doesn't, can you change that back in the next release? The foreground color is not supposed to change. If it really does, that would be a bug. However I don't seem to able to reproduce this. This is an issue with the per-tool contexts. If you select a colour with the colour picker, then select the text tool, the text tool will have a black foreground (its own context). However, it doesn't affect the background. This is confusing, because it means that using the colour picker to pick a text colour involves picking the colour, opening the colour chooser and saving it, setting the text tool, opening the colour chooser for the text tool, and loading the saved colour. Which is complicated.It would be nicer (imho) if the text tool used the active FG if it hadn't been set yet, rather than defaulting to black. If you look at this from the point of view of someone coming from 1.2, this problem is obvious. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2 Questions
Hi, Dave Neary wrote: It would be nicer (imho) if the text tool used the active FG if it hadn't been set yet, rather than defaulting to black. The proper way to do this, I suppose, would be to get rid of the color option from the text tool options, and just use the foreground in the same way as the other paint tools use it (keep it in the context, but don't set it by default). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Volunteer needed
Hi, I thought I would have time to do so, but I am fast realising that I won't. We now have, as I said before, 3 ways that people can donate funds directly to the GIMP, via the GNOME Foundation. This is a short-term arrangement, and we will discuss what (if anything) we want to put in place long-term with the foundation board at GUADEC. So - here's the request: The following information needs to be added pretty quickly (and prominently) to the webpage, so that we can start advertising the ways to fund the GIMP around community sites. Is there anyone with the time to do this today or tomorrow? I won't have time to do this (even if it's pretty small) until next week, at the earliest. Thanks, Dave. = Fundraising info to add to the webpage === Donating money to the GIMP is easy! The guys at the GNOME Foundation have graciously agreed to act as fiscal agents for us, which means we can offer tax deductible donations in the US. There are 3 ways to support the GIMP financially, and get as many of the GIMP Developers as possible to the GIMP Developers Conference, taking place in Norway as a sub-event of GUADEC at the end of June, as well as expenses associated with the establishment of the GIMP Foundation: 1) Cheque, made payable to the GNOME Foundation, and sent to GNOME Foundation c/o Novell, Inc. 8 Cambridge Center Floor 5 Cambridge, MA 02142 with a cover-letter (or a note in the memo field) saying it is for the GIMP. You can additionally send a mail saying that you have donated to [EMAIL PROTECTED], if you want to. 2) Wire transfer Send an email to [EMAIL PROTECTED], requesting bank details, and specifying that you are donating to the GIMP. 3) Paypal Donate to [EMAIL PROTECTED], this will notify us, and the GNOME board, that funds have been donated to the GIMP. Credit card donations are also accepted via this route. Please indicate whether you would like your donation to remain anonymous, as otherwise you will be listed as a sponsor of the GIMP on the gimp.org web-pages. Note: The following can be added to allow a paypal donation to be just one click from the website (the page http://www.gimp.org/sponsors/thanks.html should exist with a short thank you message, otherwise the return field should be omitted): form method=post action=https://www.paypal.com/cgi-bin/webscr; input value=_xclick name=cmd type=hidden input value=[EMAIL PROTECTED] name=business type=hidden input value=The GIMP name=item_name type=hidden input value=108 name=item_number type=hidden input value=http://www.gimp.org/sponsors/thanks.html; name=return type=hidden input value=1 name=no_shipping type=hidden input alt=Support the GIMP name=submit border=0 src=donate.png type=image /form I've attached donate.png, which is directly taken from www.gnome.org/friends. Alternatively, we can use the paypal icon like this... input alt=Make payments with PayPal - it's fast, free and secure! name=submit border=0 src=https://www.paypal.com/images/x-click-but04.gif; type=image ...but since we're not getting anything from paypal, perhaps the neutral one is better. Thanks a lot, Dave. -- Dave Neary [EMAIL PROTECTED] inline: donate.png___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Volunteer needed
Hi all, Dave Neary wrote: 3) Paypal snip I sent this a little too quickly - I'm still waiting for a confirmation that paypal is available, and the values in item_id and item_name may be different. It would still be cool to get the first 2 methods on the site asap and add the 3rd when it's confirmed as an option (which should be today). Cheers, Dave. Donate to [EMAIL PROTECTED], this will notify us, and the GNOME board, that funds have been donated to the GIMP. Credit card donations are also accepted via this route. Please indicate whether you would like your donation to remain anonymous, as otherwise you will be listed as a sponsor of the GIMP on the gimp.org web-pages. Note: The following can be added to allow a paypal donation to be just one click from the website (the page http://www.gimp.org/sponsors/thanks.html should exist with a short thank you message, otherwise the return field should be omitted): form method=post action=https://www.paypal.com/cgi-bin/webscr; input value=_xclick name=cmd type=hidden input value=[EMAIL PROTECTED] name=business type=hidden input value=The GIMP name=item_name type=hidden input value=108 name=item_number type=hidden input value=http://www.gimp.org/sponsors/thanks.html; name=return type=hidden input value=1 name=no_shipping type=hidden input alt=Support the GIMP name=submit border=0 src=donate.png type=image /form I've attached donate.png, which is directly taken from www.gnome.org/friends. Alternatively, we can use the paypal icon like this... input alt=Make payments with PayPal - it's fast, free and secure! name=submit border=0 src=https://www.paypal.com/images/x-click-but04.gif; type=image ...but since we're not getting anything from paypal, perhaps the neutral one is better. Thanks a lot, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New to Development
Hi Bill, Laughner, Bill wrote: I'm a newbie to this developer list. I've been searching the site for some info on how the developer community is governed, but could not find what I was looking for. Who/how are patches approved for release and how is the release process managed? Sven does it, mostly. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Getting to 2.2
Hi there, I know Sven wanted to get 2.2 out in late June, which is in about 7 weeks from now. When do we think would be a good time to feature freeze, string freeze, etc? I haven't yet done anything on the 2.1 series, since I've been busy with other things, and trying to take a break and rebalance my yin, so I'm not really in a position to say where we are with respect to goals and where we think we'll be in the next couple of weeks. But from experience, if we want a 2.2 release in the end of June, we will probably need to have a release soon, and a pre-release feature frozen in a couple of weeks or so. What do people think of that plan? Alternatively, I'm happy enough to freeze in the end of June, and release at the end of August or so. Cheers, Dave. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring?
Hi Robin, Robin Rowe wrote: Does code in app ever get moved into libgimp? In what cases and who decides? A recent example of code that was moved from the main app to libgimp is libgimpthumb. The decision process behind this is documented in a bugzilla report (if you search in the GIMP product, including resolved and closed bugs, with thumbnail in the search criteria, you should find it - unfortunately at this precise moment bugzilla is down, otherwise I'd do it an include a link). I honestly am not sure what the process for moving code to libgimp is... essentially it is just moving the code to a library, and then adding a wrapper (if required) around those functions to expose them to the PDB. Related question, what tools use libgimp without GIMP? To the best of my knowledge, none. There was one person about a year ago who wanted to write a GIMP PDB for batch processing, but I don't know what happened to him. There isn't a whole lot of utility code that can be used independent of the PDB (I suppose the GimpWidgets are pretty handy). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Idea for support page
Hi, A friend here heard about Koha, an open source library management program, and I was looking at their site, and found this: http://koha.org/installation/support.html I think this is a great idea. Ifg there are people out there prepared to give commercial support to the GIMP, there should be a way for them to get some kind of official status, and have their name listed on the gimp.org website. What do people think of the idea? Is the GIMP the kind of program for which support contracts might be bought? Are there people out there who want to include GIMP Support in their business? Lots of open questions - I thought this was a great idea though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-web] Cleaning up the wiki
Hi, Sven Neumann wrote: I don't feel responsible but I have a friend who's experienced with MoinMoin wikis and offered his help. He wants to address technical problems only, which means updating the Wiki to a more recent version and theming it so that it looks more GIMPish. We only didn't get around to do this yet... Where's the wiki housed? And who has a shell account with sufficient permissions to add files in there, and modify existing ones (for instance, turning on attachments in the configuration)? Cheers, Dave. -- Dave Neary [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, Branko Collin wrote: However, anyone who uses a pre-compiled build cannot know beforehand what part of the bugs are build related, and what part GIMP related. Especially MS Windows users, who may not (and should not!) have a concept of build versus source distribution to begin with, may find it difficult to make the distinction. Would it be useful to devise a system in which all users can file GIMP related bug reports, whether they have bearing only on the build they are using or on all of the GIMP? I definitely agree with that. The correct thing to do with bugs reported against the installer is, IMHO, to add jernej as a CC, set the component to Win32, and then leave it alone, and open. That way, Jernej can use our bug tracker, perhaps teach us a thing or two about windows along the way, and neither he nor our windows users feel like they aren't considered good enough to be in the GIMP crowd. Jernej's installers are a great service, and if we don't want him to stop (and I know I don't), and bit more tolerance is called for. Currently, we don't even tell people how they should report bugs against the installer, the bugs are just closed NOTGNOME. Of course, this would put the burden of triage on the GIMP developers who are currently doing that, but it might avoid reporters being scared away by curt WONTFIX replies. These bugs are already being triaged as RESOLVED NOTGNOME. Changing the component, adding a CC and leaving the bug open takes as much time, and is a lot friendlier. Cheers, Dave. -- Dave Neary [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, Simon Budig wrote: What about a component installers or binary packages where we can put the bugs that are related to a certain gimp distribution? Sure, I could do this. I'll wait to see what the feedback on this thread is first. Dave. -- Dave Neary [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, Sven Neumann wrote: Branko Collin [EMAIL PROTECTED] writes: Of course, this would put the burden of triage on the GIMP developers who are currently doing that, but it might avoid reporters being scared away by curt WONTFIX replies. The reply is NOTGNOME and we usually ask the bug reporter to get in contact with Jernej or whoever built the binary package and report the problem there. By we, you mean I, don't you? And today that hasn't happened at least once, the reply was simply Your bug report is about the installer then and thus does not belong into this bug-tracker. IMO it's up to Jernej or whoever builds the binaries to setup a bug-tracker for it and to inform users that build problems should be reported there. That's what all other packagers of GIMP do as well. It certainly doesn't belong into GNOME Bugzilla. All the other packagers of the GIMP make money from it, and employ people to do this type of thing, and have dedicated machines. Jernej makes binaries in his spare time, and the least we could do is show a little tolerance on this issue. I don't see why bugs like these certainly don't beling in GNOME Bugzilla. It would be nice if you could explain why this is so obviously true. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new file-new dialog
Hi Sven, Sven Neumann wrote: However this change is more drastic as one might think at first. We always assign a unit to an image and at the moment this unit cannot be Pixels, it needs to be a real unit. With the new dialog layout, the unit menu needs to contain Pixels or it would not be possible to easily create an image of a certain pixel size. Now what unit should be set on the image then? snip - Allow pixels as image unit. We will probably have to hide this new behaviour in the PDB because plug-ins might not expect to get pixels returned when they ask for the image's unit. We could use the resolution unit as a fallback for this. A new PDB function should then be added that maps the core behaviour. This is the solution I like. We could actually abandon dot for dot, I think, and have a View-Image Unit menu entry which allows the image unit to be changed. - Add an easy way to change the image's unit. It's quite well hidden in the Image Scale dialog right now. With the changes proposed above, changing the image unit could become a more frequent task, so it should be easily accessible. Agreed. I think it should be a first-level entry in the View menu, as I said above. I am not yet sure what parts of the core will break if we do these changes. Perhaps it's a bad idea to start with. Please comment. I like it, I think that (as you say) the current behaviour is confusing, and I think we should just display stuff in 1 unit, and allow it to be easily changed. For plug-ins which break when the unit is Pixels, I suspect it would be pretty easy to fix them. So I'd vote against hiding this change from plug-ins. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshots
Sven Neumann wrote: Hi, Dave Neary [EMAIL PROTECTED] writes: For what it's worth, I do not have any problem with nice, but out of date, screenshots being on www.gimp.org - for example, we had a lot of screenshots from the 1.1 series on www.gimp.org before the migration. In fact, devel screenshots are a great way to get people building the HEAD. I don't know when it became policy to only have screenshot from stable versions on wgo - but I'm against that policy. We discussed this before doing switching to the new web-site. IMO it is essential that tutorials and screenshots on www.gimp.org consistently show the current stable version since that's what the site is all about. I disagree. I think that www.gimp.org is a site for GIMP users, and that includes bleeding edge users. developer.gimp.org is a site for GIMP developers, at least that was my understanding of the motivation behind it. The screenshot section on developer.gimp.org exists exactly for the purpose of getting people to build the HEAD branch. IMHO the screenshot section on www.gimp.org should have a link to the development screenshots but it should show the stable version only. If I'm correct above, what you are saying is that the HEAD branch is only for developers, which I disagree with. If this isn't what you're saying then I misunderstood the reason for the creation of dgo. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshots
Hi, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: Thus far, no-one on the web team has said anything about the matter. It would be nice if someone would say sure, send screenshots to me. I don't feel comfortable changing anything in the gimp-web module any more. Well, I am afraid that it won't work that way. If you or me feel that the screenshots on www.gimp.org need work, then it's up to you or me to do something about it. It was made very clear to me that my help wasn't wanted with the website. In those conditions, I'm not going to put myself out. There are plenty of things for me to do besides. That's not going to stop me making comments on where I think things could be improved though. We don't turn away bug reports without patches - opening a bug report is helping already. Likewise, if the screenshots section of the site needs work, I'm not going to think to myself better not say that the screenshots section of the site needs work because I'm not welcome on the web team. If the web-site concerns you, then you should be willing to touch it. If you aren't willing to do any changes to gimp-web CVS module, then you should IMO refrain from asking for changes. Doing so only shows disrespect for the people working on the site. Does asking for changes to be made to the GIMP show disrespect for mitch or yourself or any of the other people working on the GIMP? I really don't follow this point. I'll repeat it - I'm happy to help out occasionally on the website. I have lots of other things to do, though, so if I'm not welcome, I'm not going to do anything. In any case, I don't think that I would be able to provide very good screenshots. However, I'm sure there are lots of power users out there who would love to, and currently they don't have anyone to send screenies to. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Account of meeting with the GNOME Foundation
Henrik Brix Andersen wrote: Hi, On Tue, 2004-05-04 at 23:24, Sven Neumann wrote: That's very good news. I've been a little bit reluctant to welcome the move towards the GNOME foundation only because I appreciate the effort that Daniel has already put into The GIMP Foundation. But since Daniel also likes the idea, I'm all for it as well. Yes - if Dan who is the one having spent lots of time investigating the possibilities of the GIMP Foundation recommends joining the GNOME Foundation I am all for it. Let's not get ahead of ourselves. I was clear (I hope) that this is a short-term arrangement with the Foundation to fulfill our immediate need of giving people ways to donate money towards the GIMP. The GIMP Foundation is not old news - we will have a chance to meet with Tim and some of the foundation board at the conference to discuss whether we would like to join the GNOME Foundation, and what that means exactly. But it is also possible that we do that for a few years while the GIMP Foundation gets off its feet, proves its worth and gets the non-profit status which we hope to get. Cheers, Dave. -- Dave Neary [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, Nathan Carl Summers wrote: On Sat, 1 May 2004, David Neary wrote: Are there any people opposed to closer ties with the GNOME Foundation? I don't see any reason why we can't do both: work closely with the GNOME Foundation now, while the GIMP Foundation is getting off the ground, and then continuing to work with them to some extent once the GIMP Foundation is a reality. There is only one - a coprporation in California (the state that the GIMP Foundation is incorporated in) has a minimum income tax charge of $80year, even if you don't do anything. So while we're not doing anything with the GIMP Foundation, someone's out of pocket for that. Of course, we might decide that's something we're prepared to do, and chip in once a year to get the $800 among ourselves, or solicit funds for that. But it's a consideration which means that it's hard to do nothing with a GIMP Foundation (in addition, a foundation that's doing nothing will not easily get non-profit status). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
