Re: MVC comments
On 05-Apr-2001 Angus Leeming wrote: > You could emit a signal whenever the user clicks in a new paragraph. That way > we wouldn;t need an update button at all. > > Or is this too easy? Well we don't want to update the paragraph-layout when we change paragraph otherwise we are not able to apply the same changes to different paragraphs, isn't it? So the update in the paragraph-layout should not be automatically only the activation of the OK/Apply buttons should automatized (if the params inside the dialog != of the params of the stuff the dialog should change) So we need some way to "force" the update of the dialog. Got me ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ It was all so different before everything changed.
Re: Still problems with tables
> btw. what do people say... can I begin the ripping? Uh... I would not mind if mathed was not the only semi-functional area ;-) It's always nice to have company. Andre' -- André Pönitz . [EMAIL PROTECTED] C++-Programmierer gesucht ... Naeheres unter http://mathematik.htwm.de/job
Re: another makecvs.log
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | Lars Gullik Bjønnes wrote: | > | > "Garst R. Reese" <[EMAIL PROTECTED]> writes: | > | > | still gcc-3.0 | > | Garstmake[3]: Entering directory `/usr/local/garst/lyx-devel/src' | > | g++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../boost-isystem |/usr/X11R6/include -O -W -Wall -DLYX_DIR=\"/usr/local/share/lyx\" \ | > | -DTOP_SRCDIR=\"..\" -c ../src/lyx_main.C | > | ../src/lyx_main.C: In member function `void LyX::ReadLangugesFile(const | > |string&)': | > | ../src/lyx_main.C:672: `languages' undeclared (first use this function) | > | ../src/lyx_main.C:672: (Each undeclared identifier is reported only once for | > |each function it appears in.) | > | make[3]: *** [lyx_main.o] Error 1 | > | > inlucde language.h in lyx_main.C | > | > -- | > Lgb | Oops, that, or something else, gave many "mulitiple definition of | std::string::blah blah hmm... so you suddenly see what I saw earlier. I really cannot see the cause for this. Do we have an include guard wrong? Is the stdc++-v3 lib having an include guard wrong? gcc 2.96 still works flawlessly. -- Lgb
Re: Small request
On Thu, 5 Apr 2001, Juergen Vigna wrote:
> for() {
> for() {
> if (a very long parameterlist
&& function(with more than one,
parameter)) {
> ^from here we need spaces
> }
> }
> }
is much easier to read and doesn't give a syntax error for missing a ')'.
Allan. (ARRae)
Re: MVC comments
On Thu, 5 Apr 2001, John Levon wrote: > On Thu, 5 Apr 2001, Allan Rae wrote: > > > That's what the input checking routine is for. > > > > The fact that an input has changed isn't significant. The problem is > > whether or not that change has resulted in a valid contents of the dialog > > or not. If the contents are valid then Okay and Apply should be > > enable-able (if the state machine is in an appropriate state). > > The problem for me is that this also enables anything you added with > addReadOnly, if the dialog is read-write. Ideally these two things > should be split somehow, I'm sure you two controller bods can come up > with something clever that works ;) I don't understand why this is a problem. If we have a read-write document then all the read-only list widgets should be enabled. What operation are you expecting? Do you want some widgets that are only enabled when we have a read-only document? Hmmm... okay maybe this is the shared management problem again. If I can get this RBG [RadioButtonGroup] patch working we should be able to define a RBG then toggle different radio buttons to get different sets of widgets activated/deactivated. Then I can generalize the patch to only use a set of ints rather than a whole RBG (hh maybe I should do this now it might make it easier to get working). That'd allow you to define within your dialog an enum to define the sets of widgets that can be activated together and inform the BC when the enum state changes. bc().refresh() then activates the appropriate widgets -- the dialog just has to track which set should be active. Hmmm yeah I think that'd probably be easier to implement than the RBG specific thing I put on ice months ago. Allan. (ARRae)
Re: MVC comments
On Thu, 5 Apr 2001, Angus Leeming wrote: > On Thursday 05 April 2001 07:31, Allan Rae wrote: > > BTW, what happens if after the user presses a key they then try to press > > Okay? If the last key press in the edit box gave an invalid entry then > > they shouldn't have an Okay button available. > > I've been thinking about (note no intention of implementing!) invalid input. > > When data is input to the button controller as invalid, why not then store a > pointer to that widget in a vector of invalid data. Future input is checked > against this vector and any (was invalid, now valid) data is removed from it. > The dialog can then only be activated when all input is valid. Then what do you do if it's the relationship between two inputs that is wrong. Like the font size settings in Preferences. These are currently restricted to being monotonic increasing (although consecutive sizes can be the same size). The way I had originally written the input() handling routine in the dialogs I ported was that it checks _all_ these relationships _everytime_ it's called. Now there seem to be a few dialogs that only do checks for individual widgets or at least for individual tabs of a tabbed dialog. Where possible I think we should use a specific input filter on an input/edit box to control what characters can be entered etc. Several of these already exist for xforms and much of their implementation could be shared with other toolkits. The overhead of input() operating the way I described is negligable because this is triggered by a user typing or clicking. So maybe I should more clearly define what I expected in my design of BC. The output of the dialog.input() processing callback defines whether the dialog is in a valid state or not. Angus has extended this to allow it say no change in previous state -- this was for handling cases where a user clicked on a widget that had no effect upon the dialog state. This should only be needed when input checking is shortcutted or at least "optimized" but even then you still run into problems of tracking. My original plan called for input() to check everything that could make a dialog invalid. This was to work in conjunction with input-filtering where possible. Under XForms all you can effectively do with an input-filter is return a bool flag of whether that input/keypress is valid or not. You can't do anything particularly tricky with it. So input() checks relationships between inputs and checks other requirements that you can't do in an input-filter. For example, typing in a writable directory name: input-filtering lets you check for valid filename characters but you can't do a check of whether or not the directory exists in the input-filter because if you return FL_INVALID the character isn't even entered in the input box making it impossible to enter anything in the box! If you want to get fancy and limit input checking to particular tabs of a tabbed dialog or individual widgets (the one the user just typed in for instance) then you need to do some invalid tracking. I have been considering inverting the input box colours or just changing it's background to red to make it more obvious to users which ones we think they've gotten wrong. This also needs some sort of tracking or at least reset to normal every time through when they are valid. Personally, I'd rather process everything, everytime, until such time as we start seeing interactive response problems. [at this point I decided to take a look at FormPreferences.C instead of just seeing how BC and co. where implemented] Looking through FormPreferences.C I now see that the input() callback is now being used as a general purpose callback and the object that triggered the callback is being used to do all sorts of things from input checking to running commands. I have this to say about that: NNN NNIII NN OO OO III NN OOOO III NN NNN OO OO NN NNOOO Clearly, there's been a misunderstanding of how I'd intended this to work and I hadn't noticed how this was being altered in my absence. Personally, I'd rather things like FormPreferences::Converters::Add() got their own callback. Direct to the function associated with the button -- which was why I'd written those callback macros in the first place. The button doesn't need any input checking because it isn't an input. Only inputs (like input boxes, sliders/counters and edit boxes) need to be calling input(). Sigh, sigh again. [Obsenity deleted]. I really don't like the idea of centralizing the callbacks and then trying to figure out who does what as a result. There's a mixture of control and input processing being done now in what was intended to be an input-only processing step. As a result you can't give BC a proper response and people are getting frustrated. If you really, really like the idea of a centralized _control_ callback then I would suggest that you cre
Re: another makecvs.log
Lars Gullik Bjønnes wrote: > > "Garst R. Reese" <[EMAIL PROTECTED]> writes: > > | still gcc-3.0 > | Garstmake[3]: Entering directory `/usr/local/garst/lyx-devel/src' > | g++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../boost-isystem >/usr/X11R6/include -O -W -Wall -DLYX_DIR=\"/usr/local/share/lyx\" \ > | -DTOP_SRCDIR=\"..\" -c ../src/lyx_main.C > | ../src/lyx_main.C: In member function `void LyX::ReadLangugesFile(const > |string&)': > | ../src/lyx_main.C:672: `languages' undeclared (first use this function) > | ../src/lyx_main.C:672: (Each undeclared identifier is reported only once for > |each function it appears in.) > | make[3]: *** [lyx_main.o] Error 1 > > inlucde language.h in lyx_main.C > > -- > Lgb Oops, that, or something else, gave many "mulitiple definition of std::string::blah blah
Re: another makecvs.log
Lars Gullik Bjønnes wrote: > inlucde language.h in lyx_main.C > > -- > Lgb Thanks
Re: another makecvs.log
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | still gcc-3.0 | Garstmake[3]: Entering directory `/usr/local/garst/lyx-devel/src' | g++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../boost-isystem /usr/X11R6/include |-O -W -Wall -DLYX_DIR=\"/usr/local/share/lyx\" \ | -DTOP_SRCDIR=\"..\" -c ../src/lyx_main.C | ../src/lyx_main.C: In member function `void LyX::ReadLangugesFile(const |string&)': | ../src/lyx_main.C:672: `languages' undeclared (first use this function) | ../src/lyx_main.C:672: (Each undeclared identifier is reported only once for |each function it appears in.) | make[3]: *** [lyx_main.o] Error 1 inlucde language.h in lyx_main.C -- Lgb
another makecvs.log
still gcc-3.0 Garst make[3]: Entering directory `/usr/local/garst/lyx-devel/src' g++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../boost-isystem /usr/X11R6/include -O -W -Wall -DLYX_DIR=\"/usr/local/share/lyx\" \ -DTOP_SRCDIR=\"..\" -c ../src/lyx_main.C ../src/lyx_main.C: In member function `void LyX::ReadLangugesFile(const string&)': ../src/lyx_main.C:672: `languages' undeclared (first use this function) ../src/lyx_main.C:672: (Each undeclared identifier is reported only once for each function it appears in.) make[3]: *** [lyx_main.o] Error 1
Re: MVC comments
On Thursday 05 April 2001 08:41, Juergen Vigna wrote: > On 05-Apr-2001 Allan Rae wrote: > > > - outputs_[INITIAL] = CLOSE; > > + outputs_[INITIAL] = OKAY | APPLY | CLOSE; > > > > This should be a safe change for both these policies. It'd also mean that > > after a Restore you can still press Okay or Apply without changing > > something in the dialog. > > > > Provided we do an input check on the contents of the dialog just as it is > > being shown then we can move to the appropriate state (INVALID or > > RO_INVALID) if the contents aren't initially valid. I suspect we assume > > that the contents are always valid on initial showing. > > > > Well we would need OKAY | APPLY only if the cursor moves to some other > paragraph isn't it or in general if the cursor moves. We should send a > update signal to buffer dependent dialogs but for this type of dialog we > would need one more signal and that is a signal which activates that buttons > if one of the parameters of the actual paragraph differs with the content > of the actual cursor position (or in the case of the ParagraphLayout the > paragraph we are actually in). Also it would be great to have: > > 1. A button in the Dialog to update the contents with the actual paragraph >(or whatever) settings. > > 2. An other way to realize this. Mayby just reopening the dialog (also >without closing it first) should do this. Otherwise if I want to change >only one thing in a paragraph I have to close the Dialog and reopen it >when the cursor is inside the paragraph to have the Dialog with the >right values. > > Comments?! Well, the inset dialogs automatically update when you click on a new inset because the inset emits a signal in InsetXXX:Edit() that's picked up by the dialog. You could emit a signal whenever the user clicks in a new paragraph. That way we wouldn;t need an update button at all. Or is this too easy? Angus
testing out the graphics inset
Baruch,
I need to make the following ChangeExtension() change to your code to find
the .xpm file in the tmp directory. Otherwise I get:
Converting from png to xpm
Calling convert 'tjunc-expr-4.png' XPM:'tjunc-expr-4.xpm'
moving /usr/users/aleem/err/tjunc-expr-4.xpm to
/tmp/lyx_tmpdir425aaanja/tjunc-expr-4425aaanja.xpm
imageConverted, retval=0
Loading XPM Image... No XPM file found.
Loading /tmp/lyx_tmpdir425aaanja/tjunc-expr-4425aaanja Failed
Now I get as far as ImageLoaderXPM::runImageLoader() where the call
XpmReadFileToPixmap fails with
Error reading XPM file 'XpmColorFailed'
The good news is xv can load and display the file, so there's hope!
Is this info any help?
How far do others get?
Angus
Index: graphics/GraphicsCacheItem.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/GraphicsCacheItem.C,v
retrieving revision 1.12
diff -u -p -r1.12 GraphicsCacheItem.C
--- graphics/GraphicsCacheItem.C2001/04/02 19:56:48 1.12
+++ graphics/GraphicsCacheItem.C2001/04/05 15:41:52
@@ -120,7 +120,7 @@ GraphicsCacheItem::convertImage(string c
// Add some stuff to have it a unique temp file.
// This tempfile is deleted in loadImage after it is loaded to memory.
- tempfile = lyx::tempName(string(), temp);
+ tempfile = ChangeExtension(lyx::tempName(string(), temp), to);
// Remove the temp file, we only want the name...
lyx::unlink(tempfile);
@@ -143,12 +143,12 @@ GraphicsCacheItem::loadImage()
image_.reset(imageLoader.getImage());
imageStatus_ = GraphicsCacheItem::Loaded;
} else {
- lyxerr << "Loading " << tempfile << "Failed" << endl;
+ lyxerr << "Loading " << tempfile << " Failed" << endl;
imageStatus_ = GraphicsCacheItem::ErrorReading;
}
// remove the xpm file now.
lyx::unlink(tempfile);
// and remove the reference to the filename.
- tempfile = string();
+ tempfile.erase();
}
Index: graphics/ImageLoaderXPM.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/ImageLoaderXPM.C,v
retrieving revision 1.1
diff -u -p -r1.1 ImageLoaderXPM.C
--- graphics/ImageLoaderXPM.C 2001/02/08 13:20:24 1.1
+++ graphics/ImageLoaderXPM.C 2001/04/05 15:41:52
@@ -78,8 +78,8 @@ ImageLoaderXPM::runImageLoader(string co
if (status != XpmSuccess) {
lyxerr << "Error reading XPM file '"
- << XpmGetErrorString(status)
- << endl;
+ << XpmGetErrorString(status)
+ << "'" << endl;
return ErrorWhileLoading;
}
Re: profiling and optimization
On 5 Apr 2001, Jean-Marc Lasgouttes wrote: > I'd say we should indeed have --enable-warnings, but maybe keep > --with-frontend (it's a kind of external package, no?). If I use > --enable-frontend, I'd always wonder what --disable-frontend does... > > As a reference point, emacs 20.4 has > --with-x-toolkit=KITuse an X toolkit (KIT = yes/lucid/athena/motif/no) Yes, you're right, I was wrong ;) thanks john -- "Be conservative in what you do, be liberal in what you accept from others." - Jon Postel
Re: profiling and optimization
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> It's an unrelated bit of pedantry, but --with-warnings along John> with --with-frontend should really by --enable. --with is for John> specifying external packages. I'd say we should indeed have --enable-warnings, but maybe keep --with-frontend (it's a kind of external package, no?). If I use --enable-frontend, I'd always wonder what --disable-frontend does... As a reference point, emacs 20.4 has --with-x-toolkit=KITuse an X toolkit (KIT = yes/lucid/athena/motif/no) JMarc
Re: profiling and optimization
On 5 Apr 2001, Lars Gullik [iso-8859-1] Bjønnes wrote: > As you can see from the latest commit, I gave in on the "move some > small methods inline" controversy. I wouldn't quite call it controversy ;) > should _always_ compile with "high" optimization turned on (in gcc > -O2) _and_ make sure that you compile LyX with assertions turned off. good point, although it wouldn't have made much a difference in this particular case. There's not much point *me* going after stuff since I'm a kernel lamer as you know. > (--disable-assertions) (hmm I thought we had a --without-warnings > option as well?) It's an unrelated bit of pedantry, but --with-warnings along with --with-frontend should really by --enable. --with is for specifying external packages. john -- "Be conservative in what you do, be liberal in what you accept from others." - Jon Postel
Re: makecvs.log again
Lars Gullik Bjønnes wrote: > > "Garst R. Reese" <[EMAIL PROTECTED]> writes: > > | here it is. g++-3.0 gcc-3.0 20010402 > > Hmm... I just tried to compile with 3.0 (before latest commit and > changes), and got a _lot_ of linker errors. From what date is your > 3.0? Sorry, I should have made it clear what that date went with. --enable-shared --enable-version-specific-runtime-libs --enable-cpp --disable-multilib Garst
Re: MVC comments
On Thu, 5 Apr 2001, Allan Rae wrote: > That's what the input checking routine is for. > > The fact that an input has changed isn't significant. The problem is > whether or not that change has resulted in a valid contents of the dialog > or not. If the contents are valid then Okay and Apply should be > enable-able (if the state machine is in an appropriate state). The problem for me is that this also enables anything you added with addReadOnly, if the dialog is read-write. Ideally these two things should be split somehow, I'm sure you two controller bods can come up with something clever that works ;) thanks john -- "Be conservative in what you do, be liberal in what you accept from others." - Jon Postel
Re: Renaming in lyxfont.h
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> Hello, In lyxfont.h there is an include for gettext.h for some Baruch> obscure reason of using enums ON and OFF that might get Baruch> redefined in locale.h OK, I commited a cleanup patch from Baruch's work and mine. Note that this will probably break for frontends that do not include gettext.h or language.h explicitely. JMarc
Re: Repeat: lyx.spec.in patch
On Thu, Apr 05, 2001 at 11:26:50AM +0200, Jean-Marc Lasgouttes wrote: > > "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: > > Kayvan> --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii > > Kayvan> Hi! > > Kayvan> Is anyone going to apply this patch for me? > > I'll do it. Should it go to 1.1.6 too? > > JMarc Yes. ---Kayvan
Re: MVC comments
On Thursday 05 April 2001 05:47, Allan Rae wrote:
> > Yes, this is a fudge to a lacking ButtonPolicy. Consider inputting a
> > citation-inset from the minibuffer. The params are perfectly valid, the
> > dialog pops up. Do you want to "Apply" them? Yes I do!
>
> Doesn't the citation inset already exist at that stage with those values?
> You're more familiar with this process than I am since you reworked a lot
> of it.
Here's the rule:
http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg21186.html
(points 2 and 4) Currently, none of the insets conform to it exactly, but
many (most) do so almost. Eventually, they all will.
But basically, no, the inset does not exist when the dialog is launched from
the minibuffer.
> I think this is the problem we've discussed before about the
> OkApplyCancel[ReadOnly]Policy. I think it would probably make sense to:
>
> - outputs_[INITIAL] = CLOSE;
> + outputs_[INITIAL] = OKAY | APPLY | CLOSE;
>
> This should be a safe change for both these policies. It'd also mean that
> after a Restore you can still press Okay or Apply without changing
> something in the dialog.
>
> Provided we do an input check on the contents of the dialog just as it is
> being shown then we can move to the appropriate state (INVALID or
> RO_INVALID) if the contents aren't initially valid. I suspect we assume
> that the contents are always valid on initial showing.
Hmmm. So we should have
void ControlSomeDialog::show()
{
bc.valid(isValid(params()));
view().show();
}
void ControlSomeDialog::update()
{
bc.valid(isValid(params()));
view().update();
}
So, another reqirement of the Params struct: it should have an isValid()
memeber function too.
> I'd enjoy being back. I'll have to get familiar with the code again
> though. So much has changed. You blokes, and you in particular Angus,
> have been doing a terrific job.
Most of the change is superficial; moving stuff out of one class and into
two. It's worth while trying to understand the control flow, but all Views
see exactly the same flow, even though there are two generic controllers,
ControlInset and ControlDialog. If you can think of a better name for
ControlDialog, then shout it out!
A
Re: Renaming in lyxfont.h
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> Ok, I'm basically half through, the problem now is not the Baruch> LyXFont, but adding gettext.h to the files that need it and Baruch> received it implicitly by including buffer.h I only had this problem with controllers/character.C. I guess the other ones are in frontends. Baruch> I'm halfway through (or so I believe), I will not submit it Baruch> today since I need to go now. If you want I can send you the Baruch> patch I have so far. Send me what you have. JMarc
Re: Repeat: lyx.spec.in patch
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan> --sm4nu43k4a2Rpi4c Content-Type: text/plain; charset=us-ascii Kayvan> Hi! Kayvan> Is anyone going to apply this patch for me? I'll do it. Should it go to 1.1.6 too? JMarc
Re: MVC comments
On Thursday 05 April 2001 07:31, Allan Rae wrote: > On Tue, 3 Apr 2001, Allan Rae wrote: > > > On Mon, 2 Apr 2001, Angus Leeming wrote: > > > > 7) I find it a bit weird that I call a method "valid(bool)" whenever > > > > e.g. a user types another character in a line edit widget. Can we > > > > add another method mutated(bool) or changed(bool) possibly ? > > > > This would make at least the KDE frontend code a lot clearer IMHO > > > > There's more than simply "changed/unchanged". valid() should only be > > called when a change has happened. So it represents "valid > > changed/invalid changed". You are also free to call bc.input(SMInput) > > directly. > > BTW, what happens if after the user presses a key they then try to press > Okay? If the last key press in the edit box gave an invalid entry then > they shouldn't have an Okay button available. I've been thinking about (note no intention of implementing!) invalid input. When data is input to the button controller as invalid, why not then store a pointer to that widget in a vector of invalid data. Future input is checked against this vector and any (was invalid, now valid) data is removed from it. The dialog can then only be activated when all input is valid. Just a thought. Angus
Re: Renaming in lyxfont.h
* Jean-Marc Lasgouttes <[EMAIL PROTECTED]> [010405 11:09]: > > "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: > > Baruch> This causes that almost any file includes gettext.h > Baruch> implicitly, it wouldn't be that bad, but in my case it forces > Baruch> reordering of header file includes. What I want is permission > Baruch> to rename the ON and OFF to FONT_ON and FONT_OFF, and do this > Baruch> rename wherever needed. > > I'll handle it. Ok, I'm basically half through, the problem now is not the LyXFont, but adding gettext.h to the files that need it and received it implicitly by including buffer.h I'm halfway through (or so I believe), I will not submit it today since I need to go now. If you want I can send you the patch I have so far. -- Baruch Even http://baruch.ev-en.org/
Re: Small request
On 05-Apr-2001 Lars Gullik Bjønnes wrote:
> I can live with that. (barely)
#:O)
> Using tab-with == 4, and at the same time indenting with 8 spaces is
> bad.
I don't indent with 8 spaces! I indent with tab's now! There's just the
problem with parameters which break to a new line (when indenting with
tabulators), this obviously not only in the function header but also
in the code, say after the normal indent level f.ex.
for() {
for() {
if (a very long parameterlist && function(with more then one,
parameter)
^from here we need spaces
{
}
}
}
I know this is annoying, but IMO this is the cleanest solution and we then
can view and print sourcecode with whatever tab-width we give. I understand
we cannot do this now for all files, but we could keep it as a general rule
(a pitty emacs indent-mode cannot handle stuff like this automatically)
Jürgen
--
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED]
Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253
I-39100 Bozen Web: http://www.sad.it/~jug
-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
But I was there and I saw what you did,
I saw it with my own two eyes.
So you can wipe off that grin;
I know where you've been--
It's all been a pack of lies!
Repeat: lyx.spec.in patch
Hi!
Is anyone going to apply this patch for me?
Thanks.
---Kayvan
Index: development/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/ChangeLog,v
retrieving revision 1.3
diff -u -u -r1.3 ChangeLog
--- development/ChangeLog 2001/04/02 12:43:30 1.3
+++ development/ChangeLog 2001/04/05 09:04:07
@@ -7,3 +7,7 @@
* Code_rules/Recommendations:
* Code_rules/Rules: update, add some comments,
spelling and grammar
+
+2001-04-03 Kayvan Sylvan <[EMAIL PROTECTED]>
+
+ * Fix lyx.spec.in handling on reLyX with RPM relocation.
Index: development/lyx.spec.in
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/lyx.spec.in,v
retrieving revision 1.8
diff -u -u -r1.8 lyx.spec.in
--- development/lyx.spec.in 2000/07/27 08:55:56 1.8
+++ development/lyx.spec.in 2001/04/05 09:04:07
@@ -87,6 +87,13 @@
cd $RPM_INSTALL_PREFIX/share/lyx
./configure --srcdir
+# Fix reLyX perl program if the prefix is non-standard
+if [ "$RPM_INSTALL_PREFIX" != "/usr" ]
+then
+perl -pi -e "s!/usr/share/lyx!$RPM_INSTALL_PREFIX/share/lyx!" \
+${RPM_INSTALL_PREFIX}/bin/reLyX
+fi
+
%post -n tetex-lyx
# Fix the TeX file hash
#
Re: Small request
Juergen Vigna <[EMAIL PROTECTED]> writes: | On 05-Apr-2001 Lars Gullik Bjønnes wrote: | | > So you still want "your" files to be special? | > _all_ other files use tabs. | | Well no this could be a general rule. So files can be viewed with whatever | tab-with you give! I can live with that. (barely) | > a tab with is 8 chars regardless of if a a tab or 8 spaces is used. | > so if you use tab eqiv. 4 spaces and indent with 8 spaces... then you | > are doomed. | | I don't understand. Maybe it's to early in the morning for difficult sentences | in a foreign language :) Using tab-with == 4, and at the same time indenting with 8 spaces is bad. -- Lgb
Re: Small request
On 05-Apr-2001 Lars Gullik Bjønnes wrote: > So you still want "your" files to be special? > _all_ other files use tabs. Well no this could be a general rule. So files can be viewed with whatever tab-with you give! > a tab with is 8 chars regardless of if a a tab or 8 spaces is used. > so if you use tab eqiv. 4 spaces and indent with 8 spaces... then you > are doomed. I don't understand. Maybe it's to early in the morning for difficult sentences in a foreign language :) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ A waist is a terrible thing to mind. -- Ziggy
Re: Small request
Juergen Vigna <[EMAIL PROTECTED]> writes: | > | >* tabular.C: small reformat | > You automatic reformatter did too many things wrong. | Lars I would apreciate if you would (re)indent this type of stuff with | spaces and not with tabs as then we have both the same view of the | file! So you still want "your" files to be special? _all_ other files use tabs. | (well I added the comment at the end of the file propsed yesterday by | H.Z so we should have the same view from now on ;) | | I understand that this type of indent is annoying with tabs depending | on how wide your tab-width is! But please be tolerant with me I already | gave in, didn't I? a tab with is 8 chars regardless of if a a tab or 8 spaces is used. so if you use tab eqiv. 4 spaces and indent with 8 spaces... then you are doomed. -- Lgb
profiling and optimization
As you can see from the latest commit, I gave in on the "move some small methods inline" controversy. One thing I'd like to point out though: When trying to optimize you should _always_ compile with "high" optimization turned on (in gcc -O2) _and_ make sure that you compile LyX with assertions turned off. (--disable-assertions) (hmm I thought we had a --without-warnings option as well?) Without this the profiling will not tell the true story. -- Lgb
Re: Renaming in lyxfont.h
> "Baruch" == Baruch Even <[EMAIL PROTECTED]> writes: Baruch> Hello, In lyxfont.h there is an include for gettext.h for some Baruch> obscure reason of using enums ON and OFF that might get Baruch> redefined in locale.h Ha! I tried to remove it when I rewrote gettext.[Ch], but could not remember where the code was %-| This is old code which fixed problems with SunOS 4.1.3. Since I guess nobody compiles on SunOS anymore, and gettext.h does not include locale.h anymore, this is not needed. Baruch> This causes that almost any file includes gettext.h Baruch> implicitly, it wouldn't be that bad, but in my case it forces Baruch> reordering of header file includes. What I want is permission Baruch> to rename the ON and OFF to FONT_ON and FONT_OFF, and do this Baruch> rename wherever needed. I'll handle it. JMarc
Small request
> >* tabular.C: small reformat > Lars I would apreciate if you would (re)indent this type of stuff with spaces and not with tabs as then we have both the same view of the file! (well I added the comment at the end of the file propsed yesterday by H.Z so we should have the same view from now on ;) I understand that this type of indent is annoying with tabs depending on how wide your tab-width is! But please be tolerant with me I already gave in, didn't I? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Hors d'oeuvres -- a ham sandwich cut into forty pieces. -- Jack Benny
Re: LyX crash when mathmod cdots is used
> "Juergen" == Juergen Vigna <[EMAIL PROTECTED]> writes: Juergen> On 04-Apr-2001 Dekel Tsur wrote: >> On Wed, Apr 04, 2001 at 10:23:05AM -0700, Michael K Cheng wrote: >>> I'm not sure what that os pointer is, but I've compiled LyX on >>> redhat 7.0 yesterday. I can crash it by opening a new document and >>> inserting a equation [M-m d] and type "s=0,\cdots,d-1" (for >>> s=0,...,d-1), then save or dvi will cause it to crash. Try opening >>> and dvi(ing) or saving the attached document. >>> >>> g++ version: Reading specs from >>> /usr/lib/gcc-lib/i386-redhat-linux/2.96/specs gcc version 2.96 >>> 2731 (Red Hat Linux 7.0) Juergen> This seems so much the same problem I have with that Juergen> compiler! Compile LyX without optimization (CXXFLAGS=-g) this Juergen> should fix it. If I compile with optimization activated I get Juergen> the same problems as you (spurius crashes when working with a Juergen> lot of paragraphs at the same time like you do if you have a Juergen> tabular!) And check that you have the latest revision of the gcc rpms (at least -69, from what I understand). JMarc
Re: makecvs.log again
"Garst R. Reese" <[EMAIL PROTECTED]> writes: | here it is. g++-3.0 gcc-3.0 20010402 Hmm... I just tried to compile with 3.0 (before latest commit and changes), and got a _lot_ of linker errors. From what date is your 3.0? | GarstMaking all in insets | make[3]: Entering directory `/usr/local/garst/lyx-devel/src/insets' | /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ |-I../.. -I../.. -I../../boost -isystem /usr/X11R6/include -O -W -Wall -c |insetcaption.C | g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../.. -I../.. -I../../boost |-isystem /usr/X11R6/include -O -W -Wall -Wp,-MD,.deps/insetcaption.pp -c |insetcaption.C -o insetcaption.o | In file included from insetcaption.h:20, | from insetcaption.C:17: | insettext.h:181: syntax error before `const' | In file included from ../../src/insets/insetfloat.h:19, | from insetcaption.C:22: | ../../src/insets/insetcollapsable.h:133: syntax error before `const' ok, easy to fix... missing std:: on vector (and perhaps an include) -- Lgb
Re: MVC comments
On 05-Apr-2001 Allan Rae wrote: > - outputs_[INITIAL] = CLOSE; > + outputs_[INITIAL] = OKAY | APPLY | CLOSE; > > This should be a safe change for both these policies. It'd also mean that > after a Restore you can still press Okay or Apply without changing > something in the dialog. > > Provided we do an input check on the contents of the dialog just as it is > being shown then we can move to the appropriate state (INVALID or > RO_INVALID) if the contents aren't initially valid. I suspect we assume > that the contents are always valid on initial showing. > Well we would need OKAY | APPLY only if the cursor moves to some other paragraph isn't it or in general if the cursor moves. We should send a update signal to buffer dependent dialogs but for this type of dialog we would need one more signal and that is a signal which activates that buttons if one of the parameters of the actual paragraph differs with the content of the actual cursor position (or in the case of the ParagraphLayout the paragraph we are actually in). Also it would be great to have: 1. A button in the Dialog to update the contents with the actual paragraph (or whatever) settings. 2. An other way to realize this. Mayby just reopening the dialog (also without closing it first) should do this. Otherwise if I want to change only one thing in a paragraph I have to close the Dialog and reopen it when the cursor is inside the paragraph to have the Dialog with the right values. Comments?! Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ You'd like to do it instantaneously, but that's too slow.
