Richard Heck wrote:
Abdelrazak Younes wrote:
I've found the real issue here. Suppose the dialog is open and the
user clicks in a new paragraph. Then update_contents() is called by
QView::update, which is called by Dialog::checkStatus, as well it
should be. But nowhere along the way has initaliseParams() been
called again, so the dialog gets updated on the basis of the original
paragraph's parameters. This seems as if it could be quite a general
problem. Should initParams() be called in QView::update()?
No. What you should do is just transfer the relevant code in
initParams() to update_contents(). Not all dialogs needs to be
re-initialised on each key-stroke. But I am wondering if this is
really the problem because I've read in Bugzilla that the former
frontends (xform and gtk) manage to do this without changing the
controller...
The patch is attached. I've pretty much got something like this working,
by putting a call to initParams() at the beginning of update_contents().
This is less easy than it might be, since initParams() wants a string
representing the paragraph parameters, and that string, for the new
paragraph, isn't readily available. I got it something like:
kernel().bufferview()->cursor().paragraph().params()
and then passing that to params2string. That seemed very messy, and I'm
hoping there's something simpler.
There is: just create a helper method in ControlParagraph that will
nicely encapsulate the kernel call for the benefit of the dialog. As I
said, you don't really want to call initParams() in there.
It also occurred to me we should
probably cache the params and only call initaliseParams() when they
change, since that looks kind of expensive.
You have the option to use a boost signal to do that: emit the signal
when the change occur. The signal should be connected to the controller.
But in this case I am sure we will find a simpler solution. I am sorry
to say that your patch looks a bit complicated for the problem we have
at hand. The reason is probably that the GUII framework is very
complicated to understand and I remember scratching my head a number of
time for the simplest problem ;-)
So, what do we need? How many choice do we need for the alignment? I'd
say 4:
case LYX_ALIGN_BLOCK: return "Justified";
case LYX_ALIGN_LEFT: return "Left";
case LYX_ALIGN_RIGHT: return "Right";
case LYX_ALIGN_CENTER: return "Center";
I think we'd better served by 4 radio buttons instead of a Combo.
Then we need to take into account the "Default" case.
case LYX_ALIGN_LAYOUT: return "Default";
Here a simple check box will do.
Then a more complicated one:
case LYX_ALIGN_NONE: return "None";
Am I right in that no modification is allowed here? I yes, then no
choice should be permitted and the controls above should be disabled.
This one I don't understand:
case LYX_ALIGN_SPECIAL: return "Special";
I am going to give you some comments in the code below even though I am
sure we are going to take this road:
Index: frontends/qt4/QParagraph.C
===================================================================
+ const int index = dialog_->align->currentIndex();
int const
I know, it's weird but that's our convention so please stick to it.
+
+ //We now both populate the combo box and build an array of acceptable
+ //alignments which we can use elsewhere.
+ //The first one is the default.
+ const QString defaultString =
+ qt_(controller().lyxAlignmentAsString(LYX_ALIGN_LAYOUT)) + " ("
QString const
Index: frontends/qt4/QParagraph.h
===================================================================
private:
/// Apply changes
virtual void apply();
@@ -35,6 +39,19 @@
virtual void update_contents();
/// build the dialog
virtual void build_dialog();
+ /// Possible alignments for last paragraph
+ LyXAlignment cached_possible_;
+ /// Total number of possible alignments
+ const int numPossibleAlignments_;
+ /// Array of alignments allowed in the current paragraph
+ LyXAlignment * activeAlignments;
+ /// number of alignments allowed
+ int numActiveAlignments_;
+ /// updates the alignment combo when the allowed
+ /// alignments have changed
+ /// @c return Returns true if the combo was updated
+ bool updateAlignmentCombo();
First the method definitions then the member data.
Index: frontends/controllers/ControlParagraph.C
===================================================================
+string ControlParagraph::lyxAlignmentAsString(const LyXAlignment align)
LyXAlignment const
Index: frontends/controllers/ControlParagraph.h
===================================================================
--- frontends/controllers/ControlParagraph.h (revision 17755)
+++ frontends/controllers/ControlParagraph.h (working copy)
@@ -15,6 +15,8 @@
#include "Dialog.h"
#include "layout.h" // for LyXAlignment
+using std::string;
+
namespace lyx {
class ParagraphParameters;
@@ -43,6 +45,13 @@
LyXAlignment alignPossible() const;
///
LyXAlignment alignDefault() const;
+ ///
+ string lyxAlignmentAsString(const LyXAlignment align);
+ ///
+ static const int numPossibleAlignments = 5;
+ ///
+ static const LyXAlignment possibleAlignments[numPossibleAlignments];
Why static?
+
private:
///
