On Wed, Jun 13, 2007 at 02:02:48PM +0200, Jean-Marc Lasgouttes wrote:
> > "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>
> >> And one of them is 'isActive()' (which probably {c,sh}ould be
> >> renamed)
> >>
>
> Martin> ...to hasText()?
>
> Or isDescendable().
Better.
Andre'
On Wed, Jun 13, 2007 at 02:09:39PM +0200, Stefan Schimanski wrote:
>
> Am 13.06.2007 um 14:02 schrieb Jean-Marc Lasgouttes:
>
> >> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
> >
> >>> And one of them is 'isActive()' (which probably {c,sh}ould be
> >>> renamed)
> >>>
> >
> > Mart
Am 13.06.2007 um 14:02 schrieb Jean-Marc Lasgouttes:
"Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
And one of them is 'isActive()' (which probably {c,sh}ould be
renamed)
Martin> ...to hasText()?
Or isDescendable().
+1
hasText() sounds like !cell(i).empty()
Stefan
PGP.sig
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
>> And one of them is 'isActive()' (which probably {c,sh}ould be
>> renamed)
>>
Martin> ...to hasText()?
Or isDescendable().
JMarc
Citeren Andre Poenitz <[EMAIL PROTECTED]>:
On Tue, Jun 12, 2007 at 09:18:45AM +0300, Martin Vermeer wrote:
On Mon, Jun 11, 2007 at 11:45:34PM +0200, Andre Poenitz wrote:
> On Mon, Jun 11, 2007 at 09:46:27PM +0300, Martin Vermeer wrote:
> > BTW I find isActive() not very clear. isHighlyEditable(
On Tue, Jun 12, 2007 at 09:18:45AM +0300, Martin Vermeer wrote:
> On Mon, Jun 11, 2007 at 11:45:34PM +0200, Andre Poenitz wrote:
> > On Mon, Jun 11, 2007 at 09:46:27PM +0300, Martin Vermeer wrote:
> > > BTW I find isActive() not very clear. isHighlyEditable() would be clearer.
> > > Is there the eq
On Mon, Jun 11, 2007 at 11:45:34PM +0200, Andre Poenitz wrote:
> On Mon, Jun 11, 2007 at 09:46:27PM +0300, Martin Vermeer wrote:
> > BTW I find isActive() not very clear. isHighlyEditable() would be clearer.
> > Is there the equivalent of IS_EDITABLE in math?
>
> None that I am aware of.
>
> One
On Mon, Jun 11, 2007 at 09:46:27PM +0300, Martin Vermeer wrote:
> BTW I find isActive() not very clear. isHighlyEditable() would be clearer.
> Is there the equivalent of IS_EDITABLE in math?
None that I am aware of.
One of the problems I have with {IS,HIGHLY}_EDITABLE is that it is
a single flag
> "Martin" == Martin Vermeer <[EMAIL PROTECTED]> writes:
Martin> BTW I find isActive() not very clear. isHighlyEditable() would
Martin> be clearer. Is there the equivalent of IS_EDITABLE in math?
A ref inset?
JMarc
On Mon, Jun 11, 2007 at 08:06:31PM +0200, Andre Poenitz wrote:
> On Mon, Jun 11, 2007 at 09:47:13AM +0200, Jean-Marc Lasgouttes wrote:
> > > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
> >
> > >> Do I understand correctly that this presupposes that 1) every
> > >> mathinset must have
On Mon, Jun 11, 2007 at 09:47:13AM +0200, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> Do I understand correctly that this presupposes that 1) every
> >> mathinset must have an isActive method and 2) it should return true
> >> only if the inset ha
On Mon, Jun 11, 2007 at 08:56:45AM +0200, Stefan Schimanski wrote:
> >I can't tell you. It is conceptionally sound, however, so close to
> >1.5.0
> >it might be more prudent to use something like
>
> The old behavior is simpler than I thought. A search for isActive
> basically shows that there
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>> Do I understand correctly that this presupposes that 1) every
>> mathinset must have an isActive method and 2) it should return true
>> only if the inset has really accessible cells?
Andre> It's even in InsetBase, and something like th
I can't tell you. It is conceptionally sound, however, so close to
1.5.0
it might be more prudent to use something like
The old behavior is simpler than I thought. A search for isActive
basically shows that there is no math inset (other than the
InsetMathMBox, which just return true, and I
On Sat, Jun 09, 2007 at 09:37:31AM +0300, Martin Vermeer wrote:
> On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
> > > "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
> >
> > Stefan> Critical bugs don't get less critical by ignorance. If anybody
> > Stefan> wan
On Fri, Jun 08, 2007 at 05:03:55PM +0200, Stefan Schimanski wrote:
> Critical bugs don't get less critical by ignorance.
>
> If anybody wants to know more:
>
> 1) CommandInset (used e.g. for references in mathed) has two cells to
> hold information about where it points to. But it only draws a
Am 09.06.2007 um 08:37 schrieb Martin Vermeer:
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Critical bugs don't get less critical by ignorance. If
anybody
Stefan> wants to know more:
[snip]
Great
Martin Vermeer wrote:
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Critical bugs don't get less critical by ignorance. If anybody
Stefan> wants to know more:
[snip]
Great analysis!
I
On Fri, Jun 08, 2007 at 08:22:42PM +0200, Jean-Marc Lasgouttes wrote:
> > "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
>
> Stefan> Critical bugs don't get less critical by ignorance. If anybody
> Stefan> wants to know more:
>
> [snip]
>
> Great analysis!
>
> I would say that th
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Critical bugs don't get less critical by ignorance. If anybody
Stefan> wants to know more:
[snip]
Great analysis!
I would say that the fix is correct, but I'd wait for Andre's input.
JMarc
Critical bugs don't get less critical by ignorance.
If anybody wants to know more:
1) CommandInset (used e.g. for references in mathed) has two cells to
hold information about where it points to. But it only draws a
button, not the cells themselves. So accessing the cells' coordinates
in t
Am 04.06.2007 um 23:35 schrieb Jean-Marc Lasgouttes:
"Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Hmm, it's a not very complex patch for a critical bug about a
Stefan> segfault and nobody has a comment?
Actually I am wondering why suddenly we have these crashes in very
s
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Hmm, it's a not very complex patch for a critical bug about a
Stefan> segfault and nobody has a comment?
Actually I am wondering why suddenly we have these crashes in very
simple operations (like breakParagraph this one). Isn
Hmm, it's a not very complex patch for a critical bug about a
segfault and nobody has a comment?
Stefan
Any consensus about this one? It still crashes in RC1.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Any consensus about this one? It still crashes in RC1.
Stefan
PGP.sig
Description: Signierter Teil der Nachricht
Am 30.05.2007 um 20:32 schrieb Andre Poenitz:
On Wed, May 30, 2007 at 05:56:35PM +0200, Abdelrazak Younes wrote:
Stefan Schimanski wrote:
Hi!
Here is a patch for a crash that happens due to a cell not in the
coord
cache during the drawing of the selection. It could be that this is
On Wed, May 30, 2007 at 05:56:35PM +0200, Abdelrazak Younes wrote:
> Stefan Schimanski wrote:
> >Hi!
> >
> >Here is a patch for a crash that happens due to a cell not in the coord
> >cache during the drawing of the selection. It could be that this is
>
Stefan Schimanski wrote:
Hi!
Here is a patch for a crash that happens due to a cell not in the coord
cache during the drawing of the selection. It could be that this is
related (and also fixes) http://bugzilla.lyx.org/show_bug.cgi?id=3715 .
I believe the problem is when an inset derived
Hi!
Here is a patch for a crash that happens due to a cell not in the
coord cache during the drawing of the selection. It could be that
this is related (and also fixes) http://bugzilla.lyx.org/show_bug.cgi?
id=3715 .
I believe the problem is when an inset derived from InsetMathNest
does
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> #ifdef Q_WS_WIN
Abdelrazak> +int const CursorWidth = 2;
About this cursor with width 2: what is the width of cursor in a
qtextedit? From reading the sources, I'd say 1.
JMarc
Martin Vermeer wrote:
On Thu, Nov 02, 2006 at 04:57:09PM +0100, Abdelrazak Younes wrote:
Martin Vermeer wrote:
On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote:
Martin Vermeer wrote:
Note that the job will be easier if stale caches are not covered up by
the current overzealous full-
On Thu, Nov 02, 2006 at 04:57:09PM +0100, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> >On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote:
> >>Martin Vermeer wrote:
> >>>Note that the job will be easier if stale caches are not covered up by
> >>>the current overzealous full-screen re
Martin Vermeer wrote:
On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote:
Martin Vermeer wrote:
Note that the job will be easier if stale caches are not covered up by
the current overzealous full-screen refresh behaviour. I suggest getting
rid of that first.
The full refresh thing is d
On Thu, 2006-11-02 at 10:45 +0100, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
> >
> > Note that the job will be easier if stale caches are not covered up by
> > the current overzealous full-screen refresh behaviour. I suggest getting
> > rid of that first.
>
> The full refresh thing is due
On Thu, 2006-11-02 at 10:40 +0100, Abdelrazak Younes wrote:
> Martin Vermeer wrote:
>
> > Hmmm, I don't think this is done in 1.4, and still single par update
> > works just fine there... in 1.5 the infrastructure is there but it isn't
> > working properly, as whole-screen updates have been layere
Martin Vermeer wrote:
Note that the job will be easier if stale caches are not covered up by
the current overzealous full-screen refresh behaviour. I suggest getting
rid of that first.
The full refresh thing is due to the cursor bug. I will work on it as
soon as I find some free time.
Abde
Martin Vermeer wrote:
Hmmm, I don't think this is done in 1.4, and still single par update
works just fine there... in 1.5 the infrastructure is there but it isn't
working properly, as whole-screen updates have been layered on top of it
with reckless disregard for what was already there, which t
On Thu, 2006-11-02 at 07:59 +0100, Asger Ottar Alstrup wrote:
> Martin Vermeer wrote:
> > On Wed, Nov 01, 2006 at 11:36:08PM +0100, Asger Ottar Alstrup wrote:
> >> [Partial refresh requires partial coord cache refresh]
>
> > Hmmm, I don't think this is done in
Martin Vermeer wrote:
On Wed, Nov 01, 2006 at 11:36:08PM +0100, Asger Ottar Alstrup wrote:
[Partial refresh requires partial coord cache refresh]
Hmmm, I don't think this is done in 1.4, and still single par update
works just fine there...
I guess that in the common case, things wor
On Wed, Nov 01, 2006 at 11:36:08PM +0100, Asger Ottar Alstrup wrote:
> Hi,
>
> To implement partial update (single paragraph update), it is not enough
> just to redraw only those parts of the screen.
>
> You also have to implement partial update of the coord cache. Righ
Hi,
To implement partial update (single paragraph update), it is not enough
just to redraw only those parts of the screen.
You also have to implement partial update of the coord cache. Right now,
the only possible operation for the coord cache is to clear all of it.
To implement partial
On Thu, Nov 04, 2004 at 12:33:47AM +0100, Alfredo Braunstein wrote:
> Am I right in that every view-related data should go to the coord cache?
That's the idea for the long run anyway. The external cache is about the
only way to allow multiple views and code is more modular after such
a
On Thu, Nov 04, 2004 at 09:23:08AM +0100, Jean-Marc Lasgouttes wrote:
> Concerning my lack of answers to your hints in my direction concerning
> this patch, this is because I do not really understand what it does. I
> just discussed with Andre about the code that got written in Chemnitz,
> and I ha
Jean-Marc Lasgouttes wrote:
> Alfredo> Not in main trunk ;-)
>
> Isee.
>
> Alfredo> In CoordBranch paragraphs have a cached dim_. It replaces
> Alfredo> what it is height+width+... in main trunk.
>
> So it should go in a second coord cache, I guess (one
>>>>> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Not in main trunk ;-)
Isee.
Alfredo> In CoordBranch paragraphs have a cached dim_. It replaces
Alfredo> what it is height+width+... in main trunk.
So it should go in a second c
Jean-Marc Lasgouttes wrote:
> Alfredo> Am I right in that every view-related data should go to the
> Alfredo> coord cache? for instance, par.ascent(), par.descent() etc.
>
> What methods are you talking about? I cannot find a
> Paragraph::ascent().
Not in main trun
>>>>> "Alfredo" == Alfredo Braunstein <[EMAIL PROTECTED]> writes:
Alfredo> Am I right in that every view-related data should go to the
Alfredo> coord cache? for instance, par.ascent(), par.descent() etc.
What methods are you talking about? I cannot find a
Paragraph::ascent().
JMarc
Am I right in that every view-related data should go to the coord cache?
for instance, par.ascent(), par.descent() etc.
Alfredo
48 matches
Mail list logo
