Georg Baum wrote:
>> If I may misquote our UI guru (let's call him John L.), "modal dialogs
>> suck". Apparently. John can probably provide references to appropriately
>> important web pages to back up my (mis)quoting.
>
> OK, but LyX does not seem to be ready to use non-modal inset dialogs. In
> this case, one would expect that the label dialog becomes inactive as
> long as the cursor is in the ert inset.
> It would be nice if somebody who knows the frontend stuff could have a
> look at this. If nobody knows how to do this I would like to go back to
> modal dialogs.
Conceptually, doing so is easy. We just need to tell the Dialog that the
buffer has become readOnly, no? That way, the OK and Apply buttons will be
disabled.
Here's an unchecked implementation of the idea. Frontend only. No hooks
from the core. However, I'm sure that you'll be able to turn this into
working code ;-)
We need a member function in frontends/Dialogs.[Ch] that is called when the
cursor is moved somewhere illegal. Eg
class Dialogs {
public:
void enable(string const & dialog_name, bool enable_it) const {
if (!visible(dialog_name))
return;
std::map<string, DialogPtr>::const_iterator it =
dialogs_.find(name);
// Paranoia check.
if (it == dialogs_.end())
return;
it->enable(enable_it);
}
bool is_enabled(string const & dialog_name) const {
if (!visible(dialog_name))
return false;
std::map<string, DialogPtr>::const_iterator it =
dialogs_.find(name);
// Paranoia check.
if (it == dialogs_.end())
return false;
return it->is_enabled();
}
};
These member functions would invoke similarly named functions in
frontends/controllers/Dialog.[Ch]:
class Dialog {
public:
Dialog() : enabled_ = true {}
void enable(bool enable_it) {
if (enabled == enabled_)
return;
enabled_ = enabled;
bc().readOnly(!enabled_);
}
bool is_enabled() const { return enabled_; }
private:
bool enabled_;
};
In fact, we could probably dispense with the Dialog::enabled_ member
variable if the ButtonController would tell us what the current read-only
status was...
--
Angus
