Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Quentin Pradet]

Hello,

Stephen is right, using Python's os.sep is much better than using
DIR-SEPARATOR.


On Mon, Feb 24, 2014 at 9:36 PM, Pat David  wrote:

> Could someone with a better grasp of the material chime in to help iron
> this out so that we can possibly include it as either a tutorial or wiki
> material?  I have to confess to not being familiar enough with the material
> to be able to add anything meaningful beyond helping to translate to the
> proper format for inclusion on wgo. :)
>
>
> On Fri, Feb 21, 2014 at 6:38 PM, Stephen Kiel 
> wrote:
>
> >  Pat,
> >
> > I did look into the DIR-SEPARATOR (DIR_SEPARATOR on python?) constant. It
> > did not appear to be documented anywhere in the gimp docs that I could
> find
> > with a search engine.  From an old scheme script I found posted I was
> able
> > to find the following:
> >
> > The DIR-SEPARATOR constant appears to be just a "/" on platforms where
> the
> > OS is Linux and "\" on platforms where the OS is Windows.  The following
> is
> > pasted from a Script-Fu Console and a Python-Fu Console (Linux).
> >
> >  Script-Fu Console*
> >
> > Welcome to TinyScheme
> > Copyright (c) Dimitrios Souflis
> > Script-Fu Console - Interactive Scheme Development
> >
> > > (string-append "Yaba" DIR-SEPARATOR "Daba" DIR-SEPARATOR "Doo")
> > "Yaba/Daba/Doo"
> >
> >
> >  PYTHON CONSOLE*
> >
> > GIMP 2.8.10 Python Console
> > Python 2.7.5 (default, Feb 11 2014, 10:29:30)
> > [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)]
> > >>> import os
> > >>> print os.sep
> > /
> > >>> from gimpfu import *
> > >>> print DIR_SEPARATOR
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > NameError: name 'DIR_SEPARATOR' is not defined
> > >>> print DIR-SEPARATOR
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > NameError: name 'DIR' is not defined
> > >>> if DIR_SEPARATOR == "/":
> > ... print "YES"
> > ...
> > Traceback (most recent call last):
> >   File "", line 1, in 
> > NameError: name 'DIR_SEPARATOR' is not defined
> > >>>
> >
> > In python, os.sep does the same job that we would expect from
> > what we see in the scheme example except it has the following
> > advantages:
> >
> >1. It is documented
> >2. It has a wide user base, so it should be robust
> >3. It works in any python shell, so you can debug programs using wide
> >range of tools.
> >4. It works.
> >
> > It seems like os.sep would be a much better design choice **IF** we
> > actually needed to determine a platform portable directory separator.  As
> > far as I can tell, we don't.
> >
> > In the code I use python functions that take care of the separator.
> > e.g.
> > srcFile = os.path.join(srcPath, srcFile)
> > Python sticks in the right separator for the host OS.
> >
> > From my point of view, it seems like using the DIR_SEPARATOR and manually
> > concatenating strings would make the code clumsy. I did not see anywhere
> > where knowing what the separator character was would be
> > an advantage.
> >
> > I wanted to keep the focus of the tutorial on Automation and not get
> > sidetracked too much on design and architecture.  It is worth while to
> note
> > that if you can design a block of code (like autoBase.py) that does not
> use
> > the gimpfu library, you can run it on any python shell and use any
> > debugging tools at your disposal.  This is a real advantage over
> debugging
> > in Gimp.  So I view using a gimp constant instead of a python library
> > function (os.sep) as kind of a mistake.
> >
> > Please let me know if I missed something.
> >
> >
> > Stephen
> >
> > On 2/20/2014 1:03 PM, Pat David wrote:
> >
> >  Stephen,
> >
> >  Just a couple of notes.  There are some concerns about the introduction
> > of the term "macro" in the tutorial and the sense with which it's used.
> >
> >  Also, saul has asked me to relay to you: "have him look into the
> > DIR-SEPARATOR constant. Using it would obviate about half of his code."
> >
> >  If you can take a look at DIR-SEPARATOR to see if perhaps it can help
> > streamline things a bit, that would be great.  I'm also hoping others
> might
> > be able to chime in with other suggestions as well.
> >
> >  There is a consideration of moving this to the wiki as opposed to wgo as
> > well.
> >
> >
> >
> > On Thu, Feb 20, 2014 at 1:37 PM, Pat David  wrote:
> >
> >>  Stephen,
> >>
> >>  I've converted the tutorial to HTML to fit the website.  I've pushed it
> >> up along with the assets, and am now just waiting on someone to poke wgo
> >> for it to show up.  Keep an eye on the tutorials page.
> >>
> >>
> >> On Thu, Feb 20, 2014 at 1:29 PM, Stephen Kiel  >wrote:
> >>
> >>> Pat,
> >>> Thanks.  Let me know if there are any issues.
> >>>  Stephen
> >>>  On Feb 20, 2014 7:27 AM, "Pat David"  wrote:
> >>>
>   Hi Stephen!
> 
>   You can just leave it as an ODT file.  I'll make the stylistic
>  changes required to fit the website HTML.
> 
>   Give me a little time and I'll make the conversion and get it up

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Roman Joost]

On Mon, Feb 24, 2014 at 02:36:56PM -0600, Pat David wrote:
> Could someone with a better grasp of the material chime in to help iron
> this out so that we can possibly include it as either a tutorial or wiki
> material?  I have to confess to not being familiar enough with the material
> to be able to add anything meaningful beyond helping to translate to the
> proper format for inclusion on wgo. :)
This debate became a bit difficult to track over two mailing lists. Can
we please not do this?

For the debate regarding what the directory separator, I've to agree
with Stephen. If you want to create paths which are OS independent in
Python you usually rely on the `os.join` methods instead of
concatenating it explicitly with a constant. Besides, Script-Fu is based
on Schema, which is a functional language, where as Python follows more
the OOP idiom. That's perhaps why you don't want to translate examples
1:1.

My 2 cents :)

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

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Pat David]

Could someone with a better grasp of the material chime in to help iron
this out so that we can possibly include it as either a tutorial or wiki
material?  I have to confess to not being familiar enough with the material
to be able to add anything meaningful beyond helping to translate to the
proper format for inclusion on wgo. :)


