Re: dialog creation
Richard Heck wrote: Andre Poenitz wrote: Is there a particular reason we keep the dialogs around instead of re-build them each time they are shown? Do they keep important state? I seem to remember some conversations in which people did want some of the dialogs to retain state. E.g., if you want to apply the same settings to a sequence of paragraphs. But I'm not sure. Yes, I think your reasoning is correct. But we could also save in the current dialog settings in Qt session management. Actually, I think we should. Abdel.
Re: mathed display broken?
Andre Poenitz wrote: Mathed does not display anymore those blue boxes for empty cells. Anybody feeling responsible? I think I do... where is the code that draws those blue boxes? Abdel.
Re: *not* everything is an inset!
On Wed, 03 Oct 2007 03:57:56 +0200
Dov Feldstern <[EMAIL PROTECTED]> wrote:
> Hi!
>
> This is an email I started writing a couple of months ago, regarding the
> ignore-spellcheck discussion; but it is even more relevant now with
> reference to the questions being raised about character styles as insets.
>
> I agree very much with what JMarc has been saying about this issue:
> although I like very much the idea of character styles / logical markup,
> I don't think that insets are the right paradigm for implementing this.
>
> I will try to articulate here when, in my opinion, an inset is
> appropriate and when it is not. I can't provide hard and fast rules, but
> here are a few questions which could be asked about a given piece of
> text, and which I think could help us clarify whether or not an inset is
> appropriate. (A lot of the questions may actually
> be asking the same thing in different forms; but then that's to be
> expected, since if I'm correct, then they are all describing
> "inset-ness" versus "non-inset-ness"). Based on each question, I will
> try to evaluate the status of various existing insets, as well as that
> of Character Styles. And I will also try to explain for each question
> why I think it describes "inset-ness".
>
> 1) Would the sentence still make sense if the text in question were
> replaced with a "black box"? Or put slightly differently: if a reader
> were to read the sentence, but instead of seeing the text in question,
> he would only know that "text of type X" belongs here, would the reader
> still get the gist of the sentence --- perhaps missing some details, but
> understanding th basic "template" of the sentence? If yes --- the text
> belongs in an inset. If no --- it does not.
>
> Note that for virtually all the insets which currently exist in LyX, the
> answer to this question is clearly "yes": almost all of the existing
> insets (footnote, note / comment, reference, ...) are not a main part of
> the sentence at all, and the sentence would be perfectly readable
> without the text in question altogether. The only case which could
> perhaps be borderline is a mathematical expression; but even in this
> case, I contend that the omission of the contents of the inset would not
> change the overall meaning of the sentence. OTOH, in the case of
> character styles, replacing it's contents with just a "emph text here"
> message would almost certainly leave us with a grammatically incorrect
> sentence, of which we could get no gist.
>
> For example, from the following sentence I have omitted the contents of
> the mathematical formulas and the references, leaving only the markers
> ($ $ and \ref{}):
>
> "An important difference in our case is that there exist measures $ $
> for which the set $ $ has \textit{no} largest element (see
> Proposition~\ref{} in Section~\ref{})."
>
> Clearly, this omission is of a whole different nature than the omission
> of the \textit{} text would have been! With the current omissions, we're
> still left with a more or less grammatically correct sentence; omitting
> the \textit{} text would not have preserved this property! (Not to
> mention the fact that in this particular case, the entire meaning of the
> sentence would be reversed by such an omission...)
>
> Why do I think that this question is related to "inset-ness"? Because of
> the collapsible nature of most insets: collapsing an inset is basically
> replacing the text in question with a black box of a known type. (Again,
> math stands out, since it is not collapsible. And we're going to see
> math standing out a lot. I think math is a special case, where a major
> reason for having it as an inset is the fact that the input method is
> so very different from "normal" text.) The fact that we can set a
> certain type of inset to be non-collapsible is quite beside the point:
> it's just another indication of the fact that perhaps that type of inset
> need not be an inset at all...
No, on the contrary: it is *the* point. A couple of months ago you
would have been correct here; not any more. Charstyles are
'Conglomerate'-type insets, where the content is always visible, and
which collapse to something that takes almost no extra screen real
estate. (And yes, having a three-block geometry might be nice -- for
multi-line insets like branches. For charstyles containing typically
just a few words it is near-irrelevant)
> 2) Does the text in question "belong to" the proposed inset / markup? If
> the attribute which the markup is supposed to endow were to be deleted,
> should the contents be deleted as well? If the answer is that "the
> contents belong to the markup, and should be deleted along with it",
> then this is an inset. If the contents exists independently of the
> markup, and should remain intact even if the markup is removed, then
> this is *not* an inset.
>
> In the case of virtually all existing insets, the answer is that the
>
Re: *not* everything is an inset!
John Levon wrote: On Tue, Oct 02, 2007 at 10:30:47PM -0400, Richard Heck wrote: There's also the question how all of this gets written to a LyX file. Especially once we're doing XML, it'll be essential that everything be properly nested (unless each character is supposed to be written with all of its associated formatting information, which is insane). Insets are a natural correlate to that, because they nest. This does NOT mean that they have to appear to the user as insets, only that the underlying data structure nests properly. However, insets imply all sorts of things about cursor movement and mouse placement. Unless things in this area got *massively* cleaned up since I last looked at the code, getting correct cursor movement with char-ranges-as-insets will not be easy. We will face challenge for sure but Cursor movement is already working well for entering and leaving insets. We will have to decide what to do with selection though. I am in the opinion that when coming outside of an inset, whatever it is (charstyle included), we should select the full insets. Right now, the implementation offers no other choice in any case. Abdel.
Re: *not* everything is an inset!
Richard Heck wrote: Dov Feldstern wrote: I agree very much with what JMarc has been saying about this issue: although I like very much the idea of character styles / logical markup, I don't think that insets are the right paradigm for implementing this. But there's a point JMarc made along the way which isn't accounted here, and it needs to be, namely: There are two questions here: how charstyles (say) are implemented in the code, and how they appear to the user. The issues that have been raised have to do with how charstyles appear to the user. Whether they exist as insets in LyX isn't critical from that point of view. There's also the question how all of this gets written to a LyX file. Especially once we're doing XML, it'll be essential that everything be properly nested (unless each character is supposed to be written with all of its associated formatting information, which is insane). Insets are a natural correlate to that, because they nest. This does NOT mean that they have to appear to the user as insets, only that the underlying data structure nests properly. Let me also add this point. One of my complaints about fonts and the like as they currently exist is that it can be very hard to tell where they begin and where they end. (Try emphasizing some text and then italicizing something in the middle of it.) Even if the boundaries of the inset are not ordinarily shown, it'd be nice to have them be showABLE, so that you can answer this kind of question without having to View>Source. I fully agree with that. Abdel.
Re: *not* everything is an inset!
Dov Feldstern wrote: Why do I think that this question is related to "inset-ness"? Because of the collapsible nature of most insets: collapsing an inset is basically replacing the text in question with a black box of a known type. (Again, math stands out, since it is not collapsible. And we're going to see math standing out a lot. I think math is a special case, where a major reason for having it as an inset is the fact that the input method is so very different from "normal" text.) The fact that we can set a certain type of inset to be non-collapsible is quite beside the point: it's just another indication of the fact that perhaps that type of inset need not be an inset at all... I think you are mixing up the implementation point of View and the Look&Feel point of View. We can make whatever we like with inset. If we decide that pressing [Delete] in from of a charstyle inset should not delete the inset but "enter the inset and delete the first char" then it's easy enough to implement. But this is look&feel. On the implementation point of view, charstyle as inset has *many* benefit: - shorter code - cleaner code - generic code 2) Does the text in question "belong to" the proposed inset / markup? If the attribute which the markup is supposed to endow were to be deleted, should the contents be deleted as well? If the answer is that "the contents belong to the markup, and should be deleted along with it", then this is an inset. If the contents exists independently of the markup, and should remain intact even if the markup is removed, then this is *not* an inset. It's the same as math really or graphics if you prefer. Those _are_ insets and belong to the text too. So that's not a valid point IMHO. I can think of two possible implementations for storing these attributes in the memory buffer: 1) spans --- which is how font attributes work today; And which is horribly complicated... 2) have each position in the text be represented in the buffer not by a char_type, but rather by a struct which would contain, in addition to the char_type, also the attribute information belonging to that position (and maybe also a pointer to the inset, if it's an inset; this would be an extension of what I once suggested in this thread: http://permalink.gmane.org/gmane.editors.lyx.devel/88025; but this is really a separate issue); and perhaps other position-specific information. That's a hammer... I mean, I think the inset address idea is interesting but replacing each and every char with a bigger structure... ouch! ;-) I'm not saying this is easy, I'm sure there are a million little details that I haven't even considered. But (a) I *do* think that it may be easier than some of the things we want to be able to do if we stick with insets (toggling of character styles; 3-box-model); Not that difficult IMO but a whole lot cleaner. and (b) much more importantly, I just think that the *concept* of inset is wrong; and using the wrong concept is bound to cost a lot later on, because the better the concepts used for coding match the "real concepts", the easier it will be to handle new, currently unforeseen situations --- just because the code will "behave" more closely to how the "real world" it is trying to represent behaves. Again you are mixing up look&feel and implementation ;-) Abdel.
Re: *not* everything is an inset!
On Tue, Oct 02, 2007 at 10:30:47PM -0400, Richard Heck wrote: > Dov Feldstern wrote: > >I agree very much with what JMarc has been saying about this issue: > >although I like very much the idea of character styles / logical > >markup, I don't think that insets are the right paradigm for > >implementing this. > But there's a point JMarc made along the way which isn't accounted here, > and it needs to be, namely: There are two questions here: how charstyles > (say) are implemented in the code, and how they appear to the user. The > issues that have been raised have to do with how charstyles appear to > the user. Whether they exist as insets in LyX isn't critical from that > point of view. > > There's also the question how all of this gets written to a LyX file. > Especially once we're doing XML, it'll be essential that everything be > properly nested (unless each character is supposed to be written with > all of its associated formatting information, which is insane). Insets > are a natural correlate to that, because they nest. This does NOT mean > that they have to appear to the user as insets, only that the underlying > data structure nests properly. > > Let me also add this point. One of my complaints about fonts and the > like as they currently exist is that it can be very hard to tell where > they begin and where they end. (Try emphasizing some text and then > italicizing something in the middle of it.) Even if the boundaries of > the inset are not ordinarily shown, it'd be nice to have them be > showABLE, so that you can answer this kind of question without having to > View>Source. > > Richard This is precisely my point also. Dov's argument is clever, and has merit, but it misses this core point: nesting behaviour. Like in HTML / XML, where you could, but should not, write bbb ccc , the same should apply to logical text styles. Insets enforce that in a natural way. Character attributes do not, and a major part of the hellish complexity of handling them, and their correct LaTeX output, is due to this. (As a historical note, I started out developing branches based on character attributes. Angus et al. forced me to use insets instead. Good that he did. Of course branches are a different thing, but it tought me the advantages of encapsulation and imposing structure -- and allowing user configurability down the line! -- that insets bring.) - Martin
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Wed, Oct 03, 2007 at 03:58:29AM +0200, Dov Feldstern wrote: > Bo Peng wrote: > >Let us put it in this way: people wants different emph styles that are > >commonly provided as bold and italics (or emph, or additionally > >\underline) by other word processors . Lyx has emph but not bold, and > >that is confusing and inconvenient (I am talking about toolbar/menu, > >not shortcuts). To new users, lyx has ONLY one emph style. > > > > As an interim solution for 1.5, why not add a button which does "bold", > but which is called "strong" --- same as we have a button which does > "italics" (yes, I know that technically it's \emph, but most users --- > especially those new to LyX/latex --- think of it as italics) but is > called "emph". > > I think that that's simple enough for users who just want "bold" and > "italics", but just different enough to convey to those same users the > message that LyX is about logical (emphasis, strong) rather than > physical/typographical (bold, italics). Obviously, one of the most FAQ > will be: "how do I get bold/italic"? and of course the answer should be: > use strong/emph, with a short explanation about LyX's concepts of > logical rather than physical document-processing. [And I guess that if > this is done, the keybindings should also be adapted accordingly: no > more Ctrl-B, but rather Ctrl-S --- or whatever --- for strong.] > > Longer term, Character Styles and true Logical Markup are definitely the > way to go IMO, but see my thoughts on that in a separate message. > > Dov Sounds good. - Martin
Re: *not* everything is an inset!
On Tue, Oct 02, 2007 at 10:30:47PM -0400, Richard Heck wrote: > There's also the question how all of this gets written to a LyX file. > Especially once we're doing XML, it'll be essential that everything be > properly nested (unless each character is supposed to be written with > all of its associated formatting information, which is insane). Insets > are a natural correlate to that, because they nest. This does NOT mean > that they have to appear to the user as insets, only that the underlying > data structure nests properly. However, insets imply all sorts of things about cursor movement and mouse placement. Unless things in this area got *massively* cleaned up since I last looked at the code, getting correct cursor movement with char-ranges-as-insets will not be easy. regards john
Re: *not* everything is an inset!
Dov Feldstern wrote: I agree very much with what JMarc has been saying about this issue: although I like very much the idea of character styles / logical markup, I don't think that insets are the right paradigm for implementing this. But there's a point JMarc made along the way which isn't accounted here, and it needs to be, namely: There are two questions here: how charstyles (say) are implemented in the code, and how they appear to the user. The issues that have been raised have to do with how charstyles appear to the user. Whether they exist as insets in LyX isn't critical from that point of view. There's also the question how all of this gets written to a LyX file. Especially once we're doing XML, it'll be essential that everything be properly nested (unless each character is supposed to be written with all of its associated formatting information, which is insane). Insets are a natural correlate to that, because they nest. This does NOT mean that they have to appear to the user as insets, only that the underlying data structure nests properly. Let me also add this point. One of my complaints about fonts and the like as they currently exist is that it can be very hard to tell where they begin and where they end. (Try emphasizing some text and then italicizing something in the middle of it.) Even if the boundaries of the inset are not ordinarily shown, it'd be nice to have them be showABLE, so that you can answer this kind of question without having to View>Source. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Crash in Current SVN
Open LyX. File>New. Quit. #0 0x00110402 in __kernel_vsyscall () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #1 0x0068fba0 in raise () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #2 0x006914b1 in abort () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #3 0x00b2fb40 in __gnu_cxx::__verbose_terminate_handler () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #4 0x00b2d625 in std::set_unexpected () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #5 0x00b2d662 in std::terminate () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #6 0x00b2dd05 in __cxa_pure_virtual () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #7 0x086cdd3f in lyx::frontend::LyXView::disconnectBuffer (this=0x95df5f4) at LyXView.cpp:172 #8 0x086cf011 in ~LyXView (this=0x95df5f4) at LyXView.cpp:83 #9 0x088769e9 in ~GuiViewBase (this=0x95df5e0) at GuiView.cpp:291 #10 0x00200ca9 in QObject::event () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #11 0x02f949a2 in QWidget::event () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #12 0x0327524f in QMainWindow::event () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #13 0x08872ae4 in lyx::frontend::GuiViewBase::event (this=0x95df5e0, e=0x9868760) at GuiView.cpp:759 #14 0x02f55930 in QApplicationPrivate::notify_helper () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #15 0x02f5b96e in QApplication::notify () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #16 0x086e0406 in lyx::frontend::GuiApplication::notify (this=0x95230b0, receiver=0x95df5e0, event=0x9868760) at GuiApplication.cpp:290 #17 0x001f2c7b in QCoreApplication::notifyInternal () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #18 0x001f42e0 in QCoreApplicationPrivate::sendPostedEvents () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #19 0x001f459d in QCoreApplication::sendPostedEvents () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #20 0x001f4690 in QCoreApplication::exec () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #21 0x02f54f37 in QApplication::exec () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/debug/safe_iterator.h:194 #22 0x086e0238 in lyx::frontend::GuiApplication::exec (this=0x95230b0) at GuiApplication.cpp:211 #23 0x08139c6b in lyx::LyX::exec (this=0xbfcb8c8c, [EMAIL PROTECTED], argv=0xbfcb8d44) at LyX.cpp:484 #24 0x0806a702 in main (argc=1, argv=Cannot access memory at address 0x7630 ) at main.cpp:48 ^done -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Bo Peng wrote: Let us put it in this way: people wants different emph styles that are commonly provided as bold and italics (or emph, or additionally \underline) by other word processors . Lyx has emph but not bold, and that is confusing and inconvenient (I am talking about toolbar/menu, not shortcuts). To new users, lyx has ONLY one emph style. As an interim solution for 1.5, why not add a button which does "bold", but which is called "strong" --- same as we have a button which does "italics" (yes, I know that technically it's \emph, but most users --- especially those new to LyX/latex --- think of it as italics) but is called "emph". I think that that's simple enough for users who just want "bold" and "italics", but just different enough to convey to those same users the message that LyX is about logical (emphasis, strong) rather than physical/typographical (bold, italics). Obviously, one of the most FAQ will be: "how do I get bold/italic"? and of course the answer should be: use strong/emph, with a short explanation about LyX's concepts of logical rather than physical document-processing. [And I guess that if this is done, the keybindings should also be adapted accordingly: no more Ctrl-B, but rather Ctrl-S --- or whatever --- for strong.] Longer term, Character Styles and true Logical Markup are definitely the way to go IMO, but see my thoughts on that in a separate message. Dov
*not* everything is an inset!
Hi!
This is an email I started writing a couple of months ago, regarding the
ignore-spellcheck discussion; but it is even more relevant now with
reference to the questions being raised about character styles as insets.
I agree very much with what JMarc has been saying about this issue:
although I like very much the idea of character styles / logical markup,
I don't think that insets are the right paradigm for implementing this.
I will try to articulate here when, in my opinion, an inset is
appropriate and when it is not. I can't provide hard and fast rules, but
here are a few questions which could be asked about a given piece of
text, and which I think could help us clarify whether or not an inset is
appropriate. (A lot of the questions may actually
be asking the same thing in different forms; but then that's to be
expected, since if I'm correct, then they are all describing
"inset-ness" versus "non-inset-ness"). Based on each question, I will
try to evaluate the status of various existing insets, as well as that
of Character Styles. And I will also try to explain for each question
why I think it describes "inset-ness".
1) Would the sentence still make sense if the text in question were
replaced with a "black box"? Or put slightly differently: if a reader
were to read the sentence, but instead of seeing the text in question,
he would only know that "text of type X" belongs here, would the reader
still get the gist of the sentence --- perhaps missing some details, but
understanding th basic "template" of the sentence? If yes --- the text
belongs in an inset. If no --- it does not.
Note that for virtually all the insets which currently exist in LyX, the
answer to this question is clearly "yes": almost all of the existing
insets (footnote, note / comment, reference, ...) are not a main part of
the sentence at all, and the sentence would be perfectly readable
without the text in question altogether. The only case which could
perhaps be borderline is a mathematical expression; but even in this
case, I contend that the omission of the contents of the inset would not
change the overall meaning of the sentence. OTOH, in the case of
character styles, replacing it's contents with just a "emph text here"
message would almost certainly leave us with a grammatically incorrect
sentence, of which we could get no gist.
For example, from the following sentence I have omitted the contents of
the mathematical formulas and the references, leaving only the markers
($ $ and \ref{}):
"An important difference in our case is that there exist measures $ $
for which the set $ $ has \textit{no} largest element (see
Proposition~\ref{} in Section~\ref{})."
Clearly, this omission is of a whole different nature than the omission
of the \textit{} text would have been! With the current omissions, we're
still left with a more or less grammatically correct sentence; omitting
the \textit{} text would not have preserved this property! (Not to
mention the fact that in this particular case, the entire meaning of the
sentence would be reversed by such an omission...)
Why do I think that this question is related to "inset-ness"? Because of
the collapsible nature of most insets: collapsing an inset is basically
replacing the text in question with a black box of a known type. (Again,
math stands out, since it is not collapsible. And we're going to see
math standing out a lot. I think math is a special case, where a major
reason for having it as an inset is the fact that the input method is
so very different from "normal" text.) The fact that we can set a
certain type of inset to be non-collapsible is quite beside the point:
it's just another indication of the fact that perhaps that type of inset
need not be an inset at all...
2) Does the text in question "belong to" the proposed inset / markup? If
the attribute which the markup is supposed to endow were to be deleted,
should the contents be deleted as well? If the answer is that "the
contents belong to the markup, and should be deleted along with it",
then this is an inset. If the contents exists independently of the
markup, and should remain intact even if the markup is removed, then
this is *not* an inset.
In the case of virtually all existing insets, the answer is that the
contents belong to the inset: if a footnote is deleted, its text should
not remain intact --- this would be disruptive to the main text (which
is why it was placed in a footnote in the first place). (Dissolve is a
special case, which is extremely useful at times; but it's not the norm
of what deleting an inset means.) OTOH, in the case of character styles,
the text should never be deleted along with the markup; after all, it's
an integral part of the original sentence. So the contents do not belong
to the markup, but to the containing sentence.
Why do I think this measures "inset-ness"? Because precisely one of the
purposes of an inset is to
[PATCH] LyX crashes loading a munged layout
Patch fixes bug. Very safe indeed. Jurgen? Richard [EMAIL PROTECTED] wrote: http://bugzilla.lyx.org/show_bug.cgi?id=4232 --- Additional Comments From [EMAIL PROTECTED] 2007-10-03 02:55 --- bt #0 0x00110402 in __kernel_vsyscall () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #1 0x0068fba0 in raise () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #2 0x006914b1 in abort () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #3 0x0896e00b in lyx::support::abort () at abort.cpp:25 #4 0x08087ef8 in boost::assertion_failed (expr=0x8a7041f "false", function=0x8a83820 "const lyx::Layout_ptr& lyx::TextClass::operator[](const lyx::docstring&) const", file=0x8a82d95 "TextClass.cpp", line=891) at boost.cpp:56 #5 0x0840b906 in lyx::TextClass::operator[] (this=0x93cdfd0, [EMAIL PROTECTED]) at TextClass.cpp:891 #6 0x08370b6e in lyx::Paragraph::expandLabel (this=0x971bb50, [EMAIL PROTECTED], [EMAIL PROTECTED], process_appendix=true) at Paragraph.cpp:1675 #7 0x080d4a7e in setLabel ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at buffer_funcs.cpp:507 #8 0x080d8e20 in lyx::updateLabels ([EMAIL PROTECTED], childonly=false) at buffer_funcs.cpp:668 #9 0x08691155 in lyx::LyXView::loadLyXFile (this=0x93eabdc, [EMAIL PROTECTED], tolastfiles=true, child_document=false, auto_open=false) at LyXView.cpp:230 #10 0x082e97dd in lyx::LyXFunc::open (this=0x932b550, [EMAIL PROTECTED]) at LyXFunc.cpp:2075 #11 0x082f30d2 in lyx::LyXFunc::dispatch (this=0x932b550, [EMAIL PROTECTED]) at LyXFunc.cpp:1276 #12 0x082bffec in lyx::dispatch ([EMAIL PROTECTED]) at LyX.cpp:1511 #13 0x0868d283 in lyx::LyXView::dispatch (this=0x93eabdc, [EMAIL PROTECTED]) at LyXView.cpp:514 #14 0x0887c923 in lyx::frontend::Action::action (this=0x97109a8) at Action.cpp:90 #15 0x0887c998 in lyx::frontend::Action::qt_metacall (this=0x97109a8, _c=QMetaObject::InvokeMetaMethod, _id=0, _a=0xbffcf16c) at Action_moc.cpp:69 #16 0x0020464a in QMetaObject::activate () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #17 0x00204930 in QMetaObject::activate () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #18 0x02f4f7d1 in QAction::triggered () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #19 0x02f5062f in QAction::activate () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #20 0x03299451 in QMenu::wheelEvent () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #21 0x0329ba27 in QMenu::mouseReleaseEvent () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #22 0x02f94f43 in QWidget::event () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #23 0x03297415 in QMenu::event () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #24 0x02f55930 in QApplicationPrivate::notify_helper () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #25 0x02f5bac7 in QApplication::notify () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #26 0x086f16ea in lyx::frontend::GuiApplication::notify (this=0x932efa0, receiver=0x970da70, event=0xbffcf718) at GuiApplication.cpp:254 #27 0x001f2c7b in QCoreApplication::notifyInternal () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #28 0x02fabe8c in QApplication::x11ProcessEvent () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #29 0x02faaa4f in QApplication::x11ProcessEvent () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #30 0x02fcee64 in QX11Info::copyX11Data () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #31 0x00bc0442 in g_main_context_dispatch () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #32 0x00bc341f in g_main_context_check () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #33 0x00bc3985 in g_main_context_iteration () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #34 0x00214198 in QEventDispatcherGlib::processEvents () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #35 0x02fcec15 in QX11Info::copyX11Data () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #36 0x001f21a1 in QEventLoop::processEvents () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/stl_tree.h:169 #37 0x001f22ac in QEventLoop::exec () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bi
Re: [Cvslog] r20677 - /lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py
Stupid mistake. Fixed at 20678.
[EMAIL PROTECTED] wrote:
Author: uwestoehr
Date: Wed Oct 3 02:09:47 2007
New Revision: 20677
URL: http://www.lyx.org/trac/changeset/20677
Log:
lyx_1_6.py: fix endless loop, but routine is still not working, see
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg128426.html
Modified:
lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py
Modified: lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py
URL:
http://www.lyx.org/trac/file/lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py?rev=20677
==
--- lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py (original)
+++ lyx-devel/trunk/lib/lyx2lyx/lyx_1_6.py Wed Oct 3 02:09:47 2007
@@ -303,6 +303,8 @@
Some insets may end up being converted to insets earlier versions of LyX
will not be able to recognize. Not sure what to do about that.
"""
+ # FIXME, this routine doesn't work, must be fixed before LyX 1.6.0, see
+ # http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg128426.html
i = 0
while 1:
i = find_token(document.body, "\\begin_inset CommandInset", i)
@@ -311,7 +313,7 @@
m = r.match(nextline)
if not m:
document.warning("Malformed LyX document: Missing LatexCommand in " +
document.body[i] + ".")
- continue
+ return
cmdName = m.group(1)
insertion = ["\\begin_inset LatexCommand " + cmdName]
document.body[i : i+2] = insertion
___
Cvslog mailing list
[EMAIL PROTECTED]
http://www.lyx.org/mailman/listinfo/cvslog
--
==
Richard G Heck, Jr
Professor of Philosophy
Brown University
http://frege.brown.edu/heck/
==
Get my public key from http://sks.keyserver.penguin.de
Hash: 0x1DE91F1E66FFBDEC
Learn how to sign your email using Thunderbird and GnuPG at:
http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: changeset/20544
> Hello Richard, > > there is a bug in yout lyx2lyx routine you commited with r20544: > > - create a document, > - write something in there and save it > - menu Export -> LyX 1.4.x > > -> Python hangs in an endless loop complaining about a missing \end tag. I fixed the endless loop, but the routine still doesn't work. Richard, could you please have a look? thanks and regards Uwe
Re: [Cvslog] r20662 - /www-user/trunk/devel/i18n.inc
On Tue, Oct 02, 2007 at 02:33:18PM -, [EMAIL PROTECTED] wrote: > Author: lasgouttes > Date: Tue Oct 2 16:33:17 2007 > New Revision: 20662 > > URL: http://www.lyx.org/trac/changeset/20662 > Log: > update translation stats > > Modified: > www-user/trunk/devel/i18n.inc Ugh! Unmangled email addresses are exposed on a web page. Please... > Modified: www-user/trunk/devel/i18n.inc > URL: http://www.lyx.org/trac/file/www-user/trunk/devel/i18n.inc?rev=20662 > == > --- www-user/trunk/devel/i18n.inc (original) > +++ www-user/trunk/devel/i18n.inc Tue Oct 2 16:33:17 2007 > @@ -5,109 +5,69 @@ > $branch_tag = "branches/BRANCH_1_5_X"; > > // The data itself > -$podata = array ( > -array ( 'langcode' => 'ca', > -"msg_tr" => 2574, "msg_fu" => 291, "msg_nt" => 695, > -"translator" => "Joan Montané", "email" => "jmontane () gmail ! com", > -"date" => "2007-08-02" ), > +\$podata = array ( > +array ( 'langcode' => 'ca', "date" => "2007-08-19", > +"msg_tr" => 2569, "msg_fu" => 304, "msg_nt" => 701, > +"translator" => "Joan Montané", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'cs', "date" => "2007-08-31", > +"msg_tr" => 3574, "msg_fu" => 0, "msg_nt" => 0, > +"translator" => "Pavel Sanda", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'de', "date" => "2007-08-28", > +"msg_tr" => 3495, "msg_fu" => 0, "msg_nt" => 79, > +"translator" => "Michael Gerz", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'es', "date" => "2006-11-07", > +"msg_tr" => 2552, "msg_fu" => 602, "msg_nt" => 420, > +"translator" => "Eulogio Serradilla", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'eu', "date" => "2006-11-08", > +"msg_tr" => 2552, "msg_fu" => 602, "msg_nt" => 420, > +"translator" => "Iñaki Larrañaga Murgoitio", "email" => "[EMAIL > PROTECTED]"), > +array ( 'langcode' => 'fi', "date" => "2007-07-14", > +"msg_tr" => 2870, "msg_fu" => 65, "msg_nt" => 639, > +"translator" => "Martin Vermeer", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'fr', "date" => "2007-07-18", > +"msg_tr" => 2436, "msg_fu" => 661, "msg_nt" => 477, > +"translator" => "Adrien Rebollo", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'gl', "date" => "2007-07-11", > +"msg_tr" => 3530, "msg_fu" => 28, "msg_nt" => 16, > +"translator" => "Ramon Flores", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'he', "date" => "2007-07-14", > +"msg_tr" => 1838, "msg_fu" => 663, "msg_nt" => 1073, > +"translator" => "Ran Rutenberg", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'hu', "date" => "2007-09-30", > +"msg_tr" => 3574, "msg_fu" => 0, "msg_nt" => 0, > +"translator" => "Alex", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'it', "date" => "2007-10-01", > +"msg_tr" => 3574, "msg_fu" => 0, "msg_nt" => 0, > +"translator" => "Enrico Forestieri", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'ja', "date" => "2007-07-18", > +"msg_tr" => 3340, "msg_fu" => 26, "msg_nt" => 208, > +"translator" => "Koji Yokota", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'ko', "date" => "2007-05-15", > +"msg_tr" => 548, "msg_fu" => 164, "msg_nt" => 2862, > +"translator" => "cghan", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'nb', "date" => "2007-06-01", > +"msg_tr" => 2417, "msg_fu" => 76, "msg_nt" => 1081, > +"translator" => "Helge Hafting", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'nn', "date" => "2007-06-26", > +"msg_tr" => 3441, "msg_fu" => 95, "msg_nt" => 38, > +"translator" => "Ingar Pareliussen", "email" => "ingarp_ved_samfundet.no"), > +array ( 'langcode' => 'pl', "date" => "2006-07-04", > +"msg_tr" => 2332, "msg_fu" => 698, "msg_nt" => 544, > +"translator" => "Andrzej Tomaszewski", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'pt', "date" => "2007-08-13", > +"msg_tr" => 3091, "msg_fu" => 455, "msg_nt" => 28, > +"translator" => "Susana Barbosa", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'ro', "date" => "2007-09-26", > +"msg_tr" => 1844, "msg_fu" => 913, "msg_nt" => 817, > +"translator" => "Marius Ionescu", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'tr', "date" => "2006-07-01", > +"msg_tr" => 1566, "msg_fu" => 734, "msg_nt" => 1274, > +"translator" => "Gürer Özen", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'zh_CN', "date" => "2007-07-18", > +"msg_tr" => 3538, "msg_fu" => 28, "msg_nt" => 8, > +"translator" => "Bo Peng", "email" => "[EMAIL PROTECTED]"), > +array ( 'langcode' => 'zh_TW', "date" => "2007-05-31", > +"msg_tr" => 2003, "msg_fu" => 1479, "msg_nt" => 92, > +"translator" => "Wei-Lun Chao", "email" => "[EMAIL PROTECTED]>") > +)?> > > -array ( 'langcode' => 'cs', > -"msg_tr" => 3560, "msg_fu" => 0, "msg_nt" => 0, > -"translator" => "Pavel Sanda", "email" => "ps () ucw ! cz", > -"date" => "2007-08-31" ), > - > -array ( 'langcode' => 'de', > -"msg_tr" => 3482, "msg_fu" => 0, "msg_nt" => 78,
Re: 1.5.X patch candidate list #5
On Tue, Oct 02, 2007 at 08:08:12AM +0200, Jürgen Spitzmüller wrote: > > http://www.lyx.org/trac/changeset/20527 - Make sure that an empty > > po/POTFILES.in file exists at configure time, > > Probably yes. Enrico? It wouldn't hurt but does not make sense, because POTFILES.in is still distributed in 1.5.x. -- Enrico
Re: dialog creation
Andre Poenitz wrote: Is there a particular reason we keep the dialogs around instead of re-build them each time they are shown? Do they keep important state? I seem to remember some conversations in which people did want some of the dialogs to retain state. E.g., if you want to apply the same settings to a sequence of paragraphs. But I'm not sure. Still, keeping them around can lead to surprises. I speak from experience. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: dialog creation
Andre Poenitz wrote: Is there a particular reason we keep the dialogs around instead of re-build them each time they are shown? Do they keep important state? I seem to remember some conversations in which people did want some of the dialogs to retain state. E.g., if you want to apply the same settings to a sequence of paragraphs. But I'm not sure. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Segfault in Current LyX-1.5.svn
Andre Poenitz wrote: On Tue, Oct 02, 2007 at 03:48:51PM -0400, Richard Heck wrote: Andre Poenitz wrote: On Tue, Oct 02, 2007 at 03:33:39PM -0400, Richard Heck wrote: #0 0x0865ea13 in boost::signals::connection::reset (this=0x99eee14, new_con=0x9a116d0) at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:50 When doing what? It was just segfaulting on startup. I'm recompiling with debug code. This was supposed to be a clean 1.5.svn copy for actual use, without all of that. Just to make sure: We are talking about the stable branch? Yes. It was when I tried to: ./configure --enable-static --disable-shared --disable-debug --disable-stdlib-debug --disable-pch that I had the problem. Now I've gone back to my usual --enable-debug, and it's ok. I'll try again with the other settings. It may have been having too many versions of LyX lying around. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
mathed display broken?
Mathed does not display anymore those blue boxes for empty cells. Anybody feeling responsible? Andre'
dialog creation
Is there a particular reason we keep the dialogs around instead of re-build them each time they are shown? Do they keep important state? Andre'
Re: [Cvslog] r20664 - in /lyx-devel/trunk/src: Buffer.cpp Buffer.h fro...
On Tue, Oct 02, 2007 at 09:06:19PM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >On Tue, Oct 02, 2007 at 06:15:43PM +0200, Abdelrazak Younes wrote: > >>Andre Poenitz wrote: > >>>On Tue, Oct 02, 2007 at 02:39:49PM -, [EMAIL PROTECTED] wrote: > Author: younes > Date: Tue Oct 2 16:39:48 2007 > New Revision: 20664 > > URL: http://www.lyx.org/trac/changeset/20664 > Log: > Fix some issues with buffer closing. > * Switch WorkAreaManager to std::list instead of vector. > >>>Urm, why? > >>Just because of list::remove(). > > > >Does it need to be stable, > > With current implementation I guess yes but I am not sure (see the > remove() method). > > >or do you do that for performance reasons? > > No, only for 3 lines of code reduction. We are not talking about > something critical here, two or 3 items is the maximum size we will have. It was a trick question. Andre'
Re: Segfault in Current LyX-1.5.svn
On Tue, Oct 02, 2007 at 03:48:51PM -0400, Richard Heck wrote: > Andre Poenitz wrote: > >On Tue, Oct 02, 2007 at 03:33:39PM -0400, Richard Heck wrote: > > > >>#0 0x0865ea13 in boost::signals::connection::reset (this=0x99eee14, > >>new_con=0x9a116d0) at > >>../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:50 > >> > >When doing what? > > > It was just segfaulting on startup. > > I'm recompiling with debug code. This was supposed to be a clean 1.5.svn > copy for actual use, without all of that. Just to make sure: We are talking about the stable branch? Andre'
Re: Segfault in Current LyX-1.5.svn
Andre Poenitz wrote: On Tue, Oct 02, 2007 at 03:33:39PM -0400, Richard Heck wrote: #0 0x0865ea13 in boost::signals::connection::reset (this=0x99eee14, new_con=0x9a116d0) at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:50 When doing what? It was just segfaulting on startup. I'm recompiling with debug code. This was supposed to be a clean 1.5.svn copy for actual use, without all of that. I've also tried cleaning out possibly conflicting old stuff. I'll report back shortly. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: Segfault in Current LyX-1.5.svn
On Tue, Oct 02, 2007 at 03:33:39PM -0400, Richard Heck wrote: > > #0 0x0865ea13 in boost::signals::connection::reset (this=0x99eee14, > new_con=0x9a116d0) at > ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:50 > #1 0x08674a1b in boost::signals::detail::slot_base::create_connection > (this=0xbf8aa51c) at slot.cpp:33 > #2 0x083c5813 in boost::slot std::allocator > >::slot boost::_mfi::mf0, > boost::_bi::list1 > > > () at > ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 > #3 0x083c03e8 in lyx::LyXView::LyXView$base () at > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 > #4 0x0841387c in lyx::frontend::GuiView::GuiView () at > ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 > #5 0x0840f25a in lyx::frontend::GuiImplementation::createRegisteredView > () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 > #6 0x083b8dd0 in lyx::frontend::Application::createView () at > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 > #7 0x0817cb6a in lyx::LyX::newLyXView () at > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 > #8 0x0817cba5 in lyx::LyX::restoreGuiSession () at > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 > #9 0x0817d09b in lyx::LyX::execBatchCommands () at > /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 > #10 0x0840a92b in lyx::frontend::GuiApplication::execBatchCommands () at > ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 > #11 0x0840a975 in lyx::frontend::GuiApplication::qt_metacall () at > ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 When doing what? Andre'
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, Oct 02, 2007 at 09:22:10PM +0300, Martin Vermeer wrote: > Like attached, including the recording/undo thing. > > Do we want this? Improves the dissolve discoverability. Why not. > And do we want math colours on the menu tree? > > About changing colours in math, that remains the same as before: delete > old, insert new. Same as with fonts (where sometimes I would have liked > a more direct redefinition path, textbf -> mathbf for instance). > > I don't suppose this is easily changed. Not easily. Andre'
Re: [Cvslog] r20664 - in /lyx-devel/trunk/src: Buffer.cpp Buffer.h fro...
Andre Poenitz wrote: On Tue, Oct 02, 2007 at 06:15:43PM +0200, Abdelrazak Younes wrote: Andre Poenitz wrote: On Tue, Oct 02, 2007 at 02:39:49PM -, [EMAIL PROTECTED] wrote: Author: younes Date: Tue Oct 2 16:39:48 2007 New Revision: 20664 URL: http://www.lyx.org/trac/changeset/20664 Log: Fix some issues with buffer closing. * Switch WorkAreaManager to std::list instead of vector. Urm, why? Just because of list::remove(). Does it need to be stable, With current implementation I guess yes but I am not sure (see the remove() method). or do you do that for performance reasons? No, only for 3 lines of code reduction. We are not talking about something critical here, two or 3 items is the maximum size we will have. Abdel.
Segfault in Current LyX-1.5.svn
#0 0x0865ea13 in boost::signals::connection::reset (this=0x99eee14, new_con=0x9a116d0) at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:50 #1 0x08674a1b in boost::signals::detail::slot_base::create_connection (this=0xbf8aa51c) at slot.cpp:33 #2 0x083c5813 in boost::slotstd::allocator > >::slotboost::_mfi::mf0, boost::_bi::list1 > > > () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 #3 0x083c03e8 in lyx::LyXView::LyXView$base () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 #4 0x0841387c in lyx::frontend::GuiView::GuiView () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 #5 0x0840f25a in lyx::frontend::GuiImplementation::createRegisteredView () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 #6 0x083b8dd0 in lyx::frontend::Application::createView () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 #7 0x0817cb6a in lyx::LyX::newLyXView () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 #8 0x0817cba5 in lyx::LyX::restoreGuiSession () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 #9 0x0817d09b in lyx::LyX::execBatchCommands () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 #10 0x0840a92b in lyx::frontend::GuiApplication::execBatchCommands () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 #11 0x0840a975 in lyx::frontend::GuiApplication::qt_metacall () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 #12 0x0020464a in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #13 0x00204f32 in QMetaObject::activate () from /usr/lib/libQtCore.so.4 #14 0x0020a057 in QTimer::start () from /usr/lib/libQtCore.so.4 #15 0x0020a09c in QTimer::start () from /usr/lib/libQtCore.so.4 #16 0x00200c65 in QObject::event () from /usr/lib/libQtCore.so.4 #17 0x02f55930 in QApplicationPrivate::notify_helper () from /usr/lib/libQtGui.so.4 #18 0x02f5b879 in QApplication::notify () from /usr/lib/libQtGui.so.4 #19 0x0840aa86 in lyx::frontend::GuiApplication::notify () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 #20 0x001f2c7b in QCoreApplication::notifyInternal () from /usr/lib/libQtCore.so.4 #21 0x002164cd in QEventDispatcherUNIX::unregisterTimer () from /usr/lib/libQtCore.so.4 #22 0x00213c30 in QEventDispatcherGlib::registeredTimers () from /usr/lib/libQtCore.so.4 #23 0x00bc0442 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #24 0x00bc341f in g_main_context_check () from /lib/libglib-2.0.so.0 #25 0x00bc3985 in g_main_context_iteration () from /lib/libglib-2.0.so.0 #26 0x00214198 in QEventDispatcherGlib::processEvents () from /usr/lib/libQtCore.so.4 #27 0x02fcec15 in QX11Info::copyX11Data () from /usr/lib/libQtGui.so.4 #28 0x001f21a1 in QEventLoop::processEvents () from /usr/lib/libQtCore.so.4 #29 0x001f22ac in QEventLoop::exec () from /usr/lib/libQtCore.so.4 #30 0x001f465a in QCoreApplication::exec () from /usr/lib/libQtCore.so.4 #31 0x02f54f37 in QApplication::exec () from /usr/lib/libQtGui.so.4 #32 0x0840a9c2 in lyx::frontend::GuiApplication::exec () at ../../../../boost/boost/detail/sp_counted_base_gcc_x86.hpp:159 #33 0x08183181 in lyx::LyX::exec () at /usr/lib/gcc/i386-redhat-linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:257 #34 0x08066e6e in main () ^done -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
pkglib vs noinst
Would that be ok? Jean-Marc? Andre' Index: src/frontends/qt4/Makefile.am === --- src/frontends/qt4/Makefile.am (revision 20665) +++ src/frontends/qt4/Makefile.am (working copy) @@ -20,7 +20,7 @@ # LIBRARIES # -pkglib_LTLIBRARIES = liblyxqt4.la +noinst_LTLIBRARIES = liblyxqt4.la liblyxqt4_la_DEPENDENCIES = $(MOCEDFILES) liblyxqt4_la_LDFLAGS = $(QT4_LDFLAGS) Index: src/frontends/controllers/Makefile.am === --- src/frontends/controllers/Makefile.am (revision 20665) +++ src/frontends/controllers/Makefile.am (working copy) @@ -4,7 +4,7 @@ EXTRA_DIST = tests/regfiles/biblio -pkglib_LTLIBRARIES = liblyxcontrollers.la +noinst_LTLIBRARIES = liblyxcontrollers.la SOURCEFILES = \ Dialog.cpp \ Index: src/frontends/Makefile.am === --- src/frontends/Makefile.am (revision 20665) +++ src/frontends/Makefile.am (working copy) @@ -8,7 +8,7 @@ BUILT_SOURCES = $(PCH_FILE) -pkglib_LTLIBRARIES = liblyxfrontends.la +noinst_LTLIBRARIES = liblyxfrontends.la AM_CPPFLAGS += $(PCH_FLAGS) -I$(srcdir)/.. $(BOOST_INCLUDES) Index: src/Makefile.am === --- src/Makefile.am (revision 20665) +++ src/Makefile.am (working copy) @@ -20,7 +20,7 @@ OTHERLIBS = $(BOOST_LIBS) $(INTLLIBS) $(AIKSAURUS_LIBS) @LIBS@ $(SOCKET_LIBS) -pkglib_LTLIBRARIES = liblyxcore.la +noinst_LTLIBRARIES = liblyxcore.la bin_PROGRAMS = lyx lyx_LDADD = \ @@ -277,7 +277,7 @@ VSpace.h ### Graphics ## -pkglib_LTLIBRARIES += liblyxgraphics.la +noinst_LTLIBRARIES += liblyxgraphics.la liblyxgraphics_la_SOURCES = \ graphics/GraphicsCache.h \ @@ -308,7 +308,7 @@ EXTRA_DIST += mathed/InsetFormulaMacro.cpp -pkglib_LTLIBRARIES += liblyxmathed.la +noinst_LTLIBRARIES += liblyxmathed.la liblyxmathed_la_SOURCES = \ mathed/InsetMathAMSArray.cpp \ @@ -458,7 +458,7 @@ ### Insets ## -pkglib_LTLIBRARIES += liblyxinsets.la +noinst_LTLIBRARIES += liblyxinsets.la EXTRA_DIST += \ insets/InsetTheorem.cpp \ Index: src/support/Makefile.am === --- src/support/Makefile.am (revision 20665) +++ src/support/Makefile.am (working copy) @@ -5,7 +5,7 @@ EXTRA_DIST = pch.h \ os_cygwin.cpp os_unix.cpp os_win32.cpp os_win32.h -pkglib_LTLIBRARIES = liblyxsupport.la +noinst_LTLIBRARIES = liblyxsupport.la liblyxsupport_la_LIBADD = $(LIBSHLWAPI) $(QT4_CORE_LIB) $(BOOST_SIGNALS) liblyxsupport_la_LDFLAGS = $(QT4_CORE_LDFLAGS) Index: boost/Makefile.am === --- boost/Makefile.am (revision 20587) +++ boost/Makefile.am (working copy) @@ -1,6 +1,6 @@ include $(top_srcdir)/config/common.am -pkglib_LTLIBRARIES = liblyxboost.la +noinst_LTLIBRARIES = liblyxboost.la # Using precompiled headers makes compilation >10% slower #EXTRA_DIST = pch.h
Re: 1.5.X patch candidate list #5
Jürgen Spitzmüller wrote: Ah, you are talking about section titles only. Then I agree, they shouldn't be changed. (I thought you were about to remove AlignPossible anywhere -- sorry for not reading more closely). No problem. Thanks for the explanation; your change makes sense indeed. However, let's wait until 1.5.2 is out. That's fine. rh -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, Oct 02, 2007 at 08:06:36PM +0200, Andre Poenitz wrote:
> On Tue, Oct 02, 2007 at 08:34:35PM +0300, Martin Vermeer wrote:
> > Well, the attached patch enables inset dissolving in mathed. (I'm sure
> > I overlooked all kinds of things.)
> >
> > It would be trivial to put the insertion of the most popular colour into
> > mathed on the menu tree.
> >
> > - Martin
> >
>
> > Index: InsetMathNest.cpp
> > ===
> > --- InsetMathNest.cpp (revision 20634)
> > +++ InsetMathNest.cpp (working copy)
> > @@ -1003,7 +1003,9 @@
> > cur.undispatched();
> > break;
> > }
> > -
> > + case LFUN_INSET_DISSOLVE:
> > + if (!cur[(cur.depth() - 2)].text())
> > + cur.pullArg();
> > default:
> > InsetMath::doDispatch(cur, cmd);
> > break;
>
> Looks a bit brutish as it assumes e.g. that no math inset is text, which
> might not be true with real math text. What about
>
> case LFUN_INSET_DISSOLVE:
> if (!asHullInset())
> cur.pullArg();
>
> And maybe even a 'break;' afterwards.
Like attached, including the recording/undo thing.
Do we want this? Improves the dissolve discoverability.
And do we want math colours on the menu tree?
About changing colours in math, that remains the same as before: delete
old, insert new. Same as with fonts (where sometimes I would have liked
a more direct redefinition path, textbf -> mathbf for instance).
I don't suppose this is easily changed.
- Martin
Index: InsetMathNest.cpp
===
--- InsetMathNest.cpp (revision 20634)
+++ InsetMathNest.cpp (working copy)
@@ -1003,6 +1003,12 @@
cur.undispatched();
break;
}
+ case LFUN_INSET_DISSOLVE:
+ if (!asHullInset()) {
+ recordUndoInset(cur, Undo::ATOMIC);
+ cur.pullArg();
+ }
+ break;
default:
InsetMath::doDispatch(cur, cmd);
@@ -1112,6 +1118,10 @@
flag.enabled(false);
break;
+ case LFUN_INSET_DISSOLVE:
+ flag.enabled(!asHullInset());
+ break;
+
default:
ret = false;
break;
Re: signal/slot -> delegates
On Tue, Oct 02, 2007 at 06:35:41PM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >On Tue, Oct 02, 2007 at 09:51:12AM +0200, Abdelrazak Younes wrote: > >>And here is the beginning of a patch. If you could take it and finish > >>the remaining bits together with your patch, you'd make me very happy. > >> > >>Abdel. > >> > > > >>Index: Buffer.cpp > >>=== > >>--- Buffer.cpp (revision 20651) > >>+++ Buffer.cpp (working copy) > >>@@ -68,6 +68,7 @@ > >> #include "mathed/MathSupport.h" > >> > >> #include "frontends/alert.h" > >>+#include "frontends/WorkAreaManager.h" > > > >With that done, does that mean you are now fine with the delegate patch? > > Just one question: what about Buffer::structureChanged() signal? How > would you solve that bit in a multiview context? Maybe we also need a > LyXViewManager? In the long run perhaps. But there will be stuctural changes needed to get there, and we know that the problems are solvable with a few lines. So I am not really too concerned right now. We could also have a "generic" gui delegate that in turn uses signal/slot in its private implementation to connect to the views/workareas/whatever. This way the kernel would not need to use s/s, yet we could use them when they really make sense. Andre'
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, Oct 02, 2007 at 08:34:35PM +0300, Martin Vermeer wrote: > Well, the attached patch enables inset dissolving in mathed. (I'm sure > I overlooked all kinds of things.) > > It would be trivial to put the insertion of the most popular colour into > mathed on the menu tree. > > - Martin > > Index: InsetMathNest.cpp > === > --- InsetMathNest.cpp (revision 20634) > +++ InsetMathNest.cpp (working copy) > @@ -1003,7 +1003,9 @@ > cur.undispatched(); > break; > } > - > + case LFUN_INSET_DISSOLVE: > + if (!cur[(cur.depth() - 2)].text()) > + cur.pullArg(); > default: > InsetMath::doDispatch(cur, cmd); > break; Looks a bit brutish as it assumes e.g. that no math inset is text, which might not be true with real math text. What about case LFUN_INSET_DISSOLVE: if (!asHullInset()) cur.pullArg(); And maybe even a 'break;' afterwards. Andre'
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Le 2 oct. 07 à 17:01, Bo Peng a écrit : Because these are fundamentally different concepts (I keep repeating myself). I do not think \textit and \em are 'fundamentally different'. \textit/\em and CharStyle Emph are. The former are all 'plain latex command', the latter can be any latex command. This is obviously different from what JMarc thinks \em is a command that nobody is supposed to use since 1994. The fact that a macro is defined by latex or a textclass or LyX is not really releavant for the discussion. Do you really make a difference between Layouts that are common to all classes, or specific to a textclass? Shold they be in a different GUI? But there are two different things: * semantic vs explicit marking * font-like extent versus inset. The first one is the one that counts. The second one is an implementation issue. From a user's point of view, the former is mapped to some latex command that is NOT configurable. Everything is configurqble. Use the package ulem and voila! emph is underline (as required by some psychology journals) The later is some complicated inset that provides flexibility at a cost of usability. It would be more naturally to put \textbf along with \em, than to put \strong (leads to a scary inset) along with \em (which simply makes your text italic). The later leads to a macro i nthe .tex code, like the others. You are mixing interface and semantics. You tried really hard to differentiate \textit and \em and tried to convince me your toolbar buttons are *not* italics and underline in word's sense. My view is different. See above. They are different, that's life http://en.wikipedia.org/wiki/Emphasis_(typography) Do you think that a section is exactly the same as a text in larger boldface? JMarc
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
But we don't even have a GUI for this (do we?) That would be a higher priority at this point. I think it was when using the character style GUI in mathed. This gives us an idea of what a GUI would do. I'm sure there is many things we could improve. Toggle-same-type would certainly be an idea. As would a dialogue for changing type (been thinking about that). But we should not try to shoehorn an inappropriate paradigm. I absolutely agree. But I do think we have a paradigm, only a data structure that shows. JMarc
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, Oct 02, 2007 at 05:35:33PM +0200, Andre Poenitz wrote: > On Tue, Oct 02, 2007 at 06:03:15PM +0300, Martin Vermeer wrote: > > On Tue, 02 Oct 2007 16:09:12 +0200 Jean-Marc Lasgouttes > > <[EMAIL PROTECTED]> wrote: > > > > > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > > > > > Yes, I understand that. Two different things. > > > > > > I know you do. > > > > > > > And I would maintain that this is a _perceived_ non-readiness > > > > mostly -- to people that are 'indoctrinated' by the font attribute > > > > way of doing things. > > > > > > The example of colors in mathed is a good one. One should not have > > > to dissolve the color inset and then insert a new one to change > > > color. > > > > But we don't even have a GUI for this (do we?) That would be a higher > > priority at this point. > > Yes. And I can tell you even why we don't have a Gui for antyhing in > math (except fot the panels/toolbar) ... > > Andre' Well, the attached patch enables inset dissolving in mathed. (I'm sure I overlooked all kinds of things.) It would be trivial to put the insertion of the most popular colour into mathed on the menu tree. - Martin Index: InsetMathNest.cpp === --- InsetMathNest.cpp (revision 20634) +++ InsetMathNest.cpp (working copy) @@ -1003,7 +1003,9 @@ cur.undispatched(); break; } - + case LFUN_INSET_DISSOLVE: + if (!cur[(cur.depth() - 2)].text()) + cur.pullArg(); default: InsetMath::doDispatch(cur, cmd); break; @@ -1112,6 +1114,10 @@ flag.enabled(false); break; + case LFUN_INSET_DISSOLVE: + flag.enabled(!cur[(cur.depth() - 2)].text()); + break; + default: ret = false; break;
Re: 1.5.X patch candidate list #5
Richard Heck wrote: > Right. But you don't have to do this now. Simply not having an > AlignPossible is equivalent to allowing only the one thing. I see. > > So if it's broken, we should rather fix it than remove it. Note that I'm > > talking out of the blue, however. > > > > There was a lot of discussion of this a while back when I was trying to > fix this, and the conclusion---as I remember it---was that how section > titles and the like are formatted is a document-class issue, not > something that should be tweaked within LyX. Fixing it is hard, or at > least causes problems. The issue is this: If you put the alignment > command inside \section, then it needs to be protected; but then it > causes chaos in the toc, page headers, etc. If, on the other hand, you > put it outside \section, then it works, but it leads to ugly and very > unnatural LaTeX---at least according to JMarc. I'm no LaTeXpert, so I'm > not competent to judge. Ah, you are talking about section titles only. Then I agree, they shouldn't be changed. (I thought you were about to remove AlignPossible anywhere -- sorry for not reading more closely). Thanks for the explanation; your change makes sense indeed. However, let's wait until 1.5.2 is out. Jürgen
Re: 1.5.X patch candidate list #5
Jürgen Spitzmüller wrote: Richard Heck wrote: Putting this: Align Left AlignPossible Left now has a different effect than it might once have had. Now, doing this allows left alignment to be set explicitly, over-riding whatever the LaTeX class would do. This is probably not the intention...and it doesn't actually work, anyway. I think the intention was to reduce the possibilities of alignment choices. So ... Right. But you don't have to do this now. Simply not having an AlignPossible is equivalent to allowing only the one thing. The more significant one is 20438, actually, which removes cases like this: Layout Section NeedsProtect 1 Align Left AlignPossible Left, Block the reason being that setting alignment to block here won't actually work: It throws a LaTeX error. It's also not the right way to proceed. this would limit the choices to Left and Block and disable Right and Centered. I cannot judge whether these tags make sense in the case where you removed them, but I think in principle this is very useful. So if it's broken, we should rather fix it than remove it. Note that I'm talking out of the blue, however. There was a lot of discussion of this a while back when I was trying to fix this, and the conclusion---as I remember it---was that how section titles and the like are formatted is a document-class issue, not something that should be tweaked within LyX. Fixing it is hard, or at least causes problems. The issue is this: If you put the alignment command inside \section, then it needs to be protected; but then it causes chaos in the toc, page headers, etc. If, on the other hand, you put it outside \section, then it works, but it leads to ugly and very unnatural LaTeX---at least according to JMarc. I'm no LaTeXpert, so I'm not competent to judge. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [Cvslog] r20664 - in /lyx-devel/trunk/src: Buffer.cpp Buffer.h fro...
On Tue, Oct 02, 2007 at 06:15:43PM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >On Tue, Oct 02, 2007 at 02:39:49PM -, [EMAIL PROTECTED] wrote: > >>Author: younes > >>Date: Tue Oct 2 16:39:48 2007 > >>New Revision: 20664 > >> > >>URL: http://www.lyx.org/trac/changeset/20664 > >>Log: > >>Fix some issues with buffer closing. > >>* Switch WorkAreaManager to std::list instead of vector. > > > >Urm, why? > > Just because of list::remove(). Does it need to be stable, or do you do that for performance reasons? Andre'
Re: signal/slot -> delegates
Andre Poenitz wrote: On Tue, Oct 02, 2007 at 09:51:12AM +0200, Abdelrazak Younes wrote: And here is the beginning of a patch. If you could take it and finish the remaining bits together with your patch, you'd make me very happy. Abdel. Index: Buffer.cpp === --- Buffer.cpp (revision 20651) +++ Buffer.cpp (working copy) @@ -68,6 +68,7 @@ #include "mathed/MathSupport.h" #include "frontends/alert.h" +#include "frontends/WorkAreaManager.h" With that done, does that mean you are now fine with the delegate patch? Just one question: what about Buffer::structureChanged() signal? How would you solve that bit in a multiview context? Maybe we also need a LyXViewManager? Abdel.
Re: [Cvslog] r20664 - in /lyx-devel/trunk/src: Buffer.cpp Buffer.h fro...
Andre Poenitz wrote: On Tue, Oct 02, 2007 at 02:39:49PM -, [EMAIL PROTECTED] wrote: Author: younes Date: Tue Oct 2 16:39:48 2007 New Revision: 20664 URL: http://www.lyx.org/trac/changeset/20664 Log: Fix some issues with buffer closing. * Switch WorkAreaManager to std::list instead of vector. Urm, why? Just because of list::remove(). Can't you just iterate backwards? We don't have a need for backward iteration I think. Abdel.
Re: signal/slot -> delegates
Andre Poenitz wrote: On Tue, Oct 02, 2007 at 09:51:12AM +0200, Abdelrazak Younes wrote: And here is the beginning of a patch. If you could take it and finish the remaining bits together with your patch, you'd make me very happy. Abdel. Index: Buffer.cpp === --- Buffer.cpp (revision 20651) +++ Buffer.cpp (working copy) @@ -68,6 +68,7 @@ #include "mathed/MathSupport.h" #include "frontends/alert.h" +#include "frontends/WorkAreaManager.h" With that done, does that mean you are now fine with the delegate patch? Yes, provided that we make its removal a goal :-) Abdel.
Re: 1.5.X patch candidate list #5
Richard Heck wrote: > Putting this: > Align Left > AlignPossible Left > now has a different effect than it might once have had. Now, doing this > allows left alignment to be set explicitly, over-riding whatever the > LaTeX class would do. This is probably not the intention...and it > doesn't actually work, anyway. I think the intention was to reduce the possibilities of alignment choices. So ... > The more significant one is 20438, actually, which removes cases like this: > Layout Section > NeedsProtect 1 > Align Left > AlignPossible Left, Block > the reason being that setting alignment to block here won't actually > work: It throws a LaTeX error. It's also not the right way to proceed. this would limit the choices to Left and Block and disable Right and Centered. I cannot judge whether these tags make sense in the case where you removed them, but I think in principle this is very useful. So if it's broken, we should rather fix it than remove it. Note that I'm talking out of the blue, however. > But none of this is essential. > > Richard Jürgen
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Bo Peng wrote:
> Why can not you think of bold as another emph style?? Italic and bold
> are methods to emphasize.
Agreed. Also small caps is a method to emphasize. Color as well, and text
size, and font family. And which method is chosen is actually defined in such
macros as \emph or \noun.
> Let us put it in this way: people wants different emph styles that are
> commonly provided as bold and italics (or emph, or additionally
> \underline) by other word processors . Lyx has emph but not bold, and
> that is confusing and inconvenient (I am talking about toolbar/menu,
> not shortcuts). To new users, lyx has ONLY one emph style.
Let's say two (noun and emph). But again, LyX has emph, not bold, not italics,
not underline in the toolbar. Depending on your document class, it might as
well output something completely different. What do you tell the users then:
that emph is broken with this specific class? It's not.
Nothing speaks against a document class that defines \emph to output bold
text. I would, for instance, chose this if I'd write a presentation class,
since italics is not very readable in presentations.
What now? Take out the bold button and add an italics one?
Again, if you come to the conclusion that the font attributes should be
accessible easier (which I'm still not convinced about), then the solution
would not be the bold button, but rather an additional "font styles" toolbar
that contained a bold, italics, smallcaps and an underline button.
> Lyx has some good ideas about charstyle but charstyle is not quite
> usable now. So, in 1.5.x, we provide \textbf, \emph, and \none etc. In
> 1.6.x, we will make charstyle easy to use so users can actually
> configure \textbf, \emph etc, using CharStyle Strong, Emph, Nonu.
> There is no reason to reject textbf if you agree with the usability of
> \strong. In the end, \strong is 99.9% times \textbf.
Actually, I don't really agree with the usability of "strong". This is not
really semantic markup, but some kind of "make it look like semantic".
Semantic is something like \emph ("emphasize this, be it italics, bold or
whatever"), \noun ("this is the way proper names should look like" -- I have
defined this to be not at all emphasized, i.e. roman upright, in many
documents btw) or \command or \keyword.
Anyway, if new users are really confused that there is emph and not bold, we
hae a documentation problem. However, I seem to remember that this specific
issue is/used to be documented rather well (which is why I remember that this
very much convinced me when I was a new user; I didn't know anything about
LaTeX or semantic markup back then, BTW).
Jürgen
Re: signal/slot -> delegates
On Tue, Oct 02, 2007 at 09:51:12AM +0200, Abdelrazak Younes wrote: > And here is the beginning of a patch. If you could take it and finish > the remaining bits together with your patch, you'd make me very happy. > > Abdel. > > Index: Buffer.cpp > === > --- Buffer.cpp(revision 20651) > +++ Buffer.cpp(working copy) > @@ -68,6 +68,7 @@ > #include "mathed/MathSupport.h" > > #include "frontends/alert.h" > +#include "frontends/WorkAreaManager.h" With that done, does that mean you are now fine with the delegate patch? Andre'
Re: 1.5.X patch candidate list #5
Jürgen Spitzmüller wrote: Richard Heck wrote: http://www.lyx.org/trac/changeset/20437 - Remove redundant AlignPossible? lines http://www.lyx.org/trac/changeset/20438 - Disallow setting of alignment in protected environments, where it is broken. Maybe. Jurgen should have a look. Could you explain again why these were redundant? Putting this: Align Left AlignPossible Left now has a different effect than it might once have had. Now, doing this allows left alignment to be set explicitly, over-riding whatever the LaTeX class would do. This is probably not the intention...and it doesn't actually work, anyway. The more significant one is 20438, actually, which removes cases like this: Layout Section NeedsProtect 1 Align Left AlignPossible Left, Block the reason being that setting alignment to block here won't actually work: It throws a LaTeX error. It's also not the right way to proceed. But none of this is essential. Richard Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
> I see your point. The problem is that noun and emph are not yet transformed to > the char styles ui. But they will (I think there's already a noun charstyle > in 1.5, but it's hidden somewhere). > Putting a bold button there would just raise the confusion. Why can not you think of bold as another emph style?? Italic and bold are methods to emphasize. Let us put it in this way: people wants different emph styles that are commonly provided as bold and italics (or emph, or additionally \underline) by other word processors . Lyx has emph but not bold, and that is confusing and inconvenient (I am talking about toolbar/menu, not shortcuts). To new users, lyx has ONLY one emph style. Lyx has some good ideas about charstyle but charstyle is not quite usable now. So, in 1.5.x, we provide \textbf, \emph, and \none etc. In 1.6.x, we will make charstyle easy to use so users can actually configure \textbf, \emph etc, using CharStyle Strong, Emph, Nonu. There is no reason to reject textbf if you agree with the usability of \strong. In the end, \strong is 99.9% times \textbf. Bo
Re: signal/slot -> delegates
On Tue, Oct 02, 2007 at 09:09:33AM +0200, Abdelrazak Younes wrote: > Andre Poenitz wrote: > >On Tue, Oct 02, 2007 at 08:11:47AM +0200, Abdelrazak Younes wrote: > >>Andre Poenitz wrote: > >>>The attached patch replaces the signal/slot connections between Buffer > >>>and BufferView to LyXView by ordinary delegates. > >>> > >>>There has always been only (at most) a single connection of each type > >>>with known endpoints, so full-blown signal/slot was overkill anyway - > >>I am sorry but that's not true for Buffer. With multi-workarea and > >>multi-view there can be more than one connection to the > >>Buffer::changed() signal. > > > >The signal was only attached to the LyXView, not to the workarea. > > Wrong, in WorkArea.h: > > /// buffer changed signal connection > boost::signals::connection bufferChangedConnection_; > /// buffer closing signal connection > boost::signals::connection bufferClosingConnection_; Urm ... right. That was not too conciously, though. I tought I had taken an approach of "'no compiler error' means 'works as before'". I missed that bit. > Wrong, see above. You can have two WorkAreas sharing the same Buffer in > the same LyXView. I'd really like this to stay. I'll come up with a solution for that. Andre'
Re: [Cvslog] r20664 - in /lyx-devel/trunk/src: Buffer.cpp Buffer.h fro...
On Tue, Oct 02, 2007 at 02:39:49PM -, [EMAIL PROTECTED] wrote: > Author: younes > Date: Tue Oct 2 16:39:48 2007 > New Revision: 20664 > > URL: http://www.lyx.org/trac/changeset/20664 > Log: > Fix some issues with buffer closing. > * Switch WorkAreaManager to std::list instead of vector. Urm, why? Can't you just iterate backwards? Andre'
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Jean-Marc Lasgouttes wrote: 2. it is easier to toggle boldface. A simple operation (usually C-B) can switch bold face on and off even for a sentense with mixed normal and bold text. It is much more difficult to work with inset charstyle. The 'backspace at the beginning of the inset' trick looks more like magic. This is a very good point, but unrelated to the bold issue. The people who push for font as an inset should put their code where their mouth is and make the interface usable (José?). Let me just say that, having entered this discussion late---I see it's been going on for rather a while---I was somewhat confused about what the debate was about. So, to clarify my own previous position, I rather agree with the point of view being pushed here, that semantic and physical markup should be clearly separated; that semantic markup should be done via charstyles; and that physical markup should be discouraged. And yes, we do need a solution to the problem to which Bo points. That said, I do still think that the mechanisms for physical markup are somewhat broken. The existing Text Styles dialog, in particular, does not work properly; the boundaries of the physical markup can be nearly impossible to discover; etc, etc. So I think the font-as-inset question is independent of the semantic--physical question, and it seems to me the two get mixed up. Richard -- == Richard G Heck, Jr Professor of Philosophy Brown University http://frege.brown.edu/heck/ == Get my public key from http://sks.keyserver.penguin.de Hash: 0x1DE91F1E66FFBDEC Learn how to sign your email using Thunderbird and GnuPG at: http://dudu.dyn.2-h.org/nist/gpg-enigmail-howto
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Bo Peng wrote: > Their usages, appearance, are vastly different. It would be weird to > put \strong next to \emph. If you ever plan to put a \stong to the > toolbar, you would better put real char styles there. I see your point. The problem is that noun and emph are not yet transformed to the char styles ui. But they will (I think there's already a noun charstyle in 1.5, but it's hidden somewhere). So let's say emph and noun have an confusing appearance that might be one cause for the whole irritation. However, the fact that they do not (yet) look like LyX char styles should not make us think that they are font attributes (like bold, italic etc.). Putting a bold button there would just raise the confusion. Jürgen
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
> If you ever plan to put a \stong to the > toolbar, you would better put real char styles there. I meant that you would better put charstyles for other stuff such as Emph there. Bo
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, Oct 02, 2007 at 06:03:15PM +0300, Martin Vermeer wrote: > On Tue, 02 Oct 2007 16:09:12 +0200 Jean-Marc Lasgouttes > <[EMAIL PROTECTED]> wrote: > > > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > > > Yes, I understand that. Two different things. > > > > I know you do. > > > > > And I would maintain that this is a _perceived_ non-readiness > > > mostly -- to people that are 'indoctrinated' by the font attribute > > > way of doing things. > > > > The example of colors in mathed is a good one. One should not have > > to dissolve the color inset and then insert a new one to change > > color. > > But we don't even have a GUI for this (do we?) That would be a higher > priority at this point. Yes. And I can tell you even why we don't have a Gui for antyhing in math (except fot the panels/toolbar) ... Andre'
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
> No. I have explained already that \emph (as well as \em) does _not_ simply
> make the text italic. I have showed you an easy example where this is not
> true, and I could show you many more.
I know that (I can read).
My point is that they are simple latex commands (macro or switch, I do
not care). The biggest difference between \emph and CharStyle Emph is
that
1. \emph is \emph in latex. It is a LATEX thing. A user can *not*
change \emph (at the lyx level).
2. CharStyle Emph is
CharStyle Emph
LatexTypeCommand
LatexNamemyemph
Font
Family italic
EndFont
Preamble
\newcommand{\myemph}[1]{{\blah{\blah #1}}}
EndPreamble
End
which is a LYX thing, it is an inset. It can be changed in .layout
(and should be configurable in document->settings).
Their usages, appearance, are vastly different. It would be weird to
put \strong next to \emph. If you ever plan to put a \stong to the
toolbar, you would better put real char styles there.
Bo
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Bo Peng wrote:
> > Because these are fundamentally different concepts (I keep repeating
> > myself).
>
> I do not think \textit and \em are 'fundamentally different'.
> \textit/\em and CharStyle Emph are. The former are all 'plain latex
> command', the latter can be any latex command.
Why do you think LaTeX macros cannot be character styles? \textit and \emph
are fundamentally different in the LaTeX scope, as any good introduction to
LaTeX will tell you. BTW, it's \emph (the macro), not \em (the switch) we are
talking about.
> This is obviously different from what JMarc thinks
> But there are two different things:
> * semantic vs explicit marking
> * font-like extent versus inset.
> The first one is the one that counts. The second one is an
> implementation issue.
>
>
> From a user's point of view, the former is mapped to some latex
> command that is NOT configurable. The later is some complicated inset
> that provides flexibility at a cost of usability. It would be more
> naturally to put \textbf along with \em, than to put \strong (leads to
> a scary inset) along with \em (which simply makes your text italic).
No. I have explained already that \emph (as well as \em) does _not_ simply
make the text italic. I have showed you an easy example where this is not
true, and I could show you many more.
This is the crucial point.
The LyX implemetation (inset vs. font) is a complete different topic. If the
inset implemetation has flaws, we should fix it. But being an inset does not
make anything a character style or not.
> > They have only
> > buttons for physical markup in the toolbars, namely bold, underline,
> > italics (and sometimes small caps). We have *none* of those buttons in
> > our toolbar, so if we are going to go that way, we have to go it to the
> > end.
>
> You tried really hard to differentiate \textit and \em and tried to
> convince me your toolbar buttons are *not* italics and underline in
> word's sense. My view is different. See above.
But it's simply not true. It's a fact that \emph is not \textit and \noun is
not \textsc. For the same reason that \section{foo} is not the same as
\Huge{\textbf{1.~foo}}. This is the very basic design philosophy of LaTeX,
and I always thought it was and should be the very basic design philosophy of
Lyx. This was actually the point where LyX caught me as a user some years
ago.
> Bo
Jürgen
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, 02 Oct 2007 16:09:12 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > > Yes, I understand that. Two different things. > > I know you do. > > > And I would maintain that this is a _perceived_ non-readiness mostly -- to > > people that are 'indoctrinated' by the font attribute way of doing things. > > The example of colors in mathed is a good one. One should not have to > dissolve the color inset and then insert a new one to change color. But we don't even have a GUI for this (do we?) That would be a higher priority at this point. > I'd be disappointed if this is all we can do with it. As it is the > font-as-inset is functional, logical, but not very exciting. Looks > like it has been designed by the french bureaucracy ;) > > What I write above is not about the charstyles (which are great), but > the look-and-feel of the underlying technology. Apple would not have > done it like that. I'm sure there is many things we could improve. Toggle-same-type would certainly be an idea. As would a dialogue for changing type (been thinking about that). But we should not try to shoehorn an inappropriate paradigm. > JMarc - Martin
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
> Because these are fundamentally different concepts (I keep repeating myself). I do not think \textit and \em are 'fundamentally different'. \textit/\em and CharStyle Emph are. The former are all 'plain latex command', the latter can be any latex command. This is obviously different from what JMarc thinks But there are two different things: * semantic vs explicit marking * font-like extent versus inset. The first one is the one that counts. The second one is an implementation issue. >From a user's point of view, the former is mapped to some latex command that is NOT configurable. The later is some complicated inset that provides flexibility at a cost of usability. It would be more naturally to put \textbf along with \em, than to put \strong (leads to a scary inset) along with \em (which simply makes your text italic). > They have only > buttons for physical markup in the toolbars, namely bold, underline, italics > (and sometimes small caps). We have *none* of those buttons in our toolbar, > so if we are going to go that way, we have to go it to the end. You tried really hard to differentiate \textit and \em and tried to convince me your toolbar buttons are *not* italics and underline in word's sense. My view is different. See above. Bo
Re: [Cvslog] r20660 - in /lyx-devel/branches/BRANCH_1_5_X/po: Makefile...
Jean-Marc Lasgouttes wrote: > With the fixes I just committed, the only problem is that one has to > invoke it like > LC_ALL=C make i18n.php > when the locale is not english. Jose promised to fix it. Note that > only a handful of persons (you, me, michael, uwe?) are impacted. OK, then let's keep it. > I just ran the thing and the result is here: > http://www.lyx.org/devel/i18n.php I saw it, thanks. I'm really impressed that we have three 100% translations now. Jürgen
Re: [Cvslog] r20660 - in /lyx-devel/branches/BRANCH_1_5_X/po: Makefile...
[EMAIL PROTECTED] (Jürgen Spitzmüller) writes: > Jean-Marc Lasgouttes wrote: >> Saw that in Juergen's last commit. > > Thanks. > >> The postat.py commit is a mistake, but the new python version is usable, >> and José promised to fix it (José?) >> >> Juergen, I can revert this part if you want (it is only a maintainer tool). > > What was the problem again with the python version? With the fixes I just committed, the only problem is that one has to invoke it like LC_ALL=C make i18n.php when the locale is not english. Jose promised to fix it. Note that only a handful of persons (you, me, michael, uwe?) are impacted. I just ran the thing and the result is here: http://www.lyx.org/devel/i18n.php JMarc
Re: [Cvslog] r20660 - in /lyx-devel/branches/BRANCH_1_5_X/po: Makefile...
Jean-Marc Lasgouttes wrote: > Saw that in Juergen's last commit. Thanks. > The postat.py commit is a mistake, but the new python version is usable, > and José promised to fix it (José?) > > Juergen, I can revert this part if you want (it is only a maintainer tool). What was the problem again with the python version? > JMarc Jürgen
Re: [Cvslog] r20660 - in /lyx-devel/branches/BRANCH_1_5_X/po: Makefile...
[EMAIL PROTECTED] writes: > Author: lasgouttes > Date: Tue Oct 2 16:19:31 2007 > New Revision: 20660 > > URL: http://www.lyx.org/trac/changeset/20660 > Log: > fix end of lines on the two chinese translations Saw that in Juergen's last commit. The postat.py commit is a mistake, but the new python version is usable, and José promised to fix it (José?) Juergen, I can revert this part if you want (it is only a maintainer tool). JMarc
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Martin Vermeer <[EMAIL PROTECTED]> writes: > Yes, I understand that. Two different things. I know you do. > And I would maintain that this is a _perceived_ non-readiness mostly -- to > people that are 'indoctrinated' by the font attribute way of doing things. The example of colors in mathed is a good one. One should not have to dissolve the color inset and then insert a new one to change color. I'd be disappointed if this is all we can do with it. As it is the font-as-inset is functional, logical, but not very exciting. Looks like it has been designed by the french bureaucracy ;) What I write above is not about the charstyles (which are great), but the look-and-feel of the underlying technology. Apple would not have done it like that. JMarc
Re: [Cvslog] r20595 - /lyx-devel/trunk/src/insets/InsetBox.cpp
On Tue, 02 Oct 2007 14:34:27 +0200 Georg Baum <[EMAIL PROTECTED]> wrote: > Martin Vermeer wrote: > > > On Mon, 01 Oct 2007 10:46:14 +0200 > > Uwe Stöhr <[EMAIL PROTECTED]> wrote: > > >> I understand that this behaviour might be confusing, but I'm innocent > >> here. This has been introduced when the box dialog was introduced with > >> LyX 1.4.0. I don't know who to blame. > > IMO you should not construct a new length for comparison, but test the > quantity that is really written: > > if (params_.height.value() != 1.0) > ... > > is more robust and does not use this "1in" implementation detail. For > example, I am not sure if tex2lyx always creates "1in", or if it can also > create "1cm". > > >> But anyway, it works > >> well and I can see no potential problems, so better blame nobody. You > >> have to use a dummy unit for the special values, so what's the problem in > >> using "in", using "cm" instead makes no difference, and the behaviour is > >> well already explained by comments in the source code? > > > > That was my reasoning IIRC. > > Exactly. But if you depend on the fact that the dummy unit is "in" you make > the code less robust, i.e. if somebody changes the default from "in" to > "cm" it would not work anymore. > > > Georg Yes, agreed. - Martin
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, 02 Oct 2007 14:27:05 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > > I agree with that. Just let people choose what they want. Font > > attribute should not become insets and people should not be forced to > > use charstyle if they really want to use Font attribute. > > But there are two different things: > * semantic vs explicit marking > * font-like extent versus inset. Yes, I understand that. Two different things. > The first one is the one that counts. The second one is an > implementation issue. Chartstyles could have been implemented as part > of font setting. It is a design choice. And I happen to think (not > that it matters much, so I ma going to shut up on this issue too) that > the inset implementation is not ready (but the solutions are not obvious). And I would maintain that this is a _perceived_ non-readiness mostly -- to people that are 'indoctrinated' by the font attribute way of doing things. Most of the things you want to do that you can do with fonts, you shouldn't even _want_ to do with charstyles. Like you shouldn't want to use ERT, or build a section header using large+bold and a number prefix. (1.5 is special though) > JMarc
Re: [Cvslog] r20653 - in /lyx-devel/trunk/src/frontends/qt4: GuiMenuba...
Jean-Marc Lasgouttes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: there are other cases like that non involving external issues: try the empth or noun toggle button to see what I mean. I am not sure what you mean, but the discussion is moot now anyway. Forget about it, I just realize the behavior was meant like this. Abdel.
Re: [Cvslog] r20653 - in /lyx-devel/trunk/src/frontends/qt4: GuiMenuba...
Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> And I am fed up that people think I do not try to understand what they >> mean just because I disagree with them. > > Problem is that when you take an ironical tone, one cannot guess what > you really mean. You should have come to Bromarv :) > That was at least 6 months before 1.5.0 I think... And by the way, > there are other cases like that non involving external issues: try the > empth or noun toggle button to see what I mean. I am not sure what you mean, but the discussion is moot now anyway. And I was mentionning the performance problems. Contrary to what some may think, I am not married to the existing system. We'll see what the new system looks like. > Well I could also enumerate a lot of things I've spent time on without > gaining any personal benefits. But thanks anyways for those. It is not the problem for me. The problem is when one only time has for those things. It is not very exciting. JMarc
Re: [Cvslog] r20653 - in /lyx-devel/trunk/src/frontends/qt4: GuiMenuba...
Jean-Marc Lasgouttes wrote: Abdelrazak Younes <[EMAIL PROTECTED]> writes: Do you really think this is playing? I am fad up that you never try to understand that what we are doing is *good* for LyX. Code is meant to change, cleanup is always good whatever you think. I play the best I can: I do not have enough time for LyX (especially until christmas), if I only spend it arguing we are not going to go very far. I personally always try to listen to constructive criticism. Therefore I let you do as you wish and we'll see afterwards what the situation is. You have carte blanche. Good. And I am fed up that people think I do not try to understand what they mean just because I disagree with them. Problem is that when you take an ironical tone, one cannot guess what you really mean. On the paragraph docking issue I did spend a lot of time trying to think about what could be done about the usability problem. The toolbar redraw problem (besides the stupid visibility bug) was mainly a problem with the new cut-and-paste stuff that was pushed in just before 1.5. That was at least 6 months before 1.5.0 I think... And by the way, there are other cases like that non involving external issues: try the empth or noun toggle button to see what I mean. I did spend a lot of time on that (and on listing too: the counters rewrite was a necessity to remove true horrors; and no, "but it was OK, I just wanted it to work" is not an excuse). Well I could also enumerate a lot of things I've spent time on without gaining any personal benefits. But thanks anyways for those. Spending time caring about other people's fun projects is not very interesting actually. So that you know I am not directed against you in particular, I think it is time for andre to actually make the build system work in a simple way... Libraries should not installed, the --enable-monolithic-foo switches are horrible, we have 4 build systems instead of 3. I am not going to work on the auto* build system at all if it means doing the cleanup. Clearer now? Yes, thanks. Abdel.
Re: [Cvslog] r20595 - /lyx-devel/trunk/src/insets/InsetBox.cpp
Martin Vermeer wrote: > On Mon, 01 Oct 2007 10:46:14 +0200 > Uwe Stöhr <[EMAIL PROTECTED]> wrote: >> I understand that this behaviour might be confusing, but I'm innocent >> here. This has been introduced when the box dialog was introduced with >> LyX 1.4.0. I don't know who to blame. IMO you should not construct a new length for comparison, but test the quantity that is really written: if (params_.height.value() != 1.0) ... is more robust and does not use this "1in" implementation detail. For example, I am not sure if tex2lyx always creates "1in", or if it can also create "1cm". >> But anyway, it works >> well and I can see no potential problems, so better blame nobody. You >> have to use a dummy unit for the special values, so what's the problem in >> using "in", using "cm" instead makes no difference, and the behaviour is >> well already explained by comments in the source code? > > That was my reasoning IIRC. Exactly. But if you depend on the fact that the dummy unit is "in" you make the code less robust, i.e. if somebody changes the default from "in" to "cm" it would not work anymore. Georg
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Abdelrazak Younes <[EMAIL PROTECTED]> writes: > I agree with that. Just let people choose what they want. Font > attribute should not become insets and people should not be forced to > use charstyle if they really want to use Font attribute. But there are two different things: * semantic vs explicit marking * font-like extent versus inset. The first one is the one that counts. The second one is an implementation issue. Chartstyles could have been implemented as part of font setting. It is a design choice. And I happen to think (not that it matters much, so I ma going to shut up on this issue too) that the inset implementation is not ready (but the solutions are not obvious). JMarc
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Martin Vermeer <[EMAIL PROTECTED]> writes: >> This is a very good point, but unrelated to the bold issue. The people >> who push for font as an inset should put their code where their mouth is >> and make the interface usable (José?). For example we could have a >> charstyle-toggle lfun that is like charstyle-insert except that, when >> one tries to insert a charstyle in itself, it dissolves instead. I am >> not sure it will be enough to make the thing work well, but it is a >> major problem with the font change as inset idea. > > Only, sometimes you wish to have a charstyle inset inside a charstyle > inset. So, should it test for being _the same_ charstyle type? This is what I had in mind indeed. The situation is the same in math where people complained that changing color from blue to red inserted a box inside the box and that removing the color was difficult. > We have already a 'dissolve inset' menu entry. Inset _is_ a different > paradigm from font attribute. What's wrong with just learning it, just > like people learn not to do line spacing with the enter key. I think the command flow, even when one is really used to it, is not as good as with the toggle-font idiom. I am not sure that what I proposed make sense, but I think we shall do something. JMarc
Re: [Cvslog] r20653 - in /lyx-devel/trunk/src/frontends/qt4: GuiMenuba...
Abdelrazak Younes <[EMAIL PROTECTED]> writes: >> Abdel, please make the effort of keeping things working when you do >> changes. grep would have told you what to do. > > In this case you should blame Andre I think. Sorry. > Do you really think this is playing? I am fad up that you never try to > understand that what we are doing is *good* for LyX. Code is meant to > change, cleanup is always good whatever you think. I play the best I can: I do not have enough time for LyX (especially until christmas), if I only spend it arguing we are not going to go very far. Therefore I let you do as you wish and we'll see afterwards what the situation is. You have carte blanche. And I am fed up that people think I do not try to understand what they mean just because I disagree with them. On the paragraph docking issue I did spend a lot of time trying to think about what could be done about the usability problem. The toolbar redraw problem (besides the stupid visibility bug) was mainly a problem with the new cut-and-paste stuff that was pushed in just before 1.5. I did spend a lot of time on that (and on listing too: the counters rewrite was a necessity to remove true horrors; and no, "but it was OK, I just wanted it to work" is not an excuse). Spending time caring about other people's fun projects is not very interesting actually. So that you know I am not directed against you in particular, I think it is time for andre to actually make the build system work in a simple way... Libraries should not installed, the --enable-monolithic-foo switches are horrible, we have 4 build systems instead of 3. I am not going to work on the auto* build system at all if it means doing the cleanup. Clearer now? JMarc
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, 2 Oct 2007, Jürgen Spitzmüller wrote: Bo Peng wrote: There is a way to introduce a bold button cleanly. But it includes removing emph and noun and replacing it with textit and textsc. I do not see why textit, em and charstyle Emph can not co-exist, and I have no objection to use em instead of textit after textbf. Because these are fundamentally different concepts (I keep repeating myself). You have referred to word processors such as msword or Ooo. Even those do separate the two concepts (here, I have to correct myself): They have only buttons for physical markup in the toolbars, namely bold, underline, italics (and sometimes small caps). We have *none* of those buttons in our toolbar, so if we are going to go that way, we have to go it to the end. My thoughts, solely as a user of LyX who really appreciated it while writing: I've read this thread, and I'm amazed about confusion that I consider part of the core values of LyX. LyX is not a word processor or a desktop publishing program. It's not WYSIWYG, but WYSIWYM. We encourage users to _not_ finger paint their document. We encourage users to _emphasize_ parts rather than manually making it italic or bold. The whole point is that the appearance of semantic markup is controlled separately. Given the above, buttons for 'emphasized', 'strong' and 'noun' are what we want. The button for 'bold' is an inconsistency, a hack, and I think it should go away. When I've demonstrated LyX for other users, expanding on the advantages of separating style from content, they often look at the bold button and are just confused. It should go. I'm not saying we should make it impossible for users to force certain parts of the text to be bold, or italic, or other kinds of font issues. However, we should not encourage them - physical markup should be kept away. If users complain about this, let's investigate what their need really is. What kind of _texts_ need part of it to be 'bold', instead of something with a meaning? Is the problem a missing LaTeX class/style? Is the problem that it's difficult to define your own semantic styles? (I never used bold with the exception of \mathbf etc, where I used it for vectors and dyads. However, if I'd been thrilled to able to mark them semantically!) If we gonna introduce the physical markup, then separate. Not under Edit->Text Style (because these are not character styles), but under a separate item (Edit->Font Shape, for instance). However, I think the character dialog is the right place. I agree. The same applies for the menus. We can introduce bold to the menus, but not together with noun and emph, but with textsc and textit. For toolbars, the boldface button can be \textbf for 1.5.x, and \strong for 1.6.x. I disagree (see above). I also do not think we should have menu items for bold etc. /Christian -- Christian Ridderström, +46-8-768 39 44 http://www.md.kth.se/~chr
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Martin Vermeer wrote: On Tue, 02 Oct 2007 09:43:09 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: "Bo Peng" <[EMAIL PROTECTED]> writes: \textbf is simpler than \strong because 1. it is simply \textbf, and \strong can be anything, and to understand what is \strong, someone needs to understand what is charstyle, and where to look for its definition, and figure out, in the end, that it is \textbf (in most cases). Yes, but learning is good. 2. it is easier to toggle boldface. A simple operation (usually C-B) can switch bold face on and off even for a sentense with mixed normal and bold text. It is much more difficult to work with inset charstyle. The 'backspace at the beginning of the inset' trick looks more like magic. This is a very good point, but unrelated to the bold issue. The people who push for font as an inset should put their code where their mouth is and make the interface usable (José?). For example we could have a charstyle-toggle lfun that is like charstyle-insert except that, when one tries to insert a charstyle in itself, it dissolves instead. I am not sure it will be enough to make the thing work well, but it is a major problem with the font change as inset idea. Only, sometimes you wish to have a charstyle inset inside a charstyle inset. So, should it test for being _the same_ charstyle type? We have already a 'dissolve inset' menu entry. Inset _is_ a different paradigm from font attribute. What's wrong with just learning it, just like people learn not to do line spacing with the enter key. I agree with that. Just let people choose what they want. Font attribute should not become insets and people should not be forced to use charstyle if they really want to use Font attribute. Abdel.
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
On Tue, 02 Oct 2007 09:43:09 +0200 Jean-Marc Lasgouttes <[EMAIL PROTECTED]> wrote: > "Bo Peng" <[EMAIL PROTECTED]> writes: > > > \textbf is simpler than \strong because > > > > 1. it is simply \textbf, and \strong can be anything, and to > > understand what is \strong, someone needs to understand what is > > charstyle, and where to look for its definition, and figure out, in > > the end, that it is \textbf (in most cases). > > Yes, but learning is good. > > > 2. it is easier to toggle boldface. A simple operation (usually C-B) > > can switch bold face on and off even for a sentense with mixed normal > > and bold text. It is much more difficult to work with inset charstyle. > > The 'backspace at the beginning of the inset' trick looks more like > > magic. > > This is a very good point, but unrelated to the bold issue. The people > who push for font as an inset should put their code where their mouth is > and make the interface usable (José?). For example we could have a > charstyle-toggle lfun that is like charstyle-insert except that, when > one tries to insert a charstyle in itself, it dissolves instead. I am > not sure it will be enough to make the thing work well, but it is a > major problem with the font change as inset idea. Only, sometimes you wish to have a charstyle inset inside a charstyle inset. So, should it test for being _the same_ charstyle type? We have already a 'dissolve inset' menu entry. Inset _is_ a different paradigm from font attribute. What's wrong with just learning it, just like people learn not to do line spacing with the enter key. - Martin
Re: signal/slot -> delegates
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Tue, Oct 02, 2007 at 08:11:47AM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
The attached patch replaces the signal/slot connections between Buffer
and BufferView to LyXView by ordinary delegates.
There has always been only (at most) a single connection of each type
with known endpoints, so full-blown signal/slot was overkill anyway -
I am sorry but that's not true for Buffer. With multi-workarea and
multi-view there can be more than one connection to the
Buffer::changed() signal.
The signal was only attached to the LyXView, not to the workarea.
Wrong, in WorkArea.h:
/// buffer changed signal connection
boost::signals::connection bufferChangedConnection_;
/// buffer closing signal connection
boost::signals::connection bufferClosingConnection_;
I did not change the structure of the code.
You did a bit I'm afraid.
OK, if we continue with your patch except for those two signals, one
solution would be to have a WorkareaManager:
OK, I've committed this solution. We can think of a more general
BufferManager solution in the future but I didn't want multiview to be
broken after you commit your patch.
Abdel.
Author: younes
Date: Tue Oct 2 11:00:08 2007
New Revision: 20654
URL: http://www.lyx.org/trac/changeset/20654
Log:
Replace Buffer' changed() and closing() signals with a WorkAreaManager
before Andre erase everything :-)
The resulting source code is not much bigger actually.
Added:
lyx-devel/trunk/src/frontends/WorkAreaManager.cpp (with props)
lyx-devel/trunk/src/frontends/WorkAreaManager.h (with props)
Modified:
lyx-devel/trunk/src/Buffer.cpp
lyx-devel/trunk/src/Buffer.h
lyx-devel/trunk/src/buffer_funcs.cpp
lyx-devel/trunk/src/frontends/Makefile.am
lyx-devel/trunk/src/frontends/WorkArea.cpp
lyx-devel/trunk/src/frontends/WorkArea.h
lyx-devel/trunk/src/frontends/qt4/GuiView.cpp
Modified: lyx-devel/trunk/src/Buffer.cpp
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Buffer.cpp?rev=20654
==
--- lyx-devel/trunk/src/Buffer.cpp (original)
+++ lyx-devel/trunk/src/Buffer.cpp Tue Oct 2 11:00:08 2007
@@ -68,6 +68,7 @@
#include "mathed/MathSupport.h"
#include "frontends/alert.h"
+#include "frontends/WorkAreaManager.h"
#include "graphics/Previews.h"
@@ -206,13 +207,17 @@
/// modified. (Used to properly enable 'File->Revert to saved', bug
4114).
time_t timestamp_;
unsigned long checksum_;
+
+ ///
+ frontend::WorkAreaManager * wa_;
};
Buffer::Impl::Impl(Buffer & parent, FileName const & file, bool readonly_)
: lyx_clean(true), bak_clean(true), unnamed(false),
read_only(readonly_),
filename(file), file_fully_loaded(false), inset(params),
- toc_backend(&parent), embedded_files(&parent), timestamp_(0),
checksum_(0)
+ toc_backend(&parent), embedded_files(&parent), timestamp_(0),
+ checksum_(0), wa_(0)
{
inset.setAutoBreakRows(true);
lyxvc.buffer(&parent);
@@ -221,6 +226,9 @@
// FIXME: And now do something if temppath == string(), because we
// assume from now on that temppath points to a valid temp dir.
// See http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg67406.html
+
+ if (use_gui)
+ wa_ = new frontend::WorkAreaManager;
}
@@ -253,9 +261,24 @@
// Remove any previewed LaTeX snippets associated with this buffer.
graphics::Previews::get().removeLoader(*this);
- closing(this);
-}
-
+ if (pimpl_->wa_) {
+ pimpl_->wa_->closing();
+ delete pimpl_->wa_;
+ }
+}
+
+
+void Buffer::changed()
+{
+ if (pimpl_->wa_)
+ pimpl_->wa_->changed();
+}
+
+
+frontend::WorkAreaManager * Buffer::workAreaManager() const
+{
+ return pimpl_->wa_;
+}
Text & Buffer::text() const
{
Modified: lyx-devel/trunk/src/Buffer.h
URL: http://www.lyx.org/trac/file/lyx-devel/trunk/src/Buffer.h?rev=20654
==
--- lyx-devel/trunk/src/Buffer.h (original)
+++ lyx-devel/trunk/src/Buffer.h Tue Oct 2 11:00:08 2007
@@ -54,6 +54,9 @@
class TocBackend;
class Undo;
+namespace frontend {
+class WorkAreaManager;
+}
/** The buffer object.
* This is the buffer object. It contains all the informations about
@@ -141,7 +144,11 @@
bool hasParWithID(int id) const;
/// This signal is emitted when the buffer is changed.
- boost::signal changed;
+ void changed();
+
+ ///
+ frontend::WorkAreaManager * workAreaManager() const;
+
/// This signal is emitted when the buffer structure is changed.
boost::signal structureChanged;
/// This signal is emitted when an embedded file is changed
@@ -158,8 +165,6 @@
boost::signal updateTitles;
/// Reset au
Re: signal/slot -> delegates
Abdelrazak Younes wrote: Abdelrazak Younes wrote: Abdelrazak Younes wrote: Andre Poenitz wrote: On Tue, Oct 02, 2007 at 08:11:47AM +0200, Abdelrazak Younes wrote: Andre Poenitz wrote: The attached patch replaces the signal/slot connections between Buffer and BufferView to LyXView by ordinary delegates. There has always been only (at most) a single connection of each type with known endpoints, so full-blown signal/slot was overkill anyway - I am sorry but that's not true for Buffer. With multi-workarea and multi-view there can be more than one connection to the Buffer::changed() signal. The signal was only attached to the LyXView, not to the workarea. Wrong, in WorkArea.h: /// buffer changed signal connection boost::signals::connection bufferChangedConnection_; /// buffer closing signal connection boost::signals::connection bufferClosingConnection_; I did not change the structure of the code. You did a bit I'm afraid. OK, if we continue with your patch except for those two signals, one solution would be to have a WorkareaManager: And here is the beginning of a patch. If you could take it and finish the remaining bits together with your patch, you'd make me very happy. I'll do it. Abdel.
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
Jean-Marc Lasgouttes wrote: > For example we could have a > charstyle-toggle lfun that is like charstyle-insert except that, when > one tries to insert a charstyle in itself, it dissolves instead. I am > not sure it will be enough to make the thing work well, but it is a > major problem with the font change as inset idea. This is very tricky indeed. What should be possible eventually as well is resetting to "none". For instance, if I have "a longer phrase" attributed to charstyle foo, I should be able to select "longer" and attribute charstyle "none", which would result in "a longer phrase", i.e., split the charstyle inset. It is all but simple to get this right. Jürgen
Re: [Cvslog] r20653 - in /lyx-devel/trunk/src/frontends/qt4: GuiMenuba...
Jean-Marc Lasgouttes wrote: [EMAIL PROTECTED] writes: Author: lasgouttes Date: Tue Oct 2 09:51:25 2007 New Revision: 20653 URL: http://www.lyx.org/trac/changeset/20653 Log: fix compilation on mac Abdel, please make the effort of keeping things working when you do changes. grep would have told you what to do. In this case you should blame Andre I think. Note that if you do big things to the menu stuff, I won't make mac menus work for the third time (not counting this one of course). If not for my cleanup in this area the mac specific code for menu won't be that simple. Personally, I'll let you both play with that as much as you like. I do not have enough time on LyX to spend it arguing. Do you really think this is playing? I am fad up that you never try to understand that what we are doing is *good* for LyX. Code is meant to change, cleanup is always good whatever you think. Abdel.
Re: [Cvslog] r20653 - in /lyx-devel/trunk/src/frontends/qt4: GuiMenuba...
[EMAIL PROTECTED] writes: > Author: lasgouttes > Date: Tue Oct 2 09:51:25 2007 > New Revision: 20653 > > URL: http://www.lyx.org/trac/changeset/20653 > Log: > fix compilation on mac Abdel, please make the effort of keeping things working when you do changes. grep would have told you what to do. Note that if you do big things to the menu stuff, I won't make mac menus work for the third time (not counting this one of course). Personally, I'll let you both play with that as much as you like. I do not have enough time on LyX to spend it arguing. JMarc
Re: signal/slot -> delegates
Abdelrazak Younes wrote:
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Tue, Oct 02, 2007 at 08:11:47AM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
The attached patch replaces the signal/slot connections between Buffer
and BufferView to LyXView by ordinary delegates.
There has always been only (at most) a single connection of each type
with known endpoints, so full-blown signal/slot was overkill anyway -
I am sorry but that's not true for Buffer. With multi-workarea and
multi-view there can be more than one connection to the
Buffer::changed() signal.
The signal was only attached to the LyXView, not to the workarea.
Wrong, in WorkArea.h:
/// buffer changed signal connection
boost::signals::connection bufferChangedConnection_;
/// buffer closing signal connection
boost::signals::connection bufferClosingConnection_;
I did not change the structure of the code.
You did a bit I'm afraid.
OK, if we continue with your patch except for those two signals, one
solution would be to have a WorkareaManager:
And here is the beginning of a patch. If you could take it and finish
the remaining bits together with your patch, you'd make me very happy.
Abdel.
Index: Buffer.cpp
===
--- Buffer.cpp (revision 20651)
+++ Buffer.cpp (working copy)
@@ -68,6 +68,7 @@
#include "mathed/MathSupport.h"
#include "frontends/alert.h"
+#include "frontends/WorkAreaManager.h"
#include "graphics/Previews.h"
@@ -206,13 +207,17 @@
/// modified. (Used to properly enable 'File->Revert to saved', bug
4114).
time_t timestamp_;
unsigned long checksum_;
+
+ ///
+ frontend::WorkAreaManager * wa_;
};
Buffer::Impl::Impl(Buffer & parent, FileName const & file, bool readonly_)
: lyx_clean(true), bak_clean(true), unnamed(false),
read_only(readonly_),
filename(file), file_fully_loaded(false), inset(params),
- toc_backend(&parent), embedded_files(&parent), timestamp_(0),
checksum_(0)
+ toc_backend(&parent), embedded_files(&parent), timestamp_(0),
+ checksum_(0), wa_(0)
{
inset.setAutoBreakRows(true);
lyxvc.buffer(&parent);
@@ -221,6 +226,9 @@
// FIXME: And now do something if temppath == string(), because we
// assume from now on that temppath points to a valid temp dir.
// See http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg67406.html
+
+ if (use_gui)
+ wa_ = new frontend::WorkAreaManager;
}
@@ -253,10 +261,18 @@
// Remove any previewed LaTeX snippets associated with this buffer.
graphics::Previews::get().removeLoader(*this);
- closing(this);
+ if (pimpl_->wa_)
+ pimpl_->wa_->closing();
}
+void Buffer::changed()
+{
+ if (pimpl_->wa_)
+ pimpl_->wa_->changed();
+}
+
+
Text & Buffer::text() const
{
return const_cast(pimpl_->inset.text_);
Index: frontends/WorkAreaManager.h
===
--- frontends/WorkAreaManager.h (revision 0)
+++ frontends/WorkAreaManager.h (revision 0)
@@ -0,0 +1,49 @@
+// -*- C++ -*-
+/**
+ * \file WorkAreaManager.h
+ * This file is part of LyX, the document processor.
+ * Licence details can be found in the file COPYING.
+ *
+ * \author Abdelrazak Younes
+ *
+ * Full author contact details are available in file CREDITS.
+ */
+
+#ifndef WORKAREA_MANAGER_H
+#define WORKAREA_MANAGER_H
+
+#include "WorkArea.h"
+
+namespace lyx {
+namespace frontend {
+
+class WorkAreaManager
+{
+public:
+ WorkAreaManager() {}
+
+ register(WorkArea * wa)
+ {
+ work_areas_.push_back(wa);
+ }
+
+ changed()
+ {
+ for (size_t i = 0; i != work_areas_.size(); ++i)
+ work_areas_[i]->redraw();
+ }
+
+ closing()
+ {
+ for (size_t i = 0; i != work_areas_.size(); ++i)
+ work_areas_[i]->close();
+ }
+
+private:
+ std::vector work_areas_;
+}
+
+} // namespace frontend
+} // namespace lyx
+
+#endif // BASE_WORKAREA_H
Property changes on: frontends\WorkAreaManager.h
___
Name: svn:eol-style
+ native
Re: [PATCH] Return of the 'basic style' menu item and bold toolbar icon.
"Bo Peng" <[EMAIL PROTECTED]> writes: > \textbf is simpler than \strong because > > 1. it is simply \textbf, and \strong can be anything, and to > understand what is \strong, someone needs to understand what is > charstyle, and where to look for its definition, and figure out, in > the end, that it is \textbf (in most cases). Yes, but learning is good. > 2. it is easier to toggle boldface. A simple operation (usually C-B) > can switch bold face on and off even for a sentense with mixed normal > and bold text. It is much more difficult to work with inset charstyle. > The 'backspace at the beginning of the inset' trick looks more like > magic. This is a very good point, but unrelated to the bold issue. The people who push for font as an inset should put their code where their mouth is and make the interface usable (José?). For example we could have a charstyle-toggle lfun that is like charstyle-insert except that, when one tries to insert a charstyle in itself, it dissolves instead. I am not sure it will be enough to make the thing work well, but it is a major problem with the font change as inset idea. And before you ask Bo, I still think we do not need a bold icon/menu :) JMarc
Re: Slowness Progress
Dov Feldstern <[EMAIL PROTECTED]> writes: > I strongly recommend > http://www.catb.org/~esr/writings/taoup/html/ch05s02.html (the book in > general, this chapter specifically is relevant to this discussion) Very interesting indeed. JMarc
Re: signal/slot -> delegates
Abdelrazak Younes wrote:
Andre Poenitz wrote:
On Tue, Oct 02, 2007 at 08:11:47AM +0200, Abdelrazak Younes wrote:
Andre Poenitz wrote:
The attached patch replaces the signal/slot connections between Buffer
and BufferView to LyXView by ordinary delegates.
There has always been only (at most) a single connection of each type
with known endpoints, so full-blown signal/slot was overkill anyway -
I am sorry but that's not true for Buffer. With multi-workarea and
multi-view there can be more than one connection to the
Buffer::changed() signal.
The signal was only attached to the LyXView, not to the workarea.
Wrong, in WorkArea.h:
/// buffer changed signal connection
boost::signals::connection bufferChangedConnection_;
/// buffer closing signal connection
boost::signals::connection bufferClosingConnection_;
I did not change the structure of the code.
You did a bit I'm afraid.
OK, if we continue with your patch except for those two signals, one
solution would be to have a WorkareaManager:
class WorkareaManager
{
WorkareaManager() {}
register(WorkArea *);
changed()
{
for (size_t i = 0; i != work_areas_.size(); ++i)
work_areas_[i]->redraw();
}
closing()
{
for (size_t i = 0; i != work_areas_.size(); ++i)
work_areas_[i]->close();
}
private:
vector work_areas_;
}
Then in Buffer:
class Buffer {
...
private:
// Instanciated only in Gui mode.
WorkareaManager* manager_;
}
The LyXView will take care of registering the WorkAreas.
Abdel.
Re: signal/slot -> delegates
Andre Poenitz wrote: On Tue, Oct 02, 2007 at 08:11:47AM +0200, Abdelrazak Younes wrote: Andre Poenitz wrote: The attached patch replaces the signal/slot connections between Buffer and BufferView to LyXView by ordinary delegates. There has always been only (at most) a single connection of each type with known endpoints, so full-blown signal/slot was overkill anyway - I am sorry but that's not true for Buffer. With multi-workarea and multi-view there can be more than one connection to the Buffer::changed() signal. The signal was only attached to the LyXView, not to the workarea. Wrong, in WorkArea.h: /// buffer changed signal connection boost::signals::connection bufferChangedConnection_; /// buffer closing signal connection boost::signals::connection bufferClosingConnection_; I did not change the structure of the code. You did a bit I'm afraid. at least given the price of boost's signal/slot: As boost/signal pulls in roughly 50 kLOC into both Buffer.h and BufferView.h which in turn heavily used throughout the code. So the change reduces "TLOCC" from 24.6M to 22.5M, i.e. by more than 9%! There might be a few simplifications possible after that, but I wanted to keep the patch small. Please wait with that until we understand the full repercussion of that change. I really sympathize with your compil time reduction goal but I don't think this is the right solution: * For one, you are working around a compiler that do not implement pch efficiently. I am pretty sure MSVC will not be affected much by your patch. But I am not compiling with MSVC, and if MSVC is "not (adversely) affected" that's completely sufficient. [Apart from that: also MSVC will benefit a bit by not having certain stuff to compile into pch, and finally by not having to compile boost/signal at all] As I said, I agree with that goal but your solution is rather radical. * Second, did you tried a more recent version of gcc? Gcc 4.2 seems good on the paper. No, I haven't. But I don't think I will. We have been promised "good gcc" for 15 years or so. I don't believe that anymore. I can't help you here :-) * Third, I don't know if you remember but I worked an awful lot to get rid of the WorkArea and LyXView dependency in the core. You are basically putting them back :-( Heck, no. As I said: I did not change the structure of the code. All dependencies that are in the code now have been there before. And also note that I did use separate interfaces for the delegates (_even_ if only LyXView implements them) exactly for that reason. I understand that (except for Buffer::changed() and closing()) and that's actually what I said just here: On the third point, I understand this is not exactly the same thing. The problem with boost signals is that they need full visibility of the objects so we cannot put them in a private implementation. OK, so let's focus on the signal solution itself: - BufferView: I think that most if not all the signal could go with some more cleanup. This is the right way forward IMO. - Buffer: only the changed() signal is important. One solution would be to have a centralized Buffer manager that will track the WorkAreas connected to it and update them if need be. This will avoid the need for this signal in particular. All other signals could and should be removed. I hope you are not too upset with my reaction. I am not. I read that that I am 80% going in the right direction, and the remaining bit (multiple buffers) would need a new implementation anyway as we are currently connecting via (a single!) LyXView to the current WorkArea only. Wrong, see above. You can have two WorkAreas sharing the same Buffer in the same LyXView. I'd really like this to stay. The idea of having a BufferManager (which I agree with) is not affected with that patch. OK. Abdel.
