scrollkeeper-devel — Developer discussion list for ScrollKeeper

Re: [Scrollkeeper-devel] Re: ScrollKeeper 0.3.10 Released

[Sander V. <San...@Su...>]

On Fri, 21 Jun 2002, Jeff Waugh wrote:

> <quote who="Dan Mueth">
> 
> > ScrollKeeper 0.3.10 is now available.
> 
> Should this ship with GNOME 2.0.0?
> 

AFAIK, very probably yes.

> - Jeff
> 
> -- 
>   "Ever since GNOME development began, I have urged people to aim to make   
>    it as good as the Macintosh.  To try to be like Windows is to try for    
>                       second-best." - Richard Stallman                      
> 

	Sander

	you'll rescue me right?
	in the exact same way that they never did
	i'll be happy right?
	when your healing powers kick in

[Scrollkeeper-devel] Re: ScrollKeeper 0.3.10 Released

[Jeff W. <jd...@pe...>]

<quote who="Dan Mueth">

> ScrollKeeper 0.3.10 is now available.

Should this ship with GNOME 2.0.0?

- Jeff

-- 
  "Ever since GNOME development began, I have urged people to aim to make   
   it as good as the Macintosh.  To try to be like Windows is to try for    
                      second-best." - Richard Stallman                      

[Scrollkeeper-devel] ScrollKeeper 0.3.10 Released

[Dan M. <mu...@al...>]

ScrollKeeper 0.3.10 is now available.

New in this release:
   * Support for DocBook's <part> element.
   * Several updated translations and one new translation.
   * A couple BSD-specific fixes.
   * A couple other small bug fixes.

Thanks to everybody who has been testing, writing bug reports, and
submitting patches.

You can get ScrollKeeper 0.3.10 at:
	http://sourceforge.net/projects/scrollkeeper

If you find any bugs, please submit them to the bug tracker at:
	http://sourceforge.net/tracker/?group_id=11543&atid=111543
Please be sure to include your name and email address in any bugs you
enter so we can contact you if necessary.

If you would like to contribute to ScrollKeeper:
There are instructions for getting the latest source from CVS at:
	http://scrollkeeper.sourceforge.net/cvs.shtml
Look over the TODO list in the tarball or CVS and the bug list on the web, 
find something you're interested in working on, and email
scr...@li... with your choice so that others 
don't duplicate your work.

- The ScrollKeeper Team

Re: [Scrollkeeper-devel] uk locale in templates/Makefile.am

[Dan M. <mu...@al...>]

Joe,

Thanks for pointing that out.

-Dan


On 16 Jun 2002, Joe Marcus Clarke wrote:

> There seems to be a superfluous ',' after the uk locale in the templates
> Makefile.am.  Is this correct?
> 
> Joe

Re: [Scrollkeeper-devel] [PATCH] bus error in scrollkeeper-tree-separate

[Dan M. <mu...@al...>]

Joe,

Thanks for the patch.  I think it is better to continue as you did instead 
of moving to the next node, so I committed the patch as is.

-Dan


On 17 Jun 2002, Joe Marcus Clarke wrote:

> In FreeBSD 5.0-CURRENT, I get a bus error trying to separate the XML
> tree during the build.  The problem looks to be like a XML node is
> freed, then its name element is referenced.  The attached patch fixes
> the problem, but I'm not exactly sure this is the best way to fix it. 
> One might also want to set node = next, then continue in the current
> iteration of the for loop. 
> 
> I'm not sure why this doesn't bite FreeBSD -stable, but it looks like
> this patch corrects the build on -CURRENT while leaving things
> functional.
> 
> 

[Scrollkeeper-devel] [PATCH] bus error in scrollkeeper-tree-separate

[Joe M. C. <ma...@Fr...>]

In FreeBSD 5.0-CURRENT, I get a bus error trying to separate the XML
tree during the build.  The problem looks to be like a XML node is
freed, then its name element is referenced.  The attached patch fixes
the problem, but I'm not exactly sure this is the best way to fix it. 
One might also want to set node = next, then continue in the current
iteration of the for loop. 

I'm not sure why this doesn't bite FreeBSD -stable, but it looks like
this patch corrects the build on -CURRENT while leaving things
functional.

[Scrollkeeper-devel] uk locale in templates/Makefile.am

[Joe M. C. <ma...@Fr...>]