On Fri, Feb 21, 2014 at 6:38 PM, Stephen Kiel  wrote:

>  Pat,
>
> I did look into the DIR-SEPARATOR (DIR_SEPARATOR on python?) constant. It
> did not appear to be documented anywhere in the gimp docs that I could find
> with a search engine.  From an old scheme script I found posted I was able
> to find the following:
>
> The DIR-SEPARATOR constant appears to be just a "/" on platforms where the
> OS is Linux and "\" on platforms where the OS is Windows.  The following is
> pasted from a Script-Fu Console and a Python-Fu Console (Linux).
>
>  Script-Fu Console*
>
> Welcome to TinyScheme
> Copyright (c) Dimitrios Souflis
> Script-Fu Console - Interactive Scheme Development
>
> > (string-append "Yaba" DIR-SEPARATOR "Daba" DIR-SEPARATOR "Doo")
> "Yaba/Daba/Doo"
>
>
>  PYTHON CONSOLE*
>
> GIMP 2.8.10 Python Console
> Python 2.7.5 (default, Feb 11 2014, 10:29:30)
> [GCC 4.8.2 20131212 (Red Hat 4.8.2-7)]
> >>> import os
> >>> print os.sep
> /
> >>> from gimpfu import *
> >>> print DIR_SEPARATOR
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'DIR_SEPARATOR' is not defined
> >>> print DIR-SEPARATOR
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'DIR' is not defined
> >>> if DIR_SEPARATOR == "/":
> ... print "YES"
> ...
> Traceback (most recent call last):
>   File "", line 1, in 
> NameError: name 'DIR_SEPARATOR' is not defined
> >>>
>
> In python, os.sep does the same job that we would expect from
> what we see in the scheme example except it has the following
> advantages:
>
>1. It is documented
>2. It has a wide user base, so it should be robust
>3. It works in any python shell, so you can debug programs using wide
>range of tools.
>4. It works.
>
> It seems like os.sep would be a much better design choice **IF** we
> actually needed to determine a platform portable directory separator.  As
> far as I can tell, we don't.
>
> In the code I use python functions that take care of the separator.
> e.g.
> srcFile = os.path.join(srcPath, srcFile)
> Python sticks in the right separator for the host OS.
>
> From my point of view, it seems like using the DIR_SEPARATOR and manually
> concatenating strings would make the code clumsy. I did not see anywhere
> where knowing what the separator character was would be
> an advantage.
>
> I wanted to keep the focus of the tutorial on Automation and not get
> sidetracked too much on design and architecture.  It is worth while to note
> that if you can design a block of code (like autoBase.py) that does not use
> the gimpfu library, you can run it on any python shell and use any
> debugging tools at your disposal.  This is a real advantage over debugging
> in Gimp.  So I view using a gimp constant instead of a python library
> function (os.sep) as kind of a mistake.
>
> Please let me know if I missed something.
>
>
> Stephen
>
> On 2/20/2014 1:03 PM, Pat David wrote:
>
>  Stephen,
>
>  Just a couple of notes.  There are some concerns about the introduction
> of the term "macro" in the tutorial and the sense with which it's used.
>
>  Also, saul has asked me to relay to you: "have him look into the
> DIR-SEPARATOR constant. Using it would obviate about half of his code."
>
>  If you can take a look at DIR-SEPARATOR to see if perhaps it can help
> streamline things a bit, that would be great.  I'm also hoping others might
> be able to chime in with other suggestions as well.
>
>  There is a consideration of moving this to the wiki as opposed to wgo as
> well.
>
>
>
> On Thu, Feb 20, 2014 at 1:37 PM, Pat David  wrote:
>
>>  Stephen,
>>
>>  I've converted the tutorial to HTML to fit the website.  I've pushed it
>> up along with the assets, and am now just waiting on someone to poke wgo
>> for it to show up.  Keep an eye on the tutorials page.
>>
>>
>> On Thu, Feb 20, 2014 at 1:29 PM, Stephen Kiel wrote:
>>
>>> Pat,
>>> Thanks.  Let me know if there are any issues.
>>>  Stephen
>>>  On Feb 20, 2014 7:27 AM, "Pat David"  wrote:
>>>
  Hi Stephen!

  You can just leave it as an ODT file.  I'll make the stylistic
 changes required to fit the website HTML.

  Give me a little time and I'll make the conversion and get it up to
 test.

  Thanks for the contribution!

  --
 pat david
 http://blog.patdavid.net

>>>
>>
>>
>>  --
>> pat david
>> http://blog.patdavid.net
>>
>
>
>
>  --
> pat david
> http://blog.patdavid.net
>
>
> --
> Stephen Kiel
> 26602 Strafford
> Mission Viejo, CA 92692
> Mobile/SMS (949) 702-1993
> Home (949) 367-2915  snick.kiel@gmail.comhttp://stephenkiel.blogspot.com/
>
>


-- 
pat david
htt

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Stephen Kiel]

Pat,

I did look into the DIR-SEPARATOR (DIR_SEPARATOR on python?) constant. 
It did not appear to be documented anywhere in the gimp docs that I 
could find with a search engine.  From an old scheme script I found 
posted I was able to find the following:


The DIR-SEPARATOR constant appears to be just a "/" on platforms where 
the OS is Linux and "\" on platforms where the OS is Windows. The 
following is pasted from a Script-Fu Console and a Python-Fu Console 
(Linux).


 Script-Fu Console*

Welcome to TinyScheme
Copyright (c) Dimitrios Souflis
Script-Fu Console - Interactive Scheme Development

> (string-append "Yaba" DIR-SEPARATOR "Daba" DIR-SEPARATOR "Doo")
"Yaba/Daba/Doo"


 PYTHON CONSOLE*

GIMP 2.8.10 Python Console
Python 2.7.5 (default, Feb 11 2014, 10:29:30)
[GCC 4.8.2 20131212 (Red Hat 4.8.2-7)]
>>> import os
>>> print os.sep
/
>>> from gimpfu import *
>>> print DIR_SEPARATOR
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'DIR_SEPARATOR' is not defined
>>> print DIR-SEPARATOR
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'DIR' is not defined
>>> if DIR_SEPARATOR == "/":
... print "YES"
...
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'DIR_SEPARATOR' is not defined
>>>

