Re: [Gimp-developer] Idea for support page
On 10 May 2004, at 9:40, Dave Neary wrote: A friend here heard about Koha, an open source library management program, and I was looking at their site, and found this: http://koha.org/installation/support.html Funny, I just visited that site a couple of days ago, in search for a library system (and finally recommending http://obiblio.sourceforge.net to the person who asked me to look for one). This is about the sort of library one borrows books from, for those wondering. :-) I think this is a great idea. If there are people out there prepared to give commercial support to the GIMP, there should be a way for them to get some kind of official status, and have their name listed on the gimp.org website. What do people think of the idea? Is the GIMP the kind of program for which support contracts might be bought? Are there people out there who want to include GIMP Support in their business? Lots of open questions - I thought this was a great idea though. I can see several sorts of support possible: - build installation support - beginners classes Using the GIMP - plug-in coding - generic upkeep (calling when new versions are out, that sort of thing) None of that sounds very exciting, but I don't work in the support business. I can imagine that for an organisation for which time is money, any sort of support they can buy-in is welcome. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] New to Development
Title: Message I'm a newbie to this developer list. I've been searching the site for some info on how the developer community is governed, but could not find what I was looking for. Who/how are patches approved for release and how is the release process managed? Thanks in advance. Insight is seeing what everyone has seen and thinking what no one else has thought. --Albert Szent-Györgyi
Re: [Gimp-developer] New to Development
Hi, Laughner, Bill [EMAIL PROTECTED] writes: I'm a newbie to this developer list. I've been searching the site for some info on how the developer community is governed, but could not find what I was looking for. Who/how are patches approved for release and how is the release process managed? The developer FAQ has answers to your questions: http://developer.gimp.org/faq.html Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Constraints, Path tool
From: Simon Budig [EMAIL PROTECTED] The Link you gave does not work. Try now: ftp://ftp.funet.fi/pub/sci/audio/devel/constraints/ http://ftp.funet.fi/pub/sci/audio/devel/constraints/ In fact there is a vector based infrastructure and I also believe that it is quite flexible. Simply fiddle a bit with the Path tool to get an idea how this works. Could you read the sketchpad.pdf and check how it differs from how the path tool is handled? The constraints directory has other pdf papers of which you could read at least the introductory sections. They give some background and motivation. The qoca subdirectory has some papers related to Qoca constraints library (GPL) -- search the source code from the web. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New to Development
Hi, On Mon, 2004-05-10 at 17:23, Laughner, Bill wrote: I'm a newbie to this developer list. I've been searching the site for some info on how the developer community is governed, but could not find what I was looking for. Who/how are patches approved for release and how is the release process managed? Welcome :) A good place to start is the GIMP Developer FAQ: http://developer.gimp.org/faq.html Regards, Brix PS: oh, and you might want to turn off HTML mail for this list. Thank you. -- Henrik Brix Andersen [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
Hi, it's a week since the last report from the development branch, so I thought you'd be waiting for an update. Let's see what has happened... Mitch added an option to clear the Undo history. May be useful if you are running out of memory. This was requested in bug #136300. I've added the possibility to set the keep-above window manager hint for the toolbox and the dock windows (bug #131672). I started to HIG-ify the core dialogs. So far I've changed all frames to use the GimpFrame widget and I did the most important changes to the spacings in the dialogs. Since we decided to also change the label alignment, more work will be needed here. The main dialogs should probably all be reviewed. The File-New dialog (or actually the GimpTemplateEditor) is the only one so far that has undergone some more significant changes. Maurits and Brix joined the HIG-ification effort and started to work on plug-in dialogs. Mitch added a new scheme for registering menu entries from plug-ins. The new scheme is backward-compatible to the old API but it has some advantages over the old scheme. First of all, a plug-in can now register multiple menu entries for the same procedure. It registers the procedure once and gives it a name. This is represented internally as a GimpPlugInAction. Then the plug-in can register this action to the menus, in multiple places if it likes to. Combined with the placeholder feature of GtkUIManager this allows to have plug-ins in the core menus and in the Filters menu. This should allow us to choose more intuitive menu locations for our plug-ins. I've changed the unit system to allow pixels as an image unit. The image statusbar now has a nice little unit combobox next to the display of the cursor coordinates. The image unit can be conveniently changed from here. Some dialogs, most notably the Scale dialog, still need to be changed accordingly. The widget that I added for the statusbar unit selector is a prototype of a replacement widget for GimpUnitMenu. Will probably move it to libgimpwidgets later. Right now it's missing some features though. Mitch started to make the toolbox configurable. Needs code to save and load these settings as well as a more untuitive GUI. I guess you can expect this to work when I'll send the next status report... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Constraints, Path tool
Juhana Sadeharju ([EMAIL PROTECTED]) wrote: From: Simon Budig [EMAIL PROTECTED] The Link you gave does not work. Try now: ftp://ftp.funet.fi/pub/sci/audio/devel/constraints/ http://ftp.funet.fi/pub/sci/audio/devel/constraints/ In fact there is a vector based infrastructure and I also believe that it is quite flexible. Simply fiddle a bit with the Path tool to get an idea how this works. Could you read the sketchpad.pdf and check how it differs from how the path tool is handled? It would be your task to explain to explain to me what you want. As I said earlier I am quite satisfied with the way it works now. Also, the path tool deals with bezier curves, the paper does not. The path tool handles polygonal line segments, the paper does not (only single straight lines). For circles a significant different way to handle them has become quite standard for vector applications. And I'd prefer to match the handling in other recent programs than a paper from 1963. The constraints directory has other pdf papers of which you could read at least the introductory sections. They give some background and motivation. Sorry, I won't go fishing for your wishes. Bye, Simon -- [EMAIL PROTECTED] http://simon.budig.de/ ___ 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 10 May 2004, at 18:49, Sven Neumann wrote: Mitch added an option to clear the Undo history. May be useful if you are running out of memory. This was requested in bug #136300. Cool, thanks. Sounds like a useful option. (The rest too, BTW :-)) -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] 2 Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 G'day, Since I migrated to Gimp 2.0.1. I noticed are a few little things you have apparently changed but I don't really understand why. Here are but 2: 1. Whenever I click on the 'Insert Text' Button, the foreground color as well as the color for the text itself changes to black. Though it is possible to use another color it is much more complicated than before (1.2.2). Why? I often pick a color out of the picture with this little colorpickertool and then insert text in this color that matches another in the picture. Black is the least I would use. But now this is complicated and rather a pain. Does this change have any purpose I just don't see? Anyway, if it doesn't, can you change that back in the next release? 2. The new 'Crop' tool is not as simple as the old. Formerly there used to be a border that opens and you could drag the corners around until they finally matched what you wanted and then you pressed the crop button. There was a shortcut too. (Ctrl+c?) Now the shortcut seems to be gone and there are no longer dragable corners. You have to use rectangular selection instead which doesn't have this. (Or does it?) And when I choose 'crop' in the menu, there is a new selection just slightly smaller than the picture over almost the entire crop. I can't really see the purpose for that. The cropped image seems to be slightly larger than the area I actually selected too. I hope you understand those thoughts being constructive criticism or stupidity on my side. It is not meant to be bad or something and I have the greatest respect and thanks for all the developers of gimp. Stephan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAn91Qbv5p9h9J588RAr+RAKCppqAyyK4RwhNrJX0Uguw5bbvZqQCgoqS1 6PKRDul5+C/uw39oB5zN+uA= =fUom -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2 Questions
Hi, Stephan Menzel [EMAIL PROTECTED] writes: 1. Whenever I click on the 'Insert Text' Button, the foreground color as well as the color for the text itself changes to black. Though it is possible to use another color it is much more complicated than before (1.2.2). Why? I often pick a color out of the picture with this little colorpickertool and then insert text in this color that matches another in the picture. Black is the least I would use. But now this is complicated and rather a pain. Does this change have any purpose I just don't see? Anyway, if it doesn't, can you change that back in the next release? The foreground color is not supposed to change. If it really does, that would be a bug. However I don't seem to able to reproduce this. 2. The new 'Crop' tool is not as simple as the old. Formerly there used to be a border that opens and you could drag the corners around until they finally matched what you wanted and then you pressed the crop button. There was a shortcut too. (Ctrl+c?) Now the shortcut seems to be gone and there are no longer dragable corners. You have to use rectangular selection instead which doesn't have this. (Or does it?) And when I choose 'crop' in the menu, there is a new selection just slightly smaller than the picture over almost the entire crop. I can't really see the purpose for that. The cropped image seems to be slightly larger than the area I actually selected too. I am sorry but the crop tool didn't change at all. You should still be able to drag the corners just as in GIMP 1.2. We only added a convenient way to crop the image to the size of the current selection (Image-Crop Image) but that's not really related. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2 Questions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, On Monday 10 May 2004 22:59, Sven Neumann wrote: The foreground color is not supposed to change. If it really does, that would be a bug. However I don't seem to able to reproduce this. Well, it does here. I can reproduce it every time. 0. Load Gimp and load any picture (tried with RGB and Greyscale) 1. press O 2. pick a color from the picture 3. close the little color chooser window 4. press T or click the Text button - - The forgroundcolor is black again and so is the text. As I said, I use version 2.0.1, which works fine, besides this. If it really is a bug. It wouldn't be so bad if I could choose a new color from the textcolorwidget but there is only the color dialog which is inconvenient. I prefer 'o'. I am sorry but the crop tool didn't change at all. You should still be able to drag the corners just as in GIMP 1.2. We only added a convenient way to crop the image to the size of the current selection (Image-Crop Image) but that's not really related. Ooops. I just didn't see it in the menu where expected and I assumed it is gone or rather it has changed that way. It does indeed work as usual which is great and I apologize. Even the shortcut works and I should have noticed that. However, it might be confusing for some users to have two crop possibilities instead of one distinct way. Stephan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAoAfzbv5p9h9J588RArbqAJ9qCu/NBk7lCBZ78JwR4GQQ9BE1fACfUg7I cQAYDQLLFHIXAcMGf5jeqJA= =GerS -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2 Questions
On Mon, 2004-05-10 at 18:53, Stephan Menzel wrote: Well, it does here. I can reproduce it every time. 0. Load Gimp and load any picture (tried with RGB and Greyscale) 1. press O 2. pick a color from the picture 3. close the little color chooser window 4. press T or click the Text button - - The forgroundcolor is black again and so is the text. It is a bug (IMO). I see the same problem with 2.0.1 but not in the 2.1 version. In 2.1 I can click a pick a colour then select the text tool without the foreground colour changing. -- Cheers! Kevin. (http://www.interlog.com/~kcozens/) Owner of Elecraft K2 #2172|What are we going to do today, Borg? E-mail:kcozens at interlog dot com|Same thing we always do, Pinkutus: Packet:[EMAIL PROTECTED]| Try to assimilate the world! #include disclaimer/favourite | -Pinkutus the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring?
Hi Robin, Robin Rowe wrote: Does code in app ever get moved into libgimp? In what cases and who decides? A recent example of code that was moved from the main app to libgimp is libgimpthumb. The decision process behind this is documented in a bugzilla report (if you search in the GIMP product, including resolved and closed bugs, with thumbnail in the search criteria, you should find it - unfortunately at this precise moment bugzilla is down, otherwise I'd do it an include a link). I honestly am not sure what the process for moving code to libgimp is... essentially it is just moving the code to a library, and then adding a wrapper (if required) around those functions to expose them to the PDB. Related question, what tools use libgimp without GIMP? To the best of my knowledge, none. There was one person about a year ago who wanted to write a GIMP PDB for batch processing, but I don't know what happened to him. There isn't a whole lot of utility code that can be used independent of the PDB (I suppose the GimpWidgets are pretty handy). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Idea for support page
Hi, A friend here heard about Koha, an open source library management program, and I was looking at their site, and found this: http://koha.org/installation/support.html I think this is a great idea. Ifg there are people out there prepared to give commercial support to the GIMP, there should be a way for them to get some kind of official status, and have their name listed on the gimp.org website. What do people think of the idea? Is the GIMP the kind of program for which support contracts might be bought? Are there people out there who want to include GIMP Support in their business? Lots of open questions - I thought this was a great idea though. Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-web] Cleaning up the wiki
Hi, Michael Schumacher [EMAIL PROTECTED] writes: - is there anyone who feels responsible for the wiki? I don't feel responsible but I have a friend who's experienced with MoinMoin wikis and offered his help. He wants to address technical problems only, which means updating the Wiki to a more recent version and theming it so that it looks more GIMPish. We only didn't get around to do this yet... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: [Gimp-web] Cleaning up the wiki
Hi, Sven Neumann wrote: I don't feel responsible but I have a friend who's experienced with MoinMoin wikis and offered his help. He wants to address technical problems only, which means updating the Wiki to a more recent version and theming it so that it looks more GIMPish. We only didn't get around to do this yet... Where's the wiki housed? And who has a shell account with sufficient permissions to add files in there, and modify existing ones (for instance, turning on attachments in the configuration)? Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Refactoring?
Hi, Robin Rowe [EMAIL PROTECTED] writes: Would like to better understand the development approach the GIMP has used over the years to segregate code in the main app from code in libgimp. Seem to recall seeing some app code that had moved into libgimp, but am not sure. Do GIMP maintainers later refactor code? Looks like you didn't understand the role of libgimp. libgimp is strictly a plug-in library; the core doesn't use libgimp. It's basically the C language binding of the PDB. Perhaps this information can help you to refactor your question. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another new image dialog mockup
Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: Sorry, but I fail to see any improvements in these mockups. Honestly, I would have expected you to reply in a more thoughtful and constructive manner. It's obvious that I spent some time (hours, actually) constructing this mockup, and that I didn't think that my choices were stupid, yet it really feels like you have dismissed them all out of hand. This is exactly the reason GIMP has problems attracting and retaining new contributors. Well, my response was a little longer than the one sentence you quoted and it did include my reasons to not accept any of the changes you suggested. When I looked at your mockup my first impression was that this dialog looks unbalanced, confusing and cluttered. That's of course a question of taste also, but it should make you think about whether your mockup is really an improvement. I think it isn't, for the reasons given. Your unpleasantly long mail also didn't convince me. It made me understand the reasons for adding the warning icon but with all the visual clutter it bring to the dialog, I don't see it being important enough to be added. I understand that you feel dismissed since you put some work into this but I think you should show the same respect to other people's work that you expect for your's. Sometimes things just don't work out and hours of work have to be thrown away. Happens every day. There's no reason to get pissy about that. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Another new image dialog mockup
Hi, Nathan Carl Summers [EMAIL PROTECTED] writes: Screen estate is really a non-issue here. Even with the ridiculously bloated theme that comes with Glade for Windows (yeah, yeah, buy me a T1 so I can do this kind of stuff at home on my beloved Debian Sarge box instead of at work) the fully-expanded dialog is by default 344 x 521 pixels, which means that it will fit on any display bigger than 640 x 480. Actually, it will even fit on a 640 x 480 display, since the somewhat ungraceful behavior of the dialog is to clip the bottom part if there isn't enough space allocated. If your display adaptor can't do 640 x 480, you will have bigger problems with GIMP than just the new image dialog going off the screen. I wasn't talking about dialog size here. The point is that the memory size label is probably the least important thing in this dialog while your mockup gives it the most prominent appearance. If the label is really so difficult to understand then it should be removed. I do however think that most users will understand it as it is. Perhaps it should be put in italics so it looks less like the other labels? When the icon changes to the warning icon, that is distracting, but it is so on purpose. The same kind of feedback could be achieved by changing the label to bold or adding an exlamation mark. Simple, small and effective. Centering the unit menu next to the size entries does IMO look horrible since it deviates from the table layout of the dialog. However, aesthetics was not the reason I made this change; there is a much more important usability factor involved here. As the HIG states, Visual design is not just about making your application look pretty. Good visual design is about communication. A well-designed application will make it easy for the user to understand the information that is being presented, and show them clearly how they can interact with that information. The changes I made make the dialog much more effective at communicating to the user the mechanics of the dialog. Right, that's why for a group of X/Y controls we put the label at the upper left and the unit menu at the lower right. That's how the user scans the dialog. It's also the reason that the OK button is located at the lower right of the dialog. The problem here is that the existing layout breaks a cardinal rule of any kind of layout: the dialog elements are not treated consistently. The controls in the Image Size and Advanced groups are labelled with headings, but the template control has no heading at all. This lack of balance makes the template dropdown look like an afterthought. Originally I simply bolded the Template: label, which made it look more balanced, but the dropdown still looked out of place, so I indented it. The unit control is a single item, not a group of controls. It thus doesn't deserve a group label. The way it is presented now gives it less weight than the Image Size controls. That's good because the Image size is the most important part of the dialog and should be what the user looks at first. Placing the template as part of the size group won't work because the template influences more things than just the size. I also don't think that templates should be place in the Advanced group. It also won't work for technical reasons. The template menu is not part of the GimpTemplateEditor widget. I think Jimmac and Tigert did a very good jo with their mockup and I don't see much room for improvement. IMHO we should stick to it. This sounds very closed minded. The dialog proposed by Jimmac and Tigert was a big improvement over the old one, but to say there is hardly any room for improvement smacks of hubris. Even if you didn't see any room for improvement when you wrote that, it does not in any way mean that there in reality isn't any, or even that you won't see any room after more discussion. I don't see much room for improvement. But that doesn't mean that I don't think that it could be further discussed. I didn't put an end to the discussion, I only told you my opinions on your mockup. Would you have preferred if I had simply ignored it? However, I think it would make much more sense to now think about the other dialogs that need to be converted. As soon as we are through with all of them, we will have collected more experience with the new HIG layout and can start the process all over. That will certainly bring us further more quickly. Sticking to an endless discussion of the File-New dialog might bring us the perfect dialog but it will leave the rest of the application looking like shit. Our schedule for 2.2 doesn't leave us much time, we need to get things into a reasonable state soon. Noone says that things can't be changed again later. But I'd rather not do too many changes to the dialogs in this development cycle. Keeping some of the established user interface elements will the switch to 2.2 easier for our users. Sven
