Georg Baum wrote:
Abdelrazak Younes wrote:
I plan to first encapsulate the conversion to/from ascii inside each of
the filetools functions. Then I will look at how boost::filesystem can
handle unicode, if at all possible...
I am tempted to convert everything even when a std::string would
suffice. For example getFormatFromContents(), should that be:
lyx::docstring const getFormatFromContents(lyx::docstring const & name);
or
std::string const getFormatFromContents(lyx::docstring const & name);
I prefer the latter. I really like to have a clear distinction between data
that can be in unicode and data that is ASCII.
I agree that it is good to differentiate between those but then it's
very cumbersome to have to do conversion each time you want to display
it. So I prefer this solution:
format names are currently
ASCII so getFormatFromContents should only be changed to return docstring
if at the same time all code that deals with format names is also changed.
So you would be OK if I change also all code that deals with format names?
I guess the format name could stay with std::string but this would not
bring a big performance advantage. The first solution (docstring has the
advantage that it looks nicer and we won't need to convert that to
docstring if we need to display that format name somewhere.
Performance is not the most important thing in this case IMO. The most
important thing is code that is easy to understand.
In this case, I think the format should be an enum instead.
enum FileFormat {
jpg,
lyx,
etc
};
What do you think?
You will be tempted to do another cleanup ;-)
Indeed ;-)
We all know that our current treating fo filenames is bad. All filenames
should be stored in a special filename class that deals with all filename
aspects, not a string of whatever kind. That class would of course make
heavy use of boost::filesystem internally. Things like makeAbsPath would go
completely, and replaced by a member of the filename class.
Angus made a start with the FileName class already, but it is not finished.
So IMO you have two options:
- convert all filenames to docstring, but don't change the existing design
That's my plan for now.
- Do the big thing and implement proper handling of filenames.
I will be reasonable this time and do the conversion first ;-)
Abdel.
