From: Kenneth J.Davis (email@example.com)
Date: Sun May 12 2002 - 06:42:19 EDT
Patrick Lam <firstname.lastname@example.org> wrote on 5/12/2002 2:08:45 AM:
>I think that this should work; the main logic is now in ap_App instead
>of platform-specific code, with callbacks as appropriate.
Yes but this 'XP' code assumes that stdout is a valid location to
display information, which simply isn't so on Windows.
I have been looking into adjusting the Windows command line processing
to match the other platforms (it currently uses a hybrid of popt and the
old command line processing, so basically it doesn't really work correctly)
and the more I do so, the more I think popt is inappropriate for it;
not impossible to use, just it is an overly Unix biased library.
As I mentioned above, popt and the new command line processing code assumes
that stdout actually sends the output to a user visible location (at least
when ran from a console). This, by default, is not true on Windows. While
stdin/stdout/stderr are available, GUI applications are not attached to a
console so the output can only be read by other programs and otherwise will
never be displayed [even if you start AbiWord from a console].
You can fairly easily reopen stdin/stdout/stderr and attach them to
STDIN/STDOUT/STDERR of a console; however I am not sure of any reliable
method (not one doesn't exist, just I'm not sure offhand) to determine
if the calling program was a console and if so attach to it. Of course
if AbiWord was called from a GUI program then a new console could be
created or we can assume there is no reason to display the output. If
a new console must be created, I see no way to know ahead of time to
determine if we actually write to the console, so one must always
be created, which just produces annoying behaviour; and any which way the
console window will be closed almost immediately after the version, help,
or whatever information is printed and AbiWord exits.
The previous behavior was for AbiWord to open a MessageBox to display
the appropriate information. This to me seems the proper thing for a
Windows GUI application to do, but I have no idea how best to implement
this given the new command line processing framework.
So my question is how best to proceed:
a) falsely assume Windows users don't use consoles and ignore that we no
longer display information such as help
b) if AbiWord was spawned from a console, see if it is possible to attach
to it [as in, can another process attach to a parent console, and if
so, is there a reliable way to find the parent process and determine if
it is a console app or not], and if not ignore that the output isn't seen
c) if AbiWord was spawned from a console, see if it is possible to attach
to it, and if not create a new console to display the output
d) always create a new console and let information written to stdout be
e) rework the cmdline processing framework and popt library so we can
get the strings and display them to a MessageBox
f) bypass the new cmdline processing framework, ie revert Windows code
back to the old approach, or at least conditionally skip the new popt
g) something else (hopefully better than any of my suggestions), perhaps
someone already has a [almost] working solution and I am wasting my time.
I think b (maybe c) or e are the best options, but I am not sure b (c) is
possible nor am I convinced e is worth the trouble.
d is what I currently have implemented (which is very annoying and somewhat useless).
I doubt other developers want f, otherwise the changes wouldn't have been
made that broke command line processing [on Windows].
a is simply bad.
g of course is unknown to me, but I'm hoping for enlightenment! :-)
I think the one Windows specific argument can go away (specifying the
filetype on the cmd line) given the much improved autodetection, and I
think the changes so subsequent windows use the stored Window size means
the code to set the initial window size is actually redundant (thus safely
removed). I.e. if the XP code can adequately display the 'windowless'
output, then the rest of the cmdline refactoring should be fine on Windows.
Thanks for taking the time to read this (and maybe responding to correct me).
Hoping I have overlooked something so this is really not an issue,
This archive was generated by hypermail 2.1.4 : Sun May 12 2002 - 08:04:12 EDT