On Wed, Oct 27, 2010 at 06:34:22AM +0200, Vincent van Ravesteijn wrote:
> >> I did something like this for Buffer::loadLyxFile(). Where would you
> >> advice to put the UI then ? I can now spit out a lot of error messages
> >> according to the number the functions comes up with. In Buffer ? In
> >> buffer_funcs ? In GuiView ?
> >
> > Any direct user interaction in src/frontends/*,
>
> I don't want to put all the error messages in frontends/*. If you have
> another gui, you don't want to implement all the error messages all
> over again, so these need to be in src/ somewhere.
I don't comment on "Another gui" for the sake of my mental health.
Note that I did not say "error messages" but "user interaction".
Of course the/a gui can pull static/localized strings from the core
if it wishes. But the decision on how to proceed after the message
has been shown belongs into the gui.
> I think the best is to put them for e.g. in Buffer, so that it is
> easier for maintenance (close to the location where the error is
> reported).
The error _is_ reported in the Gui. Adding a new user visible string
is certainly _more_ effort this way.
> Do I need a Buffer::errorMessage(int n) function ? Or maybe
> src/ErrorMessage.cpp that stores all errormessages for the whole LyX
> project.
Reminds me of the old days, when programs produced numbers instead
of "real error messages" and the user had to look them up in the
manual ;-)
> > worker methods that can run unattended, possibly
> > bailing out on error in src/{!frontend}.
>
> That was the idea. Returning some enum-value that would tell the
> caller of the function exactly what happened. Next problem is how to
> handle the user interaction part. How can we continue where we bailed
> out to ask the user something ?
>
>
> > If errors are non-fatal they could be accumulated and returned
>
> Hmm, do we already have some accumulation design in LyX ?
>
> I wrote something for Buffer::save:
>
> enum WriteStatus {
> WriteSuccess,
> WriteFailure,
> WriteDiskFull,
> [..etc..]
> }
>
> struct WriteStatusW
> {
> WriteStatus backup;
> WriteStatus write;
> }
>
> Buffer:WriteStatusW Buffer::save()
> {
> WriteStatusW status;
>
> status.backup = makeBackup(file...);
> status.write = writeFile(file...);
>
> if (status.write != WriteSuccess) {
> if (status.backup == WriteSuccess)
> restoreBackup(file....);
> }
> return status;
> }
>
> To tell the gui whether the write was succesfull or why we bailed out
> and if we have stored/restored/removed.. the backup file.
>
> > or signalled individually to the gui using a signaling mechanism that does
> > _not_
> > require the existence of an "observer" (gui or lyxserver)
>
> What does this mean in english ? Not to use the
> buffer->workareamanager->workarea->guiworkarea connection ?
Exactly.
> Using Qt signals ? Using boost ? sending an LFUN :S ?
Signals from the core to the gui. For some reason I think using _Qt_
signals would make most sense.
Andre'
