>It is an LFUN that I introduced I think (don't have the sources to
>hand). It is invoked indirectly.
>
>The frontend passes
>LFUN_INSET_MODIFY "citation" "leeming03"
>to the core.
>
>If we are modifying an existing inset then we grab it. Something like
>(don't have the sources to hand)
>
On Tue, 11 Nov 2003, Lars Gullik Bjønnes wrote:
> Alfredo Braunstein <[EMAIL PROTECTED]> writes:
>
> | Christian Ridderström wrote:
> >
> >> Wow... I think I could follow that (sort of :-). Anyway, in case anyone
> >> gets an urge to add more info, I put it here:
> >> http://wiki.lyx.org/pmwiki.
Alfredo Braunstein <[EMAIL PROTECTED]> writes:
| Christian Ridderström wrote:
>
>> Wow... I think I could follow that (sort of :-). Anyway, in case anyone
>> gets an urge to add more info, I put it here:
>> http://wiki.lyx.org/pmwiki.php/ExampleProsper/ExampleProsper
>
| I don't know why, but it
Alfredo Braunstein wrote:
> ;-) Cut & paste from the function below. Should I add the
> description or it's not needed for virtuals? The base one in
> updatableinset.h *does* have the comment.
Leave the 'virtual' and scrap the comment. (Personal preference ;-)
--
Angus
Christian RidderstrÃm wrote:
> Wow... I think I could follow that (sort of :-). Anyway, in case anyone
> gets an urge to add more info, I put it here:
> http://wiki.lyx.org/pmwiki.php/ExampleProsper/ExampleProsper
I don't know why, but it doesn't seem the right url to me ;-)
Alfredo
On Mon, 10 Nov 2003, Andre Poenitz wrote:
Wow... I think I could follow that (sort of :-). Anyway, in case anyone
gets an urge to add more info, I put it here:
http://wiki.lyx.org/pmwiki.php/ExampleProsper/ExampleProsper
/Christian
--
Christian Ridderström htt
Angus Leeming wrote:
> Alfredo Braunstein wrote:
>
>> I've removed all inset-dependent fitCursor functions,
>> and put toghether all fitcursor-related functions in screen.C in
>> only one, putting the smart tall row handling there (with some code
>> simplification and nice variable names).
>>
>>
Alfredo Braunstein wrote:
> I've removed all inset-dependent fitCursor functions,
> and put toghether all fitcursor-related functions in screen.C in
> only one, putting the smart tall row handling there (with some code
> simplification and nice variable names).
>
> Now the same routine is used fo
I've removed all inset-dependent fitCursor functions,
and put toghether all fitcursor-related functions in screen.C in only one,
putting the smart tall row handling there (with some code simplification
and nice variable names).
Now the same routine is used for mathed and normal cursors, and this i
Martin Vermeer wrote:
> On Tue, Nov 11, 2003 at 01:55:45PM +0100, Andre Poenitz spake
> thusly:
>
> ...
>
>> > Action 236 is LFUN_INSET_APPLY, which appears neither in text3.C
>> > nor in factory.C.
>>
>> Is the LFUN_INSET_APPLY handler in BufferView_pimpl::dispatch
>> handling it?
>
> No, I c
On Tue, Nov 11, 2003 at 02:09:43PM +0100, Andre Poenitz spake thusly:
> On Tue, Nov 11, 2003 at 03:19:02PM +0200, Martin Vermeer wrote:
> >
> > Patch.
>
> Ok.
>
> I'd say you could commit that as it is a step forward. Having the
> same for the other 'unhandled' LFUNs would be niche, though.
>
On Tue, Nov 11, 2003 at 01:55:45PM +0100, Andre Poenitz spake thusly:
...
> > Action 236 is LFUN_INSET_APPLY, which appears neither in text3.C nor
> > in factory.C.
>
> Is the LFUN_INSET_APPLY handler in BufferView_pimpl::dispatch handling it?
No, I checked and it isn't even getting there.
-
On Tue, Nov 11, 2003 at 12:40:45AM -0800, Ling Li wrote:
> I am confused with the --with-pspell option in LyX configure. Without
> --with-pspell, LyX 1.3.3 can still check spelling; With --with-pspell,
> the Edit->Preferences->Lang Opts->Spell command still contains only
> ispell and aspell. Wha
Andre Poenitz wrote:
>> For doing this, I've added an LCursor::updatePos to update the cached y
>> position of the inset. Both the cached y position and this updatePos can
>> be removed if we switch to absolute document coords.
>
> Because we'd call innerInset()->y() instead?
exactly. And that
On Tue, Nov 11, 2003 at 03:19:02PM +0200, Martin Vermeer wrote:
>
> Patch.
Ok.
I'd say you could commit that as it is a step forward. Having the
same for the other 'unhandled' LFUNs would be niche, though.
If you could do the same for the other
Andre'
Patch. No Changelog...
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Dept. of Surveying, Inst. of Geodesy
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
Index: text3.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-d
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Nov 11, 2003 at 01:38:52PM +0100, Lars Gullik Bjønnes wrote:
>> Andre Poenitz <[EMAIL PROTECTED]> writes:
>>
>> >> | Mainly because this levels the ground for 'dynamic insets' with
>> >> | auto-registration on startup and all these fancy things.
On Tue, Nov 11, 2003 at 12:58:40PM +, Angus Leeming wrote:
> Guys, all this is very well and, indeed, it's nice to have a vision
> of the future. However, at the moment it is just a distraction.
Sure. But it was so quiet during the last few days...
Andre'
Andre Poenitz wrote:
>> | Think plugin.
>>
>> inset-insert-pluginfoo still works...
>
> but LFUN_INSERT_PLUGIN_FOO will not as this is set at compile time.
>
>> | duplicate the code'. The code that's already there seems to
>> | support the 'single lfun' approach, so this recommendation is
>> | a
On Tue, Nov 11, 2003 at 02:55:00PM +0200, Martin Vermeer wrote:
> On Tue, Nov 11, 2003 at 11:17:39AM +0100, Andre Poenitz spake thusly:
>
> ...
>
> > > Where should the conversion LFUN_INSERT_LABEL -> LFUN_INSET_INSERT
> > > take place?
> >
> > I'd just duplicate the code in factory.C. I.e:
>
On Tue, Nov 11, 2003 at 01:38:52PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> >> | Mainly because this levels the ground for 'dynamic insets' with
> >> | auto-registration on startup and all these fancy things.
> >>
> >> I have no idea what a "dynamic inset"
On Tue, Nov 11, 2003 at 11:17:39AM +0100, Andre Poenitz spake thusly:
...
> > Where should the conversion LFUN_INSERT_LABEL -> LFUN_INSET_INSERT
> > take place?
>
> I'd just duplicate the code in factory.C. I.e:
Yes, did that. Next problem:
1) The label appears, but without label text.
2) Cl
Andre Poenitz <[EMAIL PROTECTED]> writes:
>> | Mainly because this levels the ground for 'dynamic insets' with
>> | auto-registration on startup and all these fancy things.
>>
>> I have no idea what a "dynamic inset" is.
>
| Think plugin.
inset-insert-pluginfoo still works...
>> | I think it sh
-BEGIN PGP SIGNED MESSAGE-
On Dienstag, 11. November 2003 11:03, Jose' Matos wrote:
> Do you have that file handy?
> Could you send it to me?
Yes, in a private mail.
Kornel
- --
Kornel Benko
[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.1 (GNU/Linux)
i
On Tue, Nov 11, 2003 at 12:32:34PM +0100, Alfredo Braunstein wrote:
> This an update rationalization: do not call update on the insets, but return
> the update flag in the dispatch result (I've had to put some default update
> value to true in dispatchresult.h,
> Lars please have a look. If that is
This an update rationalization: do not call update on the insets, but return
the update flag in the dispatch result (I've had to put some default update
value to true in dispatchresult.h, Lars please have a look. If that is no
good, then I'll need a DispatchResult(false, FINISHED_RIGHT, update) for
On Tue, Nov 11, 2003 at 12:11:51PM +0100, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Tue, Nov 11, 2003 at 11:42:23AM +0100, Lars Gullik Bjønnes wrote:
> >> | At some point of time we could make our minds up whether we want a
> >> | general LFUN_INSET_INSERT +
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Nov 11, 2003 at 11:42:23AM +0100, Lars Gullik Bjønnes wrote:
>> | At some point of time we could make our minds up whether we want a
>> | general LFUN_INSET_INSERT + name or special LFUN_INSET_FOO lfuns.
>>
>> I think there should be special
On Tue, Nov 11, 2003 at 11:42:23AM +0100, Lars Gullik Bjønnes wrote:
> | At some point of time we could make our minds up whether we want a
> | general LFUN_INSET_INSERT + name or special LFUN_INSET_FOO lfuns.
>
> I think there should be special LFUN_INSET_FOO lfuns.
>
> mostly because if fits
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Nov 11, 2003 at 12:24:56PM +0200, Martin Vermeer wrote:
>> I think I got a little closer the root of the problem.
>>
>> In text3.C, the case LFUN_INSERT_LABEL is not handled. So I added it:
>>
>>1542 case LFUN_INDEX_PRINT:
>>1543
On Tue, Nov 11, 2003 at 12:24:56PM +0200, Martin Vermeer wrote:
> I think I got a little closer the root of the problem.
>
> In text3.C, the case LFUN_INSERT_LABEL is not handled. So I added it:
>
>1542 case LFUN_INDEX_PRINT:
>1543 case LFUN_TOC_INSERT:
>1544 case LFUN_HF
I think I got a little closer the root of the problem.
In text3.C, the case LFUN_INSERT_LABEL is not handled. So I added it:
1542 case LFUN_INDEX_PRINT:
1543 case LFUN_TOC_INSERT:
1544 case LFUN_HFILL:
1545 case LFUN_INSERT_LINE:
1546 case LFUN_INSERT_PAGEBREAK
On Tue, Nov 11, 2003 at 09:59:20AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > A short overview.
>
> Thank you.
>
> Angus
Ah... Angus is back from the Orks...
Andre'
On Sunday 09 November 2003 14:27, Martin Vermeer wrote:
> José,
>
> what would you say if we got rid of the old clever trickery:
>
> LatexParam"4|revnumber"
>
> ?
At that time seemed the only easy option.
> What about putting the number in a separate variable "CommandLevel"?
On Friday 07 November 2003 21:08, Kornel Benko wrote:
> >
> > I have "Unknown token" now.
> >
> > Let me prepare a testfile, it will take some time to hunt it down.
> > It is a big multifile document.
>
> This one was easy.
Do you have that file handy?
Could you send it to me?
> Input is lyxf
Andre Poenitz wrote:
> A short overview.
Thank you.
Angus
Andre Poenitz <[EMAIL PROTECTED]> writes:
| I don't think much of this comment is valid anymore. We don't have much
| PragraphList::iterators anymore, most notably, there is none stored in
| the cursor. The paragraph->id solution seems to be gone as well.
>
| What should we do? Adjust the note or
Lars, please have a look.
// This is the comments that some of the warnings below refers to.
// There are some issues in this file and I don't think they are
// really related to the FIX_DOUBLE_SPACE patch. I'd rather think that
// this is a problem that has been here almost from day one and that
The original intention was (a) to separate non-LyXText users from
lyxtext.h/text.C and (b) to make text*.C smaller.
With the paroffset changes we need access to the tet for cursorPar() so
(a) is not achievable anymore. (b) was not too succesful (180 lines) but
text*.C is much slimmer now for othe
On Tue, Nov 11, 2003 at 09:40:11AM +0100, Alfredo Braunstein wrote:
> But they *are* decoupled. The cursor is needed only on fitCUrsor (and we
> need it there). When you scroll with the scrollbar, there is no fitCursor
> involved (except from cursor_follows_crollbar, that is)
That's what I was ref
Andre Poenitz wrote:
> On Tue, Nov 11, 2003 at 08:52:59AM +0100, Alfredo Braunstein wrote:
>> Andre Poenitz wrote:
>>
>> > On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
>> >> One of the problems I see is that the insets lose track of their
>> >> position if we scroll away.
>
Hi John,
I am confused with the --with-pspell option in LyX configure. Without
--with-pspell, LyX 1.3.3 can still check spelling; With --with-pspell,
the Edit->Preferences->Lang Opts->Spell command still contains only
ispell and aspell. What does --with-pspell bring to us?
In Fedora Core releas
On Tue, Nov 11, 2003 at 09:35:53AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> >> What about absolute *document* coordinates everywhere? What are the
> >> drawbacks?
> >
> > Probably none as they are equivalent to screen coordinates + y_top.
> >
> > Or, more precisely: If there a
Andre Poenitz wrote:
>> What about absolute *document* coordinates everywhere? What are the
>> drawbacks?
>
> Probably none as they are equivalent to screen coordinates + y_top.
>
> Or, more precisely: If there are drawbacks we'd see them with screen
> coordinates as well.
Should we do just tha
On Tue, Nov 11, 2003 at 09:15:12AM +0100, Alfredo Braunstein wrote:
> Alfredo Braunstein wrote:
>
> >> Don't you think we should just move to absolute screen coordinates
> >> everywhere? This scheme looks robust and simple...
> >
> > But this is exactly the problem right now: if you scroll with
Alfredo Braunstein wrote:
>> Don't you think we should just move to absolute screen coordinates
>> everywhere? This scheme looks robust and simple...
>
> But this is exactly the problem right now: if you scroll with the
> scrollbar, the coordinates where the cursor is remain invalid, and so a
>
On Tue, Nov 11, 2003 at 08:52:59AM +0100, Alfredo Braunstein wrote:
> Andre Poenitz wrote:
>
> > On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
> >> One of the problems I see is that the insets lose track of their position
> >> if we scroll away.
> >>
> >> Maybe a solution wo
On Tue, Nov 11, 2003 at 08:55:28AM +0100, Alfredo Braunstein wrote:
> THere is a lot of other not removed dead code (all fuctions called
> fit.*ursor for instance, there are like 10 of them scattered around, in
> src/ src/insets/, src/frontends/), but there is some that seems to serve to
> some par
Andre Poenitz wrote:
> On Tue, Nov 11, 2003 at 12:24:37AM +0100, Alfredo Braunstein wrote:
>> But we need to rationalize the update calls anyway, and when we do that,
>> we can add an LCursor::update_cache method or something to update the
>> cache at the exact moment we want (I think after an upd
Andre Poenitz wrote:
> On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
>> One of the problems I see is that the insets lose track of their position
>> if we scroll away.
>>
>> Maybe a solution would be to cache the absolute y position of the tip
>> inset in LCursor as soon as
On Tue, Nov 11, 2003 at 12:24:37AM +0100, Alfredo Braunstein wrote:
> But we need to rationalize the update calls anyway, and when we do that, we
> can add an LCursor::update_cache method or something to update the cache at
> the exact moment we want (I think after an update, in workAreadispatch).
On Mon, Nov 10, 2003 at 11:51:31PM +0100, Alfredo Braunstein wrote:
> One of the problems I see is that the insets lose track of their position if
> we scroll away.
>
> Maybe a solution would be to cache the absolute y position of the tip inset
> in LCursor as soon as it is push()ed.
>
> If this
52 matches
Mail list logo
