On Wed, Sep 20, 2006 at 10:42:37AM +0200, Abdelrazak Younes wrote:
> >If you're there you can as well call the method a 'slot' and connect it
> >to an, erm, 'signal'.
>
> I would be OK with that but only if we sanitize a bit how the lfun are
> used. Emitting a dozen boost signal on a simple keyst
Andre Poenitz wrote:
On Tue, Sep 19, 2006 at 10:30:11AM +0200, Abdelrazak Younes wrote:
Unfortunately, there's no obvious better solution than these big, ugly
switch statements. At least, not in C++.
There is one elegant solution IMHO, array of function pointers. This
would mean that each LFUN
On Tue, Sep 19, 2006 at 01:25:24AM +0100, Angus Leeming wrote:
> Unfortunately, there's no obvious better solution than these big, ugly
> switch statements. At least, not in C++.
Well, dispatching an LFUN is basically triggering an action and there's
no reason why action handling needs to be done
On Tue, Sep 19, 2006 at 10:30:11AM +0200, Abdelrazak Younes wrote:
> >Unfortunately, there's no obvious better solution than these big, ugly
> >switch statements. At least, not in C++.
>
> There is one elegant solution IMHO, array of function pointers. This
> would mean that each LFUN (or a grou
Angus Leeming wrote:
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Sep 17, 2006 at 10:03:33PM +0200, Abdelrazak Younes wrote:
Code that is not understandable is bad and should be simplified. In
addition, these changes would enable me to get rid of the LyXView
dependency in BufferView.
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Sun, Sep 17, 2006 at 10:03:33PM +0200, Abdelrazak Younes wrote:
Code that is not understandable is bad and should be simplified. In
addition, these changes would enable me to get rid of the LyXView
dependency in BufferView.
Check 'svn blame'.
Andre Poenitz wrote:
On Mon, Sep 18, 2006 at 10:07:01AM +0200, Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The dispatch function called is not the same dispatch function
anymore. There might be a reason why we have decided to go through
the top most
Andre Poenitz wrote:
On Sun, Sep 17, 2006 at 10:03:33PM +0200, Abdelrazak Younes wrote:
Code that is not understandable is bad and should be simplified. In
addition, these changes would enable me to get rid of the LyXView
dependency in BufferView.
Check 'svn blame'. If it says 'poenitz' or su
On Sun, Sep 17, 2006 at 10:03:33PM +0200, Abdelrazak Younes wrote:
> Code that is not understandable is bad and should be simplified. In
> addition, these changes would enable me to get rid of the LyXView
> dependency in BufferView.
Check 'svn blame'. If it says 'poenitz' or such just apply your
On Mon, Sep 18, 2006 at 12:45:25PM +0200, Abdelrazak Younes wrote:
> Jean-Marc Lasgouttes wrote:
> >>"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> >
> >Abdelrazak> Don't you think that this is a waste of CPU cycles? The
> >Abdelrazak> update machinery is done anyway because th
On Sun, Sep 17, 2006 at 10:26:01PM +0200, Lars Gullik Bjønnes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> | > The dispatch function called is not the same dispatch function
> | > anymore. There might be a reason why we have decided to go through the
> | > top most dispatch and let t
On Mon, Sep 18, 2006 at 10:07:01AM +0200, Jean-Marc Lasgouttes wrote:
> > "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> >> The dispatch function called is not the same dispatch function
> >> anymore. There might be a reason why we have decided to go through
> >> the top mos
On Mon, Sep 18, 2006 at 01:18:24AM +0200, Lars Gullik Bjønnes wrote:
> Yeah, but it also means that some LFUNS, if called from lyxtext must
> still use bv.owner()->dispatch(...), else you will not be able to
> reach all available LFUNS.
Indeed. But the ones used there should. In theory at least.
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Don't you think that this is a waste of CPU cycles? The
Abdelrazak> update machinery is done anyway because this
Abdelrazak> LyXText::setLayout() method is called only twice in two
Abdelrazak>
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Don't you think that this is a waste of CPU cycles? The
Abdelrazak> update machinery is done anyway because this
Abdelrazak> LyXText::setLayout() method is called only twice in two
Abdelrazak> LFUNs in text3.C: LFUN_FL
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I know there could be potential problem but I have had a
Abdelrazak> closed look at these lfuns one by one. We are talking here
Abdelrazak> about simple editing lfun not something complicated.
Angus Leeming wrote:
Abdelrazak Younes wrote:
Could be a good idea. But and this is a big BUT, I'd argue that if an
lfun needs to call another lfun, then that's a design problem. So if
you prefer, I can rework my patch so that there is no dispatch call
any more.
That's certainly not true. Ma
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> I know there could be potential problem but I have had a
Abdelrazak> closed look at these lfuns one by one. We are talking here
Abdelrazak> about simple editing lfun not something complicated.
Yes, but in the future w
Abdelrazak Younes wrote:
Could be a good idea. But and this is a big BUT, I'd argue that if an
lfun needs to call another lfun, then that's a design problem. So if you
prefer, I can rework my patch so that there is no dispatch call any more.
That's certainly not true. Many of the inset LFUNs a
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
The dispatch function called is not the same dispatch function
anymore. There might be a reason why we have decided to go through
the top most dispatch and let that handle the traversement of the
dispatch
Angus Leeming wrote:
Abdelrazak Younes wrote:
More seriously, why is it a problem? The dispatch hierarchy will
inevitably end-up there so why not take the shortcut? IMHO the code
looks a lot more cleaner this way.
It may look cleaner to you, but now you're creating two ways to get to
the sam
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> The dispatch function called is not the same dispatch function
>> anymore. There might be a reason why we have decided to go through
>> the top most dispatch and let that handle the traversement of the
>> dispatch hierarchy.
A
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Lars Gullik Bjønnes wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > | > The dispatch function called is not the same dispatch function
| > | > anymore. There might be a reason why we have decided to go through the
| > | > top most dispat
Abdelrazak Younes wrote:
More seriously, why is it a problem? The dispatch hierarchy will
inevitably end-up there so why not take the shortcut? IMHO the code
looks a lot more cleaner this way.
It may look cleaner to you, but now you're creating two ways to get to
the same point. That's someth
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > The dispatch function called is not the same dispatch function
| > anymore. There might be a reason why we have decided to go through the
| > top most dispatch and let that handle the traversement of the dispatch
| > hi
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| > The dispatch function called is not the same dispatch function
| > anymore. There might be a reason why we have decided to go through the
| > top most dispatch and let that handle the traversement of the dispatch
| > hierarchy.
|
| And what is tha
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Hello,
|
| This patch makes LyXText code use directly LyXText::dispatch() instead
| of the cur.bv().owner()->dispatch() redirection.
|
| Objection?
|
| Abdel.
| Index: text2.C
| ==
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Hello,
|
| This patch makes LyXText code use directly LyXText::dispatch() instead
| of the cur.bv().owner()->dispatch() redirection.
|
| Objection?
|
| Abdel.
| Index: text2.C
| ===
|
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Hello,
|
| This patch makes LyXText code use directly LyXText::dispatch() instead
| of the cur.bv().owner()->dispatch() redirection.
|
| Objection?
Is it guaranteed that 'this' is equal to 'bv.owner()'?
How is that g
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Hello,
|
| This patch makes LyXText code use directly LyXText::dispatch() instead
| of the cur.bv().owner()->dispatch() redirection.
|
| Objection?
Is it guaranteed that 'this' is equal to 'bv.owner()'?
How is that guarantee forced?
--
Hello,
This patch makes LyXText code use directly LyXText::dispatch() instead
of the cur.bv().owner()->dispatch() redirection.
Objection?
Abdel.
Index: text2.C
===
--- text2.C (revision 15030)
+++ text2.C (working copy)
@
31 matches
Mail list logo
