Abdelrazak Younes [EMAIL PROTECTED] writes:
| Angus Leeming wrote:
| Abdelrazak Younes [EMAIL PROTECTED] writes:
| Do we still need guiapi.[Ch]? Again, it seems like it is not
| linked to the final LyX executable.
| I let it there because I don't know it is used in some external
| client. We
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
| > Abdelrazak Younes <[EMAIL PROTECTED]> writes:
| >>> Do we still need guiapi.[Ch]? Again, it seems like it is not
| >>> linked to the final LyX executable.
| >> I let it there because I don't know it is used in some external
Angus Leeming wrote:
Abdelrazak Younes [EMAIL PROTECTED] writes:
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
I let it there because I don't know it is used in some external client.
We shall know if this is true or not before removing this.
Angus Leeming wrote:
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
I let it there because I don't know it is used in some external client.
We shall know if this is true or not before removing this.
Abdelrazak Younes [EMAIL PROTECTED] writes:
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
I let it there because I don't know it is used in some external client.
We shall know if this is true or not before removing this.
You can kill
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> > Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
> > the final LyX executable.
>
> I let it there because I don't know it is used in some external client.
> We shall know if this is true or not before removing this.
You
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
Michael
Michael Gerz wrote:
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
I let it there because I don't know it is used in some external client.
We shall know if this is true or not before removing this.
Abdel.
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
Michael
Michael Gerz wrote:
Do we still need guiapi.[Ch]? Again, it seems like it is not linked to
the final LyX executable.
I let it there because I don't know it is used in some external client.
We shall know if this is true or not before removing this.
Abdel.
/: ChangeLog Dialogs.h guiapi.C guiapi.h
lyx-devel/src/frontends/controllers/: ChangeLog ControlFloat.C
ControlFloat.h
ControlInclude.C
lyx-devel/src/frontends/qt2/: ChangeLog Dialogs.C Dialogs2.C
/: ChangeLog Dialogs.h guiapi.C guiapi.h
lyx-devel/src/frontends/controllers/: ChangeLog ControlWrap.C
ControlWrap.h
lyx-devel/src/frontends/qt2/: ChangeLog Dialogs.C Dialogs2.C
Dialogs3.C Dialogs_impl.h
; lyx-devel/src/frontends/: ChangeLog Dialogs.h guiapi.C guiapi.h
> lyx-devel/src/frontends/controllers/: ChangeLog ControlFloat.C
> ControlFloat.h
> ControlInclude.C
> lyx-devel/src/fr
; lyx-devel/src/frontends/: ChangeLog Dialogs.h guiapi.C guiapi.h
> lyx-devel/src/frontends/controllers/: ChangeLog ControlWrap.C
> ControlWrap.h
> lyx-devel/src/frontends/qt2/: ChangeLog Dialogs.C Dialogs2.C
>
It's mentioned in makefile.am but not there...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
On Thu, Aug 15, 2002 at 02:57:47PM +0200, Andre' Poenitz wrote:
It's mentioned in makefile.am but not there...
Hm, as it compiles after a 'touch guiapi.C', maybe it's just the
Makefile.am that's wrong?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have
On Thursday 15 August 2002 2:01 pm, Andre Poenitz wrote:
On Thu, Aug 15, 2002 at 02:57:47PM +0200, Andre' Poenitz wrote:
It's mentioned in makefile.am but not there...
Hm, as it compiles after a 'touch guiapi.C', maybe it's just the
Makefile.am that's wrong?
If it's in frontends
Angus,
I'd like to kill the display() function of formulabase.C.
I am at the poit were it is only used for that 12-pixel-descent-
correction for preview image. Could that be solved otherwise?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they
On Thursday 15 August 2002 2:30 pm, Andre Poenitz wrote:
Angus,
I'd like to kill the display() function of formulabase.C.
I am at the poit were it is only used for that 12-pixel-descent-
correction for preview image. Could that be solved otherwise?
There is no display() function in
On Thursday 15 August 2002 2:18 pm, Angus Leeming wrote:
int InsetFormula::descent(BufferView *, LyXFont const ) const
{
if (!preview_-previewReady())
return 1 + par_-descent();
int const descent = preview_-pimage()-descent();
return display() ? descent + 12
On Thu, Aug 15, 2002 at 02:18:47PM +0100, Angus Leeming wrote:
int InsetFormula::descent(BufferView *, LyXFont const ) const
{
if (!preview_-previewReady())
return 1 + par_-descent();
int const descent = preview_-pimage()-descent();
return display() ?
On Thu, Aug 15, 2002 at 02:21:26PM +0100, Angus Leeming wrote:
The simple answer is I don't know. You had a similar fix elsewhere. How did
you solve it?
*shrug* Don't know. Either not at all or the solution got lost.
I think I'll just kill the correction (as that would alllow me to simplify
a
On Thursday 15 August 2002 2:46 pm, Andre Poenitz wrote:
On Thu, Aug 15, 2002 at 02:21:26PM +0100, Angus Leeming wrote:
The simple answer is I don't know. You had a similar fix elsewhere. How
did you solve it?
*shrug* Don't know. Either not at all or the solution got lost.
I think I'll
It's mentioned in makefile.am but not there...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
On Thu, Aug 15, 2002 at 02:57:47PM +0200, Andre' Poenitz wrote:
> It's mentioned in makefile.am but not there...
Hm, as it compiles after a 'touch guiapi.C', maybe it's just the
Makefile.am that's wrong?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not h
On Thursday 15 August 2002 2:01 pm, Andre Poenitz wrote:
> On Thu, Aug 15, 2002 at 02:57:47PM +0200, Andre' Poenitz wrote:
> > It's mentioned in makefile.am but not there...
>
> Hm, as it compiles after a 'touch guiapi.C', maybe it's just the
> Makefile.am that's wrong?
If
Angus,
I'd like to kill the display() function of formulabase.C.
I am at the poit were it is only used for that 12-pixel-descent-
correction for preview image. Could that be solved otherwise?
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they
On Thursday 15 August 2002 2:30 pm, Andre Poenitz wrote:
> Angus,
>
> I'd like to kill the display() function of formulabase.C.
>
> I am at the poit were it is only used for that 12-pixel-descent-
> correction for preview image. Could that be solved otherwise?
There is no display() function in
On Thursday 15 August 2002 2:18 pm, Angus Leeming wrote:
> int InsetFormula::descent(BufferView *, LyXFont const &) const
> {
> if (!preview_->previewReady())
> return 1 + par_->descent();
>
> int const descent = preview_->pimage()->descent();
> return display() ?
On Thu, Aug 15, 2002 at 02:18:47PM +0100, Angus Leeming wrote:
> int InsetFormula::descent(BufferView *, LyXFont const &) const
> {
> if (!preview_->previewReady())
> return 1 + par_->descent();
>
> int const descent = preview_->pimage()->descent();
> return
On Thu, Aug 15, 2002 at 02:21:26PM +0100, Angus Leeming wrote:
> The simple answer is "I don't know". You had a similar fix elsewhere. How did
> you solve it?
*shrug* Don't know. Either not at all or the solution got lost.
I think I'll just kill the correction (as that would alllow me to
On Thursday 15 August 2002 2:46 pm, Andre Poenitz wrote:
> On Thu, Aug 15, 2002 at 02:21:26PM +0100, Angus Leeming wrote:
> > The simple answer is "I don't know". You had a similar fix elsewhere. How
> > did you solve it?
>
> *shrug* Don't know. Either not at all or the solution got lost.
> I
We used to have code that would have resulted in each separate LyXView having
its own set of dialogs.
Lars created guiapi.C and moved all the dialogs into singleton classes that
could be accessed through the various functions. Eg
extern C {
void gui_ShowAboutlyx(LyXView lv, Dialogs
Angus Leeming [EMAIL PROTECTED] writes:
| We used to have code that would have resulted in each separate LyXView having
| its own set of dialogs.
| Lars created guiapi.C and moved all the dialogs into singleton classes that
| could be accessed through the various functions. Eg
| extern C
On Tuesday 13 August 2002 4:24 pm, Lars Gullik Bjønnes wrote:
| Connect these boost::functions to the appropriate methods hidden deep
| within frontends. Eg
| showAboutLyX=boost::bind(ControlAboutLyX::show, this);
| (I'd like to do this in the Dialogs c-tor, but we'll see...)
and where
We used to have code that would have resulted in each separate LyXView having
its own set of dialogs.
Lars created guiapi.C and moved all the dialogs into singleton classes that
could be accessed through the various functions. Eg
extern "C" {
void gui_ShowAboutlyx(Ly
Angus Leeming <[EMAIL PROTECTED]> writes:
| We used to have code that would have resulted in each separate LyXView having
| its own set of dialogs.
>
| Lars created guiapi.C and moved all the dialogs into singleton classes that
| could be accessed through the various functions. Eg
&
On Tuesday 13 August 2002 4:24 pm, Lars Gullik Bjønnes wrote:
> | Connect these boost::functions to the appropriate methods hidden deep
> | within frontends. Eg
> | showAboutLyX=boost::bind(::show, this);
> | (I'd like to do this in the Dialogs c-tor, but we'll see...)
>
> and where do you
38 matches
Mail list logo
