On Thu, 2005-05-05 at 17:25, Juergen Spitzmueller wrote:
>
> 2. LyX asserts when you move the cursor to another cell with the mouse and
> then type something _while_ the tabular dialog is opened.
> I get two different asserts:
>
> a.)
> Assertion triggered in CoordCacheBase& CoordCache::insets
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
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
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 wha
>
> ...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)
>
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 :)
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
> usea
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
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 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 (bo
Jose' Matos wrote:
> Will you do it, or do want me to patch it?
I'd like you to fix it.
--
Angus
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. ;-)
> A
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
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
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 thr
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
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/insetcommandparam
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 B
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
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
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
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()
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 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 lin
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
unness
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 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 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 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 (e
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. c
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 arab
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
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
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 t
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 'fore
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 c
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 'fore
37 matches
Mail list logo
