Il 13/09/2011 14:43, Richard Heck ha scritto:
On 09/12/2011 07:52 PM, Tommaso Cucinotta wrote:
-bool Buffer::doExport(string const format, bool put_in_tempdir,
- bool includeall, string result_file) const
+bool Buffer::doExport(string const target, bool put_in_tempdir
Il 13/09/2011 14:43, Richard Heck ha scritto:
I guess I'd prefer to a separate LFUN_BUFFER_EXPORT_TO routine here,
rather than this sort of trick with the arguments. There might one day
be other differences one wants. I think that would also make it easier
later to add the possibility to the
Il 14/09/2011 00:20, Julien Rioux ha scritto:
On 13/09/2011 1:52 AM, Tommaso Cucinotta wrote:
-bool doExport(std::string const format, bool put_in_tempdir,
+bool doExport(std::string const target, bool put_in_tempdir,
bool includeall = false) const;
Can we keep
Il 15/09/2011 00:47, Julien Rioux ha scritto:
So that's how LFUN's with more than one argument are handled then, as
one string. No need to change the patch, I see your stance.
Ok, let me check whether further clean-ups are needed, and commit.
On a related note, check out the point 3) at the
Il 13/09/2011 14:43, Richard Heck ha scritto:
Anyway, some thoughts.
This will be very nice to have.
It's in: r39678.
There may be some additional work needed in order to deal with all the
possible cases (relative paths, absolute paths), but it seems to me that
it's mostly there. I tried
One last remark: I just found a SEGFAULT while exporting, that was there
already before my last export patch:
$ gdb --args ./src/lyx -e xhtml ./lib/doc/EmbeddedObjects.lyx
GNU gdb (Ubuntu/Linaro 7.2-1ubuntu11) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
Il 15/09/2011 03:54, Richard Heck ha scritto:
On 09/14/2011 09:21 PM, Tommaso Cucinotta wrote:
One last remark: I just found a SEGFAULT while exporting, that was
there already before my last export patch:
I get an assertion at line 192 of RenderPreview.cpp. I take it the
problem
Hi,
I just noticed I cannot start anymore the system-provided LyX on my
Ubuntu 11.04.
It say Cannot read the configuration file.
AFAICGuess, this might be due to the new multi-format-extension patch.
The problem is that I cannot start LyX anymore, so I cannot reconfigure
(of course I can
Il 15/09/2011 15:13, Julien Rioux ha scritto:
Let's say I have a document, where all my figures are in ../images and
I want to export latex to out/latex and xhtml to out/xhtml and have my
images in out/images:
out/images -- image files
out/latex -- latex source
out/xhtml -- xhtml source
How
Il 15/09/2011 14:08, Richard Heck ha scritto:
On 09/15/2011 05:31 AM, Tommaso Cucinotta wrote:
Hi,
I just noticed I cannot start anymore the system-provided LyX on my
Ubuntu 11.04.
It say Cannot read the configuration file.
AFAICGuess, this might be due to the new multi-format-extension
with spaces, it should just work fine.
Thanks,
T.
Il 08/09/2011 02:55, Tommaso Cucinotta ha scritto:
Il 08/09/2011 02:24, Julien Rioux ha scritto:
Well, looking at your script again, we don't really need a script.
We just need to set up a odg-ps converter, then let LyX do the
ps2eps part (and yes
with spaces, it should just work fine (I hope).
Thanks,
T.
Il 08/09/2011 02:55, Tommaso Cucinotta ha scritto:
Il 08/09/2011 02:24, Julien Rioux ha scritto:
Well, looking at your script again, we don't really need a script.
We just need to set up a odg-ps converter, then let LyX do the
ps2eps part
tommaso@mobiletom:~/lyx-trunk-ws/lyx-trunk$ svn up
U src/Buffer.cpp
Aggiornato alla revisione 39680.
$ make
[...]
make[4]: ingresso nella directory /home/tommaso/lyx-trunk-ws/lyx-trunk/src
CXX Buffer.o
Buffer.cpp: In member function ‘void
lyx::Buffer::writeLyXHTMLSource(lyx::odocstream, const
Hi,
what is the exporting to a LyX archive supposed to produce ?
I get this error (trunk):
tommaso@mobiletom:~/lyx-trunk-ws/lyx-trunk$ ./src/lyx
lib/doc/EmbeddedObjects.lyx
Menus.cpp(693): Menu warning: menu entries Interruzione di pagina|I
and Visible Space|i share the same shortcut.
Il 15/09/2011 03:54, Richard Heck ha scritto:
I get an assertion at line 192 of RenderPreview.cpp. I take it the
problem is that, without a GUI, we do not have a PreviewLoader, which is
what I use to create math images. I'll have to figure out what to do
about this.
The attached patch gets rid
Il 16/09/2011 01:07, Richard Heck ha scritto:
On 09/15/2011 06:45 PM, Tommaso Cucinotta wrote:
What is the intended invocation of the lyxpak.py script ?
It's supposed to produce a tar.gz or zip file that contains both the LyX
file and all associated files, too, e.g., images, and even some
Il 07/09/2011 15:41, Richard Heck ha scritto:
Perhaps Julien and I can sort that out after your patch goes in.
There's even logic to that. This version could go to branch, whereas
Julien's idea would have to be trunk-only, due to the format changes.
Let's file an enhancement bug with 2.1.0
Il 17/09/2011 02:18, Tommaso Cucinotta ha scritto:
which is used to set a corresponding boolean into the Format
structure, that is retrieved through Format::zippedNative().
The logic was not integrated directly within
FileName::guessFormatFromContents(),
I meant to say The logic was now
.
#!/usr/bin/env python
# -*- coding: utf-8 -*-
# file libreoffice2eps.py
# This file is part of LyX, the document processor.
# Licence details can be found in the file COPYING.
#
# \author Tommaso Cucinotta
#
# Full author contact details are available in file CREDITS
# This script converts
Il 17/09/2011 17:29, Julien Rioux ha scritto:
I reworked your patch to do what I just described.
I didn't try it yet, a preliminary comment is: do we need to go to the
rc fileformat = 3 ? (AFAICR, the switch to 2 is still in trunk and is
not public yet)
It also makes your patch compile.
Il 17/09/2011 17:29, Julien Rioux ha scritto:
I think the logic about formats should be in Format.cpp, not in
FileName.cpp. FileName.cpp does not know about formats.
Hi,
I think this whole format detection logic in LyX is relatively fragile.
FileName.cpp should not know about formats, but it
Il 18/09/2011 16:03, Tommaso Cucinotta ha scritto:
Please test.
I will later today, thanks.
Made a few tests including a sample dia. If it is included as external
material, then it works.
If it is included as a graphics inset, then it doesn't show on the
screen and I have
Il 18/09/2011 20:37, Julien Rioux ha scritto:
On 18/09/2011 8:22 PM, Tommaso Cucinotta wrote:
Il 18/09/2011 16:03, Tommaso Cucinotta ha scritto:
Please test.
I will later today, thanks.
Made a few tests including a sample dia. If it is included as external
material, then it works
Il 18/09/2011 23:48, Pavel Sanda ha scritto:
atters.\n
+ \t-E [--export-to] fmt filename\n
+ where fmt is the export format of choice (see
--export),\n
+ and filename is the destination
filename.\n
[apologies if you get this twice]
Il 18/09/2011 23:53, Julien Rioux ha scritto:
On 18/09/2011 10:36 PM, Tommaso Cucinotta wrote:
Would you like to change further things in this patch, or can it be
committed ?
No time to test unfortunately, but your patch looks quite good.
One small point
Il 19/09/2011 02:38, Julien Rioux ha scritto:
On 19/09/2011 1:52 AM, Tommaso Cucinotta wrote:
Done, thanks. Is a command-line guide included also within the on-line
docs (UserGuide.lyx) ?
While you're at it could you please have a look at
http://www.lyx.org/trac/ticket/4312
Done (list
Hi,
probably I'm repeating myself, but AFAICS tolerating future file-formats
in lyx would not be a bad idea.
In the last editing of a paper in these days, I had to instruct a PhD
student using an old Debian with LyX 1.6 to:
1) open the .lyx file with an editor
2) replace the 413 with 345
Il 19/09/2011 08:04, Pavel Sanda ha scritto:
Tommaso Cucinotta wrote:
Done, thanks. Is a command-line guide included also within the on-line docs
(UserGuide.lyx) ?
don't we have the new nifty advsearch feature of skimming through manuals
only? :)
Isn't asking on the list faster than using
Il 19/09/2011 08:47, Guenter Milde ha scritto:
On 2011-09-19, Vincent van Ravesteijn wrote:
You should not let the development LyX interfere with your system-wide LyX.
For me, the following works:
./configure --with-version-suffix=-svn --enable-build-type=release
The
Il 19/09/2011 08:20, Pavel Sanda ha scritto:
+#includemap
+#includectime
the unfortunate thing is that this format.h is widely used elsewhere.
if there is a way how to not use them or move to less exposed place
it would be worth it.
I took the freedom to commit a patch (r39709) that hides
Il 19/09/2011 13:00, Pavel Sanda ha scritto:
thats actually more complicated. for svn tree we have
RELEASE-NOTES for trunk
status.20x for branch
and in wiki we have
http://wiki.lyx.org/LyX/NewInLyX21 for trunk
http://wiki.lyx.org/LyX/NewInLyX20 for backported things in branch (special section
Il 19/09/2011 17:56, Vincent van Ravesteijn ha scritto:
Op 19-9-2011 12:08, Tommaso Cucinotta schreef:
I took the freedom to commit a patch (r39709) that hides all the
ZippedInfo and zipped_ cache inside Format.cpp, making this zipped_
cache a static variable. I don't think there's any good
Il 19/09/2011 15:12, Julien Rioux ha scritto:
Please read my entire emails.
I asked for a second opinion on the cache.
doesn't seem a big issue -- if it's unneeded, we can entirely get rid of
it (see the few benchmarks I sent).
I said the libreoffice2eps.py script is not necessary.
ok,
Il 19/09/2011 21:52, Vincent van Ravesteijn ha scritto:
So, we agree that Format::iszippedfile should be in filename.
Especially when the filenames are cached.
My initial patch was a modification of the isZipped() method of
FileName.cpp, with the problem that, in the end, we need to query
Hi all,
I'm forwarding the experienced problems of a colleague of mine trying to
use LyX 2.0.0 on a Mac -- I don't know whether these are known issues
and have been fixed, or if it's useful to report them.
Bye,
T.
When I open lyx v2.0 on my mac os 10.4, I get the following message:
Il 19/09/2011 15:34, Richard Heck ha scritto:
In its present state, too, LyX is likely to do very weird things
(e.g., interpret inset arguments as plain text), if not crash, since
it will get confused about where it is in the parsing. If we had a
structured (e.g., XML) format, then we could
Il 19/09/2011 23:15, Julien Rioux ha scritto:
how LyX detects the format ? i.e., try this patch to Format.cpp:
Index: src/Format.cpp
===
--- src/Format.cpp(revisione 39709)
+++ src/Format.cpp(copia locale)
@@ -159,6
Il 20/09/2011 17:13, Richard Heck ha scritto:
All of that said, the issue that started this, as I recall, had to do
with a failure to parse the preferences file. In that case, surely,
LyX should just start, throwing a warning, and perhaps asking if the
user would like to erase the invalid file
Il 19/09/2011 20:41, Vincent van Ravesteijn ha scritto:
Op 19-9-2011 20:05, Tommaso Cucinotta schreef:
I don't know whether 1.5ms of saved time (per query) is enough to
justify the existence of the cache. Please, comment.
Not if there are 6 queries.
The previous benchmarks were random
Il 19/09/2011 15:12, Julien Rioux ha scritto:
Anyway, I now get this error when I open the graphics dialog in your
example file:
gzip: /home/jrioux/dropbox/lyx/tests/kk.odg has more than one
entry--rest ignored
../../../src/support/Systemcall.cpp(259): Systemcall: 'gunzip -c
Il 20/09/2011 17:13, Richard Heck ha scritto:
If you want to file a bug for this, cc'ing me, I will get to it.
The non-sophisticated fix seems as easy as the attached. User gets a
warning on the console in case of problems.
T.
Index: src/LyX.cpp
Il 27/09/2011 15:51, Julien Rioux ha scritto:
On 20/09/2011 12:05 AM, Tommaso Cucinotta wrote:
Il 19/09/2011 23:15, Julien Rioux ha scritto:
Sorry, not much time. Don't you also get this behavior?
Not of course: for me, it works like a charm! I can insert dia files (as
graphics) and odg
Il 27/09/2011 23:49, Richard Heck ha scritto:
On 09/27/2011 05:27 PM, Tommaso Cucinotta wrote:
AFAICS, it doesn't find a direct converter from ODG to PNG, so it
gives up. So, my big question:
*) Does LyX embed any (even naive) algorithm for automatically finding
a conversion path from a format
Il 28/09/2011 01:02, Tommaso Cucinotta ha scritto:
Il 27/09/2011 23:49, Richard Heck ha scritto:
The mystery is why the fall-back to convert isn't employed here.
From my little investigation:
1) there's no path in the graph from ODG to EPS (pls, find attached
the dumped list of registered
Il 28/09/2011 16:36, Rudi Gaelzer ha scritto:
I don't know if this has already been reported. I made a quick scan
through both the user and devel lists and couldn't find anything related.
While editing a text riddled with mathematical formulae, I had to use
advanced search several times to
Il 28/09/2011 20:40, Rudi Gaelzer ha scritto:
The document I'm working right now has thousands of formulas and I've
been using the advanced search pretty heavily. I can detect the
increasing memory load even with the very simple text that I attached
(memory.lyx). I was continually searching
Hi,
if I start LyX with -dbg undo, why do I get the creation of 3 undo
groups for each single (read-only) cursor movement ?
For example, just moving right over a letter, gives me:
Undo.cpp(498): +++Creating new group 11
Undo.cpp(511): ---End of group 11
Undo.cpp(498): +++Creating
Il 29/09/2011 00:30, Jean-Marc Lasgouttes ha scritto:
Le 29/09/2011 00:05, Tommaso Cucinotta a écrit :
Also, I noticed a monotonic memory usage increase while editing the
document and especially creating math insets and deleting them later. I
guess this is due to the Undo feature, that keeps
Il 28/09/2011 06:02, Julien Rioux ha scritto:
On 28/09/2011 1:02 AM, Tommaso Cucinotta wrote:
Now, AFAICS, there are 2 possibilities:
a) flood the graph with low-priority (or, if you prefer, high-cost)
fake edges, basically from
each node (handled by convert) to any other node (handled
Il 29/09/2011 16:24, Alex Fernandez ha scritto:
Luckily, eLyXer is highly configurable. You can add a new converter
line in src/conf/base.conf:
[ImageConfig.converters]
myconverter:binary $input --export $output
and use it from the command line:
$ eLyXer --converter myconverter
Il 29/09/2011 16:25, Richard Heck ha scritto:
Now, adding the EPS to PNG conversion explicitly allows LyX to find
the conversion path.
This is fine for branch. Note that it should also allow previews of ODG
pictures in LyX.
I can't remember whether we added ODG (and the zipped=native flag in
Il 29/09/2011 23:37, Alex Fernandez ha scritto:
Alternatively, one could think of pulling all the conversion logic
(along with configuration files, graph path discovery, etc.) *out of LyX*,
and make it a powerful independent tool for image and file conversion,
over which LyX would depend (and
Il 30/09/2011 12:15, Jean-Marc Lasgouttes ha scritto:
What do we see?
1/ there is a continuous drift of memory use
2/ the most important part is the agregation of small allocations (not
very useful...)
3/ the second one is related to font loading by qt (remains stable)
4/ the third one is the
Il 30/09/2011 08:36, Tommaso Cucinotta ha scritto:
Il 29/09/2011 23:37, Alex Fernandez ha scritto:
Alternatively, one could think of pulling all the conversion logic
(along with configuration files, graph path discovery, etc.) *out of
LyX*,
and make it a powerful independent tool for image
Hi,
the attached patch adds the -C option to LyX, allowing to use its
converters
for arbitrary files conversions, e.g.:
lyx -C /path/to/source.dia /path/to/dest.eps
lyx --convert-to /path/to/source.dia /path/to/dest.eps
Despite being useful in general (as this is more powerful than
Il 01/10/2011 19:01, Rudi Gaelzer ha scritto:
On Friday 30 September 2011 21:04:35 Tommaso Cucinotta wrote:
For the increased memory usage notified by Rudi, if there were any
problem with handling the Undo instances, then we should have seen
something about Undo into the valgrind log
Il 02/10/2011 22:18, Alex Fernandez ha scritto:
I have uploaded to Savannah a test version which uses this feature:
http://download-mirror.savannah.gnu.org/releases/elyxer/older/elyxer-lyx-C.py
To use LyX as a converter:
$ elyxer --converter=lyx input.lyx output.html
It is a bit
Hi Vincent,
do we have currently any git branch on gitorious that tracks closely the
svn trunk ? i.e., such that any svn commit is immediately reflected
(pushed) on it ?
Thanks,
T.
Il 04/10/2011 10:02, Alex Fernandez ha scritto:
Hi Tommaso,
On Mon, Oct 3, 2011 at 8:48 AM, Tommaso Cucinottatomm...@lyx.org wrote:
On a related note, when trying to use the --destdirectory option, I get:
Exception: Unused arguments: ['--destdirectory', '/tmp']
Strange, I have
Il 04/10/2011 10:08, Vincent van Ravesteijn - TNW ha scritto:
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.
Also, I think in the end I probably
Il 04/10/2011 15:28, Jean-Marc Lasgouttes ha scritto:
Le 01/10/2011 02:04, Tommaso Cucinotta a écrit :
These are just cleanup ops that are not explicitly done on program exit,
but not a big deal, actually. They could help in having a better cleanup
of LyX at exit, but I'm not sure any
Il 04/10/2011 17:26, Alex Fernandez ha scritto:
It is the same option as before. But now, if the argument is found in
ImageConfig.converters then it is used as a shortcut to the configured
command line; otherwise the whole command supplied is used. For
example the new option:
Il 05/10/2011 10:06, Alex Fernandez ha scritto:
On Tue, Oct 4, 2011 at 7:29 PM, Tommaso Cucinottatomm...@lyx.org wrote:
Very nice. One last thing. I guess I'd need a test in configure.py about the
version of elyxer currently installed, so probably there's someway to
issue a elyxer --version,
Il 05/10/2011 12:13, Alex Fernandez ha scritto:
As this option is new, only use it as default if you detect a LyX version
that supports it (currently only the development version).
Is there any way to get a simple version string from the command line?
The LyX format number would be ideal, as it
Il 05/10/2011 20:37, Rudi Gaelzer ha scritto:
All right, I installed valgrind and ran it as per instructions.
When it finally opened the text, the process massif-amd64-li... was
using 13.5%MEM and the demand was increasing very slowly without any
operation on the text.
When I opened the
Il 05/10/2011 22:54, Tommaso Cucinotta ha scritto:
2) try to recompile LyX from the sources, to check whether the problem
still shows up on your system or not in the current trunk. Shortly
(but it's going to take half an hour or so):
svn co svn://svn.lyx.org/lyx/lyx-devel/trunk lyx-trunk
cd
Hi,
I was a bit unhappy with the current command-line syntax for the new
--export-to (-E) option, and the presumably well-accepted --convert-to
(-C) one I sent on the list a few days ago. Let me recap:
lyx -E [--export-to] fmt filename
lyx -C [--convert-to] sourcefile destfile
on a
Il 06/10/2011 10:27, Guenter Milde ha scritto:
Maybe the current discussion can give some momentum to the
long standing issue?
http://www.lyx.org/trac/ticket/3402
Please, try the committed version, it should fix the mentioned ticket.
T.
Il 06/10/2011 15:50, Tommaso Cucinotta ha scritto:
Il 06/10/2011 10:27, Guenter Milde ha scritto:
Maybe the current discussion can give some momentum to the
long standing issue?
http://www.lyx.org/trac/ticket/3402
Please, try the committed version, it should fix the mentioned ticket
Il 06/10/2011 18:58, Julien Rioux ha scritto:
We have Export as... at the top of the menu and More options... at
the bottom, could they be moved together?
I struggle at getting the rationale behind the More Options... entry.
You are supposed to enter a custom command that performs the actual
Il 06/10/2011 19:02, Julien Rioux ha scritto:
By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?
Sure, let's re-make the point. Can you, please, open that odg.lyx file
with -dbg any, and send the whole output, along
Il 06/10/2011 21:02, Richard Heck ha scritto:
On 10/06/2011 02:27 PM, Julien Rioux wrote:
On 05/10/2011 11:49 PM, Tommaso Cucinotta wrote:
lyx -c source.svg -o dest.eps # convert arbitrary formats
(extension-based format detection for output)
lyx -c -i svg source.svg -e eps -o dest.eps
Il 06/10/2011 19:52, Julien Rioux ha scritto:
On 06/10/2011 7:36 PM, Tommaso Cucinotta wrote:
Il 06/10/2011 19:02, Julien Rioux ha scritto:
By the way I still get this, and it happens whether I have the
converter cache enabled or not. Could you please look into it?
A few questions:
1) what
Il 06/10/2011 23:21, Julien Rioux ha scritto:
On 06/10/2011 11:05 PM, Tommaso Cucinotta wrote:
A few questions:
1) what was exactly the visible problem ? (from your log I can't see
anything
different from what I can see in my own log -- the only problem is
that it
probably still fails
Il 06/10/2011 23:53, Julien Rioux ha scritto:
My easy fix would be to query formats and not even try to call
readBB_from_PSFile() unless the file is actually eps or eps.gz. Can I
ask why is this reading of the bounding box done ? Note that it may also
imply unzipping the file and searching for
Il 07/10/2011 00:03, Uwe Stöhr ha scritto:
Hi Tommaso,
I get this error:
D:\LyXSVN\lyx-devel\src\frontends\qt4\FileDialog.cpp(99) : error
C2664: 'QFileDialog::getSaveFileName' : cannot convert parameter 5
from 'QString' to 'QString *'
No user-defined-conversion operator available
Il 07/10/2011 00:51, Richard Heck ha scritto:
On 10/06/2011 04:42 PM, Tommaso Cucinotta wrote:
I'm sure you have some concrete trouble scenario in your
mind. Please, explicit it.
The only scenario I have in mind is users complaining when such things fail
and it's got nothing to do with LyX
Il 07/10/2011 01:32, Uwe Stöhr ha scritto:
Thanks, this compiles. I'm using Qt 4.7.4.
pls, let me know as well whether the Export-Export As... dialog works
fine or you have any problems or suggestions.
T.
Il 07/10/2011 00:17, Julien Rioux ha scritto:
On 07/10/2011 12:10 AM, Tommaso Cucinotta wrote:
I must be missing some piece of the puzzle here. Is this related to DPI
settings and the possibility for the user to crop in cm/mm/in, rather
than pixels ?
So, are you suggesting to ditch
Current trunk gives these warnings, which seem related to me.
Buffer.cpp:4197:42: warning: suggest parentheses around ‘’ within ‘||’
int Buffer::spellCheck(DocIterator from, DocIterator to,
[...]
// If from is at the end of the document (which is possible
// when leaving the mathed) LyX will
Il 07/10/2011 09:01, Guenter Milde ha scritto:
Any supported format (*.*)
ps (*.ps)
pdf (*.pdf)
pdf2 (*.pdf)
pdf3 (*.pdf)
LyX should know a user level name of these formats and present it to the
user (also in the preferences GUI). This is what we do with e.g. tex-source
encoding, where
Il 07/10/2011 09:20, Vincent van Ravesteijn ha scritto:
FileDialog::Result FileDialog::save(QString const path,
-QStringList const filters, QString const suggested)
+QStringList const filters, QString const suggested,
+QString selectedFilter)
[...]
It's anyway a bit
Hi all,
in the recently added Export As... dialog, we need to enumerate the
possible export formats for the current LyX document.
Originally I had thought this was achievable by checking the
Format::document()
method, however it was returning true also for XLS, ODS, CSV and other
formats for
Il 08/10/2011 01:08, Lars Gullik Bjønnes ha scritto:
One thing I'd like your input on: Do you want the reference to the svn
commit revisions kept in the git commit messages? Or should I prune them
as well?
What happens with Trac integration ? We used to refer to commits
from the wiki, from
Hi all,
I just dropped a ticket about an assertion triggered as follows (on
current trunk r39819):
0) Activate instant preview from prefs
1) C-S-f (open the find advanced panel)
2) C-m (start math inset)
3) Menu: Insert-Regular Expression-Anything
4) C-Home
5) Cursor right twice
For details,
Hi,
still looking at cleanup code on exit, I found a few TODOs about the
GuiProgress
singleton instance created by GuiView, that we never knew when to delete.
The attached patch fixes this by using a shared_ptr.
Any comment ? Would it be useful to have this in ? The rationale is as
usual to
Il 19/10/2011 04:02, Richard Heck ha scritto:
This fixes the assertion,
yes, I thought this was priority #1 for stability reasons, that's why I
committed without discussing on the list.
but isn't the layout combo still out of sync with the Advanced FR
dialog's work area? In the test case,
Il 19/10/2011 15:06, Pavel Sanda ha scritto:
tomm...@lyx.org wrote:
+ LFUN_BUFFER_EXPORT_AS, // tommaso 20111006
just a glitch but unless this is intended for branch backporting its good
to keep RELEASE-NOTES in sync...
Done in r39888.
T.
I just updated the patch adding the paste as unformatted text
capability to LyX.
It fixes enhancement #7226, and it partially addresses #6731.
It is attached. Comments are very welcome.
Thx,
T.
Index: src/LyXAction.cpp
===
Il 29/10/2011 03:05, Richard Heck ha scritto:
On 10/28/11 6:30 PM, Tommaso Cucinotta wrote:
I just updated the patch adding the paste as unformatted text
capability to LyX.
It fixes enhancement #7226, and it partially addresses #6731.
It is attached. Comments are very welcome.
This seems
Il 29/10/2011 23:00, rgh...@lyx.org ha scritto:
Author: rgheck
Date: Sat Oct 29 23:00:23 2011
New Revision: 40073
URL: http://www.lyx.org/trac/changeset/40073
Log:
Initial work for view source improvements.
Just to add a comment to the initial posting: I can remember that,
apparently,
I was
Il 29/10/2011 23:29, Uwe Stöhr ha scritto:
If this will not be backported to branch, can you please add an entry
here:
http://wiki.lyx.org/LyX/NewInLyX21
If should go to branch can you please give me a short description what
the new menu entries do exactly so that I can update the docs?
Il 29/10/2011 23:29, Uwe Stöhr ha scritto:
If should go to branch can you please give me a short description what
the new menu entries do exactly so that I can update the docs?
I have a couple of suggestions for menus and shortcuts:
1) The [Edit]-[Paste Special...]-[Plain Text] seems to me
Il 30/10/2011 02:29, PhilipPirrip ha scritto:
I hoped to have my grace files included into a document and being able
to produce a pdf (by pdflatex), but that seems not to work. Grace
simply does not export to PDF.
I tried to chain the conversion process in LyX under Linux, but that
seemed not
Il 30/10/2011 12:08, Vincent van Ravesteijn ha scritto:
Op 30-10-2011 10:40, Tommaso Cucinotta schreef:
LyX can chain converters automatically for you. You can see the
graph of converters here:
http://retis.sssup.it/~tommaso/lyx-converters.pdf
Maybe it would be nice to implement a LyX
Il 30/10/2011 14:53, Enrico Forestieri ha scritto:
Looking for the reason of this particular failure, I just discovered
that the parser doesn't take into account another shell construct that
is used in our converters, namely 2/dev/null. This is wrongly
interpreted as discarding stdout and the
Il 30/10/2011 12:08, Vincent van Ravesteijn ha scritto:
You can see the graph of converters here:
http://retis.sssup.it/~tommaso/lyx-converters.pdf
Maybe it would be nice to implement a LyX-LaTeX converter sometime.
Also, do you mind if I drop the attached script (that produces the graph
Il 30/10/2011 16:16, Enrico Forestieri ha scritto:
If a converter contains the construct 2/dev/null, this is parsed
incorrectly. If our converter is
gracebat -hardcopy -printfile $$o -hdevice EPS $$i 2/dev/null
[...]
I've got this point, but still I cannot understand why it works
flawlessly
Il 30/10/2011 18:18, PhilipPirrip ha scritto:
On 10/30/2011 12:17 PM, Vincent van Ravesteijn wrote:
I only see a EPS - PDF (ps2pdf) converter. Maybe it is confused by
not having a EPS - PDF (pdflatex) converter ?
A good clue, thanks!
Seems that my TeX Live installation was missing epstopdf,
Hi,
I'd need to iterate over a Buffer and doing continuous exports to latex
of individual paragraphs from 2 different threads.
The GUI is frozen during this time, so no edits to the Buffer are possible.
Is there any reason of why this might not work ?
Thx,
T.
601 - 700 of 2402 matches
Mail list logo
