On 04-Jul-2000 Angus Leeming wrote:
> My head is spinning a little from all these answers, but I'd like to thank all
> of you for the ideas.
>
#:O)
[snip it as all have already read it]
>
> This way, the functionality is kept in the kernel. No new variables need to be
> stored in the inset.
My head is spinning a little from all these answers, but I'd like to thank all
of you for the ideas.
I think I'll summarise what I'm going to try and implement:
The signal in BufferView::Pimpl::workAreaButtonRelease() remains unchanged:
switch( inset_hit->LyxCode() ) {
case Inse
On 04-Jul-2000 Lars Gullik Bjønnes wrote:
> Juergen Vigna <[EMAIL PROTECTED]> writes:
>
>| Well what about:
>|
>| owner->GetDialogs()->showCitation(argument)
>|
>| but IMO this should be:
>|
>| owner->GetDialogs()->createCitation(argument)
>
> But still the dialog code should not b
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> Insert Url -> press cancel should not insert anything into doc.
Lars> Insert Url -> press ok, without any more info should imho be
Lars> inserted into doc
Except that Insert URL only has a close button (that's a bug, of course
Juergen Vigna <[EMAIL PROTECTED]> writes:
| Well what about:
|
| owner->GetDialogs()->showCitation(argument)
|
| but IMO this should be:
|
| owner->GetDialogs()->createCitation(argument)
But still the dialog code should not be allowed to insert anything
into the docment. this is the
Angus Leeming <[EMAIL PROTECTED]> writes:
| But in LyXFunc I've just allocated some new memory:
| case LFUN_INSERT_CITATION:
| owner->getDialogs()->showCitation( new
| InsetCitation(argument) );
yes _are_ allowed to rewrite...
case LFUN_INSERT_CITATION: {
On 04-Jul-2000 Lars Gullik Bjønnes wrote:
> Juergen Vigna <[EMAIL PROTECTED]> writes:
>
>| On 04-Jul-2000 Lars Gullik Bjønnes wrote:
>| >
>| > We don't want owner or owner_par in LyXInsets.
>| >
>|
>| Well we already have an owner() :) and that is if the owner is another
>| inset!
>
> yes, i
On 04-Jul-2000 Angus Leeming wrote:
>
> The alternative I thought of would be:
> case LFUN_INSERT_CITATION:
> owner->getDialogs()->showCitation(0);
>
> and to control the creation of a new InsetCitation from the FormCitation class.
> This would removed the need for the Inset
Juergen Vigna <[EMAIL PROTECTED]> writes:
| On 04-Jul-2000 Lars Gullik Bjønnes wrote:
| >
| > We don't want owner or owner_par in LyXInsets.
| >
|
| Well we already have an owner() :) and that is if the owner is another
| inset!
yes, i know, but i am not sure if we really need it.
Lg
On 04-Jul-2000 Lars Gullik Bjønnes wrote:
>
> We don't want owner or owner_par in LyXInsets.
>
Well we already have an owner() :) and that is if the owner is another
inset!
I also agree that we don't need the paragraph_owner.
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-.
On 04-Jul-2000 Lars Gullik Bjønnes wrote:
>| I'm thinking of adding a new variable to class Inset:
>|
>| class Inset {
>| bool isInserted() const { return inserted_; }
>| bool inserted_;
>| }
>
> I don't like it, and do not see why this is needed.
>
I agree you should do as I do wit
Lars> | interrogation of inset->isInserted() will allow the dialog to decide what to do
Lars> | with the inset in the callback functions called when the Ok or Cancel buttons
Lars> | are pressed.
Lars> Should be possible to decide even without that flag.
Lars> - on cancel just do nothing
Lars> -
Lior Silberman <[EMAIL PROTECTED]> writes:
| Perhaps holding a pointer to the owning paragraph whould server us
| better?
No, I don't think so...
| Insets can be either in the top-level document (owned by a paragraph) or
| inside other insets. Thus insets have an Inset* 'owner' member, but no
On Tue, 4 Jul 2000, Angus Leeming wrote:
> I'm thinking of adding a new variable to class Inset:
>
> class Inset {
> bool isInserted() const { return inserted_; }
> bool inserted_;
> }
>
> The strategy I outline below is for an InsetCitation, but I think that it also
> holds true fo
Angus Leeming <[EMAIL PROTECTED]> writes:
| I'm thinking of adding a new variable to class Inset:
|
| class Inset {
| bool isInserted() const { return inserted_; }
| bool inserted_;
| }
I don't like it, and do not see why this is needed.
| The strategy I outline below is for an I
I'm thinking of adding a new variable to class Inset:
class Inset {
bool isInserted() const { return inserted_; }
bool inserted_;
}
The strategy I outline below is for an InsetCitation, but I think that it also
holds true for other insets and so the variable should go in the top
Angus> My question is simple: is the use of argument relevant here, or
Angus> has this piece of code been superceeded by the new insets? If
Angus> it is relevant, can someone please explain where and when it
Angus> would be used? I've removed it to see if I can find any effect:
Angus> NONE! Of cou
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> My question is simple: is the use of argument relevant here, or
Angus> has this piece of code been superceeded by the new insets? If
Angus> it is relevant, can someone please explain where and when it
Angus> would be used? I've rem
18 matches
Mail list logo
