Michael == Michael Gerz [EMAIL PROTECTED] writes:
Michael O I was in hope that this patch goes in 1.4.X :-) At
Michael least it shouldn't hurt.
Why do you think it was in my tree? There are a few things I would
like to try first.
JMarc
Andre == Andre Poenitz [EMAIL PROTECTED] writes:
Andre Note the i-- is in the 'test' position.
Ha! this is what I did not see!
JMarc
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico Latest patch (using prefixIs) attached.
At least the part that skips directories can go in now. It is the part
that avoids the crash.
Concerning the rest, I think it matches a bugzilla entry. Could you
look for it?
JMarc
Abdelrazak == Abdelrazak Younes [EMAIL PROTECTED] writes:
Abdelrazak Why did you reverted then? :-)
One thing at a time.
JMarc
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Actually it isn't quite that simple (we more or less have
Martin already what you describe)
Where?
JMarc
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).
This might well be
Beck, Andrew Thomas - BECAT001 [EMAIL PROTECTED] writes:
I have generally followed this outline:
http://marc.theaimsgroup.com/?l=lyx-develm=113523961018129q=p3
I found that if I don't modify the environment as described
and the configure script, it fails to find the qt libraries.
On Fri, Mar 17, 2006 at 09:36:20AM +0100, Jean-Marc Lasgouttes wrote:
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin Actually it isn't quite that simple (we more or less have
Martin already what you describe)
Where?
It isn't quite clear to you what you mean by display mode,
Martin Vermeer wrote:
On Thu, Mar 16, 2006 at 02:59:31PM +0100, Jean-Marc Lasgouttes wrote:
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Lars == Lars Gullik Bjønnes [EMAIL PROTECTED] writes:
Lars Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: |
On Fri, 2006-03-17 at 10:29 +0100, Helge Hafting wrote:
Martin Vermeer wrote:
...
This patch makes
every save intentional, which is a Good Thing.
Lyx already indicates if the document is changed or not.
I may still need to _save_ an unchanged document, because
I know I modified the
[EMAIL PROTECTED] wrote:
If it works go for it. The patch is sensible.
Yes. Apply it.
Done in trunk. Did you mean 1.4 with the above?
Georg
On Fri, 2006-03-17 at 11:51 +0200, Martin Vermeer wrote:
On Fri, 2006-03-17 at 10:29 +0100, Helge Hafting wrote:
Martin Vermeer wrote:
...
This patch makes
every save intentional, which is a Good Thing.
Lyx already indicates if the document is changed or not.
I may still
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 guess
Martin Vermeer [EMAIL PROTECTED] writes:
you should not be able to accidentally change that file's
date stamp (yes, that's the most hateful thing about re-saving
unchanged documents -- and no way within the known laws of physics to
revert it!)
touch -t 200602291200 myfile.lyx
? Or is
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...
I
On Fri, 2006-03-17 at 10:27 +, Angus Leeming wrote:
Martin Vermeer [EMAIL PROTECTED] writes:
you should not be able to accidentally change that file's
date stamp (yes, that's the most hateful thing about re-saving
unchanged documents -- and no way within the known laws of physics to
Martin Vermeer wrote:
Better solution would be to have your LyX docs in a version control
system. I wonder how many people have.
Me. And it really helps.
Georg
Georg Baum wrote:
Forget it. The patch is wrong, and I don't understand why it worked. In
fact, I don't understand where the tabular paste buffer is filled at all
when cutting.
AFAICS on a quick look, it's just a getStatus problem of LFUN_PASTE. I'm just
compiling a possible fix. I'll post it
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
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 within
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
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:
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
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico Latest patch (using prefixIs) attached.
At least the part that skips directories can go in now. It is the part
that avoids the crash.
Concerning the rest, I think it matches a
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?
Juergen Spitzmueller wrote:
AFAICS on a quick look, it's just a getStatus problem of LFUN_PASTE. I'm
just compiling a possible fix. I'll post it on bugzilla if it works.
OK, here's the patch. I think this is the correct fix.
Jürgen
Index: src/insets/insettabular.C
Is Edwin on Linux?
yes he is.
debian unstable, qt 4.1.1.
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 for
Georg Baum [EMAIL PROTECTED] writes:
Martin Vermeer wrote:
Better solution would be to have your LyX docs in a version control
system. I wonder how many people have.
Me. And it really helps.
Me too. And I agree :)
A.
Martin Vermeer wrote:
The patch that I proposed restricts going Wide to insets having a
minimum total text height corresponding to more than two rows (Tall).
This appears to work well in my testing. It is still possible to
construct pathological cases, but ordinary typing even inside a nested
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico You are right. I found
Enrico http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say
Enrico that this patch fixes precisely that bug ;-)
Probably, yes.
Enrico Jean-Marc, what about the patch attached at bug 2344?
Enrico
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen Juergen Spitzmueller wrote:
AFAICS on a quick look, it's just a getStatus problem of
LFUN_PASTE. I'm just compiling a possible fix. I'll post it on
bugzilla if it works.
Juergen OK, here's the patch. I think this is the
Juergen Spitzmueller wrote:
Juergen Spitzmueller wrote:
AFAICS on a quick look, it's just a getStatus problem of LFUN_PASTE. I'm
just compiling a possible fix. I'll post it on bugzilla if it works.
OK, here's the patch. I think this is the correct fix.
It works fine for me, I think you
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge Lyx already indicates if the document is changed or not. I may
Helge still need to _save_ an unchanged document, because I know I
Helge modified the .lyx file through other means: * I copied another
Helge file over it (most common) * I
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg [EMAIL PROTECTED] wrote:
If it works go for it. The patch is sensible.
Yes. Apply it.
Georg Done in trunk. Did you mean 1.4 with the above?
Yes.
JMarc
The reason for bug 2380 is that awful BufferView cache in InsetText. It does
not get set correctly for table cells, and therefore we get an assert
sooner or later. The patch fixes that by always constructing the cell
insets with a valid BufferView. The other possibility would be to get rid
of the
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());
+
Jean-Marc Lasgouttes wrote:
It looks good. If georg can confirm that it works, it can go in trunk
and branch.
Done.
Jürgen
P.S.: I also switched to non-ChangeLog mode for trunk, but keep on using
ChangeLogs for branch.
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg The reason for bug 2380 is that awful BufferView cache in
Georg InsetText. It does not get set correctly for table cells, and
Georg therefore we get an assert sooner or later.
Ah, I understand the patch now. Where does the cache get set
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
Juergen == Juergen Spitzmueller [EMAIL PROTECTED] writes:
Juergen P.S.: I also switched to non-ChangeLog mode for trunk, but
Juergen keep on using ChangeLogs for branch.
Good man.
JMarc
Jean-Marc Lasgouttes wrote:
Georg == Georg Baum
[EMAIL PROTECTED]
writes:
Georg The reason for bug 2380 is that awful BufferView cache in
Georg InsetText. It does not get set correctly for table cells, and
Georg therefore we get an assert sooner or later.
Ah, I understand the patch
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
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
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
On Fri, Mar 17, 2006 at 02:49:13PM +0100, Abdelrazak Younes wrote:
...
Actually with your first patch, if you open a document, type Ctrl+end,
then only half of of screen is redrawn :-)
And if you open a new document (ctrl+n), the bottom part of the area is
not drawn.
Same with the second
Jean-Marc Lasgouttes [EMAIL PROTECTED] writes:
Enrico == Enrico Forestieri [EMAIL PROTECTED] writes:
Enrico You are right. I found
Enrico http://bugzilla.lyx.org/show_bug.cgi?id=1027 and I would say
Enrico that this patch fixes precisely that bug
Probably, yes.
Enrico Jean-Marc,
Martin Vermeer wrote:
On Fri, 2006-03-17 at 11:51 +0200, Martin Vermeer wrote:
On Fri, 2006-03-17 at 10:29 +0100, Helge Hafting wrote:
Martin Vermeer wrote:
...
This patch makes
every save intentional, which is a Good Thing.
Lyx already indicates if the
Dear Enrico,
I have problems with the -mms-bitfields option passed to gcc for cygwin
and Mingw ports. Is it something related to structure in memory
apparently. Do you know if it is still necessary? I would like to remove
that from cygwin.m4 or create a mingw.m4 but I am not really proficient
Jean-Marc Lasgouttes wrote:
Helge == Helge Hafting [EMAIL PROTECTED] writes:
Helge Lyx already indicates if the document is changed or not. I may
Helge still need to _save_ an unchanged document, because I know I
Helge modified the .lyx file through other means: * I copied
Abdelrazak Younes [EMAIL PROTECTED] writes:
Dear Enrico,
I have problems with the -mms-bitfields option passed to gcc for cygwin
and Mingw ports. Is it something related to structure in memory
apparently. Do you know if it is still necessary? I would like to remove
that from cygwin.m4
Enrico Forestieri a écrit :
Abdelrazak Younes [EMAIL PROTECTED] writes:
Dear Enrico,
I have problems with the -mms-bitfields option passed to gcc for cygwin
and Mingw ports. Is it something related to structure in memory
apparently. Do you know if it is still necessary? I would like to
Abdelrazak Younes [EMAIL PROTECTED] writes:
Next time I will try to get rid of it and tell you. I can't right now,
because building from scratch takes 1.5 hours for me.
OK, if you confirm that you don't have any problem without the option, I
would suggest to just eliminate it in
I compiled and installed lyx-1.4.0 (Qt frontend) on a SUSE 10 x86_64 box.
In lyx-1.4.0, I'm unable to edit and save a graphic. I wonder if I'm doing
something stupid. Anyway, here's the problem.
1. Open a new lyx file.
2. Insert a graphic using the Insert graphic button on the toolbar. Browse
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 Thu, Mar 16, 2006 at 10:10:39PM +0100, Lars Gullik Bjønnes wrote:
We already have that on most files...
Was part of the conversion process.
So people, if this is what you want, please fire up your auto-props:
(.subversion/config
enable-auto-props = yes
[auto-props]
* =
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 QPixmap.
On Thu, Mar 16, 2006 at 09:38:17PM +0100, Georg Baum wrote:
PS: We should really have eolstyle native on all source files.
No way.
Unix line endings everywhere are just fine.
And could be enforced by a precommit hook script.
I don't want mixed line endings, but it would be equally awkward
This patch removes qt2 support as discussed two weeks ago. It does not
touch the ui files, these should IMHO only be converted if they are
edited anyway. It does neither remove deprecated function calls, e.g.
QApplication::clipboard()-setSelectionMode(true|false). We should/need
only do that
Am Freitag, 17. März 2006 17:31 schrieb Enrico Forestieri:
Abdelrazak Younes [EMAIL PROTECTED] writes:
Next time I will try to get rid of it and tell you. I can't right
now,
because building from scratch takes 1.5 hours for me.
OK, if you confirm that you don't have any problem
Andre Poenitz [EMAIL PROTECTED] writes:
| I do hope you know what you are doing.
I am fairly confident yes.
| All but two 'problems' we had with svn during the last year and a half
| were due to people fiddling around with eol-style.
And I am not saying that we should fiddle with eol-style.
|
Georg Baum [EMAIL PROTECTED] writes:
| This patch removes qt2 support as discussed two weeks ago. It does not
| touch the ui files, these should IMHO only be converted if they are
| edited anyway. It does neither remove deprecated function calls, e.g.
|
Am Freitag, 17. März 2006 18:52 schrieb Andre Poenitz:
So, I think I stated that about four times now, but somehow nobody seems
to be exceptionally interested.
The other discussions were always about configure.ac. I did not understand
why the issue of changing the eol-style property of one
On Fri, Mar 17, 2006 at 01:42:12PM +0100, Georg Baum wrote:
Martin Vermeer wrote:
The patch that I proposed restricts going Wide to insets having a
minimum total text height corresponding to more than two rows (Tall).
This appears to work well in my testing. It is still possible to
Georg Baum [EMAIL PROTECTED] writes:
That means it is necessary if you want to link against libraries compiled
by a MS compiler, and it will hurt if you link against libraries compiled
by gcc without this switch.
Further investigation shows that this setting was added by Kayvan on
On Wed, Mar 15, 2006 at 08:48:31AM +0200, Martin Vermeer wrote:
Here is an improved patch.
100 lines added, 40 moved (indent change mostly). Not bad for something
that is already perfectly usable.
Please review.
Has anybody looked at this?
- Martin
pgp59XyMldjeG.pgp
Description: PGP
Am Freitag, 17. März 2006 21:03 schrieb Enrico Forestieri:
This was with Qt/Win, I'll later test Qt/X11 but I don't think it will
make a difference. So, at least with cygwin, I would say that
-mms-bitfield
is not needed. Moreover, if it is a gcc issue, why should it be needed
with mingw?
It
This was posted to bugzilla. Works for me.
- Martin
Index: insets/insetgraphics.C
===
--- insets/insetgraphics.C (revision 13302)
+++ insets/insetgraphics.C (working copy)
@@ -748,9 +748,15 @@
string after;
Title: RE: [patch] remove qt2 support
if qt2 goes, the attached should go (in) as well i think (i.e. remove qgridview.[Ch])
edwin
Index: qgridview.h
===
--- qgridview.h (revision 13415)
+++ qgridview.h (working copy)
@@
Thanks Angus. I can also confirm that they work fine.
Stephen Harris wrote:
The *.cmap/cset etc. were installed to C:\Aspell\lib\aspell-0.60
as I think they are supposed to be. But the default on the installer
reads C:\Aspell. Should this default read C:\Aspell\lib\aspell-0.60
like the default
On Fri, Mar 17, 2006 at 08:29:28PM +0100, Georg Baum wrote:
Am Freitag, 17. März 2006 17:31 schrieb Enrico Forestieri:
Abdelrazak Younes [EMAIL PROTECTED] writes:
Next time I will try to get rid of it and tell you. I can't right
now,
because building from scratch takes 1.5 hours
Sure, the extra trouble only ever occur for power users.
Perhaps we could have a new minibuffer command save-unchanged which
would save the document even if it is unchanged. Such power users
could replace save with save-unchanged in their .bind files etc.
If you _know_ it, it is OK to have to
Martin == Martin Vermeer [EMAIL PROTECTED] writes:
Martin On Wed, Mar 15, 2006 at 08:48:31AM +0200, Martin Vermeer
Martin wrote:
Here is an improved patch.
100 lines added, 40 moved (indent change mostly). Not bad for
something that is already perfectly usable.
Please review.
Martin
Joost Verburg [EMAIL PROTECTED] writes:
Thanks Angus. I can also confirm that they work fine.
Stephen Harris wrote:
The *.cmap/cset etc. were installed to C:\Aspell\lib\aspell-0.60
as I think they are supposed to be. But the default on the installer
reads C:\Aspell. Should this
Angus Leeming wrote:
Am I right in thinking that I don't actually need to use this again? Ie, the
AspellData-0.60.4.exe that's on the wiki is perfectly fine for LyX's purposes?
Assuming that's the case, why not try and upload this .nsi script to the wiki
yourself?
Joost Verburg [EMAIL PROTECTED] writes:
Angus Leeming wrote:
Am I right in thinking that I don't actually need to
use this again? Ie, the AspellData-0.60.4.exe that's
on the wiki is perfectly fine for LyX's purposes?
Assuming that's the case, why not try and upload this .nsi
script
Ok, I know that I'm a bit behind the times, but I've just uploaded LyX/Win
1.3.7-3 to http://wiki.lyx.org/Windows/LyX137. This thing uses the new
Aspell dictionaries and seems to work well.
Moving on to LyX/Win 1.4, what should I compile? The release tar ball or a
snapshot of the 1.4.x tree
Angus Leeming wrote:
The data installer does not have to be recompiled, but I think it would
be a good thing to upload new dictionary installers with the default
folder update.
Ok, will do.
Done.
A.
> "Michael" == Michael Gerz <[EMAIL PROTECTED]> writes:
Michael> O I was in hope that this patch goes in 1.4.X :-) At
Michael> least it shouldn't hurt.
Why do you think it was in my tree? There are a few things I would
like to try first.
JMarc
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Note the i-- is in the 'test' position.
Ha! this is what I did not see!
JMarc
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> Latest patch (using prefixIs) attached.
At least the part that skips directories can go in now. It is the part
that avoids the crash.
Concerning the rest, I think it matches a bugzilla entry. Could you
look for it?
JMarc
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Why did you reverted then? :-)
One thing at a time.
JMarc
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> Actually it isn't quite that simple (we more or less have
Martin> already what you describe)
Where?
JMarc
> "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).
>>
Beck, Andrew Thomas - BECAT001 <[EMAIL PROTECTED]> writes:
>
> I have generally followed this outline:
>
> http://marc.theaimsgroup.com/?l=lyx-devel=113523961018129=p3
>
> I found that if I don't modify the environment as described
> and the configure script, it fails to find the qt libraries.
On Fri, Mar 17, 2006 at 09:36:20AM +0100, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> Martin> Actually it isn't quite that simple (we more or less have
> Martin> already what you describe)
>
> Where?
It isn't quite clear to you what you mean
Martin Vermeer wrote:
On Thu, Mar 16, 2006 at 02:59:31PM +0100, Jean-Marc Lasgouttes wrote:
"Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
"Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Jean-Marc Lasgouttes <[EMAIL
On Fri, 2006-03-17 at 10:29 +0100, Helge Hafting wrote:
> Martin Vermeer wrote:
...
> > This patch makes
> >every save intentional, which is a Good Thing.
> >
> >
> Lyx already indicates if the document is changed or not.
> I may still need to _save_ an unchanged document, because
> I know I
[EMAIL PROTECTED] wrote:
>
>> If it works go for it. The patch is sensible.
>
> Yes. Apply it.
Done in trunk. Did you mean 1.4 with the above?
Georg
On Fri, 2006-03-17 at 11:51 +0200, Martin Vermeer wrote:
> On Fri, 2006-03-17 at 10:29 +0100, Helge Hafting wrote:
> > Martin Vermeer wrote:
>
> ...
>
> > > This patch makes
> > >every save intentional, which is a Good Thing.
> > >
> > >
> > Lyx already indicates if the document is changed or
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
Martin Vermeer <[EMAIL PROTECTED]> writes:
> you should not be able to accidentally change that file's
> date stamp (yes, that's the most hateful thing about re-saving
> "unchanged" documents -- and no way within the known laws of physics to
> revert it!)
touch -t 200602291200 myfile.lyx
?
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
On Fri, 2006-03-17 at 10:27 +, Angus Leeming wrote:
> Martin Vermeer <[EMAIL PROTECTED]> writes:
> > you should not be able to accidentally change that file's
> > date stamp (yes, that's the most hateful thing about re-saving
> > "unchanged" documents -- and no way within the known laws of
Martin Vermeer wrote:
> Better solution would be to have your LyX docs in a version control
> system. I wonder how many people have.
Me. And it really helps.
Georg
Georg Baum wrote:
> Forget it. The patch is wrong, and I don't understand why it worked. In
> fact, I don't understand where the tabular paste buffer is filled at all
> when cutting.
AFAICS on a quick look, it's just a getStatus problem of LFUN_PASTE. I'm just
compiling a possible fix. I'll post
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
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
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
1 - 100 of 158 matches
Mail list logo
