Re: [patch] more signals

2003-07-07 Thread Andre Poenitz
On Sun, Jul 06, 2003 at 10:02:33AM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > >> And how does calling BufferView through FuncRequest (through/passing > >> BufferView again) leads to cleaner code as opposed to calling it > >> directly? > > > > *shrug* > > > > Perhaps it doesn't.

Re: [patch] more signals

2003-07-06 Thread Alfredo Braunstein
Andre Poenitz wrote: >> And how does calling BufferView through FuncRequest (through/passing >> BufferView again) leads to cleaner code as opposed to calling it >> directly? > > *shrug* > > Perhaps it doesn't. And what's your final veredict then? Should I apply it, repost it, break it into sm

Re: [patch] more signals

2003-07-04 Thread Alfredo Braunstein
Lars Gullik Bjønnes wrote: > (And for this I find signals more approp than LFUNS) What about the patch I've sent (at the top of this thread)? Alfredo

Re: [patch] more signals

2003-07-03 Thread Lars Gullik Bjønnes
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | > It is not really supposed to stay a pointer, but to be a list of | > BufferViews using this buffer. | Isn't this more cleanly implemented with signals (or eventually, with | lyxfuncs if I ever get to understand how they work)? I don't understand

Re: [patch] more signals

2003-07-03 Thread Andre Poenitz
On Thu, Jul 03, 2003 at 11:55:12AM +0200, Alfredo Braunstein wrote: > > There is a bv field in FuncRequest for starters. > > And how does calling BufferView through FuncRequest (through/passing > BufferView again) leads to cleaner code as opposed to calling it directly? *shrug* Perhaps it doesn'

Re: [patch] more signals

2003-07-03 Thread Alfredo Braunstein
Andre Poenitz wrote: > On Thu, Jul 03, 2003 at 11:42:59AM +0200, Alfredo Braunstein wrote: >> > Then there are a couple of buffers, each could be looked at from >> > different views. This would make a nice tree, wouldn't it? Now all >> > requests can be fed it at the root of that tree, i.e. at the

Re: [patch] more signals

2003-07-03 Thread Andre Poenitz
On Thu, Jul 03, 2003 at 11:42:59AM +0200, Alfredo Braunstein wrote: > > Then there are a couple of buffers, each could be looked at from different > > views. This would make a nice tree, wouldn't it? Now all requests can be > > fed it at the root of that tree, i.e. at the LyXView or the LyXFunc. As

Re: [patch] more signals

2003-07-03 Thread Alfredo Braunstein
Andre Poenitz wrote: >> - gets the LyXView from the BufferView >> - get the LyXFunc from the LyXView >> - pass this LyXFunc to LaTeX >> - LaTeX dispatch its messages there > > Well, _I_'d ignore the possibility of different LyXViews for the next few > years (I have done so for a while now, and I

Re: [patch] more signals

2003-07-03 Thread Andre Poenitz
On Thu, Jul 03, 2003 at 10:25:43AM +0200, Alfredo Braunstein wrote: > Then there's something fishy going on right now, because the current (say, > converter) code does this: > > - gets the/a BufferView from the buffer through Buffer::getUser (getUser is > conceptually wrong per se IMHO - not much

Re: [patch] more signals

2003-07-03 Thread Alfredo Braunstein
Lars Gullik Bjønnes wrote: > Alfredo Braunstein <[EMAIL PROTECTED]> writes: > > | - gets the/a BufferView from the buffer through Buffer::getUser (getUser > | is conceptually wrong per se IMHO - not much different from > | current_view) > > It is not really supposed to stay a pointer, but to be

Re: [patch] more signals

2003-07-03 Thread Lars Gullik Bjønnes
Alfredo Braunstein <[EMAIL PROTECTED]> writes: | - gets the/a BufferView from the buffer through Buffer::getUser (getUser is | conceptually wrong per se IMHO - not much different from | current_view) It is not really supposed to stay a pointer, but to be a list of BufferViews using this buffer.

Re: [patch] more signals

2003-07-03 Thread Alfredo Braunstein
Andre Poenitz wrote: >> Does LyXFunc::dispatch is able to dispatch the message to all bv's the >> buffer is connected to (and not others)? Would this be wanted? > > As we don't have multiple views right now: |all| == 1, so 'yes'. But I > don't know how this scales up. Does this information need t

Re: [patch] more signals

2003-07-03 Thread Andre Poenitz
On Thu, Jul 03, 2003 at 09:53:53AM +0200, Alfredo Braunstein wrote: > Andre Poenitz wrote: > > > I just wonder whether the whole signal business does not somehow > > undermine the 'LFUN everywhere' approach. For peaceful coexistence I'd > > expect that any 'unusual' signal gets delivered to LyXFu

Re: [patch] more signals

2003-07-03 Thread Alfredo Braunstein
Andre Poenitz wrote: > I just wonder whether the whole signal business does not somehow > undermine the 'LFUN everywhere' approach. For peaceful coexistence I'd > expect that any 'unusual' signal gets delivered to LyXFunc::dispatch which > in turn figures out the BufferView, and calls dispatch()

Re: [patch] more signals

2003-07-03 Thread Andre Poenitz
On Wed, Jul 02, 2003 at 10:39:47PM +0200, Alfredo Braunstein wrote: > This patch > > - introduces two new signals in buffer: busy and message. I've renamed > parseError to error because it's used more generally than for parse errors. > It could still use a better name maybe. > > - adds all three

[patch] more signals

2003-07-02 Thread Alfredo Braunstein
This patch - introduces two new signals in buffer: busy and message. I've renamed parseError to error because it's used more generally than for parse errors. It could still use a better name maybe. - adds all three boost::signals::connection objects to BufferView::pimpl + connect/disconnect signa