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: Clean up and Re: Help System
Hello Sven Nope go a head > BTW: would someone object against getting rid of the possibility to > disable cursor changes?? This would close a bug w/o too much hassle > and I don't see why someone would want to disable cursor updating > anyway... > > >
Re: Clean up and Re: Help System
> I can make some more cursors if people think this is ok to implement before > 1.2 ? Even if we decide that enabling zoom on middle-mouse button is not worth the risk to put it in before 1.2, the cursors could need some work. IMHO the selection cursors should just be the normal cursor plus the + or - sign. Alternatively we could make the standard selection cursor the triangle that is used with the +, -, u right now. And as I said before, the intersect cursor of the path tool needs to changed. There are other places where standard gdk cursors are used now that would benefit from better-suited cursors. Salut, Sven BTW: would someone object against getting rid of the possibility to disable cursor changes?? This would close a bug w/o too much hassle and I don't see why someone would want to disable cursor updating anyway...
Re: Re: Clean up and Re: Help System
On Fri, Nov 12, 1999 at 05:48:48PM +0100, Guillermo S. Romero / Familia Romero wrote: > >Just an idea: middle mouse-button is panning, why not Shift-middle > >button = Zoom Out and ctrl middle-button = zoom in. (Personally I'd > >prefer it the opposite: Shift: Zoom In, CTRL: Zoom out, but I cannot > >tell you why, it seems more logical for me...) > >Maybe using alt for allowing window resizing is a good idea. > > Cool idea! Zoom in and out, with window resizeing or not, just by clicking > middle button with some keys! Really fast way to work. No more changing > tools. I vote YES. I knew that middle mouse could do more, you have > discovered it now. Pan and zoom all in one are perfect... damn, a 3D I know > does the same (plus rotate view, after all it is 3D), and I did not propose > it before. Actually Freehand 8 does just this. Space is for panning (Mac mouses have only one button so you cannot put that to mousebutton 2 :) But presing shift _and_ Option (used often in Mac like Alt in PC) toggles zoom-in with cursor turning to a hourglass -> ==-(+) Pressing space-option-command (command is usually equiv. to Ctrl on mac) does the opposite, zoom out, cursor is ==-(-) It makes a lot of sense, speeds up the work. I can make some more cursors if people think this is ok to implement before 1.2 ? Tig -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
Re: Help System
On 11 Nov, Marc Lehmann wrote: > The difference (IMHO) is that a help system is an integral part of the > gimp, just like menus, a good ui design or the tooltips are. IMHO the best solution would be to leave everything out of GIMP that isn't really necessary for running, including help, catalogs and a lot of plug-ins. For these we should have extra packages like gimp-german.tar.gz, gimp-english.tar.gz gimp-japanese.tar.gz and gimp-fancy-plugins.tar.gz, gimp-often_used-plugins.tar.gz and so on which gives the user the possibility to get all the features he/she wants without the need to download a single 50 MB package and then having online help on its system (possibly in some curious language) he/she never wanted... -- Servus, Daniel
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: Help System
Marc Lehmann wrote: > > On Wed, Nov 10, 1999 at 05:48:34PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > > Quite right. And to paraphrase what I wrote in a previous message, > > there is nothing wrong in having an _optional_ dependency on GNOME ... > The difference (IMHO) is that a help system is an integral part of the gimp, > just like menus, a good ui design or the tooltips are. Hi, what about this solution to the help browser problem: make it a plugin (or module). You could make a plugin for each variant. One plugin would start user-configurable web browser Second would run GtkXmHtml Third would run gnome help browser (if it uses html) The plugins would register under /... and the user would select a preferred one in setup. If the configured one is not found, the first registered is used instead. I hope that this is solution that would work for everyone. Regards, Edheldil
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 | |
Review and better --> Clean up and Re: Help System (fwd)
Hello Folks I got some feedback about the "Clean up" nearly all of them well written and with good points. I there for rewrote the main "todo" list and post it again for confirmation/evaluation. Here is my list of minor things to clean up and make better (Without breaking the freeze). First the list and then the discussion below it. * Use PS mod and extend it to fit Gimp specific functions. * Don't install any scripts by default (This means all scripts even Script-Fu scripts) * Make a script pkg with Script-Fu, Perl-Fu and Py-Fu scripts * Keep both Perl and Python as a part of std Gimp * Exception install copy-visible --> /copy/ install drop-shadow --> /filter/render/shadow install perspective-shadow --> \ /filter/render/shadow Those script must me "UNDO AWARE" i.e using gimp-undo-push-group-[start,stop] * The Script Pack * Make all small script "UNDO ENABLED" * Install those script in a sensible location not just under a general Script entry *Scripts under Xtns naturally don't need to be "undo aware"! * All Script in Xtns should be under the a top Script entry. Under the script entry the scripts has to be sorted/grouped in a sensible way. * All Script in the menu that aren't "UNDO ENABLED" should be under a top Script entry. Under the script entry the scripts has to be sorted/grouped in a sensible way. * Make the "Script Pack" install script control your config and only install scripts that works * Make it possible to e.g only install Perl-Script or e.g logo-scripts etc. * The "Script Pack" install script should preferably be a shell script avalible from the Xtns menu. When you access it a xterm will popup with some "menus" where you can choose your action. * Move/transform selections * Change move selection to actually move the selection (i.e make Gimp PS compatible) * Make Move behave as old Gimp move * Postpone trans selections to next Gimp rel (i.e 1.3) * Make all numeric input fields spin-button aware (Well Mitch wanted to do the job ;-) * Make the Info window auto aware (i.e switch to the active image) * If possible add status bar and measure info to Info Window * Make the Undo history window auto aware * Make the Navigation window auto aware * Reconstruct the menu structure Core gimp funcs Image menu /Image/-Mode-| |RGB |Grayscale |Indexed |--- |Compose |Decompose | Color--| |ColorBalance |Hue-Saturation |Brightness-Contrast |Threshold |Levels |Curves |-- |Desaturate |Posterize |Invert |-- |Auto --| |-- Equalize |Colormap Rota Auto-Stretch Contrast |Filter PackAuto-Stretch HSV | Color Enhance | Alpha (the same) | Transform--| | Offset | (Remove layer) | Auto-crop | Guillotine | Image -- Rotate (270/90) | Rotate (no layer option) | Zealous Crop | --- Canvas Size Scale Image Duplicate --- Histogram Save palette Edit Menu /Edit/---| Undo Redo Cut Copy Paste Paste into
Re: Re: Clean up and Re: Help System
>Just an idea: middle mouse-button is panning, why not Shift-middle >button = Zoom Out and ctrl middle-button = zoom in. (Personally I'd >prefer it the opposite: Shift: Zoom In, CTRL: Zoom out, but I cannot >tell you why, it seems more logical for me...) >Maybe using alt for allowing window resizing is a good idea. Cool idea! Zoom in and out, with window resizeing or not, just by clicking middle button with some keys! Really fast way to work. No more changing tools. I vote YES. I knew that middle mouse could do more, you have discovered it now. Pan and zoom all in one are perfect... damn, a 3D I know does the same (plus rotate view, after all it is 3D), and I did not propose it before. GSR
Re: [gimp-devel] Re: Clean up and Re: Help System
Sven Neumann ([EMAIL PROTECTED]) wrote: > > Magnify: > > zoom out > > ---> zoom in > > Isn't it just always Zoom In (I mean unless is pressed of course)? Just an idea: middle mouse-button is panning, why not Shift-middle button = Zoom Out and ctrl middle-button = zoom in. (Personally I'd prefer it the opposite: Shift: Zoom In, CTRL: Zoom out, but I cannot tell you why, it seems more logical for me...) Maybe using alt for allowing window resizing is a good idea. In a post 1.2 step we can make the Magnify tool behave the same and simply bind the middle mouse-button per default to the magnify-tool. Then you could assign arbitrary tools to the middle mb - for example to easily switch between the eraser and the paint tool. BTW: Shift middle-button + some dragging easily leads to artefacts when the paint tool is active! Apropos cleanup: What about removing the pencil and substitute it with a "hard edge" toggle in the Painbrush? Sometimes it is quite hard to convince the people to use the paintbrush instead of the pencil... Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Clean up and Re: Help System
On Friday, 12 Nov 1999, Sven Neumann wrote: > > Here is my list of minor things to clean up and make better (Without > > breaking the freeze). First the list and then the discussion below it. > > > > YES!! I also like the new layout. It seems more consistent. I'm not sure about leaving out all the script-fu's. I'm worried about people complaining that stuff that always used to be there isn't there anymore. Also, is there really a need to group scripts by the interpreter they run under? I don't think so. You wouldn't put shell scripts in /usr/bin/sh-scripts/, but perl scripts in /usr/bin/perl-scripts/, would you, so why make the distinction in gimp? If the script works, a user shouldn't need to know which language it's written in. Austin
Re: Clean up and Re: Help System
> > Here is my list of minor things to clean up and make better (Without > breaking the freeze). First the list and then the discussion below it. > YES!! I do especially like the new menu hierarchy you suggested. Any volunteers for this job? > > PS: Sven I think this need to be added to your list. > > Magnify: > zoom out > ---> zoom in > Isn't it just always Zoom In (I mean unless is pressed of course)? Salut, Sven
Re: Help System
On Thu, Nov 11, 1999 at 09:03:46PM +0100, Marc Lehmann wrote: > On Thu, Nov 11, 1999 at 02:50:18AM +0100, David Odin <[EMAIL PROTECTED]> wrote: > > I don't think I'm alone, since nobody complain about gimp perl any more > > these days. > > They don't? Then why do I get so many complaints? ;) > At least, on this list, I don't really see complaints but only unproductive things as : 'This damned gimp-perl thing doesn't work'. I don't see complaints here but just silly people. > Indeed the installation is still very problematic, but unfortunately > most of the problems are not under my control (and also affect all other > non-trivial plug-ins like python or tiff_load/save). > Once the installation has been done right once, everything goes right though. > > In any case, it is extremely nice to get a letter like yours from time to > time ;) > I guess! I'm just fed up reading people's messages that just says your work is bad. I wanted to say that I think you're work is valuable. Even if it needs some polishing. Oh, I have one complaint to make: I wanted to try the /Filter/Map/Xach Blocks script, just to see what it does. Unfortunately, it fails with this error : xacklego.pl: Unable to grok '0' as colour specifier at /usr/local/lib/gimp/1.1/plug-ins/xachlego.pl line 77 (ERROR) The line in question is: $gridlayer->plug_in_grid($blocksize, $blocksize, 0, 0); I don't know if you're the one who maintain this script, but you may want to know. Regards, DindinX -- [EMAIL PROTECTED] If you have nothing to do, don't do it here.
Re: Help System
Hi, > >>Why not allow the user to choose his/her browser of choice ? > >>With Netscape, Mozilla, the Gnome Help Browser, kfm, or even > >>Lynx in an xterm as possible choices, I don't see any problem with this... > > > >So Gimp help should be a set of HTML files and a small exec to launch the > >preferred browser (calling process already running if needed, a la moz > remote). > > You beat me to it. I was about to suggest that the simplest solution is to > create simple HTML files for use as help and let the user use whatever > browser they prefer to use in order to view the help files. This is > essentially what is done in a Windows based HTML editor known as > Dreamweaver (as if you really care what a Windows program does :-). > It was never questioned that the Gimp help should be simple html files and I wonder who ever said that the user will be tied to one browser to use the help. It is true that there's not yet a possibility to specify a different browser, but who has said that this can't be implemented... The reason why we think that a gimp helpbrowser is important to have is that it can and should be a very small and fast browser. Small doesn't only mean memory footprint here, but also screen estate. I'm sure that a lot of people will prefer the helpbrowser plug-in over the browser they use for the web or the gnome-helpbrowser (which is much too fat for our needs). Gimp should provide a simple helpbrowser so help is available for everyone. I don't insist on using GtkXmHtml for it and will have a look into porting the existing browser to GtkHtml. But anyway, we will have to find a solution on how to integrate or distribute the HTML widget. Salut, Sven BTW: You can even know use Netscape to use the help: Just drag the page title from the helpbrowser over into Netscape. Oops, I forgot you need the helpbrowser for that ;-) that the user should be limited to
Re: Help System
On 10 Nov, Raphael Quinet wrote: > So please stop complaining about the help system, because that could > backfire on Gimp-Perl quickly... No flamewars, please. Let us concentrate on our work instead of pushing our energies in a thread which as useless as Win 3.11 ... :)) -- Servus, Daniel
Re: Help System
On 10 Nov, Kevin Cozens wrote: > Reading the discussions re: the help system has made me think I > understand why compiling GIMP always broke at a point where it needed > a GtkXmhtml header file. I use a RedHat system without Gnome installed > and I'm beginning to understand that GtkXmhtml is a Gnome thing. I > recently upgraded to the latest glib and gtk+ as I thought what I was > missing was something that was added to a version of gtk+ more recent > than I had. The name of GtkXmhtml now seems to be misleading as it > appears not to be part of the base gtk+ libraries. By the way: you all are aware that GtkXmhtml is something that is due to be remvod from gnome-libs, right? I would like to offer stripping it down to our needs. Then we could bundle it together with an helpmodule for GIMP and the documentation. So we don't pollute our mainstream GIMP archive; help is only available to people who installed the right package Comments? -- Servus, Daniel
Re: Help System
>>Why not allow the user to choose his/her browser of choice ? >>With Netscape, Mozilla, the Gnome Help Browser, kfm, or even >>Lynx in an xterm as possible choices, I don't see any problem with this... > >So Gimp help should be a set of HTML files and a small exec to launch the >preferred browser (calling process already running if needed, a la moz remote). > >GSR You beat me to it. I was about to suggest that the simplest solution is to create simple HTML files for use as help and let the user use whatever browser they prefer to use in order to view the help files. This is essentially what is done in a Windows based HTML editor known as Dreamweaver (as if you really care what a Windows program does :-). Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg
Re: Help System
On Thu, 11 Nov 1999, Tristan Tarrant wrote: > If you want small there is also Gzilla which could be resurrected. Gzilla has already been resurrected. It changed names in the process, and is known as armadillo now. It still lives at http://www.gzilla.com/ though. later, Andrew Kieschnick
Re: Help System
> Well thats why we want to have only GtkXmHTML installed and only if it's > needed. GtkXmHTML is on its way out. Check out the gtkhtml module in CVS. The only dependency on Gnome is for the test application and the bonobo component. Otherwise it looks like plain GTK+ stuff to me. > It's not wise words (it totally ¤%#"#¤% #¤!23 words ;-). Even with the smiley I find that insulting. > This leaves us only one option if we want to be independent of a lot of > _really_ big packages. If you want small there is also Gzilla which could be resurrected. Tristan
Re: [gimp-devel] Re: Help System
I am not an active developer on Gimp, so I realize my words won't have much weight here. However, this discussion of the help-system seems silly to me. > On Wed, Nov 10, 1999 at 12:26:58PM +0100, Simon Budig <[EMAIL PROTECTED]> >wrote: > > in the Gnome-Libs, because some people refuse to install gnome > > (I dont know why, but there are those people...) > > Here is a good reason: gnome is large. TOO LARGE. And if you do not want > to use the gui it is a big price to pay just for a simple help window. Just to cast some perspective on all this "anti bloat" ranting: [glyph@helix ~]$ du -chs `rpm -ql gnome-libs` `rpm -ql gnome-libs-devel` | tail -1; du -chs /opt/gimp | tail -1 22M total 52M total (also, GNOME's `lib' directory is 39M all by itself, and note that this is with perl disabled -- perl stuff won't install into an alternate --prefix anyway) In order to be fair, I included all the development stuff from gnome, but from the user's perspective, Gimp is *much* larger than GNOME, considering that GNOME has much more stuff in the -devel package. You might argue that there are more packages to GNOME than that, but on the other hand, GNOME is much more modular than Gimp. GNOME *IS* doing something with all that space. X does not constitute a consistent or friendly UI, and neither does GTK. Something like a consistent help-system is beyond the scope of the GIMP. It should not have its own. I understand you want something cleanly integrated into the UI, but (I know *everybody* doesn't run GNU, or Linux, but it is becoming a significant plurality) the users who will need the most interface help are newbies who are running GNOME desktops from redhat. Or, perhaps they will have KDE -- but how well would Gimp really integrate w/ kdehelp? Is it really a good idea to ask the user to learn how to use a different help-system for every application they install? One per environment seems quite enough. If you want to write a *better* help browser than the one that comes with GNOME, start a project to write a help-browser, don't integrate it with Gimp. Then, have Gimp install some help-files for that browser. I don't like any of the help-systems that are out there today terribly much (has anybody ever used any of the MacOS help systems? AppleGuide, Baloon Help, et. al.? Now *that* is a classy help system, not just a bunch of html files lying around...) but I don't want an application-specific system, and I can't think of any user that would. Just my $0.08 :-) --glyph
Re: Clean up and Re: Help System
On Thu, Nov 11, 1999 at 01:11:54AM +0100, Olof S Kylander <[EMAIL PROTECTED]> wrote: > * All Script in Xtns should be under ZZ-Fu > (ZZZ == Lang) I strongly disagree. From a usability perspective this is nonsense. It might be nice for a user to know whom to blame for the script (but the language does not help much), but otherwise the user just has to memorize one fact more. It's difficult enough to remember wether a plug-in belongs to (e.g.) xtens/render or xtns/draw. Having to remember the language in which the plug-in is written (which means _nothing_ to most users) is only an additional burden. > all scripts - Gimp's menu structure will be expanded by "two", > making it even more bulky to work with. The fact that > small scripts that can be "undo awar"e are placed in non logical place > (i.e under Script-XX. Makes scripts even more messy to use. While this is mostly true, some perl scripts are very useful to all users. the problem is that the expensive of installing gimp-perl to "just" get a few standard plug-ins is relatively high. But there are worse things than that... PS: I have not _yet_ read your whole mail, but I seem to agree with the rest ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
On Wed, Nov 10, 1999 at 02:26:13PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > Solaris 2.6 machine that I use for most of my GIMP work. If you do > not want the help system to be part of the standard GIMP package I have never said that... I _do_ want a help system, but fact is that we do not have one. Gimp-perl tries to compile on every system where perl is installed, which is a much larger number than the machines that have gnome installed. And, btw., I _really_ like to fix any installation bugs, but it works fine on my machine and all machines I have access to. It also works on all machines where people had problems (which were operator errors or bugs that are now fixed). However, most people "here" just refuse to even try it, since it did not work many months ago. Bugs are natural, especially in gimp-perl where NOBODY is helping me. What makes me sad most is that people like Nick just flame around without even trying to help. If people post bug reports on this list or to me privately they will get all help from me that I cna offer. But bugs are not going to get fixed if they are never getting reported. > I disagree. Perl _does_ work on many platforms, but you cannot say the > same about Gimp-Perl. The latter only works on _very_few_ platforms, > because it requires a recent version of Perl (the majority of machines > that I have access to are using a Perl that is more than two years old), This is FUD: 5.004 is over two years old, and definitely not the most recent version of perl. > with some third-party modules such as PDL, Parse::RecDescent, Gtk-Perl. Gimp-Perl works fine without any of these modules. Gtk-Perl is highly recommended, PDL is nice, and nobody needs Parse::RecDescent. > These modules do not compile cleanly on some systems: PDL worked for > me under Linux, but not under Solaris where many self-tests failed. So just do not install it. What's the deal? > Also, the fact that Perl uses a different set of "configure" rules and > "prefix" directories means that it is not easy or not possible for > someone to compile a private copy of the GIMP (with Gimp-Perl enabled) > on a multi-user system if that person does not have write access to > the site-perl directories. This is a common problem with any perl module. The solution is also the same as with any other perl module. You can even choose your own prefix with --enable-perl=...prefix, but obivously it is much easier to just claim things (look at yourself) than to read the documentation. > So please stop complaining about the help system, because that could > backfire on Gimp-Perl quickly... Why don't you stop spreading FUD? While your view is not 100% wrong, most of it is FUD and nothing else. There are many problems (gimp-perl is a very complex thing), but given that almost nobody is trying to help me I think the result is actually quite good. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: [gimp-devel] Re: Help System
On Wed, Nov 10, 1999 at 12:26:58PM +0100, Simon Budig <[EMAIL PROTECTED]> wrote: > in the Gnome-Libs, because some people refuse to install gnome > (I dont know why, but there are those people...) Here is a good reason: gnome is large. TOO LARGE. And if you do not want to use the gui it is a big price to pay just for a simple help window. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
On Wed, Nov 10, 1999 at 05:48:34PM +0100, Raphael Quinet <[EMAIL PROTECTED]> wrote: > Quite right. And to paraphrase what I wrote in a previous message, > there is nothing wrong in having an _optional_ dependency on GNOME > just like we have an _optional_ dependency on Gtk-Perl and other > Perl stuff. The difference (IMHO) is that a help system is an integral part of the gimp, just like menus, a good ui design or the tooltips are. If any plug-in is missing (or even the 20+ perl plug-ins), this does not affect usability. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
On Wed, Nov 10, 1999 at 04:23:02AM +, Nick Lamb <[EMAIL PROTECTED]> wrote: > Well, PERL certainly works on a lot of platforms, but Sven was talking > about the supposed GimpPerl included in CVS Gimp. Yes. However, the number of platforms and machines where gnome is installed is still very small. > AFAICT Everyone just We all know that you rarely know what you are talking about ;-) > will go away. It won't work on my home machine (Slack upgraded to 2.0) > or my old work machine (RH 5.2) or my new work machine (RH 6.1) so I > guess it's not working for many people at all. It works for the 242 subscribers to the gimp-perl users list. Not a large number by absolute means, but it shows that it can't be that bad... However, since you are obviously not interested in helping the develiopment, wehy don't you just keep quiet? This is just anti-social, and you know that. > Of course, I know it's not a BUG that GimpPerl won't work out-of-box on > any reasonable system, I'd say it's definitely a bug if this would be the case. However, if people forget to run ldconfig or install more than one gimp/gtk version in the same prefix I would not count this "reasonable". > but it's also not a BUG that GimpHelp won't work > out-of-box on fairly old systems. gimphelp will not work on _any_ system that has no gnome. That's independent of age. > /me goes back to fixing bits of Gimp HE thinks are important Hear hear.. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
On Wed, Nov 10, 1999 at 11:10:14AM -0500, Federico Mena Quintero <[EMAIL PROTECTED]> wrote: > > The GIMP should really use the GNOME help browser instead of > reinventing the wheel. At the moment, this is the only viable way. Since we _require_ gnome for the help system it makes no sense to duplicate their work. However, in the long run, Gimp requires it's own help system. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
Hello On Wed, 10 Nov 1999, Guillermo S. Romero / Familia Romero wrote: > >> > The GIMP should really use the GNOME help browser instead of > >> > reinventing the wheel. > >> Will it be possible to get just the wheel without the rest of the car? > >Maybe I'm not the right person to say this, but WTF... > >What is the matter with the GIMP developers ? What is this adversion to > >GNOME ? > > I am feed up of having to install full packages just to get one thing. With > some distros, this becomes even worse. And as I, there must be more people. Well thats why we want to have only GtkXmHTML installed and only if it's needed. > >Why not allow the user to choose his/her browser of choice ? > >With Netscape, Mozilla, the Gnome Help Browser, kfm, or even > >Lynx in an xterm as possible choices, I don't see any problem with this... > > Now that are wise words: the user decides which browser. Lot of adventages, > and I do not see any disadventage (no HTML custom tricks? all HTML docs > should be "any browser", even if the browser is one with speaker for blind > people). > > So Gimp help should be a set of HTML files and a small exec to launch the > preferred browser (calling process already running if needed, a la moz remote). It's not wise words (it totally ¤%#"#¤% #¤!23 words ;-). Lynx is not doable (we need pictures)!!! Some may not want to install KDE or GNOME. Others may have not have a computer powerful enough to run both Gimp (at full speed) and Netscape/Mozilla at the same time or they maybe not want to install it. This leaves us only one option if we want to be independent of a lot of _really_ big packages. Cheers Olof
Clean up and Re: Help System
Hello Folks Yes, as Sven points out we can include GtkXmHtml and we can make a wiser configure script. The other part is that I just don't want to spend my free time to make a help system that is not a part of std Gimp. I mean it's totally idiotic to say "well if you want help ..." . When people want help, they want it ASAP not ALAP (as late as possible). On to the real tough question "to be or not to be UI consistent" ;-) Well Sven started a really nicely modkey thing (Shame on me since I said that I would help him doing it :-(. Well as Sven said it's a total mess! There are two ways do a "mod" key clean up. One we study the material and come up with our own list or we use e.g Photoshops. The reason to use PS once is (as said in a earlier mails) that the Adobe have done some serious usability test and found out what is really good and user friedly. The problem is that PS lacks some functions that Gimp has most notably the line preview when you draw in Gimp. PS can only do line painting in hor or vert mode plus arbitrary lines and all of them without preview. There are also some other misc funcs that can't be directly translated. My suggestion is to use PS mod and extend it to fit Gimp specific functions. Well, I said to Sven that I would make a suggestion about the UI and all the rest ;-). Here is my list of minor things to clean up and make better (Without breaking the freeze). First the list and then the discussion below it. * Use PS mod and extend it to fit Gimp specific functions. * Don't install any scripts by default (This means all scripts even Script-Fu scripts) * Make a script pkg with Script-Fu, Perl-Fu and Py-Fu scripts * Keep both Perl and Python as a part of std Gimp * Exception install copy-visible --> /copy/ install drop-shadow --> /filter/render/shadow install perspective-shadow --> \ /filter/render/shadow * The Script Pack * Make all small script "undo enabled" * Install those script in a sensible location not just under a general Script entry * All Script in Xtns should be under ZZ-Fu (ZZZ == Lang) * All Script in menu that aren't undo able should be under Z-Fu (Z == Lang) * Make the Script packs install script control your config and only installscripts that works * Make it possible to e.g only install Perl-Script or e.g logo-scripts etc. * Move/transform selections * Change move selection to actually move the selection (i.e make Gimp PS compatible) * Make Move behave as old Gimp move * Postpone trans selections to next Gimp rel (i.e 1.3) * Make all numeric input fields spin-button aware (Well Mitch wanted to do the job ;-) * Make the Info window auto aware (i.e switch to the active image) * If possible add status bar and measure info to Info Window * Make the Undo history window auto aware * Make the Navigation window auto aware * Reconstruct the menu structure Core gimp funcs Image menu /image/-mode-| |RGB |Grayscale |Indexed |Compose |Decompose | Color--| |ColorBalance |Hue-Saturation |Brightness-Contrast |Threshold |Levels |Curves |-- |Desaturate |Posterize |Invert |-- |Auto --| |-- Equalize |Colormap Rota Auto-Stretch Contrast |Filter PackAuto-Stretch HSV | Color Enhance | Alpha (the same) | Transform--| | Offset | (Remove layer) | Auto-crop | Guillotine | Image -- Rotate (270/90) | Rotate (no layer option) | Zealous Crop | --- Resize could be named Canvas size
Re: [gimp-devel] Re: Help System
At 13:49 10.11.99 +0200, Tor Lillqvist wrote: >> Maybe the time has come to fold GtkXmHtml into the main library. > >Ugh... cough, cough. Have you looked at the GtkXmHTML (or however it >should be capitalized) source code? One would hope GTk+ has higher >standards. Not to mention that the "Gtk" part of the GtkXmHTML name is >quite misleading, there are lots of direct Xlib calls. > .. but as suggested in a previous mail: >But I (or somebody) will probably eventually write a separate >winhelpbrowser plug-in for Windows that just uses the >user's default Web browser (Netscape or IE). The Windowze version is basically running. Maybe this approach (dynamic data exchange with the browser) could be used on most *IX systems as well, no matter if the browser is called by DDE, COM, CORBA ... You'll get all the nice formatting and image capabilities for free, or with only very few lines of code (approx. 100 in my help plug-in for win32). Hans (somebody) Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Help System
>> > The GIMP should really use the GNOME help browser instead of >> > reinventing the wheel. >> Will it be possible to get just the wheel without the rest of the car? >Maybe I'm not the right person to say this, but WTF... >What is the matter with the GIMP developers ? What is this adversion to >GNOME ? I am feed up of having to install full packages just to get one thing. With some distros, this becomes even worse. And as I, there must be more people. >Why not allow the user to choose his/her browser of choice ? >With Netscape, Mozilla, the Gnome Help Browser, kfm, or even >Lynx in an xterm as possible choices, I don't see any problem with this... Now that are wise words: the user decides which browser. Lot of adventages, and I do not see any disadventage (no HTML custom tricks? all HTML docs should be "any browser", even if the browser is one with speaker for blind people). So Gimp help should be a set of HTML files and a small exec to launch the preferred browser (calling process already running if needed, a la moz remote). GSR
Re: Help System
On Wed, 10 Nov 1999, Tristan Tarrant <[EMAIL PROTECTED]> wrote: > Zach Beane - MINT wrote: > > > The GIMP should really use the GNOME help browser instead of > > > reinventing the wheel. > > > > Will it be possible to get just the wheel without the rest of the car? > > Maybe I'm not the right person to say this, but WTF... > What is the matter with the GIMP developers ? What is this adversion to > GNOME ? Quite right. And to paraphrase what I wrote in a previous message, there is nothing wrong in having an _optional_ dependency on GNOME just like we have an _optional_ dependency on Gtk-Perl and other Perl stuff. The best solution IMHO would be to use the GNOME help browser if it is available and to revert to a standard web browser if the GNOME libs are not installed. This would allow the GIMP to benefit from whatever nice features the GNOME help browser might have in the future, while still allowing GNOME-less people to look at the help files in Netscape or Opera or Lynx or ... -Raphael
Re: Help System
Zach Beane - MINT wrote: > > The GIMP should really use the GNOME help browser instead of > > reinventing the wheel. > > Will it be possible to get just the wheel without the rest of the car? Maybe I'm not the right person to say this, but WTF... What is the matter with the GIMP developers ? What is this adversion to GNOME ? Why not allow the user to choose his/her browser of choice ? With Netscape, Mozilla, the Gnome Help Browser, kfm, or even Lynx in an xterm as possible choices, I don't see any problem with this... Just my 2.000.000 EUR. Tristan
Re: Help System
On Wed, Nov 10, 1999 at 11:10:14AM -0500, Federico Mena Quintero wrote: > > - Help us to make a seperate version of GtkXmHtml that compiles on a lot > >of setups and fix the Gimp configure script. > > Just so you know, GNOME is dropping GtkXmHTML because it is no longer > being maintained and is not very good in general. Anders is working > on a very nice GtkHTML widget, and the new GNOME help browser will use > it while Mozilla will hopefully be finished somewhere in the next millenium. > > The GIMP should really use the GNOME help browser instead of > reinventing the wheel. Will it be possible to get just the wheel without the rest of the car? Zach -- Zachary Beane [EMAIL PROTECTED] PGP mail welcome. http://www.xach.com/pgpkey.txt
Re: Help System
> - Help us to make a seperate version of GtkXmHtml that compiles on a lot >of setups and fix the Gimp configure script. Just so you know, GNOME is dropping GtkXmHTML because it is no longer being maintained and is not very good in general. Anders is working on a very nice GtkHTML widget, and the new GNOME help browser will use it while Mozilla will hopefully be finished somewhere in the next millenium. The GIMP should really use the GNOME help browser instead of reinventing the wheel. Federico
Re: Help System
On Wed, 10 Nov 1999, Marc Lehmann <[EMAIL PROTECTED]> wrote: > Either we have a help system or we haven't. At the moment, we haven't. I'd > like to use it myself, but I don't want to install a useless gnome just > for that. As Sven mentioned, you could say exactly the same thing about Gimp-Perl. Both the help system and Gimp-Perl fail to compile on the Solaris 2.6 machine that I use for most of my GIMP work. If you do not want the help system to be part of the standard GIMP package, then I would definitely recommend to also move Gimp-Perl out of that package. By the way, you do not have to install the whole GNOME system, but only the gnome-libs package. These libraries do not take much disk space. Less than Perl, for example. ;-) [...] > > All we have to do is to solve the packaging/configure problems. > > Do you expect this to be solved before 1.2? That would be nice. > > > A help system that only works by chance (i.e. not on the majority of > > > platforms) is not work the hassle. > > > > s/help/perl/ > > However, perl works on many _many_ more platforms than the help system, > which only works on a very limited number of systems. I disagree. Perl _does_ work on many platforms, but you cannot say the same about Gimp-Perl. The latter only works on _very_few_ platforms, because it requires a recent version of Perl (the majority of machines that I have access to are using a Perl that is more than two years old), with some third-party modules such as PDL, Parse::RecDescent, Gtk-Perl. These modules do not compile cleanly on some systems: PDL worked for me under Linux, but not under Solaris where many self-tests failed. Also, the fact that Perl uses a different set of "configure" rules and "prefix" directories means that it is not easy or not possible for someone to compile a private copy of the GIMP (with Gimp-Perl enabled) on a multi-user system if that person does not have write access to the site-perl directories. I am even tempted to say that if you take a machine with a "default" Linux installation or any other UNIX-like OS, it is easier to get the help system running (by installing gnome-libs) than to get Gimp-Perl running (by upgrading Perl and installing the required modules). So please stop complaining about the help system, because that could backfire on Gimp-Perl quickly... -Raphael
Re: [gimp-devel] Re: Help System
> Maybe the time has come to fold GtkXmHtml into the main library. Ugh... cough, cough. Have you looked at the GtkXmHTML (or however it should be capitalized) source code? One would hope GTk+ has higher standards. Not to mention that the "Gtk" part of the GtkXmHTML name is quite misleading, there are lots of direct Xlib calls. --tml
Re: [gimp-devel] Re: Help System
Austin Donnelly ([EMAIL PROTECTED]) wrote: > On Wednesday, 10 Nov 1999, Sven Neumann wrote: > > - Grab GtkXmHtml seperately. This is difficult at the moment, but I was > > told that the gEdit application offers a seperately bundled one. > > If gEdit needs GtkXmHtml, and so does Gimp, does this not mean there's > a real requirement to make GtkXmHtml a standard part of libgtk? > > Maybe the time has come to fold GtkXmHtml into the main library. We > should talk to the gtk people. Tim, Owen? IMHO there is a lot of things, that should be reorganized in the GLib/Gtk/Gnome-field. Higher-level widgets like Gnome-Canvas and GtkXmHtml should go in a separate library, since Gtk is already a huge library and those very specialized widgets are not useful for the average application. Gnome Canvas is so useful, it should not be in the Gnome-Libs, because some people refuse to install gnome (I dont know why, but there are those people...) Also the Object Model in Gtk should go in the glib package. Things like the signal-handling can be useful in Non-Gui applications and I dont want to link against Gtk for a console-tool... Just my 2 Pf, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/
Re: Help System
On Wednesday, 10 Nov 1999, Sven Neumann wrote: > - Grab GtkXmHtml seperately. This is difficult at the moment, but I was > told that the gEdit application offers a seperately bundled one. If gEdit needs GtkXmHtml, and so does Gimp, does this not mean there's a real requirement to make GtkXmHtml a standard part of libgtk? Maybe the time has come to fold GtkXmHtml into the main library. We should talk to the gtk people. Tim, Owen? Austin
Re: Help System
Hi, > The idea of a help system as part of GIMP sounded interesting and I had > hoped to try it out and comment on it but I now discover I won't be able > to do so. There are many things you can do about this: - Install the gnome-libs package. This will not change your desktop into a gnome one, but install a set of useful libraries that you will want to use anyway sooner or later. I must admit that this is not a solution for non-Linux users as getting gnome-libs to compile is not trivial. - Grab GtkXmHtml seperately. This is difficult at the moment, but I was told that the gEdit application offers a seperately bundled one. - Help us to make a seperate version of GtkXmHtml that compiles on a lot of setups and fix the Gimp configure script. Salut, Sven
Re: Help System
On Wed, Nov 10, 1999 at 12:36:34AM -0500, Kevin Cozens wrote: > The idea of a help system as part of GIMP sounded interesting and I had > hoped to try it out and comment on it but I now discover I won't be able to > do so. Why not? Nick.
Re: Help System
Reading the discussions re: the help system has made me think I understand why compiling GIMP always broke at a point where it needed a GtkXmhtml header file. I use a RedHat system without Gnome installed and I'm beginning to understand that GtkXmhtml is a Gnome thing. I recently upgraded to the latest glib and gtk+ as I thought what I was missing was something that was added to a version of gtk+ more recent than I had. The name of GtkXmhtml now seems to be misleading as it appears not to be part of the base gtk+ libraries. I run the autoconf.sh without any parameters on the command line. I supposed I expected it would detect whether I had gnome on my machine or not. I simply used 'make -i' to get a successful compile of GIMP. I will add --without-gnome to the command line of the configure scripts from now on and see if that avoids it trying to build the help system. The idea of a help system as part of GIMP sounded interesting and I had hoped to try it out and comment on it but I now discover I won't be able to do so. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include | -Pinkutus & the Borg
Re: Help System
On Tue, Nov 09, 1999 at 04:57:16PM +0100, Sven Neumann wrote: > > s/help/perl/ On Wed, Nov 10, 1999 at 03:09:46AM +0100, Marc Lehmann wrote: > However, perl works on many _many_ more platforms than the help system, > which only works on a very limited number of systems. Well, PERL certainly works on a lot of platforms, but Sven was talking about the supposed GimpPerl included in CVS Gimp. AFAICT Everyone just types ./autogen.sh --disable-perl and hopes that sooner or later it will go away. It won't work on my home machine (Slack upgraded to 2.0) or my old work machine (RH 5.2) or my new work machine (RH 6.1) so I guess it's not working for many people at all. Of course, I know it's not a BUG that GimpPerl won't work out-of-box on any reasonable system, but it's also not a BUG that GimpHelp won't work out-of-box on fairly old systems. /me goes back to fixing bits of Gimp HE thinks are important Nick.
Re: Help System
On Tue, Nov 09, 1999 at 04:57:16PM +0100, Sven Neumann <[EMAIL PROTECTED]> wrote: > Marc, please! You know that the situation we have now is not what we want it > to be in its final state. There are probably other good reasons to use Gnome > for later versions of Gimp, but nobody will be forced to use Gnome with > Gimp-1.2. Unless he wants to use the help sytem, which was my point. Either we have a help system or we haven't. At the moment, we haven't. I'd like to use it myself, but I don't want to install a useless gnome just for that. > Fact is it has a working help-system! Fact is I haven't ever seen it on my machine. Maybe this has something to do with the fact that I don't use gnome? Sven, I know "we" would like to have an unbundled GtkXmhtml or even some better solution. But we haven't, so we also haven't a help system. > All we have to do is to solve the packaging/configure problems. Do you expect this to be solved before 1.2? > > A help system that only works by chance (i.e. not on the majority of > > platforms) is not work the hassle. > > s/help/perl/ However, perl works on many _many_ more platforms than the help system, which only works on a very limited number of systems. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
Marc Lehmann wrote: > My very own personal opinion on this is: > > - either make gimp a gnome application (puke!). This would be honest, as we > are kind-of forcing gnome on people anyway (wanna help? use gnome!) Marc, please! You know that the situation we have now is not what we want it to be in its final state. There are probably other good reasons to use Gnome for later versions of Gimp, but nobody will be forced to use Gnome with Gimp-1.2. > - unbundle the help system (or don't ever claim the gimp would have such a > help system - fact is it doesn't work) Fact is it has a working help-system! All we have to do is to solve the packaging/configure problems. > A help system that only works by chance (i.e. not on the majority of > platforms) is not work the hassle. s/help/perl/ Salut, Sven
Re: Help System
On Wed, Nov 03, 1999 at 10:47:48AM +0100, Uwe Koloska <[EMAIL PROTECTED]> wrote: > Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally > systems without thread support) because it needs the threaded version of My very own personal opinion on this is: - either make gimp a gnome application (puke!). This would be honest, as we are kind-of forcing gnome on people anyway (wanna help? use gnome!) - unbundle the help system (or don't ever claim the gimp would have such a help system - fact is it doesn't work) A help system that only works by chance (i.e. not on the majority of platforms) is not work the hassle. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Help System
> > Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally > systems without thread support) because it needs the threaded version of > strok() strtok_r(). The latter one is new in glibc2 (aka libc6) an for the > gnome system it is doubled in gnomesupport. So to make GtkXmHTML compile on > systems without strtok_r() and without gnomesupport, we have to make our own > copy of this function. > If we would package GtkXmHTML seperately, it should be no problem to include the function with it. > > An easy solution for the guis that habe gnome installed ist to add > `-lgnomesupport' to GTKXMHTML_LIB in plug-ins/helpbrowser/Makefile > In a perfect world, gnome-config would add this flag for us. But since it appears to be broken, I think it's best to do as you suggested. Yosh, is this ok with you ?? Salut, Sven
Re: Help System
On Die, 02 Nov 1999 wrote the famous Sven Neumann: >Hi, > >> Except it doesn't seem to work on systems without GtkXmHTML installed. I >> don't have that on my systems Would it be possible for the build to recognize >> this and remove the Help option from the File menu? The current dialog that >> pops in these cases (no GtkXmHTML) is fairly confusing to those who aren't >> developers. >> >> Is GtkXmHTML a GNOME only thing now? Can it be pulled from there either >> into the Gimp or (better) into GTK? > >Yes, it could be copied out of gnome-libs into The GIMP, but I'm not absolutely >happy with this solution. A lot of our users will have gnome-libs (you don't >need the core!!) installed anyway and GtkXmHTML will enlarge the GIMP >distribution even more. > >But having the help system installed everywhere is very important, so what I'd >propose is distributing GtkXmHTML as a seperate package. Any automake/autoconf >gurus out there that want to take the job ?? Consider that GtkXmHTML cannot be compiled on linux libc5 systems (or generally systems without thread support) because it needs the threaded version of strok() strtok_r(). The latter one is new in glibc2 (aka libc6) an for the gnome system it is doubled in gnomesupport. So to make GtkXmHTML compile on systems without strtok_r() and without gnomesupport, we have to make our own copy of this function. Maybe it is necessary to patch the gtkxmhtml-Source to avoid the use of strtok_r() on systems without thread support. An easy solution for the guis that habe gnome installed ist to add `-lgnomesupport' to GTKXMHTML_LIB in plug-ins/helpbrowser/Makefile > > >Salut, Sven Uwe -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
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 | |
Review and better --> Clean up and Re: Help System (fwd)
Hello Folks I got some feedback about the "Review and better" nearly all of them well written and with good points. I there for rewrote the main "todo" list and post it again for confirmation/evaluation. Here is my list of minor things to clean up and make better (Without breaking the freeze). First the list and then the discussion below it. * Use PS mod and extend it to fit Gimp specific functions. * Don't install any scripts by default (This means all scripts even Script-Fu scripts) * Make a script pkg with Script-Fu, Perl-Fu and Py-Fu scripts * Keep both Perl and Python as a part of std Gimp * Exception install copy-visible --> /copy/ install drop-shadow --> /filter/render/shadow install perspective-shadow --> \ /filter/render/shadow Those script must me "UNDO AWARE" i.e using gimp-undo-push-group-[start,stop] * The Script Pack * Make all small script "UNDO ENABLED" * Install those script in a sensible location not just under a general Script entry *Scripts under Xtns naturally don't need to be "undo aware"! * All Script in Xtns should be under the a top Script entry. Under the script entry the scripts has to be sorted/grouped in a sensible way. * All Script in the menu that aren't "UNDO ENABLED" should be under a top Script entry. Under the script entry the scripts has to be sorted/grouped in a sensible way. * Make the "Script Pack" install script control your config and only install scripts that works * Make it possible to e.g only install Perl-Script or e.g logo-scripts etc. * The "Script Pack" install script should preferably be a shell script avalible from the Xtns menu. When you access it a xterm will popup with some "menus" where you can choose your action. * Move/transform selections * Change move selection to actually move the selection (i.e make Gimp PS compatible) * Make Move behave as old Gimp move * Postpone trans selections to next Gimp rel (i.e 1.3) * Make all numeric input fields spin-button aware (Well Mitch wanted to do the job ;-) * Make the Info window auto aware (i.e switch to the active image) * If possible add status bar and measure info to Info Window * Make the Undo history window auto aware * Make the Navigation window auto aware * Reconstruct the menu structure Core gimp funcs Image menu /Image/-Mode-| |RGB |Grayscale |Indexed |--- |Compose |Decompose | Colors-| |ColorBalance |Hue-Saturation |Brightness-Contrast |Threshold |Levels |Curves |-- |Desaturate |Posterize |Invert |-- |Auto --| |-- Equalize |Colormap Rota Auto-Stretch Contrast |Filter PackAuto-Stretch HSV | Color Enhance | Alpha (the same) | Transforms-| | Offset | (Remove layer) | Auto-crop | Guillotine | Image -- Rotate (270/90) | Rotate (no layer option) | Zealous Crop | --- Canvas Size Scale Image Duplicate --- Histogram Save palette Edit Menu /Edit/---| Undo Redo Cut Copy Paste Paste into
Re: Help System
Uwe Koloska writes: > Consider that GtkXmHTML cannot be compiled on linux libc5 systems > (or generally systems without thread support) because it needs the > threaded version of strok() strtok_r(). Not to mention it's a bit impossible to build on non-X11 systems ;-) But I'm not complaining. But I (or somebody) will probably eventually write a separate winhelpbrowser plug-in for Windows that just uses the user's default Web browser (Netscape or IE). --tml
