Re: [Gimp-developer] WikiWordOfTheDay
Raphaël Quinet wrote: > On Mon, 8 Sep 2003 11:52:10 +0200, David Neary <[EMAIL PROTECTED]> wrote: > > Solution: For a given topic, create a wikipage. Make a start on > > it (sketch paragraphs/sections, basically set up the bare bones > > of what is needed). And then propose that lots of people make > > small contributions to it. > > > > We have a wiki (many people might not know that - it's at > > http://wiki.gimp.org/gimp), which allows just such collaborative > > effort to take place. [...] > > A wiki is nice for drafting some things, but I am not too fond of > using it for the help system: it would be OK for discussing some > ideas, but not for publishing the final result. That was my intention in the proposal. The general idea would be to use the wiki as a means of generating docs, not as a way of replacing either www or the help team :) As I said above, it is for collaborative effort in content generation. > A wiki makes it too easy to add lots of WikiWords that remain empty or > unmaintained for a long time. Unless there is a strong community > interested in keeping the wiki up-to-date and refactoring old entries, > many wikis end up being a collection of very valuable contributions > mixed with content-free pages. Unfortunately, most visitors do not > know which WikiWords are interesting and which ones are not, so it is > not always easy for them to find what they are looking for. Certainly, a bit of discipline is needed. To start with, the front page should have 0 dead end wikiwords. That will happen, but not until the proof of concept (that is, that people will write docs together on this thing) has been proven. I'm willing to put some effort into getting things started, and I have been happy to see a couple of other people embrace the idea (notably Roman Joost, hi Roman), but if it becomes clear in a couple of weeks that I'm wasting my time, then I'll stop, and it will die as an idea :) One part of making it work is the adoption of the docs generated by the various projects which are more stable in terms of content - the website, developer.gimp.org and the help project. I hope that adoption will happen when the content merits it (or that comments will be added explaining why it doesn't merit it). > Now, don't get me wrong: I like wikis in general. But I doubt that a > GIMP wiki will really take off and keep on running for a long time > (picture me skeptical about "if you build it, they will come" - or > more specifically "they will keep on coming"). We already have enough > problems getting contributors for any part of the GIMP (application, > plug-ins, help system, web site) so we should be careful about > introducing a new area in which people could invest some time. The interesting thing about the wiki from my point of view is the total divorcing of technology and content. You don't need to know html, xhtml, docbook sgml, docbook xml or any other markup to generate pages which look OK. That means that there's a low barrier of entry. And it makes it easier to contribute docs. Perhaps it'll take off... > A GIMP > wiki can be very useful for discussing drafts and proposing new > content that will eventually be migrated to the help system or to the > main web site, but the content would have to be migrated over to its > destination instead of staying on the wiki. Otherwise, I am afraid > that it would sooner or later lose focus. I think it could be kept in both. But yes, I never intended (nor did I imply) that the wiki should replace the existing content deployment systems. > That's all IMHO, of course. If I am the only dissenting voice, you > can ignore me. ;-) In fact, I hope that I am wrong and that we can > have a strong community of contributors. Consider yourself ignored ;-) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: Clipboard (was Re: [Gimp-developer] Screenshot plug-in status)
Nick Lamb wrote: > On Fri, Sep 12, 2003 at 12:38:26PM +0200, Sven Neumann wrote: > > Oh, will you? I am sorry but if I remember correctly we postponed this > > until after 2.0 since we hope that until then there well be an > > accepted Free Desktop standard for this. Our prefered solution would > > be to offer the image data as image/png and so far there seems to be > > consensus that this is a good choice. I had hoped to spend time on this before 2.0 pre1, but that's not going to happen now. And it does kind of break the feature freeze. But it shouldn't be a huge packet of code. > Any Free Desktop standard for routine image clipboard handling seems to > have been overtaken by events. There might still be room for some > discussion about hi-resolution or hi-precision graphics, but for the > average user the de facto standard is already set and since there's nothing > obviously wrong with it we can move on from there. X content negotation lets > us change our minds later, and GIMP's plug-in architecture lets us make > this modular if we decide that's necessary... I'm not aware of any de facto standard - how does kde pass image data around? The only clipboard standard I know of is the one on freedesktop which says "Explicit copy -> use SECONDARY", and keeps the selected buffer = PRIMARY as an easter egg which isn't really going to be used much in future. There is no standard for image data interchange that I know of, and I did have a look. > Is there any engineering reason why this shouldn't happen prior to 2.0, > assuming the spirit of Free Time is on our side? That's a fairly big assumption :) 2.0 pre 1 (which will be absolutely string & feature frozen to give translators, documentors and the like time to clean up before 2.0) is planned for a fortnights time. There are only 2 or 3 blockers left for that release, and they're all pretty small. So the spirit of Free Time is the biggest problem I see with it :) It would be nice if we did this in a way which would interoperrate with other apps, though - which is why using image/png is so attractive. Even if we were to use something else between different gimp instances, we get to communicate with everyone who understands png. As to freedesktop, as I said I'm not aware of any standard (de facto or otherwise) - I had planned to write up a proposal to use as the basis of a freedesktop proposal after 2.0 pre1 gets out the door. But if you implement something in the meantime, there shouldn't be any problem getting it in, as long as it's feature complete and fairly clean (as Sven said). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Vector's PDB
Joao S. O. Bueno wrote: > Hi Simon, > > So...there are they guys talking about pre1 already... We've been talking about that since camp :) > How is the vector stuff? Are the itnernal representaions, if note all > thetouchs on the UI finished? People are waiting for me... I have spent as much time as I have had in the last week or so on libart stroking. Hopefully a decent run at it tonight and it will be done. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PO files
Joao S. O. Bueno wrote: > Can someone point me to a "howto" or explaination on how are the files > firstly generated? Sure. README.i18n contains the basics of how to use gettext. The inaccurate Rough Guide is like this... you copy an existing po template file to one named after your localisation, translate the messages (being careful to use UTF-8), add the po files to CVS, and when you have po files for each of the localised directories (the dirs starting with po), add the language to ALL_LINGUAS in Makefile.am The template files are .pot, and .mo files are the actual files used when localising - they're the hashmaps that map a message onto its localised version. Or something. > I usually run everything in English here, but I was browsing the > pt_BR.po, and it is looking a little worse than if the translations > were done by an authomatic engine. If the language already exists, you can ignore the bits above, and just start translating the messages directly in pt_BR.po in the various directories, and the pt_BR.mos will be generated automatically when you make. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PO files
Joao S. O. Bueno wrote:
> Here goes what I got when writting the one in charge for pt_BR in the
> GTP pages:
Snip bounce
> Does GTP have a list or something?
[EMAIL PROTECTED]
Hope this helps,
Dave.
--
David Neary,
Lyon, France
E-Mail: [EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Undo shortcut
Hi all, This came up a few months ago, along with a bunch of other stuff, but got pushed onto the backburner. The proposal as I recall was to have the default undo shortcut be the HIG-reccommended Ctrl-Shift-Z. I think it's a good idea, and would like to have that as the keybinding for 2.0. Of course, it would have been nice to have it included before the frozen 2.0 release, but I think this is a change worth doing for 2.0, which means doing it now. Are there any objections to this keymap change? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Redo shortcut (was: Undo shortcut)
Hi, Steinar H. Gunderson wrote: > Why not Ctrl-Z, which is faster and which almost everybody knows already? Excuse me - the shortcut I'd like to change is Redo, which is currently Ctrl-R. Most apps in the Linux desktop space are now adopting some or all of the GNOME HIG in this regard. So - to correct myself - I'd like to change Ctrl-R to Ctrl-Shift-Z. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Branko Collin wrote: > On 21 Sep 2003, at 14:12, David Neary wrote: > > Excuse me - the shortcut I'd like to change is Redo, which is > > currently Ctrl-R. Most apps in the Linux desktop space are now > > adopting some or all of the GNOME HIG in this regard. So - to > > correct myself - I'd like to change Ctrl-R to Ctrl-Shift-Z. > > But since when did GIMP _users_ all start living there? Do we know > what the guidelines for other platforms are? How useful are the HIG? This was also something that was addressed in the old threads, I believe... Here's the mail in question. https://lists.xcf.berkeley.edu/lists/gimp-developer/2003-June/008870.html In summary: Windows in general: Ctrl-Y Apple standard: Apple-Shift-Z GNOME: Ctrl-Shift-Z KDE: Ctrl-Shift-Z PhotoShop: Ctrl-Shift-Z PSP: Ctrl-Alt-Z (they use Ctrl-Shift-Z for "bring up undo history", apparently) The HIG is the nearest thing we have to a proposal for consistent keybindings across the free desktops - much of it has been adopted by freedesktop, and is being implemented by all the major free software platforms (OO.o, Mozilla, KDE and GNOME). As we can see, the keybinding is also widespread on other systems, and in other apps. It's a small change, and (as has been said before) anyone who is particularly upset by it would presumably be able to modify it using dynamic shortcuts (presumably, the question "what happened to Ctrl-R?" will soon join "Why doesn't = zoom in any more?" as a FAQ). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How do I get a plugin into the offical release?
David Hodson wrote: > I've got a bunch of plugins on my website, a couple of which > are reasonably stable and mature. (OK, so they're built against > 1.2 at the moment.) Who decides on the offical plugin list? The official plug-ins are the ones in the main GIMP CVS repository. In general, a plug-in will get accepted if it's (1) reasonably bug free, (2) doing things like data access in a gimpish way, and (3) has an official active maintainer. Oh, and (4) is useful :) Unfortunately, several plug-ins which have in the past been included in the main GIMP distribution, and have then "lost" their maintainer, giving a rather big maintenance headache. Also, plug-ins weren't always bug-free when accepted. There was a time when we were pretty promiscuous about what we accepted (before my time...) Because of the aforementioned maintenance, the standards have been somewhat raised. However, several plug-ins have been accepted into 1.3. > For the interested, check out wideangle, degrain, and DBP (and > maybe Cineon/DPX, although that's fairly specialised) at: Would you be interested in helping keep the plug-in registry up-to-date? It's a job that needs doing, and I honestly don't know who was responsible for that before... I know that Carol was also interested in maintaining a list of 3rd party plug-ins, perhaps you could get talking to each other? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Hi, Sven Neumann wrote: > Ack. IMHO the new keybinding (David changed it already) is really > akward to use compared to the old one. And actually Ctrl-Shift-Z > should better be left available so we can bind it to group undos later > when this feature is implemented. (A group undo would allow to undo > all operations of the same type found at the top of the undo stack, > for example all paint strokes). Personally, I'd prefer to keep the new keybinding for the reasons already stated, and look at another keybinding for the new functionality. I don't have any ideas on what that functionality should be, but I think that using the keybinding for group-undo when on other software platformsit is redo could risk being confusing. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How do I get a plugin into the offical release?
David Hodson wrote: > I really don't have the time to take on a maintenance job - I have > too many of my own projects to finish. Plus, I don't think that the > plugin registry likes me. I have some very old plugins there, but > every time I try to update them I can't get access. I'm not sure the plug-in registry likes anyone :) Who *is* responsible for maintaining it? In the meantime, as Carol suggested it might be an idea to use the wiki to collect these kinds of external resources, in the absence of a registry which gets updated. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Difference between 1.2 .gih and 1.3 .gih files?
Hi Jeff, Jeff Trefftzs wrote: > I notice that I get lots of complaints about corrupt brush files when I > try to load .gih files from gimp-1.2.x into 1.3.20. Can somebody please > point me to the right place to discover the difference between the > gimp-1.2 .gih brushes and whatever the > equivalent is in gimp-1.3.20? I have a whole lot of brushes that I'd > like to convert if only I knew how. AFAIK, there shouldn't be any incompatible change - I have no problem loading the brushes from gimp-data-extras (which are 1.2 brushes) into 1.3, for example. Could you provide an example .gih file for testing, please? You could attach it to the bugzilla report you open describing the problem ;-) Thanks a lot, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] How do I get a plugin into the offical release?
Henrik Brix Andersen wrote: > According to http://registry.gimp.org/changes?max=15 the last change to > a plug-in was done only a couple of days ago - so it seems the registry > works at least for some people. Perhaps, but there are several things which should be possible which aren't. First, the majority of the plug-ins in the registry appear to be abandonware - 1.0 plug-ins that have never been updates to 1.2, never mind 1.3/2.0. We need a way to clean out the cruft (or at least hide it away). Second, the registry could do with a ranking system to have the most common and/or popular plug-ins appearing on the top of the lists of plug-ins. The only sorting system I've seen is alphabetically, which severely limits the usefullness of the site. Third, it is not possible to attach patches for existing plug-ins to a plug-in without being a plug-in maintainer. It would be nice if this were easier to do, perhaps with a comment system? Although I guess an inscription system makes some sense... > > In the meantime, as Carol suggested it might be an idea to use > > the wiki to collect these kinds of external resources, in the > > absence of a registry which gets updated. > > Hmmm... another duplication of effort? Why have two places to store user > committed plug-ins? Wouldn't the time be better spent on say, > maintaining registry.gimp.org? Sure - "In the meantime" was meant to be "until the plug-in registry is maintained". I would still like to know who is running the site. Is Ingo still active on it? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Nathan Carl Summers wrote: > I agree. Gimp's undo and redo feature differs from many other programs in > that when comparing subtle changes it is useful to switch rapidly between > the "before" and "after" views, while for a program such as a word > processor, that is probably not a useful thing to do. This being the > case, this particular need of GIMP users was probably not considered by > the HIG. I'm sure that ergonomy was considered for Photoshop when they chose Ctrl-Shift-Z for Redo... I do think it's overstating our importance somewhat to say that what's good for a large portion of the rest of the world is not good for us. > Personally, I compare between the "before" and "after" by holding down > control and hitting z or r as necessary. For some changes, I switch > several times a second, as the human eye is remarkably able to detect > small differences when they are animated. You will be able to continue to do this, using the Wonders of Dynamic Shortcuts. However, I think that in the general case we should try to adhere to the keybindings which people expect if they have used other applications (and not just imaging applications). > Switching between views this fast with accuracy is simply not possible > using Shift-Ctrl-Z due the the physiology of the human hand. The optimal > hand position is left on the shift and control and right on the z, with > the finger on the shift moving every other beat of the other hand and the > finger on the control key staying still. That depends where the z is on the keyboard :) > > So, if it's possible to have two different keybindings for the same command > > I'd like very much to have both. > > Unfortunately, it is not. Really, GTK should be made more flexable in > this regard, but it is not a trival problem, due to how GTK handles > accelerators. I believe we could hard-code two keybindings to work as the default, couldn't we? Then if the keymapping is changed, you're on your own. Perhaps I'm talking through my hat here. > I'm sure that in this case most usability people would > say that actually being able to use the feature is more important than > consistancy with some other apps. Especially because this particular > funciton isn't particularly consistant between apps. It's pretty consistent. And the usability people have considerably more experience with this than either of us :) I've added the usability list as a CC to see what they think. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Marc A. Lehmann wrote: > On Wed, Sep 24, 2003 at 11:39:44PM +0200, David Neary <[EMAIL PROTECTED]> wrote: > > I'm sure that ergonomy was considered for Photoshop when they > > chose Ctrl-Shift-Z for Redo... I do think it's overstating our > > importance somewhat to say that what's good for a large portion > > of the rest of the world is not good for us. > > "Others do it" is never an argument, though. It's an argument, just not a very good one (on its own). "Others do it, because it's been shown to be the best way" would be a decent argument, for example (I'm not arguing this). In the current situation, I think it's reasonable to fit in with what others do in the general case, which dynamic shortcuts provide a way to revert to the old behaviour. When the others are everyone using a Mac, plus people who come to the GIMP from KDE or GNOME applications, and PhotoShop users, I think the benefits of a familiar keybinding are self-evident. If you like, I'm arguing populism here. More people use Ctrl-Shift-Z as redu than Ctrl-R. Therefore, until there is a very good reason to change, we should do the same. In addition, a considerable body of usability work reccommends this keymapping. > What you need are arguments in favour of Ctrl-Shift-Z, and the only ones > that there are is "the HIG and other platforms use it, so people are > probably used to it, making it easier for them to switch". Yes, that's about it. It's also that current GIMP users probably benefit from having the same keybindings everywhere. There's nothing that annoys me more than using emacs, getting back into the emacs keybindings, and then using vim, and freezing the terminal with C-x C-s. Of course, this is not like with like. But I imagine that people who use both the gimp and photoshop have dozens of little annoyances like these. > That is one aspect of usability. It doesn't have much to do with > ergonomics, and as others already have said, Ctrl-R/Ctrl-Z is much more > ergonomical than three-key-combinations. > I think "two keys vs. three keys" is extremely obvious, too. > So ergonomics is might have been considered, but it was certainly > _dismissed_, as other, much more ergonomic combinations, are available. You have a point here. I think that what was chosen was the consistency of Shift as negation. I think that's probably a goal we could work towards. It certainly makes a lot of logical sense. But then, so does having + to zoom in instead of =, and look how many bug reports that's got us :) > > And the usability people have considerably more experience with this > > than either of us :) > > usable != ergonomic, though. Fair enough. > And I think that gimp users have considerable more experience with using > gimp than the usability people. If the GIMP were the only graphics application choosing this keybinding I would agree. I guess that when in doubt, following the crowd is a fairly safe bet (note this leaves open the possibility of not following the crowd when not in doubt ;). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Update on pre-release schedule
Hi all, As any of you who have been following CVS know, we have been working towards a 2.0 pre1 release for the end of this month, and there are now very few blockers to that release left. However, there are more blockers than are going to be done in the next week. So we're going to have another release (1.3.21). This should come out sometime during the next week. And the 2.0 pre1 release will be pushed back about 2 weeks, to (give or take) the 15th of October. Just to keep ye up to date, the list of blockers for the 2.0 release (which is mostly a filled out list of the things mentioned at camp), and their current status, is below. Blockers for 2.0 prereleases: - Path tool: 1) moving of strokes/paths,*DONE* 2) being able to connect two strokes, *DONE* 3) dragging on curve segments, *DONE* 4) libart stroking,Mostly done 5) im/export into files. *DONE* Text tool features missing: 1) GUI for text boxes Back-end done 2) Implementation of text transforms 3) Font list/selector improvements 4) Text outlineNot a blocker Help browser features missing: 1) Symbolic references for every core function *DONE* 2) Mechanism for cross-referencing with 3rd party *DONE* documentation 3) Registering of documentation files with the core *DONE* at startup, with references. libgimp API changes missing: 1) libgck must die *RESOLVED* 2) Thumbnail API exposedNeary done 3) libgimpmisc API changes 4) gimp_dialog_new () 5) 64 bit clean libgimp All in all, on that list there are 2 or 3 worrying things that might not be done in 2 weeks time, but most of them look like they will be done by then. We do need to clean up Bugzilla a little again. There are now 75 bugs with milestone --, it would be nice to get these sorted to the right place before we hit pre-releases. http://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&target_milestone=---&cmdtype=doit&order=%27Importance%27&form_name=query There are also 159 bugs open against the 2.0 release (milestone 1.3.x or 2.0). We need to start reducing this number now. So if you have a little spare time, please have a look at these bug reports, either to help close them or to reduce the amount of time needed to fix them. http://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&target_milestone=1.3.x&target_milestone=2.0&cmdtype=doit&order=%27Importance%27&form_name=query Thanks for your time, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Converting old plug-ins to wirk with gimp-1.3.20 (gimp-2)
Hi Jeff, Jeff Trefftzs wrote: > As we are about to move to the next stage of gimpery, I have begun > looking closely at my large collection of plug-ins, many of which I > remember compiling with GIMP_ENABLE_COMPAT_CRUFT, and wondering how to > make them usable again under the new regime. Can anybody point me to a > porting guide that identifies the changes needed to go from the old > (well, present) api to that used in gimp-1.3.20 and up? I have updated a few plug-ins to 1.3.x - but I have forgotten exactly what needed to be done. Could you point me to a plug-in to migrate, I will migrate it and document what I do? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Redo shortcut
Guillermo S. Romero / Familia Romero wrote: > [EMAIL PROTECTED] (2003-09-26 at 1933.11 +): > > >I'd suggest to leave the C-R as default keybinding and hardcode the C-S-Z. > > sounds like a good option, of course, it would confuse things if a user > > wants to apply SH+CT+Z to some other function(not sure why they'd want to, > > but it's possible). > > Grouped undo, or call undo history, ie. Hardcoding would be more > problem than harm, btw. Just to clarify what I meant when I said "hard-coding a value" - since it seems to have caught on as a phrase. The default value is hard-coded for any given menu item. When registering the menu item, there is a C function call that basically does this... register menu item (name, menu placement, default shortcut); A registered menu item corresponds to a function being called. I seem to recall that it was possible to say register menu item (name, menu placement, default shortcut 1); register menu item (name, menu placement, default shortcut 2); and have 2 shortcuts to the same menu item. This is not possible in gtk+ 2 (the second shortcut over-writes the first one), so talking about hardcoding several shortcuts is probably useless :) Note also that the hard-coded shortcut is the default shortcut... it seems that there was some confusion about this above. There may be hacky ways around this, such as creating "phantom" menu items with one shortcut which are nothing but wrappers around another menu item, but that way leads madness when you throw dynamic shortcuts into the mix. > They did not have any problem about changing button order from the > most used one (important button on left side, for LTR languages) to > the easier to use one (imporant on right side), OTOH, so logic behind > when to change and when not is fuzzy for me. The button order is used elsewhere (Mac). It should be used in conjunction with better dialogs (action verbs such as "Save", "Revert", "Don't save" rather than "Yes", "No", "Cancel"). And the logic behind it is simply that humans using LTR languages read dialogs from the top left to the bottom right, so the default action should be on the bottom right. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Usability] Re: [Gimp-developer] Redo shortcut (was: Undo shortcut)
Calum Benson wrote: > Whimsical muse: since there are almost no other gtk/GNOME apps that use > Redo (and the only one I can think of doesn't use Ctrl-Shift-Z either), > it's not beyond the bounds of possibility that we might end up changing > the HIG to whatever you decide anyway :) Well, thanks for clearing that up for us, Calum :) Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] When will we branch CVS gimp-2-0?
Hi, Sven Neumann wrote: > Raphaël Quinet <[EMAIL PROTECTED]> writes: > > I suggest to create that branch immediately after the 1.3.21 release. > > We create a branch immidiately after 2.0 is released. We don't have > the resources to handle more branches. If you branch now (or after > 1.3.21), we will never get a 2.0 release out. Agreed. Pre-release branches might work on other projects with more developer resources. The reality is we want everyone who has time to work on bug-fixes to have a 2.0 before Christmas (that's still the goal, and we're still on target for that). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, If this is an almost-concensus (only myself, Alan Horkan and Raphael seem to like the change), it seems reasonable to revert the redo shortcut to Ctrl-R. Cheers, Dave. Tom Mraz wrote: > FYI (multiple keybindings per menu action in GTK+). > > As I see it will be implemented in GTK+ 2.4 I vote for leaving the > current redo keybinding as is and wait for GTK+ 2.4 with the change. > > Tom Mraz > > Original Message > Subject: [Bug 123647] Changed - Allow attaching additional (hidden) > keybindings (accelerators) to menu entries > > http://bugzilla.gnome.org/show_bug.cgi?id=123647 > > Changed by [EMAIL PROTECTED] > > --- shadow/123647 Wed Oct 1 13:49:47 2003 > +++ shadow/123647.tmp.32485 Wed Oct 1 17:09:22 2003 > @@ -1,13 +1,13 @@ > Bug#: 123647 > Product: gtk+ > Version: 2.2.x > OS: Linux > OS Details: > -Status: NEW > -Resolution: > +Status: RESOLVED > +Resolution: FIXED > Severity: enhancement > Priority: Normal > Component: gtk > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > TargetMilestone: --- > @@ -16,6 +16,10 @@ > > It should be possible to attach additional (hidden) keybindings > (accelerators) to menu entries. > > It would be a very useful functionality for backward (or another app) > compatibility. > + > +--- Additional Comments From [EMAIL PROTECTED] 2003-10-01 17:09 --- > +This will be possible in 2.4 using elements with the new > +GtkUIManager. > > > _______ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Fwd: [Bug 123647] Changed - Allow attaching additional (hidden) keybindings (accelerators) to menu entries]
Hi, Sven Neumann wrote: > Raphaël Quinet <[EMAIL PROTECTED]> writes: > > try to replace it by something that is used by some other > > applications, such as Ctrl-Y. Do not bring back the old Ctrl-R. > > Unless Ctrl-Y collides with another suggested shortcut in the HIG, it > seems like a reasonable choice then. We should ask the HIG people to > make this the suggested Redo shortcut. Agreed. > BTW, as Guillermo already > pointed out, there are some more shortcuts, like for example the one > for Duplicate, where the HIG differs from our defaults. We should > consider to change these. Also agreed :) Does anyone have a complete list of these other clashing shortcuts, or does someone need to draw it up? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] web site move
Hi all, The web team says it's ready to move, several developers have said they want it to move now, I just wanted to sort out what exactly is preventing the website move. What needs to be done to get www pointing at mmmaybe, and get wwwas pointing at www? Who has permission to do it? If only one person has the permissions to do this kind of thing, it would be nice to have at least 2 or 3 others get the necessary right to avoid these kinds of non-technical delays in the future. There is no reason why mmmaybe shouldn't have become www a couple of weeks ago. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] web site move
> Sven Neumann wrote: > > If you would have read gimp-web list (where this topic should actually > > be discussed), you would know that there were good reasons for not > > doing the move immidiately. I believe that most or evenall of these > > points have been addressed in the meantime but we should leave it up > > to the web team to decide when they want to move the site. Also, I have tried on several occasions (most recently straight after receiving this message) to subscribe to the gimp-web mailing list, and have been unable to. The result page says I have hit a mailman bug, unfortunately I don't know who to contact about that. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] web site move
Hi Sven, Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > The web team says it's ready to move, several developers have said > > they want it to move now, I just wanted to sort out what exactly is > > preventing the website move. > > If you would have read gimp-web list (where this topic should actually > be discussed), you would know that there were good reasons for not > doing the move immidiately. I believe that most or evenall of these > points have been addressed in the meantime but we should leave it up > to the web team to decide when they want to move the site. > > I appreciate that you are trying to motivate them but I am afraid that > such a mail to the gimp-developer list isn't really helpful at all. I honestly hoped for an answer. The feedback I've gotten from the web team recently says it's ready to go. scizzo thought it was going to move a couple of weeks ago, and Raphael has said several times (most recently in response to a mail from mitch here) that he doesn't know what is holding it up, and he feels it's ready for a switch. So as far as I can tell, the web team is waiting for the switch to happen. I am honestly interested in knowing why it hasn't. I certainly didn't intend to be confrontational, or unhelpful. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: The GIMP 1.3.21
Hi all, The next release in the development series of the GIMP, version 1.3.21, is now available for download from ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.21/ or from one of the mirrors listed at http://gimp.org/download.html This is an extra unstable release before we officially go into pre-release mode, because there are still some outstanding API changes to make for plug-in authors which we would like to set in stone for the 2.x series. This is the most stable development release we have had to date, and there are also a few very nice features which have been added since the last release. So tell your friends, get testing, and keep those bug reports coming in to http://bugzilla.gnome.org. Happy GIMPing, Dave. Overview of Changes in GIMP 1.3.21 == - Allow to save tool options as named presets [Mitch]. - Stroke paths using libart [Simon, Bolsh, Mitch, Sven, Ville] - Better looking and more accessible dockables [Mitch] - Fixes for right-to-left rendering [Sven, Mitch] - Rewritten webbrowser plug-in [Brix] - Much improved path tool [Simon, Mitch] - Export GIMP paths to SVG [Sven, Simon] - Import SVG paths as GIMP paths [Sven, Simon] - Added SVG file plug-in from librsvg and improved it [Sven] - Store new vectors in XCF [Simon, Mitch] - Allow to toggle visibility of paths in path list [Mitch] - Move tool now also moves paths [Mitch] - Some progress towards gimp-console, a gtk-less GIMP for batch mode [Mitch] - Improved Decompose/Compose plug-ins [Alexey Dyachenko, Sven] - More SIMD compositing code [Helvetix] - Right mouse buttons now also cancels paint operations [Mitch] - More internal code cleanup and documentation [Mitch, Sven] - Documented libgimpmath [DindinX] - Lots of bug fixes Other contributors: Adam D. Moss, Dom Lachowicz, Manish Singh, Jakub Steiner, Christian Neumair, Seth Burgess, Maurits Rijk, David Necas, Tor Lillqvist, Ville Pätsi -- David Neary, Lyon, France. E-Mail: [EMAIL PROTECTED] -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: mailing list problems (was: Re: [Gimp-developer] web site move)
Hi, Sven Neumann wrote: > > I eventually found a way to make it work. I don't remember > > exactly how but there are several ways (web or e-mail) to > > subscribe and to confirm the subscription and at least one of > > them works. Please try subscribing again, because any > > discussion about the web site should take place on the gimp-web > > list. Raphael, how can one subscribe by mail? I'm only aware of the mailman web interface. > Problems subscribing to the gimp-user list were also reported today on > the cinepaint-developers list. Someone should look into this since we > really need these lists working. If you or someone else remembers how > to work around the problem, please let us know. For information, there is the entirity of the page when I try to subscribe to gimp-web: Bug in Mailman version 2.1b4 We're sorry, we hit a bug! If you would like to help us identify the problem, please email a copy of this page to the webmaster for this site with a description of what happened. Thanks! Traceback: Traceback (most recent call last): File "/usr/lists/mailman/scripts/driver", line 87, in run_main main() File "/usr/lists/mailman/Mailman/Cgi/subscribe.py", line 94, in main process_form(mlist, doc, cgidata, language) File "/usr/lists/mailman/Mailman/Cgi/subscribe.py", line 176, in process_form mlist.AddMember(userdesc, remote) File "/usr/lists/mailman/Mailman/MailList.py", line 807, in AddMember cookie = Pending.new(Pending.SUBSCRIPTION, userdesc) File "/usr/lists/mailman/Mailman/Pending.py", line 64, in new db = _load() File "/usr/lists/mailman/Mailman/Pending.py", line 121, in _load return cPickle.load(fp) TypeError: dict objects are unhashable Python information: VariableValue sys.version 2.2.1 (#1, Oct 5 2002, 11:19:44) [GCC 2.95.4 20020320 [FreeBSD]] sys.executable /usr/local/bin/python sys.prefix /usr/local sys.exec_prefix /usr/local sys.path/usr/local sys.platformfreebsd4 Environment variables: VariableValue PATH_INFO /gimp-web HTTP_ACCEPT text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1 CONTENT_TYPEapplication/x-www-form-urlencoded HTTP_REFERER https://lists.xcf.berkeley.edu/mailman/listinfo/gimp-web SERVER_SOFTWARE Apache/1.3.27 (Unix) mod_ssl/2.8.11 OpenSSL/0.9.6g PYTHONPATH /usr/lists/mailman SCRIPT_FILENAME /usr/lists/mailman/cgi-bin/subscribe SERVER_ADMIN[EMAIL PROTECTED] SCRIPT_NAME /mailman/subscribe SERVER_SIGNATURE Apache/1.3.27 Server at lists.XCF.Berkeley.EDU Port 443 REQUEST_METHOD POST HTTP_HOST lists.xcf.berkeley.edu HTTP_KEEP_ALIVE 300 HTTPS on SERVER_PROTOCOL HTTP/1.1 QUERY_STRING PATH_TRANSLATED /usr/local/www/data/gimp-web REQUEST_URI /mailman/subscribe/gimp-web CONTENT_LENGTH 105 HTTP_ACCEPT_CHARSET ISO-8859-1,utf-8;q=0.7,*;q=0.7 HTTP_USER_AGENT Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1 HTTP_CONNECTION keep-alive SERVER_NAME lists.XCF.Berkeley.EDU REMOTE_ADDR 194.206.161.214 REMOTE_PORT 21927 HTTP_ACCEPT_LANGUAGEen-us,en;q=0.5 UNIQUE_ID P4KKz4AgcPIAAFGVafA SERVER_PORT 443 GATEWAY_INTERFACE CGI/1.1 HTTP_ACCEPT_ENCODINGgzip,deflate SERVER_ADDR 128.32.112.242 DOCUMENT_ROOT /usr/local/www/data Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP 1.3 Reference Manuals
Hi all, Sven Neumann wrote: > libgimpcolor > 3% symbol docs coverage. > 2 symbols documented. > 66 not documented. This looked like juicy pickings, so I've attacked this. I'm currently documenting gimpcolorspace.c, then I was planning on doing gimpbilinear.c - anyone else working on this already? > libgimpmath >81% symbol docs coverage. > 60 symbols documented. > 14 not documented. Then I was planning on filling in the gaps here. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 1.3.x milestone bugs
Hi all, As many of you have noticed, I'm sure, we have over-run considerably the date we originally intended having a pre-release. In consultation with Sven, I thought it would be constructive to put together a list of bugzilla bugs that are still in the 1.3.x milestone, so that we can get as many people as possible working on issues that are considered blockers. I'm sure that everyone now wants to see a pre-release out there as quicly as possible - particularly given that if we don't have one by Hallowe'en, then a 2.0 release before Christmas becomes much less likely. Here is the Bugzilla list of 1.3.x milestoned bugs (there are 12 currently, although there may be 13 in a while). ID Summary 51108 [TRACKING] Hidden tool options (missing docs + should be visible in the UI) 78064 Entering large dimensions in Scale Image causes fatal error 113033 Thumbnail PDB API for Plug-Ins 125008 PDB-API for gimp_path_get_points returns only 1/3 of the pathpoint details. 125101 "Divide" layer mode makes everything green 125141 Deprecate libgimpmisc 125142 Make libgimp 64 bit clean 125143 gimp_dialog_new () implementation 125144 Text transforms 125145 Text boxes 58507 Translators should mentioned somewhere (maybe in help->about like in nautilus) 66367 Improved animoptimize for RLE or LZW compression 71514 GUI / Functionality Separation 116606 gradients not saved until quit 118547 Convert Text Layer To Pixels / Render Text Layer 119824 Indexed palette sorting functionality 122707 Text: can't make smaller boundary size of block Aside from that, mitch is currently working on the font list to get that into good shape (as far as I know he's almost finished with it). Some of these bugs could use fleshing out. Basically, that leaves 17 bugs before we can release a pre-release. Some of those I know very little about, and perhaps one or two could be bumped to a later release. But for the most part this is more or less in line with the guidelines for what were agreed as blockers in camp. Looking at the changelog recently, it's clear that the lion's share of the work is currently being done by Sven and mitch. It would be very nice to have people claim outstanding items, and do them, in the next few days, so that we can get a gimp we're proud to release quickly. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.3.x milestone bugs
Patrick McFarland wrote: > On 21-Oct-2003, David Neary wrote: > > 118547 Convert Text Layer To Pixels / Render Text Layer > > Wow, my bug is so important, its listed. It's one of the features that is planned for the text tool before 2.0, so yeah. :) The workaround that I use, and which I added to a comment, is to duplicate the layer, clear one copy, and then merge the two copies. The merge kills the text attribute, the duplicate makes sure that the merged layer is the same size as the original text layer, and merging with a transparent layer is a no-op. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] 1.3.x milestone bugs
Hi Sven, Sven Neumann wrote: > I think it would be cool if you could post regular updates on this > list. Will do. How regular? Each time a bug on the list is resolved? Given that there are so few, I think this is reasonable... Or when someone claims a bug and starts working on it, to avoid duplication of effort? I got a mail from David Odin proposing to work on some of the API clean-up (specifically, he proposed addressing the gimp_dialog_new () bug) - I asked him to send the same mail to the list. I misunderstood quite badly some things with respect to the libgimp API problems, though, so he may not know what he's letting himself in for :) By the way, I seem to recall you saying that yosh and/or mitch were working on a proposal for the API clean-up - is that correct? If so, what is the status of that? Cheers, Dave. -- David Neary, E-Mail: [EMAIL PROTECTED] Tél: 04 78 58 08 83 CV: http://www.redbrick.dcu.ie/~bolsh/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 1.3.x milestone bugs
Hi, Branko Collin wrote: > On 24 Oct 2003, at 11:11, David Neary wrote: > > How [regularly should I report progress on 1.3.x blockers]? > > Each time a bug on the list is resolved? > > Given that there are so few, I think this is reasonable... Or > > when someone claims a bug and starts working on it, to avoid > > duplication of effort? > > Not wanting to butt in, but 'each week' seems a more sensible metric. If we're talking on the list, it's because we want feedback, as well as keeping everyone informed, so you're not butting in at all. I disagree that once a week is often enough. The list I posted was from 3 days ago, and already several of the bugs have been addressed. In addition, someone indicated that they wanted to work on a bug which someone else is already working on. > That way, if progress on several bugs is stalled for some reason, you > can say so, and others can see if they might be able to help. Also, > it forces you to look at what the actual progress is. Given that we're already behind our provisional schedule, and we're going to be cutting it close for a 2.0 this year, I would hope that the list will be very short next week... There are several bugs that could be addressed by anyone with some time to spend. It would be nice if some people piped up and claimed one. Of the outstanding bugs, I think that 125141 (following on from the comments of Sven) and 116606 are quite easily doable. Who feels like implementing instantaneous save of GimpItems and attacking libgimpmisc*? (hint: that was an invitation to pipe up) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Status update on 1.3.x
Hi all, Here's another update on the 1.3 bugs that are considered as blockers for 2.0 prereleases (the list in its current state is available here http://bugzilla.gnome.org/buglist.cgi?product=GIMP&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=NEEDINFO&bug_status=REOPENED&target_milestone=1.3.x&cmdtype=doit&order=%27Importance%27&form_name=query). I have split them up a little and added a wee comment on the state of play. There are 11 bugs, and of those 5 have an owner actively working on them. That means there are 6 bugs up for grabs, requiring your input and help. BUGS REQUIRING INPUT 78064 Entering large dimensions in Scale Image causes fatal error http://bugzilla.gnome.org/show_bug.cgi?id=78064 There has been some discussion on this bug. Personally, I think checking the new image size against the large image size set in the preferences, and giving a warning if it exceeds it, would be sufficient, but since this crashes the gimp if it happens, that behaviour is probably wrong. Comments needed, and I think that this would be fairly easy to fix so that at least it's not a crasher. 125141 Deprecate libgimpmisc http://bugzilla.gnome.org/show_bug.cgi?id=125141 As Sven said, a similar operation has been done for libgck earlier in the release cycle. There is very little to be done here except clean-up. Once all the useful functions are moved away from libgimpmisc*, this will be a tiny bug to close. Comments and coders needed. 58507 Translators should mentioned somewhere (maybe in help->about like in nautilus) http://bugzilla.gnome.org/show_bug.cgi?id=58507 If someone (nomis?) is working on this, please say so on the bug report please. If not, ideas on what the new about dialog should look like/do can be added to this report. 116606 gradients not saved until quit http://bugzilla.gnome.org/show_bug.cgi?id=116606 gimp_data_editor_save_clicked() and gimp_data_editor_revert_clicked() in app/gui/gimpdataeditor.c need non-default implementations. This should be a fairly small job, but it needs doing. Volunteers please add a comment, and reply to the list. 125142 Make libgimp 64 bit clean http://bugzilla.gnome.org/show_bug.cgi?id=125142 It would be helpful to have some comments about what exactly needs to be done for this bug. I believe yosh had some ideas - yosh? 118547 Convert Text Layer To Pixels / Render Text Layer http://bugzilla.gnome.org/show_bug.cgi?id=118547 This might be a small job, perhaps someone would like to take a look at it to give Sven more time to work on the harder problems in the text tool. Volunteers? Bugs in stage of completion with owners === 66367 Improved animoptimize for RLE or LZW compression http://bugzilla.gnome.org/show_bug.cgi?id=66367 Raphael is working on this, and will hopefully commit something this weekend. 113033 Thumbnail PDB API for Plug-Ins http://bugzilla.gnome.org/show_bug.cgi?id=113033 Sven is doing this, and will commit something soon. 125144 Text transforms http://bugzilla.gnome.org/show_bug.cgi?id=125144 122707 Text: can't make smaller boundary size of block http://bugzilla.gnome.org/show_bug.cgi?id=122707 Sven is working on these. 125143 gimp_dialog_new () implementation http://bugzilla.gnome.org/show_bug.cgi?id=125143 mitch is doing this, and will have something this weekend. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpDialog API change
Hi Mitch, Michael Natterer wrote: > GtkWidget * > gimp_dialog_new (const gchar*title, > const gchar*role, > GtkWidget *parent, > GtkDialogFlags flags, > GimpHelpFunchelp_func, > const gchar*help_id, > ...); This looks good to me. > I'll start hacking this today but would like to get some ACKs or EEKs > before I start porting the plug-ins (which have many many GimpDialogs). One question... do you think it would be worthwhile to make the API change, document what needs to be done to change from the old API to the new, and then have a number of people work on porting the plug-ins? Each plug-in in itself would probably be a small job, but the lot of them might take you a while. Would this be worthwhile? I would certainly do a few plug-ins, are there others who would be able to help out here? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpDialog API change
Michael Natterer wrote: > David Neary <[EMAIL PROTECTED]> writes: > > Would this be worthwhile? I would certainly do a few plug-ins, > > are there others who would be able to help out here? > > While there is certainly help needed (my fingers start to break when > i try to type 'GTK_RESPONSE_FOO' :-), I don't really know how this > could be done by several people without temporarily breaking > half of the tree. We could create a branch... it would be pretty shortlived. Or we could let the plug-ins break temporarily, letting people know that's going to happen (and at the same time pointing them to a doc about what needs doing to get a plug-in fixed). > After all, I think this API change is best committed atomically, > so I'll just continue hacking the plug-ins and commit everything > today or tomorrow. If you think you'll be done that quickly, that's perhaps best. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Update on the road to 2.0
Hi all, It's been a while since the last mail about the blockers for the 2.0 prereleases, so here it is. Bug # Summary 78064 Entering large dimensions in Scale Image causes fatal error 113033 Thumbnail PDB API for Plug-Ins 125115 Gimp will not work with GTK 2.4 125141 Deprecate libgimpmisc 125142 Make libgimp 64 bit clean 125144 Text transforms 58507 Translators should mentioned somewhere (maybe in help->about like in nautilus) 66367 Improved animoptimize for RLE or LZW compression 116606 gradients not saved until quit 118547 Convert Text Layer To Pixels / Render Text Layer 122707 Text: can't make smaller boundary size of block That's 11, as opposed to 11 the last time. Many of the bugs are in the same state as a couple of weeks ago. There is one new blocker (build with GTK 2.4) which has been mostly addressed, and I think that it can be moved off the 1.3.x milestone. Aside from that, I am working on 116606 (gradients not saved until quit) - there is now a workaround, and I hope to have a complete fix in place soon (perhaps today?). 125142 (64 bit clean) is mostly done, awaiting one final commit from yosh to close it. Part of this bug was the API for gimp_dialog_new() which has been changed recently by mitch. Simon is still working on the About dialog, and he has asked for input and ideas. They should be added to bug #58507. Bug #78064 (crash on scale image) is currently not being looked at by anyone. Please speak up. David Odin has been doing some work on getting rid of libgimpmisc and libgimpmiscui from the installed libgimp API, but he is looking for some help, I think. Add a comment to bug #125141. Raphael was working on bug #66367 (RLE animoptimize) last time, and I believe that's still the case. That leaves 5 bugs: 113033 Thumbnail PDB API for Plug-Ins Sven had almost finished this last I heard. 125144 Text transforms This bug has a comment from Sven which outlines what needs to be done to close this request. Perhaps someone with some time on their hands could do this? 122707 Text: can't make smaller boundary size of block I'm not sure of the current status of this. Last I heard the back-end was more or less done, and it needed an UI. I suggest buimping the milestone, since I don't think this is essential for a usable text tool. 118547 Convert Text Layer To Pixels / Render Text Layer This is on the TODO list of Sven, I think. OK - so there's the summary. Not a huge amount of movement on these, but we're going in the right direction. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on the road to 2.0
Hi, Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > OK - so there's the summary. Not a huge amount of movement on these, > > but we're going in the right direction. > > Dave, please do a CVS diff between the date of your last mail and > today. Then say this again. Actually we have made a lot of progress, > not only on the blockers but also on other bugs that need to be > addressed before 2.0. We could hardly have moved faster. I am well aware of everything that has gone into CVS in the past 2 weeks. I specifically said "on these". By that I meant that the same bugs which were blockers for the pre-releases 2 weeks ago are still blockers now, with the exception of the GimpDialog API (which I mentioned in the mail). I also summarised the changes that have been made with respect to the various blockers that are still open. Yet again, I didn't mean to offend. If there was a point to be made, it is that the proportion of the check-ins which have been directly related to bugs which are blockers for a pre-release is pretty small when compared to the sum total of what's gone in in the last couple of weeks. So, in summary, of the 11 bugs which were on the 1.3.x milestone a fortnight ago, 10 remain open, and 1 more was added. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Update on the road to 2.0
Hi, Sven Neumann wrote: > all well understood but progress reports should be motivating. So it's > important to also mentioned all the good things that have happened. > Otherwise the report will have the opposite effect of what it was > written for. Apologies if the tone seemed a little negative. I will try to avoid that in future. Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at COMDEX
Hi Daniel, Daniel Rogers wrote: > Gimp demos. Show off some of our killer features. Any ideas as to what > these might be? (layers, brushes, plugins, script-fu) He might not forgive me for this, but here's jimmac's list of user visible changes in 2.0 when compared to 1.2: http://jimmac.musichall.cz/stuff/private/gimp-2/html/index.xhtml The biggies are of course docks, the path tool, the text tool, the themability (I like showing off the small interface - do we have a big & chunky interface too?), the grid, fullscreen mode, and tool contexts. There are also the colour pickers for the levels tool (amazingly useful) and GAP. But Jakub's the man to talk to about that stuff... If you're doing a general gimp demo, then the stuff that impresses people is the clone tool, selections/masks, channel & layer manipulations. A good thing to do is search through your collection for a few shitty photos that you are fairly certain can be hugely improved with one technique, and then do that. Here, I'm thinking of Jakub's tutorial in Berlin where he had, for example, one image with a contre-jour, one image with a red cast at sunset, another image with the tourist walking across the wall, another with the bright red plane, and no other red in the picture, another with a good clear red-eye, etc. > Tips for working with the gimp in a corporate enviroment. (examples of > previous corporate help would be great). Buy a programmer to add > features. Strenths of open source, weaknesses of open source. This kind of philosophical stuff is interesting, but the FSF and OSI have lots of stuff on this. But getting someone to buy a programmer for a year or two would rock. > Future gimp plans (gegl, high bit depths, color management). Personally, I'd tend to avoid future plans until there's something to present. If someone asks about CMYK, pre-press, color profiles, etc then by all means go into the details, but I wouldn't include it in a presentation. Good luck in Vegas, and don't lose too much money :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at COMDEX
Hi, Jakub Steiner wrote: > On Thu, 2003-11-13 at 12:48, David Neary wrote: > > http://jimmac.musichall.cz/stuff/private/gimp-2/html/index.xhtml > > Eek! Looks like I need to bring it up to date and finish it. Bad, bad > Dave ;) Lot of stuff changed in the meantime. :) I thought that might be motivational for you... Thanks for writing it, by the way. Very useful document. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] GIMP at COMDEX
Hi, Henrik Brix Andersen wrote: > On Thu, 2003-11-13 at 08:13, Daniel Rogers wrote: > > cl0kd already sent me a screenshot of gimp 1.3.x running on macos 10.3! > > One of the cool thing about The GIMP is that it is cross-platform. The > exact same source code can be built on a variety of platforms. I often > meet people who think The GIMP is a GNU/Linux-only thing - maybe it is > worth mentioning that it runs on a large number of platforms? It is true that it's less stable on Win32 though... partially because of a shortage of people building it from source on that platform, yielding a smaller pool of potential bug-fixers. I regularly crash the GIMP on Win32... and crashes aren't nice for demos. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon 2004
Hi all, A while back (quite a while actually) I tried to start a discussion about where we might have next year's GimpCon. There were 2 main ideas - the first is to stage something more or less standalone - 20 odd people turn up somewhere and talk about the GIMP for 4 days. The second is to piggy-back on an existing event, taking advantage of the organisation and financing of the bigger event. I asked for ideas of events, and offers to organise the location for the 20 odd people. I also asked for proposals for dates. Unfortunately, the response was less than I'd expected, which means I probably didn't ask properly :) Today a few of us were talking about this on IRC, and a couple of concrete proposals came up. Well, more sandy-water proposals at the moment... 1) Lyon Myself and David Odin live here, we're both active in the local LUG and might get some organisational help there, David works in a university and has cleared the "in principle" issue with his boss. We would have some rooms in a university, with access to the university network, and probably guest accounts on the university network. There has been no talk of money, so we don't know how much all this access might cost. Plus: Facilities Minus: Lyon isn't easy to get to, which means higher transport costs. Dates after the 25th of June are best. 2) GUADEC The GNOME Users and Developers Conference is in the process of organising itself for the last week in June; this is about the time that I think it would be good to have a conference (around the time 2.2 comes out), before we break lots of stuff doing a gegl migration. Plus: Everything will be organised. Lots of smart people around. Minus: We're not a GNOME app, so we probably won't get travel expenses paid by the organisers (we can always ask, though - perhaps we can get a Graphics stream added, and have 4 or 5 people give presentations and get expenses that way). Again, Norway's not easy to get to. If we are having problems getting money, sponsorship might be tough (most people liable to sponsor us will also probably be sponsoring GUADEC) 3) London Sven knows some people in London who might be prepared to put in the organisational effort. Plus: London = cheap transport Minus: We don't know what facilities will be available. Other ideas (conferences we could hijack, or places where people would be able to organise stuff for us) are welcome, as well as comments on these. Please note that I have not talked about money at all really... IMHO, we need a someone who will handle the money, and a group of someones who will look for sponsorship. The problem is that we often need somebody, who could be anybody, but everybody thinks somebody will do it, and in the end nobody ends up doing it :) So it would be nice to start naming our somebodies now. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] GimpCon 2004
Hi again, David Neary wrote: > Today a few of us were talking about this on IRC, and a couple of > concrete proposals came up. Well, more sandy-water proposals at > the moment... A 4th possibility to add to the mix... 4) Dublin, Ireland I was chatting to some friends in Dublin, and their LUG has been offered conference facilities free of charge for a limited period. We're short on details at the moment, but in brief, there is a conference room for up to 20 people, a lecture theatre for up to 45 people. Not sure what the access times will be like (robably business hours), but it might be worth exploring. Pros: Possibly free facilities, fairly cheap to get to, pubs Cons: Weather, expensive city Each of these possibilities needs to be fleshed out (possible dates, whether there's funding, facility costs, who's going to do the organising, etc) pretty quickly. And if there are others, the same types of things need doing for them too. Could I have a volunteer to liaise with the GNOME foundation to see if they are open to the idea of subsuming the gimp developers conference? It would be nice to know if they think it's a good idea, and then perhaps whether we could get some money for expenses towards it from the bigger GUADEC pool... I will flesh out the Lyon possibility, and keep in contact with the Dublin people to see exactly what's on offer in terms of facilities, and what types of dates we would be talking about. It would be nice to add another couple of possibilities. Anyone have dates that they prefer? I *really* need feedback on this. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon 2004
Carol Spears wrote: > > How about we know what funding there is and how much gimp has to work > with. > > Or skip all that and just show up somewhere and send the bill to > dsrogers? Call it faith in misinformation. As I said, I think that we will need someone to be the money face on the group. Someone who will be (while we're waiting for the foundation to be up & running) the person the checks will be made out to. But we will need a number of people to hustle for money (companies who use the GIMP and Linux companies who ship the GIMP on commercial offerings would be the 2 big target groups), and eventually send on details to our money person to "close" the sponsorship deal. We will also need to start thinking about merchandising a bit earlier than last year, I think, and perhaps have someone make up a T-Shirt in the next month or so? I know that there is at least one prospective sponsor who has said he will put some money (perhaps 4 figures) towards the conference - a few more like that and we will not have problems paying travel expenses (depending, of course, on the location) - 20 people at an average of about 400 euros each (does that sound right compared to last year, Sven?) means to pay everything we'd need about 8K euros. This year we'll be adding in accomodation (which we didn't have to worry too much about last year, thanks in great part to Sven and mitch, and the CCC) which could add as much as 200 euros per person to the cost. I think that we need an event before we go looking for money, though. Saying that we want sponsorship for a vague conference that we might have next year doesn't compare to asking for money for the conference we're going to have on dates X, Y and Z in Kletzenberg. But sure, money is something we'll need to think about soon too. First things first, we need 3 or 4 volunteers who will prostrate themselves before big companies and ask for a few grand sponsorship. And someone to spearhead the effort who has a good financial head on them, and has some knowledge of figures. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon 2004
Hi Carol, Carol Spears wrote: > On Thu, Nov 20, 2003 at 03:23:47PM +0100, David Neary wrote: > > I think that we need an event before we go looking for money, > > though. > > > as far as i am concerned, this event and all of the other ones suggested > here have already occured. Perhaps I'm misunderstanding you... when I talk about an even, I mean something that we can then "sell" to people for sponsorship. That is, that we can say that we have concrete plans that we need to finance. > while people were struggling with real life problems and such, they were > told that a presentation would be needed for consideration for a recent > trip to talk about gimp with real life people. I have lost you a little here - are you talking about Roman's efforts to gather resources for presentations? Or dsrogers's call for ideas on what to present at comdex? Or something else? > someone did get to go, travel and such paid for. no presentation that > was shown to me. In fairness (I think you are talking about comdex) what ORA does with their money, and who they decide to invite to an event, is outside the scope of this discussion. There are 3 or 4 GIMP people in the US, and 1 or 2 (not sure how many) went to represent the GIMP. This is completely different from organising a developers conference to outline the future of the gimp. > everything outlined in this letter has already been done, perhaps > several times over. then over again. then again just to be sure. Which letter? > where is the money? how much is there? who are the contributers and > what did they intend to get from the money. > > faith shall set you free. > > i have much faith in the misinformation surrounding gimp.org. I'm afraid that I have no idea what you're talking about here. Could you clarify what money you're talking about, which letter, and particularly what this has to do with the conference next year? Thanks. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon 2004
Hi Carol, I really missed the point of your last 2 mails, but here's the answers to your questions... Carol Spears wrote: > My questions can all be answered very simply. > > How much money is there? There's lots of money. Every country makes their own. The European central bank makes billions of euros. I don't know how much money is at the disposition of the GIMP project, though. Sven said there's about 400 euros left over from the GIMP conference last Summer. > Who contributed it? FSF Europe, ORA, FlamingText GIMP and someone else I can't remember gave us money for the last conference, of which 400 euros remains. Apple also lent us some equipment. > For what reason was it contributed? So that we could have a conference, no strings attached... > Please, Mr. Neary. Answer these questions, not reask your own. I really didn't understand what you were asking. I would have appreciated you clearing that up... since you didn't, I'm kind of guessing what you meant. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Weekly Progress Report on GIMP development
Simon Budig wrote: > Sven Neumann ([EMAIL PROTECTED]) wrote: > > - A couple of other issues with the libgimp* APIs have been > > resolved. The APIs should be ready for GIMP-2.0 now. Only the > > addition of libgimpthumb is still missing in CVS. > > With the notable exception of vectors stuff. Or did I miss something? Whatr changes to the vector tool will require libgimp API changes before 2.0? I wasn't aware of any... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon 2004
Carol Spears wrote: > the misinformation is from gimp.org. there was funding available to > send someone to las vegas to represent gimp there. Any money that paid for someone to go to Vegas was payed by ORA (O'Reilly and Associates) as a result of their competition to send 6 open source projects to comdex. The GIMP came in #5. > a few of us were told that gimp.org would be expected to put up funding > to deliver the person to the event. fans and people working for gimp > had pride in the developers and the application they labored so much > over and said "no funding, no interest". I wasn't aware of that. Could you tell me who told you that? > there is not a foundation yet and we start out with different > information from gimp.org and from gimp.foundation. I hadn't realised there was any informatyion for anyoine. The only information I saw about comdex was the bugzilla report opened by Steve Mallett and his blog (where I voted, several times). > i am not going to explain this again. if you do not understand the > problems with this situation, i don't think you should be handling it. It's not that I don't understand the problems with the situation - it's that I don't know about the situation. Do you ithink that someone else should have gone to Vegas? I don't understand the way you are seeing this comdex thing. > i don't know who the best representative is; probably not me as I am > about as bruised and beaten as this life can do to me. but the people > who want to go get told they need to present the presentation first for > consideration. Please, name names. Who wanted to go that didn't go? No-one asked me to vouch for anyone (including yosh and Dan) - could you explain where the problem is, pelase? > the person who went did not do such a thing. this > sucks. anyone doing this should be cut off from access to anything > regarding gimp immediately. there are many volunteers who have to the > best of my knowledge gone without reward for a very long time. Anyone doing what? Anyone taking a junket? I don't understand... there was an offer to have representation at comdex. The only people I saw respond were Dan and yosh. Who else said they would have liked to go? And where? I didn't see any of this... > this was a complete list of money available to gimp and people wanting > to contribute and their reasons to contribute? > > i think not. can you give a more complete list; maybe let known some of > the mail in the exchange. I gave you as much information as I have - you have the same information. I have received no mail specifying dollar amounts, if that's what you're asking. I think perhaps you are mixing up GIMP organised stuff with external events where GIMP people get invited. The GIMP has no money (Sven says we have 400 euros). I hope this clears up any confusion. As we might say in Ireland, please don't get your knickers in a twist. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon 2004
Let me clarify a bit. Carol Spears wrote: > to find out that 1) the trip was funded and 2) dsrogers went without a > plan of what he would say or do there. i am simply unable to explain > more than this. When I heard about the comdex thing, I assumed that there was finding from O'Reilly. The fact that there wasn't surprises (and disappoints) me. And let me emphasise that this is a completely different issue to fundraising for a gimp conference. dsrogers asked for help to organise a presentation at short notice to the list. As far as I know, he got several good ideas of things to show off there. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GimpCon 2004
Hi, Sven Neumann wrote: > > FSF Europe, ORA, FlamingText GIMP and someone else I can't > > remember gave us money for the last conference, of which 400 > > euros remains. Apple also lent us some equipment. > > Please let me get things straight on the fundings for the GIMP > Developers Conference this summer. Dave confused a few things here. Sorry - indeed I did. I got the global ORA mixed up with ORA Germany, and I believed that it had been FSF Europe who gave us lots of money. And the rest of the errors :) Hopefully this year I'll be in a better position to know. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-user] GimpCon 2004
Hi Tino, Tino Schwarze wrote: > 5) Chemnitz, Germany > > There will be "Chemnitzer Linux-Tag 2004" (Chemnitz Linux Day 2004) on > 6th and 7th of March 2004. March seems a little early to me - that means only 3 months to organise the event, including sponsorship. Plus, with 2.0 before Christmas, 2.2 won't be before June, and I would have liked to see GimpCon 04 celebrate its release. > Pros and cons: > - only 2 days (is this a k.o. criterion?) Not at all... guadec is also only 2 days, but people could come before/stay after to do some work. In fact, with guadec being Monday and Tuesday, I think that's the GNOME plan. Thanks Tino, it's an idea, it's on the list. For me the big down point is that it's very soon, though. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GimpCon 2004 (follow-up)
I want to start a new thread to get this discussion (which I consider important) back on track. LOCATION So far there are 5 propositions in various stages of development, each of which has some + points and some - points. 1) GUADEC 2) Lyon 3) London 4) Dublin 5) Chemnitz Are there others? We need volunteers. FACILITIES What facilities do we need? I've been working (in my head) with figures of 20-30 people, needing fairly liberal access to conference facilities and computer network, preferably staying with LUGgers, but perhaps in a hotel. MONEY Who will manage the money side of things? We need someone who is good with numbers, to organise a few people to do fundraising. DATE When is the earliest we could meet? When's the latest reasonable date? I like late June, I think June/July/August is our target area. Any comments? Like I said, feedback is *required* for this. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon 2004 (follow-up)
Hi Henrik, thanks for the feedback. Henrik Brix Andersen wrote: > > LOCATION > > Personally I think it would be best to piggy-back on an existing event > given that the organizers wouldn't mind, of course. This would give us > the benefit of an existing infrastructure. In this case, what IT events do people know of in the timescale we're looking at? GUADEC obviously fits, the Chemnitz event is a little early for my tastes, but is certainly an option. What other events are there that people know about? > > MONEY > > > > Who will manage the money side of things? We need someone who is > > good with numbers, to organise a few people to do fundraising. > > It would be ideal if The GIMP Foundation was a reality when we start the > fund-raising. We could then use the conference to evaluate the steps > taken to raise funds - and perhaps improve the process. I don't think we can rely on the foundation existing in time. And even if we did, the foundation would need a treasurer to be the person In Charge. In either case, we need someone to say they'll take responsibility for money. It might well be reasonable that that person then become the treasurer of the foundation. Are there any candidates? Personally I think it would be a good idea to separate the organisation of physical structures from fundraising - they're 2 very different jobs, and teach represents a considerable workload. If one person does both, he's likely to be overloaded with work. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-user] GimpCon 2004 (follow-up)
Hi Andrew, Andrew Langdon-Davies wrote: > On Fri, 21 Nov 2003 12:00:51 +0100, David Neary <[EMAIL PROTECTED]> wrote: > >LOCATION > >Are there others? We need volunteers. > > Barcelona, Catalonia (near Spain)? Site of the Universal Forum of Cultures > 2004, and probably also of an alternative forum as the official event is > referred to by many as the Forum of Speculation. I could act as go-between > and possibly even provide some accommodation. When is this event? Do you have any URLs by any chance? I'm sending on your response to the list. I hope you don't mind - I'm assuming that you intended it to go there :) Cheers, Dave. -- David Neary, E-Mail: [EMAIL PROTECTED] Tél: 04 78 58 08 83 CV: http://www.redbrick.dcu.ie/~bolsh/CV/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GimpCon 2004 (follow-up)
Hi, Branko Collin wrote: > Sven suggested (IIRC), Hacking Extreme <http://www.hex2005.org>, the > follow-up event to Hackers At Large in 2001, but that is of course > still more than one and a half year away. The advantage, from what I > understood, and IIRC, was that it tied into a networked camping > event. That's a great idea - I loved the CCCamp. And since we're planning on making this a proper annual event, perhaps the 2005 edition could be there. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] GimpCon 2004 (follow-up)
Hi, Sven Neumann wrote: > I expect that 2004 will see another Hackmeeting but the webpage > doesn't mention a date nor a place yet: > http://www.hackmeeting.org/2003/history_en > Perhaps someone knows more about the plans for 2004. I heard a lot of > good things about past Hackmeetings and it would probably fit well. Sounds like a definite possibility. > Then, there seems to be a vague plan for a HackSchiff in 2004: > http://www.unet.univie.ac.at/~a9900470/cngwiki/wiki.cgi?HackSchiff2004EN > The planned route would probably take a few weeks so that would give > us enough time for some decent hacking and chatting ;) I can't speak for others, but there would be no chance of me taking 3 weeks on a ship this year. Add the cost, and the time to get to Hamburg and from Italy, and I'm voting against this :) Nice idea, though... wish I were still young & happygolucky. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] About libgimp/gimpmisc* files
Hi, David Odin wrote: > Most of the functions of gimpmiscui.h are related to the > GimpFixmePreview stuff. This part looks pretty useful to me, and the API > is clean enough to be kept imho. The only bad point I see here is that > this code use the deprecated widget GtkPreview, but this could be easily > fixed by using some GtkDrawingArea/GdkRgb stuff. What do you propose, exactly? > gimpmiscui.h also defines the gimp_plug_in_get_path() function which is > only used by the FractalExplorer, gfig, and gflare plug-ins. This > function doesn't look really useful, since it is only a wrapper for > gimp_gimprc_query(), with some error-checking. I would vote to remove > it. Anyway, even if we keep it, it should at least be moved to > libgimp/gimppaths_pdb.c. Removal sounds good. > All the functions in libgimp/gimpmisc.h are related to regions or pixels > fetchers or iterators. I'll investigate more to see if they should be > kept, moved in a better place, or removed. A pixel iterator that transparently does tile management would be very useful, so some of these functions should probably stay around. The API needs some work, though - looks like most of the functions could be delegated to the plug-ins somewhat, once we kept a PixelFetcher and an Iterator (perhaps with a slightly modified API?). I think that the GimpPixelFetcher API is pretty usable and transparently does tile stuff... perhaps we should be using this more consistently? For example, in plug-ins/common/edge.c the pixelfetcher is used only for the edge cases where the pixels aren't all in the same tile, which kind of defeats the purpose of transparent tile handling. The current API just feels a little awkward, but I'm not sure how to improve it apart from perhaps changing the names of the functions ending with 2 ... perhaps just splitting out into gimppixelfetcher.[ch] and gimprgniterator.[ch], and refining the API would be enough here? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] What makes the GIMP toolbox special?
Raphaël Quinet wrote: > There are some subtle differences that are internal and IMHO not > important from the user's point of view: > > if we look at the remaining differences (again, from the user's point > of view, not from the code point of view), what is left? > > - The toolbox has a menu bar. > - The toolbox contains the buttons for switching tools. - Drag & drop of URLs, image icons, etc. opens up the image. That's the only one I can think of off the top of my head. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: The GIMP 1.3.23
Hi all, The next release in the development series of the GIMP, version 1.3.23, is now available for download from ftp://ftp.gimp.org/pub/gimp/v1.3/v1.3.23/ or from one of the mirrors listed at http://gimp.org/download.html This is expected to be the final release before we enter a pre-release cycle. A great deal of work has gone into stabilising the plug-in API, and fixing a large number of outstanding issues before the 2.0 release, so we think that this release of the GIMP is the best yet. More than ever, we would like people to download and build this release, and try to break it in new and interesting ways. Happy GIMPing, Dave. Overview of Changes in GIMP 1.3.23 == - Color proof display filter using ICC profiles written by Banlu Kemiyatorn - New gimprc options to work around window management problems [Sven, Brix] - Fixes for using GIMP on Xinerama setups [Sven] - Numerous libgimp* API cleanups [Mitch, Sven] - Theme switching in the preferences dialog [Mitch] - Added a small theme [Mitch] - Cleanup and unification of message strings [Mitch] - 64bit clean libgimp API [Yosh] - New plug-in color selector using color-selector modules [Mitch] - GimpCanvas drawing abstraction [Sven] - Added DICOM file plug-in by Dov Grobgeld - Imported new WMF plug-in from libwmf2 [Sven, Mitch] - A session name can be given on the command-line [Sven] - Allow to move image windows and docks between screens [Mitch, Sven] - Fixed multi-head issues [Mitch] - Allow to merge visible paths [Simon] - Redone GimpDialog API [Mitch] - Load GIMP brush format version 3 [Sven] - Allow to use GIMP without any fonts [Sven] - Lots of bug fixes Other contributors: Ville Pätsi, Eric Pierce, Tor Lillqvist, Henrik Brix Andersen, Manish Singh, Dom Lachowicz, Francis James Franklin, Dave Neary, Maurits Rijk, Joao S. O. Bueno, Michael Schumacher, Daniel Rogers, Hans Breuer, Jakub Steiner -- David Neary, Lyon, France. E-Mail: [EMAIL PROTECTED] -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] bug triage for 2.0
Hi all, As those of you who follow bugzilla may have noticed, I have started attacking bugs on the 2.0 milestone. It is now clear that not all of these will be fixed before 2.0. We will need to re-distribute the ones that will not be fixed among other milestones, or close them. As rough guidelines, anything that we hope to fix before 2.0 should stay on the 2.0 milestone. We should prioritise these, so that when we want to release, they can be moved to the 2.0.1 milestone (reserved for things that really need fixing, but which aren't going to be fixed for 2.0). Bugs which are important to fix should be addressed early in the unstable release cycle, and should therefore be added to the 2.2 milestone. We will probably add milestones when we start on a 2.1 branch to further carve up these bugs. Anything which is a feature request and doesn't have an identifiable owner should go to Future. I've thought about this, and there is a certain logic. Either the feature has an owner we can hassel to do the feature, or no-one wants to do it. In that case, there's no point adding it to a milestone closer than Future, because it won't be done. When someone claims a feature request and says they'll do it, it can then be added to a more reasonable milestone. Any bug against 1.0.x should be closed WONTFIX. 1.0.x is ancient history. Any bug which has been in NEEDINFO for longer than 6 months should be closed INCOMPLETE. The original author can then re-open it if he considers the bug is still valid and he wants to add more info. Any bug which has not had a comment added for over a year should be bumped to 2.2, and have a comment added asking what the status is. If, in 6 months time, there are still no further comments, the bug can be closed WONTFIX. We are still working towards a 2.0 release before Christmas. Looking at CVS, we are not that far away from it. I feel that the pre-release cycle will throw up some surprises and that we will have trouble getting to 2.0 that early, but that's another matter. There are now under 100 bugs on the 2.0 and 1.3.x milestones. I would like to see that reduced to around 40, and I would also like to see more than 3 or 4 people closing bugs. To get a 2.0 release soon will be a huge job, and Sven and mitch cannot carry on doing all the bug fixing. If you have any free time at all, please pick a bug and help out. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Default values for window management settings
Hi, Sven Neumann wrote: > The question I'd like to bring up is what should be the default values > for these. After quite some discussions I now propose the following: > > (toolbox??window??type normal) > (dock??window??type normal) > (activate??on??focus yes) I agree wholehearedly. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP at GUADEC
Hi all, Following up from the mail last week discussing the date and location of GIMPCon, here's the state of play on the various possibilities discussed. 1) GUADEC: The GNOME crowd are delighted to have us, the guadec planning committee are very eager, and are now planning a graphics/multimedia stream for the conference. I am now on the guadec-planning mailing list, and if we go to guadec I'll be co-organising the graphics stream (I wonder why I asked for a volunteer to do this...). 2) Lyon: We have been in contact with the university, and are awaiting a response on what kind of facilities will be available, and what dates suit them. This is looking pretty promising too. The local LUG are prepared to help out and play host. 3) Dublin: Very little movement. 4) London: Idem. 5) Chemnitz: Idem. So the situation as it is is that we should decide pretty quickly where we want to have the conference. Does having it at GUADEC pose any problems for anyone? Personally I think this is the best option available to us, even if it will pose us some fundraising problems. For our part, it would be nice to see 2 or 3 papers presented by GIMP people, and the organisers have asked whether it would be possible to have GIMP demonstrations similar to the one that jimmac did last year. The papers could be quite in-depth and technical, given the nature of GUADEC, or could be more aimed towards users and have a tutorial feel to them. So - speak up. What do ye think? Are we going to GUADEC? Should I continue exploring Lyon in case it doesn't work out? Are there other possibilities? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at GUADEC
Hi, Daniel Rogers wrote: > I like the GUADEC idea technically. From a personal, selfish, > un-gimp-like, I want to see the world point of view, London, Lyon, and > Dublin have been on my list of places to see for quite some time. However, > I think GAUDEC, especially since they are excited to have us and are sound > willing to accomadate our needs, is better for us as a project. London's easy to get to, Dublin's nothing special, and why on earth would you want to come to Lyon before (say) Prague, Paris, Amsterdam, or half a dozen other cities around Europe? :) > I am not sure if there are going to be fund raising issues, per say. We > are probably one of a relativly small set of projects going that don't have > any regular funding, so I am willing to wager that the funding will be no > more trouble for us that it is normally. Given that GNOME is a GNU project, and in past years the FSF has been our biggest contributor for conferences, I can foresee problems. > Also, as far as volunteers go, obviously I am not the best person to be > planning anything happening in Europe (at the very least my sleep schedule > couldn't handle it). However, if you have anything you would like or can > be delagated to me, please ask. It would be really cool if you would be the money man - the man that we could have the checks made out to. And if you could muscle some of those Comdex contacts, and work US companies (particularly Hollywood, where we know teh GIMP is used a lot), that would be brilliant. > I should really give a presentation on Gegl there. This would encourage me > to get off my ass and write technal white papers discussing the huge about > of planning I feel I have put into gegl. This would be good for me, too, > as writing down ideas always provides a good oppurtunity to improve on > them. Also writing down ideas provides a good chance for people to > critizie those ideas, which would also be good. That's great to hear too. The official call for papers hasn't gone out yet, but the format in previous years has been 30 minute talks and 60 minute talks, people would like to see published proceedings this year, so perhaps a 60 minute presentation might be an idea to get a bit of meat on things? > What are your feelings here? Do you think there is a chance GAUDEC won't > work out? I think there is a chance that we might end up struggling to get everyone there financially. I also think there's a chance that some GIMP people might not like the connotation that GIMP is or might be a GNOME app. I also think that piggy-backing on a big developers conference is risky, in that the objective of the GimpCon would be to be 100% into the GIMP for a few days, and with GUADEC going on that might not be so easy. In other words, I can see why some people might prefer a smaller cosier event. I think that the way our organisation is now, that's asking a lot of a couple of people to organise. The benefits of a big event are that there is less infrastructure to work on from our point of view. So there are pros and cons :) Personally, I like GUADEC. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: GIMP at GUADEC
Hi David, David Odin wrote: > If the GIMPCon stand in Lyon, there will be at least some rooms, with > Internet access (ssh, web, mail, at least), via a switch/hub. Any laptop > with a dhcp config could then be connected. > > The rent for the rooms and the lunch at 12:00 might be paid by some > presentations made by one of us to the CPE's students. I still have to > discuss this point though. This is great news, I haven't yet gotten an answer from the CPE person I mailed over the weekend, but it's good to see that plans have moved along. Given that GUADEC is the end of June, and at least a few GIMP people will be going to that, I suggest that we should look at dates in mid to late July for Lyon. Hopefully by the end of the week we will manage to have a proposition that we can discuss from Lyon, as well as more information from Norway. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP at GUADEC
Hi Daniel, Daniel Rogers wrote: > The only > real choice is to start asking for support and seeing what happens. Agreed :) > I checked with the lawyer today and it seems that she would be > ready to give me all the information I need to fill the paperwork to > start The Gimp Foundation out myself after Thanksgiving. That's great news! If we give thanks now, does that mean it'll be done soon? When's thanksgiving? > As far as sniffing around Hollywood goes that is really Robin Rowe's > territory IMO. I had a conversation with him recently, trying to > encourage our projects to work together, and because I didn't understand > where he was comming from, and because it was email, I ended up sounding > arrogant and condesending (it just became an argument, really). At this > point, I simply don't want to step on his toes. I understand your point, but I think it's not valid. I don't see us as being in a turf war with CinePaint. If he has better contacts with the studios than we do, that's fine. But our target audience for funding is people who have used the software no charge, and have a vested interest in seeing it improve. The studios fit that bill to a tee. I would ask Calvin and Yosh for contacts here - they both worked with film companies for a while. Caroline Dahlof at R&H might be a good place to start, afterwards it would be nice to try to contact someone at Disney (following on from their recent evaluation of the GIMP and CinePaint) and ILM who use the GIMP lots. > I am also deeply concerned about what several sections of the movie > industry think about open source and the GIMP in particular. If it is > anything like what Robin Rowe thinks we are, then I will likely just be > laughed at for having the nerve to knock on their door. If Robin continues to preach revisionist history about the evil GIMP developers unopposed (Robin if you're reading, I'm sure this isn't an accurate reflection of your intent, but it's how it has been perceived here and by others) then it is normal that that viewpoint will gain credence. To some extent, it's a matter of visibility. We need to be seen again. A 2.0 release will help. Going to people and saying "here are our goals, here's what we've done to work towards them, here's our plan to get to them" is another great way to get people outside the project enthused by it again. > I am afriad that if I try and go to hollywood without a good technical > incentive and a convincing argument as to why they should support the > gimp, I will do more harm that good for our relations by reinforcing > whatever negative opinion they have about us. I think that you are in a better position than most of us to give good technical arguments why the GIMP should be supported. GeGL is (still) the future of the GIMP. We are hoping that GeGL will have a stable base which we can integrate into the GIMP soon (8 months time?) as well as something we can add advanced functionality to quicker, easier and better than the old core. We're not selling a panacea. But the GIMP will be competing with Adobe again, and will have outstripped CinePaint by a long way once we have a compositor engine that works well and has a nice interface. But that's not going to happen soon, unless we meet up more frequently and talk about it, plan it, see where we're at and how to get to the next waypoint. > I am waiting until we have color management, high bit depths, an awesome > compositing engine, and a frame manager before really trying anything > over there. This would give me convincing technical achievements with > which to approach Hollywood. All but the last is being worked on, while > the last is not technically challenging. I think that this is somewhat putting the cart before the horse. I think that the time that money will do the most good is now, before we have those things, so that people can get together and brainstorm through the problems. 2.0 itself represents a substantial technical achievement which could be leveraged. > Hmm, better get started on that then. I think I could fill 60 minutes > with details about our compositing engine, color management, and some > exciting far-future ideas. How will I know when the call for papers starts? I'll post it here, among other places. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Discussion on transparency
Joao S. O. Bueno wrote: > Other effects aside, I am all for preserving the RGB values of each > pixel, regardless of it's alpha value. If there is garbage in there, > once the mask has the alpha channel Agreed. I am of the opinion that modifying the alpha channel should never modify RGB data. If we consider pixels with alpha 0 as undefined, then that isn't a hard & fast rule. > Also, the nominations "copy from alpha channel" and "move to alpha > channel" sound clear enough, while "layer's alpha channel" by it is > own was very obscure to me when I met it first time. And "Alpha channel to Layer Mask" is unclear? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP Con planning update
Hi all, This is a quick update on the planning for GIMPCon 2004. As you know, I was continuing to explore two possibilities - GUADEC and a standalone event in Lyon. The current situation with GUADEC is that we are more than welcome, and are invited to take part in the Graphics stream of the conference. It is likely that there will be representatives from other graphics applications. Off the top of my head, sodipodi, inkscape, dia, OO Draw, CinePaint and ourselves are the main desktop graphics applications at the moment; are there any others I have forgotten? Organisation for this is still in a very early stage, I will know more in a couple of weeks. The Lyon situation is pretty promising. The university is very interested in having us, and are providing lots of facilities for free. They have asked that we organise a half-day of conferences and demonstrations on the GIMP and other free graphics applications. There'll be wifi, as well as access points to the local network, as long as we play nice and follow the school network usage guidelines. The only sticking point is that their facilities are typically closed on weekends, and opening things up for us would incur a cost, which they would expect us to cover. So our choices are a free 3 days during the week, or some weekend and some days during the week, but not free. In short, both propositions are costing little in terms of infrastructure for the conference, but GUADEC demands no organisational cost (apart from me - I'm co-organising the graphics stream). Just keeping you up to date. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi Stephen,
Stephen J Baker wrote:
> What GIMP does now is just fine - what might be nicer would be some kind
> of toggle to temporarily show the entire image as opaque (without actually
> destroying the value of the alpha buffer).
Raphaël will probably kill me for advertising a feature he
considers a bug, but anyway... you can now do this by converting
the alpha channel to a layer mask, and hiding the layer mask in
the usual manner.
Cheers,
Dave.
--
David Neary,
Lyon, France
E-Mail: [EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi Raphael, Raphaël Quinet wrote: > Well, I am still not sure about what was the real source of the > problem mentioned in that bug report. Quite simply, Photoshop (according to the bug submitter) does not pre-multiply RGB data by the alpha channel when saving, which allows the complete data to be retrieved afterwards. This is perhaps an option, but that was the origin of the problem. The submitter expected the GIMP to do the same thing. > According to the > second comment from the reporter, it looks like Photoshop is able to > decode both types of images correctly (with and without pre- > multiplication) So do we - but at load time, we pre-multiplied the RGB values (as prescribed in the standard), so the behind-the-alpha data was destroyed. Actually, without going into details, I think it could be considered correct to do this on save, but to read the data in the file as-is (that is, without pre-multiplication). That is, we assume that this operation was done by the application that created the image, and we read whatever's in the file. Part of the patch I attached to that bug would do this, if it were desirable. > so I suspect that the real problem comes from some > exotic option that we (or libtiff) do not use and that would allow us > to save the image with full RGBA information. Nope - according to the latest tiff standard I could find, we're unequivocally doing the right thing on save. > It > may be an undocumented extension - TIFF is known to be full of these. Ah - if you say so :) > Well, I'd rather be non-violent... ;) Of course, we should not > destroy data if we have no good reason to do it. On the other hand, > we should not lock ourselves in a situation that would prevent us from > destroying this data if that could bring other advantages. The fundamental rule that I thinkl we should follow is that modifying any 3rd party or user data should require an explicit action from the user (switching a toggle to optimize the image, for example, or toggling a preference to do alpha pre-multiplying, or somesuch). If the user does not request it, we should not touch his data just because we think that might be what he would expect. > Exposing internal data to the average user means that we would not be > allowed to some of this internal stuff later. Nonesense. Applications change their behaviour all the time - free software projects more than most. If we decide to provide features like layer auto-growing in the future, then we can do so. Saying that one 20 line patch will prevent us from doing something is just wrong. Also, I do not consider the data we're talking about to be internal, or undefined. It is simply data which is not visible in the projection. The undo brush sounds like it would be a nightmare to implement and get to act reasonably... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Here Be Bounties
Hi, That reminds me of some mail I got from a guy who also proposed prizes for GIMP functionality. I believe that he mailed to the list, he also posted on Usenet a few times. As a point of interest, what should we do when this kind of thing happens? Debate the features, decide which we'd like to have anyway, and then publish the bounties on wgo or dgo as is happenning for the GNOME/Ximian bounties? Open bugzilla bugs for each feature, and let nature take its course? Working on bounties might be an interesting way to fundraise for the GIMP community to pay for things like travel to GIMPCons and costs associated with the Foundation, if people decided to donate their prizes. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Handling of transparent pixels
Hi Raphaël, I think everyone has more or less had their say on the thread - can I just sum up the salient points? Raphaël Quinet wrote: > I agree. This is what the GIMP does and I was definitely not > suggesting to change this, so I think that you misunderstood what I > wrote. The GIMP will keep on using post-multiplied alpha in the > future, and this is a good thing. > > The whole point of this discussion was based on the fact that because > we use post-multiplied alpha, there is some ambiguity about whether > the average user is supposed to know and rely on the RGB values of > transparent pixels. If we had been using pre-multiplied alpha, then > there would be no reason for any debate, because all transparent > pixels would have R, G and B = 0. You believe that allowing the RGB data behind transparent pixels to be exposed might be confusing to some users - so far in the thread you are the only one who has asserted this. You consider that in certain circumstances this behaviour could be considered a bug. Others have stated that there are several applications where transparent data is stored across sessions, and that this data is indeed useful, and not at all undefined. Personally I have stated that we should never destroy or modify data without explicit user action to that effect. For the moment, unless I am mistaken, you are the only person to have stated that they consider the current behaviour wrt transparency flawed. Can I propose, then, that we keep the current behaviour? Perhaps we could have a filter that pre-multiplies layers by their alpha channel? That would be trivial to write, and would address Raphalël's concerns, while staying true to the principle I outlined. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using gimpwire
Shrinivas Kulkarni wrote: > Can anybody point me to examples about how to use gimpwire lib? Hi Shrinivas, I don't know if there are any such examples outside GIMP cvs. Inside CVS, use of gimpwire is limited to libgimpbase/gimpprotocol.c, and that might be a good place to start. The functions in there are called from (among other places) app/plug-in/plug-in-message.c and libgimp/gimptile.c (which encapsulates most of the image data passing in the protocol). Hope this helps, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Friends of GNOME
Hi all, We are coming up to a release. I will post a detailed progress report, along with the current thinking that I have about the outstanding blockers. But this mail is about something else. Over the years since 1.2.0, or even since 1.2 pre1 (way back in April 1999) we have seen quite a few old "heads" drift away from the GIMP, either because they've become more active on other projects, or haven't got as much free time, or simply because they got into a big row and got pissed off. I think that 2.0 is an ideal opportunity to get some old GIMPers giving time to the project again. Some notable examples of people who have started to reappear recently, and should be welcomed with open arms, are Kelly and Jay. Some names that come easily to mind are syngin, adam, vidar, prof, bex, federico, and a bunch of others I'm forgetting. We're not going to dramatically break things again in the way that we did at the start of the 1.3 cycle, or even when we made the change to GTK+ 2.2 and Fontconfig a few months ago. In principle, someone who has the dependencies for a 2.0 build should have everything they need to keep up with GIMP CVS through the 2.2 release. So, I would like to put together a list of freinds of the GIMP, and get onto them and see if we can interest any of them in getting involved again. Can anyone think of names I've left off here? Several of these are certainly still on the devel list (if you are, shout). Many will probably request not to be sent any more mail. A few might help out a bit. So can I get names and e-mail addresses of people who were hanging around a while ago that you haven't seen since, and that you thought were cool? If so, could you send me a name and an e-mail address? What do people think of the idea of a Friends of GIMP list that gets added to the announce list when we make a release, for example? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Quick progress report
Hi all, I don't have as much time as I'd hoped, so this is a quick report before bedtime. The 1.3 series is nearly at an end. If all goes well, we will have a 2.0 pre-release before Christmas, probably the end of the weekend or Monday. There are a number of issues still sitting on the 1.3 milestone, including some text tool improvements, the website migration, and a couple of small API changes. Nomis, who is working on the About dialog for 2.0, agrees that it's not a blocker for a pre-release, and in addition he won't have time to finish it until he celebrates the new year with his laptop :) The API changes are, in short, additions to the API which can be checked in very soon after the 2.0 release, or even before it if they're trivial enough. Since none of these will break existing scripts or plug-ins, I don't think that they could cause any problems. The text tool is, I think, good enough to be in a stable release. Sven had hoped to find the time to update it a little and add more of the features we would all like it to have, but as the ChangeLog shows, he has been very busy stabilising the tree, and fixing a large number of bugs which needed fixing before a stable release. These features will get scheduled for somewhere in the next few months, all going well. So there we have it. Barring a couple of small issues, we are ready for a pre-release. And given the current stability of the GIMP, I think that 2 or perhaps 3 pre-releases, with 2.0 before the end of January, is a realistic goal. That will lead us on to 2.2, and that's another thing we need to talk about. For the moment, the list of bugs on the 2.0 milestone has a number of bugs that should be fixed before we go 2.0. Many of these, though, can be fixed later on. The priority now, I think, is to get people using this piece of software we've built. Let out the GIMP! Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Friends of GIMP (was GNOME)
Hi all, Thanks to the people who pointed out my very Freudian slip above. While we are, in large part, friends of GNOME, that's not what I meant to write :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Friends of GIMP
Hi, Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > What do people think of the idea of a Friends of GIMP list that gets > > added to the announce list when we make a release, for example? > > I thought that's what gimp-developer was for. Personally I don't think that's what the developer list is for... The developers list is for people actively involved. I doubt S&P are on the developers list, for example. I wouldn't be surprised if a lot of older heads are no longer subscribed to the list (although I'm sure that many have stayed subscribed). The devel list is not pro-active. It does nothing to get people into the project, which is what we need. You could call this targeted spam, if you like... and effort to actively get in contact with people who used to hang around, and don't any more. An effort to become the cool kids again :) Recently the only way people outside our little clan have been hearing about the GIMP is through release announcements. With no disrespect intended to the site, it's not been the medium that we've used for disseminating information, and www. looks a bit old these days. mmmaybe hasn't had the news updating, most gimp people don't syndicate blogs in the way that, say GNOME developers do (I don't know how many times I've heard about cool new GNOME stuff through blog comments). So we need to make an effort in this respect. There are 2 groups of people that we can aim for - people who once were heavy GIMPers, the people (like Xach, say) who were never developers, but did a huge amount to make a community around it, and people who have never been GIMPers, but have a lot to offer (new arrivals who have made a huge impact recently are Joao, Pedro and Roman - we need more people like them). The Friends of GIMP is one way to target the first group - for a start, we know exactly who they are, which makes the task a lot easier. I think that if the community starts to become as vibrant as it was in the 1.1.x days, we will not have huge problems with the second group. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Friends of GNOME
Hi, I'm replying in 2 parts, because there were 2 different issues in this mail. Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > In > > principle, someone who has the dependencies for a 2.0 build should > > have everything they need to keep up with GIMP CVS through the 2.2 > > release. > > We will have to depend on GTK+-2.4 pretty early if we want to make use > of the new functionality it provides. Since there's a lot of very > useful stuff in the 2.4 API, we should make the switch to GTK+-2.4 > soon after the 2.0 release. What functionality is in 2.4 that we could use? I don't mean to be a killjoy - we should definitely be able to build with 2.4.x, but IMHO, we shouldn't bump the version requirement unless there's a very good reason to do so. When we asked ourselves around the conference what hurt us the most after 1.2 was released, it was the fact that the build environment got complicated, and took a considerable amount of time to set up, and also the GIMP was broken for longish periods. It all depends on what the goal of 2.2.x is. I think it should be a stabilising release, one in which we add small amounts of functionality, get it working rock solidly, and perhaps start making changes in app/base to integrate some of gegl. We might even consider shipping gegl with the GIMP during 2.1.x to get more people building & using it (I would reccommend shipping it with the GIMP sources, rather than depending on it, if we decided to do this). These are all smallish changes which shouldn't really impact people's build environments, It means that people who just want to build from CVS would be able to do so easily, and without having to spend time updating other stuff while doing so. We really have to ask ourselves whether the functional additions to GTK+ 2.4 are really worth the cost we would incur in human terms in depending on the newer version. I'd like to see us stick to 2.2 unless there's something indispensable that we need in 2.4, and even then I'd like to see a case made for it before the change on the devel list, rather than have the change happen silently after some discussion on IRC. We're anticipating a certain amount of breakage after 2.2 anyway with the integration of gegl and its development, so at that point it would be more reasonable to start upping the required GTK+ version (perhaps even to 2.6.0 when we get there). In short, I see the 2.2 series as a community building release cycle, and our best chance to get people into the project after several years in limbo. If we start depending on software that isn't commonly available yet, we risk to waste some of that opportunity. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Random seed widget
Hi, As some of you may have noticed, I committed a couple of changes recently to libgimpwidgets concerning the gui for setting random numbers. This was essentially backwards-compatibility for the PDB calls for several random functions so that we could request a random generated thing from a number of plug-ins without having to generate a random seed in the plug-in itself. Of course, we could have left libgimpwidgets the way it was if that was all there was to it, and simply have the plug-ins call g_random_int() to get a seed before calling gimp_random_seed_new(). The addition of an extra argument to gimp_random_seed_new() was to allow a way for the user to say "I don't care about the preview or whatever, just give me a random thing". The advantage of this is, for example, that you could generate 10 plasmas all different just using Alt-F to call the plasma plug-in with the last values. The thing is, I'm not particularly happy with the idea. The whole point of changing this widget was to have "run with last values" generate the same result as the last time. Plus, coming up with an appropriate UI to expose this isn't that easy - I'm personally not sure this should happen, I think that the compat code that I added last week is OK, but that the current UI should stay as it is. In any case, I have made most of the change requested by mitch. What's left would be to add a boolean for the criteria to the 4 or 5 plug-ins which use the random seed, and to make toggling the checkbox on generate a new seed. It's not done, and won't be done until at earliest tomorrow. There are screenshots of what the widget looks like here attached to the bug report about this (which I've re-opened), bug #129529 - http://bugzilla.gnome.org/show_bug.cgi?id=129529 Please attach comments there, or reply here (perhaps the mailing list is better). I think I've almost convinced mitch that this is not the right thing to do :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Quick progress report
Hi, Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > The API changes are, in short, additions to the API which can be > > checked in very soon after the 2.0 release, or even before it if > > they're trivial enough. Since none of these will break existing > > scripts or plug-ins, I don't think that they could cause any > > problems. > > Sorry, but *no* API changes can and will be made during the stable > series. An exception would be severe problems with the API that make > an API change unavoidable. Additions to the API mean new functionality > and can only go into the HEAD branch leading to GIMP-2.2. That seems a bit strict to me for some things which will essentially be small local changes, but I guess we have different philosophies on this. In any case, "very soon after the 2.0 release" could also mean "after we branch off a 2.0 maintenance branch". > > The text tool is, I think, good enough to be in a stable release. > > Sorry, but it isn't. At least undo needs to work correctly and must > not crash the application. I will continue to work on the text tool > when Blinkenlights Reloaded is up and running. Fair enough. It is at least good enough to be in a pre-release, though :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GEGL in GIMP (was: Friends of GNOME)
Hi, Sven Neumann wrote: > David Neary <[EMAIL PROTECTED]> writes: > > IMHO, we shouldn't bump the version requirement unless there's a > > very good reason to do so. > > There are very good reasons. We already prepared the tree to use the > new file chooser and everyone is looking forward to revamp the menu > system based on GtkAction. These are very important changes that > should go into the GIMP CVS tree as early as possible. I think that we could perhaps do the version bump in an organised way this time, at least? Perhaps have a 2.1.0 with a couple of weeks work (basically, the stuff which is waiting to be committed more or less now, but can't go into a 2.0 branch), and announce that it is the last release that will use gtk+ 2.2? Or even have a few releases, and do the version bump in (say) early March? You say "as early as possible" - I would argue that it's not realistic to bump versions until people have had a while to brace themselves. > > We're anticipating a > > certain amount of breakage after 2.2 anyway with the integration > > of gegl and its development, so at that point it would be more > > reasonable to start upping the required GTK+ version (perhaps > > even to 2.6.0 when we get there). > > IMO it is a lot more important to get the mentioned GTK+ changes than > to start to integrate GEGL. I guess I should clear up what I mean by "ship with gegl" here. I haven't talked in depth with people about this yet (neither the gegl developers or gimp people), but I'd like to see something like what Subversion does with Neon. They realise that Neon is not a commonly available package, so in their tarballs they package the last released Neon version - their build scripts detect if it's present (or you can specify a directory where you already have an installation), and build it for you, or use the existing build. It seems obvious to me that gegl will need to start making a plan, and making milestone releases, soon if we want it to be usable for the end of the Summer. That mean that it needs to be used and built, and all the rest. What I would propose is that the GIMP CVS module have an app/gegl directory which is linked to the gegl module, so that doing a cvs co of the GIMP would also check out gegl. We wouldn't actually be using any of the functionality in there, just building it. And in tarballs, we would release a snapshot of gegl along with the GIMP. It wouldn't gain us anything in the 2.2 release, perhaps, but I think it mlight be enormously beneficial to gegl. It would also allow some gimp developers to get more familiar with what gegl is, and what it can do, and so on. And why not start migrating some app/base code to app/gegl, and making some trivial use of gegl for 2.2, as mitch suggested some time ago? This is not something which would cost a huge amount to the GIMP. Like I say, I'm not talking about throwing out base and replacing it with gegl now, but I think that it'll benefit both projects if we start including the gegl sources in our tarballs with the 2.1 series. > > If we start depending on software that > > isn't commonly available yet, we risk to waste some of that > > opportunity. > > I don't follow you on this argumentation. Especially not since > GTK+-2.4 will probably be released around the time we release > GIMP-2.0. Depending on it is a must and I don't believe it will make > us loose a single seriously intersted developer. It's not the seriously interested developers I'm worried about, but the casual ones who might eventually become serious developers, if we don't piss them off or make it hard for them to follow the GIMP development cycle. We need more people building from CVS than we had in 1.3.x, and we're not going to have that if we depend on bleeding-edge build tools or libraries. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Problem starting gimp-1.3.23
Hi, Sven Neumann wrote: > Sorry, but what Dave wrote here is wrong and will only confuse Frank > (especially since Dave wrote freefont when he probably meant to write > fontconfig). Look at the error message. The problem isn't missing > fonts but a miscompiled Pango library. Either Frank is linking > libpangoxft with a wrong version of libpango or he compiled the pango > libraries against a wrong set of Pango headers. Yes, I had a brainfart. I mean fontconfig which, as both Frank and Sven have pointed out, was not the problem. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Hi, Sven Neumann wrote: > Because I believe that it will hurt the project to become part of the > GIMP tarballs. It will be much more helpful if we help to create > standalone GEGL releases early. This will raise interest in GEGL and > it will make packages appear for all distributions. Since neither of us are currently involved in gegl development, I was hoping that we might get some opinions from the people who are. But given that the conversation has started as a sort of argument, I'm not sure whether anyone else will get involved now. I hope so. > Moving it into the GIMP tarball is like moving GTK+ back into the GIMP > tree just because we need some functionality out of the HEAD branch. Not at all. GTK+ lived in the GIMP source tree until it was capable of being a standalone project. Afterwards, its main developers were gimp developers. Unfortunately, several of them followed the path which GTK+ has become to go on to be core GNOME developers and no longer work on the GIMP. The point is that as it is, gegl is not a standalone project. It doesn't seem to me like it is mature enough that if the GIMP went under (say a few more people quit), gegl would not go on to be a standalone graphics library in the way that gtk+ went on to be a standalone toolkit. During the incubation of the project, it needs attention from us in the same way as gtk+ got attention pre-1.0. Looked at this way, leaving gegl standalone is more like developing gtk+ as a standalone project, and saying that we would use it when it were ready, while continuing to develop the 0.99 series with motif. > GEGL is a separate project and it is IMO very important that it > doesn't become too GIMP-centric. Having it included in the GIMP > tarball will make it appear as part of The GIMP which it isn't > supposed to be. What you suggest basically has only disadvantages. Let > alone the fact that it will be a nightmare to maintain. I'm not suggesting maintenance. I'm suggesting including milestone releases of gegl in our sources. Or storing them with our release tarballs. Either is good. Basically, releasing them together. Early. Before we use the functionality. So that they get built, and people are aware that gegl is real software, not a mission statement from 3 years ago. I'd like to see this done hand-in-hand with a configure check for gegl, so that we actually do get people downloading and building it. And gegl is, at this moment, a gimp utility library. It may not stay that way. I would expect that cinepaint might like to migrate their core to gegl at some stage, if it becomes the killer graphics motor it aspires to be. Perhaps some mini-gimps, or specialised graphing applications, will use it. But being associated with the GIMP is not a disadvantage for a toolkit or utility library. Look at gtk+ and gimp-print. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gegl-developer] Re: [Gimp-developer] GEGL in GIMP
Hi, Sven Neumann wrote: > Putting the tarballs somewhere close to the GIMP tarball on the FTP > server is of course reasonable. But unless I completely misunderstood > you earlier, you proposed to include gegl as a virtual CVS module and > to include it in the GIMP tarball. That's what we've been discussing > here. It was an idea. The original idea I had was exactly what you said. Given that was so problematic, I modified the idea. Perhaps I should have signposted the change :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: GIMP Aqua GTK+OSX
Hi, David Odin wrote: > Yeah! Good job. Now, it would be great if you managed to do the same > for gimp-1.3.x. If all the necessary libs were ported too, we could even > consider to include this in the main tree, WDYT? I think this is a great idea - you'd need to talk to Owen more than likely, since he is the gtk+ guy for the most part, and most of the code changes would be in gdk. In fact, all going well, an Aqua port of gdk would require no code to change in the GIMP to run perfectly. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Friends of GIMP
Hi all, Here's the list of names on the Friends of GIMP list at the momenta The e-mail addresses I havce are from old changelogs and mailing list archives (for obvious reasons I haven't included them in the mail). If there are names I've forgotten, or e-mail addresses which have changed in the last 3 years, or your name is on here and you'd rather it not be, please send me a mail. I'm going to be away for a few days, so don't be too worried if you don't get an answer straight away. Cheers, Dave. Jay Cox Tor Lilliqvist Austin Donnelly Garry R. Osgood Nick Lamb Owen Taylor Larry Ewing Andy Thomas Adam Moss Federico Mena Quintero Kelly Martin Zach Beane Vidar Madsen Adrian Likins Rebecca (Bex) (sorry, forgotten her surname) Shawn Amundsen Seth Burgess Chris Lahey -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 2.0 pre1
Hi all, The first pre-release for the upcoming 2.0 version of the GIMP is now available for download from ftp://ftp.gimp.org/pub/gimp/v2.0/testing/ or from one of the mirrors listed at http://gimp.org/download.html Not everything is in its final state, but we think this is close to a final 2.0 release. Your feedback will help make the 2.0 release even better, and we particularly appreciate testing efforts. New bugs can be reported to us at http://bugzilla.gnome.org/ Please note that the GIMP 2.0 installs side-by-side with the GIMP 1.2, so there is no need to uninstall your older GIMP. Happy GIMPing, Dave. Overview of Changes in GIMP 2.0 pre1 == - Replaced old "About" dialog [Simon] - Allow removal of text attributes from text layer [Sven] - Add optimisation option to png (clear transparent pixels) [Joao] - Add POSIX shared memory implementation, and use it on MacOS X [Yosh] - Dashed selection and path stroking [Simon] - Grey picker in Levels dialog conserves lightness [Bolsh] - Created a library for handling thumbnails [Sven] - Support for multipage TIFFs [Andrey Kiselev] - Added a channel mixer plug-in [Martin Guldahl, Yosh] - PDB cleanup and compatibility mode [Mitch] - Cleaned up libgimp API [David Odin] - Lots of bug fixes Other contributors: Adam Moss, Jakub Steiner, Helvetix Victorinox, Pedro Gimeno, Adrian Bunk, Abel Cheung, Maurits Rijk, Ville Pätsi, Marco Munari, Shlomi Fish, Jakub Steiner, Raphaël Quinet, David Gowers, Michael Schumacher ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dithering
Hi David, David Gómez wrote: > I've scanned some jpeg images with a 24bit depth. Some of them are old > photographies in black&white that show 'bands' when are displayed on > a 16 bit depth display. This is a normal phenomenon when moving to higher bitdepths. Unless you're talking about 16 bits in total, and not 16 bits per channel, in which case I'd be a bit mystified... > After digging in the menus i noticed that the > image could be transformed to a indexed pallete, with a Floyd-Steinberg > dithering, but that did not solve nothing, the maximum number of colors > cannot be set to more that 256 :-/. Floyd-Steinberg dithering is basically a way to approximate more colors with a smaller palette... it does not actually do anything like what you are expecting (as you have noticed). > Is there another way to dither an image in gimp? Have you tried blurring the image with a radius of 0.5 or 1.5 pixels? This sometimes works quite well. > Programs like gqview, an image viewer, use the dither > algorithms bundled with gdx_pixbuf in gtk2, and they work perfectly with > the same images. Why cannot the gimp do the same quality dithering if > it's using the same library? Oh, I see what you mean, I think - you're talking about the rendering of the data, you don't actually want to change the underlying data, you want it to look better. Is that right? If that's the case, then I'm afraid the answer is that I don't know. I thought we used a GdkPixbuf, so if we don't I'm stumped :) Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GUADEC 2004 Call for Papers
GUADEC 2004 CALL FOR PAPERS The Fifth European Gnome Users and Developers Conference June 28-30, 2004, Kristiansand, Norway http://guadec.org/ Abstract submission deadline: February 16th, 2004 The European Gnome Users and Developers Conference (GUADEC) invite you to participate in the Fifth Conference on June 28-30, 2004, Kristiansand, Norway The GNOME User and Developer European Conference (GUADEC) will bring together developers, GNOME Foundation leaders and individual, business and government GNOME and open source software users. The conference is a unique forum for highlighting the capabilities and direction of GNOME, the user environment for desktops, networked servers and portable Internet devices. GUADEC will also feature discussions of the future direction of open source development. We're looking for people to give - Talks, Tutorials, Posters, Panels, Planning Sessions / BOFS Areas of interest include, but are not limited to: GNOME core: Latest developments on the GNOME desktop, core GNOME applications, related libraries, security, Mobility and Wireless Access etc. Free Software in the Information Society: Development of policies and cases related to Patents, Open Standards, Migration strategies and experiences (e.g. Office documents), Software in Public sector such as schools and hospitals, Information Society progress including developing countries. Graphics: Development and deployment of applications in particular: Multimedia, Games, Film, GIMP Freestyle: Interesting Free Software issues not covered in the other tracks and open for a less formal forms of presentation REFEREED PAPERS TRACK GUADEC seeks original papers describing research in all areas based on GNOME or related to Open Source. Papers should not have been published or be in submission at another conference or journal. Accepted papers will appear on the Web site and we plan to publish them in conference proceedings. For papers to appear in the proceedings, we need to be strict on the submission format. Format details available on the above web site. We encourage you to submit the 'source' for the paper as well (eg. HTML, LaTeX, DocBook, MagicPoint, etc). Any featured software in papers must be available under a licence compatible with the Open Source Definition (http://www.opensource.org/osd.html). Any papers that are accompanied by non-disclosure agreement forms will be rejected. All successful papers must be eligible for republication on-line and on distribution media given to conference attendees. The GNOME Foundation requires publication rights to accepted papers, including the publication of the audio proceedings as well as publication and reproduction rights to any video filmed during the presentations. These rights are non-exclusive. Copyright ownership is retained by the author. You may be asked to sign an agreement to these conditions upon arrival at the conference. PAPER SUBMISSION Authors of papers are invited to submit abstracts (150 - 400 words) in plain text, due February 16th 2004 Final papers (1500 - 4000 words) or maximum 5 pages, photo and biography, due May 15th 2004. Please send your submission to [EMAIL PROTECTED] See http://2004.guadec.org/ for further details and information on Posters, Panels, and Planning Sessions / BOFS Kristiansand is situated on the Norwegian south coast, offering a city beach and a vivid summer town life. The most visited attraction in Norway, the zoo (Dyreparken), is located nearby Kristiansand. Here the animals are kept in large outdoor space instead of cages. Perhaps we can even find some gnu's there. For those who prefer an excursion to a waterfall and Salmon River this can be also arranged. Other options include concerts, visit to islands, etc. General questions about GUADEC may be sent to [EMAIL PROTECTED] -- David Neary, E-Mail: [EMAIL PROTECTED] Tél: 04 72 33 95 35 Port: 06 03 98 39 80 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2 news ...
Hi all, Roman Joost wrote: > On Fri, Jan 09, 2004 at 10:06:50PM +0100, raymond ostertag wrote: > > What is the statut now ? Since christmas I only have a few html files > > with only "xinclude" in it. > > A new cvs update should bring you all the changes. I hope, that the > anonymous gnome cvs servers are now in sync with the other ones ... Just a quick note on CVS best practices. For fairly obvious reasons (disk crashes, accidental rms, etc) it is desirable to have as small a difference as possible between your local CVS copy and the repository. You should never really have any more than 1 or 2 outstanding things to commit locally. In general, if you have something you don't want to put into CVS (or can't), create a patch file, attach it to a bug report, and then revert the change locally bringing you back to the base state. Once the patch is stored centrally, you can always get it back later. If you're doing something which would get in the way of other people, then your choices are to develop it on a branch (doing regular merges from the head), or to set up a local repository for your development, again merging regularly from the main CVS. That way, you have your own stuff versioned too (preferably backed up off-disk). I hope these kinds of comments aren't out of place. I have noticed that commits to gimp-help-2 are fairly infrequent, and tend to affect lots of files. It is better all round if there are more frequent commits, each one making a distinct change. This also gives people an interest to do frequent cvs updates (which is essential if you want to get patches that apply without conflicts from people). Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] gimp-help-2 news ...
Daniel Egger wrote: > >It is better all round if there are > >more frequent commits, each one making a distinct change. > > IMHO your given rule of a thumb is not completely correct because the > granule of a commit should not be the smallest possible change in a > single file but the smallest possible changeset covering all files > needed to be touched for a logical step. This is what I meant above, although I can see how it might have been read differently. what I meant by "a distinct change" is precisely a changeset - something that has one paragraph in the ChangeLog, if you like. > Unfortunately with CVS that > requires a lot of discipline because it doesn't support the notion > of a changeset and creating and working with a branch is really > overkill in most cases. It kind of does - it's not changeset oriented in the way that BK or Arch are, but checking in several files at once is possible, and cvs2svn manages to make changesets out of commits that happen with the same comment, at the same time, by the same person for Subversion repositories. Anyway, the rule of thumb is "when you've finished a "thing", get it out of your local tree as quickly as possible (either by sending it to CVS or attaching it as a patch to a bug report). The "thing" could be a feature, a document, or a bug fix. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS Hanuary 16th, 2004 failed to build
Hi, Jean-Luc Coulon (f5ibh) wrote: > edit-commands.c:139: error: conflicting types for > `edit_paste_cmd_callback' > edit-commands.h:32: error: previous declaration of > `edit_paste_cmd_callback' It is possible that the anoncvs server you're using has an inconsistent repository. To verify this, could you run "cvs status edit-commands.[ch]" in app/gui? The revisions should be === File: edit-commands.c Status: Up-to-date Working revision:1.41 Repository revision: 1.41 /cvs/gnome/gimp/app/gui/edit-commands.c,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) === File: edit-commands.h Status: Up-to-date Working revision:1.4 Repository revision: 1.4 /cvs/gnome/gimp/app/gui/edit-commands.h,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) If you have another version of either of these files, you might have to wait until tomorrow to get back to a consistent state. As an alternative, try using anoncvs3.gnome.org rather than anoncvs.gnome.org for your CVS updates, as there is one known dodgy anoncvs mirror in the mix. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Alternative zoom algorithm
Hi, GSR / FR wrote: > I saw that zoom has been changed following bug 124073. After trying > it, I did not liked it. Personally I think it gives too much > importance to extreme zooms, forgeting most people work around > 100%. 4000 to 20 pix images in a reasonable size monitor is what I > normally see, not 4 pix or people with one pixel painted as > 128*128 screen pixels. I also did not liked that it quickly went to > fractional numbers in which one of X:Y is not 1, cos it does not look > very pleasing due the fast way Gimp interpolates when displaying. I like the idea of special-casing near-100% ratios (and so does Alan Horkan, from what I can tell from the bug he submitted recently). A LUT is a good way to go for them too, I think. There are some issues with the patch, though. I don't really get what's happenning in the if (src == 1 && dest == 1) clause, and I'm not sure completely reverting the old change is the way to go. Perhaps it might be an idea to have some smallish set of presets which are favoured as is suggested in bug 124073 - something from say 8:1 to 1:8, which would cover most common usages, but with zooming allowed outside that range, using the new continued fractions algorithm and a sqrt(2) zoom factor. > Help welcomed about how to make it work with typical optimization > level. Comments about the presets also welcomed, I just made a list of > the ones that seemed interesting while working always around some > given factor. I would go for 12.5% 18% 20% 25% 33% 50% 75% 100% 150% 200% 300% 400% 600% That gives you a smallish set of presets, with extra focus around 100%, and outside that you let her fly with the newer algorithm. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Path tutorials
Owen wrote: > On Sat, 24 Jan 2004 01:21:50 +0100 > Niklas Mattisson <[EMAIL PROTECTED]> wrote: > > > http://scizzo.gimp.org/gimp/Paths_Basics/ > > http://scizzo.gimp.org/gimp/Paths_Basics2/ > > I think they are excellent. maybe you should advise in > comp.graphics.apps.gimp also And perhaps Roman, Daniel or yourself could add them to the "official" docs? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] File Selection Creating Thumbnails hangs at 255 images
Hi Jeff, Jeff Trefftzs wrote: > From the magic number (255), this looks to me > like a bug in the thumbnail creation code -- possibly an artificial > limit that's getting exceeded without warning. > > Is this known, or should I hit bugzilla? It doesn't ring any bells, and I think it would... Bugzilla knows, in any case, and is the best place to look :) Could you add the bug, I don't think it's been reported yet? Thanks, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gegl query
Hi, Daniel Rogers wrote: > >Hopefully it won't be that long to a next stable release of gimp. It > >would be nice to see it in 2004 (albeit late 2004). > > I have been asked to point out that is is my opinion and noone has made > any specific plans. (From talking with other open source projects, 9-12 > month release cycles keep interest high). It's my opinion too. It's also the general plan that was discussed at the GIMP conference in Berlin. I'd personally like to aim for a 6 month stable release turnaround, similar to GNOME. At least for 2.2. Of course, this is just my opinion Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
[Gimp-developer] GIMP Update
Hi all, It's been a while since we've had anything like the status updates we had before Christmas, so here goes... We're in pre-release mode, as many of you might have noticed. gimp-2.0pre3 should be coming out this week, and will contain another 40 or so known bug fixes and lots of code clean-up we didn't know about to help 2.0 be even more stable than it would have been if we hadn't fixed the bugs. Of note are a number of fixes and features which have been added to the tiff plug-in in recent weeks, thanks to Andrej Kiselev, the libtiff maintainer. We've also had a modification in the behaviour of the zoom tool, as a result of a lively discussion between Simon Budig (of path tool fame) and Guillermo Romero. Mitch has, as usual, been doing great work. Among the changes he's made are to merge all shortcuts on image windows and docks together, so that the same shortcuts work regardless of whether the active window is the image window or another dock. He's also fixed a massive 17 of the 35 bug fixes since pre2 came out. Aside from that, there's lots of stuff happenning outside CVS too... the help team recently did a pre-release of the gimp-help-2 module, and it's looking very good. Roman, Daniel, Raymond, Niklas, Sven and everyone else who is working on the help right now are doing a great job. Sven and Wolfgang Hofer have also recently released a 2.0 snapshot of the GAP plug-in, which is lookign very nice indeed. At the moment, it has more or less all the functionality of the CinePaint frame editor, and then some. Recent additions like the bluebox plug-in and onionskin plug-in, as well as updates to the MovePath plug-in, have made this an excellent animation package. Dan Rogers is putting a lot of time into getting the GIMP Foundation up and running. This has been a tough job, which he has done more or less alone. We now need to start thinking about things like the eventual organisation fo the foundation, but having a foundation is a great step towards getting some funding for things like GUADEC. Dan and Calvin have also been talking quite a bit about how they see gegl moving forward to an eventual integration with the GIMP. There was a very lively thread on gegl-developers recently, which would be very interesting reading for all GIMP developers wondering about gegl. Unfortunately, the archives haven't yet caught up with the list, so those of you not subscribed to the list will have to wait a while. The commits have also accelerated recently in gegl - the bones of the image data structures is now present in CVS (much of it with dummy implementations, but the APIs are now available). Also, organisation plans for the GIMP conference are moving along nicely. It was decided to share the conference with GUADEC, which reduces the amount of organisation time to put in. Dan and I have started organising fundraising, and will soon be looking for more volunteers to get decent contacts for funding. The graphics thread of guadec is looking promising, and for those of you who are thinking of writing a paper, or making a presentation, the closing date for submissions is in 2 weeks time. So there we go... hoopefully a month from now, more or less, we will be celebrating the final release of the GIMP 2.0, and preparing for GUADEC/GIMPCon in June - start booking your flights soon, and see ye there! Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Reminder: GUADEC 2004 Call for Papers
Hi all, The closing date for submitting abstracts for papers to be presented at GUADEC is now only 2 weeks away. Anyone why is planning on giving a talk should send in an abstract (it doesn't have to be professional, just a short description of what you want to present) to [EMAIL PROTECTED] as soon as possible. I have attached the original call for papers, which contains a lot more information, below. Looking forward to hearing all your great ideas, Regards, Dave, on behalf of the GUADEC planning committee. GUADEC 2004 CALL FOR PAPERS The Fifth European Gnome Users and Developers Conference June 28-30, 2004, Kristiansand, Norway http://guadec.org/ Abstract submission deadline: February 16th, 2004 The European Gnome Users and Developers Conference (GUADEC) invite you to participate in the Fifth Conference on June 28-30, 2004, Kristiansand, Norway The GNOME User and Developer European Conference (GUADEC) will bring together developers, GNOME Foundation leaders and individual, business and government GNOME and open source software users. The conference is a unique forum for highlighting the capabilities and direction of GNOME, the user environment for desktops, networked servers and portable Internet devices. GUADEC will also feature discussions of the future direction of open source development. We're looking for people to give - Talks, Tutorials, Posters, Panels, Planning Sessions / BOFS Areas of interest include, but are not limited to: GNOME core: Latest developments on the GNOME desktop, core GNOME applications, related libraries, security, Mobility and Wireless Access etc. Free Software in the Information Society: Development of policies and cases related to Patents, Open Standards, Migration strategies and experiences (e.g. Office documents), Software in Public sector such as schools and hospitals, Information Society progress including developing countries. Graphics: Development and deployment of applications in particular: Multimedia, Games, Film, GIMP Freestyle: Interesting Free Software issues not covered in the other tracks and open for a less formal forms of presentation REFEREED PAPERS TRACK GUADEC seeks original papers describing research in all areas based on GNOME or related to Open Source. Papers should not have been published or be in submission at another conference or journal. Accepted papers will appear on the Web site and we plan to publish them in conference proceedings. For papers to appear in the proceedings, we need to be strict on the submission format. Format details available on the above web site. We encourage you to submit the 'source' for the paper as well (eg. HTML, LaTeX, DocBook, MagicPoint, etc). Any featured software in papers must be available under a licence compatible with the Open Source Definition (http://www.opensource.org/osd.html). Any papers that are accompanied by non-disclosure agreement forms will be rejected. All successful papers must be eligible for republication on-line and on distribution media given to conference attendees. The GNOME Foundation requires publication rights to accepted papers, including the publication of the audio proceedings as well as publication and reproduction rights to any video filmed during the presentations. These rights are non-exclusive. Copyright ownership is retained by the author. You may be asked to sign an agreement to these conditions upon arrival at the conference. PAPER SUBMISSION Authors of papers are invited to submit abstracts (150 - 400 words) in plain text, due February 16th 2004 Final papers (1500 - 4000 words) or maximum 5 pages, photo and biography, due May 15th 2004. Please send your submission to [EMAIL PROTECTED] See http://2004.guadec.org/ for further details and information on Posters, Panels, and Planning Sessions / BOFS Kristiansand is situated on the Norwegian south coast, offering a city beach and a vivid summer town life. The most visited attraction in Norway, the zoo (Dyreparken), is located nearby Kristiansand. Here the animals are kept in large outdoor space instead of cages. Perhaps we can even find some gnu's there. For those who prefer an excursion to a waterfall and Salmon River this can be also arranged. Other options include concerts, visit to islands, etc. General questions about GUADEC may be sent to [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi all, Some people thought it was ridiculous to fix dates on events when we had GIMPCon at the CCC in August - after all, we haven't done that in the past, and "it'll be done when it's done" is almost a motto for some people around. The thing is that we did make a roadmap, though - and we've deviated from it quite a bit. But I think that without it, we wouldn't have come as far as we have in so little time. We're now on the cusp of 2.0.0, and the time has come to put some realism back in the old roadmap. We expected 2.0 before Christmas, and it looks like we will have it in February. We need to start thinking about 2.2 (not just about what we will do for it, but what we will not do). I still think we should stick with a target of the end of June for 2.2.0 - this will be a short release cycle (4 months), but the goal of the 2.2 release has not changed - we should stabilise the codebase, adding some stuff which we would have liked to have in 2.0 (but not everything that we would have liked in 2.0), and work on building the community. That means that the 2.1 series will be always buildable, always usable, (almost) always releasable (following the example of the GNOME release team, my idols). This roadmap should not be seen as set in stone, but I agree with Freedman Dyson that it is better to be precise and wrong than to be vague. If we set ourselves vague targets, then we will arrive at them a long time after we'd like. So, without further ado, here's the updated roadmap... are there any comments? Cheers, Dave. Updated GIMP development Roadmap: = Aug 6-10 2003: CCC Jan 7th: 2.0 pre1 release Jan 19th: 2.0 pre2 Feb 4th: 2.0 pre3 *** WE ARE HERE *** Feb 18th: 2.0pre4 (or 2.0 rc1) Feb 25th: 2.0.0 March 10th: 2.0.1, creation of gimp-2-0 branch March 13th: Final feature list for inclusion in 2.2.0 (prioritised) March 25th: 2.0.2 (possibly final 2.0 release) April 2nd: 2.1.0 April 16th: 2.1.1 End of April: 2.1.2, Feature freeze for 2.2 (anything on the above list that's not done isn't in 2.2) Around May 15th: 2.2 pre1 (2.1.3) Pre-releases to follow every 2 weeks. Late June 2004: 2.2.0 (just before GIMPCon) August 2004: The Great Pain - the GeGL migration. I suspect that parts of this will start in February/March, and that this will not be complete until Summer 05. Summer 05: 3.0 or 4.0 (depending on how we go about versioning). -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 2.0 pre3
Hi all, The latest pre-release of the upcoming 2.0 GIMP is hot off the presses and available for download now at ftp://ftp.gimp.org/pub/gimp/v2.0/testing/ or from one of the mirrors listed at http://gimp.org/download.html Screenshots of some of the features available in the shiny new GIMP are at http://developer.gimp.org/screenshots.html We fixed a bunch of bugs, and we have another bunch to fix, and we're sure we haven't found them all yet. If you find any for us, please report them to http://bugzilla.gnome.org, against the GIMP product. We really do appreciate it. A special mention goes out to the GIMP Animation Package from Wolfgang Hofer, available here ftp://ftp.gimp.org/pub/gimp/plug-ins/v2.0/gap/testing/ The plug-in has recently had a 2.0 pre-release of its own. This plug-in is the best thing sinced sliced cheese. Screenshots are available (in French) at http://gimp-fr.org/html/mongimpfr/gap/gap2.html Happy GIMPing, Dave. Bugs fixed in GIMP 2.0pre3 == - 127451: Anchor floating selection when creating a text layer (Mitch) - 50649: Allow to call script-fu scripts from plug-ins (Mitch) - 132617: Improved gimp-remote behaviour (Sven) - 132036: Fixed issues with libart scan conversion (Simon) - 132041: Made info window not grab the focus (Mitch) - 132077: Redraw layer boundary when using transform tools (Mitch) - 132089: Flip tool misbehaviours (Mitch) - 132032: User interface issues with Plugin Details (David Odin) - 132145: Use default values when stroking from the PDB (Mitch) - 132162: Anchoring a floating selection on a channel (Mitch) - 132271: Mosaic filter on selections (Simon) - 132322: gimp-levels on grayscale images (Mitch) - 132329: Info window doesn't show inital values (Shlomi Fish) - 118084: Info window not updated in automatic mode (Shlomi Fish) - 132495: Positioning of glyphs that extend the logical rectangle (Sven) - 108659: Use g_spawn in postscript plug-in (Peter Kirchgessner) - 132508: Problems with path tool in Edit mode (Simon) - 132504: Fixed unsharp mask script (Mitch) - 132595: Don't draw the selection if it's hidden (Sven) - 132027: Crash in gimpressionist (Sven) - 132596: Use default values for color DND (Mitch) - 132493: Tuned Comic Logo script (Pedro Gimeno) - 132649: Allow to fill the whole selection using bucket-fill (Mitch) - 131902: Improved handling of missing tags in TIFF loader (Andrey Kiselev) - 93806: Validate script-fu input (Yosh) - 132214: Differentiate writable and readonly data directories (Mitch) - 131964: Zoom ratio problem (Simon) - 132969: Set help-id for tool on tool options dock (Mitch) - 132999: Make assembler code PIC safe (Yosh) - 119878: Use the same keyboard shortcuts in all GIMP windows (except the toolbox window) (Mitch) - 131975 & - 132297: Disable some warnings while loading TIFFs (Raphael) - 129529: Add a "randomize" toggle to random number widget (Dave Neary) - 133099: Duplicate PDB entries problem (Mitch) - 133122: Disallow renaming of layer masks and some floating selections (Mitch) - 130118: Allow non-UTF8 characters in the GIMP home directory (Mitch) - 122026: Workaround a bug in gdk_draw_segments() (David Odin) - 133280: Remove deleted scripts from the menu (Mitch) - 133270: Replace deprecated enum values in scripts (Kevin Cozens) - 133180: Sort menu entries for save and load procedures (Mitch) - 131563: Use percentages for zoom ratios (Simon, Sven) Other contributions: Manish Singh, Tor Lillqvist, Jakub Steiner, Michael Natterer, Sven Neumann, Kevin Cozens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Updated roadmap (so people don't laugh at the old one)
Hi, First, I'd like to say that I think it's a pity that you replied so aggressively to the mail - I would have liked to hear more comments, but I think that the tone of the thread may have intimidated people somewhat. Sven Neumann wrote: > We all know that but your roadmap gave a different impression. Instead > of pointing out what we want to achieve you gave a list of dates. Since > we will not match a single one of these dates, it doesn't make sense to > publish such a list. I am convinced that if we make releases conditional on a feature set that we will not have a 2.2 in 2004. If we're not making our major releases based on a feature set, then the only alternative is to make releases time-based. This has worked for other projects, I think it can work for ours. > Doing the release tarball takes about half an hour. What takes time is > to test it, to upload the tarball, put it on the FTP site, add a > bugzilla version, change www.gimp.org to point to the new release, > announce the release on freshmeat, gnomedesktop.org, linuxartist.org > ... You can hardly cut down much of this. You can certainly spread it around. I update the NEWS now, as well as you. Anyone can do that. Same thing goes for making the announcement on freshmeat, gnome-desktop, linuxartist... I can do bugzilla tags. Anything which requires specialist knowledge (make distcheck, as you have pointed out, requires a finely balanced set of versions for a bunch of stuff, and there are very few people who understand the website system) or permissions (uploading the tarball) is another matter, but it doesn't make sense in general to have only one person able to do these things. The thing which takes the longest for *me* is make distcheck. > But I don't see what you are trying to argument about here. We agreed > that we will do regular releases, we are already doing releases every > two or three weeks. The point is just that I don't want to have a list > that tells me that a release is pending next sunday. I got the point; so I'll repeat mine, and then we can stop. We're more or less agreed that to have 2.2 by the end of June, we need to 1) have 2.0 this month 2) Branch a stable development branch next month 3) Feature freeze at the start of April 4) start pre-releases in the middle of April 5) Release 2.2 the end of June. I don't think there's any argument there. All I did was throw in a release every couple of weeks between those 5 points. I think it's helpful to show how little time there will be in this development cycle. > Some real content in the roadmap instead of meaning-less dates would > be helpful. At perhaps make it a proposal for a roadmap next time. This comment got me angry. I've calmed down now. Everything I post to this list that isn't meant to be a fact is an opinion, and a request for comments. If I say "March 17th is St. Patrick's Day", that's a fact. If I say "I think we should have 2.2.0 at the end of June, and I think this is more or less how to get there", that's opinion. See the difference? I asked for comments. I even got a couple of positive ones, in e-mails off-list. How much more proposally would you like it to be? Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
