Re: MinGW compilation
On Sun, Dec 19, 2004 at 08:54:19PM +, Angus Leeming wrote: The unix fork, execvp pair doesn't exist on Windows. We can launch a child process well enough by using spawnvp, but then the unix waitpid(..., NOHANG) doesn't exist on Windows either, so LyX will never be informed when the process has ended. Re-write using the native API needed. With all this platform dependend stuff I wonder whether we shouldn't simply use Qt for QProcess, QSetting etc even with the xforms frontend. So we'd still get a reasonably slim and fast binary, yet do not have to re-invent the wheel. [I am not sure whether this is a goo/feasible idea myself] Andre'
Re: Configure problems for lyx-140 on Mac
Andreas Vox [EMAIL PROTECTED] writes: So the errormessage seems justified and we only have to find out which red-dripping includefile defined _D and _R ... | Ok, I found it. It's in /usr/include/ctype.h under the heading | /* backward compatibility */ -- hahaha, what about forward | compability? | Lars, Jean_Marc, what would be the best solution: | 1 - change include order (if possible) might work. Where is this ctype included from? Our code or library code? Does using cctype working better? | 2 - undef _D and _R after ctype.h was included ugly bugly | 3 - make a patch for Boost Not Boost, but GCC. The concept checks originally comes from boost, but they have been copied into GCC (libstc++). So it should be reported there. | 4 - make a patch for Apples ctype.h Yes, or at least make them aware of trhe -- Lgb
Re: MinGW compilation
Andre Poenitz wrote: On Sun, Dec 19, 2004 at 08:54:19PM +, Angus Leeming wrote: The unix fork, execvp pair doesn't exist on Windows. We can launch a child process well enough by using spawnvp, but then the unix waitpid(..., NOHANG) doesn't exist on Windows either, so LyX will never be informed when the process has ended. Re-write using the native API needed. With all this platform dependend stuff I wonder whether we shouldn't simply use Qt for QProcess, QSetting etc even with the xforms frontend. So we'd still get a reasonably slim and fast binary, yet do not have to re-invent the wheel. Granted, that is a practical idea. However, the cygwin-kde people haven't really implemented QProcess. Doing so ourselves isn't hard. Angus
Re: MinGW compilation
Andre Poenitz [EMAIL PROTECTED] writes: | On Sun, Dec 19, 2004 at 08:54:19PM +, Angus Leeming wrote: The unix fork, execvp pair doesn't exist on Windows. We can launch a child process well enough by using spawnvp, but then the unix waitpid(..., NOHANG) doesn't exist on Windows either, so LyX will never be informed when the process has ended. Re-write using the native API needed. | With all this platform dependend stuff I wonder whether we shouldn't | simply use Qt for QProcess, QSetting etc even with the xforms frontend. | So we'd still get a reasonably slim and fast binary, yet do not have to | re-invent the wheel. | [I am not sure whether this is a goo/feasible idea myself] I hate it already :-) I'd rather help make a boost::process lib. -- Lgb
My Documents et al --- success
It turns out that Jürgen's suggested way to ascertain the different
Windows folders is straightforward to implement. No need to use the .net
framework; it all exists in the standard WinAPI.
Question. What should we do in the unlikely event that these calls fail?
Post a warning or terminate?
Angus
$g++ -o trial trial.C
$ ./trial
APPDATA is C:\Documents and Settings\Angus\Application Data
COMMON_APPDATA is C:\Documents and Settings\All Users\Application Data
PERSONAL is C:\Documents and Settings\Angus\My Documents
$ cat trial.C
#include shlobj.h
#include iostream
#include string
// Needed for MinGW:
#ifndef SHGFP_TYPE_CURRENT
# define SHGFP_TYPE_CURRENT 0
#endif
std::string const folder_path(int folder_id)
{
char folder_path[MAX_PATH + 1];
if (SUCCEEDED(SHGetFolderPath(0, folder_id, 0,
SHGFP_TYPE_CURRENT, folder_path)))
return folder_path;
return std::string();
}
std::string const id_as_string(int folder_id)
{
if (folder_id == CSIDL_APPDATA)
return APPDATA;
if (folder_id == CSIDL_COMMON_APPDATA)
return COMMON_APPDATA;
if (folder_id == CSIDL_PERSONAL)
return PERSONAL;
return std::string();
}
void print_success(int folder_id)
{
std::string const folder_name = folder_path(folder_id);
std::string const id_str = id_as_string(folder_id);
if (folder_name.empty())
std::cout Unable to ascertain id_str
folder\n;
else
std::cout id_str is folder_name '\n';
}
int main()
{
print_success(CSIDL_APPDATA);
print_success(CSIDL_COMMON_APPDATA);
print_success(CSIDL_PERSONAL);
return 0;
}
Re: LFUN_MATH_MODE
On Mon, Dec 20, 2004 at 12:36:25PM +0100, Juergen Spitzmueller wrote: Alfredo Braunstein wrote: Note that Andre did the opposite change recently, maybe he had some reason to do it. ;-) (cvs says: fix #1736). But I have no idea. http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/ui/stdmenus.ui.diff?r1 =1.35r2=1.36 I see. There is also a check for the argument on in math_nestinset.C. I guess André forgot to check for that argument in other places (text3.C et al.). Indeed. Would be nice if you could fix that. Andre'
Re: My Documents et al --- success
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus It turns out that Jürgen's suggested way to ascertain the Angus different Windows folders is straightforward to implement. No Angus need to use the .net framework; it all exists in the standard Angus WinAPI. Yes, that's not a big surprise :) Angus Question. What should we do in the unlikely event that these Angus calls fail? Post a warning or terminate? Maybe terminate. This way we'll see people complain and we'll have an occasion to investigate... JMarc
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Do we need an os_mac.C? Well, that's difficult to do. Currently (besides the bundle hack you noticed) all the special mac support is in frontends/qt2 conditioned on Q_WS_MACX. This is because it is not possible outside of the frontend to ascertain whether we want to build LyX/Mac or LyX/Unix when we are under darwin. I think this is not a matter of os, but of packaging. I propose (maybe in the long term) to have a --with-packaging option (any better term is welcome) that can be either osx, win32 or unix and that this option control a package:: namespace where the code from path_defines is put (in three different versions probably). Also, this --with-packaging option will be able to set the various Makefile variables correctly. This packaging thing would set up lyxdir, userdir, localedir, document dir and things like that according to the platforms conventions. We can either do this now for 1.4.0cvs or replace temporarily with a hack. For 1.3.6cvs, the hack is probably a better idea. JMarc
Re: LFUN_MATH_MODE
Andre Poenitz wrote: I see. There is also a check for the argument on in math_nestinset.C. I guess André forgot to check for that argument in other places (text3.C et al.). Indeed. Would be nice if you could fix that. If you tell me how to handle the argument. Is it that the user can write both math-mode on content and math-mode content? I.e., do we have one argument or more? And do what in mathed/ needs fixing? Jürgen
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
Jean-Marc Lasgouttes wrote: This packaging thing would set up lyxdir, userdir, localedir, document dir and things like that according to the platforms conventions. We can either do this now for 1.4.0cvs or replace temporarily with a hack. Let's do it properly now. For 1.3.6cvs, the hack is probably a better idea. Agreed.
Re: My Documents et al --- success
Jean-Marc Lasgouttes wrote:
Angus It turns out that Jürgen's suggested way to ascertain the
Angus different Windows folders is straightforward to implement. No
Angus need to use the .net framework; it all exists in the standard
Angus WinAPI.
Yes, that's not a big surprise :)
Angus Question. What should we do in the unlikely event that these
Angus calls fail? Post a warning or terminate?
Maybe terminate. This way we'll see people complain and we'll have an
occasion to investigate...
Ok, then here's the proposal. Add to class (13x)/namespace(14x) os the
following functions that are set in os::init(int argc, char argv[]):
// The OS-dependent directory to which an application's
// system-wide data directory should generally be added.
string const os::system_appdir() {
// returns COMMON_APPDATA folder on Windows
// returns ??? on MacOS
// returns an empty string on Unix
}
// The OS-dependent directory to which an application's
// user-specific data directory should generally be added.
string const os::user_appdir() {
// returns APPDATA folder on Windows
// returns ??? on MacOS
// returns $HOME on Unix
}
// The OS-dependent directory to which a user's
// documents should generally be added.
string const os::document_dir() {
// returns PERSONAL folder on Windows
// returns ??? on MacOS
// returns $HOME on Unix
}
Then use these in lyx_main.C's LyX::init() (13x) or in path_defines.C's
setLyxPaths() (14x) to help set system_lyxdir, user_lyxdir and in
lyxrc.C's constructor to set the default lyxrc::document_path.
Thoughts?
Angus
Baffled by the reasoning
Why do we search for the system_lyxdir as // Path of binary/../share/name of binary/ but the user_lyxdir as // os::homepath() /. + PACKAGE where PACKAGE is defined in config.h as (here) lyx-1.3.6cvs. Why don't we use PACKAGE for the system_lyxdir too? Angus
Re: My Documents et al --- success
Angus == Angus Leeming [EMAIL PROTECTED] writes:
Angus // The OS-dependent directory to which an application's
Angus // system-wide data directory should generally be added.
Angus string const os::system_appdir() {
Angus // returns COMMON_APPDATA folder on Windows
On windows, I believe the right place to have the data directory is
the directory where the binary lives. There may even be an API
function to get this value directly.
Angus // returns ??? on MacOS
There is also an API for that. See:
http://doc.trolltech.com/3.3/mac-differences.html#7-1
Angus // returns an empty string on Unix
I think this one should contain the code that lives in path_defines
for now (with the stuff that follows symlinks)
Angus }
Angus // The OS-dependent directory to which an application's
Angus // user-specific data directory should generally be added.
Angus string const os::user_appdir() {
Angus // returns APPDATA folder on Windows
Or should it be APPDATA/LyX/ ?
Angus // returns ??? on MacOS
Currently this is ${HOME}/Library/Preferences/LyX
Angus // returns $HOME on Unix
Or return ${HOME}/.PACKAGE
Angus }
Angus // The OS-dependent directory to which a user's
Angus // documents should generally be added.
Angus string const os::document_dir() {
Angus // returns PERSONAL folder on Windows
Yes.
Angus // returns ??? on MacOS
I think it's HOME
Angus // returns $HOME on Unix
Angus }
You forgot the locale directory.
Angus Then use these in lyx_main.C's LyX::init() (13x) or in
Angus path_defines.C's setLyxPaths() (14x) to help set system_lyxdir,
Angus user_lyxdir and in lyxrc.C's constructor to set the default
Angus lyxrc::document_path.
I think we should reimplement setLyXPaths for each of these cases. It
will be much simpler.
Then there will be the special case of build directory to enable
running in place. This one may be trickier.
JMarc
Re: Baffled by the reasoning
Angus == Angus Leeming [EMAIL PROTECTED] writes: Angus Why do we search for the system_lyxdir as // Path of Angus binary/../share/name of binary/ but the user_lyxdir as // Angus os::homepath() /. + PACKAGE Angus where PACKAGE is defined in config.h as (here) lyx-1.3.6cvs. Angus Why don't we use PACKAGE for the system_lyxdir too? The algorithm that searches for the system_lyxdir is probably too complicated for its own good :) The idea was to allow to cinstall several versions of LyX concurrently without having to recomplie them (just with a couple of symlink). I think that reverting to just use PACKAGE instead of the name of the binary would prove simpler. JMarc
Re: Configure problems for lyx-140 on Mac
Lars Gullik Bjnnes [EMAIL PROTECTED] writes: Andreas Vox [EMAIL PROTECTED] writes: | 1 - change include order (if possible) might work. Where is this ctype included from? Our code or library code? ./configure does not include ctype directly, I traced it back to ctype.h - cctype -iosfwd - ios, string, streambuf, bits/stl_algobase.h Does using cctype working better? cctype includes ctype.h I guess cctype is the best place to correct this problem, cctype already has a section for Mac where they #undef the isalpha() Macros and the like. | 2 - undef _D and _R after ctype.h was included ugly bugly But it seems to work (I only tested the file created by ./configure), if you put something like #include ctype.h #undef _R #undef _D in front of the other includes. Is there a canonical place for LyX where we could put this? So I can test if it breaks anything else? /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox [EMAIL PROTECTED] writes: | ./configure does not include ctype directly, I traced it back to | ctype.h - cctype -iosfwd - ios, string, streambuf, bits/stl_algobase.h Does using cctype working better? | cctype includes ctype.h | I guess cctype is the best place to correct this problem, cctype already | has a section for Mac where they #undef the isalpha() Macros and the like. So this should absolutely be reported to apple. Then they can fix it. | 2 - undef _D and _R after ctype.h was included ugly bugly | But it seems to work (I only tested the file created by ./configure), if you | put something like | #include ctype.h | #undef _R | #undef _D | in front of the other includes. Sure it will work... but then why not just comment out the backwards compability stuff in ctype.h? | Is there a canonical place for LyX where we could put this? | So I can test if it breaks anything else? Not really... Only if you do it in config.h, making ctype.h being included in all files. -- Lgb
[PATCH] fix pch.h in frontends/qt2/ui
I installed a brand new Mandrake 10.1 on my laptop and thus was able to test precompiled headers support (gcc 3.4.1). The result is that I need the following patch. I do not like it much, I did not like the original code either. JMarc Index: src/frontends/qt2/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ChangeLog,v retrieving revision 1.739 diff -u -p -r1.739 ChangeLog --- src/frontends/qt2/ChangeLog 20 Dec 2004 16:59:32 - 1.739 +++ src/frontends/qt2/ChangeLog 21 Dec 2004 16:20:28 - @@ -1,3 +1,8 @@ +2004-12-21 Jean-Marc Lasgouttes [EMAIL PROTECTED] + + * ui/Makefile.am (%.C): make sure to remove the .pch file from the + uic command line. + 2004-12-19 Angus Leeming [EMAIL PROTECTED] * lyx_gui.C (start): s/slashify_path/internal_path/ Index: src/frontends/qt2/ui/Makefile.am === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ui/Makefile.am,v retrieving revision 1.27 diff -u -p -r1.27 Makefile.am --- src/frontends/qt2/ui/Makefile.am 4 Dec 2004 14:50:24 - 1.27 +++ src/frontends/qt2/ui/Makefile.am 21 Dec 2004 16:20:28 - @@ -30,4 +30,4 @@ UICFLAGS=-tr qt_ %.h: %.ui $(UIC) $(UICFLAGS) $ -o $@ %.C: %.h %.ui $(PCH_FILE) - $(UIC) $(UICFLAGS) -impl `echo $^ | sed 's/pch.h.gch//'` -o $@ + $(UIC) $(UICFLAGS) -impl `echo $^ | sed 's/[^ ]*pch.h.gch//'` -o $@
Re: [PATCH] fix pch.h in frontends/qt2/ui
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I installed a brand new Mandrake 10.1 on my laptop and thus was able | to test precompiled headers support (gcc 3.4.1). The result is that I | need the following patch. | I do not like it much, I did not like the original code either. Any better suggestions? -- Lgb
Re: [PATCH] fix pch.h in frontends/qt2/ui
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I installed a brand new Mandrake 10.1 on my laptop and thus was able | to test precompiled headers support (gcc 3.4.1). The result is that I | need the following patch. | I do not like it much, I did not like the original code either. I don't get why this is needed? Can you explain a bit? Hmm... gcc 3.4.1 is old.. -- Lgb
Re: [PATCH] fix pch.h in frontends/qt2/ui
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: | I Lars installed a brand new Mandrake 10.1 on my laptop and thus was Lars able | to test precompiled headers support (gcc 3.4.1). The Lars result is that I | need the following patch. Lars | I do not like it much, I did not like the original code Lars either. Lars Any better suggestions? Not really. Does the .C file really depend on PCH_FILE? JMarc
Re: [PATCH] fix pch.h in frontends/qt2/ui
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes: Lars I don't get why this is needed? Can you explain a bit? I do not have my laptop at hand, but the path to the pch file is passed to uic (only the naked file name is removed), and uic complains that it has an extra argument. Sorry for not being more specific, I am not typing from my laptop now. Lars Hmm... gcc 3.4.1 is old.. I knew this was coming... JMarc
Re: [PATCH] fix pch.h in frontends/qt2/ui
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: Lars Hmm... gcc 3.4.1 is old.. Jean-Marc I knew this was coming... Note also that gcc is absolutely not run in this case. You should rather complain about the version number of my qt, make or even sed ;) JMarc
Re: MinGW compilation
On Sun, Dec 19, 2004 at 08:54:19PM +, Angus Leeming wrote: > The unix "fork", "execvp" pair doesn't exist on Windows. We can launch a > child process well enough by using "spawnvp", but then the unix > "waitpid(..., NOHANG)" doesn't exist on Windows either, so LyX will never > be informed when the process has ended. Re-write using the native API > needed. With all this platform dependend stuff I wonder whether we shouldn't simply use Qt for QProcess, QSetting etc even with the xforms frontend. So we'd still get a reasonably slim and fast binary, yet do not have to re-invent the wheel. [I am not sure whether this is a goo/feasible idea myself] Andre'
Re: Configure problems for lyx-140 on Mac
Andreas Vox <[EMAIL PROTECTED]> writes: >> So the errormessage seems justified and we only have to find >> out which red-dripping includefile defined _D and _R ... > | Ok, I found it. It's in /usr/include/ctype.h under the heading | /* backward compatibility */ -- hahaha, what about forward | compability? > | Lars, Jean_Marc, what would be the best solution: > | 1 - change include order (if possible) might work. Where is this ctype included from? Our code or library code? Does using working better? | 2 - undef _D and _R after ctype.h was included ugly bugly | 3 - make a patch for Boost Not Boost, but GCC. The concept checks originally comes from boost, but they have been copied into GCC (libstc++). So it should be reported there. | 4 - make a patch for Apples ctype.h Yes, or at least make them aware of trhe -- Lgb
Re: MinGW compilation
Andre Poenitz wrote: On Sun, Dec 19, 2004 at 08:54:19PM +, Angus Leeming wrote: The unix "fork", "execvp" pair doesn't exist on Windows. We can launch a child process well enough by using "spawnvp", but then the unix "waitpid(..., NOHANG)" doesn't exist on Windows either, so LyX will never be informed when the process has ended. Re-write using the native API needed. With all this platform dependend stuff I wonder whether we shouldn't simply use Qt for QProcess, QSetting etc even with the xforms frontend. So we'd still get a reasonably slim and fast binary, yet do not have to re-invent the wheel. Granted, that is a practical idea. However, the cygwin-kde people haven't really implemented QProcess. Doing so ourselves isn't hard. Angus
Re: MinGW compilation
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Sun, Dec 19, 2004 at 08:54:19PM +, Angus Leeming wrote: >> The unix "fork", "execvp" pair doesn't exist on Windows. We can launch a >> child process well enough by using "spawnvp", but then the unix >> "waitpid(..., NOHANG)" doesn't exist on Windows either, so LyX will never >> be informed when the process has ended. Re-write using the native API >> needed. > | With all this platform dependend stuff I wonder whether we shouldn't | simply use Qt for QProcess, QSetting etc even with the xforms frontend. | So we'd still get a reasonably slim and fast binary, yet do not have to | re-invent the wheel. > | [I am not sure whether this is a goo/feasible idea myself] I hate it already :-) I'd rather help make a boost::process lib. -- Lgb
My Documents et al --- success
It turns out that Jürgen's suggested way to ascertain the different
Windows folders is straightforward to implement. No need to use the .net
framework; it all exists in the standard WinAPI.
Question. What should we do in the unlikely event that these calls fail?
Post a warning or terminate?
Angus
$g++ -o trial trial.C
$ ./trial
APPDATA is C:\Documents and Settings\Angus\Application Data
COMMON_APPDATA is C:\Documents and Settings\All Users\Application Data
PERSONAL is C:\Documents and Settings\Angus\My Documents
$ cat trial.C
#include
#include
#include
// Needed for MinGW:
#ifndef SHGFP_TYPE_CURRENT
# define SHGFP_TYPE_CURRENT 0
#endif
std::string const folder_path(int folder_id)
{
char folder_path[MAX_PATH + 1];
if (SUCCEEDED(SHGetFolderPath(0, folder_id, 0,
SHGFP_TYPE_CURRENT, folder_path)))
return folder_path;
return std::string();
}
std::string const id_as_string(int folder_id)
{
if (folder_id == CSIDL_APPDATA)
return "APPDATA";
if (folder_id == CSIDL_COMMON_APPDATA)
return "COMMON_APPDATA";
if (folder_id == CSIDL_PERSONAL)
return "PERSONAL";
return std::string();
}
void print_success(int folder_id)
{
std::string const folder_name = folder_path(folder_id);
std::string const id_str = id_as_string(folder_id);
if (folder_name.empty())
std::cout << "Unable to ascertain " << id_str
<< " folder\n";
else
std::cout << id_str << " is " << folder_name << '\n';
}
int main()
{
print_success(CSIDL_APPDATA);
print_success(CSIDL_COMMON_APPDATA);
print_success(CSIDL_PERSONAL);
return 0;
}
Re: LFUN_MATH_MODE
On Mon, Dec 20, 2004 at 12:36:25PM +0100, Juergen Spitzmueller wrote: > Alfredo Braunstein wrote: > > Note that Andre did the opposite change recently, maybe he had some reason > > to do it. ;-) (cvs says: "fix #1736"). But I have no idea. > > > > http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/lib/ui/stdmenus.ui.diff?r1 > >=1.35=1.36 > > I see. There is also a check for the argument "on" in math_nestinset.C. I > guess André forgot to check for that argument in other places (text3.C et > al.). Indeed. Would be nice if you could fix that. Andre'
Re: My Documents et al --- success
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> It turns out that Jürgen's suggested way to ascertain the Angus> different Windows folders is straightforward to implement. No Angus> need to use the .net framework; it all exists in the standard Angus> WinAPI. Yes, that's not a big surprise :) Angus> Question. What should we do in the unlikely event that these Angus> calls fail? Post a warning or terminate? Maybe terminate. This way we'll see people complain and we'll have an occasion to investigate... JMarc
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Do we need an os_mac.C? Well, that's difficult to do. Currently (besides the bundle hack you noticed) all the special mac support is in frontends/qt2 conditioned on Q_WS_MACX. This is because it is not possible outside of the frontend to ascertain whether we want to build LyX/Mac or LyX/Unix when we are under darwin. I think this is not a matter of os, but of packaging. I propose (maybe in the long term) to have a --with-packaging option (any better term is welcome) that can be either osx, win32 or unix and that this option control a package:: namespace where the code from path_defines is put (in three different versions probably). Also, this --with-packaging option will be able to set the various Makefile variables correctly. This packaging thing would set up lyxdir, userdir, localedir, document dir and things like that according to the platforms conventions. We can either do this now for 1.4.0cvs or replace temporarily with a hack. For 1.3.6cvs, the hack is probably a better idea. JMarc
Re: LFUN_MATH_MODE
Andre Poenitz wrote: >> I see. There is also a check for the argument "on" in math_nestinset.C. I >> guess André forgot to check for that argument in other places (text3.C et >> al.). > > Indeed. Would be nice if you could fix that. If you tell me how to handle the argument. Is it that the user can write both "math-mode on " and "math-mode "? I.e., do we have one argument or more? And do what in mathed/ needs fixing? Jürgen
Re: [PATCH 13x, 14x] starting LyX successfully under Windows.
Jean-Marc Lasgouttes wrote: This packaging thing would set up lyxdir, userdir, localedir, document dir and things like that according to the platforms conventions. We can either do this now for 1.4.0cvs or replace temporarily with a hack. Let's do it properly now. For 1.3.6cvs, the hack is probably a better idea. Agreed.
Re: My Documents et al --- success
Jean-Marc Lasgouttes wrote:
Angus> It turns out that Jürgen's suggested way to ascertain the
Angus> different Windows folders is straightforward to implement. No
Angus> need to use the .net framework; it all exists in the standard
Angus> WinAPI.
Yes, that's not a big surprise :)
Angus> Question. What should we do in the unlikely event that these
Angus> calls fail? Post a warning or terminate?
Maybe terminate. This way we'll see people complain and we'll have an
occasion to investigate...
Ok, then here's the proposal. Add to class (13x)/namespace(14x) os the
following functions that are set in os::init(int argc, char argv[]):
// The OS-dependent directory to which an application's
// system-wide data directory should generally be added.
string const & os::system_appdir() {
// returns COMMON_APPDATA folder on Windows
// returns ??? on MacOS
// returns an empty string on Unix
}
// The OS-dependent directory to which an application's
// user-specific data directory should generally be added.
string const & os::user_appdir() {
// returns APPDATA folder on Windows
// returns ??? on MacOS
// returns $HOME on Unix
}
// The OS-dependent directory to which a user's
// documents should generally be added.
string const & os::document_dir() {
// returns PERSONAL folder on Windows
// returns ??? on MacOS
// returns $HOME on Unix
}
Then use these in lyx_main.C's LyX::init() (13x) or in path_defines.C's
setLyxPaths() (14x) to help set system_lyxdir, user_lyxdir and in
lyxrc.C's constructor to set the default lyxrc::document_path.
Thoughts?
Angus
Baffled by the reasoning
Why do we search for the system_lyxdir as // Path of binary/../share/name of binary/ but the user_lyxdir as // os::homepath() "/." + PACKAGE where PACKAGE is defined in config.h as (here) "lyx-1.3.6cvs". Why don't we use PACKAGE for the system_lyxdir too? Angus
Re: My Documents et al --- success
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> // The OS-dependent directory to which an application's
Angus> // system-wide data directory should generally be added.
Angus> string const & os::system_appdir() {
Angus> // returns COMMON_APPDATA folder on Windows
On windows, I believe the right place to have the data directory is
the directory where the binary lives. There may even be an API
function to get this value directly.
Angus> // returns ??? on MacOS
There is also an API for that. See:
http://doc.trolltech.com/3.3/mac-differences.html#7-1
Angus> // returns an empty string on Unix
I think this one should contain the code that lives in path_defines
for now (with the stuff that follows symlinks)
Angus> }
Angus> // The OS-dependent directory to which an application's
Angus> // user-specific data directory should generally be added.
Angus> string const & os::user_appdir() {
Angus> // returns APPDATA folder on Windows
Or should it be APPDATA/LyX/ ?
Angus> // returns ??? on MacOS
Currently this is ${HOME}/Library/Preferences/LyX
Angus> // returns $HOME on Unix
Or return ${HOME}/.PACKAGE
Angus> }
Angus> // The OS-dependent directory to which a user's
Angus> // documents should generally be added.
Angus> string const & os::document_dir() {
Angus> // returns PERSONAL folder on Windows
Yes.
Angus> // returns ??? on MacOS
I think it's HOME
Angus> // returns $HOME on Unix
Angus> }
You forgot the locale directory.
Angus> Then use these in lyx_main.C's LyX::init() (13x) or in
Angus> path_defines.C's setLyxPaths() (14x) to help set system_lyxdir,
Angus> user_lyxdir and in lyxrc.C's constructor to set the default
Angus> lyxrc::document_path.
I think we should reimplement setLyXPaths for each of these cases. It
will be much simpler.
Then there will be the special case of build directory to enable
running in place. This one may be trickier.
JMarc
Re: Baffled by the reasoning
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Why do we search for the system_lyxdir as // Path of Angus> binary/../share/name of binary/ but the user_lyxdir as // Angus> os::homepath() "/." + PACKAGE Angus> where PACKAGE is defined in config.h as (here) "lyx-1.3.6cvs". Angus> Why don't we use PACKAGE for the system_lyxdir too? The algorithm that searches for the system_lyxdir is probably too complicated for its own good :) The idea was to allow to cinstall several versions of LyX concurrently without having to recomplie them (just with a couple of symlink). I think that reverting to just use PACKAGE instead of the name of the binary would prove simpler. JMarc
Re: Configure problems for lyx-140 on Mac
Lars Gullik BjÃnnes <[EMAIL PROTECTED]> writes: > > Andreas Vox <[EMAIL PROTECTED]> writes: > > > | 1 - change include order (if possible) > > might work. Where is this ctype included from? Our code or library > code? ./configure does not include directly, I traced it back to ctype.h <- cctype <-iosfwd <- ios, string, streambuf, bits/stl_algobase.h > > Does using working better? includes I guess is the best place to correct this problem, cctype already has a section for Mac where they #undef the isalpha() Macros and the like. > > | 2 - undef _D and _R after ctype.h was included > > ugly bugly But it seems to work (I only tested the file created by ./configure), if you put something like #include #undef _R #undef _D in front of the other includes. Is there a canonical place for LyX where we could put this? So I can test if it breaks anything else? /Andreas
Re: Configure problems for lyx-140 on Mac
Andreas Vox <[EMAIL PROTECTED]> writes: | ./configure does not include directly, I traced it back to | ctype.h <- cctype <-iosfwd <- ios, string, streambuf, bits/stl_algobase.h > >> >> Does using working better? > | includes | I guess is the best place to correct this problem, cctype already | has a section for Mac where they #undef the isalpha() Macros and the like. So this should absolutely be reported to apple. Then they can fix it. >> >> | 2 - undef _D and _R after ctype.h was included >> >> ugly bugly > | But it seems to work (I only tested the file created by ./configure), if you | put something like > | #include | #undef _R | #undef _D > | in front of the other includes. Sure it will work... but then why not just comment out the "backwards compability" stuff in ctype.h? | Is there a canonical place for LyX where we could put this? | So I can test if it breaks anything else? Not really... Only if you do it in config.h, making ctype.h being included in all files. -- Lgb
[PATCH] fix pch.h in frontends/qt2/ui
I installed a brand new Mandrake 10.1 on my laptop and thus was able to test precompiled headers support (gcc 3.4.1). The result is that I need the following patch. I do not like it much, I did not like the original code either. JMarc Index: src/frontends/qt2/ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ChangeLog,v retrieving revision 1.739 diff -u -p -r1.739 ChangeLog --- src/frontends/qt2/ChangeLog 20 Dec 2004 16:59:32 - 1.739 +++ src/frontends/qt2/ChangeLog 21 Dec 2004 16:20:28 - @@ -1,3 +1,8 @@ +2004-12-21 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> + + * ui/Makefile.am (%.C): make sure to remove the .pch file from the + uic command line. + 2004-12-19 Angus Leeming <[EMAIL PROTECTED]> * lyx_gui.C (start): s/slashify_path/internal_path/ Index: src/frontends/qt2/ui/Makefile.am === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ui/Makefile.am,v retrieving revision 1.27 diff -u -p -r1.27 Makefile.am --- src/frontends/qt2/ui/Makefile.am 4 Dec 2004 14:50:24 - 1.27 +++ src/frontends/qt2/ui/Makefile.am 21 Dec 2004 16:20:28 - @@ -30,4 +30,4 @@ UICFLAGS=-tr qt_ %.h: %.ui $(UIC) $(UICFLAGS) $< -o $@ %.C: %.h %.ui $(PCH_FILE) - $(UIC) $(UICFLAGS) -impl `echo $^ | sed 's/pch.h.gch//'` -o $@ + $(UIC) $(UICFLAGS) -impl `echo $^ | sed 's/[^ ]*pch.h.gch//'` -o $@
Re: [PATCH] fix pch.h in frontends/qt2/ui
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I installed a brand new Mandrake 10.1 on my laptop and thus was able | to test precompiled headers support (gcc 3.4.1). The result is that I | need the following patch. > | I do not like it much, I did not like the original code either. Any better suggestions? -- Lgb
Re: [PATCH] fix pch.h in frontends/qt2/ui
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I installed a brand new Mandrake 10.1 on my laptop and thus was able | to test precompiled headers support (gcc 3.4.1). The result is that I | need the following patch. > | I do not like it much, I did not like the original code either. > I don't get why this is needed? Can you explain a bit? Hmm... gcc 3.4.1 is old.. -- Lgb
Re: [PATCH] fix pch.h in frontends/qt2/ui
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I Lars> installed a brand new Mandrake 10.1 on my laptop and thus was Lars> able | to test precompiled headers support (gcc 3.4.1). The Lars> result is that I | need the following patch. >> Lars> | I do not like it much, I did not like the original code Lars> either. Lars> Any better suggestions? Not really. Does the .C file really depend on PCH_FILE? JMarc
Re: [PATCH] fix pch.h in frontends/qt2/ui
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> I don't get why this is needed? Can you explain a bit? I do not have my laptop at hand, but the path to the pch file is passed to uic (only the naked file name is removed), and uic complains that it has an extra argument. Sorry for not being more specific, I am not typing from my laptop now. Lars> Hmm... gcc 3.4.1 is old.. I knew this was coming... JMarc
Re: [PATCH] fix pch.h in frontends/qt2/ui
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Lars> Hmm... gcc 3.4.1 is old.. Jean-Marc> I knew this was coming... Note also that gcc is absolutely not run in this case. You should rather complain about the version number of my qt, make or even sed ;) JMarc
