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'
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
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'
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
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
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
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
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
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
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
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
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,
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 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
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
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:
| >>
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);
>> +
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.
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
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);
+
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
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
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);
> +
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.
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.
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
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.
Peter Kümmel [EMAIL PROTECTED] writes:
| Done.
|
| Attached the new patch.
This is ok with me now.
--
Lgb
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
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
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.
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
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 .
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Done.
|
| Attached the new patch.
This is ok with me now.
--
Lgb
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
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
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
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
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
-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));
+
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,
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.
//
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
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.
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);
-
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));
+
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
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)
-
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,
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
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
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
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
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
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
>>> -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,
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);
-
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.
//
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
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
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);
>> -
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));
+
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
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)
>> -
> 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
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
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.
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
| ===
| ---
Bo Peng wrote:
Index: frontends/gtk/lyx_gui.C
===
Index: frontends/gt3/lyx_gui.C
===
Index: frontends/xforms/lyx_gui.C
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
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
Bo Peng wrote:
>> Index: frontends/gtk/lyx_gui.C
>> ===
>> Index: frontends/gt3/lyx_gui.C
>> ===
>> Index: frontends/xforms/lyx_gui.C
>>
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
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
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.
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
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
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
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
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
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
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
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
"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
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
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
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
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
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
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
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
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
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
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,
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
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:
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
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
> "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
>>
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
1 - 100 of 270 matches
Mail list logo
