Re: Layout Categories
Here is the patch for the grouped layout. The whole thing would be so much easier if QComboBox supported non- uniform-sized items in the popup. It just takes the first item and multiplies it with the item number to calculate the popup size. Hence I spent most time to find a way to avoid the scrolling. Other than that it's mainly some visual code to paint the category headers. Stefan Am 07.03.2008 um 16:11 schrieb Stefan Schimanski: Am 06.03.2008 um 07:23 schrieb rgheck: This is in. See 23501-3. You want Layout::category(). groupedlayouts.patch Description: Binary data
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
On Sat, Mar 08, 2008 at 02:19:50PM -0500, rgheck wrote: > Andre Poenitz wrote: >> On Sat, Mar 08, 2008 at 12:38:22PM -0500, rgheck wrote: >> >>> (1) go back to a standard container of pointers---but just normal >>> pointers [...] >>> (2) use a "strong typedef", something like: >>> [...] >>> >> >> (3) The only place where currently a TextClass copy constructor is used >> is: >> >> /// Constructs a DocumentClass based upon a LayoutFile. >> DocumentClass(LayoutFile const & tc); >> >> If we could get rid of this method TextClass could be made noncopyable. >> >> > Right now, TextClass is copyable only by its subclasses. But changing that > wouldn't help with the larger problem, since the standard containers demand > copy and assign no matter what, right? Right. > So it's the fact that a TextClass > contains a std::vector that is the issue. Or standard containers [just kidding... But see (4) "Shallow copies"... Andre'
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
On Sat, Mar 08, 2008 at 12:38:22PM -0500, rgheck wrote: > (1) go back to a standard container of pointers---but just normal pointers > [...] > (2) use a "strong typedef", something like: > [...] (4) Move TextClass data members in a pimpl and use the compiler-generated copy consstructor. In general, this is wrong as it only does a shallow copy, but that's what we would like to have in this case. The destructor could be empty effectively leaking the pimpl data (proper solution would be reference counting, half way back on to shared_ptr ;-]) Andre'
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
Andre Poenitz wrote:
On Sat, Mar 08, 2008 at 12:38:22PM -0500, rgheck wrote:
(1) go back to a standard container of pointers---but just normal pointers
this time---and make the pointers be managed by TextClass, which is where
the container is; then we can make Layouts non-copyable. This won't be too
bad, because there's only one reason Layouts ever get deleted, namely,
because you run into a NoStyle tag in a layout file. I've recently done
exactly this with some other containers, for much this kind of reason: see
http://www.lyx.org/trac/changeset/23526. So it would be pretty
straightforward, I think.
This sounds good enough for our reasons...
(2) use a "strong typedef", something like:
class LayoutIndex {
public:
///
typedef Layout base_type;
///
LayoutIndex(LayoutIndex const & lfi) :
data_(lfi.data_) {}
///
LayoutIndex const & operator=(LayoutIndex const & lfi)
{ data_ = lfi.data_; return *this; }
///
operator base_type const & () const { return data_; }
///
bool empty() const { return data_.empty(); }
private:
///
LayoutIndex(base_type t) : data_(t) {}
///
base_type & data_;
///
friend class TextClass;
};
inside TextClass, and have the relevant methods always return LayoutIndex
objects, and make methods like setLayout require them. Then Layout objects
don't need to be non-copyable; only TextClass will be able to create the
LayoutIndex objects, and the only way to get one will be from a TextClass
object. You introduced something similar to this into TextClassList, now
LayoutFileList.[...]
This sounds ok, too.
Do you see a reason to prefer one or the other here?
The second approach seems to require more changes to other places in the
code, so 'least effort' seems to be the first one.
I have rally no strong preference here, but having one or the other
would be nicer than doing nothing.
OK. I'll do one or the other.
rh
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
Andre Poenitz wrote: On Sat, Mar 08, 2008 at 12:38:22PM -0500, rgheck wrote: (1) go back to a standard container of pointers---but just normal pointers [...] (2) use a "strong typedef", something like: [...] (3) The only place where currently a TextClass copy constructor is used is: /// Constructs a DocumentClass based upon a LayoutFile. DocumentClass(LayoutFile const & tc); If we could get rid of this method TextClass could be made noncopyable. Right now, TextClass is copyable only by its subclasses. But changing that wouldn't help with the larger problem, since the standard containers demand copy and assign no matter what, right? So it's the fact that a TextClass contains a std::vector that is the issue. Or so gcc says. rh
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
On Sat, Mar 08, 2008 at 12:38:22PM -0500, rgheck wrote: > (1) go back to a standard container of pointers---but just normal pointers > [...] > (2) use a "strong typedef", something like: > [...] (3) The only place where currently a TextClass copy constructor is used is: /// Constructs a DocumentClass based upon a LayoutFile. DocumentClass(LayoutFile const & tc); If we could get rid of this method TextClass could be made noncopyable. Andre'
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
On Sat, Mar 08, 2008 at 12:38:22PM -0500, rgheck wrote:
> (1) go back to a standard container of pointers---but just normal pointers
> this time---and make the pointers be managed by TextClass, which is where
> the container is; then we can make Layouts non-copyable. This won't be too
> bad, because there's only one reason Layouts ever get deleted, namely,
> because you run into a NoStyle tag in a layout file. I've recently done
> exactly this with some other containers, for much this kind of reason: see
> http://www.lyx.org/trac/changeset/23526. So it would be pretty
> straightforward, I think.
This sounds good enough for our reasons...
>
> (2) use a "strong typedef", something like:
> class LayoutIndex {
> public:
> ///
> typedef Layout base_type;
> ///
> LayoutIndex(LayoutIndex const & lfi) :
> data_(lfi.data_) {}
> ///
> LayoutIndex const & operator=(LayoutIndex const & lfi)
> { data_ = lfi.data_; return *this; }
> ///
> operator base_type const & () const { return data_; }
> ///
> bool empty() const { return data_.empty(); }
> private:
> ///
> LayoutIndex(base_type t) : data_(t) {}
> ///
> base_type & data_;
> ///
> friend class TextClass;
> };
> inside TextClass, and have the relevant methods always return LayoutIndex
> objects, and make methods like setLayout require them. Then Layout objects
> don't need to be non-copyable; only TextClass will be able to create the
> LayoutIndex objects, and the only way to get one will be from a TextClass
> object. You introduced something similar to this into TextClassList, now
> LayoutFileList.[...]
This sounds ok, too.
> Do you see a reason to prefer one or the other here?
The second approach seems to require more changes to other places in the
code, so 'least effort' seems to be the first one.
I have rally no strong preference here, but having one or the other
would be nicer than doing nothing.
Andre'
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
Andre Poenitz wrote:
On Sat, Mar 08, 2008 at 03:00:14AM -, [EMAIL PROTECTED] wrote:
Author: rgheck
Date: Sat Mar 8 04:00:13 2008
New Revision: 23551
URL: http://www.lyx.org/trac/changeset/23551
Log:
Comment.
Modified:
lyx-devel/trunk/src/Paragraph.h
Modified: lyx-devel/trunk/src/Paragraph.h
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Paragraph.h?rev=23551
==
--- lyx-devel/trunk/src/Paragraph.h (original)
+++ lyx-devel/trunk/src/Paragraph.h Sat Mar 8 04:00:13 2008
@@ -154,7 +154,7 @@
///
Layout const & layout() const;
- ///
+ /// Do not pass a temporary to this!
void setLayout(Layout const & layout);
I wonder whether we should make Layouts non-copyable to let the compiler
check this restriction...
I know I've made some progress as a programmer when I start thinking
like you, Andre. I've been worrying about this since.
Unfortunately, we can't quite do this at the moment, because we have
standard containers of layouts. Two options suggest themselves.
(1) go back to a standard container of pointers---but just normal
pointers this time---and make the pointers be managed by TextClass,
which is where the container is; then we can make Layouts non-copyable.
This won't be too bad, because there's only one reason Layouts ever get
deleted, namely, because you run into a NoStyle tag in a layout file.
I've recently done exactly this with some other containers, for much
this kind of reason: see http://www.lyx.org/trac/changeset/23526. So it
would be pretty straightforward, I think.
(2) use a "strong typedef", something like:
class LayoutIndex {
public:
///
typedef Layout base_type;
///
LayoutIndex(LayoutIndex const & lfi) :
data_(lfi.data_) {}
///
LayoutIndex const & operator=(LayoutIndex const & lfi)
{ data_ = lfi.data_; return *this; }
///
operator base_type const & () const { return data_; }
///
bool empty() const { return data_.empty(); }
private:
///
LayoutIndex(base_type t) : data_(t) {}
///
base_type & data_;
///
friend class TextClass;
};
inside TextClass, and have the relevant methods always return
LayoutIndex objects, and make methods like setLayout require them. Then
Layout objects don't need to be non-copyable; only TextClass will be
able to create the LayoutIndex objects, and the only way to get one will
be from a TextClass object. You introduced something similar to this
into TextClassList, now LayoutFileList.
Speaking of which, see the attached patch. This look OK?
Do you see a reason to prefer one or the other here?
This last thing seems so useful it should maybe be a template. Or a
handful of templates, depending upon whether you want references,
privacy, etc.
rh
Index: LayoutFile.h
===
--- LayoutFile.h(revision 23550)
+++ LayoutFile.h(working copy)
@@ -35,13 +35,20 @@
///
typedef std::string base_type;
///
- LayoutFileIndex(base_type t) { data_ = t; }
+ LayoutFileIndex(base_type t) : data_(t) {}
///
- operator base_type() const { return data_; }
+ LayoutFileIndex(LayoutFileIndex const & lfi) :
+ data_(lfi.data_) {}
///
+ LayoutFileIndex const & operator=(LayoutFileIndex const & lfi)
+ { data_ = lfi.data_; return *this; }
+ ///
+ operator base_type const & () const { return data_; }
+ ///
bool empty() const { return data_.empty(); }
private:
- base_type data_;
+ ///
+ base_type & data_;
};
/// This class amounts to little more than a `strong typedef'.
Re: compile problem
> Menus.cpp:1477: error: within this context > Menus.cpp:909: error: 'void lyx::frontendMenu::checkShortcuts() > const' is private > Menus.cpp:1480: error: within this context > make[5]: *** [Menus.lo] Error 1 fixed now > p
compile problem
g++ -DHAVE_CONFIG_H -I. -I../../../src -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -DQT_NO_STL -DQT_NO_KEYWORDS -I../../.. /src -I../../../src/frontends -I../../../images -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/inclu de/qt4/QtGui -I../../../boost -Wextra -Wall -O -MT Menus.lo -MD -MP -MF .deps/Menus.Tpo -c Menus.cpp -o Menus.o Menus.cpp: In constructor 'lyx::frontendGuiPopupMenu::GuiPopupMenu(lyx::frontend::GuiView*, const lyx::f rontendMenuItem&, bool)': Menus.cpp:290: warning: 'lyx::frontendGuiPopupMenu::owner_' will be initialized after Menus.cpp:284: warning: 'const bool lyx::frontendGuiPopupMenu::top_level_' Menus.cpp:263: warning: when initialized here Menus.cpp: In member function 'void lyx::frontend::Menus::Impl::macxMenuBarInit(lyx::frontend::GuiView*)': Menus.cpp:233: error: 'void lyx::frontendMenu::add(const lyx::frontendMenuItem&)' is privat e Menus.cpp:592: error: within this context Menus.cpp: In member function 'void lyx::frontend::Menus::Impl::expand(const lyx::frontendMenu&, lyx::fr ontendMenu&, const lyx::Buffer*) const': Menus.cpp:977: error: 'void lyx::frontendMenu::expandLastfiles()' is private Menus.cpp:1401: error: within this context Menus.cpp:993: error: 'void lyx::frontendMenu::expandDocuments()' is private Menus.cpp:1405: error: within this context Menus.cpp:1020: error: 'void lyx::frontendMenu::expandBookmarks()' is private Menus.cpp:1409: error: within this context Menus.cpp:1036: error: 'void lyx::frontendMenu::expandFormats(lyx::frontendMenuItem::Kind, const lyx::Buffer*)' is private Menus.cpp:1416: error: within this context Menus.cpp:1155: error: 'void lyx::frontendMenu::expandFlexInsert(const lyx::Buffer*, std::string)' is pr ivate Menus.cpp:1420: error: within this context Menus.cpp:1155: error: 'void lyx::frontendMenu::expandFlexInsert(const lyx::Buffer*, std::string)' is pr ivate Menus.cpp:1424: error: within this context Menus.cpp:1155: error: 'void lyx::frontendMenu::expandFlexInsert(const lyx::Buffer*, std::string)' is pr ivate Menus.cpp:1428: error: within this context Menus.cpp:1114: error: 'void lyx::frontendMenu::expandFloatListInsert(const lyx::Buffer*)' is private Menus.cpp:1432: error: within this context Menus.cpp:1134: error: 'void lyx::frontendMenu::expandFloatInsert(const lyx::Buffer*)' is private Menus.cpp:1436: error: within this context Menus.cpp:1319: error: 'void lyx::frontendMenu::expandPasteRecent()' is private Menus.cpp:1440: error: within this context Menus.cpp:1333: error: 'void lyx::frontendMenu::expandToolbars()' is private Menus.cpp:1444: error: within this context Menus.cpp:1360: error: 'void lyx::frontendMenu::expandBranches(const lyx::Buffer*)' is private Menus.cpp:1448: error: within this context Menus.cpp:1232: error: 'void lyx::frontendMenu::expandToc(const lyx::Buffer*)' is private Menus.cpp:1452: error: within this context Menus.cpp:676: error: 'void lyx::frontendMenu::addWithStatusCheck(const lyx::frontendMenuIt em&)' is private Menus.cpp:1460: error: within this context Menus.cpp:676: error: 'void lyx::frontendMenu::addWithStatusCheck(const lyx::frontendMenuIt em&)' is private Menus.cpp:1465: error: within this context Menus.cpp:900: error: 'bool lyx::frontendMenu::hasFunc(const lyx::FuncRequest&) const' is private Menus.cpp:1469: error: within this context Menus.cpp:676: error: 'void lyx::frontendMenu::addWithStatusCheck(const lyx::frontendMenuIt em&)' is private Menus.cpp:1470: error: within this context Menus.cpp:253: error: 'std::vector::MenuItem, std::allocator::MenuI tem> > lyx::frontendMenu::items_' is private Menus.cpp:1476: error: within this context Menus.cpp:253: error: 'std::vector::MenuItem, std::allocator::MenuI tem> > lyx::frontendMenu::items_' is private Menus.cpp:1477: error: within this context Menus.cpp:909: error: 'void lyx::frontendMenu::checkShortcuts() const' is private Menus.cpp:1480: error: within this context make[5]: *** [Menus.lo] Error 1 p
Re: [Cvslog] r23551 - /lyx-devel/trunk/src/Paragraph.h
On Sat, Mar 08, 2008 at 03:00:14AM -, [EMAIL PROTECTED] wrote: > Author: rgheck > Date: Sat Mar 8 04:00:13 2008 > New Revision: 23551 > > URL: http://www.lyx.org/trac/changeset/23551 > Log: > Comment. > > Modified: > lyx-devel/trunk/src/Paragraph.h > > Modified: lyx-devel/trunk/src/Paragraph.h > URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Paragraph.h?rev=23551 > == > --- lyx-devel/trunk/src/Paragraph.h (original) > +++ lyx-devel/trunk/src/Paragraph.h Sat Mar 8 04:00:13 2008 > @@ -154,7 +154,7 @@ > > /// > Layout const & layout() const; > - /// > + /// Do not pass a temporary to this! > void setLayout(Layout const & layout); I wonder whether we should make Layouts non-copyable to let the compiler check this restriction... Andre'
Re: InsetText Crash
Andre Poenitz wrote: On Sat, Mar 08, 2008 at 03:59:35PM +0100, Abdelrazak Younes wrote: Andre Poenitz wrote: On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote: [] There was no crash here, I had the exception message box displayed and the buffer closed. How do you get a backtrace in this situation? Well, I down need one, the message box tells me which inset is problematic. Isn't that what we want to know? For the buffer-in-inset stuff, yes. But in general I'd like to have a backtrace pointing to the place where a segfault happened, not to the place where some event loop decided to pop up a dialog... Agreed yes. And I changed that with an assertion there. Abdel.
Re: InsetText Crash
On Sat, Mar 08, 2008 at 03:59:35PM +0100, Abdelrazak Younes wrote: > Andre Poenitz wrote: >> On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote: >> [] >>> There was no crash here, I had the exception message box displayed and >>> the buffer closed. >> How do you get a backtrace in this situation? > > Well, I down need one, the message box tells me which inset is problematic. > Isn't that what we want to know? For the buffer-in-inset stuff, yes. But in general I'd like to have a backtrace pointing to the place where a segfault happened, not to the place where some event loop decided to pop up a dialog... Andre'
Re: InsetText Crash
Andre Poenitz wrote: On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote: [] There was no crash here, I had the exception message box displayed and the buffer closed. How do you get a backtrace in this situation? Well, I down need one, the message box tells me which inset is problematic. Isn't that what we want to know? Abdel.
Re: InsetText Crash
Andre Poenitz schrieb: On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote: [] There was no crash here, I had the exception message box displayed and the buffer closed. How do you get a backtrace in this situation? I am on windows also, and it is hard this way. If the exception is not caught and i start the program from within visual studio i can immediately debug with a call stack in a separate window, where i can click every line to jump to the code and inspect all the variables that are involved. bernhard
Re: InsetText Crash
On Sat, Mar 08, 2008 at 01:36:04PM +0100, Abdelrazak Younes wrote: [] > There was no crash here, I had the exception message box displayed and the > buffer closed. How do you get a backtrace in this situation? Andre'
Re: InsetText Crash
Andre Poenitz wrote:
On Sat, Mar 08, 2008 at 12:45:37PM +0100, Bernhard Roider wrote:
Andre Poenitz schrieb:
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor, and
from there in basic_string. So it looks as if there's an uninitialized
string in the Layout object, but I don't see how that could be. I think
the the paragraph in question is using emptyParagraphLayout, which is
simply a static and otherwise undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar problems
elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate the
crash.
Hm... this new 'Software Exception' dialog is pretty efficient at
creating useless stack traces.. *sigh*
That's why i needed some time to figure out the origin of the crash. Maybe
it should be disabled in debug mode?
I'd think so...
However, check with the Windows folks first, maybe the current situation
is better for them.
There was no crash here, I had the exception message box displayed and
the buffer closed.
Abdel.
Re: InsetText Crash
On Sat, Mar 08, 2008 at 12:45:37PM +0100, Bernhard Roider wrote:
> Andre Poenitz schrieb:
>> On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
>>> I've fixed the crash reported by Bernhard at r23549. But I'm still
>>> puzzled about something. The crash is probably a consequence of my
>>> attempt to work on Paragraph.cpp, but I'm not sure exactly what's
>>> happened. The backtrace gives me a crash in the Layout constructor, and
>>> from there in basic_string. So it looks as if there's an uninitialized
>>> string in the Layout object, but I don't see how that could be. I think
>>> the the paragraph in question is using emptyParagraphLayout, which is
>>> simply a static and otherwise undefined Layout object:
>>>namespace {
>>>Layout const emptyParagraphLayout;
>>>}
>>> But why should this have an uninitialized member?
>>>
>>> Anyway, I'm quite puzzled by this and worried we'll find similar problems
>>> elsewhere. If anyone has any ideas, I'd love to hear them.
>>>
>>> Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate the
>>> crash.
>> Hm... this new 'Software Exception' dialog is pretty efficient at
>> creating useless stack traces.. *sigh*
>
> That's why i needed some time to figure out the origin of the crash. Maybe
> it should be disabled in debug mode?
I'd think so...
However, check with the Windows folks first, maybe the current situation
is better for them.
Andre'
Re: amsmaths.inc
rgheck wrote:
> Does this need to be included here, or in every theorem environment? If
> in every one, then it probably ought to go in a more global sort of
> Preamble declaration. Actually, I guess the other ones depend upon that
> one, so that would be OK. But it's kind of fragile that way. So...
It needs to be included in Theorem and Theorem*. The other ones load one of
these automatically (DependsOn flag, which needs to be added to some styles,
though).
> At present, each new global Preamble over-writes the previous one. This
> is very counter-intuitive, so I'd propose this be changed, so that
> Preamble sections ADD TO the existing preamble stuff, rather than
> totally over-writing it. If necessary, we could also have a
> PreambleReset declaration.
>
> Thoughts?
This will break many layout files that deliberatly overwrite Preamble
definitions.
If needed, I'd rather add an AddPreamble flag (but DependsOn would probably be
enough in most cases).
However, for the given problem, Requires is the better solution for trunk (see
patch amsthm.diff). For branch, I'd propose patch amsthm-15.diff.
Jürgen
Index: lib/layouts/theorems.inc
===
--- lib/layouts/theorems.inc (Revision 23556)
+++ lib/layouts/theorems.inc (Arbeitskopie)
@@ -51,12 +51,13 @@
Preamble
\newtheorem{thm}{Theorem}
EndPreamble
+ Requires amsthm
End
Style Corollary
CopyStyle Theorem
- DependsOn Theorem
+ DependsOn Theorem
LatexName cor
LabelString "Corollary \thetheorem."
Preamble
@@ -67,7 +68,7 @@
Style Lemma
CopyStyle Theorem
- DependsOn Theorem
+ DependsOn Theorem
LatexName lem
LabelString "Lemma \thetheorem."
Preamble
@@ -78,7 +79,7 @@
Style Proposition
CopyStyle Theorem
- DependsOn Theorem
+ DependsOn Theorem
LatexName prop
LabelString "Proposition \thetheorem."
Preamble
@@ -89,7 +90,7 @@
Style Conjecture
CopyStyle Theorem
- DependsOn Theorem
+ DependsOn Theorem
LatexName conjecture
LabelString "Conjecture \thetheorem."
Preamble
@@ -100,7 +101,7 @@
Style Fact
CopyStyle Theorem
- DependsOn Theorem
+ DependsOn Theorem
LatexName fact
LabelString "Fact \thetheorem."
Preamble
@@ -111,7 +112,7 @@
Style Definition
CopyStyle Theorem
- DependsOn Theorem
+ DependsOn Theorem
LatexName defn
LabelString "Definition \thetheorem."
Font
@@ -133,9 +134,10 @@
LatexName example
LabelString "Example \thetheorem."
Preamble
- \theoremstyle{definition}
+ \theoremstyle{definition}
\newtheorem{example}[thm]{Example}
EndPreamble
+ Requires amsthm
End
@@ -147,6 +149,7 @@
\theoremstyle{definition}
\newtheorem{problem}[thm]{Problem}
EndPreamble
+ Requires amsthm
End
@@ -158,12 +161,13 @@
\theoremstyle{definition}
\newtheorem{xca}[thm]{Exercise}
EndPreamble
+ Requires amsthm
End
Style Remark
CopyStyle Theorem
- DependsOn Theorem
+ DependsOn Theorem
LatexName rem
LabelString "Remark \thetheorem."
Font
@@ -189,6 +193,7 @@
\theoremstyle{remark}
\newtheorem{claim}[thm]{Claim}
EndPreamble
+ Requires amsthm
End
Index: lib/layouts/theorems-starred.inc
===
--- lib/layouts/theorems-starred.inc (Revision 23556)
+++ lib/layouts/theorems-starred.inc (Arbeitskopie)
@@ -50,6 +50,7 @@
\theoremstyle{plain}
\newtheorem*{thm*}{Theorem}
EndPreamble
+ Requires amsthm
End
@@ -61,6 +62,7 @@
\theoremstyle{plain}
\newtheorem*{cor*}{Corollary}
EndPreamble
+ Requires amsthm
End
@@ -72,6 +74,7 @@
\theoremstyle{plain}
\newtheorem*{lem*}{Lemma}
EndPreamble
+ Requires amsthm
End
@@ -83,6 +86,7 @@
\theoremstyle{plain}
\newtheorem*{prop*}{Proposition}
EndPreamble
+ Requires amsthm
End
@@ -94,6 +98,7 @@
\theoremstyle{plain}
\newtheorem*{conjecture*}{Conjecture}
EndPreamble
+ Requires amsthm
End
@@ -105,6 +110,7 @@
\theoremstyle{plain}
\newtheorem*{fact*}{Fact}
EndPreamble
+ Requires amsthm
End
@@ -124,6 +130,7 @@
\theoremstyle{definition}
\newtheorem*{defn*}{Definition}
EndPreamble
+ Requires amsthm
End
@@ -135,6 +142,7 @@
\theoremstyle{definition}
\newtheorem*{example*}{Example}
EndPreamble
+ Requires amsthm
End
@@ -146,6 +154,7 @@
\theoremstyle{definition}
\newtheorem*{problem*}{Problem}
EndPreamble
+ Requires amsthm
End
@@ -157,6
Re: r23527 - in /lyx-devel/trunk/src: Makefile.am MenuBackend...
Andre Poenitz wrote: On Sat, Mar 08, 2008 at 09:51:21AM +0100, Abdelrazak Younes wrote: [EMAIL PROTECTED] wrote: Author: poenitz Date: Fri Mar 7 01:21:23 2008 New Revision: 23527 URL: http://www.lyx.org/trac/changeset/23527 Log: merge MenuBackend into frontend/Menus I did not dare to do that myself ;-) Do you plan to do the same for the toolbar backend? It seems to have a few more dependencies in the core, I might try nevertheless. However, the MenuBackend code is fairly self-contained and a bit more flexible than what Qt offers, so replacing it all with Qt classes directly does not realy bring much benefit. Agreed. I have done some more cleanup so that it is completely self contained. I'll commit that later. I want to put in more support for context menu. Abdel.
Re: InsetText Crash
Bernhard Roider wrote:
Andre Poenitz schrieb:
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still
puzzled about something. The crash is probably a consequence of my
attempt to work on Paragraph.cpp, but I'm not sure exactly what's
happened. The backtrace gives me a crash in the Layout constructor,
and from there in basic_string. So it looks as if there's an
uninitialized string in the Layout object, but I don't see how that
could be. I think the the paragraph in question is using
emptyParagraphLayout, which is simply a static and otherwise
undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar
problems elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate
the crash.
Hm... this new 'Software Exception' dialog is pretty efficient at
creating useless stack traces.. *sigh*
That's why i needed some time to figure out the origin of the crash.
Maybe it should be disabled in debug mode?
Yes, I'll do that.
Abdel.
Re: r23527 - in /lyx-devel/trunk/src: Makefile.am MenuBackend...
On Sat, Mar 08, 2008 at 09:51:21AM +0100, Abdelrazak Younes wrote: > [EMAIL PROTECTED] wrote: >> Author: poenitz >> Date: Fri Mar 7 01:21:23 2008 >> New Revision: 23527 >> URL: http://www.lyx.org/trac/changeset/23527 >> Log: >> merge MenuBackend into frontend/Menus > > I did not dare to do that myself ;-) > > Do you plan to do the same for the toolbar backend? It seems to have a few more dependencies in the core, I might try nevertheless. However, the MenuBackend code is fairly self-contained and a bit more flexible than what Qt offers, so replacing it all with Qt classes directly does not realy bring much benefit. > That would be great. If > you do that, keep in mind that there is an obvious misdesign in current > architecture, namely that the backend mixes toolbar descriptions and > status. Because of that, the status is shared among all windows. Oh yes... Andre'
Re: InsetText Crash
Andre Poenitz schrieb:
On Fri, Mar 07, 2008 at 07:16:50PM -0500, rgheck wrote:
I've fixed the crash reported by Bernhard at r23549. But I'm still puzzled
about something. The crash is probably a consequence of my attempt to work
on Paragraph.cpp, but I'm not sure exactly what's happened. The backtrace
gives me a crash in the Layout constructor, and from there in basic_string.
So it looks as if there's an uninitialized string in the Layout object, but
I don't see how that could be. I think the the paragraph in question is
using emptyParagraphLayout, which is simply a static and otherwise
undefined Layout object:
namespace {
Layout const emptyParagraphLayout;
}
But why should this have an uninitialized member?
Anyway, I'm quite puzzled by this and worried we'll find similar problems
elsewhere. If anyone has any ideas, I'd love to hear them.
Obviously, svn up -r 23548, then Help>LaTeX Configuration to generate the
crash.
Hm... this new 'Software Exception' dialog is pretty efficient at
creating useless stack traces.. *sigh*
That's why i needed some time to figure out the origin of the crash. Maybe it should be disabled in
debug mode?
bernhard
Andre'
Re: [Cvslog] r23545 - /lyx-devel/trunk/lib/layouts/theorems-ams.inc
rgheck wrote:
> Preamble
> + \usepackage{amsthm}
> \theoremstyle{plain}
> \newtheorem{thm}{Theorem}
> EndPreamble
I'd prefer
+ Requires amsthm
Jürgen
Re: r23527 - in /lyx-devel/trunk/src: Makefile.am MenuBackend...
[EMAIL PROTECTED] wrote: Author: poenitz Date: Fri Mar 7 01:21:23 2008 New Revision: 23527 URL: http://www.lyx.org/trac/changeset/23527 Log: merge MenuBackend into frontend/Menus I did not dare to do that myself ;-) Do you plan to do the same for the toolbar backend? That would be great. If you do that, keep in mind that there is an obvious misdesign in current architecture, namely that the backend mixes toolbar descriptions and status. Because of that, the status is shared among all windows. I feel that this is something that should be cleaned up before 1.6.0. Abdel.
