Re: Help files
On 30 Jul, Sven Neumann wrote: >> Sorry, this page hasn't been written in yet. Would you >> like to read this help in instead? > As you might have noticed the creators of the help system have already > thought about that. The current help-system does not yet support > multi-language help files, but the current directory structure and the > code should allow to add this feature anytime with little effort. Our > plan so far was to use a simple shell-script to create links to > english pages where other translations are not yet done. Okay, I haven't noticed the links yet. Or is this not implemented yet? > AFAIK there is no DocBook browser and we certainly don't want to write > one. The format is not even intended to be browsed directly. Creating > HTML from it will (at least in the short term) be the right thing to > do. A few persons on IRC stated they'd also like a printed reference. (Yes, I know your book and it's great, but still) :) > I'm all for using DocBook to create the help files if and only if the > help authors feel comfortable with it, someone who knows DocBook and > all that stylesheet stuff volunteers to help and Yosh as the gimp > maintainer gives his OK, since he will have to build the releases. Yes. >> Tools: yes, Time: I doubt that. Automatically processing text makes >> things faster not lenghtier... > If you would have ever used Jade, you'd know that it adds a > significant amount of time. Processing SGML is a very CPU-intensive > and time-consuming task (at least with the available tools). It didn't mean CPU time. From this view you're right. I originally wrote about development time. >> It's not that hard. I could do that... > Do I read, you could do that, or you will do that?? Since I volunteered to help with the docs it's more 'I will do that'. Time is no issue at the moment and big parts of my time are dedicated to GIMP. There's a bigger problem in support terms. > I'd vote for a plug-in API reference separated from the normal users > help. This API reference could be automatically created from the > plug-in sources. But please let us concentrate on finishing the > libgimp API reference before we start another project. Second that. > What advantage would we have if the help files are stored separately > if the release is going to include it anyway? Anyway, the one who > creates the releases should decide that. It will be a nightmare to coordinate the progress on the docs. We've counted 5 people on IRC willing to contribute. It's very likely that they will be more when this part has really started, and one person should handle that? In my eyes it's sort of overkill. Put it somewhere else, give the, let's say 20, people CVS access to it and bundle it at release time or even not if you don't like that. -- Servus, Daniel
Re: Help files
Hi, > > Format issue 1: DocBook or HTML? > > > > > Points in favour of DocBook: > > * Can be pushed to a variety of output formats with existing tools. > > * Is more searchable and indexable and whatnot, using hypothetcial > > tools. (If you can point to stable packages that index and > > intelligently search docbook, I'll take that "hypothetical" back.) > > That's not the point, but you can also automatically create > crossreferences and also something like: > > Sorry, this page hasn't been written in yet. Would you > like to read this help in instead? As you might have noticed the creators of the help system have already thought about that. The current help-system does not yet support multi-language help files, but the current directory structure and the code should allow to add this feature anytime with little effort. Our plan so far was to use a simple shell-script to create links to english pages where other translations are not yet done. AFAIK there is no DocBook browser and we certainly don't want to write one. The format is not even intended to be browsed directly. Creating HTML from it will (at least in the short term) be the right thing to do. I'm all for using DocBook to create the help files if and only if the help authors feel comfortable with it, someone who knows DocBook and all that stylesheet stuff volunteers to help and Yosh as the gimp maintainer gives his OK, since he will have to build the releases. I'll help as much as I can to create the necessary framework. As you might have noticed we already use DocBook-SGML to create the libgimp API reference. > >1) This adds significantly to the time and tools the maintainer > > requires to make a release. > > Tools: yes, Time: I doubt that. Automatically processing text makes > things faster not lenghtier... If you would have ever used Jade, you'd know that it adds a significant amount of time. Processing SGML is a very CPU-intensive and time-consuming task (at least with the available tools). > > 2) > > Making the output look good will require a non-trivial amount of > > work on the transformation stylesheets. That's a relatively rare > > skill, so finding someone to do that might be difficult. > > It's not that hard. I could do that... Do I read, you could do that, or you will do that?? > > Everyone probably agrees that we shouldn't have a different background > > colour for every help page. It might also be nice if there was some > > organizational consistancy from page to page. Also, is there anything > > that shouldn't be in the help file, or should always be in seperate > > files? For instance, should information about using the plug-in > > non-interactively not be displayed in the same file as the rest, to > > avoid exposing the user to "scary pdb stuff"? I'd vote for a plug-in API reference separated from the normal users help. This API reference could be automatically created from the plug-in sources. But please let us concentrate on finishing the libgimp API reference before we start another project. > > "GIMP doesn't *need* help files to run, so they can be > > distributed seperately." > > That's just a fraction of my argument. I've no problem with > shipping GIMP with online help. I just think it's better > to keep the source archive smaller since the onlinehelp shouldn't > depend on the source and thus can without any problem reside outside > of our maintree which would make maintainance easier IMHO... What advantage would we have if the help files are stored separately if the release is going to include it anyway? Anyway, the one who creates the releases should decide that. Now to a few things Kevin pointed out in his first mail that I haven't dealed with so far: > ** Speaking of the help browser: > I don't really know what the qualities and status of gimp's help > browser are, or why we have our own instead of passing the job to the > user's favourite browser. I vaugely remember some noise about "Oh, we > need our own help browser because it is going to have special > navigational things for our help architecture," so I let that issue > slide, but since those people have largely signed off the project, do we > need to re-think these questions? The advantage of the helpbrowser plug-in is it's speed, small screen estate and small memory footprint. I guess a lot of people are very happy that they do not have to use their "favorite" browser since it's a huge memory-eating monster that takes ages to start if GIMP is already running. For those of us that are happy with their browser, they can continue to use it. At some point we might consider adding another option, namely a gtkhtml-based helpbrowser or interfaces to the GNOME and KDE help-systems. As all this is implemented as a plug-in it should be trivial to do so. > Egger argues, "GIMP doesn't *need* help files to run, so they can be > distributed seperately."
Re: Perl Scripting
On 30 Jul, Robert L Krawitz wrote: > Pardon? Just because a version is not officially released doesn't > mean it doesn't exist, does it? > For this purpose, I would say it does (mean that it does not exist). > Especially since it isn't even a formal snapshot (which egcs was doing > for a while), but rather just the current development tree. Ok, then it's a formalistic problem. > Unless the change has been announced as permanent, you have no idea > what future gcc's will look like. OK, that's a good point. Seems like we'll be talking about this issue again when the release the next version Just for reference: GIMP and all other plugins work fine with most "versions" I've used so far... -- Servus, Daniel
Re: Help files
On 30 Jul, Kevin Turner wrote: > Format issue 1: DocBook or HTML? > > Points in favour of DocBook: > * Can be pushed to a variety of output formats with existing tools. > * Is more searchable and indexable and whatnot, using hypothetcial > tools. (If you can point to stable packages that index and > intelligently search docbook, I'll take that "hypothetical" back.) That's not the point, but you can also automatically create crossreferences and also something like: Sorry, this page hasn't been written in yet. Would you like to read this help in instead? >1) This adds significantly to the time and tools the maintainer > requires to make a release. Tools: yes, Time: I doubt that. Automatically processing text makes things faster not lenghtier... > 2) > Making the output look good will require a non-trivial amount of > work on the transformation stylesheets. That's a relatively rare > skill, so finding someone to do that might be difficult. It's not that hard. I could do that... > * Intimidation factor. Contributers are more likely to know HTML > than DocBook, and may not be willing to invest in the transition. May be right, but third party contributors can also pass pure text to Piers or me and we'll likely convert it. BTW: It's not that hard to learn. In this case it might be even more simple than HTML. > Everyone probably agrees that we shouldn't have a different background > colour for every help page. It might also be nice if there was some > organizational consistancy from page to page. Also, is there anything > that shouldn't be in the help file, or should always be in seperate > files? For instance, should information about using the plug-in > non-interactively not be displayed in the same file as the rest, to > avoid exposing the user to "scary pdb stuff"? What about letting the user choose that? > See: http://plugins.gimp.org/maze/help.html > Is this a good style to follow, or no? I think it's pretty good. > Egger argues, Please call me Daniel... > "GIMP doesn't *need* help files to run, so they can be > distributed seperately." That's just a fraction of my argument. I've no problem with shipping GIMP with online help. I just think it's better to keep the source archive smaller since the onlinehelp shouldn't depend on the source and thus can without any problem reside outside of our maintree which would make maintainance easier IMHO... -- Servus, Daniel
Re: Perl Scripting
Date: Sun, 30 Jul 2000 19:34:18 +0200 (CEST) From: [EMAIL PROTECTED] On 30 Jul, Marc Lehmann wrote: > It's you who is unprof(f)essional. You were and are totally wrong with > your today's claim about gcc -- claiming some not-yet-existant > version of gcc causes problems on your machine. Pardon? Just because a version is not officially released doesn't mean it doesn't exist, does it? For this purpose, I would say it does (mean that it does not exist). Especially since it isn't even a formal snapshot (which egcs was doing for a while), but rather just the current development tree. I'm forced to use a gcc version later than the LAST OFFICIALLY released version because I'm having severe problem with the C++ frontend in 2.95.2. I claim I'm using the CVS version from today which is obviously more rencent than 2.95.2. Now please tell me, where's my thinko??? The current development tree of GCC could do anything at all, including not work. It may not even be consistent. It is not the responsibility of the Gimp developers to track gcc in real time. When the next version of gcc is released, then it's reasonable to complain about compile failures in the Gimp, but at present you have no idea whatsoever whether this is a Gimp bug or a GCC bug. "More recent" does not necessarily mean "better" or "more correct". It's possible to have multiple versions of gcc installed on your system. > I am not. However, unless you tell me about it I will have no way of > finding out. Ok, I told you that you can't compile the plugin with a CVS version of gcc. There will be surely a new release somewhen so even more people will notice it, so fixing it before that will happen seems sensible to me. Unless the GCC developers have announced that something has changed that will permanently cause an incompatibility, there's no particular reason to believe that the compile failure is due to anything wrong with the Gimp. Marc, I just want to know ONE little thing: Will you help to make the gimpperl plugin usable on more systems (for example on future gccs), YES or NO? Unless the change has been announced as permanent, you have no idea what future gcc's will look like. -- Robert Krawitz <[EMAIL PROTECTED]> http://www.tiac.net/users/rlk/ Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for The Gimp Print -- http://gimp-print.sourceforge.net "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
Help files
Ok, so it looks like we need to start filling in the help files. There are a number of things about the help files that never got decided (or at least the decisions were never made public), because we were told "someone else is taking care of it". But now, it looks like we've got to hammer those things out ourselves... Issues: 1) Format of the help files. B) The help browser. C) Location of the help repository. Format issue 1: DocBook or HTML? Points in favour of DocBook: * Can be pushed to a variety of output formats with existing tools. * Is more searchable and indexable and whatnot, using hypothetcial tools. (If you can point to stable packages that index and intelligently search docbook, I'll take that "hypothetical" back.) Points against DocBook: * We don't have a DocBook browser, so we'd have to transform it all to HTML for browsing. 1) This adds significantly to the time and tools the maintainer requires to make a release. 2) Making the output look good will require a non-trivial amount of work on the transformation stylesheets. That's a relatively rare skill, so finding someone to do that might be difficult. * Intimidation factor. Contributers are more likely to know HTML than DocBook, and may not be willing to invest in the transition. Summary: I'm a believer that DocBook is the Right Thing for the Long Run. But that doesn't necessarily mean it's the right thing for this particular case, today. Points in favour of HTML: * The on-line help is really only going to be read on-line anyway. And the only on-line browser we have is a HTML browser. So the only thing that matters is how it looks in HTML. Also, if our HTML browser has a limited feature set, we might need to tweak it for that instead of using auto-generated HTML that might assume a full implementation. ** Speaking of the help browser: I don't really know what the qualities and status of gimp's help browser are, or why we have our own instead of passing the job to the user's favourite browser. I vaugely remember some noise about "Oh, we need our own help browser because it is going to have special navigational things for our help architecture," so I let that issue slide, but since those people have largely signed off the project, do we need to re-think these questions? Format issue 2: Style guidelines. = Everyone probably agrees that we shouldn't have a different background colour for every help page. It might also be nice if there was some organizational consistancy from page to page. Also, is there anything that shouldn't be in the help file, or should always be in seperate files? For instance, should information about using the plug-in non-interactively not be displayed in the same file as the rest, to avoid exposing the user to "scary pdb stuff"? In the (two) help files I've authored so far, I've used the time-honoured organization of the man page as a template, with the www.gimp.org colour scheme. See: http://plugins.gimp.org/maze/help.html Is this a good style to follow, or no? Location: = Egger argues, "GIMP doesn't *need* help files to run, so they can be distributed seperately." Why? It's the "Who has cvs.gnome.org write-access?" song again. But it's only been three days since Piers (our new Help-guy) requested write access, so I don't feel that's a cause for alarm yet. Personally, I don't want a single package of gimp 1.2 to ship without help files bundled in. And while some of us decided that we'd like a seperate CVS repository for plug-ins, Gnome's documentation team seems to get along without one, so I don't know that its required. Love, - Kevin -- 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: Perl Scripting
On Sun, Jul 30, 2000 at 12:09:25AM +0200, [EMAIL PROTECTED] wrote: > The most frequent bug I'm stumbling over is the uncompilability with > gcc compilers more rencent than version 2.95.2. then you must come from the future. more recent gcc versions than 2.95.2 DO NOT EXIST. it would save us gcc people a lot of time if you could import, say, gcc-3.0 from the future back to now ;) i would really appreciate if you would finally start thinking, as this is not the first time you claim things that are sooo obviously broken :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: perl 5.6? or on openbsd 2.7
On Sat, Jul 29, 2000 at 05:27:19PM -0700, pixel fairy <[EMAIL PROTECTED]> wrote: > does gimp perl work with perl 5.6? this is what ships with openbsd 2.7 > or, has anyone gotten the gimp perl stuff to work with it? I have gotten it to work with. As a matter of fact, gimp-perl is being developed with perl5.6. However, the current 5.6.0 release have a lot of bugs. If you experience problems with error-reporting in your own scripts then you either have to upgrade or to downgrade. Most everything else should work with vanilla 5.6. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl Scripting
On Sun, Jul 30, 2000 at 06:02:04PM +0200, [EMAIL PROTECTED] wrote: > > It's pure fact. You keep claiming all sorts of funny things that you > > yourself should have known long before you started posting about it. > > Ok Marc, it's enough. I will not continue this useless flamewar! > In real life you sometimes play the nice guy but back on the computer > you're pretty unproffesional! It's you who is unprof(f)essional. You were and are totally wrong with your today's claim about gcc -- claiming some not-yet-existant version of gcc causes problems on your machine. This is distracting time and other resources from real problems. > > And I think otherwise. Don't ask me if you are going to ignore me. > > I wouldn't answer if I had ignored you. Well, you sound like that ;) > The perl plugin is broken > on several configurations and you're ignoring it. I am not. However, unless you tell me about it I will have no way of finding out. > I for my part offered help to remove the problems but am pretty Then start doing what you say you are offering. Claims about problems with nonexistant programs is _not_ helping anybody. And please stop picking on your problems with perl. I am _not_ talking about perl, but about your general attitude of posting, well, garbage to this list unrelated to me, but related to gimp and often (fortunately not always) totally wrong. Wrong in a way that you, yourself, could have avoided with minmal effort. For example, when I told you that your latest patch uses mempcpy, a function not available on most systems, you just replied with a quote from the libc info pages(!), claiming the function _does_ exist. When I told you that your usage of mempcpy is wrong anyway (you used it like memcpy) you told me to read the manpage. Fact is, either you didn't read the manpage or you simply didn't understand it. Honestly, I suspect it was a typing error and you just wanted a way to save your face, wether it breaks gimp or not. It's your willingness to break the gimp sources without blinking, and without willing to fix things later, combined with your immense willingness of stealing other people's time if it saves you looking up a manpage that cost you my support now, which, I guess was the only person supporting you anymore. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Re: Perl Scripting
On Sun, Jul 30, 2000 at 04:54:55PM +0200, [EMAIL PROTECTED] wrote: > On 30 Jul, Marc Lehmann wrote: > > > i would really appreciate if you would finally start thinking, as this > > is not the first time you claim things that are sooo obviously broken > > :( > > No need to get insulting. It's pure fact. You keep claiming all sorts of funny things that you yourself should have known long before you started posting about it. > Spend your time fixing the plugin instead. This also has nothing to do with any plugin. What I said is in no way limited to this week. It is your general behaviour. > This would be more helpful for you and me. It would indeed be most helpful if you try thinking a bit before you post. I just mean that. > BTW: You told me to just close all bugreports reporting gimpperl on > the bugtracker, but I really think there could be serious problems > which would need the time of an expert (i.e. you) to have a closer And I think otherwise. Don't ask me if you are going to ignore me. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Are You A Leader? / $1000 A Day!!
EVERYONE WHO'S ANYONE IS JUMPING ON THIS ONE GUYS!!! NEWEST ONLINE LINEAR THAT PAYS $1000.00 for Every Cycle!!! With unlimited Cycles!! THIS IS DEFINATELY WORTH LOOKING INTO!!! WE HAVE BROUGHT IN ALL THE TOP LEADERS!! If You Consider Yourself To Be A Team Leader, Or You Wish To Soon Be, Then You Must Consider This!!! Ask About The Guaranteed Lead Packages And The Newest Promotional Tool "Peggy" WHAT IS PEGGY? WAIT TILL YOU HERE THIS ONE!! Just ASK US WHAT IT IS ALL ABOUT!!! >>>VERY IMPORTANT RESPOND ONLY TO THE ADDRESS BELOW AND INCLUDE YOUR NAME AND PHONE NUMBER OR YOU WILL NOT BE CONTACTED!! [EMAIL PROTECTED]
Re: Perl Scripting
On 30 Jul, Marc Lehmann wrote: >> No need to get insulting. > It's pure fact. You keep claiming all sorts of funny things that you > yourself should have known long before you started posting about it. Ok Marc, it's enough. I will not continue this useless flamewar! In real life you sometimes play the nice guy but back on the computer you're pretty unproffesional! > And I think otherwise. Don't ask me if you are going to ignore me. I wouldn't answer if I had ignored you. The perl plugin is broken on several configurations and you're ignoring it. If you don't want to help, let it be and do whatever you like to do. I for my part offered help to remove the problems but am pretty clueless since I don't know much about perl, otherwise I'd fix it on my own. -- Servus, Daniel
Compiling GIMP-Perl
(Firstly, a quick note - I apologize for my confusion in earlier sending out HTML postings to this mailing list. I wasn't aware that I was doing it. Anyway, I hope that this format is OK - plain text as far as I know) I currently have Gimp v1.1.24 (developers' version). I don't have any Perl-related menu items on the Xtns menu, and so in an attempt to remedy this, I downloaded the gimp-perl v1.16 distribution from http://registry.gimp.org. As per the instructions, I executed the command "perl Makefile.pl", but got the following error messages : ./configure: =.: command not found ./configure: line 907: syntax error near unexpected token `"(c' ./configure: line 907: ` echo $ac_n "(cached) $ac_c" 1>&6' I currently have the following installed on my machine : GTK+ version 1.2.6-6mdk perl version 5.00503-10mdk perl-GTK 0.6123-7mdk gimp 1.1.24 In the hope of getting some clue to this error, I tried looking for the string "$ac_n" in the source file Makefile.pl, but couldn't find it. What should I do from here ? Thanks in advance, regards, Andrew J Fortune
Re: Perl Scripting
On 30 Jul, Marc Lehmann wrote: > It's you who is unprof(f)essional. You were and are totally wrong with > your today's claim about gcc -- claiming some not-yet-existant > version of gcc causes problems on your machine. Pardon? Just because a version is not officially released doesn't mean it doesn't exist, does it? I'm forced to use a gcc version later than the LAST OFFICIALLY released version because I'm having severe problem with the C++ frontend in 2.95.2. I claim I'm using the CVS version from today which is obviously more rencent than 2.95.2. Now please tell me, where's my thinko??? > I am not. However, unless you tell me about it I will have no way of > finding out. Ok, I told you that you can't compile the plugin with a CVS version of gcc. There will be surely a new release somewhen so even more people will notice it, so fixing it before that will happen seems sensible to me. > For example, when I told you that your latest patch uses mempcpy, a > function not available on most systems, you just replied with a quote > from the libc info pages(!), claiming the function _does_ exist. Sorry Marc, I told you very clearly that this shouldn't have been in the patch since it was just a try that has never worked anyway but since you told me in a very selfconfident way that this function hasn't ever existed I replied with a quote of the info page! That's the fact, anything else is pure speculation from your side. [ Rest of speculations deleted ] Marc, I just want to know ONE little thing: Will you help to make the gimpperl plugin usable on more systems (for example on future gccs), YES or NO? -- Servus, Daniel
Re: Perl Scripting
On 30 Jul, Marc Lehmann wrote: > i would really appreciate if you would finally start thinking, as this > is not the first time you claim things that are sooo obviously broken > :( No need to get insulting. Spend your time fixing the plugin instead. This would be more helpful for you and me. I can supply you all the information you'd like to have. BTW: You told me to just close all bugreports reporting gimpperl on the bugtracker, but I really think there could be serious problems which would need the time of an expert (i.e. you) to have a closer look. -- Servus, Daniel
