Re: cmake on Mac
Am Montag 25 Januar 2010 schrieb Vincent van Ravesteijn - TNW: Cmake shouldn't want to compile moc_* files. It shouldn't even know that they exist. These moc_* files are #included in the normal *.cpp files and they are now compiled twice and thus giving you the previously defined here errors. Why not? They are not part of svn, so they have to be created. I had a hard time to implement it. Kornel signature.asc Description: This is a digitally signed message part.
Re: Trac rights
On 2010-01-25, Vincent wrote: Please, can we make the keywords, priority, severity and milestone fields to be editable only by people with rights. I understand that for people taking the step to report a bug, the bug is really major, but if everyone that reports a bug sets the milestone to the next minor release with priority high and severity critical, our organization gets lost. If not possible, please add documentation at a prominent place that these fields are reserved for use by the developers. Günter
[patch] bug 6218: Wrong equation references after copy and paste of a previous equation
http://www.lyx.org/trac/ticket/6218 The attached patch against branch implements a duplicate check for pasted labels in math (as we already have for text). OK? Jürgen Index: src/mathed/InsetMathHull.h === --- src/mathed/InsetMathHull.h (Revision 33221) +++ src/mathed/InsetMathHull.h (Arbeitskopie) @@ -58,6 +58,8 @@ /// void label(row_type row, docstring const label); /// + std::vectorInsetLabel * getLabels() { return label_; } + /// ColorCode backgroundColor() const { return Color_mathbg; } /// void numbered(row_type row, bool num); Index: src/CutAndPaste.cpp === --- src/CutAndPaste.cpp (Revision 33221) +++ src/CutAndPaste.cpp (Arbeitskopie) @@ -42,10 +42,12 @@ #include insets/InsetGraphics.h #include insets/InsetGraphicsParams.h #include insets/InsetInclude.h +#include insets/InsetLabel.h #include insets/InsetTabular.h #include mathed/MathData.h #include mathed/InsetMath.h +#include mathed/InsetMathHull.h #include mathed/MathSupport.h #include support/debug.h @@ -231,6 +233,35 @@ switch (it-lyxCode()) { + case MATH_CODE: { + // check for equation labels and resolve duplicates + InsetMathHull ins = static_castInsetMathHull (*it); + std::vectorInsetLabel * labels = ins.getLabels(); + if (labels.empty()) +break; + for (size_t i = 0; i != labels.size(); ++i) { +if (!labels[i]) + continue; +InsetLabel * lab = labels[i]; +docstring const oldname = lab-getParam(name); +lab-updateCommand(oldname, false); +docstring const newname = lab-getParam(name); +if (oldname != newname) { + // adapt the references + for (InsetIterator itt = inset_iterator_begin(in); + itt != i_end; ++itt) { + if (itt-lyxCode() == REF_CODE) { + InsetCommand ref = +dynamic_castInsetCommand (*itt); + if (ref.getParam(reference) == oldname) +ref.setParam(reference, newname); + } + } +} + } + break; + } + case LABEL_CODE: { // check for duplicates InsetCommand lab = static_castInsetCommand (*it);
Re: Trac rights
Vincent v.f.vanraveste...@tudelft.nl writes: Please, can we make the keywords, priority, severity and milestone fields to be editable only by people with rights. It seems that the following plugin can do what we want. http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin JMarc
RE: cmake on Mac
Cmake shouldn't want to compile moc_* files. It shouldn't even know that they exist. These moc_* files are #included in the normal *.cpp files and they are now compiled twice and thus giving you the previously defined here errors. Why not? They are not part of svn, so they have to be created. I had a hard time to implement it. Yes, I appreciate it a lot. I just mean that Cmake shouldn't want to compile them explicitly. When running Cmake it collects all *.cpp files in the src directory and tries to compile them. However, in this step it should neglect the moc_* files. Vincent
Re: cmake on Mac
Am Dienstag 26 Januar 2010 schrieb Vincent van Ravesteijn - TNW: Cmake shouldn't want to compile moc_* files. It shouldn't even know that they exist. These moc_* files are #included in the normal *.cpp files and they are now compiled twice and thus giving you the previously defined here errors. Why not? They are not part of svn, so they have to be created. I had a hard time to implement it. Yes, I appreciate it a lot. I just mean that Cmake shouldn't want to compile them explicitly. When running Cmake it collects all *.cpp files in the src directory and tries to compile them. However, in this step it should neglect the moc_* files. Vincent I see. I never had this problem (not compiling in the source tree). I try to exclude the moc files ... Kornel signature.asc Description: This is a digitally signed message part.
Re: View/Update toolbar position
Jürgen Spitzmüller wrote: Pavel Sanda wrote: to sum it up - i change the toolbar very often so i asked about changing the defaults either to off or to vertical position. I'd rather fix the cause (i.e., allow for multiple toolbars in a row). like this? or should we put view before extra instead after standard? pavel diff --git a/lib/ui/default.ui b/lib/ui/default.ui index 9688b0e..3b48f1a 100644 --- a/lib/ui/default.ui +++ b/lib/ui/default.ui @@ -39,9 +39,12 @@ Include stdtoolbars.inc # left: the toolbar should be at the left of the window # right: the toolbar should be at the right of the window # +# widen: do not create new line for this toolbar +#(note that order of toolbars is defined in stdtoolbars.inc) +# Toolbars standard on,top - view/update on,top + view/update on,top,widen extra on,top review auto,review,top vcs off,top diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc index 8c085bb..3aab9d4 100644 --- a/lib/ui/stdtoolbars.inc +++ b/lib/ui/stdtoolbars.inc @@ -95,6 +95,16 @@ ToolbarSet Item Toggle table toolbar toolbar-toggle table End + Toolbar view/update View/Update + Item View buffer-view + Item Update buffer-update + Item View master document master-buffer-view + Item Update master document master-buffer-update + Separator + StickyPopupMenu view-others View other formats + StickyPopupMenu update-others Update other formats + End + Toolbar extra Extra Item Default layout Item Numbered list layout Enumerate @@ -215,16 +225,6 @@ ToolbarSet Item Next note note-next End - Toolbar view/update View/Update - Item View buffer-view - Item Update buffer-update - Item View master document master-buffer-view - Item Update master document master-buffer-update - Separator - StickyPopupMenu view-others View other formats - StickyPopupMenu update-others Update other formats - End - Toolbar view-others View Other Formats ViewFormats End diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp index a503ed8..4f20af7 100644 --- a/src/frontends/qt4/GuiView.cpp +++ b/src/frontends/qt4/GuiView.cpp @@ -536,7 +536,7 @@ void GuiView::initToolbars() if (!tb) continue; int const visibility = guiApp-toolbars().defaultVisibility(cit-name); - bool newline = true; + bool newline = !(visibility Toolbars::WIDEN); tb-setVisible(false); tb-setVisibility(visibility); diff --git a/src/frontends/qt4/Toolbars.cpp b/src/frontends/qt4/Toolbars.cpp index 347a272..2d83ec5 100644 --- a/src/frontends/qt4/Toolbars.cpp +++ b/src/frontends/qt4/Toolbars.cpp @@ -358,6 +358,8 @@ void Toolbars::readToolbarSettings(Lexer lex) flag = RIGHT; else if (!compare_ascii_no_case(*cit, auto)) flag = AUTO; + else if (!compare_ascii_no_case(*cit, widen)) + flag = WIDEN; else { LYXERR(Debug::ANY, Toolbars::readToolbarSettings: unrecognised token:` diff --git a/src/frontends/qt4/Toolbars.h b/src/frontends/qt4/Toolbars.h index e105876..95bd04a 100644 --- a/src/frontends/qt4/Toolbars.h +++ b/src/frontends/qt4/Toolbars.h @@ -107,7 +107,8 @@ public: MATH = 128, // show when in math TABLE = 256, // show when in table REVIEW = 512, // show when change tracking is enabled - MATHMACROTEMPLATE = 1024 // show in math macro template + MATHMACROTEMPLATE = 1024, // show in math macro template + WIDEN = 2048 //place to the current row, no new line }; typedef std::vectorToolbarInfo Infos;
Re: View/Update toolbar position
Pavel Sanda wrote: like this? Looks like it. Great. Maybe widen is not the most transparent tag, I don't know (samerow?). or should we put view before extra instead after standard? Personally, I have it in the second row, before extra. But this means extra needs the tag, right? Then what happens if view/update is switched off? Jürgen
Re: r33229 - lyx-devel/trunk/src
v...@lyx.org wrote: + // FIXME: LyX is not ready for outlining within inset. this is a regression or it was always like this? pavel
Re: View/Update toolbar position
Jürgen Spitzmüller wrote: Maybe widen is not the most transparent tag, I don't know (samerow?). looks good. or should we put view before extra instead after standard? Personally, I have it in the second row, before extra. But this means extra needs the tag, right? exactly Then what happens if view/update is switched off? you mean by user? then nothing since the layout is driven by qsettings from that point. pavel
Re: r33229 - lyx-devel/trunk/src
Pavel Sanda wrote: v...@lyx.org wrote: + // FIXME: LyX is not ready for outlining within inset. this is a regression or it was always like this? pavel I don't know.. I just put back what was removed. Vincent
Re: View/Update toolbar position
Pavel Sanda wrote: Then what happens if view/update is switched off? you mean by user? then nothing since the layout is driven by qsettings from that point. OK. Jürgen
Re: cmake on Mac
Am Montag 25 Januar 2010 schrieb Vincent van Ravesteijn - TNW: > Cmake shouldn't want to compile moc_* files. It shouldn't even know that > they exist. These moc_* files are #included in the normal *.cpp files > and they are now compiled twice and thus giving you the "previously > defined here" errors. > Why not? They are not part of svn, so they have to be created. I had a hard time to implement it. Kornel signature.asc Description: This is a digitally signed message part.
Re: Trac rights
On 2010-01-25, Vincent wrote: > Please, can we make the keywords, priority, severity and milestone > fields to be editable only by people with rights. > I understand that for people taking the step to report a bug, the bug is > really major, but if everyone that reports a bug sets the milestone to > the next minor release with priority high and severity critical, our > organization gets lost. If not possible, please add documentation at a prominent place that these fields are reserved for use by the developers. Günter
[patch] bug 6218: Wrong equation references after copy and paste of a previous equation
http://www.lyx.org/trac/ticket/6218 The attached patch against branch implements a duplicate check for pasted labels in math (as we already have for text). OK? Jürgen Index: src/mathed/InsetMathHull.h === --- src/mathed/InsetMathHull.h (Revision 33221) +++ src/mathed/InsetMathHull.h (Arbeitskopie) @@ -58,6 +58,8 @@ /// void label(row_type row, docstring const & label); /// + std::vector getLabels() { return label_; } + /// ColorCode backgroundColor() const { return Color_mathbg; } /// void numbered(row_type row, bool num); Index: src/CutAndPaste.cpp === --- src/CutAndPaste.cpp (Revision 33221) +++ src/CutAndPaste.cpp (Arbeitskopie) @@ -42,10 +42,12 @@ #include "insets/InsetGraphics.h" #include "insets/InsetGraphicsParams.h" #include "insets/InsetInclude.h" +#include "insets/InsetLabel.h" #include "insets/InsetTabular.h" #include "mathed/MathData.h" #include "mathed/InsetMath.h" +#include "mathed/InsetMathHull.h" #include "mathed/MathSupport.h" #include "support/debug.h" @@ -231,6 +233,35 @@ switch (it->lyxCode()) { + case MATH_CODE: { + // check for equation labels and resolve duplicates + InsetMathHull & ins = static_cast(*it); + std::vector labels = ins.getLabels(); + if (labels.empty()) +break; + for (size_t i = 0; i != labels.size(); ++i) { +if (!labels[i]) + continue; +InsetLabel * lab = labels[i]; +docstring const oldname = lab->getParam("name"); +lab->updateCommand(oldname, false); +docstring const newname = lab->getParam("name"); +if (oldname != newname) { + // adapt the references + for (InsetIterator itt = inset_iterator_begin(in); + itt != i_end; ++itt) { + if (itt->lyxCode() == REF_CODE) { + InsetCommand & ref = +dynamic_cast(*itt); + if (ref.getParam("reference") == oldname) +ref.setParam("reference", newname); + } + } +} + } + break; + } + case LABEL_CODE: { // check for duplicates InsetCommand & lab = static_cast(*it);
Re: Trac rights
Vincentwrites: > Please, can we make the keywords, priority, severity and milestone > fields to be editable only by people with rights. It seems that the following plugin can do what we want. http://trac-hacks.org/wiki/BlackMagicTicketTweaksPlugin JMarc
RE: cmake on Mac
>> Cmake shouldn't want to compile moc_* files. It shouldn't even know >> that they exist. These moc_* files are #included in the normal *.cpp >> files and they are now compiled twice and thus giving you the >> "previously defined here" errors. >> > >Why not? They are not part of svn, so they have to be >created. I had a hard time to implement it. > Yes, I appreciate it a lot. I just mean that Cmake shouldn't want to compile them explicitly. When running Cmake it collects all *.cpp files in the src directory and tries to compile them. However, in this step it should neglect the moc_* files. Vincent
Re: cmake on Mac
Am Dienstag 26 Januar 2010 schrieb Vincent van Ravesteijn - TNW: > >> Cmake shouldn't want to compile moc_* files. It shouldn't even know > >> that they exist. These moc_* files are #included in the normal *.cpp > >> files and they are now compiled twice and thus giving you the > >> "previously defined here" errors. > > > >Why not? They are not part of svn, so they have to be > >created. I had a hard time to implement it. > > Yes, I appreciate it a lot. > > I just mean that Cmake shouldn't want to compile them explicitly. When > running Cmake it collects all *.cpp files in the src directory and tries > to compile them. However, in this step it should neglect the moc_* > files. > > Vincent > I see. I never had this problem (not compiling in the source tree). I try to exclude the moc files ... Kornel signature.asc Description: This is a digitally signed message part.
Re: View/Update toolbar position
Jürgen Spitzmüller wrote: > Pavel Sanda wrote: > > to sum it up - i change the toolbar very often so i asked about changing > > the defaults either to off or to vertical position. > > I'd rather fix the cause (i.e., allow for multiple toolbars in a row). like this? or should we put view before extra instead after standard? pavel diff --git a/lib/ui/default.ui b/lib/ui/default.ui index 9688b0e..3b48f1a 100644 --- a/lib/ui/default.ui +++ b/lib/ui/default.ui @@ -39,9 +39,12 @@ Include "stdtoolbars.inc" # left: the toolbar should be at the left of the window # right: the toolbar should be at the right of the window # +# widen: do not create new line for this toolbar +#(note that order of toolbars is defined in stdtoolbars.inc) +# Toolbars "standard" "on,top" - "view/update" "on,top" + "view/update" "on,top,widen" "extra" "on,top" "review" "auto,review,top" "vcs" "off,top" diff --git a/lib/ui/stdtoolbars.inc b/lib/ui/stdtoolbars.inc index 8c085bb..3aab9d4 100644 --- a/lib/ui/stdtoolbars.inc +++ b/lib/ui/stdtoolbars.inc @@ -95,6 +95,16 @@ ToolbarSet Item "Toggle table toolbar" "toolbar-toggle table" End + Toolbar "view/update" "View/Update" + Item "View" "buffer-view" + Item "Update" "buffer-update" + Item "View master document" "master-buffer-view" + Item "Update master document" "master-buffer-update" + Separator + StickyPopupMenu "view-others" "View other formats" + StickyPopupMenu "update-others" "Update other formats" + End + Toolbar "extra" "Extra" Item "Default" "layout" Item "Numbered list" "layout Enumerate" @@ -215,16 +225,6 @@ ToolbarSet Item "Next note" "note-next" End - Toolbar "view/update" "View/Update" - Item "View" "buffer-view" - Item "Update" "buffer-update" - Item "View master document" "master-buffer-view" - Item "Update master document" "master-buffer-update" - Separator - StickyPopupMenu "view-others" "View other formats" - StickyPopupMenu "update-others" "Update other formats" - End - Toolbar "view-others" "View Other Formats" ViewFormats End diff --git a/src/frontends/qt4/GuiView.cpp b/src/frontends/qt4/GuiView.cpp index a503ed8..4f20af7 100644 --- a/src/frontends/qt4/GuiView.cpp +++ b/src/frontends/qt4/GuiView.cpp @@ -536,7 +536,7 @@ void GuiView::initToolbars() if (!tb) continue; int const visibility = guiApp->toolbars().defaultVisibility(cit->name); - bool newline = true; + bool newline = !(visibility & Toolbars::WIDEN); tb->setVisible(false); tb->setVisibility(visibility); diff --git a/src/frontends/qt4/Toolbars.cpp b/src/frontends/qt4/Toolbars.cpp index 347a272..2d83ec5 100644 --- a/src/frontends/qt4/Toolbars.cpp +++ b/src/frontends/qt4/Toolbars.cpp @@ -358,6 +358,8 @@ void Toolbars::readToolbarSettings(Lexer & lex) flag = RIGHT; else if (!compare_ascii_no_case(*cit, "auto")) flag = AUTO; + else if (!compare_ascii_no_case(*cit, "widen")) + flag = WIDEN; else { LYXERR(Debug::ANY, "Toolbars::readToolbarSettings: unrecognised token:`" diff --git a/src/frontends/qt4/Toolbars.h b/src/frontends/qt4/Toolbars.h index e105876..95bd04a 100644 --- a/src/frontends/qt4/Toolbars.h +++ b/src/frontends/qt4/Toolbars.h @@ -107,7 +107,8 @@ public: MATH = 128, //< show when in math TABLE = 256, //< show when in table REVIEW = 512, //< show when change tracking is enabled - MATHMACROTEMPLATE = 1024 //< show in math macro template + MATHMACROTEMPLATE = 1024, //< show in math macro template + WIDEN = 2048 //place to the current row, no new line }; typedef std::vector Infos;
Re: View/Update toolbar position
Pavel Sanda wrote: > like this? Looks like it. Great. Maybe "widen" is not the most transparent tag, I don't know ("samerow"?). > or should we put view before extra instead after standard? Personally, I have it in the second row, before extra. But this means extra needs the tag, right? Then what happens if view/update is switched off? Jürgen
Re: r33229 - lyx-devel/trunk/src
v...@lyx.org wrote: > + // FIXME: LyX is not ready for outlining within inset. this is a regression or it was always like this? pavel
Re: View/Update toolbar position
Jürgen Spitzmüller wrote: > Maybe "widen" is not the most transparent tag, I don't know ("samerow"?). looks good. > > or should we put view before extra instead after standard? > > Personally, I have it in the second row, before extra. But this means extra > needs the tag, right? exactly >Then what happens if view/update is switched off? you mean by user? then nothing since the layout is driven by qsettings from that point. pavel
Re: r33229 - lyx-devel/trunk/src
Pavel Sanda wrote: v...@lyx.org wrote: + // FIXME: LyX is not ready for outlining within inset. this is a regression or it was always like this? pavel I don't know.. I just put back what was removed. Vincent
Re: View/Update toolbar position
Pavel Sanda wrote: > >Then what happens if view/update is switched off? > > you mean by user? then nothing since the layout is driven by qsettings > from that point. OK. Jürgen