Re: [Devel] [patch] small cleanup
On Friday 28 November 2003 21:31, Alfredo Braunstein wrote:
> do not use cursors when not needed, rewrite loops in a more standard
> way, and do not abuse parOffset calculations (inside loops).
> All semi-automatic (it can containg bugs as always, though)
> I'm leaving in a few hours, so I will not apply this by myself. (I'll
> look again at it on monday or so)
Some more
Alfredo
? PosIterator.C-save
? PosIterator.h-save
? bfri.C
? textcursor.C-save
? textcursor.h-save
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.264
diff -u -p -u -r1.264 lyxtext.h
--- lyxtext.h 28 Nov 2003 15:53:23 - 1.264
+++ lyxtext.h 28 Nov 2003 21:01:18 -
@@ -80,9 +80,8 @@ public:
those paragraphs
*/
ParagraphList::iterator
- setLayout(LyXCursor & actual_cursor,
- LyXCursor & selection_start,
- LyXCursor & selection_end,
+ setLayout(ParagraphList::iterator start,
+ ParagraphList::iterator end,
std::string const & layout);
///
void setLayout(std::string const & layout);
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.516
diff -u -p -u -r1.516 text2.C
--- text2.C 28 Nov 2003 15:53:27 - 1.516
+++ text2.C 28 Nov 2003 21:01:20 -
@@ -277,46 +277,33 @@ void LyXText::makeFontEntriesLayoutSpeci
ParagraphList::iterator
-LyXText::setLayout(LyXCursor & cur, LyXCursor & sstart_cur,
- LyXCursor & send_cur,
+LyXText::setLayout(ParagraphList::iterator start,
+ ParagraphList::iterator end,
string const & layout)
{
- ParagraphList::iterator endpit = boost::next(getPar(send_cur));
- ParagraphList::iterator undoendpit = endpit;
+ ParagraphList::iterator undopit = end;
ParagraphList::iterator pars_end = ownerParagraphs().end();
- if (endpit != pars_end && endpit->getDepth()) {
- while (endpit != pars_end && endpit->getDepth()) {
- ++endpit;
- undoendpit = endpit;
- }
- } else if (endpit != pars_end) {
- // because of parindents etc.
- ++endpit;
- }
+ while (undopit != pars_end && undopit->getDepth())
+ ++undopit;
+ // because of parindents etc.
+ if (undopit != pars_end)
+ ++undopit;
- recUndo(sstart_cur.par(), parOffset(undoendpit) - 1);
-
- // ok we have a selection. This is always between sstart_cur
- // and sel_end cursor
- cur = sstart_cur;
- ParagraphList::iterator pit = getPar(sstart_cur);
- ParagraphList::iterator epit = boost::next(getPar(send_cur));
+ recUndo(parOffset(start), parOffset(undopit) - 1);
BufferParams const & bufparams = bv()->buffer()->params();
LyXLayout_ptr const & lyxlayout =
bufparams.getLyXTextClass()[layout];
- do {
+ for (ParagraphList::iterator pit = start; pit != end; ++pit) {
pit->applyLayout(lyxlayout);
makeFontEntriesLayoutSpecific(bufparams, *pit);
if (lyxlayout->margintype == MARGIN_MANUAL)
pit->setLabelWidthString(lyxlayout->labelstring());
- cur.par(std::distance(ownerParagraphs().begin(), pit));
- ++pit;
- } while (pit != epit);
+ }
- return endpit;
+ return undopit;
}
@@ -343,9 +330,11 @@ void LyXText::setLayout(string const & l
return;
}
- ParagraphList::iterator endpit = setLayout(cursor, selection.start,
- selection.end, layout);
- redoParagraphs(getPar(selection.start), endpit);
+ ParagraphList::iterator start = getPar(selection.start.par());
+ ParagraphList::iterator end = boost::next(getPar(selection.end.par()));
+ ParagraphList::iterator endpit = setLayout(start, end, layout);
+
+ redoParagraphs(start, endpit);
updateCounters();
redoCursor();
}
@@ -438,11 +427,11 @@ void LyXText::setFont(LyXFont const & fo
if (!selection.set()) {
// Determine basis font
LyXFont layoutfont;
- if (cursor.pos() < cursorPar()->beginOfBody()) {
+ if (cursor.pos() < cursorPar()->beginOfBody())
layoutfont = getLabelFont(cursorPar());
- } else {
+ else
layoutfont = getLayoutFont(cursorPar());
- }
+
// Update current font
real_current_font.update(font,
bv()->buffer()->params().language,
@@ -605,36 +594,26 @@ string LyXText::getStringToIndex()
// they do not duplicate themself and you cannot play dirty tricks with
// them!
-void LyXText::setParagraph(
- Spacing const & spacing,
- LyXAlignment align,
- string const & labelwidthstring,
- bool noindent)
+void LyXText::setParagraph(Spacing const & spacing, LyXAlignment align,
+ string const & labelwidthstring, bool noindent)
{
setSelection();
// make sure that the depth behind the selection are restored, too
ParagraphList::iterator endpit = boost::next(getPar(selection.end));
- ParagraphList::iterator undoendpit = endpit;
ParagraphList::iterator pars_end = ownerParagraphs().end();
- if (endpit != pars_end && endpit->getDepth()) {
- while (endpit != pars_end && endpit->getDepth()) {
- ++endpit;
- undoendpit = endpit;
- }
- } else if (endpit != pars_
Re: [patch] move text from BufferView to Buffer
Andre Poenitz wrote: > There are, indeed, still row cache related parts 'in' the LyXText, so > LyXText is not (yet) the 'ParagraphList data & method' kind of class I'd > like to have in the end. > > [The 'elements' are, of course, Paragraphs::rows itself, and a few > bits and pieces all over the place. textwidth_ belongs in this > category.] > > [I still think we can get away with 'draw on demand' in the end so the > row cache could completely die...] In the meantime (and in this perspective), the LyXText could set it's textwidth in init, by taking the width from the bv passed as argument. At least this seems reasonable to me... Alfredo
[patch] small cleanup
do not use cursors when not needed, rewrite loops in a more standard way,
and do not abuse parOffset calculations (inside loops).
All semi-automatic (it can containg bugs as always, though)
I'm leaving in a few hours, so I will not apply this by myself. (I'll look again at it
on
monday or so)
Regards, Alfredo
? PosIterator.C-save
? PosIterator.h-save
? bfri.C
? textcursor.C-save
? textcursor.h-save
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.264
diff -u -p -u -r1.264 lyxtext.h
--- lyxtext.h 28 Nov 2003 15:53:23 - 1.264
+++ lyxtext.h 28 Nov 2003 20:18:32 -
@@ -80,9 +80,8 @@ public:
those paragraphs
*/
ParagraphList::iterator
- setLayout(LyXCursor & actual_cursor,
- LyXCursor & selection_start,
- LyXCursor & selection_end,
+ setLayout(ParagraphList::iterator start,
+ ParagraphList::iterator end,
std::string const & layout);
///
void setLayout(std::string const & layout);
Index: text2.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text2.C,v
retrieving revision 1.516
diff -u -p -u -r1.516 text2.C
--- text2.C 28 Nov 2003 15:53:27 - 1.516
+++ text2.C 28 Nov 2003 20:18:35 -
@@ -277,44 +277,36 @@ void LyXText::makeFontEntriesLayoutSpeci
ParagraphList::iterator
-LyXText::setLayout(LyXCursor & cur, LyXCursor & sstart_cur,
- LyXCursor & send_cur,
+LyXText::setLayout(ParagraphList::iterator start,
+ ParagraphList::iterator end,
string const & layout)
{
- ParagraphList::iterator endpit = boost::next(getPar(send_cur));
- ParagraphList::iterator undoendpit = endpit;
+ ParagraphList::iterator endpit = end;
ParagraphList::iterator pars_end = ownerParagraphs().end();
- if (endpit != pars_end && endpit->getDepth()) {
- while (endpit != pars_end && endpit->getDepth()) {
- ++endpit;
- undoendpit = endpit;
- }
- } else if (endpit != pars_end) {
- // because of parindents etc.
+ while (endpit != pars_end && endpit->getDepth())
+ ++endpit;
+
+ // because of parindents etc.
+ if (endpit != pars_end)
++endpit;
- }
- recUndo(sstart_cur.par(), parOffset(undoendpit) - 1);
+ recUndo(parOffset(start), parOffset(endpit) - 1);
// ok we have a selection. This is always between sstart_cur
// and sel_end cursor
- cur = sstart_cur;
- ParagraphList::iterator pit = getPar(sstart_cur);
- ParagraphList::iterator epit = boost::next(getPar(send_cur));
+ ParagraphList::iterator pit = start;
BufferParams const & bufparams = bv()->buffer()->params();
LyXLayout_ptr const & lyxlayout =
bufparams.getLyXTextClass()[layout];
- do {
+ for (; pit != end; ++pit) {
pit->applyLayout(lyxlayout);
makeFontEntriesLayoutSpecific(bufparams, *pit);
if (lyxlayout->margintype == MARGIN_MANUAL)
pit->setLabelWidthString(lyxlayout->labelstring());
- cur.par(std::distance(ownerParagraphs().begin(), pit));
- ++pit;
- } while (pit != epit);
+ }
return endpit;
}
@@ -343,9 +335,11 @@ void LyXText::setLayout(string const & l
return;
}
- ParagraphList::iterator endpit = setLayout(cursor, selection.start,
- selection.end, layout);
- redoParagraphs(getPar(selection.start), endpit);
+ ParagraphList::iterator start = getPar(selection.start.par());
+ ParagraphList::iterator end = boost::next(getPar(selection.end.par()));
+ ParagraphList::iterator endpit = setLayout(start, end, layout);
+
+ redoParagraphs(start, endpit);
updateCounters();
redoCursor();
}
@@ -438,11 +432,11 @@ void LyXText::setFont(LyXFont const & fo
if (!selection.set()) {
// Determine basis font
LyXFont layoutfont;
- if (cursor.pos() < cursorPar()->beginOfBody()) {
+ if (cursor.pos() < cursorPar()->beginOfBody())
layoutfont = getLabelFont(cursorPar());
- } else {
+ else
layoutfont = getLayoutFont(cursorPar());
- }
+
// Update current font
real_current_font.update(font,
bv()->buffer()->params().language,
@@ -605,36 +599,27 @@ string LyXText::getStringToIndex()
// they do not duplicate themself and you cannot play dirty tricks with
// them!
-void LyXText::setParagraph(
- Spacing const & spacing,
- LyXAlignment align,
- string const & labelwidthstring,
- bool noindent)
+void LyXText::setParagraph(Spacing const & spacing, LyXAlignment align,
+ string const & labelwidthstring, bool noindent)
{
setSelection();
// make sure that the depth behind the selection are restored, too
ParagraphList::iterator endpit = boost::next(getPar(selection.end));
- ParagraphList::iterator undoendpit = endpit;
ParagraphList::iterator pars_end = ownerParagraphs().end();
- if (endpit != pars_end && endpit->getDepth()) {
- while (endpit != pars_end && endpit->getDepth()) {
- ++endpit;
- undoendpit = endpit;
- }
- } else if (endpit != pars_end) {
- // because of parindents etc.
+ while (endpit != pars_end && endpit->getDepth())
++endpit;
-
Re: A working InsetVSpace
Angus Leeming wrote: > 5. Qt: I got rid of the VSpace stuff from the Paragraph dialog but have not > written QVSpace. Done (patch attached). If noone objects, I'll commit this tomorrow. BTW: - is there any special reason why you have removed "keep" (i.e. \vspace*) in the xforms dialog? I have reintroduced it (as "protect") in qt. - is the "Vertical Space ()" intended when setting "none" in the dialog? Jürgen. qvspace.diff.gz Description: GNU Zip compressed data
Re: [Patch] Class Header
On Friday 28 November 2003 19:44, Martin Vermeer wrote: > > > > Until this moment you added: > > > > * emphasis > > * noun > > * ... > > Emph and Noun are only for LaTeX. For linuxdoc you just have to look > up the syntax from the DTD, and implement what can be readily > implemented and will work right. (And yes, it would be nice if some > of these were common to all backends.) Actually it should not matter. But definitively Emph belongs to all of them, both linuxdoc, docbook and I suspect AGU have emphasis style. Noun can be translated to docbook as ..., and something related to linuxdoc. This interchangeability is fundamental in my point of view. > The name convention for a charstyle is now the same as for a paragraph > style: first letter cap, rest small. Ok, that is fair. > > In this case dummy is "!-- --" that will give _ an empty > > comment. > > Ah, I see. Perhaps it would be better to completely suppress it. And we do, but sometimes they are very good to see what is happening during debug. I think that we ignore every empty parameter, or if is a comment. > > Do you intend to add a new class of insets agu? > > No, that must be avoided. I *hope* to manage by clever > parametrization, but... let's make that up as we go... Ok, let us see. I am a little skeptic about that, but you have proved me wrong before so... ;-) > - Martin -- José Abílio
Re: Harmonization of UI messages
Martin Vermeer wrote: The changes look pretty harmless, don't they? (In particular in comparison with Andre's patches :-)) Please apply. Could you also have a look at my second email? Michael It's in. (And yes, everything that worked before still appears to work.) Could you please also check the coherent use of ":" in the dialog? Thanks, Michael
Re: [Patch] Class Header
On Fri, Nov 28, 2003 at 04:04:15PM +, Jose' Matos spake thusly: > On Friday 28 November 2003 10:51, Martin Vermeer wrote: > > > > I will adapt the linuxdoc code to the new scheme. > > > > Great! Make sure the output does't change. > > As long as it is whitespace that has no meaning. :-) > I intend to add also Character Styles to linuxdoc. > > If we could agree on some kind of naming for them we could have a general > list that would apply to all backends. > > Until this moment you added: > > * emphasis > * noun > * ... Emph and Noun are only for LaTeX. For linuxdoc you just have to look up the syntax from the DTD, and implement what can be readily implemented and will work right. (And yes, it would be nice if some of these were common to all backends.) The name convention for a charstyle is now the same as for a paragraph style: first letter cap, rest small. > What do you think? > > > > With the exception of insets, as you noted, all the other parts are > > > equal. > > > > Actually that's not quite true. In docbook spans > > header *plus text*. I understand that linuxdoc is more LaTeX-like in > > this respect. (Shouldn't be a problem though. Use InnerTag as the > > header name, and leave the header name itself empty (dummy?)). > > I was not clear, what I meant is that this behaviour can be configured in > the layout files. Yes... precisely. > In this case dummy is "!-- --" that will give _ an empty comment. Ah, I see. Perhaps it would be better to completely suppress it. > > > What about AGU? Do the inset always throw the correct output? > > > > No, I would say 'almost never'. Cross-reference e.g. > > > > docbookor ... > > linuxdoc > > AGU ... > > > > ...with the complication that the reference has to know the *type* of > > the label (figure, table, section header...). Some programming > > required... > > Do you intend to add a new class of insets agu? No, that must be avoided. I *hope* to manage by clever parametrization, but... let's make that up as we go... > > Currently AGU outputs docbook inset code throughout. Still I expect > > this will already be a major saving in manual mark-up work. > > This would give even better results. :-) > > > - Martin > > -- > José Abílio - Martin pgp0.pgp Description: PGP signature
Re: feature request
Dear John, dear Andre, I'm writing my PhD Thesis using Lyx. Sometimes I would like to read quickly throung the last paragraphs. On the other hand I have to fill in footnotes all the time. So closing all the footnotes manually just to get a better view of the text is a bit complicated. I believe that the result of your discussion - a view of all the footnotes open - would be an ideal solution for my problem. Thanks, Markus Am Freitag, 28. November 2003 17:47 schrieben Sie: > On Fri, Nov 28, 2003 at 04:39:20PM +, John Levon wrote: > > On Fri, Nov 28, 2003 at 05:38:41PM +0100, Andre Poenitz wrote: > > > I, for my part, prefer the 'closed' situation for working as this > > > lets me jump around in the document quickly. > > > > Sorry can you explain further ? Is this because footnotes appear inline > > and make the text formatting weird (huge line heights, etc.) > > Yes, for instance. And it's a way to filter away part of the document to > make it optically smaller. I find things better if the search space is > small. > > It could well be that the somewhat clumsy long-range navigation in LyX > comes into play here.. > > > > For 'reading', the 'open' situation is much better, though. > > > > > > Soetimes I work, sometimes I read... > > > > I would strongly prefer to have a View->All Insets Open (with a better > > name though). This would NOT affect the permanent state of the insets, > > it is a view only. In particular when you go back to View->Normal, then > > each inset is exactly as closed or as open as you chose it to be > > previously. > > Ah yes. > > > I believe this caters well for your use case. > > Indeed. This solution would be fine. > > Andre'
Re: Harmonization of UI messages
On Fri, Nov 28, 2003 at 06:32:32PM +0100, Michael Schmitt spake thusly: > > Martin Vermeer wrote: > > > If everything still works after this, I am happy with it... > > The changes look pretty harmless, don't they? (In particular in > comparison with Andre's patches :-)) > > Please apply. Could you also have a look at my second email? > > Michael It's in. (And yes, everything that worked before still appears to work.) - Martin pgp0.pgp Description: PGP signature
Re: POT file generation - Part II
Finally!
I fixed it. Of course, the value of LC_XXX must be exported... Silly me.
Please check and apply the patch (for HEAD and 1.3.X branch)
Michael
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/po/ChangeLog,v
retrieving revision 1.156.2.45
diff -u -r1.156.2.45 ChangeLog
--- ChangeLog 2003/11/24 17:00:38 1.156.2.45
+++ ChangeLog 2003/11/28 18:04:07
@@ -1,3 +1,7 @@
+2003-11-28 Michael Schmitt <[EMAIL PROTECTED]>
+
+ * Makefile.in.in: always create pot files with LC_ALL="C"
+
2003-11-24 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* Makefile.in.in (*l10n.pot): fix the file names when building
Index: Makefile.in.in
===
RCS file: /cvs/lyx/lyx-devel/po/Makefile.in.in,v
retrieving revision 1.28.2.4
diff -u -r1.28.2.4 Makefile.in.in
--- Makefile.in.in 2003/11/24 17:00:39 1.28.2.4
+++ Makefile.in.in 2003/11/28 18:04:08
@@ -197,11 +197,12 @@
$(SHELL) ./config.status
${srcdir}/POTFILES.in: $(POTFILE_IN_DEPS)
+ export LC_ALL=C ; \
rm -f [EMAIL PROTECTED] \
&& ( cd $(top_srcdir); \
grep -l "_(\".*\")" `find src -name \*.[hHC] -print` |\
sed -e '/xforms.forms/d' | \
-LC_COLLATE=C sort | uniq ) > [EMAIL PROTECTED] \
+sort | uniq ) > [EMAIL PROTECTED] \
&& mv [EMAIL PROTECTED] $@
@@ -211,6 +212,7 @@
$(srcdir)/xforms_l10n.pot: $(top_srcdir)/src/frontends/xforms/forms/*.fd
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
BEGIN { \
print "#, fuzzy"; \
@@ -236,6 +238,7 @@
$(srcdir)/qt_l10n.pot: $(top_srcdir)/src/frontends/qt2/ui/*.ui
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
// { \
line=$$0; \
@@ -252,6 +255,7 @@
$(srcdir)/layouts_l10n.pot: $(top_srcdir)/lib/layouts/*.layout
$(top_srcdir)/lib/layouts/*.inc
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
/^Style / { \
line=$$0; \
Index: ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/po/ChangeLog,v
retrieving revision 1.171
diff -u -r1.171 ChangeLog
--- ChangeLog 2003/11/21 11:35:56 1.171
+++ ChangeLog 2003/11/28 18:15:54
@@ -1,3 +1,7 @@
+2003-11-28 Michael Schmitt <[EMAIL PROTECTED]>
+
+ * Makefile.in.in: always create pot files with LC_ALL="C"
+
2003-11-14 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* Makefile.in.in (xforms_l10n.pot): skip entries in symbol font
Index: Makefile.in.in
===
RCS file: /cvs/lyx/lyx-devel/po/Makefile.in.in,v
retrieving revision 1.36
diff -u -r1.36 Makefile.in.in
--- Makefile.in.in 2003/11/24 17:59:27 1.36
+++ Makefile.in.in 2003/11/28 18:15:55
@@ -197,11 +197,12 @@
$(SHELL) ./config.status
${srcdir}/POTFILES.in: $(POTFILE_IN_DEPS)
+ export LC_ALL=C ; \
rm -f [EMAIL PROTECTED] \
&& ( cd $(top_srcdir); \
grep -l "_(\".*\")" `find src -name \*.[hHC] -print` |\
sed -e '/xforms.forms/d' | \
-LC_COLLATE=C sort | uniq ) > [EMAIL PROTECTED] \
+sort | uniq ) > [EMAIL PROTECTED] \
&& mv [EMAIL PROTECTED] $@
@@ -211,6 +212,7 @@
$(srcdir)/xforms_l10n.pot: $(top_srcdir)/src/frontends/xforms/forms/*.fd
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
BEGIN { \
print "#, fuzzy"; \
@@ -236,6 +238,7 @@
$(srcdir)/qt_l10n.pot: $(top_srcdir)/src/frontends/qt2/ui/*.ui
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
// { \
line=$$0; \
@@ -253,6 +256,7 @@
$(srcdir)/layouts_l10n.pot: $(top_srcdir)/lib/layouts/*.layout
$(top_srcdir)/lib/layouts/*.inc
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
/^Style / { \
line=$$0; \
@@ -285,6 +289,7 @@
$(srcdir)/ui_l10n.pot: $(top_srcdir)/lib/ui/*.ui
cd ${srcdir} ; \
+ export LC_ALL=C ; \
awk ' \
/^[^#]*Submenu/ { \
line=$$0; \
Re: [Devel] Re: lyx-devel lib/: ChangeLog lib/ui/: stdmenus.ui po/: POTFIL ...
On Fri, Nov 28, 2003 at 05:44:00PM +, Jose' Matos wrote: > On Friday 28 November 2003 18:38, [EMAIL PROTECTED] wrote: > > > > Modified files: > > lyx-devel/lib/: ChangeLog > > lyx-devel/lib/ui/: stdmenus.ui > > lyx-devel/po/: POTFILES.in > > lyx-devel/src/frontends/xforms/: ChangeLog FormVSpace.C > > lyx-devel/src/insets/: ChangeLog insetvspace.C insetvspace.h > > > > Log message: > > The VSpace inset is now fully functional AFAICT. > > Does this deserves an entry in development/FORMAT? Aehm Yes. Andre'
Crash when closing buffer
Start LyX
New Doc
type some crap
File->Close
'Discard'
...
crash
Program received signal SIGSEGV, Segmentation fault.
Buffer::text() const (this=0x0) at ../../boost/boost/scoped_ptr.hpp:95
95 BOOST_ASSERT(ptr != 0);
(gdb) where
#0 Buffer::text() const (this=0x0) at
../../boost/boost/scoped_ptr.hpp:95
#1 0x0805aff0 in BufferView::Pimpl::buffer(Buffer*) (this=0x842b950,
b=0x0)
at ../../src/BufferView_pimpl.C:296
#2 0x08060e48 in
boost::detail::function::void_function_obj_invoker0,
boost::_bi::list2,
boost::_bi::value > >,
void>::invoke(boost::detail::function::any_pointer)
(function_obj_ptr=
{obj_ptr = 0x0, const_obj_ptr = 0x0, func_ptr = 0, data = ""})
at ../../boost/boost/bind/mem_fn_template.hpp:130
#3 0x08094c20 in boost::signal0, int,
std::less, boost::function0 > >::operator()()
(this=0x852dea0) at
../../boost/boost/function/function_template.hpp:321
#4 0x0808d936 in ~Buffer (this=0x852de40) at ../../src/buffer.C:214
#5 0x080996c5 in BufferList::release(Buffer*) (this=0x838cb34,
buf=0x852de40)
at ../../src/bufferlist.C:125
#6 0x08099ccc in BufferList::close(Buffer*, bool) (this=0x838cb34,
buf=0x852de40, ask=64) at ../../src/bufferlist.C:187
#7 0x080e358f in LyXFunc::closeBuffer() (this=0x840b978)
at ../../src/lyxfunc.C:1694
#8 0x080dde1c in LyXFunc::dispatch(FuncRequest const&, bool)
(this=0x840b978,
[EMAIL PROTECTED], verbose=true) at ../../src/lyxfunc.C:938
#9 0x0829e58b in XFormsMenubar::MenuCallback(flobjs_*, long)
(ob=0x840aaf0,
button=1) at ../../../../src/frontends/LyXView.h:78
#10 0x0829ce91 in C_XFormsMenubar_MenuCallback (ob=0x840aaf0,
button=1)
at ../../../../src/frontends/xforms/XFormsMenubar.C:77
#11 0x400aac75 in fl_object_qread () at ../../lib/events.c:206
#12 0x400bfe74 in fl_check_forms () at ../../lib/forms.c:2128
#13 0x081dcde1 in lyx_gui::start(std::string const&,
std::vector > const&)
([EMAIL PROTECTED], [EMAIL PROTECTED])
at ../../../../src/frontends/xforms/lyx_gui.C:311
#14 0x080cf688 in LyX::priv_exec(int&, char**) (this=0x839cca0,
[EMAIL PROTECTED], argv=0xbfffe054) at ../../src/lyx_main.C:253
#15 0x080ceb69 in LyX::exec(int&, char**) ([EMAIL PROTECTED],
argv=0xbfffe054)
at ../../boost/boost/scoped_ptr.hpp:94
#16 0x080544b2 in main (argc=1, argv=0xbfffe054) at
../../src/main.C:41
#17 0x42015967 in __libc_start_main () from /lib/i686/libc.so.6
(gdb)
--
Angus
Re: [Devel] Re: lyx-devel lib/: ChangeLog lib/ui/: stdmenus.ui po/: POTFIL ...
On Friday 28 November 2003 5:44 pm, Jose' Matos wrote: > On Friday 28 November 2003 18:38, [EMAIL PROTECTED] wrote: > > Modified files: > > lyx-devel/lib/: ChangeLog > > lyx-devel/lib/ui/: stdmenus.ui > > lyx-devel/po/: POTFILES.in > > lyx-devel/src/frontends/xforms/: ChangeLog FormVSpace.C > > lyx-devel/src/insets/: ChangeLog insetvspace.C insetvspace.h > > > > Log message: > > The VSpace inset is now fully functional AFAICT. > > Does this deserves an entry in development/FORMAT? I believe so yes. See Andrés original mail: PPS: José, it would be nice if you could incorporate that change into lyx2lyx. It's basically '\added_space_top 5ex' -> '\begin_inset VSpace 5ex\n\end_inset' before the paragraph and '\added_space_bottom 5ex' -> '\begin_inset VSpace 5ex\n\end_inset' after the paragraph.
Re: lyx-devel lib/: ChangeLog lib/ui/: stdmenus.ui po/: POTFIL ...
On Friday 28 November 2003 18:38, [EMAIL PROTECTED] wrote: > > Modified files: > lyx-devel/lib/: ChangeLog > lyx-devel/lib/ui/: stdmenus.ui > lyx-devel/po/: POTFILES.in > lyx-devel/src/frontends/xforms/: ChangeLog FormVSpace.C > lyx-devel/src/insets/: ChangeLog insetvspace.C insetvspace.h > > Log message: > The VSpace inset is now fully functional AFAICT. Does this deserves an entry in development/FORMAT? -- José Abílio
Re: Harmonization of UI messages
Martin Vermeer wrote: If everything still works after this, I am happy with it... The changes look pretty harmless, don't they? (In particular in comparison with Andre's patches :-)) Please apply. Could you also have a look at my second email? Michael
[patch] move ParagraphList of InsetText and Buffer to LyXText
Step 2. Almost mechanical.
Andre'
--
Those who desire to give up Freedom in order to gain Security, will not have,
nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.212
diff -u -p -r1.212 BufferView.C
--- BufferView.C28 Nov 2003 15:08:35 - 1.212
+++ BufferView.C28 Nov 2003 17:14:27 -
@@ -308,7 +308,7 @@ void BufferView::gotoLabel(string const
if (find(labels.begin(),labels.end(),label) != labels.end()) {
text()->clearSelection();
text()->setCursor(
- std::distance(text()->ownerParagraphs().begin(),
it.getPar()),
+ std::distance(text()->paragraphs().begin(),
it.getPar()),
it.getPos());
text()->selection.cursor = text()->cursor;
update();
@@ -413,7 +413,7 @@ Encoding const * BufferView::getEncoding
return t->cursorPar()->getFont(
buffer()->params(),
t->cursor.pos(),
- outerFont(t->cursorPar(), t->ownerParagraphs())
+ outerFont(t->cursorPar(), t->paragraphs())
).language()->encoding();
}
Index: buffer.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/buffer.C,v
retrieving revision 1.545
diff -u -p -r1.545 buffer.C
--- buffer.C28 Nov 2003 15:08:38 - 1.545
+++ buffer.C28 Nov 2003 17:14:27 -
@@ -146,7 +146,6 @@ struct Buffer::Impl
limited_stack undostack;
limited_stack redostack;
BufferParams params;
- ParagraphList paragraphs;
LyXVC lyxvc;
string temppath;
bool nicefile;
@@ -190,7 +189,7 @@ Buffer::Impl::Impl(Buffer & parent, stri
: nicefile(true),
lyx_clean(true), bak_clean(true), unnamed(false), read_only(readonly_),
filename(file), filepath(OnlyPath(file)), file_fully_loaded(false),
- text(0, 0, 0, paragraphs)
+ text(0, 0, 0)
{
lyxvc.buffer(&parent);
if (readonly_ || lyxrc.use_tempdir)
@@ -218,8 +217,6 @@ Buffer::~Buffer()
bformat(_("Could not remove the temporary directory %1$s"),
temppath()));
}
- paragraphs().clear();
-
// Remove any previewed LaTeX snippets associated with this buffer.
lyx::graphics::Previews::get().removeLoader(*this);
}
@@ -269,13 +266,13 @@ BufferParams const & Buffer::params() co
ParagraphList & Buffer::paragraphs()
{
- return pimpl_->paragraphs;
+ return pimpl_->text.paragraphs();
}
ParagraphList const & Buffer::paragraphs() const
{
- return pimpl_->paragraphs;
+ return pimpl_->text.paragraphs();
}
Index: lyx_cb.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyx_cb.C,v
retrieving revision 1.232
diff -u -p -r1.232 lyx_cb.C
--- lyx_cb.C28 Nov 2003 08:55:06 - 1.232
+++ lyx_cb.C28 Nov 2003 17:14:28 -
@@ -428,7 +428,7 @@ string getContentsOfAsciiFile(BufferView
string const getPossibleLabel(BufferView const & bv)
{
ParagraphList::iterator pit = bv.getLyXText()->cursorPar();
- ParagraphList & plist = bv.getLyXText()->ownerParagraphs();
+ ParagraphList & plist = bv.getLyXText()->paragraphs();
LyXLayout_ptr layout = pit->layout();
Index: lyxtext.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtext.h,v
retrieving revision 1.264
diff -u -p -r1.264 lyxtext.h
--- lyxtext.h 28 Nov 2003 15:53:23 - 1.264
+++ lyxtext.h 28 Nov 2003 17:14:28 -
@@ -53,7 +53,7 @@ class LyXText : public TextCursor {
// Public Functions
public:
/// Constructor
- LyXText(BufferView *, InsetText *, bool ininset, ParagraphList & plist);
+ LyXText(BufferView *, InsetText *, bool ininset);
///
void init(BufferView *);
@@ -334,7 +334,7 @@ public:
//
// special owner functions
///
- ParagraphList & ownerParagraphs() const;
+ ParagraphList & paragraphs() const;
/// return true if this is owned by an inset.
bool isInInset() const;
@@ -414,8 +414,6 @@ public:
mutable Bidi bidi;
///
bool in_inset_;
- ///
- ParagraphList * paragraphs_;
/// absolute document pixel coordinates of this LyXText
mutable int xo_;
@@ -473,6 +471,10 @@ private:
void number();
/// is the cursor paragraph right-to-left?
bool rtl() const;
+
+
+ ///
+ ParagraphList paragraphs_;
};
/// return the default height of a row in pixels, considering fo
Re: Harmonization of UI messages
On Fri, Nov 28, 2003 at 05:48:26PM +0100, Michael Schmitt spake thusly: > >>I changed a couple of messages (mainly concerning the Box dialog) to > >>"harmonize" the dialogs. Could you please check and apply the patch? > >>Thanks in advance. > > > > I like these short patches... don't consume unnecessary bandwidth. > > Oh, I forgot the attachment! Here it comes... > > Michael If everything still works after this, I am happy with it... > -label: Vertical Position > +label: Vertical Alignment > -label: Inner Position (Vert.) > +label: Inner Alignment (Vert.) > -label: Horizontal Position > +label: Horizontal Alignment Yes, better english. "Position" is a latexicism. - Martin pgp0.pgp Description: PGP signature
Re: Harmonization of UI messages
Martin Vermeer wrote:
I changed a couple of messages (mainly concerning the Box dialog) to
"harmonize" the dialogs. Could you please check and apply the patch?
Thanks in advance.
I like these short patches... don't consume unnecessary bandwidth.
Oh, I forgot the attachment! Here it comes...
Michael
Index: lib/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v
retrieving revision 1.543
diff -u -r1.543 ChangeLog
--- lib/ChangeLog 2003/11/27 16:52:07 1.543
+++ lib/ChangeLog 2003/11/28 11:00:27
@@ -1,3 +1,7 @@
+2003-11-28 Michael Schmitt <[EMAIL PROTECTED]>
+
+ * layouts/chess.layout: Remove blanks in style name
+
2003-11-27 Martin Vermeer <[EMAIL PROTECTED]>
* layouts/db_stdclass.inc:
Index: lib/layouts/chess.layout
===
RCS file: /cvs/lyx/lyx-devel/lib/layouts/chess.layout,v
retrieving revision 1.6
diff -u -r1.6 chess.layout
--- lib/layouts/chess.layout2003/10/13 09:50:09 1.6
+++ lib/layouts/chess.layout2003/11/28 11:00:29
@@ -81,7 +81,7 @@
# This is a subsubsubvariation.
-Style SubVariation3
+Style SubVariation3
CopyStyle Variation
LatexName lyxvariation[4]
LabelString "Subvariation(3): "
Index: src/frontends/xforms/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/ChangeLog,v
retrieving revision 1.846
diff -u -r1.846 ChangeLog
--- src/frontends/xforms/ChangeLog 2003/11/21 11:38:17 1.846
+++ src/frontends/xforms/ChangeLog 2003/11/28 11:01:10
@@ -1,3 +1,11 @@
+2003-11-28 Michael Schmitt <[EMAIL PROTECTED]>
+
+ * src/frontends/xforms/forms/form_box.fd:
+ * src/frontends/xforms/FormMinipage.C:
+ * src/frontends/xforms/FormDocument.C:
+ * src/frontends/xforms/FormBox.C: fix capitalization in
+ messages; harmonize messages of different dialogs
+
2003-11-14 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* forms/form_maths_panel.fd (label): replace label "Greek" by
Index: src/frontends/xforms/FormBox.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/FormBox.C,v
retrieving revision 1.2
diff -u -r1.2 FormBox.C
--- src/frontends/xforms/FormBox.C 2003/10/13 09:43:14 1.2
+++ src/frontends/xforms/FormBox.C 2003/11/28 11:01:11
@@ -71,21 +71,21 @@
bcview().addReadOnly(dialog_->radio_minipage);
bcview().addReadOnly(dialog_->choice_pos);
- fl_addto_choice(dialog_->choice_pos, _("top").c_str());
- fl_addto_choice(dialog_->choice_pos, _("middle").c_str());
- fl_addto_choice(dialog_->choice_pos, _("bottom").c_str());
+ fl_addto_choice(dialog_->choice_pos, _("Top").c_str());
+ fl_addto_choice(dialog_->choice_pos, _("Middle").c_str());
+ fl_addto_choice(dialog_->choice_pos, _("Bottom").c_str());
bcview().addReadOnly(dialog_->choice_inner_pos);
- fl_addto_choice(dialog_->choice_inner_pos, _("top").c_str());
- fl_addto_choice(dialog_->choice_inner_pos, _("middle").c_str());
- fl_addto_choice(dialog_->choice_inner_pos, _("bottom").c_str());
- fl_addto_choice(dialog_->choice_inner_pos, _("stretch").c_str());
+ fl_addto_choice(dialog_->choice_inner_pos, _("Top").c_str());
+ fl_addto_choice(dialog_->choice_inner_pos, _("Middle").c_str());
+ fl_addto_choice(dialog_->choice_inner_pos, _("Bottom").c_str());
+ fl_addto_choice(dialog_->choice_inner_pos, _("Stretch").c_str());
bcview().addReadOnly(dialog_->choice_hor_pos);
- fl_addto_choice(dialog_->choice_hor_pos, _("left").c_str());
- fl_addto_choice(dialog_->choice_hor_pos, _("center").c_str());
- fl_addto_choice(dialog_->choice_hor_pos, _("right").c_str());
- fl_addto_choice(dialog_->choice_hor_pos, _("stretch").c_str());
+ fl_addto_choice(dialog_->choice_hor_pos, _("Left").c_str());
+ fl_addto_choice(dialog_->choice_hor_pos, _("Center").c_str());
+ fl_addto_choice(dialog_->choice_hor_pos, _("Right").c_str());
+ fl_addto_choice(dialog_->choice_hor_pos, _("Stretch").c_str());
bcview().addReadOnly(dialog_->input_width);
bcview().addReadOnly(dialog_->choice_width_unit);
@@ -261,7 +261,7 @@
string const input = getString(dialog_->input_width);
bool const invalid = !isValidLength(input) && !isStrDbl(input);
if (invalid) {
- postWarning(_("Invalid Length!"));
+ postWarning(_("Invalid length!"));
return ButtonPolicy::SMI_INVALID;
}
}
@@ -269,7 +269,7 @@
string const input = getString(dialog_->input_height);
bool const invalid = !isValidLength(input) && !isStrDbl(inp
Re: feature request
On Fri, Nov 28, 2003 at 04:39:20PM +, John Levon wrote: > On Fri, Nov 28, 2003 at 05:38:41PM +0100, Andre Poenitz wrote: > > > I, for my part, prefer the 'closed' situation for working as this > > lets me jump around in the document quickly. > > Sorry can you explain further ? Is this because footnotes appear inline > and make the text formatting weird (huge line heights, etc.) Yes, for instance. And it's a way to filter away part of the document to make it optically smaller. I find things better if the search space is small. It could well be that the somewhat clumsy long-range navigation in LyX comes into play here.. > > For 'reading', the 'open' situation is much better, though. > > > > Soetimes I work, sometimes I read... > > I would strongly prefer to have a View->All Insets Open (with a better > name though). This would NOT affect the permanent state of the insets, > it is a view only. In particular when you go back to View->Normal, then > each inset is exactly as closed or as open as you chose it to be > previously. Ah yes. > I believe this caters well for your use case. Indeed. This solution would be fine. Andre'
Re: feature request
On Fri, Nov 28, 2003 at 05:38:41PM +0100, Andre Poenitz wrote: > I, for my part, prefer the 'closed' situation for working as this > lets me jump around in the document quickly. Sorry can you explain further ? Is this because footnotes appear inline and make the text formatting weird (huge line heights, etc.) > For 'reading', the 'open' situation is much better, though. > > Soetimes I work, sometimes I read... I would strongly prefer to have a View->All Insets Open (with a better name though). This would NOT affect the permanent state of the insets, it is a view only. In particular when you go back to View->Normal, then each inset is exactly as closed or as open as you chose it to be previously. I believe this caters well for your use case. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: feature request
On Fri, Nov 28, 2003 at 04:30:59PM +, John Levon wrote: > > Because other people have other preferences and want to see them all? > > This is what I want to find out: why people have these preferences. I see. I, for my part, prefer the 'closed' situation for working as this lets me jump around in the document quickly. For 'reading', the 'open' situation is much better, though. Soetimes I work, sometimes I read... Andre'
Re: feature request
On Fri, Nov 28, 2003 at 05:24:37PM +0100, Andre Poenitz wrote: > > > Yet, the feature that I am missing in Lyx is a switch, either a menu entry or > > > a button to open/close all footnotes at once. This feature was available in > > > > Why do you want to be able to open or close all the footnotes at once ? > > Because spellchecking opens them? That's a separate bug to fix separately. Fix underlying bugs instead of complicating UI. > Because I want to go them out of sight? That's a mere rephrasing of the request. > Because other people have other preferences and want to see them all? This is what I want to find out: why people have these preferences. You just do not accept feature requests as is: they go through the design process. regards, john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: feature request
On Fri, Nov 28, 2003 at 01:07:08AM +, John Levon wrote: > On Tue, Nov 25, 2003 at 05:12:40PM +0100, Markus B. wrote: > > > Yet, the feature that I am missing in Lyx is a switch, either a menu entry or > > a button to open/close all footnotes at once. This feature was available in > > Why do you want to be able to open or close all the footnotes at once ? Because spellchecking opens them? Because I want to go them out of sight? Because other people have other preferences and want to see them all? Andre'
Re: [patch] move text from BufferView to Buffer
On Fri, Nov 28, 2003 at 01:33:53PM +, Angus Leeming wrote: > Andre Poenitz wrote: > > > > > [We had discussed this already once, but as this is 'fundamental' I > > thought we'd better agree explicitly on it ;-)] > > > > This replaces the LyXText 'semi member' of BufferView by a real > > LyXText member of Buffer. > > [snip...] > > > Comments? > > This (below) seems fundamentally wrong. If the LyXText needs to know > the width of the WorkArea, then it isn't a Buffer property at all. > Of course, this maybe the 'prepares for' bit ;-) There are, indeed, still row cache related parts 'in' the LyXText, so LyXText is not (yet) the 'ParagraphList data & method' kind of class I'd like to have in the end. [The 'elements' are, of course, Paragraphs::rows itself, and a few bits and pieces all over the place. textwidth_ belongs in this category.] [I still think we can get away with 'draw on demand' in the end so the row cache could completely die...] Andre'
Re: A working InsetVSpace
On Fri, Nov 28, 2003 at 01:23:37PM +, Angus Leeming wrote: > On Friday 28 November 2003 1:12 pm, Angus Leeming wrote: > > There, I didn't think that it should be so hard. > > I forgot to 'cvs add' the new files. This patch has everything. Could you please commit the Qt parts yourself? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: [Patch] Class Header
On Friday 28 November 2003 10:51, Martin Vermeer wrote: > > I will adapt the linuxdoc code to the new scheme. > > Great! Make sure the output does't change. As long as it is whitespace that has no meaning. :-) I intend to add also Character Styles to linuxdoc. If we could agree on some kind of naming for them we could have a general list that would apply to all backends. Until this moment you added: * emphasis * noun * ... What do you think? > > With the exception of insets, as you noted, all the other parts are > > equal. > > Actually that's not quite true. In docbook spans > header *plus text*. I understand that linuxdoc is more LaTeX-like in > this respect. (Shouldn't be a problem though. Use InnerTag as the > header name, and leave the header name itself empty (dummy?)). I was not clear, what I meant is that this behaviour can be configured in the layout files. In this case dummy is "!-- --" that will give _ an empty comment. > > What about AGU? Do the inset always throw the correct output? > > No, I would say 'almost never'. Cross-reference e.g. > > docbookor ... > linuxdoc > AGU ... > > ...with the complication that the reference has to know the *type* of > the label (figure, table, section header...). Some programming > required... Do you intend to add a new class of insets agu? > Currently AGU outputs docbook inset code throughout. Still I expect > this will already be a major saving in manual mark-up work. This would give even better results. :-) > - Martin -- José Abílio
Re: [Devel] Re: questions: selection
On Fri, Nov 28, 2003 at 03:27:56PM +, Angus Leeming wrote: > On Friday 28 November 2003 3:25 pm, Andre Poenitz wrote: > > I question the utility of this feature. > > That's not really relevant to the original discussion. Now why should we break tradition? Andre'
Re: Character styles changeover?
On Friday 28 November 2003 12:41, Helge Hafting wrote:
> > ...and yes, I think (agree?) that character attributes
> > (size/bold/italic/...) ought to die off... but we cannot just remove
> > them, as they are in old docs. Discourage their use ("finger
> > painting") together with providing logical character (and paragraph)
> > styles to make them unnecessary.
>
> Old docs will need a converter anyway, the converter may notice
> that the user used "bold" or "underline" and create such a style
> in the converted document. So the old style system can be removed
> without breaking compatibility. Of course the converter can't
> guess the true menaing of the markup and will resort to
> style names like "underlined-for-some-reason" . . .
I agree with Helge, lyx2lyx should convert the old documents, even if it is
for "underlined-for-some-reason" logical char style.
Legacy documents should not be the problem...
> Helge Hafting
--
José Abílio
Re: [Devel] Re: questions: selection
On Friday 28 November 2003 3:25 pm, Andre Poenitz wrote: > I question the utility of this feature. That's not really relevant to the original discussion. Alfredo was trying to ascertain what the existing code was trying to do. > General marks _are_ useful, but in LyX I'd probably implement them as > invisible or barely visible insets, not as part of the selection > mechanism... Fine. A.
Re: [JMarc]: xforms/Makefile.am
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
Angus> Jean-Marc, wouldn't this: stamp-forms: lyx_forms.h-tmp if cmp
Angus> -s $< lyx_forms.h ; then \ : ;\ else \ rm -f lyx_forms.h ;\ cp
Angus> $< lyx_forms.h ;\ fi echo timestamp > $@
Angus> be better as this: stamp-forms: lyx_forms.h-tmp cmp -s $<
Angus> lyx_forms.h || { \ rm -f lyx_forms.h ;\ cp $< lyx_forms.h ;\
Angus> }
Angus> echo timestamp > $@
I am not really used to this {} syntax (I did not know it existed,
actually).
But the right thing to do in this particular case is to get rid of
these include files and go back to the good old
#include FORMS_H_LOCATION
we used to have. The reason why Lars introduced that (that
rerunning configure with a different frontend forces a full rebuild)
does not hold anymore now that we have multiple frontends support.
JMarc
Re: Harmonization of UI messages
On Fri, Nov 28, 2003 at 12:12:13PM +0100, Michael Schmitt spake thusly: > Dear Martin and Angus, > > I changed a couple of messages (mainly concerning the Box dialog) to > "harmonize" the dialogs. Could you please check and apply the patch? > Thanks in advance. I like these short patches... don't consume unnecessary bandwidth. - Martin pgp0.pgp Description: PGP signature
Re: [Devel] Re: questions: selection
On Fri, Nov 28, 2003 at 03:12:28PM +, Angus Leeming wrote: > On Friday 28 November 2003 3:04 pm, Andre Poenitz wrote: > > > Copy the buffer from the 'set-mark' point to the current cursor > > > position. (M-w in emacs shortcut notation.) > > > > Is there just a single one of these buffers? > > It appears so, yes. At least trying to set the mark in two views of the same > buffer causes the mark set in the first view to be unset. > > > > Thus I could type: > > > C-S-@ > > > Esc-> > > > M-w > > > > > > to copy all text from the current cursor position to the end of the > > > document. > > > > Sounds like what 'vG' or 'vG$' would do in vim... > > > > In any case, this marking setting business seems to be unrelated to > > selection as such. If so, it should not be implemented there. > > Well, it marks the starting point for any future selection... I question the utility of this feature. First, I have to mark the beginning of the potential selection. With the same effort I could start a real selection. Second, the feature could be implemented on top of real marks. I.e. in vim I'd use ma (set mark 'a') G (go to end of doc) v (select ... 'a ... to mark 'a') General marks _are_ useful, but in LyX I'd probably implement them as invisible or barely visible insets, not as part of the selection mechanism... Andre'
Re: [patch 13x and 14x] convertDefault.sh
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> convertDefault.sh will report failure when invoked on Win32 Angus> with files with absolute paths. This patch fixes the problem. Angus> -FILE=`echo $2 | cut -d ':' -f 2` +# Note that Win32 filenames Angus> have the form 'C:\my\file', +# so use everything from the first Angus> ':' to the end of the line. +FILE=`echo $2 | cut -d ':' -f 2-` Angus> Jean-Marc, ok to apply to 13x? Sure. JMarc
Re: Translations concerning the "box" inset
On Fri, Nov 28, 2003 at 11:18:50AM +0100, Michael Schmitt spake thusly: > Hi Martin and Angus, > > when doing the German translations, I noticed that I have to translate > the same messages (with slight variations) again and again. > > Could you please have a look at the attachment and at the code > concerning the box insert? It feels like there is a lot of redundancy in > the code that should be removed for consistency and maintainability > reasons. The messages in ControlBox, FormBox and insetbox can be remove > in two of these file, can't they? > > Could also please make sure that the capitalization (ovalbox vs. > Ovalbox) does not play a role? This is quite bad UI-wise. But it *does* play a role in LaTeX... > Kind regards, > > Michael > > #: ../lib/ui/stdmenus.ui:347 > msgid "Boxed|B" > #: ../lib/ui/stdmenus.ui:348 > msgid "Oval Box|O" > #: ../lib/ui/stdmenus.ui:349 > msgid "Oval Box, Thick|T" > #: ../lib/ui/stdmenus.ui:350 > msgid "Shadow Box|S" > #: ../lib/ui/stdmenus.ui:351 > msgid "Double Box|D" > #: ../lib/ui/stdmenus.ui:346 > msgid "Frameless|F" These appear in the dialog choice pulldown choosing the box type. > #: src/frontends/controllers/ControlBox.C:60 > msgid "No frame drawn" > #: src/frontends/controllers/ControlBox.C:61 > msgid "Rectangular box" > #: src/frontends/controllers/ControlBox.C:62 > msgid "Oval box, thin" > #: src/frontends/controllers/ControlBox.C:63 > msgid "Oval box, thick" > #: src/frontends/controllers/ControlBox.C:64 > msgid "Shadow box" > #: src/frontends/controllers/ControlBox.C:65 > msgid "Double box" This appears in the tooltip over the dialog... > #: src/frontends/xforms/FormBox.C:56 > msgid "" > "Frameless: No border\n" > "Boxed: Rectangular\n" > "ovalbox: Oval, thin border\n" > "Ovalbox: Oval, thick border\n" > "Shadowbox: Box casting shadow\n" > "Doublebox: Double line border" ...and these are the strings appearing on the buttons in the LyX GUI. They should be short/one word, obviously. > #: src/insets/insetbox.C:52 > msgid "Boxed" > #: src/insets/insetbox.C:53 > msgid "Frameless" > #: src/insets/insetbox.C:54 > msgid "ovalbox""OvalThin" > #: src/insets/insetbox.C:55 > msgid "Ovalbox""OvalThick" > #: src/insets/insetbox.C:56 > msgid "Shadowbox" > #: src/insets/insetbox.C:57 > msgid "Doublebox" I am open to suggestions... but these are the constraints. The above alternatives are in reponse to your valid objection to using capitalization in the UI. Happy with them I am not. - Martin pgp0.pgp Description: PGP signature
Re: [Devel] Re: questions: selection
On Friday 28 November 2003 3:04 pm, Andre Poenitz wrote: > > Copy the buffer from the 'set-mark' point to the current cursor > > position. (M-w in emacs shortcut notation.) > > Is there just a single one of these buffers? It appears so, yes. At least trying to set the mark in two views of the same buffer causes the mark set in the first view to be unset. > > Thus I could type: > > C-S-@ > > Esc-> > > M-w > > > > to copy all text from the current cursor position to the end of the > > document. > > Sounds like what 'vG' or 'vG$' would do in vim... > > In any case, this marking setting business seems to be unrelated to > selection as such. If so, it should not be implemented there. Well, it marks the starting point for any future selection... Angus
Re: ping
> Do we still have two hours roundtrip time on this list? Actually 2 1/2 hours this time... Alfredo
Re: [Devel] Re: questions: selection
On Fri, Nov 28, 2003 at 02:44:50PM +, Angus Leeming wrote: > On Friday 28 November 2003 1:46 pm, Alfredo Braunstein wrote: > > On Friday 28 November 2003 14:37, Angus Leeming wrote: > > > Is this like emacs' 'mark'? Ie, we 'mark' the start of the > > > selection buffer. Angus (being thick and lazy) > > > > Possibly. What's good for, in emacs? How does it work? > > Some text |in emacs going on for line after line. A new para. Foo > bar. Lack of inspiration. > > The cursor is on the top line, immediately before 'in'. Using the > command-buffer 'M-x set-mark-command' or the shortcut 'C-S-@' to 'set > mark' > > Move the cursor to the bottom line, either by scrolling using the > arrow keys or USING THE MOUSE TO CLICK at the desired position. > > Copy the buffer from the 'set-mark' point to the current cursor > position. (M-w in emacs shortcut notation.) Is there just a single one of these buffers? > Thus I could type: > C-S-@ > Esc-> > M-w > > to copy all text from the current cursor position to the end of the > document. Sounds like what 'vG' or 'vG$' would do in vim... In any case, this marking setting business seems to be unrelated to selection as such. If so, it should not be implemented there. Andre'
Re: feature request
> "Christian" == Christian Ridderström <[EMAIL PROTECTED]> writes: Christian> The problem mainly seems to lie with the UI: - John didn't Christian> like adding menu alternatives for this because it would Christian> clutter the menus. (i.e. one alternative for "Open all Christian> floats", one for "Close all floats") - JMarc suggested a Christian> toggle-function for "insets similar to this point" (this Christian> sounds pretty good to me actually) I think that for a great part the problem is that nobody took the time to do it. I guess that it should be much easier now that we have proper iterators. JMarc
Re: [Devel] Re: questions: selection
On Friday 28 November 2003 15:44, Angus Leeming wrote: > [...]to copy all text from the current cursor position to the end of the > document. Indeed, I think it can be the case (it seems to be more or less coherent with how it is used in the code). Thanks for the explanation. Alfredo
Re: [Patch] Class Header
On Fri, Nov 28, 2003 at 10:38:04AM +, Angus Leeming spake thusly: > > Jose' Matos wrote: ... > >> An in-between kludge at this point could be to test for > >> linuxdoc/docbook at line 227 of output_docbook.C and call either > >> simpleDocBookOnePar() or simpleLinuxDocOnePar(). Of course after > >> adapting the linuxdoc layout files to use the new parametrization. > > > > I will adapt the linuxdoc code to the new scheme. > > With the exception of insets, as you noted, all the other parts > > are equal. > > José, in that case, you might use boost::bind and boost::function to > call the correct inset member function. ... yes! A beautiful, elegant, alternative in-between kludge. > Perhaps this helps? I still want to see the insets rich-parametrized too. Remember, we want to arrive at a situation where any new DTD can be supported by someone not needing to touch the C++ code base, only the .layout file tree. Like we currently have for LaTeX. A tall order, I know. > -- > Angus - Martin pgp0.pgp Description: PGP signature
Re: [Devel] Re: questions: selection
On Friday 28 November 2003 1:46 pm, Alfredo Braunstein wrote: > On Friday 28 November 2003 14:37, Angus Leeming wrote: > > Is this like emacs' 'mark'? Ie, we 'mark' the start of the selection > > buffer. Angus (being thick and lazy) > > Possibly. What's good for, in emacs? How does it work? Some text |in emacs going on for line after line. A new para. Foo bar. Lack of inspiration. The cursor is on the top line, immediately before 'in'. Using the command-buffer 'M-x set-mark-command' or the shortcut 'C-S-@' to 'set mark' Move the cursor to the bottom line, either by scrolling using the arrow keys or USING THE MOUSE TO CLICK at the desired position. Copy the buffer from the 'set-mark' point to the current cursor position. (M-w in emacs shortcut notation.) Thus I could type: C-S-@ Esc-> M-w to copy all text from the current cursor position to the end of the document. HTH, Angus
Re: [Devel] Re: questions: selection
On Friday 28 November 2003 14:37, Angus Leeming wrote: > Is this like emacs' 'mark'? Ie, we 'mark' the start of the selection > buffer. Angus (being thick and lazy) Possibly. What's good for, in emacs? How does it work? > ps, could you cc lyx-devel when mailing to [EMAIL PROTECTED] The message > will get there 'eventually' and will then make its way into the archive. ok (but then people tend to answer there... ) Alfredo
Re: feature request
On Tue, Nov 25, 2003 at 05:12:40PM +0100, Markus B. wrote: > Yet, the feature that I am missing in Lyx is a switch, either a menu entry or > a button to open/close all footnotes at once. This feature was available in Why do you want to be able to open or close all the footnotes at once ? john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [patch] move text from BufferView to Buffer
Andre Poenitz wrote: > > [We had discussed this already once, but as this is 'fundamental' I > thought we'd better agree explicitly on it ;-)] > > This replaces the LyXText 'semi member' of BufferView by a real > LyXText member of Buffer. [snip...] > Comments? This (below) seems fundamentally wrong. If the LyXText needs to know the width of the WorkArea, then it isn't a Buffer property at all. Of course, this maybe the 'prepares for' bit ;-) Index: BufferView_pimpl.C === // set current buffer buffer_ = b; + buffer_->text().init(bv_); + buffer_->text().textwidth_ = workarea().workWidth(); + buffer_->text().fullRebreak(); > > Andre' -- Angus
Re: Harmonization of UI messages
Michael Schmitt wrote: Hi, Michael. > I changed a couple of messages (mainly concerning the Box dialog) to > "harmonize" the dialogs. Could you please check and apply the patch? > Thanks in advance. Patch please... -- Angus
Re: A working InsetVSpace
On Friday 28 November 2003 1:12 pm, Angus Leeming wrote: > There, I didn't think that it should be so hard. I forgot to 'cvs add' the new files. This patch has everything. Angus vspace.diff.bz2 Description: BZip2 compressed data
Re: A working InsetVSpace
On Fri, Nov 28, 2003 at 01:12:07PM +, Angus Leeming wrote: > There, I didn't think that it should be so hard. Well, it was for me. Thank you. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
A working InsetVSpace
There, I didn't think that it should be so hard. Things I've changed: 1. stdmenus.ui now dispatches "dialog-show-new-inset vspace" rather than "insert-vspace". LFUN_INSERT_VSPACE no longer exists. Rationale: when I insert a vspace from the menu, I want the dialog to pop up so that I can specify the size of the space. Only of 'Apply' is the inset created. 2. InsetVSpace now has a mailer, InsetVSpaceMailer. Associated with this the InsetVSpace(string const &) constructor is replaced with InsetVSpace(VSpace const &) as that is what is stored internally. I haven't made the VSpace space_ member private, but it should. 3. CommandVSpace: the mailer makes this class trivial. Note that dispatch should post LFUN_INSERT_INSET rather than LFUN_PARA_APPLY or whatever it was. 4. FormVSpace: I got rid of the EnableWidget stuff. The choice still needs to be filled. 5. Qt: I got rid of the VSpace stuff from the Paragraph dialog but have not written QVSpace. (6. In text3.C doInsertInset now takes a LyXText const &. I have no idea why things were crashing before when calling this, but don't really care either. The interface was incorrect. See 1 above.) 7. I note that on 'Apply' from the dialog, the inset is drawn partially 'hidden'... HTH, Angus vspace.diff.bz2 Description: BZip2 compressed data
[JMarc]: xforms/Makefile.am
Jean-Marc, wouldn't this:
stamp-forms: lyx_forms.h-tmp
if cmp -s $< lyx_forms.h ; then \
: ;\
else \
rm -f lyx_forms.h ;\
cp $< lyx_forms.h ;\
fi
echo timestamp > $@
be better as this:
stamp-forms: lyx_forms.h-tmp
cmp -s $< lyx_forms.h || { \
rm -f lyx_forms.h ;\
cp $< lyx_forms.h ;\
}
echo timestamp > $@
Ditto here:
stamp-xpm: lyx_xpm.h-tmp
if cmp -s $< lyx_xpm.h ; then \
: ;\
else \
rm -f lyx_xpm.h ;\
cp $< lyx_xpm.h ;\
fi
echo timestamp > $@
--
Angus
ping
Do we still have two hours roundtrip time on this list? Andre'
Re: Character styles changeover?
Martin Vermeer wrote:
On Fri, Nov 28, 2003 at 09:46:11AM +0100, Andre Poenitz spake thusly:
I would not trust in an eternal existence of different implementations
of 'logical' and 'physical' markup... Even if there is a theoretic
difference I can't see a technical reason requiring two implementations.
However, I think LyX should strive for using logical mark-up only...
if we find that, e.g., someone is underlining text elements, we should
ask *why* he is doing that, i.e., what does he try to express...
semantic mark-up. And then create a logical mark-up style to support
that.
For underline, all I can think of is a typewriter lacking an italic
font... i.e. "typewriter emph". Or (together with blue) a hyperlink.
...and yes, I think (agree?) that character attributes
(size/bold/italic/...) ought to die off... but we cannot just remove
them, as they are in old docs. Discourage their use ("finger
painting") together with providing logical character (and paragraph)
styles to make them unnecessary.
Old docs will need a converter anyway, the converter may notice
that the user used "bold" or "underline" and create such a style
in the converted document. So the old style system can be removed
without breaking compatibility. Of course the converter can't
guess the true menaing of the markup and will resort to
style names like "underlined-for-some-reason" . . .
Helge Hafting
Re: right margin!
Andre Poenitz <[EMAIL PROTECTED]> writes: >> Not the look of the main screen looks like something is hidden at the >> right side all the time... not looking good at all. >> >> Can it be put back again please. > | Done. Thanks. -- Lgb
Harmonization of UI messages
Dear Martin and Angus,
I changed a couple of messages (mainly concerning the Box dialog) to
"harmonize" the dialogs. Could you please check and apply the patch?
Thanks in advance.
Could you please also have a look at the Box dialog (I don't use xforms)
and check that colons are used consistently? ("Height" vs. "Height:") I
guess a few are missing. This might save us poor translators another few
messages.
Kind regards,
Michael
Re: Character styles changeover?
On Fri, Nov 28, 2003 at 08:08:03AM +, Jose' Matos spake thusly:
> On Thursday 27 November 2003 18:51, Martin Vermeer wrote:
> >
> > ...and remember, in these charstyle insets, like in ERT, there is no
> > possibility to internally change char attributes anyway...
>
> I like it. :-)
> Could not this work apply to index either as the users are asking this in
> the users mailing list?
Easy enough, as John remarked. See attached. It's not based on this
work though... index is not a collaps(a/i)ble inset.
However, I think the original poster wanted a way to move the index
boxes out of the way completely, as he has lots of them...
- Martin
Index: insetindex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetindex.C,v
retrieving revision 1.57
diff -u -p -r1.57 insetindex.C
--- insetindex.C5 Nov 2003 12:06:16 - 1.57
+++ insetindex.C28 Nov 2003 11:04:12 -
@@ -42,7 +42,10 @@ InsetIndex::~InsetIndex()
string const InsetIndex::getScreenLabel(Buffer const &) const
{
- return _("Idx");
+ string s = getContents();
+ if (s.size() > 15)
+ s = s.substr(0, 12) + "...";
+ return _("Idx:") + s;
}
pgp0.pgp
Description: PGP signature
[patch] move text from BufferView to Buffer
[We had discussed this already once, but as this is 'fundamental' I
thought we'd better agree explicitly on it ;-)]
This replaces the LyXText 'semi member' of BufferView by a real LyXText
member of Buffer.
The benefit in the long run is, of course, simpler architecture.
Immediately we would gain the possibility to move the ParagraphList
members of InsetText and Buffer into LyXText and use the member there
instead of the ownerParagraphs() construct, which, in turn, is the only
'real' of the remaining user of the LyXText::inset_owner backpointers.
Additionally, this improves the separation of 'View' (BufferView) and
'Data' (paragraph data in Buffer, operations in LyXText)
I think this can be best viewed as a consequence of a shift in semantics
we've had in the 1.4 series: Historically, LyXText was the 'row cache'
and happened to carry a lot of the text manipulation operations. The
rows-per-par split deprived LyXText of its row store position, so
currently there is not much left in addition to the text operation. So
the merge of the text operations in LyXText and the text data in
ParagraphList seems sensible. That's what this patch does/prepares for.
Comments?
Andre'
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.211
diff -u -p -r1.211 BufferView.C
--- BufferView.C28 Nov 2003 08:55:04 - 1.211
+++ BufferView.C28 Nov 2003 10:24:53 -
@@ -59,14 +59,11 @@ BufferView::BufferView(LyXView * owner,
int width, int height)
: pimpl_(new Pimpl(this, owner, xpos, ypos, width, height)),
x_target_(0)
-{
- text_ = 0;
-}
+{}
BufferView::~BufferView()
{
- delete text_;
delete pimpl_;
}
@@ -256,10 +253,10 @@ bool BufferView::insertLyXFile(string co
string const fname = MakeAbsPath(filen);
- text_->clearSelection();
- text_->breakParagraph(buffer()->paragraphs());
+ text()->clearSelection();
+ text()->breakParagraph(buffer()->paragraphs());
- bool res = buffer()->readFile(fname, text_->cursorPar());
+ bool res = buffer()->readFile(fname, text()->cursorPar());
resize();
return res;
}
@@ -290,9 +287,9 @@ void BufferView::setCursorFromRow(int ro
buffer()->texrow().getIdFromRow(row, tmpid, tmppos);
if (tmpid == -1)
- text_->setCursor(0, 0);
+ text()->setCursor(0, 0);
else
- text_->setCursor(buffer()->getParFromID(tmpid).pit(), tmppos);
+ text()->setCursor(buffer()->getParFromID(tmpid).pit(), tmppos);
}
@@ -309,11 +306,11 @@ void BufferView::gotoLabel(string const
vector labels;
it->getLabelList(*buffer(), labels);
if (find(labels.begin(),labels.end(),label) != labels.end()) {
- text_->clearSelection();
- text_->setCursor(
- std::distance(text_->ownerParagraphs().begin(),
it.getPar()),
+ text()->clearSelection();
+ text()->setCursor(
+ std::distance(text()->ownerParagraphs().begin(),
it.getPar()),
it.getPos());
- text_->selection.cursor = text_->cursor;
+ text()->selection.cursor = text()->cursor;
update();
return;
}
@@ -327,7 +324,7 @@ void BufferView::undo()
return;
owner()->message(_("Undo"));
- text_->clearSelection();
+ text()->clearSelection();
if (!textUndo(this))
owner()->message(_("No further undo information"));
update();
@@ -341,7 +338,7 @@ void BufferView::redo()
return;
owner()->message(_("Redo"));
- text_->clearSelection();
+ text()->clearSelection();
if (!textRedo(this))
owner()->message(_("No further redo information"));
update();
@@ -460,4 +457,10 @@ int BufferView::x_target() const
void BufferView::updateParagraphDialog()
{
pimpl_->updateParagraphDialog();
+}
+
+
+LyXText * BufferView::text() const
+{
+ return pimpl_->buffer_ ? &pimpl_->buffer_->text() : 0;
}
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.153
diff -u -p -r1.153 BufferView.h
--- BufferView.h28 Nov 2003 08:55:04 - 1.153
+++ BufferView.h28 Nov 2003 10:24:53 -
@@ -189,9 +189,7 @@ public:
///
UpdatableInset * innerInset() const;
///
- LyXText * text() const { return text_; }
- ///
- void setText(LyXText * t) { text_ = t; }
+ LyXText * text() const;
private:
///
@@ -200,9 +198,6 @@
Re: [Patch] Class Header
Jose' Matos wrote:
> On Wednesday 26 November 2003 20:18, Martin Vermeer wrote:
>>
>> In principle. Doing so now would break all insets that are
>> different for linuxdoc and docbook (and that's most of them!)
>>
>> An in-between kludge at this point could be to test for
>> linuxdoc/docbook at line 227 of output_docbook.C and call either
>> simpleDocBookOnePar() or simpleLinuxDocOnePar(). Of course after
>> adapting the linuxdoc layout files to use the new parametrization.
>
> I will adapt the linuxdoc code to the new scheme.
> With the exception of insets, as you noted, all the other parts
> are equal.
José, in that case, you might use boost::bind and boost::function to
call the correct inset member function.
boost::function inset_exporter;
if (using_linuxdoc) {
// inset_exporter(inset) is equivalent to
// inset.linuxdoc(buf, os, runparams)
inset_exporter =
boost::bind(&InsetOld::linuxdoc, _1,
boost::cref(buf),
boost::ref(os),
boost::cref(runparams));
} else {
// inset_exporter(inset) is equivalent to
// inset.docbook(buf, os, runparams)
inset_exporter =
boost::bind(&InsetOld::docbook, _1,
boost::cref(buf),
boost::ref(os),
boost::cref(runparams));
}
To be used, so:
paragraph.simpleSGMLOnePar(buf, os, outerfont, runparams,
inset_exporter)
The relevant code in simpleSGMLOnePar would be:
void Paragraph::simpleSGMLOnePar(Buffer const & buf,
ostream & os,
LyXFont const & outerfont,
OutputParams const & runparams,
boost::function inset_exporter)
{
...
if (c == Paragraph::META_INSET) {
InsetOld const & inset = *getInset(i);
inset_exporter(inset);
font_old = font;
continue;
}
...
}
Perhaps this helps?
--
Angus
Re: [Patch] Class Header
On Fri, Nov 28, 2003 at 08:03:02AM +, Jose' Matos spake thusly: > On Wednesday 26 November 2003 20:18, Martin Vermeer wrote: > > > > In principle. Doing so now would break all insets that are different > > for linuxdoc and docbook (and that's most of them!) > > > > An in-between kludge at this point could be to test for > > linuxdoc/docbook at line 227 of output_docbook.C and call either > > simpleDocBookOnePar() or simpleLinuxDocOnePar(). Of course after > > adapting the linuxdoc layout files to use the new parametrization. > > I will adapt the linuxdoc code to the new scheme. Great! Make sure the output does't change. > With the exception of insets, as you noted, all the other parts are equal. Actually that's not quite true. In docbook spans header *plus text*. I understand that linuxdoc is more LaTeX-like in this respect. (Shouldn't be a problem though. Use InnerTag as the header name, and leave the header name itself empty (dummy?)). > What about AGU? Do the inset always throw the correct output? No, I would say 'almost never'. Cross-reference e.g. docbookor ... linuxdoc AGU ... ...with the complication that the reference has to know the *type* of the label (figure, table, section header...). Some programming required... Currently AGU outputs docbook inset code throughout. Still I expect this will already be a major saving in manual mark-up work. - Martin pgp0.pgp Description: PGP signature
Re: Change in CharStyle syntax?
> Does anybody have production documents containing CharStyles already? > > If not, I'll just check this in later today/tomorrow. i Committed. - Martin pgp0.pgp Description: PGP signature
Translations concerning the "box" inset
Hi Martin and Angus, when doing the German translations, I noticed that I have to translate the same messages (with slight variations) again and again. Could you please have a look at the attachment and at the code concerning the box insert? It feels like there is a lot of redundancy in the code that should be removed for consistency and maintainability reasons. The messages in ControlBox, FormBox and insetbox can be remove in two of these file, can't they? Could also please make sure that the capitalization (ovalbox vs. Ovalbox) does not play a role? This is quite bad UI-wise. Kind regards, Michael #: ../lib/ui/stdmenus.ui:347 msgid "Boxed|B" #: ../lib/ui/stdmenus.ui:348 msgid "Oval Box|O" #: ../lib/ui/stdmenus.ui:349 msgid "Oval Box, Thick|T" #: ../lib/ui/stdmenus.ui:350 msgid "Shadow Box|S" #: ../lib/ui/stdmenus.ui:351 msgid "Double Box|D" #: ../lib/ui/stdmenus.ui:346 msgid "Frameless|F" #: src/frontends/controllers/ControlBox.C:60 msgid "No frame drawn" #: src/frontends/controllers/ControlBox.C:61 msgid "Rectangular box" #: src/frontends/controllers/ControlBox.C:62 msgid "Oval box, thin" #: src/frontends/controllers/ControlBox.C:63 msgid "Oval box, thick" #: src/frontends/controllers/ControlBox.C:64 msgid "Shadow box" #: src/frontends/controllers/ControlBox.C:65 msgid "Double box" #: src/frontends/xforms/FormBox.C:56 msgid "" "Frameless: No border\n" "Boxed: Rectangular\n" "ovalbox: Oval, thin border\n" "Ovalbox: Oval, thick border\n" "Shadowbox: Box casting shadow\n" "Doublebox: Double line border" #: src/insets/insetbox.C:52 msgid "Boxed" #: src/insets/insetbox.C:53 msgid "Frameless" #: src/insets/insetbox.C:54 msgid "ovalbox" #: src/insets/insetbox.C:55 msgid "Ovalbox" #: src/insets/insetbox.C:56 msgid "Shadowbox" #: src/insets/insetbox.C:57 msgid "Doublebox"
Re: feature request
On Tue, 25 Nov 2003, Markus B. wrote: > Hi, > > I have been using Klyx for a long time and I appreciate it very much. > > Yet, the feature that I am missing in Lyx is a switch, either a menu entry or > a button to open/close all footnotes at once. This feature was available in > Klyx. Actually, I would need it quite badly because I am writing on my thesis > with so far over 700 footnotes. Opening and closing them manually is a bit of > a hassle. > > Perhaps I have just overlooked it, but is this feature available or planned? > AFIK, it's not avaiable, but something similar is in bugzilla: http://bugzilla.lyx.org/show_bug.cgi?id=502 The entry is mainly about floats, but this request pops up now and then for footnotes and other insets too. The problem mainly seems to lie with the UI: - John didn't like adding menu alternatives for this because it would clutter the menus. (i.e. one alternative for "Open all floats", one for "Close all floats") - JMarc suggested a toggle-function for "insets similar to this point" (this sounds pretty good to me actually) /Christian -- Christian Ridderström http://www.md.kth.se/~chr
New bugs
Hello everybody,
I found a couple of new bugs in LyX 1.4. Simple test case descriptions
are attached. Unless I hear from you, I will add them to bugzilla in the
evening.
Have a nice day,
Michael
-- 1 --
Open new doc; enter "a", CTRL-M, "{"; click in front of "a"
=> the red math box does not disappear
-- 2 --
Open new doc; enter CTRL-M (math formula); close doc (with cursor inside empty math
formula;
discard changes)
=> valgrind moans
==17053==
==17053== Invalid read of size 4
==17053==at 0x80DC5FA: LCursor::innerInsetOfType(int) const (cursor.C:215)
==17053==by 0x80DC64A: LCursor::innerInsetTabular() const (cursor.C:223)
==17053==by 0x810C6EC: LyXFunc::getStatus(FuncRequest const&) const (lyxfunc.C:315)
==17053==by 0x82A114A: QLToolbar::update() (QLToolbar.C:69)
==17053==Address 0x42EF422C is 0 bytes inside a block of size 52 free'd
==17053==at 0x4002D07B: __builtin_delete (vg_replace_malloc.c:244)
==17053==by 0x4002D099: operator delete(void*) (vg_replace_malloc.c:253)
==17053==by 0x8190003: InsetFormula::~InsetFormula() (formula.C:85)
==17053==by 0x80843F3: InsetList::~InsetList() (InsetList.C:51)
==17053==
==17053== Jump to the invalid address stated on the next line
==17053==at 0x69626962: ???
==17053==by 0x80DC64A: LCursor::innerInsetTabular() const (cursor.C:223)
==17053==by 0x810C6EC: LyXFunc::getStatus(FuncRequest const&) const (lyxfunc.C:315)
==17053==by 0x82A114A: QLToolbar::update() (QLToolbar.C:69)
==17053==Address 0x69626962 is not stack'd, malloc'd or free'd
==17053== Warning: SIGSEGV not in user code; either from syscall kill()
==17053==or possible Valgrind bug. This message is only shown 3 times.
-- 3 --
Open new doc; enter CTRL-M; press cursor-left
=> cursor does not leave the math inset
-- 4 --
Open new doc; enter "a", CTRL-M, "{"; click in front of "a"; close doc (discard
changes); open new doc
=> valgrind moans
==17093==
==17093== Invalid read of size 4
==17093==at 0x81999DC: MathCursor::info() const (math_cursor.C:1292)
==17093==by 0x80CC203: bv_funcs::currentState(BufferView*) (bufferview_funcs.C:176)
==17093==by 0x8113497: LyXFunc::view_status_message() (lyxfunc.C:1742)
==17093==by 0x829FB25: QtView::update_view_state_qt() (QtView.C:119)
==17093==Address 0x449E5BBC is 0 bytes inside a block of size 100 free'd
==17093==at 0x4002D07B: __builtin_delete (vg_replace_malloc.c:244)
==17093==by 0x4002D099: operator delete(void*) (vg_replace_malloc.c:253)
==17093==by 0x81B9303: MathHullInset::~MathHullInset() (math_hullinset.C:492)
==17093==by 0x819575A: MathAtom::~MathAtom() (math_atom.C:47)
==17093==
==17093== Invalid read of size 4
==17093==at 0x8197E72: MathCursor::array() const (math_cursor.C:858)
==17093==by 0x8197CC4: MathCursor::prevAtom() const (math_cursor.C:829)
==17093==by 0x8199A33: MathCursor::info() const (math_cursor.C:1296)
==17093==by 0x80CC203: bv_funcs::currentState(BufferView*) (bufferview_funcs.C:176)
==17093==Address 0x449E5BBC is 0 bytes inside a block of size 100 free'd
==17093==at 0x4002D07B: __builtin_delete (vg_replace_malloc.c:244)
==17093==by 0x4002D099: operator delete(void*) (vg_replace_malloc.c:253)
==17093==by 0x81B9303: MathHullInset::~MathHullInset() (math_hullinset.C:492)
==17093==by 0x819575A: MathAtom::~MathAtom() (math_atom.C:47)
==17093==
==17093== Jump to the invalid address stated on the next line
==17093==at 0xA: ???
==17093==by 0x8197CC4: MathCursor::prevAtom() const (math_cursor.C:829)
==17093==by 0x8199A33: MathCursor::info() const (math_cursor.C:1296)
==17093==by 0x80CC203: bv_funcs::currentState(BufferView*) (bufferview_funcs.C:176)
==17093==Address 0xA is not stack'd, malloc'd or free'd
==17093== Warning: SIGSEGV not in user code; either from syscall kill()
==17093==or possible Valgrind bug. This message is only shown 3 times.
-- 5 --
Open new doc; create a 1x1 table; try to select the whole table
=> the table can be selected but the marked area does not match the table
-- 6 --
Open new doc; create a 3x3 table; click into the center cell
=> the whole table is shifted to the left
enter two letters
=> the first letter is printed in front of the table,
the second inside the cell - but to the right (although the column alignment is
vertical)
changing the column alignment finally leads to seg fault
[patch 13x and 14x] convertDefault.sh
convertDefault.sh will report failure when invoked on Win32 with files
with absolute paths. This patch fixes the problem.
-FILE=`echo $2 | cut -d ':' -f 2`
+# Note that Win32 filenames have the form 'C:\my\file',
+# so use everything from the first ':' to the end of the line.
+FILE=`echo $2 | cut -d ':' -f 2-`
Jean-Marc, ok to apply to 13x?
--
AngusIndex: lib/scripts/convertDefault.sh
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/lib/scripts/convertDefault.sh,v
retrieving revision 1.5
diff -u -p -r1.5 convertDefault.sh
--- lib/scripts/convertDefault.sh 13 Jan 2003 23:35:18 - 1.5
+++ lib/scripts/convertDefault.sh 28 Nov 2003 09:29:39 -
@@ -6,18 +6,24 @@
# replacement in ~/.lyx/scripts
#
# converts an image from $1 to $2 format
-convert -depth 8 $1 $2
-if [ $? -ne 0 ]; then
-exit $?
-fi
+
+convert -depth 8 $1 $2 || {
+ echo "$0 ERROR"
+ echo "Execution of \"convert\" failed."
+ exit 1
+}
# It appears that convert succeeded, but we know better than to trust it ;-)
# convert is passed strings in the form "FMT:FILENAME", so use the ':' to
# delimit the two parts.
-FILE=`echo $2 | cut -d ':' -f 2`
+# Note that Win32 filenames have the form 'C:\my\file',
+# so use everything from the first ':' to the end of the line.
+FILE=`echo $2 | cut -d ':' -f 2-`
-# FSTATUS == 0 is the file exists and == 1 if it does not.
-FSTATUS=0
-test -f $FILE || FSTATUS=1
+test -f $FILE || {
+ echo "$0 ERROR"
+ echo "Unable to find file \"${FILE}\""
+ exit 1
+}
-exit $FSTATUS
+echo "$0 generated file \"${FILE}\" successfully."
Re: Character styles changeover?
On Fri, Nov 28, 2003 at 09:46:11AM +0100, Andre Poenitz spake thusly:
> On Thu, Nov 27, 2003 at 09:52:11PM +0100, Lars Gullik Bjønnes wrote:
> > No... underline/underbar is much more releted to size/bold/italic etc.
> > It is not a logical style, and that is what I belive charstyles should
> > be.
>
> I would not trust in an eternal existence of different implementations
> of 'logical' and 'physical' markup... Even if there is a theoretic
> difference I can't see a technical reason requiring two implementations.
However, I think LyX should strive for using logical mark-up only...
if we find that, e.g., someone is underlining text elements, we should
ask *why* he is doing that, i.e., what does he try to express...
semantic mark-up. And then create a logical mark-up style to support
that.
For underline, all I can think of is a typewriter lacking an italic
font... i.e. "typewriter emph". Or (together with blue) a hyperlink.
...and yes, I think (agree?) that character attributes
(size/bold/italic/...) ought to die off... but we cannot just remove
them, as they are in old docs. Discourage their use ("finger
painting") together with providing logical character (and paragraph)
styles to make them unnecessary.
- Martin
pgp0.pgp
Description: PGP signature
Re: right margin!
On Thu, Nov 27, 2003 at 10:22:29PM +0100, Lars Gullik Bjønnes wrote: > > Ok, who removed the right margin? I did when straightening out the 'overlapping insets' 'feature' and seemingly forgot to re-add it in the end. > Not the look of the main screen looks like something is hidden at the > right side all the time... not looking good at all. > > Can it be put back again please. Done. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: CVS lyx and math power box?
On Thu, Nov 27, 2003 at 08:48:07PM -0800, Kayvan A. Sylvan wrote: > Hi folks, > > When I enter "^" in math mode (or use the power button in the math > panel), I see a "^" and not the box slightly up and to the right that > I expect. Funny. I can confirm this. Maybe a result if the dispatch order corrections. I'll have a look tonight. Andre'
Re: feature request
On Tue, Nov 25, 2003 at 05:12:40PM +0100, Markus B. wrote: > Hi, > > I have been using Klyx for a long time and I appreciate it very much. > > Yet, the feature that I am missing in Lyx is a switch, either a menu entry or > a button to open/close all footnotes at once. This feature was available in > Klyx. Actually, I would need it quite badly because I am writing on my thesis > with so far over 700 footnotes. Opening and closing them manually is a bit of > a hassle. In such 'emergency' cases you could run your favourite text editors' search&replace or even Perl on the raw .lyx file. > Perhaps I have just overlooked it, but is this feature available or planned? It got lost somehow. Should not be too hard to re-implement but somehow nobody did so far. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson or B. Franklin or both...)
Re: Character styles changeover?
On Thu, Nov 27, 2003 at 09:52:11PM +0100, Lars Gullik Bjønnes wrote: > No... underline/underbar is much more releted to size/bold/italic etc. > It is not a logical style, and that is what I belive charstyles should > be. I would not trust in an eternal existence of different implementations of 'logical' and 'physical' markup... Even if there is a theoretic difference I can't see a technical reason requiring two implementations. Andre'
[patch] small stuff
This changes public BufferView::text into a private BufferView::text_
and removes a bit of unused code from the insets (insetInInsetY,
InsetText::textwidth_/cpos/cpar/crow)
Should be uncontroversial.
Andre'
? .lyxlayout.C.swp
? 0.diff
? 1.diff
? 2.diff
? frontends/controllers/ControlVSpace.C
? frontends/controllers/ControlVSpace.h
? frontends/xforms/FormVSpace.C
? frontends/xforms/FormVSpace.h
? frontends/xforms/forms/form_vspace.fd
? insets/2
? insets/insetvspace.C
? insets/insetvspace.h
Index: BufferView.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.C,v
retrieving revision 1.210
diff -u -p -r1.210 BufferView.C
--- BufferView.C13 Nov 2003 13:43:35 - 1.210
+++ BufferView.C28 Nov 2003 08:25:56 -
@@ -60,13 +60,13 @@ BufferView::BufferView(LyXView * owner,
: pimpl_(new Pimpl(this, owner, xpos, ypos, width, height)),
x_target_(0)
{
- text = 0;
+ text_ = 0;
}
BufferView::~BufferView()
{
- delete text;
+ delete text_;
delete pimpl_;
}
@@ -256,10 +256,10 @@ bool BufferView::insertLyXFile(string co
string const fname = MakeAbsPath(filen);
- text->clearSelection();
- text->breakParagraph(buffer()->paragraphs());
+ text_->clearSelection();
+ text_->breakParagraph(buffer()->paragraphs());
- bool res = buffer()->readFile(fname, text->cursorPar());
+ bool res = buffer()->readFile(fname, text_->cursorPar());
resize();
return res;
}
@@ -290,9 +290,9 @@ void BufferView::setCursorFromRow(int ro
buffer()->texrow().getIdFromRow(row, tmpid, tmppos);
if (tmpid == -1)
- text->setCursor(0, 0);
+ text_->setCursor(0, 0);
else
- text->setCursor(buffer()->getParFromID(tmpid).pit(), tmppos);
+ text_->setCursor(buffer()->getParFromID(tmpid).pit(), tmppos);
}
@@ -309,11 +309,11 @@ void BufferView::gotoLabel(string const
vector labels;
it->getLabelList(*buffer(), labels);
if (find(labels.begin(),labels.end(),label) != labels.end()) {
- text->clearSelection();
- text->setCursor(
- std::distance(text->ownerParagraphs().begin(),
it.getPar()),
+ text_->clearSelection();
+ text_->setCursor(
+ std::distance(text_->ownerParagraphs().begin(),
it.getPar()),
it.getPos());
- text->selection.cursor = text->cursor;
+ text_->selection.cursor = text_->cursor;
update();
return;
}
@@ -327,7 +327,7 @@ void BufferView::undo()
return;
owner()->message(_("Undo"));
- text->clearSelection();
+ text_->clearSelection();
if (!textUndo(this))
owner()->message(_("No further undo information"));
update();
@@ -341,7 +341,7 @@ void BufferView::redo()
return;
owner()->message(_("Redo"));
- text->clearSelection();
+ text_->clearSelection();
if (!textRedo(this))
owner()->message(_("No further redo information"));
update();
@@ -354,14 +354,14 @@ void BufferView::replaceWord(string cons
if (!available())
return;
- LyXText * text = getLyXText();
+ LyXText * t = getLyXText();
- text->replaceSelectionWithString(replacestring);
- text->setSelectionRange(replacestring.length());
+ t->replaceSelectionWithString(replacestring);
+ t->setSelectionRange(replacestring.length());
// Go back so that replacement string is also spellchecked
for (string::size_type i = 0; i < replacestring.length() + 1; ++i)
- text->cursorLeft(this);
+ t->cursorLeft(this);
// FIXME: should be done through LFUN
buffer()->markDirty();
@@ -410,13 +410,13 @@ Language const * BufferView::getParentLa
Encoding const * BufferView::getEncoding() const
{
- LyXText * text = getLyXText();
- if (!text)
+ LyXText * t = getLyXText();
+ if (!t)
return 0;
- return text->cursorPar()->getFont(
+ return t->cursorPar()->getFont(
buffer()->params(),
- text->cursor.pos(),
- outerFont(text->cursorPar(), text->ownerParagraphs())
+ t->cursor.pos(),
+ outerFont(t->cursorPar(), t->ownerParagraphs())
).language()->encoding();
}
Index: BufferView.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView.h,v
retrieving revision 1.152
diff -u -p -r1.152 BufferView.h
--- BufferView.h10 Nov 2003 13:23:08 -0
Re: Character styles changeover?
On Thursday 27 November 2003 18:51, Martin Vermeer wrote: > > ...and remember, in these charstyle insets, like in ERT, there is no > possibility to internally change char attributes anyway... I like it. :-) Could not this work apply to index either as the users are asking this in the users mailing list? > - Martin -- José Abílio LyX and docbook, a perfect match. :-)
Re: [Patch] Class Header
On Wednesday 26 November 2003 20:18, Martin Vermeer wrote: > > In principle. Doing so now would break all insets that are different > for linuxdoc and docbook (and that's most of them!) > > An in-between kludge at this point could be to test for > linuxdoc/docbook at line 227 of output_docbook.C and call either > simpleDocBookOnePar() or simpleLinuxDocOnePar(). Of course after > adapting the linuxdoc layout files to use the new parametrization. I will adapt the linuxdoc code to the new scheme. With the exception of insets, as you noted, all the other parts are equal. What about AGU? Do the inset always throw the correct output? > Dunno if that will work tho. Or is worth bothering with. One step each time. :-) > - Martin -- José Abílio