In python, os.sep does the same job that we would expect from
what we see in the scheme example except it has the following
advantages:

1. It is documented
2. It has a wide user base, so it should be robust
3. It works in any python shell, so you can debug programs using wide
   range of tools.
4. It works.

It seems like os.sep would be a much better design choice **IF** we 
actually needed to determine a platform portable directory separator.  
As far as I can tell, we don't.


In the code I use python functions that take care of the separator.
e.g.
srcFile = os.path.join(srcPath, srcFile)
Python sticks in the right separator for the host OS.

From my point of view, it seems like using the DIR_SEPARATOR and 
manually concatenating strings would make the code clumsy. I did not see 
anywhere where knowing what the separator character was would be

an advantage.

I wanted to keep the focus of the tutorial on Automation and not get 
sidetracked too much on design and architecture.  It is worth while to 
note that if you can design a block of code (like autoBase.py) that does 
not use the gimpfu library, you can run it on any python shell and use 
any debugging tools at your disposal.  This is a real advantage over 
debugging in Gimp.  So I view using a gimp constant instead of a python 
library function (os.sep) as kind of a mistake.


Please let me know if I missed something.

Stephen

On 2/20/2014 1:03 PM, Pat David wrote:

Stephen,

Just a couple of notes.  There are some concerns about the 
introduction of the term "macro" in the tutorial and the sense with 
which it's used.


Also, saul has asked me to relay to you: "have him look into the 
DIR-SEPARATOR constant. Using it would obviate about half of his code."


If you can take a look at DIR-SEPARATOR to see if perhaps it can help 
streamline things a bit, that would be great.  I'm also hoping others 
might be able to chime in with other suggestions as well.


There is a consideration of moving this to the wiki as opposed to wgo 
as well.




On Thu, Feb 20, 2014 at 1:37 PM, Pat David > wrote:


Stephen,

I've converted the tutorial to HTML to fit the website.  I've
pushed it up along with the assets, and am now just waiting on
someone to poke wgo for it to show up.  Keep an eye on the
tutorials page.


On Thu, Feb 20, 2014 at 1:29 PM, Stephen Kiel
mailto:snick.k...@gmail.com>> wrote:

Pat,
Thanks.  Let me know if there are any issues.
Stephen

On Feb 20, 2014 7:27 AM, "Pat David" mailto:patda...@gmail.com>> wrote:

Hi Stephen!

You can just leave it as an ODT file.  I'll make the
stylistic changes required to fit the website HTML.

Give me a little time and I'll make the conversion and get
it up to test.

Thanks for the contribution!

-- 
pat david

http://blog.patdavid.net




-- 
pat david

http://blog.patdavid.net




--
pat david
http://blog.patdavid.net


--
Stephen Kiel
26602 Strafford
Mission Viejo, CA 92692
Mobile/SMS (949) 702-1993
Home (949) 367-2915
snick.k...@gmail.com
http://stephenkiel.blogspot.com/

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

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Sam Gleske]

Thanks so much for your contribution!  I downloaded the PDF and ODT copy.
I plan on going through it and learning about it :D


On Wed, Feb 19, 2014 at 9:19 PM, Stephen Kiel  wrote:

> Pat,
>
> I finally finished the tutorial that I was talking about with you a couple
> of months ago.  You mentioned then that I could either send it in Word
> Processor format or take attempt to convert it to HTML.
>
> Which of the two methods would be easiest for you?  I am not sure if it is
> easier to fix a document that I might get partially 'right' or just start
> from scratch.  Maybe you could take a look at it and give me your opinion
> on the best way to proceed.
>
> I have it on a Box.net share at https://app.box.com/s/mbd93d12ha6t1gvzgbhy
>
> You should see the file AutomateEditingInGimp.odt and the corresponding
> .pdf file.  It was written using LibreOffice Writer.  The jpeg pictures in
> the same directory.  The code examples are in the directories plug-ins and
> myXml.
>
> I was able to get html directly out of Writer that looked real good in
> Firefox, I just don't know if some of the tags might cause problems within
> the help system.  If not, the job could be easy!  One problem that I did
> notice with the automatically generated html was that the images were no
> longer centered, but other than this issue, it looked good, and the links
> seemed to work.  If you want me to generate a copy of the html, let me
> know.
>
> The tutorial is kind of long, wish I could have made it shorter, but since
> it uses some Gimp features that aren't documented elsewhere, I had to
> expand on them.
>
> Anyway, let me know if there are issues or feedback and whether you think
> it would be better for you to format the tutorial or if you want me to take
> a first pass at it.
>
> Thanks,
>
> Stephen Kiel
>
>
> On Wed, Oct 16, 2013 at 12:21 PM, Pat David  wrote:
>
> > If you want to keep it in a word processor, I can just translate it from
> > there.
> >
> > You can also use google docs if you want to share it with my acct through
> > there.
> >
> >
> > On Wednesday, October 16, 2013, Stephen Kiel wrote:
> >
> >> Pat,
> >>
> >> That sounds great.  I will plan to write in a word processor (with a
> >> spell checker) & then dump it into bluefish to add the html tags.  If
> that
> >> works it should make the whole authoring process pretty
> straightforward.  I
> >> would prefer to stay in a word processor form rough to final draft &
> >> minimize editing of the html for of the document in order to avoid
> >> accidentally goofing up the closures.
> >>
> >> I am on my way out of town for a couple of days as well, I will touch
> >> base again when I get closer to a finished tutorial.
> >>
> >> Thanks,
> >>
> >> Stephen
> >>
> >>
> >> On Wed, Oct 16, 2013 at 7:20 AM, Pat David  wrote:
> >>
> >>> Just stick to clean, plain HTML and you should be fine. Style inline if
> >>> you want, I'll move it to an external style sheet anyway.
> >>>
> >>> You can publish screen grabs if gimp non problem I believe. Someone may
> >>> correct me.
> >>>
> >>> I'll be out of town for a few days, but just hit me up when you're
> ready
> >>> for testing.
> >>>
> >>>
> >>> --
> >>> pat david
> >>> http://blog.patdavid.net
> >>>
> >>>
> >>
> >>
> >> --
> >> Stephen Kiel
> >> 26602 Strafford
> >> Mission Viejo, CA 92692
> >> *Mobile/SMS (949) 702-1993 <%28949%29%20702-1993>*
> >> Home (949) 367-2915
> >> snick.k...@gmail.com
> >> http://stephenkiel.blogspot.com/
> >>
> >
> >
> > --
> > pat david
> > http://blog.patdavid.net
> >
> >
>
>
> --
> Stephen Kiel
> 26602 Strafford
> Mission Viejo, CA 92692
> *Mobile/SMS (949) 702-1993*
> Home (949) 367-2915
> snick.k...@gmail.com
> http://stephenkiel.blogspot.com/
> ___
> gimp-web-list mailing list
> gimp-web-l...@gnome.org
> https://mail.gnome.org/mailman/listinfo/gimp-web-list
>
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Stephen Kiel]

