Re: Space
On Sat, Jun 22, 2002 at 09:50:08AM +0300, Gady Kozma wrote: no longer adds a space after it. Is this intentional? Not exactly. If so, the tutorial should be updated (section 4.2). Maybe somebody could write a short UI things that changed from 1.1.6 to 1.2 and you need to readjust doc. The goal is actually 'make 1.2 behave as 1.1.6 and document things when this is not possible'. And yes, somebody would have to document these things. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS: SIGSEGV when inserting math env.
On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote: CVS 1.3.0 as of June 19th. Do following: 1. Start LyX 2. File - New 3. Insert mathed with, for example, the math tool kaboom: SIGSEGV!! There seems to be some problem with the dependency tracking for recompilation. I've seen similar and a clean recompile helped. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Menu re-organisation
On Fri, Jun 21, 2002 at 07:31:05AM +0100, John Levon wrote: o dunno where to put preferences. Tools is a possibility, but that sucks o insert is still far too clumsy Edit? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
configure with qt2 frontend on FreeBSD fails!?!
Hi, I do: $ ./autogen.sh $ ./configure --with-frontend=qt2 \ --with-qt2-includes=/usr/X11R6/include/qt2 \ --with-qt2-libraries=/usr/X11R6/lib which ends with: [...] checking for X11/forms.h... no checking for forms.h... yes checking xforms header version... 0.88.1 checking for Qt... configure: error: Qt2 (headers and libraries) not found. Please check your installation! What's wrong? ls /usr/X11R6/include/qt2 has: jri.h jritypes.h npapi.h npupp.h q1xcompatibility.h qabstractlayout.h qaccel.h [...] qwmatrix.h qworkspace.h qxml.h qxt.h and ls /usr/X11R6/lib | grep qt has: libqt1.so libqt1.so.3 libqt2-mt.so libqt2-mt.so.4 libqt2.so libqt2.so.4 libqtgl.so libqtgl.so.4 Any idea why the qt-configure script fails on my FreeBSD PC? Regards, Rob.
[PATCH] graphics stuff
here comes a total diff of my graphics stuff, which I posted more
than one time to the list in smaller pieces! It fixes several bugs.
If no one is interested then let it be ...
Herbert
--
http://www.lyx.org/help/
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.775
diff -u -r1.775 ChangeLog
--- src/ChangeLog 21 Jun 2002 11:35:39 - 1.775
+++ src/ChangeLog 24 Jun 2002 07:58:00 -
@@ -1,3 +1,8 @@
+2002-06-23 Herbert Voss [EMAIL PROTECTED]
+
+ * lengthcommon.C:
+ * lyxlength.[Ch]: support vertical length for imahe scaling
+
2002-06-21 John Levon [EMAIL PROTECTED]
* lyxrc.h:
Index: src/lengthcommon.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lengthcommon.C,v
retrieving revision 1.3
diff -u -r1.3 lengthcommon.C
--- src/lengthcommon.C 27 Mar 2002 12:27:17 - 1.3
+++ src/lengthcommon.C 24 Jun 2002 07:58:00 -
@@ -8,7 +8,8 @@
char const * unit_name[num_units] = {
sp, pt, bp, dd, mm, pc, cc, cm,
in, ex, em, mu,
- text%, col%, page%, line% };
+ text%, col%, page%, line%,
+ theight%, pheight% };
LyXLength::UNIT unitFromString(string const data)
Index: src/lyxlength.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlength.C,v
retrieving revision 1.16
diff -u -r1.16 lyxlength.C
--- src/lyxlength.C 10 Jun 2002 07:57:36 - 1.16
+++ src/lyxlength.C 24 Jun 2002 07:58:00 -
@@ -47,7 +47,8 @@
return subst(oldLength,c%,col%);
} else if (oldLength.find(t%) != string::npos) {
- if (oldLength.find(text%) != string::npos)
+ if (oldLength.find(text%) != string::npos ||
+ oldLength.find(height%) != string::npos)
return oldLength;
else
return subst(oldLength,t%,text%);
@@ -113,6 +114,14 @@
buffer abs(static_castint(val_/100)) .
abs(static_castint(val_)%100) \\linewidth;
break;
+ case PH:
+ buffer abs(static_castint(val_/100)) .
+ abs(static_castint(val_)%100) \\paperheight;
+ break;
+ case TH:
+ buffer abs(static_castint(val_/100)) .
+ abs(static_castint(val_)%100) \\textheight;
+ break;
default:
buffer val_ unit_name[unit_]; // setw?
break;
@@ -230,6 +239,10 @@
case LyXLength::PP:
case LyXLength::PL:
result = val_ * default_width / 100;
+ break;
+ case LyXLength::PH:
+ case LyXLength::TH:
+ result = val_ * default_height / 100;
break;
case LyXLength::UNIT_NONE:
result = 0; // this cannot happen
Index: src/lyxlength.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlength.h,v
retrieving revision 1.7
diff -u -r1.7 lyxlength.h
--- src/lyxlength.h 11 Apr 2002 18:36:18 - 1.7
+++ src/lyxlength.h 24 Jun 2002 07:58:00 -
@@ -36,10 +36,12 @@
EX, /// Height of a small x for the current font.
EM, /// Width of capital M in current font.
MU, /// Math unit (18mu = 1em) for positioning in math mode
- PW, /// Percent of columnwidth both % or %c
- PE, /// FIXME
+ PW, /// Percent of columnwidth
+ PE, /// Percent of textwidth
PP, /// Percent of pagewidth
PL, /// Percent of linewidth
+ TH, /// Percent of textheight // Herbert 2002-05-16
+ PH, /// Percent of paperheight // Herbert 2002-05-16
UNIT_NONE /// no unit
};
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.191
diff -u -r1.191 ChangeLog
--- src/frontends/controllers/ChangeLog 21 Jun 2002 16:35:29 - 1.191
+++ src/frontends/controllers/ChangeLog 24 Jun 2002 07:58:00 -
@@ -1,3 +1,10 @@
+2002-06-23 Herbert Voss [EMAIL PROTECTED]
+
+ * ControlBibtex.C:
+ * tex_helpers.C: test of existing file only in tex_helpers
+
+ * ControlGraphics.C: comments
+
2002-06-21 Angus Leeming [EMAIL PROTECTED]
* tex_helpers.C: Use vector not vector.h. Reorder header files.
Index: src/frontends/controllers/ControlBibtex.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ControlBibtex.C,v
retrieving revision 1.18
Re: sciword bindings + M-x
On Thu, Jun 20, 2002 at 10:47:31PM +0100, John Levon wrote: Should I kill screen-recenter to allow M-x for accessing the minibuffer ? What is 'screen-recenter' supposed to do? Andr'e -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS: SIGSEGV when inserting math env.
Andre Poenitz wrote: On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote: CVS 1.3.0 as of June 19th. Do following: 1. Start LyX 2. File - New 3. Insert mathed with, for example, the math tool kaboom: SIGSEGV!! There seems to be some problem with the dependency tracking for recompilation. I've seen similar and a clean recompile helped. Nope. The SIGSEGV persist after a make maintainer-clean and even after a complete fresh download of lyx-devel from CVS! So it can't be a dependency problem. Does my gdb-backtrace at http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg39632.html give a clue? Remember that we had similar problem before. Rob.
Re: [PATCH] graphics stuff
Herbert Voss [EMAIL PROTECTED] writes: | here comes a total diff of my graphics stuff, which I posted more | than one time to the list in smaller pieces! It fixes several bugs. | If no one is interested then let it be ... Did you ever answer Jean-Marcs question about changeExtension? (i.e. Is it really needed?) As to the earlier times when you have posted parts of this patch... there has been comments, questions and request that never got answered (and still aren't), or you posted that patch at a time when it could never be committed. -- Lgb
Re: sciword bindings + M-x
Andre Poenitz [EMAIL PROTECTED] writes: | On Thu, Jun 20, 2002 at 10:47:31PM +0100, John Levon wrote: Should I kill screen-recenter to allow M-x for accessing the minibuffer ? | What is 'screen-recenter' supposed to do? Ctrl-l Scroll the screen so that the cursor is at the middle (top-down), and/or repaint the screen. -- Lgb
Re: configure with qt2 frontend on FreeBSD fails!?!
On Monday 24 June 2002 7:56 am, R. Lahaye wrote: Hi, I do: $ ./autogen.sh $ ./configure --with-frontend=qt2 \ --with-qt2-includes=/usr/X11R6/include/qt2 \ --with-qt2-libraries=/usr/X11R6/lib which ends with: [...] checking for X11/forms.h... no checking for forms.h... yes checking xforms header version... 0.88.1 checking for Qt... configure: error: Qt2 (headers and libraries) not found. Please check your installation! What's wrong? ls /usr/X11R6/include/qt2 has: Well this isn't exactly a nornal place for sysytem header files. Do you have environment variables QTDIR, QTINC, QTLIB set? If not, I'm not surprised that they can't be found. and ls /usr/X11R6/lib | grep qt has:patibility.h why on earth do you have header files in a lib directory? Any idea why the qt-configure script fails on my FreeBSD PC? Didnt you have some problems in the early days of all this? I seem to remember that a lot of special casing code has been removed for the time being. The guy who knows (John) has dissappeared for a few weeks, so I don't think I can help much. Anyway, once you configure, you won't be able to compile. Wait a while... Angus
the minibuffer
I thought I'd try and move the minibuffer behind the frontends firewall and
so had a look at which functions are used by the general public. It
transpires that only addSet and getString are used.
I propose, therefore, getting rid entirely of LyXView::getMiniBuffer() and
replacing it with two boost::functions. The minibuffer can then disappear
from view.
Any objections? Reasons please...
aleem@pneumon:src- grep -n getMiniBuffer() *.C */*.C */*/*.C
lyxfunc.C:827:
owner-getMiniBuffer()-addSet(commandshortcut);lyxfunc.C:830:
owner-getMiniBuffer()-addSet(' ' + commandshortcut);
lyxfunc.C:1050: owner-getMiniBuffer()-getString(MiniBuffer::spaces,
frontends/LyXView.C:118:MiniBuffer * LyXView::getMiniBuffer() const
frontends/xforms/XFormsView.C:81: getMiniBuffer()-redraw();
LyXView owns the minibuffer and XFormsView derives from LyXView so these
don't count. That means that the only functions of interest are:
void MiniBuffer::addSet(string const s1, string const s2)
{
string const str = text + ' ' + s1 + ' ' + s2;
message(str);
}
* Note that s2 is NEVER used. Shall I kill it?
* This command is used to append the command shortcut to the displayed
lyxfunc. Might a better name be void appendShortCut(string const sc)?
/** Makes the minibuffer wait for a string to be inserted.
Waits for a string to be inserted into the minibuffer, when
the string has been inserted the signal stringReady is
emitted.
*/
void MiniBuffer::getString(State spaces,
vectorstring const completion,
vectorstring history)
{
state_ = spaces;
completion_ = completion;
history_ = history;
hist_iter = history_-end();
prepare();
}
* Again, I think that this name is confusing. Why not prepareBuffer(...)? or
some such?
Angus
Re: the minibuffer
Angus Leeming [EMAIL PROTECTED] writes:
| I thought I'd try and move the minibuffer behind the frontends firewall and
| so had a look at which functions are used by the general public. It
| transpires that only addSet and getString are used.
| I propose, therefore, getting rid entirely of LyXView::getMiniBuffer() and
| replacing it with two boost::functions. The minibuffer can then disappear
| from view.
| Any objections? Reasons please...
I am not sure how this will look.
| aleem@pneumon:src- grep -n getMiniBuffer() *.C */*.C */*/*.C
| lyxfunc.C:827:
| owner-getMiniBuffer()-addSet(commandshortcut);lyxfunc.C:830:
| owner-getMiniBuffer()-addSet(' ' + commandshortcut);
| lyxfunc.C:1050: owner-getMiniBuffer()-getString(MiniBuffer::spaces,
| frontends/LyXView.C:118:MiniBuffer * LyXView::getMiniBuffer() const
| frontends/xforms/XFormsView.C:81: getMiniBuffer()-redraw();
| LyXView owns the minibuffer and XFormsView derives from LyXView so these
| don't count. That means that the only functions of interest are:
| void MiniBuffer::addSet(string const s1, string const s2)
| {
| string const str = text + ' ' + s1 + ' ' + s2;
| message(str);
| }
| * Note that s2 is NEVER used. Shall I kill it?
Yes.
| * This command is used to append the command shortcut to the displayed
| lyxfunc. Might a better name be void appendShortCut(string const sc)?
Isn't it also used internally in the minibuffer? For telling then end
of history is reached etc. ?
| /** Makes the minibuffer wait for a string to be inserted.
| Waits for a string to be inserted into the minibuffer, when
| the string has been inserted the signal stringReady is
| emitted.
| */
| void MiniBuffer::getString(State spaces,
| vectorstring const completion,
| vectorstring history)
| {
| state_ = spaces;
| completion_ = completion;
| history_ = history;
| hist_iter = history_-end();
| prepare();
| }
| * Again, I think that this name is confusing. Why not prepareBuffer(...)? or
| some such?
If you read the comment the same of the funciton is perfectly sane..
IMHO.
We use it to get a string (and it is delivered through a signal.)
--
Lgb
Re: the minibuffer
On Monday 24 June 2002 10:37 am, Lars Gullik Bjønnes wrote:
Angus Leeming [EMAIL PROTECTED] writes:
| I thought I'd try and move the minibuffer behind the frontends firewall
| and so had a look at which functions are used by the general public. It
| transpires that only addSet and getString are used.
|
| I propose, therefore, getting rid entirely of LyXView::getMiniBuffer()
| and replacing it with two boost::functions. The minibuffer can then
| disappear from view.
|
| Any objections? Reasons please...
I am not sure how this will look.
lyxview().minibufferAddSet(...);
or isn't this what you mean?
| * This command is used to append the command shortcut to the displayed
| lyxfunc. Might a better name be void appendShortCut(string const sc)?
Isn't it also used internally in the minibuffer? For telling then end
of history is reached etc. ?
No. Maybe it was once, but no more:
aleem@pneumon:src- grep -n addSet minibuffer.*
minibuffer.C:355:void MiniBuffer::addSet(string const s1, string const s2)
minibuffer.h:42:void addSet(string const ,
| /** Makes the minibuffer wait for a string to be inserted.
| Waits for a string to be inserted into the minibuffer, when
| the string has been inserted the signal stringReady is
| emitted.
| */
| void MiniBuffer::getString(State spaces,
|vectorstring const completion,
|vectorstring history)
| * Again, I think that this name is confusing. Why not prepareBuffer(...)?
| or some such?
If you read the comment the same of the funciton is perfectly sane..
IMHO.
We use it to get a string (and it is delivered through a signal.)
Well you might call it sane. I'm not going to call it insane, just clumsy.
foo::callingFunc()
{
minibuffer.getString();
}
foo::receivingFunc is connected to minibuffer::signalReady.
To my eyes, this code suggests that I now have a string to manipulate,
whereas actually I have nothing until another foo function is called when
the signal is emitted. So, why not reflect this reality in the names:
void minibuffer::prepareForInput(...);
boost::signal1void, string const minibuffer::inputString;
Incidentally, I for one would be happier if the excesssive name calling
that's been creeping into this list recently were to creep out again. No,
this isn't directed at Lars; I think he's had to bear the brunt of the abuse
recently. To my eyes STFU helps no-one.
Angus
variable naming
Can anybody please explain to me in simple words the variable naming in the
following snippet taken from FormDialog.C?
void UserCache::add(uid_t ID) const
{
string pszNewName;
[...]
It almost made me spill tea over the keyboard together with some
yellowish-green liquid fairly similar to the one we've seen in the zoo in
Maia (although it originated from a tiger there).
Apart from that the forms/form_filedialog.h included in line 77 in that
file does not exist on my machine and is not rebuild after a clean
checkout. Actually, I do not understand most of the code between lines 50
and 80 there.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
lyx configure script
Hi,
I had a bit of a problem with the lyx configure script on a cygwin
environment.
The following check only works if the sh shell points to the bash
shell.
### Adjust PATH for Win32 (Cygwin)
if test x$OSTYPE = xcygwin; then
echo configure: cygwin detected; path correction
srcdir=`cygpath -w ${srcdir} | tr '' /`
echo srcdir=${srcdir}
fi
To my knowledge there is no OSTYPE defined on the sh shell that is
something specific to bash. Perhaps that should be mentioned somewhere.
Alternatively the following check should be sufficient for both bash
and sh.
if test -f /bin/cygwin1.dll; then
Ok that is not really a check for the enviroment we are on but at
least it works and I can't imagination that a cygwin1.dll is on a
non cygwin system found.
Soeren
==
When you don't know what to do, walk fast and look worried.
Re: variable naming
On Monday 24 June 2002 11:04 am, Andre Poenitz wrote:
Can anybody please explain to me in simple words the variable naming in the
following snippet taken from FormDialog.C?
void UserCache::add(uid_t ID) const
{
string pszNewName;
[...]
It almost made me spill tea over the keyboard together with some
yellowish-green liquid fairly similar to the one we've seen in the zoo in
Maia (although it originated from a tiger there).
At last! Someone else who finds that code foul! I have avoided touching it
for two years because it's so disgusting; in fact it's the only dialog in the
frontends that hasn't become a daughter of FormBase (or FormBaseDeprecated)
for this very reason.
Apart from that the forms/form_filedialog.h included in line 77 in that
file does not exist on my machine and is not rebuild after a clean
checkout. Actually, I do not understand most of the code between lines 50
and 80 there.
Andre'
All the forms/form_*.[Ch] files are now autogenerated. As such, you'll
probably find them in your build tree, not your src tree.
Angus
Re: variable naming
On Mon, Jun 24, 2002 at 10:58:44AM +0100, Angus Leeming wrote: All the forms/form_*.[Ch] files are now autogenerated. As such, you'll probably find them in your build tree, not your src tree. I looked in either. Some of the form_*.[Ch] were there, some not (_about* was missing, too) Anyway. I try a really clean checkout/rebuild right now. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
mathed rendering broken
Attached is a small LyX document who's mathed rendering is broken with
current cvs. Attached also are a couple of screen shots of the old and new
appearances.
Any ideas, André?
Angus
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset FormulaMacro
\newcommand{\integral}[3]{\int _{#1}^{#2}\! \! \textrm{d}#3\; }
\end_inset
\layout Standard
\begin_inset Formula \begin{equation}
M=\integral{A}{}{A}\rho \qquad .\end{equation}
\end_inset
\the_end
1_2_X.png
Description: PNG image
1.3.cvs.png
Description: PNG image
Re: mathed rendering broken
On Mon, Jun 24, 2002 at 11:05:32AM +0100, Angus Leeming wrote:
Attached is a small LyX document who's mathed rendering is broken with
current cvs. Attached also are a couple of screen shots of the old and new
appearances.
Any ideas, André?
My first idea was to have a look as soon as I got LyX compiled ;-}
Apart from that it looks like one of the bugs I fixed when in José's
custody, but I haven't applied thes to CVS yet.
Andre'
PS: Since I have you on the line: Would it be possible to separate the
graphics loading in some low-level and some high-level part? I need just
the load a graphics and give me an ('owning') handle (i.e. low-level)
part and I do /not/ have a InsetGraphics around which seems to be needed
for the cache part (which should then be come the 'high-level part')?
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: variable naming
On Monday 24 June 2002 11:16 am, Andre Poenitz wrote: On Mon, Jun 24, 2002 at 10:58:44AM +0100, Angus Leeming wrote: All the forms/form_*.[Ch] files are now autogenerated. As such, you'll probably find them in your build tree, not your src tree. I looked in either. Some of the form_*.[Ch] were there, some not (_about* was missing, too) You mean both... Linguistic splitting of hairs aside, I'd be interested in discovering what's going on. It's a new adventure for me this makefile stuff and I found it quite confusing at times. Of course, you could be demonstrating that your dependency tracking has goine mad yet again ;-) Anyway. I try a really clean checkout/rebuild right now. That's a little excessive ;-) Why not cd build/src/frontends/xforms/forms make clean make or even rm -f form* make or more elegantly (?) trigger a rebuild with cd lyxsrc/src/frontends/xforms/forms touch *.fd cd lyxbuild/src/frontends/xforms/forms make Angus
Re: variable naming
Angus Leeming [EMAIL PROTECTED] writes: | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll | probably find them in your build tree, not your src tree. One note though... I do not agree to when this is generated, now you generate upon compile, right? It should be done on autogen, so that a source distribution does not require users to have fdesign installed. -- Lgb
Re: variable naming
On Mon, Jun 24, 2002 at 11:14:04AM +0100, Angus Leeming wrote: I looked in either. Some of the form_*.[Ch] were there, some not (_about* was missing, too) You mean both... I looked in both. That should include either, shouldn't it? Linguistic splitting of hairs aside, Oh... ;-} I'd be interested in discovering what's going on. It's a new adventure for me this makefile stuff and I found it quite confusing at times. Of course, you could be demonstrating that your dependency tracking has goine mad yet again ;-) My personal feeling is that the Makefiles used by LyX are far too heavy and I wonder from time to time whether hand-made would be better. But then, I do not have too much experience with cross-platform make. Anyway. I try a really clean checkout/rebuild right now. That's a little excessive ;-) Why not cd build/src/frontends/xforms/forms make clean make Because just 'cd lyx-build ; rm -rf * ; ../lyx-devel/configure ; make' did not work. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: variable naming
On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll | probably find them in your build tree, not your src tree. One note though... I do not agree to when this is generated, now you generate upon compile, right? It should be done on autogen, so that a source distribution does not require users to have fdesign installed. Can I convince you that you're wrong? Probably not ;-) Anyway here is why I prefer the current approach: 1. What is wrong with forcing the users to install fdesign? It's the appropriate compilation tool. (You insist on a C== compiler for .C code...) In effect, you are special-casing the xforms frontend. The qt frontend will require uic to be present. Ditto, gnome will require glade. 2. The makefile is used to rebuild object files when a src file is changed. In this case, the src file is the .fd file. When it's modified all is rebuilt correctly. If we adopt your proposal, then that is no longer the case. Angus
Re: mathed rendering broken
On Monday 24 June 2002 11:23 am, Andre Poenitz wrote:
PS: Since I have you on the line: Would it be possible to separate the
graphics loading in some low-level and some high-level part? I need just
the load a graphics and give me an ('owning') handle (i.e. low-level)
part and I do /not/ have a InsetGraphics around which seems to be needed
for the cache part (which should then be come the 'high-level part')?
And now we're going to need such an approach for the splash screen it would
appear. Yes such a thing is possible. Yes, I'll concentrate on it.
My list of things to do:
* clean-up the graphics
* move minibuffer behind the frontends firewall (I think that that will mean
that the LyX core will then know nothing about the frontends at all)
* introduce a controller-view split to the minibuffer.
* help John with his event-driven rendering of the LyX screen. Now on the
back burner since he's gone on LyX-holiday ;-)
* clean up the controllers heirarchy so that more things are has a rather
than is a.
* introduce a controller-view split to the remaining few dialogs derived from
FromBaseDeprecated.
* introduce my wrappers for xforms. I'll probably start with the minibuffer
here since that is what I'm currently thinking about. Certainly the current
xforms rubbish should be replaced by a combox...
As you can see, most of this can be classified as code cleanup rather than
new functionality. I'm quite happy to concentrate on the graphics stuff
rather than choose another area.
Most importantly:
do some real work.
How was the extended holiday?
Angus
Re: expose is broken
On Sat, Jun 22, 2002 at 08:42:19AM +0200, Lars Gullik Bjønnes wrote: | More informed bug reports are welcome. Meaning that my report is wrong or that you want more details? More details. But looking it's obvious - your WM doesn't do saveunders for menus, and we're not doing the copy of the pixmap at FL_DRAW time. Related to the stuff me angus were talking aobut. And I am at least pestering someone about the problems I see. If you (or anyone else) just keep quiet how am I supposed to know that you still have a problem. Yes, I remember how quiet everyone was about the boost changes. Because the boost changes are making a _running_ lyx misbehave in what way? (and are you really unable to keep issues separate?) Because I was drunk gimme a break ... regards john -- If a thing is not diminished by being shared, it is not rightly owned if it is only owned not shared. - St. Augustine
Re: cursor_follows_scrollbar
On Mon, Jun 24, 2002 at 12:16:10PM +1000, Allan Rae wrote: I was actually referring to myself here not you. But it works either way. heh I scroll to where I am working and edit there. There is no going back because I don't need to -- I rarely use bookmarks in emacs and have never felt the need to use them in my LyX docs. If I need to check something that something is almost always in a different file so there is no jumping around within a single file. FYI, this option provides consistency and conformity with [X]Emacs operation. We all know how much you hate emacs but as it is a major standard for Unix users -- particularly for emacs+AucTeX users who move to LyX -- it should hopefully be considered a valid useability arguement. Sounds good to me. I'm not completely unreasonable you know. And please don't bother lecturing me about horrible emacs' interface is in your opinion. It works for me and thousands of others. But numbers don't count do they? Of course they do. But they are by no means the sole argument. You're kidding, right ? Have you any idea how long that list is :) No, I have no idea how long your list is, so I am asking to see it. To quote from Dilbert : It's not so much a physical list as a philosophy. Then the (likely to be the majority) non-contraversial group can be agreed upon quickly and cleaned out and subthreads arguing the cases for whatever is contraversial can then take place. To actually generate such a list would take a few days of close examination and application of heuristics to LyX's UI. I'd much rather deal with things on a case-by-case, so things like show banner can be removed quickly, and more controversial things can be, um, more controversial :) john -- If a thing is not diminished by being shared, it is not rightly owned if it is only owned not shared. - St. Augustine
Re: expose is broken
On Monday 24 June 2002 12:02 pm, John Levon wrote: On Sat, Jun 22, 2002 at 08:42:19AM +0200, Lars Gullik Bjønnes wrote: | More informed bug reports are welcome. Meaning that my report is wrong or that you want more details? More details. But looking it's obvious - your WM doesn't do saveunders for menus, and we're not doing the copy of the pixmap at FL_DRAW time. Related to the stuff me angus were talking aobut. As I see it, the current code is much the same as the old code. The philosophy behind the code has not changed yet anyway. So do the changes you've introduced so far fall between two stools? Ie, they are neither the new way nor the old way, they're just broken? More importantly, is it fixable without going the whole way? As you'll gather, I'm confused by what you actually did commit on Friday. Could you post the patch and/or explain it? Certainly give an explantation of what you did and why. Help us keep up with you ;-) And I am at least pestering someone about the problems I see. If you (or anyone else) just keep quiet how am I supposed to know that you still have a problem. Yes, I remember how quiet everyone was about the boost changes. Because the boost changes are making a _running_ lyx misbehave in what way? (and are you really unable to keep issues separate?) Because I was drunk gimme a break ... Bad behaviour when drunk is still bad behaviour. STFU is no way to behave. An old prude.
Re: variable naming
On Mon, Jun 24, 2002 at 11:29:52AM +0100, Angus Leeming wrote: 1. What is wrong with forcing the users to install fdesign? It's the appropriate compilation tool. (You insist on a C== compiler for .C code...) In effect, you are special-casing the xforms frontend. The qt frontend will require uic to be present. Ditto, gnome will require glade. Isn't this similar to distrubute the configure script to relieve the user from running automake and autoconf? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: mathed rendering broken
On Mon, Jun 24, 2002 at 11:42:40AM +0100, Angus Leeming wrote: [...] And now we're going to need such an approach for the splash screen it would appear. Yes such a thing is possible. Yes, I'll concentrate on it. That's a good thing to hear. [...] How was the extended holiday? Nice indeed. And shame on you people that you did not show up. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: mathed rendering broken
On Monday 24 June 2002 12:27 pm, Andre Poenitz wrote: How was the extended holiday? Nice indeed. And shame on you people that you did not show up. Shame indeed. I worked till 2am every night that weekend on a grant proposal that should have been done weeks before. The deadline was 8pm Monday and some colleagues have different ideas about sensible working practices to me. Unfortunately, two of them are called Prof, so it can be difficult telling them in language sufficiently simple that they understand. Angus
Re: Mathematica's facilities with lyx...
On Mon, Jun 24, 2002 at 07:43:51AM +0200, Andre Poenitz wrote: You basically have to add a function 'mathematicize' (or whatever) to every math inset (or at least to the ones you are interested in) and there you put code to transform the inset into Mma syntax. Usually you should be able to copy the 'maplize' function and replace parantheses by square brackets and things like that. Than you need to have a look add math_extern.C and formulabase.C and hook calls to these new functions in. It is not very nice to have this hardcoded in the LyX sources. can't you do it in external scripts, like the first implementation ? Another idea would be to use text template files. For example, an extern_maple would be something like Insets frac ($0)/($1) sqrt sqrt($0) ... End Header readlib(latex): latex/csname_font := `: ... End
Re: Mathematica's facilities with lyx...
On Mon, Jun 24, 2002 at 03:05:59PM +0300, Dekel Tsur wrote: It is not very nice to have this hardcoded in the LyX sources. I know. can't you do it in external scripts, like the first implementation ? The external scripts would have to re-create the structure used within mathed (more or less). I just got tired of re-implemting mathed a second and third time. Another idea would be to use text template files. For example, an extern_maple would be something like Insets frac ($0)/($1) sqrt sqrt($0) ... End Have a go. But I think I'll do something like that myself some day when the math-extern stuff has reached some critical mass that allows me to see what is a generic common base and can be used as the hard-coded part, and what is backend specific that could be put in such configuration files. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: variable naming
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll | probably find them in your build tree, not your src tree. One note though... I do not agree to when this is generated, now you generate upon compile, right? It should be done on autogen, so that a source distribution does not require users to have fdesign installed. | Can I convince you that you're wrong? Probably not ;-) Anyway here is why I | prefer the current approach: | 1. What is wrong with forcing the users to install fdesign? It's the | appropriate compilation tool. (You insist on a C== compiler for .C code...) | In effect, you are special-casing the xforms frontend. The qt frontend will | require uic to be present. Ditto, gnome will require glade. | 2. The makefile is used to rebuild object files when a src file is changed. | In this case, the src file is the .fd file. When it's modified all is rebuilt | correctly. If we adopt your proposal, then that is no longer the case. just make the form_about.c depend on form_about.fd then... -- Lgb
Re: expose is broken
John Levon [EMAIL PROTECTED] writes: | On Sat, Jun 22, 2002 at 08:42:19AM +0200, Lars Gullik Bjønnes wrote: | More informed bug reports are welcome. Meaning that my report is wrong or that you want more details? | More details. But looking it's obvious - your WM doesn't do saveunders | for menus, and we're not doing the copy of the pixmap at FL_DRAW time. | Related to the stuff me angus were talking aobut. _but_ I have never had problems with LyX and saveunders with this WM ealier, so it must be somehting that we do different. And I am at least pestering someone about the problems I see. If you (or anyone else) just keep quiet how am I supposed to know that you still have a problem. | Yes, I remember how quiet everyone was about the boost changes. I have tried to act on some of those issues, esp. binary size. For gcc 3.0 the binary size is imo more than satisfactory, for 2.96 it as imho acceptable albeit a bit big. Because the boost changes are making a _running_ lyx misbehave in what way? (and are you really unable to keep issues separate?) | Because I was drunk gimme a break ... drunkards get no leeway. -- Lgb
Re: variable naming
On Monday 24 June 2002 1:28 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll | probably find them in your build tree, not your src tree. One note though... I do not agree to when this is generated, now you generate upon compile, right? It should be done on autogen, so that a source distribution does not require users to have fdesign installed. | | Can I convince you that you're wrong? Probably not ;-) Anyway here is why | I prefer the current approach: | | 1. What is wrong with forcing the users to install fdesign? It's the | appropriate compilation tool. (You insist on a C== compiler for .C | code...) In effect, you are special-casing the xforms frontend. The qt | frontend will require uic to be present. Ditto, gnome will require glade. | | 2. The makefile is used to rebuild object files when a src file is | changed. In this case, the src file is the .fd file. When it's modified | all is rebuilt correctly. If we adopt your proposal, then that is no | longer the case. just make the form_about.c depend on form_about.fd then... ??? It does. Not only does all work perfectly for me, but the Makefile.am looks fine too. However, I'm no expert and you are. Could you have a look at Makefile.am and see if there are any glaring errors. FWIW, here's what happens for me: aleem@pneumon:lyx- cd devel/src/frontends/xforms/forms aleem@pneumon:forms- touch form_aboutlyx.fd aleem@pneumon:forms- cd ../../../../../devel-build/src/frontends/xforms/forms aleem@pneumon:forms- make /bin/sh ../../../../../devel/src/frontends/xforms/forms/fdfix.sh ../../../../../devel/src/frontends/xforms/forms/form_aboutlyx.fd source='form_aboutlyx.C' object='form_aboutlyx.lo' libtool=yes \ depfile='.deps/form_aboutlyx.Plo' tmpdepfile='.deps/form_aboutlyx.TPlo' \ depmode=tru64 /bin/sh ../../../../../devel/config/depcomp \ /bin/sh ../../../../libtool --mode=compile cxx -std strict_ansi -DHAVE_CONFIG_H -I. -I../../../../../devel/src/frontends/xforms/forms -I../../../../src -I../../../../../devel/src/frontends/xforms/forms/.. -I../../../../../devel/src -I/usr/local/include-nopure_cname -nocleanup -msg_display_number -w1 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel-build/lyx_cxx_repository -O2 -c -o form_aboutlyx.lo `test -f form_aboutlyx.C || echo '../../../../../devel/src/frontends/xforms/forms/'`form_aboutlyx.C cxx -std strict_ansi -DHAVE_CONFIG_H -I. -I../../../../../devel/src/frontends/xforms/forms -I../../../../src -I../../../../../devel/src/frontends/xforms/forms/.. -I../../../../../devel/src -I/usr/local/include -nopure_cname -nocleanup -msg_display_number -w1 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel-build/lyx_cxx_repository -O2 -c -MD form_aboutlyx.C echo timestamp form_aboutlyx.lo
Re: the minibuffer
It seems that the changes Juergen and I did to the minibuffer from Porto has not been included? We did rework all of these methods... Greets, Asger
Re: variable naming
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 24 June 2002 1:28 pm, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: Angus Leeming [EMAIL PROTECTED] writes: | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll | probably find them in your build tree, not your src tree. One note though... I do not agree to when this is generated, now you generate upon compile, right? It should be done on autogen, so that a source distribution does not require users to have fdesign installed. | | Can I convince you that you're wrong? Probably not ;-) Anyway here is why | I prefer the current approach: | | 1. What is wrong with forcing the users to install fdesign? It's the | appropriate compilation tool. (You insist on a C== compiler for .C | code...) In effect, you are special-casing the xforms frontend. The qt | frontend will require uic to be present. Ditto, gnome will require glade. | | 2. The makefile is used to rebuild object files when a src file is | changed. In this case, the src file is the .fd file. When it's modified | all is rebuilt correctly. If we adopt your proposal, then that is no | longer the case. just make the form_about.c depend on form_about.fd then... | ??? It does. Then what it the problem with distributing an up to date form_about.c? | Not only does all work perfectly for me, but the Makefile.am | looks fine too. However, I'm no expert and you are. Could you have a look at | Makefile.am and see if there are any glaring errors. It works for me as well. -- Lgb
redraw problems
Is anything being done about the massive redraw problems (parts of the main window do not get updated when they should). Current CVS is compeltely unusable with that feature Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: the minibuffer
Asger Kunuk Alstrup Nielsen [EMAIL PROTECTED] writes: | It seems that the changes Juergen and I did to the minibuffer from | Porto has not been included? | We did rework all of these methods... Hmm... I did apply the complete diff... I can check against what I have in the Porto CVS repository. -- Lgb
Re: the minibuffer
On Mon, Jun 24, 2002 at 03:11:43PM +0200, Lars Gullik Bjønnes wrote: | It seems that the changes Juergen and I did to the minibuffer from | Porto has not been included? | We did rework all of these methods... Hmm... I did apply the complete diff... I can check against what I have in the Porto CVS repository. Try that. I had difficulties to apply my last Porto changes to current CVS. This looked as if not every change had made it into CVS... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: variable naming
On Monday 24 June 2002 2:10 pm, Lars Gullik Bjønnes wrote: | ??? It does. Then what it the problem with distributing an up to date form_about.c? | Not only does all work perfectly for me, but the Makefile.am | looks fine too. However, I'm no expert and you are. Could you have a look | at Makefile.am and see if there are any glaring errors. It works for me as well. Are you really talking about a make dist option. Ie, distribute the .[ch] files not the .fd ones? Angus
Re: variable naming
Angus Leeming [EMAIL PROTECTED] writes: | On Monday 24 June 2002 2:10 pm, Lars Gullik Bjønnes wrote: | ??? It does. Then what it the problem with distributing an up to date form_about.c? | Not only does all work perfectly for me, but the Makefile.am | looks fine too. However, I'm no expert and you are. Could you have a look | at Makefile.am and see if there are any glaring errors. It works for me as well. | Are you really talking about a make dist option. Ie, distribute the .[ch] | files not the .fd ones? No, distribute both. Yes, imho we should dictribute the .ch files as well as the .fd files in the tar.gz dist. -- Lgb
Re: redraw problems
Andre Poenitz [EMAIL PROTECTED] writes: | On Mon, Jun 24, 2002 at 03:10:31PM +0200, Andre' Poenitz wrote: Current CVS is compeltely unusable with that feature | Maybe some more information: I am running fvwm2 and the problem is not just | with LyX-internal windows but with overlapping external windows, too. | I even get a completely grey LyX main window if I just switch to another | virtual screen and back. copy copy (I just reported exactly the same (and received a small flamage in return)) -- Lgb
Re: the minibuffer
On Monday 24 June 2002 3:02 pm, Lars Gullik Bjønnes wrote: [EMAIL PROTECTED] (Lars Gullik Bjønnes) writes: | Asger Kunuk Alstrup Nielsen [EMAIL PROTECTED] writes: | | It seems that the changes Juergen and I did to the minibuffer from | | Porto has not been included? | | We did rework all of these methods... | | Hmm... I did apply the complete diff... | I can check against what I have in the Porto CVS repository. Some things forgotten. I'll apply this, unless somebody beats me too it. NOTE! however that this patch cannot just be applied, it has to be done piece by piece. A large chunk of this appears to be what John applied on Friday (all that BufferView::redraw/repaint stuff). So, if it worked for you in Porto, it should work again. Hoorah! and no, I'm not going to try and apply it. Angus
graphic converter question
Hi, I noticed a difference how the filename in different converters handled. In the epstoxpm converter $$i points to the original file in the source directory. In the epstopdf converter $$i points to a temporary file. Why this difference? If I wrote my own converter I have no chance to get the path to the original file, right? Did I miss something obvious here or is this a bug.(perhaps only misfeatured) Soeren == Do not simplify the design of a program if a way can be found to make it complex and wonderful.
Re: lyx-devel src/mathed/: Makefile.am formulabase.C math_boxinset ...
On Monday 24 June 2002 6:51 pm, [EMAIL PROTECTED] wrote: CVSROOT: /usr/local/lyx/cvsroot Module name: lyx-devel Repository: lyx-devel/src/mathed/ Changes by: [EMAIL PROTECTED]02/06/24 17:51:35 Modified files: lyx-devel/src/mathed/: Makefile.am formulabase.C math_boxinset.C math_boxinset.h math_factory.C math_parser.C Added files: lyx-devel/src/mathed/: button_inset.C button_inset.h command_inset.C command_inset.h ref_inset.C ref_inset.h Log message: First shot at inset-unification mathed rest of the world A quick look at these files suggests that you're going to get these insets working inside mathed and then replace the existing InsetRef et al with the new scheme. Am I right or will we end up with two insets doing the same thing? Just curious, Angus
Re: lyx-devel src/mathed/: Makefile.am formulabase.C math_boxinset ...
On Mon, Jun 24, 2002 at 04:48:16PM +0100, Angus Leeming wrote: A quick look at these files suggests that you're going to get these insets working inside mathed and then replace the existing InsetRef et al with the new scheme. It currently is just additional functionality for mathed, but yes, the plan is to have a single RefInset again (in insets/) that behaves as the old one outside and inside mathed. The code is already 90% old InsetRef so there is not really much missing. The only problem is popping up the dialog on mouse click but to solve that I'll probably do the decentralized dispatcher stuff first (the cursor is a path in the inset tree and the lowest inset that is capable of handling an LFUN does that. Currently everything ends up in the outermost inset and we do fancy stuff to figure out which inset is able to handle add a column to itself etc) Am I right or will we end up with two insets doing the same thing? true || false == true... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Tabular/Tabular Material vs. Table
On Fri, 21 Jun 2002, robin wrote: John Levon wrote: JMarc suggested I ask here about this terminology. My question is, what is our justificatino for exposing the user to the unusual formulation Tabular Material, or the even worse Tabular ? Beats me. This is another of those things that was argued about back when the Earth was young and dinosaurs roamed the land. The issue was how to make a distinction between LaTeX's tabular - the actual table material - and a table, which is the floating thing you put a tabular into. A similar problem was posed by figure, but at least there we could call the actual picture a graphic. In tabular form :-) we have Content Float -- graphic --- Figure ??? --- Table So, the problem is how to properly label the ???. We compromised on tabular material so we could go back to arguing about more important things. What are the problems with using Table everywhere throughout the GUI and the documentation (except where specifically related to the LaTeX construct) ? None, as far as I can see. Maybe it's a LaTeX thang. In general I'm in favour of making the GUI and the documentation as close as possible to conventional word-processors, HTML editors etc. Now that floating figures and tables have been moved off into their own submenu (Insert-Floats-Table), this isn't so big a deal anymore, but then people will ask What's the difference between Insert-Table and Insert-Floats-Table?. LaTeX chose to solve it by using the names Tabular and Table. Just because everyone else chose the wrong thing :-) doesn't mean we need to change. On the other hand, I've never particularly liked tabular material. Kinda sounds like the corroding metal encrusting the garbage disposal in my kitchen sink (Honey, what's this tabular material growing out of the disposal?). So, I'm in favor of renaming it if a consistent, non-ambiguous solution can be found. Keep in mind the fact that if one inserts a Insert-Floats-Table, one then needs to insert a Insert-Table into it. That's a bit too ambiguous for my taste. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
Re: Mathed screenfonts in 1.3.0cvs ...
On Thu, Jun 13, 2002 at 02:58:36PM +0300, Staffan Ringbom wrote: Since roughly 3 weeks there has been a change in the code, which makes it impossible to view the math-formulas on screen. (Scaling the fonts doesn't seem to help either) Is this still present? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Tabular/Tabular Material vs. Table
On Mon, Jun 24, 2002 at 10:26:29AM -0700, Mike Ressler wrote: So, I'm in favor of renaming it if a consistent, non-ambiguous solution can be found. Keep in mind the fact that if one inserts a Insert-Floats-Table, one then needs to insert a Insert-Table into it. That's a bit too ambiguous for my taste. Mike Just for the record, the ambiguity can also be resolved in the other direction: by always calling a LaTeX Figure a Figure Float and a LaTeX Table a Table Float. And yes, then you can insert a Table into a Table Float, if you feel so disposed. For me again, the distinction between Table and Tabular is a bit too ambiguous. Adding Float to the menu name whenever a float is what we have, is both simple and semantically correct. My 0.02 Euro (soon to be worth more than US$0.02 :-) Martin msg39778/pgp0.pgp Description: PGP signature
Re: Tabular/Tabular Material vs. Table
Martin Vermeer [EMAIL PROTECTED] writes: | On Mon, Jun 24, 2002 at 10:26:29AM -0700, Mike Ressler wrote: So, I'm in favor of renaming it if a consistent, non-ambiguous solution can be found. Keep in mind the fact that if one inserts a Insert-Floats-Table, one then needs to insert a Insert-Table into it. That's a bit too ambiguous for my taste. Mike | Just for the record, the ambiguity can also be resolved in the other | direction: by always calling a LaTeX Figure a Figure Float and a | LaTeX Table a Table Float. And yes, then you can insert a Table into a | Table Float, if you feel so disposed. | For me again, the distinction between Table and Tabular is a bit too | ambiguous. Adding Float to the menu name whenever a float is what we | have, is both simple and semantically correct. And you won't have any ambiguity between Table Float and Table? I'd prefere Table Float and Tabular Please also remember that we have to take LaTeX terminoloty into account. -- Lgb
Lyx on OSX
Hello, I'm a fan of Lyx, usually running on Linux. But now Ihave OSX and miss Lyx so much. I know there is a version on X on X, but will there be a port to native OSX? I think this will be a nice thing for Tex users on OSX, and there are only few Frontends, but noone is as good as Lyx! I hope for a OSX support. Stefan
Re: Lyx on OSX
bernhard [EMAIL PROTECTED] writes: | Hello, | I'm a fan of Lyx, usually running on Linux. But now Ihave OSX and miss | Lyx so much. I know there is a version on X on X, but will there be a | port to native OSX? I think this will be a nice thing for Tex users on | OSX, and there are only few Frontends, but noone is as good as Lyx! I | hope for a OSX support. You should round up some fellow OSX developers then and get going. That is basically the only way it will (and can) happen, none of the current developers use OSX. Looking forward you seeing you contribute :-) -- Lgb
math_decorationinset.C:13: ostream: No such file or directory
Hi, Current CVS: [...] g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include -g -O -W -Wall -c math_decoratio ninset.C -Wp,-MD,.deps/math_decorationinset.TPlo math_decorationinset.C:13: ostream: No such file or directory gmake[3]: *** [math_decorationinset.lo] Error 1 Should line 13 in math_decorationinset.C: #include ostream be replaced by: #include iostream ? Rob.
Re: Mathed screenfonts in 1.3.0cvs ...
On Mon, Jun 24, 2002 at 04:26:54PM -0300, Garst R. Reese wrote: I sent Staffan detailed instructions on how to get the math fonts working and he is OK now. Fine. Thank you. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: math_decorationinset.C:13: ostream: No such file or directory
On Tue, Jun 25, 2002 at 11:41:24AM +0900, R. Lahaye wrote: Should line 13 in math_decorationinset.C: #include ostream be replaced by: #include iostream ? I replace it with support/LOstream.h. This includes whatever is available. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS: SIGSEGV when inserting math env.
Andre Poenitz wrote: On Mon, Jun 24, 2002 at 05:24:50PM +0900, R. Lahaye wrote: There seems to be some problem with the dependency tracking for recompilation. I've seen similar and a clean recompile helped. Nope. The SIGSEGV persist after a make maintainer-clean and even after a complete fresh download of lyx-devel from CVS! So it can't be a dependency problem. Does my gdb-backtrace at http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg39632.html give a clue? No. As I said: When I had that problem a clean rebuiold helped. And in fact, my current build (which is current CVS now) does not show the behaviour you see. Hmmm, since this nasty crash persists, even with a total fresh checkout of CVS, I also persist in providing info on what could be the reason behind this strange SIGSEGV crash. lyx -dbg MATHED provides the attached output. This comes from simpy do File-New and the click on the mathed icon on the icon-taskbar. Does this give a clue? (see earlier email for gdb-backtrace). Rob. SIGSEGV_mathed_output.txt.gz Description: GNU Zip compressed data
cs does not link
lyxfunc.o: In function `LyXFunc::verboseDispatch(kb_action, basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const , bool)': /usr/src/lyx/lyx-build/src/../../lyx-devel/src/lyxfunc.C:833: undefined reference to `MiniBuffer::addSet(basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const )' /usr/src/lyx/lyx-build/src/../../lyx-devel/src/lyxfunc.C:836: undefined reference to `MiniBuffer::addSet(basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const )' lyxfunc.o: In function `LyXFunc::dispatch(kb_action, basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 )': /usr/src/lyx/lyx-build/src/../../lyx-devel/src/lyxfunc.C:1056: undefined reference to `MiniBuffer::prepareForInput(vectorbasic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 , allocatorbasic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0const , vectorbasic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 , allocatorbasic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0)' frontends/.libs/libfrontends.a(LyXView.o): In function `LyXView::message(basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const )': /usr/src/lyx/lyx-build/src/frontends/../../../lyx-devel/src/frontends/LyXView.C:126: undefined reference to `MiniBuffer::message(basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const )' frontends/.libs/libfrontends.a(LyXView.o): In function `LyXView::messagePush(basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const )': /usr/src/lyx/lyx-build/src/frontends/../../../lyx-devel/src/frontends/LyXView.C:132: undefined reference to `MiniBuffer::messagePush(basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const )' frontends/.libs/libfrontends.a(LyXView.o): In function `LyXView::messagePop(void)': /usr/src/lyx/lyx-build/src/frontends/../../../lyx-devel/src/frontends/LyXView.C:138: undefined reference to `MiniBuffer::messagePop(void)' frontends/.libs/libfrontends.a(XFormsView.o): In function `XFormsView::redraw(void)': /usr/src/lyx/lyx-build/src/frontends/xforms/../../../../lyx-devel/src/frontends/xforms/XFormsView.C:85: undefined reference to `XMiniBuffer::redraw(void)' frontends/.libs/libfrontends.a(XFormsView.o): In function `XFormsView::create_form_form_main(int, int)': /usr/src/lyx/lyx-build/src/frontends/xforms/../../../../lyx-devel/src/frontends/xforms/XFormsView.C:158: undefined reference to `XMiniBuffer::XMiniBuffer(LyXView *, int, int, int, int)' /usr/src/lyx/lyx-build/src/frontends/xforms/../../../../lyx-devel/src/frontends/xforms/XFormsView.C:185: undefined reference to `XMiniBuffer::dd_init(void)' collect2: ld returned 1 exit status make[3]: *** [lyx] Error 1 make[3]: Leaving directory `/usr/src/lyx/lyx-build/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/lyx/lyx-build/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/src/lyx/lyx-build/src' make: *** [all-recursive] Error 1 -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS: SIGSEGV when inserting math env.
On Tue, Jun 25, 2002 at 01:31:47PM +0900, R. Lahaye wrote: lyx -dbg MATHED provides the attached output. This is the expected output, most of it coming from reading lib/symbol. It just looks fine. This comes from simpy do File-New and the click on the mathed icon on the icon-taskbar. Does this give a clue? Not really. (see earlier email for gdb-backtrace). Even that. What compiler, what machine was that? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: cs does not link
On Tue, Jun 25, 2002 at 07:24:13AM +0200, Andre' Poenitz wrote: lyxfunc.o: In function `LyXFunc::verboseDispatch(kb_action, basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const , bool)': /usr/src/lyx/lyx-build/src/../../lyx-devel/src/lyxfunc.C:833: undefined reference to `MiniBuffer::addSet(basic_stringchar, string_char_traitschar, __default_alloc_templatetrue, 0 const )' This is because Minibuffer.C is not in the Makefile although it is in Makefile.am. Strange. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Space
On Sat, Jun 22, 2002 at 09:50:08AM +0300, Gady Kozma wrote: > no longer adds a space after it. Is this intentional? Not exactly. > If so, the tutorial should be updated (section 4.2). Maybe somebody > could write a short "UI things that changed from 1.1.6 to 1.2 and you > need to readjust" doc. The goal is actually 'make 1.2 behave as 1.1.6 and document things when this is not possible'. And yes, somebody would have to document these things. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS: SIGSEGV when inserting math env.
On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote: > CVS 1.3.0 as of June 19th. Do following: > > 1. Start LyX > 2. File -> New > 3. Insert mathed with, for example, the math tool > > kaboom: SIGSEGV!! There seems to be some problem with the dependency tracking for recompilation. I've seen similar and a clean recompile helped. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Menu re-organisation
On Fri, Jun 21, 2002 at 07:31:05AM +0100, John Levon wrote: > o dunno where to put preferences. Tools is a possibility, but that sucks > o insert is still far too clumsy Edit? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
configure with qt2 frontend on FreeBSD fails!?!
Hi, I do: $ ./autogen.sh $ ./configure --with-frontend=qt2 \ --with-qt2-includes=/usr/X11R6/include/qt2 \ --with-qt2-libraries=/usr/X11R6/lib which ends with: [...] checking for X11/forms.h... no checking for forms.h... yes checking xforms header version... 0.88.1 checking for Qt... configure: error: Qt2 (headers and libraries) not found. Please check your installation! What's wrong? "ls /usr/X11R6/include/qt2" has: jri.h jritypes.h npapi.h npupp.h q1xcompatibility.h qabstractlayout.h qaccel.h [...] qwmatrix.h qworkspace.h qxml.h qxt.h and "ls /usr/X11R6/lib | grep qt" has: libqt1.so libqt1.so.3 libqt2-mt.so libqt2-mt.so.4 libqt2.so libqt2.so.4 libqtgl.so libqtgl.so.4 Any idea why the qt-configure script fails on my FreeBSD PC? Regards, Rob.
[PATCH] graphics stuff
here comes a total diff of my graphics stuff, which I posted more
than one time to the list in smaller pieces! It fixes several bugs.
If no one is interested then let it be ...
Herbert
--
http://www.lyx.org/help/
Index: src/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/ChangeLog,v
retrieving revision 1.775
diff -u -r1.775 ChangeLog
--- src/ChangeLog 21 Jun 2002 11:35:39 - 1.775
+++ src/ChangeLog 24 Jun 2002 07:58:00 -
@@ -1,3 +1,8 @@
+2002-06-23 Herbert Voss <[EMAIL PROTECTED]>
+
+ * lengthcommon.C:
+ * lyxlength.[Ch]: support vertical length for imahe scaling
+
2002-06-21 John Levon <[EMAIL PROTECTED]>
* lyxrc.h:
Index: src/lengthcommon.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lengthcommon.C,v
retrieving revision 1.3
diff -u -r1.3 lengthcommon.C
--- src/lengthcommon.C 27 Mar 2002 12:27:17 - 1.3
+++ src/lengthcommon.C 24 Jun 2002 07:58:00 -
@@ -8,7 +8,8 @@
char const * unit_name[num_units] = {
"sp", "pt", "bp", "dd", "mm", "pc", "cc", "cm",
"in", "ex", "em", "mu",
- "text%", "col%", "page%", "line%" };
+ "text%", "col%", "page%", "line%",
+ "theight%", "pheight%" };
LyXLength::UNIT unitFromString(string const & data)
Index: src/lyxlength.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlength.C,v
retrieving revision 1.16
diff -u -r1.16 lyxlength.C
--- src/lyxlength.C 10 Jun 2002 07:57:36 - 1.16
+++ src/lyxlength.C 24 Jun 2002 07:58:00 -
@@ -47,7 +47,8 @@
return subst(oldLength,"c%","col%");
} else if (oldLength.find("t%") != string::npos) {
- if (oldLength.find("text%") != string::npos)
+ if (oldLength.find("text%") != string::npos ||
+ oldLength.find("height%") != string::npos)
return oldLength;
else
return subst(oldLength,"t%","text%");
@@ -113,6 +114,14 @@
buffer << abs(static_cast(val_/100)) << "."
<< abs(static_cast(val_)%100) << "\\linewidth";
break;
+ case PH:
+ buffer << abs(static_cast(val_/100)) << "."
+ << abs(static_cast(val_)%100) << "\\paperheight";
+ break;
+ case TH:
+ buffer << abs(static_cast(val_/100)) << "."
+ << abs(static_cast(val_)%100) << "\\textheight";
+ break;
default:
buffer << val_ << unit_name[unit_]; // setw?
break;
@@ -230,6 +239,10 @@
case LyXLength::PP:
case LyXLength::PL:
result = val_ * default_width / 100;
+ break;
+ case LyXLength::PH:
+ case LyXLength::TH:
+ result = val_ * default_height / 100;
break;
case LyXLength::UNIT_NONE:
result = 0; // this cannot happen
Index: src/lyxlength.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxlength.h,v
retrieving revision 1.7
diff -u -r1.7 lyxlength.h
--- src/lyxlength.h 11 Apr 2002 18:36:18 - 1.7
+++ src/lyxlength.h 24 Jun 2002 07:58:00 -
@@ -36,10 +36,12 @@
EX, ///< Height of a small "x" for the current font.
EM, ///< Width of capital "M" in current font.
MU, ///< Math unit (18mu = 1em) for positioning in math mode
- PW, ///< Percent of columnwidth both "%" or "%c"
- PE, ///< FIXME
+ PW, ///< Percent of columnwidth
+ PE, ///< Percent of textwidth
PP, ///< Percent of pagewidth
PL, ///< Percent of linewidth
+ TH, ///< Percent of textheight // Herbert 2002-05-16
+ PH, ///< Percent of paperheight // Herbert 2002-05-16
UNIT_NONE ///< no unit
};
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.191
diff -u -r1.191 ChangeLog
--- src/frontends/controllers/ChangeLog 21 Jun 2002 16:35:29 - 1.191
+++ src/frontends/controllers/ChangeLog 24 Jun 2002 07:58:00 -
@@ -1,3 +1,10 @@
+2002-06-23 Herbert Voss <[EMAIL PROTECTED]>
+
+ * ControlBibtex.C:
+ * tex_helpers.C: test of existing file only in tex_helpers
+
+ * ControlGraphics.C: comments
+
2002-06-21 Angus Leeming <[EMAIL PROTECTED]>
* tex_helpers.C: Use not . Reorder header files.
Index: src/frontends/controllers/ControlBibtex.C
===
RCS file:
Re: sciword bindings + M-x
On Thu, Jun 20, 2002 at 10:47:31PM +0100, John Levon wrote: > Should I kill screen-recenter to allow M-x for accessing the minibuffer > ? What is 'screen-recenter' supposed to do? Andr'e -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: CVS: SIGSEGV when inserting math env.
Andre Poenitz wrote: > > On Wed, Jun 19, 2002 at 11:49:11AM +0900, R. Lahaye wrote: > > CVS 1.3.0 as of June 19th. Do following: > > > > 1. Start LyX > > 2. File -> New > > 3. Insert mathed with, for example, the math tool > > > > kaboom: SIGSEGV!! > > There seems to be some problem with the dependency tracking for > recompilation. I've seen similar and a clean recompile helped. Nope. The SIGSEGV persist after a "make maintainer-clean" and even after a complete fresh download of lyx-devel from CVS! So it can't be a dependency problem. Does my gdb-backtrace at http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg39632.html give a clue? Remember that we had similar problem before. Rob.
Re: [PATCH] graphics stuff
Herbert Voss <[EMAIL PROTECTED]> writes: | here comes a total diff of my graphics stuff, which I posted more | than one time to the list in smaller pieces! It fixes several bugs. > | If no one is interested then let it be ... Did you ever answer Jean-Marcs question about changeExtension? (i.e. Is it really needed?) As to the earlier times when you have posted parts of this patch... there has been comments, questions and request that never got answered (and still aren't), or you posted that patch at a time when it could never be committed. -- Lgb
Re: sciword bindings + M-x
Andre Poenitz <[EMAIL PROTECTED]> writes: | On Thu, Jun 20, 2002 at 10:47:31PM +0100, John Levon wrote: >> Should I kill screen-recenter to allow M-x for accessing the minibuffer >> ? > | What is 'screen-recenter' supposed to do? Ctrl-l Scroll the screen so that the cursor is at the middle (top-down), and/or repaint the screen. -- Lgb
Re: configure with qt2 frontend on FreeBSD fails!?!
On Monday 24 June 2002 7:56 am, R. Lahaye wrote: > Hi, > > I do: > > $ ./autogen.sh > $ ./configure --with-frontend=qt2 \ > --with-qt2-includes=/usr/X11R6/include/qt2 \ > --with-qt2-libraries=/usr/X11R6/lib > > which ends with: > > [...] > checking for X11/forms.h... no > checking for forms.h... yes > checking xforms header version... 0.88.1 > checking for Qt... configure: error: Qt2 (headers and libraries) not found. > Please check your installation! > > What's wrong? > > "ls /usr/X11R6/include/qt2" has: Well this isn't exactly a nornal place for "sysytem" header files. Do you have environment variables QTDIR, QTINC, QTLIB set? If not, I'm not surprised that they can't be found. > and "ls /usr/X11R6/lib | grep qt" has:patibility.h why on earth do you have header files in a lib directory? > Any idea why the qt-configure script fails on my FreeBSD PC? Didnt you have some problems in the early days of all this? I seem to remember that a lot of special casing code has been removed for the time being. The "guy who knows" (John) has dissappeared for a few weeks, so I don't think I can help much. Anyway, once you configure, you won't be able to compile. Wait a while... Angus
the minibuffer
I thought I'd try and move the minibuffer behind the frontends firewall and
so had a look at which functions are used by the "general public". It
transpires that only addSet and getString are used.
I propose, therefore, getting rid entirely of LyXView::getMiniBuffer() and
replacing it with two boost::functions. The minibuffer can then disappear
from view.
Any objections? Reasons please...
aleem@pneumon:src-> grep -n "getMiniBuffer()" *.C */*.C */*/*.C
lyxfunc.C:827:
owner->getMiniBuffer()->addSet(commandshortcut);lyxfunc.C:830:
owner->getMiniBuffer()->addSet(' ' + commandshortcut);
lyxfunc.C:1050: owner->getMiniBuffer()->getString(MiniBuffer::spaces,
frontends/LyXView.C:118:MiniBuffer * LyXView::getMiniBuffer() const
frontends/xforms/XFormsView.C:81: getMiniBuffer()->redraw();
LyXView "owns" the minibuffer and XFormsView derives from LyXView so these
don't count. That means that the only functions of interest are:
void MiniBuffer::addSet(string const & s1, string const & s2)
{
string const str = text + ' ' + s1 + ' ' + s2;
message(str);
}
* Note that s2 is NEVER used. Shall I kill it?
* This command is used to append the command shortcut to the displayed
lyxfunc. Might a better name be "void appendShortCut(string const & sc)"?
/** Makes the minibuffer wait for a string to be inserted.
Waits for a string to be inserted into the minibuffer, when
the string has been inserted the signal stringReady is
emitted.
*/
void MiniBuffer::getString(State spaces,
vector const & completion,
vector & history)
{
state_ = spaces;
completion_ = completion;
history_ =
hist_iter = history_->end();
prepare();
}
* Again, I think that this name is confusing. Why not prepareBuffer(...)? or
some such?
Angus
Re: the minibuffer
Angus Leeming <[EMAIL PROTECTED]> writes:
| I thought I'd try and move the minibuffer behind the frontends firewall and
| so had a look at which functions are used by the "general public". It
| transpires that only addSet and getString are used.
>
| I propose, therefore, getting rid entirely of LyXView::getMiniBuffer() and
| replacing it with two boost::functions. The minibuffer can then disappear
| from view.
>
| Any objections? Reasons please...
I am not sure how this will look.
>
| aleem@pneumon:src-> grep -n "getMiniBuffer()" *.C */*.C */*/*.C
| lyxfunc.C:827:
| owner->getMiniBuffer()->addSet(commandshortcut);lyxfunc.C:830:
| owner->getMiniBuffer()->addSet(' ' + commandshortcut);
| lyxfunc.C:1050: owner->getMiniBuffer()->getString(MiniBuffer::spaces,
| frontends/LyXView.C:118:MiniBuffer * LyXView::getMiniBuffer() const
| frontends/xforms/XFormsView.C:81: getMiniBuffer()->redraw();
>
| LyXView "owns" the minibuffer and XFormsView derives from LyXView so these
| don't count. That means that the only functions of interest are:
>
| void MiniBuffer::addSet(string const & s1, string const & s2)
| {
| string const str = text + ' ' + s1 + ' ' + s2;
| message(str);
| }
>
| * Note that s2 is NEVER used. Shall I kill it?
Yes.
| * This command is used to append the command shortcut to the displayed
| lyxfunc. Might a better name be "void appendShortCut(string const & sc)"?
Isn't it also used internally in the minibuffer? For telling then end
of history is reached etc. ?
| /** Makes the minibuffer wait for a string to be inserted.
| Waits for a string to be inserted into the minibuffer, when
| the string has been inserted the signal stringReady is
| emitted.
| */
| void MiniBuffer::getString(State spaces,
| vector const & completion,
| vector & history)
| {
| state_ = spaces;
| completion_ = completion;
| history_ =
| hist_iter = history_->end();
| prepare();
| }
>
| * Again, I think that this name is confusing. Why not prepareBuffer(...)? or
| some such?
If you read the comment the same of the funciton is perfectly sane..
IMHO.
We use it to get a string (and it is delivered through a signal.)
--
Lgb
Re: the minibuffer
On Monday 24 June 2002 10:37 am, Lars Gullik Bjønnes wrote:
> Angus Leeming <[EMAIL PROTECTED]> writes:
> | I thought I'd try and move the minibuffer behind the frontends firewall
> | and so had a look at which functions are used by the "general public". It
> | transpires that only addSet and getString are used.
> |
> | I propose, therefore, getting rid entirely of LyXView::getMiniBuffer()
> | and replacing it with two boost::functions. The minibuffer can then
> | disappear from view.
> |
> | Any objections? Reasons please...
>
> I am not sure how this will look.
lyxview().minibufferAddSet(...);
or isn't this what you mean?
> | * This command is used to append the command shortcut to the displayed
> | lyxfunc. Might a better name be "void appendShortCut(string const & sc)"?
>
> Isn't it also used internally in the minibuffer? For telling then end
> of history is reached etc. ?
No. Maybe it was once, but no more:
aleem@pneumon:src-> grep -n addSet minibuffer.*
minibuffer.C:355:void MiniBuffer::addSet(string const & s1, string const & s2)
minibuffer.h:42:void addSet(string const &,
>
> | /** Makes the minibuffer wait for a string to be inserted.
> | Waits for a string to be inserted into the minibuffer, when
> | the string has been inserted the signal stringReady is
> | emitted.
> | */
> | void MiniBuffer::getString(State spaces,
> |vector const & completion,
> |vector & history)
> | * Again, I think that this name is confusing. Why not prepareBuffer(...)?
> | or some such?
>
> If you read the comment the same of the funciton is perfectly sane..
> IMHO.
> We use it to get a string (and it is delivered through a signal.)
Well you might call it sane. I'm not going to call it insane, just clumsy.
foo::callingFunc()
{
minibuffer.getString();
}
foo::receivingFunc is connected to minibuffer::signalReady.
To my eyes, this code suggests that I now have a string to manipulate,
whereas actually I have nothing until another foo function is called when
the signal is emitted. So, why not reflect this reality in the names:
void minibuffer::prepareForInput(...);
boost::signal1 minibuffer::inputString;
Incidentally, I for one would be happier if the excesssive name calling
that's been creeping into this list recently were to creep out again. No,
this isn't directed at Lars; I think he's had to bear the brunt of the abuse
recently. To my eyes "STFU" helps no-one.
Angus
variable naming
Can anybody please explain to me in simple words the variable naming in the
following snippet taken from FormDialog.C?
void UserCache::add(uid_t ID) const
{
string pszNewName;
[...]
It almost made me spill tea over the keyboard together with some
yellowish-green liquid fairly similar to the one we've seen in the zoo in
Maia (although it originated from a tiger there).
Apart from that the forms/form_filedialog.h included in line 77 in that
file does not exist on my machine and is not rebuild after a clean
checkout. Actually, I do not understand most of the code between lines 50
and 80 there.
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
lyx configure script
Hi,
I had a bit of a problem with the lyx configure script on a cygwin
environment.
The following check only works if the sh shell points to the bash
shell.
### Adjust PATH for Win32 (Cygwin)
if test "x$OSTYPE" = xcygwin; then
echo "configure: cygwin detected; path correction"
srcdir=`cygpath -w "${srcdir}" | tr '' /`
echo "srcdir=${srcdir}"
fi
To my knowledge there is no OSTYPE defined on the sh shell that is
something specific to bash. Perhaps that should be mentioned somewhere.
Alternatively the following check should be sufficient for both bash
and sh.
if test -f /bin/cygwin1.dll; then
Ok that is not really a check for the enviroment we are on but at
least it works and I can't imagination that a cygwin1.dll is on a
non cygwin system found.
Soeren
==
When you don't know what to do, walk fast and look worried.
Re: variable naming
On Monday 24 June 2002 11:04 am, Andre Poenitz wrote:
> Can anybody please explain to me in simple words the variable naming in the
> following snippet taken from FormDialog.C?
>
> void UserCache::add(uid_t ID) const
> {
> string pszNewName;
> [...]
>
> It almost made me spill tea over the keyboard together with some
> yellowish-green liquid fairly similar to the one we've seen in the zoo in
> Maia (although it originated from a tiger there).
At last! Someone else who finds that code foul! I have avoided touching it
for two years because it's so disgusting; in fact it's the only dialog in the
frontends that hasn't become a daughter of FormBase (or FormBaseDeprecated)
for this very reason.
> Apart from that the forms/form_filedialog.h included in line 77 in that
> file does not exist on my machine and is not rebuild after a clean
> checkout. Actually, I do not understand most of the code between lines 50
> and 80 there.
>
> Andre'
All the forms/form_*.[Ch] files are now autogenerated. As such, you'll
probably find them in your build tree, not your src tree.
Angus
Re: variable naming
On Mon, Jun 24, 2002 at 10:58:44AM +0100, Angus Leeming wrote: > All the forms/form_*.[Ch] files are now autogenerated. As such, you'll > probably find them in your build tree, not your src tree. I looked in either. Some of the form_*.[Ch] were there, some not (_about* was missing, too) Anyway. I try a really clean checkout/rebuild right now. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
mathed rendering broken
Attached is a small LyX document who's mathed rendering is broken with
current cvs. Attached also are a couple of screen shots of the old and new
appearances.
Any ideas, André?
Angus
#LyX 1.2 created this file. For more info see http://www.lyx.org/
\lyxformat 220
\textclass article
\language english
\inputencoding auto
\fontscheme default
\graphics default
\paperfontsize default
\papersize Default
\paperpackage a4
\use_geometry 0
\use_amsmath 0
\use_natbib 0
\use_numerical_citations 0
\paperorientation portrait
\secnumdepth 3
\tocdepth 3
\paragraph_separation indent
\defskip medskip
\quotes_language english
\quotes_times 2
\papercolumns 1
\papersides 1
\paperpagestyle default
\layout Standard
\begin_inset FormulaMacro
\newcommand{\integral}[3]{\int _{#1}^{#2}\! \! \textrm{d}#3\; }
\end_inset
\layout Standard
\begin_inset Formula \begin{equation}
M=\integral{A}{}{A}\rho \qquad .\end{equation}
\end_inset
\the_end
1_2_X.png
Description: PNG image
1.3.cvs.png
Description: PNG image
Re: mathed rendering broken
On Mon, Jun 24, 2002 at 11:05:32AM +0100, Angus Leeming wrote:
> Attached is a small LyX document who's mathed rendering is broken with
> current cvs. Attached also are a couple of screen shots of the old and new
> appearances.
>
> Any ideas, André?
My first idea was to have a look as soon as I got LyX compiled ;-}
Apart from that it looks like one of the bugs I fixed when in José's
custody, but I haven't applied thes to CVS yet.
Andre'
PS: Since I have you on the line: Would it be possible to separate the
graphics loading in some low-level and some high-level part? I need just
the "load a graphics and give me an ('owning') handle" (i.e. low-level)
part and I do /not/ have a InsetGraphics around which seems to be needed
for the cache part (which should then be come the 'high-level part')?
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: variable naming
On Monday 24 June 2002 11:16 am, Andre Poenitz wrote: > On Mon, Jun 24, 2002 at 10:58:44AM +0100, Angus Leeming wrote: > > All the forms/form_*.[Ch] files are now autogenerated. As such, you'll > > probably find them in your build tree, not your src tree. > > I looked in either. Some of the form_*.[Ch] were there, some not (_about* > was missing, too) You mean both... Linguistic splitting of hairs aside, I'd be interested in discovering what's going on. It's a new adventure for me this makefile stuff and I found it quite confusing at times. Of course, you could be demonstrating that your dependency tracking has goine mad yet again ;-) > Anyway. I try a really clean checkout/rebuild right now. That's a little excessive ;-) Why not cd build/src/frontends/xforms/forms make clean make or even rm -f form* make or more elegantly (?) trigger a rebuild with cd lyxsrc/src/frontends/xforms/forms touch *.fd cd lyxbuild/src/frontends/xforms/forms make Angus
Re: variable naming
Angus Leeming <[EMAIL PROTECTED]> writes: | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll | probably find them in your build tree, not your src tree. One note though... I do not agree to when this is generated, now you generate upon compile, right? It should be done on autogen, so that a source distribution does not require users to have fdesign installed. -- Lgb
Re: variable naming
On Mon, Jun 24, 2002 at 11:14:04AM +0100, Angus Leeming wrote: > > I looked in either. Some of the form_*.[Ch] were there, some not (_about* > > was missing, too) > > You mean both... I looked in both. That should include either, shouldn't it? > Linguistic splitting of hairs aside, Oh... ;-} > I'd be interested in discovering what's going on. It's a new adventure > for me this makefile stuff and I found it quite confusing at times. Of > course, you could be demonstrating that your dependency tracking has > goine mad yet again ;-) My personal feeling is that the Makefiles used by LyX are far too heavy and I wonder from time to time whether hand-made would be better. But then, I do not have too much experience with cross-platform make. > > Anyway. I try a really clean checkout/rebuild right now. > > That's a little excessive ;-) Why not cd build/src/frontends/xforms/forms > make clean make Because just 'cd lyx-build ; rm -rf * ; ../lyx-devel/configure ; make' did not work. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: variable naming
On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll > | probably find them in your build tree, not your src tree. > > One note though... I do not agree to when this is generated, now you > generate upon compile, right? It should be done on autogen, so that a > source distribution does not require users to have fdesign installed. Can I convince you that you're wrong? Probably not ;-) Anyway here is why I prefer the current approach: 1. What is wrong with forcing the users to install fdesign? It's the appropriate compilation tool. (You insist on a C== compiler for .C code...) In effect, you are special-casing the xforms frontend. The qt frontend will require uic to be present. Ditto, gnome will require glade. 2. The makefile is used to rebuild object files when a src file is changed. In this case, the src file is the .fd file. When it's modified all is rebuilt correctly. If we adopt your proposal, then that is no longer the case. Angus
Re: mathed rendering broken
On Monday 24 June 2002 11:23 am, Andre Poenitz wrote:
> PS: Since I have you on the line: Would it be possible to separate the
> graphics loading in some low-level and some high-level part? I need just
> the "load a graphics and give me an ('owning') handle" (i.e. low-level)
> part and I do /not/ have a InsetGraphics around which seems to be needed
> for the cache part (which should then be come the 'high-level part')?
And now we're going to need such an approach for the splash screen it would
appear. Yes such a thing is possible. Yes, I'll concentrate on it.
My list of things to do:
* clean-up the graphics
* move minibuffer behind the frontends firewall (I think that that will mean
that the LyX core will then know nothing about the frontends at all)
* introduce a controller-view split to the minibuffer.
* help John with his "event-driven" rendering of the LyX screen. Now on the
back burner since he's gone on LyX-holiday ;-)
* clean up the controllers heirarchy so that more things are "has a" rather
than "is a".
* introduce a controller-view split to the remaining few dialogs derived from
FromBaseDeprecated.
* introduce my wrappers for xforms. I'll probably start with the minibuffer
here since that is what I'm currently thinking about. Certainly the current
xforms rubbish should be replaced by a combox...
As you can see, most of this can be classified as code cleanup rather than
new functionality. I'm quite happy to concentrate on the graphics stuff
rather than choose another area.
Most importantly:
do some real work.
How was the extended holiday?
Angus
Re: expose is broken
On Sat, Jun 22, 2002 at 08:42:19AM +0200, Lars Gullik Bjønnes wrote: > | More informed bug reports are welcome. > > Meaning that my report is wrong or that you want more details? More details. But looking it's obvious - your WM doesn't do saveunders for menus, and we're not doing the copy of the pixmap at FL_DRAW time. Related to the stuff me & angus were talking aobut. > > And I am at least pestering someone about the problems I see. > If you (or anyone else) just keep quiet how am I supposed to know that > you still have a problem. Yes, I remember how quiet everyone was about the boost changes. > Because the boost changes are making a _running_ lyx misbehave in what > way? (and are you really unable to keep issues separate?) Because I was drunk gimme a break ... regards john -- "If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared." - St. Augustine
Re: cursor_follows_scrollbar
On Mon, Jun 24, 2002 at 12:16:10PM +1000, Allan Rae wrote: > I was actually referring to myself here not you. But it works either > way. heh > I scroll to where I am working and edit there. There is no going back > because I don't need to -- I rarely use bookmarks in emacs and have > never felt the need to use them in my LyX docs. If I need to check > something that something is almost always in a different file > so there is no jumping around within a single file. > > FYI, this option provides consistency and conformity with [X]Emacs > operation. We all know how much you hate emacs but as it is a major > "standard" for Unix users -- particularly for emacs+AucTeX users who > move to LyX -- it should hopefully be considered a valid useability > arguement. Sounds good to me. I'm not completely unreasonable you know. > And please don't bother lecturing me about horrible emacs' interface > is in your opinion. It works for me and thousands of others. But > numbers don't count do they? Of course they do. But they are by no means the sole argument. > > You're kidding, right ? Have you any idea how long that list is :) > > No, I have no idea how long your list is, so I am asking to see it. To quote from Dilbert : It's not so much a physical list as a philosophy. > Then the (likely to be the majority) non-contraversial group can be > agreed upon quickly and cleaned out and subthreads arguing the cases > for whatever is contraversial can then take place. To actually generate such a list would take a few days of close examination and application of heuristics to LyX's UI. I'd much rather deal with things on a case-by-case, so things like show banner can be removed quickly, and more controversial things can be, um, more controversial :) john -- "If a thing is not diminished by being shared, it is not rightly owned if it is only owned & not shared." - St. Augustine
Re: expose is broken
On Monday 24 June 2002 12:02 pm, John Levon wrote: > On Sat, Jun 22, 2002 at 08:42:19AM +0200, Lars Gullik Bjønnes wrote: > > | More informed bug reports are welcome. > > > > Meaning that my report is wrong or that you want more details? > > More details. But looking it's obvious - your WM doesn't do saveunders > for menus, and we're not doing the copy of the pixmap at FL_DRAW time. > Related to the stuff me & angus were talking aobut. As I see it, the current code is much the same as the old code. The philosophy behind the code has not changed yet anyway. So do the changes you've introduced so far fall between two stools? Ie, they are neither the new way nor the old way, they're just broken? More importantly, is it fixable without going the whole way? As you'll gather, I'm confused by what you actually did commit on Friday. Could you post the patch and/or explain it? Certainly give an explantation of what you did and why. Help us keep up with you ;-) > > And I am at least pestering someone about the problems I see. > > If you (or anyone else) just keep quiet how am I supposed to know that > > you still have a problem. > > Yes, I remember how quiet everyone was about the boost changes. > > > Because the boost changes are making a _running_ lyx misbehave in what > > way? (and are you really unable to keep issues separate?) > > Because I was drunk gimme a break ... Bad behaviour when drunk is still bad behaviour. STFU is no way to behave. An old prude.
Re: variable naming
On Mon, Jun 24, 2002 at 11:29:52AM +0100, Angus Leeming wrote: > 1. What is wrong with forcing the users to install fdesign? It's the > appropriate compilation tool. (You insist on a C== compiler for .C code...) > In effect, you are special-casing the xforms frontend. The qt frontend will > require uic to be present. Ditto, gnome will require glade. Isn't this similar to distrubute the configure script to relieve the user from running automake and autoconf? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: mathed rendering broken
On Mon, Jun 24, 2002 at 11:42:40AM +0100, Angus Leeming wrote: > [...] > And now we're going to need such an approach for the splash screen it would > appear. Yes such a thing is possible. Yes, I'll concentrate on it. That's a good thing to hear. > [...] > How was the extended holiday? Nice indeed. And shame on you people that you did not show up. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: mathed rendering broken
On Monday 24 June 2002 12:27 pm, Andre Poenitz wrote: > > How was the extended holiday? > > Nice indeed. > > And shame on you people that you did not show up. Shame indeed. I worked till 2am every night that weekend on a grant proposal that should have been done weeks before. The deadline was 8pm Monday and some colleagues have different ideas about sensible working practices to me. Unfortunately, two of them are called Prof, so it can be difficult telling them in language sufficiently simple that they understand. Angus
Re: Mathematica's facilities with lyx...
On Mon, Jun 24, 2002 at 07:43:51AM +0200, Andre Poenitz wrote: > You basically have to add a function 'mathematicize' (or whatever) to every > math inset (or at least to the ones you are interested in) and there you > put code to transform the inset into Mma syntax. Usually you should be able > to copy the 'maplize' function and replace parantheses by square brackets > and things like that. Than you need to have a look add math_extern.C and > formulabase.C and hook calls to these new functions in. It is not very nice to have this hardcoded in the LyX sources. can't you do it in external scripts, like the first implementation ? Another idea would be to use text template files. For example, an extern_maple would be something like Insets frac ($0)/($1) sqrt sqrt($0) ... End Header readlib(latex): latex/csname_font := `: ... End
Re: Mathematica's facilities with lyx...
On Mon, Jun 24, 2002 at 03:05:59PM +0300, Dekel Tsur wrote: > It is not very nice to have this hardcoded in the LyX sources. I know. > can't you do it in external scripts, like the first implementation ? The external scripts would have to re-create the structure used within mathed (more or less). I just got tired of re-implemting mathed a second and third time. > Another idea would be to use text template files. > For example, an extern_maple would be something like > > Insets > frac ($0)/($1) > sqrt sqrt($0) > ... > End Have a go. But I think I'll do something like that myself some day when the math-extern stuff has reached some critical mass that allows me to see what is a "generic common base" and can be used as the hard-coded part, and what is "backend specific" that could be put in such configuration files. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: variable naming
Angus Leeming <[EMAIL PROTECTED]> writes: | On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: >> Angus Leeming <[EMAIL PROTECTED]> writes: >> | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll >> | probably find them in your build tree, not your src tree. >> >> One note though... I do not agree to when this is generated, now you >> generate upon compile, right? It should be done on autogen, so that a >> source distribution does not require users to have fdesign installed. > | Can I convince you that you're wrong? Probably not ;-) Anyway here is why I | prefer the current approach: > | 1. What is wrong with forcing the users to install fdesign? It's the | appropriate compilation tool. (You insist on a C== compiler for .C code...) | In effect, you are special-casing the xforms frontend. The qt frontend will | require uic to be present. Ditto, gnome will require glade. > | 2. The makefile is used to rebuild object files when a src file is changed. | In this case, the src file is the .fd file. When it's modified all is rebuilt | correctly. If we adopt your proposal, then that is no longer the case. just make the form_about.c depend on form_about.fd then... -- Lgb
Re: expose is broken
John Levon <[EMAIL PROTECTED]> writes: | On Sat, Jun 22, 2002 at 08:42:19AM +0200, Lars Gullik Bjønnes wrote: > >> | More informed bug reports are welcome. >> >> Meaning that my report is wrong or that you want more details? > | More details. But looking it's obvious - your WM doesn't do saveunders | for menus, and we're not doing the copy of the pixmap at FL_DRAW time. | Related to the stuff me & angus were talking aobut. _but_ I have never had problems with LyX and saveunders with this WM ealier, so it must be somehting that we do different. >> And I am at least pestering someone about the problems I see. >> If you (or anyone else) just keep quiet how am I supposed to know that >> you still have a problem. > | Yes, I remember how quiet everyone was about the boost changes. I have tried to act on some of those issues, esp. binary size. For gcc 3.0 the binary size is imo more than satisfactory, for 2.96 it as imho acceptable albeit a bit big. >> Because the boost changes are making a _running_ lyx misbehave in what >> way? (and are you really unable to keep issues separate?) > | Because I was drunk gimme a break ... drunkards get no leeway. -- Lgb
Re: variable naming
On Monday 24 June 2002 1:28 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > | On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: > >> Angus Leeming <[EMAIL PROTECTED]> writes: > >> | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll > >> | probably find them in your build tree, not your src tree. > >> > >> One note though... I do not agree to when this is generated, now you > >> generate upon compile, right? It should be done on autogen, so that a > >> source distribution does not require users to have fdesign installed. > | > | Can I convince you that you're wrong? Probably not ;-) Anyway here is why > | I prefer the current approach: > | > | 1. What is wrong with forcing the users to install fdesign? It's the > | appropriate compilation tool. (You insist on a C== compiler for .C > | code...) In effect, you are special-casing the xforms frontend. The qt > | frontend will require uic to be present. Ditto, gnome will require glade. > | > | 2. The makefile is used to rebuild object files when a src file is > | changed. In this case, the src file is the .fd file. When it's modified > | all is rebuilt correctly. If we adopt your proposal, then that is no > | longer the case. > > just make the form_about.c depend on form_about.fd then... ??? It does. Not only does all work perfectly for me, but the Makefile.am looks fine too. However, I'm no expert and you are. Could you have a look at Makefile.am and see if there are any glaring errors. FWIW, here's what happens for me: aleem@pneumon:lyx-> cd devel/src/frontends/xforms/forms aleem@pneumon:forms-> touch form_aboutlyx.fd aleem@pneumon:forms-> cd ../../../../../devel-build/src/frontends/xforms/forms aleem@pneumon:forms-> make /bin/sh ../../../../../devel/src/frontends/xforms/forms/fdfix.sh ../../../../../devel/src/frontends/xforms/forms/form_aboutlyx.fd source='form_aboutlyx.C' object='form_aboutlyx.lo' libtool=yes \ depfile='.deps/form_aboutlyx.Plo' tmpdepfile='.deps/form_aboutlyx.TPlo' \ depmode=tru64 /bin/sh ../../../../../devel/config/depcomp \ /bin/sh ../../../../libtool --mode=compile cxx -std strict_ansi -DHAVE_CONFIG_H -I. -I../../../../../devel/src/frontends/xforms/forms -I../../../../src -I../../../../../devel/src/frontends/xforms/forms/.. -I../../../../../devel/src -I/usr/local/include-nopure_cname -nocleanup -msg_display_number -w1 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel-build/lyx_cxx_repository -O2 -c -o form_aboutlyx.lo `test -f form_aboutlyx.C || echo '../../../../../devel/src/frontends/xforms/forms/'`form_aboutlyx.C cxx -std strict_ansi -DHAVE_CONFIG_H -I. -I../../../../../devel/src/frontends/xforms/forms -I../../../../src -I../../../../../devel/src/frontends/xforms/forms/.. -I../../../../../devel/src -I/usr/local/include -nopure_cname -nocleanup -msg_display_number -w1 -ptr /usr/users/aleem/OTHERS_CODE/lyx/devel-build/lyx_cxx_repository -O2 -c -MD form_aboutlyx.C echo timestamp > form_aboutlyx.lo
Re: the minibuffer
It seems that the changes Juergen and I did to the minibuffer from Porto has not been included? We did rework all of these methods... Greets, Asger
Re: variable naming
Angus Leeming <[EMAIL PROTECTED]> writes: | On Monday 24 June 2002 1:28 pm, Lars Gullik Bjønnes wrote: >> Angus Leeming <[EMAIL PROTECTED]> writes: >> | On Monday 24 June 2002 11:28 am, Lars Gullik Bjønnes wrote: >> >> Angus Leeming <[EMAIL PROTECTED]> writes: >> >> | All the forms/form_*.[Ch] files are now autogenerated. As such, you'll >> >> | probably find them in your build tree, not your src tree. >> >> >> >> One note though... I do not agree to when this is generated, now you >> >> generate upon compile, right? It should be done on autogen, so that a >> >> source distribution does not require users to have fdesign installed. >> | >> | Can I convince you that you're wrong? Probably not ;-) Anyway here is why >> | I prefer the current approach: >> | >> | 1. What is wrong with forcing the users to install fdesign? It's the >> | appropriate compilation tool. (You insist on a C== compiler for .C >> | code...) In effect, you are special-casing the xforms frontend. The qt >> | frontend will require uic to be present. Ditto, gnome will require glade. >> | >> | 2. The makefile is used to rebuild object files when a src file is >> | changed. In this case, the src file is the .fd file. When it's modified >> | all is rebuilt correctly. If we adopt your proposal, then that is no >> | longer the case. >> >> just make the form_about.c depend on form_about.fd then... > | ??? It does. Then what it the problem with distributing an up to date form_about.c? | Not only does all work perfectly for me, but the Makefile.am | looks fine too. However, I'm no expert and you are. Could you have a look at | Makefile.am and see if there are any glaring errors. It works for me as well. -- Lgb
redraw problems
Is anything being done about the massive redraw problems (parts of the main window do not get updated when they should). Current CVS is compeltely unusable with that "feature" Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: the minibuffer
Asger Kunuk Alstrup Nielsen <[EMAIL PROTECTED]> writes: | It seems that the changes Juergen and I did to the minibuffer from | Porto has not been included? | We did rework all of these methods... Hmm... I did apply the complete diff... I can check against what I have in the Porto CVS repository. -- Lgb
Re: the minibuffer
On Mon, Jun 24, 2002 at 03:11:43PM +0200, Lars Gullik Bjønnes wrote: > | It seems that the changes Juergen and I did to the minibuffer from > | Porto has not been included? > | We did rework all of these methods... > > Hmm... I did apply the complete diff... > I can check against what I have in the Porto CVS repository. Try that. I had difficulties to apply my last Porto changes to current CVS. This looked as if not every change had made it into CVS... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
