Hi,

On Wed, Feb 5, 2014 at 9:51 PM, Roman Joost wrote:

Hi,

I've put together a Roadmap proposal under:

http://wiki.gimp.org/index.php/Documentation:Main

Any feedback is welcome. Some of the points are not to be read as: go ahead and implement, but rather look into it for it's feasibility.

If there are no objections or comments I'd basically call the roadmap silently as accepted. For each point I think it'll be good to create bugs so we can track progress.

I've not read it in details and mostly skimmed through.

I got intrigued by a specific point though: moving the manual to github. Really? I know several (all?) of GNOME's repos have already been *mirrored* to github. Personally I find it acceptable if repos are just mirrored (that's after all one of the point of git as a "distributed" revision control), but not if it is to be considered the new main repository of the project. github is just another of these platforms led by a company, just like was Sourceforge (and now look, with time, all projects are fleeing it, just as we did), and like will be some other "fashionable" platform in the future. So I say, we keep control of the main repo. And if a github mirror had to be created, that would only be to profit of its network effect (why not), but it must be soon clear to new contributors that they must sync with the GNOME repo in the end, not the github one.

Was that what you were proposing? If so, ok.

If you really propose to "move" the main repo to github (as it is worded on the wiki), then I personally vote against.

Jehan

Kind Regards,
--
Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org
_______________________________________________ gimp-developer-list mailing list
List address: gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list

On Thu, 2014-02-06 at 17:07 +1300, Jehan Pagès wrote:

Hi,

On Wed, Feb 5, 2014 at 9:51 PM, Roman Joost wrote:

Hi,

I've put together a Roadmap proposal under:

http://wiki.gimp.org/index.php/Documentation:Main

Any feedback is welcome. Some of the points are not to be read as: go ahead and implement, but rather look into it for it's feasibility.

If there are no objections or comments I'd basically call the roadmap silently as accepted. For each point I think it'll be good to create bugs so we can track progress.

I've not read it in details and mostly skimmed through.

I got intrigued by a specific point though: moving the manual to github. Really? I know several (all?) of GNOME's repos have already been *mirrored* to github. Personally I find it acceptable if repos are just mirrored (that's after all one of the point of git as a "distributed" revision control), but not if it is to be considered the new main repository of the project. github is just another of these platforms led by a company, just like was Sourceforge (and now look, with time, all projects are fleeing it, just as we did), and like will be some other "fashionable" platform in the future. So I say, we keep control of the main repo. And if a github mirror had to be created, that would only be to profit of its network effect (why not), but it must be soon clear to new contributors that they must sync with the GNOME repo in the end, not the github one.

Was that what you were proposing? If so, ok.

If you really propose to "move" the main repo to github (as it is worded on the wiki), then I personally vote against.

+1 from me.

Why would you move to github? I agree with everything Jehan said.

Regards, --Mitch

Στις 06/02/2014 10:16 πμ, ο/η Michael Natterer έγραψε:

On Thu, 2014-02-06 at 17:07 +1300, Jehan Pagès wrote:

Hi,

On Wed, Feb 5, 2014 at 9:51 PM, Roman Joost wrote:

Hi,

I've put together a Roadmap proposal under:

http://wiki.gimp.org/index.php/Documentation:Main

Any feedback is welcome. Some of the points are not to be read as: go ahead and implement, but rather look into it for it's feasibility.

If there are no objections or comments I'd basically call the roadmap silently as accepted. For each point I think it'll be good to create bugs so we can track progress.

I've not read it in details and mostly skimmed through.

I got intrigued by a specific point though: moving the manual to github. Really? I know several (all?) of GNOME's repos have already been *mirrored* to github. Personally I find it acceptable if repos are just mirrored (that's after all one of the point of git as a "distributed" revision control), but not if it is to be considered the new main repository of the project. github is just another of these platforms led by a company, just like was Sourceforge (and now look, with time, all projects are fleeing it, just as we did), and like will be some other "fashionable" platform in the future. So I say, we keep control of the main repo. And if a github mirror had to be created, that would only be to profit of its network effect (why not), but it must be soon clear to new contributors that they must sync with the GNOME repo in the end, not the github one.

