Enrico Forestieri wrote:
"Notice that if you make a shortcut to lyx-x11.exe, you don't need to
manually start the X server. If needed, lyx-x11.exe will start the X
server using the /usr/local/bin/startxserver script which performs the
same exact actions as the /usr/X11R6/bin/startxwin.{sh,bat} sc
Abdelrazak Younes wrote:
> I will check the documentation on scoped_ptr and I will remove the
> scoped_ptr on Clipboard. But ultimately, the job of destruction should
> be left to the frontends.
scoped_ptr is like auto_ptr, boost docs:
The scoped_ptr template is a simple solution for simple needs
Abdelrazak Younes wrote:
> Yes. I have been experimenting with a QPicture cache between
> QLPainter::start() and QLPainter::end() which would replay the QPicture
> into the QWorkArea painting_device_ (which is a QPixmap). The speedup
> is awesome. Unfortunately the core is not prepared for that k
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Peter Kümmel wrote:
The most time is spend in the Qt function QPainter::drawText.
Could this time be reduced?
I came to the same conclusion with the Mac profiling done by Bennett. I
guess we can't do much about QPainter::drawText beca
Angus Leeming wrote:
Abdelrazak Younes wrote
Angus Leeming wrote:
I'm nervous about your comment to Bo about the Sconscript
having a circlar qt4->frontends->qt4 dependency. We avoid such
dependencies by use of a factory method to generate concrete
instances of classes whose interface is defin
Not sure if this is a known phenomenon, but version 1.4.1 (which was
working) is now broken, and I'm pretty sure the cause is my installing
1.4.svn (Joost's installer).
Symptoms: View->Draft DVI results in a Windows error box saying
"Windows can't find 'auto'." The LyX error message is "An e
Abdelrazak Younes wrote:
And yet another one updated from latest SVN that contained some qt4
changes.
And the patch...
Index: src/BufferView.C
===
--- src/BufferView.C(revision 14001)
+++ src/BufferView.C(working copy)
@@
And yet another one updated from latest SVN that contained some qt4 changes.
Abdel
_
Log:
This patch split introduce a new Clipboard class that contains the
clipboard related methods of WorkArea. The effective splitup has only be
done for qt4. Once the xforms,
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> The most time is spend in the Qt function QPainter::drawText.
>> Could this time be reduced?
>
> I came to the same conclusion with the Mac profiling done by Bennett. I
> guess we can't do much about QPainter::drawText because this is part of
> the
Abdelrazak Younes wrote
> Angus Leeming wrote:
>> I'm nervous about your comment to Bo about the Sconscript
>> having a circlar qt4->frontends->qt4 dependency. We avoid such
>> dependencies by use of a factory method to generate concrete
>> instances of classes whose interface is defined in src/fr
Abdelrazak Younes wrote:
Peter Kümmel wrote:
then it will crash, because qApp->mainWidget() returns a invalid pointer.
mainWidget has been set before the patch by QtView, but the setMainWidget
call has been removed by the patch, so all-or-nothing, sorry.
OK, I'll fix that, sorry.
Done.
Peter Kümmel wrote:
then it will crash, because qApp->mainWidget() returns a invalid pointer.
mainWidget has been set before the patch by QtView, but the setMainWidget
call has been removed by the patch, so all-or-nothing, sorry.
OK, I'll fix that, sorry.
Abdel.
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Here a patch which avoids a virtual call
>> and the the allocations when calling
>> Painter::lines.
>>
>> I've tested it with Qt4, but the changes are
>> similar to the other frontends, and should
>> make no problem.
>
> Do you have numbers that sh
Abdelrazak Younes wrote:
Hello,
Here is my big clipbard and workarea cleanup patch. I have worked a lot
on this one so please don't tell me it can't go in because of missing
full split-up of other frontends. This patch should not remove anything
from them and I expect others to do the work if
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Abdelrazak Younes wrote:
>>
>>
>>> Do you want to wait until you have or do you want me to put this in for
>>> you?
>>>
>>
>> It would be great when you could check it in, my diffs are too big :)
>>
>
> I have committed all changes except
Peter Kümmel wrote:
The most time is spend in the Qt function QPainter::drawText.
Could this time be reduced?
I came to the same conclusion with the Mac profiling done by Bennett. I
guess we can't do much about QPainter::drawText because this is part of
the Qt API.
Abdel.
Peter Kümmel wrote:
Here a patch which avoids a virtual call
and the the allocations when calling
Painter::lines.
I've tested it with Qt4, but the changes are
similar to the other frontends, and should
make no problem.
Do you have numbers that shows the speedup? It will facilitate the
approva
Peter Kümmel wrote:
Abdelrazak Younes wrote:
Do you want to wait until you have or do you want me to put this in for
you?
It would be great when you could check it in, my diffs are too big :)
I have committed all changes except for the one touching QWorkArea. They
are merged in
Abdelrazak Younes wrote:
>Angus Leeming wrote:
>> In src/frontends/gtk/WorkAreaFactory.C you
>> introduce a new static global variable.
> By the way, I have always believed that, in C++, the
> keyword static in this case is to say that this
> variable is _not_ global but reserved to this file.
Angus Leeming wrote:
In src/frontends/gtk/WorkAreaFactory.C you introduce a new static global
variable.
By the way, I have always believed that, in C++, the keyword static in
this case is to say that this variable is _not_ global but reserved to
this file. This is different for a static var
Angus Leeming wrote:
I'm nervous about your comment to Bo about the Sconscript having a
circlar qt4->frontends->qt4 dependency. We avoid such dependencies by
use of a factory method to generate concrete instances of classes
whose interface is defined in src/frontends. All subsequent use is
throug
Peter Kümmel wrote:
> complete QLPainter member functions:
> Scope 12,ms : 1236 -> setQPainterPen
> Scope 14,ms : 812 -> line
> Scope 15,ms : 172
> Scope 16,ms : 46
> Scope 17,ms : 3683 -> fillRectangle
> Scope 20,ms : 16
> Scope 22,ms : 514
> Scope 23,ms : 201
>
The http://news.gmane.org/gmane.editors.lyx.devel interface is "down for
maintenance", so I'm posting this from my email account; sorry to break the
thread. If you CC leeming AT lyx.org in any reply, it'll help me not break the
thread any further.
Angus
I'm nervous about your comment to Bo abo
Angus Leeming wrote:
> It would appear to me that introducing unicode now will kill off any serious
> attempt to speed up the Qt frontend.
>
> Of course, I'd love to be proved wrong ;-) Maybe Abdel's Qt clean up will fix
> things as if by magic ;-)
Here some statistics of QLPainter functions:
I'
Edwin Leuven wrote:
Georg Baum wrote:
Am Sonntag, 4. Juni 2006 16:28 schrieb Abdelrazak Younes:
I said that I was going to fix it the proper way after my
reorganisation. Your patch is touching a lot of things everywhere. I
already plan to have a hard time convincing Lars and JMarc about my
c
Georg Baum wrote:
Am Sonntag, 4. Juni 2006 16:28 schrieb Abdelrazak Younes:
I said that I was going to fix it the proper way after my
reorganisation. Your patch is touching a lot of things everywhere. I
already plan to have a hard time convincing Lars and JMarc about my
change to BufferView s
Peter Kümmel wrote:
Peter Kümmel wrote:
The change to the other functions is similar.
Peter
it seems
void Painter::fillPolygon(int const * xp, int const * yp,
int np, LColor_color col)
is never used.
No, AFAIR, JMarc replaced its use with something else. So I guess it can go.
Pe
Hello,
Here is my big clipbard and workarea cleanup patch. I have worked a lot
on this one so please don't tell me it can't go in because of missing
full split-up of other frontends. This patch should not remove anything
from them and I expect others to do the work if they feel the need to
(w
On Sun, Jun 04, 2006 at 06:27:11PM +0200, Juergen Spitzmueller wrote:
> Enrico Forestieri wrote
> > Please, don't fix what is not broken...
>
> I certainly won't fix it (my knowledge on shell scripting is close to zero,
> so
> thanks for your explanations).
> Note, however, that something *is*
Enrico Forestieri wrote
> Please, don't fix what is not broken...
I certainly won't fix it (my knowledge on shell scripting is close to zero, so
thanks for your explanations).
Note, however, that something *is* broken. The script crashes on Edwins box
(and we have a similar report from a window
On Sun, Jun 04, 2006 at 01:59:28PM +0200, Juergen Spitzmueller wrote:
> Edwin Leuven wrote:
> > > Edwin, does the situation improve if you change that?
> >
> > i have different script here (that looks ok):
>
> Fine. So my suspicion was basically right. You'll send a patch, won't you?
Please, don
On Sun, Jun 04, 2006 at 01:33:41PM +0200, Edwin Leuven wrote:
> Juergen Spitzmueller wrote:
> > if test -z "$COMSPEC" || test -z "$ComSpec"; then SEP=':'; else SEP=';'; fi
> >
> > Edwin, does the situation improve if you change that?
>
> i have different script here (that looks ok):
It is exact
On Sun, Jun 04, 2006 at 01:18:37PM +0200, Juergen Spitzmueller wrote:
> Edwin Leuven wrote:
> > > It looks like the script fails (sh crashes), so that it has to be
> > > re-run everytime. You should investigate why it cashes on windows.
> >
> > yeah, but time is probably better spent getting rid o
Juergen Spitzmueller wrote:
Edwin Leuven wrote:
it's the script that's in trunk: i didn't touch it (dunno anything about
shell scripting...)
I see. But does it solve your problem?
no, i had the problem with this in the first place...
If so, it should probably be backported
to branch.
i s
Angus Leeming wrote:
> Peter Kümmel <[EMAIL PROTECTED]> writes:
>>> Yes, it's MSVC. It's a performance warning about possibly loosing
>>> precision due to the automatic cast. You can get rid of the warning via
>>> an explicit cast.
>>>
>>> + return bool(provides_ & p);
>> Yes, that's a better
Peter Kümmel wrote:
> The change to the other functions is similar.
>
> Peter
>
>
it seems
void Painter::fillPolygon(int const * xp, int const * yp,
int np, LColor_color col)
is never used.
Peter Kümmel <[EMAIL PROTECTED]> writes:
> > Yes, it's MSVC. It's a performance warning about possibly loosing
> > precision due to the automatic cast. You can get rid of the warning via
> > an explicit cast.
> >
> > + return bool(provides_ & p);
>
> Yes, that's a better solution.
It's cer
Georg Baum <[EMAIL PROTECTED]> writes:
> > Could you post a patch (or provide a link to the patch if it's huge)?
> I am not Lars, but I just checked the branch out yesterday, so here is the
> patch.
Thanks.
> > There seems to be a lot of good stuff going on at the moment;
> > would be a shame t
Abdelrazak Younes wrote:
> Angus Leeming wrote:
>> Georg Baum <[EMAIL PROTECTED]> writes:
- return provides_ & p;
+ return (provides_ & p) != 0;
}
>>
>>> I have the feeling that you will get objections for things like this
>>> from others.
>>
>> Ceratinly, it seems unnce
Am Sonntag, 4. Juni 2006 16:28 schrieb Abdelrazak Younes:
> I said that I was going to fix it the proper way after my
> reorganisation. Your patch is touching a lot of things everywhere. I
> already plan to have a hard time convincing Lars and JMarc about my
> change to BufferView so I don't fe
Angus Leeming wrote:
Georg Baum <[EMAIL PROTECTED]> writes:
- return provides_ & p;
+ return (provides_ & p) != 0;
}
I have the feeling that you will get objections for things like this from
others.
Ceratinly, it seems unncesessary. C++ (unlike C#) has an implicit cast from int
Georg Baum <[EMAIL PROTECTED]> writes:
> > + return deplist.size() != 0;
>
> We use
> + return !deplist.empty();
> all over the place.
Right. And using "empty()" is often much faster than "size() != 0", so it's a
good habbit to get into.
> > - return provides_ & p;
> > +
Am Sonntag, 4. Juni 2006 16:08 schrieb Angus Leeming:
> Could you post a patch (or provide a link to the patch if it's huge)?
I am not Lars, but I just checked the branch out yesterday, so here is the
patch.
> M. There are so few active devs, that I think you have to be very
careful
> abou
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> Angus Leeming wrote:
> > Abdelrazak Younes ...> writes:
> >> G. gmane's web interface is a PITA!
>
> Why don't you use
It's a personal thing (and probably ridiculous ;-)) I'm
happy reading a web page on a work machine; less happy installing
Georg Baum wrote:
Am Sonntag, 4. Juni 2006 13:38 schrieb Abdelrazak Younes:
"QClipboard::Selection" doesn't make sense under Mac and Windows so I am
fixing that.
But in a wrong way. I know that the system clipboard does not work at all
on windows, and I understand that you want to fix it. My
Am Sonntag, 4. Juni 2006 13:36 schrieb Edwin Leuven:
> Georg Baum wrote:
> > The patch I sent yesterday seems basically to work, but it needs some
fine
> > tuning and testing. I hoped that Edwin would do that.
>
> he probably will if he finds some time (perhaps in a week or so...)
Great!
> > b
Am Sonntag, 4. Juni 2006 14:06 schrieb Peter Kümmel:
> And here a patch which removes a lot of
> warning about performance and some
> signed/unsigned mismatches.
I see the signed/unsigned things, but which changes should have something
to do with performance? Which compiler is that?
> Index: D
Am Sonntag, 4. Juni 2006 13:38 schrieb Abdelrazak Younes:
> I've seen your patch and I will work on it afterward. Now, I just want
> to fix was is obviously wrong. Up to now, "QClipboard::Selection" is
> used everywhere so it's not like I am removing something.
No, you don't remove anything.
>
Abdelrazak Younes wrote:
> Do you want to wait until you have or do you want me to put this in for
> you?
It would be great when you could check it in, my diffs are too big :)
Peter
Peter Kümmel wrote:
If yes, why not inverting the QT3_SUPPORT macro logic:
not defining it for the whole project, but only in
front of the cpp file?
Why not indeed. If you want you could provide a patch to qt.m4 and scons
that will remove the QT3_SUPPORT.
It's just a removing, but
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> I have been making small progress on the unicode branch
> (svn://svn.lyx.org/lyx/lyx-devel/branches/personal/larsbj/unicode),
> but the work is comming along really slow.
Could you post a patch (or provide a link to the patch if it's huge)?
>
> As
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
G. gmane's web interface is a PITA!
Why don't you use
Here're my comments about the code. Executive summary: I don't like the fact
that Application and WorkaArea both derive from Clipboard.
Me neither, it was a temporar
The change to the other functions is similar.
Peter
Here a patch which avoids a virtual call
and the the allocations when calling
Painter::lines.
I've tested it with Qt4, but the changes are
similar to the other frontends, and should
make no problem.
Here the current Painter::lines implementations:
Qt4:
see patch
Qt3:
void QLPainter::lines(int
Abdelrazak Younes wrote:
> Peter Kümmel wrote:
>> Hi,
>>
>> is there interest to also drop all functions
>> enabled by the QT3_SUPPORT macro?
>
> Of course there is! ;-)
Fine, then I will do more on that.
>
>> If yes, why not inverting the QT3_SUPPORT macro logic:
>> not defining it for the who
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> G. gmane's web interface is a PITA!
Here're my comments about the code. Executive summary: I don't like the fact
that Application and WorkaArea both derive from Clipboard. I'd much rather see a
Clipboard member variable. What's the rationale for
Peter Kümmel wrote:
And here a patch which removes a lot of
warning about performance and some
signed/unsigned mismatches.
They all seems safe.
Abdel.
Edwin Leuven wrote:
> it's the script that's in trunk: i didn't touch it (dunno anything about
> shell scripting...)
I see. But does it solve your problem? If so, it should probably be backported
to branch.
Jürgen
Peter Kümmel wrote:
Hi,
is there interest to also drop all functions
enabled by the QT3_SUPPORT macro?
Of course there is! ;-)
If yes, why not inverting the QT3_SUPPORT macro logic:
not defining it for the whole project, but only in
front of the cpp file?
Why not indeed. If you want you co
Bo Peng wrote:
> So I guess debug is not supported after all. (Maybe someone can try to
> set a breakpoint and run.)
I've tried this, but there are no debug infos. But I think
it's possible to solve this with some more compiler/linker flags.
> As of slow starting, under command line, one can use
Juergen Spitzmueller wrote:
Edwin Leuven wrote:
Edwin, does the situation improve if you change that?
i have different script here (that looks ok):
Fine. So my suspicion was basically right. You'll send a patch, won't you?
it's the script that's in trunk: i didn't touch it (dunno anything a
And here a patch which removes a lot of
warning about performance and some
signed/unsigned mismatches.
Peter
Index: DepTable.C
===
--- DepTable.C (Revision 13994)
+++ DepTable.C (Arbeitskopie)
@@ -253,5 +253,5 @@
}
Edwin Leuven wrote:
> > Edwin, does the situation improve if you change that?
>
> i have different script here (that looks ok):
Fine. So my suspicion was basically right. You'll send a patch, won't you?
Jürgen
Hi,
is there interest to also drop all functions
enabled by the QT3_SUPPORT macro?
If yes, why not inverting the QT3_SUPPORT macro logic:
not defining it for the whole project, but only in
front of the cpp file?
Attached some patches, which frees from QT3_SUPPORT.
Peter
Index: QCommandBuffer.
Georg Baum wrote:
Am Sonntag, 4. Juni 2006 12:36 schrieb Abdelrazak Younes:
Please find an updated patch. I think it is OK now but I worked on it a
bit more. I had to change a bit the other frontends because I removed
clipboard methods from WorkArea and put them in a new Clipboard class. I
ha
Georg Baum wrote:
The patch I sent yesterday seems basically to work, but it needs some fine
tuning and testing. I hoped that Edwin would do that.
he probably will if he finds some time (perhaps in a week or so...)
besides some testing it only needs some code to disable
LFUN_PRIMARY_SELECTION
Juergen Spitzmueller wrote:
if test -z "$COMSPEC" || test -z "$ComSpec"; then SEP=':'; else SEP=';'; fi
Edwin, does the situation improve if you change that?
i have different script here (that looks ok):
DOSISH=no
case `uname -s` in
CYGWIN*|Cygwin*|cygwin*)
# MikTeX's kpsewhich says "kp
Edwin Leuven wrote:
> > It looks like the script fails (sh crashes), so that it has to be
> > re-run everytime. You should investigate why it cashes on windows.
>
> yeah, but time is probably better spent getting rid of the script
> altogether.
In the meantime I had a quick look at the script. I d
Am Sonntag, 4. Juni 2006 12:36 schrieb Abdelrazak Younes:
> Please find an updated patch. I think it is OK now but I worked on it a
> bit more. I had to change a bit the other frontends because I removed
> clipboard methods from WorkArea and put them in a new Clipboard class. I
> have also tran
Abdelrazak Younes wrote:
Georg Baum wrote:
I think it is almost ready but I have some infinite:
QObject::killTimer: timers cannot be stopped from another thread
when using Cut/Copy/Paste. I suspect that your patch will help me fix
that. So please put yours first and I'll do the merging.
I f
Georg Baum wrote:
Am Samstag, 3. Juni 2006 23:48 schrieb Abdelrazak Younes:
Corrected thanks. The doxygen comments are OK also.
Do you mean in the fixed patch (you did not send it). The doxygen comments
are not OK in your first patch (wrong file names).
Please find an updated patch. I think
Another trivial fix:
Log:
fix change tracking in replaceAll()
Modified:
lyx-devel/branches/personal/gerz/change-tracking/src/lyxfind.C
Michael
Index: lyxfind.C
===
--- lyxfind.C (Revision 13990)
+++ lyxfind.C (Arbeitskopie)
Am Sonntag, 4. Juni 2006 11:05 schrieb Michael Gerz:
> I am pretty sure that these converters were in configure.sh =>
Regression!
No, they were not (at least not in the last version before the change to
configure.py). I had them in my own preferences since a long time, but
always forgot to cha
On Sat, Jun 03, 2006 at 10:09:25PM -0700, Stephen Harris wrote:
> Stephen Harris wrote:
>
> >> Nico wrote:
> >> At the end, LyX started, but with the error message "This is not a LyX
> >> document", in a tiny, non-resizable window, and the error "bddraw = 0"
> >> in the dos box, seemingly repeati
Georg Baum wrote:
Imagemagick can't convert tgif files, so preview fails. This patch adds
the necessary converters and goes in now.
Jean-Marc, do you also want that for 1.4?
I am pretty sure that these converters were in configure.sh => Regression!
They should also be in configure.py in 1.
Am Samstag, 3. Juni 2006 23:48 schrieb Abdelrazak Younes:
> Corrected thanks. The doxygen comments are OK also.
Do you mean in the fixed patch (you did not send it). The doxygen comments
are not OK in your first patch (wrong file names).
> I thought this qt-immodule thing was a Qt3 only thing. I
Hi,
this fixes change tracking in text2.C:
fix calls to Paragraph::insertInset() and Paragraph::erase()
Michael
Index: text2.C
===
--- text2.C (Revision 13990)
+++ text2.C (Arbeitskopie)
@@ -617,7 +617,9 @@
{
BOOST_ASSERT(this
Imagemagick can't convert tgif files, so preview fails. This patch adds
the necessary converters and goes in now.
Jean-Marc, do you also want that for 1.4?
Georg
Log:
* lib/configure.py: Add tgif->png and tgif->ppm converters
Index: lib/configure.py
=
Hi,
another set of simple fixes to get the change tracking branch working.
Michael
PS: Only about 430 lines of patches are left...
Index: insettabular.C
===
--- insettabular.C (Revision 13990)
+++ insettabular.C (Arbeitskopie)
@@ -
On Sat, Jun 03, 2006 at 11:50:33PM +0200, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> >On Sat, Jun 03, 2006 at 07:38:29PM +0200, Abdelrazak Younes wrote:
> >>You don't want to give a go to the Qt4 version? ;-)
> >
> >
> >Here's the patch... I'm unable to test it here. Apply inside the qt4
>
80 matches
Mail list logo
