Re: dvipng reports baseline
Jan-Åke Larsson wrote: Angus Leeming wrote: 1. Here I had colour specials in the latex file. In future I will not need them, right? Instead I'll pass them direct to dvipng, as above. Yes. You can do either. The DVI colors are preferred, of course. 2. I should prefer your -depth and -height flags, extracting the metrics info from the output above, rather than extracting it from the latex log file? Reason: the log file info is going to be wrong if I invoke dvipng with the '-T tight' option, right? (and I would like to do so so that I can strip off the front margin of a displaystyle equation). There are actually three ways to determine the boundingboxes. 1) -T tight which would make -depth -height necessary. You'd get the boundingbox determined from the ink of the image. 2) From the output I see you have used the tightpage option to preview, I have code lying around that will take the boundingboxes from the specials instead, do you want that? 3) dvipng dvifile - will fire up the stdin interface where you could input the dimensions yourself per page, as obtained from the latex run. Once the stdin interface is up you give -T 1in,1in -O 40sp,30sp -pp1 and then -T 3cm,3cm -O 3pt,5pt -pp2 and so on. In case 2) and 3) you can of course give --depth and read the _pixel_ depth off dvipng's stdout. I was also thinking of doing 2b) and 3b) by allowing the bbox to grow from the (-T) specified bbox to include all ink produced by the DVI. This would eliminate shaved edges, while still keeping the specified bbox, whitespace and such. Opinions? /JÅ -- Linux: The choice of a GNU generation.
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Fri, Dec 05, 2003 at 07:49:38PM +0100, Christian Ridderström wrote:
I agree with Helge here, and it reminded me of a behaviour that's
sometimes annoying in mathed. It happens quite often that I delete the
previous 'box' without intending to when using the backspace key. An
example (just imagine that the latex is actually math in mathed, and '|'
is the cursor):
a^2+\textrm{aFunction}|
Pressing backspace now, leaves me with a measly a^2+ :-(
Anyway, I just remembered that this is something that frequently has
annoyed me. Not that I know what to do about it though, because at other
times it's really convenient to be able to delete an entire block at
once...
It would be nice if our keyboards were force sensitive sometimes.. then
I could simply press backspace a bit harder to get it to delete a block.
A blue sky idea here might be to have a single backspace keypress delete a
simple 'character' to the left if there is one, and if there's a 'box' to
the left, you have to press backspace twice?
This gives the impression your keyboard is stuck. I tried this already.
The most annoying 'feature' in this area is that undo does not set the
cursor properly...
now when you press backspace, the textinset isn't deleted, but highlighted
and a cute text shows up on the statusbar saying Press delete again to
actually delete.
a^2+\textrm{aFunction}|
\---delete?--\
and then when you press delete again, you end up with
Hm... highlighting might indeed be an option as the first backspace is
not silently swallowed.
Andre'
Re: word-backward/forward in mathed
On Fri, Dec 05, 2003 at 07:29:18PM +0100, Christian Ridderström wrote:
This started in some charStyle thread... it is about a suggestion to
change the behaviour of C-left/right in mathed (aka word-backward/forward)
Originally I was (approx.) complaining that it takes a lot of left/right's
to move in mathed because of all the boundaries you have to cross.
Then I suggested that maybe C-left/right could be used to move at a
'courser' level...
[Brief interlude in the dialog were we are informed of Andre's 14 year
old configuration of his window manager - it steals his C-left/right)
[It doesn't steal it. It does what it is supposed to do...]
Now back from the break, my suggestion is that we change the behaviour of
word-backward/forward so that it uses something other spaces as word
separators. One idea could be to use '+' and '-', essentially moving the
cursor one term at a time in a formula.
This is close to useless. I have one-page-formulas where '+' and '-'
appear (at best) in some index computations. So going to the begin of
the current box is much more sensible than searching for the next '+'.
While on the subject, something's rotten in Denmark.. mathed, since
line-beginning/end
behave the same as
word-backward/forward
as far as I can tell.
Such things could be proven quickly by looking at the source.
Both move the cursor to the first or last position
of the mathed box, and this seems pointless to me.
Better idea?
In fact, even inside \textrm{adsfas asdf asfd} word-backward/forward
doesn't work (i.e. go to the next word separated by a space).
Mathed has almost no idea what a 'word' or a 'space' is.
Anyway, my conclusion (?) is perhaps that a 'word' in a formula should
correspond to something like a 'term' in a mathematical expression.
How do you detect a term?
Andre'
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: You need to fix your window manager? SCNR Indeed. Save a few small changes I use the same configuration as 14 years ago. ok... and all new WM features since then are just crap? ;) Maybe it's just their documentation. For one, I've not yet figured out how to bind e.g. 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' and 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, going to the next screen to the left when necessary' in either KDE or Gnome. I even asked on usenet... It could be made less intrusive like the pink corners of the math boxes (instead of a 'solid' box...) Those corners are nice... which reminds me, do you remember that problem with extra space after the math-inset (the one where the extra space made you think that there was a real space, and then at the printout you got stuff like in this formula C=2you have) Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... Well, it's not easy to know if it's too much or not. That's one reason I think it would be good to be able to switch between modes... for that matter different people probably have different thresholds. Too much choice is bad as well. This holds for a novel or such, but even the random science paper has structure. And, btw, if you only have flat text you'll never see a box even with all-boxes. Now I'm confused... I don't write novels, but I am a book-aholic, and there's quite often markup (italics, bold etc) even in them. Some modern novels look awful due to too much markup btw. The average novel I read is just flat text with a heading every 20 pages or so. Anyway, this markup would show up as boxes wouldn't it? Yes. (and thus possibly impede the writer of that text). You lost me. If too much markup in a novel annoys you, so why do you try to use 'people need lots of markup in novels' as an argument? Andre'
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Sat, Dec 06, 2003 at 10:59:30AM +0200, Martin Vermeer wrote: This is actually not a bad idea. But we sort-of have this now already. In MathEd, I never delete anything but single characters straightaway. I don't dare to :-( If I want to delete a bracketed expression etc., I always select it first to see its extent. One could in the above situation make the first backspace invoke selection of the previous bracketed expression. I don't know how hard that is to implement. Straight-forward. Five lines at most. Andre'
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller wrote: Juergen Spitzmueller wrote: BTW is it possible to get rid of the space at the beginning of a char style inset? Apparently this has more than one source. One part of the problem is that the insettext inside the inset has indended paragraph if the document uses paragraph indendation. The main problem is the 20 pixel room for the [ nesting markers (which won't be needed in all-boxes btw) Andre'
Re: The current char style UI
On Sat, Dec 06, 2003 at 04:45:23PM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: What I'm telling you is that the problem goes completely away with ranges, because we then have a natural interface: Edit-Text_Style-Noun Emphasis Badger Other... | And? We just keep this. Clicking on this entry inserts a new inset of | this type. I am kindo with John, not that we must/should use ranges, but that the actual ui should not show that insets are used for this. In essence a LCS inset cannot just be a normal inset. Even as base for implementation? 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 Sat, Dec 06, 2003 at 04:53:05PM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | If the overlapping stuff is out and physical position == locical | position is in, all-boxes is (a) natural, (b) simple. I am not convinced... OTOH what I am convinced about is that we don't need to support overlapping stuff/nested LCS. Ah. Good. This would mean we could use insets for implementation if we manage to come up with some UI that mimics having one cursor position instead of the two (befor/after tha inset border). 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] move ParagraphList of InsetText and Buffer to LyXText
On Sat, Dec 06, 2003 at 04:59:29PM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | On Tue, Dec 02, 2003 at 04:49:26PM +0100, Lars Gullik Bjønnes wrote: Andre Poenitz [EMAIL PROTECTED] writes: | Step 2. Almost mechanical. I wonder why this is a good move. | Because it consolidates common code of InsetText and Buffer in a single | place (LyXText). But hasn't this rendered multiple views of the same buffer virtually impossible? No more difficult than before. The main text needs about the same per-view information as any other text inset (the only difference is that the main text starts always at (0,0), but that's not really worth a 'simplification' that duplicates lots of code'). 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: word-backward/forward in mathed
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Now back from the break, my suggestion is that we change the behaviour of word-backward/forward so that it uses something other spaces as word separators. One idea could be to use '+' and '-', essentially moving the cursor one term at a time in a formula. Andre This is close to useless. I have one-page-formulas where '+' Andre and '-' appear (at best) in some index computations. So going Andre to the begin of the current box is much more sensible than Andre searching for the next '+'. What word-backward/forward could to is jump over insets instead of entering them. The equivalent of a 'word' in mathed is an inset (a block) IMO. JMarc
Re: [PATCH] Inset VSpace for tex2lyx
On Sat, Dec 06, 2003 at 10:16:01PM +0100, Georg Baum wrote: Comments? Looks good. Andre'
Re: subscript not working in 1.4-xforms?
On Sun, Dec 07, 2003 at 01:46:47PM +0100, Christian Ridderström wrote: Hi Have the method of getting subscripts changed or something in 1.4 xforms? When I press '_' I actually get a '_' instead of a subscript? (Same thing goes for superscripts, '^' inserts a '^' :-( I see that, too. Something broke some black magic that were there before to ditinguish '_' in math and outside... Andre'
Re: [patch] text2.C
On Mon, Dec 08, 2003 at 02:04:53AM -0300, Alfredo Braunstein wrote: this is the same patch proposed a week ago. - don't use cursors for loops - rewrite some loops in a more standard way pretty uncontroversial. I'll apply tomorrow if there are no objections. Please do so. 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: word-backward/forward in mathed
On Mon, Dec 08, 2003 at 10:12:16AM +0100, Jean-Marc Lasgouttes wrote: What word-backward/forward could to is jump over insets instead of entering them. The equivalent of a 'word' in mathed is an inset (a block) IMO. It does so already. Andr'e
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Mon, Dec 08, 2003 at 09:46:16AM +0100, Andre Poenitz spake thusly: One could in the above situation make the first backspace invoke selection of the previous bracketed expression. I don't know how hard that is to implement. Straight-forward. Five lines at most. Which five lines? :-) - Martin pgp0.pgp Description: PGP signature
Re: The current char style UI
Andre Poenitz wrote: On Fri, Dec 05, 2003 at 02:06:10PM +0100, Helge Hafting wrote: [...] gave me a src/lyx that don't want keyboard input. I can't type, only move around and/or paste text. I thought this just was the sort of things that might happen when trying 1.4cvs versions. It shouldn't. Is this still there? Andre' I did a cvs update, compiled, and can now write normally. This time I noticed: * The scroll wheel on the mouse only work with the pointer over the scrollbar, not with the pointer over the main text. Ouch. And it crashes lyx after a while too. * The character styles is on another meny, but work the same way as in 1.3, i.e. overlapping ranges works and backspace don't do anything unusual. Aren't they new styles in 1.4cvs, or is my cvs set up wrong? * Help-about lyx says Lyx 1.4.0cvs Thu, Jan 30, 2003. This made me suspect a cvs setup error, or doesn't the date reflect the latest change? I believe I checked out lyx-devel using instructions on the developer website. These instructions weren't clear to me, particularly these two entries: lyx-devel This is the new development and stable branch. The development will progress in branches and the main trunk will stay stable. All future source code development will be done in this repository. lyx This is the unstable development branch, and is not in use anymore. Use this only if you know want to see in what direction LyX is going (e.g. the new LyX kernel). Expect this to crash frequently. So, is lyx-devel development or stable? (stable makes me think only fully developed tested stuff) Is lyx where I find the very latest (but unstable) kernel to test, or is it not in use anymore, i.e. totally obsolete, existing only for historical reasons? I went for lyx-devel, because that is where all future development happens despite being stable. I'm new to cvs, and confused. Helge Hafting
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Mon, Dec 08, 2003 at 12:12:51PM +0200, Martin Vermeer wrote:
Straight-forward. Five lines at most.
Which five lines?
:-)
Attached.
Actually, I even think this feature is usable.
Andre'
? .math_cursor.C.swp
? 1.diff
? cursor.diff
Index: math_cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_cursor.C,v
retrieving revision 1.368
diff -u -p -r1.368 math_cursor.C
--- math_cursor.C 1 Nov 2003 15:45:18 - 1.368
+++ math_cursor.C 8 Dec 2003 10:37:07 -
@@ -436,8 +436,12 @@ bool MathCursor::backspace()
}
}
- --pos();
- plainErase();
+ if (hasPrevAtom() prevAtom()-nargs() 0)
+ left(true);
+ else {
+ --pos();
+ plainErase();
+ }
return true;
}
Re: The current char style UI
On Mon, Dec 08, 2003 at 11:28:30AM +0100, Helge Hafting wrote: * Help-about lyx says Lyx 1.4.0cvs Thu, Jan 30, 2003. This made me suspect a cvs setup error, or doesn't the date reflect the latest change? That's ok. So, is lyx-devel development or stable? The former with the general goal to make it stable as well. Right now it isn't. I went for lyx-devel, because that is where all future development happens despite being stable. And unless there was a Don't use CVS right now warning posted to lyx-devel. You have to check [EMAIL PROTECTED] regularly to make your mind up yourself. Right now I would not recommend 1.4.0cvs for real work. I am using 1.3.3 myself. Andre'
Compilation failure in checkedwodgets.C with qt 2.3.0
I get the following error when compiling:
stlport -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt2 -I../../../src
-I../../../../lyx-devel/src/ -I../../../../lyx-devel/src/frontends/
-I../../../../lyx-devel/images -I/usr/lib/qt-2.3.0//include
-I../../../../lyx-devel/boost -I../../../../lyx-devel/src/frontends/controllers
-I/afs/rocq/home/preval/common/include -I/usr/X11R6/include -DQT_CLEAN_NAMESPACE
-DQT_GENUINE_STR -DQT_NO_TRANSLATION -fno-exceptions -ftemplate-depth-30
-Wno-non-template-friend -W -Wall -c
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C -MT checkedwidgets.lo -MD -MP
-MF .deps/checkedwidgets.TPlo
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C: In function `void
{unnamed}::setWidget (bool,
QLineEdit *, QLabel *)':
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C:36: no matching function for
call to
`QLineEdit::setPaletteForegroundColor (const QColor )'
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C:44: no matching function for
call to
`QLabel::setPaletteForegroundColor (const QColor )'
Angus, qt 2.3.0 does not have this setPaletteForegroundColor thing.
JMarc
Re: [patch] text2.C
Andre Poenitz wrote: Please do so. Done. Btw, for this month I'll be sort of very slow in the mornings... I'm ok: I've only suffered a timezone warp! Alfredo
[PATCH] Add drag-and-drop support to LyX/Qt 1.3.4cvs
I plan to apply this patch to 1.3.4cvs. This is already applied to
1.4.0cvs. Did anybody try drag and drop of .lyx files with 1.4.0cvs?
Did it work as expected?
JMarc
Index: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.322
diff -u -p -r1.322 BufferView_pimpl.C
--- src/BufferView_pimpl.C 23 Jan 2003 16:23:35 - 1.322
+++ src/BufferView_pimpl.C 4 Dec 2003 16:50:11 -
@@ -93,6 +93,7 @@ unsigned int const saved_positions_num =
// (Lgb)
boost::signals::connection dispatchcon;
+boost::signals::connection viewdispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
boost::signals::connection resizecon;
@@ -119,6 +120,8 @@ BufferView::Pimpl::Pimpl(BufferView * bv
.connect(boost::bind(BufferView::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
.connect(boost::bind(BufferView::Pimpl::dispatch, this, _1));
+ viewdispatchcon = workarea().viewDispatch
+ .connect(boost::bind(BufferView::Pimpl::viewDispatch, this, _1));
kpresscon = workarea().workAreaKeyPress
.connect(boost::bind(BufferView::Pimpl::workAreaKeyPress, this, _1, _2));
selectioncon = workarea().selectionRequested
@@ -912,6 +915,13 @@ void BufferView::Pimpl::MenuInsertLyXFil
#endif
owner_-message(STRCONV(str.str()));
}
+}
+
+
+bool BufferView::Pimpl::viewDispatch(FuncRequest const ev)
+{
+ owner_-dispatch(ev);
+ return true;
}
Index: src/BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.81
diff -u -p -r1.81 BufferView_pimpl.h
--- src/BufferView_pimpl.h 21 Oct 2002 00:15:48 - 1.81
+++ src/BufferView_pimpl.h 4 Dec 2003 16:50:11 -
@@ -102,6 +102,9 @@ struct BufferView::Pimpl : public boost:
void updateInset(Inset * inset, bool mark_dirty);
///
bool dispatch(FuncRequest const ev);
+ ///
+ bool viewDispatch(FuncRequest const ev);
+
private:
///
friend class BufferView;
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1021.2.23
diff -u -p -r1.1021.2.23 ChangeLog
--- src/ChangeLog 20 Nov 2003 14:13:03 - 1.1021.2.23
+++ src/ChangeLog 4 Dec 2003 16:50:13 -
@@ -1,3 +1,8 @@
+2003-12-04 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * BufferView_pimpl.C (viewDispatch): new method, called by the qt
+ drag-and-drop code.
+
2003-11-19 Angus Leeming [EMAIL PROTECTED]
* lyxtextclass.C (LyXTextClass): fix warning about variable
Index: src/frontends/WorkArea.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/WorkArea.h,v
retrieving revision 1.17
diff -u -p -r1.17 WorkArea.h
--- src/frontends/WorkArea.h 21 Oct 2002 17:38:07 - 1.17
+++ src/frontends/WorkArea.h 4 Dec 2003 16:50:13 -
@@ -72,6 +72,8 @@ public:
boost::signal2void, LyXKeySymPtr, key_modifier::state workAreaKeyPress;
/// some mouse event
boost::signal1void, FuncRequest dispatch;
+ /// used by drag-and-drop
+ boost::signal1bool, FuncRequest viewDispatch;
/// emitted when an X client has requested our selection
boost::signal0void selectionRequested;
/// emitted when another X client has stolen our selection
Index: src/frontends/qt2/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ChangeLog,v
retrieving revision 1.389.2.39
diff -u -p -r1.389.2.39 ChangeLog
--- src/frontends/qt2/ChangeLog 19 Nov 2003 16:32:49 - 1.389.2.39
+++ src/frontends/qt2/ChangeLog 4 Dec 2003 16:50:13 -
@@ -1,3 +1,9 @@
+2003-12-04 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * QWorkArea.C (QWorkArea):
+ (dragEnterEvent):
+ (dropEvent): add support for drag and drop of URIs
+
2003-11-14 Jean-Marc Lasgouttes [EMAIL PROTECTED]
* ui/QMathDialogBase.ui: remove mention of \frac in tooltip, since
Index: src/frontends/qt2/QWorkArea.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QWorkArea.C,v
retrieving revision 1.11
diff -u -p -r1.11 QWorkArea.C
--- src/frontends/qt2/QWorkArea.C 17 Dec 2002 20:37:10 - 1.11
+++ src/frontends/qt2/QWorkArea.C 4 Dec 2003 16:50:13 -
@@ -27,6 +27,7 @@
#include qapplication.h
#include qevent.h
+#include qdragobject.h
#include qpainter.h
#include qmainwindow.h
#include qlayout.h
@@ -53,6 +54,7 @@ QWorkArea::QWorkArea(int, int, int, int)
(static_castQMainWindow*(qApp-mainWidget()))-setCentralWidget(this);
setFocusProxy(content_);
+ setAcceptDrops(true);
content_-show();
@@ -143,4 +145,25 @@ void QWorkArea::putClipboard(string cons
QApplication::clipboard()-setSelectionMode(true);
#endif
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Mon, 8 Dec 2003, Andre Poenitz wrote: On Mon, Dec 08, 2003 at 12:12:51PM +0200, Martin Vermeer wrote: Straight-forward. Five lines at most. Which five lines? :-) Attached. Actually, I even think this feature is usable. Not bad... I think this should be applied. Perhaps unrelated: If you do Ctrl-q when in a math-inset and discard the changes, lyx says it caught a bug once it has quit. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
[PATCH] Allow double-clicking on file to launch LyX/Mac
Since nobody read my previous patch for dnd support in lyx/qt, here is
a second one that adds support for AppleEvent OpenDocuments.
Basically, with this one can double-click a file in the finder and
have the file open in a running LyX.
This second patch has been written by Ronald Florence, who found some
example code on the net and managed to make it work for LyX.
The patch is not too large, but it has a slightly ugly hack: in
QWorkArea.C, a plain C function has to know what the current workarea
is, and thus uses a global variable wa_ptr (already used in some X11
event handler) to call dispatch. I'd be glad to change this scheme if
somebody has a better idea (John?).
If nobody complains, this will go in 1.3.4cvs soon, and Ronald will
adapt it to 1.4.0cvs later.
JMarc
Index: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.322
diff -u -p -r1.322 BufferView_pimpl.C
--- src/BufferView_pimpl.C 23 Jan 2003 16:23:35 - 1.322
+++ src/BufferView_pimpl.C 8 Dec 2003 13:42:19 -
@@ -93,6 +93,7 @@ unsigned int const saved_positions_num =
// (Lgb)
boost::signals::connection dispatchcon;
+boost::signals::connection viewdispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
boost::signals::connection resizecon;
@@ -119,6 +120,8 @@ BufferView::Pimpl::Pimpl(BufferView * bv
.connect(boost::bind(BufferView::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
.connect(boost::bind(BufferView::Pimpl::dispatch, this, _1));
+ viewdispatchcon = workarea().viewDispatch
+ .connect(boost::bind(BufferView::Pimpl::viewDispatch, this, _1));
kpresscon = workarea().workAreaKeyPress
.connect(boost::bind(BufferView::Pimpl::workAreaKeyPress, this, _1, _2));
selectioncon = workarea().selectionRequested
@@ -912,6 +915,13 @@ void BufferView::Pimpl::MenuInsertLyXFil
#endif
owner_-message(STRCONV(str.str()));
}
+}
+
+
+bool BufferView::Pimpl::viewDispatch(FuncRequest const ev)
+{
+ owner_-dispatch(ev);
+ return true;
}
Index: src/BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.81
diff -u -p -r1.81 BufferView_pimpl.h
--- src/BufferView_pimpl.h 21 Oct 2002 00:15:48 - 1.81
+++ src/BufferView_pimpl.h 8 Dec 2003 13:42:19 -
@@ -102,6 +102,9 @@ struct BufferView::Pimpl : public boost:
void updateInset(Inset * inset, bool mark_dirty);
///
bool dispatch(FuncRequest const ev);
+ ///
+ bool viewDispatch(FuncRequest const ev);
+
private:
///
friend class BufferView;
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1021.2.23
diff -u -p -r1.1021.2.23 ChangeLog
--- src/ChangeLog 20 Nov 2003 14:13:03 - 1.1021.2.23
+++ src/ChangeLog 8 Dec 2003 13:42:21 -
@@ -1,3 +1,8 @@
+2003-12-04 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * BufferView_pimpl.C (viewDispatch): new method, called by the qt
+ drag-and-drop code.
+
2003-11-19 Angus Leeming [EMAIL PROTECTED]
* lyxtextclass.C (LyXTextClass): fix warning about variable
Index: src/frontends/WorkArea.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/WorkArea.h,v
retrieving revision 1.17
diff -u -p -r1.17 WorkArea.h
--- src/frontends/WorkArea.h 21 Oct 2002 17:38:07 - 1.17
+++ src/frontends/WorkArea.h 8 Dec 2003 13:42:21 -
@@ -72,6 +72,8 @@ public:
boost::signal2void, LyXKeySymPtr, key_modifier::state workAreaKeyPress;
/// some mouse event
boost::signal1void, FuncRequest dispatch;
+ /// used by drag-and-drop
+ boost::signal1bool, FuncRequest viewDispatch;
/// emitted when an X client has requested our selection
boost::signal0void selectionRequested;
/// emitted when another X client has stolen our selection
Index: src/frontends/qt2/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ChangeLog,v
retrieving revision 1.389.2.40
diff -u -p -r1.389.2.40 ChangeLog
--- src/frontends/qt2/ChangeLog 5 Dec 2003 10:00:18 - 1.389.2.40
+++ src/frontends/qt2/ChangeLog 8 Dec 2003 13:42:21 -
@@ -1,3 +1,16 @@
+2003-12-08 Ronald Florence [EMAIL PROTECTED]
+
+ * QWorkArea.C (checkAppleEventForMissingParams)
+ (handleOpenDocuments): add support for OpenDocuments apple event
+
+ * lyx_gui.C (macEventFilter): handle apple events
+
+2003-12-04 Jean-Marc Lasgouttes [EMAIL PROTECTED]
+
+ * QWorkArea.C (QWorkArea):
+ (dragEnterEvent):
+ (dropEvent): add support for drag and drop of URIs
+
2003-12-05 Juergen Spitzmueller [EMAIL PROTECTED]
* QDocument.C: use geometry on custom, A3, B3 and B4
Index: src/frontends/qt2/QWorkArea.C
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
On Mon, Dec 08, 2003 at 05:51:14PM +0100, Jean-Marc Lasgouttes wrote: Since nobody read my previous patch for dnd support in lyx/qt, here is a second one that adds support for AppleEvent OpenDocuments. That's wrong. I read it. But I did not even understand what you were talking about let alone able to judge the implications of this patch. Andre'
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
-BEGIN PGP SIGNED MESSAGE- On Montag, 8. Dezember 2003 18:04, Andre Poenitz wrote: On Mon, Dec 08, 2003 at 05:51:14PM +0100, Jean-Marc Lasgouttes wrote: Since nobody read my previous patch for dnd support in lyx/qt, here is a second one that adds support for AppleEvent OpenDocuments. That's wrong. I read it. But I did not even understand what you were talking about let alone able to judge the implications of this patch. I did not read, but I tested it with the qt-lyx. For me it worked as expected (using konqueror for drag and lyx to drop into) Andre' Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP9SwiLewfbDGmeqhAQEVoAP/VVUHGmtEppyIStKTgpDhkK88qoNaXuoV 3vp9Bv2SVZ5LHJjDk/sR9K9CLIW+GSsJFsbGCfCUpxnHfDocSxWU+Vvs3eV0cWXB mwFTXDyOdJ1TJ9bIJ0H9GR5OHwPBgNnC0O4pffSEFm0osHPomKp/FWObgzSbdWth /EuYe/sIRTU= =lAgS -END PGP SIGNATURE-
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Andre On Mon, Dec 08, 2003 at 05:51:14PM +0100, Jean-Marc Lasgouttes Andre wrote: Since nobody read my previous patch for dnd support in lyx/qt, here is a second one that adds support for AppleEvent OpenDocuments. Andre That's wrong. I know, but what do you want me to do to get a reaction? ;) Andre I read it. But I did not even understand what you were talking Andre about let alone able to judge the implications of this patch. OK. Basically the dnd patch does what trolltech tell us to do to implement drag-n-drop. The only LyX related thing here is that we need a way to dispatch LFUN_FILE_OPEN from WorkArea. To this end, I added a new workarea signal that calls LyXView::dispatch. Note that this code is already in 1.4.0cvs, but that it has a slightly different form. What I have in this patch was the simplest alternative. For the other patch, we have to be able to intercept the OS X events. To this end, one overrides QApplication::macEventFilter so that it actually does something with the events. Then, in QWorkarea.C I have a free-standing event handler (and an auxiliary function) that do the actual work of decoding the OpenDocuments event and sending it to WorkArea::viewDispatch. The dnd code should work on any qt version (platform independent) The macEvent code is only compiled on Qt/Mac. So, I think that the implications are not a problem, but that it can probably be written in a cleaner way... Does this help? JMarc
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
Kornel == Kornel Benko [EMAIL PROTECTED] writes: Kornel I did not read, but I tested it with the qt-lyx. For me it Kornel worked as expected (using konqueror for drag and lyx to drop Kornel into) Yes, this works here too (with qt 2.3.0). JMarc
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
On Mon, Dec 08, 2003 at 06:26:17PM +0100, Jean-Marc Lasgouttes wrote: So, I think that the implications are not a problem, but that it can probably be written in a cleaner way... *shrug* Didn't look like the messiest part of LyX... Does this help? A bit. But I still can't answer anything else than 'does not look wrong, does not sound wrong...' Andre'
Re: Compilation failure in checkedwodgets.C with qt 2.3.0
Jean-Marc Lasgouttes wrote: Angus, qt 2.3.0 does not have this setPaletteForegroundColor thing. Shame! Ahhh well. It's just a bit of fun and not vital to the use of the class. I'll wrap the contents of setWidget up inside some 3ifdef magic for now. -- Angus
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
Andre == Andre Poenitz [EMAIL PROTECTED] writes: Does this help? Andre A bit. But I still can't answer anything else than 'does not Andre look wrong, does not sound wrong...' I understand that. I am just posting to see whether ideas emerge :) I'll probably commit that to 1.3.4cvs tomorrow. JMarc
Re: CharStyle discussion
On Sunday 07 December 2003 06:53 am, you wrote: On Sat, Dec 06, 2003 at 03:03:42PM -0500, Kuba Ober wrote: There will also be some constraints as to how far a character style can go. I imagine we will artificially need to terminate all character styling at the end of the paragraph, otherwise it'll be an uncontainable mess. This may actually make sense for logical formatting - typically, you're making a word/sentence bolded, not the whole document; if it's the whole document you should adjust the default paragraph style properties (in LyX's case it would be more like document properties). I haven't read the whole thread yet, so if my points have already been raised, feel free to ignore me :) Well, there is the point that a quotation occationally will contain a few short paragraphs, so using the paragraph end as a limit won't work well. People do select two and a half paragraph in order to apply a style. Perhaps not often, but it do happen. It is nice if it works, even if the code have to create several insets for the multiple paragraphs. Oh yes, then certainly it will work like that. Another way of doing it is instead of having character style insets just have character style flags and have the core do the job. I.e. have bold on and bold off flags. Obviously their manipulation will need some equilibristic skills. I guess that implementation with insets is just plain easier, and making the insets behave to the user as expected should involve less work than keeping state of the flags sprinkled around the text. Kuba
Re: dvipng reports baseline
Jan-Åke Larsson wrote: > Angus Leeming wrote: > > 1. Here I had colour specials in the latex file. In future I will not > > need them, right? Instead I'll pass them direct to dvipng, as above. > > Yes. You can do either. The DVI colors are preferred, of course. > > 2. I should prefer your -depth and -height flags, extracting the > > metrics info from the output above, rather than extracting it from > > the latex log file? Reason: the log file info is going to be wrong if > > I invoke dvipng with the '-T tight' option, right? (and I would like > > to do so so that I can strip off the front margin of a displaystyle > > equation). > > There are actually three ways to determine the boundingboxes. > > 1) "-T tight" which would make "-depth -height" necessary. You'd get > the boundingbox determined from the ink of the image. > > 2) From the output I see you have used the "tightpage" option to > preview, I have code lying around that will take the boundingboxes > from the specials instead, do you want that? > > 3) "dvipng -" will fire up the stdin interface where you > could input the dimensions yourself per page, as obtained from the > latex run. Once the stdin interface is up you give > "-T 1in,1in -O 40sp,30sp -pp1" and then "-T 3cm,3cm -O 3pt,5pt -pp2" > and so on. In case 2) and 3) you can of course give --depth and read the _pixel_ depth off dvipng's stdout. I was also thinking of doing 2b) and 3b) by allowing the bbox to grow from the (-T) specified bbox to include all ink produced by the DVI. This would eliminate shaved edges, while still keeping the specified bbox, whitespace and such. Opinions? /JÅ -- Linux: The choice of a GNU generation.
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Fri, Dec 05, 2003 at 07:49:38PM +0100, Christian Ridderström wrote:
> I agree with Helge here, and it reminded me of a behaviour that's
> sometimes annoying in mathed. It happens quite often that I delete the
> previous 'box' without intending to when using the backspace key. An
> example (just imagine that the latex is actually math in mathed, and '|'
> is the cursor):
>
> a^2+\textrm{aFunction}|
>
> Pressing backspace now, leaves me with a measly a^2+ :-(
>
> Anyway, I just remembered that this is something that frequently has
> annoyed me. Not that I know what to do about it though, because at other
> times it's really convenient to be able to delete an entire block at
> once...
>
> It would be nice if our keyboards were force sensitive sometimes.. then
> I could simply press backspace a bit harder to get it to delete a block.
>
> A blue sky idea here might be to have a single backspace keypress delete a
> simple 'character' to the left if there is one, and if there's a 'box' to
> the left, you have to press backspace twice?
This gives the impression your keyboard is stuck. I tried this already.
The most annoying 'feature' in this area is that undo does not set the
cursor properly...
> now when you press backspace, the textinset isn't deleted, but highlighted
> and a cute text shows up on the statusbar saying "Press delete again to
> actually delete".
>
> a^2+\textrm{aFunction}|
> \---delete?--\
>
> and then when you press delete again, you end up with
Hm... highlighting might indeed be an option as the first backspace is
not silently swallowed.
Andre'
Re: word-backward/forward in mathed
On Fri, Dec 05, 2003 at 07:29:18PM +0100, Christian Ridderström wrote:
> This started in some charStyle thread... it is about a suggestion to
> change the behaviour of C-left/right in mathed (aka word-backward/forward)
>
> Originally I was (approx.) complaining that it takes a lot of left/right's
> to move in mathed because of all the boundaries you have to cross.
> Then I suggested that maybe C-left/right could be used to move at a
> 'courser' level...
>
> [Brief interlude in the dialog were we are informed of Andre's 14 year
> old configuration of his window manager - it steals his C-left/right)
[It doesn't steal it. It does what it is supposed to do...]
> Now back from the break, my suggestion is that we change the behaviour of
> word-backward/forward so that it uses something other spaces as word
> separators. One idea could be to use '+' and '-', essentially moving the
> cursor one term at a time in a formula.
This is close to useless. I have one-page-formulas where '+' and '-'
appear (at best) in some index computations. So going to the begin of
the current box is much more sensible than searching for the next '+'.
> While on the subject, something's rotten in Denmark.. mathed, since
>
> line-beginning/end
>
> behave the same as
>
> word-backward/forward
>
> as far as I can tell.
Such things could be proven quickly by looking at the source.
> Both move the cursor to the first or last position
> of the mathed box, and this seems pointless to me.
Better idea?
> In fact, even inside \textrm{adsfas asdf asfd} word-backward/forward
> doesn't work (i.e. go to the next word separated by a space).
Mathed has almost no idea what a 'word' or a 'space' is.
> Anyway, my conclusion (?) is perhaps that a 'word' in a formula should
> correspond to something like a 'term' in a mathematical expression.
How do you detect a term?
Andre'
Re: CharStyle discussion
On Fri, Dec 05, 2003 at 08:19:16PM +0100, Christian Ridderström wrote: > > > You need to fix your window manager? SCNR > > > > Indeed. Save a few small changes I use the same configuration as 14 > > years ago. > > ok... and all new WM features since then are just crap? ;) Maybe it's just their documentation. For one, I've not yet figured out how to bind e.g. 'Ctrl-Left' to 'move mouse cursor one virtual screen to the left' and 'Alt-Left' to 'move mouse cursor half a virtual screen to the left, going to the next screen to the left when necessary' in either KDE or Gnome. I even asked on usenet... > > It could be made less intrusive like the pink corners of the math boxes > > (instead of a 'solid' box...) > > Those corners are nice... which reminds me, do you remember that problem > with extra space after the math-inset (the one where the extra space made > you think that there was a real space, and then at the printout you got > stuff like "in this formula C=2you have") Yes, I run into this regularly myself. But that's just the usual 2 point box space acculmulated by nested boxes... Maybe going down to 1 would help already... > Well, it's not easy to know if it's too much or not. That's one reason I > think it would be good to be able to switch between modes... for that > matter different people probably have different thresholds. Too much choice is bad as well. > > This holds for a novel or such, but even the random science paper has > > structure. And, btw, if you only have flat text you'll never see a box > > even with all-boxes. > > Now I'm confused... I don't write novels, but I am a book-aholic, and > there's quite often markup (italics, bold etc) even in them. Some modern > novels look awful due to too much markup btw. The average novel I read is just flat text with a heading every 20 pages or so. > Anyway, this markup would show up as boxes wouldn't it? Yes. > (and thus possibly impede the writer of that text). You lost me. If too much markup in a novel annoys you, so why do you try to use 'people need lots of markup in novels' as an argument? Andre'
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Sat, Dec 06, 2003 at 10:59:30AM +0200, Martin Vermeer wrote: > This is actually not a bad idea. But we sort-of have this now already. > In MathEd, I never delete anything but single characters straightaway. > I don't dare to :-( If I want to delete a bracketed expression etc., I > always select it first to see its extent. > > One could in the above situation make the first backspace invoke > selection of the previous bracketed expression. I don't know how hard > that is to implement. Straight-forward. Five lines at most. Andre'
Re: [Patch] Re: [Patch] Re: CharStyle discussion
On Sat, Dec 06, 2003 at 01:10:29PM +0100, Juergen Spitzmueller wrote: > Juergen Spitzmueller wrote: > > BTW is it possible to get rid of the space at the beginning of a char style > > inset? > > Apparently this has more than one source. One part of the problem is that the > insettext inside the inset has indended paragraph if the document uses > paragraph indendation. The main problem is the 20 pixel room for the [ nesting markers (which won't be needed in all-boxes btw) Andre'
Re: The current char style UI
On Sat, Dec 06, 2003 at 04:45:23PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > >> What I'm telling you is that the problem goes completely away with > >> ranges, because we then have a natural interface: > >> > >> Edit->Text_Style->Noun > >> Emphasis > >> Badger > >> Other... > > > | And? We just keep this. Clicking on this entry inserts a new inset of > | this type. > > I am kindo with John, not that we must/should use ranges, but that the > actual ui should not show that insets are used for this. In essence a > LCS "inset" cannot just be a normal inset. Even as base for implementation? 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 Sat, Dec 06, 2003 at 04:53:05PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | If the overlapping stuff is out and physical position == locical > | position is in, all-boxes is (a) natural, (b) simple. > > I am not convinced... > > OTOH what I am convinced about is that we don't need to support > overlapping stuff/nested LCS. Ah. Good. This would mean we could use insets for implementation if we manage to come up with some UI that mimics having one cursor position instead of the two (befor/after tha inset border). 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] move ParagraphList of InsetText and Buffer to LyXText
On Sat, Dec 06, 2003 at 04:59:29PM +0100, Lars Gullik Bjønnes wrote: > Andre Poenitz <[EMAIL PROTECTED]> writes: > > | On Tue, Dec 02, 2003 at 04:49:26PM +0100, Lars Gullik Bjønnes wrote: > >> Andre Poenitz <[EMAIL PROTECTED]> writes: > >> > >> | Step 2. Almost mechanical. > >> > >> I wonder why this is a good move. > > > | Because it consolidates common code of InsetText and Buffer in a single > | place (LyXText). > > But hasn't this rendered multiple views of the same buffer virtually > impossible? No more difficult than before. The main text needs about the same per-view information as any other text inset (the only difference is that the main text starts always at (0,0), but that's not really worth a 'simplification' that duplicates lots of code'). 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: word-backward/forward in mathed
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> Now back from the break, my suggestion is that we change the >> behaviour of word-backward/forward so that it uses something other >> spaces as word separators. One idea could be to use '+' and '-', >> essentially moving the cursor one term at a time in a formula. Andre> This is close to useless. I have one-page-formulas where '+' Andre> and '-' appear (at best) in some index computations. So going Andre> to the begin of the current box is much more sensible than Andre> searching for the next '+'. What word-backward/forward could to is jump over insets instead of entering them. The equivalent of a 'word' in mathed is an inset (a block) IMO. JMarc
Re: [PATCH] Inset VSpace for tex2lyx
On Sat, Dec 06, 2003 at 10:16:01PM +0100, Georg Baum wrote: > Comments? Looks good. Andre'
Re: subscript not working in 1.4-xforms?
On Sun, Dec 07, 2003 at 01:46:47PM +0100, Christian Ridderström wrote: > Hi > > Have the method of getting subscripts changed or something in 1.4 xforms? > When I press '_' I actually get a '_' instead of a subscript? > (Same thing goes for superscripts, '^' inserts a '^' :-( I see that, too. Something broke some black magic that were there before to ditinguish '_' in math and outside... Andre'
Re: [patch] text2.C
On Mon, Dec 08, 2003 at 02:04:53AM -0300, Alfredo Braunstein wrote: > this is the same patch proposed a week ago. > > - don't use cursors for loops > - rewrite some loops in a more standard way > > pretty uncontroversial. > > I'll apply tomorrow if there are no objections. Please do so. 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: word-backward/forward in mathed
On Mon, Dec 08, 2003 at 10:12:16AM +0100, Jean-Marc Lasgouttes wrote: > What word-backward/forward could to is jump over insets instead of > entering them. The equivalent of a 'word' in mathed is an inset (a > block) IMO. It does so already. Andr'e
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Mon, Dec 08, 2003 at 09:46:16AM +0100, Andre Poenitz spake thusly: > > One could in the above situation make the first backspace invoke > > selection of the previous bracketed expression. I don't know how hard > > that is to implement. > > Straight-forward. Five lines at most. Which five lines? :-) - Martin pgp0.pgp Description: PGP signature
Re: The current char style UI
Andre Poenitz wrote: On Fri, Dec 05, 2003 at 02:06:10PM +0100, Helge Hafting wrote: [...] gave me a src/lyx that don't want keyboard input. I can't type, only move around and/or paste text. I thought this just was the sort of things that might happen when trying 1.4cvs versions. It shouldn't. Is this still there? Andre' I did a cvs update, compiled, and can now write normally. This time I noticed: * The scroll wheel on the mouse only work with the pointer over the scrollbar, not with the pointer over the main text. Ouch. And it crashes lyx after a while too. * The character styles is on another meny, but work the same way as in 1.3, i.e. overlapping ranges works and backspace don't do anything unusual. Aren't they new styles in 1.4cvs, or is my cvs set up wrong? * Help->about lyx says Lyx 1.4.0cvs Thu, Jan 30, 2003. This made me suspect a cvs setup error, or doesn't the date reflect the latest change? I believe I checked out "lyx-devel" using instructions on the developer website. These instructions weren't clear to me, particularly these two entries: lyx-devel This is the new development and stable branch. The development will progress in branches and the main trunk will stay stable. All future source code development will be done in this repository. lyx This is the unstable development branch, and is not in use anymore. Use this only if you know want to see in what direction LyX is going (e.g. the new LyX kernel). Expect this to crash frequently. So, is "lyx-devel" development or stable? (stable makes me think "only fully developed & tested stuff") Is "lyx" where I find the very latest (but unstable) kernel to test, or is it "not in use anymore", i.e. totally obsolete, existing only for historical reasons? I went for lyx-devel, because that is where "all future development happens" despite being "stable". I'm new to cvs, and confused. Helge Hafting
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Mon, Dec 08, 2003 at 12:12:51PM +0200, Martin Vermeer wrote:
> > Straight-forward. Five lines at most.
>
> Which five lines?
>
> :-)
Attached.
Actually, I even think this feature is usable.
Andre'
? .math_cursor.C.swp
? 1.diff
? cursor.diff
Index: math_cursor.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/mathed/math_cursor.C,v
retrieving revision 1.368
diff -u -p -r1.368 math_cursor.C
--- math_cursor.C 1 Nov 2003 15:45:18 - 1.368
+++ math_cursor.C 8 Dec 2003 10:37:07 -
@@ -436,8 +436,12 @@ bool MathCursor::backspace()
}
}
- --pos();
- plainErase();
+ if (hasPrevAtom() && prevAtom()->nargs() > 0)
+ left(true);
+ else {
+ --pos();
+ plainErase();
+ }
return true;
}
Re: The current char style UI
On Mon, Dec 08, 2003 at 11:28:30AM +0100, Helge Hafting wrote: > * Help->about lyx says Lyx 1.4.0cvs Thu, Jan 30, 2003. This made me suspect > a cvs setup error, or doesn't the date reflect the latest change? That's "ok". > So, is "lyx-devel" development or stable? The former with the general goal to make it stable as well. Right now it isn't. > I went for lyx-devel, because that is where "all future development > happens" despite being "stable". And unless there was a "Don't use CVS right now" warning posted to lyx-devel. You have to check [EMAIL PROTECTED] regularly to make your mind up yourself. Right now I would not recommend 1.4.0cvs for real work. I am using 1.3.3 myself. Andre'
Compilation failure in checkedwodgets.C with qt 2.3.0
I get the following error when compiling:
stlport -DHAVE_CONFIG_H -I. -I../../../../lyx-devel/src/frontends/qt2 -I../../../src
-I../../../../lyx-devel/src/ -I../../../../lyx-devel/src/frontends/
-I../../../../lyx-devel/images -I/usr/lib/qt-2.3.0//include
-I../../../../lyx-devel/boost -I../../../../lyx-devel/src/frontends/controllers
-I/afs/rocq/home/preval/common/include -I/usr/X11R6/include -DQT_CLEAN_NAMESPACE
-DQT_GENUINE_STR -DQT_NO_TRANSLATION -fno-exceptions -ftemplate-depth-30
-Wno-non-template-friend -W -Wall -c
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C -MT checkedwidgets.lo -MD -MP
-MF .deps/checkedwidgets.TPlo
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C: In function `void
{unnamed}::setWidget (bool,
QLineEdit *, QLabel *)':
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C:36: no matching function for
call to
`QLineEdit::setPaletteForegroundColor (const QColor &)'
../../../../lyx-devel/src/frontends/qt2/checkedwidgets.C:44: no matching function for
call to
`QLabel::setPaletteForegroundColor (const QColor &)'
Angus, qt 2.3.0 does not have this setPaletteForegroundColor thing.
JMarc
Re: [patch] text2.C
Andre Poenitz wrote: > Please do so. Done. Btw, for this month I'll be sort of "very slow in the mornings"... I'm ok: I've only suffered a timezone warp! Alfredo
[PATCH] Add drag-and-drop support to LyX/Qt 1.3.4cvs
I plan to apply this patch to 1.3.4cvs. This is already applied to
1.4.0cvs. Did anybody try drag and drop of .lyx files with 1.4.0cvs?
Did it work as expected?
JMarc
Index: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.322
diff -u -p -r1.322 BufferView_pimpl.C
--- src/BufferView_pimpl.C 23 Jan 2003 16:23:35 - 1.322
+++ src/BufferView_pimpl.C 4 Dec 2003 16:50:11 -
@@ -93,6 +93,7 @@ unsigned int const saved_positions_num =
// (Lgb)
boost::signals::connection dispatchcon;
+boost::signals::connection viewdispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
boost::signals::connection resizecon;
@@ -119,6 +120,8 @@ BufferView::Pimpl::Pimpl(BufferView * bv
.connect(boost::bind(::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
.connect(boost::bind(::Pimpl::dispatch, this, _1));
+ viewdispatchcon = workarea().viewDispatch
+ .connect(boost::bind(::Pimpl::viewDispatch, this, _1));
kpresscon = workarea().workAreaKeyPress
.connect(boost::bind(::Pimpl::workAreaKeyPress, this, _1, _2));
selectioncon = workarea().selectionRequested
@@ -912,6 +915,13 @@ void BufferView::Pimpl::MenuInsertLyXFil
#endif
owner_->message(STRCONV(str.str()));
}
+}
+
+
+bool BufferView::Pimpl::viewDispatch(FuncRequest const & ev)
+{
+ owner_->dispatch(ev);
+ return true;
}
Index: src/BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.81
diff -u -p -r1.81 BufferView_pimpl.h
--- src/BufferView_pimpl.h 21 Oct 2002 00:15:48 - 1.81
+++ src/BufferView_pimpl.h 4 Dec 2003 16:50:11 -
@@ -102,6 +102,9 @@ struct BufferView::Pimpl : public boost:
void updateInset(Inset * inset, bool mark_dirty);
///
bool dispatch(FuncRequest const & ev);
+ ///
+ bool viewDispatch(FuncRequest const & ev);
+
private:
///
friend class BufferView;
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1021.2.23
diff -u -p -r1.1021.2.23 ChangeLog
--- src/ChangeLog 20 Nov 2003 14:13:03 - 1.1021.2.23
+++ src/ChangeLog 4 Dec 2003 16:50:13 -
@@ -1,3 +1,8 @@
+2003-12-04 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * BufferView_pimpl.C (viewDispatch): new method, called by the qt
+ drag-and-drop code.
+
2003-11-19 Angus Leeming <[EMAIL PROTECTED]>
* lyxtextclass.C (LyXTextClass): fix warning about variable
Index: src/frontends/WorkArea.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/WorkArea.h,v
retrieving revision 1.17
diff -u -p -r1.17 WorkArea.h
--- src/frontends/WorkArea.h 21 Oct 2002 17:38:07 - 1.17
+++ src/frontends/WorkArea.h 4 Dec 2003 16:50:13 -
@@ -72,6 +72,8 @@ public:
boost::signal2 workAreaKeyPress;
/// some mouse event
boost::signal1 dispatch;
+ /// used by drag-and-drop
+ boost::signal1 viewDispatch;
/// emitted when an X client has requested our selection
boost::signal0 selectionRequested;
/// emitted when another X client has stolen our selection
Index: src/frontends/qt2/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ChangeLog,v
retrieving revision 1.389.2.39
diff -u -p -r1.389.2.39 ChangeLog
--- src/frontends/qt2/ChangeLog 19 Nov 2003 16:32:49 - 1.389.2.39
+++ src/frontends/qt2/ChangeLog 4 Dec 2003 16:50:13 -
@@ -1,3 +1,9 @@
+2003-12-04 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * QWorkArea.C (QWorkArea):
+ (dragEnterEvent):
+ (dropEvent): add support for drag and drop of URIs
+
2003-11-14 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
* ui/QMathDialogBase.ui: remove mention of \frac in tooltip, since
Index: src/frontends/qt2/QWorkArea.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/QWorkArea.C,v
retrieving revision 1.11
diff -u -p -r1.11 QWorkArea.C
--- src/frontends/qt2/QWorkArea.C 17 Dec 2002 20:37:10 - 1.11
+++ src/frontends/qt2/QWorkArea.C 4 Dec 2003 16:50:13 -
@@ -27,6 +27,7 @@
#include
#include
+#include
#include
#include
#include
@@ -53,6 +54,7 @@ QWorkArea::QWorkArea(int, int, int, int)
(static_cast(qApp->mainWidget()))->setCentralWidget(this);
setFocusProxy(content_);
+ setAcceptDrops(true);
content_->show();
@@ -143,4 +145,25 @@ void QWorkArea::putClipboard(string cons
QApplication::clipboard()->setSelectionMode(true);
#endif
QApplication::clipboard()->setText(toqstr(str));
+}
+
+
+void QWorkArea::dragEnterEvent(QDragEnterEvent * event)
+{
+
Re: annoying mathed-behaviour (was Re: The current char style UI)
On Mon, 8 Dec 2003, Andre Poenitz wrote: > On Mon, Dec 08, 2003 at 12:12:51PM +0200, Martin Vermeer wrote: > > > Straight-forward. Five lines at most. > > > > Which five lines? > > > > :-) > > Attached. > > Actually, I even think this feature is usable. Not bad... I think this should be applied. Perhaps unrelated: If you do Ctrl-q when in a math-inset and discard the changes, lyx says it caught a bug once it has quit. /Christian -- Christian Ridderström http://www.md.kth.se/~chr
[PATCH] Allow double-clicking on file to launch LyX/Mac
Since nobody read my previous patch for dnd support in lyx/qt, here is
a second one that adds support for AppleEvent OpenDocuments.
Basically, with this one can double-click a file in the finder and
have the file open in a running LyX.
This second patch has been written by Ronald Florence, who found some
example code on the net and managed to make it work for LyX.
The patch is not too large, but it has a slightly ugly hack: in
QWorkArea.C, a plain C function has to know what the current workarea
is, and thus uses a global variable wa_ptr (already used in some X11
event handler) to call dispatch. I'd be glad to change this scheme if
somebody has a better idea (John?).
If nobody complains, this will go in 1.3.4cvs soon, and Ronald will
adapt it to 1.4.0cvs later.
JMarc
Index: src/BufferView_pimpl.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.C,v
retrieving revision 1.322
diff -u -p -r1.322 BufferView_pimpl.C
--- src/BufferView_pimpl.C 23 Jan 2003 16:23:35 - 1.322
+++ src/BufferView_pimpl.C 8 Dec 2003 13:42:19 -
@@ -93,6 +93,7 @@ unsigned int const saved_positions_num =
// (Lgb)
boost::signals::connection dispatchcon;
+boost::signals::connection viewdispatchcon;
boost::signals::connection timecon;
boost::signals::connection doccon;
boost::signals::connection resizecon;
@@ -119,6 +120,8 @@ BufferView::Pimpl::Pimpl(BufferView * bv
.connect(boost::bind(::Pimpl::workAreaResize, this));
dispatchcon = workarea().dispatch
.connect(boost::bind(::Pimpl::dispatch, this, _1));
+ viewdispatchcon = workarea().viewDispatch
+ .connect(boost::bind(::Pimpl::viewDispatch, this, _1));
kpresscon = workarea().workAreaKeyPress
.connect(boost::bind(::Pimpl::workAreaKeyPress, this, _1, _2));
selectioncon = workarea().selectionRequested
@@ -912,6 +915,13 @@ void BufferView::Pimpl::MenuInsertLyXFil
#endif
owner_->message(STRCONV(str.str()));
}
+}
+
+
+bool BufferView::Pimpl::viewDispatch(FuncRequest const & ev)
+{
+ owner_->dispatch(ev);
+ return true;
}
Index: src/BufferView_pimpl.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/BufferView_pimpl.h,v
retrieving revision 1.81
diff -u -p -r1.81 BufferView_pimpl.h
--- src/BufferView_pimpl.h 21 Oct 2002 00:15:48 - 1.81
+++ src/BufferView_pimpl.h 8 Dec 2003 13:42:19 -
@@ -102,6 +102,9 @@ struct BufferView::Pimpl : public boost:
void updateInset(Inset * inset, bool mark_dirty);
///
bool dispatch(FuncRequest const & ev);
+ ///
+ bool viewDispatch(FuncRequest const & ev);
+
private:
///
friend class BufferView;
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.1021.2.23
diff -u -p -r1.1021.2.23 ChangeLog
--- src/ChangeLog 20 Nov 2003 14:13:03 - 1.1021.2.23
+++ src/ChangeLog 8 Dec 2003 13:42:21 -
@@ -1,3 +1,8 @@
+2003-12-04 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * BufferView_pimpl.C (viewDispatch): new method, called by the qt
+ drag-and-drop code.
+
2003-11-19 Angus Leeming <[EMAIL PROTECTED]>
* lyxtextclass.C (LyXTextClass): fix warning about variable
Index: src/frontends/WorkArea.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/WorkArea.h,v
retrieving revision 1.17
diff -u -p -r1.17 WorkArea.h
--- src/frontends/WorkArea.h 21 Oct 2002 17:38:07 - 1.17
+++ src/frontends/WorkArea.h 8 Dec 2003 13:42:21 -
@@ -72,6 +72,8 @@ public:
boost::signal2 workAreaKeyPress;
/// some mouse event
boost::signal1 dispatch;
+ /// used by drag-and-drop
+ boost::signal1 viewDispatch;
/// emitted when an X client has requested our selection
boost::signal0 selectionRequested;
/// emitted when another X client has stolen our selection
Index: src/frontends/qt2/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/qt2/ChangeLog,v
retrieving revision 1.389.2.40
diff -u -p -r1.389.2.40 ChangeLog
--- src/frontends/qt2/ChangeLog 5 Dec 2003 10:00:18 - 1.389.2.40
+++ src/frontends/qt2/ChangeLog 8 Dec 2003 13:42:21 -
@@ -1,3 +1,16 @@
+2003-12-08 Ronald Florence <[EMAIL PROTECTED]>
+
+ * QWorkArea.C (checkAppleEventForMissingParams)
+ (handleOpenDocuments): add support for OpenDocuments apple event
+
+ * lyx_gui.C (macEventFilter): handle apple events
+
+2003-12-04 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * QWorkArea.C (QWorkArea):
+ (dragEnterEvent):
+ (dropEvent): add support for drag and drop of URIs
+
2003-12-05 Juergen Spitzmueller <[EMAIL PROTECTED]>
* QDocument.C: use geometry on custom, A3, B3 and B4
Index: src/frontends/qt2/QWorkArea.C
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
On Mon, Dec 08, 2003 at 05:51:14PM +0100, Jean-Marc Lasgouttes wrote: > > Since nobody read my previous patch for dnd support in lyx/qt, here is > a second one that adds support for AppleEvent OpenDocuments. That's wrong. I read it. But I did not even understand what you were talking about let alone able to judge the implications of this patch. Andre'
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
-BEGIN PGP SIGNED MESSAGE- On Montag, 8. Dezember 2003 18:04, Andre Poenitz wrote: > On Mon, Dec 08, 2003 at 05:51:14PM +0100, Jean-Marc Lasgouttes wrote: > > Since nobody read my previous patch for dnd support in lyx/qt, here is > > a second one that adds support for AppleEvent OpenDocuments. > > That's wrong. > > I read it. But I did not even understand what you were talking about > let alone able to judge the implications of this patch. I did not read, but I tested it with the qt-lyx. For me it worked as expected (using konqueror for drag and lyx to drop into) > Andre' Kornel - -- Kornel Benko [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iQCVAwUBP9SwiLewfbDGmeqhAQEVoAP/VVUHGmtEppyIStKTgpDhkK88qoNaXuoV 3vp9Bv2SVZ5LHJjDk/sR9K9CLIW+GSsJFsbGCfCUpxnHfDocSxWU+Vvs3eV0cWXB mwFTXDyOdJ1TJ9bIJ0H9GR5OHwPBgNnC0O4pffSEFm0osHPomKp/FWObgzSbdWth /EuYe/sIRTU= =lAgS -END PGP SIGNATURE-
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Mon, Dec 08, 2003 at 05:51:14PM +0100, Jean-Marc Lasgouttes Andre> wrote: >> Since nobody read my previous patch for dnd support in lyx/qt, >> here is a second one that adds support for AppleEvent >> OpenDocuments. Andre> That's wrong. I know, but what do you want me to do to get a reaction? ;) Andre> I read it. But I did not even understand what you were talking Andre> about let alone able to judge the implications of this patch. OK. Basically the dnd patch does what trolltech tell us to do to implement drag-n-drop. The only LyX related thing here is that we need a way to dispatch LFUN_FILE_OPEN from WorkArea. To this end, I added a new workarea signal that calls LyXView::dispatch. Note that this code is already in 1.4.0cvs, but that it has a slightly different form. What I have in this patch was the simplest alternative. For the other patch, we have to be able to intercept the OS X events. To this end, one overrides QApplication::macEventFilter so that it actually does something with the events. Then, in QWorkarea.C I have a free-standing event handler (and an auxiliary function) that do the actual work of decoding the OpenDocuments event and sending it to WorkArea::viewDispatch. The dnd code should work on any qt version (platform independent) The macEvent code is only compiled on Qt/Mac. So, I think that the implications are not a problem, but that it can probably be written in a cleaner way... Does this help? JMarc
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
> "Kornel" == Kornel Benko <[EMAIL PROTECTED]> writes: Kornel> I did not read, but I tested it with the qt-lyx. For me it Kornel> worked as expected (using konqueror for drag and lyx to drop Kornel> into) Yes, this works here too (with qt 2.3.0). JMarc
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
On Mon, Dec 08, 2003 at 06:26:17PM +0100, Jean-Marc Lasgouttes wrote: > So, I think that the implications are not a problem, but that it can > probably be written in a cleaner way... *shrug* Didn't look like the messiest part of LyX... > Does this help? A bit. But I still can't answer anything else than 'does not look wrong, does not sound wrong...' Andre'
Re: Compilation failure in checkedwodgets.C with qt 2.3.0
Jean-Marc Lasgouttes wrote: > Angus, qt 2.3.0 does not have this setPaletteForegroundColor thing. Shame! Ahhh well. It's just a bit of fun and not vital to the use of the class. I'll wrap the contents of setWidget up inside some 3ifdef magic for now. -- Angus
Re: [PATCH] Allow double-clicking on file to launch LyX/Mac
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: >> Does this help? Andre> A bit. But I still can't answer anything else than 'does not Andre> look wrong, does not sound wrong...' I understand that. I am just posting to see whether ideas emerge :) I'll probably commit that to 1.3.4cvs tomorrow. JMarc
Re: CharStyle discussion
On Sunday 07 December 2003 06:53 am, you wrote: > On Sat, Dec 06, 2003 at 03:03:42PM -0500, Kuba Ober wrote: > > There will also be some constraints as to how far a character style can > > go. I imagine we will artificially need to terminate all character > > styling at the end of the paragraph, otherwise it'll be an uncontainable > > mess. This may actually make sense for logical formatting - typically, > > you're making a word/sentence bolded, not the whole document; if it's the > > whole document you should adjust the default paragraph style properties > > (in LyX's case it would be more like document properties). > > > > I haven't read the whole thread yet, so if my points have already been > > raised, feel free to ignore me :) > > Well, there is the point that a quotation occationally will contain a few > short paragraphs, so using the paragraph end as a limit won't work well. > > People do select "two and a half" paragraph in order to apply a style. > Perhaps not often, but it do happen. It is nice if it works, even if > the code have to create several insets for the multiple paragraphs. Oh yes, then certainly it will work like that. Another way of doing it is instead of having character style insets just have character style flags and have the core do the job. I.e. have "bold on" and "bold off" flags. Obviously their manipulation will need some equilibristic skills. I guess that implementation with insets is just plain easier, and making the insets behave to the user as "expected" should involve less work than keeping state of the flags sprinkled around the text. Kuba