Pat,

The conversion to compatible HTML went much faster than I imagined. It 
looks like getting everybody comfortable with the tutorial is going to 
be the longer part of the process.


I looked at the notes, if we need to make some changes we can, I would 
rather not make a lot of changes if they aren't really necessary though. 
Let me comment back about the notes, I am not sure what to do about them 
at this point.


1. 'the term "macro" in the tutorial' - Where in the tutorial was it a
   problem, and what was the suggested alternative?  The term seemed
   pretty descriptive and non-proprietary, so I don't know where the
   problem lies.  Part of the wikipedia description of macro is -
   "Macros are used to make a sequence of computing instructions
   available to the programmer as a single program statement, making
   the programming task less tedious and less error-prone."  I am not
   stuck on using the term but would need to know what a better
   suggestion would be.
2. 'have him look into the DIR-SEPARATOR constant' - Again I really
   don't know what problem we are try to fix, the suggestion isn't very
   specific. I would say that it is the usual case that you can write a
   more efficient program - 2nd version - using a 1st version as a
   working model. I would actually be kind of surprised if there
   weren't several places where reviewing the code and productizing it
   produced code that is better from an aesthetic and maintenance point
   of view. But, that is kind of missing the point:
 * This is an Automation Tutorial. The efficiency from being able
   to edit 20 images in the time that it takes to edit one by hand.
 * It is not a programming tutorial nor is a rolled out change to
   Gimp. As I pointed out in the text - I am not a programmer.  The
   gimp - python environment is not great for debugging and in the
   past it was not robust.  If the code is working I would not be
   inclined to mess with it.  You could waste a lot of time by
   trying to get too cute with 'enhancements'.
 * If there is a real desire to productize the automation tools, I
   would be happy to work on that effort, but I am not really that
   interested in beautifying working code for a tutorial.
3. I think all of the Gimp Documentation should move to a Wiki.  The
   biggest hole in the documentation is topics not being covered and
   coverage that is out of date.  Lowering the threshold for people to
   contribute would be a great way to address this.  A Wiki seems like
   it would allow for a larger amount of participation than the current
   method of converting things to HTML by hand.
 * My concern about moving the tutorial to a Wiki site, is whether
   it would get buried in a corner of the internet that no one can
   find.  I certainly have no idea where this wiki is.  It would be
   a shame to do the work of writing a tutorial and then put it
   where no one sees it.
 * I think a Wiki format is great in that it can be kept current
   and follow the changes of Gimp.  As I said, I think all of the
   documentation should be ported to a Wiki.

Anyway, if there are some specific things that need to be fixed, let me 
know and we can address them.  I can be fairly flexible with changes, I 
just don't want to get into a loop - modifying code until someone like 
it. That has no real / specific goal.


If there is a documenation Wiki, let me know where to look, I would like 
to see what is there so far.


Thanks for all of your help!

Stephen




On 2/20/2014 1:03 PM, Pat David wrote:

Stephen,

Just a couple of notes.  There are some concerns about the 
introduction of the term "macro" in the tutorial and the sense with 
which it's used.


Also, saul has asked me to relay to you: "have him look into the 
DIR-SEPARATOR constant. Using it would obviate about half of his code."


If you can take a look at DIR-SEPARATOR to see if perhaps it can help 
streamline things a bit, that would be great.  I'm also hoping others 
might be able to chime in with other suggestions as well.


There is a consideration of moving this to the wiki as opposed to wgo 
as well.




On Thu, Feb 20, 2014 at 1:37 PM, Pat David > wrote:


Stephen,

I've converted the tutorial to HTML to fit the website.  I've
pushed it up along with the assets, and am now just waiting on
someone to poke wgo for it to show up.  Keep an eye on the
tutorials page.


On Thu, Feb 20, 2014 at 1:29 PM, Stephen Kiel
mailto:snick.k...@gmail.com>> wrote:

Pat,
Thanks.  Let me know if there are any issues.
Stephen

On Feb 20, 2014 7:27 AM, "Pat David" mailto:patda...@gmail.com>> wrote:

Hi Stephen!

You can just leave it as an ODT file.  I'll make the
stylistic changes required to fit the website HTML.

Give me a little time and I'll make the conversion and 

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Pat David]

Stephen,

Just a couple of notes.  There are some concerns about the introduction of
the term "macro" in the tutorial and the sense with which it's used.

Also, saul has asked me to relay to you: "have him look into the
DIR-SEPARATOR constant. Using it would obviate about half of his code."

If you can take a look at DIR-SEPARATOR to see if perhaps it can help
streamline things a bit, that would be great.  I'm also hoping others might
be able to chime in with other suggestions as well.

There is a consideration of moving this to the wiki as opposed to wgo as
well.



On Thu, Feb 20, 2014 at 1:37 PM, Pat David  wrote:

