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 b
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 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.mo
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
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
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
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.
Wel
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);
> +
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 cr
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 <[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 f
Peter Kümmel <[EMAIL PROTECTED]> writes:
| Done.
|
| Attached the new patch.
This is ok with me now.
--
Lgb
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 .
>
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 br
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.
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
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.
B
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 (wor
> 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,
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.mo
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
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));
+ v
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);
>> -
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 o
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
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:
-QtView::QtView(unsigned int width, unsigned int height)
+QtView::QtView()
: QMainWindow(), LyXView(), commandbuffer_(0), frontend_(*this)
{
-resize(width, height);
-
qApp->setMainWidget(this);
-bufferview_.res
>>> -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, widt
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 update
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
merg
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.
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:
> 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 p
Bo Peng wrote:
>> Index: frontends/gtk/lyx_gui.C
>> ===
>> Index: frontends/gt3/lyx_gui.C
>> ===
>> Index: frontends/xforms/lyx_gui.C
>> ==
"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
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
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
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
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 ar
> "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
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:
> >>
> >> ...
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 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
> "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
>> Ctr
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 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
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 docu
On Fri, Mar 17, 2006 at 10:19:09AM +, Angus Leeming wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > Hum, after thinking a bit more about this, I am maybe wrong here
> > when the windowing system is an X11 server. Georg's post pushed me
> > to try using a backing QImage instead of a Q
On Thu, Mar 16, 2006 at 10:38:00PM +0100, Abdelrazak Younes wrote:
> This was just
> for clarification and I think we agree on everything except the fact
> that QPixmap can be painted into at any time.
Uh.. we might agree on that, too, once I read the docs ;-)
Andre'
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 sec
Abdelrazak Younes a écrit :
OK, this was just a trial... I am going to revert the cursor changes as
Angus explained in another mail because this make sense to me.
But on the subject of QPixmap vs QImage in QWorkArea, I would like to
continue investigating this route a bit.
Here is a new appr
Martin Vermeer a écrit :
On Fri, 2006-03-17 at 14:12 +0100, Abdelrazak Younes wrote:
Martin Vermeer a écrit :
On Fri, 2006-03-17 at 12:25 +0100, Georg Baum wrote:
I don't... but it appears straightforward to do. See patch. Works fine
for me.
Hello Martin,
It seems to work fine on screen but...
Martin Vermeer a écrit :
On Fri, 2006-03-17 at 14:12 +0100, Abdelrazak Younes wrote:
Martin Vermeer a écrit :
On Fri, 2006-03-17 at 12:25 +0100, Georg Baum wrote:
I don't... but it appears straightforward to do. See patch. Works fine
for me.
Hello Martin,
It seems to work fine on screen but...
On Fri, 2006-03-17 at 14:12 +0100, Abdelrazak Younes wrote:
> Martin Vermeer a écrit :
> > On Fri, 2006-03-17 at 12:25 +0100, Georg Baum wrote:
> > I don't... but it appears straightforward to do. See patch. Works fine
> > for me.
>
> Hello Martin,
> It seems to work fine on screen but...
>
> > +
Abdelrazak Younes wrote:
> No, they are in red here. At least those in "Allsymbols.lyx" Care to
> give an example?
Any unknown symbol would do, but I just saw that the reason was a local
modification and it occurs in the other frontends, too, so never mind.
Georg
Martin Vermeer a écrit :
On Fri, 2006-03-17 at 12:25 +0100, Georg Baum wrote:
I don't... but it appears straightforward to do. See patch. Works fine
for me.
Hello Martin,
It seems to work fine on screen but...
+ //expose(0, 0, workarea().workWidth(), workarea().workHeight());
+ ex
On Fri, 2006-03-17 at 12:25 +0100, Georg Baum wrote:
> Abdelrazak Younes wrote:
...
> > But on the subject of QPixmap vs QImage in QWorkArea, I would like to
> > continue investigating this route a bit. Right now, correct me if I'm
> > wrong, the lyx kernel ask for a repaint of the whole screen f
> Is Edwin on Linux?
yes he is.
debian unstable, qt 4.1.1.
Georg Baum a écrit :
Abdelrazak Younes wrote:
And do you still see the Painting error messages on the console?
No, but this was already the case without the patch.
Then Juergen is the only one left with those errors... Weird.
Do you also see unknown math commands in blue instead of red?
Abdelrazak Younes wrote:
> And do you still see the Painting error messages on the console?
No, but this was already the case without the patch.
Do you also see unknown math commands in blue instead of red?
> No I've read only Qt Assistant local documentation and it's definitely
> poorer.
On l
Juergen Spitzmueller a écrit :
Abdelrazak Younes wrote:
Is this your case? I mean, I don't understand why Edwin doesn't see the
same QPainting error as you and Juergen are seeing.
Is Edwin on Linux?
Good question :-)
I am assuming by default that everybody is on Linux except me :-(
Abdel.
Abdelrazak Younes wrote:
> Is this your case? I mean, I don't understand why Edwin doesn't see the
> same QPainting error as you and Juergen are seeing.
Is Edwin on Linux?
Jürgen
Angus Leeming a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Hum, after thinking a bit more about this, I am maybe wrong here when
the windowing system is an X11 server. Georg's post pushed me to try
using a backing QImage instead of a QPixmap. I cannot feel any speed
difference withi
Georg Baum a écrit :
Abdelrazak Younes wrote:
Hum, after thinking a bit more about this, I am maybe wrong here when
the windowing system is an X11 server. Georg's post pushed me to try
using a backing QImage instead of a QPixmap. I cannot feel any speed
difference within Windows but I guess it c
Abdelrazak Younes wrote:
> Abdelrazak Younes a écrit :
>> Andre Poenitz a écrit :
>>> On Thu, Mar 16, 2006 at 10:50:41AM +0100, Abdelrazak Younes wrote:
>>>
> I thought even painting into a pixmap should only be done in a
> paintEvent(). The pixmap is located on the server side after all
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Hum, after thinking a bit more about this, I am maybe wrong here when
> the windowing system is an X11 server. Georg's post pushed me to try
> using a backing QImage instead of a QPixmap. I cannot feel any speed
> difference within Windows but I gu
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>>> tool? I think a simple, case-insensitive, search-as-type is more
>>> than enough and more intuitive. A more powerful search tool dialog
>>> could be opened in need of advanced search (via Ctr+F and/or a
>>> search button).
>>
Abdelrazak Younes a écrit :
Andre Poenitz a écrit :
On Thu, Mar 16, 2006 at 10:50:41AM +0100, Abdelrazak Younes wrote:
I thought even painting into a pixmap should only be done in a
paintEvent(). The pixmap is located on the server side after all...
I don't think so... or maybe I don't
Abdelrazak Younes a écrit :
Andre Poenitz a écrit :
I am blacklisted by your mailer Andre:
This is the Postfix program at host smtp2-g19.free.fr.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, p
John Levon a écrit :
On Thu, Mar 16, 2006 at 06:21:44PM +0100, Abdelrazak Younes wrote:
I think its a matter of "beginner vs power user".
No. If it comes down to that, we've already failed.
OK.
tool? I think a simple, case-insensitive, search-as-type is more than
enough and more intuitive
Georg Baum a écrit :
Am Donnerstag, 16. März 2006 10:50 schrieb Abdelrazak Younes:
I don't think so... or maybe I don't understand what you mean by "server
side".
Probably the X server in the X11 client server model. The server operates
the graphics card, keyboard and mouse and is always on
Andre Poenitz a écrit :
On Thu, Mar 16, 2006 at 10:50:41AM +0100, Abdelrazak Younes wrote:
I thought even painting into a pixmap should only be done in a
paintEvent(). The pixmap is located on the server side after all...
I don't think so... or maybe I don't understand what you mean by
Am Donnerstag, 16. März 2006 10:50 schrieb Abdelrazak Younes:
> I don't think so... or maybe I don't understand what you mean by "server
> side".
Probably the X server in the X11 client server model. The server operates
the graphics card, keyboard and mouse and is always on the local machine.
On Thu, Mar 16, 2006 at 10:50:41AM +0100, Abdelrazak Younes wrote:
> >I thought even painting into a pixmap should only be done in a
> >paintEvent(). The pixmap is located on the server side after all...
>
> I don't think so... or maybe I don't understand what you mean by "server
> side".
The X
On Thu, Mar 16, 2006 at 06:21:44PM +0100, Abdelrazak Younes wrote:
> I think its a matter of "beginner vs power user".
No. If it comes down to that, we've already failed.
> tool? I think a simple, case-insensitive, search-as-type is more than
> enough and more intuitive. A more powerful search
i agree with your points here on the insert citation dialog (i like the 1.3
version better too)
for clarity: in my previous mail i referred to the insert bibtex biblio dialog
(or 2 dialogs in 1.4)
it is tedious going through 2 dialogs if 1 could have sufficed...
my 2c of course
edwin
John Levon a écrit :
On Thu, Mar 16, 2006 at 12:37:33PM +0100, Abdelrazak Younes wrote:
I have read some people complaining in lyx-users but maybe some poll is
in order. In any case, no need to erase any code, we can provide both in
the qt4 frontend and switch to one or the other via a compile
On Thu, Mar 16, 2006 at 12:37:33PM +0100, Abdelrazak Younes wrote:
> I have read some people complaining in lyx-users but maybe some poll is
> in order. In any case, no need to erase any code, we can provide both in
> the qt4 frontend and switch to one or the other via a compiler switch or
> so
On Thu, Mar 16, 2006 at 11:03:34AM +0100, Leuven, E. wrote:
> i am trying to get some work done with it, but at the moment cannot insert a
> bibtex biblio...
>
> why is there an extra dialog here btw? think i like the 1.3 version better
>
> perhaps we can reinstate that one while john levon is
Abdelrazak Younes wrote:
> > don't see painting errors on the console,
>
> Very good, maybe it just vanished after my QWorkArea cleanup, Georg,
> Juergen, do you confirm that?
No, it's still there.
Jürgen
> Yeah... I weeded out committers that did not declare interest in
> keeping the RW access. Shall I enable it for you?
i don't think i will be a big committer, a fix now and then.
you could enable it for qt4 so that abdel does not need to shove them in...
it is up to you.
regards, edwin
"Leuven, E." <[EMAIL PROTECTED]> writes:
| > I guess you have commit RW access, so please commit your patch.
|
| am not sure i have. i can imagine lars removed me from the list
| after migrating to subversion
Yeah... I weeded out committers that did not declare interest in
keeping the RW access.
Leuven, E. a écrit :
I don't know, are you compiling with enable-stdlib-debug?
no i disabled that one...
perhaps we can reinstate that one while john levon is not watching? ;-)
I would agree with such a change.
don't know how others think about it, but i am very tempted...
I have read so
> I don't know, are you compiling with enable-stdlib-debug?
no i disabled that one...
>> perhaps we can reinstate that one while john levon is not watching? ;-)
> I would agree with such a change.
don't know how others think about it, but i am very tempted...
ed.
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Leuven, E. a écrit :
>>> I guess you have commit RW access, so please commit your patch.
>> am not sure i have. i can imagine lars removed me from the list
>> after migrating to subversion
Abdelrazak> At least you hav
Leuven, E. a écrit :
I guess you have commit RW access, so please commit your patch.
am not sure i have. i can imagine lars removed me from the list after migrating
to subversion
At least you have an account in "svn.lyx.org":
[EMAIL PROTECTED] ~]$ ls -d /home/leuven
/home/leuven
Leuven, E. a écrit :
I am curious of how well it works for you. Do you see the same
problem as Georg? (slowness and Qt errors about painting in
the console)
don't see painting errors on the console,
Very good, maybe it just vanished after my QWorkArea cleanup, Georg,
Juergen, do you confirm
> I am curious of how well it works for you. Do you see the same
> problem as Georg? (slowness and Qt errors about painting in
> the console)
don't see painting errors on the console, but it seems a bit slow when
selecting text (not sure this is a qt4 frontend thingie)
i am trying to get some wo
Andre Poenitz a écrit :
On Mon, Mar 13, 2006 at 12:20:28PM +0100, Abdelrazak Younes wrote:
Juergen Spitzmueller a écrit :
Abdelrazak Younes wrote:
The problems seems to be that we try to initialize the QPainter object
multiple times (at least in QLPainter). This is not allowed:
http://doc.trol
Leuven, E. a écrit :
hi guys,
just compiled the qt4 frontend and am surprised how well it works. great
work abdul!
Thanks :-)
I am curious of how well it works for you. Do you see the same problem
as Georg? (slowness and Qt errors about painting in the console)
i made some little changes
On Mon, Mar 13, 2006 at 12:20:28PM +0100, Abdelrazak Younes wrote:
> Juergen Spitzmueller a écrit :
> >Abdelrazak Younes wrote:
> >>>The problems seems to be that we try to initialize the QPainter object
> >>>multiple times (at least in QLPainter). This is not allowed:
> >>>http://doc.trolltech.com
Juergen Spitzmueller a écrit :
Abdelrazak Younes wrote:
The problems seems to be that we try to initialize the QPainter object
multiple times (at least in QLPainter). This is not allowed:
http://doc.trolltech.com/4.1/qpainter.html#QPainter-2
Yep and that's why I erased all use of qp_ private me
Abdelrazak Younes wrote:
> > The problems seems to be that we try to initialize the QPainter object
> > multiple times (at least in QLPainter). This is not allowed:
> > http://doc.trolltech.com/4.1/qpainter.html#QPainter-2
>
> Yep and that's why I erased all use of qp_ private member in
> "QLPainte
Juergen Spitzmueller a écrit :
Georg Baum wrote:
I get lots of
QX11PaintEngine::begin: Painter is already active.
You must end() the painter before a second begin()
QPainter::begin(), QPaintEngine::begin() returned false
on the console, and using the scrollbar is slow and crashes somet
Georg Baum wrote:
> I get lots of
>
> QX11PaintEngine::begin: Painter is already active.
> You must end() the painter before a second begin()
> QPainter::begin(), QPaintEngine::begin() returned false
>
> on the console, and using the scrollbar is slow and crashes sometimes.
The problems se
Am Donnerstag, 9. März 2006 17:14 schrieb Abdelrazak Younes:
> I see... is it at all possible to have different flags for different
> different directory?
I don't know.
> If yes it should be possible to put a condition for mingw and qt4
> directory. Or we just create a new 'config/mingw.m4' bas
Georg Baum a écrit :
Abdelrazak Younes wrote:
Dear Georg,
Don't ask me why but in order for the Qt4 frontend to work correctly, I
had to modify the Makefile and remove the '-mms-bitfields' option from
CXXFLAGS. Without this, under Windows, the QWorkarea has an unchangeable
size of -743x1 and t
Abdelrazak Younes wrote:
> Dear Georg,
>
> Don't ask me why but in order for the Qt4 frontend to work correctly, I
> had to modify the Makefile and remove the '-mms-bitfields' option from
> CXXFLAGS. Without this, under Windows, the QWorkarea has an unchangeable
> size of -743x1 and the work area
On Sat, Mar 04, 2006 at 08:19:56PM +0100, Abdelrazak Younes wrote:
> Lars, you told me you want to have a say in how the porting to Qt4 is
> done. I just want to warn you that it is not worth having the two
> frontends sharing code at all. You must see them as two totally
> separated frontends (
On Sun, Mar 05, 2006 at 04:47:25PM +0100, Abdelrazak Younes wrote:
> This is because there isn't one/one matching for colors between LyX and
> Qt4. I had to manually map some inexistent grey color to something that
> exists under Qt.
Qt has 32 bit RGB(A), the same as X/LyX...
Andre'
1 - 100 of 125 matches
Mail list logo
