From mario.sopena at gmail.com  Fri Feb  1 12:29:17 2008
From: mario.sopena at gmail.com (Mario Sopena Novales)
Date: Fri, 1 Feb 2008 18:29:17 +0100
Subject: [Mono-docs-list] monodoc Licensing
In-Reply-To: <479A4F73.5050009@extremeboredom.net>
References: <1201288491.25514.145.camel@lina.magi.jprl.com>
	<Pine.LNX.4.64-044.0801251434540.11027@unix34.andrew.cmu.edu>
	<479A4F73.5050009@extremeboredom.net>
Message-ID: <ef36f55f0802010929r12720131m55acf5a879340898@mail.gmail.com>

Sorry for answering late but I was on vacation.

Fine for me too

On 25/01/2008, Eric Butler <eric at extremeboredom.net> wrote:
> Fine with me too.
>   - Eric
>
> Ben Maurer wrote:
> > Hi Jon,
> >
> > Long time, no talk. I hope you are doing well. MIT/X11 is fine for
> > anything I've written in monodoc.
> >
> > -b
> >
> > On Fri, 25 Jan 2008, Jonathan Pryor wrote:
> >
> >> Joshua et al,
> >>
> >> You wrote and contributed to the monodoc module & many related
> >> utilities, such as monodocer, monodocs2html, etc., in addition to
> >> monodoc/engine and related documentation providers.
> >>
> >> The monodoc module currently claims to be under the GPL, as does
> >> `monodocer --version` and monodocs2html.
> >>
> >> How would you feel about relicensing these contributions under MIT/X11?
> >>
> >> No major reason, aside from an eventual simplification of Mono's
> >> licensing policy from GPL/LGPL/MIT-X11 to LGPL/MIT-X11, and I don't see
> >> much reason to prevent non-GPL-compliant reuse of these libraries and
> >> apps...
> >>
> >> Thanks,
> >> - Jon
> >>
> >>
> >>
> >>
>

From jonpryor at vt.edu  Tue Feb  5 09:01:24 2008
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Tue, 05 Feb 2008 09:01:24 -0500
Subject: [Mono-docs-list] [Mono-dev] monodocer ignores "internal
	protected" members
In-Reply-To: <1202214401.6395.9.camel@linux-laptop>
References: <1202214401.6395.9.camel@linux-laptop>
Message-ID: <1202220084.15602.149.camel@lina.magi.jprl.com>

On Tue, 2008-02-05 at 13:26 +0100, Stefan Noack wrote:
> I'm not sure whether this problem is subject to this list but I didn't
> find a better place to report my problem.

mono-docs-list is the normal place for this.

> I use monodocer with -importslashdoc to import XML documentation from
> the files generated by the compiler from in-source XML documentation. As
> it should be internal and private classes/members are ignored. However,
> internal protected members should not be ignored as they are accessible
> to someone overriding class members. They are present in the XML files
> generated by the compiler, though. I neither found an option telling
> monodocer not to ignore internal protected classes/members nor did I
> find a bug report about this issue. 

What version of mono is this?  That was fixed on 2007-03-15 so that
internal protected members were documented; it's even checked in the
unit tests.  I'm not sure which Mono release came after that, but it's
been fixed in svn for nearly a year.

If you have a recent version of monodocer and it still fails for you,
could you file a minimal reproducible test case at bugzilla.novell.com?

Thanks,
 - Jon



From jonpryor at vt.edu  Tue Feb  5 14:00:53 2008
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Tue, 05 Feb 2008 14:00:53 -0500
Subject: [Mono-docs-list] [Mono-dev] monodocer ignores "internal
	protected" members
In-Reply-To: <1202231367.6320.7.camel@linux-laptop>
References: <1202214401.6395.9.camel@linux-laptop>
	<1202220084.15602.149.camel@lina.magi.jprl.com>
	<1202231367.6320.7.camel@linux-laptop>
Message-ID: <1202238053.21046.3.camel@lina.magi.jprl.com>

On Tue, 2008-02-05 at 18:09 +0100, Stefan Noack wrote:
> > What version of mono is this? 
> 
> This is strange. I use mono 1.2.6 and the monodoc 1.2.6 gentoo ebuild
> which afaik contains monodocer. But it looks strange, though:
> 
> noah at linux-laptop ~/prog/liblamp/trunk $ monodocer --version
> Monodocer - The Mono Documentation Tool  0.0.0.0 - Copyright (c) 2004
> Joshua Tauberer <tauberer at for.net>
> released under the GPL.
> A tool for creating and updating Mono XML documentation files for
> assemblies.

You can ignore the 0.0.0.0 version number; it's automatically generated
by Mono.GetOptions, and has no relation to any actual monodocer or mono
version number.

Mono 1.2.6 should have an up-to-date monodocer, so I'm surprised that
you're seeing this problem with protected internal members.

> I think the ebuild might be wrong and uses old code or something. Thanks
> for your help :) Maybe i should switch to the SVN sources?

You shouldn't need to switch to svn or anything.

Please file a bug at bugzilla.novell.com and I'll take a look at it.

 - Jon



From mfisher1966 at comcast.net  Sat Feb  9 00:22:47 2008
From: mfisher1966 at comcast.net (mfisher1966 at comcast.net)
Date: Sat, 09 Feb 2008 05:22:47 +0000
Subject: [Mono-docs-list] Correction to Mono_Basics
Message-ID: <020920080522.24252.47AD38A7000320AC00005EBC2207021053C0C0C7CE9D0A089C070003@comcast.net>