There seems to be a superfluous ',' after the uk locale in the templates
Makefile.am.  Is this correct?

Joe

[Scrollkeeper-devel] a patch for toc.xsl

[Sander V. <San...@Su...>]

So, this patch for extract/stylesheets/toc.xsl does two things:

	* adds support for <part> so that structure of documents
	  marked up as a book consisting of parts is preserved

	* adds support for the wrapped chapters of the user guide so
	  they get correct TOC-s 

the second use (and the need for it) will hopefully go away soon after
gnome 2.0.0 when a better solution is found.

	Sander

	you'll rescue me right?
	in the exact same way that they never did
	i'll be happy right?
	when your healing powers kick in

Re: [Scrollkeeper-devel] Scrollkeeper is extremely slow on gnome2-user-docs

[Sander V. <San...@Su...>]

On Tue, 11 Jun 2002, Dan Mueth wrote:

> 
> On 11 Jun 2002, Frederic Crozat wrote:
> 
> > Hi,
> > 
> > I'm wondering on the scrollkeeper performance when it is indexing
> > gnome2-user-docs files..
> > 
> > On my PIII/750Mhz, it takes more than 10 minutes to complete..
> > 
> > This is definitely a stopper for Mandrake cooker installation (this
> > locks our install process until scrollkeeper is done).
> > 
> > It is ok or is there something wrong in our packages ?
> > 
> > (PS : using scrollkeeper 0.3.9 with docbook-xml-stylesheets 4.1.2
> > correctly registered in XML catalog..)
> 
> I just took a glance at the gnome2-user-docs to see why it might be slow.  
> It looks like it has an OMF file for each of the ~12 chapters, each of
> which point to the main document.  So, when it is installed it indexes and
> extracts the TOC for the entire document (which is quite large) 12 times.
> 
> I suspect the intent was to have each chapter of the User Guide show up in
> the TOC individually.  I'm not sure if this can be done without actually 
> making each chapter its own document.  Pat - Could you comment, or direct 
> me to the right person, as to what the intent was here?

Actually, in HEAD, these no longer point at the main file. They way it is
presently (mis-)implemented is not the best, but I discovered the bug way
too late and had a need far *A* fix for the sun release. There isn't a
release that contains the fix for various reasons yet, though. 

It is a problem with the omf.make and its assumptions about document
layout - its pretty much tailored to a very specific case, which doesn't
match the 'multiple closely related documents' one.

> 
> When we have lots of translations of large documents, we may run into
> performance issues once again.  The easy solution is to ship translations
> of very large documents seperately.  There may also be ways to optimize
> the stylesheets.  
> 
> In a future release, I plan to allow the extracted information to be
> generated at build time and installed.  This way the user's system doesn't
> have to re-generate them unless they upgrade their ScrollKeeper version
> (to a version which has additional extracted data, relative to the version
> used to build the package).  Users who install from a distribution's CD
> would not see a significant change in installation time due to SK.
> 

This is already done in the sun release AFAIK - then again, distributors
who cannot assume that all of gnome will be installed in one go may have
slightly differnet constraints.

> Dan
> 

	Sander

	you'll rescue me right?
	in the exact same way that they never did
	i'll be happy right?
	when your healing powers kick in

Re: [Scrollkeeper-devel] Scrollkeeper is extremely slow on gnome2-user-docs

[Dan M. <mu...@al...>]

On 11 Jun 2002, Frederic Crozat wrote:

> Hi,
> 
> I'm wondering on the scrollkeeper performance when it is indexing
> gnome2-user-docs files..
> 
> On my PIII/750Mhz, it takes more than 10 minutes to complete..
> 
> This is definitely a stopper for Mandrake cooker installation (this
> locks our install process until scrollkeeper is done).
> 
> It is ok or is there something wrong in our packages ?
> 
> (PS : using scrollkeeper 0.3.9 with docbook-xml-stylesheets 4.1.2
> correctly registered in XML catalog..)

I just took a glance at the gnome2-user-docs to see why it might be slow.  
It looks like it has an OMF file for each of the ~12 chapters, each of
which point to the main document.  So, when it is installed it indexes and
extracts the TOC for the entire document (which is quite large) 12 times.

I suspect the intent was to have each chapter of the User Guide show up in
the TOC individually.  I'm not sure if this can be done without actually 
making each chapter its own document.  Pat - Could you comment, or direct 
me to the right person, as to what the intent was here?