> Stephen,
>
> I've converted the tutorial to HTML to fit the website.  I've pushed it up
> along with the assets, and am now just waiting on someone to poke wgo for
> it to show up.  Keep an eye on the tutorials page.
>
>
> On Thu, Feb 20, 2014 at 1:29 PM, Stephen Kiel wrote:
>
>> Pat,
>> Thanks.  Let me know if there are any issues.
>> Stephen
>> On Feb 20, 2014 7:27 AM, "Pat David"  wrote:
>>
>>> Hi Stephen!
>>>
>>> You can just leave it as an ODT file.  I'll make the stylistic changes
>>> required to fit the website HTML.
>>>
>>> Give me a little time and I'll make the conversion and get it up to test.
>>>
>>> Thanks for the contribution!
>>>
>>> --
>>> pat david
>>> http://blog.patdavid.net
>>>
>>
>
>
> --
> pat david
> http://blog.patdavid.net
>



-- 
pat david
http://blog.patdavid.net
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Pat David]

Hi Stephen!

You can just leave it as an ODT file.  I'll make the stylistic changes
required to fit the website HTML.

Give me a little time and I'll make the conversion and get it up to test.

Thanks for the contribution!

-- 
pat david
http://blog.patdavid.net
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Stephen Kiel]

Pat,

I finally finished the tutorial that I was talking about with you a couple
of months ago.  You mentioned then that I could either send it in Word
Processor format or take attempt to convert it to HTML.

Which of the two methods would be easiest for you?  I am not sure if it is
easier to fix a document that I might get partially 'right' or just start
from scratch.  Maybe you could take a look at it and give me your opinion
on the best way to proceed.

I have it on a Box.net share at https://app.box.com/s/mbd93d12ha6t1gvzgbhy

You should see the file AutomateEditingInGimp.odt and the corresponding
.pdf file.  It was written using LibreOffice Writer.  The jpeg pictures in
the same directory.  The code examples are in the directories plug-ins and
myXml.

I was able to get html directly out of Writer that looked real good in
Firefox, I just don't know if some of the tags might cause problems within
the help system.  If not, the job could be easy!  One problem that I did
notice with the automatically generated html was that the images were no
longer centered, but other than this issue, it looked good, and the links
seemed to work.  If you want me to generate a copy of the html, let me know.

The tutorial is kind of long, wish I could have made it shorter, but since
it uses some Gimp features that aren't documented elsewhere, I had to
expand on them.

Anyway, let me know if there are issues or feedback and whether you think
it would be better for you to format the tutorial or if you want me to take
a first pass at it.

Thanks,

Stephen Kiel


On Wed, Oct 16, 2013 at 12:21 PM, Pat David  wrote:

> If you want to keep it in a word processor, I can just translate it from
> there.
>
> You can also use google docs if you want to share it with my acct through
> there.
>
>
> On Wednesday, October 16, 2013, Stephen Kiel wrote:
>
>> Pat,
>>
>> That sounds great.  I will plan to write in a word processor (with a
>> spell checker) & then dump it into bluefish to add the html tags.  If that
>> works it should make the whole authoring process pretty straightforward.  I
>> would prefer to stay in a word processor form rough to final draft &
>> minimize editing of the html for of the document in order to avoid
>> accidentally goofing up the closures.
>>
>> I am on my way out of town for a couple of days as well, I will touch
>> base again when I get closer to a finished tutorial.
>>
>> Thanks,
>>
>> Stephen
>>
>>
>> On Wed, Oct 16, 2013 at 7:20 AM, Pat David  wrote:
>>
>>> Just stick to clean, plain HTML and you should be fine. Style inline if
>>> you want, I'll move it to an external style sheet anyway.
>>>
>>> You can publish screen grabs if gimp non problem I believe. Someone may
>>> correct me.
>>>
>>> I'll be out of town for a few days, but just hit me up when you're ready
>>> for testing.
>>>
>>>
>>> --
>>> pat david
>>> http://blog.patdavid.net
>>>
>>>
>>
>>
>> --
>> Stephen Kiel
>> 26602 Strafford
>> Mission Viejo, CA 92692
>> *Mobile/SMS (949) 702-1993 <%28949%29%20702-1993>*
>> Home (949) 367-2915
>> snick.k...@gmail.com
>> http://stephenkiel.blogspot.com/
>>
>
>
> --
> pat david
> http://blog.patdavid.net
>
>


-- 
Stephen Kiel
26602 Strafford
Mission Viejo, CA 92692
*Mobile/SMS (949) 702-1993*
Home (949) 367-2915
snick.k...@gmail.com
http://stephenkiel.blogspot.com/
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Pat David]

If you want to keep it in a word processor, I can just translate it from
there.

You can also use google docs if you want to share it with my acct through
there.

On Wednesday, October 16, 2013, Stephen Kiel wrote:

> Pat,
>
> That sounds great.  I will plan to write in a word processor (with a spell
> checker) & then dump it into bluefish to add the html tags.  If that works
> it should make the whole authoring process pretty straightforward.  I would
> prefer to stay in a word processor form rough to final draft & minimize
> editing of the html for of the document in order to avoid accidentally
> goofing up the closures.
>
> I am on my way out of town for a couple of days as well, I will touch base
> again when I get closer to a finished tutorial.
>
> Thanks,
>
> Stephen
>
>
> On Wed, Oct 16, 2013 at 7:20 AM, Pat David 
> 
> > wrote:
>
>> Just stick to clean, plain HTML and you should be fine. Style inline if
>> you want, I'll move it to an external style sheet anyway.
>>
>> You can publish screen grabs if gimp non problem I believe. Someone may
>> correct me.
>>
>> I'll be out of town for a few days, but just hit me up when you're ready
>> for testing.
>>
>>
>> --
>> pat david
>> http://blog.patdavid.net
>>
>>
>
>
> --
> Stephen Kiel
> 26602 Strafford
> Mission Viejo, CA 92692
> *Mobile/SMS (949) 702-1993*
> Home (949) 367-2915
> snick.k...@gmail.com 
> http://stephenkiel.blogspot.com/
>


-- 
pat david
http://blog.patdavid.net
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Stephen Kiel]

Pat,

That sounds great.  I will plan to write in a word processor (with a spell
checker) & then dump it into bluefish to add the html tags.  If that works
it should make the whole authoring process pretty straightforward.  I would
prefer to stay in a word processor form rough to final draft & minimize
editing of the html for of the document in order to avoid accidentally
goofing up the closures.

I am on my way out of town for a couple of days as well, I will touch base
again when I get closer to a finished tutorial.

Thanks,

Stephen


