Re: new ostream code
On 8 Mar 2000, Lars Gullik Bjønnes wrote: > > I will begin slowly to remove the code that is dead when > USE_OSTREAM_ONLY is defined. Pending bugreports I am going to do that > in the next two-three days. > > After that is done, I think we should have a new prerelease to get a > broader userbase to have a look. (This will perhaps also be a nice > time for rae to update again?) I'll put in some cvs tags. That would indeed be not only convenient but very good timing. If all goes to my secret plan my branch could be merged into the main trunk by late next week. > Another prelease about a week later. Then again maybe I should hold off on merging gui-indep until after 1.1.5? GUI initialization is likely to stay in lyx_gui.C until we have gotten further down the track with other gui toolkits. Otherwise it gets even more awkward trying to get xforms initialized for the LyXViews and the other toolkit/s for the dialogs. Allan. (ARRae)
Re: LDN future plans
On 8 Mar 2000, Lars Gullik Bjønnes wrote:
> Allan Rae <[EMAIL PROTECTED]> writes:
> | I just downloaded a copy of the latest html-4.01 specification. It has a
> | paragraph saying that redirects via META tags are _bad_ and server side
> | redirects only should be used -- in other words they aren't part of the
> | standard.
>
> What does that give? One point to me?
I'll give you half a point. For a whole point you have to tell me how to
do the equivalent of \hfill{} in html without using a table.
Allan. (ARRae)
P.S. I suspect you may not get that whole point ever
Re: lyx-1.1.5cvs bug: All protected spaces export as ~
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | > | > No it Lars> doesen't but it absolutely should. The best (less maintence | > Lars> problems) would be if this knwledge about the surounding Lars> envronment | > could be done with arguments. | > | | Do you want Lars> to make that change or should I? | | I can easily pass the Lars> freespacing bool around when the inset->latex() functions | get Lars> called. Lars> Is the freespacing bool enough? Ot should we rather pass a Lars> pointer to the surrounding paragraph parameters? I am sure that in other cases other problems will occur... What would be nice is to have a special output stream (the writer) which would now among other things the current paragraph (this is needed anyway to incorporate the texrow stuff in the writer). If we were to pass the freespacing bool, we might as well pass the whole layout info. JMarc
Question on LyXLex
Fast Question: - Is it possible to push back a token read with lex.nextToken() so that when calling another function it can do also lex.nextToken() and get the same? (Hope I explained what I would like to have :) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Make a wish, it might come true. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Using lyx-1.1.2 for the first time
I've just installed LyX 1.1.2 (the most recent stable version) on a Slackware 7 system (glibc-2.1), after reading README and INSTALL, with: ./configure --prefix=/usr/local/pkg/lyx-1.1.2 make make install as user `bin' (who has permission to write to /usr/local/pkg). All went well. (I prefer to install developing programs under /usr/ local/pkg instead of /usr/local, as I can then keep an older version available while a more recent one is being evaluated; the `pkg' (packages) subdirectory keeps /usr/local from getting cluttered.) I made symbolic links from /usr/local/pkg/lyx-1.1.2/bin/* to /usr/ local/bin. Then, as user `john', I moved my existing $HOME/.lyx directory out of the way and ran this lyx. It asked me if I wanted to create a personal LyX directory, and I replied `Yes'. I then got the messages: LyX: Creating directory /usr/john/.lyx and running configure... sh: configure: command not found LyX: Done! LyXTextClassList::Read: unable to find textclass file `~/'. Exiting. The dialogue box: `LyX wasn't able to find its layout descriptions!' Check that the file "textclass.lst" is installed correctly. Sorry, has to exit :-( also appeared. To fix all this, I added `/usr/local/pkg/lyx-1.1.2/share/lyx' and `/usr/share/texmf/bin' (the weird place Slackware 7 puts its TeX executables - what's wrong with /usr/local/bin?!) to my PATH, in order to pick up `configure' and tried again. This fixed it. My question is - what should I have done? A new LyX installer and user could be very confused by what happens. I've seen no mention of the above in the README or INSTALL files. I'm not a subscriber to the LyX developer's list, so I'd be pleased if you would send me any reply directly. John A. Murdie Experimental Officer (Software) Department of Computer Science University of York England
Re: Using lyx-1.1.2 for the first time
> "john" == john <[EMAIL PROTECTED]> writes: john> I've just installed LyX 1.1.2 (the most recent stable version) john> on a Slackware 7 system (glibc-2.1), after reading README and john> INSTALL, with: john> ./configure --prefix=/usr/local/pkg/lyx-1.1.2 make make john> install This should work indeed. However, there is a bug in lyx 1.1.2 in this respect. Upgrading to lyx 1.1.4fix1 should fix your problems. Another solution is to set the environment variable LYX_DIR_11x to point to /usr/local/pkg/lyx-1.1.2/share/lyx. The bug is that lyx is not able to find its data dir by looking at [bindir]/../share/lyx (because of the symlink) and the hardcoded fallback directory is not correct in this version. However, now that I think of it, there is code which is supposed to follow symlinks and find the real binary directory... Could you send the output of "lyx -dbg init"? JMarc
Why do mathed drawing functions take a byte*
I get the following errors with compaq cxx: cxx: Error: ../../../lyx-devel/src/mathed/math_macro.C, line 274: argument of type "const char *" is incompatible with parameter of type "unsigned char *" drawStr(pain, LM_TC_TEX, size, x, baseline, ost.str().c_str(), 2); ^ cxx: Error: ../../../lyx-devel/src/mathed/math_macro.C, line 294: argument of type "const char *" is incompatible with parameter of type "const unsigned char *" width = mathed_string_width(LM_TC_TEX, size, ost.str().c_str(), 2); -^ cxx: Error: ../../../lyx-devel/src/mathed/math_macro.C, line 296: argument of type "const char *" is incompatible with parameter of type "const unsigned char *" ost.str().c_str(), 2, ascent, descent); -^ It appears that MathedInset::drawStr and the string metrics functions in formula.C use byte* as parameter for the string. Is there a reason for that, or can I change them to char const *? JMarc
Porting pop-ups in the rae branch
i thought I'd follow in Allan Rae's footsteps and try and
port a pop-up to frontends.
Thinking, "let's keep this simple", I chose the
Help->Credits pop-up. I now have a FormCredits.[Ch] in the
src/frontends/xforms/ directory and...
it all works!
The changes I've made in src/ are minimal --- remove
credits.[Ch}, credits_form.[Ch] from Makefile.am and change
a FEW lines in LyXAction.C, commandtags.h, lyxfunc.C,
menus.[Ch]
I also modified a FEW lines of a few files in
src/frontends/xforms/ and, of course, created two more,
FormCredits.[Ch] which are closely modelled on
FormCopyright.[Ch]
The close similarity between FormCredits.[Ch] and
FormCopyright.[Ch] (see attachments), suggests that I
should proceed by creating a base class with virtual
build() and two derived classes FormCredits, and
FormCopyright implementing the build() function. Is this a
Good Idea? (I ask because C++ is new to me and I'm learing
as I go ;-).)
Angus
/* FormCredits.C
* FormCredits Interface Class Implementation
*/
#include
#include "lyx_gui_misc.h"
#include "gettext.h"
#include FORMS_H_LOCATION
#include "FormCredits.h"
#include "Dialogs.h"
#include "lyxfunc.h"
#include "support/filetools.h"
#ifdef __GNUG__
#pragma implementation
#endif
extern string system_lyxdir;
FormCredits::FormCredits(LyXFunc * c, Dialogs * d)
: dialog_(0), lf_(c), d_(d), h_(0)
{
// let the dialog be shown
// This is a permanent connection so we won't bother
// storing a copy because we won't be disconnecting.
d->showCredits.connect(slot(this, &FormCredits::show));
}
FormCredits::~FormCredits()
{
free();
}
void FormCredits::build()
{
FL_OBJECT *obj;
FD_form_credits *fdui = dialog_ = new FD_form_credits;
fdui->form_credits = fl_bgn_form(FL_NO_BOX, 500, 330);
fdui->form_credits->u_vdata = this;
obj = fl_add_box(FL_UP_BOX, 0, 0, 500, 330, "");
obj = fl_add_text(FL_NORMAL_TEXT, 10, 10, 480, 30, _("All these people have contributed to the LyX project. Thanks, "));
fl_set_object_lsize(obj, FL_NORMAL_SIZE);
fl_set_object_lalign(obj, FL_ALIGN_CENTER|FL_ALIGN_INSIDE);
fl_set_object_gravity(obj, FL_NorthWest, FL_NorthEast);
obj = fl_add_text(FL_NORMAL_TEXT, 10, 40, 480, 30, _("Matthias"));
fl_set_object_lsize(obj, FL_NORMAL_SIZE);
fl_set_object_lalign(obj, FL_ALIGN_CENTER|FL_ALIGN_INSIDE);
fl_set_object_lstyle(obj, FL_ITALIC_STYLE);
fl_set_object_gravity(obj, FL_NorthWest, FL_NorthEast);
fdui->browser_credits =
obj = fl_add_browser(FL_NORMAL_BROWSER, 10, 80, 480, 200, "");
fl_set_object_gravity(obj, FL_NorthWest, FL_SouthEast);
fdui->button_ok =
obj = fl_add_button(FL_RETURN_BUTTON, 180, 290, 140, 30, _("OK"));
fl_set_object_lsize(obj, FL_NORMAL_SIZE);
fl_set_object_gravity(obj, FL_South, FL_South);
fl_set_object_resize(obj, FL_RESIZE_NONE);
fl_set_object_callback(obj, FormCredits::CreditsOKCB, 0);
fl_end_form();
fdui->form_credits->fdui = fdui;
// Insert the contents of the credits file into browser_credits
string real_file = AddName (system_lyxdir, "CREDITS");
if (!fl_load_browser(fdui->browser_credits, real_file.c_str()))
{
char const
* const line1 = "ERROR: LyX wasn't able to read CREDITS file",
* const line2 = "Please install correctly to estimate the great",
* const line3 = "amount of work other people have done for the LyX project.";
fl_add_browser_line(fdui->browser_credits, _(line1));
fl_add_browser_line(fdui->browser_credits, "");
fl_add_browser_line(fdui->browser_credits, _(line2));
fl_add_browser_line(fdui->browser_credits, _(line3));
}
}
void FormCredits::show()
{
if (!dialog_) {
build();
fl_set_form_atclose(dialog_->form_credits,
FormCredits::CreditsWMHideCB, 0);
}
if (dialog_->form_credits->visible) {
fl_raise_form(dialog_->form_credits);
} else {
fl_show_form(dialog_->form_credits,
FL_PLACE_MOUSE,
FL_FULLBORDER,
_("Credits"));
h_ = d_->hideAll.connect(slot(this, &FormCredits::hide));
}
}
void FormCredits::hide()
{
if (dialog_
&& dialog_->form_credits
&& dialog_->form_credits->visible) {
fl_hide_form(dialog_->form_credits);
h_.disconnect();
}
free();
}
void FormCredits::free()
{
// we don't need to delete h here because
// hide() does that after disconnecting.
if (dialog_) {
if (dialog_->form_credits
&& dialog_->form_credits->visible) {
hide();
}
fl_free_form(dialog_->form_credits);
delete dialog_;
dialog_ = 0;
}
}
int FormCredits::CreditsWMHideCB(FL_FORM * form, void *)
{
// Ensure that the signal h is disconnected even if the
// window manager is used to close the dialog.
FormCredits * pre = (FormCredits*)form->u_vdata;
pre->hide();
return FL_CANCEL;
}
void FormCredits::CreditsOKCB(FL_OBJECT * ob, long)
{
FormCredits * pre = (FormCredits*)ob->form->u_vdata;
pre->hide();
}
// -*- C++ -*-
/* FormCredits.h
* FormCredits Interface Class
*/
#ifndef FORMCREDITS_H
#define FORMCREDITS_H
#include "DialogBase.h"
class Dialogs;
// same arguement as in Dialogs
Macros
Is it true that there is no lyxfunc that simply inserts its argument as text in the current buffer (similar to the behaviour of LFUN_UNKNOWN_ACTION? Or am I just optically chaleenged? Andre' -- It'll take a long time to eat 63.000 peanuts. André Pönitz . [EMAIL PROTECTED]
Re: Macros
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Is it true that there is no lyxfunc that simply inserts its Andre> argument as text in the current buffer (similar to the Andre> behaviour of LFUN_UNKNOWN_ACTION? Andre> Or am I just optically chaleenged? I would think that self-insert works, but I did not check. JMarc
Re: lyx rpms...galore
On Wed, Mar 08, 2000 at 03:35:27AM +0100, Lars Gullik Bjønnes wrote: > > http://rpmfind.net/linux/RPM/lyx.html > > I have no clue on how they locate rpm's. Those are the different rpm's that they have available at their own site. They have it in different folders that correspond to different distributions, contrib sites and so on. Look in http://rufus.w3.org/linux/RPM/ for the base directory, actually this the same as http://rpmfind.net/linux/RPM/ > Lgb -- José
Text inset does not have special double-space handling
Is that really a good thing? JMarc
RE: Text inset does not have special double-space handling
On 08-Mar-2000 Jean-Marc Lasgouttes wrote: > > Is that really a good thing? > Well it does not have ANY space-handling yet :) I would say that it depends on the type of inset if we have spacehandling ore not. IMO that the ERT inset should not have any space-handling as this is LaTeX code and I CAN write as many spaces as I want inside LaTeX code, also between words. For the rest this has to be implemented, but I don't know the best and cleanest way to realize this. There are also a lot of othere "Normal" text features which are to be implemented (Cut/Paste for example!) I'm also aware of at least 2 problems: - the cursor-movement somehow stops before the last character in the inset (I'm pretty sure I can fix this fast ;) - sometimes the cursor does not hide before moving inside the inset and there remains a vertical bar (I tried to have a look but did not find where to fix this problem) - if you have an open collapsabel inset as first character of a paragraph and try to close it it can happen that it opens immediately again. (I fixed this already and commit the changes soon) - there are problems with selection when opening a collapsable inset. LyX thinks that we selected some text (don't know where to find this) - probably some more but as we know TextInsets for now are work in progress. They are stable thought (at least I had no problems with them till now)! Could someone try a memeory management tool on this insets (Michael/Jean-Marc?) Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug Actors will happen even in the best-regulated families. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
new lyx port does not link -- gettext (-lintl is missing)
>Submitter-Id: current-users >Originator: Mikhail Teterin >Organization: Virtual Estates, Inc. >Confidential: no >Synopsis: new lyx port does not link -- gettext (-lintl is missing) >Severity: critical >Priority: medium >Category: ports >Release:FreeBSD 3.4-STABLE i386 >Class: sw-bug >Environment: >Description: It appears, the configure script does check for -lint, and finding it installed on the system already rightfully chooses not to use the included one. Unfortunately, it then does not set the INTLLIB to anything, which means lyx_LDADD in src/Makefile does not mention the -lintl at all and the following linker error is seen. g++295 -O2 -fexpensive-optimizations -pipe -mcpu=i686 -march=i686 -L/usr/X11R6/lib -o lyx BufferView.o Bullet.o Chktex.o DepTable.o FontInfo.o FontLoader.o ImportLaTeX.o ImportNoweb.o LaTeX.o LaTeXFeatures.o LaTeXLog.o Literate.o LyXAction.o LyXSendto.o LyXView.o PaperLayout.o ParagraphExtra.o Spacing.o TableLayout.o bmtable.o buffer.o bufferlist.o bufferparams.o bullet_forms.o bullet_forms_cb.o chset.o combox.o credits.o credits_form.o debug.o filedlg.o form1.o intl.o kbmap.o lastfiles.o latexoptions.o layout.o layout_forms.o lyx.o lyx_cb.o lyx_gui.o lyx_gui_misc.o lyx_main.o lyx_sendfax.o lyx_sendfax_main.o lyx_sty.o lyxdraw.o lyxfont.o lyxfr0.o lyxfr1.o lyxfunc.o lyxlex.o lyxlookup.o lyxrc.o lyxserver.o lyxvc.o main.o menus.o minibuffer.o paragraph.o print_form.o screen.o sp_form.o spellchecker.o table.o tex-accent.o tex-strings.o texoptions.o texrow.o text.o text2.o toolbar.o trans.o trans_mgr.o undo.o vc-backend.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a! support/.libs/libsupport.a -lxforms -lXpm -lSM -lICE -liberty -lc -lm -L/usr/X11R6/lib -lX11 BufferView.o: In function `BufferView::resizeCurrentBuffer(void)': BufferView.o(.text+0x96c): undefined reference to `gettext' BufferView.o: In function `BufferView::gotoError(void)': BufferView.o(.text+0xe5b): undefined reference to `gettext' BufferView.o(.text+0xef9): undefined reference to `gettext' Chktex.o: In function `Chktex::scanLogFile(TeXErrors &)': Chktex.o(.text+0x5b3): undefined reference to `gettext' FontLoader.o: In function `FontLoader::doLoad(LyXFont::FONT_FAMILY, LyXFont::FONT_SERIES, LyXFont::FONT_SHAPE, LyXFont::FONT_SIZE)': FontLoader.o(.text+0xad3): undefined reference to `gettext' LaTeX.o(.text+0x591): more undefined references to `gettext' follow main.o: In function `main': main.o(.text+0x98): undefined reference to `bindtextdomain' main.o(.text+0xa8): undefined reference to `textdomain' menus.o: In function `Menus::openByName(lyxstring const &)': menus.o(.text+0x292): undefined reference to `gettext' menus.o(.text+0x2c3): undefined reference to `gettext' menus.o(.text+0x2f4): undefined reference to `gettext' menus.o(.text+0x32c): undefined reference to `gettext' menus.o(.text+0x35d): undefined reference to `gettext' menus.o(.text+0x38e): more undefined references to `gettext' follow collect2: ld returned 1 exit status *** Error code 1 Stop. [...] >How-To-Repeat: >Fix: A dirty fix is to add the -lintl to the lyx_LDADD line in src/Makefile after configure. A clean fix is too complicated I'm afraid of the configure.in/configure mess.
platypus (fwd)
Would someone mind translating this for me? My high school German is getting awfully rusty ... Mike [EMAIL PROTECTED] -- Forwarded message -- Date: Wed, 08 Mar 2000 15:36:12 +0100 From: Jonas Meurer <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: platypus Hallo Mike Es geht um deinen graphischen Rundgeng über LyX: Wenn ich alles genauso mache, wie du es beschreibst, wird diese(s) Platypus auf der zweiten Seite ganz oben, das heisst vor - A decedt LaTeX2e instalation... ... ... 2 Other Stuff The following is the famous platypus EPS file abgebildet, anstatt danach, obwohl ich die Abbildung unterhalb dieses Abschnittes eingefügt habe. Man sieht diesen Fehler also erst beim drucken oder bei "DVI anzeigen". Gibt es für dieses Phänomen eine Erklärung? Wie kann ich so was verändern? Danke schon mal mfG Jonas
Re: problem with RPM
On Wed, Mar 08, 2000 at 06:02:37PM +0100, [EMAIL PROTECTED] wrote:
>
> I have included the command in the spec file and it works too.
> I guess it would be a nice place to set it
Good idea.
JMarc, can you commit this?
---Kayvan
--
Kayvan A. Sylvan | Proud husband of | Father to my kids:
Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena
http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Index: development/lyx.spec.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/lyx.spec.in,v
retrieving revision 1.4
diff -u -r1.4 lyx.spec.in
--- development/lyx.spec.in 1999/11/08 13:47:48 1.4
+++ development/lyx.spec.in 2000/03/08 18:30:30
@@ -36,10 +36,12 @@
%setup
%build
+unset LINGUAS
CXXFLAGS="$RPM_OPT_FLAGS" CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=/usr
make
%install
+unset LINGUAS
rm -rf ${RPM_BUILD_ROOT}
install -d -m 755 ${RPM_BUILD_ROOT}
make prefix=${RPM_BUILD_ROOT}/usr install
Bug report ("buffer-new" crashes lyx and server)
I am using the binary versions of lyx (rpm). I found this bug in lyx-1.1.3 but the same bug persists even after I've upgraded to lyx 1.1.4fix1. I've turned on the server. The server pipes are the defaults ".lyxpipe.in" and ".lyxpipe.out". When I send the command "buffer-new:" by the following method: echo "LYXCMD:test:buffer-new:" > .lyxpipe.in Lyx crashes after the dialog window closes (either by pressing "cancel" or entering any file name and pressing "enter").
Re: new ostream code
Allan Rae <[EMAIL PROTECTED]> writes: | > Another prelease about a week later. | | Then again maybe I should hold off on merging gui-indep until after | 1.1.5? Yes, we should wait till after 1.1.5 before merging the rae branch. Lgb
Re: lyx-1.1.5cvs bug: All protected spaces export as ~
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> "Kayvan A. Sylvan" <[EMAIL PROTECTED]> writes: | > | > No it | Lars> doesen't but it absolutely should. The best (less maintence | > | Lars> problems) would be if this knwledge about the surounding | Lars> envronment | > could be done with arguments. | > | | Do you want | Lars> to make that change or should I? | | I can easily pass the | Lars> freespacing bool around when the inset->latex() functions | get | Lars> called. | | Lars> Is the freespacing bool enough? Ot should we rather pass a | Lars> pointer to the surrounding paragraph parameters? | | I am sure that in other cases other problems will occur... What would | be nice is to have a special output stream (the writer) which would | now among other things the current paragraph (this is needed anyway to | incorporate the texrow stuff in the writer). | | If we were to pass the freespacing bool, we might as well pass the | whole layout info. Will more thatn the buffer parameters be needed then? Lgb
Re: Question on LyXLex
Juergen Vigna <[EMAIL PROTECTED]> writes: | Fast Question: | | - Is it possible to push back a token read with lex.nextToken() so | that when calling another function it can do also lex.nextToken() | and get the same? So it is not possible to skip the nextToken just look at the token in both places with GetString? | (Hope I explained what I would like to have :) Kindo... but not why. We have several places that check for a token, do some thing based on that and then check the same token again to see if the correct thing is done. Lgb
Re: Why do mathed drawing functions take a byte*
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | I get the following errors with compaq cxx: | | cxx: Error: ../../../lyx-devel/src/mathed/math_macro.C, line 274: argument of | type "const char *" is incompatible with parameter of type | "unsigned char *" | drawStr(pain, LM_TC_TEX, size, x, baseline, ost.str().c_str(), 2); | ^ | cxx: Error: ../../../lyx-devel/src/mathed/math_macro.C, line 294: argument of | type "const char *" is incompatible with parameter of type | "const unsigned char *" | width = mathed_string_width(LM_TC_TEX, size, ost.str().c_str(), 2); | -^ | cxx: Error: ../../../lyx-devel/src/mathed/math_macro.C, line 296: argument of | type "const char *" is incompatible with parameter of type | "const unsigned char *" | ost.str().c_str(), 2, ascent, descent); | -^ | | It appears that MathedInset::drawStr and the string metrics functions | in formula.C use byte* as parameter for the string. Is there a reason | for that, or can I change them to char const *? All the math structure is stored in a byte array (unsigned char), so we are likely to need a lot of reinterpret_cast anyway. Lgb
Re: new lyx port does not link -- gettext (-lintl is missing)
Mikhail Teterin <[EMAIL PROTECTED]> writes: | Stop. | [...] | >How-To-Repeat: | | | >Fix: | A dirty fix is to add the -lintl to the lyx_LDADD line | in src/Makefile after configure. A clean fix is too | complicated I'm afraid of the configure.in/configure | mess. I think the correct fix it to check if -lintl is needed when linking. This is not always the case, i.e. linux glibc systems does not need it. This should be done in similar fashion to the one we use for checking if -lc and -lm are needed on the link line. Lgb
RE: platypus (fwd)
Hello Jonas, (and everybody else) On Wed, 8 Mar 2000, Dr. Ing. Dieter Jurzitza wrote: > On 08-Mar-00 [EMAIL PROTECTED] wrote: > > Would someone mind translating this for me? My high school German is > > getting awfully rusty ... > > > > -- Forwarded message -- > > From: Jonas Meurer <[EMAIL PROTECTED]> > > Wenn ich alles genauso mache, wie du es beschreibst, > > wird diese(s) Platypus auf der zweiten Seite > > ganz oben, das heisst vor > when following all your hints, this Platypus is being printed on the > top of the second page, i. e. right in front of ... rather than behind > it. This happens even though I inserted the picture underneath of this > paragraph. The "error" (quotation marks inserted by me) occurs only > when printing or when "View DVI" is selected. Is there an explanation > for this phenomenon? (of course!) How can I change this behaviour? My dirty tricks are coming back to haunt me. To achieve proper figure placement in the Graphical Tour, I added the Float Placement options "!ht" to the Document Layout menu. That is: 1) Select Layout->Document 2) Find the Float Placement box 3) Type "!ht" into the box "!ht" means "Put the figure right here, darn it! and if you really can't, then try the top of the next page. Note that this is a global setting for all figure floats. I took the philosophy of Donald Knuth - I used a subtle untruth to demonstrate my point, figuring that no one would ever actually try this. I guess Jonas proved that assumption false ... Mike [EMAIL PROTECTED]
Re: platypus (fwd)
<[EMAIL PROTECTED]> writes: | "!ht" means "Put the figure right here, darn it! and if you really can't, | then try the top of the next page. More like "I really, really want the figure right here". I you want "Put the figure here!" then you need the here.sty package. (and then use a "H" alone. Lgb
Re: Arabic patch
Dekel Tsur <[EMAIL PROTECTED]> writes: | --J2SCkAp4GZ/dPZZf | Content-Type: text/plain; charset=us-ascii | | The following patch adds better support for Arabic, and fix several other | things. | Also, it includes the end-of-proof patch (which haven't yet been | applied) I am sorry but a lot of the code that this patch touches has changed since you made the patch. I just now had the time to read through you patch now and it seems to move the whole rtl support in the right direction. Now if we could only enchance the language sturct to include information on what to do with rtl languages and other language quirks we could remove most of the special rtl support from lyxrc. I hope that you will we able to recreate the pach against current cvs. Lgb
Re: cvs install nit
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | I installed cvs 1.1.5cvs (this morning's) with --with-lyxname=lyxd | All of the share directories etc went well, but the bin went into | (overwrote) /usr/local/bin/lyx instead of lyxd. Do you have time to look at this Jean-Marc? Lgb
Re: Bugs
Dekel Tsur <[EMAIL PROTECTED]> writes: | 4. The following may be intentional changes: | - The colors for math-mode,latex-mode etc. are darker than before This one is intentional. | - In math mode, the empty delimiter (i.e. \left. or \right. ) is drawn as a |continuous line, instead of dotted line as before. This one is not. I'll fix that one. Lgb
Re: Problem with dead keys
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes:
| > "Jacques" == Jacques B Siboni <[EMAIL PROTECTED]> writes:
|
| Jacques> But presently the problem occurs with lyx editor: generation
| Jacques> of accented characters is ok 'e leads to é `e leads to è "e
| Jacques> leads to ë but generation of standard apostrophe, double
| Jacques> quote, caret (^), tilde and back quote are impossible. Lyx
| Jacques> refuses I get the accent that would be upon a character.
| Jacques> Generated LateX is \i \'{ } instead of '
|
| Hello,
|
| I can confirm this problem, which existed already in 1.0.3, as far as
| I can tell.
|
| Jacques> I believe it is a known problem.
|
| No, it was not. Thanks for reporting it. I have moved the discussion
| to lyx-devel so that a fix can be devised.
|
| Lars, I do not understand the use of the isDeadEvent() function in
| lyxlookup. I thought at the time that it was to avoid a clash with our
| own dead key handling. However, now that I think about it, LyX dead
| key handling is done mainly on plain characters. For example,
| \kmod ' acute aAcCeEiIjJlLnNoOsSuUzZ
| will act on a real ascii quote character, not on a ' dead key. So, why
| is it necessary to filter dead key events at all?
You, tell me. All this was added a lot later than my initial _X_
dead_key support.
Is this deadkey handling only wrong when a keymap is used? or always?
Lgb
Re: recreated close shop
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: | | >> I think that I found a way to recreate this bug (or maybe it a | >> different bug) Open the attached file, put the cursor before the | >> letter X, and then hold backspace, and LyX will crash (it doesn't | >> happens every time, but often enough) | | Kayvan> Yup. I managed to recreate this as well. | | Kayvan> Same basic backtrace: | | To add another bit of information, here is what purify says. It seems | that the problem is in the mechanism which deletes empty paragraph. | Lars, maybe this has to do with your double-space patch? By now you should have had time to read my comments in text.C. // This is the comments that some of the warnings below refers to. // There are some issues in this file and I don't think they are // really related to the FIX_DOUBLE_SPACE patch. I'd rather think that // this is a problem that has been here almost from day one and that a // larger userbase with differenct access patters triggers the bad // behaviour. (segfaults.) What I think happen is: In several places // we store the paragraph in the current cursor and then moves the // cursor. This movement of the cursor will delete paragraph at the // old position if it is now empty. This will make the temporary // pointer to the old cursor paragraph invalid and dangerous to use. // And is some cases this will trigger a segfault. I have marked some // of the cases where this happens with a warning, but I am sure there // are others in this file and in text2.C. There is also a note in // Delete() that you should read. In Delete I store the paragraph->id // instead of a pointer to the paragraph. I am pretty sure this faulty // use of temporary pointers to paragraphs that might have gotten // invalidated (through a cursor movement) before they are used, are // the cause of the strange crashes we get reported often. // // It is very tiresom to change this code, especially when it is as // hard to read as it is. Help to fix all the cases where this is done // would be greately appreciated. // // Lgb So now have a go at it. If you have other ideas on what could cause this crashing behaviour I'd like to hear that too. Lgb
Re: The code in layout.C
Dekel Tsur <[EMAIL PROTECTED]> writes:
| | void LyXTextClass::readOutputType(LyXLex & lexrc)
| | {
| | keyword_item outputTypeTags[] = {
| | { "docbook", DOCBOOK },
| | { "latex", LATEX },
| | { "linuxdoc", LINUXDOC },
| | { "literate", LITERATE }
| | };
|
| Why isn't outputTypeTags declared static?
I though a bit wrong about this and tought we could save some
runtime-footprint.
|
| | pushpophelper pph(lexrc, outputTypeTags, LITERATE);
|
| It is not a good idea to use the tag LITERATE because someone might change
| enum OutputType by adding a new tag after LITERATE, but he may forget to
| change the line above.
Agree.
| A better idea is to use sizeof(outputTypeTags)/sizeof(keyword_item),
| (another option is to add a line "OutputType_LAST = LITERATE" to
| enum OutputType, and then use OutputType_LAST instead of LITERATE)
I think I'd prefere the sizeof()/sizeof() method. That is the one we
use elsewhere.
| | int le = lexrc.lex();
| | switch(le) {
| | case LyXLex::LEX_UNDEF:
| | lexrc.printError("Unknown output type `$$Token'");
| | return;
| | case LATEX:
| | case LINUXDOC:
| | case DOCBOOK:
| | case LITERATE:
| | outputType_ = static_cast(le);
| | break;
| | default:
| | lyxerr << "Unhandled value " << le
| |<< " in LyXTextClass::readOutputType." << endl;
| |
| | break;
| | }
|
| The code here isn't very pretty.
| The value of 'le' can be either an error code from LyXLex::lex() namely
| either LyXLex::LEX_UNDEF, LEX_FEOF or LEX_DATA,
| and otherwise, it is either LATEX,LINUXDOC,DOCBOOK or LITERATE
| so the code can be as follows:
|
| switch(le) {
| case LyXLex::LEX_UNDEF:
| lexrc.printError("Unknown output type `$$Token'");
| return;
| case LyXLex::LEX_FEOF:
| case LyXLex::LEX_DATA:
| lyxerr << "Unhandled value " << le
| << " in LyXTextClass::readOutputType." << endl;
| default:
|outputType_ = static_cast(le);
| }
Hmm... yes in this case I think you are right. But if we also thing
about concistency between this and the other parsing funcitons your
way of doing it is not applicable to all of them.
Lgb
\show_banner
I am not sure if anyone noticed, but I added a lyxrc variable \show_banner that can be used to control whether to show the LyX startup banner or not. Lgb
Re: Porting pop-ups in the rae branch
Angus Leeming <[EMAIL PROTECTED]> writes: | --Boundary-=_qmZrHLajoetbkwlTZTViemHPfybp | Content-Type: text/plain | Content-Transfer-Encoding: 8bit | | i thought I'd follow in Allan Rae's footsteps and try and | port a pop-up to frontends. Allan, are you having a look at this? Lgb
unless
unless I see some objections I will begin to remove code that is dead because of USE_OSTREAM_ONLY today. Lgb
Latest CVS does not compile
Here's the error: g++ -DHAVE_CONFIG_H -I. -I. -I. -I../images -I/usr/X11R6/include -g -ansi -W -Wall -Wno-return-type -c lyxlex.C Wall -Wno-return-type -c lyxlex.C In file included from lyxlex.C:19: support/lyxalgo.h:8: `less' not declared ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Latest CVS does not compile
On Wed, Mar 08, 2000 at 09:27:59PM -0800, Kayvan A. Sylvan wrote: > Here's the error: > > g++ -DHAVE_CONFIG_H -I. -I. -I. -I../images -I/usr/X11R6/include -g -ansi -W -Wall >-Wno-return-type -c lyxlex.C > > Wall -Wno-return-type -c lyxlex.C > In file included from lyxlex.C:19: > support/lyxalgo.h:8: `less' not declared Commenting out "using std::less" in lyxalgo.h works for compiling. -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
Re: Porting pop-ups in the rae branch
I haven't time to look at this straight away. I'll look tonight and give you some feedback on the patches tomorrow. I have a few comments for you at the bottom of this email also. I'll make a few general comments at this point regarding rules for gui-indep of dialogs. These are not directed at you specifically, Angus, just laying some ground rules for anyone who's interested. 1. Anyone who wants to help is welcome too. 2. To avoid several people trying to port the same code ask me if anyone is working on that dialog or at least post to this list. I will add a table of dialogs with some comments to my web pages so it'll be easier to see who's working on what and how difficult a particular dialog is likely to be. 3. If anyone wants to dip their toe in the water I strongly recommend they get the lyx module from cvs and see what Jürgen and I did with dialogs there. There are a large number of dialogs already gui-indep there. The differences between that scheme and the current more refined one are quite small (apart from the swapping of Communicator for a LyXFunc entry and using xtl -- coming soon). 4. I have an almost complete script for converting all the work Jürgen and I did in the old lyx module to fit the new scheme. The only bits I still have to add are converting the Communicator calls into lyxfunc::dispatch() calls instead. These won't necessarily compile but they will be pretty close to complete. As such, I'd like to get this script finished and do one or two dialogs of different types by myself first. Most inset-related dialogs are very similar in the way they interact with their related inset for example. That way newbie developers can have something to work from and pass further comment on. Then either they do dialogs not already converted and I just run through the ones that've already been converted in the old module or vice versa. With this script most of the work will involve cutting out the code from the rest of the lyx codebase whilst checking that any bug-fixes or enhancements are incorporated into the old code. Most of this can be done via cut-and-paste. It should also mean we get a dialog done in 2 hours or so instead of every three days. 5. Make all patches against the rae branch. This should be obvious now but once gui-indep is merged into the main trunk I'll probably make a new branch called "dialogs" or something like that. That'll only be updated from the main trunk once a week/fortnight and will be used for testing/cleaning your submitted patch before it gets merged into the main trunk. This also means you have a fairly stable target to work against and if you time your submission right I'll do the merging instead of you. 6. All dialogs should have a corresponding .fd file in xforms/forms/. One dialog per file. Dialogs with multiple tabs also count as a single dialog. Then follow the instructions in the Makefile/README in the same directory to generate the corresponding Form::build(). Plug this into your new form class. This makes maintenance much easier. Also pay attention to the naming scheme for _all_ buttons and inputs and the naming of all callbacks. 7. Patches may be committed to the rae branch by any of the developers if they are bug fixes such as JMarcs configure fixes were. If you have to fix something in sigc++/ then check to make sure the bug wasn't a result of the development/tools/makeLyXsigc.sh script. If the bug really is a problem in libsigc++ send a patch to the libsigc++ mailing list: [EMAIL PROTECTED] That was longer than I expected... I better put a copy in xforms/forms/. On Wed, 8 Mar 2000, Angus Leeming wrote: > i thought I'd follow in Allan Rae's footsteps and try and port a > pop-up to frontends. Thinking, "let's keep this simple", I chose the > Help->Credits pop-up. I now have a FormCredits.[Ch] in the > src/frontends/xforms/ directory and... it all works! Credits was indeed the second dialog that I converted in the lyx module so you certainly are following closely. [description of modifications req'd] Sounds good so far. Although as I implied above I'd rather not lose all the previous work. Credits, however, is one dialog I was going to implement differently this time around. See below. > The close similarity between FormCredits.[Ch] and FormCopyright.[Ch] > (see attachments), suggests that I should proceed by creating a base > class with virtual build() and two derived classes FormCredits, and > FormCopyright implementing the build() function. Is this a Good Idea? > (I ask because C++ is new to me and I'm learing as I go ;-).) If you look at the lyx module in cvs you'll see a browserbase class and then notice that the filebrowser for latex errors and one other (can't remember the class) are derived from it. Credits i
Re: Formatting source code
On Thu, Mar 09, 2000 at 05:31:14AM +0100, Lars Gullik Bjønnes wrote: > > This is really a great package. > I just tested with buffer.C in the LyX distribution and it worked > flawlessly. > > I think we should somehow create support for this in LyX. > The listings package seems to be actively maintained too. I've just added the listings package to my tetex-extras RPM. The latest version is available in ftp://ftp.sylvan.com/pub/lyx/extras If you run Redhat and have tetex installed, you can just plop this RPM down and it will just work. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory
4 1/2 ways to implement XTL-based get/set and constructor
/* Test code for demonstrating 4 1/2 possible ways of using XTL to get/set
* the contents of a parameter class. In this case, PrinterParams -- not
* the real one but a simulated one.
*
* Compile with:
*-DMACROS -- use macros to setup member functions
*-DMIXIN -- use a mixin class
*-DTEMPFUNC-- use template functions
*(no extra defines)-- use hand-written member functions
*
* Author: Allan Rae <[EMAIL PROTECTED]>
*/
#include
/*===
* From here to the next divider is what would be in LXTL.h
*===
*/
#include
//
// can't use a typedef here
#define gui_format raw_format
#if defined(MACROS)
// macros place the lowest demands on the compiler (wrt. templates)
//
#define LXTL_GET(Format)\
void get(int size, char * buf) \
{ \
mem_buffer mb1(buf, size); \
Format fo(mb1);\
obj_output > output(fo);\
output.simple(*this); \
}
#define LXTL_SET(Format)\
void set(int size, char * buf) \
{ \
mem_buffer mb1(buf, size); \
Format fi(mb1); \
obj_input > input(fi); \
input.simple(*this);\
}
// for extra convenience
#define LXTL_GUI_GET LXTL_GET(gui_format)
#define LXTL_GUI_SET LXTL_SET(gui_format)
#elif defined(MIXIN)
// I thought a mixin class might be a little prettier than macros however
// it looks considerably worse.
// I can't use the same definitions as the macros above because I can't use
// *this to build the output. If I try, then I only get Mixin_XTL<>::composite()
// called.
// I now get the class I'm mixed in with to pass the *this, but of
// course this just gets uglier and uglier by the minute. Uglier because I
// now can't call the mixin class directly without it looking silly:
//mt.get(size, buf, &mt)
// so I need a get(int, char *) in the derived class to call the get(...)
// in this mixin class. This works but is unnecessarily complicated.
// It could look a little cleaner if fewer template arguements were used.
//
template class Format>
class Mixin_XTL
{
public:
void get(int size, char * buf, Derived * self)
{
mem_buffer mb1(buf, size);
Format fo(mb1);
obj_output > output(fo);
output.simple(*self);
}
void set(int size, char * buf, Derived * self)
{
mem_buffer mb1(buf, size);
Format fi(mb1);
obj_input > input(fi);
input.simple(*self);
}
#if 0
// Here we'd probably want to use a different format to what we use for
// the gui interaction necessitating either a different mixin class or
// another template arguement.
//
void write(int size, char * buf, Derived * self)
{
mem_buffer mb1(buf, size);
Format fo(mb1);
obj_output > output(fo);
output.simple(*self);
}
void read(int size, char * buf, Derived * self)
{
mem_buffer mb1(buf, size);
Format fi(mb1);
obj_input > input(fi);
input.simple(*self);
}
#endif
};
#elif defined(TEMPFUNC)
// try template functions instead
//
// Maybe better function names would help. There's not much point in
// dropping the Format template arguement.
//
template class Format>
void get(ClassToGet * target, int size, char * buf)
{
mem_buffer mb1(buf, size);
Format fo(mb1);
obj_output > output(fo);
output.simple(*target);
}
template class Format>
void set(ClassToSet * target, int size, char * buf)
{
mem_buffer mb1(buf, size);
Format fi(mb1);
obj_input > input(fi);
input.simple(*target);
}
#endif
/*
* End of LXTL.h
*
* From here to the next divider is what could be in PrinterParams.h
*
Re: LDN
On Tue, 7 Mar 2000, Allan Rae wrote: > > A "LyX tip of the (Bi)Week" might not be a bad idea, though. Of course, if > > we had FAQ it might not be necessary. > > What's with this bi-weekly rubbish? Hasn't the US heard of fortnights? [ I then went on and ranted about people with tiny minds ] None of those people use LyX or are on the mailing list or even ever likely to be. So don't worry I wasn't meaning any of you or any of our users or future users. Tuesday I had the "anti-Midas touch" where everything I touched turned to sh!t. I even forgot the smiley from the above paragraphs of rant. Allan. (ARRae)