Was that what you were proposing? If so, ok.

If you really propose to "move" the main repo to github (as it is worded on the wiki), then I personally vote against.

+1 from me.

Why would you move to github? I agree with everything Jehan said.

Regards, --Mitch

_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

+1 from me

+1 from me. Unless github has much better usability for working than our repo, even the network effect is doubtful.

On Thu, Feb 6, 2014 at 8:53 AM, dmtrs32 wrote:

Στις 06/02/2014 10:16 πμ, ο/η Michael Natterer έγραψε:

On Thu, 2014-02-06 at 17:07 +1300, Jehan Pagès wrote:

Hi,

On Wed, Feb 5, 2014 at 9:51 PM, Roman Joost wrote:

Hi,

I've put together a Roadmap proposal under:

http://wiki.gimp.org/index.php/Documentation:Main

Any feedback is welcome. Some of the points are not to be read as: go ahead and implement, but rather look into it for it's feasibility.

If there are no objections or comments I'd basically call the roadmap silently as accepted. For each point I think it'll be good to create bugs so we can track progress.

I've not read it in details and mostly skimmed through.

I got intrigued by a specific point though: moving the manual to github. Really? I know several (all?) of GNOME's repos have already been *mirrored* to github. Personally I find it acceptable if repos are just mirrored (that's after all one of the point of git as a "distributed" revision control), but not if it is to be considered the new main repository of the project. github is just another of these platforms led by a company, just like was Sourceforge (and now look, with time, all projects are fleeing it, just as we did), and like will be some other "fashionable" platform in the future. So I say, we keep control of the main repo. And if a github mirror had to be created, that would only be to profit of its network effect (why not), but it must be soon clear to new contributors that they must sync with the GNOME repo in the end, not the github one.

Was that what you were proposing? If so, ok.

If you really propose to "move" the main repo to github (as it is worded on the wiki), then I personally vote against.

+1 from me.

Why would you move to github? I agree with everything Jehan said.

Regards, --Mitch

_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

+1 from me

_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Hi Roman -
when you talk about a "3.0" manual version in "3.0" - I am with the impression that the
purposed changes would take place before GIMP 3.0 itself (as the next version shall be 2.10)

So - it looks like the purposed version numbering would dissociate the manual version from GIMP's version - is that so? I think that might be confusing - although on a second thought it could be a manageable confusion, if it is clearly specified, inv arious places, that, for example, gimp-help-2 "3.0" refers to "gimp-2.10" .

(As for the idea of going github I am of the same opinion as Jehan. We could put a mirror ("fork" in github parlor) there - but the authoritative repository
should, by the reasons listed and maybe some more, be kept in the gnome infrastructure).

regards,

js ->

Hi Roman -
when you talk about a "3.0" manual version in "3.0" - I am with the impression that the
purposed changes would take place before GIMP 3.0 itself (as the next version shall be 2.10)

So - it looks like the purposed version numbering would dissociate the manual version from GIMP's version - is that so? I think that might be confusing - although on a second thought it could be a manageable confusion, if it is clearly specified, inv arious places, that, for example, gimp-help-2 "3.0" refers to "gimp-2.10" .

(As for the idea of going github I am of the same opinion as Jehan. We could put a mirror ("fork" in github parlor) there - but the authoritative repository
should, by the reasons listed and maybe some more, be kept in the gnome infrastructure).

regards,

js ->

Hi,

I am warry about to use Publican.

Publican prohibits to use WORD(S) tag then allows tag only for internal hyperlink. (xreflabel is also disallowed.)
http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/appe-Users_Guide-Disallowed_elements_and_attributes.html

That means we need revise whole text so that each targeted section has a . In much cases on our document, we use with verb/noun for representing an action, a filter, or a tool of GIMP instead of using its title in the reference section. To replace it with , almost links may be reformed in 'see also' style, because it cannot be replaced with other adjusted phrase for inline context at referring text.

I presume some translators may unwelcome this restriction especially for languages that have conjugation and/or declension, when tag happens in the middle of text structure.

If this rule does not make any matters for you, Publican may be the best choice.

Cheers,
-=-=-=-
RyoTa SimaMoto

