Recruiting a Mac programmer sounds extremely sensible. I doubt it could be
done otherwise. MacOS has its own or preferred ways of handling just about
everything, as well as established ways of accommodating exceptions,
options, variations that will turn up when running in many languages and on
several versions of the OS. A lot of tools are available. I do strongly
recommend everyone writing code on this project take David's suggestion,
get an Apple Developer login and become familiar with the structure of a
Mac application and the development tools and software libraries that are
freely available on Apple's developer site.
I don't know if there are any cross compilation tools that allow Windows
applications to recompile to run on a Mac. There used to be a good variety
that allow Mac application source code to cross compile to create a version
that will run under Windows. If there are it could safe a lot of grief,
finding the right tools to create once and compile for several platforms.
I have been giving thought to how best to handle text in Hermes
given the desire to produce versions for Linux and Mac. Broadly
there are three options, as follows:
(1) Handle all text as UTF-8 and, in Windows, convert to UTF-16 at a
low level when dealing with the Windows API.
(2) Handle all text as UTF-16 and, in Linux, convert to UTF-8 at a
low level when calling Linux APIs.
(3) Use MSVC's TCHAR mechanism which allows text to be either UTF-8
or UTF-16 depending on a compilation option. For Windows we would
use UTF-16 and for Linux UTF-8. I am unclear which would be better
for Mac.
I dislike (1) mostly because it would require the most extensive
changes for Windows and I think we should give priority to getting a
Windows version completed with as few changes as practical. I
dislike (2) because, while there can be no problem storing text as
UTF-16 on all platforms, facilities for manipulating text as UTF-16
may be limited on Linux (and possibly Mac). The bottom line is that
I find myself favouring (3). It makes for great consistency.
Everywhere text is stored in char's it is assumed to be UTF-8
(except of course in contexts where it is being converted from other
single- and multi-byte character sets to UTF-8) and everywhere text
is stored in wchar_t's it is assumed to be UTF-16.
Do we have any consensus on this? Before making a final decision, it
would be useful to know what WxWidgets works with -- I hope either.
Soren, could you answer this for us, please.
I am not a Mac programmer, but have been around long enough to have
some ideas....
Firstly, in what context are you wanting to handle text? Messages can
arrive in multiple encodings, and presumably will need to be left in
that form? Or are you thinking of text strings as part of the
program? Or even the source code itself?
As for what Mac supports, TextWrangler (a version of the very highly
regarded BBedit programmer's editor) supports all these encodings:
I believe UTF-8 is most common. Note also that there are two formats
of UTF-16 with bytes switched. Mac uses one, Windows uses the other
iirc. No idea what BOM above means.
Note also that line endings on Mac were originally a carriage return,
but when it switched to a Unix base with OS X, the default became a
line feed. Both are still supported. This compares with Windows which
I believe is a carriage return/line feed pair.
It is free - you just need an Apple ID. It has all the documentation
about Apple products. There are also forums where you can interact
with other developers to clarify techy issues. You may even be able
to recruit a Mac programmer to provide more practical input.
In the samples for WxWidgets there are examples of autotools files that
presumably builds on all platforms, including OSX or Mac or whatever it has
become. Also Borland C++. I can't get them to compile right now, but this
may be because I have installed and uninstalled WxWidgets and other
programs so many times that my Linux is effed. I may have to reinstall
Debian. No big deal, I just have to backup a lot of stuff.
Also, these configure and makefiles are very complex. Some even refer to
the automake build system as "autohell".
I have it layed out in my head. I even started in codelite, but I would
like to use the Autotools build system.
Do you have more experience with autotools than me Pete?
Recruiting a Mac programmer sounds extremely sensible. I doubt it could be
done otherwise. MacOS has its own or preferred ways of handling just about
everything, as well as established ways of accommodating exceptions,
options, variations that will turn up when running in many languages and on
several versions of the OS. A lot of tools are available. I do strongly
recommend everyone writing code on this project take David's suggestion,
get an Apple Developer login and become familiar with the structure of a
Mac application and the development tools and software libraries that are
freely available on Apple's developer site.
I don't know if there are any cross compilation tools that allow Windows
applications to recompile to run on a Mac. There used to be a good variety
that allow Mac application source code to cross compile to create a version
that will run under Windows. If there are it could safe a lot of grief,
finding the right tools to create once and compile for several platforms.
Laurie
On Tue, Sep 18, 2018 at 9:32 PM David Morrison
davidmorr@users.sourceforge.net wrote:
I have been giving thought to how best to handle text in Hermes
given the desire to produce versions for Linux and Mac. Broadly
there are three options, as follows:
(1) Handle all text as UTF-8 and, in Windows, convert to UTF-16 at a
low level when dealing with the Windows API.
(2) Handle all text as UTF-16 and, in Linux, convert to UTF-8 at a
low level when calling Linux APIs.
(3) Use MSVC's TCHAR mechanism which allows text to be either UTF-8
or UTF-16 depending on a compilation option. For Windows we would
use UTF-16 and for Linux UTF-8. I am unclear which would be better
for Mac.
I dislike (1) mostly because it would require the most extensive
changes for Windows and I think we should give priority to getting a
Windows version completed with as few changes as practical. I
dislike (2) because, while there can be no problem storing text as
UTF-16 on all platforms, facilities for manipulating text as UTF-16
may be limited on Linux (and possibly Mac). The bottom line is that
I find myself favouring (3). It makes for great consistency.
Everywhere text is stored in char's it is assumed to be UTF-8
(except of course in contexts where it is being converted from other
single- and multi-byte character sets to UTF-8) and everywhere text
is stored in wchar_t's it is assumed to be UTF-16.
Do we have any consensus on this? Before making a final decision, it
would be useful to know what WxWidgets works with -- I hope either.
Soren, could you answer this for us, please.
I am not a Mac programmer, but have been around long enough to have
some ideas....
Firstly, in what context are you wanting to handle text? Messages can
arrive in multiple encodings, and presumably will need to be left in
that form? Or are you thinking of text strings as part of the
program? Or even the source code itself?
As for what Mac supports, TextWrangler (a version of the very highly
regarded BBedit programmer's editor) supports all these encodings:
I believe UTF-8 is most common. Note also that there are two formats
of UTF-16 with bytes switched. Mac uses one, Windows uses the other
iirc. No idea what BOM above means.
Note also that line endings on Mac were originally a carriage return,
but when it switched to a Unix base with OS X, the default became a
line feed. Both are still supported. This compares with Windows which
I believe is a carriage return/line feed pair.
It is free - you just need an Apple ID. It has all the documentation
about Apple products. There are also forums where you can interact
with other developers to clarify techy issues. You may even be able
to recruit a Mac programmer to provide more practical input.
[Re: [hermesmail:discussion] Re: [hermesmail:discussion] The question
of text-handling](https://sourceforge.net/p/hermesmail/
discussion/general/thread/2f4b1b07/?limit=25#c90f)
Recruiting a Mac programmer sounds extremely sensible. I doubt it could be
done otherwise. MacOS has its own or preferred ways of handling just about
everything, as well as established ways of accommodating exceptions,
options, variations that will turn up when running in many languages and on
several versions of the OS. A lot of tools are available. I do strongly
recommend everyone writing code on this project take David's suggestion,
get an Apple Developer login and become familiar with the structure of a
Mac application and the development tools and software libraries that are
freely available on Apple's developer site.
I don't know if there are any cross compilation tools that allow Windows
applications to recompile to run on a Mac. There used to be a good variety
that allow Mac application source code to cross compile to create a version
that will run under Windows. If there are it could safe a lot of grief,
finding the right tools to create once and compile for several platforms.
On Tue, Sep 18, 2018 at 9:32 PM David Morrison davidmorr@users.sourceforge.net wrote:
A mac programmer would be invaluable.
In the samples for WxWidgets there are examples of autotools files that
presumably builds on all platforms, including OSX or Mac or whatever it has
become. Also Borland C++. I can't get them to compile right now, but this
may be because I have installed and uninstalled WxWidgets and other
programs so many times that my Linux is effed. I may have to reinstall
Debian. No big deal, I just have to backup a lot of stuff.
Also, these configure and makefiles are very complex. Some even refer to
the automake build system as "autohell".
I have it layed out in my head. I even started in codelite, but I would
like to use the Autotools build system.
Do you have more experience with autotools than me Pete?
Regards
On Wednesday, September 19, 2018, Music_Mouse laurie_spiegel@users.sourceforge.net wrote:
--
Søren Bro Thygesen