Here is the existing code in LyXFunc:dispatch:
case LFUN_CITATION_INSERT: {
BOOST_ASSERT(lyx_view_);
if (!argument.empty()) {
// we can have one optional argument, delimited by '|'
// citation-insert |
// this should b
Edwin Leuven <[EMAIL PROTECTED]> writes:
| > You didn't read my message regarding this?
|
| I read your message...
|
| > I really thing that we should avoid inheritance here.
| > (one thing is that we can store the spellchecker as a real object and
| > not as a pointer)
|
| You wrote:
|
| > _
> You didn't read my message regarding this?
I read your message...
> I really thing that we should avoid inheritance here.
> (one thing is that we can store the spellchecker as a real object and
> not as a pointer)
You wrote:
> _OR_ perhaps more in the iostream fassion:
> (I think I like this
Edwin Leuven <[EMAIL PROTECTED]> writes:
| Hi guys,
|
| I cleaned up the spellcheck code a bit; I took spellchecker.C and did the
| following:
|
| 1. put the ispell and pspell code in their own classes that inherit from a
| common spellbase class
You didn't read my message regarding this?
I
Haven't read this closely yet but class SpellBase is meant to be an abstract
base class isn't it. Ie, you can't create an instance of SpellBase, just of
it's derived classes?
If so, then it's member functions should be declared pure virtual.
ie, not
virtual void initialize(BufferParams cons
Hi guys,
I cleaned up the spellcheck code a bit; I took spellchecker.C and did the
following:
1. put the ispell and pspell code in their own classes that inherit from a
common spellbase class
2. have these changes reflected in RunSpellChecker
3. deleted the spelloptions (for the moment support
On 11 Sep 2000, Jean-Marc Lasgouttes wrote:
> > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> You could start by grouping checks -- various menu entries
> Allan> aren't available for readonly docs, different menu entries are
> Allan> available when no buffers exist. That sort o
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
Marko> You are right, LyXFunc::getStatus() is not expencive. I've
Marko> tried to move cursor through the document and took almost the
Marko> same amount of time to reach the end of the document regardless
Marko> to whether I updated the
On 11 Sep 2000, Jean-Marc Lasgouttes wrote:
> > "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
>
> Marko> The problem is whether menus and toolbars should have their own
> Marko> means to track the state of LyX actions or there should be some
> Marko> general way to inform about the
> "Marko" == Marko Vendelin <[EMAIL PROTECTED]> writes:
Marko> The problem is whether menus and toolbars should have their own
Marko> means to track the state of LyX actions or there should be some
Marko> general way to inform about the change of the status to all
Marko> interested parties. A
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> You could start by grouping checks -- various menu entries
Allan> aren't available for readonly docs, different menu entries are
Allan> available when no buffers exist. That sort of thing. Then you
Allan> can deactivate a bunch of stuf
On Fri, 8 Sep 2000, Marko Vendelin wrote:
>
>
> On 8 Sep 2000, Jean-Marc Lasgouttes wrote:
>
> > Let's face it: if you want to a tearable menu to change when the
> > cursor moves you will have to do _something_. What I would try to do
> > if I were to write the gnome frontend is first to build
On 8 Sep 2000, Jean-Marc Lasgouttes wrote:
> Let's face it: if you want to a tearable menu to change when the
> cursor moves you will have to do _something_. What I would try to do
> if I were to write the gnome frontend is first to build the menus at
> update() time and see whether it causes p
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes:
>> I agree that this may have drawbacks, but I have not found them
>> yet. Could you be a bit more constructive?
Juergen> Did you see the messages about the problems with the new menu
Juergen> code and other implementations (GNOME)? Whi
On 08-Sep-2000 Jean-Marc Lasgouttes wrote:
>> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
>
> Lars> You are not calling this a _nice_ way to do context sensitive
> Lars> menus are you?
>
> Could you discuss this a bit more? What I find ``nice'' here is that,
> with the already
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
Lars> You are not calling this a _nice_ way to do context sensitive
Lars> menus are you?
Could you discuss this a bit more? What I find ``nice'' here is that,
with the already existing menu scheme, we would be able to define in
one
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
|
| Allan> Lars you were saying something last week about c-s menu
| Allan> support. Any ideas for handling this in a simple manner? JMarc
| Allan> any suggestions for how we map c-s menus i
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
Allan> Lars you were saying something last week about c-s menu
Allan> support. Any ideas for handling this in a simple manner? JMarc
Allan> any suggestions for how we map c-s menus in the UI menu stuff?
Provided you know how to trigger the m
Allan> Angus, from what I'm reading you seem to want to have two dialogs with
Allan> almost identical capabilities. Just make one. Maybe this is what you are
Allan> working towards with the addition of the browser?
One dialog only. When called with an inset (as in showRef( this );), the browser
On Mon, 7 Aug 2000, Angus Leeming wrote:
> Well, I'm in the process of modifying my dialog so that it has the big insert
> ref's browser.
> If the dialog is called from "insert cross reference", then we have exactly
> the same functionality as now. Ie, browser enabled, can change reference name
On 7 Aug 2000, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
>
>
> | Lars> And we don't want the dialog to popup on on RMB, we want a small pup
> | Lars> menu with just a few items.
> |
> | Well, I'm not worried about how we give the user the ability to do
> | this, bu
Angus Leeming <[EMAIL PROTECTED]> writes:
| Lars> And we don't want the dialog to popup on on RMB, we want a small pup
| Lars> menu with just a few items.
|
| Well, I'm not worried about how we give the user the ability to do
| this, but I
| do think that a pup won't be sufficient in this case
Lars> | > Lars> I'd like to have a RMB context menu popup. Wherever I click RMB the
Lars> | > Lars> context-sensitive-menu is called and the appropriate popup is shown.
Lars> | > Lars> F.ex if I RMB on the small red margin on a marginal note I get a small
Lars> | > Lars> popup where I can choose l
Allan Rae <[EMAIL PROTECTED]> writes:
| > Lars> I'd like to have a RMB context menu popup. Wherever I click RMB the
| > Lars> context-sensitive-menu is called and the appropriate popup is shown.
| > Lars> F.ex if I RMB on the small red margin on a marginal note I get a small
| > Lars> popup wher
Allan> The four things you listed (IIRC) don't need a dialog to be useful. None
Allan> of the four required input. One was "goto ref" and three were effectively
Allan> a set of radio buttons. You can only select one of the three entries in
Allan> a menu at a time. Ergo, we have the radio butto
On Mon, 7 Aug 2000, Angus Leeming wrote:
> Allan> This is why we need context sensitive menu support. Another dialog is
> Allan> pointless for what is really a trivial action. Why click three times
> Allan> (open, select, close) when a single held click on a c-s menu will do.
>
> Because the
Allan> This is why we need context sensitive menu support. Another dialog is
Allan> pointless for what is really a trivial action. Why click three times
Allan> (open, select, close) when a single held click on a c-s menu will do.
Because the dialog will do more than just "go to the ref"
Allan
Allan Rae <[EMAIL PROTECTED]> writes:
| This is why we need context sensitive menu support. Another dialog is
| pointless for what is really a trivial action. Why click three times
| (open, select, close) when a single held click on a c-s menu will do.
|
| Lars you were saying something last we
On Fri, 4 Aug 2000, Angus Leeming wrote:
[...]
> I'd like to change this behaviour so that clicking on the inset
> launches a new reference dialog.
>
> (This dialog will not allow the user to change the thing to which it refers.
> For that, the reference must be deleted and a new one inserted, as
Angus> I'd like to change this behaviour so that clicking on the inset
Angus> launches a new reference dialog.
JMarc> Then maybe the goto feature shold assigned to another event, like
JMarc> Shift-Click1.
Good. I'll have a go.
A.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> I'd like to change this behaviour so that clicking on the inset
Angus> launches a new reference dialog.
Then maybe the goto feature shold assigned to another event, like
Shift-Click1.
JMarc
Afternoon, all
I have got as far as InsertRef in my game of "let's play with the insets".
Once the inset is created, (somewhere else. Doesn't matter), and we have an
inset sitting in the text, we can do two things with it:
1. Clicking on it takes us to the label to which it refers.
2. Typing "M
32 matches
Mail list logo
