| |
| |
Implementing resume() is easy as it is a method of the
printer class. Both functions are one-liners that will be
inlined by the compiler, so they really only are a shortcut in
the header.
I am still torn if it should be push(screen)/pop() or
pop()/push(printer). If the pushed context is a another surface,
the second solution would be wrong.
That depends on the definition of right or wrong or, to be clear,
the definition of the method. In my mind suspend() would return to
the state before the printing began (i.e. pop()) and the following
resume(), i.e. push() would switch back to the printer context.
What you suppose - i.e. first push(screen) - would unconditionally
push the screen context as the active surface which is exactly what
you need, as you describe it, but this would not be a general
solution IMHO.
So
Fl_Printer::suspend() {
Fl_Surface_Device::push_current(Fl_Display_Device::display_device());
}
Fl_Printer::resume() {
Fl_Surface_Device::pop_current(); }
are a good solution IMHO to hide the surface handling if a
user absolutely must call Fl::wait() for
some reason.
So, yes, that would be Manolo's suggestion.
I'm not convinced that this is the best solution though. IMHO
suspend() should definitely *return* to the previous condition
before printing started and not add yet another context to the
stack.
When the user calls Fl_Printer::suspend()
we must (and can) assume that the printer context is active and Fl_Printer::resume() can always push()
the printer context and thus make it active.
What I want to say is that suspend means in my understanding to
return to the previous state and not to switch to a new state. If we
used a different method instead of Fl_Printer::suspend(),
maybe Fl_Surface_Device::push_display() that would be clear, and a
following Fl_Surface_Device::pop_current() would resume printing.
It's difficult to express why I think that "suspend" should not
"push the display" context. I hope you get it. Somehow.
BTW: Matt, what you try to do would work with either way, so this is
not the problem.
Thanks all for looking into this!
Albrecht Schlosser schrieb am
Montag, 13. Juni 2022 um 18:23:56 UTC+2:
On
6/12/22 13:40 'melcher....@...' via fltk.coredev wrote:
As Manolo wrote, adding
Fl_Surface_Device::push_current(Fl_Display_Device::display_device());
before Fl::wait(); and
Fl_Surface_Device::pop_current();
after Fl::wait(); would work.
So,
to answer the "other" question: if we added such new methods
I'd
suggest to `pop` the drawing context in `suspend()` and `push`
the
printer context in `resume()`. This would make these methods
independent
of the "previous" context - which would be very likely but
not
necessarily the "display" context.
I have no idea how to implement such a `resume()` method that
would push
the pre-existing printer context back on the stack but I guess
Manolo
would know?
--
You received this message because you are subscribed to the Google
Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it,
send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/8100ce56-1e09-472f-bde5-9bb4ea5f81a4n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups "fltk.coredev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkcoredev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkcoredev/48ed868c-e5bc-b27f-143d-862055c1dba9%40online.de.
[ Direct Link to Message ] | |
|
| |
