Template field on the General page of the document properties

Gary

Does anybody know how sure whether or not that a document file generated
from a template would automatically have the template filename
automatically inserted in the Template field of the General page of the
document properties (File > Properties > General)? I somehow thought
that was the case; however, it does not work on the test documents I
created today by a few test templates (version 3.3, I think...). I am
using version 3.4.3.

The behavior I see with Writer when opening a custom template is that
the new document name is "Untitled #". I did find a setting to change
this behavior. This behavior is similar to what I remember from MSO;
using a template results in a new document Named "Untitled #".

The behavior that I get for the Template field is: that field in a new file created from a template is empty, even if the template had that
field entered. It remains empty even after the new file copy is assigned another name other than Untitled and saved.

Do you know what is supposed to occur? The online help is not terribly informative about the Template field in the General page. I assumed that the filename for the template that generated the file copy would have its filename automatically entered in the Template field. No?

Gary

Does anybody know how sure whether or not that a document file generated from a template would automatically have the template filename automatically inserted in the Template field of the General page of the document properties (File > Properties > General)? I somehow thought that was the case; however, it does not work on the test documents I created today by a few test templates (version 3.3, I think...). I am using version 3.4.3.

What you describe has always worked for me, as long as I use File > New > Templates and Documents (or one of the equivalent ways of getting to Templates and Documents) or when using the Template Changer extension.

However, if you create the new file by double-clicking on the template in any ordinary folder, the template is NOT attached and the name of the template does NOT appear on the Properties page. Or that used to be the behavior.

Later today I'll verify that with v3.4.3. What o/s are you using?

If so, would that particular field have to be preset in the template? I inserted an entry in that field in the template proper, and it still did not automatically carry over to the copy. Does this field need to be manually inserted in a document? Or might this behavior be a bug?

I didn't know it was possible to set that field manually.

--Jean

That field also exists in the template file proper. How does the template get that field entered, as the template does not have a template for itself? Does the UI just enter the filename for the template there so that it can import the data field to the copy?

Gary

BTW, the O/S is Windows XP Pro SP3 on an ancient P4 Wintel box. I use the older machine for testing the software. If it works there, it should work on the ultra-fast 64-bit Quad 4s, whose CPU benchmarks are nearly twenty times faster than the P4, with sixteen times as much RAM.

Gary.

Good question. I haven't a clue. You probably need to ask a developer.

--Jean

You are right. The Template field cannot be manually entered. However, I cannot get anything other than a blank Template field whenever generating a new template-file copy through the usual template process. Could this be a bug or is my version configured wrong?

On another point, the Comment command in the Edit menu is grayed-out. What needs to occur in order to get the Edit > Changes > Comment command into focus?

Gary

If I have time later today, I'll fire up my old Win XP Pro SP3 netbook
(and/or the Windows 7 laptop) and test this, but it certainly works as
described on Mac OS X Lion and Ubuntu 11.04. I haven't used OOo or LO
on any of my Windows installs in some time.

--Jean

It works for me when the cursor is anywhere in any changed text, but
not if the cursor is elsewhere.

--Jean

Maybe I should create a brand-new version 3.4.3 test template instead of trying to generate a version 3.3.4 template copy. Perhaps, the UI has been altered with version 3.4.x and is not backward compatible for a version 3.3.x template anymore.

In addition, generating a template copy by double-clicking it and not getting the Template field entered could be an unimplemented "feature" in itself--a bug. Why should one manner work, but not the other?

Gary

Maybe I should create a brand-new version 3.4.3 test template instead of
trying to generate a version 3.3.4 template copy. Perhaps, the UI has been
altered with version 3.4.x and is not backward compatible for a version
3.3.x template anymore.

My copy of LO_3_4_chapter_template.ott does not show anything in the
Template field in File > Properties > General.

If I use File > Templates > Edit to open that template for editing and
then use File > Templates > Save to create a copy under another name,
the resulting template (test.ott) does not show anything in the
Template field in File > Properties > General.

However, if I open a new .ODT document from that template and then use
File > Templates > Save to save the .odt as a new template
(test2.ott), the new template does show LO_3_4_chapter_template in
that field.

In addition, generating a template copy by double-clicking it and not
getting the Template field entered could be an unimplemented "feature" in
itself--a bug. Why should one manner work, but not the other?

It's been that way for years in OOo. I believe it's considered a
feature: the idea is that for some documents one might want the
template associated with the file (so when the template is updated,
the file pops up the "do you want to update styles" message); but for
other documents, one might want them based on the template but not
associated with it.

As for undocumented: I had written this up in an earlier version of
the Writer Guide, and I thought the info was still there. Ah, well, my
memory isn't what it used to be. Or perhaps I removed it because the
info was incomplete; there seem to be a lot of non-obvious
interactions. Because of that complexity, this is one of the topics on
my list for extensive research for my proposed book on styles and
templates.

--Jean

One major problem with OOo was not knowing if some of its deficiencies were bugs that might get fixed or if some bugs would be permanent. (Both MS Word and FrameMaker still have numerous bugs remaining unfixed from well over a decade already, and newer bugs are continually being created.)

OOo would take eons in order to tackle many of their bugs, as newer bugs were likely piling up faster than their relatively few developers could fix them. LO seems to be a lot quicker. A case in point is LO's quick response to its first 3.4 release bug that would not handle edit tracking properly (where the copyedited deletions were not visible).

