On Thu, Nov 13, 2003 at 03:01:21PM +, Angus Leeming spake thusly:
> > If no shout, I'll commit a bit later.
>
> Please do.
So done.
- Martin
pgp0.pgp
Description: PGP signature
Martin Vermeer wrote:
> OK, here's my latest including a local LFUN_INSET_INSERT.
Thank you.
> If no shout, I'll commit a bit later.
Please do.
--
Angus
On Thu, Nov 13, 2003 at 02:04:06PM +, Angus Leeming spake thusly:
>
> Andre Poenitz wrote:
>
> > On Thu, Nov 13, 2003 at 01:48:37PM +, Angus Leeming wrote:
> >> I am all in favour of the general thrust (to get things working)
> >> but would want LFUN_INSET_INSERT to be moved across too.
>
On Thu, Nov 13, 2003 at 02:04:06PM +, Angus Leeming wrote:
> > Andre', off for a few days now.
> Have a good break.
Conference.
Talk.
*sigh*
Andre'
Andre Poenitz wrote:
> On Thu, Nov 13, 2003 at 01:48:37PM +, Angus Leeming wrote:
>> I am all in favour of the general thrust (to get things working)
>> but would want LFUN_INSET_INSERT to be moved across too.
>> Pleaeee!
>
> So why don't you just do it.
> You are a big boy after
On Thu, Nov 13, 2003 at 01:48:37PM +, Angus Leeming wrote:
> I am all in favour of the general thrust (to get things working) but
> would want LFUN_INSET_INSERT to be moved across too.
> Pleaeee!
So why don't you just do it.
You are a big boy after all.
Andre', off for a few day
Andre Poenitz wrote:
> On Thu, Nov 13, 2003 at 01:26:53PM +, [EMAIL PROTECTED]
> wrote:
>> ..
>>
>> >> Attached a patch instrumented with asserts.
>> >>
>> >> Let's check this in. We'll hear about it soon enough if this
>> >> code is
>> >> in use somewhere... I gave it a quick test, but didn
On Thu, Nov 13, 2003 at 01:26:53PM +, [EMAIL PROTECTED] wrote:
> ..
>
> >> Attached a patch instrumented with asserts.
> >>
> >> Let's check this in. We'll hear about it soon enough if this code is
> >> in use somewhere... I gave it a quick test, but didn't manage to
> >> trigger it.
> >>
> >
...
>> Attached a patch instrumented with asserts.
>>
>> Let's check this in. We'll hear about it soon enough if this code is
>> in use somewhere... I gave it a quick test, but didn't manage to
>> trigger it.
>>
>> (Is there a way to check more systematically whether a piece of code
>> _ever_ get
On Thu, Nov 13, 2003 at 02:58:01PM +0200, Martin Vermeer wrote:
> On Thu, Nov 13, 2003 at 12:13:14PM +, [EMAIL PROTECTED] spake thusly:
>
> > It doesn't get called, that's what's wrong with it.
> >
> > What implications does deleting the above code from
> > BufferView::Pimpl::dispatch have?
On Thu, Nov 13, 2003 at 12:13:14PM +, [EMAIL PROTECTED] spake thusly:
> It doesn't get called, that's what's wrong with it.
>
> What implications does deleting the above code from
> BufferView::Pimpl::dispatch have? I haven't tried it.
Attached a patch instrumented with asserts.
Let's ch
>Hmmm. and where is LFUN_INSET_APPLY currently handled? It certainly
>isn't in LyXText::dispatch and it does exist somewhere...
>
>Ok, got it. It's in BufferView_pimpl.C.
>
>Martin, I note that your patch doesn't delete this copy of the LFUN
>handler. If you're going to add it to LyxText::dispatc
Andre Poenitz wrote:
> On Thu, Nov 13, 2003 at 10:15:03AM +, Angus Leeming wrote:
>> Andre Poenitz wrote:
>> > Is that else-branch equivalent to
>> >
>> > } else {
>> > doInsertInset(this, cmd, true, false);
>> > }
>> > br
On Thu, Nov 13, 2003 at 10:15:03AM +, Angus Leeming wrote:
> Andre Poenitz wrote:
> > Is that else-branch equivalent to
> >
> > } else {
> > doInsertInset(this, cmd, true, false);
> > }
> > break;
>
> Depends what doInsert
On Thu, Nov 13, 2003 at 10:07:46AM +, [EMAIL PROTECTED] wrote:
>
> > } else {
> >> FuncRequest cmd2 = cmd;
> >> cmd2.action = LFUN_INSET_INSERT;
> >> dispatch(cmd2);
> >> }
> >
> >Is that el
Andre Poenitz wrote:
> Is that else-branch equivalent to
>
> } else {
> doInsertInset(this, cmd, true, false);
> }
> break;
Depends what doInsertInset does with cmd doesn't it... Ie, does it
check that it is dealing with LFUN
> } else {
>> FuncRequest cmd2 = cmd;
>> cmd2.action = LFUN_INSET_INSERT;
>> dispatch(cmd2);
>> }
>
>Is that else-branch equivalent to
>
> } else {
>doInsertI
On Thu, Nov 13, 2003 at 09:50:30AM +, Angus Leeming wrote:
> Martin Vermeer wrote:
>
> > On Wed, Nov 12, 2003 at 05:10:41PM +, Angus Leeming spake
> > thusly:
> >
> > ...
> >
> > Progress!
> >
> > Now I have the attached, and the dialog comes up and if you enter a
> > string there, it b
Martin Vermeer wrote:
> On Wed, Nov 12, 2003 at 05:10:41PM +, Angus Leeming spake
> thusly:
>
> ...
>
> Progress!
>
> Now I have the attached, and the dialog comes up and if you enter a
> string there, it becomes the inset name. I.e., the "APPLY: no inset"
> branch now functions. And not on
On Wed, Nov 12, 2003 at 05:10:41PM +, Angus Leeming spake thusly:
...
Progress!
Now I have the attached, and the dialog comes up and if you enter a
string there, it becomes the inset name. I.e., the "APPLY: no inset"
branch now functions. And not only for label, but for URLs as well.
The "
Angus Leeming wrote:
> [EMAIL PROTECTED] wrote:
>> I see. But show is called when inserting the label inset:
>>
>>1523 case LFUN_INSERT_LABEL: {
>>1524 doInsertInset(this, cmd, true, false);
>>1525 InsetCommandParams p("label");
>>1526 string const data
[EMAIL PROTECTED] wrote:
> I see. But show is called when inserting the label inset:
>
>1523 case LFUN_INSERT_LABEL: {
>1524 doInsertInset(this, cmd, true, false);
>1525 InsetCommandParams p("label");
>1526 string const data =
>InsetCommandMailer::pa
>You should be invoking the Dialogs::show member function to
>pop up the dialog. If you press the button to launch the dialog,
>then an InsetLabel pointer is passed to the function. On return
>from the dialog ("Apply") the global dispatch() interrogates the
>Dialogs class: "has any particular ins
Martin Vermeer wrote:
> On Wed, Nov 12, 2003 at 08:29:12AM +, Angus Leeming spake
> thusly:
>>
>> [EMAIL PROTECTED] wrote:
>> > Looks like just the other way around, in fact:
>>
>> Sigh. I need a holiday to recover from the holiday.
>> Ah well,
>> --
>> Angus
>
> Angus,
>
> sorry to distur
On Wed, Nov 12, 2003 at 08:29:12AM +, Angus Leeming spake thusly:
>
> [EMAIL PROTECTED] wrote:
> > Looks like just the other way around, in fact:
>
> Sigh. I need a holiday to recover from the holiday.
> Ah well,
> --
> Angus
Angus,
sorry to disturb your ongoing holiday :-) but what's wron
[EMAIL PROTECTED] wrote:
> Looks like just the other way around, in fact:
Sigh. I need a holiday to recover from the holiday.
Ah well,
--
Angus
>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)
>
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 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
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
44 matches
Mail list logo