For now it makes sense to remove the OMF files except for 
user-guide-C.omf.  That will at least speed things up a lot and allow you 
to make a sane package.

When we have lots of translations of large documents, we may run into
performance issues once again.  The easy solution is to ship translations
of very large documents seperately.  There may also be ways to optimize
the stylesheets.  

In a future release, I plan to allow the extracted information to be
generated at build time and installed.  This way the user's system doesn't
have to re-generate them unless they upgrade their ScrollKeeper version
(to a version which has additional extracted data, relative to the version
used to build the package).  Users who install from a distribution's CD
would not see a significant change in installation time due to SK.

Dan

Re: [Scrollkeeper-devel] Scrollkeeper is extremely slow on gnome2-user-docs

[Christian M. <mar...@fr...>]

>> "FC" == Frederic Crozat <fc...@ma...> writes:

> Hi,

Hi,

> I'm wondering on the scrollkeeper performance when it is indexing
> gnome2-user-docs files..

> On my PIII/750Mhz, it takes more than 10 minutes to complete..

Same problem with Debian.

Christian

[Scrollkeeper-devel] Scrollkeeper is extremely slow on gnome2-user-docs

[Frederic C. <fc...@ma...>]

Hi,

I'm wondering on the scrollkeeper performance when it is indexing
gnome2-user-docs files..

On my PIII/750Mhz, it takes more than 10 minutes to complete..

This is definitely a stopper for Mandrake cooker installation (this
locks our install process until scrollkeeper is done).

It is ok or is there something wrong in our packages ?

(PS : using scrollkeeper 0.3.9 with docbook-xml-stylesheets 4.1.2
correctly registered in XML catalog..)
--=20
Fr=E9d=E9ric Crozat
MandrakeSoft

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Dan M. <mu...@al...>]

On 2 Jun 2002, Joe Marcus Clarke wrote:

> Revision 1.16 / (view) - annotate - [select for diffs] , Sun Jun 2
> 04:25:51 2002 UTC (2 hours, 14 minutes ago) by muet
> Branch: MAIN
> CVS Tags: HEAD
> Changes since 1.15: +10 -1 lines
> Diff to previous 1.15
> 
> 2002-06-01 Dan Mueth <mu...@al...>
> 
>         Having scrollkeeper-preinstall just copy the OMF file if it
>         can't update the URL.  This way at least packages will be built
>         on systems like BSD, even though some OMF files may not
> register.
> 
>         * cl/src/preinstall.c:
> 
>         * configure.in: Bumping version to 0.3.10beta1
> 
> Thanks, Dan.  I'll give this a shot, and let you know how things go.


No problem.  If it fixes the BSD package build problem, tell me and I can
put out 0.3.10 right away so you have a real release to work with.

Dan

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Joe M. C. <ma...@Fr...>]

Revision 1.16 / (view) - annotate - [select for diffs] , Sun Jun 2
04:25:51 2002 UTC (2 hours, 14 minutes ago) by muet
Branch: MAIN
CVS Tags: HEAD
Changes since 1.15: +10 -1 lines
Diff to previous 1.15

2002-06-01 Dan Mueth <mu...@al...>

        Having scrollkeeper-preinstall just copy the OMF file if it
        can't update the URL.  This way at least packages will be built
        on systems like BSD, even though some OMF files may not
register.

        * cl/src/preinstall.c:

        * configure.in: Bumping version to 0.3.10beta1

Thanks, Dan.  I'll give this a shot, and let you know how things go.

Joe

[Scrollkeeper-devel] Re: OMF DTD problems

[Dan M. <mu...@al...>]

On 29 May 2002, John Fleck wrote:

> Folks -
> I'm not sure of the reason for this, but we've run into a problem when
> adding the dtd to omf files.
> scrollkeeper-preinstall was failing, making packages unbuildable when
> the dtd was added to the omf file.
> I've removed it from workspace-switcher-C.omf, which was causing
> gnome-panel's build to fail. I'm not sure where else this may show up,
> which is why I'm sending this note to the lists.
> I don't know whether it's a catalog problem, or a problem getting the
> dtd from the net, but whatever it is it was breaking the build so I
> think reverting it and leaving dtd's out until we've sorted out the
> problem is the correct approach.
> Cheers,
> John

There was a bug in ScrollKeeper < 0.3.9 in how it addresses the root XML
node which doesn't show up unless you have the DOCTYPE declaration in 
the OMF file.  ScrollKeeper 0.3.9, which was just released, includes the 
fix.

Dan

[Scrollkeeper-devel] ScrollKeeper 0.3.9 Released

[Dan M. <mu...@al...>]

ScrollKeeper 0.3.9 is now available.  As with other releases in the 0.3.x
series, this is a development release.  We are getting very close to 0.4.0, so
if you find any problems, please submit bug reports and/or patches.

New in this release:
   * Improvements to documentation and example OMF files, including 
     correction of typos and validation errors, addition of encoding 
     declaration, and addition of DTD declaration.
   * Updated Catalan translation.
   * Updated INSTALL information.
   * Added fix to allow comments in OMF files.
   * Suppressed warnings about OMF directories which are listed in
     configuration file but which don't exist, except in verbose mode.
   * Several platform-specific fixes (SPARC, Solaris)
   * Fix to scrollkeeper-preinstall for OMF files with doctype declaration
   * Fixed bug relating to library linking.
   * Other minor bug fixes.

You can get ScrollKeeper 0.3.9 at:
	http://sourceforge.net/projects/scrollkeeper

If you find any bugs, please submit them to the bug tracker at:
	http://sourceforge.net/tracker/?group_id=11543&atid=111543
Please be sure to include your name and email address in any bugs you
enter so we can contact you if necessary.

If you would like to contribute to ScrollKeeper:
There are instructions for getting the latest source from CVS at:
	http://scrollkeeper.sourceforge.net/cvs.shtml
Look over the TODO list in the tarball or CVS and the bug list on the web, 
find something you're interested in working on, and email
scr...@li... with your choice so that others 
don't duplicate your work.

- The ScrollKeeper Team

[Scrollkeeper-devel] Re: OMF DTD problems

[Chris L. <ch...@wi...>]

On Wed, 2002-05-29 at 06:01, John Fleck wrote:
> Folks -
> I'm not sure of the reason for this, but we've run into a problem when
> adding the dtd to omf files.
> scrollkeeper-preinstall was failing, making packages unbuildable when
> the dtd was added to the omf file.
> I've removed it from workspace-switcher-C.omf, which was causing
> gnome-panel's build to fail. I'm not sure where else this may show up,
> which is why I'm sending this note to the lists.
> I don't know whether it's a catalog problem, or a problem getting the
> dtd from the net, but whatever it is it was breaking the build so I
> think reverting it and leaving dtd's out until we've sorted out the
> problem is the correct approach.

I've also noticed that new documents are not being added by the build to
my scrollkeeper db. If I run scrollkeeper-rebuilddb it registers them
fine.

Chris
-- 
RedHat Certified Engineer #807302549405490.
--------------------------------------------
	|^|
	| |   |^|
	| |^| | |  Life out here is raw 
	| | |^| |  But we will never stop
	| |_|_| |  We will never quit 
	| / __> |  cause we are Metallica
	|/ /    |
	\       /
	 |     |
--------------------------------------------

[Scrollkeeper-devel] OMF DTD problems

[John F. <jf...@in...>]

Folks -
I'm not sure of the reason for this, but we've run into a problem when
adding the dtd to omf files.
scrollkeeper-preinstall was failing, making packages unbuildable when
the dtd was added to the omf file.
I've removed it from workspace-switcher-C.omf, which was causing
gnome-panel's build to fail. I'm not sure where else this may show up,
which is why I'm sending this note to the lists.
I don't know whether it's a catalog problem, or a problem getting the
dtd from the net, but whatever it is it was breaking the build so I
think reverting it and leaving dtd's out until we've sorted out the
problem is the correct approach.
Cheers,
John
-- 
John Fleck
jf...@in... (h) jf...@ab... (w)
http://www.inkstain.net http://www.abqjournal.com

"You don't want to die with the music still in you."
 - John Gardner

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Joe M. C. <ma...@ma...>]