New Mono user, etc. -- what a cool project!

What's the drill for reporting documentation issues or helping to make the edits? I see the "Editor Login" links, but there doesn't seem to be a registration form for new editors. 

Wild guess -- it won't be too far off topic to mention the issue on this list. I'm using OpenSuse 10.2, and have been stepping through the examples from this page:

  http://www.mono-project.com/Mono_Basics

Everything goes OK, except the "Winforms Hello World" example. I did find a solution over on the Ubuntu forums, which is to compile using either of the following commands:

  mcs hello.cs -r:System.Windows.Forms.dll -r:System.Drawing.dll
  gmcs hello.cs -r:System.Windows.Forms.dll -r:System.Drawing.dll

Best,

 - Matt

From jonpryor at vt.edu  Sat Feb  9 05:00:02 2008
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Sat, 09 Feb 2008 05:00:02 -0500
Subject: [Mono-docs-list] Correction to Mono_Basics
In-Reply-To: <020920080522.24252.47AD38A7000320AC00005EBC2207021053C0C0C7CE9D0A089C070003@comcast.net>
References: <020920080522.24252.47AD38A7000320AC00005EBC2207021053C0C0C7CE9D0A089C070003@comcast.net>
Message-ID: <1202551202.14650.48.camel@lina.magi.jprl.com>

On Sat, 2008-02-09 at 05:22 +0000, mfisher1966 at comcast.net wrote:
> Wild guess -- it won't be too far off topic to mention the issue on
> this list. I'm using OpenSuse 10.2, and have been stepping through the
> examples from this page:
> 
>   http://www.mono-project.com/Mono_Basics
> 
> Everything goes OK, except the "Winforms Hello World" example. I did
> find a solution over on the Ubuntu forums, which is to compile using
> either of the following commands:

Using -pkg:dotnet doesn't work for you?  At least on 10.3, dotnet.pc is
part of the mono-devel package; you might want to install the mono-devel
package if you don't have it installed.

 - Jon


From m.j.hutchinson at gmail.com  Sat Feb  9 14:59:25 2008
From: m.j.hutchinson at gmail.com (Michael Hutchinson)
Date: Sat, 9 Feb 2008 14:59:25 -0500
Subject: [Mono-docs-list] Correction to Mono_Basics
In-Reply-To: <020920080522.24252.47AD38A7000320AC00005EBC2207021053C0C0C7CE9D0A089C070003@comcast.net>
References: <020920080522.24252.47AD38A7000320AC00005EBC2207021053C0C0C7CE9D0A089C070003@comcast.net>
Message-ID: <aec34c770802091159m7e75fbc5q9f7827c5ecdb3571@mail.gmail.com>

On Feb 9, 2008 12:22 AM,  <mfisher1966 at comcast.net> wrote:
> New Mono user, etc. -- what a cool project!
>
> What's the drill for reporting documentation issues or helping to make the edits? I see the "Editor Login" links, but there doesn't seem to be a registration form for new editors.

Accounts are only available on request (though not from me!), because
of past problems with spam bots.

-- 
Michael Hutchinson
http://mjhutchinson.com

From noackstefan at googlemail.com  Tue Feb  5 12:09:27 2008
From: noackstefan at googlemail.com (Stefan Noack)
Date: Tue, 05 Feb 2008 18:09:27 +0100
Subject: [Mono-docs-list] [Mono-dev] monodocer ignores "internal
	protected" members
In-Reply-To: <1202220084.15602.149.camel@lina.magi.jprl.com>
References: <1202214401.6395.9.camel@linux-laptop>
	<1202220084.15602.149.camel@lina.magi.jprl.com>
Message-ID: <1202231367.6320.7.camel@linux-laptop>

> What version of mono is this?  That was fixed on 2007-03-15 so that
> internal protected members were documented; it's even checked in the
> unit tests.  I'm not sure which Mono release came after that, but it's
> been fixed in svn for nearly a year.
> 
> If you have a recent version of monodocer and it still fails for you,
> could you file a minimal reproducible test case at bugzilla.novell.com?
> 

This is strange. I use mono 1.2.6 and the monodoc 1.2.6 gentoo ebuild
which afaik contains monodocer. But it looks strange, though:

noah at linux-laptop ~/prog/liblamp/trunk $ monodocer --version
Monodocer - The Mono Documentation Tool  0.0.0.0 - Copyright (c) 2004
Joshua Tauberer <tauberer at for.net>
released under the GPL.
A tool for creating and updating Mono XML documentation files for
assemblies.

I think the ebuild might be wrong and uses old code or something. Thanks
for your help :) Maybe i should switch to the SVN sources?

Stefan
-- 
Check out my open source .NET physics library project at
http://liblamp.sourceforge.net


From sucotronic at gmail.com  Wed Feb 13 10:40:19 2008
From: sucotronic at gmail.com (Suco)
Date: Wed, 13 Feb 2008 16:40:19 +0100
Subject: [Mono-docs-list] How to update documentation
Message-ID: <256d62360802130740x2c2da90fr37cc5a5e4d032374@mail.gmail.com>

I was looking for info of how to show an icon in the system tray, and
I found this page:

