Re: [Patch] Last Q3 reference in the qt4 frontend (hopefully) (was Re: Is really Qt3Support gone?)
On Thu, Aug 24, 2006 at 09:36:07PM +0200, Abdelrazak Younes wrote: Will commit soon the attached patch. You could have removed the line entirely. Andre'
Re: [Patch] Last Q3 reference in the qt4 frontend (hopefully) (was Re: Is really Qt3Support gone?)
Andre Poenitz wrote: On Thu, Aug 24, 2006 at 09:36:07PM +0200, Abdelrazak Younes wrote: Will commit soon the attached patch. You could have removed the line entirely. I tried that but Qt designer will put it again if you open it. So in order to avoid unnecessary future commit I decided to let this line. Abdel.
Re: [Patch] Last Q3 reference in the qt4 frontend (hopefully) (was Re: Is really Qt3Support gone?)
On Thu, Aug 24, 2006 at 09:36:07PM +0200, Abdelrazak Younes wrote: > Will commit soon the attached patch. You could have removed the line entirely. Andre'
Re: [Patch] Last Q3 reference in the qt4 frontend (hopefully) (was Re: Is really Qt3Support gone?)
Andre Poenitz wrote: On Thu, Aug 24, 2006 at 09:36:07PM +0200, Abdelrazak Younes wrote: Will commit soon the attached patch. You could have removed the line entirely. I tried that but Qt designer will put it again if you open it. So in order to avoid unnecessary future commit I decided to let this line. Abdel.
[Patch] Last Q3 reference in the qt4 frontend (hopefully) (was Re: Is really Qt3Support gone?)
Abdelrazak Younes wrote: Georg Baum wrote: Abdelrazak Younes wrote: Enrico Forestieri wrote: I think this not a big deal, but LyX/Qt4 is not really Qt3Support free ;-) On my system it really is... Grepping for Q3 and Qt3 gives absolutely nothing: Enrico is right, it is not. Grep the build dir, and you will see it. For example, this patch removes a qt3 header from one generated .h file. I guess you know what needs to be done for the others. Yes, thanks for the hint. This line is regenerated when you save a ui file within Qt Designer but without the qPixmapFromMimeSource. I removed all of them and am compiling right now. Will commit as soon as I am sure there is no side effect. No side effect visible, the dialogs looks as usual. I guess this is qPixmapFromMimeSource was a remnant of Qt3 or Qt2 ui format. Will commit soon the attached patch. Abdel. Index: BiblioUi.ui === --- BiblioUi.ui (revision 14826) +++ BiblioUi.ui (working copy) @@ -133,7 +133,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction resources/ connections/ /ui Index: BranchesUi.ui === --- BranchesUi.ui (revision 14826) +++ BranchesUi.ui (working copy) @@ -106,7 +106,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction resources/ connections/ /ui Index: BulletsUi.ui === --- BulletsUi.ui(revision 14826) +++ BulletsUi.ui(working copy) @@ -186,7 +186,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction resources/ connections connection Index: FontUi.ui === --- FontUi.ui (revision 14826) +++ FontUi.ui (working copy) @@ -250,7 +250,7 @@ /layout /widget layoutdefault spacing=6 margin=11 / - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction tabstops tabstopfontsRomanCO/tabstop tabstopfontsizeCO/tabstop Index: LanguageUi.ui === --- LanguageUi.ui (revision 14826) +++ LanguageUi.ui (working copy) @@ -204,7 +204,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction tabstops tabstoplanguageCO/tabstop tabstopdefaultencodingCB/tabstop Index: LaTeXUi.ui === --- LaTeXUi.ui (revision 14826) +++ LaTeXUi.ui (working copy) @@ -170,7 +170,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction tabstops tabstopclassCO/tabstop tabstopoptionsLE/tabstop Index: MathsUi.ui === --- MathsUi.ui (revision 14826) +++ MathsUi.ui (working copy) @@ -57,7 +57,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction tabstops tabstopamsautoCB/tabstop /tabstops Index: NumberingUi.ui === --- NumberingUi.ui (revision 14826) +++ NumberingUi.ui (working copy) @@ -79,7 +79,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction tabstops tabstoptocSL/tabstop tabstopdepthSL/tabstop Index: PreambleUi.ui === --- PreambleUi.ui (revision 14826) +++ PreambleUi.ui (working copy) @@ -27,7 +27,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction resources/ connections/ /ui Index: QAboutUi.ui === --- QAboutUi.ui (revision 14826) +++ QAboutUi.ui (working copy) @@ -139,7 +139,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction resources/ connections/ /ui Index: QAskForTextUi.ui === --- QAskForTextUi.ui(revision 14826) +++ QAskForTextUi.ui(working copy) @@ -102,7 +102,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction + pixmapfunction/pixmapfunction resources/ connections/ /ui Index: QBibitemUi.ui === --- QBibitemUi.ui (revision 14826) +++ QBibitemUi.ui (working copy) @@ -146,7 +146,7 @@ /item /layout /widget - pixmapfunctionqPixmapFromMimeSource/pixmapfunction +
[Patch] Last Q3 reference in the qt4 frontend (hopefully) (was Re: Is really Qt3Support gone?)
Abdelrazak Younes wrote: Georg Baum wrote: Abdelrazak Younes wrote: Enrico Forestieri wrote: I think this not a big deal, but LyX/Qt4 is not really Qt3Support free ;-) On my system it really is... Grepping for Q3 and Qt3 gives absolutely nothing: Enrico is right, it is not. Grep the build dir, and you will see it. For example, this patch removes a qt3 header from one generated .h file. I guess you know what needs to be done for the others. Yes, thanks for the hint. This line is regenerated when you save a ui file within Qt Designer but without the qPixmapFromMimeSource. I removed all of them and am compiling right now. Will commit as soon as I am sure there is no side effect. No side effect visible, the dialogs looks as usual. I guess this is qPixmapFromMimeSource was a remnant of Qt3 or Qt2 ui format. Will commit soon the attached patch. Abdel. Index: BiblioUi.ui === --- BiblioUi.ui (revision 14826) +++ BiblioUi.ui (working copy) @@ -133,7 +133,7 @@ - qPixmapFromMimeSource + Index: BranchesUi.ui === --- BranchesUi.ui (revision 14826) +++ BranchesUi.ui (working copy) @@ -106,7 +106,7 @@ - qPixmapFromMimeSource + Index: BulletsUi.ui === --- BulletsUi.ui(revision 14826) +++ BulletsUi.ui(working copy) @@ -186,7 +186,7 @@ - qPixmapFromMimeSource + Index: FontUi.ui === --- FontUi.ui (revision 14826) +++ FontUi.ui (working copy) @@ -250,7 +250,7 @@ - qPixmapFromMimeSource + fontsRomanCO fontsizeCO Index: LanguageUi.ui === --- LanguageUi.ui (revision 14826) +++ LanguageUi.ui (working copy) @@ -204,7 +204,7 @@ - qPixmapFromMimeSource + languageCO defaultencodingCB Index: LaTeXUi.ui === --- LaTeXUi.ui (revision 14826) +++ LaTeXUi.ui (working copy) @@ -170,7 +170,7 @@ - qPixmapFromMimeSource + classCO optionsLE Index: MathsUi.ui === --- MathsUi.ui (revision 14826) +++ MathsUi.ui (working copy) @@ -57,7 +57,7 @@ - qPixmapFromMimeSource + amsautoCB Index: NumberingUi.ui === --- NumberingUi.ui (revision 14826) +++ NumberingUi.ui (working copy) @@ -79,7 +79,7 @@ - qPixmapFromMimeSource + tocSL depthSL Index: PreambleUi.ui === --- PreambleUi.ui (revision 14826) +++ PreambleUi.ui (working copy) @@ -27,7 +27,7 @@ - qPixmapFromMimeSource + Index: QAboutUi.ui === --- QAboutUi.ui (revision 14826) +++ QAboutUi.ui (working copy) @@ -139,7 +139,7 @@ - qPixmapFromMimeSource + Index: QAskForTextUi.ui === --- QAskForTextUi.ui(revision 14826) +++ QAskForTextUi.ui(working copy) @@ -102,7 +102,7 @@ - qPixmapFromMimeSource + Index: QBibitemUi.ui === --- QBibitemUi.ui (revision 14826) +++ QBibitemUi.ui (working copy) @@ -146,7 +146,7 @@ - qPixmapFromMimeSource + Index: QBibtexAddUi.ui === --- QBibtexAddUi.ui (revision 14826) +++ QBibtexAddUi.ui (working copy) @@ -135,7 +135,7 @@ - qPixmapFromMimeSource + bibED addPB Index: QBibtexUi.ui === --- QBibtexUi.ui(revision 14826) +++ QBibtexUi.ui(working copy) @@ -258,7 +258,7 @@ - qPixmapFromMimeSource + addBibPB deletePB Index: QBranchUi.ui === --- QBranchUi.ui(revision 14826) +++ QBranchUi.ui(working copy) @@ -74,7 +74,7 @@ - qPixmapFromMimeSource + Index: QChangesUi.ui === --- QChangesUi.ui (revision 14826) +++ QChangesUi.ui (working copy) @@ -135,7 +135,7 @@ - qPixmapFromMimeSource + acceptPB rejectPB Index: QCharacterUi.ui === --- QCharacterUi.ui (revision 14826) +++ QCharacterUi.ui (working copy) @@ -383,7 +383,7 @@ - qPixmapFromMimeSource + familyCO seriesCO Index: QErrorListUi.ui
Re: Qt4 frontend save/restore geoemtry patch
void GuiView::closeEvent(QCloseEvent *)
{
+ // FIXME:
+ // change the ifdef to 'geometry = normalGeometry();' only
+ // when Trolltech has fixed the broken normalGeometry on X11.
+ // Then also the moveEvent, resizeEvent, and the
+ // code for floatingGeometry_ can be removed;
+ // adjust lyx_gui::start
+#ifdef Q_OS_WIN32
QRect geometry = normalGeometry();
+#else
+ updateFloatingGeometry();
+ QRect geometry = floatingGeometry_;
+#endif
+
Here the Qt task:
http://www.trolltech.com/developer/task-tracker/index_html?id=119684+method=entry
I will add the link to the comment.
Peter
Re: Qt4 frontend save/restore geoemtry patch
void GuiView::closeEvent(QCloseEvent *)
{
+ // FIXME:
+ // change the ifdef to 'geometry = normalGeometry();' only
+ // when Trolltech has fixed the broken normalGeometry on X11.
+ // Then also the moveEvent, resizeEvent, and the
+ // code for floatingGeometry_ can be removed;
+ // adjust lyx_gui::start
+#ifdef Q_OS_WIN32
QRect geometry = normalGeometry();
+#else
+ updateFloatingGeometry();
+ QRect geometry = floatingGeometry_;
+#endif
+
Here the Qt task:
http://www.trolltech.com/developer/task-tracker/index_html?id=119684+=entry
I will add the link to the comment.
Peter
Re: Qt4 frontend save/restore geoemtry patch
Andre Poenitz wrote: On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: I think it's just because we decided it improves readability. These things should be read from right to left: QRect const A reference to a const QRect char const * const A const pointer to a const char. Well, in almost all cases we have just a single 'const'. I find const QRect rc = ...; const int i = 3; const bool b = true; or even const QRect rc = ...; const int i = 3; const bool b = true; more pleasant to read than QRect const rc = ...; int const i = 3; bool const b = true; However, placing 'const' at the right is (apart from formatting) about the only thing which is done consistently within LyX, so 'it is good as it is'. But most C++ projects including boost, stl and Qt place the const at the left. I always have to force myself to put it to the right. Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes [EMAIL PROTECTED] writes: | Andre Poenitz wrote: | On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: | I think it's just because we decided it improves readability. These things | should be read from right to left: | QRect const | A reference to a const QRect | | char const * const | A const pointer to a const char. | Well, in almost all cases we have just a single 'const'. I find |const QRect rc = ...; |const int i = 3; |const bool b = true; | or even |const QRect rc = ...; |const int i = 3; |const bool b = true; | more pleasant to read than |QRect const rc = ...; |int const i = 3; |bool const b = true; | However, placing 'const' at the right is (apart from formatting) | about | the only thing which is done consistently within LyX, so 'it is good as | it is'. | | But most C++ projects including boost, stl and Qt place the const at | the left. Ahh... but they are mis-guided. | I always have to force myself to put it to the right. When you get used to it, it feels a lot more natural. -- Lgb
Re: Qt4 frontend save/restore geoemtry patch
Lars Gullik Bjønnes wrote: Abdelrazak Younes [EMAIL PROTECTED] writes: | Andre Poenitz wrote: | On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: | I think it's just because we decided it improves readability. These things | should be read from right to left: | QRect const | A reference to a const QRect | | char const * const | A const pointer to a const char. | Well, in almost all cases we have just a single 'const'. I find |const QRect rc = ...; |const int i = 3; |const bool b = true; | or even |const QRect rc = ...; |const int i = 3; |const bool b = true; | more pleasant to read than |QRect const rc = ...; |int const i = 3; |bool const b = true; | However, placing 'const' at the right is (apart from formatting) | about | the only thing which is done consistently within LyX, so 'it is good as | it is'. | | But most C++ projects including boost, stl and Qt place the const at | the left. Ahh... but they are mis-guided. It might feel great to be in your shoes man! | I always have to force myself to put it to the right. When you get used to it, it feels a lot more natural. That is, up until the moment you have to get back to use the much more wide spread style... Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Andre Poenitz wrote:
On Tue, Jun 20, 2006 at 01:09:15PM +0200, Peter Kümmel wrote:
+if (width != -1 height != -1 posx != -1 posy != -1) {
+view.initNormalGeometry(QRect(posx, posy, width, height));
+view.resize(width, height);
+view.move(posx, posy);
+if (maximize)
+{
if (maximize) {
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
That'd be a tab, not spaces.
+QRect QtView::qtViewGeometry() const
+{
+QRect rec;
+// setX/Y changes the size!
+rec.setX(frameGeometry().x());
+rec.setY(frameGeometry().y());
+rec.setWidth(geometry().width());
+rec.setHeight(geometry().height());
+return rec;
+}
IIRC there's a constructor that avoids the commented pitfall,
i.e.
return QRect(... .x(), ... y(), w h)
+if (width()maxWidth)
Grrr.
protected:
/// make sure we quit cleanly
virtual void closeEvent(QCloseEvent * e);
+
+#ifndef Q_OS_WIN32
+ ///
+ virtual void resizeEvent(QResizeEvent * e);
+
+ ///
+ virtual void moveEvent(QMoveEvent * e);
+#endif
Tabs for indentation.
private:
/// focus the command buffer widget
void focus_command_widget();
@@ -112,6 +121,14 @@
static QMainWindow* mainWidget_;
GuiImplementation frontend_;
+
+#ifndef Q_OS_WIN32
+ ///
+ QRect qtViewGeometry() const;
+
+ ///
+ QRect normalGeometry_;
+#endif
};
Tabs for indentation.
Why do we need the #ifndef? I seemingly forgot the reasoning.
+QRect GuiView::qtViewGeometry() const
+{
+QRect rec;
+// setX/Y changes the size!
+rec.setX(frameGeometry().x());
+rec.setY(frameGeometry().y());
+rec.setWidth(geometry().width());
+rec.setHeight(geometry().height());
+return rec;
+}
+
+void GuiView::resizeEvent(QResizeEvent *)
Two empty lines between fuctions.
Andre'
Done.
Re: Qt4 frontend save/restore geoemtry patch
On Fri, Jun 23, 2006 at 11:06:20AM +0200, Lars Gullik Bjønnes wrote: | I always have to force myself to put it to the right. When you get used to it, it feels a lot more natural. I think you agree that I have written enough code with 'const' on the right and still like it more on the left. Andre'
Re: Qt4 frontend save/restore geoemtry patch
Andre Poenitz wrote: On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: I think it's just because we decided it improves readability. These things should be read from right to left: QRect const & A reference to a const QRect char const * const A const pointer to a const char. Well, in almost all cases we have just a single 'const'. I find const QRect rc = ...; const int i = 3; const bool b = true; or even const QRect rc = ...; const int i = 3; const bool b = true; more pleasant to read than QRect const rc = ...; int const i = 3; bool const b = true; However, placing 'const' at the right is (apart from formatting) about the only thing which is done consistently within LyX, so 'it is good as it is'. But most C++ projects including boost, stl and Qt place the const at the left. I always have to force myself to put it to the right. Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Andre Poenitz wrote: | > On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: | >> I think it's just because we decided it improves readability. These things | >> should be read from right to left: | >>QRect const & | >>A reference to a const QRect | >> | >>char const * const | >>A const pointer to a const char. | > Well, in almost all cases we have just a single 'const'. I find | > const QRect rc = ...; | > const int i = 3; | > const bool b = true; | > or even | > const QRect rc = ...; | > const int i = 3; | > const bool b = true; | > more pleasant to read than | > QRect const rc = ...; | > int const i = 3; | > bool const b = true; | > However, placing 'const' at the right is (apart from formatting) | > about | > the only thing which is done consistently within LyX, so 'it is good as | > it is'. | | But most C++ projects including boost, stl and Qt place the const at | the left. Ahh... but they are mis-guided. | I always have to force myself to put it to the right. When you get used to it, it feels a lot more natural. -- Lgb
Re: Qt4 frontend save/restore geoemtry patch
Lars Gullik Bjønnes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: | Andre Poenitz wrote: | > On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: | >> I think it's just because we decided it improves readability. These things | >> should be read from right to left: | >>QRect const & | >>A reference to a const QRect | >> | >>char const * const | >>A const pointer to a const char. | > Well, in almost all cases we have just a single 'const'. I find | > const QRect rc = ...; | > const int i = 3; | > const bool b = true; | > or even | > const QRect rc = ...; | > const int i = 3; | > const bool b = true; | > more pleasant to read than | > QRect const rc = ...; | > int const i = 3; | > bool const b = true; | > However, placing 'const' at the right is (apart from formatting) | > about | > the only thing which is done consistently within LyX, so 'it is good as | > it is'. | | But most C++ projects including boost, stl and Qt place the const at | the left. Ahh... but they are mis-guided. It might feel great to be in your shoes man! | I always have to force myself to put it to the right. When you get used to it, it feels a lot more natural. That is, up until the moment you have to get back to use the much more wide spread style... Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Andre Poenitz wrote:
> On Tue, Jun 20, 2006 at 01:09:15PM +0200, Peter Kümmel wrote:
>> +if (width != -1 && height != -1 && posx != -1 && posy != -1) {
>> +view.initNormalGeometry(QRect(posx, posy, width, height));
>> +view.resize(width, height);
>> +view.move(posx, posy);
>> +if (maximize)
>> +{
>
> if (maximize) {
>
>>
>> -QtView::QtView(unsigned int width, unsigned int height)
>> +QtView::QtView()
>> : QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
>
> That'd be a tab, not spaces.
>
>> +QRect QtView::qtViewGeometry() const
>> +{
>> +QRect rec;
>> +// setX/Y changes the size!
>> +rec.setX(frameGeometry().x());
>> +rec.setY(frameGeometry().y());
>> +rec.setWidth(geometry().width());
>> +rec.setHeight(geometry().height());
>> +return rec;
>> +}
>
> IIRC there's a constructor that avoids the commented pitfall,
> i.e.
>
>return QRect(... .x(), ... y(), w h)
>
>> +if (width()
> Grrr.
>
>> protected:
>> /// make sure we quit cleanly
>> virtual void closeEvent(QCloseEvent * e);
>> +
>> +#ifndef Q_OS_WIN32
>> + ///
>> + virtual void resizeEvent(QResizeEvent * e);
>> +
>> + ///
>> + virtual void moveEvent(QMoveEvent * e);
>> +#endif
>
> Tabs for indentation.
>
>> private:
>> /// focus the command buffer widget
>> void focus_command_widget();
>> @@ -112,6 +121,14 @@
>> static QMainWindow* mainWidget_;
>>
>> GuiImplementation frontend_;
>> +
>> +#ifndef Q_OS_WIN32
>> + ///
>> + QRect qtViewGeometry() const;
>> +
>> + ///
>> + QRect normalGeometry_;
>> +#endif
>> };
>
> Tabs for indentation.
>
> Why do we need the #ifndef? I seemingly forgot the reasoning.
>
>
>> +QRect GuiView::qtViewGeometry() const
>> +{
>> +QRect rec;
>> +// setX/Y changes the size!
>> +rec.setX(frameGeometry().x());
>> +rec.setY(frameGeometry().y());
>> +rec.setWidth(geometry().width());
>> +rec.setHeight(geometry().height());
>> +return rec;
>> +}
>> +
>> +void GuiView::resizeEvent(QResizeEvent *)
>
> Two empty lines between fuctions.
>
> Andre'
>
>
Done.
Re: Qt4 frontend save/restore geoemtry patch
On Fri, Jun 23, 2006 at 11:06:20AM +0200, Lars Gullik Bjønnes wrote: > | I always have to force myself to put it to the right. > > When you get used to it, it feels a lot more natural. I think you agree that I have written enough code with 'const' on the right and still like it more on the left. Andre'
Re: Qt4 frontend save/restore geoemtry patch
Quoting Peter Kümmel [EMAIL PROTECTED]: Abdelrazak Younes wrote: I think we should use QMainWindow::centralWidget().width/height instead. In this particular case, yes. But I would prefer to fix the problem at the source: We don't need the width and height on BufferView creation. My cleanup will fix that. Yes, that is the best solution! I've done that in my branch by the way... Abdel.
Re: Qt4 frontend save/restore geoemtry patch
On Tue, Jun 20, 2006 at 01:09:15PM +0200, Peter Kümmel wrote:
+ if (width != -1 height != -1 posx != -1 posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
if (maximize) {
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
That'd be a tab, not spaces.
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
IIRC there's a constructor that avoids the commented pitfall,
i.e.
return QRect(... .x(), ... y(), w h)
+ if (width()maxWidth)
Grrr.
protected:
/// make sure we quit cleanly
virtual void closeEvent(QCloseEvent * e);
+
+#ifndef Q_OS_WIN32
+ ///
+ virtual void resizeEvent(QResizeEvent * e);
+
+ ///
+ virtual void moveEvent(QMoveEvent * e);
+#endif
Tabs for indentation.
private:
/// focus the command buffer widget
void focus_command_widget();
@@ -112,6 +121,14 @@
static QMainWindow* mainWidget_;
GuiImplementation frontend_;
+
+#ifndef Q_OS_WIN32
+ ///
+ QRect qtViewGeometry() const;
+
+ ///
+ QRect normalGeometry_;
+#endif
};
Tabs for indentation.
Why do we need the #ifndef? I seemingly forgot the reasoning.
+QRect GuiView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void GuiView::resizeEvent(QResizeEvent *)
Two empty lines between fuctions.
Andre'
Re: Qt4 frontend save/restore geoemtry patch
On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: I think it's just because we decided it improves readability. These things should be read from right to left: QRect const A reference to a const QRect char const * const A const pointer to a const char. Well, in almost all cases we have just a single 'const'. I find const QRect rc = ...; const int i = 3; const bool b = true; or even const QRect rc = ...; const int i = 3; const bool b = true; more pleasant to read than QRect const rc = ...; int const i = 3; bool const b = true; However, placing 'const' at the right is (apart from formatting) about the only thing which is done consistently within LyX, so 'it is good as it is'. Andre'
Re: Qt4 frontend save/restore geoemtry patch
Quoting Peter Kümmel <[EMAIL PROTECTED]>: > Abdelrazak Younes wrote: > >> > >> I think we should use QMainWindow::centralWidget().width/height instead. > > > > In this particular case, yes. But I would prefer to fix the problem at > > the source: We don't need the width and height on BufferView creation. > > My cleanup will fix that. > > Yes, that is the best solution! I've done that in my branch by the way... Abdel.
Re: Qt4 frontend save/restore geoemtry patch
On Tue, Jun 20, 2006 at 01:09:15PM +0200, Peter Kümmel wrote:
> + if (width != -1 && height != -1 && posx != -1 && posy != -1) {
> + view.initNormalGeometry(QRect(posx, posy, width, height));
> + view.resize(width, height);
> + view.move(posx, posy);
> + if (maximize)
> + {
if (maximize) {
>
> -QtView::QtView(unsigned int width, unsigned int height)
> +QtView::QtView()
> : QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
That'd be a tab, not spaces.
> +QRect QtView::qtViewGeometry() const
> +{
> + QRect rec;
> + // setX/Y changes the size!
> + rec.setX(frameGeometry().x());
> + rec.setY(frameGeometry().y());
> + rec.setWidth(geometry().width());
> + rec.setHeight(geometry().height());
> + return rec;
> +}
IIRC there's a constructor that avoids the commented pitfall,
i.e.
return QRect(... .x(), ... y(), w h)
> + if (width() protected:
> /// make sure we quit cleanly
> virtual void closeEvent(QCloseEvent * e);
> +
> +#ifndef Q_OS_WIN32
> + ///
> + virtual void resizeEvent(QResizeEvent * e);
> +
> + ///
> + virtual void moveEvent(QMoveEvent * e);
> +#endif
Tabs for indentation.
> private:
> /// focus the command buffer widget
> void focus_command_widget();
> @@ -112,6 +121,14 @@
> static QMainWindow* mainWidget_;
>
> GuiImplementation frontend_;
> +
> +#ifndef Q_OS_WIN32
> + ///
> + QRect qtViewGeometry() const;
> +
> + ///
> + QRect normalGeometry_;
> +#endif
> };
Tabs for indentation.
Why do we need the #ifndef? I seemingly forgot the reasoning.
> +QRect GuiView::qtViewGeometry() const
> +{
> + QRect rec;
> + // setX/Y changes the size!
> + rec.setX(frameGeometry().x());
> + rec.setY(frameGeometry().y());
> + rec.setWidth(geometry().width());
> + rec.setHeight(geometry().height());
> + return rec;
> +}
> +
> +void GuiView::resizeEvent(QResizeEvent *)
Two empty lines between fuctions.
Andre'
Re: Qt4 frontend save/restore geoemtry patch
On Wed, Jun 21, 2006 at 10:24:31AM +, Angus Leeming wrote: > I think it's just because we decided it improves readability. These things > should be read from right to left: >QRect const & >A reference to a const QRect > >char const * const >A const pointer to a const char. Well, in almost all cases we have just a single 'const'. I find const QRect rc = ...; const int i = 3; const bool b = true; or even const QRect rc = ...; const int i = 3; const bool b = true; more pleasant to read than QRect const rc = ...; int const i = 3; bool const b = true; However, placing 'const' at the right is (apart from formatting) about the only thing which is done consistently within LyX, so 'it is good as it is'. Andre'
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote: Hi Abdel, Bo here the next version with your embedded suggestions. I've also simplified the floating code. If you correct Lars small issue, that's fine with me. Good work. Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote: On 6/20/06, Peter Kümmel [EMAIL PROTECTED] wrote: Hi Abdel, Bo here the next version with your embedded suggestions. I've also simplified the floating code. Looks fine to me (others may have higher standard though). Is this patch against the trunk or some branch? I can not apply cleanly. Bo It was trunk. Under Linux I get messages because of the line ending. Peter
Re: Qt4 frontend save/restore geoemtry patch
Lars Gullik Bjønnes wrote:
| + maxWidth=QApplication::desktop()-width()-20;
Oooo... spacing.
Year, I've only one line with spacing errors ;)
| + if (width() maxWidth)
| + maxWidth = width();
maxWidth = max(width(), maxWidth);
Msvc needs std::max and #include algorithm.
QRect const
Done.
(Will search for the reason for this in the mailing list archive.
The doc says Asger had strong arguments)
| +void GuiView::updateFloatingGeometry()
| +{
| + if (!isMaximized()) {
| + // setX/Y changes the size!
| + floatingGeometry_.setX(x()); // == frameGeometry().x()
| + floatingGeometry_.setY(y()); // == frameGeometry().y()
| + floatingGeometry_.setWidth(width()); // == geometry().width()
| + floatingGeometry_.setHeight(height());// == geometry().height()
| + }
| +}
What are the comments about?
To make clear that the floating geometry is a mixture of geometry and
frameGeometry.
But I've removed them, it's not so important.
| Index: lyx_main.C
| ===
| --- lyx_main.C (revision 14157)
| +++ lyx_main.C (working copy)
| @@ -995,6 +1002,10 @@
| std::mapstring, cmd_helper::const_iterator it
| = cmdmap.find(argv[i]);
|
| + // check for X11 -geometry option
| + if (argv[i] == string(-geometry))
| + geometryOption_ = true;
instead of useing the string(...) temporary style you can also use the
compare from lstring.h:
if (lyx::support::compare(argv[i], -geometry) == 0)
...
Then no conversion to std::string will be done at all, and compare is
an inline function.
Done.
Attached the new patch.
Peter
Index: frontends/qt3/lyx_gui.C
===
--- frontends/qt3/lyx_gui.C (revision 14165)
+++ frontends/qt3/lyx_gui.C (working copy)
@@ -222,22 +222,29 @@
void start(string const batch, vectorstring const files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptrQtView view_ptr(new QtView(width, height));
+ boost::shared_ptrQtView view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView view = *view_ptr.get();
- if (posx != -1 posy != -1)
- view.move(QPoint(posx, posy));
-
- view.show();
view.init();
+ if (width != -1 height != -1) {
+ view.initFloatingGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ if (posx != -1 posy != -1)
+ view.move(posx, posy);
+ view.show();
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ } else
+ view.show();
+
// FIXME: some code below needs moving
lyxserver = new LyXServer(view.getLyXFunc(), lyxrc.lyxpipes);
Index: frontends/qt3/QtView.C
===
--- frontends/qt3/QtView.C (revision 14165)
+++ frontends/qt3/QtView.C (working copy)
@@ -37,6 +37,8 @@
#include qpixmap.h
#include qstatusbar.h
+#include algorithm
+
using std::string;
FontLoader fontloader;
@@ -55,14 +57,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp-setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +157,49 @@
return qApp-activeWindow() == this;
}
+void QtView::initFloatingGeometry(QRect const g)
+{
+ floatingGeometry_ = g;
+ maxWidth = QApplication::desktop()-width() - 20;
+}
+void QtView::updateFloatingGeometry()
+{
+ if (width() maxWidth frameGeometry().x() 0)
+ {
+ // setX/Y changes the size!
+ floatingGeometry_.setX(x());
+ floatingGeometry_.setY(y());
+ floatingGeometry_.setWidth(width());
+ floatingGeometry_.setHeight(height());
+ }
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ maxWidth = std::max(width(), maxWidth);
+
+ updateFloatingGeometry();
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ updateFloatingGeometry();
+}
+
void QtView::closeEvent(QCloseEvent *)
{
+ updateFloatingGeometry();
+ QRect geometry = floatingGeometry_;
+
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel [EMAIL PROTECTED] writes: | Done. | | Attached the new patch. This is ok with me now. -- Lgb
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel [EMAIL PROTECTED] writes: Lars Gullik Bjønnes wrote: QRect const Done. (Will search for the reason for this in the mailing list archive. The doc says Asger had strong arguments) I think it's just because we decided it improves readability. These things should be read from right to left: QRect const A reference to a const QRect char const * const A const pointer to a const char. Angus
Re: Qt4 frontend save/restore geoemtry patch
Lars Gullik Bjønnes wrote: Peter Kümmel [EMAIL PROTECTED] writes: | Done. | | Attached the new patch. This is ok with me now. I've checked it in. Having now the qt3 and the qt4 version of lyx on my machine here my two benchmark timings: Windows qt3: 18 sec qt4: 31 sec
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote: Hi Abdel, Bo here the next version with your embedded suggestions. I've also simplified the floating code. If you correct Lars small issue, that's fine with me. Good work. Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote: > On 6/20/06, Peter Kümmel <[EMAIL PROTECTED]> wrote: >> Hi Abdel, Bo >> >> here the next version with your embedded suggestions. >> I've also simplified the floating code. > > Looks fine to me (others may have higher standard though). > > Is this patch against the trunk or some branch? I can not apply cleanly. > > Bo It was trunk. Under Linux I get messages because of the line ending. Peter
Re: Qt4 frontend save/restore geoemtry patch
Lars Gullik Bjønnes wrote:
> | + maxWidth=QApplication::desktop()->width()-20;
>
> Oooo... spacing.
Year, I've only one line with spacing errors ;)
> | + if (width() > maxWidth)
> | + maxWidth = width();
>
> maxWidth = max(width(), maxWidth);
Msvc needs std::max and #include .
> QRect const &
Done.
(Will search for the reason for this in the mailing list archive.
The doc says Asger had strong arguments)
> | +void GuiView::updateFloatingGeometry()
> | +{
> | + if (!isMaximized()) {
> | + // setX/Y changes the size!
> | + floatingGeometry_.setX(x()); // == frameGeometry().x()
> | + floatingGeometry_.setY(y()); // == frameGeometry().y()
> | + floatingGeometry_.setWidth(width()); // == geometry().width()
> | + floatingGeometry_.setHeight(height());// == geometry().height()
> | + }
> | +}
>
> What are the comments about?
To make clear that the floating geometry is a mixture of geometry and
frameGeometry.
But I've removed them, it's not so important.
>
> | Index: lyx_main.C
> | ===
> | --- lyx_main.C (revision 14157)
> | +++ lyx_main.C (working copy)
> | @@ -995,6 +1002,10 @@
> | std::map::const_iterator it
> | = cmdmap.find(argv[i]);
> |
> | + // check for X11 -geometry option
> | + if (argv[i] == string("-geometry"))
> | + geometryOption_ = true;
>
> instead of useing the string(...) temporary style you can also use the
> compare from lstring.h:
>
> if (lyx::support::compare(argv[i], "-geometry") == 0)
> ...
>
> Then no conversion to std::string will be done at all, and compare is
> an inline function.
>
Done.
Attached the new patch.
Peter
Index: frontends/qt3/lyx_gui.C
===
--- frontends/qt3/lyx_gui.C (revision 14165)
+++ frontends/qt3/lyx_gui.C (working copy)
@@ -222,22 +222,29 @@
void start(string const & batch, vector const & files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptr view_ptr(new QtView(width, height));
+ boost::shared_ptr view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView & view = *view_ptr.get();
- if (posx != -1 && posy != -1)
- view.move(QPoint(posx, posy));
-
- view.show();
view.init();
+ if (width != -1 && height != -1) {
+ view.initFloatingGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ if (posx != -1 && posy != -1)
+ view.move(posx, posy);
+ view.show();
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ } else
+ view.show();
+
// FIXME: some code below needs moving
lyxserver = new LyXServer((), lyxrc.lyxpipes);
Index: frontends/qt3/QtView.C
===
--- frontends/qt3/QtView.C (revision 14165)
+++ frontends/qt3/QtView.C (working copy)
@@ -37,6 +37,8 @@
#include
#include
+#include
+
using std::string;
FontLoader fontloader;
@@ -55,14 +57,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp->setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +157,49 @@
return qApp->activeWindow() == this;
}
+void QtView::initFloatingGeometry(QRect const & g)
+{
+ floatingGeometry_ = g;
+ maxWidth = QApplication::desktop()->width() - 20;
+}
+void QtView::updateFloatingGeometry()
+{
+ if (width() < maxWidth && frameGeometry().x() > 0)
+ {
+ // setX/Y changes the size!
+ floatingGeometry_.setX(x());
+ floatingGeometry_.setY(y());
+ floatingGeometry_.setWidth(width());
+ floatingGeometry_.setHeight(height());
+ }
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ maxWidth = std::max(width(), maxWidth);
+
+ updateFloatingGeometry();
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ updateFloatingGeometry();
+}
+
void QtView::closeEvent(QCloseEvent *)
{
+ updateFloatingGeometry();
+ QRect geometry = floatingGeometry_;
+
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel <[EMAIL PROTECTED]> writes: | Done. | | Attached the new patch. This is ok with me now. -- Lgb
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel <[EMAIL PROTECTED]> writes: > Lars Gullik Bjønnes wrote: >> QRect const & > Done. > (Will search for the reason for this in the mailing list archive. > The doc says Asger had strong arguments) I think it's just because we decided it improves readability. These things should be read from right to left: QRect const & A reference to a const QRect char const * const A const pointer to a const char. Angus
Re: Qt4 frontend save/restore geoemtry patch
Lars Gullik Bjønnes wrote: > Peter Kümmel <[EMAIL PROTECTED]> writes: > > | Done. > | > | Attached the new patch. > > This is ok with me now. > I've checked it in. Having now the qt3 and the qt4 version of lyx on my machine here my two benchmark timings: Windows qt3: 18 sec qt4: 31 sec
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
But when you prefer the (-1,-1) solution I'll change it.
Since (-1, -1) will save a significant amount of coding, I prefer this.
Bo
Here the patch with above changes.
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Peter
Index: src/frontends/qt3/lyx_gui.C
===
--- src/frontends/qt3/lyx_gui.C (revision 14157)
+++ src/frontends/qt3/lyx_gui.C (working copy)
@@ -222,21 +222,30 @@
void start(string const batch, vectorstring const files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptrQtView view_ptr(new QtView(width, height));
+ boost::shared_ptrQtView view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView view = *view_ptr.get();
- if (posx != -1 posy != -1)
- view.move(QPoint(posx, posy));
+ view.init();
+ if (width != -1 height != -1 posx != -1 posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
+ view.show();
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ }
+
view.show();
- view.init();
// FIXME: some code below needs moving
Index: src/frontends/qt3/QtView.C
===
--- src/frontends/qt3/QtView.C (revision 14157)
+++ src/frontends/qt3/QtView.C (working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp-setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,62 @@
return qApp-activeWindow() == this;
}
+void QtView::initNormalGeometry(const QRect g)
+{
+ normalGeometry_ = g;
+ maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() maxWidth) {
+ maxWidth = width();
+ return;
+ }
+ if (frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
+
+ std::coutmaxWidth-normalGeometry_.width(), resizeEvent
:normalGeometry_.x()\n;
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ if (width() maxWidth frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
+ std::coutmaxWidth-normalGeometry_.width(), moveEvent
:normalGeometry_.x()\n;
+}
+
void QtView::closeEvent(QCloseEvent *)
{
+ QRect geometry;
+ std::coutmaxWidth:maxWidth\n;
+ std::coutnormalGeometry_: normalGeometry_.width()\n;
+ if (QWidget::geometry().width() maxWidth)
+ geometry = qtViewGeometry();
+ else
+ geometry = normalGeometry_;
+
+ std::coutcloseEvent : geometry.width() geometry.x()
\n\n;
+
Session session = LyX::ref().session();
session.saveSessionInfo(WindowIsMaximized, (isMaximized() ? yes :
no));
// save windows size and position
- session.saveSessionInfo(WindowWidth, convertstring(width()));
- session.saveSessionInfo(WindowHeight, convertstring(height()));
+ session.saveSessionInfo(WindowWidth,
convertstring(geometry.width()));
+ session.saveSessionInfo(WindowHeight,
convertstring(geometry.height()));
if (lyxrc.geometry_xysaved) {
- session.saveSessionInfo(WindowPosX, convertstring(x()));
- session.saveSessionInfo(WindowPosY, convertstring(y()));
+ session.saveSessionInfo(WindowPosX,
convertstring(geometry.x()));
+ session.saveSessionInfo(WindowPosY,
convertstring(geometry.y()));
}
// trigger LFUN_LYX_QUIT instead of quit directly
// since LFUN_LYX_QUIT may have more cleanup stuff
@@ -179,6 +222,8 @@
{
setCaption(qt_(LyX));
QMainWindow::show();
+ if (width()maxWidth)
+ normalGeometry_ = qtViewGeometry();
}
Index: src/frontends/qt3/QtView.h
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Bo Peng wrote:
But when you prefer the (-1,-1) solution I'll change it.
Since (-1, -1) will save a significant amount of coding, I prefer this.
Bo
Here the patch with above changes.
Hello Peter,
Thanks for the updated patch and sorry for the inconvenience that my
merging activity has caused to you.
Please find my comments below. Don't take them personally please and
feel free to contradict me if you think I'm wrong.
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Peter
Index: src/frontends/qt3/lyx_gui.C
===
- boost::shared_ptrQtView view_ptr(new QtView(width, height));
+ boost::shared_ptrQtView view_ptr(new QtView);
Note that in my next cleanup round I will move the QtView creation from
lyx_gui to GuiImplementation.
LyX::ref().addLyXView(view_ptr);
QtView view = *view_ptr.get();
- if (posx != -1 posy != -1)
- view.move(QPoint(posx, posy));
+ view.init();
+ if (width != -1 height != -1 posx != -1 posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
+ view.show();
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ }
+
view.show();
- view.init();
So you don't need LyXView::init() anymore or is it done elsewhere?
// FIXME: some code below needs moving
Index: src/frontends/qt3/QtView.C
===
--- src/frontends/qt3/QtView.C (revision 14157)
+++ src/frontends/qt3/QtView.C (working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp-setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,62 @@
return qApp-activeWindow() == this;
}
+void QtView::initNormalGeometry(const QRect g)
+void QtView::resetGeometry(const QRect g)
+{
+ normalGeometry_ = g;
+ maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() maxWidth) {
+ maxWidth = width();
+ return;
+ }
+ if (frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
+
+ std::coutmaxWidth-normalGeometry_.width(), resizeEvent
:normalGeometry_.x()\n;
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ if (width() maxWidth frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
This is just for updating x and y position isn't it? Why do we need that
by the way? Because you want to save this in the session info as well. I
guess it make sense on Windows but won't this clash with Window manager
that do this under X11?
Index: src/frontends/qt4/lyx_gui.C
===
--- src/frontends/qt4/lyx_gui.C (revision 14157)
+++ src/frontends/qt4/lyx_gui.C (working copy)
@@ -194,15 +194,22 @@
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptrGuiView view_ptr(new GuiView(width, height));
+ boost::shared_ptrGuiView view_ptr(new GuiView);
+
LyX::ref().addLyXView(view_ptr);
GuiView view = *view_ptr.get();
view.init();
-
- if (posx != -1 posy != -1) {
+
+ if (width != -1 height != -1 posx != -1 posy != -1) {
+#ifndef Q_OS_WIN32
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#else
view.setGeometry(posx, posy,
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Bo Peng wrote:
But when you prefer the (-1,-1) solution I'll change it.
Since (-1, -1) will save a significant amount of coding, I prefer this.
Bo
Here the patch with above changes.
Hello Peter,
Thanks for the updated patch and sorry for the inconvenience that my
merging activity has caused to you.
No problem, thanks for your hard work improving the code base.
Please find my comments below. Don't take them personally please and
feel free to contradict me if you think I'm wrong.
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Peter
Index: src/frontends/qt3/lyx_gui.C
===
-boost::shared_ptrQtView view_ptr(new QtView(width, height));
+boost::shared_ptrQtView view_ptr(new QtView);
Note that in my next cleanup round I will move the QtView creation from
lyx_gui to GuiImplementation.
LyX::ref().addLyXView(view_ptr);
QtView view = *view_ptr.get();
-if (posx != -1 posy != -1)
-view.move(QPoint(posx, posy));
+view.init();
+if (width != -1 height != -1 posx != -1 posy != -1) {
+view.initNormalGeometry(QRect(posx, posy, width, height));
+view.resize(width, height);
+view.move(posx, posy);
+if (maximize)
+{
+view.show();
+view.setWindowState(Qt::WindowMaximized);
+}
+}
+
view.show();
-view.init();
So you don't need LyXView::init() anymore or is it done elsewhere?
before the if (width ...
I think it makes more sense to initialize before showing and resizing.
// FIXME: some code below needs moving
Index: src/frontends/qt3/QtView.C
===
--- src/frontends/qt3/QtView.C(revision 14157)
+++ src/frontends/qt3/QtView.C(working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp-setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,62 @@
return qApp-activeWindow() == this;
}
+void QtView::initNormalGeometry(const QRect g)
+void QtView::resetGeometry(const QRect g)
The functionality of most code here is to have a valid not-maximized geometry:
the normal geometry.
initNormalGeometry does not change the geometry of the window, it's part
of the workaround for the missing normal/maximized functionality on x11/qt3,
so I think 'normal' is still a good choice for the naming.
+{
+normalGeometry_ = g;
+maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
Yes, that's better.
+{
+QRect rec;
+// setX/Y changes the size!
+rec.setX(frameGeometry().x());
+rec.setY(frameGeometry().y());
+rec.setWidth(geometry().width());
+rec.setHeight(geometry().height());
+return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+if (width() maxWidth) {
+maxWidth = width();
+return;
+}
+if (frameGeometry().x() 0)
+normalGeometry_ = qtViewGeometry();
+
+std::coutmaxWidth-normalGeometry_.width(), resizeEvent
:normalGeometry_.x()\n;
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+if (width() maxWidth frameGeometry().x() 0)
+normalGeometry_ = qtViewGeometry();
This is just for updating x and y position isn't it? Why do we need that
by the way? Because you want to save this in the session info as well. I
guess it make sense on Windows but won't this clash with Window manager
that do this under X11?
Here I update the normal size and position which should be saved when
lyx is closed in a maximized status. normalGeometry_ must not be overwritten
by values of the maximized window, therefore the if.
X11/qt3 does not provide the normal size of a maximized windows, because of
this all the code here.
Index:
Re: Qt4 frontend save/restore geoemtry patch
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp-setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
Having an additional look at the docs, it seems I was wrong. But
I had no problems with this code, as you explained.
Peter
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp-setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
Having an additional look at the docs, it seems I was wrong. But
I had no problems with this code, as you explained.
Peter
I think we should use QMainWindow::centralWidget().width/height instead.
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Abdelrazak Younes wrote:
view.show();
-view.init();
So you don't need LyXView::init() anymore or is it done elsewhere?
before the if (width ...
I think it makes more sense to initialize before showing and resizing.
Of course yes. I haven't seen it.
// FIXME: some code below needs moving
Index: src/frontends/qt3/QtView.C
===
--- src/frontends/qt3/QtView.C(revision 14157)
+++ src/frontends/qt3/QtView.C(working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp-setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
Hum, frameGeometry doesn't include the Window Title but it still
include menubar and toolbar IIUC so I guess I am still right :-)
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,62 @@
return qApp-activeWindow() == this;
}
+void QtView::initNormalGeometry(const QRect g)
+void QtView::resetGeometry(const QRect g)
The functionality of most code here is to have a valid not-maximized geometry:
the normal geometry.
initNormalGeometry does not change the geometry of the window, it's part
of the workaround for the missing normal/maximized functionality on x11/qt3,
so I think 'normal' is still a good choice for the naming.
Hum, we are talking about floating window geometry right? Why do you
think about floatingGeometry_ instead of normalGeometry and
setFloatingGeometry() instead of initNormalGeometry() ?
+{
+normalGeometry_ = g;
+maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
Yes, that's better.
or even better :
+QRect QtView::geometry() const
+void QtView::moveEvent(QMoveEvent *)
+{
+if (width() maxWidth frameGeometry().x() 0)
+normalGeometry_ = qtViewGeometry();
This is just for updating x and y position isn't it? Why do we need that
by the way? Because you want to save this in the session info as well. I
guess it make sense on Windows but won't this clash with Window manager
that do this under X11?
Here I update the normal size and position which should be saved when
lyx is closed in a maximized status. normalGeometry_ must not be overwritten
by values of the maximized window, therefore the if.
I didn't questioned the if but the necessity of the moveEvent() method,
sorry for the confusion. I mean, if the objective is to save the
geometry on exit do that on the closeEvent. Or am I missing something here?
X11/qt3 does not provide the normal size of a maximized windows, because of
this all the code here.
OK.
+#ifndef Q_OS_WIN32
+// X11: use frameGeometry position
+view.setGeometry(0, 0, width, height);
+view.move(posx, posy);
+#else
view.setGeometry(posx, posy, width, height);
+#endif
if (maximize)
view.setWindowState(Qt::WindowMaximized);
I don't like the #ifndef at all. Why do we need them? Why only for qt4?
X11/qt4 is broken, we only need the workaround on X11. Most ifdefs could
be removed, but then we have some useless additional calls on windows, but this
isn't a big problem.
If it isn't harmful remove them please. Or, as I said, encapsulate them
in some helper function.
+#ifndef Q_OS_WIN32
+ ///
+ virtual void resizeEvent(QResizeEvent * e);
+
+ ///
+ virtual void moveEvent(QMoveEvent * e);
+#endif
Same here. IMO if these methods are really necessary define them in any
case. The #ifdef code in GuiView.C should then be encapsulated in some
helper functions somewhere that will set the geometry of QWidget
depending on the platform. Please understand that I've worked hard to
avoid special cases in general code and I don't want them to come back.
X11/Mac/WIn specific code should go in helper functions.
There's no problem removing the ifdefs. But I would prefer to have the
ifdef in the closeEvent implementation, it could be removed when TT has
fixed the issue.
OK, let them only in the closeEvent implementation but put a FIXME
explaining the issue there.
+// check for X11 -geometry option
+if (argv[i] == string(-geometry))
+
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Peter Kümmel wrote:
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp-setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
Having an additional look at the docs, it seems I was wrong. But
I had no problems with this code, as you explained.
Yes ;-)
Peter
I think we should use QMainWindow::centralWidget().width/height instead.
In this particular case, yes. But I would prefer to fix the problem at
the source: We don't need the width and height on BufferView creation.
My cleanup will fix that.
Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes wrote:
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
Hum, frameGeometry doesn't include the Window Title but it still
include menubar and toolbar IIUC so I guess I am still right :-)
Yes, I've realized it, see other mail.
The functionality of most code here is to have a valid not-maximized
geometry:
the normal geometry.
initNormalGeometry does not change the geometry of the window, it's part
of the workaround for the missing normal/maximized functionality on
x11/qt3,
so I think 'normal' is still a good choice for the naming.
Hum, we are talking about floating window geometry right? Why do you
think about floatingGeometry_ instead of normalGeometry and
setFloatingGeometry() instead of initNormalGeometry() ?
floating is also a good description, but 'normal' is the name TT uses for this
behavior
(showNormal, normalGeoemtry), sure we could use our own naming.
+{
+normalGeometry_ = g;
+maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
Yes, that's better.
or even better :
+QRect QtView::geometry() const
There is already QWidget::geometry, so maybe we should switch to
floatingGeometry.
+void QtView::moveEvent(QMoveEvent *)
+{
+if (width() maxWidth frameGeometry().x() 0)
+normalGeometry_ = qtViewGeometry();
This is just for updating x and y position isn't it? Why do we need that
by the way? Because you want to save this in the session info as well. I
guess it make sense on Windows but won't this clash with Window manager
that do this under X11?
Here I update the normal size and position which should be saved when
lyx is closed in a maximized status. normalGeometry_ must not be
overwritten
by values of the maximized window, therefore the if.
I didn't questioned the if but the necessity of the moveEvent() method,
sorry for the confusion. I mean, if the objective is to save the
geometry on exit do that on the closeEvent. Or am I missing something here?
The problem is that at the closeEvent the size and position of the
NOT maximized window is lost, we must remember it somehow, so we can use
it when saving the session data. It makes no sense to save the size/position
of the maximized window, this was the status before my patch.
When the miximized size and position is saved then clicking on the normalize
button of the window has no effect, the patch tries to fix this.
When the floating window is 1. moved, 2.maximized and then 3. closed, we have
no actual position without the moveEvent function, because resize is not called.
X11/qt3 does not provide the normal size of a maximized windows,
because of
this all the code here.
OK.
+#ifndef Q_OS_WIN32
+// X11: use frameGeometry position
+view.setGeometry(0, 0, width, height);
+view.move(posx, posy);
+#else
view.setGeometry(posx, posy, width, height);
+#endif
if (maximize)
view.setWindowState(Qt::WindowMaximized);
I don't like the #ifndef at all. Why do we need them? Why only for qt4?
X11/qt4 is broken, we only need the workaround on X11. Most ifdefs could
be removed, but then we have some useless additional calls on windows,
but this
isn't a big problem.
If it isn't harmful remove them please. Or, as I said, encapsulate them
in some helper function.
I'll remove them.
+#ifndef Q_OS_WIN32
+ ///
+ virtual void resizeEvent(QResizeEvent * e);
+
+ ///
+ virtual void moveEvent(QMoveEvent * e);
+#endif
Same here. IMO if these methods are really necessary define them in any
case. The #ifdef code in GuiView.C should then be encapsulated in some
helper functions somewhere that will set the geometry of QWidget
depending on the platform. Please understand that I've worked hard to
avoid special cases in general code and I don't want them to come back.
X11/Mac/WIn specific code should go in helper functions.
There's no problem removing the ifdefs. But I would prefer to have the
ifdef in the closeEvent implementation, it could be removed when TT has
fixed the issue.
OK, let them only in the closeEvent implementation but put a FIXME
explaining the issue there.
OK.
+// check for X11 -geometry option
+if (argv[i] == string(-geometry))
+geometryOption_ = true;
+
I have read somewhere that QApplication already understand this option.
How would this interact with your code here?
Qt4::QApplication handles the -geometry option in the ctor,
Qt3::QApplication handles it when calling setMainWidget.
So when we use Qt4 we must know if we should resize the window
after constructing, and therefore we must knowif
there was a geometry option.
By this way both front ends uses the same logic:
Construct with geoemtry size/pos (if any) and only resize/move
when there was no geometry
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes wrote:
Peter Kümmel wrote:
Peter Kümmel wrote:
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0),
frontend_(*this)
{
-resize(width, height);
-
qApp-setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size
of the
WorkArea but width() and height() will give you the size of the
window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size.
So I
guess that passing 100x100 or whatever will produce the same effect.
Having an additional look at the docs, it seems I was wrong. But
I had no problems with this code, as you explained.
Yes ;-)
Peter
I think we should use QMainWindow::centralWidget().width/height instead.
In this particular case, yes. But I would prefer to fix the problem at
the source: We don't need the width and height on BufferView creation.
My cleanup will fix that.
Yes, that is the best solution!
Peter
Re: Qt4 frontend save/restore geoemtry patch
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Thanks. I have not read what Abdel says about the patch. Here is mine:
- if (posx != -1 posy != -1)
- view.move(QPoint(posx, posy));
+ view.init();
+ if (width != -1 height != -1 posx != -1 posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
+ view.show();
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ }
+
view.show();
- view.init();
The logic is that width and height should work without valid posx, and
poxy. (saveGeometry controls that).
Also, why not move if(maximize) out of the scope? (view.show() called
twice). Something like:
view.show()
if max:
setWindowState.
+void QtView::initNormalGeometry(const QRect g)
+{
+ normalGeometry_ = g;
+ maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() maxWidth) {
+ maxWidth = width();
+ return;
+ }
+ if (frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
+
+ std::coutmaxWidth-normalGeometry_.width(), resizeEvent
:normalGeometry_.x()\n;
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ if (width() maxWidth frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
+ std::coutmaxWidth-normalGeometry_.width(), moveEvent
:normalGeometry_.x()\n;
+}
+
void QtView::closeEvent(QCloseEvent *)
{
+ QRect geometry;
+ std::coutmaxWidth:maxWidth\n;
+ std::coutnormalGeometry_: normalGeometry_.width()\n;
+ if (QWidget::geometry().width() maxWidth)
+ geometry = qtViewGeometry();
+ else
+ geometry = normalGeometry_;
+
+ std::coutcloseEvent : geometry.width() geometry.x()
\n\n;
+
Session session = LyX::ref().session();
session.saveSessionInfo(WindowIsMaximized, (isMaximized() ? yes :
no));
// save windows size and position
- session.saveSessionInfo(WindowWidth, convertstring(width()));
- session.saveSessionInfo(WindowHeight, convertstring(height()));
+ session.saveSessionInfo(WindowWidth,
convertstring(geometry.width()));
+ session.saveSessionInfo(WindowHeight,
convertstring(geometry.height()));
if (lyxrc.geometry_xysaved) {
- session.saveSessionInfo(WindowPosX, convertstring(x()));
- session.saveSessionInfo(WindowPosY, convertstring(y()));
+ session.saveSessionInfo(WindowPosX,
convertstring(geometry.x()));
+ session.saveSessionInfo(WindowPosY,
convertstring(geometry.y()));
}
// trigger LFUN_LYX_QUIT instead of quit directly
// since LFUN_LYX_QUIT may have more cleanup stuff
@@ -179,6 +222,8 @@
{
setCaption(qt_(LyX));
QMainWindow::show();
+ if (width()maxWidth)
+ normalGeometry_ = qtViewGeometry();
}
If I remember correctly, you said that geometry can only be correctly
traced in events like resize so you have to handle them. This makes
the code really long for this simple task. Is not there a way/hack to
do that in the close event, such as a hack in triggering resize? wide
guess though.
+ if (width != -1 height != -1 posx != -1 posy != -1) {
The same logic problem.
I will test the patch later.
Cheers,
Bo
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Hum, we are talking about floating window geometry right? Why do you
think about floatingGeometry_ instead of normalGeometry and
setFloatingGeometry() instead of initNormalGeometry() ?
floating is also a good description, but 'normal' is the name TT uses for this
behavior
(showNormal, normalGeoemtry), sure we could use our own naming.
I didn't know that. English is not my mother tongue but floating window
is more meaningful to me.
+{
+normalGeometry_ = g;
+maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
Yes, that's better.
or even better :
+QRect QtView::geometry() const
There is already QWidget::geometry, so maybe we should switch to
floatingGeometry.
I guess so ;-)
I didn't questioned the if but the necessity of the moveEvent() method,
sorry for the confusion. I mean, if the objective is to save the
geometry on exit do that on the closeEvent. Or am I missing something here?
The problem is that at the closeEvent the size and position of the
NOT maximized window is lost, we must remember it somehow, so we can use
it when saving the session data. It makes no sense to save the size/position
of the maximized window, this was the status before my patch.
When the miximized size and position is saved then clicking on the normalize
button of the window has no effect, the patch tries to fix this.
When the floating window is 1. moved, 2.maximized and then 3. closed, we have
no actual position without the moveEvent function, because resize is not called.
I understand, thanks.
Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Thanks. I have not read what Abdel says about the patch. Here is mine:
- if (posx != -1 posy != -1)
- view.move(QPoint(posx, posy));
+ view.init();
+ if (width != -1 height != -1 posx != -1 posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width,
height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
+ view.show();
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ }
+
view.show();
- view.init();
The logic is that width and height should work without valid posx, and
poxy. (saveGeometry controls that).
I wondered if there is a case where the width is saved but not the position,
couldn't the pos!=-1 be removed?
Also, why not move if(maximize) out of the scope? (view.show() called
twice). Something like:
view.show()
if max:
setWindowState.
+ view.resize(width, height);
+ view.move(posx, posy);
+ view.show();
+ if (maximize)
+ {
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ } else
+ view.show();
+
- view.init();
+void QtView::initNormalGeometry(const QRect g)
+{
+ normalGeometry_ = g;
+ maxWidth=QApplication::desktop()-width()-20;
+}
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() maxWidth) {
+ maxWidth = width();
+ return;
+ }
+ if (frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
+
+ std::coutmaxWidth-normalGeometry_.width(), resizeEvent
:normalGeometry_.x()\n;
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ if (width() maxWidth frameGeometry().x() 0)
+ normalGeometry_ = qtViewGeometry();
+ std::coutmaxWidth-normalGeometry_.width(), moveEvent
:normalGeometry_.x()\n;
+}
+
void QtView::closeEvent(QCloseEvent *)
{
+ QRect geometry;
+ std::coutmaxWidth:maxWidth\n;
+ std::coutnormalGeometry_: normalGeometry_.width()\n;
+ if (QWidget::geometry().width() maxWidth)
+ geometry = qtViewGeometry();
+ else
+ geometry = normalGeometry_;
+
+ std::coutcloseEvent : geometry.width()
geometry.x() \n\n;
+
Session session = LyX::ref().session();
session.saveSessionInfo(WindowIsMaximized, (isMaximized() ?
yes : no));
// save windows size and position
- session.saveSessionInfo(WindowWidth, convertstring(width()));
- session.saveSessionInfo(WindowHeight,
convertstring(height()));
+ session.saveSessionInfo(WindowWidth,
convertstring(geometry.width()));
+ session.saveSessionInfo(WindowHeight,
convertstring(geometry.height()));
if (lyxrc.geometry_xysaved) {
- session.saveSessionInfo(WindowPosX,
convertstring(x()));
- session.saveSessionInfo(WindowPosY,
convertstring(y()));
+ session.saveSessionInfo(WindowPosX,
convertstring(geometry.x()));
+ session.saveSessionInfo(WindowPosY,
convertstring(geometry.y()));
}
// trigger LFUN_LYX_QUIT instead of quit directly
// since LFUN_LYX_QUIT may have more cleanup stuff
@@ -179,6 +222,8 @@
{
setCaption(qt_(LyX));
QMainWindow::show();
+ if (width()maxWidth)
+ normalGeometry_ = qtViewGeometry();
}
If I remember correctly, you said that geometry can only be correctly
traced in events like resize so you have to handle them. This makes
the code really long for this simple task. Is not there a way/hack to
do that in the close event, such as a hack in triggering resize? wide
guess though.
Please read my answers to Abdel.
+ if (width != -1 height != -1 posx != -1 posy != -1) {
The same logic problem.
I will test the patch later.
Thanks!
Cheers,
Bo
Peter
Re: Qt4 frontend save/restore geoemtry patch
The logic is that width and height should work without valid posx, and
poxy. (saveGeometry controls that).
I wondered if there is a case where the width is saved but not the position,
couldn't the pos!=-1 be removed?
At least this was the original logic. Saving windows width/height is
safe, but not exactly windows position. For example, several
instantces of lyx might be launched overlapped.
I guess the logic should be:
if (width!=-1 and height!=-1)
{
if (posx != -1 and posy !=-1)
...
}
Bo
Re: Qt4 frontend save/restore geoemtry patch
Hi Abdel, Bo
here the next version with your embedded suggestions.
I've also simplified the floating code.
Peter
Index: frontends/qt3/lyx_gui.C
===
--- frontends/qt3/lyx_gui.C (revision 14157)
+++ frontends/qt3/lyx_gui.C (working copy)
@@ -222,22 +222,29 @@
void start(string const batch, vectorstring const files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptrQtView view_ptr(new QtView(width, height));
+ boost::shared_ptrQtView view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView view = *view_ptr.get();
- if (posx != -1 posy != -1)
- view.move(QPoint(posx, posy));
-
- view.show();
view.init();
+ if (width != -1 height != -1) {
+ view.initFloatingGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ if (posx != -1 posy != -1)
+ view.move(posx, posy);
+ view.show();
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ } else
+ view.show();
+
// FIXME: some code below needs moving
lyxserver = new LyXServer(view.getLyXFunc(), lyxrc.lyxpipes);
Index: frontends/qt3/QtView.C
===
--- frontends/qt3/QtView.C (revision 14157)
+++ frontends/qt3/QtView.C (working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp-setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,49 @@
return qApp-activeWindow() == this;
}
+void QtView::initFloatingGeometry(const QRect g)
+{
+ floatingGeometry_ = g;
+ maxWidth=QApplication::desktop()-width()-20;
+}
+void QtView::updateFloatingGeometry()
+{
+ if (width() maxWidth frameGeometry().x() 0)
+ {
+ // setX/Y changes the size!
+ floatingGeometry_.setX(x());
+ floatingGeometry_.setY(y());
+ floatingGeometry_.setWidth(width());
+ floatingGeometry_.setHeight(height());
+ }
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() maxWidth)
+ maxWidth = width();
+ updateFloatingGeometry();
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ updateFloatingGeometry();
+}
+
void QtView::closeEvent(QCloseEvent *)
{
+ updateFloatingGeometry();
+ QRect geometry = floatingGeometry_;
+
Session session = LyX::ref().session();
session.saveSessionInfo(WindowIsMaximized, (isMaximized() ? yes :
no));
// save windows size and position
- session.saveSessionInfo(WindowWidth, convertstring(width()));
- session.saveSessionInfo(WindowHeight, convertstring(height()));
+ session.saveSessionInfo(WindowWidth,
convertstring(geometry.width()));
+ session.saveSessionInfo(WindowHeight,
convertstring(geometry.height()));
if (lyxrc.geometry_xysaved) {
- session.saveSessionInfo(WindowPosX, convertstring(x()));
- session.saveSessionInfo(WindowPosY, convertstring(y()));
+ session.saveSessionInfo(WindowPosX,
convertstring(geometry.x()));
+ session.saveSessionInfo(WindowPosY,
convertstring(geometry.y()));
}
// trigger LFUN_LYX_QUIT instead of quit directly
// since LFUN_LYX_QUIT may have more cleanup stuff
@@ -179,6 +209,7 @@
{
setCaption(qt_(LyX));
QMainWindow::show();
+ updateFloatingGeometry();
}
Index: frontends/qt3/QtView.h
===
--- frontends/qt3/QtView.h (revision 14157)
+++ frontends/qt3/QtView.h (working copy)
@@ -38,8 +38,8 @@
class QtView : public QMainWindow, public LyXView {
Q_OBJECT
public:
- /// create a main window of the given dimensions
- QtView(unsigned int w, unsigned int h);
+ /// create a main window
+ QtView();
~QtView();
@@ -67,9 +67,19 @@
//
lyx::frontend::Gui gui() { return frontend_; }
+ ///
+ void initFloatingGeometry(const QRect );
+
public slots:
/// idle timeout
void update_view_state_qt();
+
+ ///
+ virtual void
Re: Qt4 frontend save/restore geoemtry patch
On 6/20/06, Peter Kümmel [EMAIL PROTECTED] wrote: Hi Abdel, Bo here the next version with your embedded suggestions. I've also simplified the floating code. Looks fine to me (others may have higher standard though). Is this patch against the trunk or some branch? I can not apply cleanly. Bo
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel [EMAIL PROTECTED] writes:
| Hi Abdel, Bo
|
| here the next version with your embedded suggestions.
| I've also simplified the floating code.
|
| Peter
| Index: frontends/qt3/QtView.C
| ===
| --- frontends/qt3/QtView.C(revision 14157)
| +++ frontends/qt3/QtView.C(working copy)
| @@ -157,17 +155,49 @@
| return qApp-activeWindow() == this;
| }
|
| +void QtView::initFloatingGeometry(const QRect g)
| +{
| + floatingGeometry_ = g;
| + maxWidth=QApplication::desktop()-width()-20;
Oooo... spacing.
| +}
|
| +void QtView::updateFloatingGeometry()
| +{
| + if (width() maxWidth frameGeometry().x() 0)
| + {
| + // setX/Y changes the size!
| + floatingGeometry_.setX(x());
| + floatingGeometry_.setY(y());
| + floatingGeometry_.setWidth(width());
| + floatingGeometry_.setHeight(height());
| + }
| +}
| +
| +void QtView::resizeEvent(QResizeEvent *)
| +{
| + if (width() maxWidth)
| + maxWidth = width();
maxWidth = max(width(), maxWidth);
| + updateFloatingGeometry();
| +}
| +
| +void QtView::moveEvent(QMoveEvent *)
| +{
| + updateFloatingGeometry();
| +}
| +
| void QtView::closeEvent(QCloseEvent *)
| {
| + updateFloatingGeometry();
| + QRect geometry = floatingGeometry_;
| +
| Session session = LyX::ref().session();
| session.saveSessionInfo(WindowIsMaximized, (isMaximized() ? yes :
no));
| // save windows size and position
| - session.saveSessionInfo(WindowWidth, convertstring(width()));
| - session.saveSessionInfo(WindowHeight, convertstring(height()));
| + session.saveSessionInfo(WindowWidth,
convertstring(geometry.width()));
| + session.saveSessionInfo(WindowHeight,
convertstring(geometry.height()));
| if (lyxrc.geometry_xysaved) {
| - session.saveSessionInfo(WindowPosX, convertstring(x()));
| - session.saveSessionInfo(WindowPosY, convertstring(y()));
| + session.saveSessionInfo(WindowPosX,
convertstring(geometry.x()));
| + session.saveSessionInfo(WindowPosY,
convertstring(geometry.y()));
| }
| // trigger LFUN_LYX_QUIT instead of quit directly
| // since LFUN_LYX_QUIT may have more cleanup stuff
| Index: frontends/qt3/QtView.h
| ===
| --- frontends/qt3/QtView.h(revision 14157)
| +++ frontends/qt3/QtView.h(working copy)
| @@ -67,9 +67,19 @@
| //
| lyx::frontend::Gui gui() { return frontend_; }
|
| + ///
| + void initFloatingGeometry(const QRect );
| +
QRect const
| Index: frontends/qt4/GuiView.C
| ===
| --- frontends/qt4/GuiView.C (revision 14157)
| +++ frontends/qt4/GuiView.C (working copy)
| @@ -176,12 +175,45 @@
| return qApp-activeWindow() == this;
| }
|
| +void GuiView::updateFloatingGeometry()
| +{
| + if (!isMaximized()) {
| + // setX/Y changes the size!
| + floatingGeometry_.setX(x()); // == frameGeometry().x()
| + floatingGeometry_.setY(y()); // == frameGeometry().y()
| + floatingGeometry_.setWidth(width()); // == geometry().width()
| + floatingGeometry_.setHeight(height());// == geometry().height()
| + }
| +}
What are the comments about?
| Index: lyx_main.C
| ===
| --- lyx_main.C(revision 14157)
| +++ lyx_main.C(working copy)
| @@ -995,6 +1002,10 @@
| std::mapstring, cmd_helper::const_iterator it
| = cmdmap.find(argv[i]);
|
| + // check for X11 -geometry option
| + if (argv[i] == string(-geometry))
| + geometryOption_ = true;
instead of useing the string(...) temporary style you can also use the
compare from lstring.h:
if (lyx::support::compare(argv[i], -geometry) == 0)
...
Then no conversion to std::string will be done at all, and compare is
an inline function.
--
Lgb
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
>> But when you prefer the (-1,-1) solution I'll change it.
>
> Since (-1, -1) will save a significant amount of coding, I prefer this.
>
> Bo
Here the patch with above changes.
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Peter
Index: src/frontends/qt3/lyx_gui.C
===
--- src/frontends/qt3/lyx_gui.C (revision 14157)
+++ src/frontends/qt3/lyx_gui.C (working copy)
@@ -222,21 +222,30 @@
void start(string const & batch, vector const & files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptr view_ptr(new QtView(width, height));
+ boost::shared_ptr view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView & view = *view_ptr.get();
- if (posx != -1 && posy != -1)
- view.move(QPoint(posx, posy));
+ view.init();
+ if (width != -1 && height != -1 && posx != -1 && posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
+ view.show();
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ }
+
view.show();
- view.init();
// FIXME: some code below needs moving
Index: src/frontends/qt3/QtView.C
===
--- src/frontends/qt3/QtView.C (revision 14157)
+++ src/frontends/qt3/QtView.C (working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp->setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,62 @@
return qApp->activeWindow() == this;
}
+void QtView::initNormalGeometry(const QRect & g)
+{
+ normalGeometry_ = g;
+ maxWidth=QApplication::desktop()->width()-20;
+}
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() > maxWidth) {
+ maxWidth = width();
+ return;
+ }
+ if (frameGeometry().x() > 0)
+ normalGeometry_ = qtViewGeometry();
+
+ std::cout< 0)
+ normalGeometry_ = qtViewGeometry();
+ std::cout<
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Bo Peng wrote:
But when you prefer the (-1,-1) solution I'll change it.
Since (-1, -1) will save a significant amount of coding, I prefer this.
Bo
Here the patch with above changes.
Hello Peter,
Thanks for the updated patch and sorry for the inconvenience that my
merging activity has caused to you.
Please find my comments below. Don't take them personally please and
feel free to contradict me if you think I'm wrong.
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Peter
Index: src/frontends/qt3/lyx_gui.C
===
- boost::shared_ptr view_ptr(new QtView(width, height));
+ boost::shared_ptr view_ptr(new QtView);
Note that in my next cleanup round I will move the QtView creation from
lyx_gui to GuiImplementation.
LyX::ref().addLyXView(view_ptr);
QtView & view = *view_ptr.get();
- if (posx != -1 && posy != -1)
- view.move(QPoint(posx, posy));
+ view.init();
+ if (width != -1 && height != -1 && posx != -1 && posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
+ view.show();
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ }
+
view.show();
- view.init();
So you don't need LyXView::init() anymore or is it done elsewhere?
// FIXME: some code below needs moving
Index: src/frontends/qt3/QtView.C
===
--- src/frontends/qt3/QtView.C (revision 14157)
+++ src/frontends/qt3/QtView.C (working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp->setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,62 @@
return qApp->activeWindow() == this;
}
+void QtView::initNormalGeometry(const QRect & g)
+void QtView::resetGeometry(const QRect & g)
+{
+ normalGeometry_ = g;
+ maxWidth=QApplication::desktop()->width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() > maxWidth) {
+ maxWidth = width();
+ return;
+ }
+ if (frameGeometry().x() > 0)
+ normalGeometry_ = qtViewGeometry();
+
+ std::cout< 0)
+ normalGeometry_ = qtViewGeometry();
This is just for updating x and y position isn't it? Why do we need that
by the way? Because you want to save this in the session info as well. I
guess it make sense on Windows but won't this clash with Window manager
that do this under X11?
Index: src/frontends/qt4/lyx_gui.C
===
--- src/frontends/qt4/lyx_gui.C (revision 14157)
+++ src/frontends/qt4/lyx_gui.C (working copy)
@@ -194,15 +194,22 @@
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptr view_ptr(new GuiView(width, height));
+ boost::shared_ptr view_ptr(new GuiView);
+
LyX::ref().addLyXView(view_ptr);
GuiView & view = *view_ptr.get();
view.init();
-
- if (posx != -1 && posy != -1) {
+
+ if (width != -1 && height != -1 && posx != -1 && posy != -1) {
+#ifndef Q_OS_WIN32
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#else
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Bo Peng wrote:
But when you prefer the (-1,-1) solution I'll change it.
>>> Since (-1, -1) will save a significant amount of coding, I prefer this.
>>>
>>> Bo
>>
>> Here the patch with above changes.
>
> Hello Peter,
>
> Thanks for the updated patch and sorry for the inconvenience that my
> merging activity has caused to you.
>
No problem, thanks for your hard work improving the code base.
> Please find my comments below. Don't take them personally please and
> feel free to contradict me if you think I'm wrong.
>
>
>> I've also implemented the patch for the qt3 frontend.
>> Now Qt3 and Qt4 are an par on Linux and Windows.
>> Diff against current svn.
>>
>> Peter
>>
>>
>>
>>
>>
>> Index: src/frontends/qt3/lyx_gui.C
>> ===
>
>> -boost::shared_ptr view_ptr(new QtView(width, height));
>> +boost::shared_ptr view_ptr(new QtView);
>
> Note that in my next cleanup round I will move the QtView creation from
> lyx_gui to GuiImplementation.
>
>> LyX::ref().addLyXView(view_ptr);
>>
>> QtView & view = *view_ptr.get();
>>
>> -if (posx != -1 && posy != -1)
>> -view.move(QPoint(posx, posy));
>> +view.init();
>>
>> +if (width != -1 && height != -1 && posx != -1 && posy != -1) {
>> +view.initNormalGeometry(QRect(posx, posy, width, height));
>> +view.resize(width, height);
>> +view.move(posx, posy);
>> +if (maximize)
>> +{
>> +view.show();
>> +view.setWindowState(Qt::WindowMaximized);
>> +}
>> +}
>> +
>> view.show();
>> -view.init();
>
> So you don't need LyXView::init() anymore or is it done elsewhere?
before the if (width ...
I think it makes more sense to initialize before showing and resizing.
>
>>
>> // FIXME: some code below needs moving
>>
>> Index: src/frontends/qt3/QtView.C
>> ===
>> --- src/frontends/qt3/QtView.C(revision 14157)
>> +++ src/frontends/qt3/QtView.C(working copy)
>>
>> @@ -55,14 +55,12 @@
>>
>>
>>
>> -QtView::QtView(unsigned int width, unsigned int height)
>> +QtView::QtView()
>> : QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
>> {
>> -resize(width, height);
>> -
>> qApp->setMainWidget(this);
>>
>> -bufferview_.reset(new BufferView(this, width, height));
>> +bufferview_.reset(new BufferView(this, width(), height()));
>
> I think there might be a problem there. BufferView needs the size of the
> WorkArea but width() and height() will give you the size of the window,
> including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
> But I guess this is OK now because a resize event will happen just
> afterward and readjust the BufferView to the proper WorkArea size. So I
> guess that passing 100x100 or whatever will produce the same effect.
>
>>
>> menubar_.reset(new QLMenubar(this, menubackend));
>> getToolbars().init();
>> @@ -157,17 +155,62 @@
>> return qApp->activeWindow() == this;
>> }
>>
>> +void QtView::initNormalGeometry(const QRect & g)
>
> +void QtView::resetGeometry(const QRect & g)
>
The functionality of most code here is to have a valid not-maximized geometry:
the normal geometry.
initNormalGeometry does not change the geometry of the window, it's part
of the workaround for the missing normal/maximized functionality on x11/qt3,
so I think 'normal' is still a good choice for the naming.
>> +{
>> +normalGeometry_ = g;
>> +maxWidth=QApplication::desktop()->width()-20;
>> +}
>>
>> +QRect QtView::qtViewGeometry() const
>
> +QRect QtView::getGeometry() const
>
Yes, that's better.
>> +{
>> +QRect rec;
>> +// setX/Y changes the size!
>> +rec.setX(frameGeometry().x());
>> +rec.setY(frameGeometry().y());
>> +rec.setWidth(geometry().width());
>> +rec.setHeight(geometry().height());
>> +return rec;
>> +}
>> +
>> +void QtView::resizeEvent(QResizeEvent *)
>> +{
>> +if (width() > maxWidth) {
>> +maxWidth = width();
>> +return;
>> +}
>> +if (frameGeometry().x() > 0)
>> +normalGeometry_ = qtViewGeometry();
>> +
>> +std::cout<> :"<> +}
>> +
>> +void QtView::moveEvent(QMoveEvent *)
>> +{
>> +if (width() < maxWidth && frameGeometry().x() > 0)
>> +normalGeometry_ = qtViewGeometry();
>
> This is just for updating x and y position isn't it? Why do we need that
> by the way? Because you want to save this in the session info as well. I
> guess it make sense on Windows but won't this clash with Window manager
> that do this under X11?
>
Here I update the normal size and position which
Re: Qt4 frontend save/restore geoemtry patch
>>> -QtView::QtView(unsigned int width, unsigned int height)
>>> +QtView::QtView()
>>> : QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
>>> {
>>> -resize(width, height);
>>> -
>>> qApp->setMainWidget(this);
>>>
>>> -bufferview_.reset(new BufferView(this, width, height));
>>> +bufferview_.reset(new BufferView(this, width(), height()));
>> I think there might be a problem there. BufferView needs the size of the
>> WorkArea but width() and height() will give you the size of the window,
>> including menubar and toolbars.
>
> No, this is given by frameGeometry, see
> http://doc.trolltech.com/4.1/geometry.html
> same for Qt3
>
>> But I guess this is OK now because a resize event will happen just
>> afterward and readjust the BufferView to the proper WorkArea size. So I
>> guess that passing 100x100 or whatever will produce the same effect.
Having an additional look at the docs, it seems I was wrong. But
I had no problems with this code, as you explained.
Peter
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp->setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
>>> I think there might be a problem there. BufferView needs the size of the
>>> WorkArea but width() and height() will give you the size of the window,
>>> including menubar and toolbars.
>> No, this is given by frameGeometry, see
>> http://doc.trolltech.com/4.1/geometry.html
>> same for Qt3
>>
>>> But I guess this is OK now because a resize event will happen just
>>> afterward and readjust the BufferView to the proper WorkArea size. So I
>>> guess that passing 100x100 or whatever will produce the same effect.
>
> Having an additional look at the docs, it seems I was wrong. But
> I had no problems with this code, as you explained.
>
> Peter
I think we should use QMainWindow::centralWidget().width/height instead.
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Abdelrazak Younes wrote:
view.show();
-view.init();
So you don't need LyXView::init() anymore or is it done elsewhere?
before the if (width ...
I think it makes more sense to initialize before showing and resizing.
Of course yes. I haven't seen it.
// FIXME: some code below needs moving
Index: src/frontends/qt3/QtView.C
===
--- src/frontends/qt3/QtView.C(revision 14157)
+++ src/frontends/qt3/QtView.C(working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp->setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
Hum, frameGeometry doesn't include the "Window Title" but it still
include menubar and toolbar IIUC so I guess I am still right :-)
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,62 @@
return qApp->activeWindow() == this;
}
+void QtView::initNormalGeometry(const QRect & g)
+void QtView::resetGeometry(const QRect & g)
The functionality of most code here is to have a valid not-maximized geometry:
the normal geometry.
initNormalGeometry does not change the geometry of the window, it's part
of the workaround for the missing normal/maximized functionality on x11/qt3,
so I think 'normal' is still a good choice for the naming.
Hum, we are talking about floating window geometry right? Why do you
think about floatingGeometry_ instead of normalGeometry and
setFloatingGeometry() instead of initNormalGeometry() ?
+{
+normalGeometry_ = g;
+maxWidth=QApplication::desktop()->width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
Yes, that's better.
or even better :
+QRect QtView::geometry() const
+void QtView::moveEvent(QMoveEvent *)
+{
+if (width() < maxWidth && frameGeometry().x() > 0)
+normalGeometry_ = qtViewGeometry();
This is just for updating x and y position isn't it? Why do we need that
by the way? Because you want to save this in the session info as well. I
guess it make sense on Windows but won't this clash with Window manager
that do this under X11?
Here I update the normal size and position which should be saved when
lyx is closed in a maximized status. normalGeometry_ must not be overwritten
by values of the maximized window, therefore the if.
I didn't questioned the if but the necessity of the moveEvent() method,
sorry for the confusion. I mean, if the objective is to save the
geometry on exit do that on the closeEvent. Or am I missing something here?
X11/qt3 does not provide the normal size of a maximized windows, because of
this all the code here.
OK.
+#ifndef Q_OS_WIN32
+// X11: use frameGeometry position
+view.setGeometry(0, 0, width, height);
+view.move(posx, posy);
+#else
view.setGeometry(posx, posy, width, height);
+#endif
if (maximize)
view.setWindowState(Qt::WindowMaximized);
I don't like the #ifndef at all. Why do we need them? Why only for qt4?
X11/qt4 is broken, we only need the workaround on X11. Most ifdefs could
be removed, but then we have some useless additional calls on windows, but this
isn't a big problem.
If it isn't harmful remove them please. Or, as I said, encapsulate them
in some helper function.
+#ifndef Q_OS_WIN32
+ ///
+ virtual void resizeEvent(QResizeEvent * e);
+
+ ///
+ virtual void moveEvent(QMoveEvent * e);
+#endif
Same here. IMO if these methods are really necessary define them in any
case. The #ifdef code in GuiView.C should then be encapsulated in some
helper functions somewhere that will set the geometry of QWidget
depending on the platform. Please understand that I've worked hard to
avoid special cases in general code and I don't want them to come back.
X11/Mac/WIn specific code should go in helper functions.
There's no problem removing the ifdefs. But I would prefer to have the
ifdef in the closeEvent implementation, it could be removed when TT has
fixed the issue.
OK, let them only in the closeEvent implementation but put a FIXME
explaining the issue there.
+// check for X11 -geometry option
+if (argv[i] ==
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Peter Kümmel wrote:
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp->setMainWidget(this);
-bufferview_.reset(new BufferView(this, width, height));
+bufferview_.reset(new BufferView(this, width(), height()));
I think there might be a problem there. BufferView needs the size of the
WorkArea but width() and height() will give you the size of the window,
including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
But I guess this is OK now because a resize event will happen just
afterward and readjust the BufferView to the proper WorkArea size. So I
guess that passing 100x100 or whatever will produce the same effect.
Having an additional look at the docs, it seems I was wrong. But
I had no problems with this code, as you explained.
Yes ;-)
Peter
I think we should use QMainWindow::centralWidget().width/height instead.
In this particular case, yes. But I would prefer to fix the problem at
the source: We don't need the width and height on BufferView creation.
My cleanup will fix that.
Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes wrote:
>> No, this is given by frameGeometry, see
>> http://doc.trolltech.com/4.1/geometry.html
>> same for Qt3
>
> Hum, frameGeometry doesn't include the "Window Title" but it still
> include menubar and toolbar IIUC so I guess I am still right :-)
Yes, I've realized it, see other mail.
>>
>> The functionality of most code here is to have a valid not-maximized
>> geometry:
>> the normal geometry.
>> initNormalGeometry does not change the geometry of the window, it's part
>> of the workaround for the missing normal/maximized functionality on
>> x11/qt3,
>> so I think 'normal' is still a good choice for the naming.
>
> Hum, we are talking about floating window geometry right? Why do you
> think about floatingGeometry_ instead of normalGeometry and
> setFloatingGeometry() instead of initNormalGeometry() ?
floating is also a good description, but 'normal' is the name TT uses for this
behavior
(showNormal, normalGeoemtry), sure we could use our own naming.
>>
+{
+normalGeometry_ = g;
+maxWidth=QApplication::desktop()->width()-20;
+}
+QRect QtView::qtViewGeometry() const
>>> +QRect QtView::getGeometry() const
>>>
>>
>> Yes, that's better.
>
> or even better :
>
> +QRect QtView::geometry() const
>
There is already QWidget::geometry, so maybe we should switch to
floatingGeometry.
>
+void QtView::moveEvent(QMoveEvent *)
+{
+if (width() < maxWidth && frameGeometry().x() > 0)
+normalGeometry_ = qtViewGeometry();
>>> This is just for updating x and y position isn't it? Why do we need that
>>> by the way? Because you want to save this in the session info as well. I
>>> guess it make sense on Windows but won't this clash with Window manager
>>> that do this under X11?
>>>
>>
>> Here I update the normal size and position which should be saved when
>> lyx is closed in a maximized status. normalGeometry_ must not be
>> overwritten
>> by values of the maximized window, therefore the if.
>
> I didn't questioned the if but the necessity of the moveEvent() method,
> sorry for the confusion. I mean, if the objective is to save the
> geometry on exit do that on the closeEvent. Or am I missing something here?
>
The problem is that at the closeEvent the size and position of the
NOT maximized window is lost, we must remember it somehow, so we can use
it when saving the session data. It makes no sense to save the size/position
of the maximized window, this was the status before my patch.
When the miximized size and position is saved then clicking on the "normalize"
button of the window has no effect, the patch tries to fix this.
When the floating window is 1. moved, 2.maximized and then 3. closed, we have
no actual position without the moveEvent function, because resize is not called.
>
>>
>> X11/qt3 does not provide the normal size of a maximized windows,
>> because of
>> this all the code here.
>
> OK.
>
>
+#ifndef Q_OS_WIN32
+// X11: use frameGeometry position
+view.setGeometry(0, 0, width, height);
+view.move(posx, posy);
+#else
view.setGeometry(posx, posy, width, height);
+#endif
if (maximize)
view.setWindowState(Qt::WindowMaximized);
>>> I don't like the #ifndef at all. Why do we need them? Why only for qt4?
>>>
>>
>> X11/qt4 is broken, we only need the workaround on X11. Most ifdefs could
>> be removed, but then we have some useless additional calls on windows,
>> but this
>> isn't a big problem.
>
> If it isn't harmful remove them please. Or, as I said, encapsulate them
> in some helper function.
>
I'll remove them.
>
+#ifndef Q_OS_WIN32
+ ///
+ virtual void resizeEvent(QResizeEvent * e);
+
+ ///
+ virtual void moveEvent(QMoveEvent * e);
+#endif
>>> Same here. IMO if these methods are really necessary define them in any
>>> case. The #ifdef code in GuiView.C should then be encapsulated in some
>>> helper functions somewhere that will set the geometry of QWidget
>>> depending on the platform. Please understand that I've worked hard to
>>> avoid special cases in general code and I don't want them to come back.
>>> X11/Mac/WIn specific code should go in helper functions.
>>>
>>
>> There's no problem removing the ifdefs. But I would prefer to have the
>> ifdef in the closeEvent implementation, it could be removed when TT has
>> fixed the issue.
>
> OK, let them only in the closeEvent implementation but put a FIXME
> explaining the issue there.
>
>
OK.
+// check for X11 -geometry option
+if (argv[i] == string("-geometry"))
+geometryOption_ = true;
+
>>> I have read somewhere that QApplication already understand this option.
>>> How would this interact with your code here?
>>>
>>
>> Qt4::QApplication handles the -geometry option in the ctor,
>> Qt3::QApplication handles it when calling
Re: Qt4 frontend save/restore geoemtry patch
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Peter Kümmel wrote:
>> -QtView::QtView(unsigned int width, unsigned int height)
>> +QtView::QtView()
>> : QMainWindow(), LyXView(), commandbuffer_(0),
>> frontend_(*this)
>> {
>> -resize(width, height);
>> -
>> qApp->setMainWidget(this);
>>
>> -bufferview_.reset(new BufferView(this, width, height));
>> +bufferview_.reset(new BufferView(this, width(), height()));
> I think there might be a problem there. BufferView needs the size
> of the
> WorkArea but width() and height() will give you the size of the
> window,
> including menubar and toolbars.
No, this is given by frameGeometry, see
http://doc.trolltech.com/4.1/geometry.html
same for Qt3
> But I guess this is OK now because a resize event will happen just
> afterward and readjust the BufferView to the proper WorkArea size.
> So I
> guess that passing 100x100 or whatever will produce the same effect.
>>> Having an additional look at the docs, it seems I was wrong. But
>>> I had no problems with this code, as you explained.
>
> Yes ;-)
>
>>>
>>> Peter
>>
>> I think we should use QMainWindow::centralWidget().width/height instead.
>
> In this particular case, yes. But I would prefer to fix the problem at
> the source: We don't need the width and height on BufferView creation.
> My cleanup will fix that.
Yes, that is the best solution!
Peter
Re: Qt4 frontend save/restore geoemtry patch
I've also implemented the patch for the qt3 frontend.
Now Qt3 and Qt4 are an par on Linux and Windows.
Diff against current svn.
Thanks. I have not read what Abdel says about the patch. Here is mine:
- if (posx != -1 && posy != -1)
- view.move(QPoint(posx, posy));
+ view.init();
+ if (width != -1 && height != -1 && posx != -1 && posy != -1) {
+ view.initNormalGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ view.move(posx, posy);
+ if (maximize)
+ {
+ view.show();
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ }
+
view.show();
- view.init();
The logic is that width and height should work without valid posx, and
poxy. (saveGeometry controls that).
Also, why not move if(maximize) out of the scope? (view.show() called
twice). Something like:
view.show()
if max:
setWindowState.
+void QtView::initNormalGeometry(const QRect & g)
+{
+ normalGeometry_ = g;
+ maxWidth=QApplication::desktop()->width()-20;
+}
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() > maxWidth) {
+ maxWidth = width();
+ return;
+ }
+ if (frameGeometry().x() > 0)
+ normalGeometry_ = qtViewGeometry();
+
+ std::cout< 0)
+ normalGeometry_ = qtViewGeometry();
+ std::cout<
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Hum, we are talking about floating window geometry right? Why do you
think about floatingGeometry_ instead of normalGeometry and
setFloatingGeometry() instead of initNormalGeometry() ?
floating is also a good description, but 'normal' is the name TT uses for this
behavior
(showNormal, normalGeoemtry), sure we could use our own naming.
I didn't know that. English is not my mother tongue but floating window
is more meaningful to me.
+{
+normalGeometry_ = g;
+maxWidth=QApplication::desktop()->width()-20;
+}
+QRect QtView::qtViewGeometry() const
+QRect QtView::getGeometry() const
Yes, that's better.
or even better :
+QRect QtView::geometry() const
There is already QWidget::geometry, so maybe we should switch to
floatingGeometry.
I guess so ;-)
I didn't questioned the if but the necessity of the moveEvent() method,
sorry for the confusion. I mean, if the objective is to save the
geometry on exit do that on the closeEvent. Or am I missing something here?
The problem is that at the closeEvent the size and position of the
NOT maximized window is lost, we must remember it somehow, so we can use
it when saving the session data. It makes no sense to save the size/position
of the maximized window, this was the status before my patch.
When the miximized size and position is saved then clicking on the "normalize"
button of the window has no effect, the patch tries to fix this.
When the floating window is 1. moved, 2.maximized and then 3. closed, we have
no actual position without the moveEvent function, because resize is not called.
I understand, thanks.
Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
>> I've also implemented the patch for the qt3 frontend.
>> Now Qt3 and Qt4 are an par on Linux and Windows.
>> Diff against current svn.
>
> Thanks. I have not read what Abdel says about the patch. Here is mine:
>
>> - if (posx != -1 && posy != -1)
>> - view.move(QPoint(posx, posy));
>> + view.init();
>>
>> + if (width != -1 && height != -1 && posx != -1 && posy != -1) {
>> + view.initNormalGeometry(QRect(posx, posy, width,
>> height));
>> + view.resize(width, height);
>> + view.move(posx, posy);
>> + if (maximize)
>> + {
>> + view.show();
>> + view.setWindowState(Qt::WindowMaximized);
>> + }
>> + }
>> +
>> view.show();
>> - view.init();
>
> The logic is that width and height should work without valid posx, and
> poxy. (saveGeometry controls that).
I wondered if there is a case where the width is saved but not the position,
couldn't the pos!=-1 be removed?
> Also, why not move if(maximize) out of the scope? (view.show() called
> twice). Something like:
> view.show()
> if max:
> setWindowState.
>
+ view.resize(width, height);
+ view.move(posx, posy);
+ view.show();
+ if (maximize)
+ {
+ view.setWindowState(Qt::WindowMaximized);
+ }
+ } else
+ view.show();
+
- view.init();
>> +void QtView::initNormalGeometry(const QRect & g)
>> +{
>> + normalGeometry_ = g;
>> + maxWidth=QApplication::desktop()->width()-20;
>> +}
>>
>> +QRect QtView::qtViewGeometry() const
>> +{
>> + QRect rec;
>> + // setX/Y changes the size!
>> + rec.setX(frameGeometry().x());
>> + rec.setY(frameGeometry().y());
>> + rec.setWidth(geometry().width());
>> + rec.setHeight(geometry().height());
>> + return rec;
>> +}
>> +
>> +void QtView::resizeEvent(QResizeEvent *)
>> +{
>> + if (width() > maxWidth) {
>> + maxWidth = width();
>> + return;
>> + }
>> + if (frameGeometry().x() > 0)
>> + normalGeometry_ = qtViewGeometry();
>> +
>> + std::cout<> :"<> +}
>> +
>> +void QtView::moveEvent(QMoveEvent *)
>> +{
>> + if (width() < maxWidth && frameGeometry().x() > 0)
>> + normalGeometry_ = qtViewGeometry();
>> + std::cout<> :"<> +}
>> +
>> void QtView::closeEvent(QCloseEvent *)
>> {
>> + QRect geometry;
>> + std::cout<<"maxWidth:"<> + std::cout<<"normalGeometry_: "<> + if (QWidget::geometry().width() < maxWidth)
>> + geometry = qtViewGeometry();
>> + else
>> + geometry = normalGeometry_;
>> +
>> + std::cout<<"closeEvent : "<> "<> +
>> Session & session = LyX::ref().session();
>> session.saveSessionInfo("WindowIsMaximized", (isMaximized() ?
>> "yes" : "no"));
>> // save windows size and position
>> - session.saveSessionInfo("WindowWidth", convert(width()));
>> - session.saveSessionInfo("WindowHeight",
>> convert(height()));
>> + session.saveSessionInfo("WindowWidth",
>> convert(geometry.width()));
>> + session.saveSessionInfo("WindowHeight",
>> convert(geometry.height()));
>> if (lyxrc.geometry_xysaved) {
>> - session.saveSessionInfo("WindowPosX",
>> convert(x()));
>> - session.saveSessionInfo("WindowPosY",
>> convert(y()));
>> + session.saveSessionInfo("WindowPosX",
>> convert(geometry.x()));
>> + session.saveSessionInfo("WindowPosY",
>> convert(geometry.y()));
>> }
>> // trigger LFUN_LYX_QUIT instead of quit directly
>> // since LFUN_LYX_QUIT may have more cleanup stuff
>> @@ -179,6 +222,8 @@
>> {
>> setCaption(qt_("LyX"));
>> QMainWindow::show();
>> + if (width()> + normalGeometry_ = qtViewGeometry();
>> }
>>
>
> If I remember correctly, you said that geometry can only be correctly
> traced in events like resize so you have to handle them. This makes
> the code really long for this simple task. Is not there a way/hack to
> do that in the close event, such as a hack in triggering resize? wide
> guess though.
>
Please read my answers to Abdel.
>> + if (width != -1 && height != -1 && posx != -1 && posy != -1) {
>
> The same logic problem.
>
> I will test the patch later.
>
Thanks!
> Cheers,
> Bo
>
>
Peter
Re: Qt4 frontend save/restore geoemtry patch
> The logic is that width and height should work without valid posx, and
> poxy. (saveGeometry controls that).
I wondered if there is a case where the width is saved but not the position,
couldn't the pos!=-1 be removed?
At least this was the original logic. Saving windows width/height is
safe, but not exactly windows position. For example, several
instantces of lyx might be launched overlapped.
I guess the logic should be:
if (width!=-1 and height!=-1)
{
if (posx != -1 and posy !=-1)
...
}
Bo
Re: Qt4 frontend save/restore geoemtry patch
Hi Abdel, Bo
here the next version with your embedded suggestions.
I've also simplified the floating code.
Peter
Index: frontends/qt3/lyx_gui.C
===
--- frontends/qt3/lyx_gui.C (revision 14157)
+++ frontends/qt3/lyx_gui.C (working copy)
@@ -222,22 +222,29 @@
void start(string const & batch, vector const & files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptr view_ptr(new QtView(width, height));
+ boost::shared_ptr view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView & view = *view_ptr.get();
- if (posx != -1 && posy != -1)
- view.move(QPoint(posx, posy));
-
- view.show();
view.init();
+ if (width != -1 && height != -1) {
+ view.initFloatingGeometry(QRect(posx, posy, width, height));
+ view.resize(width, height);
+ if (posx != -1 && posy != -1)
+ view.move(posx, posy);
+ view.show();
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ } else
+ view.show();
+
// FIXME: some code below needs moving
lyxserver = new LyXServer((), lyxrc.lyxpipes);
Index: frontends/qt3/QtView.C
===
--- frontends/qt3/QtView.C (revision 14157)
+++ frontends/qt3/QtView.C (working copy)
@@ -55,14 +55,12 @@
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
- resize(width, height);
-
qApp->setMainWidget(this);
- bufferview_.reset(new BufferView(this, width, height));
+ bufferview_.reset(new BufferView(this, width(), height()));
menubar_.reset(new QLMenubar(this, menubackend));
getToolbars().init();
@@ -157,17 +155,49 @@
return qApp->activeWindow() == this;
}
+void QtView::initFloatingGeometry(const QRect & g)
+{
+ floatingGeometry_ = g;
+ maxWidth=QApplication::desktop()->width()-20;
+}
+void QtView::updateFloatingGeometry()
+{
+ if (width() < maxWidth && frameGeometry().x() > 0)
+ {
+ // setX/Y changes the size!
+ floatingGeometry_.setX(x());
+ floatingGeometry_.setY(y());
+ floatingGeometry_.setWidth(width());
+ floatingGeometry_.setHeight(height());
+ }
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if (width() > maxWidth)
+ maxWidth = width();
+ updateFloatingGeometry();
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ updateFloatingGeometry();
+}
+
void QtView::closeEvent(QCloseEvent *)
{
+ updateFloatingGeometry();
+ QRect geometry = floatingGeometry_;
+
Session & session = LyX::ref().session();
session.saveSessionInfo("WindowIsMaximized", (isMaximized() ? "yes" :
"no"));
// save windows size and position
- session.saveSessionInfo("WindowWidth", convert(width()));
- session.saveSessionInfo("WindowHeight", convert(height()));
+ session.saveSessionInfo("WindowWidth",
convert(geometry.width()));
+ session.saveSessionInfo("WindowHeight",
convert(geometry.height()));
if (lyxrc.geometry_xysaved) {
- session.saveSessionInfo("WindowPosX", convert(x()));
- session.saveSessionInfo("WindowPosY", convert(y()));
+ session.saveSessionInfo("WindowPosX",
convert(geometry.x()));
+ session.saveSessionInfo("WindowPosY",
convert(geometry.y()));
}
// trigger LFUN_LYX_QUIT instead of quit directly
// since LFUN_LYX_QUIT may have more cleanup stuff
@@ -179,6 +209,7 @@
{
setCaption(qt_("LyX"));
QMainWindow::show();
+ updateFloatingGeometry();
}
Index: frontends/qt3/QtView.h
===
--- frontends/qt3/QtView.h (revision 14157)
+++ frontends/qt3/QtView.h (working copy)
@@ -38,8 +38,8 @@
class QtView : public QMainWindow, public LyXView {
Q_OBJECT
public:
- /// create a main window of the given dimensions
- QtView(unsigned int w, unsigned int h);
+ /// create a main window
+ QtView();
~QtView();
@@ -67,9 +67,19 @@
//
lyx::frontend::Gui & gui() { return frontend_; }
+ ///
+ void initFloatingGeometry(const QRect &);
+
public slots:
/// idle timeout
void update_view_state_qt();
+
+ ///
+ virtual void resizeEvent(QResizeEvent * e);
+
+ ///
+
Re: Qt4 frontend save/restore geoemtry patch
On 6/20/06, Peter Kümmel <[EMAIL PROTECTED]> wrote: Hi Abdel, Bo here the next version with your embedded suggestions. I've also simplified the floating code. Looks fine to me (others may have higher standard though). Is this patch against the trunk or some branch? I can not apply cleanly. Bo
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Hi Abdel, Bo
|
| here the next version with your embedded suggestions.
| I've also simplified the floating code.
|
| Peter
| Index: frontends/qt3/QtView.C
| ===
| --- frontends/qt3/QtView.C(revision 14157)
| +++ frontends/qt3/QtView.C(working copy)
| @@ -157,17 +155,49 @@
| return qApp->activeWindow() == this;
| }
|
| +void QtView::initFloatingGeometry(const QRect & g)
| +{
| + floatingGeometry_ = g;
| + maxWidth=QApplication::desktop()->width()-20;
Oooo... spacing.
| +}
|
| +void QtView::updateFloatingGeometry()
| +{
| + if (width() < maxWidth && frameGeometry().x() > 0)
| + {
| + // setX/Y changes the size!
| + floatingGeometry_.setX(x());
| + floatingGeometry_.setY(y());
| + floatingGeometry_.setWidth(width());
| + floatingGeometry_.setHeight(height());
| + }
| +}
| +
| +void QtView::resizeEvent(QResizeEvent *)
| +{
| + if (width() > maxWidth)
| + maxWidth = width();
maxWidth = max(width(), maxWidth);
| + updateFloatingGeometry();
| +}
| +
| +void QtView::moveEvent(QMoveEvent *)
| +{
| + updateFloatingGeometry();
| +}
| +
| void QtView::closeEvent(QCloseEvent *)
| {
| + updateFloatingGeometry();
| + QRect geometry = floatingGeometry_;
| +
| Session & session = LyX::ref().session();
| session.saveSessionInfo("WindowIsMaximized", (isMaximized() ? "yes" :
"no"));
| // save windows size and position
| - session.saveSessionInfo("WindowWidth", convert(width()));
| - session.saveSessionInfo("WindowHeight", convert(height()));
| + session.saveSessionInfo("WindowWidth",
convert(geometry.width()));
| + session.saveSessionInfo("WindowHeight",
convert(geometry.height()));
| if (lyxrc.geometry_xysaved) {
| - session.saveSessionInfo("WindowPosX", convert(x()));
| - session.saveSessionInfo("WindowPosY", convert(y()));
| + session.saveSessionInfo("WindowPosX",
convert(geometry.x()));
| + session.saveSessionInfo("WindowPosY",
convert(geometry.y()));
| }
| // trigger LFUN_LYX_QUIT instead of quit directly
| // since LFUN_LYX_QUIT may have more cleanup stuff
| Index: frontends/qt3/QtView.h
| ===
| --- frontends/qt3/QtView.h(revision 14157)
| +++ frontends/qt3/QtView.h(working copy)
| @@ -67,9 +67,19 @@
| //
| lyx::frontend::Gui & gui() { return frontend_; }
|
| + ///
| + void initFloatingGeometry(const QRect &);
| +
QRect const &
| Index: frontends/qt4/GuiView.C
| ===
| --- frontends/qt4/GuiView.C (revision 14157)
| +++ frontends/qt4/GuiView.C (working copy)
| @@ -176,12 +175,45 @@
| return qApp->activeWindow() == this;
| }
|
| +void GuiView::updateFloatingGeometry()
| +{
| + if (!isMaximized()) {
| + // setX/Y changes the size!
| + floatingGeometry_.setX(x()); // == frameGeometry().x()
| + floatingGeometry_.setY(y()); // == frameGeometry().y()
| + floatingGeometry_.setWidth(width()); // == geometry().width()
| + floatingGeometry_.setHeight(height());// == geometry().height()
| + }
| +}
What are the comments about?
| Index: lyx_main.C
| ===
| --- lyx_main.C(revision 14157)
| +++ lyx_main.C(working copy)
| @@ -995,6 +1002,10 @@
| std::map::const_iterator it
| = cmdmap.find(argv[i]);
|
| + // check for X11 -geometry option
| + if (argv[i] == string("-geometry"))
| + geometryOption_ = true;
instead of useing the string(...) temporary style you can also use the
compare from lstring.h:
if (lyx::support::compare(argv[i], "-geometry") == 0)
...
Then no conversion to std::string will be done at all, and compare is
an inline function.
--
Lgb
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
Index: frontends/gtk/lyx_gui.C
===
Index: frontends/gt3/lyx_gui.C
===
Index: frontends/xforms/lyx_gui.C
===
--- frontends/xforms/lyx_gui.C (revision 14139)
+++ frontends/xforms/lyx_gui.C (working copy)
So they are totally untouched, right? I mean geometry is still
working, and isMaximized is not implemented.
Yes, I don't touch hem.
Index: frontends/qt4/lyx_gui.C
===
--- frontends/qt4/lyx_gui.C (revision 14139)
+++ frontends/qt4/lyx_gui.C (working copy)
@@ -228,24 +228,32 @@
+ if (!geometryOption)
+ if (posx != -1 posy != -1) {
+#ifndef Q_OS_WIN32
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#else
+ view.setGeometry(posx, posy, width, height);
+#endif
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ }
So geometry option will be handled automatically in QtView? I see.
Yes, all resizing/moving is disabled when -geometry is used.
Index: frontends/qt4/QtView.C
===
--- frontends/qt4/QtView.C (revision 14139)
+++ frontends/qt4/QtView.C (working copy)
@@ -70,7 +70,7 @@
} // namespace anon
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0)
{
mainWidget_ = this;
@@ -78,7 +78,8 @@
// setToolButtonStyle(Qt::ToolButtonIconOnly);
// setIconSize(QSize(12,12));
- bufferview_.reset(new BufferView(this, width, height));
+ // -geometry could set the width and hight
+ bufferview_.reset(new BufferView(this, geometry().width(),
geometry().height()));
OK.
+#ifndef Q_OS_WIN32
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if(!isMaximized())
+ showGeometry_ = qtViewGeometry();
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ if(!isMaximized())
+ showGeometry_ = qtViewGeometry();
+}
+#endif
+
void QtView::closeEvent(QCloseEvent *)
{
+#ifndef Q_OS_WIN32
+ QRect geometry;
+ if (isMaximized())
+ geometry = showGeometry_;
+ else
+ geometry = qtViewGeometry();
+#else
QRect geometry = normalGeometry();
+#endif
This, plus several event handlers, do look like an overkill for such a
simple problem. Should they be considered as a QT/win32 bug?
I've reported yesterday a bug report on this to TT. But I could imagine
that they say: That's not our job, it's a problem of the window manager.
The doc sounds a little bit like this:
Nor does X11 provide a way to maximize a window.
QWidget::showMaximized() has to emulate the feature.
Its result depends on the result of QWidget::frameGeometry()
and the capability of the window manager to do proper
window placement, neither of which can be guaranteed.
Index: frontends/lyx_gui.h
===
--- frontends/lyx_gui.h (revision 14139)
+++ frontends/lyx_gui.h (working copy)
@@ -57,7 +57,8 @@
* batch commands, and loading the given documents
*/
void start(std::string const batch, std::vectorstd::string const
files,
- unsigned int width, unsigned int height, int posx, int
posy, bool maximize);
+ unsigned int width, unsigned int height, int posx, int
posy, bool maximize,
+ bool geometryOption);
/**
* Enter the main event loop (\sa LyX::exec2)
Index: lyx_main.C
===
--- lyx_main.C (revision 14139)
+++ lyx_main.C (working copy)
@@ -170,7 +170,7 @@
LyX::LyX()
- : first_start(false)
+ : first_start(false), geometryOption_(false)
{}
@@ -335,7 +335,7 @@
if (!val.empty())
posy = convertint(val);
}
- lyx_gui::start(batch_command, files, width, height,
posx, posy, maximize);
+ lyx_gui::start(batch_command, files, width, height,
posx, posy, maximize, geometryOption_);
} else {
// Something went wrong above
quitLyX(false);
@@ -995,6 +995,10 @@
std::mapstring,
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
Also, if -geometry is going to override everything, can not we do
if (geometry option present) {
width = -1;
height = -1;
start(... width, height, isMaximized)
}
Bo
I also thought about this, and I also preferred it first
because then I don't have to pass an additional parameter.
But because it is a solution which uses magic numbers
I've switched to a more readable implementation.
When I pass (-1,-1) I have add some comments in the code,
but using if(!geoemtryOption) then the code is its own
documentation.
But when you prefer the (-1,-1) solution I'll change it.
Peter
Re: Qt4 frontend save/restore geoemtry patch
But when you prefer the (-1,-1) solution I'll change it. Since (-1, -1) will save a significant amount of coding, I prefer this. Bo
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
>> Index: frontends/gtk/lyx_gui.C
>> ===
>> Index: frontends/gt3/lyx_gui.C
>> ===
>> Index: frontends/xforms/lyx_gui.C
>> ===
>> --- frontends/xforms/lyx_gui.C (revision 14139)
>> +++ frontends/xforms/lyx_gui.C (working copy)
>
> So they are totally untouched, right? I mean geometry is still
> working, and isMaximized is not implemented.
>
Yes, I don't touch hem.
>
>> Index: frontends/qt4/lyx_gui.C
>> ===
>> --- frontends/qt4/lyx_gui.C (revision 14139)
>> +++ frontends/qt4/lyx_gui.C (working copy)
>> @@ -228,24 +228,32 @@
>
>> + if (!geometryOption)
>> + if (posx != -1 && posy != -1) {
>> +#ifndef Q_OS_WIN32
>> + // X11: use frameGeometry position
>> + view.setGeometry(0, 0, width, height);
>> + view.move(posx, posy);
>> +#else
>> + view.setGeometry(posx, posy, width, height);
>> +#endif
>> + if (maximize)
>> + view.setWindowState(Qt::WindowMaximized);
>> + }
>
> So geometry option will be handled automatically in QtView? I see.
Yes, all resizing/moving is disabled when -geometry is used.
>
>> Index: frontends/qt4/QtView.C
>> ===
>> --- frontends/qt4/QtView.C (revision 14139)
>> +++ frontends/qt4/QtView.C (working copy)
>> @@ -70,7 +70,7 @@
>> } // namespace anon
>>
>>
>> -QtView::QtView(unsigned int width, unsigned int height)
>> +QtView::QtView()
>> : QMainWindow(), LyXView(), commandbuffer_(0)
>> {
>> mainWidget_ = this;
>> @@ -78,7 +78,8 @@
>> // setToolButtonStyle(Qt::ToolButtonIconOnly);
>> // setIconSize(QSize(12,12));
>>
>> - bufferview_.reset(new BufferView(this, width, height));
>> + // -geometry could set the width and hight
>> + bufferview_.reset(new BufferView(this, geometry().width(),
>> geometry().height()));
>
> OK.
>
>>
>> +#ifndef Q_OS_WIN32
>>
>> +QRect QtView::qtViewGeometry() const
>> +{
>> + QRect rec;
>> + // setX/Y changes the size!
>> + rec.setX(frameGeometry().x());
>> + rec.setY(frameGeometry().y());
>> + rec.setWidth(geometry().width());
>> + rec.setHeight(geometry().height());
>> + return rec;
>> +}
>> +
>> +void QtView::resizeEvent(QResizeEvent *)
>> +{
>> + if(!isMaximized())
>> + showGeometry_ = qtViewGeometry();
>> +}
>> +
>> +void QtView::moveEvent(QMoveEvent *)
>> +{
>> + if(!isMaximized())
>> + showGeometry_ = qtViewGeometry();
>> +}
>> +#endif
>> +
>> void QtView::closeEvent(QCloseEvent *)
>> {
>> +#ifndef Q_OS_WIN32
>> + QRect geometry;
>> + if (isMaximized())
>> + geometry = showGeometry_;
>> + else
>> + geometry = qtViewGeometry();
>> +#else
>> QRect geometry = normalGeometry();
>> +#endif
>
> This, plus several event handlers, do look like an overkill for such a
> simple problem. Should they be considered as a QT/win32 bug?
>
I've reported yesterday a bug report on this to TT. But I could imagine
that they say: "That's not our job, it's a problem of the window manager."
The doc sounds a little bit like this:
"Nor does X11 provide a way to maximize a window.
QWidget::showMaximized() has to emulate the feature.
Its result depends on the result of QWidget::frameGeometry()
and the capability of the window manager to do proper
window placement, neither of which can be guaranteed."
>> Index: frontends/lyx_gui.h
>> ===
>> --- frontends/lyx_gui.h (revision 14139)
>> +++ frontends/lyx_gui.h (working copy)
>> @@ -57,7 +57,8 @@
>> * batch commands, and loading the given documents
>> */
>> void start(std::string const & batch, std::vector const
>> & files,
>> - unsigned int width, unsigned int height, int posx, int
>> posy, bool maximize);
>> + unsigned int width, unsigned int height, int posx, int
>> posy, bool maximize,
>> + bool geometryOption);
>>
>> /**
>> * Enter the main event loop (\sa LyX::exec2)
>> Index: lyx_main.C
>> ===
>> --- lyx_main.C (revision 14139)
>> +++ lyx_main.C (working copy)
>> @@ -170,7 +170,7 @@
>>
>>
>> LyX::LyX()
>> - : first_start(false)
>> + : first_start(false), geometryOption_(false)
>> {}
>>
>>
>> @@ -335,7 +335,7 @@
>> if (!val.empty())
>> posy = convert(val);
>> }
>> - lyx_gui::start(batch_command, files, width, height,
>> posx, posy, maximize);
>> +
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
> Also, if -geometry is going to override everything, can not we do
>
> if (geometry option present) {
> width = -1;
> height = -1;
> start(... width, height, isMaximized)
> }
>
> Bo
>
>
I also thought about this, and I also preferred it first
because then I don't have to pass an additional parameter.
But because it is a solution which uses "magic numbers"
I've switched to a more readable implementation.
When I pass (-1,-1) I have add some comments in the code,
but using "if(!geoemtryOption)" then the code is its own
documentation.
But when you prefer the (-1,-1) solution I'll change it.
Peter
Re: Qt4 frontend save/restore geoemtry patch
But when you prefer the (-1,-1) solution I'll change it. Since (-1, -1) will save a significant amount of coding, I prefer this. Bo
Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
On 6/16/06, Peter Kümmel [EMAIL PROTECTED] wrote:
I've fixed the save/restore and -geometry problem for Qt4.
Therefore I have to remember lyx if there was the geometry option,
and I have to emulate the QWidget::normalGeometry() function.
I've tested it with Linux and Windows.
I do not really like this big patch, although this may be the only way
out. I moved most common behaviors of all frontends to lyx_main.C,
hoping to result in simpler logic in the frontends. Now, things would
be clearer if all geometry handling goes back to the frontends.
At the very least, geometryOption_ can be passed as an additional
variable, just as isMaximized, or better, handled in lyx_main.C so
frontends do not have to worry about it.
I've changed the code so that the geometryOption is now passed as
argument to lyx_gui::start. But I don't see a way to handle the
geometry option in lyx_main.
Now you could run lyx with the geometry option maximize the window
and close it maximized and it will remember the geometry values so
that they are not longer needed for the next start of lyx.
I've also reported the X11 workaround,
+#ifdef Q_OS_WIN32
+ view.setGeometry(posx, posy, width, height);
+#else
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#endif
as bug at Trolltech.
Attached the new patch.
(The added event handlers of QtView are needed to remember
the last geometry values)
Peter
Index: frontends/gtk/lyx_gui.C
===
--- frontends/gtk/lyx_gui.C (revision 14139)
+++ frontends/gtk/lyx_gui.C (working copy)
@@ -123,7 +123,7 @@
void lyx_gui::start(string const batch, std::vectorstring const files,
- unsigned int width, unsigned int height, int posx, int
posy, bool)
+ unsigned int width, unsigned int height, int posx, int
posy, bool, bool)
{
boost::shared_ptrGView view_ptr(new GView);
LyX::ref().addLyXView(view_ptr);
Index: frontends/qt3/lyx_gui.C
===
--- frontends/qt3/lyx_gui.C (revision 14140)
+++ frontends/qt3/lyx_gui.C (working copy)
@@ -222,7 +222,7 @@
void start(string const batch, vectorstring const files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool,
bool)
{
// this can't be done before because it needs the Languages object
initEncodings();
Index: frontends/qt4/lyx_gui.C
===
--- frontends/qt4/lyx_gui.C (revision 14139)
+++ frontends/qt4/lyx_gui.C (working copy)
@@ -228,24 +228,32 @@
void start(string const batch, vectorstring const files,
- unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize,
+ bool geometryOption)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptrQtView view_ptr(new QtView(width, height));
+ boost::shared_ptrQtView view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView view = *view_ptr.get();
view.init();
-
- if (posx != -1 posy != -1) {
- view.setGeometry(posx, posy, width, height);
- if (maximize)
- view.setWindowState(Qt::WindowMaximized);
- }
+ if (!geometryOption)
+ if (posx != -1 posy != -1) {
+#ifndef Q_OS_WIN32
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#else
+ view.setGeometry(posx, posy, width, height);
+#endif
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ }
+
view.show();
// FIXME: some code below needs moving
Index: frontends/qt4/QtView.C
===
--- frontends/qt4/QtView.C (revision 14139)
+++ frontends/qt4/QtView.C (working copy)
@@ -70,7 +70,7 @@
} // namespace anon
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0)
{
mainWidget_ = this;
@@ -78,7 +78,8 @@
// setToolButtonStyle(Qt::ToolButtonIconOnly);
// setIconSize(QSize(12,12));
- bufferview_.reset(new BufferView(this, width, height));
+ // -geometry could set the width and hight
+ bufferview_.reset(new BufferView(this, geometry().width(),
geometry().height()));
Re: Qt4 frontend save/restore geoemtry patch
On 6/18/06, Peter Kümmel [EMAIL PROTECTED] wrote:
The added event handlers of QtView are needed to remember
the last geometry values)
This part I trust you.
Index: frontends/gtk/lyx_gui.C
===
Index: frontends/gt3/lyx_gui.C
===
Index: frontends/xforms/lyx_gui.C
===
--- frontends/xforms/lyx_gui.C (revision 14139)
+++ frontends/xforms/lyx_gui.C (working copy)
So they are totally untouched, right? I mean geometry is still
working, and isMaximized is not implemented.
Index: frontends/qt4/lyx_gui.C
===
--- frontends/qt4/lyx_gui.C (revision 14139)
+++ frontends/qt4/lyx_gui.C (working copy)
@@ -228,24 +228,32 @@
+ if (!geometryOption)
+ if (posx != -1 posy != -1) {
+#ifndef Q_OS_WIN32
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#else
+ view.setGeometry(posx, posy, width, height);
+#endif
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ }
So geometry option will be handled automatically in QtView? I see.
Index: frontends/qt4/QtView.C
===
--- frontends/qt4/QtView.C (revision 14139)
+++ frontends/qt4/QtView.C (working copy)
@@ -70,7 +70,7 @@
} // namespace anon
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0)
{
mainWidget_ = this;
@@ -78,7 +78,8 @@
// setToolButtonStyle(Qt::ToolButtonIconOnly);
// setIconSize(QSize(12,12));
- bufferview_.reset(new BufferView(this, width, height));
+ // -geometry could set the width and hight
+ bufferview_.reset(new BufferView(this, geometry().width(),
geometry().height()));
OK.
+#ifndef Q_OS_WIN32
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if(!isMaximized())
+ showGeometry_ = qtViewGeometry();
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ if(!isMaximized())
+ showGeometry_ = qtViewGeometry();
+}
+#endif
+
void QtView::closeEvent(QCloseEvent *)
{
+#ifndef Q_OS_WIN32
+ QRect geometry;
+ if (isMaximized())
+ geometry = showGeometry_;
+ else
+ geometry = qtViewGeometry();
+#else
QRect geometry = normalGeometry();
+#endif
This, plus several event handlers, do look like an overkill for such a
simple problem. Should they be considered as a QT/win32 bug?
Index: frontends/lyx_gui.h
===
--- frontends/lyx_gui.h (revision 14139)
+++ frontends/lyx_gui.h (working copy)
@@ -57,7 +57,8 @@
* batch commands, and loading the given documents
*/
void start(std::string const batch, std::vectorstd::string const files,
- unsigned int width, unsigned int height, int posx, int posy, bool
maximize);
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize,
+ bool geometryOption);
/**
* Enter the main event loop (\sa LyX::exec2)
Index: lyx_main.C
===
--- lyx_main.C (revision 14139)
+++ lyx_main.C (working copy)
@@ -170,7 +170,7 @@
LyX::LyX()
- : first_start(false)
+ : first_start(false), geometryOption_(false)
{}
@@ -335,7 +335,7 @@
if (!val.empty())
posy = convertint(val);
}
- lyx_gui::start(batch_command, files, width, height, posx, posy,
maximize);
+ lyx_gui::start(batch_command, files, width, height, posx, posy,
maximize, geometryOption_);
} else {
// Something went wrong above
quitLyX(false);
@@ -995,6 +995,10 @@
std::mapstring, cmd_helper::const_iterator it
= cmdmap.find(argv[i]);
+ // check for X11 -geometry option
+ if (argv[i] == string(-geometry))
+ geometryOption_ = true;
+
// don't complain if not found - may be parsed later
if (it == cmdmap.end())
continue;
Index: lyx_main.h
===
--- lyx_main.h (revision 14139)
+++ lyx_main.h (working
Re: Qt4 frontend save/restore geoemtry patch
Also, if -geometry is going to override everything, can not we do
if (geometry option present) {
width = -1;
height = -1;
start(... width, height, isMaximized)
}
Bo
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote: I've changed the code so that the geometryOption is now passed as argument to lyx_gui::start. But I don't see a way to handle the geometry option in lyx_main. Hello Peter, I appreciate very much your work on qt4 but, in this particular case, could you wait a bit until my branch is merged? I'll try to review your patch tomorrow. Thanks in advance, Abdel.
Re: Qt4 frontend save/restore geoemtry patch
Bo Peng [EMAIL PROTECTED] writes:
| Also, if -geometry is going to override everything, can not we do
|
| if (geometry option present) {
|width = -1;
| height = -1;
|start(... width, height, isMaximized)
| }
I'd like that a lot better.
--
Lgb
Qt4 frontend save/restore geoemtry patch
Bo Peng wrote:
> On 6/16/06, Peter Kümmel <[EMAIL PROTECTED]> wrote:
>> I've fixed the save/restore and -geometry problem for Qt4.
>> Therefore I have to remember lyx if there was the geometry option,
>> and I have to emulate the QWidget::normalGeometry() function.
>>
>> I've tested it with Linux and Windows.
>
> I do not really like this big patch, although this may be the only way
> out. I moved most common behaviors of all frontends to lyx_main.C,
> hoping to result in simpler logic in the frontends. Now, things would
> be clearer if all geometry handling goes back to the frontends.
>
> At the very least, geometryOption_ can be passed as an additional
> variable, just as isMaximized, or better, handled in lyx_main.C so
> frontends do not have to worry about it.
I've changed the code so that the geometryOption is now passed as
argument to lyx_gui::start. But I don't see a way to handle the
geometry option in lyx_main.
Now you could run lyx with the geometry option maximize the window
and close it maximized and it will remember the geometry values so
that they are not longer needed for the next start of lyx.
I've also reported the X11 workaround,
+#ifdef Q_OS_WIN32
+ view.setGeometry(posx, posy, width, height);
+#else
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#endif
as bug at Trolltech.
Attached the new patch.
(The added event handlers of QtView are needed to remember
the last geometry values)
Peter
Index: frontends/gtk/lyx_gui.C
===
--- frontends/gtk/lyx_gui.C (revision 14139)
+++ frontends/gtk/lyx_gui.C (working copy)
@@ -123,7 +123,7 @@
void lyx_gui::start(string const & batch, std::vector const & files,
- unsigned int width, unsigned int height, int posx, int
posy, bool)
+ unsigned int width, unsigned int height, int posx, int
posy, bool, bool)
{
boost::shared_ptr view_ptr(new GView);
LyX::ref().addLyXView(view_ptr);
Index: frontends/qt3/lyx_gui.C
===
--- frontends/qt3/lyx_gui.C (revision 14140)
+++ frontends/qt3/lyx_gui.C (working copy)
@@ -222,7 +222,7 @@
void start(string const & batch, vector const & files,
- unsigned int width, unsigned int height, int posx, int posy, bool)
+ unsigned int width, unsigned int height, int posx, int posy, bool,
bool)
{
// this can't be done before because it needs the Languages object
initEncodings();
Index: frontends/qt4/lyx_gui.C
===
--- frontends/qt4/lyx_gui.C (revision 14139)
+++ frontends/qt4/lyx_gui.C (working copy)
@@ -228,24 +228,32 @@
void start(string const & batch, vector const & files,
- unsigned int width, unsigned int height, int posx, int posy, bool
maximize)
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize,
+ bool geometryOption)
{
// this can't be done before because it needs the Languages object
initEncodings();
- boost::shared_ptr view_ptr(new QtView(width, height));
+ boost::shared_ptr view_ptr(new QtView);
LyX::ref().addLyXView(view_ptr);
QtView & view = *view_ptr.get();
view.init();
-
- if (posx != -1 && posy != -1) {
- view.setGeometry(posx, posy, width, height);
- if (maximize)
- view.setWindowState(Qt::WindowMaximized);
- }
+ if (!geometryOption)
+ if (posx != -1 && posy != -1) {
+#ifndef Q_OS_WIN32
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#else
+ view.setGeometry(posx, posy, width, height);
+#endif
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ }
+
view.show();
// FIXME: some code below needs moving
Index: frontends/qt4/QtView.C
===
--- frontends/qt4/QtView.C (revision 14139)
+++ frontends/qt4/QtView.C (working copy)
@@ -70,7 +70,7 @@
} // namespace anon
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0)
{
mainWidget_ = this;
@@ -78,7 +78,8 @@
// setToolButtonStyle(Qt::ToolButtonIconOnly);
// setIconSize(QSize(12,12));
- bufferview_.reset(new BufferView(this, width, height));
+ // -geometry could set the width and hight
+ bufferview_.reset(new BufferView(this, geometry().width(),
geometry().height()));
Re: Qt4 frontend save/restore geoemtry patch
On 6/18/06, Peter Kümmel <[EMAIL PROTECTED]> wrote:
The added event handlers of QtView are needed to remember
the last geometry values)
This part I trust you.
Index: frontends/gtk/lyx_gui.C
===
Index: frontends/gt3/lyx_gui.C
===
Index: frontends/xforms/lyx_gui.C
===
--- frontends/xforms/lyx_gui.C (revision 14139)
+++ frontends/xforms/lyx_gui.C (working copy)
So they are totally untouched, right? I mean geometry is still
working, and isMaximized is not implemented.
Index: frontends/qt4/lyx_gui.C
===
--- frontends/qt4/lyx_gui.C (revision 14139)
+++ frontends/qt4/lyx_gui.C (working copy)
@@ -228,24 +228,32 @@
+ if (!geometryOption)
+ if (posx != -1 && posy != -1) {
+#ifndef Q_OS_WIN32
+ // X11: use frameGeometry position
+ view.setGeometry(0, 0, width, height);
+ view.move(posx, posy);
+#else
+ view.setGeometry(posx, posy, width, height);
+#endif
+ if (maximize)
+ view.setWindowState(Qt::WindowMaximized);
+ }
So geometry option will be handled automatically in QtView? I see.
Index: frontends/qt4/QtView.C
===
--- frontends/qt4/QtView.C (revision 14139)
+++ frontends/qt4/QtView.C (working copy)
@@ -70,7 +70,7 @@
} // namespace anon
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0)
{
mainWidget_ = this;
@@ -78,7 +78,8 @@
// setToolButtonStyle(Qt::ToolButtonIconOnly);
// setIconSize(QSize(12,12));
- bufferview_.reset(new BufferView(this, width, height));
+ // -geometry could set the width and hight
+ bufferview_.reset(new BufferView(this, geometry().width(),
geometry().height()));
OK.
+#ifndef Q_OS_WIN32
+QRect QtView::qtViewGeometry() const
+{
+ QRect rec;
+ // setX/Y changes the size!
+ rec.setX(frameGeometry().x());
+ rec.setY(frameGeometry().y());
+ rec.setWidth(geometry().width());
+ rec.setHeight(geometry().height());
+ return rec;
+}
+
+void QtView::resizeEvent(QResizeEvent *)
+{
+ if(!isMaximized())
+ showGeometry_ = qtViewGeometry();
+}
+
+void QtView::moveEvent(QMoveEvent *)
+{
+ if(!isMaximized())
+ showGeometry_ = qtViewGeometry();
+}
+#endif
+
void QtView::closeEvent(QCloseEvent *)
{
+#ifndef Q_OS_WIN32
+ QRect geometry;
+ if (isMaximized())
+ geometry = showGeometry_;
+ else
+ geometry = qtViewGeometry();
+#else
QRect geometry = normalGeometry();
+#endif
This, plus several event handlers, do look like an overkill for such a
simple problem. Should they be considered as a QT/win32 bug?
Index: frontends/lyx_gui.h
===
--- frontends/lyx_gui.h (revision 14139)
+++ frontends/lyx_gui.h (working copy)
@@ -57,7 +57,8 @@
* batch commands, and loading the given documents
*/
void start(std::string const & batch, std::vector const & files,
- unsigned int width, unsigned int height, int posx, int posy, bool
maximize);
+ unsigned int width, unsigned int height, int posx, int posy, bool
maximize,
+ bool geometryOption);
/**
* Enter the main event loop (\sa LyX::exec2)
Index: lyx_main.C
===
--- lyx_main.C (revision 14139)
+++ lyx_main.C (working copy)
@@ -170,7 +170,7 @@
LyX::LyX()
- : first_start(false)
+ : first_start(false), geometryOption_(false)
{}
@@ -335,7 +335,7 @@
if (!val.empty())
posy = convert(val);
}
- lyx_gui::start(batch_command, files, width, height, posx, posy,
maximize);
+ lyx_gui::start(batch_command, files, width, height, posx, posy,
maximize, geometryOption_);
} else {
// Something went wrong above
quitLyX(false);
@@ -995,6 +995,10 @@
std::map::const_iterator it
= cmdmap.find(argv[i]);
+ // check for X11 -geometry option
+ if (argv[i] == string("-geometry"))
+ geometryOption_ = true;
+
// don't complain if not found - may be parsed later
if (it == cmdmap.end())
continue;
Index: lyx_main.h
===
--- lyx_main.h (revision 14139)
+++ lyx_main.h (working copy)
@@
Re: Qt4 frontend save/restore geoemtry patch
Also, if -geometry is going to override everything, can not we do
if (geometry option present) {
width = -1;
height = -1;
start(... width, height, isMaximized)
}
Bo
Re: Qt4 frontend save/restore geoemtry patch
Peter Kümmel wrote: I've changed the code so that the geometryOption is now passed as argument to lyx_gui::start. But I don't see a way to handle the geometry option in lyx_main. Hello Peter, I appreciate very much your work on qt4 but, in this particular case, could you wait a bit until my branch is merged? I'll try to review your patch tomorrow. Thanks in advance, Abdel.
Re: Qt4 frontend save/restore geoemtry patch
"Bo Peng" <[EMAIL PROTECTED]> writes:
| Also, if -geometry is going to override everything, can not we do
|
| if (geometry option present) {
|width = -1;
| height = -1;
|start(... width, height, isMaximized)
| }
I'd like that a lot better.
--
Lgb
Is the qt4 frontend ready for (experimental) use?
I finally got my compiler sorted out, I can compile lyx again. :-) At least I got the qt frontend going with g++ 4.1 I then tried to install qt4 tools libraries to compile that frontend, but it failed. Is qt4 simply not ready for testing yet, or broken in svn right now, or should I look for errors in my setup? Helge Hafting
Re: Is the qt4 frontend ready for (experimental) use?
Helge Hafting wrote: Is qt4 simply not ready for testing yet, or broken in svn right now, or should I look for errors in my setup? It compiles fine here with gcc 3.3. Please send the error messages, maybe some error is tolerated by older gccs but not by gcc 4.1 Georg
Re: Is the qt4 frontend ready for (experimental) use?
Helge Hafting a écrit : I finally got my compiler sorted out, I can compile lyx again. :-) At least I got the qt frontend going with g++ 4.1 I then tried to install qt4 tools libraries to compile that frontend, but it failed. Is qt4 simply not ready for testing yet, or broken in svn right now, or should I look for errors in my setup? Unless I have introduced something bad lately, it should compile and work OK (except for the Citation dialog). At least Georg, Juegen and Edwin were able to run it. Is it a configuration error or a compilation error? If the later please post the gcc output. Thanks, Abdel.
Is the qt4 frontend ready for (experimental) use?
I finally got my compiler sorted out, I can compile lyx again. :-) At least I got the qt frontend going with g++ 4.1 I then tried to install qt4 tools & libraries to compile that frontend, but it failed. Is qt4 simply not ready for testing yet, or broken in svn right now, or should I look for errors in my setup? Helge Hafting
Re: Is the qt4 frontend ready for (experimental) use?
Helge Hafting wrote: > Is qt4 simply not ready for testing yet, or broken in svn right now, > or should I look for errors in my setup? It compiles fine here with gcc 3.3. Please send the error messages, maybe some error is tolerated by older gccs but not by gcc 4.1 Georg
Re: Is the qt4 frontend ready for (experimental) use?
Helge Hafting a écrit : I finally got my compiler sorted out, I can compile lyx again. :-) At least I got the qt frontend going with g++ 4.1 I then tried to install qt4 tools & libraries to compile that frontend, but it failed. Is qt4 simply not ready for testing yet, or broken in svn right now, or should I look for errors in my setup? Unless I have introduced something bad lately, it should compile and work OK (except for the Citation dialog). At least Georg, Juegen and Edwin were able to run it. Is it a configuration error or a compilation error? If the later please post the gcc output. Thanks, Abdel.
Re: Qt4 frontend
Martin Vermeer a écrit : On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer wrote: On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: ... Actually with your first patch, if you open a document, type Ctrl+end, then only half of of screen is redrawn :-) And if you open a new document (ctrl+n), the bottom part of the area is not drawn. Same with the second patch. The reason is that the grey areas that are correctly drawn in paintText, are never exposed. I know how to do it, it's easy... have to run now. Here is the fix for the end-of-document problem. Are you going to apply this patch to trunk Martin? It works fine here. Abdel.
Re: Qt4 frontend
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer Martin wrote: On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: ... Actually with your first patch, if you open a document, type Ctrl+end, then only half of of screen is redrawn :-) And if you open a new document (ctrl+n), the bottom part of the area is not drawn. Same with the second patch. The reason is that the grey areas that are correctly drawn in paintText, are never exposed. I know how to do it, it's easy... have to run now. Martin Here is the fix for the end-of-document problem. Martin What I would really like to know is if this helps when using Martin LyX over a slow line, i.e., does expose really send a Martin rectangle of pixels from the application to the server Martin display, i.e., were all the earlier painting operations to a Martin local canvas only? Is this supposed to help with 1.4? We have some reports of operations on mac being dependent on document size (and profiles of LyX rebreaking the whole document for no reason). JMarc
Re: Qt4 frontend
On Mon, 2006-03-20 at 14:01 +0100, Abdelrazak Younes wrote: Martin Vermeer a écrit : On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer wrote: On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: ... Actually with your first patch, if you open a document, type Ctrl+end, then only half of of screen is redrawn :-) And if you open a new document (ctrl+n), the bottom part of the area is not drawn. Same with the second patch. The reason is that the grey areas that are correctly drawn in paintText, are never exposed. I know how to do it, it's easy... have to run now. Here is the fix for the end-of-document problem. Are you going to apply this patch to trunk Martin? It works fine here. Abdel. OK, I applied it. I suppose it doesn't harm. Log entry: Selective expose patch * metricsinfo.h (ViewMetricsInfo): add size parameter * BufferView_pimpl.C (BufferView::Pimpl::metrics): return size * frontends/screen.C (LyXScreen::redraw): expose selectively, using y1, y2 in vi, and exposing lower grey at end using size test Thanks for testing! - Martin signature.asc Description: This is a digitally signed message part
Re: Qt4 frontend
Jean-Marc Lasgouttes a écrit : Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer Martin wrote: On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: ... Actually with your first patch, if you open a document, type Ctrl+end, then only half of of screen is redrawn :-) And if you open a new document (ctrl+n), the bottom part of the area is not drawn. Same with the second patch. The reason is that the grey areas that are correctly drawn in paintText, are never exposed. I know how to do it, it's easy... have to run now. Martin Here is the fix for the end-of-document problem. Martin What I would really like to know is if this helps when using Martin LyX over a slow line, i.e., does expose really send a Martin rectangle of pixels from the application to the server Martin display, i.e., were all the earlier painting operations to a Martin local canvas only? Is this supposed to help with 1.4? We have some reports of operations on mac being dependent on document size (and profiles of LyX rebreaking the whole document for no reason). I think this plus the repaint-update patch should help with 1.4, especially on mac where there seems to be painting problems also. But it is independent of document size. Abdel.
Re: Qt4 frontend
On Mon, 2006-03-20 at 16:08 +0100, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Martin On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer Martin wrote: On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: ... Actually with your first patch, if you open a document, type Ctrl+end, then only half of of screen is redrawn :-) And if you open a new document (ctrl+n), the bottom part of the area is not drawn. Same with the second patch. The reason is that the grey areas that are correctly drawn in paintText, are never exposed. I know how to do it, it's easy... have to run now. Martin Here is the fix for the end-of-document problem. Martin What I would really like to know is if this helps when using Martin LyX over a slow line, i.e., does expose really send a Martin rectangle of pixels from the application to the server Martin display, i.e., were all the earlier painting operations to a Martin local canvas only? Is this supposed to help with 1.4? We have some reports of operations on mac being dependent on document size Which operations? Core operations are unrelated to this patch. (and profiles of LyX rebreaking the whole document for no reason). Hardly related to this. - Martin signature.asc Description: This is a digitally signed message part
Re: Qt4 frontend
Martin == Martin Vermeer [EMAIL PROTECTED] writes: Is this supposed to help with 1.4? We have some reports of operations on mac being dependent on document size Martin Which operations? Core operations are unrelated to this patch. Things like that: http://marc.theaimsgroup.com/?t=11351752952r=1w=2 In any case, do you think your patch would help on 1.4. It cannot hurt, can it? JMarc
Re: Qt4 frontend
On Mon, 2006-03-20 at 17:01 +0100, Jean-Marc Lasgouttes wrote: Martin == Martin Vermeer [EMAIL PROTECTED] writes: Is this supposed to help with 1.4? We have some reports of operations on mac being dependent on document size Martin Which operations? Core operations are unrelated to this patch. Things like that: http://marc.theaimsgroup.com/?t=11351752952r=1w=2 In any case, do you think your patch would help on 1.4. It cannot hurt, can it? No, it won't hurt, but the signature of the slowness reported by Bennett is wrong for this to be the cause. I'll sleep on it :-) - Martin signature.asc Description: This is a digitally signed message part
Re: Qt4 frontend
Martin Vermeer a écrit : On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer wrote: On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: ... Actually with your first patch, if you open a document, type Ctrl+end, then only half of of screen is redrawn :-) And if you open a new document (ctrl+n), the bottom part of the area is not drawn. Same with the second patch. The reason is that the grey areas that are correctly drawn in paintText, are never exposed. I know how to do it, it's easy... have to run now. Here is the fix for the end-of-document problem. Are you going to apply this patch to trunk Martin? It works fine here. Abdel.
Re: Qt4 frontend
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes: Martin> On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer Martin> wrote: >> On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: >> >> ... >> >> > Actually with your first patch, if you open a document, type >> Ctrl+end, > then only half of of screen is redrawn :-) > And if you >> open a new document (ctrl+n), the bottom part of the area is > not >> drawn. >> >> Same with the second patch. The reason is that the grey areas that >> are correctly drawn in paintText, are never exposed. I know how to >> do it, it's easy... have to run now. Martin> Here is the fix for the end-of-document problem. Martin> What I would really like to know is if this helps when using Martin> LyX over a slow line, i.e., does "expose" really send a Martin> rectangle of pixels from the application to the server Martin> display, i.e., were all the earlier painting operations to a Martin> local canvas only? Is this supposed to help with 1.4? We have some reports of operations on mac being dependent on document size (and profiles of LyX rebreaking the whole document for no reason). JMarc
Re: Qt4 frontend
On Mon, 2006-03-20 at 14:01 +0100, Abdelrazak Younes wrote: > Martin Vermeer a écrit : > > On Fri, Mar 17, 2006 at 04:21:16PM +0200, Martin Vermeer wrote: > >> On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote: > >> > >> ... > >> > >>> Actually with your first patch, if you open a document, type Ctrl+end, > >>> then only half of of screen is redrawn :-) > >>> And if you open a new document (ctrl+n), the bottom part of the area is > >>> not drawn. > >> Same with the second patch. The reason is that the grey areas that are > >> correctly drawn in paintText, are never exposed. I know how to do it, > >> it's easy... have to run now. > > > > Here is the fix for the end-of-document problem. > > Are you going to apply this patch to trunk Martin? It works fine here. > > Abdel. OK, I applied it. I suppose it doesn't harm. Log entry: Selective expose patch * metricsinfo.h (ViewMetricsInfo): add size parameter * BufferView_pimpl.C (BufferView::Pimpl::metrics): return size * frontends/screen.C (LyXScreen::redraw): expose selectively, using y1, y2 in vi, and exposing lower grey at end using size test Thanks for testing! - Martin signature.asc Description: This is a digitally signed message part
