On Wed, May 04, 2005 at 08:22:13PM +0100, Angus Leeming wrote:
Angus Leeming wrote:
Martin,
I guess that this one is for you to test. Rather than draw a new line on
each cursor blink, I bitBlt cached pixmaps. It works (we still have a
blinking cursor, either 'normal' or 'foreign'), but
Martin Vermeer wrote:
On Wed, May 04, 2005 at 08:22:13PM +0100, Angus Leeming wrote:
Angus Leeming wrote:
Martin,
I guess that this one is for you to test. Rather than draw a new line
on each cursor blink, I bitBlt cached pixmaps. It works (we still have
a blinking cursor, either
On Thu, May 05, 2005 at 10:42:29AM +0100, Angus Leeming wrote:
Martin Vermeer wrote:
...
I guess that this one is for you to test. Rather than draw a new line
on each cursor blink, I bitBlt cached pixmaps. It works (we still have
a blinking cursor, either 'normal' or 'foreign'), but I
Martin Vermeer wrote:
I guess that this one is for you to test. Rather than draw a new
line on each cursor blink, I bitBlt cached pixmaps. It works (we
still have a blinking cursor, either 'normal' or 'foreign'), but I
have no idea whether it works as desired (zero traffic).
Michael Schmitt wrote:
Hello!
I harmonized the titles of the xforms and qt dialogs. (This will ease
the life of the translators.) In addition, I fixed a few messages that I
have already fixed in the 1.3 branch some weeks ago.
If nobody objects, please commit the patch. More patches
Angus Leeming wrote:
I applied all except the FormLog bit. Note this:
Sorry, I overlooked the Controller stuff. Thank you very much for the hint!
If you wish to standardise things between frontends you should
1. get the Qt dialogs to use the title defined by the Controller
2. clean up these titles
Hossein Noorikhah wrote:
Hi
By default, when I want to use an alternative language beside English, I
can seperate it in the commands needed to switch to that language, ... .
But now my problem is that I want to use an arabic context(really
persian, that has somehow similar script to arabic),
Michael Schmitt wrote:
I applied all except the FormLog bit. Note this:
Sorry, I overlooked the Controller stuff. Thank you very much for the
hint!
If you wish to standardise things between frontends you should
1. get the Qt dialogs to use the title defined by the Controller
2. clean up
On Thu, May 05, 2005 at 11:17:21AM +0100, Angus Leeming wrote:
Martin Vermeer wrote:
...
So we did some good, just not enough? Are you able to give me any
pointers to the remaining sources?
I doubled the blink rate (400 - 200 msec) and traffic went from 450 to
900 B/s (estimated;
On Thu, May 05, 2005 at 02:55:04PM +0300, Martin Vermeer wrote:
On Thu, May 05, 2005 at 11:17:21AM +0100, Angus Leeming wrote:
Martin Vermeer wrote:
...
If that hypothesis is correct, then the traffic is instructions to copy
one existing pixmap to an area of another existing pixmap
On Tue, May 03, 2005 at 08:54:25AM -0400, Rob Bearman wrote:
Based on yesterday's changes, could this patch be committed please? It
contains the updates to config.h and lyx.vcproj in the development\win32
directory.
I don't think it is necessary to have DOS line endings in our source
files.
On Tue, May 03, 2005 at 05:03:57PM +0100, Angus Leeming wrote:
Does this work for you? (Everything is, of course, fine here.)
Couldn't you simply
#define POPEN ::popen
#define POPEN ::_popen
#define POPEN bark
and use
FILE * inf = POPEN(cmd.c_str(), os::popen_read_mode());
instead
On Wed, May 04, 2005 at 02:45:05PM +0300, Martin Vermeer wrote:
tabular.C:
// returns 1 if a complete update is necessary, otherwise 0
void LyXTabular::setWidthOfCell(idx_type cell, int new_width)
Returns what?!?
This was a vital part in the old update architecture. Completely
unnessary
Andre Poenitz wrote:
On Tue, May 03, 2005 at 08:54:25AM -0400, Rob Bearman wrote:
Based on yesterday's changes, could this patch be committed please? It
contains the updates to config.h and lyx.vcproj in the development\win32
directory.
I don't think it is necessary to have DOS line
Am Dienstag, 3. Mai 2005 22:28 schrieb Angus Leeming:
It seems that something is going wrong on your side.
The reason was that I forgot to update autogen.sh - and I did not notice
it wanted to read the old *spell.m4 files. Sorry for bothering you,
everything is fine now.
Georg
Andre Poenitz wrote:
On Tue, May 03, 2005 at 05:03:57PM +0100, Angus Leeming wrote:
Does this work for you? (Everything is, of course, fine here.)
Couldn't you simply
#define POPEN ::popen
#define POPEN ::_popen
#define POPEN bark
and use
FILE * inf = POPEN(cmd.c_str(),
Juergen Spitzmueller wrote:
The patch fixes the drawing of the start appendix line (which was way off)
and the setOnOff handling in LyXText::getStatus (i.e. the visual feedback
of startAppendix, Noun and Emphasized).
committed both.
Jürgen
Martin Vermeer wrote:
Attached, please review
- Martin
tabular.getCellInset(cell)-metrics(m, dim);
+ if (!p_width.zero())
+ dim.wid = m.base.textwidth;
Well, I can see what it does, but it seems a bit ugly. Surely, this should
be happening inside of InsetText? Also, if
Martin Vermeer wrote:
Attached, please review
It works.
I stepped on two (unrelated) things while testing:
1. Do you also see the drawing error in the first cell (borders) when opening
the tabular dialog? It disapperas when you type something. Missing update?
2. LyX asserts when you move the
Hi,
am I the only one using FC3 with the latest gcc?
For some weeks I haven't been able to use the cvs version as I had an
assert reading files, something like:
$ src/lyx ~/newfile2.lyx
void BufferView::Pimpl::update(bool, bool)[fitcursor = 0, forceupdate = 1]
buffer: 0
void
Jose' Matos wrote:
Hi,
am I the only one using FC3 with the latest gcc?
If by latest you mean whatever ships with FC3, updated with up2date,
then no, you're not the only one. That's my home system too.
After I bit of research I found the culprit:
Index: src/insets/insetcommandparams.C
On Thu, May 05, 2005 at 05:23:56PM +0100, Angus Leeming wrote:
Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
No, it means what it says, one before the start of the array in this
case.
john
Hello,
as far as I can see, the titles of the Qt dialogs are set in the qt2/*.C
files. However, each qt2/ui/*.ui file defines a caption as well (which
also finds its way into the po files).
Since there are some inconsistencies between the titles specified in the
two sets of files, there are
Am Donnerstag, 5. Mai 2005 16:25 schrieb Juergen Spitzmueller:
1. Do you also see the drawing error in the first cell (borders) when
opening
the tabular dialog? It disapperas when you type something. Missing
update?
I see this too.
Georg
Michael Schmitt wrote:
Hello,
as far as I can see, the titles of the Qt dialogs are set in the qt2/*.C
files. However, each qt2/ui/*.ui file defines a caption as well (which
also finds its way into the po files).
Since there are some inconsistencies between the titles specified in the
On Thursday 05 May 2005 17:23, Angus Leeming wrote:
Is this the right fix?
Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
:-D
That is python, I knew that its influence was spreading inside of you, but
I didn't suspect its dissemination was so advanced. ;-)
Jose' Matos wrote:
Will you do it, or do want me to patch it?
I'd like you to fix it.
--
Angus
On Thu, May 05, 2005 at 04:25:07PM +0200, Juergen Spitzmueller wrote:
Martin Vermeer wrote:
Attached, please review
It works.
...but that's not necessarily good enough.
I stepped on two (unrelated) things while testing:
1. Do you also see the drawing error in the first cell (borders)
On Thursday 05 May 2005 18:39, Angus Leeming wrote:
I'd like you to fix it.
Is the attached patch OK?
I noticed that you have used '\0', for the null character is that style
favored over a plain 0?
Thanks,
--
José Abílio
? frontends/gtk/pch.h.gch
? frontends/gtk/pch.h.gch.dep
Index:
On Thu, May 05, 2005 at 03:09:36PM +0100, Angus Leeming wrote:
Martin Vermeer wrote:
Attached, please review
- Martin
tabular.getCellInset(cell)-metrics(m, dim);
+ if (!p_width.zero())
+ dim.wid = m.base.textwidth;
Well, I can see what it does, but it seems a
On Tue, May 03, 2005 at 09:35:37PM +0300, Martin Vermeer wrote:
On Tue, May 03, 2005 at 10:57:55AM +0300, Martin Vermeer wrote:
On Mon, May 02, 2005 at 06:53:26PM +0200, Juergen Spitzmueller wrote:
...
OK, I figured it out. The attached actually makes non-bibtex bibliography
useable
Jose' Matos wrote:
On Thursday 05 May 2005 18:39, Angus Leeming wrote:
I'd like you to fix it.
Is the attached patch OK?
I noticed that you have used '\0', for the null character is that style
favored over a plain 0?
shrugDunno/shrug
char const b (and c) wouldn't hurt though :)
...and wouldn't it be time to lay this to rest?
// ale070405 This function maybe shouldn't be here. We'll fix this at 0.13.
int bibitemMaxWidth(BufferView * bv, LyXFont const )
...as we have and actually use
// ale070405
string const bibitemWidest(Buffer const buffer)
- Martin
On Wed, May 04, 2005 at 08:49:59PM +0200, Andre Poenitz wrote:
On Wed, May 04, 2005 at 02:45:05PM +0300, Martin Vermeer wrote:
tabular.C:
// returns 1 if a complete update is necessary, otherwise 0
void LyXTabular::setWidthOfCell(idx_type cell, int new_width)
Returns what?!?
This
Martin Vermeer wrote:
Guess what: open a remote xterm over ssh with the command 'xterm -bc',
and you get a blinking cursor. And the same kind of ADSL traffic as with
LyX... that settles it, doesn't it: the authors of xterm know X better
than anyone.
Do you think that the 50bytes/sec saving is
On Thu, May 05, 2005 at 10:01:15PM +0100, Angus Leeming wrote:
Martin Vermeer wrote:
Guess what: open a remote xterm over ssh with the command 'xterm -bc',
and you get a blinking cursor. And the same kind of ADSL traffic as with
LyX... that settles it, doesn't it: the authors of xterm know
On Wed, May 04, 2005 at 08:22:13PM +0100, Angus Leeming wrote:
> Angus Leeming wrote:
> > Martin,
> >
> > I guess that this one is for you to test. Rather than draw a new line on
> > each cursor blink, I bitBlt cached pixmaps. It works (we still have a
> > blinking cursor, either 'normal' or
Martin Vermeer wrote:
> On Wed, May 04, 2005 at 08:22:13PM +0100, Angus Leeming wrote:
>> Angus Leeming wrote:
>> > Martin,
>> >
>> > I guess that this one is for you to test. Rather than draw a new line
>> > on each cursor blink, I bitBlt cached pixmaps. It works (we still have
>> > a blinking
On Thu, May 05, 2005 at 10:42:29AM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
...
> >> > I guess that this one is for you to test. Rather than draw a new line
> >> > on each cursor blink, I bitBlt cached pixmaps. It works (we still have
> >> > a blinking cursor, either 'normal' or
Martin Vermeer wrote:
>> >> > I guess that this one is for you to test. Rather than draw a new
>> >> > line on each cursor blink, I bitBlt cached pixmaps. It works (we
>> >> > still have a blinking cursor, either 'normal' or 'foreign'), but I
>> >> > have no idea whether it works as desired (zero
Michael Schmitt wrote:
> Hello!
>
> I harmonized the titles of the xforms and qt dialogs. (This will ease
> the life of the translators.) In addition, I fixed a few messages that I
> have already fixed in the 1.3 branch some weeks ago.
>
> If nobody objects, please commit the patch. More
Angus Leeming wrote:
I applied all except the FormLog bit. Note this:
Sorry, I overlooked the Controller stuff. Thank you very much for the hint!
If you wish to standardise things between frontends you should
1. get the Qt dialogs to use the title defined by the Controller
2. clean up these titles
Hossein Noorikhah wrote:
> Hi
> By default, when I want to use an alternative language beside English, I
> can seperate it in the commands needed to switch to that language, ... .
> But now my problem is that I want to use an arabic context(really
> persian, that has somehow similar script to
Michael Schmitt wrote:
>> I applied all except the FormLog bit. Note this:
>
> Sorry, I overlooked the Controller stuff. Thank you very much for the
> hint!
>
>>If you wish to standardise things between frontends you should
>>1. get the Qt dialogs to use the title defined by the Controller
>>2.
On Thu, May 05, 2005 at 11:17:21AM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
...
> >> So we did some good, just not enough? Are you able to give me any
> >> pointers to the remaining sources?
> >
> > I doubled the blink rate (400 -> 200 msec) and traffic went from 450 to
> > 900 B/s
On Thu, May 05, 2005 at 02:55:04PM +0300, Martin Vermeer wrote:
> On Thu, May 05, 2005 at 11:17:21AM +0100, Angus Leeming wrote:
> > Martin Vermeer wrote:
>
> ...
>
> > If that hypothesis is correct, then the traffic is instructions to copy
> > one existing pixmap to an area of another existing
On Tue, May 03, 2005 at 08:54:25AM -0400, Rob Bearman wrote:
> Based on yesterday's changes, could this patch be committed please? It
> contains the updates to config.h and lyx.vcproj in the development\win32
> directory.
I don't think it is necessary to have DOS line endings in our source
files.
On Tue, May 03, 2005 at 05:03:57PM +0100, Angus Leeming wrote:
> Does this work for you? (Everything is, of course, fine here.)
Couldn't you simply
#define POPEN ::popen
#define POPEN ::_popen
#define POPEN bark
and use
FILE * inf = POPEN(cmd.c_str(), os::popen_read_mode());
instead
On Wed, May 04, 2005 at 02:45:05PM +0300, Martin Vermeer wrote:
> tabular.C:
>
> // returns 1 if a complete update is necessary, otherwise 0
> void LyXTabular::setWidthOfCell(idx_type cell, int new_width)
>
> Returns what?!?
This was a vital part in the old update architecture. Completely
Andre Poenitz wrote:
> On Tue, May 03, 2005 at 08:54:25AM -0400, Rob Bearman wrote:
>> Based on yesterday's changes, could this patch be committed please? It
>> contains the updates to config.h and lyx.vcproj in the development\win32
>> directory.
>
> I don't think it is necessary to have DOS
Am Dienstag, 3. Mai 2005 22:28 schrieb Angus Leeming:
> It seems that something is going wrong on your side.
The reason was that I forgot to update autogen.sh - and I did not notice
it wanted to read the old *spell.m4 files. Sorry for bothering you,
everything is fine now.
Georg
Andre Poenitz wrote:
> On Tue, May 03, 2005 at 05:03:57PM +0100, Angus Leeming wrote:
>> Does this work for you? (Everything is, of course, fine here.)
>
> Couldn't you simply
>
> #define POPEN ::popen
> #define POPEN ::_popen
> #define POPEN bark
>
> and use
>
> FILE * inf =
Juergen Spitzmueller wrote:
> The patch fixes the drawing of the start appendix line (which was way off)
> and the setOnOff handling in LyXText::getStatus (i.e. the visual feedback
> of startAppendix, Noun and Emphasized).
committed both.
Jürgen
Martin Vermeer wrote:
> Attached, please review
>
> - Martin
tabular.getCellInset(cell)->metrics(m, dim);
+ if (!p_width.zero())
+ dim.wid = m.base.textwidth;
Well, I can see what it does, but it seems a bit ugly. Surely, this should
be happening inside of InsetText? Also,
Martin Vermeer wrote:
> Attached, please review
It works.
I stepped on two (unrelated) things while testing:
1. Do you also see the drawing error in the first cell (borders) when opening
the tabular dialog? It disapperas when you type something. Missing update?
2. LyX asserts when you move
Hi,
am I the only one using FC3 with the latest gcc?
For some weeks I haven't been able to use the cvs version as I had an
assert reading files, something like:
$ src/lyx ~/newfile2.lyx
void BufferView::Pimpl::update(bool, bool)[fitcursor = 0, forceupdate = 1]
buffer: 0
void
Jose' Matos wrote:
> Hi,
> am I the only one using FC3 with the latest gcc?
If by "latest" you mean whatever ships with FC3, updated with up2date,
then no, you're not the only one. That's my home system too.
> After I bit of research I found the culprit:
>
> Index:
On Thu, May 05, 2005 at 05:23:56PM +0100, Angus Leeming wrote:
> Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
No, it means what it says, one before the start of the array in this
case.
john
Hello,
as far as I can see, the titles of the Qt dialogs are set in the qt2/*.C
files. However, each qt2/ui/*.ui file defines a caption as well (which
also finds its way into the po files).
Since there are some inconsistencies between the titles specified in the
two sets of files, there are
Am Donnerstag, 5. Mai 2005 16:25 schrieb Juergen Spitzmueller:
> 1. Do you also see the drawing error in the first cell (borders) when
opening
> the tabular dialog? It disapperas when you type something. Missing
update?
I see this too.
Georg
Michael Schmitt wrote:
> Hello,
>
> as far as I can see, the titles of the Qt dialogs are set in the qt2/*.C
> files. However, each qt2/ui/*.ui file defines a caption as well (which
> also finds its way into the po files).
>
> Since there are some inconsistencies between the titles specified in
On Thursday 05 May 2005 17:23, Angus Leeming wrote:
> > Is this the right fix?
>
> Urs. Doesn't cmd[-1] mean cmd[cmd.length()-2]. Some nasty c-ism?
:-D
That is python, I knew that its influence was spreading inside of you, but
I didn't suspect its dissemination was so advanced. ;-)
>
Jose' Matos wrote:
> Will you do it, or do want me to patch it?
I'd like you to fix it.
--
Angus
On Thu, May 05, 2005 at 04:25:07PM +0200, Juergen Spitzmueller wrote:
> Martin Vermeer wrote:
> > Attached, please review
>
> It works.
...but that's not necessarily good enough.
> I stepped on two (unrelated) things while testing:
>
> 1. Do you also see the drawing error in the first cell
On Thursday 05 May 2005 18:39, Angus Leeming wrote:
>
> I'd like you to fix it.
Is the attached patch OK?
I noticed that you have used '\0', for the null character is that style
favored over a plain 0?
Thanks,
--
José Abílio
? frontends/gtk/pch.h.gch
? frontends/gtk/pch.h.gch.dep
Index:
On Thu, May 05, 2005 at 03:09:36PM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
>
> > Attached, please review
> >
> > - Martin
>
> tabular.getCellInset(cell)->metrics(m, dim);
> + if (!p_width.zero())
> + dim.wid = m.base.textwidth;
>
> Well, I can see what it does,
On Tue, May 03, 2005 at 09:35:37PM +0300, Martin Vermeer wrote:
> On Tue, May 03, 2005 at 10:57:55AM +0300, Martin Vermeer wrote:
> > On Mon, May 02, 2005 at 06:53:26PM +0200, Juergen Spitzmueller wrote:
>
> ...
>
> OK, I figured it out. The attached actually makes non-bibtex bibliography
>
Jose' Matos wrote:
> On Thursday 05 May 2005 18:39, Angus Leeming wrote:
>>
>> I'd like you to fix it.
>
> Is the attached patch OK?
>
> I noticed that you have used '\0', for the null character is that style
> favored over a plain 0?
Dunno
"char const b" (and c) wouldn't hurt though :)
>
> ...and wouldn't it be time to lay this to rest?
>
> // ale070405 This function maybe shouldn't be here. We'll fix this at 0.13.
> int bibitemMaxWidth(BufferView * bv, LyXFont const &)
>
> ...as we have and actually use
>
> // ale070405
> string const bibitemWidest(Buffer const & buffer)
>
On Wed, May 04, 2005 at 08:49:59PM +0200, Andre Poenitz wrote:
> On Wed, May 04, 2005 at 02:45:05PM +0300, Martin Vermeer wrote:
> > tabular.C:
> >
> > // returns 1 if a complete update is necessary, otherwise 0
> > void LyXTabular::setWidthOfCell(idx_type cell, int new_width)
> >
> > Returns
Martin Vermeer wrote:
> Guess what: open a remote xterm over ssh with the command 'xterm -bc',
> and you get a blinking cursor. And the same kind of ADSL traffic as with
> LyX... that settles it, doesn't it: the authors of xterm know X better
> than anyone.
Do you think that the 50bytes/sec
On Thu, May 05, 2005 at 10:01:15PM +0100, Angus Leeming wrote:
> Martin Vermeer wrote:
> > Guess what: open a remote xterm over ssh with the command 'xterm -bc',
> > and you get a blinking cursor. And the same kind of ADSL traffic as with
> > LyX... that settles it, doesn't it: the authors of
72 matches
Mail list logo
