Issue 94561 - allow separate default folders for different document types
Summary: allow separate default folders for different document types
Status: CONFIRMED
Alias: None
Product: General
Classification: Code
Component: ui (show other issues)
Version: OOo 3.0 Beta 2
Hardware: PC All
: P3 Trivial with 1 vote (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-02 03:17 UTC by timdeaton
Modified: 2013-02-07 22:37 UTC (History)
2 users (show)

See Also:
Issue Type: ENHANCEMENT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments

Note You need to log in before you can comment on or make changes to this issue.
Description timdeaton 2008-10-02 03:17:52 UTC
I would like to be able to set separate default paths (under
|Tools|Options|OpenOffice.org|Paths|) for each type of document (Writer, Calc,
Impress, Base).  As a heavy user of Microsoft Office for more than 10 years, I
have so many of each type of files that I like to keep them segregated into
their own directories under "My Documents".

(I'm running Windows XP Home SP2.)

I originally mentioned this as a 2nd comment in a bug-report I had filed (closed
Issue 90463), and 'cornouws' didn't think it was a good idea, because the files
ought to be separated by subject matter and not by file type.

I can appreciate that.  That's what we do where I now work - a separate folder
for each client.  But there are also many times where subjects don't seem
predictable or users just don't have the time & patience to organize, and
hundreds of documents from a dozen different programs all end up in one big mess
in the 'My Documents' folder.  At my last employer, that was the norm.  

Having the ability to set MS Office up on their computers and at least default
all spreadsheets to an 'Excel' folder and all word-processing documents to a
'Word' folder helped a great deal.  And having one default place for all my
Access databases and nothing else also made life much easier.  THAT's why I'd
like to be able to set such defaults.  

The user wouldn't have to have separate folders if he didn't want to, and you
can always override them and save your documents someplace else.  But making
those separate defaults possible at least provides a minimum level of
organization - especially for those who accept Microsoft's default of hiding
file extensions.

Thanks,
Tim
Comment 1 cno 2008-10-02 07:18:33 UTC
Hi Tim,

Thanks for your explanation.
I still do not support the idea as such, but do set to new.

IMO something else with folders is more important and a bit related: when
opening or saving a file, is something done with the last used location and/or
the file on the screen?
There must be issues for this. At least I've seen debates/discussions on the
subject. Without choice for a change, atm.
But if the engineers consider it a succesful candidate for implementation, I
could initiate a discussion on user experience, to see if we can find a better
solution.
What do you think?
Comment 2 thorsten.martens 2008-10-02 11:19:20 UTC
TM->requirements: please have a look, thanks !
Comment 3 timdeaton 2008-10-03 03:00:16 UTC
Depending on how it's implemented, I think it could be very useful.  But what I
think of when reading your suggestion is something MS Office has always done,
and which I assumed OO was already doing as well.  

I don't really have the experience with OO to know, because most of my work so
far is still in MS Office.  (I hope to change that after v3.0 is finalized.)  My
OO work has been limited thus far to either creating or opening one file,
working on it, saving it, and then closing the file and the whole program.

Word, Access, and Excel always open looking at their default directories.  But
if I tell Excel to go get a file in xyz folder, it remembers that for the rest
of the session unless I tell it something else.  Any old file I had open will
remember it's home and be saved back there, but any new file I create & save
will default to that xyz folder.  If that's not how OOo already works, then I
would consider that a bug in desperate need of being fixed. 

-- Tim