One problem with documentation when bugs are involved is that such documentation likely consists of workarounds--but these workarounds are not listed as being bug fixes. So, some documentation might not be accurate at some point in the future (or even needed) after any such bugs get fixed by the developers. IOW, the documents could contain much unnecessary (or possibly even nonfactual) material.

My take is that all documentation that involves known bug fixes should be disclosed as being bug fixes--even if doing that exposes the software suite to some criticism.

Gary

Hi :slight_smile:
I think it has already dealt with by having a fixed set of documentation for the 3.3.x branch and now making the newer release for the 3.4.x branch. See the gap at the right-hand-side of
http://wiki.documentfoundation.org/Documentation/Publications
Smart eh?

Some people may continue to prefer to use the work-arounds given as part of the documentation for the 3.3.x branch even after a bug has been fixed in some cases.

If you really feel the need to identify which established ways of doing things are/were due to bugs and which are/were just an alternative way or even a main way of doing things then feel free. I think Alfresco still has the folders ready for updating the older version of the documentation. Personally i think it's better to keep moving forwards where possible rather than to back-track.

The OOo devs were often able to fix bugs and they submitted many patches and updates that had already been tested by the community but Sun often disdained to accept work done by non-employees (apparently). That was part of the reason for forks such as Go-oo. It was probably also part of the reason why so much was achieved so quickly with the code in early releases of LO when Go-oo and possibly others re-integrated with LO. At least that's the impression i get after reading-up 3rd party accounts and hearing from a few disgruntled people that are much happier with LO under TDF than with anything under Sun.

Regards from
Tom :slight_smile:

One thing that you apparently do not understand is that I am not at all in favor of keeping any deadwood kludges around, as you stated, but to eliminate them in current and future docs. (I do not know how you inferred that I favor keeping deadwood. Just the opposite.)

However, if (undocumented) kludges were a part of any current templates or other docs--such as any remaining artifacts carried forward from buggy versions 1 or 2 even, just how would you any anyone else delete them if, in fact, you were not even aware of their existence in the first place?

My point is that all such esoteric workarounds put into any document, template, or master document should be adequately disclosed, so that anybody maintaining or reviewing or editing those docs would know of their existence, their locations, their effects, their reasons for existence, and whether or not they are even needed any longer. If LO or OOo were to use any such mysterious kludges in the future, they should be appropriately documented. OOo (and LO) rarely ever disclosed their former kludges in a clear, consistent manner. That's all to my point.

The only good reason that a workaround would have been used in the past was to act as a temporary band-aid approach due to a bug being present. Bugs generally get fixed, so after the bugs are fixed, the kludges should be eliminated in favor of better writing or editing practices.

Gary

Are there "kludges and workarounds" in our docs or templates?

I've got lost in this conversation, which seems to have mutated from
how templates work (and whether something we've observed is a bug or a
feature).

--Jean

Hi :slight_smile:
The 3.3.x branch was initial publicised as having "one year's support" and part of that surely has to include documentation. I get the feeling that a lot of people have forgotten about that promise but at least if documentation is there then we keep the promise and make it easier for other people to do so too, especially the Users List.

So it was really me that was saying i am in favour of keeping "old deadwood" but i am definitely not in favour of spending time on improving it.

There are problems within documentation but these seem to be being ironed out as we move forwards with the releases for the newer branches. It would be really cool and might make work easier in the future if there were comments on the documentation. I think there are some such notes in Alfresco rather than weighing down individual documents by having them embedded in some way.

I'm still not completely clear on how much of a template is retained or not in a final document but i think we have sometimes been trying to keep things light and fast for the end-users rather than for documenters.
Regards from
Tom :slight_smile:

That is my point. I would hope that none were used because if there were. it is likely that they would not be documented. However, I do not know if any still linger on as artifacts anymore.

In the past on occasion you had sprinkled around a few in some pages or another, especially when the buggy versions of master documents were involved. However, I do not recall ever seeing any editor notes or marginal comments about their use then either.

My advice is merely to prevent the future use of any kludges that are undocumented--not their use when advantageous, BTW.

Gary

Having marginal comments embedded within active source documents does not in any way bog down its use. They can serve as a cheap-and-easy form of conditional writing because the viewing (and printing) of the comments can be effectively squelched via menu commands and other options. However, if such kludges and their documentation ever become separated from each other, then numerous ambiguities as to their existence and possible usage can easily arise.

IOW, keep the kludges, if any get used, and their documents together--such as inserting marginal comments at the closest location of any workarounds.

Gary

Gary

Hi :slight_smile:
Words such as kludge and "work-around" are descriptions of types of coding. It just about stretches to documentation but for me ...

kludge = messy, inelegant coding that is a nightmare to look through. It might be original coding or it might be a patch. So, it's not necessarily a work-around. Apparently in OpenSource code people often leave a comment apologising if they have been forced into doing a quick kludge.

work-around = a bit of code that gets around a problem. It might look a bit weird if you take an overview of the entire project but it's not necessarily a kludge. It might be that perfect coding would involve a total re-write of the entire project but a work-around of just a few lines might give much the same result. A work-around might be a very elegant piece of coding and might even improve on some long-established coding.

Regards from
Tom :slight_smile:

Hi :slight_smile:
Ahhh, ok. I don't know what is in the notes but it's got to be worth having a quick look because there is likely to be some helpful stuff in there.
Regards from
Tom :slight_smile: