Re: [Gimp-developer] gimp-help-2
On Mon, 18 Aug 2003 22:08:14 +0200, Branko Collin [EMAIL PROTECTED] wrote: On 18 Aug 2003, at 20:25, Raphaël Quinet wrote: On Mon, 18 Aug 2003 20:12:06 +0200, Roman Joost [EMAIL PROTECTED] wrote: I'll setup up some pages for the module, but where can i upload these pages? [...] I suggest that you keep this temporary URL for the next two or three weeks. The new web site (currently mmmaybe.gimp.org) should replace the old one soon and it will be easier to set up the correct URL after all parts of the new site are in place. Regarding the final location, I would suggest something like: http://www.gimp.org/docs/help/ The web site is under CVS control (module gimp-web), so there should be no problem for synchronizing the contents if you have write access to CVS. Shouldn't support for documentation writing take place on http://developer.gimp.org, rather than http://www.gimp.org? Sorry, I should have mentioned that the above URL was refering to the stable help pages. The URL for the development of the help pages could of course be different, and it could be hosted on the developers' site. As we have discussed during GIMPcon, the next release of the GIMP will not contain the help system in the default package. The help system will be shipped as a separate package (with its own release schedule) and it will be up to those who build and distribute binaries to decide if they ship them together or not. If a user tries to access the help system while it is not installed, the GIMP should display a message saying that the corresponding help page is not installed and suggest to install the missing package. But it should also provide a link to a copy of the help pages available from www.gimp.org. This is what I was refering to in my previous message: http://www.gimp.org/docs/help/ This URL would always contain the latest stable version of the help pages. This URL (a prefix, actually) would be known by the GIMP so that those who do not have the gimp-help(-2) package can access the online help. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2
On Tue, 19 Aug 2003 01:35:33 +0200, Sven Neumann [EMAIL PROTECTED] wrote: What I care about is how the generated HTML files in different languages will be structured since the helpbrowser will have to choose the appropriate files based on the users locale and it will probably have to know how to fallback to the english version. I was wondering... Is it really necessary for the help browser to know how to fallback to the English version? This could also be done by the build system for the help pages, and it would even be better for encouraging the users to translate the pages. Let me explain... Let's assume that we have one tree per language (similar to gimp-1-2). Instead of shipping a set of help pages that could have missing pages for some languages, we set up a build system for the help pages in such a way that it ensures that all help pages from the C directory are automatically added to all other languages. The top-level directory for each language would contain a template file with the following message in the corresponding language: This page has not been translated yet to your language. The English version is included below. If you want to help other GIMP users, please consider submitting a translated version of this page to the language translators at address. So when a page is missing in some language, the corresponding page from the C directory would be copied by the build system (not by the GIMP itself) and would include the text mentioned above in order to encourage users to contribute their own translations. The message could also include a link to the online version of the help system (hosted at www.gimp.org or developer.gimp.org) so that the users can check if the latest version of this help page is already translated or not. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On Tue, Aug 19, 2003 at 12:23:06AM +0200, Sven Neumann wrote: Why don't you simply write it all in UTF-8? Using HTML entities seems akward and error-prone. The helpbrowser plug-in is fully UTF-8 aware and if you use an editor that copes with UTF-8, you can simply use umlauts in your texts. Its written with UTF-8 Entities, so i think this thread is deprecated .. The only thing was a correct mapping of the umlauts. I setup my editor correctly and now i can write the docs without typing in the entities. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Documentation of the GIMP-1.3 internals
Hi, On Tue, 2003-08-19 at 06:13, Carol Spears wrote: This is the list of eh, C calls? You have to give a little list of values to make them work right? No, as I said, this is the object hierarchy. It's a list of all GIMP classes shown with their base classes. The documentation includes a cross-linked HTML version of this. What I posted here is just some intermediate file created by gtk-doc using introspection. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
Hi, On Tue, 2003-08-19 at 10:33, Roman Joost wrote: Its written with UTF-8 Entities, so i think this thread is deprecated .. The only thing was a correct mapping of the umlauts. I setup my editor correctly and now i can write the docs without typing in the entities. Excuse my ignorance, but what are UTF-8 entities? I had a look at the stuff in CVS: secondaryEinfuuml;hrung/secondary and I would have expected: secondaryEinfhrung/secondary (Let's hope the mail client transfers this correctly and marks the mail as UTF-8 encoded). Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2
Hi, On Tue, 2003-08-19 at 09:48, Raphaël Quinet wrote: On Tue, 19 Aug 2003 01:35:33 +0200, Sven Neumann [EMAIL PROTECTED] wrote: What I care about is how the generated HTML files in different languages will be structured since the helpbrowser will have to choose the appropriate files based on the users locale and it will probably have to know how to fallback to the english version. I was wondering... Is it really necessary for the help browser to know how to fallback to the English version? The current helpbrowser does it that way. But, no, it isn't necessary and that's why I wanted to see it discussed. Since Daniel obviously refuses to do that, I won't be able to do work on the implementation. I also don't want to work on it any longer unless Daniel changes his state of mind which seems unlikely to happen. So much for my infamous last words on the gimp2 help system... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] style guide gimp-help-2
I am getting a little confused by some of the statements made in this and earlier threads. What it comes down to, I guess, is that Daniel and Mel had a clear vision of the style of the new user documentation, but I somehow missed an explanation of that vision. In an earlier thread, Daniel wrote: we're not too happy with the content and the structure of the GUMP. I take it you meant the GIMP documentation? Why are you not too happy about the content and the structure? You also talked about granularity. Apparently, part of your idea of a GIMP documentation style is that help pages should be of similar size. Could you elaborate about that? Is that what you mean with granularity? From what I understand, you want to give authors for a certain language a certain freedom of what and how much they write on any given topic. Doesn't this collide with your goal of having a set size grain? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] style guide gimp-help-2
Am Die, 2003-08-19 um 12.19 schrieb Branko Collin: What it comes down to, I guess, is that Daniel and Mel had a clear vision of the style of the new user documentation, but I somehow missed an explanation of that vision. We started the project by sketching that vision in some files in the CVS module. I'm totally aggreeing that this not only needs updating but also to be placed in a more prominent location. In an earlier thread, Daniel wrote: we're not too happy with the content and the structure of the GUMP. I take it you meant the GIMP documentation? GUM is the GIMP User Manual, so yes. Why are you not too happy about the content and the structure? It is too anarchic in its sructural layout and Mel didn't like the language at all. What we imagined was more like a modern manual (in both content and layout) leveraging all possibilities of modern tools without the fear to break anything existant (ie. the helpbrowser). You also talked about granularity. Apparently, part of your idea of a GIMP documentation style is that help pages should be of similar size. Could you elaborate about that? Is that what you mean with granularity? Granularity means that an author is not limited to squeeze all information about a certain topic into exactly the given structure, like a section; we had great troubles and some not so nice workarounds when being faced with large topics in the old version. This means that if something deserves a chapter it'll get a chapter without us having to worry about how this is transformed into a HTML file with a fixed name (because it's hardcoded into the GIMP) and referenced later on. This would be grnaularity on the source side. Granularity on the output means exactly what you are referring to that the help chunks are all of the correct size. When the user requests help on blur the displayed information should resemble exactly that and not show all plugins with blur somewhere at the beginning. We already agreed to use HTML with anchors though, so this is something we probably cannot have easily since it's impossible to control the output granularity on case-by-case basis. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] gimp-help-2
Am Die, 2003-08-19 um 11.52 schrieb Sven Neumann: The current helpbrowser does it that way. But, no, it isn't necessary and that's why I wanted to see it discussed. Since Daniel obviously refuses to do that, Do not lay words in my mouth! I won't be able to do work on the implementation. This is a poor mans' excuse. I also don't want to work on it any longer unless Daniel changes his ^ This is what you wanted to say, nothing else. Really sad... -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] gimp-help-2
Am Die, 2003-08-19 um 09.48 schrieb Raphaël Quinet: following message in the corresponding language: This page has not been translated yet to your language. The English version is included below. If you want to help other GIMP users, please consider submitting a translated version of this page to the language translators at address. I'm not sure I exactly like this idea completely (ie. the implied automatism) since I don't want to enforce 1:1 translations, however it seems like a bright idea to set it up for completely uncovered topics. Not that we have any translations at the moment which are incomplete enough so this would matter, but if people like it, I'll certainly put it on the list. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] style guide gimp-help-2
Thank you for your elaborate answer. I do have some follow-up questions though. On 19 Aug 2003, at 14:01, Daniel Egger wrote: Am Die, 2003-08-19 um 12.19 schrieb Branko Collin: [current manual] Why are you not too happy about the content and the structure? It is too anarchic in its sructural layout and Mel didn't like the language at all. What we imagined was more like a modern manual (in both content and layout) leveraging all possibilities of modern tools without the fear to break anything existant (ie. the helpbrowser). Assume for a second that I know nothing about 'modern manuals'. What is it about them that you like. What did Mel not like about the language of the old manual? Also, when I came to the GIMP, there was no manual. There was a book that called itself that, but it wasn't shipped with any of the GIMP distros that I knew, and a web version was actually rather hard to find. So, when you are talking about the GUM, are you talking about that obscure book, or about the help files, or both? Are you trying to make a manual and help files in one? You also talked about granularity. Apparently, part of your idea of a GIMP documentation style is that help pages should be of similar size. Could you elaborate about that? Is that what you mean with granularity? Granularity means that an author is not limited to squeeze all information about a certain topic into exactly the given structure, like a section; we had great troubles and some not so nice workarounds when being faced with large topics in the old version. This means that if something deserves a chapter it'll get a chapter without us having to worry about how this is transformed into a HTML file with a fixed name (because it's hardcoded into the GIMP) and referenced later on. This would be grnaularity on the source side. Granularity on the output means exactly what you are referring to that the help chunks are all of the correct size. When the user requests help on blur the displayed information should resemble exactly that and not show all plugins with blur somewhere at the beginning. Ah, OK, so when you say size, you don't mean physical size? But that the document is on-topic for the user? We already agreed to use HTML with anchors though, so this is something we probably cannot have easily since it's impossible to control the output granularity on case-by-case basis. Probably not. But I imagine that if I wanted to see a page about one of the blur filters, you would be able to provide me with a page about that help filter. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2
Hi, On Tue, 2003-08-19 at 13:35, Daniel Egger wrote: I also don't want to work on it any longer unless Daniel changes his ^ This is what you wanted to say, nothing else. Really sad... Yes, it is sad. But please read your own mails again. First you claimed that there is no need for further discussion since we discussed all this weeks ago already. Then, a few mails later it becomes clear that you didn't understand the proposed concept at all. I felt that there is more need for discussion and I tried to get it started since I wanted to start working on the implementation. I can however not work with someone who is as arrogant and insulting as you are. Even if I ignore the private emails we exchanged yesterday, I cannot work with you any longer. Someone else will have to work on the help-system in gimp or you will have to change your attitude. I will not any longer waste any of my free time dealing with you. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2
Daniel Egger ([EMAIL PROTECTED]) wrote: Am Die, 2003-08-19 um 11.52 schrieb Sven Neumann: The current helpbrowser does it that way. But, no, it isn't necessary and that's why I wanted to see it discussed. Since Daniel obviously refuses to do that, Do not lay words in my mouth! I won't be able to do work on the implementation. This is a poor mans' excuse. I also don't want to work on it any longer unless Daniel changes his ^ This is what you wanted to say, nothing else. Really sad... Hi Daniel, Sven. Would you please *both* step back a bit and look at the mails you just wrote? They make you both look very silly. Apparently there are some gripes between you both and you probably should talk in private mail about that. But I really do not understand why you seem impossible to discuss this in a reasonable manner. Threatening to stop development on gimp-help and - vice versa - to impute that that was the whole point is not helpful at all. I'd like to ask you to stop discussion for today and tell each other in a non-pissed off way tomorrow on this list, what you need from each other. From my point of view neither the gimp-help team nor the gimp-developers-team have proposed a way to do the linking between gimp and gimp-help and this obviously is necessary to integrate the help with the Gimp. Sheesh! Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] style guide gimp-help-2
On 19 Aug 2003 14:01:12 +0200, Daniel Egger [EMAIL PROTECTED] wrote: Am Die, 2003-08-19 um 12.19 schrieb Branko Collin: In an earlier thread, Daniel wrote: we're not too happy with the content and the structure of the GUMP. I take it you meant the GIMP documentation? GUM is the GIMP User Manual, so yes. Why are you not too happy about the content and the structure? It is too anarchic in its sructural layout and Mel didn't like the language at all. What we imagined was more like a modern manual (in both content and layout) leveraging all possibilities of modern tools without the fear to break anything existant (ie. the helpbrowser). Now I am confused. I thought that we were talking about the online help system, not about the manual (GUM). It looks like you consider both of them to be the same thing. Is that right? I thought that the online help would be something that is focused on explaining individual functions, i.e. one page for each feature. If I understood you correctly, you would like to merge these functional descriptions with something that is more like a tutorial. For the online help part (the part that is called directly by the GIMP when the user invokes the context help), I do not see any need to allow anything else than a one-to-one mapping between the English version and the translations. That's why I did not understand some of your previous arguments. But if you want to merge this with a tutorial part, then it could make sense to allow a bit more freedom for the translators. I think that too many people are confused now. Daniel, it would be nice if you start a new thread with a message explaining what are the plans for the new help system. I would like to know what are the goals, non-goals and the proposed implementation. Note that these goals do not necessarily have to be discussed: it would be fine for me if you said: I am going to do it like that or not at all. But at least these ideas should be summarized in a clear way, to avoid future confusion about the plans for the help system. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
On Tue, Aug 19, 2003 at 11:50:51AM +0200, Sven Neumann wrote: Excuse my ignorance, but what are UTF-8 entities? I had a look at the stuff in CVS: secondaryEinfuuml;hrung/secondary and I would have expected: secondaryEinführung/secondary AFAIK, you can't write german umlauts in xml files, which are utf-8 encoded. The UTF-8 Entity for the german umlauts are mapped in gimp.xml to html entities. I think, daniel made this for contributors, because the most know the german umlauts as HTML entities. Greetings, -- Roman Joost www: http://www.romanofski.de email: [EMAIL PROTECTED] pgp0.pgp Description: PGP signature
[Gimp-developer] bugs@gimp.org spam getting a little out of hand
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone else noticed how the [EMAIL PROTECTED] spam is getting a little out of hand? perhaps now would be a good time to change that address. - -- Dan -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE/Qjunad4P1+ZAZk0RAgdFAJ0a9mlxy/947bJOSayuAoj1WwrxcQCglaSS SBUYodfIqr6pPFACax1mQd4= =zbTP -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] writing german online help
Hi, On Tue, 2003-08-19 at 16:19, Roman Joost wrote: AFAIK, you can't write german umlauts in xml files, which are utf-8 encoded. Well, of course you can. That's the whole point of UTF-8 encoding. It provides a single encoding suitable for all languages so that they can coexist in the same file. All XML-1.0 compatible tools must handle UTF-8 correctly and there is thus no need to use entities. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bugs@gimp.org spam getting a little out ofhand
On Tue, 19 Aug 2003 08:00:55 -0700, Daniel Rogers [EMAIL PROTECTED] wrote: Has anyone else noticed how the [EMAIL PROTECTED] spam is getting a little out of hand? perhaps now would be a good time to change that address. Well, this looks like another Microsoft worm spreading like wildfire. This is yet another variant of the Sobig worm: http://securityresponse.symantec.com/avcenter/venc/data/[EMAIL PROTECTED] I got several hundred copies of it in the last 6 hours. Most of them came from [EMAIL PROTECTED] Sigh! We cannot easily change that address because that would require changing all gimp bugs, which are using this as the contact address. But as I suggested during GIMPcon, we could configure this address so that it accepts mails from Bugzilla only. Anything that is not coming from Bugzilla would be bounced back to the sender. -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bugs@gimp.org spam getting a little out ofhand
Hi, On Tue, 2003-08-19 at 18:04, Raphaël Quinet wrote: We cannot easily change that address because that would require changing all gimp bugs, which are using this as the contact address. But as I suggested during GIMPcon, we could configure this address so that it accepts mails from Bugzilla only. Anything that is not coming from Bugzilla would be bounced back to the sender. I think everyone keeps suggesting this for quite some time already but we need Yosh to implement this suggestion... Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Documentation of the GIMP-1.3 internals
On Mon, 18 Aug 2003, Sven Neumann wrote: Hi, there is something I hacked up during GimpCon and I thought it might be of interest to some of you although it's not yet finished (and perhaps YEY! (This is a very good thing.) Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] style guide gimp-help-2
Am Die, 2003-08-19 um 14.25 schrieb Branko Collin: Thank you for your elaborate answer. I do have some follow-up questions though. No problem, whatever you want to know. :) Assume for a second that I know nothing about 'modern manuals'. What is it about them that you like. What did Mel not like about the language of the old manual? The old manual (or at least the content we had, I've never read the book, see below) was anachronistic, more like a reference than a fluent style, every single part following the exactly same style like a manpage. We changed quite a lot and tried to enrich the content as much as we could but Mel felt that it was too tight to reuse and that it would be better to completely start over; I liked that idea so this is what we did. So, when you are talking about the GUM, are you talking about that obscure book, or about the help files, or both? The old gimp-help content was derived from this obscure book with consent from the authors, so yes. In the beginning we just had the HTML which was converted over to DocBook/SGML in quite some amount of work and reformatted to be useful. Are you trying to make a manual and help files in one? Ultimatively yes. We tried to start with the manual though and haven't cared to much about the help files so far. In the end the help files will simply be fractions of the manual whether HTML or some other format, optionally reformatted for better use in a helpbrowser. Ah, OK, so when you say size, you don't mean physical size? Size is the perceived size, whether that are kilobyte, megabyte, lines or words (real or with markup) doesn't matter. But that the document is on-topic for the user? I beg your pardon? Probably not. But I imagine that if I wanted to see a page about one of the blur filters, you would be able to provide me with a page about that help filter. That for sure. Uncertain is how much information you'll get. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] writing german online help
Am Die, 2003-08-19 um 16.48 schrieb Sven Neumann: Well, of course you can. That's the whole point of UTF-8 encoding. It provides a single encoding suitable for all languages so that they can coexist in the same file. All XML-1.0 compatible tools must handle UTF-8 correctly and there is thus no need to use entities. There are two reasons not to use UTF-8 as input format: - There're still editors, consoles and other tools that have hefty troubles with UTF-8, especially when it's not used as the native encoding on the system - Last time I looked most if not all processors have troubles transcoding UTF-8 to HTML entities or different charactersets, unfortunately quite a few browsers cannot properly display the former. I'm sure we can switch really fast as soon as there is significant support or at least demand. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] bugs@gimp.org spam getting a little out of hand
On Tue, 19 Aug 2003, Daniel Rogers wrote: Date: Tue, 19 Aug 2003 08:00:55 -0700 From: Daniel Rogers [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Gimp-developer] [EMAIL PROTECTED] spam getting a little out of hand -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone else noticed how the [EMAIL PROTECTED] spam is getting a little out of hand? perhaps now would be a good time to change that address. Banning attachments and HTML email might be a tolerable compromise. At worst any real people sending to bugs will know to resend or use http://bugzilla.gnome.org instead if they are unwilling or unable to not send as HTML. Just a suggestion to consider, feel free to kill the address if you prefer. - Alan ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bugs@gimp.org spam getting a little out of hand
On Tue, Aug 19, 2003 at 08:58:25PM +0100, Alan Horkan [EMAIL PROTECTED] wrote: Banning attachments and HTML email might be a tolerable compromise. A compromise that wouldn't even catch 1% of the mail isn't torable in my opinion (especially as it's not possible to filter for this). How can one unsubscribe from [EMAIL PROTECTED], by mailing yosh? Just a suggestion to consider, feel free to kill the address if you prefer. The problem mail does not come from [EMAIL PROTECTED], but through [EMAIL PROTECTED] Filtering for it is close to impossible, as the problem is not spam, but replies to spams send by others. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bugs@gimp.org spam getting a little out of hand
On Tue, Aug 19, 2003 at 06:20:43PM +0200, Sven Neumann wrote: Hi, On Tue, 2003-08-19 at 18:04, Rapha??l Quinet wrote: We cannot easily change that address because that would require changing all gimp bugs, which are using this as the contact address. But as I suggested during GIMPcon, we could configure this address so that it accepts mails from Bugzilla only. Anything that is not coming from Bugzilla would be bounced back to the sender. I think everyone keeps suggesting this for quite some time already but we need Yosh to implement this suggestion... Done. But if anyone is filtering on the X-Mailing-List, you'll have to change it (this is something I wanted to avoid doing, but I haven't figured out how, so hence the wait) -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] bugs@gimp.org spam getting a little out of hand
On Tue, Aug 19, 2003 at 03:02:18PM -0700, Manish Singh [EMAIL PROTECTED] wrote: Done. Damn, you were too fast :) Thanks for implementing it! -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] style guide gimp-help-2
Am Die, 2003-08-19 um 15.08 schrieb Raphaël Quinet: Now I am confused. I thought that we were talking about the online help system, not about the manual (GUM). It looks like you consider both of them to be the same thing. Is that right? The old gimp-help was build upon the content of the GUM. And yes, I think it still makes sense to derive the onlinehelp from manual (but not the other way round). I thought that the online help would be something that is focused on explaining individual functions, i.e. one page for each feature. If I understood you correctly, you would like to merge these functional descriptions with something that is more like a tutorial. Exactly, I think online help is only worth it when it helps people. That means it should provide information about the topic at hand, it's meaning, a short description how it works, the available parameters and at least a link to some tutorial. Typically some builtin help is more like a rephrasing of what a non-blind person can see in the user interface. I don't think this is helpful at all; I think the person desperately trying to retrieve some useful information which cannot be found is more annoyed by the loss of time than the missing help. At least I made that experience some years ago with quite prominent MS software. For the online help part (the part that is called directly by the GIMP when the user invokes the context help), I do not see any need to allow anything else than a one-to-one mapping between the English version and the translations. Yes, for this it may not be necessary technically, but why restrict oneself when more is possible without additional efforts... :) I think that too many people are confused now. Daniel, it would be nice if you start a new thread with a message explaining what are the plans for the new help system. I would like to know what are the goals, non-goals and the proposed implementation. Note that these goals do not necessarily have to be discussed: it would be fine for me if you said: I am going to do it like that or not at all. But at least these ideas should be summarized in a clear way, to avoid future confusion about the plans for the help system. Caught me here. I fear I still haven't provided enough information so I'd probably be better off investing some time into some updated paperwork which I can refer to. I'm a bit busy though so please don't hold your breath -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] style guide gimp-help-2
On Tue, Aug 19, 2003 at 07:32:24PM +0200, Daniel Egger [EMAIL PROTECTED] wrote: book, see below) was anachronistic, more like a reference than a fluent style, every single part following the exactly same style like a manpage. We changed quite a lot and tried to enrich the content as much References are extremely important, more important than tutorials in prose, IMnsHO. I think tutorials/introductions/verbose manuals/howtos are extremely important to get people working, but for the actual work I very very much prefer manpages, since when I ask for help on a specific item I want to know about obscure settings, settings I didn't memorize, and a terse manpage-like style is the one that gets the information across. Now, maybe this can be combined, like a manpage-style reference + links to usage examples (that would imho be optimal!), plus introductory material. Of course, whoever produces a sizable amount of help material decides on the style, so the above just declares my preference in what I would clal useful. I mean, I almost never use online help since I usually cannot find the information I was looking for anyways. Under Windows (where I most often need help) for example, I often go to the online help because I want to know what that obscure option does, only to find that only the basic options are documented, the basic options I know already anyways. That for sure. Uncertain is how much information you'll get. Yeah :( But providing good and useful documentation is extremely hard. I don't believe the Gimp will succeed, but if it does, it'll be _the_ prototypical free software rocks app for another reason again. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-help-2
Am Mit, 2003-08-20 um 00.47 schrieb Michael Natterer: Is this a solution everybody can live with or did I miss something obvious? If it sounds reasonable, we should go ahead, it's not even an awful lot of work (the coding part, not writing the help pages :) Clean, (relatively) simple, I like it. In fact to push forward I simply went ahead and implemented it. Below is the result from the current German version. A few tweaks surely will have to be made and we haven't settled for some directory structure as of yet, but you get the idea ?xml version=1.0 encoding=UTF-8? gimp-help help-item id=GIMP target=index.html/ help-item id=introduction target=ch01.html/ help-item id=introduction-gimp target=ch01.html#introduction-gimp/ help-item id=introduction-platforms target=ch01.html#introduction-platforms/ help-item id=introduction-help target=ch01.html#introduction-help/ help-item id=legal target=ch02.html/ help-item id=legal-gimp target=ch02.html#legal-gimp/ help-item id=toolbox target=ch03.html/ help-item id=toolbox-introduction target=ch03.html#toolbox-introduction/ help-item id=menu target=ch03s02.html/ help-item id=toolbox-rectangle-selection target=ch03s03.html/ help-item id=toolbox-ellipse-selection target=ch03s04.html/ help-item id=toolbox-free-selection target=ch03s05.html/ help-item id=toolbox-fuzzy-selection target=ch03s06.html/ help-item id=toolbox-bycolor-selection target=ch03s07.html/ help-item id=toolbox-scissors-selection target=ch03s08.html/ help-item id=gimp-nohelp target=ch03s09.html/ help-item id=toolbox-color-picker target=ch03s10.html/ help-item id=toolbox-hostogram target=ch03s11.html/ help-item id=toolbox-zoom target=ch03s12.html/ help-item id=toolbox-measure target=ch03s13.html/ help-item id=toolbox-move target=ch03s14.html/ help-item id=toolbox-crop target=ch03s15.html/ help-item id=toolbox-rotate target=ch03s16.html/ help-item id=toolbox-scale target=ch03s17.html/ help-item id=toolbox-shear target=ch03s18.html/ help-item id=toolbox-perspective target=ch03s19.html/ help-item id=toolbox-flip target=ch03s20.html/ help-item id=toolbox-text target=ch03s21.html/ help-item id=toolbox-fill target=ch03s22.html/ help-item id=toolbox-gradient target=ch03s23.html/ help-item id=toolbox-pencil target=ch03s24.html/ help-item id=toolbox-pencil target=ch03s25.html/ help-item id=toolbox-erase target=ch03s26.html/ help-item id=toolbox-convolve target=ch03s27.html/ help-item id=filters target=ch04.html/ help-item id=filter_introduction target=ch04.html#filter_introduction/ help-item id=filters-blur target=ch04s02.html/ /gimp-help -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] writing german online help
Am Mit, 2003-08-20 um 01.31 schrieb [EMAIL PROTECTED]: Transcoding is a no-brainer, if that is a problem a simple one-liner can convert to whatever you want. I'm talking about the XSLT processors; sure a small perl/python/bash script will recode all generated HTML files in a directory, but as this does not seem necessary at the moment, I don't see a good reason to insert another step in the chain. unfortunately quite a few browsers cannot properly display the former. That's highly interesting. Even the venerable netscape-4 can properly display documents in utf-8, even utf-7. The IEs had troubles until somewhen (haven't checked for quite some time). Also the smaller homegrown browsers did, probably also the old GIMP helpbrowser. And I'm not sure about lynx and w3c either. Usually one doesn't notice because ASCII is directly representable in the lower 7 bits UTF-8 and what more does a good American citizen need? :) (and in any case, just convert to latin1 and you have universal support). Guess what we're using right now... :) I know UTF-8 is highly useful, but since it's just the flip of a switch and we don't really need it at the moment, it's causing more troubles than benefits. So I'd rather hold off with generating UTF-8 output for now. Input is a completely different matter, but I think right now the technical barrier to writing documentation is already high enough to require the writers to have a UTF-8 compatible environment. Since the charset is choosable on a file-by-file base anyways I don't see any problem using this feature for languages that need it. :) -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [Gimp-developer] style guide gimp-help-2
Am Mit, 2003-08-20 um 01.41 schrieb [EMAIL PROTECTED]: References are extremely important, more important than tutorials in prose, IMnsHO. This doesn't clash with my idea. Especially good cross references are important but this is exactly one of DocBooks' strengths. Now, maybe this can be combined, like a manpage-style reference + links to usage examples (that would imho be optimal!), plus introductory material. This is the plan. :) Yeah :( But providing good and useful documentation is extremely hard. I don't believe the Gimp will succeed, but if it does, it'll be _the_ prototypical free software rocks app for another reason again. Heh, don't be so negative, rather help us to bring the help up to par with your sense of quality, content- and structurewise. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
