On Fri, Sep 15, 2006 at 12:02:05PM +0200, Abdelrazak Younes wrote:
Georg Baum wrote:
Abdelrazak Younes wrote:
If only Lars and Georg work on this, I am afraid that it will take some
time before all the corner cases are worked out step by step.
I don't think that I am going to do any
Abdelrazak Younes wrote:
> If only Lars and Georg work on this, I am afraid that it will take some
> time before all the corner cases are worked out step by step.
I don't think that I am going to do any further unicode work. I'll just sit
and wait what happens. These endless discussions about
Georg Baum wrote:
> Abdelrazak Younes wrote:
>
>> If only Lars and Georg work on this, I am afraid that it will take some
>> time before all the corner cases are worked out step by step.
>
> I don't think that I am going to do any further unicode work. I'll just sit
> and wait what happens.
Georg Baum wrote:
Abdelrazak Younes wrote:
If only Lars and Georg work on this, I am afraid that it will take some
time before all the corner cases are worked out step by step.
I don't think that I am going to do any further unicode work. I'll just sit
and wait what happens.
Welcome to the
Abdelrazak Younes wrote:
> Well, I hope you don't include me in this group because I did some work
> on the unicode front.
No, I do not include you. I disagree with you about how the uncide things
should go, but I don't want to force you to do things in a way that you
personally think is wrong.
Georg Baum wrote:
Abdelrazak Younes wrote:
Well, I hope you don't include me in this group because I did some work
on the unicode front.
No, I do not include you.
Good... no... I can resist!
I disagree with you about how the uncide things
should go, but I don't want to force you to do
On Fri, Sep 15, 2006 at 12:02:05PM +0200, Abdelrazak Younes wrote:
> Georg Baum wrote:
> >Abdelrazak Younes wrote:
> >
> >>If only Lars and Georg work on this, I am afraid that it will take some
> >>time before all the corner cases are worked out step by step.
> >
> >I don't think that I am going
Andre Poenitz wrote:
On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
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
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Andre Poenitz wrote:
| On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
| I am tempted to convert everything even when a std::string would
| suffice. For example getFormatFromContents(), should that be:
|
| lyx::docstring const
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such a hurry.
This back and forth conversion
On Thu, Sep 14, 2006 at 09:59:01AM +0200, Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Andre Poenitz wrote:
| On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
| I am tempted to convert everything even when a std::string would
| suffice. For
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such a hurry.
Abdelrazak Younes [EMAIL PROTECTED] writes:
| This back and forth conversion tp/from utf8 during this transition
| phase is a real hassle. Taking this decision now will simplify and
| speed-up greatly the transition. We also need quickly the operator
| that Georg is working on (+=, streams, etc).
Georg Baum wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such a
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| This back and forth conversion tp/from utf8 during this transition
| phase is a real hassle. Taking this decision now will simplify and
| speed-up greatly the transition. We also need quickly the operator
| that Georg is
Abdelrazak Younes wrote:
For win/MSVC, boost::uint32_t is fine. The real problem as I understand
is mingw and cygwin. But I guess even those will be OK to use
boost::uin32_t when used with STLPort. If I am right (Georg, could you
confirm that?)
No, STLPort does not help as Enrico found out
Abdelrazak Younes wrote:
Georg Baum wrote:
It looks to me as if you want to convert almost everything to docstring.
That would have been better done with some global search/replace.
I really think we should have done just that. We are just complicating
our life for no real benefit. What's
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
It looks to me as if you want to convert almost everything to docstring.
That would have been better done with some global search/replace.
I really think we should have done just that. We are just complicating
our life for no real
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about this transition: I've spent many hours already
trying to convert filetools to
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about this transition: I've spent many hours already
trying to
On Thu, Sep 14, 2006 at 02:09:01PM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about this
On Wed, Sep 13, 2006 at 04:30:08PM +0200, Abdelrazak Younes wrote:
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
};
Andre Poenitz wrote:
On Thu, Sep 14, 2006 at 02:09:01PM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about
Andre Poenitz wrote:
On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
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
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Andre Poenitz wrote:
| > On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
| >> I am tempted to convert everything even when a std::string would
| >> suffice. For example getFormatFromContents(), should that be:
| >>
| >>
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such a hurry.
This back and forth conversion
On Thu, Sep 14, 2006 at 09:59:01AM +0200, Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | Andre Poenitz wrote:
> | > On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
> | >> I am tempted to convert everything even when a std::string would
> | >>
Abdelrazak Younes wrote:
> Lars Gullik Bjønnes wrote:
>> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
>> | class MenuId: public KeyString {};
>> |
>> | class DialogId: public KeyString {};
>> |
>> |
>> | We need to take a decision now!
>>
>> No we don't.
>
> That's your opinion.
>
>> We
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This back and forth conversion tp/from utf8 during this transition
| phase is a real hassle. Taking this decision now will simplify and
| speed-up greatly the transition. We also need quickly the operator
| that Georg is working on (+=, streams,
Georg Baum wrote:
Abdelrazak Younes wrote:
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| class MenuId: public KeyString {};
|
| class DialogId: public KeyString {};
|
|
| We need to take a decision now!
No we don't.
That's your opinion.
We are not in such
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| This back and forth conversion tp/from utf8 during this transition
| phase is a real hassle. Taking this decision now will simplify and
| speed-up greatly the transition. We also need quickly the operator
| that Georg is
Abdelrazak Younes wrote:
> For win/MSVC, boost::uint32_t is fine. The real problem as I understand
> is mingw and cygwin. But I guess even those will be OK to use
> boost::uin32_t when used with STLPort. If I am right (Georg, could you
> confirm that?)
No, STLPort does not help as Enrico found
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> It looks to me as if you want to convert almost everything to docstring.
>> That would have been better done with some global search/replace.
>
> I really think we should have done just that. We are just complicating
> our life for no real benefit.
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
It looks to me as if you want to convert almost everything to docstring.
That would have been better done with some global search/replace.
I really think we should have done just that. We are just complicating
our life for no real
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about this transition: I've spent many hours already
trying to convert filetools to
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about this transition: I've spent many hours already
trying to
On Thu, Sep 14, 2006 at 02:09:01PM +0200, Abdelrazak Younes wrote:
> Abdelrazak Younes wrote:
> >Georg Baum wrote:
>
> >>Then I suggest that you don't get involved anymore in the converting
> >>business, that will be easier for all of us.
> >
> >I might do that indeed.
>
> Just a final note
On Wed, Sep 13, 2006 at 04:30:08PM +0200, Abdelrazak Younes wrote:
> >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,
Andre Poenitz wrote:
On Thu, Sep 14, 2006 at 02:09:01PM +0200, Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
Then I suggest that you don't get involved anymore in the converting
business, that will be easier for all of us.
I might do that indeed.
Just a final note about
Abdelrazak Younes wrote:
Am I right that all of the filetools.h API should be converted to
docstring?
If filenames with non-ASCII characters should be supported, then yes.
I have started the conversion already so please tell me quick if that's
not the case.
You will probably need to add
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not sure if a blind conversion is
Georg Baum wrote:
Abdelrazak Younes wrote:
Am I right that all of the filetools.h API should be converted to
docstring?
If filenames with non-ASCII characters should be supported, then yes.
I think we should support that indeed.
I have started the conversion already so please tell me
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not
Lars Gullik Bjønnes wrote:
Filesystems and unicode is tricky.
And I am not sure if a blind conversion is the way to go.
But, yes, I think we should allow for utf-8 filesystem (I do not think
anyone uses utf-16 in the filesystem?)
I'd prefere is most of this work tried to leverage
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Am I right that all of the filetools.h API should be converted to
| docstring?
| | | I have started the conversion already so please tell me quick if
| | that's not the
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
Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
| I think NTFS is UFT16...
Hmm... strange choice imho.
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of
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
Angus Leeming wrote:
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of UTF-16. See http://en.wikipedia.org/wiki/UTF-16.
Originally, all Unicode Windows
Abdelrazak Younes wrote:
So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
If the answer to that question is yes and it does not create problems
elsewhere, then it would be OK with me.
In this
Joost Verburg wrote:
Originally, all Unicode Windows features and the NTFS file system
used UCS-2 encoding. After Unicode 3.0 became available this has
been upgraded. Windows 2000 and later support UTF-16.
Thanks, Joost.
Angus
Georg Baum wrote:
Abdelrazak Younes wrote:
So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
Me neither but probably not. Unless a Chinese user for example use a
format is not defined in
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Georg
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Sure... I meant
Abdelrazak Younes writes:
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs
resulting from this misunderstanding.
format names are unique, file
Angus Leeming wrote:
Abdelrazak Younes writes:
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs
resulting from this misunderstanding.
format names
Abdelrazak Younes [EMAIL PROTECTED] writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
--
Lgb
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Am I right that all of the filetools.h API should be converted to
| docstring?
| | | I have started the conversion already so please tell me
Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
orrh I am not stupid!
I mean ascii is a subset of ucs4 using the first byte...
Abdelrazak Younes [EMAIL PROTECTED] writes:
| I'd prefere is most of this work tried to leverage boost::filesystem
| as much as possible.
|
| Yes, I think I've read somewhere that boost::filesystem will support
| the default encoding of the system in 1.34.
Note that we are using
Angus Leeming wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
No, all is as it should be. NTFS uses UTF-16 (thanks again, Joost), so that
can be stored reasonably well in std::wstring although there will be corner
cases where two wchar_ts are required to represent a single unicode
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
Angus Leeming wrote:
Note that keeping std::string for the format name will enable you to
enforce
the distinction at compile time. Even clearer if you follow Georg's
suggestion
of
typedef std::string
Georg Baum wrote:
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
Angus Leeming wrote:
Note that keeping std::string for the format name will enable you to
enforce
the distinction at compile time. Even clearer if you follow Georg's
suggestion
of
typedef std::string
On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
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
On Wed, Sep 13, 2006 at 04:17:15PM +0200, Lars Gullik Bjønnes wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
| Lars Gullik Bjønnes wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| | Am I right that all of the filetools.h API should be converted to
| docstring?
| | | I have
Abdelrazak Younes wrote:
> Am I right that all of the filetools.h API should be converted to
> docstring?
If filenames with non-ASCII characters should be supported, then yes.
> I have started the conversion already so please tell me quick if that's
> not the case.
You will probably need to
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not sure if a "blind" conversion
Georg Baum wrote:
Abdelrazak Younes wrote:
Am I right that all of the filetools.h API should be converted to
docstring?
If filenames with non-ASCII characters should be supported, then yes.
I think we should support that indeed.
I have started the conversion already so please tell me
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not
Lars Gullik Bjønnes wrote:
> Filesystems and unicode is tricky.
> And I am not sure if a "blind" conversion is the way to go.
>
> But, yes, I think we should allow for utf-8 filesystem (I do not think
> anyone uses utf-16 in the filesystem?)
>
> I'd prefere is most of this work tried to
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Am I right that all of the filetools.h API should be converted to docstring?
|
| I have started the conversion already so please tell me quick if
| that's not the case.
Filesystems and unicode is tricky.
And I am not
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Am I right that all of the filetools.h API should be converted to
| > docstring?
| > | | I have started the conversion already so please tell me quick if
| > | that's
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
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | I think NTFS is UFT16...
> Hmm... strange choice imho.
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of
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
Angus Leeming wrote:
You reckon? I think that it was pretty farsighted. NTFS was designed in about
1992.
For the pedantically-minded, I believe that NTFS is encoded in UCS-2, a fixed-
length 16 bit subset of UTF-16. See http://en.wikipedia.org/wiki/UTF-16.
Originally, all Unicode Windows
Abdelrazak Younes wrote:
> So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
If the answer to that question is yes and it does not create problems
elsewhere, then it would be OK with me.
> In
Joost Verburg wrote:
> Originally, all Unicode Windows features and the NTFS file system
> used UCS-2 encoding. After Unicode 3.0 became available this has
> been upgraded. Windows 2000 and later support UTF-16.
Thanks, Joost.
Angus
Georg Baum wrote:
Abdelrazak Younes wrote:
So you would be OK if I change also all code that deals with format names?
The question is: Do non-ASCII format names make sense? I really don't know.
Me neither but probably not. Unless a Chinese user for example use a
format is not defined in
Abdelrazak Younes wrote:
> Then we need docstring as we don't know which kind of extension a user
> could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Georg
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs resulting from
this misunderstanding. format names are unique, file extensions not.
Sure... I meant
Abdelrazak Younes writes:
> Georg Baum wrote:
> > Abdelrazak Younes wrote:
>>> Then we need docstring as we don't know which kind of extension a user
>>> could create.
>> Please: format name != file extension!!! I fixed several bugs
>> resulting from this misunderstanding.
>> format names are
Angus Leeming wrote:
Abdelrazak Younes writes:
Georg Baum wrote:
Abdelrazak Younes wrote:
Then we need docstring as we don't know which kind of extension a user
could create.
Please: format name != file extension!!! I fixed several bugs
resulting from this misunderstanding.
format names
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
--
Lgb
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | Am I right that all of the filetools.h API should be converted to
| > docstring?
| > | | I have started the conversion already so please
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| I don't like much asciistring because docstring can be ascii also.
No... it cannot it has 4-byte chars remember.
orrh I am not stupid!
I mean ascii is a subset of ucs4 using the first byte...
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > | > I'd prefere is most of this work tried to leverage boost::filesystem
> > | > as much as possible.
> > |
> > | Yes, I think I've read somewhere that boost::filesystem will support
> > | the default encoding of the system in 1.34.
> >
> > Note
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
No, all is as it should be. NTFS uses UTF-16 (thanks again, Joost), so that
can be stored reasonably well in std::wstring although there will be corner
cases where two wchar_ts are required to represent a single unicode
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
> Angus Leeming wrote:
> > Note that keeping std::string for the format name will enable you to
enforce
> > the distinction at compile time. Even clearer if you follow Georg's
suggestion
> > of
> > typedef std::string
Georg Baum wrote:
Am Mittwoch, 13. September 2006 17:41 schrieb Abdelrazak Younes:
Angus Leeming wrote:
Note that keeping std::string for the format name will enable you to
enforce
the distinction at compile time. Even clearer if you follow Georg's
suggestion
of
typedef std::string
On Wed, Sep 13, 2006 at 03:40:34PM +0200, Abdelrazak Younes wrote:
> 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
>
>
On Wed, Sep 13, 2006 at 04:17:15PM +0200, Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | Lars Gullik Bjønnes wrote:
> | > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> | > | Am I right that all of the filetools.h API should be converted to
> | > docstring?
> |
Abdelrazak Younes [EMAIL PROTECTED] writes:
| While re-compiling LyX, I noticed the following warning:
|
| ..\..\..\src\lyxfunc.C(218) : warning C4244: 'initializing' :
| conversion from 'lyx::char_type' to 'char', possible loss of data
|
| in
|
| void LyXFunc::handleKeyFunc(kb_action
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| While re-compiling LyX, I noticed the following warning:
|
| ..\..\..\src\lyxfunc.C(218) : warning C4244: 'initializing' :
| conversion from 'lyx::char_type' to 'char', possible loss of data
|
| in
|
| void LyXFunc::handleKeyFunc(kb_action
[EMAIL PROTECTED] writes:
| Due to a discussion on the PmWiki list, I'd like to check if I've gotten
| it correct that LyX 1.5 will be unicode, and 1.6 will use an XML-based
| file format?
Yes. This is correct.
--
Lgb
[EMAIL PROTECTED] writes:
| Due to a discussion on the PmWiki list, I'd like to check if I've gotten
| it correct that LyX 1.5 will be unicode, and 1.6 will use an XML-based
| file format?
Yes. This is correct.
--
Lgb
Bennett Helm [EMAIL PROTECTED] writes:
| On Jul 16, 2006, at 3:22 AM, Georg Baum wrote:
|
| Am Samstag, 15. Juli 2006 21:45 schrieb
| [EMAIL PROTECTED]:
|
| AFAIK, it's just a matter of placing stuff in some directory
| (which) and
| then you should perhaps tell someone (who?).
|
| You
Bennett Helm <[EMAIL PROTECTED]> writes:
| On Jul 16, 2006, at 3:22 AM, Georg Baum wrote:
|
| > Am Samstag, 15. Juli 2006 21:45 schrieb
| > [EMAIL PROTECTED]:
| >
| >> AFAIK, it's just a matter of placing stuff in some directory
| >> (which) and
| >> then you should perhaps tell someone (who?).
On Jul 16, 2006, at 3:22 AM, Georg Baum wrote:
Am Samstag, 15. Juli 2006 21:45 schrieb
[EMAIL PROTECTED]:
AFAIK, it's just a matter of placing stuff in some directory
(which) and
then you should perhaps tell someone (who?).
You should put it in ftp.devel.lyx.org/pub/incoming and then
601 - 700 of 1246 matches
Mail list logo
