Re: Approaching LyX 1.5.2 [status update #3]
> 1. apply my patch for now.
> 2. display a message box when lyx is started without proper .lst
> files. This can be done easily if someone can show me where to insert
> this message box.
>
> Because my patch follows this line, I propose that we figure out 2 for
> 1.5.x, and complete 3 and 4 for 1.6.x.
OK. Here is an updated patch that does 2 as well. When lyx is started
without proper .lst files, a message box will appear and say "No
textclass is found. Click OK to reconfigure". After a user clicks OK,
reconfigure will start.
Uwe: please test.
Abdel, it would be good if the output of reconfigure can appear in a
dialog. Because miktex' update is very slow (25 min in my case), some
progress would better be displayed.
Bo
Index: src/LyX.cpp
===
--- src/LyX.cpp (revision 20474)
+++ src/LyX.cpp (working copy)
@@ -611,6 +611,13 @@
// aknowledged.
restoreGuiSession();
+ // if reconfiguration is needed.
+ if (textclasslist.empty()) {
+ Alert::error(_("No textclass is found"),
+ _("Click OK to reconfigure lyx."));
+ pimpl_->lyxfunc_.dispatch(FuncRequest(LFUN_RECONFIGURE));
+ }
+
// Execute batch commands if available
if (batch_command.empty())
return;
@@ -626,6 +633,10 @@
{
LyXView * view = newLyXView();
+ // if there is no valid class list, do not load any file.
+ if (textclasslist.empty())
+ return;
+
// if some files were specified at command-line we assume that the
// user wants to edit *these* files and not to restore the session.
if (!pimpl_->files_to_load_.empty()) {
Index: src/TextClassList.cpp
===
--- src/TextClassList.cpp (revision 20474)
+++ src/TextClassList.cpp (working copy)
@@ -164,13 +164,15 @@
}
LYXERR(Debug::TCLASS) << "End of parsing of textclass.lst" << endl;
- if (classlist_.empty()) {
+ // lyx will start with an empty classlist_, but only reconfigure is allowed
+ // in this case. This gives users a second chance to configure lyx if
+ // initial configuration fails. (c.f. bug 2829)
+ if (classlist_.empty())
lyxerr << "TextClassList::Read: no textclasses found!"
<< endl;
- return false;
- }
- // Ok everything loaded ok, now sort the list.
- sort(classlist_.begin(), classlist_.end(), less_textclass_avail_desc());
+ else
+ // Ok everything loaded ok, now sort the list.
+ sort(classlist_.begin(), classlist_.end(), less_textclass_avail_desc());
return true;
}
Index: src/TextClassList.h
===
--- src/TextClassList.h (revision 20474)
+++ src/TextClassList.h (working copy)
@@ -40,6 +40,8 @@
const_iterator begin() const { return classlist_.begin(); }
///
const_iterator end() const { return classlist_.end(); }
+ ///
+ bool empty() const { return classlist_.empty(); }
/// Gets textclass number from name, -1 if textclass name does not exist
std::pair const
Index: src/LyXFunc.cpp
===
--- src/LyXFunc.cpp (revision 20474)
+++ src/LyXFunc.cpp (working copy)
@@ -390,6 +390,16 @@
//lyxerr << "LyXFunc::getStatus: cmd: " << cmd << endl;
FuncStatus flag;
+ // if textclasslist is empty, the only allowed operation is reconfigure (c.f. bug 2829)
+ // FIXME: this can be removed after lyx can restart itself automatically
+ // after reconfiguration. Note that reconfiguration is triggered at
+ // LyX::execBatchCommands() in LyX.cpp.
+ if (textclasslist.empty() && cmd.action != LFUN_RECONFIGURE
+ && cmd.action != LFUN_LYX_QUIT) {
+ flag.enabled(false);
+ return flag;
+ }
+
Cursor & cur = view()->cursor();
/* In LyX/Mac, when a dialog is open, the menus of the
Re: Approaching LyX 1.5.2 [status update #3]
> I'm not sure what to do. As I see it, both patches have their drawbacks. Yes. My patch should display a dialog and let the user click ok to reconfigure. The output should be redirected to a dialog. Enrico's path has the problem that nothing happens after lyx.exe is clicked so several instances of lyx are likely to be started. The long-term solution here is that 1. apply my patch for now. 2. display a message box when lyx is started without proper .lst files. This can be done easily if someone can show me where to insert this message box. 3. redirect configure.py output to a dialog. (I do not know how difficult it is. Abdel may help here.) 4. restart lyx automatically after reconfiguration. Because my patch follows this line, I propose that we figure out 2 for 1.5.x, and complete 3 and 4 for 1.6.x. Cheers, Bo
Re: Cannot compile CoordCache.h
> typename cache_type::const_iterator it ... > > . In older versions of the standard an implicit typename was assumed, and I > guess that your MSVC still allows this. Yes. typename is required by gcc. Bo
Re: [patch] bug 4122: Caption in listings inset produce invalid latex code
> The attached patch is a tentative fix for this issue that solves two things: I can confirm that this patch fixes 4122. Bo
Re: Approaching LyX 1.5.2 [status update #3]
> 2829 maj LyX unusable after unsuccessful configuration > > The discussion of the implementation details kind of died, but there > seems to be no consensus yet. So, what shall we do? I think something has to be done here. I still prefer my patch but Enrico's one-liner is also acceptable. To be more specific, my patch allows lyx to start without proper .lst file, but only allows reconfiguration in this case. Enrico's patch restarts reconfiguration if .lst files are not generated successfully. > 4182 maj Caption in listings inset produce invalid latex code > > See patch I just sent to the list. Thanks! Bo
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
> can you be more verbose what you mean or give me some link ? somehow i'm > reluctant to believe that mutt would break any RFC. > > pavel http://marc.info/?t=11835435303&r=1&w=2 especially http://marc.info/?l=lyx-devel&m=118366121102662&w=2 I would not blame mutt, but a line may be needed to muttrc to change the way it handles pure-text attachments. Bo
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
> I _do_ send them as an attachment _always_. If some web archives corrupt it, > its not my fault. But I can CC you which should solve this issue. I guess you have the same problem as Abdel once had. Your attachment should be coded as attachment. Cheers, Bo
Re: [Patch#4] Bug 3527 - Basic PDF support via hyperref
I tried to play with the PDF property feature. 1. view source dialog is still broken (Can not update). Can anyone fix it? 2. I only checked two items but your hyperref output has two lines of options. Can you remove some of them that are using their default values? 3. Should other items be disabled when 'use hyperref' is not checked? 4. I select 'no frames around links' but I still see red frames around my TOC items. Bo
Re: DocBook
> - It corrects LyX' exported SGML code, so that you can use it (otherwise you > will get tons of errors). I tried to use docbook with lyx but the exported SGML code can not compile. It there anything specific lyx can do to produce the correct code? Are there bugzilla entries for them? Bo
Re: Compression and other assorted bits
> It is the save/saveas part that annoys me most. My understanding is that > embedding or not, I am working on the same file. A possible solution to the save/saveas problem might be linking .lyx and .lyz tightly and say 'save a bundled copy' instead of 'save in bundled format'. Then, .lyx will always be saved and .lyz will be saved if requested. This is also confusing because 'save as' might save two files, and the logic has to be changed if .lyz is opened directly. So, whoever proposes the use of a separate file extension has to give me a clear logic how to handle save and save as. Bo
Re: Compression and other assorted bits
> In case it is not clear (and I agree that it is not) the question about > secondary argument refers to unpacking in place. Unpacking will prompt for overwrite if file.lyx already exists. It is the save/saveas part that annoys me most. My understanding is that embedding or not, I am working on the same file. Bo
Re: Small puzzle.
> Possible conclusions: Precompiled headers are a waste of time and space. > 22% increase on compile times, ~300% increase on disk space. > > Could somebody please try the same test with a different compiler? I tried a while ago with gcc 3.4 on linux. Autotools' pch did not show any advantage in compile time. This was why I did not add pch to scons. I heard that pch can do magic to msvc though. Cheers, Bo
Re: Compression and other assorted bits
> If we want a different suffix for embedded lyx files why not to call them > .elyx? I am not in favor of a separate file extension partly because of the extra work (document, .cpp etc). If it is decided to use one, I would prefer .lyz. 'z' is after 'x', it means 'compression', and '.lyz' actually sounds like '.lyx'. Remember, if you have file.lyz and file.lyx in the same directory, unpacking file.lyz will overwrite file.lyx. You also have to decide if you want to save file.lyx along with file.lyz if you edit file.lyx and then enable embedding. A single extension is easier to understand. Bo
Re: Compression and other assorted bits
> I don't care so much if we drop the feature of reading compress files > with > lyx as long as the program deals with lyx.gz files. I agree that we can drop the compression feature as long as lyx2lyx can decompress compressed files so that lyx can read it. As for the embedding feature, the manifest is now in .lyx file so if someone wants a compressed file without embedding anything, s/he can enable 'save in bundled format', select all embedded files and click the 'do not embed' button. The embedding feature is almost complete (lacking better update of the embedding dialog and support for InsetExternal etc) so I would welcome public testing. If you dislike any part of the user interaction, please bring it up now. Basically, embedding works like this: 1. InsetGraphics (and later on InsetExternal, InsetInclude) has an attribute 'Embed'. It can be set individually in the Graphics dialog, or all at once in the embedding dialog. 2. .lyx file can be saved in plain text, or in a bundled format, which can be turned on/off in the embedding dialog. 3. When embedding is turned off, all embedded files are copied to their original places (if necessary). lyx can be used as usual and files will not be copied around. 4. When 'save in bundled format' is enabled, embedded files will be copied to temppath() and external modification will not change them. Changing embedding status will embed/extract related files. 5. Additional features include add and extraction of embedded files. Cheers, Bo
Re: Flex Insets [Was: Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...]
> In any event, flex insets are what used to be charstyles, only now it's > possible to make them collapsable as well as inline. So you can do > something like this: > InsetLayout Custom:Label >LyXTypecustom >LatexNamelabel >LatexTypecommand >Decorationclassic >LabelStringLabel > End OK, using lyx1.6svn, open user's guide, where can I find a flex inset? Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
> > All that's left then is adding the lyx2lyx code to convert the old > > insets to this. BTW, giving different insets different size/color/shape makes sense to me. Bo
Re: trunk does no longer compile
> Missing #include . Fix committed. > > I probably should reconfigure --without-pch to chatch this kind of > errors. You should. I have fixed at least five such instances. Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
> Well, thanks to Richard we have the possibility to build custom flex > insets for this now, right? Look Ma, no C++! > > All that's left then is adding the lyx2lyx code to convert the old > insets to this. > > Any takers? Not me. I do not know what is a flex inset. Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
On 9/17/07, Uwe Stöhr <[EMAIL PROTECTED]> wrote:
> >> I would suggest (think I did) to completely leave Idx: off, and make the
> >> appearance of the button distinctive. People are curious and will click
> >> if they wonder what it is, and will quickly learn.
> >
> > This would be an option.
>
> This would indeed be a solution, together with a limit for the label length
> of 20 chars.
I quickly hacked something like the attached (screenshot and patch).
If people like it, I can implement it seriously later on (I will be
quite busy in the next two weeks, and this will have low priority). I
am be happy if someone (Uwe?) can take it over. The obvious things to
add may be a separate index background color, or something to the left
of the box to make it look like a P shape with | meaning Index.
I suspect that it would be difficult to satisfy everyone with the new
look of this index inset.
Cheers,
Bo
<>Index: src/insets/RenderButton.cpp
===
--- src/insets/RenderButton.cpp (revision 20333)
+++ src/insets/RenderButton.cpp (working copy)
@@ -23,7 +23,7 @@
RenderButton::RenderButton()
- : editable_(false)
+ : editable_(false), type_(Regular)
{}
@@ -43,20 +43,37 @@
bool RenderButton::metrics(MetricsInfo &, Dimension & dim) const
{
Font font(Font::ALL_SANE);
- font.decSize();
- frontend::FontMetrics const & fm =
- theFontMetrics(font);
+ if (type_ == Regular) {
+ font.decSize();
+ frontend::FontMetrics const & fm =
+ theFontMetrics(font);
- if (editable_)
- fm.buttonText(text_, dim.wid, dim.asc, dim.des);
- else
- fm.rectText(text_, dim.wid, dim.asc, dim.des);
+ if (editable_)
+ fm.buttonText(text_, dim.wid, dim.asc, dim.des);
+ else
+ fm.rectText(text_, dim.wid, dim.asc, dim.des);
- dim.wid += 4;
- if (dim_ == dim)
- return false;
- dim_ = dim;
- return true;
+ dim.wid += 4;
+ if (dim_ == dim)
+ return false;
+ dim_ = dim;
+ return true;
+ } else if (type_ == UpperCorner) {
+ font.setSize(Font::SIZE_TINY);
+ frontend::FontMetrics const & fm =
+ theFontMetrics(font);
+
+ if (editable_)
+ fm.buttonText(text_, dim.wid, dim.asc, dim.des);
+ else
+ fm.rectText(text_, dim.wid, dim.asc, dim.des);
+
+ dim.wid += 2;
+ if (dim_ == dim)
+ return false;
+ dim_ = dim;
+ return true;
+ }
}
@@ -65,13 +82,22 @@
// Draw it as a box with the LaTeX text
Font font(Font::ALL_SANE);
font.setColor(Color::command);
- font.decSize();
-
- if (editable_) {
- pi.pain.buttonText(x + 2, y, text_, font, renderState());
- } else {
- pi.pain.rectText(x + 2, y, text_, font,
- Color::commandbg, Color::commandframe);
+ if (type_ == Regular) {
+ font.decSize();
+ if (editable_) {
+ pi.pain.buttonText(x + 2, y, text_, font, renderState());
+ } else {
+ pi.pain.rectText(x + 2, y, text_, font,
+ Color::commandbg, Color::commandframe);
+ }
+ } else if (type_ == UpperCorner) {
+ font.setSize(Font::SIZE_TINY);
+ if (editable_) {
+ pi.pain.buttonText(x + 2, y - 8, text_, font, renderState());
+ } else {
+ pi.pain.rectText(x + 2, y - 8, text_, font,
+ Color::commandbg, Color::commandframe);
+ }
}
}
Index: src/insets/InsetIndex.cpp
===
--- src/insets/InsetIndex.cpp (revision 20333)
+++ src/insets/InsetIndex.cpp (working copy)
@@ -29,14 +29,16 @@
InsetIndex::InsetIndex(InsetCommandParams const & p)
: InsetCommand(p, "index")
-{}
+{
+ setButtonType(RenderButton::UpperCorner);
+}
docstring const InsetIndex::getScreenLabel(Buffer const &) const
{
size_t const maxLabelChars = 25;
- docstring label = _("Idx: ") + getParam("name");
+ docstring label = getParam("name");
if (label.size() > maxLabelChars) {
label.erase(maxLabelChars - 3);
label += "...";
Index: src/insets/InsetCommand.h
===
--- src/insets/InsetCommand.h (revision 20333)
+++ src/insets/InsetCommand.h (working copy)
@@ -109,7 +109,8 @@
void setParams(InsetCommandParams const &);
/// This should provide the text for the button
virtual docstring const getScreenLabel(Buffer const &) const = 0;
-
+ ///
+ void setButtonType(RenderButton::ButtonType type) { button_.setType(type); }
private:
///
InsetCommandParams p_;
Index: src/insets/RenderButton.h
===
--- src/insets/RenderButton.h (revision 20333)
+++ src/insets/RenderButton.h (working copy)
@@ -23,6 +23,12 @@
class RenderButton : public RenderBase
{
public:
+
+ enum ButtonType {
+ Regular,
+ UpperCorner,
+ };
+
RenderButton();
RenderBase * clone(Inset const *) const;
@@ -43,11 +49,13 @@
/// equivalent to dynamic_cast
virtual RenderButton * asButton() { return this; }
+ void setType(ButtonType type) { type_ = type; }
private:
/// The stored data.
docstring text_;
bool editable_;
Box button_box_;
+ ButtonType type_;
};
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
> > > + Bo* > > > + Jürgen* > > > - Uwe > > > - Jean-Marc > > + Martin* (until a better solution, e.g., tooltip) > - Enrico + Abdel There was a positive vote from Abdel. Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
> I think "Index: " plus a 25-char-string is too long (I actually think the > string should be shortened to 20 chars anyway). And remove the space after :. Bo
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
> + Martin* (until a better solution, e.g., tooltip) I agree. The easiest solution might be to add a checkbox somewhere to the preference dialog ... Bo
Wrong prompt for changes in the master document?
Dear all, I am experiencing something like this: 1. open a master document, 2. click on a child document and edit 3. save the child document and close lyx. Lyx thinks that the master document has unsaved changes and ask me if I want to save it. This is sort of scary because I have to ask myself if I have accidentally done anything to the master document ... Can anyone confirm? Is this a known bug? Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
> This is not what I meant. "Idx: " is not translateable because it is not a > word. The label should > have the name "Index" not "Idx". This could then be translated to different > languages, e.g to > "Índice" when you use Spanish menus. You have complained that the label of index inset is too long now, and you want to change 'Idx: ' to 'Index: '? I do not actually mind the change, so you can change it if Jurgen (and Jose for trunk) agrees. Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
> Why is this an advantage?
Because you do not have to click on the index to know the index key.
> We also don't show footnote text in the footnote label.
Because footnotes, ERT etc are long.
> Book indexes like the ones in the LyX docs don't have a "name"
??? The name is the index key.
> Instead of this, the aim should have been to make the label translateable.
> Therefore the label
> should have the name "Index" so that it could be translated in the .po-files
> (like we already for
> e.g. for the footnote label).
_("Idx") was translatable. I made a mistake and changed it to "Idx:"
and now it is translatable again: _("Idx: ").
> Besides this, I don't know why this could go to branch since there was no
> need for this change.
I have told you my story. I needed to change a bunch of "a b" to "b!a"
(making 'a' a sub entry for 'b'). After only a few changes back and
forth, I got lost and had to lick all indexes again to make sure the
changes have been done correctly. I was easy enough for me to change
lyx and showing the names in the label saved me a lot of time.
Cheers,
Bo
Re: [Cvslog] r20315 - in /lyx-devel/branches/BRANCH_1_5_X: src/insets/...
On 9/16/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > -return _("Idx");
> > +size_t const maxLabelChars = 25;
> > +
> > +docstring label = "Idx:" + getParam("name");
>
> However, "Idx" still should be translatable. And I would add a blank after the
> colon.
My mistake.
Fixed.
Bo
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
On 9/16/07, Jürgen Spitzmüller <[EMAIL PROTECTED]> wrote: > Bo Peng wrote: > > Is this something you want for branch? > > yes, why not. Done. Thanks. I needed to change some index labels from 'a b' to 'b!a' for my document and I quickly lost track of which indexes have been updated and which have not. The ability to make this change in 5 minutes demonstrates the real benefit of using an open source program. (Ohmm, normal users need to wait longer.. :-) Bo
Re: r20313 - /lyx-devel/trunk/src/insets/InsetIndex.cpp
> URL: http://www.lyx.org/trac/changeset/20313 > Log: > Display index name in InsetIndex label Jurgen: Is this something you want for branch? Bo
Re: Display index name in the label of InsetIndex?
> Hmmm, what does "name" stand for? The content of the inset, i.e., the > term being indexed? Yes. > So it will be up to 45 chars long, and if longer, cut it off with an > ellipsis. How much screen real estate will this eat, and is there a way > to prevent this? > > 45 is quite a lot. ERT uses 15, like Branch used to (not any more, > decoration type changed) I agree that 45 is quite long, but 15 seems to be short in some cases. I have used 25. Bo
Display index name in the label of InsetIndex?
Can I make the label of InsetIndex more meaningful by displaying
'Idx:name' instead of 'Idx'?
A simple patch is attached. I will commit it if there is no objection
in one day.
Bo
Index: src/insets/InsetIndex.cpp
===
--- src/insets/InsetIndex.cpp (revision 20301)
+++ src/insets/InsetIndex.cpp (working copy)
@@ -39,7 +39,14 @@
docstring const InsetIndex::getScreenLabel(Buffer const &) const
{
- return _("Idx");
+ unsigned int const maxLabelChars = 45;
+
+ docstring label = "Idx:" + getParam("name");
+ if (label.size() > maxLabelChars) {
+ label.erase(maxLabelChars-3);
+ label += "...";
+ }
+ return label;
}
Re: tex as lyx native file format
> > 2) I cannot use LyX anymore because when you write in a > > collaborarion a common format is needed and, de-facto, this is Latex, > > not lyx file format. Isn't this sad? You can try to convert your co-authors. If you are the first author, they do not need to know anything about lyx before they can revise your paper. Bo
Re: tex as lyx native file format
> Can make LyX work with TEX files as native document format? .lyx file stores more information than a .tex file can ever store. For example, the change-tracking feature can save changes and produce different output (different .tex files) with or without revision marks. The branch feature can save different 'versions' of the same document. The yet-to-come embedding .lyx file can save dependent files along with .lyx file. Using .tex as the native lyx format would seriously limit what lyx can do. Cheers, Bo
Re: Updating embedding dialog. Was: [Embedding PATCH] Update graphics dialog when the embedding status is changed.
> Signal in the core, dialogs connect to that... makes 3 lines of code > plus 1 per connecting dialog. The problem is where to emit the signal. If I do that at the inset level, and emit the signal whenever an inset is created, modified and removed, it may not be efficient because insets get created and destroyed all the time. It is not easy to do so after each edition either because it is hard to determine if an editing action involves an inset. Cheers, Bo
Updating embedding dialog. Was: [Embedding PATCH] Update graphics dialog when the embedding status is changed.
> I will commit if there is no objection. Done. I have only done this for InsetGraphics. Other insets like InsetExternal and InsetBibtex will wait. Now, the only problem left is when to update the embedding dialog. I am reluctant to implement a full auto-update facility, that update this dialog whenever an inset is created/destroyed/modified. I am not sure how to semi-auto, or manually update it either. Any suggestion is welcome. Bo
Re: [Embedding PATCH] Update graphics dialog when the embedding status is changed.
> The attached patch:
>
Here it is.
Bo
Index: src/insets/InsetGraphicsParams.h
===
--- src/insets/InsetGraphicsParams.h (revision 20282)
+++ src/insets/InsetGraphicsParams.h (working copy)
@@ -17,6 +17,7 @@
#include "graphics/GraphicsTypes.h"
#include "Length.h"
#include "support/FileName.h"
+#include "EmbeddedFiles.h"
namespace lyx {
@@ -31,7 +32,7 @@
{
public:
/// Image filename.
- support::DocFileName filename;
+ EmbeddedFile filename;
/// Scaling the Screen inside Lyx
unsigned int lyxscale;
/// How to display the image inside LyX
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp (revision 20282)
+++ src/insets/InsetGraphics.cpp (working copy)
@@ -192,9 +192,9 @@
Buffer const & buffer = cur.buffer();
InsetGraphicsParams p;
InsetGraphicsMailer::string2params(to_utf8(cmd.argument()), buffer, p);
- if (!p.filename.empty())
+ if (!p.filename.empty()) {
setParams(p);
- else
+ } else
cur.noUpdate();
break;
}
@@ -243,13 +243,11 @@
EmbeddedFile const & file)
{
BOOST_ASSERT(buf.embeddedFiles().enabled());
- LYXERR(Debug::FILES) << "Update InsetGraphics file from "
- << params_.filename.toFilesystemEncoding() << std::endl;
- params_.filename.set(file.availableFile(&buf), buf.filePath());
- LYXERR(Debug::FILES) << " to "
- << params_.filename.toFilesystemEncoding() << std::endl;
- // FIXME: graphics dialog is not updated even if the underlying
- // filename is updated. What should I do?
+ params_.filename = file;
+ LYXERR(Debug::FILES) << "Update InsetGraphic with File "
+ << params_.filename.toFilesystemEncoding()
+ << ", embedding status: "
+ << params_.filename.embedded() << std::endl;
}
@@ -305,7 +303,7 @@
if (it != buf.embeddedFiles().end())
// using available file, embedded or external, depending on file availability and
// embedding status.
- params_.filename = DocFileName(it->availableFile(&buf));
+ params_.filename = *it;
}
graphic_->update(params().as_grfxParams());
}
Index: src/insets/InsetGraphicsParams.cpp
===
--- src/insets/InsetGraphicsParams.cpp (revision 20282)
+++ src/insets/InsetGraphicsParams.cpp (working copy)
@@ -18,7 +18,6 @@
#include "Lexer.h"
#include "LyXRC.h"
#include "Buffer.h"
-#include "EmbeddedFiles.h"
#include "graphics/GraphicsParams.h"
@@ -154,15 +153,10 @@
void InsetGraphicsParams::Write(ostream & os, Buffer const & buffer) const
{
// Do not write the default values
-
if (!filename.empty()) {
- // when we save, we still use the original filename
- EmbeddedFiles::EmbeddedFileList::const_iterator it =
- buffer.embeddedFiles().find(filename.toFilesystemEncoding());
- if (it != buffer.embeddedFiles().end())
- os << "\tfilename " << DocFileName(it->absFilename()).outputFilename(buffer.filePath()) << '\n';
- else
- os << "\tfilename " << filename.outputFilename(buffer.filePath()) << '\n';
+ os << "\tfilename " << filename.outputFilename(buffer.filePath()) << '\n';
+ os << "\tinzipName " << filename.inzipName() << '\n';
+ os << "\tembed " << (filename.embedded() ? "true" : "false") << '\n';
}
if (lyxscale != 100)
os << "\tlyxscale " << lyxscale << '\n';
@@ -211,6 +205,12 @@
if (token == "filename") {
lex.eatLine();
filename.set(lex.getString(), bufpath);
+ } else if (token == "inzipName") {
+ lex.eatLine();
+ filename.setInzipName(lex.getString());
+ } else if (token == "embed") {
+ lex.next();
+ filename.setEmbed(lex.getBool());
} else if (token == "lyxscale") {
lex.next();
lyxscale = lex.getInteger();
Index: src/EmbeddedFiles.cpp
===
--- src/EmbeddedFiles.cpp (revision 20282)
+++ src/EmbeddedFiles.cpp (working copy)
@@ -468,7 +468,9 @@
EmbeddedFiles::EmbeddedFileList::const_iterator it = begin();
EmbeddedFiles::EmbeddedFileList::const_iterator it_end = end();
for (; it != it_end; ++it) {
- if (!it->valid())
+ // only saved 'extra' files. Other embedded files are saved
+ // with insets.
+ if (!it->valid() || it->refCount() > 0)
continue;
// save the relative path
os << "\\filename "
Index: src/frontends/qt4/GuiGraphics.cpp
===
--- src/frontends/qt4/GuiGraphics.cpp (revision 20282)
+++ src/frontends/qt4/GuiGraphics.cpp (working copy)
@@ -256,6 +256,7 @@
controller().browse(qstring_to_ucs4(filename->text()));
if(!str.empty()){
filename->setText(toqstr(str));
+ embedCB->setCheckState(Qt::Unchecked);
changed();
}
}
@@ -425,6 +426,7 @@
string const name =
igp.filename.outputFilename(controller().bufferFilepath());
filename->setText(toqstr(name));
+embedCB->setCheckState(igp.filename.embedded() ? Qt::Checked : Qt::Unchecked);
// set the bounding box values
if (igp.b
Re: [Embedding PATCH] Update graphics dialog when the embedding status is changed.
> Sounds like a plan? > The attached patch: 1. Use EmbeddedFile for InsetGraphicsParams::filename. This involves params2string and file format change. 2. Because InsetGraphics now has embedding information, it can be easily updated from the embedding dialog. The inset graphic dialog now has an embedding checkbox that display and set the embedding status of the inset. I will commit if there is no objection. Bo
Re: Modules Merge Complete
On 9/14/07, Richard Heck <[EMAIL PROTECTED]> wrote: > > With revision 20282, the merge of the layout modules material is > essentially complete. Please test away, and let me know of any problems. > Also, please have a look at the existing modules in lib/layout/ and > think creatively about what else it would be nice to have there. I've > got a few ideas (and patches) lying about, but I'm sure I'm thinking too > narrowly. Could you please, if you have not done so, update or add a chapter in User's Guide (or other document) how to use this feature? Bo
Re: file formats in pref dialog
> first iteration of the patch is attached and i am seeking comments on the > ui and code. I like the ui much better than the old one, I am not familiar with that part of the code so I will let others comment on the code. Bo
Re: [Embedding PATCH] Update graphics dialog when the embedding status is changed.
> Attached is an updated patch, which is even uglier because it tries to > display 'Embedded:/filename' in the graphic dialog when the file is > embedded. As you can imagine, back and forth translations are needed. I am actually waiting for someone to say ' this is way too ugly. Why do not you merge DocFileName and EmbeddedFile and let InsetGraphicsParams handle this by itself?' The actual problem is then, due to the way param2string and InsetGraphicsParams::write() is implemented, changing InsetGraphicsParams implies file format change. I actually like the idea to add inzipName etc to DocFileName because Embedding needs to be handled in all places where DocFileName is used. Then, embedding status will be saved along with insets, and the manifest section will only have extra embedded files. Sounds like a plan? Bo
Re: Approaching LyX 1.5.2 [status update #2]
> cri crash when cursor position in session file becomes invalid > > Bo, do you have an idea? I am not aware of this bug, I will have a look when I get a chance. Bo
Re: Master Preview
On 9/14/07, Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > > One question: Why don't we make this the default? I mean that the > > present binding will always work with the master document. This means > > that new binding should be created for child documents. I personally > > would prefer this behaviour a lot because, thanks to the integerated > > outline I don't have to wonder anymore if I am in a child document or > > not. > > Very good point actually. A child-buffer-view lfun would make more > sense. No. The whole idea of separating chapters from a book is that I can compile and view the chapters *quicker*. I do not want to compile the whole book when I am working on a chapter. I still do not see what is so difficult to go to the master buffer and view. Bo
Re: [Embedding PATCH] Update graphics dialog when the embedding status is changed.
> Here is a question for you: Do you want to display true, embedded
> filename, or the may-not-exist external filename in the graphics
> dialog? The attached patch does the former, but in a ugly way:
>
Attached is an updated patch, which is even uglier because it tries to
display 'Embedded:/filename' in the graphic dialog when the file is
embedded. As you can imagine, back and forth translations are needed.
Bo
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp (revision 20269)
+++ src/insets/InsetGraphics.cpp (working copy)
@@ -248,8 +248,6 @@
params_.filename.set(file.availableFile(&buf), buf.filePath());
LYXERR(Debug::FILES) << " to "
<< params_.filename.toFilesystemEncoding() << std::endl;
- // FIXME: graphics dialog is not updated even if the underlying
- // filename is updated. What should I do?
}
Index: src/insets/InsetGraphicsParams.cpp
===
--- src/insets/InsetGraphicsParams.cpp (revision 20269)
+++ src/insets/InsetGraphicsParams.cpp (working copy)
@@ -157,6 +157,9 @@
if (!filename.empty()) {
// when we save, we still use the original filename
+ // This ensures that the external filename will be written
+ // to .lyx file, but causes trouble in graphics dialog update
+ // In that dialog, true filename has to be displayed.
EmbeddedFiles::EmbeddedFileList::const_iterator it =
buffer.embeddedFiles().find(filename.toFilesystemEncoding());
if (it != buffer.embeddedFiles().end())
Index: src/frontends/qt4/GuiGraphics.cpp
===
--- src/frontends/qt4/GuiGraphics.cpp (revision 20269)
+++ src/frontends/qt4/GuiGraphics.cpp (working copy)
@@ -56,6 +56,9 @@
namespace lyx {
+
+using support::DocFileName;
+
namespace frontend {
@@ -253,7 +256,7 @@
void GuiGraphicsDialog::on_browsePB_clicked()
{
docstring const str =
- controller().browse(qstring_to_ucs4(filename->text()));
+ controller().browse(controller().translateFileName(qstring_to_ucs4(filename->text(;
if(!str.empty()){
filename->setText(toqstr(str));
changed();
@@ -422,9 +425,8 @@
break;
}
- string const name =
- igp.filename.outputFilename(controller().bufferFilepath());
- filename->setText(toqstr(name));
+ // this file may be embedded
+ filename->setText(toqstr(controller().displayFileName()));
// set the bounding box values
if (igp.bb.empty()) {
@@ -569,7 +571,7 @@
{
InsetGraphicsParams & igp = controller().params();
- igp.filename.set(internal_path(fromqstr(filename->text())),
+ igp.filename.set(internal_path(controller().translateFileName(fromqstr(filename->text(,
controller().bufferFilepath());
// the bb section
@@ -663,7 +665,7 @@
void GuiGraphicsDialog::getBB()
{
- string const fn = fromqstr(filename->text());
+ string const fn = controller().translateFileName(fromqstr(filename->text()));
if (!fn.empty()) {
string const bb = controller().readBB(fn);
if (!bb.empty()) {
Index: src/frontends/controllers/ControlEmbeddedFiles.cpp
===
--- src/frontends/controllers/ControlEmbeddedFiles.cpp (revision 20269)
+++ src/frontends/controllers/ControlEmbeddedFiles.cpp (working copy)
@@ -111,6 +111,9 @@
else
item.extract(&buffer());
item.updateInsets(&buffer());
+ // FIXME: unless we record the type of file item, we will
+ // need to update all possible dialogs (bibtex etc).
+ updateDialog("graphics");
}
if (embed)
dispatchMessage("Embed file " + item.outputFilename(buffer().filePath()));
Index: src/frontends/controllers/ControlGraphics.h
===
--- src/frontends/controllers/ControlGraphics.h (revision 20269)
+++ src/frontends/controllers/ControlGraphics.h (working copy)
@@ -61,6 +61,13 @@
bool isFilenameValid(std::string const & fname) const;
/// edit file
void editGraphics();
+ /// in case that the file is embedded, we need to display
+ /// its embedded filename in the form of Embed::
+ /// Note that params() always holds the external filename.
+ std::string const displayFileName() const;
+ /// translate Embedd:: filename to a valid one.
+ docstring const translateFileName(docstring const &) const;
+ std::string const translateFileName(std::string const &) const;
private:
///
Index: src/frontends/controllers/ControlGraphics.cpp
===
--- src/frontends/controllers/ControlGraphics.cpp (revision 20269)
+++ src/frontends/controllers/ControlGraphics.cpp (working copy)
@@ -18,6 +18,8 @@
#include "FuncRequest.h"
#include "gettext.h"
#include "LyXRC.h"
+#include "Buffer.h"
+#include "EmbeddedFiles.h"
#include "graphics/GraphicsCache.h"
#include "graphics/GraphicsCacheItem.h"
@@ -30,6 +32,7 @@
#include "support/filetools.h"
#include "su
Re: Master Preview
> I find it useful. Maybe others too. It is useful, but it is not so difficult to switch to the master buffer and generate preview from there. We already have many items under the View menu, and a shortcut-only hidden feature is not that appealing. Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> still think that an autogenerated properties dialog will be even better > though... This is exactly what I proposed. > the information you have put now in ParValidator::ParValidator() could > be parsed to build the dialog Yes. > if there are a lot of parameters as with listing i am sure they can be > grouped to have a better overview You can certainly group things. The whole idea is not that difficult, we simply need a few text files with fields like parameter name, group name, type, hint, default value, validation type, validation parameter Then, a property list like what qt designer has can be generated using this list. The user can change the options and the dialog would return an option list. Some code can be borrowed from InsetListingsParams. However, this is very Qt/Gui intensive and I certainly do not have the needed knowledge to do it. As a matter of fact, I asked help for similar things when I design the listing dialog but everyone was busy. Cheers, Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> We call it consistent behaviour. ;-) Then we can implement a 'compose' dialog, that 1. Option [params ] Compose_Button 2. When the compose button is pressed, dialog 'compose listings/hyperref/whatever options' is triggered. 3. This dialog has all the validation facilities and hints to help the user create an option list. Different packages can use this facility using potentially external definition files. What do you think? Bo
[Embedding PATCH] Update graphics dialog when the embedding status is changed.
Here is a question for you: Do you want to display true, embedded
filename, or the may-not-exist external filename in the graphics
dialog? The attached patch does the former, but in a ugly way:
1. call updateDialog("graphics"); in setEmbed().
LFUN_INSET_DIALOG_UPDATE is triggered as expected.
2. params2string uses *external filename*, using EmbeddedFiles()'s
look up facility, because it is the same function used to write to
.lyx file.
3. In GuiGraphics.cpp, params().filename has to be converted to
embedded filename again.
Also, we do not really want to display '/tmp/adfdf223234234/filename'.
Some more lines are needed to display "Embedded:filename".
Bo
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp (revision 20261)
+++ src/insets/InsetGraphics.cpp (working copy)
@@ -248,8 +248,6 @@
params_.filename.set(file.availableFile(&buf), buf.filePath());
LYXERR(Debug::FILES) << " to "
<< params_.filename.toFilesystemEncoding() << std::endl;
- // FIXME: graphics dialog is not updated even if the underlying
- // filename is updated. What should I do?
}
Index: src/insets/InsetGraphicsParams.cpp
===
--- src/insets/InsetGraphicsParams.cpp (revision 20261)
+++ src/insets/InsetGraphicsParams.cpp (working copy)
@@ -157,6 +157,9 @@
if (!filename.empty()) {
// when we save, we still use the original filename
+ // This ensures that the external filename will be written
+ // to .lyx file, but causes trouble in graphics dialog update
+ // In that dialog, true filename has to be displayed.
EmbeddedFiles::EmbeddedFileList::const_iterator it =
buffer.embeddedFiles().find(filename.toFilesystemEncoding());
if (it != buffer.embeddedFiles().end())
Index: src/frontends/qt4/GuiGraphics.cpp
===
--- src/frontends/qt4/GuiGraphics.cpp (revision 20261)
+++ src/frontends/qt4/GuiGraphics.cpp (working copy)
@@ -56,6 +56,9 @@
namespace lyx {
+
+using support::DocFileName;
+
namespace frontend {
@@ -422,8 +425,9 @@
break;
}
- string const name =
- igp.filename.outputFilename(controller().bufferFilepath());
+ // this file may be embedded
+ DocFileName const & af = controller().availableFile(igp.filename);
+ string const name = af.outputFilename(controller().bufferFilepath());
filename->setText(toqstr(name));
// set the bounding box values
Index: src/frontends/controllers/ControlEmbeddedFiles.cpp
===
--- src/frontends/controllers/ControlEmbeddedFiles.cpp (revision 20262)
+++ src/frontends/controllers/ControlEmbeddedFiles.cpp (working copy)
@@ -111,6 +111,9 @@
else
item.extract(&buffer());
item.updateInsets(&buffer());
+ // FIXME: unless we record the type of file item, we will
+ // need to update all possible dialogs (bibtex etc).
+ updateDialog("graphics");
}
if (embed)
dispatchMessage("Embed file " + item.outputFilename(buffer().filePath()));
Index: src/frontends/controllers/ControlGraphics.h
===
--- src/frontends/controllers/ControlGraphics.h (revision 20261)
+++ src/frontends/controllers/ControlGraphics.h (working copy)
@@ -18,6 +18,7 @@
#include "Dialog.h"
#include "support/docstring.h"
+#include "support/FileName.h"
#include
#include
@@ -61,6 +62,10 @@
bool isFilenameValid(std::string const & fname) const;
/// edit file
void editGraphics();
+ /// in case that the file is embedded, we need to display
+ /// its embedded filename. Note that params() always holds
+ /// the external filename.
+ support::DocFileName const availableFile(support::DocFileName const &) const;
private:
///
Index: src/frontends/controllers/ControlGraphics.cpp
===
--- src/frontends/controllers/ControlGraphics.cpp (revision 20261)
+++ src/frontends/controllers/ControlGraphics.cpp (working copy)
@@ -18,6 +18,8 @@
#include "FuncRequest.h"
#include "gettext.h"
#include "LyXRC.h"
+#include "Buffer.h"
+#include "EmbeddedFiles.h"
#include "graphics/GraphicsCache.h"
#include "graphics/GraphicsCacheItem.h"
@@ -45,6 +47,7 @@
using support::addName;
using support::FileFilterList;
using support::FileName;
+using support::DocFileName;
using support::isFileReadable;
using support::makeAbsPath;
using support::package;
@@ -149,6 +152,16 @@
}
+DocFileName const ControlGraphics::availableFile(DocFileName const & filename) const
+{
+ EmbeddedFiles const & files = buffer().embeddedFiles();
+ EmbeddedFiles::EmbeddedFileList::const_iterator it = files.find(filename.absFilename());
+ if (it != files.end())
+ return DocFileName(it->availableFile(&buffer()));
+ return filename;
+}
+
+
namespace {
char const * const bb_units[] = { "bp", "cm", "mm", "in" };
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> We call it consistent behaviour. ;-) > > Note that the problem happens as well for other packages. Again it would be > nice to have a general solution. The point is not to look prettier but to > have the same look and feel everywhere, the principle of least surprise. (not > sure if this is the right name) You know how much time I spent on this validation system, and on the AUTO embedding feature? I seem to over-shot my features a lot. :-( Bo
Re: [Cvslog] r20253 - in /lyx-devel/trunk/src/frontends: controllers/C...
> 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
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> > i would prefer a simple lineedit as with the document class options > > and would expect people who use this functionality to read the > > listings documentation. > > > > so i do not see the urgency of validating the input and duplicating > > the documentation in a separate hints window. we don't do that with > > the document options either. > > +1 So you guys are willing to remove validation and allow the input of arbitrary (wrong) parameters, just to make the dialog look prettier? Bo
Re: [Cvslog] r20253 - in /lyx-devel/trunk/src/frontends: controllers/C...
> > 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 LFUN_UPDATE_EMBEDDED_FILE file and maybe LFUN_ENABLE_BUNDLE on/off I have not really though of this so this is just some rough idea. > >> What happens when the document is read-only? Do you allow embedding? > > > > Currently, yes, and this is a bug. > > An lfun would spare this and the mark-dirty code ;) Yes. I know... I have fixed this in a dirty way. I guess when embedding is completed, we can talk about how *exactly* embedding should behave, and better implementations. Bo
Re: [Cvslog] r20253 - in /lyx-devel/trunk/src/frontends: controllers/C...
> 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? Do you allow embedding? Currently, yes, and this is a bug. Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> now there is a big textedit with an ugly "documentation" field next to it and > that i don't like so much: If you can think of a better-looking alternative to display hints and error messages, I will be quite happy to change that. (I do not like that very much either) Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
On 9/12/07, José Matos <[EMAIL PROTECTED]> wrote: > On Wednesday 12 September 2007 15:12:55 Bo Peng wrote: > > > Another way is to just have the most interesting options, and > > > a text entry field for the rest. Much cleaner, but with the > > > disadvantage that that users can enter latex-crashing > > > syntax errors in the entry field. > > > > This is what listings is doing. > > And not one of the brightest faces of the listing support. :-) But there is no way to GUI'ify all 163 listings parameters. > In a sense it is to bare to lyx. IMHO we need to improve that. > The label is not on line with labels on lyx and that is ugly. :-( I do not know what you refer to here. Bo
Re: 1.5.X patch candidate list #2
> Jürgen, do you think we have enough patches for 1.5.2? I hope that listings caption can be fixed before 1.5.2 is released. Bo
Re: r20240 - in /lyx-devel/trunk/src: EmbeddedFiles.cpp Embed...
On 9/12/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > [EMAIL PROTECTED] wrote: > > Author: bpeng > > Date: Wed Sep 12 16:27:47 2007 > > New Revision: 20240 > > > > URL: http://www.lyx.org/trac/changeset/20240 > > Log: > > Embedding: update related insets when the embedding status of a fileitem is > > changed > > > +void EmbeddedFile::updateInsets(Buffer const * buf) const > > Why is this const? You mean this function? This function does not change anything in EmbeddedFiles, it changes the insets. > > Why did you use "Inset const *" as the base element type if you are > going to modify it? I'd say remove the const and use that: > > vector::iterator > Good question. I remember that the problem was that when I save these insets in update(), the passed Buffer * is const so I had to save Inset const *. Of course, the question is whether I should use const_cast in update() (before they are saved), or updateInsets() (after they are saved). > > +void EmbeddedFiles::updateInsets() const > > Same question, why const? Save answer. Bo
Re: file formats in pref dialog
> the attached changes the looks of the file formats panel in the preferences > dialog to this: > > http://leuven.ecodip.net/lyx/lyx.png > Why do we need this modify button? Why cannot we simply change, and allow for save/cancel/restore as we do in other cases? Bo
Re: [Embedding PATCH] update insets after the embedding status is changed
> This adds another virtual function to Inset, so I need at least one OK. Jose? Committed. Bo
Re: Lyx/branch crashes during exit.
> The attached patch should solve the problem. As the added fonts are > application specific, fontconfig should do the cleanup for us, even > if the docs say nothing to this end. I tested this patch against the branch and I can confirm that it fixes the crash. You should explain to Jurgen what this patch does and put it to branch (and trunk). Cheers, Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> Yes, this package has many options, and it seems many of them are > actually used too. I find it nice not having to use ERT to use > a package when LyX supports it. Especially for people with no > latex background. True. > If we want to support many hyperref options, then a tabbed > dialog might be in order. With the most used options on the first > page, and less used options grouped on the other pages. Colors > for links could be one such secondary page. This is not feasible in thie settings dialog. > Another way is to just have the most interesting options, and > a text entry field for the rest. Much cleaner, but with the > disadvantage that that users can enter latex-crashing > syntax errors in the entry field. This is what listings is doing. > Some simple syntex checking can be done, it seems that these > options always is a comma-separated list of key=value pairs, > with the value possibly containing balanced braces. I think much of the logics/code can be copied from InsetListingsParams. Bo
Re: Lyx/branch crashes during exit.
> I will compile with gcc 4 and try again. Gcc4 + Qt 422 crashes. Gcc4 + Qt 4.0 (or 4.11? not sure) does not. Have not tested Gcc 3 + Qt 4.0, but it is likely a Qt 422 problem. Bo
Re: Lyx/branch crashes during exit.
> I should have said, using Qt 4.2.1, so this code is being compiled. Then this might be another gcc 3 / signals problem. :-) I will compile with gcc 4 and try again. Bo
Lyx/branch crashes during exit.
On linux, simply start and quit lyx.
Backtrace:
#0 0x003412512838 in FcConfigSetFonts ()
from /usr/lib64/libfontconfig.so.1
#1 0x002a95c67267 in QFontDatabase::removeApplicationFont (handle=0)
at text/qfontdatabase_x11.cpp:1959
#2 0x0086a7a6 in ~GuiFontLoader (this=0xf13cb8)
at src/frontends/qt4/GuiFontLoader.cpp:235
#3 0x00863ed9 in ~GuiApplication (this=0xf13bb0)
at
/usr/lib/gcc/x86_64-redhat-linux/3.4.6/../../../../include/c++/3.4.6/bits/stl_tree.h:558
#4 0x00445aa1 in boost::scoped_ptr::reset
(this=0xf0e2b8, p=0x0) at boost/boost/checked_delete.hpp:34
#5 0x0042d15a in lyx::LyX::prepareExit (this=0x7fb380)
at boost/boost/scoped_ptr.hpp:93
#2 points to
GuiFontLoader::~GuiFontLoader()
{
#if QT_VERSION >= 0x040200
for (int i = 0 ; i < num_math_fonts; ++i) {
if (fontID[i] >= 0)
QFontDatabase::removeApplicationFont(fontID[i]);
}
delete [] fontID;
#endif
}
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
On 9/11/07, Pavel Sanda <[EMAIL PROTECTED]> wrote: > > 1. "PDF support" may not be the best name. I am thinking of "Document > > Properties", but "Hyperref Support" may be clearer. > > users with a little knowledge of latex will not understand Hyperref Support. > Document Properties is too general. we can change the naming, but still > i think that the keyword "pdf" should be incorporated somehow. PDF Properties? > > 3. pagebackref, pageref, bookmark etc should be more verbal. > > suggestions ? (there are already more verbal tooltips) Something like "Add backlink to bibliographic items", "Generate bookmark links" etc. Cheers, Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> http://wiki.lyx.org/uploads/DevelDoc/pdfsupport.gif > that is the current state on my local branch. still receiving additional > requests :) Nice dialog. I think 1. "PDF support" may not be the best name. I am thinking of "Document Properties", but "Hyperref Support" may be clearer. 2. This page should be put before preamble, which means the *last* and ultimate method of customization. I am thinking of "Document Properties" after "Document class" or "Hyperref Support" after Bibliography. 3. pagebackref, pageref, bookmark etc should be more verbal. Cheers, Bo
Re: [Patch] Bug 3527 - Basic PDF support via hyperref
> i have basic working skeleton for bug 3527; now there is only minimal set of > supported features, but i'll add others, when you won't opose the general > construction of this code. i would like to ask : Nice work! > 1) is it possible to add hyperref support to 1.6 series (Jose?) As long as you can complete the feature before 1.6 is released, so I guess the answer is yes. > 2) can somebody review this code and comment what should be done >otherwise and mainly what i forgot to do. I have a quick look at the patch, and have one question though: why do you use separate file for PDFOptions.h|cpp? I guess it can be merged to BufferParams. > 3) what features you would like to have from hyperref ? Have not tried your patch... > 3) is there something needed for lyx2lyx support ? Remove these options with back conversion. > 4) adding others things like keywords, checkboxes for working bookmarks and > references. I guess I also want 'fullscreen' mode for presentation. Cheers, Bo
Re: Embedding feature slows down updateLabels() very significantly!
> I am not quite sure what is > the best way to do this though. With a patch that I just submitted for review, this is the last major problem that needs to be resolved. Basically, I need to call EmbeddedFiles::update() (or emit embeddingChanged() signal) when an inset that has embedded files is created/removed/modified. Do you have any good idea? I am not against the idea of an 'update' button that forces the update. This will be most efficient. Cheers, Bo
Re: Embedding feature slows down updateLabels() very significantly!
On 9/11/07, Abdelrazak Younes <[EMAIL PROTECTED]> wrote: > I think... I have not done any profiling but this is possible. Because EmbeddedFiles now saves inset pointers (not ParConstIterator), EmbeddedFiles::update() should be moved out of updateLabels() and iscalled with inset addition and removal. I am not quite sure what is the best way to do this though. Cheers, Bo
[Embedding PATCH] update insets after the embedding status is changed
The attached patch
1. add Inset::updateEmbeddedFile, that will be called after the
embedding status of a file is changed. A typical use is
+void InsetGraphics::updateEmbeddedFile(Buffer const & buf,
+ EmbeddedFile const & file)
+{
+ params_.filename.set(file.availableFile(&buf), buf.filePath());
+}
The problem here is that even if the underlying filename is changed,
the Graphic dialog is not updated. Does anyone know how to do this?
2. add EmbeddedFile::updateInsets(Buffer&) and
EmbeddedFiles::updateInsets() to update related insets.
+void EmbeddedFile::updateInsets(Buffer const * buf) const
+{
+ vector::const_iterator it = inset_list_.begin();
+ vector::const_iterator it_end = inset_list_.end();
+ for (; it != it_end; ++it)
+ const_cast(*it)->updateEmbeddedFile(*buf, *this);
+}
+
3. call updateInsets at appropriate times. Such as when embedding is
enabled, and when a file embedding status is changed. Because stored
inset pointers are not guranteed to be up to date,
EmbeddedFiles::update() is called before such calls.
This adds another virtual function to Inset, so I need at least one OK. Jose?
Bo
Index: src/insets/InsetGraphics.h
===
--- src/insets/InsetGraphics.h (revision 20211)
+++ src/insets/InsetGraphics.h (working copy)
@@ -80,6 +80,8 @@
bool getStatus(Cursor &, FuncRequest const &, FuncStatus &) const;
/// all graphics can be embedded
void registerEmbeddedFiles(Buffer const &, EmbeddedFiles &) const;
+ ///
+ void updateEmbeddedFile(Buffer const &, EmbeddedFile const &);
protected:
InsetGraphics(InsetGraphics const &);
///
Index: src/insets/InsetGraphics.cpp
===
--- src/insets/InsetGraphics.cpp (revision 20211)
+++ src/insets/InsetGraphics.cpp (working copy)
@@ -239,6 +239,20 @@
}
+void InsetGraphics::updateEmbeddedFile(Buffer const & buf,
+ EmbeddedFile const & file)
+{
+ BOOST_ASSERT(buf.embeddedFiles().enabled());
+ LYXERR(Debug::FILES) << "Update InsetGraphics file from "
+ << params_.filename.toFilesystemEncoding() << std::endl;
+ params_.filename.set(file.availableFile(&buf), buf.filePath());
+ LYXERR(Debug::FILES) << " to "
+ << params_.filename.toFilesystemEncoding() << std::endl;
+ // FIXME: graphics dialog is not updated even if the underlying
+ // filename is updated. What should I do?
+}
+
+
void InsetGraphics::edit(Cursor & cur, bool)
{
InsetGraphicsMailer(*this).showDialog(&cur.bv());
Index: src/insets/Inset.h
===
--- src/insets/Inset.h (revision 20211)
+++ src/insets/Inset.h (working copy)
@@ -49,6 +49,7 @@
class ParIterator;
class Text;
class TocList;
+class EmbeddedFile;
class EmbeddedFiles;
@@ -441,6 +442,8 @@
virtual void addToToc(TocList &, Buffer const &, ParConstIterator const &) const {}
/// report files that can be embedded with the lyx file
virtual void registerEmbeddedFiles(Buffer const &, EmbeddedFiles &) const {};
+ /// use embedded or external file after the embedding status of a file is changed
+ virtual void updateEmbeddedFile(Buffer const &, EmbeddedFile const &) {}
/// Fill keys with BibTeX information
virtual void fillWithBibKeys(Buffer const &,
BiblioInfo &, InsetIterator const &) const { return; }
Index: src/EmbeddedFiles.cpp
===
--- src/EmbeddedFiles.cpp (revision 20212)
+++ src/EmbeddedFiles.cpp (working copy)
@@ -225,6 +225,15 @@
}
+void EmbeddedFile::updateInsets(Buffer const * buf) const
+{
+ vector::const_iterator it = inset_list_.begin();
+ vector::const_iterator it_end = inset_list_.end();
+ for (; it != it_end; ++it)
+ const_cast(*it)->updateEmbeddedFile(*buf, *this);
+}
+
+
bool EmbeddedFiles::enabled() const
{
return buffer_->params().embedded;
@@ -241,6 +250,8 @@
// if operation is successful
buffer_->markDirty();
buffer_->params().embedded = flag;
+ if (flag)
+ updateInsets();
}
}
@@ -468,4 +479,14 @@
}
+void EmbeddedFiles::updateInsets() const
+{
+ EmbeddedFiles::EmbeddedFileList::const_iterator it = begin();
+ EmbeddedFiles::EmbeddedFileList::const_iterator it_end = end();
+ for (; it != it_end; ++it)
+ if (it->valid() && it->refCount() > 0)
+ it->updateInsets(buffer_);
}
+
+
+}
Index: src/frontends/controllers/ControlEmbeddedFiles.cpp
===
--- src/frontends/controllers/ControlEmbeddedFiles.cpp (revision 20213)
+++ src/frontends/controllers/ControlEmbeddedFiles.cpp (working copy)
@@ -89,6 +89,7 @@
item.updateFromExternalFile(&buffer());
else
item.extract(&buffer());
+ item.updateInsets(&buffer());
}
}
Index: src/EmbeddedFiles.h
===
--- src/EmbeddedFiles.h (revision 20212)
+++ src/EmbeddedFiles.h (working copy)
@@ -155,6 +155,1
Re: [Embedding discussion 2] Data structure of embedded files.
> Using a map for this purpose would fit exactly. If you > need also the reverse translation then it might not be the best fit > anymore There are reverse translations. The problem is that *both* names have to be checked because EmbeddedFiles does not know in advance which name will be checked. > I would design the interface in such a way that it is always clear which > name has to be used. IMO there are three types of names: > > - always embedded > - always external > - depending on the embedded status of that inset, either external or > embedded. This is the case now. > I would prefer to have each file only once. It does not make sense to me to > allow to embed a file for one inset, but then say in another inset that > also uses the same file to not embed it. That is a contradiction that > should not exist IMO. This is the case now. Multiple insets can be related to the same file; and if the embedding status of a file is changed, all insets are affected. Cheers, Bo
Re: 1.5.X patch candidates - next iteration
> > http://www.lyx.org/trac/changeset/19472 - fix crash after assertion when > > using %s with integer arguments > > Someone with checked-out branch should just apply that. Done. r20199. Bo
Re: [Embedding PATCH] Add manifest to .lyx file itself.
> > string filename = ""; > > string inzipName = ""; > > string filename; > string inzipName; > > Shorter, quicker, equivalent. Got it. Thanks. :-) Bo
Re: 1.5.X patch candidates - next iteration
> http://www.lyx.org/trac/changeset/19916 - Save the right timestamp and > checksum of an opened file. Already done. > http://www.lyx.org/trac/changeset/20039 - Fix bug 4193 Revert ask for > saving file before closing Already done. > http://www.lyx.org/trac/changeset/20093 - Forgot this: windows backslash > needs special treatment > http://www.lyx.org/trac/changeset/20094 - Fix previous commit. I really > do not understand why windows FileName() can not have backslash > (assertion at line 49 of support/FileName.cpp) Not for 1.5.x. (Actually they are, but I am too lazy to maintain scons for 1.5.x as long as it works). Bo
Re: [Embedding PATCH] Add manifest to .lyx file itself.
> Then what remains is whether or not you want to move embedded_files_
> to BufferParams. I am neutral about this.
Latest patch attached. Can I apply?
Cheers,
Bo
Index: src/EmbeddedFiles.cpp
===
--- src/EmbeddedFiles.cpp (revision 20193)
+++ src/EmbeddedFiles.cpp (working copy)
@@ -286,7 +286,7 @@
}
-bool EmbeddedFiles::write(DocFileName const & filename)
+bool EmbeddedFiles::writeFile(DocFileName const & filename)
{
// file in the temporary path has the content
string const content = FileName(addName(buffer_->temppath(),
@@ -406,7 +406,7 @@
file_list_.clear();
string filename = "";
string inzipName = "";
- bool status = "";
+ bool embedded = false;
while (lex.isOK()) {
lex.next();
@@ -431,9 +431,9 @@
lex >> filename;
else if (token == "\\inzipName")
lex >> inzipName;
- else if (token == "\\status") {
- lex >> status;
- registerFile(filename, status, NULL, inzipName);
+ else if (token == "\\embed") {
+ lex >> embedded;
+ registerFile(filename, embedded, NULL, inzipName);
filename = "";
inzipName = "";
} else {
@@ -463,7 +463,7 @@
<< to_utf8(makeRelPath(from_utf8(it->absFilename()),
from_utf8(buffer_->filePath( << '\n'
<< "\\inzipName " << it->inzipName() << '\n'
- << "\\status " << (it->embedded() ? "true" : "false") << '\n';
+ << "\\embed " << (it->embedded() ? "true" : "false") << '\n';
}
}
Index: src/EmbeddedFiles.h
===
--- src/EmbeddedFiles.h (revision 20193)
+++ src/EmbeddedFiles.h (working copy)
@@ -77,7 +77,7 @@
3. When a lyx file file.lyx is saved, it is save to tmppath() first.
Embedded files are compressed along with file.lyx and a manifest.txt.
If embedding is disabled, file.lyx is saved in the usual pure-text form.
-(c.f. Buffer::writeFile(), EmbeddedFiles::write())
+(c.f. Buffer::writeFile(), EmbeddedFiles::writeFile())
4. When a lyx file.lyx file is opened, if it is a zip file, it is
decompressed to tmppath(). If manifest.txt and file.lyx exists in
@@ -199,7 +199,7 @@
void update();
/// write a zip file
- bool write(support::DocFileName const & filename);
+ bool writeFile(support::DocFileName const & filename);
void clear() { file_list_.clear(); }
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 20193)
+++ src/Buffer.cpp (working copy)
@@ -142,7 +142,7 @@
namespace {
-int const LYX_FORMAT = 284;
+int const LYX_FORMAT = 285;
} // namespace anon
@@ -559,7 +559,10 @@
"\\lyxadded and \\lyxdeleted in the LaTeX preamble."));
}
}
+ // read manifest after header
+ embeddedFiles().readManifest(lex, errorList);
+ // read main text
bool const res = text().read(*this, lex, errorList);
for_each(text().paragraphs().begin(),
text().paragraphs().end(),
@@ -661,12 +664,9 @@
LYXERR(Debug::FILES) << filename << " is in zip format. Unzip to " << temppath() << endl;
::unzipToDir(filename.toFilesystemEncoding(), temppath());
//
- FileName manifest(addName(temppath(), "manifest.txt"));
- FileName lyxfile(addName(temppath(),
- onlyFilename(filename.toFilesystemEncoding(;
+ FileName lyxfile(addName(temppath(), "content.lyx"));
// if both manifest.txt and file.lyx exist, this is am embedded file
- if (fs::exists(manifest.toFilesystemEncoding()) &&
- fs::exists(lyxfile.toFilesystemEncoding())) {
+ if (fs::exists(lyxfile.toFilesystemEncoding())) {
params().embedded = true;
fname = lyxfile;
}
@@ -889,8 +889,7 @@
FileName content;
if (params().embedded)
// first write the .lyx file to the temporary directory
- content = FileName(addName(temppath(),
- onlyFilename(fname.toFilesystemEncoding(;
+ content = FileName(addName(temppath(), "content.lyx"));
else
content = fname;
@@ -910,9 +909,8 @@
if (retval && params().embedded) {
// write file.lyx and all the embedded files to the zip file fname
- // if embedding is enabled, and there is any embedded file
- pimpl_->embedded_files.update();
- return pimpl_->embedded_files.write(fname);
+ // if embedding is enabled
+ return pimpl_->embedded_files.writeFile(fname);
}
return retval;
}
@@ -951,6 +949,12 @@
params().writeFile(ofs);
ofs << "\\end_header\n";
+ // write the manifest after header
+ ofs << "\n\\begin_manifest\n";
+ pimpl_->embedded_files.update();
+ embeddedFiles().writeManifest(ofs);
+ ofs << "\\end_manifest\n";
+
// write the text
ofs << "\n\\begin_body\n";
text().write(*this, ofs);
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (revision 20193)
+++ lib/lyx2lyx/LyX.py (working copy)
@@ -78,7 +78,7 @@
("1_3", [221], generate_minor_versions("1.3" , 7)),
("1_4", range(222,246), generate_minor_versions("1.4" , 5)),
("1_5", ran
Re: LyX 1.5.1 crashes on SUSE 10.2: resolved
> Which reminds me of another yet-unstarted battle: Do we really want > hard crashs as the prefered way to tell the user that there is something > wrong in Denmark? I have long thought of this. Many internal errors does not really prevent lyx from functioning, but lyx simply crashes without even a proper error message. For example, if a cursor can not be placed correctly, or if undo fails, lyx should continue to work. I think this is a consequence of lyx' refusal to use try/catch exceptions in the past, and is something that should be addressed. To be dramatic, all BOOST_ASSERT should be ignored in the release mode... Bo
Re: LyX 1.5.1 crashes on SUSE 10.2: resolved
> What I can see here is that we need better error messages.
And I meant something like the follows. Because boost does not report
the file it fails to check, it would be nice to report such
information.
Cheers,
Index: src/support/filetools.cpp
===
--- src/support/filetools.cpp (revision 20191)
+++ src/support/filetools.cpp (working copy)
@@ -163,7 +163,12 @@
bool isFileReadable(FileName const & filename)
{
std::string const path = filename.toFilesystemEncoding();
- return fs::exists(path) && !fs::is_directory(path) &&
fs::is_readable(path);
+ try {
+ return fs::exists(path) && !fs::is_directory(path) &&
fs::is_readable(path);
+ } catch(...) {
+ lyxerr << "Failed to check file " << path << std::endl;
+ throw;
+ }
}
Re: LyX 1.5.1 crashes on SUSE 10.2: resolved
> 'boost::filesystem::basic_filesystem_error boost::filesystem::path_traits> >' > what(): boost::filesystem::exists > Aborted What I can see here is that we need better error messages. Bo
Re: [Embedding PATCH] Add manifest to .lyx file itself.
> > Looking at the code in Buffer.cpp, I do not think this is a good idea:
> >
> > Write:
> > // now write out the buffer parameters.
> > ofs << "\\begin_header\n";
> > params().writeFile(ofs);
> > ofs << "\\end_header\n";
> >
> > Read:
> > while (lex.isOK()) {
> > string unknown = params().readToken(lex, token);
> > if (!unknown.empty()) {
> >
> > You can see that header <==> params() so unless I move embedded_files_
> > to params(), this does not look right.
>
> I know and that is my point. :-)
> Do you disagree?
Moving Buffer::pimpl_::embedded_files_ to BufferParams is not
particularly difficult, but I do not see any benefit either.
> > +# LyX file format <= 284 does not have a manifest section
> > +# so this section is set to None
> > +if self.manifest is None:
> > +manifest = []
> > +else:
> > +manifest = ['\\begin_manifest'] + self.manifest +
> > ['\\end_manifest']
> > +
> > +for line in header + [''] + manifest + [''] + self.body:
>
> I would suggest to include one of the empty lines above in manifest so that
> if we don't have a manifest we don't get two consecutive empty lines (this is
> cosmetics).
OK.
> I like this. That was what I was thinking. :-)
Then what remains is whether or not you want to move embedded_files_
to BufferParams. I am neutral about this.
Bo
Re: [Embedding PATCH] Add manifest to .lyx file itself.
> What if the file does not reference any external file? Then the manifest is empty, and an empty manifest will be written by the current implementation. I added an empty manifest to make logics in Buffer.cpp clearer. Bo
Re: [Embedding PATCH] Add manifest to .lyx file itself.
> > Two suggestions:
> > - include the manifest in the header. Possibly it can be place before the
> > preamble although the order is irrelevant.
>
> This will lead to more work in .cpp. I will see.
Looking at the code in Buffer.cpp, I do not think this is a good idea:
Write:
// now write out the buffer parameters.
ofs << "\\begin_header\n";
params().writeFile(ofs);
ofs << "\\end_header\n";
Read:
while (lex.isOK()) {
string unknown = params().readToken(lex, token);
if (!unknown.empty()) {
You can see that header <==> params() so unless I move embedded_files_
to params(), this does not look right.
If you do not like version testing in LyX.py, the attached version
moves this to lyx_1_6.py,
in LyX.py:
+# LyX file format <= 284 does not have a manifest section
+# so this section is set to None
+if self.manifest is None:
+manifest = []
+else:
+manifest = ['\\begin_manifest'] + self.manifest +
['\\end_manifest']
+
+for line in header + [''] + manifest + [''] + self.body:
and in lyx_1_6.py:
+def remove_manifest(document):
+"Remove the manifest section"
+document.menifest = None
+ revert = [
+ [284, [remove_manifest]],
Cheers,
Bo
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 20190)
+++ src/Buffer.cpp (working copy)
@@ -142,7 +142,7 @@
namespace {
-int const LYX_FORMAT = 284;
+int const LYX_FORMAT = 285;
} // namespace anon
@@ -559,7 +559,10 @@
"\\lyxadded and \\lyxdeleted in the LaTeX preamble."));
}
}
+ // read manifest after header
+ embeddedFiles().readManifest(lex, errorList);
+ // read main text
bool const res = text().read(*this, lex, errorList);
for_each(text().paragraphs().begin(),
text().paragraphs().end(),
@@ -661,12 +664,9 @@
LYXERR(Debug::FILES) << filename << " is in zip format. Unzip to " << temppath() << endl;
::unzipToDir(filename.toFilesystemEncoding(), temppath());
//
- FileName manifest(addName(temppath(), "manifest.txt"));
- FileName lyxfile(addName(temppath(),
- onlyFilename(filename.toFilesystemEncoding(;
+ FileName lyxfile(addName(temppath(), "content.lyx"));
// if both manifest.txt and file.lyx exist, this is am embedded file
- if (fs::exists(manifest.toFilesystemEncoding()) &&
- fs::exists(lyxfile.toFilesystemEncoding())) {
+ if (fs::exists(lyxfile.toFilesystemEncoding())) {
params().embedded = true;
fname = lyxfile;
}
@@ -890,7 +890,7 @@
if (params().embedded)
// first write the .lyx file to the temporary directory
content = FileName(addName(temppath(),
- onlyFilename(fname.toFilesystemEncoding(;
+ "content.lyx"));
else
content = fname;
@@ -911,7 +911,6 @@
if (retval && params().embedded) {
// write file.lyx and all the embedded files to the zip file fname
// if embedding is enabled, and there is any embedded file
- pimpl_->embedded_files.update();
return pimpl_->embedded_files.write(fname);
}
return retval;
@@ -951,6 +950,12 @@
params().writeFile(ofs);
ofs << "\\end_header\n";
+ // write a manifest
+ ofs << "\n\\begin_manifest\n";
+ pimpl_->embedded_files.update();
+ embeddedFiles().writeManifest(ofs);
+ ofs << "\\end_manifest\n";
+
// write the text
ofs << "\n\\begin_body\n";
text().write(*this, ofs);
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (revision 20190)
+++ lib/lyx2lyx/LyX.py (working copy)
@@ -78,7 +78,7 @@
("1_3", [221], generate_minor_versions("1.3" , 7)),
("1_4", range(222,246), generate_minor_versions("1.4" , 5)),
("1_5", range(246,277), generate_minor_versions("1.5" , 1)),
- ("1_6", range(277,285), generate_minor_versions("1.6" , 0))]
+ ("1_6", range(277,286), generate_minor_versions("1.6" , 0))]
def formats_list():
@@ -175,6 +175,7 @@
self.default_layout = ''
self.header = []
self.preamble = []
+self.manifest = []
self.body = []
self.status = 0
self.encoding = encoding
@@ -198,7 +199,7 @@
def read(self):
-"""Reads a file into the self.header and self.body parts, from self.input."""
+"""Reads a file into the self.header, self.manifest and self.body parts, from self.input."""
while 1:
line = self.input.readline()
@@ -225,6 +226,25 @@
if check_token(line, '\\end_preamble'):
continue
+if check_token(line, '\\begin_manifest'):
+while 1:
+line = self.input.readline()
+if not line:
+self.error("Invalid LyX file.")
+
+line = trim_eol(line)
+if check_token(line, "\\end_manifest"
Re: [Embedding PATCH] Add manifest to .lyx file itself.
> - if there is no manifest there is no need to place an empty manifest. Then > there is no need to test for the document version. But all files saved after format 254 will have a manifest. Note that manifest also records non-embedded files. Cheers, Bo
Re: [Embedding PATCH] Add manifest to .lyx file itself.
On 9/10/07, José Matos <[EMAIL PROTECTED]> wrote: > On Monday 10 September 2007 05:14:18 Bo Peng wrote: > > - for line in header + [''] + self.body: > > + # LyX file format <= 284 does not have a manifest section > > + if self.format <= 284: > > + manifest = [] > > + elif self.manifest: > > + manifest = ['\\begin_manifest'] + self.manifest + > > ['\\end_manifest'] + else: > > + manifest = ['\\begin_manifest', '\\end_manifest'] > > + > > + for line in header + [''] + manifest + [''] + self.body: > > self.output.write(line.encode(self.encoding)+"\n") > > Two suggestions: > - include the manifest in the header. Possibly it can be place before the > preamble although the order is irrelevant. This will lead to more work in .cpp. I will see. Cheers, Bo
Re: [Help Needed] Problems with storing inset pointers in EmbeddedFiles.
> Note that reference to an inset is a very fragile thing. I guess that > an undo-redo cycle will reallocate the inset. Stored insets are used in two ways: 1. navigation. Because I compare a stored inset pointer with currently available ones. If the stored pointer does not exist, navigation of that file item fail. On the other hand, this operation will not crash lyx so it is not a big problem. 2. change filename used by an inset (not yet committed). When embedding is enabled, and the embedding status of a file is changed, all insets that refer to that file will be updated to use appropriate filename. This is more dangerous so validate the pointer before such an operation. It would be safer to do a EmbeddedFiles::update() though. Cheers, Bo
Fwd: [Bug 4173] Middle-button paste between apps sometimes uses old selection.
--- Additional Comments From [EMAIL PROTECTED] 2007-09-10 11:51 --- Bo, if this is tested, it can be committed to branch. Hi, JMarc, I am not sure which of your patches has not been put to branch, could you take care of this? Thanks. Bo
[Embedding PATCH] Add manifest to .lyx file itself.
Hi, Jose,
As we have discussed, the attached patch adds manifest to .lyx file
itself, as a separate manifest section. The idea here is that
manipulation of embedding status is independent of whether or not the
.lyx file will be saved in bundled format. This ensures lossless
conversion when we pack/unpack a bunbled .lyx file.
This patch also changes the bundle structure. Besides the removal of
manifest.txt, it uses 'content.lyx', instead of file.lyx in the zip
file.
Please check if I am doing the right things to lyx2lyx.
Bo
Index: src/Buffer.cpp
===
--- src/Buffer.cpp (revision 20186)
+++ src/Buffer.cpp (working copy)
@@ -142,7 +142,7 @@
namespace {
-int const LYX_FORMAT = 284;
+int const LYX_FORMAT = 285;
} // namespace anon
@@ -559,7 +559,10 @@
"\\lyxadded and \\lyxdeleted in the LaTeX preamble."));
}
}
+ // read manifest after header
+ embeddedFiles().readManifest(lex, errorList);
+ // read main text
bool const res = text().read(*this, lex, errorList);
for_each(text().paragraphs().begin(),
text().paragraphs().end(),
@@ -661,12 +664,9 @@
LYXERR(Debug::FILES) << filename << " is in zip format. Unzip to " << temppath() << endl;
::unzipToDir(filename.toFilesystemEncoding(), temppath());
//
- FileName manifest(addName(temppath(), "manifest.txt"));
- FileName lyxfile(addName(temppath(),
- onlyFilename(filename.toFilesystemEncoding(;
+ FileName lyxfile(addName(temppath(), "content.lyx"));
// if both manifest.txt and file.lyx exist, this is am embedded file
- if (fs::exists(manifest.toFilesystemEncoding()) &&
- fs::exists(lyxfile.toFilesystemEncoding())) {
+ if (fs::exists(lyxfile.toFilesystemEncoding())) {
params().embedded = true;
fname = lyxfile;
}
@@ -890,7 +890,7 @@
if (params().embedded)
// first write the .lyx file to the temporary directory
content = FileName(addName(temppath(),
- onlyFilename(fname.toFilesystemEncoding(;
+ "content.lyx"));
else
content = fname;
@@ -911,7 +911,6 @@
if (retval && params().embedded) {
// write file.lyx and all the embedded files to the zip file fname
// if embedding is enabled, and there is any embedded file
- pimpl_->embedded_files.update();
return pimpl_->embedded_files.write(fname);
}
return retval;
@@ -951,6 +950,12 @@
params().writeFile(ofs);
ofs << "\\end_header\n";
+ // write a manifest
+ ofs << "\n\\begin_manifest\n";
+ pimpl_->embedded_files.update();
+ embeddedFiles().writeManifest(ofs);
+ ofs << "\\end_manifest\n";
+
// write the text
ofs << "\n\\begin_body\n";
text().write(*this, ofs);
Index: lib/lyx2lyx/LyX.py
===
--- lib/lyx2lyx/LyX.py (revision 20185)
+++ lib/lyx2lyx/LyX.py (working copy)
@@ -78,7 +78,7 @@
("1_3", [221], generate_minor_versions("1.3" , 7)),
("1_4", range(222,246), generate_minor_versions("1.4" , 5)),
("1_5", range(246,277), generate_minor_versions("1.5" , 1)),
- ("1_6", range(277,285), generate_minor_versions("1.6" , 0))]
+ ("1_6", range(277,286), generate_minor_versions("1.6" , 0))]
def formats_list():
@@ -175,6 +175,7 @@
self.default_layout = ''
self.header = []
self.preamble = []
+self.manifest = []
self.body = []
self.status = 0
self.encoding = encoding
@@ -198,7 +199,7 @@
def read(self):
-"""Reads a file into the self.header and self.body parts, from self.input."""
+"""Reads a file into the self.header, self.manifest and self.body parts, from self.input."""
while 1:
line = self.input.readline()
@@ -225,6 +226,25 @@
if check_token(line, '\\end_preamble'):
continue
+if check_token(line, '\\begin_manifest'):
+while 1:
+line = self.input.readline()
+if not line:
+self.error("Invalid LyX file.")
+
+line = trim_eol(line)
+if check_token(line, "\\end_manifest"):
+break
+
+if not line.startswith('\\filename') and not line.startswith('\\inzipName') \
+and not line.startswith('\\status'):
+self.warning("Malformed LyX file: Missing '\\end_manifest'.")
+
+self.manifest.append(line)
+
+if check_token(line, '\\end_manifest'):
+continue
+
line = line.strip()
if not line:
continue
@@ -275,7 +295,15 @@
else:
header = self.header
-for line in header + [''] + self.body:
+# LyX file format <= 284 does not have a manifest section
+if self.format <= 284:
+manifest = []
+eli
Re: lyx2lyx or toc building is broken after user's guide update.
>. I have fixed it. Ohmm, I have some network problem here and can not commit. Uwe, please fix it yourself. while par[-1].strip() == '' and par: to while par and par[-1].strip() == '': Cheers, Bo
Re: lyx2lyx or toc building is broken after user's guide update.
> > This line is logically wrong. It should be > > > > while par and par[-1].strip(): > > This fixes the list range bug, I therefore applied it. I was not very careful, I meant 'and par[-1].strip() == '''. I have fixed it. Bo
Re: lyx2lyx or toc building is broken after user's guide update.
> This is strange because doc_toc.py is utf-8 encoded and the "Í" is included > in latin1. > But anyway, when I delete this character, I get: > > File "D:\LyXSVN\lyx-devel\build-msvc\Resources\lyx2lyx\LyX.py", line 544, in > get_toc > while par[-1].strip() == '' and par: > IndexError: list index out of range > This line is logically wrong. It should be while par and par[-1].strip(): because whether or not par is empty should be tested before if the last line is empty. Bo
Re: lyx2lyx or toc building is broken after user's guide update.
> It seems that doc_toc.py can no longer > build toc. One of the problems is the title "Índice general LyX documentation" can not be encoded at line 279 of LyX.py. Bo
lyx2lyx or toc building is broken after user's guide update.
Hi, Uwe, Scons can not install lyx after the recent User's guide update. Could you check what is going on? It seems that doc_toc.py can no longer build toc. Cheers, Bo
Re: [Help Needed] Problems with storing inset pointers in EmbeddedFiles.
> I spent a few hours on this idea, and everything seems to be fine > until I use inset_iterator_begin(inset_ptr) to locate the inset. Lyx > instantly crashes. It turns out the the stored inset pointer is > obsolete without any buffer edition. It turns out that I can not use 'inset_iterator_begin(ptr)' to locate an inset from an inset pointer, so I have to use for (InsetIterator it = inset_iterator_begin(buf->inset()); it; ++it) if (&(*it) == ptr) Note that because of operator overloading, &(*it) is the only way to get the pointer of the inet. it->inset() etc does not work! Patch submitted. I notice that the cursor is not blinking when I navigate with the embedding dialog, something needs to be fixed later. Cheers, Bo
[Help Needed] Problems with storing inset pointers in EmbeddedFiles.
Currently, EmbeddedFiles stores a list of ParConstIterator that can be used to locate the inset's paragraph. This has a number of problems: 1. I can only move the cursor to the beginning of the paragraph, not where the inset is. 2. Such ParConstIterator need to be updated along with structureChanged(). Otherwise, they will soon be outdated. Because I need to separate embeddingChanged() from structureChanged(), this is unacceptable. It then seems obvious that I need to store the insets themselves. Because, 1. I can locate an inset easily and accurately using: InsetIterator it = inset_iterator_begin(inset_ptr), which is a DocIterator. 2. It allows me to change the insets directly if, for example, the embedding status is changed and the inset needs to use another file. I spent a few hours on this idea, and everything seems to be fine until I use inset_iterator_begin(inset_ptr) to locate the inset. Lyx instantly crashes. It turns out the the stored inset pointer is obsolete without any buffer edition. My question is: is there any reliable way to store the reference to an inset? Basically, I need to save something about an inset, and look up that inset with it easily later. Many thanks in advance. Bo
Re: State of src/frontends/
> It's fixing time. The earthquake is over, Great! I just sent a message asking this... Bo
Re: All dialogs seem broken
> There have been several update() methods in the different layers > of the GUII machinery. I had to rename some when merging classes, > and even if these changes were rather mechanical it's rather likely > that something went wrong somewhere. So is there any planned big changes? Bo
Re: [Embedding discussion 2] Data structure of embedded files.
> I am solving this problem by A patch has already been submitted. Please test it using lyx' User's guide. Bo
Re: [Embedding discussion 2] Data structure of embedded files.
> This is actually also related to the original problem with [Embedding > discussion 1], do we want multiple entries for multiple insets > referring to the same file? I am solving this problem by 1, store a list of ParConstIterator for multiple insets in a EmbeddedFile item. 2. display the file item as 'file (1/4)' if file is referred 4 times. 3. when the user clicks 'file (1/4)' the cursor will go to the first inset, and the label will be changed to 'file (2/4). Click again will go to the next inset. Cheers, Bo
Re: Embedding LaTeX dependant packages ?
> I don't know how useful that would be. They'd have to unpack the files, > install them, run texhash (or whatever), just as they do now. Right? Not really. If you put a .cls in your document directory, lyx can make use of it. That is to say, if your customized class is simple enough (a single file), you can embed it with the .lyx file and use it directly. Embedding large class files such as beamer is not encouraged (though possible). Cheers, Bo
[Embedding discussion 2] Data structure of embedded files.
Dear all, Thanks to Edwin, the embedding dialog is working again. It now has a list of embedded files, with embedding status (true/false) indicated by checkboxes. There are five buttons: select (embed selected files), unselect (dis-embed selected files), add (add a file), extract (extract selected files) and update (update selected files from their external version). EmbeddedFiles.h|cpp and ControlEmbeddedFiles.h|cpp are updated accordingly. Two problems left with the embedding dialog though: a) I can not see the buttons! I should have missed something obvious. b) I used some random button icons. New icons are needed. This can wait though because we may add/remove some buttons later. Edwin, could you have a look at problem a? Now, JMarc mentioned that he would like to use a map for embedded files. What do you have in mind? This is not a standalone problem because this EmbeddedFileList can be looked up by 'absFilename()' and by 'embeddedFilename()' because InsetGraphics can use either file, depending on the embedding status. When this inset calls registerEmbeddedFiles(), it can pass either name to the function. This is actually also related to the original problem with [Embedding discussion 1], do we want multiple entries for multiple insets referring to the same file? Cheers, Bo
Re: [Embedding discussion 1] How to handle an embeded file that is referred by multiple insets.
> > I agree, but the problem is that sometimes it is not easy to insert > > all needed files (.inc, .modules, .sty) so manual adjustment may be > > needed. This can be postponed until we implement this feature. > > If we can't do it, then we should not try to bundle layout files. > Normal users are not supposed to have to deal with that. Richard (?) had an idea to insert all needed parts as a single layout file so maybe this is doable. Also, even if manual adjustment is needed, we can have it as an advanced feature. It is very nice to say 'Hey, this is the university thesis template, open it (on any machine with lyx installed) and add your stuff.'. Bo
Re: Please help implement a list of checkboxes in the embedding dialog.
> + // FIXME, Bo this does nothing > bool mode = false; > + // FIXME: Bo, this is not used > + // FIXME: Bo, this is not used > + //int row = filesLW->row(*it); BTW, these are the consequences of the removal of AUTO feature. The dialog is being rewritten. Bo
Re: [Embedding discussion 1] How to handle an embeded file that is referred by multiple insets.
> > What do you think? > > I do not think that it should be possible to add arbitrary files manually. > LyX is a writing tool, not an archiver. The .layout and .cls files would be > the only ones needing a setting in the .lyx file. I agree, but the problem is that sometimes it is not easy to insert all needed files (.inc, .modules, .sty) so manual adjustment may be needed. This can be postponed until we implement this feature. Cheers, Bo