On Wed, Oct 16, 2013 at 7:20 AM, Pat David  wrote:

> Just stick to clean, plain HTML and you should be fine. Style inline if
> you want, I'll move it to an external style sheet anyway.
>
> You can publish screen grabs if gimp non problem I believe. Someone may
> correct me.
>
> I'll be out of town for a few days, but just hit me up when you're ready
> for testing.
>
>
> --
> pat david
> http://blog.patdavid.net
>
>


-- 
Stephen Kiel
26602 Strafford
Mission Viejo, CA 92692
*Mobile/SMS (949) 702-1993*
Home (949) 367-2915
snick.k...@gmail.com
http://stephenkiel.blogspot.com/
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Pat David]

Just stick to clean, plain HTML and you should be fine. Style inline if you
want, I'll move it to an external style sheet anyway.

You can publish screen grabs if gimp non problem I believe. Someone may
correct me.

I'll be out of town for a few days, but just hit me up when you're ready
for testing.


-- 
pat david
http://blog.patdavid.net
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Marco Ciampa]

On Wed, Jul 24, 2013 at 08:10:09AM +0200, Marco Ciampa wrote:
> BTW I think that it is better for you to just create a patch and post it
> here to someone that have write permissions to "push" it into master
> branch ...

Ok I'll try to push your tutorial ... let me check it ...

-- 


Marco Ciampa

++
| Linux User  #78271 |
| FSFE fellow   #364 |
++
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Marco Ciampa]

First of all, I am not a git expert.

I am trying to help you in the hope to do and say not too much errors...

On Mon, Jul 22, 2013 at 07:22:07AM -0700, Stephen Kiel wrote:
> [stephen@localhost gimp-web-staging]$ which git
> /usr/bin/git
> [stephen@localhost gimp-web-staging]$ git config --global user.name "Stephen 
> Kiel"
> [stephen@localhost gimp-web-staging]$ git config --global user.email 
> snick.k...@gmail.com
> [stephen@localhost gimp-web-staging]$ git config --global color.ui auto
> [stephen@localhost gimp-web-staging]$ git clone git://git.gnome.org/gimp-web
> Cloning into 'gimp-web'...
> remote: Counting objects: 16053, done.
> remote: Compressing objects: 100% (6204/6204), done.
> remote: Total 16053 (delta 10709), reused 14402 (delta 9672)
> Receiving objects: 100% (16053/16053), 66.74 MiB | 387.00 KiB/s, done.
> Resolving deltas: 100% (10709/10709), done.
> [stephen@localhost gimp-web-staging]$ cd gimp-web/
> [stephen@localhost gimp-web]$ ls
> about  downloadsinstall.sh   release-notes
> admin  errorirc.htrw robots.txt
> announcements  features linksscreenshots
> archive.htrw   gimp-web.doapmacintoshsource
> books  google33e0e7c6a0a36ade.html  mail_lists.htrw  style
> bugs   images   MAINTAINERS  team.htrw
> ChangeLog  includes Makefile template.htrw
> contestindex.htrw   man  tutorials
> developINSTALL  news unix
> docs   install.config.samplenopatents.html   webmasters.htrw
> donating   install.exclude  programmatic windows

so far so good

> [stephen@localhost gimp-web]$ git branch -r
>   origin/2-8-temp
>   origin/HEAD -> origin/master
>   origin/master
>   origin/master_svn1715
>   origin/old-trunk
>   origin/static-html5
>   origin/v2.4
>   origin/v2.6

so far so good. At THIS point, if you do a 

git branch --all

you must see this like mine:

* master
  remotes/origin/2-8-temp
  remotes/origin/HEAD -> origin/master
  remotes/origin/master
  remotes/origin/master_svn1715
  remotes/origin/old-trunk
  remotes/origin/static-html5
  remotes/origin/v2.4
  remotes/origin/v2.6

that means that you have a local branch named "master" which is a
"tracking" local branch. That means that if you do just a 

 git pull

it will do a 

git fetch and then a git merge of the remote "master" branch into the local 
"master".

OK

If you prefer you can do a git pull --rebase to do a git fetch followed
by a git rebase of the remote "master" again into the local "master". 

...

> [stephen@localhost gimp-web]$ git checkout -b HEAD origin/HEAD
> Branch HEAD set up to track remote branch master from origin.
> Switched to a new branch 'HEAD'

with this you just create a _new_ local remote tracking branch with name
HEAD but since HEAD is a special name in git I think that this is an
error and you should avoid this. I think that you just followed an
example without undestanding it because that HEAD I think was there just
as an example... it meaning was something like this:

 git checkout -b put_here_the_name_of_your_local_branch 
origin/put_here_the_name_of_the_remote_branch_that_you_want_to_track

but since git clone already set up a local tracking branch you do not
have to do it ...

> warning: refname 'HEAD' is ambiguous.
> warning: refname 'HEAD' is ambiguous.

see? HEAD is not a good name!

BTW I think that it is better for you to just create a patch and post it
here to someone that have write permissions to "push" it into master
branch ...


-- 


Marco Ciampa

++
| Linux User  #78271 |
| FSFE fellow   #364 |
++
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Marco Ciampa]

On Mon, Jul 22, 2013 at 07:22:07AM -0700, Stephen Kiel wrote:
> Roman and Pat,
> 
> I have made some progress toward getting my tutorial ready for release, but
> I am at a point now where I have hit a wall, and I would like to ask for
> some advice on how to proceed.
> 
> I did do a final edit of the tutorial, format it into xhtml, and add a
> couple of pictures. I downloaded a copy of Bluefish and used it to format
> the material into an xhtml file adding the boilerplate provided in the
> tutorial template by hand. It seemed to render well in the Firefox browser.
> 
> I did find a procedure for adding content through git web at
> https://wiki.gnome.org/Git/Developers and followed it as best as I could. I
> was able to clone the gimp-web, check out a branch, make local changes and
> commit them, but then my progress stopped. My questions are:
> 
>  1) when I performed a 'git branch -r' several branches were listed. I
> guessed and picked HEAD as it appeared to link to origin/master. When I did
> a 'git status' and 'git commit -a' I got a warning message that “refname
> 'HEAD' is ambiguous”. Did I pick the wrong branch? Is there another
> problem, or is this warning normal?