On Mon, 2002-05-27 at 16:23, Dan Mueth wrote:
> 
> On Mon, 27 May 2002, Joe Clarke wrote:
> 
> > I don't think I was clear.  The build of gnome-core _succeeds_, however,
> > the OMF files for certain components are not installed.  This breaks
> > FreeBSD's packaging system since the plist refers to files that do not
> > exist.  The Makefiles look pretty solid to me.
> 
> Ah, ok.  I'm not familiar with the plist system.  I'm glad that at least 
> the build and regular install work correctly.  I hope the plist system can 
> be massaged into ignoring these missing files.
> 
> If we have to, we could hack scrollkeeper-preinstall to have a different
> failure mode where the OMF file is written.  The easy ways to do this
> though would produce an invalid OMF file, without the encoding declaration
> (eg. just copy the OMF file as is).  It would at least allow the package
> build to proceed, although SK would not be able to register these
> documents when they are installed. (It would silently fail to register
> them, writing a message to the log file at install time.)  Tell me what
> you think, as this would be easy to do and may be helpful for other
> packaging systems.

Yes, please!  This would make it so FreeBSD could use SK 0.3.x|0.4.x
globally.  Yelp will be pleased ;-).

Joe

> 
> > > If we want complete support for older OMF files, we would need to be able
> > > to automatically convert old OMF files to conform to the DTD.  It looks
> > > like John has made a lot of progress in this.  We would need to try to
> > > guess the encoding, which we can probably get right some but not all the
> > > time.  For this to be useful, we would have to add support for SGML docs
> > > back to ScrollKeeper.  The original SGML support used openjade which a lot
> > > of distributors and people complained about as being crufty and uncommon.
> > > We would need to use the SGML support DV put into libxml2, which should be
> > > much better but still has some issues I think.
> > >
> > > The question is, do we want SK-0.4.0 to fail gracefully for old OMF files
> > > or do we want to try to get complete backwards compatibility with full
> > > functionality?
> > 
> > I'd like to see full backwards compat.  However, the more I look into
> > things, I _think_ I can create both scrollkeeper (0.2) and scrollkeeper2
> > (0.3.x|0.4.x) ports which will be built depending on the version of GNOME
> > desired.  It looks like GNOME 1.4.x libraries (i.e. gnome-libs, oaf,
> > bonobo, etc.) don't really use scrollkeeper as much as the desktop
> > components (i.e. gnome-core, gnome-applets, gnome-utils, etc.) do.  If
> > that's the case, then I should be okay.  Thoughts....
> 
> In GNOME 1.4.x, only Nautilus accesses the ScrollKeeper database info.  
> All of the packages with end-user documentation (ie. the desktop 
> components) install docs with OMF files, while none of the platform 
> packages (ie. libraries) do.
> 
> > I really appreciate this dialog.  It's helping a lot with the porting
> > process.
> 
> :)
> 
> It is good to review these things periodically, since most people who need 
> to know these things don't always watch this mailing list.
> 
> Dan
> 
> 
-- 
PGP Key : http://www.marcuscom.com/pgp.asc

[Scrollkeeper-devel] Updates to "Writing ScrollKeeper OMF Files"

[Dan M. <mu...@al...>]

I just uploaded a new version of "Writing ScrollKeeper OMF Files" to:

http://scrollkeeper.sourceforge.net/documentation/writing_scrollkeeper_omf_files/index.html

The changes are minor, but there are three things which I want to point 
out:

1) Explicitly state the encoding on the top line of the OMF file.  It
isn't necessary for UTF-8 or ASCII docs, but it is a good habit to start.  

eg: <?xml version="1.0" encoding="UTF-8"?>

2) Include a DOCTYPE declaration as shown in the example.  Thanks to
libxml2's support of XML catalogs, the local version of the DTD can be
found without going onto the net.  I did upload a copy to its new official
location on the net though, in case somebody blows away their XML catalog.

eg: <!DOCTYPE omf PUBLIC "-//OMF//DTD Scrollkeeper OMF Variant V1.0//EN" 
"http://scrollkeeper.sourceforge.net/dtds/scrollkeeper-omf-1.0/scrollkeeper-omf.dtd">

Note that ScrollKeeper currently keeps track of the location of the DTD on
the system explicitly, so things will still work if this declaration is 
missing. However, an XML file is not technically valid if it doesn't
explicitly specify its DTD.  In the future, we are likely to maintain 
compatibility with multiple DTD versions and convert OMF files between 
them with stylesheets, so it will be convenient to know which DTD version 
each OMF file was written to.

3) To validate an OMF file which declares its DTD:
	xmllint --noout --valid foo-C.omf
The correct version of the DTD will be found locally, if ScrollKeeper is 
installed, or else on the net if SK isn't installed.

Dan

