Menu
▾
▴
#23 improve GUI error/warning output
Make xdvi output *all* information on its current
status to a window. It should be possible to use xdvik
without seeing stderr (e.g. when launching it from a
Desktop) and still always know what's going on. (The
only message still printed to stderr should be `can't
open display' if X is not running at all).
Some people mainly using the command-line might also
want this as an option (e.g. think of the `no such file
or directory' messages - one would probably not want to
construct the full-fledged window hierarchy for that).
Also, care needs to be taken that the messages don't
become distracting (maybe the `logbook'-thingie from
YAP, which basically consists in collecting all output
to stderr to a window, is a good way to do this).
Logged In: YES
user_id=177175
Migrated from #51876 here:
- make sure to use xdvi_exit(status) always, instead
of exit(status). (Maybe xdvi_exit() could also take
the error message as additional argument.) By the
same token, make sure that xdvi_exit() can be used
for *all* exits, by having the invoked routines
make sure themselves whether they can be run or not.
Logged In: YES
user_id=177175
On a related note: some messages such as verbose output of
font generation, dvips generation, but also warnings about
missing fonts that might scroll by fast, should be saved to
some kind of logging facility. Also all statusline messages
should be saved there. This log buffer would be an internal
ring buffer of configurable size (default: 1000 lines?) that
can be displayed in a popup window from some `View log'
menu, similar to the `logbook' in YAP. (For privacy reasons,
it's better not to use a file for this by default, but there
should be a button for saving it to a file. See the GUI page
for a spec.)
Logged In: YES
user_id=635642
Just one idea related to that: always bring up a
window when xdvi was launched, even if it is not
yet ready to display a file.
When pk fonts are generated in the background,
xdvi does not provide any visual feedback. Simply
mapping an empty window would send the
message 'xdvi was launched succesfully' to a
user that doesn't look at stderr.
BTW: why not post short messages on the status
line? This way they are unobtrusive since one
doesn't need to close any windows that pop up.
Logged In: YES
user_id=177175
> Just one idea related to that: always bring up a
> window when xdvi was launched, even if it is not
> yet ready to display a file.
>
> When pk fonts are generated in the background,
> xdvi does not provide any visual feedback. Simply
> mapping an empty window would send the
> message 'xdvi was launched succesfully' to a
> user that doesn't look at stderr.
Full ACK.
The problem is however that it's not easy to implement,
since the current program flow is:
1. open file
2. process postamble with the font definitions
3. generate PK fonts if needed
4. open window
Obviously (4) would need to come before (1), but for that
lots of internals need to be changed. (Another good thing
would be to process the fonts not in one huge bunch at the
beginning, but rather on demand, or when the application
is idle; I also mentioned that in feature request #599596,
but it's actually more related to this one).
Currently the PKs seem to be generated `on demand' only
for the VF fonts (i.e. mostly ps2pk invocations).
I think however that the problem is alleviated by the
fact that with T1lib xdvik should hardly ever need to
generate PKs at all for `most' DVI files.
> BTW: why not post short messages on the status
> line? This way they are unobtrusive since one
> doesn't need to close any windows that pop up.
Yup, that's what we should do for one-line messages.
(There's a comment `Suggested Policy for using the GUI
messages' in message-window.c that recommends to always
prefer the statusline for these); and I think the current
messages all stick to that policy (or don't they?)
One problem left is that the kpathsea font searching
libraries are not really up to that advanced interaction:
You can only tell them to load a font, and they will invoke
mktexpk dynamically if the font doesn't exist, so you don't
know in advance whether you'll need to display a status
message. Maybe one should set up a timer to deal with that.
So it's nothing that one could easily implement in a few
hours, and I think we'll only be able to tackle that after
22.6x.
Logged In: YES
user_id=177175
FWIW, what I wrote above with the steps 1. - 4. was quite
an oversimplification ;-) My current (still rather rough
view) of how the steps *could* be is as follows:
1. Check for --help or --version options; if present, print
msg to stderr and exit.
2. Check for existance of DVI file; if it doesn't exist,
I'm not sure whether we always want to print a msg to
stderr or whether sometimes a window would be needed as
well. (If the latter, we might want to make it a minimal
top-level window on its own)
3. Start talking to the X server : XtInitialize(),
XtAddActions().
4. Perform checks for forward search, and set property and
exit iff another instance is already running with that
DVI file. This requires (2) and (3).
5. Initialize resources: mfmode, shrinkfactor.
6. Initialize PS communication.
7. settle colormap issues (`Step 2' in xdvi.c).
8. Set title and icon name, but *don't* call init_dvi_file();
have some other way of getting page info from the DVI file.
9. Set window size, create widgets.
10. Map the toplevel window.
11. Init_t1(), and only *now* call init_dvi_file() (an
advanced version of that which doesn't use the postamble
to define fonts).
Now all error messages from these can go into the window.
12. Enter event loop.
Actually I think it would be nice if main() consisted
only of a bunch of functions, suitably named, that
implemented these steps.
Logged In: YES
user_id=635642
>> BTW: why not post short messages on the
>> status line? This way they are unobtrusive
>> since one doesn't need to close any windows
>> that pop up.
> Yup, that's what we should do for one-line
> messages.
> One problem left is that the kpathsea font
> searching libraries are not really up to
> that advanced interaction: You can only tell
> them to load a font, and they will invoke
> mktexpk dynamically if the font doesn't
> exist, so you don't know in advance whether
> you'll need to display a status message.
> Maybe one should set up a timer to deal with
> that.
My original idea was in fact much more
simple-minded. As a user, I would merely
expect xdvi to give a concise description of
what it does when it is busy and not
accepting user input. It might post a
message like "Loading fonts, please wait" on
the stats line, and "Fonts loaded" when it's
done.
In fact I wouldn't even want to be bothered
with detailed log-style messages for
everything going on in the background! This
would rather cause confusion. The messages
that go to stderr are not something I check during
regular use either; and for debugging, one could
still launch xdvi from a terminal and look at the
verbose messages.
Maybe this 'division of labor' between the GUI and
stderr could simplify the implementation?
Logged In: YES
user_id=177175
> My original idea was in fact much more
> simple-minded. As a user, I would merely
> expect xdvi to give a concise description of
> what it does when it is busy and not
> accepting user input. It might post a
> message like "Loading fonts, please wait" on
> the stats line, and "Fonts loaded" when it's
> done.
Indeed, that sounds like a good idea. Needless
detail is always a bad thing. (Example at hand:
the `scanning page n of m' messages in non-k
xdvi, for which there's even a popup window, even
though the process just takes a few milliseconds).
> In fact I wouldn't even want to be bothered
> with detailed log-style messages for
> everything going on in the background! This
> would rather cause confusion.
The reasoning was that if a font creation command
fails, it might be useful to have a warning message
with a button `view logs' that would popup a window
with such details; however:
> The messages
> that go to stderr are not something I check during
> regular use either; and for debugging, one could
> still launch xdvi from a terminal and look at the
> verbose messages.
... that's true; an X version of the log would merely
be a convenience. It's more one of those features
that one adds when there's nothing else left to do
(and we're a far cry from that ;-)