Re: [Gimp-developer] Joining the GNOME Foundation
Hi, Nathan Carl Summers wrote: On Sat, 1 May 2004, David Neary wrote: Are there any people opposed to closer ties with the GNOME Foundation? I don't see any reason why we can't do both: work closely with the GNOME Foundation now, while the GIMP Foundation is getting off the ground, and then continuing to work with them to some extent once the GIMP Foundation is a reality. There is only one - a coprporation in California (the state that the GIMP Foundation is incorporated in) has a minimum income tax charge of $80year, even if you don't do anything. So while we're not doing anything with the GIMP Foundation, someone's out of pocket for that. Of course, we might decide that's something we're prepared to do, and chip in once a year to get the $800 among ourselves, or solicit funds for that. But it's a consideration which means that it's hard to do nothing with a GIMP Foundation (in addition, a foundation that's doing nothing will not easily get non-profit status). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Donation for GIMP features
Hi Sven, IMHO, the plugins could be left un-bound to any window as they are atm. Or is there a hard coded underlying attachment between the plugin and parent windows required for it all to work? Are you saying that plug-in dialogs should be handled differently than core dialogs? If we want to implement WiW, then plug-in dialogs need IMO be embedded into the container windows just like any other GIMP dialog. I wouldn't mind either way. If it was less trouble to leave them not embedded into the container windows I would not complain. Photoshop does not presently have plugins within the main window I believe. If it was just as easy to have them embedded within the normal window that would be great too. Kind regards JG ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
On 3 May 2004, Sven Neumann wrote: > Hi, > > Dave Neary <[EMAIL PROTECTED]> writes: > > Well, dgo was started to finally give an alternative to this outdated > sourceforge site, so please consider to help with dgo instead. It's in > CVS, you have write access, feel free to improve it. Do you have to run any weird scripts after you make changes, like you did with the old wgo? CCed to the list in the intrest of making the answer public knowledge. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation)
On 3 May 2004, Sven Neumann wrote: > PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost > HIG compliant file-new dialog. This is a screenshot from the HEAD > branch. Looks fantastic! I really like the "hideaway" Image Comment section. Here are just a few minor suggestions that I think would improve the dialog: * The "extra title bar" seems to take up a lot more space than it needs. * Center "Create a New Image" vertically (perhaps horizontally as well) * Put the size in bytes either flushed right to or directly under the "Image Size" label. Flushed right will probably look better. * Move the portrait/landscape controls to the right of the template dropdown. Grey them out when no template is selected. * Merge the two Width and Height entries, or make the second one hideaway. If you make the second one hideaway, make the top one have a dropdown units menu, so that you don't have to use the hideaway to specify image size in units other than pixel. * Consider making Resolution hideaway as well. * Resolution should have its own outdent, just like Image Size does. * The units dropdowns should be centered vertically between the two entry boxes to which they apply. (It would be better if they were aligned horizontally as well, but the presence of the link control in the resolution area makes that impractical.) * Consider putting a GtkVSeparator between the "Image Type" and "Fill Type" combo box lists. These are pretty easy to do; I would make the changes myself except that the universe seems to be conspiring against me ever having a machine that I can follow gimp-development work with. Poor Rockwalrus. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
Hi Nathan, Nathan Carl Summers wrote: > On 3 May 2004, Sven Neumann wrote: > > Well, dgo was started to finally give an alternative to this outdated > > sourceforge site, so please consider to help with dgo instead. It's in > > CVS, you have write access, feel free to improve it. > > Do you have to run any weird scripts after you make changes, like you did > with the old wgo? CCed to the list in the intrest of making the answer > public knowledge. You don't *have* to run any scripts with the new wgo, by the way (although you probably should as a sanity check), the rebuild is done as a check-in hook. The same thing is true of the dgo site, but it helps to have a docbook XML set-up working, since this allows you to check for mistakes before committing. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
On 3 May 2004, Sven Neumann wrote: > Hi, > > here's another summary of what's happening in the HEAD branch, what do > watch out for if you want to join development and where help is > needed... > > > Mitch has almost finished the port of the menus to GtkUIManager. The > new code is in use now and seems to work fine. The only remaining > regression is integration with the help system (pressing F1 on a menu > item should call the relevant help pages). This is being worked on and > will soon be reenabled. Is the ocassionally-suggested right-click-menu for menu items easily implementable with GtkAction? > I started to change our dialogs to be more compliant with the GNOME > HIG. To ease this effort, I've added a new widget called GimpFrame. > This is a variant of GtkFrame that doesn't draw a frame but instead > sets a bold title and indents the content of the "frame" as suggested > by the HIG. I've changed some core dialogs already and I think the > results look very pleasant. > > What remains to be done here is changing all plug-in dialogs. I don't > plan to do this myself so it would be nice to get some volunteers for > this task. > > It's important that we try to create a consistent dialog layout so > this job should be well coordinated or done by a single person. Any > volunteers for this? While I don't volunteer to be this coordinator, I have created a Bugzilla entry to help with that process: http://bugzilla.gnome.org/show_bug.cgi?id=141772 This seems like an excellent opportunity to get new volunteer developers' feet wet. We could have a news item blurb about it on wgo that links to a page on dgo with the proper steps: 1. Identify plug-ins with forbidden dialogs. 2. File a bug-report on bugzilla for each bug, making it block #141772. (there should be a mini-tutorial on how to file the bug and make it block #141772) 3. Identify the offending plug-in dialog code, and fix it. (Mini-tutorial here as well) 4. Attach patch to bug report, add keyword PATCH. 5. Bask in glory. > What I didn't address yet is the fact that the HIG suggests to > left-align labels of UI controls while we currently consistenly > right-align labels so that they are close to the control they are > describing. I am not sure if I can follow the HIG argumentation for > this. I guess we should create some screenshots or mockups of standard > GIMP dialogs and discuss this change here before we start to work on > this. It seems like the HIG suggests left-alignment for controls whose labels are roughly equal in length, and right-alignment for dissimilarly-sized labels. While this probably does result in the most pleasant appearance, it's an internationalization nightmare. I suggest we stick with the Palm usability guidelines here. I suggest that the next version of the HIG do the same. And while we're talking about the HIG, I still wonder what they were smoking when they suggested that Gnome lay out all of its buttons opposite to the way that common sense and every other set of UI guidelines I've ever read suggests. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Screenshots
Hi all, I was just looking for some nice looking screenshots to show off on the GUADEC GIMP pages, and the best ones are all on developer.gimp.org It would be really cool to have lots & lots of screenshots of the GIMP on www.gimp.org. Could someone from the web team take responsibility for this and publish an e-mail address where screenshots can be sent to be included on the site, please? In the meantime, I will link to screenshots on dgo. The current content to go on guadec (which will also probably end up on dgo when the dust settles) is here (as usual, all corrections & comments are welcome, that's what wikis are for): http://wiki.gimp.org/gimp/GimpCon2004 Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Menu Reorganization
On Sun, 2 May 2004, David Neary wrote: > Sven Neumann wrote: > > Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > > http://wiki.gimp.org/gimp/GimpMenuReorganization > > > > Very nice. I wonder if there's a way to convert between the menu XML > > files and the Wiki content. That would make it possible to easily try > > the suggested menu layout. > > The forward direction (menu XML to wiki text) should be trivial > with xslt - the other way would probably be easier with perl or > something. That's funny, I think of wiki -> menu as being the forward direction. :) Turning wiki into XML looks like it should be trivial with Perl. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation)
[EMAIL PROTECTED] accidentally forgot to cc the mailing list. Forwarded with his permission. Date: Mon, 3 May 2004 16:53:32 -0500 From: Seth Burgess <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Nathan Carl Summers <[EMAIL PROTECTED]> Subject: Re: [Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation) Also, from the HIG: Right-justify the contents of spin boxes, unless the convention in the user's locale demands otherwise. This is useful in windows where the user might want to compare two numerical values in the same column of controls. In this case, ensure the right edges of the relevant controls are also aligned. Its just my opinion, but I think showing 3 places of precision past the decimal for resolution is a bit excessive and I would hazard rarely adds any useful information. The alignment of 'Y' seems different than that of 'X' in 'Resolution X.' Maybe just an odd font rendering, but it looks to me like Resolution X has an extra space between X and ':". I disagree on the vertical separator - I think the absense of such noise is welcome in the dialog, and its pretty clear without it due to the bolded headings. Seth On Mon, 3 May 2004 13:40:03 -0700 (PDT), Nathan Carl Summers <[EMAIL PROTECTED]> wrote: > > On 3 May 2004, Sven Neumann wrote: > > > PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost > > HIG compliant file-new dialog. This is a screenshot from the HEAD > > branch. > > Looks fantastic! I really like the "hideaway" Image Comment section. > > Here are just a few minor suggestions that I think would improve the > dialog: > > * The "extra title bar" seems to take up a lot more space than it needs. > * Center "Create a New Image" vertically (perhaps horizontally as well) > * Put the size in bytes either flushed right to or directly under the >"Image Size" label. Flushed right will probably look better. > * Move the portrait/landscape controls to the right of the template >dropdown. Grey them out when no template is selected. > * Merge the two Width and Height entries, or make the second one >hideaway. If you make the second one hideaway, make the top one have a >dropdown units menu, so that you don't have to use the hideaway to >specify image size in units other than pixel. > * Consider making Resolution hideaway as well. > * Resolution should have its own outdent, just like Image Size does. > * The units dropdowns should be centered vertically between the two entry >boxes to which they apply. (It would be better if they were aligned >horizontally as well, but the presence of the link control in the >resolution area makes that impractical.) > * Consider putting a GtkVSeparator between the "Image Type" and "Fill > Type" combo box lists. > > These are pretty easy to do; I would make the changes myself except that > the universe seems to be conspiring against me ever having a machine that > I can follow gimp-development work with. Poor Rockwalrus. > > Rockwalrus > > ___ > Gimp-developer mailing list > [EMAIL PROTECTED] > http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer > ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new file-new dialog (Was: Joining the GNOME Foundation)
On Mon, 3 May 2004, Seth Burgess wrote: > Also, from the HIG: > > Its just my opinion, but I think showing 3 places of precision past > the decimal for resolution is a bit excessive and I would hazard > rarely adds any useful information. Good point. > I disagree on the vertical separator - I think the absense of such > noise is welcome in the dialog, and its pretty clear without it due to > the bolded headings. Asthetics is such a fickle thing. :) I suggest the separator for two reasons: 1) It's not so clear to my eye that the two lists aren't related in some way. but more for: 2) It distracts from the fact that the two lists are asymetrical. I think that if Resolution is outdented, that will be somewhat less of an issue. Also, a separator was what was clearly suggested in earlier drafts of the HIG for this exact kind of case, although that language seems to have been watered down to something to the effect of add a separator if you need one in the current version. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
On Sat, 1 May 2004, David Neary wrote: > Hi all, > > Myself and Dan Rogers will be meeting with someone from the GNOME > Foundation this week with the intention of having greater > co-operation with them on things like money. > > For the moment, I am working under the supposition that the best > option available to us is to join the GNOME Foundation. > > The alternative is that Dan continue with the work involved in > creating an independent GIMP Foundation. > > The short term effects of doing this would be that we wouldn't > have any way to accept tax-deductible donations in the US for > this year, and it is unlikely (given Dan's current availability) > that the foundation would have cleared up all paperwork issues > and elected a board before the end of the year. > > On the other hand, a partnership with the GNOME Foundation would > give us federal tax exempt status in the US now. We could probably > work out an arrangement where contributions made to the GIMP get > used for GIMP events. > > Are there any people opposed to closer ties with the GNOME > Foundation? I don't see any reason why we can't do both: work closely with the GNOME Foundation now, while the GIMP Foundation is getting off the ground, and then continuing to work with them to some extent once the GIMP Foundation is a reality. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Menu Reorganization
Hi, Nathan Carl Summers wrote: > > The forward direction (menu XML to wiki text) should be trivial > > with xslt - the other way would probably be easier with perl or > > something. > > That's funny, I think of wiki -> menu as being the forward direction. :) Weird. Perhaps you're sufferring an LSD flashback? > Turning wiki into XML looks like it should be trivial with Perl. I think there may even be a whatchummacall that does it already. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new file-new dialog (Was: Joining the GNOME Foundation)
Hi, Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost > > HIG compliant file-new dialog. This is a screenshot from the HEAD > > branch. > > Looks fantastic! I really like the "hideaway" Image Comment section. > > Here are just a few minor suggestions that I think would improve the > dialog: > > * The "extra title bar" seems to take up a lot more space than it needs. This dialog is a GimpTemplateEditor packed into a GimpViewableDialog. It's GimpViewableDialog that creates the title and the extra space is in other GimpViewableDialogs used to display the name of the viewable (which could for example be an image or a layer). We could of course change GimpViewableDialog to show a smaller title when no name is set but I think consistency makes more sense here. Not sure though, what do others think? > * Center "Create a New Image" vertically (perhaps horizontally as well) This also needs to be reviewed with respect to other dialogs using the same viewable-dialog widget. > * Put the size in bytes either flushed right to or directly under the >"Image Size" label. Flushed right will probably look better. I am afraid the HIG disagrees with this. But perhaps it needs to be seen on a mockup. I think the memory size is rather well placed, but let's see how this would look like. > * Move the portrait/landscape controls to the right of the template >dropdown. Grey them out when no template is selected. But they also make sense when no template is selected and allow you to easily flip width and height. Why bind them to the template selection? > * Merge the two Width and Height entries, or make the second one >hideaway. If you make the second one hideaway, make the top one have a >dropdown units menu, so that you don't have to use the hideaway to >specify image size in units other than pixel. > * Consider making Resolution hideaway as well. > * Resolution should have its own outdent, just like Image Size does. IMHO resolution and the second size group belong together. I could imagine having "Pixel Size" at the top and "Print Size" below. The "Print Size" group would contain size and resolution. > * The units dropdowns should be centered vertically between the two entry >boxes to which they apply. (It would be better if they were aligned >horizontally as well, but the presence of the link control in the >resolution area makes that impractical.) /me shudders > * Consider putting a GtkVSeparator between the "Image Type" and "Fill > Type" combo box lists. The idea was to make the dialog HIG compliant. The HIG clearly suggests not to use any separators and I agree that spacing is a better choice since it adds less visual noise. I like the idea of making more use of GtkExpander in our dialogs. As you suggested, we could hide more controls in this dialog (and others). However for this to be really convenient, the dialog would have to remember the expanded/collapsed state of the frames. Everything expect the most important settings could be collapsed by default. That would make GIMP much more accessible to newbies. The default state of the dialog could even be dependant on a level of user expertise that can be choosen. GIMP for newbies would by default only show the simple things while GIMP for experts would always come up with the full dialog expanded. While the user explores the GIMP world, she can expand more of the dialogs. Whenever a frame is left expanded, GIMP should remember that and the dialog come up like this the next time. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: new file-new dialog (Was: Joining the GNOME Foundation)
On 4 May 2004, Sven Neumann wrote: > Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > > > PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost > > > HIG compliant file-new dialog. This is a screenshot from the HEAD > > > branch. > > > > Looks fantastic! I really like the "hideaway" Image Comment section. > > > > Here are just a few minor suggestions that I think would improve the > > dialog: > > > > * The "extra title bar" seems to take up a lot more space than it needs. > > This dialog is a GimpTemplateEditor packed into a GimpViewableDialog. > It's GimpViewableDialog that creates the title and the extra space is > in other GimpViewableDialogs used to display the name of the viewable > (which could for example be an image or a layer). We could of course > change GimpViewableDialog to show a smaller title when no name is set > but I think consistency makes more sense here. Not sure though, what > do others think? It looks seems a little awkward the way it currently is here. There are probably several ways to make it look nicer. Maybe one of the graphic artists could give more productive suggestions. > > * Center "Create a New Image" vertically (perhaps horizontally as well) > > This also needs to be reviewed with respect to other dialogs using the > same viewable-dialog widget. See my comment above about graphic artists. > > * Put the size in bytes either flushed right to or directly under the > >"Image Size" label. Flushed right will probably look better. > > I am afraid the HIG disagrees with this. But perhaps it needs to be > seen on a mockup. I think the memory size is rather well placed, but > let's see how this would look like. My concern is that currently the image size is visually associated most closely with the portrait/landscape control. Perhaps the best solution is to have a "Memory Required" outdent at either the top or the bottom, and have the size after that. > > * Move the portrait/landscape controls to the right of the template > >dropdown. Grey them out when no template is selected. > > But they also make sense when no template is selected and allow you to > easily flip width and height. Why bind them to the template selection? I thought that they didn't work without templates, but it turns out that I just tested them on a square image. :) OK, they are useful for non-templated images, so instead, I suggest that we keep them where they are, and grey them out if the image is square. > > * Merge the two Width and Height entries, or make the second one > >hideaway. If you make the second one hideaway, make the top one have a > >dropdown units menu, so that you don't have to use the hideaway to > >specify image size in units other than pixel. > > * Consider making Resolution hideaway as well. > > * Resolution should have its own outdent, just like Image Size does. > > IMHO resolution and the second size group belong together. I could > imagine having "Pixel Size" at the top and "Print Size" below. The > "Print Size" group would contain size and resolution. This makes a whole lot of sense. Make "print size" and "print resolution" be one hideaway group. > > * The units dropdowns should be centered vertically between the two entry > >boxes to which they apply. (It would be better if they were aligned > >horizontally as well, but the presence of the link control in the > >resolution area makes that impractical.) > > /me shudders OK, so alignment isn't plausable, but the units still should be centered between the width (or x) and height (or y) entry boxes so that it is more clear that it applies to both of them. > > * Consider putting a GtkVSeparator between the "Image Type" and "Fill > > Type" combo box lists. > > The idea was to make the dialog HIG compliant. The HIG clearly > suggests not to use any separators and I agree that spacing is a > better choice since it adds less visual noise. The HIG guidelines suggest that "[b]efore you add a frame with a visible border or separator to any window, consider carefully if you really need it. It is usually better to do without, if the groups can be separated by space alone. Do not use frames and separators to compensate for poor control layout or alignnment." It's not an ironclad prohibition. (http://developer.gnome.org/projects/gup/hig/1.0/controls.html#controls-frames) I refer to my reply to sjburges for my rationale in this suggestion, but I'll point out here that it's not because of poor control layout or alignment. I'll also say that I can't think of any way to re-arrainge the controls that would be better. > I like the idea of making more use of GtkExpander in our dialogs. As > you suggested, we could hide more controls in this dialog (and > others). However for this to be really convenient, the dialog would > have to remember the expanded/collapsed state of the frames. Agreed. Is the session-state stuff we have now a good candidate? > Everything expect th
Re: [Gimp-developer] status report from the development branch
Hi, Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > What I didn't address yet is the fact that the HIG suggests to > > left-align labels of UI controls while we currently consistenly > > right-align labels so that they are close to the control they are > > describing. I am not sure if I can follow the HIG argumentation for > > this. I guess we should create some screenshots or mockups of standard > > GIMP dialogs and discuss this change here before we start to work on > > this. > > It seems like the HIG suggests left-alignment for controls whose labels > are roughly equal in length, and right-alignment for dissimilarly-sized > labels. While this probably does result in the most pleasant appearance, > it's an internationalization nightmare. I suggest we stick with the Palm > usability guidelines here. I suggest that the next version of the HIG do > the same. Since we use a whole lot of those labels that say something like "Scale X:" and below "Y:" I think we should generally stick to the right-aligned labels that we use now. What does the HIG say about the colons? Are they needed? Due to kerning the "Y" tends to crawl under the trailing colon so I'd rather get rid of the column and increase the spacing from the currently used 4 pixels to 6 pixels. > And while we're talking about the HIG, I still wonder what they were > smoking when they suggested that Gnome lay out all of its buttons > opposite to the way that common sense and every other set of UI > guidelines I've ever read suggests. If you are refering to the button order in the action area, I have to say that I am very happy about this decision. Mac OS uses this button order and I always found it to be more logical than the Windows way of arranging the buttons. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] new file-new dialog (Was: Joining the GNOME Foundation)
Hi, Nathan Carl Summers <[EMAIL PROTECTED]> writes: > Right-justify the contents of spin boxes, unless the convention in > the user's locale demands otherwise. AFAIK GTK+ doesn't provide an API for this. > Its just my opinion, but I think showing 3 places of precision past > the decimal for resolution is a bit excessive and I would hazard > rarely adds any useful information. The number of decimal points shown in a GimpSizeEntry is dermined from the unit and the entry's range. It is choosen in a way that allows to enter a number with at least the possible precision. You could play with the Gimp Unit Editor, perhaps the number of digits should be changed for the inch unit (and perhaps others). That would automatically reduce the number of digits after the decimal separator shown here. > The alignment of 'Y' seems different than that of 'X' in 'Resolution > X.' Maybe just an odd font rendering, but it looks to me like > Resolution X has an extra space between X and ':". That's due to kerning. As I said in another mail, this could be solved by removing the colon. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Screenshots
Hi, David Neary <[EMAIL PROTECTED]> writes: > I was just looking for some nice looking screenshots to show off > on the GUADEC GIMP pages, and the best ones are all on > developer.gimp.org The problem with the screenshots on dgo is that they are screenshots of the 1.3.x development version. Most of them clearly don't look like 2.0. It shouldn't be too difficult to redo these shots with an uptodate version. I am sure people will happily donate their screenshots. > It would be really cool to have lots & lots of screenshots of the > GIMP on www.gimp.org. Could someone from the web team take > responsibility for this and publish an e-mail address where > screenshots can be sent to be included on the site, please? > > In the meantime, I will link to screenshots on dgo. I'd like to remove the dgo screenshots sooner or later and replace them with screenshots of the CVS version. But of course I'll leave them online until more screenshots are available from www.gimp.org. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
On 4 May 2004, Sven Neumann wrote: > Hi, > > Nathan Carl Summers <[EMAIL PROTECTED]> writes: > > > > What I didn't address yet is the fact that the HIG suggests to > > > left-align labels of UI controls while we currently consistenly > > > right-align labels so that they are close to the control they are > > > describing. I am not sure if I can follow the HIG argumentation for > > > this. I guess we should create some screenshots or mockups of standard > > > GIMP dialogs and discuss this change here before we start to work on > > > this. > > > > It seems like the HIG suggests left-alignment for controls whose labels > > are roughly equal in length, and right-alignment for dissimilarly-sized > > labels. While this probably does result in the most pleasant appearance, > > it's an internationalization nightmare. I suggest we stick with the Palm > > usability guidelines here. I suggest that the next version of the HIG do > > the same. > > Since we use a whole lot of those labels that say something like > "Scale X:" and below "Y:" I think we should generally stick to the > right-aligned labels that we use now. What does the HIG say about the > colons? Are they needed? Due to kerning the "Y" tends to crawl under > the trailing colon so I'd rather get rid of the column and increase > the spacing from the currently used 4 pixels to 6 pixels. Colons are definitely required; the HIG states that they help screen readers identify which component is being labeled. On the other hand, labeling the two components "X Scale:" and "Y Scale:" seems to conform better to the independent-labelling guideline while also conveniently working around the kerning problem. (For those unfamiliar with the independent-labeling guideline, the HIG suggests that the entire meaning of a control be contained in the label, because those with screen-readers cannot tell that (in this case) the "Scale X:" and "Y:" labels are arrainged analogously, and that both refer to the scaling parameters.) > > And while we're talking about the HIG, I still wonder what they were > > smoking when they suggested that Gnome lay out all of its buttons > > opposite to the way that common sense and every other set of UI > > guidelines I've ever read suggests. > > If you are refering to the button order in the action area, I have to > say that I am very happy about this decision. Mac OS uses this button > order and I always found it to be more logical than the Windows way of > arranging the buttons. It seems to me that it makes sense to order the buttons so that when they are scanned in normal reading order, the most likely button press is the one that is read first. If you know you want to "Launch Spaceship", why should you have to skip over "Help", "Surrender Game", and "Cancel Launch" first? I know that you can train yourself to scan the buttons backwards, but this is inherently less efficient, unless you learn to llew sa sdrawkcab dear. I didn't know that the Apple said something different. I'll have to read their guidelines again. They probably have some good rationale. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
On 3 May 2004, Sven Neumann wrote: > Hi, > > Dave Neary <[EMAIL PROTECTED]> writes: > > > > There are only a very small number of people who really believe this > > to be still the case. It may still be called the GIMP Toolkit (but > > more & more I've heard it called the GNOME Toolkit), but that is a > > historical nod. > > I disagree. Every time we port GIMP to new features of the GIMP > toolkit I get the strong impression that we are the first using the > new API. There's certainly a lot of interaction between GIMP and GTK+, > way more than between GIMP and the gimp-print project. It should be pointed out that Sven is our main point of contact between GTK and GIMP, so I'm sure he's much more aware of the continuing interaction between the two projects. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Hi, Michael Schumacher <[EMAIL PROTECTED]> writes: > Thne fears that I - as a Win32 user - have are that by moving closer > to GNOME, GIMP might become too linux-centric. If those fears are > unjustified, I'd be glad to presented the facts that render them > invalid. No facts, but since GIMP works nicely on Win32 and we don't want to change that, you can rest assured that we will not do any changes that would cause a regression on Win32. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Daniel Rogers wrote: David Neary wrote: Are there any people opposed to closer ties with the GNOME Foundation? Well, GIMP is not part of GNOME, and this assertion was made repeatedly over the years. Apart from labeling GIMP more of a GNOME program, I wouldn't oppose (but I don't count much anyway :) I know, We could even change the name of the GIMP to the GINPOG it's been repeated so much. But this is a bunch of people with really close ties to the gimp (we use their toolkit and infrastructure, a few years ago they used to use our toolkit), who really want to help us both short term and long term. See the problem I see with the GINPOG attitude and joining GNOME is that we are saying we are willing to take your money and your time and your developers, but we are not willing to actually show any support for you in any way. Thne fears that I - as a Win32 user - have are that by moving closer to GNOME, GIMP might become too linux-centric. If those fears are unjustified, I'd be glad to presented the facts that render them invalid. HTH, Michael -- The GIMP > http://www.gimp.org| IRC: irc://irc.gimp.org/gimp Sodipodi > http://sodipodi.sf.net | IRC: irc://irc.gimp.org/sodipodi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Sven Neumann wrote: It's not that we wouldn't put a lot of effort into making GIMP work well on a GNOME desktop. Adhering to FreeDesktop standards is one of our goals and we are even working towards full GNOME HIG compliance. The only things we really want to avoid is to be forced to do any of this. Above all, everyone should know you are a volunteer. And as long as you are a volunteer, noone can tell you to do anything. If they every forget this fact, you can always politely remind them (or no-so-politely tell them to sod off). And really, the above is kinda the reason I think this is a good plan. We are already moving in the direction they would want us to, thus it is quite easy to join them. Since we aren't a GNOME application, noone can force us into anything and that's a good thing. GNOME still can't force any volunteer to do anything. The worst damage they could do is, "do this or we we will withold some funding" but even then, you are no better off then you are now. -- Dan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2 plugin porting problems
Hi, Stephan Menzel <[EMAIL PROTECTED]> writes: > gimptool caused problems during configure and I tried several > workarounds that seemed to work in the first place but this was some > kind of wishful thinking. > > > I did not have time to look at the patch at sourceforge, but it seems like > > Stephan is linking with the old version of the libgimp libraries. The > > obvious solution is to simply use the outputs from gimptool-2 instead of my > > hacked version. I am afraid that I don't have the time right now to suggest > > a good solution (anyhow I don't have Gimp-2 installed, so I can't test any > > modifications). The best thing is not to use gimptool at all but to use pkg-config. For a plug-in that has a user interface, you'd use this: pkg-config --cflags gimpui-2.0 pkg-config --libs gimpui-2.0 For a plug-in that just needs libgimp, the following should work: pkg-config --cflags gimp-2.0 pkg-config --libs gimp-2.0 If you want to use libgimpthumb, you can use this: pkg-config --cflags gimpui-2.0 gimpthumb-2.0 pkg-config --libs gimpui-2.0 gimpthumb-2.0 You should get the idea. If not, have a look at the pkg-config man-page. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2 plugin porting problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 03 May 2004 17:02, Ernst Lippe wrote: > I think that I have found cause of the Stephan's problem. > My plugin used GTK-2, so in the makefiles I had to use some > tricks to get the correct include path and libraries. I could > not directly use the output of the old gimptool, because that used > the wrong GTK versions. Hello Ernst! yes, that seems right. gimptool caused problems during configure and I tried several workarounds that seemed to work in the first place but this was some kind of wishful thinking. > I did not have time to look at the patch at sourceforge, but it seems like > Stephan is linking with the old version of the libgimp libraries. The > obvious solution is to simply use the outputs from gimptool-2 instead of my > hacked version. I am afraid that I don't have the time right now to suggest > a good solution (anyhow I don't have Gimp-2 installed, so I can't test any > modifications). I just checked with ldd as Sven suggested and here's the output: libgtk-x11-2.0.so.0 => /usr/lib/libgtk-x11-2.0.so.0 (0x40033000) libgdk-x11-2.0.so.0 => /usr/lib/libgdk-x11-2.0.so.0 (0x40288000) libatk-1.0.so.0 => /usr/lib/libatk-1.0.so.0 (0x402f7000) libgdk_pixbuf-2.0.so.0 => /usr/lib/libgdk_pixbuf-2.0.so.0 (0x4031) libm.so.6 => /lib/tls/libm.so.6 (0x40324000) libpangoxft-1.0.so.0 => /usr/lib/libpangoxft-1.0.so.0 (0x40346000) libpangox-1.0.so.0 => /usr/lib/libpangox-1.0.so.0 (0x40367000) libpango-1.0.so.0 => /usr/lib/libpango-1.0.so.0 (0x40374000) libgobject-2.0.so.0 => /usr/lib/libgobject-2.0.so.0 (0x403a7000) libgmodule-2.0.so.0 => /usr/lib/libgmodule-2.0.so.0 (0x403dc000) libdl.so.2 => /lib/libdl.so.2 (0x403e1000) libglib-2.0.so.0 => /usr/lib/libglib-2.0.so.0 (0x403e5000) libgimp-1.2.so.0 => /usr/lib/libgimp-1.2.so.0 (0x4044f000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4047) libXrandr.so.2 => /usr/X11R6/lib/libXrandr.so.2 (0x4054e000) libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x40553000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4055b000) libXft.so.2 => /usr/X11R6/lib/libXft.so.2 (0x40569000) libXrender.so.1 => /usr/X11R6/lib/libXrender.so.1 (0x4057b000) libfontconfig.so.1 => /usr/lib/libfontconfig.so.1 (0x40583000) libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x405aa000) libz.so.1 => /usr/lib/libz.so.1 (0x405fc000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x4060a000) libexpat.so.0 => /usr/lib/libexpat.so.0 (0x4062f000) I understand it links against libgimp-1.2 which is apparently wrong. Jean-Luc meanwhile sent me a compiled binary and refocus is running now with my gimp2 which is great and I can continue my work. However, I will try to work more on the problem and I will post a solution when I found it. Thank you so far! Stephan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAlmMGbv5p9h9J588RAjg/AJ9n3HGRpjihmhl12IJ35hCZuo3ZyQCggxBt 2DR9ndRyEMxbhdvOqSyaNUU= =SQrB -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2 plugin porting problems
On Monday 03 May 2004 13:39, Stephan Menzel wrote: > G'day! > > On Sunday 02 May 2004 21:32, Jean-Luc wrote: > > There is a patch for refocus on sourceforge. > > If was built for 1.3 but I have applied it and, with this patch applied, > > the plugin works for me [tm] with gimp 2.0.1. > > > > You can find the patch at: > > http://sourceforge.net/tracker/?atid=535004&group_id=72588&func=browse I think that I have found cause of the Stephan's problem. My plugin used GTK-2, so in the makefiles I had to use some tricks to get the correct include path and libraries. I could not directly use the output of the old gimptool, because that used the wrong GTK versions. I did not have time to look at the patch at sourceforge, but it seems like Stephan is linking with the old version of the libgimp libraries. The obvious solution is to simply use the outputs from gimptool-2 instead of my hacked version. I am afraid that I don't have the time right now to suggest a good solution (anyhow I don't have Gimp-2 installed, so I can't test any modifications). Ernst Lippe ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] status report from the development branch
Hi, here's another summary of what's happening in the HEAD branch, what do watch out for if you want to join development and where help is needed... Mitch has almost finished the port of the menus to GtkUIManager. The new code is in use now and seems to work fine. The only remaining regression is integration with the help system (pressing F1 on a menu item should call the relevant help pages). This is being worked on and will soon be reenabled. What's not yet working is global accelerators. The toolbox and the image window share accelerators already but it's not working from the dock windows yet. Mitch says we will need some ugly hacks to get it working :( In order to avoid duplications in the menu XML files, I've added some Makefile rules that call xsltproc to generate some of the XML files. So if you want to edit the menu hierarchy, keep an eye on the first lines of the XML file you are about to edit. If it's a generated file, there's a comment telling you so. You need to edit the respective foo.xml.in file then. This also means that xsltproc is now needed to build GIMP from CVS. The tarball will contain the generated files so this is solely a requirement for people who want or need to build from CVS. xsltproc is quite commonly installed nowadays and is available for Win32 as well, so I don't expect this to be a problem. Whenever you edit anything in the "menus" directory, please run 'make validate' to get your changes checked against the DTD. This ensures validity of the files which is important since GtkUIManager crashes badly on broken menu files. You need xmllint for this to work, so I strongly suggest you install that as well. I started to change our dialogs to be more compliant with the GNOME HIG. To ease this effort, I've added a new widget called GimpFrame. This is a variant of GtkFrame that doesn't draw a frame but instead sets a bold title and indents the content of the "frame" as suggested by the HIG. I've changed some core dialogs already and I think the results look very pleasant. Of course it's not sufficient to simply replace gtk_frame_new() with gimp_frame_new(), the dialog spacings needs some adjustments as well. The dialogs may become slightly larger by this change but I think that's OK for temporary dialogs. It's a problem for permanent dialogs like the tool options though. We will probably have to come up with a more compact style for these. Jimmac and Tigert promised to do some mockups for tool options that go well with HIG compliant dialogs but are more compact than strictly following the HIG-suggested layout. We will see how this turns out... What remains to be done here is changing all plug-in dialogs. I don't plan to do this myself so it would be nice to get some volunteers for this task. Basically each plug-in dialog needs to be reviewed. Unneeded frames such as those saying "Parameter Settings" or "Preview" should probably simply be removed. Frames that do actually group controls should be changed to use the new GimpFrame widget. Separators should be replaced by empty space. The spacing of the main vbox needs to be changed to 12 pixels to clearly separate groups of controls. The dialog border width should also be 12 pixels (although I personally prefer 6 pixels, but see http://developer.gnome.org/projects/gup/hig/1.0/layout.html#window-layout-spacing). It's important that we try to create a consistent dialog layout so this job should be well coordinated or done by a single person. Any volunteers for this? What I didn't address yet is the fact that the HIG suggests to left-align labels of UI controls while we currently consistenly right-align labels so that they are close to the control they are describing. I am not sure if I can follow the HIG argumentation for this. I guess we should create some screenshots or mockups of standard GIMP dialogs and discuss this change here before we start to work on this. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2 plugin porting problems
Hi, Stephan Menzel <[EMAIL PROTECTED]> writes: > to run two gimps at the same time now. The old one to do refocus and > the new one for everything else. It's consuming lots of memory too > so I would really like to see refocus working with 2.0. Any ideas or > hints what to do or check next? Hoping it is alright for Ernst I > include the src/Makefile and both sources. Thanks a lot! Including the Makefile is not really helpful since noone wants to read an automatically generated Makefile. It's Makefile.am that you should show us. I suggest you use ldd to check what libraries the plug-in executables are linked to at run-time. That might give you a hint on what's going wrong. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: As part of preparing my guadec talk on writing a GIMP plug-in, I plan to update this document, so I'd prefer if it didn't get deleted just yet. In addition, it's quite nicely written with a type of tutorial feel, and it doesn't really have any homologue on the dgo site (yet). Well, dgo was started to finally give an alternative to this outdated sourceforge site, so please consider to help with dgo instead. It's in CVS, you have write access, feel free to improve it. I'll commit the updated article from Kevin, plus my paper, plus my slides when I have them. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp2 plugin porting problems
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
G'day!
On Sunday 02 May 2004 21:32, Jean-Luc wrote:
> There is a patch for refocus on sourceforge.
> If was built for 1.3 but I have applied it and, with this patch applied,
> the plugin works for me [tm] with gimp 2.0.1.
>
> You can find the patch at:
> http://sourceforge.net/tracker/?atid=535004&group_id=72588&func=browse
Thank you for your efforts and for that clue.
I applied this patch which did pretty much the same stuff I did, apart from
some changes in the Makefile. However, it still doesn't work. The same
problem. I could find out some more information though that might be helpful.
In the src of refocus, there is a test-matrix module compiled, which is not
installed by default. I just copied it to the plugin directory to see, what
happens. And it is loaded, performs some tests and exits. But it is not a
proper plugin. It simply contains a main like this..
int
main (int argc, const char *argv[]) {}
Nothing else. No GimpPlugInInfo and no query(). Gimp2 loads and executes it.
Is that supposed to happen?
It is built using the same Makefile as refocus itself and uses the very same
routines too. I tried including a similar main() in the refocus source but it
still doesn't load.
The next thing I tried was executing those binaries directly. And here it is
the opposite. The modified refocus binary executes and prints my included
'hello world'. The untouched test-matrix binary just throws a segmentation
fault. That brings me to the conclusion that although the Makefile looks
identical, there must be some difference in the way those binaries are
created.
I also tried a strace which showed nothing suspicious. The plugin is loaded
with the same function and return code as all the others.
I start to find all that rather interesting but i am still anoyed that I have
to run two gimps at the same time now. The old one to do refocus and the new
one for everything else. It's consuming lots of memory too so I would really
like to see refocus working with 2.0. Any ideas or hints what to do or check
next? Hoping it is alright for Ernst I include the src/Makefile and both
sources.
Thanks a lot!
Stephan
src/Makefile:
# Makefile.in generated automatically by automake 1.4-p5 from Makefile.am
# Copyright (C) 1994, 1995-8, 1999, 2001 Free Software Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY, to the extent permitted by law; without
# even the implied warranty of MERCHANTABILITY or FITNESS FOR A
# PARTICULAR PURPOSE.
SHELL = /bin/sh
srcdir = .
top_srcdir = ..
prefix = /usr/local
exec_prefix = ${prefix}
bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
libexecdir = ${exec_prefix}/libexec
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
sharedstatedir = ${prefix}/com
localstatedir = ${prefix}/var
libdir = ${exec_prefix}/lib
infodir = ${prefix}/info
mandir = ${prefix}/man
includedir = ${prefix}/include
oldincludedir = /usr/include
DESTDIR =
pkgdatadir = $(datadir)/refocus
pkglibdir = $(libdir)/refocus
pkgincludedir = $(includedir)/refocus
top_builddir = ..
ACLOCAL = aclocal-1.8
AUTOCONF = autoconf
AUTOMAKE = automake-1.8
AUTOHEADER = autoheader
INSTALL = /usr/bin/install -c
INSTALL_PROGRAM = ${INSTALL} $(AM_INSTALL_PROGRAM_FLAGS)
INSTALL_DATA = ${INSTALL} -m 644
INSTALL_SCRIPT = ${INSTALL}
transform = s,x,x,
NORMAL_INSTALL = :
PRE_INSTALL = :
POST_INSTALL = :
NORMAL_UNINSTALL = :
PRE_UNINSTALL = :
POST_UNINSTALL = :
CC = gcc
GCC3 =
GIMPTOOL = /usr/bin/gimptool-2.0
GIMP_CFLAGS = -I/usr/include/gimp-2.0 -I/usr/include/glib-2.0
- -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
- -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include
- -I/usr/include/freetype2
GIMP_CFLAGS_NOUI = -I/usr/include/gimp-2.0 -I/usr/include/glib-2.0
- -I/usr/lib/glib-2.0/include
GIMP_DATA_DIR = /usr/share/gimp/2.0
GIMP_LIBS = -Wl,--export-dynamic -lgimpui-2.0 -lgimpwidgets-2.0 -lgimp-2.0
- -lgimpmath-2.0 -lgimpcolor-2.0 -lgimpbase-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0
- -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0
- -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0
GIMP_LIBS_NOUI = -lgimp-2.0 -lgimpmath-2.0 -lgimpcolor-2.0 -lgimpbase-2.0
- -lglib-2.0
GIMP_PLUGIN_DIR = /usr/lib/gimp/2.0
GLIB_CFLAGS = -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
GLIB_GENMARSHAL = glib-genmarshal
GLIB_LIBS = -lglib-2.0
GLIB_MKENUMS = glib-mkenums
GOBJECT_QUERY = gobject-query
GTKDOC = false
GTK_CFLAGS = -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
- -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/X11R6/include
- -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include
GTK_LIBS = -Wl,--export-dynamic -lg
Re: [Gimp-developer] Plug-in howto
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > As part of preparing my guadec talk on writing a GIMP plug-in, I plan > to update this document, so I'd prefer if it didn't get deleted just > yet. In addition, it's quite nicely written with a type of tutorial > feel, and it doesn't really have any homologue on the dgo site (yet). Well, dgo was started to finally give an alternative to this outdated sourceforge site, so please consider to help with dgo instead. It's in CVS, you have write access, feel free to improve it. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Hi, Daniel Rogers <[EMAIL PROTECTED]> writes: > See the problem I see with the GINPOG attitude and joining GNOME is > that we are saying we are willing to take your money and your time and > your developers, but we are not willing to actually show any support > for you in any way. It's kinda datardly. GNOME wants to help us. It's not that we wouldn't put a lot of effort into making GIMP work well on a GNOME desktop. Adhering to FreeDesktop standards is one of our goals and we are even working towards full GNOME HIG compliance. The only things we really want to avoid is to be forced to do any of this. Since we aren't a GNOME application, noone can force us into anything and that's a good thing. It's just a matter of time before libgnome and libgnomeui will be completely obsoleted and all this functionality be in GTK+. At that time The GIMP will probably look and feel like any other GNOME application. Sven PS: See http://sven.gimp.org/gimp-new-image-dialog.png for an almost HIG compliant file-new dialog. This is a screenshot from the HEAD branch. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
Hi, Sven Neumann wrote: Dave Neary <[EMAIL PROTECTED]> writes: http://gimp-plug-ins.sourceforge.net/doc/Writing/html/plug-in.html I don't think we should point people to this document any longer. It's outdated and should better be removed. http://developer.gimp.org/ is where we are collecting more uptodate information and that's where people should be pointed to. As part of preparing my guadec talk on writing a GIMP plug-in, I plan to update this document, so I'd prefer if it didn't get deleted just yet. In addition, it's quite nicely written with a type of tutorial feel, and it doesn't really have any homologue on the dgo site (yet). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
Hi, "Bartekk" <[EMAIL PROTECTED]> writes: > i have a question about the development of plug-in. I want to use > the plugin template u can get from the gimp site. The problem is I > don't know which files are important. If I want to write a simple > Gaussian Filter, how can I do that. For such a simple plug-in you will probably want to keep all code in one file and the plug-in template is complete overkill. You can simply use gimptool to build your plug-in and probably don't need a full-featured autoconf/automake setup as provided by gimp-plugin-template. Have a look at the gauss blur plug-ins in the GIMP source tree. Also make sure you have the GIMP API reference manual available. It comes with the GIMP tarball (in the devel-docs directory) and is available online at http://developers.gimp.org/. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > There are only a very small number of people who really believe this > to be still the case. It may still be called the GIMP Toolkit (but > more & more I've heard it called the GNOME Toolkit), but that is a > historical nod. The GIMP Toolkit is less a GIMP project than the > GIMP Print drivers. I disagree. Every time we port GIMP to new features of the GIMP toolkit I get the strong impression that we are the first using the new API. There's certainly a lot of interaction between GIMP and GTK+, way more than between GIMP and the gimp-print project. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
Hi, Dave Neary <[EMAIL PROTECTED]> writes: > Bartekk wrote: > > i have a question about the development of plug-in. > > I want to use the plugin template u can get from the gimp site. The > > problem is I don't know which files are important. If I want to > > write a simple Gaussian Filter, how can I do that. > > Is there somebody who can give me an how to or an example. > > This document is still somewhat valid, although the API has changed a > lot since then, the principles are the same (the API changes are > fairly evident in the plug-in template): > http://gimp-plug-ins.sourceforge.net/doc/Writing/html/plug-in.html I don't think we should point people to this document any longer. It's outdated and should better be removed. http://developer.gimp.org/ is where we are collecting more uptodate information and that's where people should be pointed to. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] OS X help with plugin
Hi everyone, I've been asked by an OS X user if there's any chance of an OS X version of my CMYK plugin (at http://www.blackfiveservices.co.uk/separate.shtml). I don't have access to an OS X machine, so if there's any developer here who does and is willing to help out, please contact me. All the best -- Alastair M Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
On 2 May 2004, at 23:24, Carol Spears wrote: > not using doc format was a really good suggestion, The solutions mankind has come up with to increase readability are diverse, and range from using open document formats to using capitals at the beginning of sentences and for the word 'I'. I recommend using them all. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMPCon
Hi, Henrik Brix Andersen wrote: Well, I think we should discuss the road map (or whatever you prefer to call it) for the release to come after 2.2 (2.4? 3.0?). We need to talk about stuff like PDB rewrite, GEGL integration, next generation XCF, plug-in policies etc. Is anyone actually working on a requirements list for a new PDB? It would be nice to know what exactly we expect from it, and whether the PDB should be refactored or re-written with gegl nodes in mind. Also, is there any way currently to have standalone out-of-process or threaded GeglNodes? As to the next generation XCF, pippin has a pretty good file format which he is currently using with libgggl and bauxite, currently there is no competing format around. For gegl migration, there has been quite a bit of talk already. Last I heard there were two ideas, which can generally be called data first or structure first - either we keep the same image data objects, and start using GeglGraphs for compositing first, then start changing data structures (I guess that going this way means turning GeglNodes into more or less an interface which delegate operations to a GIMP data based implementation, or to a gegl data based implementation, then eventually killing off the GIMP based ones)., or we change the data structures first (which implies that the data structures and the methods for accessing them are finished) and once we have the data in gegl, start migrating the internal compositing engine and plug-ins to GeglNodes. There was no concrete decision out of the last conversation we had about this. Dan and Calvin's proposal to Mark Shuttleworth on bounties will help lay down tracks here, but it's currently looking unlikely that gegl will be ready to integrate into the GIMP this Sumemr at its current rate of change. Dan has said he'll have less time to spend on it from now on, which means that gegl right now needs some people to work on the data structures end. If this doesn't happen soon, Calvin's proposition of migrating the rendering framework first, and following up with the data structures when they're done, will look a lot more attractive. I recently posted a link to a requirements document that Lourens Veen did for plug-in distribution, but I haven't seen any comments on it. Again, this is one of those things that needs someone actually working on it, rather than just saying to ourselves "that needs to be done". I know yosh was thinking about this - perhaps he has comments? We also need to talk about the GIMP Foundation and how it fits in with GIMP development. I think that this will be resolved before GUADEC. I hope it will be resolved by the end of this week... Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plug-in howto
Hi Bartekk, Bartekk wrote: i have a question about the development of plug-in. I want to use the plugin template u can get from the gimp site. The problem is I don't know which files are important. If I want to write a simple Gaussian Filter, how can I do that. Is there somebody who can give me an how to or an example. This document is still somewhat valid, although the API has changed a lot since then, the principles are the same (the API changes are fairly evident in the plug-in template): http://gimp-plug-ins.sourceforge.net/doc/Writing/html/plug-in.html You might want to look at the Gaussian blur plug-in, the edge detect plug-in and the generic convolution filtre plug-in in (respectively) plug-ins/common/gauss_rle.c, plug-ins/common/edge.c and plug-ins/common/convolve.c - all of these plug-ins are of the type which interests you. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Carol Spears wrote: On Sun, May 02, 2004 at 08:04:04PM +0200, David Neary wrote: (we use their toolkit and infrastructure, a few years ago they used to use our toolkit), did the name change? as far as i know it is still the gimp tool kit. There are only a very small number of people who really believe this to be still the case. It may still be called the GIMP Toolkit (but more & more I've heard it called the GNOME Toolkit), but that is a historical nod. The GIMP Toolkit is less a GIMP project than the GIMP Print drivers. i was quite embarrassed for gnome when i saw how the elections worked on the irc. i know the irc is not really the same as the mail and the official business and such, however -- it was the only view i got at that point. Not sure what you're talking about here - GNOME Foundation elections work by sending a unique mail to every member of the GNOME Foundation, and then automatically parsing the reply to that mail to verify the identity of the sender, the ID on the mail and their voting preferences. No voting is done on IRC. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Joining the GNOME Foundation
Hi Dan, Daniel Rogers wrote: And if you are not a non-profit you need to pay taxes, wether or not you make money. (and if GIMP joins GNOME and abandons TGF, I'm the one that has to pay the 800 dollar minimum tax, I might add). I think that everyone should pool in together to pay this. I have a paypal account, if we use it for nothing else, we should use it to raise the $800 for this. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Donation for GIMP features
Hi, J. Grant wrote: Hi, I wonder if there is any way I can donate money towards development of a specific feature addition in GIMP? We are currently working out two things which may be of interest - first, we are working to have a way to make tax deductible donations to the GIMP via another organisation. And second, we are working out a set of bounties with another donor. In short, for small amounts there is no point in proposing to pay for the feature (I note that you are proposing something like £50, which is very generous for an individual, but it is hardly an incentive for a developer to do a couple of weeks work - the incentive would be actually wanting the feature). We always accept feature requests, and it is quite possible that your feature request is already on our TODO list. Unfortunately the TODO list gets things added to it quicker than they get taken off - the resource we lack most at the moment is people willing to take on a feature and code it. However, there are several ways you can donate money to the GIMP - you can donate to the FSF directly, who have always been our biggest sponsor, and have given us great support over the years, or if you hold on for a few days, you will be able to donate via PayPal (and perhaps other ways - details will follow) directly to the GIMP. Your money will go towards having as many developers as possible meet up for the GIMP Developers Conference in Norway this Summer, which will be hosted by GUADEC. Thanks for your generous offer, in any case. I hope we can make it easy for you to donate in the very near future. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
