Re: Status of help system?
Kevin Turner wrote: What is the status of the help system these days? Is there a help browser procedure which calls on extension_web_browser if the gtkxhtml browser is not available? Yes, Netscape is called it no help browser is found. How does the help system work for 3rd party plug-ins and scripts? This is on my todo. Will be a simple function gimp_help_register() which will take a directory name. The help files mentioned in gimp_dialog_new() etc. will be relative to this directory. There will also be a standard way for plug-ins which don't want to register their own help path. The canonical path for these plugins will be "$DATADIR/help/C/contrib/plug_in_name/whatever.html" Feel free to suggest a better word than "contrib", it was just the first which came to my mind. Can images be included in the help? If so, what are the naming conventions? As 3rd party plug-ins will have their own directory anyway, it's up to the plug-in's maintainer. A good choice maybe to prefix all help files for a plug-in with the plug-in's name and a underscore. bye, --Mitch
Status of help system?
What is the status of the help system these days? Is there a help browser procedure which calls on extension_web_browser if the gtkxhtml browser is not available? How does the help system work for 3rd party plug-ins and scripts? Do we need a grassroots effort to fill in the help files, or do Karin Olof have this one covered? Can images be included in the help? If so, what are the naming conventions? Just another one of those things to do before 1.2 final... -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here Plug-ins: They make GIMP do stuff. http://gimp-plug-ins.sourceforge.net/ This list is archived at http://marc.theaimsgroup.com/?l=gimp-developer To unsubscribe, mail [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?)? 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: 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 help/... 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 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: 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: [gimp-devel] Re: Clean up and Re: Help System
Sven Neumann ([EMAIL PROTECTED]) wrote: Magnify: Shift zoom out --- Ctrl zoom in Isn't it just always Zoom In (I mean unless Shift 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: 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: 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: 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 disclaimer/favourite| -Pinkutus the Borg
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
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: 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: Shift zoom out ---Ctrl zoom in Isn't it just always Zoom In (I mean unless Shift 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 Image/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, 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 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: [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: 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, 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: [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: 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
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 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 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
Help System
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 ?? Salut, Sven
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 | |
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