Hi Tommaso,
No, we don't have one yet. Uptil now it is all manual labor.
However, I happen to have installed a git repo on my own server now, to
which I will gradually add more functionality.
Vincent
Op 3-10-2011 23:02, Tommaso Cucinotta schreef:
Hi Vincent,
do we have currently any git
Hi Tommaso,
No, we don't have one yet. Uptil now it is all manual labor.
However, I happen to have installed a git repo on my own server now, to
which I will gradually add more functionality.
Vincent
Op 3-10-2011 23:02, Tommaso Cucinotta schreef:
Hi Vincent,
do we have currently any git
IIRC, you had to be subscribed to the lyx-cvs-list in order for
the commit messages to be sent. So, I'd restrict the senders to
only those that are subscribed to the list.
That's how I set it up for now.
- The problem is that lyx-cvs is not working anymore. I guess its
because elzm
I agree with killing boost, but we should do it cleanly. We could
start with the headers as Peter suggested and use tr1 for everybody.
Then if there are problems, we'll add exceptions for some computers.
Or we can do autoconf/cmake tests on the features.
fine with me if this will happen
IIRC, you had to be subscribed to the lyx-cvs-list in order for
the commit messages to be sent. So, I'd restrict the senders to
only those that are subscribed to the list.
That's how I set it up for now.
- The problem is that lyx-cvs is not working anymore. I guess its
Did you subscribe to the lyx-cvs list with your lyx.org address ?
Apparently you did as the mailing list announcement message came
through.
Vincent
This link works for me:
http://www.ecp.fr/
So ftp.lyx.org should also be online again the next hours.
It works again now.
Vincent
>> >> IIRC, you had to be subscribed to the lyx-cvs-list in order for
>> >> the commit messages to be sent. So, I'd restrict the senders to
>> >> only those that are subscribed to the list.
>>
>> That's how I set it up for now.
>
> - The problem is that lyx-cvs is not working anymore. I guess
>> I agree with killing boost, but we should do it cleanly. We could
>> start with the headers as Peter suggested and use tr1 for everybody.
>> Then if there are problems, we'll add exceptions for some computers.
>> Or we can do autoconf/cmake tests on the features.
>
>fine with me if this will
>>
>> >> >> IIRC, you had to be subscribed to the lyx-cvs-list in order for
>> >> >> the commit messages to be sent. So, I'd restrict the senders to
>> >> >> only those that are subscribed to the list.
>> >>
>> >> That's how I set it up for now.
>> >
>> > - The problem is that lyx-cvs is not
>Did you subscribe to the lyx-cvs list with your lyx.org address ?
>
Apparently you did as the mailing list announcement message came
through.
Vincent
>This link works for me:
>http://www.ecp.fr/
>
>So ftp.lyx.org should also be online again the next hours.
>
It works again now.
Vincent
This introduces a new LFUN LFUN_INSET_COPY_AS, which copies a certain
Inset to the clipboard. For InsetInfo this is the text that is
visible, but this could also replace LFUN_LABEL_COPY_AS_REF, by
copying the INSET to the clipboard as a reference, and also a Math
inset to copy to the
The problem was that I never expected that InsetInfo is a child class
of InsetCollapsable. This feels wrong.
We need something between InsetText and InsetCollapsable
or we migrate the inset decoration to InsetText. Then
InsetCollapsable would just add tha ability to collapse.
Note that the
The problem was that I never expected that InsetInfo is a child
class
of InsetCollapsable. This feels wrong.
We need something between InsetText and InsetCollapsable or we
migrate the inset decoration to InsetText. Then InsetCollapsable
would just add tha ability
The problem was that I never expected that InsetInfo
is a child class of InsetCollapsable. This feels wrong.
We need something between InsetText and InsetCollapsable
or we migrate the inset decoration to InsetText. Then
InsetCollapsable would just add tha ability to collapse.
Note that
Don't know if it helps, but that's where I'd start.
The thing that helps is to call
disp_.setMessage(docstring());
at the beginning of Cursor::dispatch().
However, this would break messaging in case of nested dispatch calls.
This would mean you'd have to clear the message from BufferView
>> This introduces a new LFUN LFUN_INSET_COPY_AS, which copies a certain
>> Inset to the clipboard. For InsetInfo this is the text that is
>> visible, but this could also replace LFUN_LABEL_COPY_AS_REF, by
>> copying the INSET to the clipboard as a reference, and also a Math
>> inset to copy
>> The problem was that I never expected that InsetInfo is a child class
>> of InsetCollapsable. This feels wrong.
>
>We need something between InsetText and InsetCollapsable
>or we migrate the inset decoration to InsetText. Then
>InsetCollapsable would just add tha ability to collapse.
>
>Note
>>> The problem was that I never expected that InsetInfo is a child
>>> class
>>>
>
>>> of InsetCollapsable. This feels wrong.
>>>
>> We need something between InsetText and InsetCollapsable or we
>> migrate the inset decoration to InsetText. Then InsetCollapsable
>> would
>> The problem was that I never expected that InsetInfo
>> is a child class of InsetCollapsable. This feels wrong.
>
> We need something between InsetText and InsetCollapsable
> or we migrate the inset decoration to InsetText. Then
> InsetCollapsable would just add tha
>Don't know if it helps, but that's where I'd start.
The thing that helps is to call
disp_.setMessage(docstring());
at the beginning of Cursor::dispatch().
However, this would break messaging in case of nested dispatch calls.
This would mean you'd have to clear the message from BufferView
One less copy than returning a DispatchResult const ?
I think we think the same.. ;)
No, I am wondering why it has to be const.
Because there is no reason to make it non-const. I can't think of a
reason to allow code from outside the Cursor class to change the result
of the Cursor
Author: uwestoehr
Date: Fri Apr 16 11:08:33 2010
New Revision: 34151
URL: http://www.lyx.org/trac/changeset/34151
Log:
PrefOutputUi.ui, LyX-Mac-binary-release.sh: add once more
missing SVN EOL style (why is it so complicated to think
aout this when adding new files to SVN?)
What happens if this
Modified: lyx-devel/trunk/src/frontends/qt4/GuiView.cpp
==
--- lyx-devel/trunk/src/frontends/qt4/GuiView.cpp Fri Apr 16
12:51:20 2010 (r34160)
+++ lyx-devel/trunk/src/frontends/qt4/GuiView.cpp Fri Apr 16
>> One less copy than returning a "DispatchResult const &" ?
>>
>> I think we think the same.. ;)
>
>No, I am wondering why it has to be const.
>
Because there is no reason to make it non-const. I can't think of a
reason to allow code from outside the Cursor class to change the result
of the
>Author: uwestoehr
>Date: Fri Apr 16 11:08:33 2010
>New Revision: 34151
>URL: http://www.lyx.org/trac/changeset/34151
>
>Log:
>PrefOutputUi.ui, LyX-Mac-binary-release.sh: add once more
>missing SVN EOL style (why is it so complicated to think
>aout this when adding new files to SVN?)
What happens
> Modified: lyx-devel/trunk/src/frontends/qt4/GuiView.cpp
>
==
> --- lyx-devel/trunk/src/frontends/qt4/GuiView.cpp Fri Apr 16
12:51:20 2010 (r34160)
> +++ lyx-devel/trunk/src/frontends/qt4/GuiView.cpp Fri Apr
The user get's a message box with a warning that he might not
generate
any output. (or do you mean something else ?).
You did throw it in one of the three cases in the function.
Vincent
I still don't get any warning (neither in a box or
on the console). What's up? Bug still present as
Author: lasgouttes
Date: Fri Nov 13 15:32:51 2009
New Revision: 31969
URL: http://www.lyx.org/trac/changeset/31969
+ // Is this a function that acts on inset at point?
+ if (lyxaction.funcHasFlag(cmd.action, LyXAction::AtPoint)
+ nextInset()) {
+
>> The user get's a message box with a warning that he might not
generate
>> any output. (or do you mean something else ?).
>>
>> You did throw it in one of the three cases in the function.
>>
>> Vincent
>>
>
>I still don't get any warning (neither in a box or
>on the console). What's up? Bug
>Author: lasgouttes
>Date: Fri Nov 13 15:32:51 2009
>New Revision: 31969
>URL: http://www.lyx.org/trac/changeset/31969
>
>+ // Is this a function that acts on inset at point?
>+ if (lyxaction.funcHasFlag(cmd.action, LyXAction::AtPoint)
>+ && nextInset()) {
>+
Author: vfr
Date: Wed Apr 14 13:54:12 2010
New Revision: 34130
URL: http://www.lyx.org/trac/changeset/34130
Log:
Fix bug #6651: No error messages when module dependencies are not
fulfilled.
We need to throw the ExceptionMessage's.
Can you tell me what happens when this exception
Can you tell me what happens when this exception gets thrown? (I
have
no idea why I didn't throw it.)
The user get's a message box with a warning that he might not
generate
any output. (or do you mean something else ?).
OK. I'll check this later. I'm guessing that maybe the
>> Author: vfr
>> Date: Wed Apr 14 13:54:12 2010
>> New Revision: 34130
>> URL: http://www.lyx.org/trac/changeset/34130
>>
>> Log:
>> Fix bug #6651: No error messages when module dependencies are not
fulfilled.
>>
>> We need to throw the ExceptionMessage's.
>>
>>
>Can you tell me what happens
>>> Can you tell me what happens when this exception gets thrown? (I
have
>>> no idea why I didn't throw it.)
>>>
>> The user get's a message box with a warning that he might not
generate
>> any output. (or do you mean something else ?).
>>
>>
>OK. I'll check this later. I'm guessing
- : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0),
+ : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0),
y_(0),
What's the rationale about initializing a docstring with 0 ? (Does it
even compile ?)
Vincent
ehh, i thought from the one without argument, no?
FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION,
o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39
Please read further:
#11 0x081a00c8 in static_initialization_and_destruction_0 ()
at FuncRequest?.cpp:28
This is your 0
>- : action_(LFUN_NOACTION), origin_(o), x_(0), y_(0),
>+ : argument_(0), action_(LFUN_NOACTION), origin_(o), x_(0),
y_(0),
>
What's the rationale about initializing a docstring with 0 ? (Does it
even compile ?)
Vincent
>ehh, i thought from the one without argument, no?
>
>FuncRequest? (this=0x8c0111c, act=lyx::LFUN_UNKNOWN_ACTION,
>o=lyx::FuncRequest::INTERNAL) at FuncRequest?.cpp:39
Please read further:
#11 0x081a00c8 in static_initialization_and_destruction_0 ()
at FuncRequest?.cpp:28
This is your 0
For me, requiring this means that I can no longer compile on Linux as
I don't have the appropriate rights there to update automake.
You can still use cmake, aren't you?
Abdel.
Yes.
Vincent
>>
>> For me, requiring this means that I can no longer compile on Linux as
>> I don't have the appropriate rights there to update automake.
>>
>
>You can still use cmake, aren't you?
>
>Abdel.
>
Yes.
Vincent
Well, on my Duron 700 with 512 MB, it took several
hours (and finally crashed).
I guess the memory is the big problem here. I upgraded my machine from
512 MB to 2 GB and compilation times were severely reduced.
Vincent
no i see in unpatched sources :
New in 1.10.1:
- make dist can now create lzma-compressed tarballs.
so my proposal is lo use lzma from dependency and compression ratio
reasons.
OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate
releases. So you should require 1.10.1.
Did you run autogen.sh first?
BH
Actually, autogen is throwing an error/warning:
Using automake (GNU automake) 1.9
Using autoconf (GNU Autoconf) 2.64
Building macros...
Building config header template...
Building Makefile templates...
configure.ac:29: option `dist-lzma' not recognized
>Well, on my Duron 700 with 512 MB, it took several
>hours (and finally crashed).
I guess the memory is the big problem here. I upgraded my machine from
512 MB to 2 GB and compilation times were severely reduced.
Vincent
>> no i see in unpatched sources :
>> New in 1.10.1:
>> - "make dist" can now create lzma-compressed tarballs.
>>
>> so my proposal is lo use lzma from dependency and compression ratio
>> reasons.
>
>OK, the NEWS file for 1.11 does not contain the 1.10.x intermediate
>releases. So you should
>> Did you run autogen.sh first?
>>
>> BH
>
>Actually, autogen is throwing an error/warning:
>
>Using automake (GNU automake) 1.9
>Using autoconf (GNU Autoconf) 2.64
>Building macros...
>Building config header template...
>Building Makefile templates...
>configure.ac:29: option `dist-lzma' not
i understand the problem but this is really ugly. we must find
another way.
either shortcuting a-la 'Greyedout color' and the rest in tooltip
or use something else then label.
Why is having a label over 2 lines ugly? Qt supports this and
also many other applications have this. Moreover the
Log:
Move command line arg --batch to -batch.
Things are still bit inconsistent due to the existence of additional --
switches, but the correct fix is not so easy.
Aren't you now destroying the backward compatibility for all the scripts
that people might have made ?
Isn't it the 'normal' way of
>> i understand the problem but this is really ugly. we must find
another way.
>> either shortcuting a-la 'Greyedout color' and the rest in tooltip
>> or use something else then label.
>
>Why is having a label over 2 lines ugly? Qt supports this and
>also many other applications have this.
>Log:
>Move command line arg --batch to -batch.
>Things are still bit inconsistent due to the existence of additional --
switches, but the correct fix is not so easy.
>
Aren't you now destroying the backward compatibility for all the scripts
that people might have made ?
Isn't it the 'normal'
Moreover, it would be nice if one can set the GNUWIN32_DIR variable
within the user interface of Cmake. This is now not possible. Only the
GNUWIN32_DIR_tmp variable is visible in the gui.
I've committed a patch. Should work now.
Thanks.
Next chance for improvement: The iconv.dll is not
I'm seeing some weird trunk behavior today, as shown here:
http://bobjweil.com/sales/lyx.png
Did you update my last fix for the mistake I made ?
Vincent
>> Moreover, it would be nice if one can set the GNUWIN32_DIR variable
>> within the user interface of Cmake. This is now not possible. Only the
>> GNUWIN32_DIR_tmp variable is visible in the gui.
>
>I've committed a patch. Should work now.
>
Thanks.
Next chance for improvement: The iconv.dll
>I'm seeing some weird trunk behavior today, as shown here:
> http://bobjweil.com/sales/lyx.png
Did you update my last fix for the mistake I made ?
Vincent
I have download alpha 1, configure, compile and install without problem.
But when I run it get:
lyx-2.0.0.a1: symbol lookup error: lyx-2.0.0.a1: undefined
symbol: _ZN11QVectorData4freeEPS_i
I have debian lenny with g++ 4.3.2, qt 4.6.2.
Regards
Usually, you use a different run-time version
-Building Visual C++ 2005 project files
+Building Visual C++ project files
--
-* install Visual C++ 2005
-* install Platform SDK 2005, Core and Web Workshop
+* install Visual C++ 2008
+* install Platform SDK 2008, Core and Web Workshop
This seems like a sensible request. Anyone know off-hand where we set
this?
ConverterCache::init() ?
// We do this here and not in the constructor because package() gets
// initialized after all static variables.
cache_dir = FileName(addName(package().user_support().absFilename(),
cache));
Richard,
Could you please add an extension to the patches you send, .patch or
.diff or .txt.
Then, I can open the attachment without difficulties and/or annoying
extra mouseclicks.
Vincent
Author: rgheck
Date: Fri Mar 26 17:59:08 2010
New Revision: 33875
URL: http://www.lyx.org/trac/changeset/33875
Log:
Backport fix for #6454. The real cause may be elsewhere, but
this does fix the crash and is a worthwhile sanity check in
any event.
Status.16x ?
Vincent
Author: rgheck
Date: Fri Mar 26 17:54:24 2010
New Revision: 33874
URL: http://www.lyx.org/trac/changeset/33874
Log:
Backport fix for #6522.
Status.16x ?
Vincent
> I have download alpha 1, configure, compile and install without problem.
> But when I run it get:
>
>lyx-2.0.0.a1: symbol lookup error: lyx-2.0.0.a1: undefined
>symbol: _ZN11QVectorData4freeEPS_i
>
> I have debian lenny with g++ 4.3.2, qt 4.6.2.
>
>Regards
Usually, you use a different run-time
>> -Building Visual C++ 2005 project files
>> +Building Visual C++ project files
>> --
>>
>> -* install Visual C++ 2005
>> -* install Platform SDK 2005, "Core" and "Web Workshop"
>> +* install Visual C++ 2008
>> +* install Platform SDK 2008,
>
>This seems like a sensible request. Anyone know off-hand where we set
this?
>
ConverterCache::init() ?
// We do this here and not in the constructor because package() gets
// initialized after all static variables.
cache_dir = FileName(addName(package().user_support().absFilename(),
Richard,
Could you please add an extension to the patches you send, .patch or
.diff or .txt.
Then, I can open the attachment without difficulties and/or annoying
extra mouseclicks.
Vincent
>Author: rgheck
>Date: Fri Mar 26 17:59:08 2010
>New Revision: 33875
>URL: http://www.lyx.org/trac/changeset/33875
>
>Log:
>Backport fix for #6454. The real cause may be elsewhere, but
>this does fix the crash and is a worthwhile sanity check in
>any event.
Status.16x ?
Vincent
>Author: rgheck
>Date: Fri Mar 26 17:54:24 2010
>New Revision: 33874
>URL: http://www.lyx.org/trac/changeset/33874
>
>Log:
>Backport fix for #6522.
Status.16x ?
Vincent
last call for 2.0 feature requests we have reported.
i'm going to cleanup bugzilla from enhacenments we wont offer in 2.0. i
have listed those which are not clear and we have to decide which action
should we take on each of the requests.
a) do it for 2.0
b) postpone for 2.1 in case you want to
I compiled with -Dmerge=1 as suggested in the
Install.CMake file and also the build.bat
file in the cmake folder in trunk.
This is not really practical to use when developing. Every change will
then trigger a full rebuild. Moreover, clicking a compile error won't
bring you to the original source
- To run the reconfigure script on Windows, we need a python version
with the logging module included. This is not yet the case for the
python.exe/dll we ship with LyX1.6.x.
Joost, Uwe, are you able to provide a new python version ?
- I really am frustrated that configure script makes MikTeX
Author: vfr
Date: Thu Mar 25 19:03:49 2010
New Revision: 33868
URL: http://www.lyx.org/trac/changeset/33868
Log:
Prevent the ghost index files when the converter cache is either not
used or not initialized.
Modified:
lyx-devel/trunk/src/ConverterCache.cpp
Modified:
if you do, then i have no problems.
OK, then the problem is in LyX's metrics calculation (and not in Qt's).
Of course it is.
ParagraphMetrics::singleWidth has to call Paragraph::transformChar for arabic
characters. This is however not done if the language is not marked arabic. And,
well,
Would it not be better to have one searchreplace dialog and a
button to toggle between simple mode and advanced mode.
The simple search will be a toolbar if it's up to me.
Today the advanced mode pane design is different than the simple one in
term of place of the find button, replace button,
last call for 2.0 feature requests we have reported.
i'm going to cleanup bugzilla from enhacenments we wont offer in 2.0. i
have listed those which are not clear and we have to decide which action
should we take on each of the requests.
a) do it for 2.0
b) postpone for 2.1 in case you want to
>I compiled with "-Dmerge=1" as suggested in the
>"Install.CMake" file and also the "build.bat"
>file in the "cmake" folder in trunk.
>
This is not really practical to use when developing. Every change will
then trigger a full rebuild. Moreover, clicking a compile error won't
bring you to the
- To run the reconfigure script on Windows, we need a python version
with the logging module included. This is not yet the case for the
python.exe/dll we ship with LyX1.6.x.
Joost, Uwe, are you able to provide a new python version ?
- I really am frustrated that configure script makes MikTeX
Author: vfr
Date: Thu Mar 25 19:03:49 2010
New Revision: 33868
URL: http://www.lyx.org/trac/changeset/33868
Log:
Prevent the ghost index files when the converter cache is either not
used or not initialized.
Modified:
lyx-devel/trunk/src/ConverterCache.cpp
Modified:
>> if you do, then i have no problems.
>
>OK, then the problem is in LyX's metrics calculation (and not in Qt's).
>
Of course it is.
ParagraphMetrics::singleWidth has to call Paragraph::transformChar for arabic
characters. This is however not done if the language is not marked arabic. And,
>Would it not be better to have one search dialog and a
>button to toggle between simple mode and advanced mode.
The simple search will be a toolbar if it's up to me.
>Today the advanced mode pane design is different than the simple one in
>term of place of the find button, replace button,
Do you see this problem also with other insets (such as Box or
Float)? If so, it might be a problem of metrics calculation.
Yes, i do. the language of the user interface is not the case english
or arabic, the problem appears when writing in arabic,some spaces are
added with each of
>> > Do you see this problem also with other insets (such as "Box" or
>> > "Float")? If so, it might be a problem of metrics calculation.
>>
>> Yes, i do. the language of the user interface is not the case "english
>> or arabic", the problem appears when writing in arabic,some spaces are
>>
Investigation of #6454 revealed that we are blinking the cursor even
when it is off screen, causing recalculations of paragraph metrics,
which may have weird side effects---such as #6454. Can someone please
stop the cursor from blinking when it isn't on the screen? At least
most of the
>>
>> Investigation of #6454 revealed that we are blinking the cursor even
>> when it is off screen, causing recalculations of paragraph metrics,
>> which may have weird side effects---such as #6454. Can someone please
>> stop the cursor from blinking when it isn't on the screen? At least
>>
Yes, that's right. So does the attached make sense? It seems
to solve it for me, but I have no idea what it does to the RTL stuff.
The problems seems to be that we want to draw the cursor, even if it's
not visible. To compute the height and place of the cursor, we retrieve
what font the text has
I don't remember: is it correct that boundary only affect the cursor's
display?
No, probably not. If the cursor is displayed somewhere else, newly
entered text will appear somewhere else.
If so, and if we're correct that the metrics will not exist only when
the
cursor's paragraph is off the
Besides this code is truly horrific:
Why exactly is this horrific?
Because you store things in variables that are not used anywhere.
Constructions with the ? And : operators, without proper spacing and
then a conditional assignment at the end, which value is also assigned
to some magic
+
+ // if the metrics have not been calculated, then we are not
+ // on screen and can safely ignore issues about boundaries.
+ if (!contains(pit))
+ return false;
+
I don't like this. The function is called: isRTLBoundary(), so I expect
it to return whether the
>Yes, that's right. So does the attached make sense? It seems
>to solve it for me, but I have no idea what it does to the RTL stuff.
The problems seems to be that we want to draw the cursor, even if it's
not visible. To compute the height and place of the cursor, we retrieve
what font the text
>I don't remember: is it correct that boundary only affect the cursor's
display?
No, probably not. If the cursor is displayed somewhere else, newly
entered text will appear somewhere else.
>If so, and if we're correct that the metrics will not exist only when
the
>cursor's paragraph is off the
>> Besides this code is truly horrific:
>
>Why exactly is this horrific?
>
Because you store things in variables that are not used anywhere.
Constructions with the ? And : operators, without proper spacing and
then a conditional assignment at the end, which value is also assigned
to some magic
>+
>+ // if the metrics have not been calculated, then we are not
>+ // on screen and can safely ignore issues about boundaries.
>+ if (!contains(pit))
>+ return false;
>+
I don't like this. The function is called: isRTLBoundary(), so I expect
it to return whether the
gcc 4.4.3 is throwing a lot of warnings here:
Besides this code is truly horrific:
+ // store the height for every cell
+ // this is later needed in InsetTabular::draw to determine the
valignment
+ int const top_space_cell = tabular.row_info[r].top_space_default
?
+
>gcc 4.4.3 is throwing a lot of warnings here:
>
Besides this code is truly horrific:
+ // store the height for every cell
+ // this is later needed in InsetTabular::draw to determine the
valignment
+ int const top_space_cell = tabular.row_info[r].top_space_default
?
+
The frightening list of critical bugs shrunk thanks to the fearless
fighters (Vincent, Enrico, Richard et al.), and I think it's time to
let the users participate from that.
I have just stamped my OK on some open issues on trac. Apart
from that, I still see the following (critical) bugs:
#6055
>The frightening list of critical bugs shrunk thanks to the fearless
>fighters (Vincent, Enrico, Richard et al.), and I think it's time to
>let the users participate from that.
>
>I have just stamped my OK on some open issues on trac. Apart
>from that, I still see the following (critical) bugs:
>
The problem is that it doesn't compile because of an
unresolved external:
InsetTabular.obj : error LNK2019: unresolved external
symbol public: __thiscall lyx::MetricsInfo::MetricsInfo
(void) (??0metricsi...@lyx@@q...@xz) referenced in
function public: virtual void __thiscall lyx::
p.s. I still don't understand how exactly dim.asc is calculated.
Where in the code is this done?
Well. Have a look in the code then :S ?
Well, that's the point. I did this intensively several
times but the tabular code simply miss any comment. MSCV
comes with a beautiful search engine but
Well, that's the point. I did this intensively several times but the
tabular code simply miss any comment. MSCV comes with a beautiful
search engine but when it comes to search more than one file I have to
use a desktop search. But even this brings often no results.
Huh.. I can use
For some reason, it appears that there is no ErrorList in the main
buffer.
I've touched this today.. I hope I didn't break anything. If you wanna
be sure try to revert the changes I made.
Vincent
1 - 100 of 1326 matches
Mail list logo
