Re: Help request: QController and QView
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> But from an architecture point of view, IMHO, the kernel Abdelrazak> should not know at all about how the frontend is doing the Abdelrazak> action. This is a too big job to restructure it so I guess Abdelrazak> we have to live with that. For the sidebar I agree. For the other examples (putting the citations in the menus seems awful to me :), I'd have to see. This was just an example to explain the possibilities. For citations, the ultimate solution is a context menu at the keyboard cursor location with find as type feature. If you want to modify its style you can still click on the just generated inset and you will get the full blown Citation dialog. Abdel.
Re: Help request: QController and QView
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> But from an architecture point of view, IMHO, the kernel Abdelrazak> should not know at all about how the frontend is doing the Abdelrazak> action. This is a too big job to restructure it so I guess Abdelrazak> we have to live with that. For the sidebar I agree. For the other examples (putting the citations in the menus seems awful to me :), I'd have to see. JMarc
Re: Help request: QController and QView
Jean-Marc Lasgouttes a écrit : "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Indeed, the idea would be to allow current GUIs to diverge Abdelrazak> (for the better). Allowing GUIs to diverge is of course OK. The only limit is to try to keep the documentors and translators work not too difficult and to avoid to turn this into a competition between the frontends authors. Generally, really good ideas can be resused in other frontends. Hopefully there would be not much to document as I aim for simplified dialog. I guess we can also reuse already translated strings. Abdelrazak> Another example is the TOC who can be either a dialog or a Abdelrazak> docked widget for outlining. Separating the model from the Abdelrazak> view will make the creation of a new view very cheap. Having all the navigating dialogs (ToCs, errors, labels) as docked widgets (sidebars) would be very nice. I do not see however how the current scheme prevents from doing that. You just have to implement something and say "sure, I am a dialog"; the GUI-I part does not care, does it? I guess so, I just have to sit down and take a pen and a paper to see how all this can be done. As I said in a previous mail to Edwin, I hope the change can be localized inside the qt4 frontend. Just need time... But from an architecture point of view, IMHO, the kernel should not know at all about how the frontend is doing the action. This is a too big job to restructure it so I guess we have to live with that. Abdel.
Re: Help request: QController and QView
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes: Abdelrazak> Indeed, the idea would be to allow current GUIs to diverge Abdelrazak> (for the better). Allowing GUIs to diverge is of course OK. The only limit is to try to keep the documentors and translators work not too difficult and to avoid to turn this into a competition between the frontends authors. Generally, really good ideas can be resused in other frontends. Abdelrazak> My goal is to split current GUI into model/view so that a Abdelrazak> functionality can have diverse form. For example, adding a Abdelrazak> citation could be done via a Dialog, a menu or a combo Abdelrazak> box; but all views will share the same model. Intriguing. Abdelrazak> Another example is the TOC who can be either a dialog or a Abdelrazak> docked widget for outlining. Separating the model from the Abdelrazak> view will make the creation of a new view very cheap. Having all the navigating dialogs (ToCs, errors, labels) as docked widgets (sidebars) would be very nice. I do not see however how the current scheme prevents from doing that. You just have to implement something and say "sure, I am a dialog"; the GUI-I part does not care, does it? JMarc
Re: Help request: QController and QView
Edwin Leuven a écrit :
i will have a look at what you've done with the citation dialog. my time
is a bit thin (as are my programming skills) so it won't go at the speed
of light though...
Any help is welcome :-)
I am not sure about the correct architecture. Right now, the link to the
kernel is done in frontends/qt4/Dialogs.C :
} else if (name == "citation") {
dialog->setController(new ControlCitation(*dialog));
dialog->setView(new QCitation(*dialog));
dialog->bc().bp(new NoRepeatedApplyReadOnlyPolicy);
Maybe the solution is just to replace that with:
} else if (name == "citation") {
dialog->setController(new ControlCitation(*dialog));
dialog->setView(new QCitationDialog(*dialog));
dialog->bc().bp(new NoRepeatedApplyReadOnlyPolicy);
In this scheme, QCitationDialog would inherit Dialog::View directly.
QCitationDialog would use a new QCitationModel (containing the model
currently in QCitation). This QCitationModel could be reused for another
func_request:
} else if (name == "inline_citation") {
dialog->setController(new ControlCitation(*dialog));
dialog->setView(new QCitationInline(*dialog));
dialog->bc().bp();
QCitationInline would be a context menu at the keyboard cursor location
that would be invoked by some keyboard shortcut.
But I am not sure this would work with the current Dialog class definition.
Abdel.
Re: Help request: QController and QView
i will have a look at what you've done with the citation dialog. my time is a bit thin (as are my programming skills) so it won't go at the speed of light though... edwin Abdelrazak Younes wrote: Angus Leeming a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: Please don't take this all personally, I don't. Software evolves. the GUII surely was a good thing for xforms and I guess it provided an easy porting to Qt; but I think that we should use what Qt4 provides. Fine. Go for it. Of course I am not going this way if there is no consensus among potential Qt4 developers. I guess Andre is already on my side , what about others? Why not make your vision concrete by porting, say, the Citation dialog? That's what I am trying to do actually. The code is already in svn. But I could use some help here. For sure I am not going to do all this alone so if there is no interest I'll just settle. Abdel. Regards, Angus -- http://leuven.ecodip.net
Re: Help request: QController and QView
Angus Leeming a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: Please don't take this all personally, I don't. Software evolves. the GUII surely was a good thing for xforms and I guess it provided an easy porting to Qt; but I think that we should use what Qt4 provides. Fine. Go for it. Of course I am not going this way if there is no consensus among potential Qt4 developers. I guess Andre is already on my side , what about others? Why not make your vision concrete by porting, say, the Citation dialog? That's what I am trying to do actually. The code is already in svn. But I could use some help here. For sure I am not going to do all this alone so if there is no interest I'll just settle. Abdel. Regards, Angus
Re: Help request: QController and QView
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > Please don't take this all personally, I don't. Software evolves. > the GUII surely was a good thing > for xforms and I guess it provided an easy porting to Qt; but I think > that we should use what Qt4 provides. Fine. Go for it. > Of course I am not going this way if there is no consensus among > potential Qt4 developers. I guess Andre is already on my side , what > about others? Why not make your vision concrete by porting, say, the Citation dialog? Regards, Angus
Re: Help request: QController and QView
Lars Gullik Bjønnes a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Of course I am not going this way if there is no consensus among | potential Qt4 developers. I guess Andre is already on my side ;-), | what about others? It was never the intention that all GUIs must be alike. So I for one is not against it. That's two! ;-) BUT if we want frontends to stay close "feeling" wise, this is perhaps not a good idea. (I have no strong feelings for that.) Indeed, the idea would be to allow current GUIs to diverge (for the better). My goal is to split current GUI into model/view so that a functionality can have diverse form. For example, adding a citation could be done via a Dialog, a menu or a combo box; but all views will share the same model. Another example is the TOC who can be either a dialog or a docked widget for outlining. Separating the model from the view will make the creation of a new view very cheap. The usability can become only better with this strategy. Abdel.
Re: Help request: QController and QView
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Of course I am not going this way if there is no consensus among | potential Qt4 developers. I guess Andre is already on my side ;-), | what about others? It was never the intention that all GUIs must be alike. So I for one is not against it. BUT if we want frontends to stay close "feeling" wise, this is perhaps not a good idea. (I have no strong feelings for that.) -- Lgb
Re: Help request: QController and QView
Angus Leeming a écrit : Go read controllers/Dialog.C which *is* pretty transparent even if things become less so in the frontends. My feeling about this is that people try and make sense of the logic by starting in a frontend implementation of a Dialog::View and, of course, end up confused because they can't see the controlling logic. OK, I have read Dialog.[Ch], Control*, QDialogView, etc... And I still think that this is too complicated. The infrastructure assumes that all GUIs will be separate dialogs with OK, Apply, Cancel, and Restore buttons. IMHO the model should not know about the view. Qt4 provide a clean separation between those too but I am having a hard time trying to fit that into current architecture. I only need a base class that will transfer all lyx func request to/from the kernel. My QLAction class does that already for the toolbars and the menubars and I think this is the way to go for all kind of GUI. This would mean extracting the logic from the current controllers and put that into what Qt4 would call "delegates". A delegate job is to know about the data inside and to provide a nice and easy interface for the frontend. Basically, in the case of the Citation dialog, this is just a version of ControlCitation freed from the controller work. Some more code could be transfered from the current frontend code. This new architecture would imply that those new dialogs use nothing from the frontends/controllers. No need to do that in one go, this can be done dialog per dialog. Of course, no need to rewrite the current frontends to this new architecture, this can be a Qt4 only thing. Please don't take this all personally, the GUII surely was a good thing for xforms and I guess it provided an easy porting to Qt; but I think that we should use what Qt4 provides. Of course I am not going this way if there is no consensus among potential Qt4 developers. I guess Andre is already on my side ;-), what about others? Abdel.
Re: Help request: QController and QView
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > The logic of the buttons, as far as I remember: > > > > Press the button. This should trigger a call to > > Dialog::Controller::ApplyButton() AFAIR. Within that method is a call to > > view().apply() which is what QCitation::apply() is. > > That's what I understood yes but at the end QCitation::apply is not > called. I guess there is an error somewhere in the process touch the few files in controllers and qt4 that you're interested in and rebuild with make CPPFLAGS='-g' that should add debugging data to just the stuff you're interested in, allowing you to step through with the debugger. > >> By the way, what's the "QCitation::hide" method for? > > Hides the dialog? > I mean is it useful to hide it? Is there any calls to this hide method? Yes, it's useful. When you switch documents, then document-specific dialogs are hidden. Go read controllers/Dialog.C which *is* pretty transparent even if things become less so in the frontends. My feeling about this is that people try and make sense of the logic by starting in a frontend implementation of a Dialog::View and, of course, end up confused because they can't see the controlling logic. Angus
Re: Help request: QController and QView
Angus Leeming a écrit : Abdelrazak Younes <[EMAIL PROTECTED]> writes: Right now, QCitation derives from QControllerQView >. I have approximatively the same code as in the qt2 frontend but the OK and Apply buttons don't work properly. It seems that QCitation::update_content is properly called on construction but QCitation::apply is not called when Apply or OK button are pressed. There is an error message in the console: NoRepeatedApplyReadOnlyPolicy: No transition for input SMI_APPLY from state INVALID I'm not very good at the ButtonController. It's a state machine; Allan Rae's work. The logic of the buttons, as far as I remember: Press the button. This should trigger a call to Dialog::Controller::ApplyButton() AFAIR. Within that method is a call to view().apply() which is what QCitation::apply() is. That's what I understood yes but at the end QCitation::apply is not called. I guess there is an error somewhere in the process I am more and more agreeing with Andre about GUII. I am spending more time fitting into its concept than actually coding the GUI Well, feel free to start from scratch with the Qt4 frontend. Nobody's forcing you to use it. Well I tried to shortcut that Controller thing and connect the Apply and button directly to QCitationDialog::apply (and the same for the OK button), but it crashes! Unfortunately I don't have enough disk space and time to compile it with debug, so I though there might be something ovious that you guys would see... Maybe Juergen? Or Edwin? Remember, however, that there are over 40 dialogs, so I hope you've got lots of stamina. If the change are as minimal as shortcutting the controller (as described above), it should be easy and will be actually less code. But first I need confirmation from you. By the way, what's the "QCitation::hide" method for? Hides the dialog? :-) I mean is it useful to hide it? Is there any calls to this hide method? Thanks, Abdel.
Re: Help request: QController and QView
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > Right now, QCitation derives from QController QView >. I have approximatively the same code as in the > qt2 frontend but the OK and Apply buttons don't work properly. It seems > that QCitation::update_content is properly called on construction but > QCitation::apply is not called when Apply or OK button are pressed. > There is an error message in the console: > NoRepeatedApplyReadOnlyPolicy: No transition for input SMI_APPLY from > state INVALID I'm not very good at the ButtonController. It's a state machine; Allan Rae's work. The logic of the buttons, as far as I remember: Press the button. This should trigger a call to Dialog::Controller::ApplyButton() AFAIR. Within that method is a call to view().apply() which is what QCitation::apply() is. > I am more and more agreeing with Andre about GUII. I am spending more > time fitting into its concept than actually coding the GUI Well, feel free to start from scratch with the Qt4 frontend. Nobody's forcing you to use it. Remember, however, that there are over 40 dialogs, so I hope you've got lots of stamina. > By the way, what's the "QCitation::hide" method for? Hides the dialog? Angus
Help request: QController and QView
Hello,
I am trying to implement a nice Citation dialog for qt4 but I have
difficulties with the controller:
Right now, QCitation derives from QControllerQView >. I have approximatively the same code as in the
qt2 frontend but the OK and Apply buttons don't work properly. It seems
that QCitation::update_content is properly called on construction but
QCitation::apply is not called when Apply or OK button are pressed.
There is an error message in the console:
NoRepeatedApplyReadOnlyPolicy: No transition for input SMI_APPLY from
state INVALID
I've tried to understand the controller mechanism but it's really too
convoluted for me (like A calls B calls C calls B calls A ...). So
please if someone knows about this (Angus?), help me.
I am more and more agreeing with Andre about GUII. I am spending more
time fitting into its concept than actually coding the GUI :-(
By the way, what's the "QCitation::hide" method for?
Abdel.
PS: QCitation.[Ch] attached.
/**
* \file QCitation.C
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Angus Leeming
* \author Kalle Dalheimer
*
* Full author contact details are available in file CREDITS.
*/
#include
#include "QCitation.h"
#include "QCitationDialog.h"
#include "Qt2BC.h"
#include "qt_helpers.h"
#include "bufferparams.h"
#include "controllers/ButtonController.h"
#include "controllers/ControlCitation.h"
#include "support/lstrings.h"
namespace lyx {
namespace frontend {
typedef QController > base_class;
QCitation::QCitation(Dialog & parent)
: base_class(parent, _("Citation"))
{
}
void QCitation::apply()
{
dialog_->update(controller().params());
}
void QCitation::build_dialog()
{
dialog_.reset(new QCitationDialog(this));
}
void QCitation::update_contents()
{
// Make the list of all available bibliography keys
bibkeys = biblio::getKeys(controller().bibkeysInfo());
dialog_->update(controller().params());
bc().valid(dialog_->isValid());
}
void QCitation::hide()
{
bibkeys.clear();
QDialogView::hide();
}
bool QCitation::isValid()
{
return dialog_->isValid();
}
QString QCitation::getKeyInfo(int selection) const
{
biblio::InfoMap const & theMap = controller().bibkeysInfo();
if (!theMap.empty())
return toqstr(biblio::getInfo(theMap,
bibkeys[selection]));
return "";
}
} // namespace frontend
} // namespace lyx
// -*- C++ -*-
/**
* \file QCitation.h
* This file is part of LyX, the document processor.
* Licence details can be found in the file COPYING.
*
* \author Angus Leeming
* \author Kalle Dalheimer
*
* Full author contact details are available in file CREDITS.
*/
#ifndef QCITATION_H
#define QCITATION_H
#include "QDialogView.h"
#include
#include
#include
namespace lyx {
namespace frontend {
class ControlCitation;
class QCitationDialog;
class QCitation : public QController >
{
public:
friend class QCitationDialog;
///
QCitation(Dialog &);
std::vector const & availableKeys() const {
return bibkeys;
}
QString QCitation::getKeyInfo(int selection) const;
protected:
virtual bool isValid();
private:
/// Set the Params variable for the Controller.
virtual void apply();
/// Build the dialog.
virtual void build_dialog();
/// Hide the dialog.
virtual void hide();
/// Update dialog before/whilst showing it.
virtual void update_contents();
/// available bib keys
std::vector bibkeys;
};
} // namespace frontend
} // namespace lyx
#endif // QCITATION_H
