Re: Status of help system?

2000-05-18 Thread Michael Natterer

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?

2000-05-17 Thread Kevin Turner

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)

1999-11-20 Thread Olof S Kylander

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)

1999-11-20 Thread Olof S Kylander

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

1999-11-13 Thread Jarda Benkovsky

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)

1999-11-13 Thread Tuomas Kuosmanen

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

1999-11-12 Thread Austin Donnelly

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

1999-11-12 Thread Simon Budig

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)

1999-11-12 Thread Marc Lehmann

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

1999-11-11 Thread Tristan Tarrant

 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

1999-11-11 Thread Kevin Cozens

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

1999-11-11 Thread Daniel . Egger

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

1999-11-11 Thread Sven Neumann

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

1999-11-11 Thread Sven Neumann

 
 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

1999-11-11 Thread David Odin

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

1999-11-10 Thread Sven Neumann

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

1999-11-10 Thread Austin Donnelly

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

1999-11-10 Thread Tor Lillqvist

 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

1999-11-10 Thread Federico Mena Quintero

  - 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

1999-11-10 Thread Zach Beane - MINT

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

1999-11-10 Thread Marc Lehmann

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

1999-11-10 Thread Marc Lehmann

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

1999-11-09 Thread Sven Neumann

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

1999-11-09 Thread Nick Lamb

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

1999-11-08 Thread Marc Lehmann

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

1999-11-03 Thread Sven Neumann

 
 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

1999-11-02 Thread 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 ??


Salut, Sven




Re: Review and better -- Clean up and Re: Help System (fwd)

1999-01-16 Thread Marc Lehmann

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

1999-01-02 Thread Tor Lillqvist

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