HEAD is the generic name for the "head" of a [your] local branch... see this
for an intro into git:

http://www.sbf5.com/~cduan/technical/git/

what you probably want to do is:

git checkout master

to see _all_ the branches

git branch --all


>  2) The guidelines I was looking at seemed to be saying I could either use
> 'git-bz' or 'git push' to get my changes back to the main repository.

better to use the second ...

> Neither worked,

have you write rights?

> so I was wondering which technique I should focus on. Would
> rather not debug them both at this time (could use quite a bit of time,
> since I don't know what either is trying to do).
> 
>  The error message that I go with git-bz was:
> 
> > bash: git-bz: command not found...

if ubuntu / debian you have to:

apt-cache show git-bzr-ng

but ... are you more confident with bazar? Why you want to insist on use
such an iterface module? I do not suggest you to use such tool ... use
directly git!

> 
>  The error message from git push –dry-run was:
> 
> fatal: Could not read from remote repository.
> 
>  Please make sure you have the correct access rights

that was what I was saying above...

> 
> and the repository exists.
> 
>  A git pull –rebase right before trying the push seemed to find the
> repository and verify that my current branch is up to date.

ok

> 
>  I would appreciate any pointers you could give me. I am attaching a copy
> of the transcript from my shell session. I am also attaching a copy of the
> files I was trying to add & modify in case it is relevant or you would like
> to take a look at them.
> 

I'll look at those ...

>  In the mean time, I will start looking at git-bz in case that is the write
> way to go. It looks like there may be some setup issues, even though the
> error message make it look like it is an installation issue. The options
> for the bz command were not clear to me. The wiki page indicated the syntax
> should be:
> 
> git-bz file product/component HEAD
> 
> I am guessing the product should be 'gimp-web', but when I look at
> https://bugzilla.gnome.org/buglist.cgi?quicksearch=gimp-web I see the
> component listed as both gimp-web and www.gimp.org. Do you know which it
> should be, or whether it matters? 

git-web

> When it asks for 'file' I am assuming it
> is looking for the results of the local 'commit'. In my case the feedback
> was
> 
> [HEAD a97ce5a] Added tutorial Automate Creation fo XCF from JPG"
> 
> Are they looking for a97ce5a as the file?

see the illuminating above tutorial... that is a header and it is just a
checksum for your branch "state"

bye

PS: sorry I haven't followed the thread until now... I'll read all
mailing exchanges to give more useful answers ...

-- 


Marco Ciampa

++
| Linux User  #78271 |
| FSFE fellow   #364 |
++
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Stephen Kiel]

Roman & Pat,

I spent quite a bit of time fiddling round with git-bz and after
downloading it, configuring it, and trying to use it to send in the
differences from  checking my tutorial into git (local check out / check in
*seems* OK), I have come to the conclusion that this is probably not what
you guys are using because it sure seems to be - broken.  After trying to
send in a patch with git-bz it told me that I did not seem to be logged
into bugzilla.gnome.org in firefox - I am.  It does not seem to be able to
read the cookies (Firefox V22 on Fedora).

Is there a set of instructions written down anywhere that indicates what
format and method someone should use to send in changes, updates and new
content like a tutorial?  I did format the tutorial into web format and do
a checkout / check in into the repository, but not being able to get any
farther with it is beginning to take a lot of time.

The files I am trying to check in are in a share (should be easy to
download) at:

https://spideroak.com/browse/share/Stephen_Kiel_Pictures/Stephen_Kiel_Gimp_Tutorial

I would appreciate any help you could give me.  I will be on the road for
about a week, so I may be slow getting back to you.

Thanks,

Stephen


On Mon, Jul 22, 2013 at 7:22 AM, Stephen Kiel  wrote:

> Roman and Pat,
>
> I have made some progress toward getting my tutorial ready for release,
> but I am at a point now where I have hit a wall, and I would like to ask
> for some advice on how to proceed.
>
> I did do a final edit of the tutorial, format it into xhtml, and add a
> couple of pictures. I downloaded a copy of Bluefish and used it to format
> the material into an xhtml file adding the boilerplate provided in the
> tutorial template by hand. It seemed to render well in the Firefox browser.
>
> I did find a procedure for adding content through git web at
> https://wiki.gnome.org/Git/Developers and followed it as best as I could.
> I was able to clone the gimp-web, check out a branch, make local changes
> and commit them, but then my progress stopped. My questions are:
>
>  1) when I performed a 'git branch -r' several branches were listed. I
> guessed and picked HEAD as it appeared to link to origin/master. When I did
> a 'git status' and 'git commit -a' I got a warning message that “refname
> 'HEAD' is ambiguous”. Did I pick the wrong branch? Is there another
> problem, or is this warning normal?
>
>  2) The guidelines I was looking at seemed to be saying I could either
> use 'git-bz' or 'git push' to get my changes back to the main repository.
> Neither worked, so I was wondering which technique I should focus on. Would
> rather not debug them both at this time (could use quite a bit of time,
> since I don't know what either is trying to do).
>
>  The error message that I go with git-bz was:
>
> > bash: git-bz: command not found...
>
>  The error message from git push –dry-run was:
>
> fatal: Could not read from remote repository.
>
>  Please make sure you have the correct access rights
>
> and the repository exists.
>
>  A git pull –rebase right before trying the push seemed to find the
> repository and verify that my current branch is up to date.
>
>  I would appreciate any pointers you could give me. I am attaching a copy
> of the transcript from my shell session. I am also attaching a copy of the
> files I was trying to add & modify in case it is relevant or you would like
> to take a look at them.
>
>  In the mean time, I will start looking at git-bz in case that is the
> write way to go. It looks like there may be some setup issues, even though
> the error message make it look like it is an installation issue. The
> options for the bz command were not clear to me. The wiki page indicated
> the syntax should be:
>
> git-bz file product/component HEAD
>
> I am guessing the product should be 'gimp-web', but when I look at
> https://bugzilla.gnome.org/buglist.cgi?quicksearch=gimp-web I see the
> component listed as both gimp-web and www.gimp.org. Do you know which it
> should be, or whether it matters? When it asks for 'file' I am assuming it
> is looking for the results of the local 'commit'. In my case the feedback
> was
>
> [HEAD a97ce5a] Added tutorial Automate Creation fo XCF from JPG"
>
> Are they looking for a97ce5a as the file?
>
>  Thanks,
>
>  Stephen Kiel
>
>
> On Wed, Jul 10, 2013 at 10:49 PM, Roman Joost  wrote:
>
>> Dear Stephen,
>>
>> On Tue, Jul 02, 2013 at 12:37:33PM -0700, Stephen Kiel wrote:
>> > Roman,
>> >
>> > I did browse through some of the tutorials & looked at they way they
>> were
>> > marked up.  I don't think porting my tutorials into a markup language
>> will
>> > be any problem.  The part that I don't really understand yet is whether
>> > there are tags that will or won't work right.  In other words, if the
>> XHTLM
>> > is well formed and presents in a web browser is there any downstream
>> > processing that looks at or uses particular tags? e.g. some of the xhtml
>> > that I looked at used the older  tags f

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Roman Joost]

