Re: Review and better --> Clean up and Re: Help System (fwd)
On Sat, Nov 20, 1999 at 09:04:24PM +, "Steinar H. Gunderson" <[EMAIL PROTECTED]> wrote: > 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 This must be a new bug, then ;) One thing that might cause this is that you have configured gimp-perl in it's plug-in directory before without running make distclean in between (and maybe make distclean has a bug). If, after a make distclean, it still does not configure, could you send me your config.log? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
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: Review and better --> Clean up and Re: Help System (fwd)
Olof, >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? >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? /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
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: Review and better .......
On Mon, Nov 15, 1999 at 11:02:12AM +, Austin Donnelly wrote: > On Saturday, 13 Nov 1999, Olof S Kylander wrote: > > > The above statements leads to the conclusion that you often need to > > zoom in out quickly. > > What's wrong with the "+" and "-" keys? I used them exclusively to > control the zoom level, and find it quite convenient. I never do anything but this. If I was being evil, I'd drop the zoom tool altogether, but that is not good. It is good to have it there for new users, but I strongly believe that most people never use it - the keys are _way_ more convenient. This applies to a LOT of other things in gimp also. I have defined myself 3 additional shortcuts that I use all the time: 1) Alt-R -> image -> RGB 2) Alt-G -> image -> GRAY 3) Alt-I -> image -> Indexed I dont know if they clash with any existing ones, but doing your private handy shortcuts is very good feature in gimp. Much better than tear-off menus (which are sometimes handy too). I strongly suggest people to learn to use them :) > It would be even better if the zoom also panned to center the zoom > around the location the mouse cursor is over then the key is pressed. > I'm not sure how to go about plumbing that in, though. Yep, it probably would be nice. But I dont know how hard it would be to implement. Tig -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: Review and better .......
On Saturday, 13 Nov 1999, Olof S Kylander wrote: > The above statements leads to the conclusion that you often need to > zoom in out quickly. What's wrong with the "+" and "-" keys? I used them exclusively to control the zoom level, and find it quite convenient. It would be even better if the zoom also panned to center the zoom around the location the mouse cursor is over then the key is pressed. I'm not sure how to go about plumbing that in, though. Austin
Re: Review and better --> Clean up...
First off, many thank you's to Olof for gathering this task list into one place! >Simon Budig Noted: >> Olof S. Kylander ([EMAIL PROTECTED]) wrote: >> [Lots of good ideas snipped] >> /image/-mode-| >> |RGB >> |Grayscale >> |Indexed >> >> Add a separator here, since Compose and Decompose are no Modes... >> Do we have a better name for the submenu to reflect this? >> >> |Compose >> |Decompose I feel that these items are only tangentially related to "mode," in that decomposing or recomposing an image can generate images that differ in mode from the parent. It would be nice if they had their own submenu. But what to call it? I am not aware of a good (English) verb that encompasses and generalize the two particulars of (1) making a composite and (2) reducing to parts. The idea may be better said in another tongue. Am I alone in voting for the change: [Old] /Filter/Render... [New] /Renderers... ? Plug-ins that carry a collection of parameters to a new rendering that is, in fact, disjoint from a parent image does not play in my mind as any kind of "filter" at all. (Taking an input, applying a transform, producing an output...). Just my US 0.02 ... Garry Osgood
Re: Review and better .......
On Fri, Nov 12, 1999 at 09:57:49PM +, Andy Thomas wrote: > > Olof S Kylander:- Thanks for your summary of the problems in Gimp. > > I noticed the following on this list:- > > > * Make the Navigation window auto aware > > > I was trying to think what advantages having the nav window auto switch over > would do. The small "popup" area in the lower right hand corner already offers > a short cut to move around the currently active image so I think it would be > used for convenience. > > The current situation where the nav dialog is tied to the view (not image) > allows you to have many views open on an image an scroll around them > independantly (you dont have to selected and image to do that). I have used > this to compare parts of images. Valid point. I use the popup myself, though I'm so used to middle-mousebutton pannig that I usually end using that before my brains point to the popup icon :) > Thinking about it I can't convince myself that making the nav dialog view > auto aware is really worth the effort since I think that dialog will rarely be > used and only then in specialised cases, the smaller "popup" is better for > quick navigation.(BTW another side effect of the nav per view allows you to > have "thumbnails" of the images currently opened, sorta like a icon box for > the images. I was thinking about adding the ability to "auto raise to top" when > the image in the nav dialog was clicked on . This should be the case when the > image is selected in the L&C&P dialog as well). True. > Also the info window shows the current pixel value of the cursor position. > If it is changed to be auto aware then you would have to click on an image > (to make it active) before the info window started to register info. > Normally you just move the mouse over the image and the info is displayed. > > Any thoughts? I use to toggle active images - it is very easy and space by default does nothing. It is also easy to reach. I'd like the info-window be auto aware. Does anyone else know any issues the change might introduce? Tig -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: Review and better --> Clean up and Re: Help System (fwd)
On Fri, Nov 12, 1999 at 08:11:15PM +0100, Olof S Kylander wrote: [zap] > > File Menu Toolbox > /File/-| > New > Open > > Acquire (We have to tell SANE) Also XSane (alternative gtk frontend to SANE, also works as a gimp plugin) I think they know about this, since at least the debian package for XSane-for-gimp-1.1 installs itself here already. Anyone with scanner check that out btw, it is really nice. Has lots of things to control, like black and white and gray point by clicking on spots of the image etc.. > > Preferences > > Dialogs > - > Doc Hist > > Quit > Xtns Menu > > /Xtns--| > Module Browser > DB Explorer > Plugin Details > > Help Menu > /Help--| > Help > Context Help (Shift-F1) > Tip of the day > About > > Select Menu > /select > (the same) > > AnimFrames > /AnimFrames > (the same) > > View Meny > /View > The same but add Undo History. If/When Nav, Info and Undo > History is "auto aware" move them to the dialog menu. > > > > I will skip the discussion this time just look into my old mail. I will > however comment on the changes in the "Suggestion". > > Marcs remark about the script location and "undo aware" makes total sense. > So I adopted his view and changed it. > > However I'm not after a "on the fly loader". I just want a simple (i.e not > load Gimp with bugs) way of handling/install all the scripts. Furthermore > most users don't want all scripts. Most of the time you only want a > subset. > > The "Script Pack" script will simply enable you to choose scripts which > will be installed under your .gimp directory if they are supported by your > Gimp configuration. This will solve the Perl thing once and for all and > ever body will be happy ;-). The script can even tell you that you don't > have e.g Perl-XFY installed and there for you will not be able to install > XXX script. Maybe it could also scan the plugin/script dirs for non.working scripts? Just an idea, tell me if it makes any sense.. > Simon's/Austin's remarks about the menus was also really good and I > adopted all of them except the Toy thing ;-). The Undo History is moved to > the view menu which is wise until it's "auto aware" which I BTW think is > mandatory! The Egg should perhaps be hidden again for the release? Aspirin, got any evil ideas? :) While we are at it, what do people think of patching the default session file (the one that gets installed by default) to open the following dialogs: - toolbox (yea, right :) - brushes (a lot of people have no clue how to change the brush size though we now have the indicators... perhaps this is not needed since we have those.. - Layers dialog (this is a very important part of Gimp anyway - Photoshop has it open by default too) - Palette with Visibone as the defaut (I think it is already?) - Other suggestions? I assume the problem is not knowing the screen resolution and thus where to place the dialogs? Is this worth doing? > PS: Sven I was a bit out in the blue when I talk about the mag tool. But > maybe we can make it possible to max zoom if you press . Doh! There is a mag _tool_ also! 8) I always use the shortcuts! Never really used it, except for checking out for the first time what it does .. :) Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: Review and better --> Clean up and Re: Help System (fwd)
On Fri, Nov 12, 1999 at 08:11:15PM +0100, Olof S Kylander <[EMAIL PROTECTED]> wrote: > However I'm not after a "on the fly loader". I just want a simple (i.e not > load Gimp with bugs) way of handling/install all the scripts. Furthermore > most users don't want all scripts. Most of the time you only want a > subset. I still fail to see the difference between what you call a script and a in normal plug-(in the python or perl case). Script-Fu scripts, OTOH, are not normal plug-ins. I also do not understand why the user might, say, not want to install some script-fu script but ALWAYS wants to install ALL plug.ins written in C. So are plug-ins written in C more useful by definition than scripts in script-fu? This is what you imply! > The "Script Pack" script will simply enable you to choose scripts which > will be installed under your .gimp directory if they are supported by your > Gimp configuration. Again, since there is no difference between a plug-in written in C or in perl, why not just use a "plug-in-pack" and manage your plug-ins with these? I think the overhead of finding out wether a given executable is a perl/python-plug-in or c is not worth the trouble. > This will solve the Perl thing once and for all and What's the perl thing, btw? > ever body will be happy ;-). The script can even tell you that you don't > have e.g Perl-XFY installed and there for you will not be able to install > XXX script. Just a note: this is how it's done (for perl) since more than half a year, with the exception of the tex and povray plug-ins. All others won't clutter the menu unless the necessary modules are found. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Review and better .......
>1: Most artist how works with a program like Gimp has more or less all >dialog open. E.g they arrange the workbench with the Image in the middle >and all the dialogs around. A Navigation window fits just fine into that >arrangements if it's auto aware. True. Each user places them as he likes, but most will end with lot of dialogs open (the wm's shade function is your friend, at least mine). >2: The artist above will then use the nav window not just for panning >(which you also can do with the middle mouse button or the popup window) >but most probably for a quick way of zooming in and out. This function is >the most important since it will allow you to have a quick view of really >big images or small images (that you work with in a large scale). Remember >all of us hasn't the opportunity to have a wheel mouse i.e all of us >working with a UNIX workstation. I use PCs, I have tested wheel mouses... no thanks. It is just a way to convert a useful button into "three" unuseful ones. Software that requires three buttons is a pain with this "cool" mouse, at least for me, becuase the middle button is a small bastard that moves forward and back when it wants. I am still trying to see a situation where the wheel does something that middle button can not. Scroll? Click, drag a bit and scroll in any dir, the more you drag the faster it goes (some software does that, others do as Gimp, which is not bad either). Zoom? The same as scroll. Combination zoom / pan? Key your hand near ctrl key (or any other modifier). 3D manipulation? Middle and drag gives you a two continue axis precise control. Well, forget all the ranting. I just want to say that three buttons is cool: MB1 for action, MB2 for view (zoom, pan, etc), MB3 for menu. >The above statements leads to the conclusion that you often need to >zoom in out quickly. That you have arrange your workspace to fit the >program and there for don't want additional dialogs for each image. It >there for very important to have a auto switch. Keybindings, typing fingers are faster than mouse. I use 12345 keys plus the key near 1 and versions with Ctrl (12345 zoom in to fixed ratio, ctrl+12345 out, extra key in / out in small steps). >If we now argue for the fact that is shouldn't be auto aware. Well to be >useful as a "icon" it must be much smaller. I don't say that Andy's >arguments are bad but I think a user/Artist is much more comfortable to >have only one nav window instead of one for each image he works with. She >then has to arrange his desk twice for each image. Further more she has >to bring up the dialog for each image that he works with. One nav window, like one L&C, is a good idea. With auto on / off and drop down menu to select like L&C (no icon needed here, I guess). My two Ecent, if someday we use them. ;] GSR
Re: Review and better .......
Hello Andy Yes I have thought of this a lot, your ideas are also well thought. My idea was to make the Nav as much Auto as the layer dialog. I.e you can switch it on and off. The main reason to make it auto aware is that: 1: Most artist how works with a program like Gimp has more or less all dialog open. E.g they arrange the workbench with the Image in the middle and all the dialogs around. A Navigation window fits just fine into that arrangements if it's auto aware. 2: The artist above will then use the nav window not just for panning (which you also can do with the middle mouse button or the popup window) but most probably for a quick way of zooming in and out. This function is the most important since it will allow you to have a quick view of really big images or small images (that you work with in a large scale). Remember all of us hasn't the opportunity to have a wheel mouse i.e all of us working with a UNIX workstation. The above statements leads to the conclusion that you often need to zoom in out quickly. That you have arrange your workspace to fit the program and there for don't want additional dialogs for each image. It there for very important to have a auto switch. If we now argue for the fact that is shouldn't be auto aware. Well to be useful as a "icon" it must be much smaller. I don't say that Andy's arguments are bad but I think a user/Artist is much more comfortable to have only one nav window instead of one for each image he works with. She then has to arrange his desk twice for each image. Further more she has to bring up the dialog for each image that he works with. Cheers Olof On Fri, 12 Nov 1999, Andy Thomas wrote: > Olof S Kylander:- Thanks for your summary of the problems in Gimp. > > I noticed the following on this list:- > > > * Make the Navigation window auto aware > > > I was trying to think what advantages having the nav window auto switch over > would do. The small "popup" area in the lower right hand corner already offers > a short cut to move around the currently active image so I think it would be > used for convenience. > > The current situation where the nav dialog is tied to the view (not image) > allows you to have many views open on an image an scroll around them > independantly (you dont have to selected and image to do that). I have used > this to compare parts of images. > > Thinking about it I can't convince myself that making the nav dialog view > auto aware is really worth the effort since I think that dialog will rarely be > used and only then in specialised cases, the smaller "popup" is better for > quick navigation.(BTW another side effect of the nav per view allows you to > have "thumbnails" of the images currently opened, sorta like a icon box for > the images. I was thinking about adding the ability to "auto raise to top" when > the image in the nav dialog was clicked on . This should be the case when the > image is selected in the L&C&P dialog as well). > > Also the info window shows the current pixel value of the cursor position. If > it > is changed to be auto aware then you would have to click on an image (to make > it active) before the info window started to register info. Normally you just > move the mouse over the image and the info is displayed. > > Any thoughts? > > > Andy. > > > > > [EMAIL PROTECTED] > >
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?)? 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. The user has instead a new "Script Installer" menu item in the Xtns menu. He can from there invoke the manager which will provide him with a list of install able "scripts" for his Gimp system (e.g the script will not include Python "Scripts" if that isn't supported). The user will also be informed that her Gimp environment isn't complete since she can't run e.g Perl "Scripts". Additional "Script Packs" not included in core Gimp can now be installed under e.g ..share/gimp/uninstalled_filters/utils when the "Script Installer" installer is executed it will search all dirs in ..share/gimp/uninstalled_filters/ and list avalibel "filters" in those directories that are supported by the Gimp system. Additional "Script Packs" of C plugins can also be release in this fashion. All we have to do is to make the plugin "autoconf" aware. As I said earlier we will need a plugin maintainer. This is anyway necessary since we now have around 250 plugins and I presume an equal amount of Perl-Fu, Python-Fu and Script-Fu functions. > Or is the script-pack meant to be something like "rpms", i.e. we make a > release tarball with only the "core" functionality and one or several extra > packs with the extension scripts/plug-ins? > > In that case, will we just define "filesets" for distributors? > > > I *think* you opted for the first alternative (everything in the tarball), > which would require us to write something like an extension pack manager > (a shell script? something with a gtk+ gui?). Well I think I have answered your question and yes a gui would be a nice thing even if it isn't necessary it will definitely be more user friendly. Cheers Olof
Re: Review and better --> Clean up and Re: Help System (fwd)
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?)? Or is the script-pack meant to be something like "rpms", i.e. we make a release tarball with only the "core" functionality and one or several extra packs with the extension scripts/plug-ins? In that case, will we just define "filesets" for distributors? I *think* you opted for the first alternative (everything in the tarball), which would require us to write something like an extension pack manager (a shell script? something with a gtk+ gui?). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
