Andre Poenitz <[EMAIL PROTECTED]> writes:
| If we were serious about cutting dependencies we'd just use that GUI
| toolkit with embedded kitchen sink. There wouldn't even be much need for
| boost then...
and tr1 ... and tr2...
Qt has a nice way of going backwards into the future.
--
Lg
On Thu, Jul 27, 2006 at 10:49:01AM +0200, Lars Gullik Bjønnes wrote:
> | > I still need to have communication between two processes?
> |
> | I am bassically talking about simple linking and a simgle process.
>
> Do we really feel the overwelming need for an embedded script
> language?
It would f
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sat, Jul 22, 2006 at 06:06:39PM +0200, Lars Gullik Bjønnes wrote:
| > Andre Poenitz <[EMAIL PROTECTED]> writes:
| > | For external use a python extension seems to be in orderi. This could
| > | be just a thin wrapper around the lfun interface. [This i
On Sat, Jul 22, 2006 at 06:06:39PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
> | For external use a python extension seems to be in orderi. This could
> | be just a thin wrapper around the lfun interface. [This is closer to
> | 'embedding LyX in Python'.]
> |
>
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Sun, Jul 16, 2006 at 11:34:34AM +0200, Lars Gullik Bjønnes wrote:
| > | Apart from that I never said we should not use the LFUN interface.
| > | However, going through the lyxserver is a completely unecesary
| > | complication.
| >
| > So what commun
On Sun, Jul 16, 2006 at 11:34:34AM +0200, Lars Gullik Bjønnes wrote:
> | Apart from that I never said we should not use the LFUN interface.
> | However, going through the lyxserver is a completely unecesary
> | complication.
>
> So what communication channel do you see as suitable?
> (Or do you wa
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Thu, Jul 13, 2006 at 09:52:27PM +0200, Lars Gullik Bjønnes wrote:
| > | That feels like a good decision from a security POV. Why'd anyone want to
enable
| > | a scripting language to be able to execute lyx::support::unlink f.ex.?
| > |
| > | What do
On Thu, Jul 13, 2006 at 09:52:27PM +0200, Lars Gullik Bjønnes wrote:
> | That feels like a good decision from a security POV. Why'd anyone want to
> enable
> | a scripting language to be able to execute lyx::support::unlink f.ex.?
> |
> | What do I miss?
>
> >From my POV nothing.
Maybe most scr
On Thu, Jul 13, 2006 at 09:03:42PM +0200, Lars Gullik Bjønnes wrote:
> Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> | On Wed, Jul 12, 2006 at 10:24:18AM +, Angus Leeming wrote:
> | > That use the LyXServer? There are a number of bibliography database
> | > programs. Pybliographer is the one
On Sat, 15 Jul 2006, Abdelrazak Younes wrote:
I look forward to the day when more than one person can edit the same
document simultaneously!
There's some more clean-up to do but I think this is achievable.
I think Frame Maker allowed two people to edit a document simultaneously,
but I don't
[EMAIL PROTECTED] wrote:
On Tue, 11 Jul 2006, Lars Gullik Bjønnes wrote:
...
| that, but I think that having the BufferView emitting signals is |
wrong. The BufferView is just a tool used by the frontend to visualize
| the buffer.
Yes, but it is not only "The Frontend" it might be "Frontends
On Tue, 11 Jul 2006, Lars Gullik Bjønnes wrote:
...
| that, but I think that having the BufferView emitting signals is |
wrong. The BufferView is just a tool used by the frontend to visualize |
the buffer.
Yes, but it is not only "The Frontend" it might be "Frontends", and then
signals for c
Angus Leeming <[EMAIL PROTECTED]> writes:
| Angus Leeming <[EMAIL PROTECTED]> writes:
| > Lars Gullik Bjønnes ...> writes:
| > > | Can someone explain how this "embedding" works? LyX itself understands
| > > | LFUNs not Python so we'll still need to translate the python to a
| > > | series of LF
Angus Leeming <[EMAIL PROTECTED]> writes:
> Lars Gullik Bjønnes ...> writes:
> > | Can someone explain how this "embedding" works? LyX itself understands
> > | LFUNs not Python so we'll still need to translate the python to a
> > | series of LFUNs, no?
> >
> > Yes. So imho it is simpler to write
Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes:
> | Can someone explain how this "embedding" works? LyX itself understands
> | LFUNs not Python so we'll still need to translate the python to a
> | series of LFUNs, no?
>
> Yes. So imho it is simpler to write a lib python/ruby/java/whatever
> that c
Angus Leeming <[EMAIL PROTECTED]> writes:
| André Pönitz wrote:
| > On Wed, Jul 12, 2006 at 10:24:18AM +, Angus Leeming wrote:
| >> There's lots that is a mess about the LFUN language (ad hoc,
| >> no formal grammar, etc) but it is powerful and will become
| >> more so if someone adds the abil
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Wed, Jul 12, 2006 at 10:24:18AM +, Angus Leeming wrote:
| > That use the LyXServer? There are a number of bibliography database
| > programs. Pybliographer is the one I'm familiar with but there are
| > others.
| >
| > There's also the LyXSocket
André Pönitz wrote:
> On Wed, Jul 12, 2006 at 10:24:18AM +, Angus Leeming wrote:
>> There's lots that is a mess about the LFUN language (ad hoc,
>> no formal grammar, etc) but it is powerful and will become
>> more so if someone adds the ability to return queried-for
>> information like these L
On Wednesday 12 July 2006 17:46, Andre Poenitz wrote:
> Shouldn't we simply embed Python now that it has become de facto the
> Chosen Scripting Language?
No, no, we will start the LI (Language Independent) sub-project since we
don't want to alienate the perl, ruby, lua and scheme developers in
On Wed, Jul 12, 2006 at 10:24:18AM +, Angus Leeming wrote:
> That use the LyXServer? There are a number of bibliography database
> programs. Pybliographer is the one I'm familiar with but there are
> others.
>
> There's also the LyXSocket stuff which is conceptually similar (uses
> sockets ra
Abdelrazak Younes wrote:
> Angus Leeming wrote:
>> What happens in the (hypothetical for now) case when we have two
>> LyXViews neither of which have focus and the LyXServer receives
>> the setBuffer LFUN? Which LyXView do we choose is "active"?
> We will need to adjust the protocol...
> ... Are t
Jose' Matos wrote:
On Wednesday 12 July 2006 10:59, Abdelrazak Younes wrote:
I believe Angus was talking about some program communicating with the
LyXServer without any GUI interaction.
I know, I was referring to --remote-url (if not this another similar), that
ask to recycle an existing in
On Wednesday 12 July 2006 10:59, Abdelrazak Younes wrote:
> I believe Angus was talking about some program communicating with the
> LyXServer without any GUI interaction.
I know, I was referring to --remote-url (if not this another similar), that
ask to recycle an existing instance and not to o
Jose' Matos wrote:
On Wednesday 12 July 2006 10:33, Angus Leeming wrote:
What happens in the (hypothetical for now) case when we have two LyXViews
neither of which have focus and the LyXServer receives the setBuffer LFUN?
Which LyXView do we choose is "active"?
Using firefox, as an example,
Angus Leeming wrote:
Abdelrazak Younes wrote:
Angus Leeming wrote:
I haven't looked at the patch but I do have a question: why LyXView?
Good question. There are two reasons why setBuffer and LoadLyXFile are
transfered to LyXView instead of WorkArea:
...
Does it make sense?
Having looke
On Wednesday 12 July 2006 10:33, Angus Leeming wrote:
> What happens in the (hypothetical for now) case when we have two LyXViews
> neither of which have focus and the LyXServer receives the setBuffer LFUN?
> Which LyXView do we choose is "active"?
Using firefox, as an example, I would say that
Abdelrazak Younes wrote:
> Angus Leeming wrote:
>> I haven't looked at the patch but I do have a question: why LyXView?
> Good question. There are two reasons why setBuffer and LoadLyXFile are
> transfered to LyXView instead of WorkArea:
...
> Does it make sense?
Having looked at the code now,
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
This commit move out from BufferView all update to the LyXView owner.
The goal is that BufferView is not used directly but LyXView instead.
There is a degradation of performance due to too many calls to
WorkArea::redraw(). I ha
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> This commit move out from BufferView all update to the LyXView owner.
> The goal is that BufferView is not used directly but LyXView instead.
> There is a degradation of performance due to too many calls to
> WorkArea::redraw(). I have to review wh
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Right now, when the user press a key, th Qt event handler calls the
| processKeySym lfun which calls BufferView::update() (two times). The
| signal LyXView::view_state_changed() is then emitted from there (two
| times). B
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Right now, when the user press a key, th Qt event handler calls the
| processKeySym lfun which calls BufferView::update() (two times). The
| signal LyXView::view_state_changed() is then emitted from there (two
| times). But the frontend was of course
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| So, using your terminology, I'd say that Buffer is the server and
| the
| the WorkArea (thus the frontend) is the client as one buffer might be
| edited and/or visualized in multiple WorkArea. I would agree with
| that, b
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| So, using your terminology, I'd say that Buffer is the server and
| the
| the WorkArea (thus the frontend) is the client as one buffer might be
| edited and/or visualized in multiple WorkArea. I would agree with
| that, but I think that having the Bu
Lars Gullik Bjønnes wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| In principle I agree that the use of signals is very beneficial in the
| case of event driven application. This is the case for
| pseudo-desynchronized dialogs and for forked process handling. But in
| the case of kernel
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| In principle I agree that the use of signals is very beneficial in the
| case of event driven application. This is the case for
| pseudo-desynchronized dialogs and for forked process handling. But in
| the case of kernel <-> frontend I am not sure th
Angus Leeming wrote:
Angus Leeming wrote:
I don't think that you'll get a definitive answer from them. This
signal precedes Abdel
Indeed but I could have answered . Eventually all the boost signals
should disappear...
I don't agree with that. There are some, such as the signal from the
core
> Angus Leeming wrote:
>> I don't think that you'll get a definitive answer from them. This
>> signal precedes Abdel
> Indeed but I could have answered . Eventually all the boost signals
> should disappear...
I don't agree with that. There are some, such as the signal from the
core that the buff
Angus Leeming wrote:
Michael Gerz <[EMAIL PROTECTED]> writes:
Abdel, Lars,
could you please have a look at the attached patch?
I don't think that you'll get a definitive answer from them. This signal
precedes Abdel
Indeed but I could have answered ;-). Eventually all the boost signals
shoul
Angus Leeming <[EMAIL PROTECTED]> writes:
| Michael Gerz <[EMAIL PROTECTED]> writes:
| > Abdel, Lars,
| > could you please have a look at the attached patch?
|
| I don't think that you'll get a definitive answer from them. This signal
| precedes Abdel and Lars has only just found the frontend cod
Michael Gerz <[EMAIL PROTECTED]> writes:
> Abdel, Lars,
> could you please have a look at the attached patch?
I don't think that you'll get a definitive answer from them. This signal
precedes Abdel and Lars has only just found the frontend code ;-)
> Is redrawGUI a remainder of the xforms or is i
Abdel, Lars,
could you please have a look at the attached patch?
Is redrawGUI a remainder of the xforms or is it still needed?
Michael
Index: Dialogs.h
===
--- Dialogs.h (Revision 14416)
+++ Dialogs.h (Arbeitskopie)
@@ -34,14 +34,
41 matches
Mail list logo
