On 08/10/2009 06:23 PM, Pavel Sanda wrote:
Richard Heck wrote:
My thought was more simpleminded, but I don't know this code. Why do we
need a cache of the original image once the pixmap has been set? If the
original is changed, then presumably we want to reload. But if it doesn't
change, we
Richard Heck wrote:
> My thought was more simpleminded, but I don't know this code. Why do we
> need a cache of the original image once the pixmap has been set? If the
> original is changed, then presumably we want to reload. But if it doesn't
> change, we don't need access to it any more, do we
On 08/10/2009 05:01 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b,
a will be a shadow copy of b up until it is modified, thus occupying
zero additional memory.
On 08/10/2009 05:43 PM, Jon wrote:
Thanks for the suggestion! I will try a script to replace the default
converter,
BTW, how to add it to trac? Can you forward it to the lyx develop group?
http://www.lyx.org/trac/newticket
rh
Thanks for the suggestion! I will try a script to replace the default
converter,
BTW, how to add it to trac? Can you forward it to the lyx develop group?
On Mon, Aug 10, 2009 at 3:50 PM, rgheck wrote:
> On 08/10/2009 01:23 PM, bsmile wrote:
>
>> Dear Developers,
>>
>> I am wondering whether th
On 10/08/2009 23:34, Vincent van Ravesteijn wrote:
Are the spellcheck dictionaries in the memory ? I hope that I would
not have to read from disk everytime.
Nope, there is something called the disk cache. I am betting you will
never, ever noticed any slowdown because of this, pretty sure o
Are the spellcheck dictionaries in the memory ? I hope that I would
not have to read from disk everytime.
Nope, there is something called the disk cache. I am betting you will
never, ever noticed any slowdown because of this, pretty sure of that.
Abdel.
You realize the large problems w
On 10/08/2009 23:23, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 10/08/2009 23:10, Abdelrazak Younes wrote:
On 10/08/2009 23:03, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 10/08/2009 22:57, Vincent van Ravesteijn wrote:
you...@lyx.org schreef:
Author: younes
Abdelrazak Younes schreef:
On 10/08/2009 23:10, Abdelrazak Younes wrote:
On 10/08/2009 23:03, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 10/08/2009 22:57, Vincent van Ravesteijn wrote:
you...@lyx.org schreef:
Author: younes
Date: Mon Aug 10 22:54:22 2009
New Revision: 30970
On 10/08/2009 23:10, Abdelrazak Younes wrote:
On 10/08/2009 23:03, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 10/08/2009 22:57, Vincent van Ravesteijn wrote:
you...@lyx.org schreef:
Author: younes
Date: Mon Aug 10 22:54:22 2009
New Revision: 30970
URL: http://www.lyx.org/trac
On 10/08/2009 23:03, Vincent van Ravesteijn wrote:
Abdelrazak Younes schreef:
On 10/08/2009 22:57, Vincent van Ravesteijn wrote:
you...@lyx.org schreef:
Author: younes
Date: Mon Aug 10 22:54:22 2009
New Revision: 30970
URL: http://www.lyx.org/trac/changeset/30970
Log:
Move the inline spellche
Abdelrazak Younes schreef:
On 10/08/2009 22:57, Vincent van Ravesteijn wrote:
you...@lyx.org schreef:
Author: younes
Date: Mon Aug 10 22:54:22 2009
New Revision: 30970
URL: http://www.lyx.org/trac/changeset/30970
Log:
Move the inline spellchecking code from collectWords() to the row
drawing r
On 10/08/2009 22:57, Vincent van Ravesteijn wrote:
you...@lyx.org schreef:
Author: younes
Date: Mon Aug 10 22:54:22 2009
New Revision: 30970
URL: http://www.lyx.org/trac/changeset/30970
Log:
Move the inline spellchecking code from collectWords() to the row
drawing routine. The text row is spel
On 10/08/2009 22:46, rgheck wrote:
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b,
a will be a shadow copy of b up until it is modified, thus occupying
zero additional memory. This is the same concept as shared pointer,
the
you...@lyx.org schreef:
Author: younes
Date: Mon Aug 10 22:54:22 2009
New Revision: 30970
URL: http://www.lyx.org/trac/changeset/30970
Log:
Move the inline spellchecking code from collectWords() to the row drawing
routine. The text row is spell checked only if changed!
Now inline SpellChecker
On 08/10/2009 04:21 PM, Abdelrazak Younes wrote:
QPixmap are implicitly shared. So this means that when you do a = b, a
will be a shadow copy of b up until it is modified, thus occupying
zero additional memory. This is the same concept as shared pointer,
the object, and thus the memory, is not
Abdelrazak Younes wrote:
> QPixmap are implicitly shared.
this was the missing brick.. thanks
pavel
On Mon, Aug 10, 2009 at 09:34:00PM +0200, Pavel Sanda wrote:
> hi,
> for the third time my system get frozen because of
> bug http://www.lyx.org/trac/ticket/5002.
>
> it seems when we load eg. jpg image to cache and rescale it, the
> original image is not forgoten so even small scale is of no help
On 10/08/2009 22:18, rgheck wrote:
On 08/10/2009 04:16 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the
details but
the original image is also stored somewhere else in the graphics
cache,
Piero schreef:
Hello, maybe this is a known issue.
I use LyX since versions 1.5 (till curren 1.6.3) and, as far as I can remember,
I've never been able to shut down Windows XP without manually closing LyX. (it
doesn't even ask to save my unsaved docs, unless I manually try to close LyX).
This i
On 08/10/2009 04:16 PM, Abdelrazak Younes wrote:
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the
details but
the original image is also stored somewhere else in the graphics
cache,
AFAIR.
which doesn't help me to u
On 10/08/2009 22:11, Pavel Sanda wrote:
Abdelrazak Younes wrote:
This code works and is not the problem. I don't remember the details but
the original image is also stored somewhere else in the graphics cache,
AFAIR.
which doesn't help me to understand what '// Clear the pixmap t
Abdelrazak Younes wrote:
>>> This code works and is not the problem. I don't remember the details but
>>> the original image is also stored somewhere else in the graphics cache,
>>> AFAIR.
>>>
>>
>> which doesn't help me to understand what '// Clear the pixmap to save some
>> memory'
>> mean
On 10/08/2009 21:55, Pavel Sanda wrote:
Abdelrazak Younes wrote:
but my question is simpler now:
why should original_ = QImage(); release the memory as the comment above
says?
if not what would be correct way of releasing it?
This code works and is not the problem. I don't remember
Abdelrazak Younes wrote:
>> but my question is simpler now:
>> why should original_ = QImage(); release the memory as the comment above
>> says?
>> if not what would be correct way of releasing it?
>>
>
> This code works and is not the problem. I don't remember the details but
> the original
On 08/10/2009 01:23 PM, bsmile wrote:
Dear Developers,
I am wondering whether the default settings of lyx works with metafont. I
guess not since the package feynmf uses metafont on the fly, but lyx cannot
generate the right pdf/dvi. If I guessed right, can you improve lyx to make
the metafont wo
On 10/08/2009 21:46, Pavel Sanda wrote:
Abdelrazak Younes wrote:
Very intricate!
The problem is not coming from Qt but from our own caching mechanism which
is heavy and is redundant with Qt own caching system. Last time I tried to
clean up this mess I stopped at this issue with a big headac
Abdelrazak Younes wrote:
> Very intricate!
>
> The problem is not coming from Qt but from our own caching mechanism which
> is heavy and is redundant with Qt own caching system. Last time I tried to
> clean up this mess I stopped at this issue with a big headache... The only
> sane solution is t
On 10/08/2009 21:39, Abdelrazak Younes wrote:
On 10/08/2009 21:34, Pavel Sanda wrote:
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small sca
On 10/08/2009 21:34, Pavel Sanda wrote:
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small scale is of no help
and more print-ready image are
hi,
for the third time my system get frozen because of
bug http://www.lyx.org/trac/ticket/5002.
it seems when we load eg. jpg image to cache and rescale it, the
original image is not forgoten so even small scale is of no help
and more print-ready image are able to knock system down.
the code look
On 10/08/2009 20:27, rgheck wrote:
On 08/10/2009 02:03 PM, Manoj Rajagopalan wrote:
Thanks, Richard and Vincent.
For a long time I've wished for a LaTeX rendering widget in Qt. I do
a lot of
scientific computing and I'd like my GUI's to contain label widgets that
display greek symbols etc. an
On 10/08/2009 21:02, Pavel Sanda wrote:
Abdelrazak Younes wrote:
1) Disable inline spellchecking. Measure the time to load the User Guide.
Do it twice in order to have the file in cache.
cant be this solved by asynchro call for inline spellcheck similarly we do
for images loading?
Abdelrazak Younes wrote:
> 1) Disable inline spellchecking. Measure the time to load the User Guide.
> Do it twice in order to have the file in cache.
cant be this solved by asynchro call for inline spellcheck similarly we do
for images loading?
pavel
Jean-Marc Lasgouttes wrote:
> > > Unfortunately not. However, it might be worth have this new sort of
> > > alert (if we want to implement "don't ask me next time" type of
> > > alerts).
> >
> > would you be satisfied when i change this patch so that
> > Alert::warning(_("Emergency file deleted") h
On Mon, Aug 10, 2009 at 02:03:09PM -0400, Manoj Rajagopalan wrote:
> Thanks, Richard and Vincent.
>
> For a long time I've wished for a LaTeX rendering widget in Qt. I do a
> lot of scientific computing and I'd like my GUI's to contain label
> widgets that display greek symbols etc. and what bette
On 08/10/2009 02:03 PM, Manoj Rajagopalan wrote:
Thanks, Richard and Vincent.
For a long time I've wished for a LaTeX rendering widget in Qt. I do a lot of
scientific computing and I'd like my GUI's to contain label widgets that
display greek symbols etc. and what better way to do this than to h
Manoj Rajagopalan wrote:
>
> Thanks, Richard and Vincent.
>
> For a long time I've wished for a LaTeX rendering widget in Qt. I do a lot of
> scientific computing and I'd like my GUI's to contain label widgets that
> display greek symbols etc. and what better way to do this than to have a
> co
Hello, maybe this is a known issue.
I use LyX since versions 1.5 (till curren 1.6.3) and, as far as I can remember,
I've never been able to shut down Windows XP without manually closing LyX. (it
doesn't even ask to save my unsaved docs, unless I manually try to close LyX).
This is not that annoyi
>y guess is there should be a fontmap somewhere that
>maps latex symbols to the glyphs to be printed and
>this info should be read sometime after the call to
>Cursor::macroModeClose(). Latex has an elaborate
>font-map setup for this.
Have a look at lib\symbols.
There you see, for example:
#
#
Thanks, Richard and Vincent.
For a long time I've wished for a LaTeX rendering widget in Qt. I do a lot of
scientific computing and I'd like my GUI's to contain label widgets that
display greek symbols etc. and what better way to do this than to have a
constructor that interprets a subset of l
>In math mode, when I select the menu item for the greek alpha
>character, or when I type \alpha within the inline equation box and
>then press TAB, how does lyx render this to the character?
You should be somewhat clearer what you mean with 'render'.
The general story is that each keypress wil
On 08/10/2009 01:19 PM, Manoj Rajagopalan wrote:
Hi all,
In math mode, when I select the menu item for the greek alpha character, or
when I type \alpha within the inline equation box and then press TAB, how
does lyx render this to the character?
This looks like one for devel, so I'm mo
Am Montag 10 August 2009 schrieb Abdelrazak Younes:
> Abdelrazak Younes wrote:
> > Kornel Benko wrote:
> >> Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> >>> Kornel Benko wrote:
> Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> > Kornel Benko wrote:
> >> Am Monday 10 Augu
Dear Developers,
I am wondering whether the default settings of lyx works with metafont. I
guess not since the package feynmf uses metafont on the fly, but lyx cannot
generate the right pdf/dvi. If I guessed right, can you improve lyx to make
the metafont work with lyx? As far as I could see, thi
Abdelrazak Younes wrote:
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Hello
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Hello Kornel,
Don't kn
Jean-Marc Lasgouttes wrote:
I am not sure if it is spell() or suggest() that is so slow but I will
investigate.
Both are very slow (maybe 10 or 20 times as slow as aspell).
Can it be related to this thread
http://www.mail-archive.com/d...@lingucomponent.openoffice.org/msg01827.html
>> I am not sure if it is spell() or suggest() that is so slow but I will
>> investigate.
>
> Both are very slow (maybe 10 or 20 times as slow as aspell).
Can it be related to this thread
http://www.mail-archive.com/d...@lingucomponent.openoffice.org/msg01827.html
Did you check with different lan
Abdelrazak Younes wrote:
At least on Linux/ubuntu On Windows, with my self compile
hunspell, it seemed quite fast.
Just do this test:
1) Disable inline spellchecking. Measure the time to load the User
Guide. Do it twice in order to have the file in cache.
2) Enable inline spellchecking and
> Jean-Marc Lasgouttes wrote:
> > Pavel Sanda writes:
> >
> > > Jean-Marc Lasgouttes wrote:
> > >> I think that too many dialogs mean that people won't read them. I
> > >> prefer the approach with a new checkbox as proposed in the bug, since
> > >> it explicitly tells that the file will be deleted
On 08/10/2009 05:30 AM, Pavel Sanda wrote:
Richard Heck wrote:
what version we need, etc. The only difference I see has to do with the
first line (), so perhaps that can just be removed.
this line was causing problems with older qt.
and i would also ask whether the rowpainte
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> Kornel Benko wrote:
> > Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> >
> >> Kornel Benko wrote:
> >>
> >>> Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> >>>
> >>>
> Hello Kornel,
>
> Don't know i
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Hello Kornel,
Don't know if you're aware of that but it seems that CMake prefer /usr
over /usr/local. I have compiled and installe
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> Kornel Benko wrote:
> > Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> >
> >> Hello Kornel,
> >>
> >> Don't know if you're aware of that but it seems that CMake prefer /usr
> >> over /usr/local. I have compiled and installed hunspell
Kornel Benko wrote:
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
Hello Kornel,
Don't know if you're aware of that but it seems that CMake prefer /usr
over /usr/local. I have compiled and installed hunspell in "/usr/local"
but CMake persists in taking the version in "/usr"...
Am Monday 10 August 2009 schrieb Abdelrazak Younes:
> Hello Kornel,
>
> Don't know if you're aware of that but it seems that CMake prefer /usr
> over /usr/local. I have compiled and installed hunspell in "/usr/local"
> but CMake persists in taking the version in "/usr"...
You may give cmake a h
Hello Kornel,
Don't know if you're aware of that but it seems that CMake prefer /usr
over /usr/local. I have compiled and installed hunspell in "/usr/local"
but CMake persists in taking the version in "/usr"...
Idea?
Abdel.
Richard Heck wrote:
> what version we need, etc. The only difference I see has to do with the
> first line (), so perhaps that can just be removed.
this line was causing problems with older qt.
>> and i would also ask whether the rowpainter part couldn't
>> be optimized through some cache?
>
>> A waste of what exactly ?
>
>time and energy to create and maintain :)
>
For now, this discussion has wasted more time and energy than it took me
to create them.
>> I didn't realize that they were there too, so you can remove my pages
then (as I seem not to be able or allowed to do that).
>
At least on Linux/ubuntu On Windows, with my self compile hunspell,
it seemed quite fast.
Just do this test:
1) Disable inline spellchecking. Measure the time to load the User
Guide. Do it twice in order to have the file in cache.
2) Enable inline spellchecking and select "aspell" spellchec
Vincent van Ravesteijn - TNW wrote:
> > isnt creating new page for each new version waste ?
> > this is not enough: http://www.lyx.org/RoadMap ?
>
> A waste of what exactly ?
time and energy to create and maintain :)
> I didn't realize that they were there too, so you can remove my pages then
>
"Vincent van Ravesteijn - TNW" writes:
>> > All recent posts: http://wiki.lyx.org/Site/AllRecentChanges
>> >
>> > * http://wiki.lyx.org/LyX.NewInBranch162 . . . 2009-08-09 14:26 CEST
>> > by vfr * http://wiki.lyx.org/LyX.NewInBranch161 . . . 2009-08-09
>> > 14:28 CEST by vfr * http://wiki.lyx.o
> and i would also ask whether the rowpainter part couldn't
> be optimized through some cache?
>
>
Kadeuh ?
Vincent
> > All recent posts: http://wiki.lyx.org/Site/AllRecentChanges
> >
> > * http://wiki.lyx.org/LyX.NewInBranch162 . . . 2009-08-09 14:26 CEST
> > by vfr * http://wiki.lyx.org/LyX.NewInBranch161 . . . 2009-08-09
> > 14:28 CEST by vfr * http://wiki.lyx.org/LyX.NewInBranch . . .
> > 2009-08-09 14:3
Uwe Stöhr writes:
> It is not acceptable that this tex2lyx issue
> http://www.lyx.org/trac/ticket/6059
> eventually delays LyX 1.6.4. I therefore reverted now my controversial
> commit in branch and opt for the following solution that was basically
> proposed by Vincent:
Thanks. I am not sure wh
Vincent van Ravesteijn writes:
> Uwe Stöhr schreef:
>>> > You misunderstood my concept. I only remove things that are
>>> > definitively re-added by LyX, see above. Do you have an example
>>> > where this is not the case?
Actually, you remove things that are re-added by LyX, but without
checki
67 matches
Mail list logo
