Am 09.12.2010 um 02:04 schrieb Enrico Forestieri:
> On Wed, Dec 08, 2010 at 11:52:10PM +0100, Stephan Witt wrote:
>>
>> I don't know if there are any drawbacks - it works!
>
> It may have drawbacks.
> For example, are you able to paste between different LyX instances?
No. If I copy in instance
hi
I tried to compile the new lyx2.0 beta2 with visual studio 2010 but i am
always getting errors, but in visual studio 2008 it work very nice
Is it there a path to make it work with visual studio 2010?
thx
On Wed, Dec 8, 2010 at 8:04 PM, Enrico Forestieri wrote:
> On Wed, Dec 08, 2010 at 11:52:10PM +0100, Stephan Witt wrote:
>>
>> I don't know if there are any drawbacks - it works!
>
> It may have drawbacks. For example, are you able to paste between
> different LyX instances?
I haven't been follow
Helge Hafting wrote:
> I hope this can be useful for LyX 2.0, spreadsheets are requested
> now and then on the user list.
its committed. please add item to newinlyx20 wiki pages. perhaps some
other wiki pages about excel import call for update as well.
thanks,
pavel
On Wed, Dec 08, 2010 at 11:52:10PM +0100, Stephan Witt wrote:
>
> I don't know if there are any drawbacks - it works!
It may have drawbacks. For example, are you able to paste between
different LyX instances?
--
Enrico
On 12/08/2010 05:21 PM, Peter Kuemmel wrote:
Original-Nachricht
Datum: Wed, 08 Dec 2010 16:05:39 -0500
Von: Richard Heck
An: LyX Developers
Betreff: Error List Worry Re Asynchronous Export
This code:
void GuiView::errors(string const& error_type, bool from_master)
{
Buf
Am 08.12.2010 um 23:36 schrieb Enrico Forestieri:
> On Wed, Dec 08, 2010 at 10:05:32PM +0100, Vincent van Ravesteijn wrote:
>> This has the clue!
>>
>> case LFUN_PASTE: {
>>
>> // without argument?
>> string const arg = to_utf8(cmd.argument());
>> if (
On Wed, Dec 08, 2010 at 10:05:32PM +0100, Vincent van Ravesteijn wrote:
> This has the clue!
>
> case LFUN_PASTE: {
>
> // without argument?
> string const arg = to_utf8(cmd.argument());
> if (arg.empty()) {
> if (theClipboard(
Original-Nachricht
> Datum: Wed, 08 Dec 2010 16:05:39 -0500
> Von: Richard Heck
> An: LyX Developers
> Betreff: Error List Worry Re Asynchronous Export
>
> This code:
>
> void GuiView::errors(string const & error_type, bool from_master)
> {
> BufferView const * const bv
Le 8 déc. 2010 à 19:09, Philippe Charpentier a écrit :
Hi,
> I update this morning the svn version of lyx, compile it and notice the
> following bug:
>
> using the class article(chess), the layout Mainline is not traduced to
> latex with the command mainline: the latex code produced with this
> la
On 12/08/2010 01:09 PM, Philippe Charpentier wrote:
Hi,
I update this morning the svn version of lyx, compile it and notice the
following bug:
using the class article(chess), the layout Mainline is not traduced to
latex with the command mainline: the latex code produced with this
layout is only:
Am 07.12.2010 um 19:53 schrieb Steve Litt:
> On Tuesday 07 December 2010 01:33:03 Stephan Witt wrote:
>> Am 07.12.2010 um 00:18 schrieb Richard Heck:
>>> On 12/06/2010 06:06 PM, Steve Litt wrote:
On Monday 06 December 2010 17:18:33 Paul Rubin wrote:
With what will they replace the
On Wed, Dec 8, 2010 at 10:25 PM, Vincent van Ravesteijn wrote:
>> According to the Qt documentation:
>>
>> Windows and Mac OS X does not have the concept of ownership; the
>> clipboard is a fully global resource so all applications are notified
>> of changes.
>>
>> http://doc.trolltech.com/stable/
> According to the Qt documentation:
>
> Windows and Mac OS X does not have the concept of ownership; the
> clipboard is a fully global resource so all applications are notified
> of changes.
>
> http://doc.trolltech.com/stable/qclipboard.html#notes-for-mac-os-x-users
Even though Windows doesn't h
This code:
void GuiView::errors(string const & error_type, bool from_master)
{
BufferView const * const bv = currentBufferView();
if (!bv)
return;
ErrorList & el = from_master ?
bv->buffer().masterBuffer()->errorList(error_type) :
bv->buffer().errorList(error
> pasteClipboardText [CutAndPaste.cpp, 912]
> Buffer::readString [Buffer.cpp, 695]
> Buffer::readFile(Lexer,...) [Buffer.cpp, 752]
> Buffer::readDocument [Buffer.cpp, 568]
> Text::read [Text.cpp, 1311]
> readParagraph [Text.cpp, 248]
> readParToken [Text.cpp, 84]
> readInset [factory.cpp, 420]
> In
Hi,
I update this morning the svn version of lyx, compile it and notice the
following bug:
using the class article(chess), the layout Mainline is not traduced to
latex with the command mainline: the latex code produced with this
layout is only: {what you type
I suppose this is a bug with PassThru,
On Dec 8, 2010, at 2:20 PM, Enrico Forestieri wrote:
> It would be interesting to see what is the output on a Mac.
> If we get any "1" whenever the filename in not empty, we also have the
> explanation of why the bug only occurs on Mac (but not why it does).
Insert image:
igp: "" 1
this: "" 1
Lots of emails... short summary:
1) Changing the DocFileName constructor definition does not help.
2) filename and igp.filename in InsetGraphicsParams::copy always have identical
saveAbsPath() values
3) common_path is not called on paste (see below).
On Dec 8, 2010, at 11:35 AM, Enrico Forestier
> It would be interesting to see what is the output on a Mac.
So,
Christian, Stephan, Abdel, Richard, Jean-Marc, Bennett, ... anyone ?
Vincent
On Wed, Dec 08, 2010 at 05:41:51PM +0100, Vincent van Ravesteijn wrote:
> New test.
>
> InsetGraphicsParams::copy(InsetGraphicsParams const & igp)
> {
> filename = igp.filename;
>
> LYXERR0("igp:" << igp.filename << " " << igp.filename.saveAbsPath());
> LYXERR0("this: " << filename <<
Helge Hafting wrote:
> I compiled & installed today's LyX 2.0.
> Running it and selecting Tools->Reconfigure, I get:
>
> Failed to find \Declare line for layout file
> `/usr/local/share/lyx2/layouts/manpage.layout'
> ../../../lyx-devel3/src/support/Systemcall.cpp(237): Systemcall: 'python
> -tt "/
spitz wrote:
> Author: spitz
> Date: Wed Dec 8 19:42:10 2010
> New Revision: 36777
> URL: http://www.lyx.org/trac/changeset/36777
>
> Log:
> * resolve conflicts of XeTeX with AMS by loading all AMS packages before
> fontspec. See
>
http://www.macfreek.nl/mindmaster/LaTeX_package_conflicts#Ams
On Wed, Dec 08, 2010 at 06:19:54PM +0100, Vincent van Ravesteijn wrote:
> This log indicates to me that outputFilename is able to make a
> relative path with the same input, so my feeling says it really is
> this save_abs_path_ boolean that differs.
Maybe. The only way to know what really happens
Am 08.12.2010 um 18:12 schrieb Enrico Forestieri:
> Anyway, we should chase a platform-dependent bug. Now I am shooting
> in the dark, but makeRelPath() calls os::common_path() to decide
> whether a common prefix exists, and in os_unix.cpp I see:
>
> docstring::size_type common_path(docstring con
> Anyway, we should chase a platform-dependent bug.
Different compilers make a difference too. Though, I don't know how
much the GCC on mac differs from the *nix gcc compilers.
> and in makeRelPath() (in filetools.cpp) we have:
>
> docstring::size_type i = os::common_path(abspath, basepa
Am 08.12.2010 um 17:57 schrieb Vincent van Ravesteijn:
>>>
>>> - DocFileName(std::string const & abs_filename, bool save_abs_path =
>>> true);
>>> - DocFileName(FileName const & abs_filename, bool save_abs_path = true);
>>> + DocFileName(std::string const & abs_filename, bool save_ab
On Wed, Dec 08, 2010 at 05:57:41PM +0100, Vincent van Ravesteijn wrote:
> >>
> >> - DocFileName(std::string const & abs_filename, bool save_abs_path =
> >> true);
> >> - DocFileName(FileName const & abs_filename, bool save_abs_path =
> >> true);
> >> + DocFileName(std::string const &
>>
>> - DocFileName(std::string const & abs_filename, bool save_abs_path =
>> true);
>> - DocFileName(FileName const & abs_filename, bool save_abs_path = true);
>> + DocFileName(std::string const & abs_filename, bool save_abs_path =
>> false);
>> + DocFileName(FileName const & abs
On Wed, Dec 08, 2010 at 05:49:35PM +0100, Vincent van Ravesteijn wrote:
> What about this:
>
> DocFileName(FileName const & abs_filename, bool save_abs_path = true);
>
> The FileName is _implicitly_ converted from FileName to DocFileName
> and secretly save_abs_path_ is set to true.
>
> can you
On Wed, Dec 08, 2010 at 05:41:51PM +0100, Vincent van Ravesteijn wrote:
> I hypothesize now that
>
> filename = igp.filename
>
> uses FileName::operator= and then sets the DocFileName::save_abs_path_
> member to its default 'true'.
That would not explain why it seems to occur only on Mac.
--
What about this:
DocFileName(FileName const & abs_filename, bool save_abs_path = true);
The FileName is _implicitly_ converted from FileName to DocFileName
and secretly save_abs_path_ is set to true.
can you check whether this patch fixes the problem:
src/support/filenam...@245--246:
- D
New test.
InsetGraphicsParams::copy(InsetGraphicsParams const & igp)
{
filename = igp.filename;
LYXERR0("igp:" << igp.filename << " " << igp.filename.saveAbsPath());
LYXERR0("this: " << filename << " " << filename.saveAbsPath());
...
}
Can you try this and output the result ?
On Wed, Dec 08, 2010 at 10:14:46AM -0600, Christian Thiemann wrote:
> Clicking on original image:
>
> GuiGraphics.cpp(554): paramsToDialog: name = Desktop/WAN_map.pdf
> GuiGraphics.cpp(555): paramsToDialog: igp.filename.absFilename() =
> /Users/ct/Desktop/WAN_map.pdf
> GuiGraphics.cpp(556): param
I compiled & installed today's LyX 2.0.
Running it and selecting Tools->Reconfigure, I get:
Failed to find \Declare line for layout file
`/usr/local/share/lyx2/layouts/manpage.layout'
../../../lyx-devel3/src/support/Systemcall.cpp(237): Systemcall: 'python
-tt "/usr/local/share/lyx2/configure.p
This patch lets LyX 2.0 use spreadsheets as external insets:
* gnumeric spreadsheets
* openoffice spreadsheets
* excel spreadhsheets
This is done using the "ssconvert" utility that comes with gnumeric,
so it is necessary to have gnumeric even if the spreadsheets used
are made with openoffice/exce
On Dec 8, 2010, at 9:43 AM, Vincent van Ravesteijn wrote:
>> It seems like prepareFile() is not called during copy'n'paste.
>
> No, it is used when generating LaTeX. If you open the view source
> window, and automatically update, you will see the debugging info when
> you change the document.
O
> BTW, there is a ticket here, isn't it the same problem?
> http://www.lyx.org/trac/ticket/6538
>
> Stephan
Yes, it is, but now I decided I wanted to figure out how it happens.
Luckily the number of Mac-agnostic developers/willing-to-help users is
no longer countable on one hand, so now we should
> It seems like prepareFile() is not called during copy'n'paste.
No, it is used when generating LaTeX. If you open the view source
window, and automatically update, you will see the debugging info when
you change the document.
> GuiGraphics.cpp(554): paramsToDialog: name = /Users/ct/Desktop/WAN_
On Wed, Dec 08, 2010 at 04:29:29PM +0100, Pavel Sanda wrote:
> Enrico Forestieri wrote:
> > On Wed, Dec 08, 2010 at 03:47:30PM +0100, Vincent van Ravesteijn wrote:
> >
> > > "C:\Documents\chapters\first\firstsection\test.lyx"
> > > "C:\UnrelatedPath\test\images\large\color\test.jpg" ?
> > >
> > >
Am 08.12.2010 um 15:47 schrieb Vincent van Ravesteijn:
>> I noticed there are some closed entries in the bug tracker about this
>> already, but I've had this problem for a long time and it still appears in
>> LyX 1.6.8 (I am using Mac OS X):
>
> The problem is that it seems to occur only on Mac
Enrico Forestieri wrote:
> On Wed, Dec 08, 2010 at 03:47:30PM +0100, Vincent van Ravesteijn wrote:
>
> > "C:\Documents\chapters\first\firstsection\test.lyx"
> > "C:\UnrelatedPath\test\images\large\color\test.jpg" ?
> >
> > Should we now have a relative path
> > "..\..\..\..\UnrelatedPath\test\ima
Thanks for the reply.
On Dec 8, 2010, at 8:47 AM, Vincent van Ravesteijn wrote:
>
> InsetGraphics::prepareFile():
>
> string const orig_file = params().filename.absFilename();
> // this is for dryrun and display purposes, do not use latexFilename
> string const rel_file =
> pa
On Wed, Dec 08, 2010 at 03:47:30PM +0100, Vincent van Ravesteijn wrote:
> "C:\Documents\chapters\first\firstsection\test.lyx"
> "C:\UnrelatedPath\test\images\large\color\test.jpg" ?
>
> Should we now have a relative path
> "..\..\..\..\UnrelatedPath\test\images\large\color\texst.jpg" ? This
> doe
On 12/08/2010 10:12 AM, Liviu Andronic wrote:
Dear all
Is there a reason for using 'box' instead of 'box (minipage)' in
Insert? My problem with current arrangement is that it is unintuitive.
When I first found about *minipage* functionality and needed to use it
in LyX, I needed a good deal of sea
Dear all
Is there a reason for using 'box' instead of 'box (minipage)' in
Insert? My problem with current arrangement is that it is unintuitive.
When I first found about *minipage* functionality and needed to use it
in LyX, I needed a good deal of searching before understanding that
'box' was offer
> I noticed there are some closed entries in the bug tracker about this
> already, but I've had this problem for a long time and it still appears in
> LyX 1.6.8 (I am using Mac OS X):
The problem is that it seems to occur only on MacOSX.
>
> 1) Insert a new graphic and select an image via the f
> This would mean that the Undo stack really should not be a Buffer
> member but a BufferView member.
>
But that would mean that you have different Undo stacks in different
BufferViews.
Well, not really, you do have different Undo stacks, but it is filled
with the same elements as the Buffer cha
On 12/07/2010 04:31 PM, b...@lyx.org wrote:
Author: baum
Date: Tue Dec 7 22:31:31 2010
New Revision: 36766
URL: http://www.lyx.org/trac/changeset/36766
Log:
Fix bug #6603.
The problem was that the child buffers were closed,
and therefore the TOC contained dangling pointers.
The fix is simple: R
> While you're at this, I wonder if you have a relatively easy fix for this
> bug. Add a character to a document, then go to the end of the document. Now
> do Undo, Redo. The redo moves you to the end of the document, so you don't
> actually see what you just redid. There are also forms of this bug
On 12/08/2010 05:04 AM, lasgout...@lyx.org wrote:
Author: lasgouttes
Date: Wed Dec 8 11:04:07 2010
New Revision: 36771
URL: http://www.lyx.org/trac/changeset/36771
Log:
Some Undo cleanup. Functionality should be unchanged
- whitespace and typos in comments
- make sure that the Undo::recordUndoX
Am 08.12.2010 um 14:13 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> That's not my play ground... to save me time I'd like to ask:
>
> i meant whether you can reproduce on mac.
Not here... but I never copied some 1.6 preferences to 2.0...
I don't know if the ticket reporter did it - I suspect it
Hello,
I noticed there are some closed entries in the bug tracker about this already,
but I've had this problem for a long time and it still appears in LyX 1.6.8 (I
am using Mac OS X):
1) Insert a new graphic and select an image via the file selection dialog.
2) The graphics dialog now shows a
Stephan Witt wrote:
> That's not my play ground... to save me time I'd like to ask:
i meant whether you can reproduce on mac.
> where is it stored? What's the name of the variable to search for?
it wont be rc variable but something stored in ~/.config/LyX/*.conf
via qt session stuff.
pavel
Le 08/12/2010 13:48, Vincent van Ravesteijn a écrit :
I don't like this indirection. A buffer has a property dirty or not
_and_ has and Undo stack so that it can record the changes, but now
suddenly this Undo member governs the dirty status of the buffer.
Agreed. I do not like it either, but I
> Author: lasgouttes
> Date: Wed Dec 8 11:30:45 2010
> New Revision: 36772
> URL: http://www.lyx.org/trac/changeset/36772
>
> Modified: lyx-devel/trunk/src/Undo.cpp
> ==
> --- lyx-devel/trunk/src/Undo.cpp Wed Dec
56 matches
Mail list logo
