On Sun, Oct 07, 2007 at 02:04:10AM -0700, Angus Leeming wrote:
> Andre Poenitz wrote:
> >On Sat, Oct 06, 2007 at 10:13:58PM -0700, Angus Leeming wrote:
> >>Abdelrazak Younes wrote:
> >>>I think that what we call "controllers" are really just abstraction
>
Andre Poenitz wrote:
On Sat, Oct 06, 2007 at 10:13:58PM -0700, Angus Leeming wrote:
Abdelrazak Younes wrote:
I think that what we call "controllers" are really just abstraction
layers created for the benefit of code sharing between multiple
frontends.
That's exactly what they
On Sat, Oct 06, 2007 at 10:13:58PM -0700, Angus Leeming wrote:
> Abdelrazak Younes wrote:
> >I think that what we call "controllers" are really just abstraction
> >layers created for the benefit of code sharing between multiple
> >frontends.
>
> That's
Abdelrazak Younes wrote:
I think that what we call "controllers" are really just abstraction
layers created for the benefit of code sharing between multiple
frontends.
That's exactly what they are. Now that only Qt4 survives, there's no
reason for their continued existe
On Fri, Oct 05, 2007 at 03:23:27PM -0400, Richard Heck wrote:
>
> Looking over this, it seems that you're doing more than just eliminating
> the controllers. By eliminating ControlCommand, you are also eliminating
> the way ControlRef (e.g.) inherited from ControlCommand, so
Looking over this, it seems that you're doing more than just eliminating
the controllers. By eliminating ControlCommand, you are also eliminating
the way ControlRef (e.g.) inherited from ControlCommand, so it
looks---and I've only looked at this quickly---as if this will lea
oving the controller API layer but, if you do that, I'd prefer that
you isolate relevant codes that is frontend independent and put them in
helper functions. Those helpers functions can stay in
frontends/controllers/ or in a new frontends/helpers/
Or even in the core if it is useful th
On Fri, Oct 05, 2007 at 11:04:33AM +0200, Jean-Marc Lasgouttes wrote:
> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>
> > Basically, frontends/qt4 should contain everything about
> > _visualisation_ on screen and frontends/helpers/ should contain
> > advanced algorithms like data searching, etc.
the fuss about insets and ranges, any comment on that?
>
> I think that what we call "controllers" are really just abstraction
> layers created for the benefit of code sharing between multiple
> frontends.
Right.
> I am still in the opinion that non obvious algorithms
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Thu, Oct 04, 2007 at 09:19:04PM +0200, Andre Poenitz wrote:
I am looking for a way to solve the "controller problem".
[...]
Hm, with all the fuss about insets and ranges, any comment on that?
I think that what we call "c
Andre Poenitz wrote:
On Thu, Oct 04, 2007 at 09:19:04PM +0200, Andre Poenitz wrote:
I am looking for a way to solve the "controller problem".
[...]
Hm, with all the fuss about insets and ranges, any comment on that?
Less code gives faster compiles. And then it becomes more
interest
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
> Basically, frontends/qt4 should contain everything about
> _visualisation_ on screen and frontends/helpers/ should contain
> advanced algorithms like data searching, etc.
+1.
JMarc
Andre Poenitz wrote:
On Thu, Oct 04, 2007 at 09:19:04PM +0200, Andre Poenitz wrote:
I am looking for a way to solve the "controller problem".
[...]
Hm, with all the fuss about insets and ranges, any comment on that?
I think that what we call "controllers" are really just
On Thu, Oct 04, 2007 at 09:19:04PM +0200, Andre Poenitz wrote:
> I am looking for a way to solve the "controller problem".
> [...]
Hm, with all the fuss about insets and ranges, any comment on that?
Andre'
ned by me is "having to wait for
compiling stuff that I consider useless."
Part of the "controller problem" is also that our controllers are
more or less _only_ an interface between core and dialog. When one
browses a bit at http://en.wikipedia.org/wiki/Model-view-controlle
On Sun, Sep 16, 2007 at 06:50:04PM +0200, Jürgen Spitzmüller wrote:
> Andre Poenitz wrote:
> > > So as long as I don't see
> > > src/frontends/controllers/tests/regfiles/biblio show up in the
> > > source-tarball, I will also disable
> > > src/fron
Andre Poenitz wrote:
> > So as long as I don't see
> > src/frontends/controllers/tests/regfiles/biblio show up in the
> > source-tarball, I will also disable
> > src/frontends/controllers/tests/test_biblio. (Unless anybody tells me,
> > that this test is ver
Bo Peng wrote:
LFUNs can accept as many parameters as you like and, in principle, in
whatever form you like. You just have to parse it.
So I guess I can use
LFUN_EMBEDDED_FILES embed file
LFUN_EMBEDDED_FILES add file
etc..
I don't see why not, in principle.
rh
--
==
> LFUNs can accept as many parameters as you like and, in principle, in
> whatever form you like. You just have to parse it.
So I guess I can use
LFUN_EMBEDDED_FILES embed file
LFUN_EMBEDDED_FILES add file
etc..
Bo
Bo Peng wrote:
You are right, but the problem is that there are two many opearations:
add file, extract file, embed file, dis-embed file, ...
How many exactly? Which of these could be useful from the lyx-server?
If LFUN can only accept one parameter, then
LFUN_EMBED_FILE file
LFUN
> > You are right, but the problem is that there are two many opearations:
> > add file, extract file, embed file, dis-embed file, ...
>
> How many exactly? Which of these could be useful from the lyx-server?
If LFUN can only accept one parameter, then
LFUN_EMBED_FILE file
LFUN_UN_EMBED_FILE file
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> Makes me wonder: isn't embedding something we would like to do with an
>> lfun (which would take care of the dirty work)?
>
> You are right, but the problem is that there are two many opearations:
> add file, extract file, embed file, dis-embed file, ...
H
> Makes me wonder: isn't embedding something we would like to do with an
> lfun (which would take care of the dirty work)?
You are right, but the problem is that there are two many opearations:
add file, extract file, embed file, dis-embed file, ...
> What happens when the document is read-only?
[EMAIL PROTECTED] writes:
> Author: bpeng
> Date: Thu Sep 13 06:45:49 2007
> New Revision: 20253
>
> URL: http://www.lyx.org/trac/changeset/20253
> Log:
> Embedding: mark buffer dirty after changing embedding status
Makes me wonder: isn't embedding something we would like to do with an
lfun (whic
On Wed, Sep 12, 2007 at 09:05:58PM +0200, Ullrich Franke wrote:
> So as long as I don't see
> src/frontends/controllers/tests/regfiles/biblio show up in the
> source-tarball, I will also disable
> src/frontends/controllers/tests/test_biblio. (Unless anybody tells me,
> th
Hi again,
I've now stumbled across the next build-error, also mentioned in
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg114305.html:
Missing src/frontends/controllers/tests/regfiles
and src/frontends/controllers/tests/regfiles/biblio
in both lyx-1.5.1.tar.gz and lyx-
ber of 'boost'
frontend_helpers.h:79: error: '_1' was not declared in this scope
make[6]: *** [ControlBibtex.lo] Error 1
make[6]: Leaving directory `/cvs/lyx-devel/trunk/src/frontends/controllers'
make[5]: *** [all] Error 2
make[5]: Leaving directory `/cvs/lyx-devel/trunk/src/fro
On Tue, Sep 04, 2007 at 06:35:59PM -, [EMAIL PROTECTED] wrote:
> Author: kuemmel
> Date: Tue Sep 4 20:35:58 2007
> New Revision: 20044
>
> URL: http://www.lyx.org/trac/changeset/20044
> Log:
> move getSecond to frontend_helpers.h
urm...
Could people please stay away from frontends/* for two
> > // copy buffer embeddedFiles to a local copy
> > kernel().buffer().embeddedFiles().update();
> > - kernel().buffer().embeddingChanged();
> > }
>
> A comment saying '// FIXME: Bo, please look here' would have been
> nicer...
Sorry about the compile problem. It was the result of
On Mon, Sep 03, 2007 at 08:06:11PM +0200, Edwin Leuven wrote:
> Andre Poenitz wrote:
>> A comment saying '// FIXME: Bo, please look here' would have been
>> nicer...
>
>
>
> i cc'ed him on that mail, thought that was nicer than leaving dead code
> laying around...
>
> but then again, de gustibus
Andre Poenitz wrote:
A comment saying '// FIXME: Bo, please look here' would have been
nicer...
i cc'ed him on that mail, thought that was nicer than leaving dead code
laying around...
but then again, de gustibus non est disputandum (right enrico?)
On Mon, Sep 03, 2007 at 01:01:40PM -, [EMAIL PROTECTED] wrote:
> Author: leuven
> Date: Mon Sep 3 15:01:38 2007
> New Revision: 20020
>
> URL: http://www.lyx.org/trac/changeset/20020
> Log:
> make lyx compile
>
> Modified:
> lyx-devel/t
Michael Gerz wrote:
> OK, I did it for you...
thanks to you both.
Jürgen
Michael Gerz schrieb:
Andre Poenitz schrieb:
Modified:
lyx-devel/trunk/src/frontends/controllers/frontend_helpers.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/controllers/frontend_helpers.cpp?rev=18992
Something is wrong with this link (surprise included).
Note
Andre Poenitz schrieb:
Modified: lyx-devel/trunk/src/frontends/controllers/frontend_helpers.cpp
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/src/frontends/controllers/frontend_helpers.cpp?rev=18992
Something is wrong with this link (surprise included).
Note that in general it is
On Thu, Jul 05, 2007 at 04:11:46PM -, [EMAIL PROTECTED] wrote:
> Author: spitz
> Date: Thu Jul 5 18:11:44 2007
> New Revision: 18992
>
> URL: http://www.lyx.org/trac/changeset/18992
> Log:
> * src/frontends/controllers/frontend_helpers.cpp Family name):
> - d
> "lasgouttes" == lasgouttes <[EMAIL PROTECTED]> writes:
lasgouttes> Author: lasgouttes Date: Thu Jul 5 12:40:00 2007 New
lasgouttes> Revision: 18988
lasgouttes> URL: http://www.lyx.org/trac/changeset/18988 Log: Patch
lasgouttes> from Pavel Sanda
lasgouttes> * frontend_helpers.cpp (Sort
> "Stefan" == Stefan Schimanski <[EMAIL PROTECTED]> writes:
Stefan> Closed the second now. I don't have the rights to close the
Stefan> first.
Now you have (even if it is too late).
JMarc
Stefan Schimanski wrote:
[EMAIL PROTECTED] wrote:
Author: sts
Date: Mon May 14 07:16:57 2007
New Revision: 18300
URL: http://www.lyx.org/trac/changeset/18300
Log:
The source view dialog does not send a lfun, so it can be applied
unconditionally. This fixes #3398 and #3594.
Please close the b
Stefan Schimanski wrote:
[EMAIL PROTECTED] wrote:
Author: sts
Date: Mon May 14 07:16:57 2007
New Revision: 18300
URL: http://www.lyx.org/trac/changeset/18300
Log:
The source view dialog does not send a lfun, so it can be applied
unconditionally. This fixes #3398 and #3594.
Please close the b
[EMAIL PROTECTED] wrote:
Author: sts
Date: Mon May 14 07:16:57 2007
New Revision: 18300
URL: http://www.lyx.org/trac/changeset/18300
Log:
The source view dialog does not send a lfun, so it can be applied
unconditionally. This fixes #3398 and #3594.
Please close the bugs Stefan.
Closed the s
[EMAIL PROTECTED] wrote:
Author: sts
Date: Mon May 14 07:16:57 2007
New Revision: 18300
URL: http://www.lyx.org/trac/changeset/18300
Log:
The source view dialog does not send a lfun, so it can be applied
unconditionally. This fixes #3398 and #3594.
Please close the bugs Stefan.
Abdel.
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"younes" == younes <[EMAIL PROTECTED]> writes:
younes> Author: younes Date: Thu May 3 16:20:12 2007 New Revision:
younes> 18186
younes> URL: http://www.lyx.org/trac/changeset/18186 Log: Fix
younes> interface problem in order to cleanly sup
Jean-Marc Lasgouttes wrote:
"younes" == younes <[EMAIL PROTECTED]> writes:
younes> Author: younes Date: Thu May 3 16:20:12 2007 New Revision:
younes> 18186
younes> URL: http://www.lyx.org/trac/changeset/18186 Log: Fix
younes> interface problem in order to cleanly support "cursor position
youn
> "younes" == younes <[EMAIL PROTECTED]> writes:
younes> Author: younes Date: Thu May 3 16:20:12 2007 New Revision:
younes> 18186
younes> URL: http://www.lyx.org/trac/changeset/18186 Log: Fix
younes> interface problem in order to cleanly support "cursor position
younes> memory" in the preamb
> "Edwin" == Edwin Leuven <[EMAIL PROTECTED]> writes:
>> My favourite is 'a.'.
Edwin> the casing suggests the presence of a Frontend class somewhere.
Edwin> if the file contains functions used in the frontend but not
Edwin> related to a Frontend class then i think that d. makes most
Edwin>
Andre Poenitz schrieb:
_pimpl.[Ch] should be included in the respective .C files. Actually I
think there's none left...
There are still two *_pimpl left:
$ find . -name "*impl*"
./frontends/Alert_pimpl.h
./frontends/qt4/Alert_pimpl.C
Michael
On Wed, 25 Apr 2007, Bo Peng wrote:
I vote d.
You guys already won. see src/frontends/controllers/frontend_helpers.h/cpp.
:-)
I have also changed file extension for controllers/*.C, and that will be
all for today. I need to leave some time for you guys to check if
everything is still
>> d. frontend_helper
>>
>> I vote d.
>
> I vote a, as I have said.
I vote d.
You guys already won. see src/frontends/controllers/frontend_helpers.h/cpp. :-)
I have also changed file extension for controllers/*.C, and that will
be all for today. I need to leav
On Wed, 25 Apr 2007, Bo Peng wrote:
Did you see my small script for checking that?
Not yet. Did you find anything wrong in insets, graphics and mathed?
Bo> a. FrontendHelper
b. frontendHelper
c. Frontend_helper
d. frontend_helper
I vote d.
I vote a, as I have said.
On Wed, Apr 25, 2007 at 05:58:19PM +0200, Jean-Marc Lasgouttes wrote:
> > "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>
> >> pegase: ../checknames.sh graphics/*.h insets/*.h
> >> graphics/GraphicsCache.h is bad graphics/GraphicsCacheItem.h is bad
> >> graphics/GraphicsConverter.h is bad graphi
On Wed, Apr 25, 2007 at 10:20:55AM -0500, Bo Peng wrote:
> >My rules are more or less:
> >
> >it should be Foo.h/Foo.cpp.
> >it should be named Foo.h/Foo.cpp.
> >it should be named Foo.h/Foo.cpp.
> >
> >Name clashes should be avoided.
>
> There is a problem with your approach, as in the case of sr
Andre Poenitz wrote:
On Wed, Apr 25, 2007 at 10:07:56AM -0500, Bo Peng wrote:
PS. I like to be consistent in the naming, but what are the guidelines?
Guideline1: classname = filename. Because classnames are in
uppercase, files are also named in this way. src/insets/*,
src/mathed/* and src/grap
On Wed, Apr 25, 2007 at 10:07:56AM -0500, Bo Peng wrote:
> >PS. I like to be consistent in the naming, but what are the guidelines?
>
> Guideline1: classname = filename. Because classnames are in
> uppercase, files are also named in this way. src/insets/*,
> src/mathed/* and src/graphics/* follow
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> pegase: ../checknames.sh graphics/*.h insets/*.h
>> graphics/GraphicsCache.h is bad graphics/GraphicsCacheItem.h is bad
>> graphics/GraphicsConverter.h is bad graphics/GraphicsImage.h is bad
>> graphics/GraphicsLoader.h is bad graphics/GraphicsP
pegase: ../checknames.sh graphics/*.h insets/*.h
graphics/GraphicsCache.h is bad
graphics/GraphicsCacheItem.h is bad
graphics/GraphicsConverter.h is bad
graphics/GraphicsImage.h is bad
graphics/GraphicsLoader.h is bad
graphics/GraphicsParams.h is bad
insets/ExternalTemplate.h is bad
insets/Externa
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> Did you see my small script for checking that?
Bo> Not yet. Did you find anything wrong in insets, graphics and
Bo> mathed?
pegase: ../checknames.sh graphics/*.h insets/*.h
graphics/GraphicsCache.h is bad
graphics/GraphicsCacheItem.h is bad
gra
My rules are more or less:
it should be Foo.h/Foo.cpp.
it should be named Foo.h/Foo.cpp.
it should be named Foo.h/Foo.cpp.
Name clashes should be avoided.
There is a problem with your approach, as in the case of src/box and
src/frontends/qt4/box. I am not offended by QBox, although I dislike
Q
On Wed, Apr 25, 2007 at 01:43:06PM +0200, [EMAIL PROTECTED] wrote:
> On Wed, 25 Apr 2007, Abdelrazak Younes wrote:
>
> >Jean-Marc Lasgouttes wrote:
> >>> > > > > "christian" == christian ridderstrom
> >>> > > > > <[EMAIL PROTECTED]>
> >>> > > > > writes:
> >>
> >>> > > Actually, I propose to
Did you see my small script for checking that?
Not yet. Did you find anything wrong in insets, graphics and mathed?
Bo> a. FrontendHelper b. frontendHelper c. Frontend_helper d.
Bo> frontend_helper
I vote d.
I vote a, as I have said.
Bo
> "Bo" == Bo Peng <[EMAIL PROTECTED]> writes:
>> PS. I like to be consistent in the naming, but what are the
>> guidelines?
Bo> Guideline1: classname = filename. Because classnames are in
Bo> uppercase, files are also named in this way. src/insets/*,
Bo> src/mathed/* and src/graphics/* follow
PS. I like to be consistent in the naming, but what are the guidelines?
Guideline1: classname = filename. Because classnames are in
uppercase, files are also named in this way. src/insets/*,
src/mathed/* and src/graphics/* follow this guideline well so these
are what I have renamed so far.
Gui
On Wed, 25 Apr 2007, Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
> > > > > "christian" == christian ridderstrom
> > > > > <[EMAIL PROTECTED]>
> > > > > writes:
> > > Actually, I propose to merge all these files to FrontendHelpers.
christian> I probably missed it in the thread,
Jean-Marc Lasgouttes wrote:
"christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:
Actually, I propose to merge all these files to FrontendHelpers.
christian> I probably missed it in the thread, but I thought
christian> UpperCase.cpp was intended for a file that defined the
christi
> "christian" == christian ridderstrom <[EMAIL PROTECTED]> writes:
>>> Actually, I propose to merge all these files to FrontendHelpers.
christian> I probably missed it in the thread, but I thought
christian> UpperCase.cpp was intended for a file that defined the
christian> class UpperCase?
I
On Wed, 25 Apr 2007, Andre Poenitz wrote:
On Tue, Apr 24, 2007 at 11:03:43PM -0500, Bo Peng wrote:
Only five files do not follow the new conventions.
biblio.C
tex_helpers.C
frnt_lang.C
helper_funcs.C
character.C
How about:
BiblioHelpers.cpp (the old name? I see BIBLIOHELPERS_H defined)
TexHe
On Tue, Apr 24, 2007 at 11:03:43PM -0500, Bo Peng wrote:
> Only five files do not follow the new conventions.
>
> biblio.C
> tex_helpers.C
> frnt_lang.C
> helper_funcs.C
> character.C
>
> How about:
>
> BiblioHelpers.cpp (the old name? I see BIBLIOHELPERS_H defined)
> TexHelpers.cpp
> LangHelper
Only five files do not follow the new conventions.
biblio.C
tex_helpers.C
frnt_lang.C
helper_funcs.C
character.C
How about:
BiblioHelpers.cpp (the old name? I see BIBLIOHELPERS_H defined)
TexHelpers.cpp
LangHelpers.cpp
FrontendHelpers.cpp
CharacterHelpers.cpp (the old name?)
Actually, I propos
On Sunday 25 March 2007 2:38:17 am Abdelrazak Younes wrote:
> Last time I do that, promise.
OK.
> Abdel.
--
José Abílio
your approval here because I won't have
much time in the next days and I am sure this commit is a clear
improvement over what we had...
Last time I do that, promise.
Abdel.
Modified:
lyx-devel/trunk/src/frontends/controllers/ControlCitation.C
lyx-devel/trunk/src/frontends/c
Lars Gullik Bjønnes wrote:
> The include here... is it inside "namespace lyx"?
No.
> If so it should be moved outside.
Of course.
Georg
[EMAIL PROTECTED] writes:
| Author: baum
| Date: Thu Mar 1 17:35:26 2007
| New Revision: 17391
|
| URL: http://www.lyx.org/trac/changeset/17391
| Log:
| remove unneeded namespace
|
| Modified:
| lyx-devel/trunk/src/frontends/controllers/ControlPrefs.C
|
| Modified: lyx-devel/trunk/src
:
* frontends/controllers/ControlChanges.C:
* frontends/controllers/ControlChanges.h: fix merge-changes dialog;
remove old cruft; strip interface down to what is really needed
Modified:
lyx-devel/trunk/src/frontends/controllers/ControlChanges.C
lyx-devel/trunk/src/frontends
[EMAIL PROTECTED] wrote:
Author: baum
Date: Fri Jan 5 15:38:53 2007
New Revision: 16533
URL: http://www.lyx.org/trac/changeset/16533
Log:
Abdel, get yourself a decent file system!
Oups, sorry! :-(
Abdel.
Georg Baum wrote:
Am Sonntag, 8. Oktober 2006 12:32 schrieb [EMAIL PROTECTED]:
Author: younes
Date: Sun Oct 8 12:32:33 2006
New Revision: 15279
URL: http://www.lyx.org/trac/changeset/15279
Log:
* ControlChanges:
- getChangeAuthor() and getChangeDate(): converted to unicode.
And a bit more:
Am Sonntag, 8. Oktober 2006 12:32 schrieb [EMAIL PROTECTED]:
> Author: younes
> Date: Sun Oct 8 12:32:33 2006
> New Revision: 15279
>
> URL: http://www.lyx.org/trac/changeset/15279
> Log:
> * ControlChanges:
> - getChangeAuthor() and getChangeDate(): converted to unicode.
And a bit more:
../
[EMAIL PROTECTED] a écrit :
Author: vermeer
Date: Fri Apr 28 09:45:37 2006
New Revision: 13773
Log:
Brown paper bag for r13772
I was about to humiliate you in public :-)
Abdel.
Modified:
lyx-devel/trunk/src/frontends/controllers/ControlToc.h
On Thu, Mar 06, 2003 at 06:41:11PM +0100, Lars Gullik Bj?nnes wrote:
> | > But works with the xforms frontend you say, so that suggests
> | > something relatively trivial.
Seems it was a bad compile after all that .Sorrty for the noise
john
John Levon <[EMAIL PROTECTED]> writes:
| On Thu, Mar 06, 2003 at 04:59:08PM +, Angus Leeming wrote:
|
| > But works with the xforms frontend you say, so that suggests
| > something relatively trivial.
|
| Hmm.
|
| Can you really iterate along a C array with std::find_if ?
Sure, why not?
On Thu, Mar 06, 2003 at 04:59:08PM +, Angus Leeming wrote:
> But works with the xforms frontend you say, so that suggests
> something relatively trivial.
Hmm.
Can you really iterate along a C array with std::find_if ?
john
Alfredo Braunstein wrote:
> No insert->external in my menu. Moreover, on lyx startup the following
> shows up:
>
> MenuItem(): LyX command `buffer-child-insert' does not exist.
> MenuItem(): LyX command `external-insert' does not exist.
>
> Alfredo
Forget what I've said (forgot to cvs update l
On Thu, Mar 06, 2003 at 05:08:24PM +, Angus Leeming wrote:
> Maybe I forgot to commit lib/ui/default.ui
Well you didn't forget, unless I mysteriously acquired the file from you
somehow
john
Alfredo Braunstein wrote:
> Angus Leeming wrote:
>
>>
>> Well, I've just checked out cvs head here. It looks Ok to a quick
>> glance... Can anybody out there with current cvs open the External
>> dialog from the menu? Either frontend...
>>
>
> No insert->external in my menu. Moreover, on lyx s
John Levon wrote:
> On Thu, Mar 06, 2003 at 04:36:43PM +, Angus Leeming wrote:
>
>> Strange. They did for me last night. Indded, I wouldn't have found
>> that QExternal buglet with the Apply button otherwise.
>>
>> How about
>> dialog-show-new-inset citation
>
> Works.
>
> Fails wi
Angus Leeming wrote:
>
> Well, I've just checked out cvs head here. It looks Ok to a quick
> glance... Can anybody out there with current cvs open the External
> dialog from the menu? Either frontend...
>
No insert->external in my menu. Moreover, on lyx startup the following shows
up:
MenuItem
On Thu, Mar 06, 2003 at 04:36:43PM +, Angus Leeming wrote:
> Strange. They did for me last night. Indded, I wouldn't have found
> that QExternal buglet with the Apply button otherwise.
>
> How about
> dialog-show-new-inset citation
Works.
Fails with external and include.
regards
j
John Levon wrote:
> On Thu, Mar 06, 2003 at 04:15:40PM +, Angus Leeming wrote:
>
>> Hmmm. Is there an "external" in the c-string array in
>> frontends/qt2/Dialogs3.C?
>
> There is. I don't think any of the new ones work.
>
>> Perhaps you'd try the xforms frontend too?
>
> Works fine.
>
>>
Angus Leeming wrote:
> John Levon wrote:
>
>> On Thu, Mar 06, 2003 at 03:57:04PM +, Angus Leeming wrote:
>>
>>> > What do I have to do to make e.g. external dialog menu entry do
>>> > something now ?
>>>
>>> Sorry I don't follow you. If you mean "selecting the External menu
>>> entry should
On Thu, Mar 06, 2003 at 04:15:40PM +, Angus Leeming wrote:
> Hmmm. Is there an "external" in the c-string array in
> frontends/qt2/Dialogs3.C?
There is. I don't think any of the new ones work.
> Perhaps you'd try the xforms frontend too?
Works fine.
> Sorry that I'm not more helpful but m
John Levon wrote:
> On Thu, Mar 06, 2003 at 03:57:04PM +, Angus Leeming wrote:
>
>> > What do I have to do to make e.g. external dialog menu entry do
>> > something now ?
>>
>> Sorry I don't follow you. If you mean "selecting the External menu
>> entry should pop up the external dialog", the
On Thu, Mar 06, 2003 at 03:57:04PM +, Angus Leeming wrote:
> > What do I have to do to make e.g. external dialog menu entry do
> > something now ?
>
> Sorry I don't follow you. If you mean "selecting the External menu
> entry should pop up the external dialog", then you need an entry in
> d
John Levon wrote:
>
> What do I have to do to make e.g. external dialog menu entry do
> something now ?
Sorry I don't follow you. If you mean "selecting the External menu
entry should pop up the external dialog", then you need an entry in
defualt.ui that has "dialog-show-new-inset external". S
What do I have to do to make e.g. external dialog menu entry do
something now ?
john
files:
> lyx-devel/src/frontends/controllers/: ChangeLog ControlFloat.h
> ControlFloat.C
> lyx-devel/src/frontends/qt2/: QFloat.C
> lyx-devel/src/frontends/xforms/: FormFloat.C FormFloat.h
>
> Log message:
> Move
; lyx-devel/src/frontends/controllers/: ChangeLog ControlFloat.C
> ControlFloat.h
> lyx-devel/src/frontends/qt2/: ChangeLog QFloat.C
> lyx-devel/src/insets/: ChangeLog insetfloat.C insetfloat.h
>
> Log message:
> M
On Tue, Feb 25, 2003 at 08:11:02PM +, [EMAIL PROTECTED] wrote:
>
> http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/frontends/controllers/ChangeLog?r1=1.273&r2=1.273.2.1
>
> http://www.lyx.org/cgi-bin/viewcvs.cgi/lyx-devel/src/frontends/controllers/ControlDocument.C?r
On Tue, Feb 25, 2003 at 01:56:58PM +, Angus Leeming wrote:
> ControlButtons.[Ch] ControlConnections.[Ch] ControlDialog.h
> ControlDialog_impl.[Ch] ControlDialog.tmpl ControlInset.h ControlInset.tmpl
> GUI.h ViewBase.h
Cool !
> I would love to. But several of them have subtle differences. I
On Tue, Feb 25, 2003 at 01:56:58PM +, Angus Leeming wrote:
> Shall I just commit it and let people try it out. What's the consensus on
> this?
Commit.
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 Tuesday 25 February 2003 1:39 pm, John Levon wrote:
> On Fri, Feb 21, 2003 at 04:56:55PM +, Angus Leeming wrote:
> > until that is done. However, the attached patch is the Brave New World of
> > controllers and I'd value your considered perusal.
>
> Hrm, it'
On Fri, Feb 21, 2003 at 04:56:55PM +, Angus Leeming wrote:
> until that is done. However, the attached patch is the Brave New World of
> controllers and I'd value your considered perusal.
Hrm, it's not very Linus friendly is it :
95 files changed, 2471 insertions(+), 881
1 - 100 of 143 matches
Mail list logo
