Re: Call for help with documentation
Hello Sven, I and Karin can look into the user documentation if you want. Cheers Olof On Wed, 19 Jan 2000, Sven Neumann wrote: Hi, the last call for contributions was a great success. The list of plug-ins that remain to be gettextized has shrunk down to (assuming that the posted list was correct): MapObject gfli libgck xjt and I`m sure someone is already working on these. So, here comes the next call for help: This one is targeted especially at people who always wanted to contribute, but couldn't due to the lack of coding skills. There's some documentation shipped with The GIMP that urgently needs to be updated and checked for correctness before version 1.2 can be released. Here's a list of things that need to be overworked: man-pages: gimp.1 gimprc.5 (generated from gimprc.5.in) stuff in the docs directory: cheat_sheet.txt keybindings.txt( do we need both ? ) quick_reference.ps Additionally gimprc.in from which the global configuration file is generated should be checked for completeness and correctness. All possible configurations should be listed here with useful comments. The Phtoshop-keybindings file ps-menurc has to be updated to reflect the changes in the menu-structure. There's probably more If you want to take one of those jobs, please announce that you are working on it, so we don't duplicate effort. Before starting to work on one of the files listed here, send me an email. I'll try to coordinate the work. Salut, Sven
Re: compiling a plug in
Hello Please use gimptool to build the plugin additional information (a whole chapter) about compiling can also be found in the Gimp Users Manual manual.gimp.org. To build a plugin with gimptool simply do gimptool --build plug-in.c . NOTE that this only work with one c source file. Cheers Olof -- Olof Kylander Frozenriver Digital Design http://www.frozenriver.nu Consultant at Sigma nBiT Technical writer and coauthor of GUM (the Gimp User Manual) On Sat, 11 Dec 1999, Willem Robert van Hage wrote: I've been searching for documentation about how to actually compile a plug in, but all I could find was how to write the code... I tried compiling it like this, gcc -c myplug.c ld -G -o myplug.o but when gimp tries to load it from my ~/.gimp-1.1 (I use gimp-1.1.8) it gives a warning that the plugin has crashed. I'm pretty sure the problem is the way I compile it, because it's with all the plugin code I try, not just my hello world plugin :) if anybody could help out I'd greatly appreciate it. Willem -- [EMAIL PROTECTED] | http://www.xs4all.nl/~wrvh [EMAIL PROTECTED] | http://gene.wins.uva.nl/~wrvhage
Re: Review and better -- Clean up and Re: Help System (fwd)
Hello Marc (and Gimpers) On Fri, 19 Nov 1999, Marc Lehmann wrote: On Thu, Nov 18, 1999 at 11:04:51PM +0100, Olof S Kylander [EMAIL PROTECTED] wrote: * Make a script pkg with Script-Fu, Perl-Fu and Py-Fu scripts A small detail is unclear to me ;) Who is supposed to make that script-pack? Would the release tarball contain everything, inlcuding the script, which would just not get installed (or which would just now show up in the menu?)? Sorry I forgot to answer one question, "Who is supposed to make that script-pack". Well as I pointed out we need a "Plug-Script" maintainer (one or a team). The "Plug-Script" maintainer(s) is supposed to make the Packs. Cheers Olof PS: Well how volunteer to be a part of this team? I definitely into it, but I think we need one or two more developers to be in the team.
Re: Modifier keys (second call for votes)
Hello Sven This is Karins vote. She I think circle restricts is the best. It gives you a better control of what you are doing and it simply feels better. She would also love if you could make it snap to guide as I suggested in my mail yesterday. Cheers Olof On Sat, 20 Nov 1999, Sven Neumann wrote: Hi, I haven't got many responses to my last mail (two votes to be exact), so I ask you once again. Speak up now or be quiet later!! Please check out CVS and test the blend tool (or apply the patch included in my previous mail). Then decide which way you prefer: Holding Shift restricts you to 15 degrees and puts the endpoint on the circle you are defining with your mouse and the startpoint. Holding Ctrl restricts you to 15 degrees too, but puts the endpoint on a rectangle defined by your mouse and the closest 15-degrees angle. The question is not which key to use (I'm planning to use Ctrl for it), but which way of constraining movements to 15 degrees feels better. This only applies to the line draw mode of the paint tools and to the blend tool. Now vote!! Salut, Sven
Re: Review and better -- Clean up and Re: Help System (fwd)
Hello Steinar, On Sat, 20 Nov 1999, Steinar H. Gunderson wrote: My idea is that Gimp 1.2 is delivered with all "scripts" and "filters" some of them aren't installed by default (most notably "scripts" but also some C plugins). They are instead installed in ..share/gimp/uninstalled_filters/core. I'm afraid I don't see the purpose of all this. I think novice GIMP users want to get all the features straight away, and not discover them three months later (this happened to me for Gimp-Perl, for instance). GIMP starts up fast enough as it is, doesn't it? Fist in my view the hardest task is for a novice Gimp user to find the right command to use. As of today we have five similar Color Maping filters. The question is which one to use. Secondly, if we add all possible extra functions (C plugs, Script-Fu, Perl-Fu and Python-Fu). The menu system will be very large and difficult to navigate. Furthermore I think that the average user doesn't want to have all that functionality (just ask your self how often do you use Draw HSV Graph). There are also some functions that are only useful under some conditions. Maybe the user never uses funcs like that? Finaly, if we have a script pack manager we can make packs of e.g all the plugins and scripts available at registry.gimp.org . This will benefit the user quite much since it will be very easy to install more funcs into Gimp. The user will also be informed that her Gimp environment isn't complete since she can't run e.g Perl "Scripts". While we're speaking about user-friendliness on this topic, my impression is that you'll have to install GIMP (`make install') _before_ you can configure Perl-Fu, which is a bit confusing. If you do `configure --enable-perl', configure automatically tries to configure in plug-ins/perl, which then fails (`GIMP is not installed'), which is a bit confusing. Is there (as usual) something wrong with my system, or is this just a glitch? Well, the std ./configure will try to configure Perl-Fu/Python-Fu if it fails it will still continue and enable you to build Gimp. When you later try to install additional script you will be informed that since XXX YYY Python-Fu isn't enabled on your system. Please XXXdasd erwe to enable Perl-Fu. I mean there isn't anything saying that we can't inform the user that there isn't any thing wrong with his system it only lacks the necessary support to enable Python-Fu. Cheers Olof
Re: More Inconsistency in eraser, blur and dodge tools
Hello all Gimpers ;-) On Mon, 1 Nov 1999, Michael Natterer wrote: Hi all, all the stuff below sounds quite good (the current modifier usage is really confusing, even for experienced users). When redefining it (making it consistent), we shouldn't forget to care for dnd. Hacking dnd of selection masks / selections between images or images and the named buffer dialog shouldn't be too hard. I've just redefined the middle mouse button to the standard gimp dnd button (not commited yet) Left mousebutton dnd still works as now, but with the middle it's possible to drag from the indicator area and from the brush/pattern/gradient selections (ie all areas where button 1 pops up a preview and/or selects stuff) I'm thinking of the following operations: shift+mouse2 -- copy paste the selection mask or copy paste the selection itself (if it's floated) ctrl+mouse2 -- cut paste the selection ifself (works only if it's floated) (You see I'm still speaking in terms of "floating" because I didn't quite get what Tigert means with "nuke" ;-) Comments, flames??? bye, Sounds fair to me. Really lovely if I may say so -- me say go for it. To add my view the path to Gimp 1.2 is * Good, consistent and user friendly UI (with out making to much core hacks i.e make it unnessesary unstable) * Stability * Release I mean releasing Gimp 1.2 before that is not wise. Why? Well what we have been bashed most of is the inconsistent UI. So adding a lot of new features and then say "stop and go" is not very wise. The bottom line Gimp is the top of the line open source application that is targeting *_users_. I don't mind waiting around extra three months to make Gimp be the top of the line program when it comes to user friendly UI. I mean if we rush it really we can maybe release Gimp 1.2 in Jan 2000. So how much will it hurt to release it in Mars instead. Cheers Olof * Gimp isn't emacs nor is it a browser, Gimp is a artist program targeting both artists and others. Just having artist in the audience makes Gimp special. Artists are conservative and they are picky about user friendly ness. This means that the UI must be good if we want to convince them to use Gimp.
Re: More Inconsistency in eraser, blur and dodge tools
Hello all On Mon, 1 Nov 1999, Austin Donnelly wrote: On Monday, 1 Nov 1999, Michael Natterer wrote: shift+mouse2 -- copy paste the selection mask or copy paste the selection itself (if it's floated) ctrl+mouse2 -- cut paste the selection ifself (works only if it's floated) But, people like dragging with mouse1 - its more of a psychological think. Also, not everyone has a 3 button mouse, so putting too much on mouse2 is probably bad. Gimp is a X11/UNIX program, which is designed to make use of three mouse buttons. I say get a three button mouse or don't use Gimp. It's a ton easier to use the middle mouse button than to remember a trillion mod key combinations. I realise distinguishing between mouse1 click, double click and drag make the event logic more complex, but I think it's worth it in reduced number of "help me!" emails. I think the best way to avoid help mails is to have a system. Which I think I'm writing just now if I remember correctly ;-). Note also alt+mouse1 drag on a selection moved the mask itself, so this feature already exists. Well see in your own mail below where you say use PS mod keys/short cuts. When you move a PS selection you move the selection it self. You aren't making it into a floating selection. See more below. I'm just saying use "to float" if you want to have a floating selection. Sven Neumann wrote: So my proposal is: Shift is used for line mode in all paint tools Ctrl is the default tool toggle key Alt limits your moevent to 15 degree directions Check what PhotoShop uses, and use that. I have hazy memories of MacPaint and SuperPaint using shift to limit to 15 degrees. Well what about how you move a selection is PhotoShop? Gimp uses the total opposite of PhotoShop and many other Win/Mac image manipulation programs. The reason why Gimp uses to float when you drag a selection is because it's still there since the days we didn't have layers. When you don't have layers you want a float to be able to do selections and masks with in the floating selection. Today this is very confusing -- the user drags a selection gets a float, if he then try to make another selection (to e.g add) she will get a mask with in the float. She will most likely start to say four letter words now and leave Gimp to rest in peace. I say if you want a float use "to float", don't "force" an unaware user into floating selections. Furthermore it is very important to be able to transform the selection (not the selection with substance). Imagine that you want to select a round traffic sign in a photo taken from an angel. This is done by making a circle selection and the shear it. Today this is very cumbersome since the transform tool will transform the substance of the selection and not the selection it self. (Yes I have tried to use quick mask and make a transform in the "red" image. It doesn't work or at least it doesn't work in my CVS very uptodate Gimp. This is still a work around and not a good solution.) Michael Natterer wrote: Comments, flames??? I think we have larger problems than UI ones right now, and I suggest people start fixing them. Eg: - shrink wrap redraws the entire image 3 times (yes, 3!) - redundant redraws in a number of other places These _really_ bite when working with (say) 3000x3000 images. Yea they probably do, but I think Mitch is a UI programmer and wanted flames or Comments on the UI thing. Note: I'm not saying that we shouldn't fix the redraw problem. They are also important, a slow application is not user friendly. Cheers and take care Olof
Re: More Inconsistency in eraser, blur and dodge tools
Hello Gimpers On Mon, 1 Nov 1999, Carey Bunks wrote: Michael for the freeze - focus on bug fixing. UI problems can be Michael considered bugs, but the truth is they are a design issue. They do work, Michael just not as might be desired. I think that Michael has a good point here. Why is it useful to declare a feature freeze? In my opinion the answer is so people can begin making plans with respect to the upcoming new stable release. If just anything is allowed after a feature freeze why declare one? It depends how you specify feature freeze. Some specify it as a stop to add anything (nearly a code freeze) some one else specify it as a clean up and fix time until we enter code freeze. Me my self specify it as a clean up and fix time (that includes e.g cleaning the UI to be consistent). Olof There was no design specifications (if I'm not totally out Olof in the sky flying). We code and write etc. for the fun and Olof joy not to do specifications (don't interpret me wrong Olof design specifications is a very good thing most of the Olof time). There is no formal design specification. However, there is an informal one. When the feature freeze was announce there was a call to declare all the features that would be included in version 1.2. These UI issues were not declared, and, as Michael already said, they are not bugs. I think they where declared we Sven, Micth, Simon and me made a virtual CVS check in 8 August 1999. Which was sent to the mailing list Date: Tue, 31 Aug 1999 23:10:15 +0200 (CEST) under the subject "CCC GIMP hacking and conclusions. (virtual CVS checkin)" the delay due to that the list was down. Here Micth stated a lot of nice cleanups (just go into the mail archive and read, since I think sending the mail as an attachment is a bit to much) The mail was not "rejected" from the Gimp dev-mail community. I think that document is a quite good specification about the UI. Olof, I think that the UI changes you are working on are great and need to be included in the GIMP. I'm not working on any changes. I'm writing the help system just now, which makes it painfully obvious that the UI isn't consistent. However, many people have worked hard (I'm not just speaking for myself) based on the presumption of a freeze. I think that should be respected. I know that a lot of people has worked hard, me my self included. The discussion is not about disrespect. Trust me I respect you and other hard working people 100%, but I also respect a user demanding a good UI to work within. Best Wishes Olof S Kylander
More Inconsistency in eraser, blur and dodge tools
Hello Again There are some major inconsistency or more precisely hard to use functions in the eraser, the sharpen/blur and dodge/burn tools. Pressing Ctrl will change the tool behavior from eraser -- anti-eraser, blur -- sharpen and dodge -- burn. Pressing Ctrl will in combination with Shift limit the movements/stokes to horizontal movements. Okay so if you want to have only horizontal movements then you also get the opposite effect i.e sharpen instead of blur. This is _not_ good!!! Okay so if you want the opposite effect and want to e.g have only vertical movements? This will not work with short cuts. Anyway this will be a mess in short cuts and work around solutions. I think it's better to remove the "line" drawing function you will probably not use it as much as you use the short cut to change tool effect. A small question, why don't we use the AltGr button? Cheers Olof PS: As you might understand I'm adjusting the preliminary 1.0 help system to Gimp 1.2
Re: More Inconsistency in eraser, blur and dodge tools
Hello Yes, we have to overwork the modifier keys! HeHe ;-), it is more or less impossible to know what all of them do. I'd propose to use only a single modifier for constraining the movement into a special direction. The gradient/blend tool already offers this. Strg/Ctrl are bound to horizontal/vertical movements as usual. Shift shows what I am thinking of here: It limits you to 15 degrees steps. IMHO this works quite well and would free up one modifier. It should be possible to find one key that can then be used explicitely for constraints and would never have a different meaning. So my proposal is: Shift is used for line mode in all paint tools Ctrl is the default tool toggle key Alt limits your moevent to 15 degree directions We would have to drop Alt for "Allow Enlarging" in the CropResize tool, but I think we could live without that. I think that would be a _very_ nice solution !!! Lets go for it!! Cheers Olof
UI consistency in Gimp
Hello Gimpers Some items that I think need a shape up before 1.2. I know code it or move away, but I thought you might want to know anyway. The info window is very nice but it is not explored to it's fully functionality. First of all it's not auto switched which IMHO is mandatory. The measure tool and the status info (i.e the pos in the image currently displayed in the status bar). Not that I'm not saying that it should be present in a popup (measure) or in the status bar. I'm just saying that the info should also be present in the info window. The nav widow should be integrated into the info window or at least the nav window should be auto switched (which IMHO is mandatory). Gimp has number of mod keys when you make selections. This makes the select commands very powerful but hard to control. In my opinion it's better to have an option for pure circles and squares, instead of a modkeys. There are simply to many funcs pressed in to mod key combinations at the moment (i.e this is not intuitive). When you move a selection you get a floating section IMNSHO this is _not_ good. It should be the selection it self you move, Alt + Move (selection) creates a floating selection which you can also move. Why? It's irritating to always get a float. We will enter the windows world Win32 Gimp and it's more common to have the move tool to move the selection it self. I think the constant ratio is a bit confusing or at least I can't get it to work in intersect and minus mode. I think it also would be very nice to set only one way as fixed e.g only one pixel wide but unlimited range in height. (I might miss some of the trillion short cut keys, but as I said they are to many at the moment to hold in your (my) tiny head). Cheers Olof -- Olof Kylander Frozenriver Digital Design http://www.frozenriver.nu Consultant at Sigma nBiT Technical writer and coauthor of GUM (the Gimp User Manual)
Re: Icons in LC dialog (and elsewhere)
Hello Well "feature" freeze is a wide term. Currently only Gimp (app and lib) is in feature freeze (If I haven't missed a mail). Functions such as IS, Bezier, Airbrush, brush scaling, context etc.. is not finished. For me a feature freeze is when you stop add new functionality. It's not when you change how a tool work (e.g moving Simons curve tools to IS). It is not when you make the brush scaling work etc. Neither can feature freeze stop you from e.g cleaning up the menu paths for e.g plugins. Changing icons is not (in my view) a new feature (adding a new tool is). Cheers Olof -- Olof Kylander Frozenriver Digital Design http://www.frozenriver.nu Consultant at Sigma nBiT Technical writer and coauthor of GUM (the Gimp User Manual) On Mon, 25 Oct 1999, Carey Bunks wrote: Sven Hi, would somebody cry and whine if I check this in: Sven http://sven.gimp.org/files/lc_new_icons.png Sven IMHO a little facelift can't hurt and the anchor does fit Sven better with the Gnome icons. = I don't object to changing the icons but I'm against it for the 1.2 release. I think that since the GIMP is in feature freeze the only changes should be to eliminate bugs. This is an important point for folks who are working on documentation, i.e., those working on GIMP books. Carey Bunks Dr. Carey Bunks Senior Scientist BBN Technologies 70 Fawcett St, 15/2A Cambridge, MA 02138 tel: 617-873-3028 fax: 617-873-2918 email: [EMAIL PROTECTED]
