Re: [patch] Qt scrolling
Angus Leeming wrote:
>> On Montag, 1. Dezember 2003 11:21, Angus Leeming wrote:
>>> The patch has the timout returning after 400ms. Could you modify
>>> the code to return after 200ms and see how that feels please.
>>
>> I would, but the patch is not applying anymore to cvs. I am at work
>> now, and don't have the sources from yesterday.
>>
>> - From what I remember, even the 400 ms was fast ...
>> I just managed to follow the selections, so I was not unhappy with
>> that value.
>
> Try 3, Kornel.
>
> This one should feel much smoother when you move the mouse back into
> the work area. In fact, I thnk that this is ready to go into the
> sources (and, indeed, be ported to 1.3.x) but I'd value it if you
> road-tested it for me one more time.
Actually, try this. Factually the same but the debug output is gone,
the comments reflect reality and it'll actually apply against current
cvs ;-)
--
AngusIndex: src/frontends/qt2/QContentPane.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.29
diff -u -p -r1.29 QContentPane.C
--- src/frontends/qt2/QContentPane.C 1 Dec 2003 23:04:36 - 1.29
+++ src/frontends/qt2/QContentPane.C 1 Dec 2003 23:08:35 -
@@ -10,6 +10,8 @@
#include
+#include
+
#include "QWorkArea.h"
#include "QContentPane.h"
#include "QLyXKeySym.h"
@@ -18,9 +20,6 @@
#include
#include
-#include "funcrequest.h"
-
-
namespace {
/// return the LyX key state from Qt's
@@ -74,10 +73,20 @@ mouse_button::state q_motion_state(Qt::B
} // namespace anon
+SyntheticMouseEvent::SyntheticMouseEvent()
+ : timeout(400), restart_timeout(true),
+ x_old(-1), y_old(-1), scrollbar_value_old(-1.0)
+{}
+
+
QContentPane::QContentPane(QWorkArea * parent)
: QWidget(parent, "content_pane", WRepaintNoErase),
track_scrollbar_(true), wa_(parent)
{
+ synthetic_mouse_event_.timeout.timeout.connect(
+ boost::bind(&QContentPane::generateSyntheticMouseEvent,
+ this));
+
setFocusPolicy(QWidget::WheelFocus);
setFocus();
setCursor(ibeamCursor);
@@ -85,7 +94,25 @@ QContentPane::QContentPane(QWorkArea * p
// stupid moc strikes again
connect(wa_->scrollbar_, SIGNAL(valueChanged(int)),
this, SLOT(scrollBarChanged(int)));
+}
+
+void QContentPane::generateSyntheticMouseEvent()
+{
+ // Set things off to generate the _next_ 'psuedo' event.
+ if (synthetic_mouse_event_.restart_timeout)
+ synthetic_mouse_event_.timeout.start();
+
+ // Has anything changed on-screen since the last timeout signal
+ // was received?
+ double const scrollbar_value = wa_->scrollbar_->value();
+ if (scrollbar_value != synthetic_mouse_event_.scrollbar_value_old) {
+ // Yes it has. Store the params used to check this.
+ synthetic_mouse_event_.scrollbar_value_old = scrollbar_value;
+
+ // ... and dispatch the event to the LyX core.
+ wa_->dispatch(synthetic_mouse_event_.cmd);
+ }
}
@@ -115,6 +142,9 @@ void QContentPane::mousePressEvent(QMous
void QContentPane::mouseReleaseEvent(QMouseEvent * e)
{
+ if (synthetic_mouse_event_.timeout.running())
+ synthetic_mouse_event_.timeout.stop();
+
FuncRequest const cmd(LFUN_MOUSE_RELEASE, e->x(), e->y(),
q_button_state(e->button()));
wa_->dispatch(cmd);
@@ -125,7 +155,50 @@ void QContentPane::mouseMoveEvent(QMouse
{
FuncRequest const cmd(LFUN_MOUSE_MOTION, e->x(), e->y(),
q_motion_state(e->state()));
- wa_->dispatch(cmd);
+
+ // If we're above or below the work area...
+ if (e->y() <= 0 || e->y() >= height()) {
+ // Store the event, to be handled when the timeout expires.
+ synthetic_mouse_event_.cmd = cmd;
+
+ if (synthetic_mouse_event_.timeout.running())
+ // Wait for the timeout to expire before handling the
+ // event.
+ // Ie, when the timeout expires, we handle the
+ // most recent event but discard all others that
+ // occurred after the one used to start the timeout
+ // in the first place.
+ return;
+ else {
+ synthetic_mouse_event_.restart_timeout = true;
+ synthetic_mouse_event_.timeout.start();
+ // Fall through to handle this event...
+ }
+
+ } else if (synthetic_mouse_event_.timeout.running()) {
+ // Store the event, to be handled when the timeout expires.
+ // Thereafter, normal control is returned to mouseMoveEvent.
+ // This results in a much smoother 'feel' when moving the
+ // mouse back into the work area.
+ synthetic_mouse_event_.cmd = cmd;
+ synthetic_mouse_event_.restart_timeout = false;
+ return;
+ }
+
+ // Has anything changed on-screen since the last QMouseEvent
+ // was received?
+ double const scrollbar_value = wa_->scrollbar_->value();
+ if (e->x() != synthetic_mouse_event_.x_old ||
+ e->y() != synthetic_mouse_event_.y_old ||
+ scrollbar_value != synthetic_mouse_event_.scrollbar_value_old) {
+ // Yes it has. Store the params used to check this.
+ synthetic_mouse_event_.x_old = e->x();
+ synthetic_mouse_event_.y_old = e->y();
+ synthetic_mouse_
Re: [patch] Qt scrolling
Kornel Benko wrote:
> On Montag, 1. Dezember 2003 11:21, Angus Leeming wrote:
>> The patch has the timout returning after 400ms. Could you modify
>> the code to return after 200ms and see how that feels please.
>
> I would, but the patch is not applying anymore to cvs. I am at work
> now, and don't have the sources from yesterday.
>
> - From what I remember, even the 400 ms was fast ...
> I just managed to follow the selections, so I was not unhappy with
> that value.
Try 3, Kornel.
This one should feel much smoother when you move the mouse back into
the work area. In fact, I thnk that this is ready to go into the
sources (and, indeed, be ported to 1.3.x) but I'd value it if you
road-tested it for me one more time.
--
AngusIndex: src/frontends/qt2/QContentPane.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QContentPane.C,v
retrieving revision 1.28
diff -u -p -r1.28 QContentPane.C
--- src/frontends/qt2/QContentPane.C 30 Nov 2003 18:26:41 - 1.28
+++ src/frontends/qt2/QContentPane.C 1 Dec 2003 21:44:09 -
@@ -10,6 +10,10 @@
#include
+#include "debug.h"
+
+#include
+
#include "QWorkArea.h"
#include "QContentPane.h"
#include "QLyXKeySym.h"
@@ -18,9 +22,6 @@
#include
#include
-#include "funcrequest.h"
-
-
namespace {
/// return the LyX key state from Qt's
@@ -74,10 +75,20 @@ mouse_button::state q_motion_state(Qt::B
} // namespace anon
+SyntheticMouseEvent::SyntheticMouseEvent()
+ : timeout(400), restart_timeout(true),
+ x_old(-1), y_old(-1), scrollbar_value_old(-1.0)
+{}
+
+
QContentPane::QContentPane(QWorkArea * parent)
: QWidget(parent, "content_pane", WRepaintNoErase),
track_scrollbar_(true), wa_(parent)
{
+ synthetic_mouse_event_.timeout.timeout.connect(
+ boost::bind(&QContentPane::generateSyntheticMouseEvent,
+ this));
+
setFocusPolicy(QWidget::WheelFocus);
setFocus();
setCursor(ibeamCursor);
@@ -85,7 +96,26 @@ QContentPane::QContentPane(QWorkArea * p
// stupid moc strikes again
connect(wa_->scrollbar_, SIGNAL(valueChanged(int)),
this, SLOT(scrollBarChanged(int)));
+}
+
+void QContentPane::generateSyntheticMouseEvent()
+{
+ if (synthetic_mouse_event_.restart_timeout)
+ synthetic_mouse_event_.timeout.start();
+
+ // Has anything changed on-screen since the last timeout signal
+ // was received?
+ double const scrollbar_value = wa_->scrollbar_->value();
+ if (scrollbar_value != synthetic_mouse_event_.scrollbar_value_old) {
+ // Yes it has. Store the params used to check this.
+ synthetic_mouse_event_.scrollbar_value_old = scrollbar_value;
+
+ // ... and dispatch the event to the LyX core.
+ lyxerr << "dispatching from generate_synthetic_mouse_event()"
+ << std::endl;
+ wa_->dispatch(synthetic_mouse_event_.cmd);
+ }
}
@@ -107,6 +137,9 @@ void QContentPane::mousePressEvent(QMous
return;
}
+ if (synthetic_mouse_event_.timeout.running())
+ synthetic_mouse_event_.timeout.stop();
+
FuncRequest cmd(LFUN_MOUSE_PRESS, e->x(), e->y(),
q_button_state(e->button()));
wa_->dispatch(cmd);
@@ -115,6 +148,9 @@ void QContentPane::mousePressEvent(QMous
void QContentPane::mouseReleaseEvent(QMouseEvent * e)
{
+ if (synthetic_mouse_event_.timeout.running())
+ synthetic_mouse_event_.timeout.stop();
+
FuncRequest cmd(LFUN_MOUSE_RELEASE, e->x(), e->y(),
q_button_state(e->button()));
wa_->dispatch(cmd);
@@ -123,9 +159,57 @@ void QContentPane::mouseReleaseEvent(QMo
void QContentPane::mouseMoveEvent(QMouseEvent * e)
{
- FuncRequest cmd
- (LFUN_MOUSE_MOTION, e->x(), e->y(), q_motion_state(e->state()));
- wa_->dispatch(cmd);
+ int const dx = e->x() - x();
+ int const dy = e->y() - y();
+
+ FuncRequest const
+ cmd(LFUN_MOUSE_MOTION, dx, dy, q_motion_state(e->state()));
+
+ bool const above_or_below_workarea = dy <= 0 || dy >= height();
+
+ if (above_or_below_workarea) {
+ lyxerr << "Above/below work area." << std::endl;
+ // Store the 'psuedo' event and start the timeout
+ // if it isn't already running.
+ synthetic_mouse_event_.cmd = cmd;
+
+ if (synthetic_mouse_event_.timeout.running())
+ // Discard event.
+ // Wait for the timeout to return and handle the
+ // (updated) FuncRequest.
+ return;
+ else {
+ synthetic_mouse_event_.restart_timeout = true;
+ synthetic_mouse_event_.timeout.start();
+ // Fall through...
+ }
+
+ } else if (synthetic_mouse_event_.timeout.running()) {
+ lyxerr << "About to return control to mouseMoveEvent proper"
+ << std::endl;
+ // Discard event.
+ // Wait for the timeout to return, handle one last
+ // 'pseudo' event and then proceed 'as normal'.
+ synthetic_mouse_event_.restart_timeout = false;
+ return;
+ }
+
+ // Has anything changed on-screen since the last QMouseEvent
+ // was received?
+ double const scrollbar_value = wa_->scrollbar_->value();
+ if (e->x() != synthetic_mouse_event_.x_old ||
+ e->y() != synthetic_mouse_event_.y_old ||
+ scrollbar_value !=
Re: [PATCH] Various small stuff
Michael Schmitt wrote: > I think you missed some parts of my patch. Please have a look at the > attached file. Cheers, Michael. Applied. -- Angus
Re: [PATCH] chess.layout
Michael Schmitt wrote: > I think this patch got lost. Cheers, Michael. Applied. -- Angus
Re: A working InsetVSpace
Georg Baum wrote:
>> Sounds like the inset scheme is still a bit too complex if copy &
>> paste introduces errors... Why is an inset supposed to read the
>> \end_inset token? Isn't that 'data belonging to a level above'?
>
> I would think so. But nevertheless, adding something like the
> following in InsetVSpace::read() (stolen from insettext.C)
>
> + if (lex.isOK())
> + lex.next();
> + if (lex.getString() != "\\end_inset") {
> + lex.printError("Missing \\end_inset at this point. "
> +"Read: `$$Token'");
> + }
>
> makes it work.
Cheers, Georg. Applied, although I suspect that someone will now try
and factorize all these pieces of code handling 'end_inset'...
--
Angus
[PATCH] chess.layout
Hello, I think this patch got lost. Thanks for applying it. Michael Index: lyx-devel-1.4.0cvs/lib/ChangeLog === RCS file: /cvs/lyx/lyx-devel/lib/ChangeLog,v retrieving revision 1.545 diff -u -r1.545 ChangeLog --- lyx-devel-1.4.0cvs/lib/ChangeLog2003/11/28 17:38:37 1.545 +++ lyx-devel-1.4.0cvs/lib/ChangeLog2003/12/01 18:07:01 @@ -1,3 +1,7 @@ +2003-11-28 Michael Schmitt <[EMAIL PROTECTED]> + + * layouts/chess.layout: Remove blanks in style name + 2003-11-28 Angus Leeming <[EMAIL PROTECTED]> * ui/stdmenus.ui: add Insert VSpace. Index: lyx-devel-1.4.0cvs/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 --- lyx-devel-1.4.0cvs/lib/layouts/chess.layout 2003/10/13 09:50:09 1.6 +++ lyx-devel-1.4.0cvs/lib/layouts/chess.layout 2003/12/01 18:07:03 @@ -81,7 +81,7 @@ # This is a subsubsubvariation. -Style SubVariation3 +Style SubVariation3 CopyStyle Variation LatexName lyxvariation[4] LabelString "Subvariation(3): "
Re: A working InsetVSpace
Am Montag, 1. Dezember 2003 14:10 schrieb Andre Poenitz:
> Sounds like the inset scheme is still a bit too complex if copy & paste
> introduces errors... Why is an inset supposed to read the \end_inset
> token? Isn't that 'data belonging to a level above'?
I would think so. But nevertheless, adding something like the following in
InsetVSpace::read() (stolen from insettext.C)
+ if (lex.isOK())
+ lex.next();
+ if (lex.getString() != "\\end_inset") {
+ lex.printError("Missing \\end_inset at this point. "
+ "Read: `$$Token'");
+ }
makes it work.
Georg
[PATCH] Various small stuff
Hi Juergen,
I think you missed some parts of my patch. Please have a look at the
attached file.
Michael
Index: lyx-devel-1.4.0cvs/src/frontends/qt2/QVSpace.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/QVSpace.C,v
retrieving revision 1.4
diff -u -r1.4 QVSpace.C
--- lyx-devel-1.4.0cvs/src/frontends/qt2/QVSpace.C 2003/12/01 14:16:26 1.4
+++ lyx-devel-1.4.0cvs/src/frontends/qt2/QVSpace.C 2003/12/01 18:07:08
@@ -93,7 +93,7 @@
LengthCombo * unit,
bool keep)
{
- VSpace space = VSpace(VSpace::DEFSKIP);
+ VSpace space;
switch (spacing) {
case 0:
@@ -157,7 +157,7 @@
// spacing
// If a vspace choice is "Length" but there's no text in
// the input field, do not insert a vspace at all.
- if (dialog_->spacingCO->currentItem() == 6
+ if (dialog_->spacingCO->currentItem() == 5
&& dialog_->valueLE->text().isEmpty())
return;
Index: lyx-devel-1.4.0cvs/src/frontends/xforms/FormVSpace.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/xforms/FormVSpace.C,v
retrieving revision 1.4
diff -u -r1.4 FormVSpace.C
--- lyx-devel-1.4.0cvs/src/frontends/xforms/FormVSpace.C2003/12/01 14:16:27
1.4
+++ lyx-devel-1.4.0cvs/src/frontends/xforms/FormVSpace.C2003/12/01 18:07:24
@@ -75,7 +75,7 @@
input_length && input_length->objclass == FL_INPUT &&
choice_length && choice_length->objclass == FL_CHOICE);
- VSpace space = VSpace(VSpace::DEFSKIP);
+ VSpace space;
switch (fl_get_choice(choice_type)) {
case 1:
Re: [patch] fix for inlied ERT
On Mon, Dec 01, 2003 at 07:01:25PM +0100, Andre Poenitz spake thusly: > > I moved the inline stuff from InsetERT to InsetCollapsable. More general > and saves 60 lines. > > Andre' - void InsetERTMailer::string2params(string const & in, - InsetERT::ERTStatus & status) + InsetCollapsable::InsetCollapsable::CollapseStatus & status) - Huh? Surely there's a jumble here. Great job otherwise. I was vaguely planning something like this, but you beat me to it. - @@ -1620,7 +1624,7 @@ void LyXText::metrics(MetricsInfo & mi, // final dimension dim.asc = firstRow()->ascent_of_text(); dim.des = height - dim.asc; - dim.wid = std::max(mi.base.textwidth, int(width)); + dim.wid = width; } - Does this now mean that LyXText returns proper widths again? In that case I'll have to have a look at inlined CharStyles again ;-) - Martin pgp0.pgp Description: PGP signature
Re: feature request
On Mon, Dec 01, 2003 at 02:21:58PM -0500, Kuba Ober wrote: > In any case, don't ignore John I don't think André gets the poportunity to do that, much as he'd like to sometimes :) john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: feature request
On Friday 28 November 2003 11:39 am, 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.) > > > 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. In any case, don't ignore John, he's trying to do a good design job! It's nice to see that way of thinking! He's very correct in that a user's request may say indicate a deeper underlying design problem, a more general solution being in order, and a thousand of other things. Quite often user requests need serious rephrasing before they get implemented, while still giving the user what he/she needs. John's approach is quite pragmatic and I like it. Not that I have much to say here, but if an outsider's opinion is worth a cent, here it is :) Cheers, Kuba Ober
Re: LyX 1.4 task list
Jean-Marc Lasgouttes wrote:
> Andre> Relying on extensions to determine the file type is not very
> Andre> robust. I could e.g. imagine that the mapping extension ->
> Andre> application is not 1:1.
>
> We have some code to guess type by contents already.
>
> Andre> However, from an UI point of view it might even make sense
> ("Do Andre> something sensible"). But I am not sure I like it more
> than an Andre> extra level of menu items
>
> What we could do is have
>
> - a text field for the file name, with a browse button
>
> - a combox (less clutter that a list like we have now) with the list
> of types (== templates), which is set initially to 'auto' (or
> 'default'). The user can choose to override the template guessed
> by the dialog.
I think that we're getting ahead of ourselves. This is the
UI-equivalent of syntatic sugar. Worse, we're sweetening an interface
that isn't used yet by the vast majority of our users.
Let me finish the all singing, all dancing inset I have been promising
you and then we can discuss this.
--
Angus
Re: LyX 1.4 task list
Andre Poenitz wrote: > We basically have a choice of making what we have now workable and > create some fragile glue code (which should be better than we had > before, but...) or tame that beast for good. > I am opting for the latter right now as this minimizes total effort > in the long run. You have my vote too. Which reminds me: I like the mathed approach to tables ;-) -- Angus
Re: LyX 1.4 task list
Andre Poenitz wrote: >> Asger proposed a solution to this. Each dialog could save its >> 'stateful' variables in files preferences.xforms, preferences.qt >> etc > But that's pretty complicated for the dialog author unless this is > done somehow automatically. Oh, I'm sure we could automate it, just as we have automated checking that the input string is a valid gluelength etc, enabling/disabling the 'Apply','Ok' buttons as appropriate: addCheckedGlueLength(bcview(), dialog_->input_space, dialog_->input_space); I'd imagine syntax like recorder().add(dialog_->choice_template); in FormExternal::build, together with recorder().getStates(); in FormExternal::update() and recorder().setStates(); in FormExternal::apply(). Presumably, recorder() would be the 'FormExternal' view on a singleton XformsRecordState class that actually read from and wrote to preferences.xforms. Pretty trivial really. -- Angus
[patch] fix for inlied ERT
I moved the inline stuff from InsetERT to InsetCollapsable. More general
and saves 60 lines.
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: factory.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/factory.C,v
retrieving revision 1.73
diff -u -p -r1.73 factory.C
--- factory.C 28 Nov 2003 15:53:23 - 1.73
+++ factory.C 1 Dec 2003 17:55:17 -
@@ -231,9 +231,9 @@ InsetOld * createInset(FuncRequest const
return new InsetCitation(icp);
} else if (name == "ert") {
- InsetERT::ERTStatus s;
- InsetERTMailer::string2params(cmd.argument, s);
- return new InsetERT(params, s);
+ InsetCollapsable::CollapseStatus st;
+ InsetERTMailer::string2params(cmd.argument, st);
+ return new InsetERT(params, st);
} else if (name == "external") {
Buffer const & buffer = *cmd.view()->buffer();
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.504
diff -u -p -r1.504 text.C
--- text.C 1 Dec 2003 13:35:41 - 1.504
+++ text.C 1 Dec 2003 17:55:17 -
@@ -282,6 +282,7 @@ int LyXText::leftMargin(ParagraphList::i
break;
case MARGIN_RIGHT_ADDRESS_BOX: {
+#if 0
// ok, a terrible hack. The left margin depends on the widest
// row in this paragraph.
RowList::iterator rit = pit->rows.begin();
@@ -294,6 +295,9 @@ int LyXText::leftMargin(ParagraphList::i
x += font_metrics::signedWidth(layout->leftmargin,
tclass.defaultfont());
x += minfill;
+#endif
+ // also wrong, but much shorter.
+ x += textwidth_ / 2;
break;
}
}
@@ -1620,7 +1624,7 @@ void LyXText::metrics(MetricsInfo & mi,
// final dimension
dim.asc = firstRow()->ascent_of_text();
dim.des = height - dim.asc;
- dim.wid = std::max(mi.base.textwidth, int(width));
+ dim.wid = width;
}
Index: frontends/controllers/ControlERT.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlERT.h,v
retrieving revision 1.11
diff -u -p -r1.11 ControlERT.h
--- frontends/controllers/ControlERT.h 6 Oct 2003 15:42:45 - 1.11
+++ frontends/controllers/ControlERT.h 1 Dec 2003 17:55:17 -
@@ -23,9 +23,9 @@ public:
///
ControlERT(Dialog &);
///
- InsetERT::ERTStatus status() const { return status_; }
+ InsetCollapsable::CollapseStatus status() const { return status_; }
///
- void setStatus(InsetERT::ERTStatus status) { status_ = status; }
+ void setStatus(InsetCollapsable::CollapseStatus status) { status_ = status; }
///
virtual bool initialiseParams(std::string const & data);
/// clean-up on hide.
@@ -36,7 +36,7 @@ public:
virtual bool isBufferDependent() const { return true; }
private:
///
- InsetERT::ERTStatus status_;
+ InsetCollapsable::CollapseStatus status_;
};
#endif
Index: insets/inset.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/inset.h,v
retrieving revision 1.147
diff -u -p -r1.147 inset.h
--- insets/inset.h 1 Dec 2003 13:35:45 - 1.147
+++ insets/inset.h 1 Dec 2003 17:55:17 -
@@ -237,7 +237,7 @@ public:
/// open the inset
virtual void open() {}
/// close the inset
- virtual void close() const {}
+ virtual void close() {}
// should this inset be handled like a normal charater
virtual bool isChar() const { return false; }
// is this equivalent to a letter?
Index: insets/insetcollapsable.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/insets/insetcollapsable.C,v
retrieving revision 1.218
diff -u -p -r1.218 insetcollapsable.C
--- insets/insetcollapsable.C 1 Dec 2003 14:51:51 - 1.218
+++ insets/insetcollapsable.C 1 Dec 2003 17:55:17 -
@@ -40,7 +40,8 @@ using std::ostream;
InsetCollapsable::InsetCollapsable(BufferParams const & bp, bool collapsed)
- : UpdatableInset(), inset(bp), collapsed_(collapsed), label("Label")
+ : UpdatableInset(), inset(bp), status_(collapsed ? Collapsed : Open),
+ label("Label")
#if 0
,autocollapse(false)
#endif
@@ -54,7 +55,7 @@ InsetCollapsable::InsetCollapsable(Buffe
InsetCollapsable::InsetCollapsable(InsetCollaps
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 05:59:33PM +0100, Michael Schmitt wrote: > John Levon wrote: > > >This is actually 99% of the work. I hope people are beginning to see > >what a massive task this actually is now ... just getting tables back up > >and running will probably take *weeks* (sadly, I don't think I'm > >exaggerating). > > And I also hope people are beginning to see that _every_ new feature and > _every_ code change introduces new bugs. That's why we should have a > feature freeze very soon. I see that and I also see that I am the main source of new bugs right now. However, I think that most of the things will be easily fixable as soon as the core is in a stable condition. And I see this time approaching. We basically have a choice of making what we have now workable and create some fragile glue code (which should be better than we had before, but...) or tame that beast for good. I am opting for the latter right now as this minimizes total effort in the long run. Andre'
Re: LyX 1.4 task list
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Relying on extensions to determine the file type is not very
Andre> robust. I could e.g. imagine that the mapping extension ->
Andre> application is not 1:1.
We have some code to guess type by contents already.
Andre> However, from an UI point of view it might even make sense ("Do
Andre> something sensible"). But I am not sure I like it more than an
Andre> extra level of menu items
What we could do is have
- a text field for the file name, with a browse button
- a combox (less clutter that a list like we have now) with the list
of types (== templates), which is set initially to 'auto' (or
'default'). The user can choose to override the template guessed by
the dialog.
JMarc
Re: LyX 1.4 task list
John Levon wrote: This is actually 99% of the work. I hope people are beginning to see what a massive task this actually is now ... just getting tables back up and running will probably take *weeks* (sadly, I don't think I'm exaggerating). And I also hope people are beginning to see that _every_ new feature and _every_ code change introduces new bugs. That's why we should have a feature freeze very soon. (OTOH I would like to stress that I really appreciate what Andre, Alfredo, Martin, and all others have achieved so far!) Michael
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 05:53:37PM +0100, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> As always, life is a little complicated. The only reason to
> Angus> have two dialogs is to 1. Get rid of that combox (XFig, Raster,
> Angus> Chess, Date) etc when we know that we want to insert a graphic.
>
> Angus> However, XFig, Raster, VectorGraphic, Tgif, Dia, ... are all
> Angus> 'graphic' formats that may or may not produce different latex
> Angus> output.
>
> So we could have a simple 'insert object', where the external template
> is chosen based on the file type (or extension). The idea is that, if
> one inserts a xfig or eps file, it should not be necessary to choose a
> template, just give the file name.
Relying on extensions to determine the file type is not very robust.
I could e.g. imagine that the mapping extension -> application is not
1:1.
However, from an UI point of view it might even make sense ("Do
something sensible"). But I am not sure I like it more than an extra
level of menu items
Andre'
Re: LyX 1.4 task list
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> As always, life is a little complicated. The only reason to Angus> have two dialogs is to 1. Get rid of that combox (XFig, Raster, Angus> Chess, Date) etc when we know that we want to insert a graphic. Angus> However, XFig, Raster, VectorGraphic, Tgif, Dia, ... are all Angus> 'graphic' formats that may or may not produce different latex Angus> output. So we could have a simple 'insert object', where the external template is chosen based on the file type (or extension). The idea is that, if one inserts a xfig or eps file, it should not be necessary to choose a template, just give the file name. This means that most of the objects supported by the external inset can be used with the interface of Insert>Graphics. Of course, there are external templates which are not related to a file, but these ones should maybe be moved to somewhere else. Does this make sense? JMarc
Re: The current char style UI
On Mon, Dec 01, 2003 at 04:03:57PM +, Angus Leeming wrote: > Andre Poenitz wrote: > > > On Mon, Dec 01, 2003 at 03:34:35PM +, John Levon wrote: > >> On Mon, Dec 01, 2003 at 03:21:23PM +, Angus Leeming wrote: > >> > >> > > Easy peasy ! > >> > > >> > and if the inset is drawn over two or more lines, does each row > >> > have a '|--- noun -|' centered underneath that chunk > >> > of inset? > >> > >> No. > >> > >> OK, maybe, but it's easier if it's not. And you could easily do : > >> > >> | mkl dlmwqd klmwldk mwqdklm wq | > >> | mdkmelfmewkflmew fklmew lfkme | > >> |-- noun ---| > >> > >> which is even quite clear > > > > But this doesn't fit nicely into the three-boxes drawing model... > > Does my original suggestion of the 'style' under each row fit? I > haven't looked at InsetText for ages. Does it draw its own contents > and split this content onto separate rows? That's done in LyXText. The paramaters for the drawing of LyXText could be manipulated by the containing InsetText. > If so, adding a 'std::string style_label' variable to InsetText and > passing this to the painter for each line would work, no? This could be made working, but I'd think having 5 of these guys nested results in totally incomprehensible screen clutter. Andre'
Re: [Patch] Re: box dialog, xforms
On Mon, Dec 01, 2003 at 04:00:21PM +, Angus Leeming spake thusly: > Martin Vermeer wrote: > > > On Mon, Dec 01, 2003 at 01:35:20PM +, John Levon spake thusly: > > > >> > >> The parbox/minipage radio set does not behave as a radio set. > >> > >> regards > >> john > > > > Thanks. > > > > The attached works by brute force; if only I understood why it is > > necessary at all. It isn't for any of the other radio button pairs I > > looked at in other dialogs. > > > > Shall I apply this, or does anyone have a deeper insight to offer? > > I suspect that the other dialogs have 'grouped' these buttons > together in fdesign... > > Maybe you might find Baruch Even's RadioButtonGroup class useful > here. Dunno. See, eg, FormGraphics for an example of its use. (This > may be bogus choice, I can't remember if FormGraphics still uses it > ;-) > > -- > Angus That was the secret. Thanks. The correct patch attached. I'll commit presently. - Martin Index: form_box.fd === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/forms/form_box.fd,v retrieving revision 1.2 diff -u -p -r1.2 form_box.fd --- form_box.fd 28 Nov 2003 19:17:34 - 1.2 +++ form_box.fd 1 Dec 2003 16:18:10 - @@ -11,7 +11,7 @@ SnapGrid: 7 Name: form_box Width: 442 Height: 379 -Number of Objects: 19 +Number of Objects: 21 class: FL_BOX @@ -32,6 +32,24 @@ callback: argument: +class: FL_FRAME +type: ENGRAVED_FRAME +box: 14 112 112 63 +boxtype: FL_NO_BOX +colors: FL_BLACK FL_COL1 +alignment: FL_ALIGN_CENTER +style: FL_NORMAL_STYLE +size: FL_DEFAULT_SIZE +lcol: FL_BLACK +label: +shortcut: +resize: FL_RESIZE_ALL +gravity: FL_NoGravity FL_NoGravity +name: +callback: +argument: + + class: FL_CHOICE type: NORMAL_CHOICE box: 175 21 231 28 @@ -194,60 +212,6 @@ callback: C_FormDialogView_InputCB argument: 0 -class: FL_ROUND3DBUTTON -type: RADIO_BUTTON -box: 21 112 35 28 -boxtype: FL_NO_BOX -colors: FL_COL1 FL_YELLOW -alignment: FL_ALIGN_CENTER -style: FL_NORMAL_STYLE -size: FL_NORMAL_SIZE -lcol: FL_BLACK -label: Parbox -shortcut: -resize: FL_RESIZE_ALL -gravity: FL_NoGravity FL_NoGravity -name: radio_parbox -callback: C_FormDialogView_InputCB -argument: 0 - - -class: FL_ROUND3DBUTTON -type: RADIO_BUTTON -box: 21 140 35 28 -boxtype: FL_NO_BOX -colors: FL_COL1 FL_YELLOW -alignment: FL_ALIGN_CENTER -style: FL_NORMAL_STYLE -size: FL_NORMAL_SIZE -lcol: FL_BLACK -label: Minipage -shortcut: -resize: FL_RESIZE_ALL -gravity: FL_NoGravity FL_NoGravity -name: radio_minipage -callback: C_FormDialogView_InputCB -argument: 0 - - -class: FL_FRAME -type: ENGRAVED_FRAME -box: 14 112 112 63 -boxtype: FL_NO_BOX -colors: FL_BLACK FL_COL1 -alignment: FL_ALIGN_CENTER -style: FL_NORMAL_STYLE -size: FL_DEFAULT_SIZE -lcol: FL_BLACK -label: -shortcut: -resize: FL_RESIZE_ALL -gravity: FL_NoGravity FL_NoGravity -name: -callback: -argument: - - class: FL_CHOICE type: NORMAL_CHOICE2 box: 315 112 91 28 @@ -354,6 +318,78 @@ gravity: FL_NoGravity FL_NoGravity name: button_defaults callback: C_FormDialogView_InputCB argument: 0 + + +class: FL_BEGIN_GROUP +type: 0 +box: 0 0 0 0 +boxtype: FL_NO_BOX +colors: FL_COL1 FL_MCOL +alignment: FL_ALIGN_CENTER +style: FL_NORMAL_STYLE +size: FL_DEFAULT_SIZE +lcol: FL_BLACK +label: +shortcut: +resize: FL_RESIZE_ALL +gravity: FL_NoGravity FL_NoGravity +name: noname +callback: +argument: + + +class: FL_ROUND3DBUTTON +type: RADIO_BUTTON +box: 21 112 35 28 +boxtype: FL_NO_BOX +colors: FL_COL1 FL_YELLOW +alignment: FL_ALIGN_CENTER +style: FL_NORMAL_STYLE +size: FL_NORMAL_SIZE +lcol: FL_BLACK +label: Parbox +shortcut: +resize: FL_RESIZE_ALL +gravity: FL_NoGravity FL_NoGravity +name: radio_parbox +callback: C_FormDialogView_InputCB +argument: 0 + + +class: FL_ROUND3DBUTTON +type: RADIO_BUTTON +box: 21 140 35 28 +boxtype: FL_NO_BOX +colors: FL_COL1 FL_YELLOW +alignment: FL_ALIGN_CENTER +style: FL_NORMAL_STYLE +size: FL_NORMAL_SIZE +lcol: FL_BLACK +label: Minipage +shortcut: +resize: FL_RESIZE_ALL +gravity: FL_NoGravity FL_NoGravity +name: radio_minipage +callback: C_FormDialogView_InputCB +argument: 0 + + +class: FL_END_GROUP +type: 0 +box: 0 0 0 0 +boxtype: FL_NO_BOX +colors: FL_COL1 FL_MCOL +alignment: FL_ALIGN_CENTER +style: FL_NORMAL_STYLE +size: FL_DEFAULT_SIZE +lcol: FL_BLACK +label: +shortcut: +resize: FL_RESIZE_ALL +gravity: FL_NoGravity FL_NoGravity +name: +callback: +argument: == create_the_forms pgp0.pgp Description: PGP signature
Re: The current char style UI
Andre Poenitz wrote: > On Mon, Dec 01, 2003 at 03:34:35PM +, John Levon wrote: >> On Mon, Dec 01, 2003 at 03:21:23PM +, Angus Leeming wrote: >> >> > > Easy peasy ! >> > >> > and if the inset is drawn over two or more lines, does each row >> > have a '|--- noun -|' centered underneath that chunk >> > of inset? >> >> No. >> >> OK, maybe, but it's easier if it's not. And you could easily do : >> >> | mkl dlmwqd klmwldk mwqdklm wq | >> | mdkmelfmewkflmew fklmew lfkme | >> |-- noun ---| >> >> which is even quite clear > > But this doesn't fit nicely into the three-boxes drawing model... Does my original suggestion of the 'style' under each row fit? I haven't looked at InsetText for ages. Does it draw its own contents and split this content onto separate rows? If so, adding a 'std::string style_label' variable to InsetText and passing this to the painter for each line would work, no? -- Angus
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 03:52:50PM +, Angus Leeming wrote: > John Levon wrote: > > > On Mon, Dec 01, 2003 at 04:29:23PM +0100, Andre Poenitz wrote: > > > >> > So, the need for the combox remains even for 'graphic' files, > >> > unless we 'pollute' the calling menu Insert->XFig, Insert->Raster > >> > etc. > >> > >> I even like this idea. I'd rather access something in the menu > >> hierarchy instead of some dialog which tends to forget my > >> preferences after restart. > > Asger proposed a solution to this. Each dialog could save its > 'stateful' variables in files preferences.xforms, preferences.qt etc But that's pretty complicated for the dialog author unless this is done somehow automatically. A menu entry, OTOH is pretty simple to add and remove or shift nowadays. Andre'
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 03:52:50PM +, Angus Leeming wrote: > Indeed. Isn't the current, 1.4.x heirarchy something like: > Insert->XYZ->External Material > where I forget XYZ, leading to > Insert->XYZ->XFig, etc. > > Of course, we might have a separate 'External' sub menu > Insert->External->Latex File > Insert->External->Vector graphic file > Insert->External->Bitmap graphic file > Insert->External->Xfig file > Insert->External->Tgif file > Insert->External->Dia file Well, this would equally well be Insert->File->, which is where External Material is already. So Insert->External_File or something. There is really no great solution available, we will have to suffer reasonable compromises. *shrug* regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [Patch] Class Header
On Sat, Nov 29, 2003 at 02:31:24PM +0200, Martin Vermeer spake thusly: > > Here is the patch for 'latexparam' in CharStyle, to make this kind of thing > possible. > > OK to commit this? > > - Martin Done. - Martin pgp0.pgp Description: PGP signature
Re: [Patch] Re: box dialog, xforms
Martin Vermeer wrote: > On Mon, Dec 01, 2003 at 01:35:20PM +, John Levon spake thusly: > >> >> The parbox/minipage radio set does not behave as a radio set. >> >> regards >> john > > Thanks. > > The attached works by brute force; if only I understood why it is > necessary at all. It isn't for any of the other radio button pairs I > looked at in other dialogs. > > Shall I apply this, or does anyone have a deeper insight to offer? I suspect that the other dialogs have 'grouped' these buttons together in fdesign... Maybe you might find Baruch Even's RadioButtonGroup class useful here. Dunno. See, eg, FormGraphics for an example of its use. (This may be bogus choice, I can't remember if FormGraphics still uses it ;-) -- Angus
[Patch] Re: box dialog, xforms
On Mon, Dec 01, 2003 at 01:35:20PM +, John Levon spake thusly:
>
> The parbox/minipage radio set does not behave as a radio set.
>
> regards
> john
Thanks.
The attached works by brute force; if only I understood why it is
necessary at all. It isn't for any of the other radio button pairs I
looked at in other dialogs.
Shall I apply this, or does anyone have a deeper insight to offer?
- Martin
Index: FormBox.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormBox.C,v
retrieving revision 1.3
diff -u -p -r1.3 FormBox.C
--- FormBox.C 28 Nov 2003 19:17:34 - 1.3
+++ FormBox.C 1 Dec 2003 15:47:28 -
@@ -206,6 +206,7 @@ void FormBox::apply()
controller().params().height_special = ids_spec_[i - 1];
}
+
ButtonPolicy::SMInput FormBox::input(FL_OBJECT * ob, long)
{
if (ob == dialog_->check_inner_box) {
@@ -276,11 +277,22 @@ ButtonPolicy::SMInput FormBox::input(FL_
if (ob == dialog_->button_defaults) {
fl_set_button(dialog_->check_inner_box, true);
fl_set_button(dialog_->radio_parbox, false);
+ fl_set_button(dialog_->radio_minipage, true);
fl_set_input(dialog_->input_width, "100");
fl_set_choice(dialog_->choice_width_unit, LyXLength::PCW + 1);
fl_set_choice(dialog_->choice_special, NONE);
fl_set_input(dialog_->input_height, "1");
fl_set_choice(dialog_->choice_height_special, TOTALHEIGHT);
+ }
+
+ if (ob == dialog_->radio_parbox) {
+ fl_set_button(dialog_->radio_parbox, true);
+ fl_set_button(dialog_->radio_minipage, false);
+ }
+
+ if (ob == dialog_->radio_minipage) {
+ fl_set_button(dialog_->radio_parbox, false);
+ fl_set_button(dialog_->radio_minipage, true);
}
return ButtonPolicy::SMI_VALID;
pgp0.pgp
Description: PGP signature
Re: LyX 1.4 task list
John Levon wrote: > On Mon, Dec 01, 2003 at 04:29:23PM +0100, Andre Poenitz wrote: > >> > So, the need for the combox remains even for 'graphic' files, >> > unless we 'pollute' the calling menu Insert->XFig, Insert->Raster >> > etc. >> >> I even like this idea. I'd rather access something in the menu >> hierarchy instead of some dialog which tends to forget my >> preferences after restart. Asger proposed a solution to this. Each dialog could save its 'stateful' variables in files preferences.xforms, preferences.qt etc > The Insert menu is already creaking under the weight of all the > stuff in it. And no, I don't have a good solution :( Indeed. Isn't the current, 1.4.x heirarchy something like: Insert->XYZ->External Material where I forget XYZ, leading to Insert->XYZ->XFig, etc. Of course, we might have a separate 'External' sub menu Insert->External->Latex File Insert->External->Vector graphic file Insert->External->Bitmap graphic file Insert->External->Xfig file Insert->External->Tgif file Insert->External->Dia file At least these might have bindable shortcuts, but I agree that the menus are creaking somewhat. Anyway, I'll try and add transforms to the External dialogs first. Thereafter, if you personally want to scrap use of InsetGraphic, then there's one less thing stoping you from doing so. -- Angus
Re: The current char style UI
On Mon, Dec 01, 2003 at 03:34:35PM +, John Levon wrote: > On Mon, Dec 01, 2003 at 03:21:23PM +, Angus Leeming wrote: > > > > Easy peasy ! > > > > and if the inset is drawn over two or more lines, does each row have > > a '|--- noun -|' centered underneath that chunk of inset? > > No. > > OK, maybe, but it's easier if it's not. And you could easily do : > > | mkl dlmwqd klmwldk mwqdklm wq | > | mdkmelfmewkflmew fklmew lfkme | > |-- noun ---| > > which is even quite clear But this doesn't fit nicely into the three-boxes drawing model... Andre'
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 04:29:23PM +0100, Andre Poenitz wrote: > > So, the need for the combox remains even for 'graphic' files, unless > > we 'pollute' the calling menu Insert->XFig, Insert->Raster etc. > > I even like this idea. I'd rather access something in the menu > hierarchy instead of some dialog which tends to forget my preferences > after restart. The Insert menu is already creaking under the weight of all the stuff in it. And no, I don't have a good solution :( regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The current char style UI
On Mon, Dec 01, 2003 at 03:21:23PM +, Angus Leeming wrote: > > Easy peasy ! > > and if the inset is drawn over two or more lines, does each row have > a '|--- noun -|' centered underneath that chunk of inset? No. OK, maybe, but it's easier if it's not. And you could easily do : | mkl dlmwqd klmwldk mwqdklm wq | | mdkmelfmewkflmew fklmew lfkme | |-- noun ---| which is even quite clear regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 03:16:33PM +, Angus Leeming wrote: > So, the need for the combox remains even for 'graphic' files, unless > we 'pollute' the calling menu Insert->XFig, Insert->Raster etc. I even like this idea. I'd rather access something in the menu hierarchy instead of some dialog which tends to forget my preferences after restart. Andre'
Re: The current char style UI
John Levon wrote: > On Mon, Dec 01, 2003 at 02:51:40PM +0100, Juergen Spitzmueller > wrote: > >> > Would you feel like coding it up? I can assure you it's well >> > beyond my ability right now. >> >> No, I don't feel like coding it up (it's well beyond my ability >> too). And I > > Come come guys, of course it's not beyond either of you. All you > need is an inset that adds to its natural height space for the > "underline" bit. Set it to be w/o a frame (assuming that still > works), and draw your underline bit on top. > > Easy peasy ! and if the inset is drawn over two or more lines, does each row have a '|--- noun -|' centered underneath that chunk of inset? -- Angus
Re: LyX 1.4 task list
Jean-Marc Lasgouttes wrote: > Angus> Actually, what you said is that having a single > Angus> inset that was able to handle any 'external' data > Angus> (ie InsetExternal) would result in a UI something > Angus> like that of PowerPoint where a single dialog > Angus> controls the input of many, conceptually > Angus> different, 'external's. > Ah yes! > Angus> Or something like that. > No, that was perfect, you manage to reproduce my thought with a > great fidelity :) > Angus> John's suggestion was to have the Graphics dialog > Angus> also connected to ControlExternal. Ie, two dialogs > Angus> resulting in the input/manipulation of a single Inset. > Right. > Angus> I can see the argument for, but I can also see the > Angus> argument against. I also think that this is a second > Angus> step. > It depends when we plan to do the second step. If it is in 1.5, then > people will have time to get pissed off :) As always, life is a little complicated. The only reason to have two dialogs is to 1. Get rid of that combox (XFig, Raster, Chess, Date) etc when we know that we want to insert a graphic. However, XFig, Raster, VectorGraphic, Tgif, Dia, ... are all 'graphic' formats that may or may not produce different latex output. Eg, \input or \includegraphics. Eg2 Raster images can be converted to png format for pdflatex whilst VectorGraphic should be converted to pdf. So, the need for the combox remains even for 'graphic' files, unless we 'pollute' the calling menu Insert->XFig, Insert->Raster etc. 2. Disable (rotate, scale, crop) transformations when the inset doesn't support them. But, once the combox choice has been made, we know which transformations are allowed as they are part of the ExternalTemplate definition. So, we can disable on-the-fly. Angus ... and before you ask, there is no VectorGraphic template, but it is probably the thing to have for PostScript/PDF images.
Re: The current char style UI
On Mon, Dec 01, 2003 at 05:20:20PM +0200, Martin Vermeer wrote: > > http://marc.theaimsgroup.com/?l=lyx-devel&m=104974730920332&w=2 > > Yes, it all comes back (fine write-up BTW). So basically we have that > now, except the user editable part, don't we? Only, it's an inset, not > a named combination of attributes that can be 'painted' to text. > > Personally I think it's OK to be an inset. If only it looked better. Well my opinion on implementation-level details (inset or not) resulting in the same UI is, I suspect, rather well known by now :) regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The current char style UI
On Mon, Dec 01, 2003 at 01:19:46PM +, John Levon spake thusly: > On Mon, Dec 01, 2003 at 03:23:42PM +0200, Martin Vermeer wrote: > > > Now I have to read that. Do you happen to have a link handy? > > http://marc.theaimsgroup.com/?l=lyx-devel&m=104974730920332&w=2 > > john Yes, it all comes back (fine write-up BTW). So basically we have that now, except the user editable part, don't we? Only, it's an inset, not a named combination of attributes that can be 'painted' to text. Personally I think it's OK to be an inset. If only it looked better. - Martin pgp0.pgp Description: PGP signature
Re: Remove stray "if" in src/frontends/xforms/Makefile.am
> "Rob" == Rob Lahaye <[EMAIL PROTECTED]> writes: Rob> Angus, Rob> Apologies for the person-to-person email, but my emails to the Rob> devel list seem to end up in /dev/null :(. I did it. JMarc
Re: Character styles changeover?
On Sat, Nov 29, 2003 at 10:20:33PM +0200, Martin Vermeer spake thusly: > On Thu, Nov 27, 2003 at 08:51:30PM +0200, Martin Vermeer spake thusly: > > > I did the 'button text' thing... > > Shall I check this in? (Note this doesn't exclude an inlined solution > later on, when inset widths work again.) > > > I think BTW that content-on-the-button would be a good solution also for > > Branch insets... > > ... with this included. > > And the similar index button solution too. > > Anybody object to any or all of this? > > > - Martin Committed the part for CharStyle insets. - Martin pgp0.pgp Description: PGP signature
Re: Qt font handling and a mail from Andrew Abyzov, 01 Jun 2003
Andre Poenitz wrote: > On Mon, Dec 01, 2003 at 01:19:57PM +, Angus Leeming wrote: >> Did anything come of this? > > Nothing I am aware of, but I cant' read the attachment (is this base > 64?) mime type: message/rfc822 Use mimencode to manipulate it. -- Angus
Re: LyX 1.4 task list
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Actually, what you said is that having a single inset that was Angus> able to handle any 'external' data (ie InsetExternal) would Angus> result in a UI something like that of PowerPoint where a single Angus> dialog controls the input of many, conceptually different, Angus> 'external's. Ah yes! Angus> Or something like that. No, that was perfect, you manage to reproduce my thought with a great fidelity :) Angus> John's suggestion was to have the Graphics dialog also Angus> connected to ControlExternal. Ie, two dialogs resulting in the Angus> input/manipulation of a single Inset. Right. Angus> I can see the argument for, but I can also see the argument Angus> against. I also think that this is a second step. It depends when we plan to do the second step. If it is in 1.5, then people will have time to get pissed off :) JMarc
Re: The current char style UI
On Mon, Dec 01, 2003 at 02:51:40PM +0100, Juergen Spitzmueller wrote: > > Would you feel like coding it up? I can assure you it's well beyond my > > ability right now. > > No, I don't feel like coding it up (it's well beyond my ability too). And I Come come guys, of course it's not beyond either of you. All you need is an inset that adds to its natural height space for the "underline" bit. Set it to be w/o a frame (assuming that still works), and draw your underline bit on top. Easy peasy ! regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: LyX 1.4 task list
Jean-Marc Lasgouttes wrote: >> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> * I think that I would like to give the External inset > dialogs Angus> the ability to rotate, resize and crop their data. > This Angus> involves additions to qt/QExternal* and > xforms/FormExternal* Angus> only. > > Angus> That would make InsetExternal an almost-drop-in replacement > for Angus> InsetGraphics. (Wouldn't handle "subfigure".) Jean-Marc > stated Angus> that he thought that this would be the wrong way to go > but I'd Angus> like to try it out anyway. > > Did I say that? I remember not liking a rotate inset, but having > external insets being able to do that would be nice. Actually, I > thought you already did that :) It's in the inset but not in the dialog. (Coding up dialogs is a PITA.) Actually, what you said is that having a single inset that was able to handle any 'external' data (ie InsetExternal) would result in a UI something like that of PowerPoint where a single dialog controls the input of many, conceptually different, 'external's. Or something like that. John's suggestion was to have the Graphics dialog also connected to ControlExternal. Ie, two dialogs resulting in the input/manipulation of a single Inset. I can see the argument for, but I can also see the argument against. I also think that this is a second step. -- Angus
Re: The current char style UI
Martin Vermeer wrote: > Would you feel like coding it up? I can assure you it's well beyond my > ability right now. No, I don't feel like coding it up (it's well beyond my ability too). And I didn't say that you have to do it. And of course your efforts are a huge step into the right direction. But the thread is on how things might be improved, so I described how I (as a user) would like to have CharStyles. Regards, Jürgen.
Re: Right address is horked
On Mon, Dec 01, 2003 at 02:50:42PM +0100, Jean-Marc Lasgouttes wrote:
> > "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
>
> Andre> This would be some kind of solution, too, but I don't really
> Andre> like this kind of special casing in the core...
>
> Come on...
Hm. What about
Index: text.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/text.C,v
retrieving revision 1.504
diff -u -p -r1.504 text.C
--- text.C 1 Dec 2003 13:35:41 - 1.504
+++ text.C 1 Dec 2003 13:57:09 -
@@ -282,6 +282,7 @@ int LyXText::leftMargin(ParagraphList::i
break;
case MARGIN_RIGHT_ADDRESS_BOX: {
+#if 0
// ok, a terrible hack. The left margin depends on the widest
// row in this paragraph.
RowList::iterator rit = pit->rows.begin();
@@ -294,6 +295,8 @@ int LyXText::leftMargin(ParagraphList::i
x += font_metrics::signedWidth(layout->leftmargin,
tclass.defaultfont());
x += minfill;
+#endif
+ x += textwidth_ / 2;
break;
}
}
with the option to remove the #if 0 ... #endif stuff entirely?
Andre'
Re: LyX 1.4 task list
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> * I think that I would like to give the External inset dialogs Angus> the ability to rotate, resize and crop their data. This Angus> involves additions to qt/QExternal* and xforms/FormExternal* Angus> only. Angus> That would make InsetExternal an almost-drop-in replacement for Angus> InsetGraphics. (Wouldn't handle "subfigure".) Jean-Marc stated Angus> that he thought that this would be the wrong way to go but I'd Angus> like to try it out anyway. Did I say that? I remember not liking a rotate inset, but having external insets being able to do that would be nice. Actually, I thought you already did that :) JMarc
Re: Right address is horked
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> This would be some kind of solution, too, but I don't really Andre> like this kind of special casing in the core... Come on... JMarc
Re: The current char style UI
On Mon, Dec 01, 2003 at 08:49:49AM +0100, Juergen Spitzmueller spake thusly: > I think the > conglomerate-like solution (where the content description can be switched > off) would fit very much to LyX's philosophy and is user friendly. Would you feel like coding it up? I can assure you it's well beyond my ability right now. > But if I > understand Martin, the current solution is only interim anyway. Yes... until someone else builds something better ;-) > Regards, > Jürgen > > > regards > > john - Martin pgp0.pgp Description: PGP signature
Re: Qt font handling and a mail from Andrew Abyzov, 01 Jun 2003
On Mon, Dec 01, 2003 at 01:19:57PM +, Angus Leeming wrote: > Did anything come of this? Nothing I am aware of, but I cant' read the attachment (is this base 64?) 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: The current char style UI
On Mon, Dec 01, 2003 at 12:20:33PM +0100, Helge Hafting spake thusly: > > Of course code for deleting or "unapplying" an inset (e.g., backspace > > in pos 0, like in math) could be created as well. But what you will > > never be able to do in this paradigm is "unapplying" a charstyle for a > > piece in the middle of an applied charstyle, as you can do with > > physical attributes -- or more generally, creating arbitrary bit > > patterns of attributes. (But then I would argue "why would you want > > to?") > > Because people work that way? Eh, people also insert empty paragraphs and expect them to be there when they come back :-) > Example: > I paste two big quotes from other text into my document. Between them > is a "and" or something that isn't part of the quote. > > (Because of "blablablah" and "blablah" we see that . . .) > > I could mark each quote in turn and set them to some quote style. It might be > easier to mark everything and then unapply the "and" in the middle though. Not easier, same number of steps. Only easier if it is "the way we've always done it", which I don't really accept as an argument. I do realize that near all (other) word processors use the "independent character attribute bits" mental model, which works and is consistent but somewhat messy to implement. This however is the "text objects with properties" mental model, which is quite different, but I would claim just as easy to learn and more logical/realistic. Which is perhaps why LaTeX uses it. The only thing really that is wrong with the current representation of these objects as insets is how they look. A text containing even many of them should look continuous and fluently legible on the screen, across inset boundaries. We aren't there yet. > Perhaps I even want to add the non-quote "and" _after_ pasting in the > stuff and setting the style. I.e. break up the quote, just as I > occationally break up a paragraph. Perhaps. Or perhaps you should just get used to the reality that *this is a different paradigm* and you use it best on its own terms. Just playing the devil's advocate here. > The user don't care that the latter aproach might be some more work for > the code. It is nice if it works, and I believe many will worry > if they can't insert "normal" text in the middle of styled text. Don't worry, be happy ;-) > Pasting some paragraphs (with various styles) into the middle of some > styled text is another one that ought to work. And can be made to fairly easily. Doesn't right now though. > Helge Hafting - Martin pgp0.pgp Description: PGP signature
box dialog, xforms
The parbox/minipage radio set does not behave as a radio set. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Qt font handling and a mail from Andrew Abyzov, 01 Jun 2003
John Levon wrote: >> Did anything come of this? > http://marc.theaimsgroup.com/?l=lyx-devel&m=105543142806579&w=2 Cheers, John! -- Angus
Re: [patch] remove LyXText::inset_owner
On Mon, Dec 01, 2003 at 01:18:05PM +, Angus Leeming wrote:
> Index: buffer.h
> - /** The list of paragraphs.
> + /** The list of paragraphs().
> This is a linked list of paragraph, this list holds the
> whole contents of the document.
> */
Grmpf. As soon as I introduce some verbosity people start to complain...
> Index: text2.C
> - the beginning of paragraphs. This happens if you have
> + the beginning of paragraphs(). This happens if you have
>
>
> Thought: do you still need to forward-declare BufferView now?
> Index: iterators.h
> @@ -20,6 +20,7 @@
> class LyXText;
> class InsetOld;
> class Cursor;
> +class Buffer;
> class BufferView;
> class PosIterator;
>
> What has happended to this:
> Index: lyxfunc.C
> - case LFUN_INSET_TOGGLE: {
> - LyXText * lt = view()->getLyXText();
> - disable = !(isEditableInset(lt->getInset())
> - || (lt->inset_owner
> - && lt->inset_owner->owner()
> - && lt->inset_owner->owner()->isOpen()));
> - break;
> - }
>
> ... Ah. Neat (I see the code in insetcollapsable).
Most of the other inset->owner() usages are probably removable like
this. That's why my suspicion that InsetOld::owner_ is not needed at
all.
> Thought: Buffer now contains a LyxText variable that contains the
> entire document, right?
Hm, yes.
> Is 'Buffer" becoming redundant, given that most of its member
> functions could/should be implemented as free functions?
Maybe. Note that a LyXText is 'nestable', a Buffer is not. So the
main text plays two roles. Having them separated in 'Buffer' (read/write
files etc) and 'LyXText' (basic editing) does not sound wrong.
> This makes me feel uneasy, maybe because I never really got to grips
> with the 'inherit' stuff. Is the change really Ok?
>
> @@ -82,13 +71,7 @@ void InsetOld::setBackgroundColor(LColor
>
> LColor_color InsetOld::backgroundColor() const
> {
> - if (background_color_ == LColor::inherit) {
> - if (owner())
> - return owner()->backgroundColor();
> - else
> - return LColor::background;
> - } else
> - return LColor::color(background_color_);
> + return LColor::color(background_color_);
> }
I've played a bit around and it got e.g. the Note inset right. I was
actually expecting the need to pass the 'active' background color around
using the PainterInfo struct but so far I've not yet seen a case where
this is needed.
> Ditto. Really Ok?
> Index: insets/inset.h
> - /// check if the font of the char we want inserting is correct
> - /// and modify it if it is not.
> - virtual bool checkInsertChar(LyXFont &);
>
> - /* needed for widths which are % of something
> - returns the value of \textwidth in this inset. Most of the
> - time this is the width of the workarea, but if there is a
> - minipage somewhere, it will be the width of this minipage */
> - virtual int latexTextWidth(BufferView *) const;
I think so. This pretty much was dead code and the only suspicious case
'minipage' gets it right without this.
> I think that these showInsetDialog member functions could safely be
> discarded, given tht many insets implement this directly in
> priv_dispatch:
>
> Index: insets/insetwrap.h
> - bool showInsetDialog(BufferView *) const;
> - ///
> - int latexTextWidth(BufferView *) const;
> + bool showInsetDialog(BufferView *) const;
>
> Man! You've been busy!
It was the third or fourth attempt on the matter, so it wasn't that
difficult...
Andre'
Re: Qt font handling and a mail from Andrew Abyzov, 01 Jun 2003
On Mon, Dec 01, 2003 at 01:19:57PM +, Angus Leeming wrote: > Did anything come of this? http://marc.theaimsgroup.com/?l=lyx-devel&m=105543142806579&w=2 john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Qt font handling and a mail from Andrew Abyzov, 01 Jun 2003
Did anything come of this? -- Angus--- Begin Message --- Hello! I've made some improvements to the procedure of symbol font loading in the qt frontend. Now it uses QFontInfo mechanism recommended by Qt developers and works under Qt 3.1.1 / RH9. Also I have made a TTF wasy10 font, which can be included in the latex-ttf-fonts package. --- WBR, Andrew Abyzov qfont_loader.tar.bz2 Description: Binary data --- End Message ---
Re: [PATCH] remove "none" from vspace gui
Juergen Spitzmueller wrote: > The patch removes VSPACE::NONE from both the qt and the xforms > dialog. I haven't touched the inset (and won't). This is half of Michael Schmitt's patch, right? Why not just apply it all? > One problem left (in both frontends): what do I have to do to let > the ok/apply buttons be enabled if I insert a *new* inset? > Currently I have to change sth in the dialog to be able to apply. Add a line like bc().valid() to the controller somewhere. Grep the other controllers. > And a question: does the "Restore" button make any sense in this > dialog? It is probably simple enough to just use 'Cancel'. -- Angus
Re: The current char style UI
On Mon, Dec 01, 2003 at 03:23:42PM +0200, Martin Vermeer wrote: > Now I have to read that. Do you happen to have a link handy? http://marc.theaimsgroup.com/?l=lyx-devel&m=104974730920332&w=2 john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: Right address is horked
On Mon, Dec 01, 2003 at 12:12:49PM +0100, Jean-Marc Lasgouttes wrote: > Andre> And has been for a while... > > >> it's off the left of the screen. > > Andre> Would you think that moving this 'right address' business to an > Andre> inset is a good idea? > [...] > Not really, since it is just a way to show on screen some layouts > (which exist only in letter-type layouts...). It would be > better/easier to display this in a 'degraded' way such as > > |here is > --[right]-->|my address > |on three lines > > or something more intuitive. This would be some kind of solution, too, but I don't really like this kind of special casing in the core... 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] remove LyXText::inset_owner
Andre Poenitz wrote:
> Huh... I thought I attached it.
>
> I certainly did attach it to the mail sent to [EMAIL PROTECTED]
> Anyway. Next try.
>
> Andre'
These are not improvements IMO:
Index: buffer.h
- /** The list of paragraphs.
+ /** The list of paragraphs().
This is a linked list of paragraph, this list holds the
whole contents of the document.
*/
Index: lyxtext.h
- /** the DTP switches for paragraphs. LyX will store the top settings
+ /** the DTP switches for paragraphs(). LyX will store the top
settings
Index: text2.C
- the beginning of paragraphs. This happens if you have
+ the beginning of paragraphs(). This happens if you have
Thought: do you still need to forward-declare BufferView now?
Index: iterators.h
@@ -20,6 +20,7 @@
class LyXText;
class InsetOld;
class Cursor;
+class Buffer;
class BufferView;
class PosIterator;
What has happended to this:
Index: lyxfunc.C
- case LFUN_INSET_TOGGLE: {
- LyXText * lt = view()->getLyXText();
- disable = !(isEditableInset(lt->getInset())
- || (lt->inset_owner
- && lt->inset_owner->owner()
- && lt->inset_owner->owner()->isOpen()));
- break;
- }
... Ah. Neat (I see the code in insetcollapsable).
Thought: Buffer now contains a LyxText variable that contains the
entire document, right? Is 'Buffer" becoming redundant, given that
most of its member functions could/should be implemented as free
functions?
This makes me feel uneasy, maybe because I never really got to grips
with the 'inherit' stuff. Is the change really Ok?
@@ -82,13 +71,7 @@ void InsetOld::setBackgroundColor(LColor
LColor_color InsetOld::backgroundColor() const
{
- if (background_color_ == LColor::inherit) {
- if (owner())
- return owner()->backgroundColor();
- else
- return LColor::background;
- } else
- return LColor::color(background_color_);
+ return LColor::color(background_color_);
}
Ditto. Really Ok?
Index: insets/inset.h
- /// check if the font of the char we want inserting is correct
- /// and modify it if it is not.
- virtual bool checkInsertChar(LyXFont &);
- /* needed for widths which are % of something
- returns the value of \textwidth in this inset. Most of the
- time this is the width of the workarea, but if there is a
- minipage somewhere, it will be the width of this minipage */
- virtual int latexTextWidth(BufferView *) const;
I think that these showInsetDialog member functions could safely be
discarded, given tht many insets implement this directly in
priv_dispatch:
Index: insets/insetwrap.h
- bool showInsetDialog(BufferView *) const;
- ///
- int latexTextWidth(BufferView *) const;
+ bool showInsetDialog(BufferView *) const;
Man! You've been busy!
Angus
Re: The current char style UI
On Mon, Dec 01, 2003 at 12:27:41PM +, John Levon spake thusly: > On Mon, Dec 01, 2003 at 09:18:06AM +0200, Martin Vermeer wrote: > > > > > Hmmm perhaps. Did I point out already that I don't really like physical > > > > character attributes? :-) > > > > > > They shouldn't exist at all, but that has some other implications. > > > > They won't be going away any time soon. Just like in LaTeX. > > What makes you say this ? As soon as we have a "finished" LCS feature, > they can and should die completely, as I outlined and got broad > agreement on (not that I was the first to feel this way) > > I suppose we might live with the current inset approach for now, but we > must remember it is really a hack to some extent, not what we finally > want. > > regards > john Now I have to read that. Do you happen to have a link handy? Not that I feel differently... I just don't think it is around the corner. - Martin pgp0.pgp Description: PGP signature
Re: Right address is horked
-BEGIN PGP SIGNED MESSAGE- On Montag, 1. Dezember 2003 11:11, Michael Schmitt wrote: > It is hard for me to motivate myself to do some testing when LyX > misbehaves in almost every situation and the architecture of LyX is > refactored daily... All too true. I second here. > Where is the promised end of the tunnel? Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP8s9cbewfbDGmeqhAQES6wQAmHDOOA0QvJJW4AXA5m17MJgt/PII7BoG EDAzsit7CgmfQLNmVHSUtEZuxUqulk+U3/rZuuv1tpqCNYYcaZP+pq0Mzy8ZQ7a1 OrjL9cuPMaeMcZ6pStSZRNztOcVaGdxvaslZqwggcegUfoaXpuNfsisFckmKKGyy xuZXdeg/9VQ= =p22s -END PGP SIGNATURE-
Re: [Devel] Re: [PATCH] VSpace cleanup
On Mon, Dec 01, 2003 at 01:41:39PM +0100, Juergen Spitzmueller wrote: > Michael Schmitt wrote: > > NONE is a pretty pointless option with a true VSpace inset. > > > > Please check and apply the attached patch. > > Cool. I merge it with my changes and commit, o.k.? (I have a few > other changes concerning the VSpace gui). I would think so. Both looked good. 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: A working InsetVSpace
On Mon, Dec 01, 2003 at 10:17:43AM +, Angus Leeming wrote: > Martin Vermeer wrote: > > The paragraph reading code readParagraph() in paragraph_funcs.C > > shouldn't be handling the \end_inset token... that's for the VSpace > > inset itself to do. Something fishy here. > > Ok, makes sense. Remember, André doesn't write many of these 'normal' > insets, so you should be kind and show him the error of his ways ;-) Sounds like the inset scheme is still a bit too complex if copy & paste introduces errors... Why is an inset supposed to read the \end_inset token? Isn't that 'data belonging to a level above'? 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: The current char style UI
On Mon, Dec 01, 2003 at 11:07:55AM +0100, Andre Poenitz spake thusly: > > > > As I wrote earlier, one-box inlined is implementable right now but > > won't work right for current CVS because of the width stuff. > > What width stuff? > > Andre' Try and insert an inlined ERT into a text, any text. You'll see :-( - Martin pgp0.pgp Description: PGP signature
Re: Right address is horked
On Mon, Dec 01, 2003 at 11:11:08AM +0100, Michael Schmitt wrote: > >Right Address is completely broken, it's off the left of the screen. > > > >Also resizing the window does not resize the document. > > > >I've also spotted about 10 new regressions other than that since I last > >tried LyX, but I suppose they are well known about ... > > And that makes me very sad, sad, sad :-( > > It is hard for me to motivate myself to do some testing when LyX > misbehaves in almost every situation and the architecture of LyX is > refactored daily... Where is the promised end of the tunnel? You'll hear the call for testing... 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: Boxes
On Mon, Dec 01, 2003 at 11:21:20AM +0100, Michael Schmitt spake thusly: > > > Martin, > > I think we should add "Minipage" and "Parbox" to the box type lists instead of > > "frameless". If the user choses Minipage or Parbox, then the "has inner box" > > stuff should be completely disabled. > > > > Otherwise people will bug us because they do not find minipage anymore. > > The situation is worse (UI-wise): >I insert a frameless box and I get a minipage => Maximum confusion! > > I don't know whether we have to distinguish between minipages and > parboxes or whether one of them supercharges the other. But in the UI we > should not mix _frame_ properties with general _box_ properties. > > IMHO the menu should look like this: > > >Box => No Frame > Single Frame > Double Frame > Oval Frame, Thin > Oval Frame, Thick > Shadow Frame OK, looks good. Can you prepare a patch? > Alternatively, we can remove the submenu and use "Single Frame" as default. > > As box label, I propose to have, e.g, "Box (No Frame)". In this way we > can save a couple of messages and gain a greater consistency. (Martin, I > don't think that the size of the label really matters.) Fine! That means a patch against insetbox.C. Could you make it? Do you have to change ControlBox.C at all? > Or even better, > we visualize the frame. I guess this can be done in a simple way > technically. Not *so* simple... Angus proposed that too. Perhaps later... > Michael - Martin pgp0.pgp Description: PGP signature
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 01:25:04PM +0100, Andre Poenitz wrote: > Undo should be checked again. Undo is (fairly) trivially crashing again regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [patch] Qt scrolling
-BEGIN PGP SIGNED MESSAGE- On Montag, 1. Dezember 2003 11:21, Angus Leeming wrote: > The patch has the timout returning after 400ms. Could you modify the > code to return after 200ms and see how that feels please. I would, but the patch is not applying anymore to cvs. I am at work now, and don't have the sources from yesterday. - From what I remember, even the 400 ms was fast ... I just managed to follow the selections, so I was not unhappy with that value. Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP8s7VLewfbDGmeqhAQEjaAQAiEs8AzLcF5nqGhe+HI1d60f4Lyz7jhNH Co/SPZ8IQqeosuglcxb6Wp8D/blO+oqLBMxXOmtm73an833t7TpPqp9kEPT70bVh 9oPXBQOkgJg0fNYimQZmp1F6b3q+dfidTxMOfp1I97ymXRyLR82+rD0R5gqeM2/h RzyO0H3iC0o= =y5YI -END PGP SIGNATURE-
Re: [Devel] [PATCH] remove "none" from vspace gui
On Mon, Dec 01, 2003 at 01:42:39PM +0100, Juergen Spitzmueller wrote: > > Change the policy in the controller. > > Where? To what? in qt2/Dialogs.C: 263 dialog->setController(new ControlVSpace(*dialog)); 264 dialog->setView(new QVSpace(*dialog)); 265 dialog->bc().bp(new OkApplyCancelReadOnlyPolicy); You need one of the others than OkApplyCancelROPolicy regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [PATCH] VSpace cleanup
Michael Schmitt wrote: > NONE is a pretty pointless option with a true VSpace inset. > > Please check and apply the attached patch. Cool. I merge it with my changes and commit, o.k.? (I have a few other changes concerning the VSpace gui). Thanks, Jürgen.
Re: [Devel] [PATCH] remove "none" from vspace gui
John Levon wrote: > > One problem left (in both frontends): what do I have to do to let the > > ok/apply buttons be enabled if I insert a *new* inset? Currently I have > > to change sth > > Change the policy in the controller. Where? To what? (sorry, but I really can't see it). Jürgen.
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 10:48:13AM +0100, Michael Schmitt wrote: > set up a new task list covering the remaining open issues of LyX 1.4. > > Beside the usual bug fixing, I see the following open issues: This is actually 99% of the work. I hope people are beginning to see what a massive task this actually is now ... just getting tables back up and running will probably take *weeks* (sadly, I don't think I'm exaggerating). > - Change tracking > - Major rewrite (JL?) Should probably be backed out regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: [Devel] [PATCH] remove "none" from vspace gui
On Mon, Dec 01, 2003 at 11:16:06AM +0100, Juergen Spitzmueller wrote: > The patch removes VSPACE::NONE from both the qt and the xforms dialog. I > haven't touched the inset (and won't). Whoops, duplicated effort ! I'll let you deal with merging with Michael's if it makes sense. > One problem left (in both frontends): what do I have to do to let the ok/apply > buttons be enabled if I insert a *new* inset? Currently I have to change sth Change the policy in the controller. > in the dialog to be able to apply. > And a question: does the "Restore" button make any sense in this dialog? I don't think anything other than OK and Close really make sense actually regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: LyX 1.4 task list
Michael Schmitt wrote: > I still do not give up hope that LyX 1.4 will eventually become > reality. As someone noted a wee while ago, the changes in functionality from 1.3 to 1.4 are small. The long lead time does not mean that users are missing out. > Optional tasks > > - Frontend: > - Controller simplications (AL) > - ControlDocument ControlPreamble ControlPrint ControlSearch > ControlSendto C ontrolSpellchecker ControlForks ControlPrefs Thes are definitely optional, in that the current code works fine and the user will see no change should the code be changed. I'll just plug away as the motivation grabs me. More important, and something that should definitely be addressed IMO is the fact that our interface with the outside world has changed. (All those lfun name changes.) Thi means that external programs like pybliographer will most definitely NOT work with LyX 1.4 as things stand now. Do we need an lfun2lfun converter? Two 'wish-list' things that I would like: * Refactor the Preview code so that it sits confortably with InsetExternal (RenderPreview, actually.) I know what I'd like to see anyway... * I think that I would like to give the External inset dialogs the ability to rotate, resize and crop their data. This involves additions to qt/QExternal* and xforms/FormExternal* only. That would make InsetExternal an almost-drop-in replacement for InsetGraphics. (Wouldn't handle "subfigure".) Jean-Marc stated that he thought that this would be the wrong way to go but I'd like to try it out anyway. The alternative of one inset with several different dialogs (for graphics-type insets and for 'others') is a refinement IMO and one that may or may not be needed. Note that both of these 'wish list' items concern a part of LyX that almost nobody currently uses. I certainly don't think that their implementation (or not) should hold-up any future release date. -- Angus
Re: [PATCH] VSpace cleanup
On Mon, Dec 01, 2003 at 10:30:27AM +0100, Michael Schmitt wrote: > NONE is a pretty pointless option with a true VSpace inset. > > Please check and apply the attached patch. Looks good regards john
Re: Right address is horked
On Mon, Dec 01, 2003 at 09:47:15AM +0100, Andre Poenitz wrote: > Would you think that moving this 'right address' business to an inset is > a good idea? Worse UI, but I suppose so. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The current char style UI
On Mon, Dec 01, 2003 at 09:18:06AM +0200, Martin Vermeer wrote: > > > Hmmm perhaps. Did I point out already that I don't really like physical > > > character attributes? :-) > > > > They shouldn't exist at all, but that has some other implications. > > They won't be going away any time soon. Just like in LaTeX. What makes you say this ? As soon as we have a "finished" LCS feature, they can and should die completely, as I outlined and got broad agreement on (not that I was the first to feel this way) I suppose we might live with the current inset approach for now, but we must remember it is really a hack to some extent, not what we finally want. regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: The current char style UI
On Mon, Dec 01, 2003 at 08:49:49AM +0100, Juergen Spitzmueller wrote: > > What are people's future plans in this regard ? I know its already been > > discussed wrt how the inset should look, but I have real issues with > > this stuff being in the Insert menu at all. I'd muich rather see text > > style being a submenu in Edit. > > IMHO we should have another combo in the (one) toolbar. Char Styles should > conceptually be handled like paragraph styles. I know, there is not much > place, but we can remove the noun, emph and font-free buttons, and we should > default to 2 toolbars anyway. It can certainly be in the toolbar. But this does not solve the problem of where it goes in the menus, and how. > stuff. Perhaps it's only me, but this seriously disturbs me. I think the It's not only you. > off) would fit very much to LyX's philosophy and is user friendly. But if I > understand Martin, the current solution is only interim anyway. This is (part of) what I'm asking ... regards john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: vspace ui
On Mon, Dec 01, 2003 at 08:35:08AM +0100, Juergen Spitzmueller wrote: > > There are missing tooltips it seems ... (qt) > > Where? Sorry, there wasn't ... but I don't like the tooltip for protect, "reset" is the wrong word here john -- Khendon's Law: If the same point is made twice by the same person, the thread is over.
Re: LyX 1.4 task list
On Mon, Dec 01, 2003 at 10:48:13AM +0100, Michael Schmitt wrote: > Mandatory tasks > > - Kernel > - General cleanup (details?) (AB, AP) I think we are "structurally" through. User interaction with tables is completely broken due to the one-and-a-half cursor slice limbo. [I am a bit in a dilemma here: Moving to two slices should be fairly straight forward, but OTOH math tables are 'one slice', so going 'two slice' would make IU harder...] Undo should be checked again. >From my wish list: - move LyXFunc::getStatus into the insets pretty much the way dispatch() is handled - get rid of Paragraph::Pimpl::inset_owner and Inset::owner_ > Did I miss anything? Or is anybody working on some pet project that > shall be included in LyX 1.4? - make 1.4.0 uniformly faster than 1.3.x > IMHO we should agree on a feature freeze really soon now - taking into > account that we have already entered the bug fixing phase some _months_ ago! 1.3.latest is in a pretty good shape so I don't feel the need to rush things. But I agree that two years is a pretty long time... Andre'
Ping (ignore this mail)
I'm just checking the latency... Michael
Re: [patch] remove LyXText::inset_owner
On Mon, Dec 01, 2003 at 11:28:33AM +, Angus Leeming wrote: > Andre Poenitz wrote: > > This finally moves the ParagraphList members of Buffer and InsetText > > to LyXText (and replaces the ParagraphList * member we've had there > > by the real thing). > > > > A few smaller modification finally makes LyXText::inset_owner > > superflous. > > > > [So we have only three 'bad' back pointers in the core left: > > Paragraph::Pimpl_::inset_owner, InsetOld::owner_, and, depending on > > your point of view, LyXText::bv_owner. We won't be able to do much > > about the last one for a while, though...] > > Note that LyX is now a singleton class, so you could access all > BufferViews through it... Not sure whether this is the way to go. I'd rather hand down BufferView* parameters to all functions that need it. > > Andre' > > Could we see the patch? Huh... I thought I attached it. I certainly did attach it to the mail sent to [EMAIL PROTECTED] Anyway. Next try. Andre' 1.diff.gz Description: application/gunzip
Re: [patch] remove LyXText::inset_owner
Andre Poenitz wrote: > This finally moves the ParagraphList members of Buffer and InsetText > to LyXText (and replaces the ParagraphList * member we've had there > by the real thing). > > A few smaller modification finally makes LyXText::inset_owner > superflous. > > [So we have only three 'bad' back pointers in the core left: > Paragraph::Pimpl_::inset_owner, InsetOld::owner_, and, depending on > your point of view, LyXText::bv_owner. We won't be able to do much > about the last one for a while, though...] Note that LyX is now a singleton class, so you could access all BufferViews through it... > Andre' Could we see the patch? -- Angus
Re: The current char style UI
Martin Vermeer wrote: On Mon, Dec 01, 2003 at 12:17:38AM +, John Levon spake thusly: [...] An essential difference is that a char attribute can be applied or unapplied. An inset can only be inserted (i.e., "applied" after selecting the text to be contained in it.) Exactly ... this is just one of the many problems with a box-based approach visible in the UI (as opposed to a purely internal box paradigm) Of course code for deleting or "unapplying" an inset (e.g., backspace in pos 0, like in math) could be created as well. But what you will never be able to do in this paradigm is "unapplying" a charstyle for a piece in the middle of an applied charstyle, as you can do with physical attributes -- or more generally, creating arbitrary bit patterns of attributes. (But then I would argue "why would you want to?") Well, I'm sure I could construct a valid use case. For *logical* charstyles to be used in this way? Or for attribute bits? I would grant the latter, grudgingly ;-) Logical character styles can add up in many interesting ways. A word might be both "foreign language" (for the spellchecker, and perhaps marked up too) and a "technical term" (other kind of markup) at the same time. As for unapplying, consider marking a little too much text when setting a style. Perhaps I want to adjust that without retyping text. Perhaps my editor instructs me to mark only the important sentence fragments instead of the entire paragraph. Unapplying is useful, even if the code may have to split an inset for me. Helge Hafting
Re: Right address is horked
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Sun, Nov 30, 2003 at 05:42:51PM +, John Levon wrote: >> Right Address is completely broken, Andre> And has been for a while... >> it's off the left of the screen. Andre> Would you think that moving this 'right address' business to an Andre> inset is a good idea? Andre> The code was/is cluttered with 'this is a hack' style comments Andre> and I don't think the feature as such is so fundamental to Andre> deserve a place in the core. Implementing it as light weight Andre> inset on top of InsetText should be straight forward and clean, Andre> though... Not really, since it is just a way to show on screen some layouts (which exist only in letter-type layouts...). It would be better/easier to display this in a 'degraded' way such as |here is --[right]-->|my address |on three lines or something more intuitive. JMarc
Re: The current char style UI
Martin Vermeer wrote: On Sun, Nov 30, 2003 at 05:30:58PM +, John Levon spake thusly: It has some real problems IMHO. We need to be careful here. What are people's future plans in this regard ? I know its already been discussed wrt how the inset should look, but I have real issues with this stuff being in the Insert menu at all. I'd muich rather see text style being a submenu in Edit. Fine with me! But since this is really only a halfway house to what we really want, that might not be suitable. What *do* we/you really want? But it's slightly weird to have some completely different UI for handling logical styles from physical settings, as we have currently. Hmmm perhaps. Did I point out already that I don't really like physical character attributes? :-) I can see your problem though. Having insets is a quite different paradigm, but is conceptually cleaner and more practical to implement. IMHO. An essential difference is that a char attribute can be applied or unapplied. An inset can only be inserted (i.e., "applied" after selecting the text to be contained in it.) Of course code for deleting or "unapplying" an inset (e.g., backspace in pos 0, like in math) could be created as well. But what you will never be able to do in this paradigm is "unapplying" a charstyle for a piece in the middle of an applied charstyle, as you can do with physical attributes -- or more generally, creating arbitrary bit patterns of attributes. (But then I would argue "why would you want to?") Because people work that way? Example: I paste two big quotes from other text into my document. Between them is a "and" or something that isn't part of the quote. (Because of "blablablah" and "blablah" we see that . . .) I could mark each quote in turn and set them to some quote style. It might be easier to mark everything and then unapply the "and" in the middle though. Perhaps I even want to add the non-quote "and" _after_ pasting in the stuff and setting the style. I.e. break up the quote, just as I occationally break up a paragraph. The user don't care that the latter aproach might be some more work for the code. It is nice if it works, and I believe many will worry if they can't insert "normal" text in the middle of styled text. Pasting some paragraphs (with various styles) into the middle of some styled text is another one that ought to work. Helge Hafting
Re: Still src/frontends/xforms/Makefile.am problem
Kayvan A. Sylvan wrote: > The patch I sent was not fully applied, it looks like. Ok, I'm brain dead! Could someone put me out of your misery and apply Kayvan's patch please. -- Angus
Re: Remove stray "if" in src/frontends/xforms/Makefile.am
Rob Lahaye wrote: > Angus, > Another patch is needed to src/frontends/xforms/Makefile.am in CVS, > to remove a stray 'if': Indeed. Know any good brain surgeons? It seems that I need one... -- Angus
Re: Boxes
Martin, I think we should add "Minipage" and "Parbox" to the box type lists instead of "frameless". If the user choses Minipage or Parbox, then the "has inner box" stuff should be completely disabled. Otherwise people will bug us because they do not find minipage anymore. The situation is worse (UI-wise): I insert a frameless box and I get a minipage => Maximum confusion! I don't know whether we have to distinguish between minipages and parboxes or whether one of them supercharges the other. But in the UI we should not mix _frame_ properties with general _box_ properties. IMHO the menu should look like this: Box => No Frame Single Frame Double Frame Oval Frame, Thin Oval Frame, Thick Shadow Frame Alternatively, we can remove the submenu and use "Single Frame" as default. As box label, I propose to have, e.g, "Box (No Frame)". In this way we can save a couple of messages and gain a greater consistency. (Martin, I don't think that the size of the label really matters.) Or even better, we visualize the frame. I guess this can be done in a simple way technically. Michael
Re: [patch] Qt scrolling
Kornel Benko wrote: >> Ok, Kornel, try 2. >> * revert yesterday's patch. >> * cvs up >> * apply the patch attached. > Something fishy hier ... > 3.57 korben.kornel 22:51 > patch -p0 < > '/tmp/kde-kornel/kmailfnaUvb.3/qt.diff' patching file > src/frontends/qt2//QContentPane.C Hunk #3 succeeded at 79 with fuzz > 2. patching file src/frontends/qt2//QContentPane.h > ... Fishy indeed, but it worked so let's not worry too much. >> It should fix both problems. If you still think (1) is too fast, >> could you play with the '400' ms passed to the timeout in the >> SyntheticMouseEvent constructor (QContentPane.h). > No need for 400ms now. This patch cured both problems. Good. The patch has the timout returning after 400ms. Could you modify the code to return after 200ms and see how that feels please. > BTW, I was unable to crash it with pointer selections. Good'o. > P.S. > This mail-delays are going to be too nerving. A PITA. -- Angus
[PATCH] remove "none" from vspace gui
The patch removes VSPACE::NONE from both the qt and the xforms dialog. I
haven't touched the inset (and won't).
One problem left (in both frontends): what do I have to do to let the ok/apply
buttons be enabled if I insert a *new* inset? Currently I have to change sth
in the dialog to be able to apply.
And a question: does the "Restore" button make any sense in this dialog?
Thanks,
Jürgen.
? src/frontends/qt2/QBox.C
? src/frontends/qt2/QBox.h
? src/frontends/qt2/ui/QBoxDialogBase.ui
Index: src/frontends/qt2/QVSpace.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QVSpace.C,v
retrieving revision 1.3
diff -u -r1.3 QVSpace.C
--- src/frontends/qt2/QVSpace.C 1 Dec 2003 07:54:02 - 1.3
+++ src/frontends/qt2/QVSpace.C 1 Dec 2003 10:10:23 -
@@ -50,26 +50,23 @@
{
int item = 0;
switch (space.kind()) {
- case VSpace::NONE:
- item = 0;
- break;
case VSpace::DEFSKIP:
- item = 1;
+ item = 0;
break;
case VSpace::SMALLSKIP:
- item = 2;
+ item = 1;
break;
case VSpace::MEDSKIP:
- item = 3;
+ item = 2;
break;
case VSpace::BIGSKIP:
- item = 4;
+ item = 3;
break;
case VSpace::VFILL:
- item = 5;
+ item = 4;
break;
case VSpace::LENGTH:
- item = 6;
+ item = 5;
break;
}
spacing->setCurrentItem(item);
@@ -96,28 +93,25 @@
LengthCombo * unit,
bool keep)
{
- VSpace space = VSpace(VSpace::NONE);
+ VSpace space = VSpace(VSpace::DEFSKIP);
switch (spacing) {
case 0:
- space = VSpace(VSpace::NONE);
- break;
- case 1:
space = VSpace(VSpace::DEFSKIP);
break;
- case 2:
+ case 1:
space = VSpace(VSpace::SMALLSKIP);
break;
- case 3:
+ case 2:
space = VSpace(VSpace::MEDSKIP);
break;
- case 4:
+ case 3:
space = VSpace(VSpace::BIGSKIP);
break;
- case 5:
+ case 4:
space = VSpace(VSpace::VFILL);
break;
- case 6:
+ case 5:
space = VSpace(LyXGlueLength(
widgetsToLength(value, unit)));
break;
@@ -163,10 +157,10 @@
{
// spacing
// If a vspace choice is "Length" but there's no text in
- // the input field, reset the choice to "None".
+ // the input field, do not insert a vspace at all.
if (dialog_->spacingCO->currentItem() == 6
&& dialog_->valueLE->text().isEmpty())
- dialog_->spacingCO->setCurrentItem(0);
+ return;
VSpace const space =
setVSpaceFromWidgets(dialog_->spacingCO->currentItem(),
Index: src/frontends/qt2/QVSpaceDialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QVSpaceDialog.C,v
retrieving revision 1.2
diff -u -r1.2 QVSpaceDialog.C
--- src/frontends/qt2/QVSpaceDialog.C 29 Nov 2003 17:25:30 - 1.2
+++ src/frontends/qt2/QVSpaceDialog.C 1 Dec 2003 10:10:23 -
@@ -52,7 +52,7 @@
void QVSpaceDialog::enableCustom(int)
{
- bool const enable = spacingCO->currentItem()==6;
+ bool const enable = spacingCO->currentItem()==5;
valueLE->setEnabled(enable);
unitCO->setEnabled(enable);
}
Index: src/frontends/qt2/ui/QVSpaceDialogBase.ui
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ui/QVSpaceDialogBase.ui,v
retrieving revision 1.2
diff -u -r1.2 QVSpaceDialogBase.ui
--- src/frontends/qt2/ui/QVSpaceDialogBase.ui 29 Nov 2003 17:25:31 - 1.2
+++ src/frontends/qt2/ui/QVSpaceDialogBase.ui 1 Dec 2003 10:10:24 -
@@ -13,7 +13,7 @@
0
0
-335
+331
140
@@ -115,12 +115,6 @@
QComboBox
-
-
-text
-None
-
-
text
Index: src/frontends/xforms/FormVSpace.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormVSpace.C,v
retrieving revision 1.3
diff -u -r1.3 FormVSpace.C
--- src/frontends/xforms/FormVSpace.C 29 Nov 2003 20:13:50 - 1.3
+++ src/frontends/xforms/FormVSpace.C 1 Dec 2003 10:10:25 -
@@ -54,14 +54,14 @@
BOOST_ASSERT(choice_type && choice_type->objclass == FL_CHOICE &&
input_length && input_length->objclass == FL_INPUT);
- if (fl_get_choice(choice_type) != 7)
+ if (fl_get_choice(choice_type) != 6)
return;
// If a vspace kind is "Length" but there's no text in
- // the input field, reset the kind to "None".
+ // the input field, insert nothing.
string const input = rtrim(getString(input_length));
if (input.empty())
- fl_set_choice(choice_type, 1);
+ return;
}
@@ -75,28 +75,25 @@
input_length && input_length->objclass == FL_INPUT &&
choice_length && choice_length->objclass == FL_CHOICE);
- VSpace space = VSpace(VSpace::NONE);
+ VSpace space = VSpace(VSpace::DEFSKIP);
switch (fl_get_choice(choice_type)) {
case 1:
- space = VSpace(VSpace::NONE);
Re: A working InsetVSpace
Martin Vermeer wrote: > The paragraph reading code readParagraph() in paragraph_funcs.C > shouldn't be handling the \end_inset token... that's for the VSpace > inset itself to do. Something fishy here. Ok, makes sense. Remember, André doesn't write many of these 'normal' insets, so you should be kind and show him the error of his ways ;-) Angus ps, I won't be near a box with the LyX sources on it for a few days, so please post/commit the patch. A
Right address is horked
Right Address is completely broken, it's off the left of the screen. Also resizing the window does not resize the document. I've also spotted about 10 new regressions other than that since I last tried LyX, but I suppose they are well known about ... And that makes me very sad, sad, sad :-( It is hard for me to motivate myself to do some testing when LyX misbehaves in almost every situation and the architecture of LyX is refactored daily... Where is the promised end of the tunnel? Michael
Re: The current char style UI
On Mon, Dec 01, 2003 at 09:18:06AM +0200, Martin Vermeer wrote: > On Mon, Dec 01, 2003 at 12:17:38AM +, John Levon spake thusly: > > > > On Sun, Nov 30, 2003 at 10:44:11PM +0200, Martin Vermeer wrote: > > > > > > But since this is really only a halfway > > > > house to what we really want, that might not be suitable. > > > > > > What *do* we/you really want? > > > > Well as outlined and discussed some months ago. > > Don't remember precisely. Wasn't it about three-box inlined? > > As I wrote earlier, one-box inlined is implementable right now but > won't work right for current CVS because of the width stuff. What width stuff? Andre'
LyX 1.4 task list
Hello, I still do not give up hope that LyX 1.4 will eventually become reality. Since http://www.devel.lyx.org/roadmap.php3 is totally outdated (it lists some features that were initially planned for 1.2), I started to set up a new task list covering the remaining open issues of LyX 1.4. Beside the usual bug fixing, I see the following open issues: *** Mandatory tasks - Kernel - General cleanup (details?) (AB, AP) - Frontend: - QT box dialog (JS) - LyX2LyX - Vspace conversion - Change tracking - Major rewrite (JL?) - User manuals & translations - General overhaul (various artists) Optional tasks - Frontend: - Controller simplications (AL) - ControlDocument ControlPreamble ControlPrint ControlSearch ControlSendto ControlSpellchecker ControlForks ControlPrefs - QT citation dialog - Insert dialog pops up immediately (JS) *** Did I miss anything? Or is anybody working on some pet project that shall be included in LyX 1.4? IMHO we should agree on a feature freeze really soon now - taking into account that we have already entered the bug fixing phase some _months_ ago! Of course, this is just my personal opinion... Michael
[PATCH] VSpace cleanup
Hello,
NONE is a pretty pointless option with a true VSpace inset.
Please check and apply the attached patch.
Thanks, Michael
Index: src/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/ChangeLog,v
retrieving revision 1.1732
diff -u -r1.1732 ChangeLog
--- src/ChangeLog 2003/12/01 00:35:26 1.1732
+++ src/ChangeLog 2003/12/01 09:28:01
@@ -1,3 +1,7 @@
+2003-12-01 Michael Schmitt <[EMAIL PROTECTED]>
+
+ * vspace.[Ch]: remove VSpace::NONE
+
2003-12-01 John Levon <[EMAIL PROTECTED]>
* BufferView_pimpl.C: fix a crash on exit with
Index: src/vspace.C
===
RCS file: /cvs/lyx/lyx-devel/src/vspace.C,v
retrieving revision 1.79
diff -u -r1.79 vspace.C
--- src/vspace.C2003/11/21 17:31:46 1.79
+++ src/vspace.C2003/12/01 09:28:03
@@ -337,7 +337,7 @@
//
VSpace::VSpace()
- : kind_(NONE), len_(), keep_(false)
+ : kind_(DEFSKIP), len_(), keep_(false)
{}
@@ -357,7 +357,7 @@
VSpace::VSpace(string const & data)
- : kind_(NONE), len_(), keep_(false)
+ : kind_(DEFSKIP), len_(), keep_(false)
{
if (data.empty())
return;
@@ -436,7 +436,6 @@
{
string result;
switch (kind_) {
- case NONE: break;
case DEFSKIP: result = "defskip"; break;
case SMALLSKIP: result = "smallskip";break;
case MEDSKIP: result = "medskip"; break;
@@ -444,7 +443,7 @@
case VFILL: result = "vfill";break;
case LENGTH:result = len_.asString(); break;
}
- if (keep_ && kind_ != NONE && kind_ != DEFSKIP)
+ if (keep_)
result += '*';
return result;
}
@@ -472,9 +471,6 @@
return keep_ ? "\\vspace*{" + len_.asLatexString() + '}'
: "\\vspace{" + len_.asLatexString() + '}';
- case NONE:
- return string();
-
default:
BOOST_ASSERT(false);
return string();
@@ -510,9 +506,6 @@
case LENGTH:
return len_.len().inPixels(bv.workWidth());
-
- case NONE:
- return 0;
default:
BOOST_ASSERT(false);
Index: src/vspace.h
===
RCS file: /cvs/lyx/lyx-devel/src/vspace.h,v
retrieving revision 1.30
diff -u -r1.30 vspace.h
--- src/vspace.h2003/10/06 15:42:43 1.30
+++ src/vspace.h2003/12/01 09:28:03
@@ -24,7 +24,6 @@
public:
/// The different kinds of spaces.
enum vspace_kind {
- NONE, ///< no added vertical space
DEFSKIP,
SMALLSKIP,
MEDSKIP,
Index: src/frontends/qt2/ChangeLog
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/ChangeLog,v
retrieving revision 1.615
diff -u -r1.615 ChangeLog
--- src/frontends/qt2/ChangeLog 2003/12/01 07:54:02 1.615
+++ src/frontends/qt2/ChangeLog 2003/12/01 09:28:12
@@ -1,3 +1,9 @@
+2003-12-01 Michael Schmitt <[EMAIL PROTECTED]>
+
+ * QVSpace.C:
+ * QVSpaceDialog.C:
+ * ui/QVSpaceDialogBase.ui: remove VSpace::NONE
+
2003-12-01 Juergen Spitzmueller <[EMAIL PROTECTED]>
* QDocumentDialog.[Ch]: (branches) don't insert a coloritem
Index: src/frontends/qt2/QVSpace.C
===
RCS file: /cvs/lyx/lyx-devel/src/frontends/qt2/QVSpace.C,v
retrieving revision 1.3
diff -u -r1.3 QVSpace.C
--- src/frontends/qt2/QVSpace.C 2003/12/01 07:54:02 1.3
+++ src/frontends/qt2/QVSpace.C 2003/12/01 09:28:12
@@ -50,26 +50,23 @@
{
int item = 0;
switch (space.kind()) {
- case VSpace::NONE:
- item = 0;
- break;
case VSpace::DEFSKIP:
- item = 1;
+ item = 0;
break;
case VSpace::SMALLSKIP:
- item = 2;
+ item = 1;
break;
case VSpace::MEDSKIP:
- item = 3;
+ item = 2;
break;
case VSpace::BIGSKIP:
- item = 4;
+ item = 3;
break;
case VSpace::VFILL:
- item = 5;
+ item = 4;
break;
case VSpace::LENGTH:
- item = 6;
+ item = 5;
break;
}
spacing->setCurrentItem(item);
@@ -96,28 +93,25 @@
LengthCombo * unit,
bool keep)
{
- VSpace space = VSpace(VSpace::NONE);
+ VSpace space;
switch (spacing) {
case 0:
- space = VSpace(VSpace::NONE);
- break;
- case 1:
space = VSpace(VSpace::DEFSKIP);
break;
- case 2:
+ ca
Re: A working InsetVSpace
On Mon, Dec 01, 2003 at 08:59:58AM +0200, Martin Vermeer wrote: > On Sun, Nov 30, 2003 at 10:01:07PM +0100, Georg Baum spake thusly: > > Am Sonntag, 30. November 2003 10:00 schrieb Juergen Spitzmueller: > > > Georg Baum wrote: > > > > Apart from that, I get error messages like > > > > > > > > Paragraph ended in line 31 > > > > Missing \end_layout. > > > > > > > > if I use the VSpace inset (see attached example). Is this expected (CVS > > > > from this morning)? I checked the file by hand, the structure seems to > > > > be correct. > > > > > > cannot reproduce (and you forgot to attach the file). > > > > Oops. Now really attached. I am using gcc 2.95.4 + stlport. Could this be > > the problem? > > > > > > Georg > > Confirmed. The problem seems to be (debugging) > > Handling token: `\begin_layout' > Handling paragraph token: `begin' > Handling paragraph token: `\begin_inset' > Handling paragraph token: `\end_inset' > Paragraph ended in line 31 > Missing \end_layout. > > The paragraph reading code readParagraph() in paragraph_funcs.C > shouldn't be handling the \end_inset token... that's for the VSpace > inset itself to do. Something fishy here. Maybe just a missing lex.next()? 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: Right address is horked
On Sun, Nov 30, 2003 at 05:42:51PM +, John Levon wrote: > > Right Address is completely broken, And has been for a while... > it's off the left of the screen. Would you think that moving this 'right address' business to an inset is a good idea? The code was/is cluttered with 'this is a hack' style comments and I don't think the feature as such is so fundamental to deserve a place in the core. Implementing it as light weight inset on top of InsetText should be straight forward and clean, though... 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] fix exit crash
On Sun, Nov 30, 2003 at 03:41:15AM +, John Levon wrote: > > ->text() is NULL when you're shutting down with a discarded document > open. > > Fix accesses Looks ok. 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...)
[patch] remove LyXText::inset_owner
This finally moves the ParagraphList members of Buffer and InsetText to LyXText (and replaces the ParagraphList * member we've had there by the real thing). A few smaller modification finally makes LyXText::inset_owner superflous. [So we have only three 'bad' back pointers in the core left: Paragraph::Pimpl_::inset_owner, InsetOld::owner_, and, depending on your point of view, LyXText::bv_owner. We won't be able to do much about the last one for a while, though...] 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...)