2014-02-05, Roman Joost :

Hi,

I've put together a Roadmap proposal under:

http://wiki.gimp.org/index.php/Documentation:Main

Any feedback is welcome. Some of the points are not to be read as: go ahead and implement, but rather look into it for it's feasibility.

If there are no objections or comments I'd basically call the roadmap silently as accepted. For each point I think it'll be good to create bugs so we can track progress.

Kind Regards, --
Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org
_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

RyoTa :

how much do you know about Publican? Do you think it is possible to change it so that it would allow
the extra forms in which we use these links could work? (We'd try to commit these changes upstream, of course).

otherwise, I agree it is not a suitable option.

js -> wrote:

Hi,

I am warry about to use Publican.

Publican prohibits to use WORD(S) tag then allows tag only for internal hyperlink. (xreflabel is also disallowed.)
http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/appe-Users_Guide-Disallowed_elements_and_attributes.html

That means we need revise whole text so that each targeted section has a . In much cases on our document, we use with verb/noun for representing an action, a filter, or a tool of GIMP instead of using its title in the reference section. To replace it with , almost links may be reformed in 'see also' style, because it cannot be replaced with other adjusted phrase for inline context at referring text.

I presume some translators may unwelcome this restriction especially for languages that have conjugation and/or declension, when tag happens in the middle of text structure.

If this rule does not make any matters for you, Publican may be the best choice.

Cheers,
-=-=-=-
RyoTa SimaMoto

2014-02-05, Roman Joost :

Hi,

I've put together a Roadmap proposal under:

http://wiki.gimp.org/index.php/Documentation:Main

Any feedback is welcome. Some of the points are not to be read as: go ahead and implement, but rather look into it for it's feasibility.

If there are no objections or comments I'd basically call the roadmap silently as accepted. For each point I think it'll be good to create bugs so we can track progress.

Kind Regards, --
Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org
_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

RyoTa :

how much do you know about Publican? Do you think it is possible to change it so that it would allow
the extra forms in which we use these links could work? (We'd try to commit these changes upstream, of course).

otherwise, I agree it is not a suitable option.

js -> wrote:

Hi,

I am warry about to use Publican.

Publican prohibits to use WORD(S) tag then allows tag only for internal hyperlink. (xreflabel is also disallowed.)
http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/appe-Users_Guide-Disallowed_elements_and_attributes.html

That means we need revise whole text so that each targeted section has a . In much cases on our document, we use with verb/noun for representing an action, a filter, or a tool of GIMP instead of using its title in the reference section. To replace it with , almost links may be reformed in 'see also' style, because it cannot be replaced with other adjusted phrase for inline context at referring text.

I presume some translators may unwelcome this restriction especially for languages that have conjugation and/or declension, when tag happens in the middle of text structure.

If this rule does not make any matters for you, Publican may be the best choice.

Cheers,
-=-=-=-
RyoTa SimaMoto

2014-02-05, Roman Joost :

Hi,

I've put together a Roadmap proposal under:

http://wiki.gimp.org/index.php/Documentation:Main

Any feedback is welcome. Some of the points are not to be read as: go ahead and implement, but rather look into it for it's feasibility.

If there are no objections or comments I'd basically call the roadmap silently as accepted. For each point I think it'll be good to create bugs so we can track progress.

Kind Regards, --
Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org
_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

On Fri, Feb 07, 2014 at 11:07:25AM -0200, Joao S. O. Bueno wrote:

Hi Roman -
when you talk about a "3.0" manual version in "3.0" - I am with the impression that the purposed changes would take place before GIMP 3.0 itself (as the next version shall be 2.10)

So - it looks like the purposed version numbering would dissociate the manual version from GIMP's version - is that so? I think that might be confusing - although on a second thought it could be a manageable confusion, if it is clearly specified, inv arious places, that, for example, gimp-help-2 "3.0" refers to "gimp-2.10" .

(As for the idea of going github I am of the same opinion as Jehan. We could put a mirror ("fork" in github parlor) there - but the authoritative repository
should, by the reasons listed and maybe some more, be kept in the gnome infrastructure).

I too agree. IMHO gimp-help should follow the gimp versioning convention for avoid confusion, i.e. the new gimp-help-2 should be gimp-2.10.

Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino  di due passi, lei si allontana
di due  passi. Faccio dieci  passi e  l'orizzonte si allontana  di dieci
passi.  Per quanto cammini, non la raggiunger  mai. A cosa serve
l'utopia? A questo: serve a camminare."              Eduardo Galeano

+--------------------+
| Linux User  #78271 |
| FSFE fellow   #364 |
+--------------------+

On Sat, Feb 08, 2014 at 12:26:11PM +0100, Marco Ciampa wrote:

IMHO gimp-help should follow the gimp versioning convention for avoid confusion, i.e. the new gimp-help-2 should be gimp-2.10.

May I rewrite the wiki in this respect?

Marco Ciampa

"L'utopia sta all'orizzonte. Mi avvicino  di due passi, lei si allontana
di due  passi. Faccio dieci  passi e  l'orizzonte si allontana  di dieci
passi.  Per quanto cammini, non la raggiunger  mai. A cosa serve
l'utopia? A questo: serve a camminare."              Eduardo Galeano

+--------------------+
| Linux User  #78271 |
| FSFE fellow   #364 |
+--------------------+

So - while we don't make a major decision about the roadmap (hello LGM :-) ), or have a branch to work on changes for GIMP -2.10 - do we have at least a wiki page where we can take notes of things that should go into the manual?

(I'd be for creating a "2.10" branch and start editing the XML english SRC there - there will be quite a lot of news for this release, and it would be said to have to wait over an year for the manual to catch-up when it is out).

I remebered this e-mail thread because I added some changes to the "align" tool yesterday, which would make for 1 or 2 paragraphs in the manual - but also, now, looking at the logs I saw just this:

""" commit dd648b1c1264a70ade137276293e827b40954eca Author: Michael Natterer
Date: Sun May 19 22:21:38 2013 +0200

...skipping... Don't allow tool operations on invisible items, just like we do for group layers or locked items.

Cleaned up and enhanced the patch a bit --Mitch """
Which means: trying to paint in an invisible, active, layer works up to GIMP 2.8, but is a NOp in
GIMP Master.
It is there for over an year, and I had not taken note - yet, it should be mentioned in the manual, as it is in some aspects a big change in the way GIMP used to work. (And I see no drawbacks in it)

js -> wrote:

Dear RyoTa,

On Fri, Feb 07, 2014 at 11:52:13PM +0900, RyoTa SimaMoto wrote:

Hi,

I am warry about to use Publican.

Publican prohibits to use WORD(S) tag then allows tag only for internal hyperlink. (xreflabel is also disallowed.)
http://jfearn.fedorapeople.org/en-US/Publican/3.2/html/Users_Guide/appe-Users_Guide-Disallowed_elements_and_attributes.html

That means we need revise whole text so that each targeted section has a . In much cases on our document, we use with verb/noun for representing an action, a filter, or a tool of GIMP instead of using its title in the reference section. To replace it with , almost links may be reformed in 'see also' style, because it cannot be replaced with other adjusted phrase for inline context at referring text.

Cheers for pointing this out. It seems that this needs to be looked at closer in order to figure out the best way to go about it. A migration seems to be quite costly...

I presume some translators may unwelcome this restriction especially for languages that have conjugation and/or declension, when tag happens in the middle of text structure.

Thanks for this valuable pointer. To keep the discussion for this topic in one place, would you mind moving this to the associated bug?

https://bugzilla.gnome.org/show_bug.cgi?id=723512

Cheers! --
Roman Joost
www: http://www.romanofski.de
email: romanofski@gimp.org
_______________________________________________ gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

On 13 March 2014 16:38, Joao S. O. Bueno wrote:

So - while we don't make a major decision about the roadmap (hello LGM :-) ), or have a branch to work on changes for GIMP -2.10 - do we have at least a wiki page where we can take notes of things that should go into the manual?

No reply for this, while tens of smallish features are getting added to GIMP 2.9 with no documentation at all. :-(

I've justed commited docs for one such small change as commented-out xml code in the appropriate file.

js ->