Dear Stephen,

On Tue, Jul 02, 2013 at 12:37:33PM -0700, Stephen Kiel wrote:
> Roman,
> 
> I did browse through some of the tutorials & looked at they way they were
> marked up.  I don't think porting my tutorials into a markup language will
> be any problem.  The part that I don't really understand yet is whether
> there are tags that will or won't work right.  In other words, if the XHTLM
> is well formed and presents in a web browser is there any downstream
> processing that looks at or uses particular tags? e.g. some of the xhtml
> that I looked at used the older  tags for bold instead of .
> Both work, one is more contemporary, but what I am wondering is whether
> there is a reason to use the older tag format.
Not sure. I think these are remnants of old edits which have simply been
updated for a new version of the website.

> Once I do get ready to check out the module and add my tutorial, is there
> any kind of an approval process, or do I just stage the changes and commit
> them?
Usually you can send in your patches and they're been reviewed by people
who have access to the module. The more you contribute, the more likely
maintainers see to getting you commit (read: push) rights.

> Thanks for the feedback & help.
Happy to help!

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

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Stephen Kiel]

Roman,

Thanks for getting back to me, your feedback wasn't discouraging, I just
didn't really know how to proceed (so no worries).

I completely understand peoples limited time, I am in the same boat, I did
not want to invest hours in writing, learning the nuances of a particular
markup language, only to have a barrier thrown up at the end.  This is the
reason for my questions.

I would be happy to format and maintain my own tutorial, as this is my
first contribution of any kind, I am completely unfamiliar with the
procedures, customs, and requirements for doing this on the gimp project.
It sounds like the barriers that you mentioned are more technical than
administrative, so that is actually pretty encouraging.

I am not quite ready to checkout a module and add my own tutorial just yet,
I need to read up on using Git for a collaborative project.  I have used
older CMS S/W (RCS, CVS) for collaborative projects, but that was a while
ago.  I will follow the link and do some reading.

I did browse through some of the tutorials & looked at they way they were
marked up.  I don't think porting my tutorials into a markup language will
be any problem.  The part that I don't really understand yet is whether
there are tags that will or won't work right.  In other words, if the XHTLM
is well formed and presents in a web browser is there any downstream
processing that looks at or uses particular tags? e.g. some of the xhtml
that I looked at used the older  tags for bold instead of .
Both work, one is more contemporary, but what I am wondering is whether
there is a reason to use the older tag format.

Once I do get ready to check out the module and add my tutorial, is there
any kind of an approval process, or do I just stage the changes and commit
them?

Thanks for the feedback & help.



On Mon, Jul 1, 2013 at 12:35 AM, Roman Joost  wrote:

> On Fri, Jun 28, 2013 at 05:09:49PM -0700, Stephen Kiel wrote:
> > Pat,
> >
> > Sorry for the delay in getting back to you.  I would really appreciate
> your
> > help.  While all of Roman's suggestions sounded positive and a great
> idea,
> > they left me wondering how I would go about accomplishing them.  Having
> > someone that has gone through a few of these steps or is going through
> them
> > would be a great help.
> Sorry if I sounded discouraging. The problem for most of the GIMP people
> is to take care of your contributions since there is only a limited
> amount of spare time available for all of us. At the moment, the file
> format you're using is incompatible at what is being used for the
> homepage and/or the manual. That means, someone would need to
> incorporate it.
>
> What you could do is, checkout the gimp-web module from:
>
> https://git.gnome.org/browse/gimp-web
>
> and try to add your tutorial. That should be something you can't export
> from libre office.
>
> As you can see, the barrier has already risen from simply contributing
> something you can write in an office application towards something where
> you need to write markup and perhaps even source code. Even more, you
> need to figure out how to incorporate your contributions instead of just
> making them available.
>
> Hope that makes things more clear on where to start, but feel free to
> follow your own ideas.
>
> Kind Regards,
> --
> Roman Joost
> www: http://www.romanofski.de
> email: romanof...@gimp.org
>



-- 
Stephen Kiel
26602 Strafford
Mission Viejo, CA 92692
*Mobile/SMS (949) 702-1993*
Home (949) 367-2915
snick.k...@gmail.com
http://stephenkiel.blogspot.com/
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Roman Joost]

On Wed, Jun 26, 2013 at 09:53:53AM -0500, Pat David wrote:
> > the best way to go with this is to become a maintainer of your content.
> 
> This is actually the step I am at currently while trying to contribute
> at least some time in updating and creating new tutorial content.
> 
> Stephen, I'll have some free time in a week or two if you want to send
> me the .odt files to have a look?  I might be able to help you get
> started as well...  (or at least caught up to my rather limited
> insight so far).
Thanks Pat for helping out!!

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

Re: [Gimp-docs] [Gimp-web] Proposed gimp tutorial

[Pat David]

> the best way to go with this is to become a maintainer of your content.

This is actually the step I am at currently while trying to contribute
at least some time in updating and creating new tutorial content.

Stephen, I'll have some free time in a week or two if you want to send
me the .odt files to have a look?  I might be able to help you get
started as well...  (or at least caught up to my rather limited
insight so far).
___
gimp-docs-list mailing list
gimp-docs-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-docs-list