> > Juergen> I think we should decide if we want the logic in the core or
> > Juergen> in the frontends. I'd vote for the frontend simply because of
> > Juergen> transparency to the users (disabling/enabling widgets etc.)
> > Juergen> and because the frontends have different means to handle the
> > Juergen> logic.
> >
> > I do not understand how this changes transparency for the users? Could
> > you explain what the difference would be?
>
> Before 1.2 (I think) the logic of paperpackages vs. papersize was
> completely handled by the core. There were two choices in the dialog:
> Papersize and "Special (A4 portrait only)" (i.e. paperpackages). It was
> possible to chose e.g. A5 and "Extra wide Margins", but this was reset to
> A4/Extra wide margins by bufferparams. So errors were corrected, but the
> user was not informed about this.
> In the 1.2 development cycle, we have decided to give some visual clues in
> the dialog. When an input does not make sense, it should not be allowed,
> when a widget does not make sense, it should be disabled (greyed out).
[...]
What about literally refactorizing the code, and putting common stuff in the
core while retaining the functionality? Something like
- let the core do all package-depedent checks
- the core then returns a functionality set (flags) to the frontend
- the frontend diasables/enables widgets per functionality set (bitmapped
flags) and also indicated invalid entries per some more flags
I believe that would be the cleanest approach. A function like this would
reside in the core
// core
typedef enum { EnablePaperSize=1, EnableLandscape=2, ..., } flags_t;
flags_t Core::DigestPaperSizes(setting1, setting2, ...)
setting(i) is the setting from the UI, whatever.
Does this make any sense at all?
I presume it's much easier to maintain output-dependent (latex dependent!)
logic in one place, rather than in the core *and* in both frontends, right?
Cheers, Kuba Ober
