target OOo3.0

dev notes

See also Patrick's posts in the thread at trinity beginning here:
http://trinity.neooffice.org/modules.php?name=Forums&file=viewtopic&p=3952#3952

Currently this can only be done imperfectly--in fact, backwards--since OOo does
not provide enough information at save time.

Adding a type code or creator code to a file will typically add a resource fork to a file. Resource forks are 
disliked in many circumstances. 

AFAIK: 

* type and creator codes are legacy

* it's preferable to use extended attributes. 

No, type and creator codes are HFS metadata (just like extended attributes on
10.5); they have absolutely nothing to do with resource forks.

Thanks for all explanations. 

Please don't fear to provide patches: they are welcome

Set keyword

imho, this issue must be fiwed for 3.0 

sardisson: thanks for the clarification. Timely to remind myself about type code, creator code, filename 
suffix and resource fork ...
 
http://pastie.textmate.org/116495

ericb: much as I'd like to offer patches, I lack the skills. Sorry!

set target 3.x

set target 3.x

Can anybody on CC of the issue confirm whether it is 

- fixed 
- unfixed 

Tino ? 

Thanks  :-)

ÙThis remains unfixed in OOo 3.0rc1 on 10.5/Intel.  Saving a file and examining
it with an application[1] that supports viewing/editing type/creator codes
indicates that neither type code nor creator code is set (i.e., values are set
to ????).

[1] FileInfo, http://www.panix.com/~shopsinm/

If nobody disagrees, I'll have a look 

Created attachment 56618 [details]
creator as it should appear ?

Reassigning to me

@sardisson

That's what I have currently. Is it correct ?

In fact, we have a lot of creator types Apple registered, but we need to set them on the fly, what is not 
trivial (at least, I have no direct solution)

FYI, I have used just a little part of the patch, because most of it is obsolete, and only one parameter 
was set(two need to be set)

I'll take some time before the commit, to see whether the change has (probably positive) side effects

Started. Set target to 3.1 (I hope so .. )

> Created an attachment (id=56618)
> creator as it should appear ?

The Creator looks fine.

You don't want to be setting the Type on document files (like the creator007.odt
in the screenshot) to 'APPL'; that Type is reserved for applications.

If you can't set the right Type per document type (which is what I take "but we
need to set them on the fly, what is not trivial (at least, I have no direct
solution)" to mean, you should not set the Type at all, or use '????' as the
Type instead, and just set the Creator and fix only half of this bug.

@sardisson

Thanks for the comments. 

So, what type must be used ?  Looking at the list FileInfo does propose, I think there is no other choice, 
but I'm probably wrong. 

Other possibilities I found i n the documentation, are framework , bundle or .. I don't know. 
Got a better idea ?

> you should not set the Type at all, or use '????' as the Type instead, and just set the Creator and fix 
only half of this bug.

Interesting. 

Focusing first on the type code:

Re http://developer.apple.com/faq/datatype.html 

> Apple no longer registers file types

and AFAIK no-one looks to any other registering authority. It is, to some extent, a free-for-all. Open :)

As the formats of ODF are specifically open, 
so the corresponding type code(s) may/should be open. 

As we use _established_ extensions to file names 
(.odp .ods .odt et cetera), 
with no plan for an additional establishment 
(no notion of .odtooo3 for example),
so we need not -- probably SHOULD not -- 
vary from an _established_ file type:

NO%F

----

Now, shift focus to creator code:

As NeoOffice does not distinguish its creations or editions, 
so OpenOffice.org need not distinguish its creations or editions. 
Use creator code:

????

Setting a creator code at any time may be misinterpreted, rarely, as somewhat proprietary. 

Keep it open. 

Allow the user to make their own decisions concerning file/application associations. Users will typically 
do so using Finder | File menu | Get Info | Open with: …

==========
Likelihood
==========

> many long-time Mac users save files without extensions, the Finder relies on the file's type or creator 
code to match extension-less files to an application.

Ultimately, the occurence of extension-less files should be rare. Especially with more modern 
applications and more modern versions of Mac OS X. 

Now, with apologies for use of uppercase:

IF OpenOffice.org 3 
defaults to saving a file with the appropriate extension to its name

AND IF OpenOffice.org 3 
defaults to hiding the extension at the time of naming

THEN we people need have little or no concern regarding type code or creator code.


IF the user strays from that default and 
AND IF the user opts to _omit_ the extension, 
THEN I suspect that the type and creator should be 
NO%F ????


ONLY IF you prefer to establish an ADDITIONAL type 
for the same open format (IMHO not a good idea) 
THEN my first thoughts would be: 

ODF?

and that might allow for a future family of types within the new establishment:

ODFP
ODFS
ODFT

but I do strongly suspect that it will be better to respect the open and established type code 

NO%F

Distinction -- if ever -- should be by creator.

Best regards
Graham

Note to self, 

ADC Home > Reference Library > Guides > Cocoa > Design Guidelines > Document-Based Applications 
Overview > Saving HFS Type and Creator Codes

http://tinyurl.com/typecreator

Without intending to stray from Bugzilla: I'm a long-time user of 
Diigo, and am likely to keep highlights and sticky notes at 
http://groups.diigo.com/groups/openoffice 

There is a demand, and I think this code is usefull.

@grahamperrin  : I'm sorry but I only care for OpenOffice.org

any progress here, re-set target to 3.2 ?

OOo 3.2 is in show-stopper stage. This issue is re-targeted to OOo 3.x. If this
issue is critical for the current release please target it back.

Reset assigne to the default "issues@openoffice.apache.org".