http://www.mono-project.com/GtkSharpNotificationIcon

But the info is outdated and now exists other more efficient way to do that:

StatusIcon trayIcon = new StatusIcon(Gdk.Pixbuf.LoadFromResource("icon.png"));
trayIcon.Visible = true;
trayIcon.Activate += OnTrayIconClicked;
trayIcon.PopupMenu += OnTrayIconPopup;
trayIcon.Tooltip = Catalog.GetString("example icon");

How can I update the page? or Can a maintainer update the info?

From jonpryor at vt.edu  Wed Feb 20 21:07:11 2008
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Wed, 20 Feb 2008 21:07:11 -0500
Subject: [Mono-docs-list] mdoc: Introduction and RFC
Message-ID: <1203559631.20719.150.camel@lina.magi.jprl.com>

I think the monodoc tools need an "umbrella" program, in the spirit of
svn or git, where instead of doing "monodocer ARGS" we could instead do 
"mdoc update ARGS".

The reasons for this are threefold:

1. Many moons ago, I wrote man pages for many of the monodoc tools, and
was somewhat annoyed because there was no "umbrella" term/program to use
for the collection of apps.  In particular, monodocer, monodocs2html,
and monodocs2slashdoc (among others) should be able to reference the XML
schema used, but currently only monodocer does.  Certainly,
monodocs2html and monodocs2slashdoc could reference the monodocer man
page, but this doesn't seem "clean" to me; at minimum, the XML schema
docs should be in section 5, not section 1 (as is currently done), but a
`monodocer(5)' section just seems wrong.

2. I foresee adding additional programs, and don't want to pollute $PATH
with additional programs.

3. I (personally) find it annoying when related apps don't have a common
prefix.  Now, we have mdassembler, mdvalidator, monodocer,
monodocs2html...  The only common prefix is "m", which doesn't create
any association between them when using bash tab completion...

Consequently, I've written a `mdoc' front-end to most of these programs,
which has a _different_ set of command-line arguments than the
underlying programs.  The primary reason for the change is for
consistency, so that all of the mdoc sub-programs are similar.

Attached are two files:

  - mdoc.txt is the `mdoc help' output, listing all of the sub-commands.
  - mdoc.commands.txt is the `mdoc help COMMAND' output for each of the 
    sub-commands.

Some changes I'd like to highlight:

  - `mdoc assemble' uses the same format for all directories, while 
    `mdassembler' allows you to specify a different format for each 
    directory; to compare/contrast:

	mdoc assemble -o netdocs --format=ecma corlib/en System/en ...
	mdassembler -o netdocs --ecma corlib/en --ecma System/en ...

    The added flexibility of mdassembler might be useful...if anything
    actually used it; monodoc/class does not.  By requiring only one
    format for all directories listed, this improves consistency with 
    the other apps, as all of them take a trailing list of 
    files/directories for various purposes (usually input files).

    This is also consistent with things like mdvalidator, which use a 
    single provider for all remaining options.

  - `mdoc update' has *far* fewer options than monodocer, mostly because
    I can't see the need for some monodocer options such as 
    -ignore_extra_docs (it should die now), -pretty (when don't you want
    nicely formatted XML?), -name, -since, etc.

Is there interest in this (or am I wasting my time)?  Any feedback on
the command names and the argument lists?

Thanks,
 - Jon

-------------- next part --------------
usage: mdoc COMMAND [OPTIONS]
Use `mdoc help COMMAND' for help on a specific command.

Available commands:

   assemble
   create
   export-html
   export-slashdoc
   help
   import-ecma
   import-slashdoc
   normalize
   update
   validate

mdoc is a tool for documentation management.
For additional information, see http://www.mono-project.com/
-------------- next part --------------
usage: mdoc assemble [OPTIONS]+ DIRECTORIES
Assemble documentation within DIRECTORIES for use within the monodoc browser.

Available Options:
  -f, --format=FORMAT        The documentation FORMAT used in DIRECTORIES.  
                               Valid formats include:
                                 ecma
                                 ecmaspec
                                 error
                                 hb
                                 man
                                 simple
                                 xhtml
  -o, --out=PREFIX           Provides the output file prefix; the files 
                               PREFIX.zip and PREFIX.tree will be created.
                               If not specified, `tree' is the default PREFIX.
  -h, -?, --help             Show this message and exit.

usage: mdoc create [OPTIONS]+ ASSEMBLIES
Create or update documentation from ASSEMBLIES.

Available Options:
  -i, --import=FORMAT:FILE   Import documentation from FILE in the specified 
                               FORMAT.  Supported formats include:
                                 ecma
                                 slashdoc
      --delete               Delete removed members from the XML files.
  -o, --out=DIRECTORY        Root DIRECTORY to generate/update documentation.
  -h, -?, --help             Show this message and exit.

usage: mdoc export-html [OPTIONS]+ DIRECTORIES
Export mdoc documentation within DIRECTORIES to HTML.

Available Options:
      --ext=EXTENSION        The file EXTENSION to use for created files.  
                               This defaults to "html".
      --template=FILE        An XSLT FILE to use to generate the created 
                               files.  If not specified, uses the template 
                               generated by --dump-template.
      --default-template     Writes the default XSLT to stdout.
  -o, --out=DIRECTORY        The DIRECTORY to place the generated files and 
                               directories.
  -h, -?, --help             Show this message and exit.

usage: mdoc export-slashdoc [OPTIONS]+ DIRECTORIES
Export mdoc documentation within DIRECTORIES into /doc XML files.

The file created is based on DIRECTORY/index.xml, in the 
(XPath) /Overview/Assemblies/Assembly/@Name attribute.

Available Options:
  -h, -?, --help             Show this message and exit.

usage: mdoc import-ecma [OPTIONS]+ ASSEMBLIES
Create or update documentation from ASSEMBLIES.

Available Options:
  -i, --import-from=FILE     Import documentation from FILE.
  -o, --out=DIRECTORY        Root DIRECTORY to generate/update documentation.
  -h, -?, --help             Show this message and exit.

usage: mdoc import-slashdoc [OPTIONS]+ ASSEMBLIES
Create or update documentation from ASSEMBLIES.

Available Options:
  -i, --import-from=FILE     Import documentation from FILE.
  -o, --out=DIRECTORY        Root DIRECTORY to generate/update documentation.
  -h, -?, --help             Show this message and exit.

usage: mdoc normalize FILES
Normalize XML documents.

Available Options:
  -h, -?, --help             Show this message and exit.

usage: mdoc update [OPTIONS]+ ASSEMBLIES
Create or update documentation from ASSEMBLIES.

Available Options:
  -i, --import=FORMAT:FILE   Import documentation from FILE in the specified 
                               FORMAT.  Supported formats include:
                                 ecma
                                 slashdoc
      --delete               Delete removed members from the XML files.
  -o, --out=DIRECTORY        Root DIRECTORY to generate/update documentation.
  -h, -?, --help             Show this message and exit.

usage: mdoc validate [OPTIONS]+ PATHS
Validate PATHS against the specified format schema.

Available Options:
  -f, --format=FORMAT        The documentation FORMAT used within PATHS.  
                               Valid formats include:
                                 ecma
                               If no format provided, `ecma' is used.
  -h, -?, --help             Show this message and exit.

From jit at occams.info  Thu Feb 21 06:58:11 2008
From: jit at occams.info (Joshua Tauberer)
Date: Thu, 21 Feb 2008 06:58:11 -0500
Subject: [Mono-docs-list] mdoc: Introduction and RFC
In-Reply-To: <1203559631.20719.150.camel@lina.magi.jprl.com>
References: <1203559631.20719.150.camel@lina.magi.jprl.com>
Message-ID: <47BD6753.70302@occams.info>

Hey, Jon.

Why not just merge all of the tools into a mdoc.exe (with the new 
options parsing library to boot), rather than wrapping them all with a 
script?

But otherwise I think it's a good idea.

>   - `mdoc update' has *far* fewer options than monodocer, mostly because
>     I can't see the need for some monodocer options such as 
>     -ignore_extra_docs (it should die now), -pretty (when don't you want
>     nicely formatted XML?), -name, -since, etc.

I think I added -pretty because reformatting XML causes problems with 
version control. And I don't even recall what -name does.

Josh

From mario.sopena at gmail.com  Thu Feb 21 07:08:12 2008
From: mario.sopena at gmail.com (Mario Sopena Novales)
Date: Thu, 21 Feb 2008 13:08:12 +0100
Subject: [Mono-docs-list] mdoc: Introduction and RFC
In-Reply-To: <47BD6753.70302@occams.info>
References: <1203559631.20719.150.camel@lina.magi.jprl.com>
	<47BD6753.70302@occams.info>
Message-ID: <ef36f55f0802210408i511b7af5nab989e50610f18fd@mail.gmail.com>

Hi,

   I also think it is a good Idea. Go ahead.



On 21/02/2008, Joshua Tauberer <jit at occams.info> wrote:
>
> Hey, Jon.
>
> Why not just merge all of the tools into a mdoc.exe (with the new
> options parsing library to boot), rather than wrapping them all with a
> script?
>
> But otherwise I think it's a good idea.
>
>
> >   - `mdoc update' has *far* fewer options than monodocer, mostly because
> >     I can't see the need for some monodocer options such as
> >     -ignore_extra_docs (it should die now), -pretty (when don't you want
> >     nicely formatted XML?), -name, -since, etc.
>
>
> I think I added -pretty because reformatting XML causes problems with
> version control. And I don't even recall what -name does.
>
> Josh
> _______________________________________________
> Mono-docs-list maillist  -  Mono-docs-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-docs-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-docs-list/attachments/20080221/df9e150f/attachment-0001.html 

From jonpryor at vt.edu  Thu Feb 21 07:24:25 2008
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Thu, 21 Feb 2008 07:24:25 -0500
Subject: [Mono-docs-list] mdoc: Introduction and RFC
In-Reply-To: <47BD6753.70302@occams.info>
References: <1203559631.20719.150.camel@lina.magi.jprl.com>
	<47BD6753.70302@occams.info>
Message-ID: <1203596665.20719.177.camel@lina.magi.jprl.com>

On Thu, 2008-02-21 at 06:58 -0500, Joshua Tauberer wrote:
> Why not just merge all of the tools into a mdoc.exe (with the new 
> options parsing library to boot), rather than wrapping them all with a 
> script?

Because that would imply removing the older tools, which would break any
number of existing projects; I know that removing monodocer and
monodocs2html would break Mono.Fuse and NDesk.Options, and probably
Gtk#.  These tools will need to remain for the foreseeable future, and
potentially may never be removed.  New tools can be restricted to just
mdoc sub-commands.

Furthermore, mdoc isn't a shell script, it is a C# .exe.  As such, I can
do such wonderful things as -r:monodocer.exe and invoke the monodocer
Main() function directly from mdoc.  Alas, this means that everything is
transferred between mdoc and the subcommands via a string[], but this
allows simpler maintenance and code re-use.

> But otherwise I think it's a good idea.
> 
> >   - `mdoc update' has *far* fewer options than monodocer, mostly because
> >     I can't see the need for some monodocer options such as 
> >     -ignore_extra_docs (it should die now), -pretty (when don't you want
> >     nicely formatted XML?), -name, -since, etc.
> 
> I think I added -pretty because reformatting XML causes problems with 
> version control.

I found that without -pretty, all "unnecessary" whitespace was removed,
which resulted in *huge* diffs after minor updates (lack of newlines,
etc.).  Also (monodocer bug?), the initial monodocer output was usually
pretty-printed, even if -pretty wasn't provided, which resulted in
further executions *removing* the whitespace (thus contributing to the
diff problem).

What I have observed is that monodocer occasionally goes schizo and
removes whitespace from e.g. <list/> elements.  I have no idea why, nor
have I fixed this yet.

>  And I don't even recall what -name does.

Allows you to provide the project name. :-)

Also missing is -type, -namespace, -updateto....

And -overrides is enabled by default under `mdoc update`.

 - Jon



From mario.sopena at gmail.com  Fri Feb 22 07:16:44 2008
From: mario.sopena at gmail.com (Mario Sopena Novales)
Date: Fri, 22 Feb 2008 13:16:44 +0100
Subject: [Mono-docs-list] [PATCH] Fixing namespace edit (#319116)
Message-ID: <ef36f55f0802220416y611badb6w23c1c3c07ee8d160@mail.gmail.com>

Hi,

    the attached path fices the problem with namespaces that cannot be
edited right now as states bug #319116.

Unfortunately, you must rebuild the docs to see it working, because
the editing infrastructure put some information on zip files for
editing which is not present for namespaces unless you rebuild the doc
with the patch.

May I commit it?

Reggards,  MarioS

From jonpryor at vt.edu  Fri Feb 22 09:20:35 2008
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Fri, 22 Feb 2008 09:20:35 -0500
Subject: [Mono-docs-list] [PATCH] Fixing namespace edit (#319116)
In-Reply-To: <ef36f55f0802220416y611badb6w23c1c3c07ee8d160@mail.gmail.com>
References: <ef36f55f0802220416y611badb6w23c1c3c07ee8d160@mail.gmail.com>
Message-ID: <1203690035.20719.205.camel@lina.magi.jprl.com>

On Fri, 2008-02-22 at 13:16 +0100, Mario Sopena Novales wrote:
> Hi,
> 
>     the attached path fices the problem with namespaces that cannot be
> edited right now as states bug #319116.
> 
> Unfortunately, you must rebuild the docs to see it working, because
> the editing infrastructure put some information on zip files for
> editing which is not present for namespaces unless you rebuild the doc
> with the patch.
> 
> May I commit it?

Insert missing patch here.  :-)

 - Jon



From mario.sopena at gmail.com  Fri Feb 22 12:08:38 2008
From: mario.sopena at gmail.com (Mario Sopena Novales)
Date: Fri, 22 Feb 2008 18:08:38 +0100
Subject: [Mono-docs-list] [PATCH] Fixing namespace edit (#319116)
In-Reply-To: <1203690035.20719.205.camel@lina.magi.jprl.com>
References: <ef36f55f0802220416y611badb6w23c1c3c07ee8d160@mail.gmail.com>
	<1203690035.20719.205.camel@lina.magi.jprl.com>
Message-ID: <ef36f55f0802220908l2cf8eb2eia8346abf0324df85@mail.gmail.com>

Ups,

  ;-P

On 22/02/2008, Jonathan Pryor <jonpryor at vt.edu> wrote:
> On Fri, 2008-02-22 at 13:16 +0100, Mario Sopena Novales wrote:
>  > Hi,
>  >
>  >     the attached path fices the problem with namespaces that cannot be
>  > edited right now as states bug #319116.
>  >
>  > Unfortunately, you must rebuild the docs to see it working, because
>  > the editing infrastructure put some information on zip files for
>  > editing which is not present for namespaces unless you rebuild the doc
>  > with the patch.
>  >
>  > May I commit it?
>
>
> Insert missing patch here.  :-)
>
>   - Jon
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns.diff
Type: text/x-patch
Size: 4969 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-docs-list/attachments/20080222/0b84da86/attachment.bin 

From jonpryor at vt.edu  Fri Feb 22 13:10:43 2008
From: jonpryor at vt.edu (Jonathan Pryor)
Date: Fri, 22 Feb 2008 13:10:43 -0500
Subject: [Mono-docs-list] [PATCH] Fixing namespace edit (#319116)
In-Reply-To: <ef36f55f0802220908l2cf8eb2eia8346abf0324df85@mail.gmail.com>
References: <ef36f55f0802220416y611badb6w23c1c3c07ee8d160@mail.gmail.com>
	<1203690035.20719.205.camel@lina.magi.jprl.com>
	<ef36f55f0802220908l2cf8eb2eia8346abf0324df85@mail.gmail.com>
Message-ID: <1203703843.20719.220.camel@lina.magi.jprl.com>

On Fri, 2008-02-22 at 18:08 +0100, Mario Sopena Novales wrote:
> Index: provider.cs
> ===================================================================
> --- provider.cs (revisi?n: 96411)
> +++ provider.cs (copia de trabajo)
> @@ -609,9 +609,13 @@
>                 }       
>         }
>         
> -       public void PackXml (string fname, XmlDocument doc)
> +       public void PackXml (string fname, XmlDocument doc, string real_path)
>         {
> -               zip_output.PutNextEntry (new ZipEntry (fname));
> +        ZipEntry entry = new ZipEntry (fname);
> +        if (real_path != null)
> +            entry.ExtraData = ConvertToArray(real_path);
> +
> +               zip_output.PutNextEntry (entry);

Please fix your indenting.

> Index: mono-ecma-css.xsl
> ===================================================================
> --- mono-ecma-css.xsl   (revisi?n: 96411)
> +++ mono-ecma-css.xsl   (copia de trabajo)
> @@ -684,7 +684,7 @@
>                                 <xsl:apply-templates select="summary" mode="notoppara"/>
>                                 <xsl:if test="monodoc:MonoEditing()">
>                                         <xsl:value-of select="' '" />
> -                                       <a href="{monodoc:EditUrlNamespace ($namespace, 'summary')}">[Edit]</a>
> +                                       [<a href="{monodoc:EditUrlNamespace (., $namespace, 'summary')}">Edit</a>]

Any particular reason you don't want the '[' and ']' as part of the link
text?  I'd prefer to keep them as part of the link.

> Index: ecma-provider.cs
> ===================================================================
> --- ecma-provider.cs    (revisi?n: 96411)
> +++ ecma-provider.cs    (copia de trabajo)
> @@ -184,6 +184,7 @@
>                                         if (File.Exists (ns_summary_file)) {
>                                                 XmlDocument nsSummaryFile = new XmlDocument ();
>                                                 nsSummaryFile.Load (ns_summary_file);
> +                        namespace_realpath [tn] = ns_summary_file;

Fix indentation.
                                                
> @@ -869,16 +871,16 @@
>  
>                         match_node = ns_node;
>                         string ns_name = nsurl.Substring (2);
> -                       
> -                       XmlReader summary = GetNamespaceDocument (ns_name);
> -                       if (summary == null)
> +            
> +            XmlDocument doc = GetHelpXmlWithChanges("xml.summary." + ns_name);
> +            if (doc == null)
>                                 return null;

Shouldn't this fall-back to using GetNamspaceDocument() if
GetHelpXmlWithChanges() fails?
 
> @@ -1181,10 +1183,12 @@
>                         return "";
>                 }
>  
> -               public string EditUrlNamespace (string ns, string section)
> +               public string EditUrlNamespace (XPathNodeIterator itr, string ns, string section)
>                 {
>                         if (hs is EcmaUncompiledHelpSource)
>                                 return "edit:file:" + Path.Combine(((EcmaUncompiledHelpSource)hs).BasePath, ns + ".xml") + "@/Namespace/Docs/" + section; 
> +            else if (itr.MoveNext ())
> +                return EditingUtils.FormatEditUri(itr.Current.BaseURI, "/elements/" + section);

Indentation.

Thanks,
 - Jon



From mario.sopena at gmail.com  Fri Feb 22 13:49:41 2008
From: mario.sopena at gmail.com (Mario Sopena Novales)
Date: Fri, 22 Feb 2008 19:49:41 +0100
Subject: [Mono-docs-list] [PATCH] Fixing namespace edit (#319116)
In-Reply-To: <1203703843.20719.220.camel@lina.magi.jprl.com>
References: <ef36f55f0802220416y611badb6w23c1c3c07ee8d160@mail.gmail.com>
	<1203690035.20719.205.camel@lina.magi.jprl.com>
	<ef36f55f0802220908l2cf8eb2eia8346abf0324df85@mail.gmail.com>
	<1203703843.20719.220.camel@lina.magi.jprl.com>
Message-ID: <ef36f55f0802221049u7de62d7g6bb895666cc021c2@mail.gmail.com>

Hi,

   I fixed all the indentation mess. More comments below:

On 22/02/2008, Jonathan Pryor <jonpryor at vt.edu> wrote:
> On Fri, 2008-02-22 at 18:08 +0100, Mario Sopena Novales wrote:
>  > Index: provider.cs
>  > ===================================================================
>  > --- provider.cs (revisi?n: 96411)
>  > +++ provider.cs (copia de trabajo)
>  > @@ -609,9 +609,13 @@
>  >                 }
>  >         }
>  >
>  > -       public void PackXml (string fname, XmlDocument doc)
>  > +       public void PackXml (string fname, XmlDocument doc, string real_path)
>  >         {
>  > -               zip_output.PutNextEntry (new ZipEntry (fname));
>  > +        ZipEntry entry = new ZipEntry (fname);
>  > +        if (real_path != null)
>  > +            entry.ExtraData = ConvertToArray(real_path);
>  > +
>  > +               zip_output.PutNextEntry (entry);
>
>  Please fix your indenting.
>
>  > Index: mono-ecma-css.xsl
>  > ===================================================================
>  > --- mono-ecma-css.xsl   (revisi?n: 96411)
>  > +++ mono-ecma-css.xsl   (copia de trabajo)
>  > @@ -684,7 +684,7 @@
>  >                                 <xsl:apply-templates select="summary" mode="notoppara"/>
>  >                                 <xsl:if test="monodoc:MonoEditing()">
>  >                                         <xsl:value-of select="' '" />
>  > -                                       <a href="{monodoc:EditUrlNamespace ($namespace, 'summary')}">[Edit]</a>
>  > +                                       [<a href="{monodoc:EditUrlNamespace (., $namespace, 'summary')}">Edit</a>]
>
>  Any particular reason you don't want the '[' and ']' as part of the link
>  text?  I'd prefer to keep them as part of the link.

Because the other Edit links are like this, so I though it would be
better to keep all unified.


>
>  > Index: ecma-provider.cs
>  > ===================================================================
>  > --- ecma-provider.cs    (revisi?n: 96411)
>  > +++ ecma-provider.cs    (copia de trabajo)
>  > @@ -184,6 +184,7 @@
>  >                                         if (File.Exists (ns_summary_file)) {
>  >                                                 XmlDocument nsSummaryFile = new XmlDocument ();
>  >                                                 nsSummaryFile.Load (ns_summary_file);
>  > +                        namespace_realpath [tn] = ns_summary_file;
>
>  Fix indentation.
>
>  > @@ -869,16 +871,16 @@
>  >
>  >                         match_node = ns_node;
>  >                         string ns_name = nsurl.Substring (2);
>  > -
>  > -                       XmlReader summary = GetNamespaceDocument (ns_name);
>  > -                       if (summary == null)
>  > +
>  > +            XmlDocument doc = GetHelpXmlWithChanges("xml.summary." + ns_name);
>  > +            if (doc == null)
>  >                                 return null;
>
>  Shouldn't this fall-back to using GetNamspaceDocument() if
>  GetHelpXmlWithChanges() fails?

Well, the reason is that GetNamespaceDocument calls GetHelpXml() which
is a function copy&pasted to GetHelpXmlWithChanges except for the
later calling one extra method to detect whether there are changes and
applying them. In fact, I think we should remove
GetNamespaceDocument... well, I think the monodoc "library" need a
heavy refactoring because it is a little mess, I just don't find
enough free time to do it, ;-P


>
>  > @@ -1181,10 +1183,12 @@
>  >                         return "";
>  >                 }
>  >
>  > -               public string EditUrlNamespace (string ns, string section)
>  > +               public string EditUrlNamespace (XPathNodeIterator itr, string ns, string section)
>  >                 {
>  >                         if (hs is EcmaUncompiledHelpSource)
>  >                                 return "edit:file:" + Path.Combine(((EcmaUncompiledHelpSource)hs).BasePath, ns + ".xml") + "@/Namespace/Docs/" + section;
>  > +            else if (itr.MoveNext ())
>  > +                return EditingUtils.FormatEditUri(itr.Current.BaseURI, "/elements/" + section);
>
>  Indentation.
>
>  Thanks,
>   - Jon



Thanks,  Mario
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ns.diff
Type: text/x-patch
Size: 4882 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-docs-list/attachments/20080222/e99252a8/attachment-0001.bin 

From valentin.sawadski at googlemail.com  Sat Feb 23 12:06:10 2008
From: valentin.sawadski at googlemail.com (Valentin Sawadski)
Date: Sat, 23 Feb 2008 18:06:10 +0100
Subject: [Mono-docs-list] How to update documentation
In-Reply-To: <256d62360802130740x2c2da90fr37cc5a5e4d032374@mail.gmail.com>
References: <256d62360802130740x2c2da90fr37cc5a5e4d032374@mail.gmail.com>
Message-ID: <1203786370.23844.2.camel@pi1536.site>

Hi,

could you please clarify what part of the page is outdated, because
there's a lot of code on this site, with whom I'm not familiar with. I
will then upload the changes then for you.

Kind Regards,
Valentin Sawadski

On Wed, 2008-02-13 at 16:40 +0100, Suco wrote:
> I was looking for info of how to show an icon in the system tray, and
> I found this page:
> 
> http://www.mono-project.com/GtkSharpNotificationIcon
> 
> But the info is outdated and now exists other more efficient way to do that:
> 
> StatusIcon trayIcon = new StatusIcon(Gdk.Pixbuf.LoadFromResource("icon.png"));
> trayIcon.Visible = true;
> trayIcon.Activate += OnTrayIconClicked;
> trayIcon.PopupMenu += OnTrayIconPopup;
> trayIcon.Tooltip = Catalog.GetString("example icon");
> 
> How can I update the page? or Can a maintainer update the info?
> _______________________________________________
> Mono-docs-list maillist  -  Mono-docs-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-docs-list


From valentin.sawadski at googlemail.com  Sat Feb 23 13:09:19 2008
From: valentin.sawadski at googlemail.com (Valentin Sawadski)
Date: Sat, 23 Feb 2008 19:09:19 +0100
Subject: [Mono-docs-list] How to update documentation
In-Reply-To: <256d62360802230912q68705eaele3ea6f9da2ac3271@mail.gmail.com>
References: <256d62360802130740x2c2da90fr37cc5a5e4d032374@mail.gmail.com>
	<1203786370.23844.2.camel@pi1536.site>
	<256d62360802230912q68705eaele3ea6f9da2ac3271@mail.gmail.com>
Message-ID: <1203790159.23844.4.camel@pi1536.site>

Hi,

thanks for the code sample. The Wiki has now been updated and I also
mentioned you as the contributor of the code.

Kind Regards,
Valentin Sawadski

On Sat, 2008-02-23 at 18:12 +0100, Suco wrote:
> Hello,
>   The sample code in the page is outdate, one actual sample that work is this:
> http://blog.wikifotos.org/2008/02/14/mono-c-y-los-iconos-en-la-bandeja-del-sistema/
> 
> On Sat, Feb 23, 2008 at 6:06 PM, Valentin Sawadski
> <valentin.sawadski at googlemail.com> wrote:
> > Hi,
> >
> >  could you please clarify what part of the page is outdated, because
> >  there's a lot of code on this site, with whom I'm not familiar with. I
> >  will then upload the changes then for you.
> >
> >  Kind Regards,
> >  Valentin Sawadski
> >
> >
> >
> >  On Wed, 2008-02-13 at 16:40 +0100, Suco wrote:
> >  > I was looking for info of how to show an icon in the system tray, and
> >  > I found this page:
> >  >
> >  > http://www.mono-project.com/GtkSharpNotificationIcon
> >  >
> >  > But the info is outdated and now exists other more efficient way to do that:
> >  >
> >  > StatusIcon trayIcon = new StatusIcon(Gdk.Pixbuf.LoadFromResource("icon.png"));
> >  > trayIcon.Visible = true;
> >  > trayIcon.Activate += OnTrayIconClicked;
> >  > trayIcon.PopupMenu += OnTrayIconPopup;
> >  > trayIcon.Tooltip = Catalog.GetString("example icon");
> >  >
> >  > How can I update the page? or Can a maintainer update the info?
> >  > _______________________________________________
> >  > Mono-docs-list maillist  -  Mono-docs-list at lists.ximian.com
> >  > http://lists.ximian.com/mailman/listinfo/mono-docs-list
> >
> >


From jit at occams.info  Mon Feb 25 16:21:32 2008
From: jit at occams.info (Joshua Tauberer)
Date: Mon, 25 Feb 2008 16:21:32 -0500
Subject: [Mono-docs-list] mdoc: Introduction and RFC
In-Reply-To: <1203596665.20719.177.camel@lina.magi.jprl.com>
References: <1203559631.20719.150.camel@lina.magi.jprl.com>	<47BD6753.70302@occams.info>
	<1203596665.20719.177.camel@lina.magi.jprl.com>
Message-ID: <47C3315C.1080309@occams.info>

Jonathan Pryor wrote:
> On Thu, 2008-02-21 at 06:58 -0500, Joshua Tauberer wrote:
>> Why not just merge all of the tools into a mdoc.exe (with the new 
>> options parsing library to boot), rather than wrapping them all with a 
>> script?
> 
> Because that would imply removing the older tools, which would break any
> number of existing projects; I know that removing monodocer and
> monodocs2html would break Mono.Fuse and NDesk.Options

Oh those don't count! :) If you're going to update something, you can 
update your other projects at the same time.

Seriously, I think when major cruft-removal is in order, and a 2.0 Mono 
release is approaching, it's fair to break things like documentation 
generation.

> Furthermore, mdoc isn't a shell script, it is a C# .exe. 

Ahha! That's neat.

But it's all good. I'm always happy to see your improvements.

-- 
- Josh Tauberer

http://razor.occams.info

"Yields falsehood when preceded by its quotation!  Yields
falsehood when preceded by its quotation!" Achilles to
Tortoise (in "Godel, Escher, Bach" by Douglas Hofstadter)


  As such, I can
> do such wonderful things as -r:monodocer.exe and invoke the monodocer
> Main() function directly from mdoc.  Alas, this means that everything is
> transferred between mdoc and the subcommands via a string[], but this
> allows simpler maintenance and code re-use.
> 
>> But otherwise I think it's a good idea.
>>
>>>   - `mdoc update' has *far* fewer options than monodocer, mostly because
>>>     I can't see the need for some monodocer options such as 
>>>     -ignore_extra_docs (it should die now), -pretty (when don't you want
>>>     nicely formatted XML?), -name, -since, etc.
>> I think I added -pretty because reformatting XML causes problems with 
>> version control.
> 
> I found that without -pretty, all "unnecessary" whitespace was removed,
> which resulted in *huge* diffs after minor updates (lack of newlines,
> etc.).  Also (monodocer bug?), the initial monodocer output was usually
> pretty-printed, even if -pretty wasn't provided, which resulted in
> further executions *removing* the whitespace (thus contributing to the
> diff problem).
> 
> What I have observed is that monodocer occasionally goes schizo and
> removes whitespace from e.g. <list/> elements.  I have no idea why, nor
> have I fixed this yet.
> 
>>  And I don't even recall what -name does.
> 
> Allows you to provide the project name. :-)
> 
> Also missing is -type, -namespace, -updateto....
> 
> And -overrides is enabled by default under `mdoc update`.
> 
>  - Jon
> 
>