Idea for selecting delimiters in Delimiter panel
Hello Lyx Developpers
If I had the skill, i would probably give a patch for that, but i'm a
simple user (for the moment).
I write my thesis now. I have a lot of equations with lots of [] {} ()
and so on...
I would be nice if
-- the left clic on the desired delimiter select left delimiter
-- the right clic on the desired delimiter select right delimiter
It would be faster for me
thanks for your jobs, this soft is really nice, and usable
Yann
--
"Y faut liiirrreee, Arlequin, Champion de l'amou" Dany Boon
---
(Yann MORERE mailto:[EMAIL PROTECTED] )
(Doctorant Automatique http://ymorere.multimania.com/ )
Re: Keyboard handling - current cvs
[EMAIL PROTECTED] (Lars Gullik Bj nes) wrote: > Hmm, not quite true? 0.88 does not use XmbLookupString and we use the > LyXLookupString as we did earlier, but at a different point in the X > callback chain. In 0.89 XForms uses XmbLookupStrin internally and we > only use XLookupString to get hold of the XEvents keysym. Then I guess I have to request T.C. Zhao for 0.89 source. Regards, SMiyata
Adolescent LyX
LyX seems to have developed acne. There are pimples everywhere now. I think there is at least one we can squeeze out: the GUIRuntime pimple. I can't see that it serves any useful purpose to have an extra class here (other than helping extend compile times by a second or so). Why not just share the common header file in frontends/GUIRuntime.h between the toolkit specific frontends/*/GUIRuntime.C? Just like we do with frontends/*/Dialogs.C. It will achieve the same effect -- we only have one of the pimple implementations in any given executable now anyway. Nice idiom, wrong application. Even if someone eventually finds the need for variables in the GUIRuntime class then you could use a Pimpl specific to the toolkits. Either way we don't need frontends/GUIRuntime.C. What you would have at best (with the current implementation rewritten): frontend/GUIRuntime.h frontend/*/GUIRuntime.C at worst (if someone needed variables in class GUIRuntime): frontend/GUIRuntime.h frontend/*/GUIRuntime.C frontend/*/GUIRuntime_pimpl.h frontend/*/GUIRuntime_pimpl.C Allan. (ARRae)
Re: Suggestion on FormTabular: Cell cettings and multicol
On 21 Aug 2000, Lars Gullik Bjønnes wrote: > Allan Rae <[EMAIL PROTECTED]> writes: > > | On Fri, 18 Aug 2000, Juergen Vigna wrote: > | > | > > | > On 17-Aug-2000 Lars Gullik Bjønnes wrote: > | > > > | > > NEW_INSETS should be enabled at the same time, because: > | > > | > Well to answer you what I think: [...] > | > Why activate NEW_TABULAR and not NEW_INSETS: [...] > | > > | > So you see while the tabular-inset IS ready for prime-time most (it reads > | > all old code correct I tried this with various files and also the UserGuide!) > | > the other text inset still need lot's of work. > | [...] > | > My vote is 1.1.6 with ONLY NEW_TABULAR activated! > > I think I'd be willing to do this for 1.1.6. > > | I'm willing to compromise on my 1.1.6-with-no-NEW_ANYTHING by suggesting: > | > | ./configure --with-bleeding-edge=tabular \ > | --with-bleeding-edge=insets > > Hate it already... the fileformats will not be compatible. So? The point is to make it easier for people to test the new stuff. As it is now they have to figure out where to set a #define. Maybe this is a useful way of filtering out people who probably couldn't do much debugging if they did encounter problems but it also means that people with a little time and the skills are put off trying the new stuff. *I'm* put off trying the new stuff because I have to change the sources and hence risk committing that change to cvs (as I think Jürgen has already done himself) and I have only a little time for LyX at present. > | This makes it even easier for people to try the new stuff while still > | recognising that it may be buggy. Besides, having a --with-bleeding-edge > | option would be a fun and useful addition ;-) > > No, not really. You're right. I should have suggested: ./configure --with-cucumber=insets :Þ Allan. (ARRae)
Re: BUG when closing document
On Mon, 21 Aug 2000, Juergen Vigna wrote: > > On 19-Aug-2000 Baruch Even wrote: > > On Sat, 19 Aug 2000, Baruch Even wrote: > > > >> Whoever did the new FormDocument, I BLAME YOU! > > > > Sorry for this harsh language, I'm too tired to think anymore. I apologize > > You shouldn't be sorry it was friday, wasn't it ;) > > Anyway I've seen Allan fixed this already and also changed the > ButtonPolicy for FormDocument. > > BTW.: Allan now the "Restore"-button is always disabled, do I have to > enable it by hand? U... let me guess... you added a restore button to FormDocument? Okay, then we have a problem. I didn't realise you had done this. In which case we need to do one of three things: 1. Allow more than one object to be matched to a given "Button" in ButtonController. For example, list apply_; instead of FL_OBJECT * apply_; 2. Create a new policy for RestoreReadOnly. 3. Add "UndoAll" to the output of the appropriate states in all the policies. #1 is easy to change but would mean that Restore wouldn't be active while the doc was readonly (all the readonly policies allow editting of the dialog contents but keep OK and Apply deactivated). I also can't see that it would be much use for any dialogs. #2 means adding a new policy that is effectively a merger of NoRepeatedApplyReadOnlyPolicy and PreferencesPolicy. #3 is probably the best option otherwise we end up creating a million and one different policies that are otherwise almost identical. Hmmm... yes that makes better sense. That just means any state that has the dialog in a modified condition should have "| UndoAll" appended to its state output. I'll take a look. But I really need to get LDN done first. Allan. (ARRae)
Re: Graphics insert - question
On Mon, 21 Aug 2000, Martijn Brouwer wrote: > Hello Baruch, > At 06:35 AM 8/19/00 +0300, you wrote: > >I'm the developer who works on the Graphics Inset, that is the component > >that is responsible for the insertion of graphics into LyX documents and > >emiting the LaTeX code for them. That is I'm working on the NEW Graphics > >Insert as opposed to the old (and unsupported) FigInset. > > >There are quite a few features that will be added, for example the > >auto-conversion of file formats, say from EPS to PNG when generating PDF > >files, and from JPG to PNG or EPS when generating PS or PDF outputs. > > I would very much appreciate the possibility to insert pstex/pstex_t > figures in the same way as normal .eps figures, with the possility to ajust > its size and view the result in a wysiwym way. > I am not a TeX-nician, but to me it seems that this is not impossible, or > am I wrong. I hope it does not require to much rewriting... I expect this to occur later on in the schedule, for this to happen I'll actually need to merge my InsetGraphics with ExternalInset, the first handles only pure graphics files, the second can handle mostly anything, but it doesn't give the graphics dialog for the graphics file. It was already discussed in the development list, and I expect the merger to happen one day, though it's not as simple as it sounds and requires some work and thought to be done correctly. The reason that my InsetGraphics won't do this from the start is that it requires special handling, the external inset actually takes the .fig file and exports from it the pstex sources that are then included into the latex sources with a special latex code that is needed for this. The graphics inset has no such smartness, the idea is to have the graphics dialog capability for the graphics import of the external inset. Until then if you want the pstex use the external inset, if you want resizing create an EPS output from the XFig file and use that. > >features or less important. The net question is this, assuming I can get > >either inline viewing or additional features into the Graphics Inset for > >the next version of LyX, what would you prefer? > > In my oppinion features are nearly allways more important than presentation. Another vote for features first :-) I'll change course to add features over doing inline viewing. But actually the auto-conversion feature that is on the top of the list has components that are shared with the inline viewing so it's not really diverging.
minor big in filename handling
If you use a filename with a % in it (mine was comps10%.lyx), the following error occurs: In ParsePup [xpopup.c 298] Unknown sequence %. In PupParse [xpopup.c 304] Error while parsing pup entry Everything still appears to work in spite of this message. Kenneth
Re: [cpptips] a little initialization gem (fwd)
On 21 Aug 2000, Lars Gullik Bjønnes wrote: > John Levon <[EMAIL PROTECTED]> writes: > > | On 21 Aug 2000, Lars Gullik Bjønnes wrote: > | > | > No. > | > > | > | That's what I thought. I asked just to make sure I wasn't going to > | embarrass myself C++-wise. > | > | Anyway, my point being, this isn't portable. Not all OS's ensure that the > | BSS (or equivalent) is zeroed out on load. So it would be better IMHO not > | to rely on such a feature. > > It should be portable, it is required by the language... > So actually we _should_ rely on this. IMO this is the same box as > deleting a null pointer is a no-op. So we dont ned if (ptr) delete ptr; > > Lgb > Lars sorry for the confusion then. I didn't know this was actually part of the standard. thanks john -- "Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes." - Richard Hamming
Re: [cpptips] a little initialization gem (fwd)
John Levon <[EMAIL PROTECTED]> writes: | On 21 Aug 2000, Lars Gullik Bjønnes wrote: | | > No. | > | | That's what I thought. I asked just to make sure I wasn't going to | embarrass myself C++-wise. | | Anyway, my point being, this isn't portable. Not all OS's ensure that the | BSS (or equivalent) is zeroed out on load. So it would be better IMHO not | to rely on such a feature. It should be portable, it is required by the language... So actually we _should_ rely on this. IMO this is the same box as deleting a null pointer is a no-op. So we dont ned if (ptr) delete ptr; Lgb
Re: [cpptips] a little initialization gem (fwd)
On 21 Aug 2000, Lars Gullik Bjønnes wrote: > No. > That's what I thought. I asked just to make sure I wasn't going to embarrass myself C++-wise. Anyway, my point being, this isn't portable. Not all OS's ensure that the BSS (or equivalent) is zeroed out on load. So it would be better IMHO not to rely on such a feature. I'll admit I don't know what actually happens under OS/2 or Windows, but it seems a good idea not to rely on this ... john -- "Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes." - Richard Hamming
Re: [cpptips] a little initialization gem (fwd)
John Levon <[EMAIL PROTECTED]> writes:
| > (or is this only static variables at file scope?)
| >
| > Lgb
| >
|
| Is this a c++ thing ?
No.
Try this:
#include
static
int test1;
int test2;
int main()
{
int test3;
printf("test1: %d\n", test1);
printf("test2: %d\n", test2);
printf("test3: %d\n", test3);
}
With both C and C++ compilers.
Lgb
RE: some qustions: FormCitation, FormTabular
Hi Marko! > > FormTabular: It looks like the functionality of this dialog box is > duplicated (partly) by Edit/Table menu. What is an expected evaluation of > this dialog? Will it be just used for borders or we will have two way > to add/remove columns ... ? Or maybe we will have a special toolbar for > tables? The Menu-Entries are only there so you can access some functionality of the tabular without the need to use a mouse. The evaluation, hmmm, well I would say it's the primary frontend to set stuff for the tabular! Toolbars? Why not, but be aware that you cannot set all stuff from toolbar as you can't from the menu! It would be really great to have toolbars for different modules. > > Finally, how can I fire up FormGraphics? Menu? M-x graphic-insert? 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Possessions increase to fill the space available for their storage. -- Ryan
Re: some qustions: FormCitation, FormTabular
On Mon, 21 Aug 2000, Marko Vendelin wrote: > Finally, how can I fire up FormGraphics? Menu? I'm the one who wrote it (and still do), so I'll answer. This dialog is started up for the new insetgraphics, which is not yet at a finished state so it doesn't appear in the menu. However you can do: M-x graphics-insert to insert the inset and show the dialog.
some qustions: FormCitation, FormTabular
Hi! before porting these dialogs to gnome frontend I would like to ask the following questions: FormCitation: I think that there is an important functionality missing in this dialog. Namely, I really miss "Search" and bibtex parser. In my work, I use bibtex database which has more than 1000 entries, each key is very lengthy containing author names, journal name, pages, year, ... So, when the current implementation of FormCitation is fired up, I see huge amount of keys (unsorted!) with almost no hope to find the right one :(. Thus, it will be nice to have at least a possibility to search the references. To make looking up of the references a little bit more fun, I would like to have a columned list with author names, title, year in the separated columns. This means that I have to parse the contents of the blist[i].second field. How should I implement it? Do we have bibtex parser within LyX? What should I expect to find in this field? FormTabular: It looks like the functionality of this dialog box is duplicated (partly) by Edit/Table menu. What is an expected evaluation of this dialog? Will it be just used for borders or we will have two way to add/remove columns ... ? Or maybe we will have a special toolbar for tables? Finally, how can I fire up FormGraphics? Menu? Marko
Re: [cpptips] a little initialization gem (fwd)
On 21 Aug 2000, Lars Gullik Bjønnes wrote: > "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes: > > | Of course, it will not detect uninitialized global variables, but you > | would never use such, would you? > > Variables at file scope are always automatically initialized. > (or is this only static variables at file scope?) > > Lgb > Is this a c++ thing ? john -- "Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes." - Richard Hamming
Re: CVS instructionm
Baruch Even <[EMAIL PROTECTED]> writes: | I've been given (read) access to the main cvs reposistory, however now | thatg I'm on my aging computer I don't remember the CVSROOT required to | access it (I've got the user and passwd). | | Can anyone refresh my memory? (It's working much like regular computer | memory, requires a read/write sequence every once in a while :-) CVSROOT=:ext:[EMAIL PROTECTED]:/usr/local/lyx/cvsroot Lgb
Re: Nits
On 20-Aug-2000 Dekel Tsur wrote: > > I thought that alt+enter (break paragraph, keep layout) would do what you > want (i.e., start a new paragraph, but keep it in the minipage) > but it doesn't. I consider this a bug, and it can be fixed by removing the > if condition in LyXParagraph::SetPExtraType (patch is attached). > > This patch should be applied to the CVS (and to the 1.1.5 branch) assuming > it doesn't break anything. I'm not sure this is the right patch, but I will have a look (I'm sure the if is there because I had a reason to put it there, but ...) Anyway we will change to Minipage-Insets in 1.2.0 (I'm quite sure about this!) and so this minipage hack will vanish! 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Truth is free, but information costs.
Re: [cpptips] a little initialization gem (fwd)
"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes: | Of course, it will not detect uninitialized global variables, but you | would never use such, would you? Variables at file scope are always automatically initialized. (or is this only static variables at file scope?) Lgb
Re: BUG when closing document
On 19-Aug-2000 Baruch Even wrote: > On Sat, 19 Aug 2000, Baruch Even wrote: > >> Whoever did the new FormDocument, I BLAME YOU! > > Sorry for this harsh language, I'm too tired to think anymore. I apologize You shouldn't be sorry it was friday, wasn't it ;) Anyway I've seen Allan fixed this already and also changed the ButtonPolicy for FormDocument. BTW.: Allan now the "Restore"-button is always disabled, do I have to enable it by hand? 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Bill Dickey is learning me his experience. -- Yogi Berra in his rookie season.
Re: Suggestion on FormTabular: Cell cettings and multicol
>| > My vote is 1.1.6 with ONLY NEW_TABULAR activated! > > I think I'd be willing to do this for 1.1.6. Ok then I'll do my best to fix all the "missing-feature" reports I got till now (when time permits). BTW.: Are you working on LyXGui-Class? I had in mind to remove all xforms calls from this class (if possible I didn't look at it till now) and move them over to the frontends or lyx_gui_misc. 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "If there isn't a population problem, why is the government putting cancer in the cigarettes?" -- the elder Steptoe, c. 1970
Re: Suggestion on FormTabular: Cell cettings and multicol
Allan Rae <[EMAIL PROTECTED]> writes: | On Fri, 18 Aug 2000, Juergen Vigna wrote: | | > | > On 17-Aug-2000 Lars Gullik Bjønnes wrote: | > > | > > NEW_INSETS should be enabled at the same time, because: | > | > Well to answer you what I think: [...] | > Why activate NEW_TABULAR and not NEW_INSETS: [...] | > | > So you see while the tabular-inset IS ready for prime-time most (it reads | > all old code correct I tried this with various files and also the UserGuide!) | > the other text inset still need lot's of work. | [...] | > My vote is 1.1.6 with ONLY NEW_TABULAR activated! I think I'd be willing to do this for 1.1.6. | I'm willing to compromise on my 1.1.6-with-no-NEW_ANYTHING by suggesting: | | ./configure --with-bleeding-edge=tabular \ | --with-bleeding-edge=insets Hate it already... the fileformats will not be compatible. | This makes it even easier for people to try the new stuff while still | recognising that it may be buggy. Besides, having a --with-bleeding-edge | option would be a fun and useful addition ;-) No, not really. Lgb
Re: Keyboard handling - current cvs
Miyata Shigeru <[EMAIL PROTECTED]> writes: | Since the current CVS does not use XmbLookupString(), LyX only receives | raw keyboard events and there is no event processed by IM server. Hmm, not quite true? 0.88 does not use XmbLookupString and we use the LyXLookupString as we did earlier, but at a different point in the X callback chain. In 0.89 XForms uses XmbLookupStrin internally and we only use XLookupString to get hold of the XEvents keysym. Lgb
Re: A small bug fix
Allan Rae wrote: > > On Mon, 21 Aug 2000, Garst R. Reese wrote: > > > Allan Rae wrote: > > > > > > On Mon, 21 Aug 2000, Garst R. Reese wrote: > > > > Just tried to make. Attached is the log. > > > > xforms .88, gcc-2.95.2 libc2.1.3 > > > > Garst > > > > > > D'oh! Fixed the fix now. Try again. > > > > > > Allan. (ARRae) > > It compiled, I can close a file, but Alt-Enter still gets me out of a > > mini-page, and it looks like dekel's patch did *not* get committed. > > Not the patch from Dekel that you are talking about. I committed his > other one-line patch to Spacing.C. I haven't looked at his patch from the > "Nits" thread. > > Allan. (ARRae) OK :), thanks.
