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 -- 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)
On Fri, Nov 12, 1999 at 08:11:15PM +0100, Olof S Kylander wrote: [zap] File Menu Toolbox 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 toolbox/Xtns--| Module Browser DB Explorer Plugin Details Help Menu toolbox/Help--| Help Context Help (Shift-F1) Tip of the day About Select Menu image/select (the same) AnimFrames image/AnimFrames (the same) View Meny image/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 Ctrl. 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 -- 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 | |