Re: [Scrollkeeper-devel] strange DTD changes

[John F. <jf...@in...>]

On Mon, 2002-05-27 at 00:05, Dan Mueth wrote:
> 
> Could anybody comment on the viability of writing a stylesheet to convert 
> OMF files from one DTD version to another?  It seems completely doable, 
> and I think John has already done this for migrating OMF files from SK-0.2 
> to SK-0.3.x/0.4, although I'm not sure what the final verdict is on how 
> well it works.  Comments John?
> 

It's relatively straightforward if all of the information is captured in
the source DTD. My stylesheet worked fine, but since there was no DTD
before, some of the source files lacked information required by the DTD,
so manual intervention was required.

Cheers,
John
-- 
John Fleck
jf...@in... (h) jf...@ab... (w)
http://www.inkstain.net http://www.abqjournal.com

"You don't want to die with the music still in you."
 - John Gardner

Re: [Scrollkeeper-devel] install() function don't skip comment nodes while looking for <OMF>

[Dan M. <mu...@al...>]

Thanks.  Committed to CVS.

Dan

On Thu, 23 May 2002, Christian Marillat wrote:

> Hi,
> 
> Another patche from a Debian user
> 
> Christian
> 
> From: "J.H.M. Dassen (Ray)" <dm...@ze...>
> Subject: Bug#146848: Patch
> To: 14...@bu...
> Date: Wed, 22 May 2002 22:26:24 +0200
> User-Agent: Mutt/1.3.28i
> Reply-To: "J.H.M. Dassen (Ray)" <dm...@ze...>, 14...@bu...
> Resent-From: "J.H.M. Dassen (Ray)" <dm...@ze...>
> 
> This makes the install() function skip comment nodes while looking for <OMF>
> elements.
> 
> It may well be that there are other places where (lib)scrollkeeper's code
> needs refinement to deal with comment nodes the right way. Also, the
> install() function really should be rewritten to not have code paths along
> which it fails without providing a clue for debugging.
> 
> diff -r -u scrollkeeper-0.3.8/libs/install.c scrollkeeper-devel/libs/install.c
> --- scrollkeeper-0.3.8/libs/install.c	Sun Apr 21 05:14:16 2002
> +++ scrollkeeper-devel/libs/install.c	Wed May 22 22:14:28 2002
> @@ -144,11 +144,14 @@
>      return toc_tree;
>  }
>  
> +/* FIXME: this function should be rewritten to provide warnings/errors for all
> +   cases in which it doesn't install an OMF entry. Currently it may fail
> +   silently for a variety of reasons. */
>  int install(char *omf_name, char *scrollkeeper_dir, char *data_dir, char
> outputprefs)
>  {    
>      xmlDocPtr omf_doc;
>      xmlDtdPtr dtd;
> -    xmlNodePtr node, s_node;
> +    xmlNodePtr node, omf_node, s_node;
>      char *docpath, *title, *format, str[1024];
>      char cl_filename[PATHLEN], cl_ext_filename[PATHLEN];
>      char locale_dir[PATHLEN], locale_name[PATHLEN], *locale, *ptr;
> @@ -193,7 +196,24 @@
>         they should start from the top node's children
>      */
>  
> -    for(node = omf_doc->children->children; node != NULL; node = node->next)
> +    /* Well, sort of. Let's do the right thing when comments are involved. */
> +    for(omf_node = omf_doc->children;
> +
> (omf_node != NULL) && (omf_node->type != XML_ELEMENT_NODE);
> +
> omf_node = omf_node->next)
> +
> ;;
> +
> +    if (!omf_node) {
> +
> /* This should not happen */
> +
> sk_message(outputprefs, SKOUT_DEFAULT, SKOUT_QUIET, "(install)", _("Failed to
> locate an <OMF> element.\n"));
> +
> return 0;
> +    }
> +    if (!omf_node->children) {
> +
> /* This should not happen */
> +
> sk_message(outputprefs, SKOUT_DEFAULT, SKOUT_QUIET, "(install)", _("<OMF> node
> has no children.\n"));
> +
> return 0;
> +    }
> +
> +    for(node = omf_node->children; node != NULL; node = node->next)
>      {
>          if (!xmlStrcmp(node->name, (xmlChar *)"resource"))
>  	{
> 

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Dan M. <mu...@al...>]

On Mon, 27 May 2002, Joe Clarke wrote:

> I don't think I was clear.  The build of gnome-core _succeeds_, however,
> the OMF files for certain components are not installed.  This breaks
> FreeBSD's packaging system since the plist refers to files that do not
> exist.  The Makefiles look pretty solid to me.

Ah, ok.  I'm not familiar with the plist system.  I'm glad that at least 
the build and regular install work correctly.  I hope the plist system can 
be massaged into ignoring these missing files.

If we have to, we could hack scrollkeeper-preinstall to have a different
failure mode where the OMF file is written.  The easy ways to do this
though would produce an invalid OMF file, without the encoding declaration
(eg. just copy the OMF file as is).  It would at least allow the package
build to proceed, although SK would not be able to register these
documents when they are installed. (It would silently fail to register
them, writing a message to the log file at install time.)  Tell me what
you think, as this would be easy to do and may be helpful for other
packaging systems.

> > If we want complete support for older OMF files, we would need to be able
> > to automatically convert old OMF files to conform to the DTD.  It looks
> > like John has made a lot of progress in this.  We would need to try to
> > guess the encoding, which we can probably get right some but not all the
> > time.  For this to be useful, we would have to add support for SGML docs
> > back to ScrollKeeper.  The original SGML support used openjade which a lot
> > of distributors and people complained about as being crufty and uncommon.
> > We would need to use the SGML support DV put into libxml2, which should be
> > much better but still has some issues I think.
> >
> > The question is, do we want SK-0.4.0 to fail gracefully for old OMF files
> > or do we want to try to get complete backwards compatibility with full
> > functionality?
> 
> I'd like to see full backwards compat.  However, the more I look into
> things, I _think_ I can create both scrollkeeper (0.2) and scrollkeeper2
> (0.3.x|0.4.x) ports which will be built depending on the version of GNOME
> desired.  It looks like GNOME 1.4.x libraries (i.e. gnome-libs, oaf,
> bonobo, etc.) don't really use scrollkeeper as much as the desktop
> components (i.e. gnome-core, gnome-applets, gnome-utils, etc.) do.  If
> that's the case, then I should be okay.  Thoughts....

In GNOME 1.4.x, only Nautilus accesses the ScrollKeeper database info.  
All of the packages with end-user documentation (ie. the desktop 
components) install docs with OMF files, while none of the platform 
packages (ie. libraries) do.

> I really appreciate this dialog.  It's helping a lot with the porting
> process.

:)

It is good to review these things periodically, since most people who need 
to know these things don't always watch this mailing list.

Dan

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Joe C. <ma...@ma...>]

On Mon, 27 May 2002, Dan Mueth wrote:

>
> On 27 May 2002, John Fleck wrote:
>
> > On Sun, 2002-05-26 at 23:46, Dan Mueth wrote:
> > >
> > >
> > > For FreeBSD, I'd recommend just using GNOME 1.4.x with the latest stable
> > > ScrollKeeper (0.2.0), which should work fine.  (Note that ScrollKeeper
> > > 0.3.x is the developer-only series.)  GNOME 2.0 and ScrollKeeper 0.4.0
> > > should work together well and be out in a month or two.  After that, the
> > > use of versioned DTDs and stylesheets should allow us to maintain
> > > backwards compatibility.
> > >
> >
> > But there are likely to be mixed systems out there for a long time to
> > come. One of the premises of GNOME2 is that a lot of old GNOME1 apps
> > will not be ported in the near term, and therefore both systems should
> > be able to run in parallel.
> >
> > In addition, to the extent ScrollKeeper has been adopted more widely,
> > there may be other old-style OMF files remaining in the wild.
> >
> > Is it possible to make the newer versions (SK>3.6 or whenever the new
> > DTD came into use) more tolerant of the error caused by an old OMF that
> > doesn't validate against the DTD?
>
> Well, we definitely want any package to build and install fine, even if it
> contains OMF files for SK-0.2.0 and the user's/packager's system has
> SK-0.4.0.  On the SK side, this means we just determine if the OMF file
> validates and fail gracefully if it doesn't.  I think SK already does this
> correctly, although it is worth double-checking.  It also means the
> Makefiles must ignore this sort of error and complete the build and
> install.  I tried to be very generous with ignoring errors from
> ScrollKeeper in Makefiles for other packages for this reason.  It sounds
> like I may not have been generous enough though, since Joe said he had
> gnome-core fail to build.

I don't think I was clear.  The build of gnome-core _succeeds_, however,
the OMF files for certain components are not installed.  This breaks
FreeBSD's packaging system since the plist refers to files that do not
exist.  The Makefiles look pretty solid to me.

>
> If we want complete support for older OMF files, we would need to be able
> to automatically convert old OMF files to conform to the DTD.  It looks
> like John has made a lot of progress in this.  We would need to try to
> guess the encoding, which we can probably get right some but not all the
> time.  For this to be useful, we would have to add support for SGML docs
> back to ScrollKeeper.  The original SGML support used openjade which a lot
> of distributors and people complained about as being crufty and uncommon.
> We would need to use the SGML support DV put into libxml2, which should be
> much better but still has some issues I think.
>
> The question is, do we want SK-0.4.0 to fail gracefully for old OMF files
> or do we want to try to get complete backwards compatibility with full
> functionality?

I'd like to see full backwards compat.  However, the more I look into
things, I _think_ I can create both scrollkeeper (0.2) and scrollkeeper2
(0.3.x|0.4.x) ports which will be built depending on the version of GNOME
desired.  It looks like GNOME 1.4.x libraries (i.e. gnome-libs, oaf,
bonobo, etc.) don't really use scrollkeeper as much as the desktop
components (i.e. gnome-core, gnome-applets, gnome-utils, etc.) do.  If
that's the case, then I should be okay.  Thoughts....

>
> BTW: Does Yelp render SGML documents?

No.  I get all kinds of errors trying to render GNOME help documents in
yelp unless I have SK 0.3.6 installed (and then, I can only render GNOME 2
docs).  This may be a FreeBSD thing, though.

I really appreciate this dialog.  It's helping a lot with the porting
process.

Joe

>
> Dan
>
>
>
>

PGP Key : http://www.marcuscom.com/pgp.asc

Re: [Scrollkeeper-devel] scrollkeeper-0.3.x and GNOME 1.4.x

[Dan M. <mu...@al...>]

On 27 May 2002, John Fleck wrote:

> On Sun, 2002-05-26 at 23:46, Dan Mueth wrote:
> > 
> > 
> > For FreeBSD, I'd recommend just using GNOME 1.4.x with the latest stable
> > ScrollKeeper (0.2.0), which should work fine.  (Note that ScrollKeeper
> > 0.3.x is the developer-only series.)  GNOME 2.0 and ScrollKeeper 0.4.0
> > should work together well and be out in a month or two.  After that, the
> > use of versioned DTDs and stylesheets should allow us to maintain 
> > backwards compatibility.
> > 
> 
> But there are likely to be mixed systems out there for a long time to
> come. One of the premises of GNOME2 is that a lot of old GNOME1 apps
> will not be ported in the near term, and therefore both systems should
> be able to run in parallel.
> 
> In addition, to the extent ScrollKeeper has been adopted more widely,
> there may be other old-style OMF files remaining in the wild.
> 
> Is it possible to make the newer versions (SK>3.6 or whenever the new
> DTD came into use) more tolerant of the error caused by an old OMF that
> doesn't validate against the DTD?

Well, we definitely want any package to build and install fine, even if it
contains OMF files for SK-0.2.0 and the user's/packager's system has
SK-0.4.0.  On the SK side, this means we just determine if the OMF file
validates and fail gracefully if it doesn't.  I think SK already does this
correctly, although it is worth double-checking.  It also means the
Makefiles must ignore this sort of error and complete the build and
install.  I tried to be very generous with ignoring errors from
ScrollKeeper in Makefiles for other packages for this reason.  It sounds
like I may not have been generous enough though, since Joe said he had
gnome-core fail to build.

If we want complete support for older OMF files, we would need to be able
to automatically convert old OMF files to conform to the DTD.  It looks
like John has made a lot of progress in this.  We would need to try to
guess the encoding, which we can probably get right some but not all the
time.  For this to be useful, we would have to add support for SGML docs
back to ScrollKeeper.  The original SGML support used openjade which a lot
of distributors and people complained about as being crufty and uncommon.  
We would need to use the SGML support DV put into libxml2, which should be
much better but still has some issues I think.

The question is, do we want SK-0.4.0 to fail gracefully for old OMF files 
or do we want to try to get complete backwards compatibility with full 
functionality?

BTW: Does Yelp render SGML documents?

Dan