Re: New Coding Rule
On Tue, Mar 12, 2002 at 12:28:10AM +0100, Lars Gullik Bjønnes wrote:
> | Can you please give an example for the brain dead amongst us ?
>
> class Foo {
> // unsafe variant
> Foo()
> : bar1(new Bar), bar2(new Bar)
> {}
> // safer variant
> Foo() {
> bar1 = new Bar;
> bar2 = new Bar;
> }
> private:
> Bar * bar1;
> Bar * bar2;
> };
Bad example. No class should contain more than one raw 'owned' pointer
is a better rule...
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
Re: New Coding Rule
On Mon, Mar 11, 2002 at 11:24:49PM +0100, Lars Gullik Bjønnes wrote: > I just got a new book :-) That's fine for you. > - > Always perform unmanaged resource acquisition in the constructor body, > never in initializer lists. > - > > - > Perform every explicit resource allocation (for example, new) in its > own code statement, which immidiately gives the new'd resource to a > manager object (for example, auto_ptr.) > - > > Both of these has to do with exception safety, and even if we do not > use exceptions yet, we should think about this now. Care to explain? I think I understand the latter, but not the first. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Re: lyxtextclass optimization
On Mon, Mar 11, 2002 at 06:21:03PM +0100, Lars Gullik Bjønnes wrote: > I felt that the layout lookup became a bit slow with the new layout as > string stuff, so I did this patch. Is the added complexity worth it? Hm... I doubt that there is a lot of difference when there are just 30 items in the vector/map... Do you have any hard numbers? Apart from that I'd rather try to come up with some "really fast" 'conststring' class which could improve most of the handling of this 'strings used for convenience reasons' stuff, both for memory and runtime. > (I cleaned up the textclass a bit as well...) That's not too bad I guess. Andre' -- André Pönitz .. [EMAIL PROTECTED]
Problem compiling LyX cvs
Hello, On my linux box debian 2.2r3 sparc, i try to compile lyx cvs. I had no problem with last wee releases, but last friday, and yesterday i get this g++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I../boost -I./xforms -isystem /usr/X11R6/include -O -fno-rtti -fno-exceptions -W -Wall -c buffer.C buffer.C:300: warning: #warning And _why_ is this here? (Lgb) buffer.C: In method `const class string Buffer::asciiParagraph(const Paragraph *, unsigned int, bool = false) const': buffer.C:1997: no matching function for call to `basic_string,__default_alloc_template >::push_back (char &)' make[3]: *** [buffer.o] Error 1 make[3]: Leaving directory `/root/lyxdevel/lyx-devel/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/root/lyxdevel/lyx-devel/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/root/lyxdevel/lyx-devel/src' make: *** [all-recursive] Error 1 lyxdevel@yoda:~/lyx-devel$ even with "cvs lyx checkout" and the following make command : make clean; ./autogen.sh; CFLAGS="-O2" CXXFLAGS="-O2" ./configure --prefix=/home/lyxdevel/lyx;make CXXFLAGS="-O -fno-rtti -fno-exceptions -W -Wall" Is anybody got an idea Yann -- A little suffering is good for the soul. -- Kirk, "The Corbomite Maneuver", stardate 1514.0 --- ( Yann MORERE ICQ=#97130491 mailto:[EMAIL PROTECTED] ) ( Tel.: 33 (0)3 87 54 70 87 Fax.: 33 (0)3 87 31 53 33) ( Maitre de Conférences http://ymorere.multimania.com/ )
lfuncore.diff
can someone apply lfun_core.diff please ? thanks john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.
Re: New Coding Rule
John Levon <[EMAIL PROTECTED]> writes:
| On Mon, Mar 11, 2002 at 11:24:49PM +0100, Lars Gullik Bjønnes wrote:
>
>> Always perform unmanaged resource acquisition in the constructor body,
>> never in initializer lists.
>
| Can you please give an example for the brain dead amongst us ?
class Foo {
// unsafe variant
Foo()
: bar1(new Bar), bar2(new Bar)
{}
// safer variant
Foo() {
bar1 = new Bar;
bar2 = new Bar;
}
private:
Bar * bar1;
Bar * bar2;
};
For the unsafe constructor try to think how you can avoid a memory
leak if the second new throws.
--
Lgb
Re: New Coding Rule
On Mon, Mar 11, 2002 at 11:24:49PM +0100, Lars Gullik Bjønnes wrote: > Always perform unmanaged resource acquisition in the constructor body, > never in initializer lists. Can you please give an example for the brain dead amongst us ? regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.
New Coding Rule
I just got a new book :-) More Exceptional C++, and I found a couple of nice rules that I want us to adopt: - Always perform unmanaged resource acquisition in the constructor body, never in initializer lists. - - Perform every explicit resource allocation (for example, new) in its own code statement, which immidiately gives the new'd resource to a manager object (for example, auto_ptr.) - Both of these has to do with exception safety, and even if we do not use exceptions yet, we should think about this now. -- Lgb
list manager warning messages
Gals and Guys, Lately, apparently some messages sent to the list contained viruses, and some ISPs bounce these messages back to the list manager which then sends out a warning message to you. These warnings are harmless, and you are not going to be dropped from the list as a result. If, on the other hand, a warning message also bounces (this should not happen since the warning message will not contain a virus) then after some grace period the list manager sends out a probe, and if the probe also bounces then you will be removed from the list since the list manager declares your address bad. There are about 20 days between the message the list manager tried to deliver to you first bounced, and the possible removal of your address from the list because a probe message bounced. I'd like to emphasize that if only messages containing viruses are bounced back to the list manager, but not the warning message, then you will not be removed from the list. In case you want to know more, let me tell you the paperpath of a message that bounces: 1) Suppose [EMAIL PROTECTED] sends a message to the list. 2) Upon receiving the message, the list manager called ezmlm first rewrites the sender address [EMAIL PROTECTED] to a special address. This is to protect the sender. Indeed, imagine you are [EMAIL PROTECTED], and imagine 50 of subscribers's to the list bounce back the message. According to the rules of email (rfc 2821), bounces must go to the sender address---so [EMAIL PROTECTED] (you) would receive 50 bounces. Not great. So to protect the sender [EMAIL PROTECTED], ezmlm changes the sender address to a special address so that any bounce will be handled by ezmlm automatically. It is important to note that ezmlm makes no other change to the message. So if the message contained a virus, the virus will be sent to all subscribers. 3) Now suppose the message (originally from [EMAIL PROTECTED]) ezmlm is trying to send to the subscriber address [EMAIL PROTECTED] bounces (say the server on c.d detected a virus in the message). The bounce arrives back to ezmlm. It then waits about 10 days, and sends a warning message to [EMAIL PROTECTED] explaining that some messages have bounced back. Now two things can happen: 3/a: This warning message bounces back from [EMAIL PROTECTED] Then ezmlm makes a note of it, and about 10 days later will send a probe message to [EMAIL PROTECTED] If the probe bounces back, the address [EMAIL PROTECTED] is removed from the list. If the probe does not bounce back, the bad behavior of [EMAIL PROTECTED] is forgotten for now. 3/b: This message does not bounce back from [EMAIL PROTECTED] Then the bad behavior of [EMAIL PROTECTED] is forgotten for now. That is it. So note that if a new message sent to the list bounces back from [EMAIL PROTECTED], then the whole thing starts all over. In particular, another 20 day grace period will start for this new message---independently from [EMAIL PROTECTED]'s bad behavior on a previous message. You see you will be removed from the list only if your address is really bad. Mate
Re: [Devel] New bug list
Angus Leeming <[EMAIL PROTECTED]> writes: | - When changing "LyX View>Scale" to 70 in the graphics dialog and pressing | enter: |"BadWindow (invalid Window parameter) id: 33555485" <-> crash (happens in | other situations, too) > > | The important thing here is to hit the Return key on the keyboard after | changing the size. Here I get consistently: > | We exec'd a shell: /usr/bin/sh | Received unhandled X11 event | Type: 0xaTarget: 0x7800115 | Received unhandled X11 event | Type: 0x9Target: 0x7800115 | Received unhandled X11 event | Type: 0x8Target: 0x7800115 > | The message is printed from WorkArea::getClipboard() does anything bad happen? because some application attach a type tag to the clipboard selection that xforms does not understand... but it should not harm anything. -- Lgb
Is .../lib/doc/ExternalMaterial.lyx still relevant
I've been thinking about starting to update the docs in anticipation of 1.2.0, now that the interface appears to be stabilizing a bit. While rooting around the CVS, I discovered the above file. Is it still relevant? If so, I'll paste it into Extended. Whether it is or isn't, it should probably be deleted from this directory. Mike -- Mike Ressler [EMAIL PROTECTED] OK, I'm lame: I don't have my own website ...
umlauts in file name
Hi, when I export a LyX file with german umlauts in the file name (like "Kündigung.lyx") to an postscript (or latex or ...) file, then the file name will contain stupid characters (like "K|ndigung.ps"). Can I change this behaviour or is it a bug? Greetings! __ Tagesgeld: 4% Guthabenzinsen bei täglicher Verfügbarkeit. Jetzt informieren! http://diba.web.de/
Re: DocBook-class weirdness
On Monday, 11. March 2002 10.01, you wrote: > On Sunday 10 March 2002 10:46, Niklaus Giger wrote: > > > > I had a LyX-file based on the LinuxDoc class. It > > > > had some Itemize, Description paragraphs. Then I > > > > changed the layout to DocBook class and I got quit > > > > a few errors like this: > > > > > > > > /usr/bin/jade:[EMAIL PROTECTED]:228:12:E: end tag for > > > > element "LISTITEM" which is not open > > > > > > can you create a small lyx file that demonstrates the > > > bug please ? > > > > It is attached. > > Ok, I see. In docbook all descriptions must have the > second part, that is mandatory. > > So, it should be: > > Describe something > more something Thank you very much for your hint. But this behaviour violates the "Principle of least surprise", which I think is usually appropriate for a user interface. E.g. I often begin sketching my ideas with just one or two words in a description. The rest will follow later. It would be very nice and helpful if you could figure out a work around for a upcoming version of LyX. Regards -- Niklaus Giger Wieshoschet 6 CH-8753 Mollis [EMAIL PROTECTED] Tel. G: +41 55 618 64 68, P: +41 55 612 20 54
Re: CRASH latest cvs
On Monday 11 March 2002 5:22 pm, Herbert Voss wrote: > I get a crash when Layout->LaTeX preamble > > it works when I comment out this line in FormPreamble.C > >setPrehandler(dialog_->input_preamble); > > but then the ok-button isn't activated when pasting into > the preamble window. > > Herbert Fixed. A
lyxtextclass optimization
I felt that the layout lookup became a bit slow with the new layout as
string stuff, so I did this patch. Is the added complexity worth it?
(I cleaned up the textclass a bit as well...)
all lookup functions has changed from O(n) to O(log n)
delete_layout is still O(n), but with a higer constant factor.
but of course the lists are never very long, so the constant factor
really plays a role here.
Index: src/lyxtextclass.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtextclass.h,v
retrieving revision 1.2
diff -u -p -r1.2 lyxtextclass.h
--- src/lyxtextclass.h 2002/03/02 16:39:48 1.2
+++ src/lyxtextclass.h 2002/03/11 17:15:13
@@ -23,6 +23,7 @@
#include "LString.h"
#include
+#include
class LyXLex;
@@ -34,12 +35,14 @@ public:
///
typedef std::vector LayoutList;
///
+ typedef std::map LayoutMap;
+ ///
typedef LayoutList::const_iterator const_iterator;
///
explicit
- LyXTextClass (string const & = string(),
- string const & = string(),
- string const & = string());
+ LyXTextClass(string const & = string(),
+string const & = string(),
+string const & = string());
///
const_iterator begin() const { return layoutlist.begin(); }
@@ -60,9 +63,6 @@ public:
///
LyXLayout const & operator[](string const & vname) const;
- ///
- LyXLayout & operator[](string const & vname);
-
/// Sees to that the textclass structure has been loaded
bool load() const;
@@ -70,8 +70,7 @@ public:
string const defaultLayoutName() const;
///
LyXLayout const & defaultLayout() const;
- ///
- LyXLayout & defaultLayout();
+
///
string const & name() const;
///
@@ -185,7 +184,8 @@ private:
///
LayoutList layoutlist;
-
+ ///
+ LayoutMap layoutmap;
/// Has this layout file been loaded yet?
mutable bool loaded;
};
Index: src/lyxtextclass.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/lyxtextclass.C,v
retrieving revision 1.8
diff -u -p -r1.8 lyxtextclass.C
--- src/lyxtextclass.C 2002/03/05 23:02:37 1.8
+++ src/lyxtextclass.C 2002/03/11 17:15:13
@@ -183,13 +183,16 @@ bool LyXTextClass::Read(string const & f
string const name = subst(lexrc.getString(),
'_', ' ');
if (hasLayout(name)) {
- LyXLayout & lay = operator[](name);
+ LyXLayout & lay = layoutlist[layoutmap[name]];
error = do_readStyle(lexrc, lay);
} else {
LyXLayout lay;
lay.setName(name);
- if (!(error = do_readStyle(lexrc, lay)))
+ if (!(error = do_readStyle(lexrc, lay))) {
+ layoutmap[name] = size();
layoutlist.push_back(lay);
+ }
+
if (defaultlayout_.empty()) {
// We do not have a default
// layout yet, so we choose
@@ -496,10 +499,9 @@ string const & LyXTextClass::rightmargin
bool LyXTextClass::hasLayout(string const & n) const
{
string const name = (n.empty() ? defaultLayoutName() : n);
-
- return find_if(layoutlist.begin(), layoutlist.end(),
- lyx::compare_memfun(&LyXLayout::name, name))
- != layoutlist.end();
+
+ LayoutMap::const_iterator cit = layoutmap.find(name);
+ return cit != layoutmap.end();
}
@@ -511,49 +513,18 @@ LyXLayout const & LyXTextClass::operator
lyxerr << "Operator[] called with empty n" << endl;
string const name = (n.empty() ? defaultLayoutName() : n);
-
- LayoutList::const_iterator cit =
- find_if(layoutlist.begin(),
- layoutlist.end(),
- lyx::compare_memfun(&LyXLayout::name, name));
- if (cit == layoutlist.end()) {
+ LayoutMap::const_iterator cit = layoutmap.find(name);
+ if (cit == layoutmap.end()) {
lyxerr << "We failed to find the layout '" << name
<< "' in the layout list. You MUST investigate!"
<< endl;
-
- // we require the name to exist
- lyx::Assert(false)
CRASH latest cvs
I get a crash when Layout->LaTeX preamble it works when I comment out this line in FormPreamble.C setPrehandler(dialog_->input_preamble); but then the ok-button isn't activated when pasting into the preamble window. Herbert -- http://www.lyx.org/help/
Re: [Devel] New bug list
- When changing "LyX View>Scale" to 70 in the graphics dialog and pressing enter: "BadWindow (invalid Window parameter) id: 33555485" <-> crash (happens in other situations, too) The important thing here is to hit the Return key on the keyboard after changing the size. Here I get consistently: We exec'd a shell: /usr/bin/sh Received unhandled X11 event Type: 0xaTarget: 0x7800115 Received unhandled X11 event Type: 0x9Target: 0x7800115 Received unhandled X11 event Type: 0x8Target: 0x7800115 The message is printed from WorkArea::getClipboard() Hope this info helps... Angus
Re: [Bug 60] page up/down in large ERT insets
On Mon, Mar 11, 2002 at 04:53:47PM +0100, Juergen Vigna wrote: > > I strongly disagree. Page Down doesn't move down a page sometimes: how > > can that /not/ be a bug ? > > > > OK, it perhaps is hard to fix, and won't happen for 1.2.0 - that's fine. > > We are going to have open bugs for 1.2.0, no question. But it doesn't > > make them a feature request. > > So you tell me that when I am 3 lines above the end of a document and I > press PG/Down and it "only" scrolls down the remaining 3 lines this is > wrong. Isn't it? That's fine, if it did that. Open the test case. Press Page Down (goes to start of inset - OK, but not ideal). Press PAge Down - *nothing happens*. That is not right. This is why I said we need to have some code to place a cursor on screen artibtrarily that actually opens insets etc. Do you see my point now ? regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.
RE: [Bug 60] page up/down in large ERT insets
On 11-Mar-2002 bugzilla-daemon wrote: > I strongly disagree. Page Down doesn't move down a page sometimes: how > can that /not/ be a bug ? > > OK, it perhaps is hard to fix, and won't happen for 1.2.0 - that's fine. > We are going to have open bugs for 1.2.0, no question. But it doesn't > make them a feature request. So you tell me that when I am 3 lines above the end of a document and I press PG/Down and it "only" scrolls down the remaining 3 lines this is wrong. Isn't it? Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ 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 -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ This fortune is dedicated to your mother, without whose invaluable assistance last night would never have been possible.
Re: [PATCH] Re: bibtex parser broken?
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> attached a "mini"-patch "mini"-applied. JMarc
Re: sourcedoc questions
Angus Leeming <[EMAIL PROTECTED]> writes: | On Monday 11 March 2002 2:27 pm, Lars Gullik Bjønnes wrote: >> Angus Leeming <[EMAIL PROTECTED]> writes: >> >> | On Monday 11 March 2002 1:31 pm, John Levon wrote: >> >> I would love this to happen (everywhere). Why ? >> >> >> >> 1. standardised copyright thing that we agreed on a while ago >> >> 2. obvious generated file thing in sourcedoc >> >> 3. people altering the code are encouraged to add their name to the >> >> authors list if it's a significant change. This /is/ helpful ... >> > >> | What to do with the year info. >> > >> | Ie, was >> |Copyright 1995-2001 LyX Team >> | now >> | * Copyright 2002 the LyX Team >> | ??? >> >> We should change what already is. > | I don't understand your English. Please be explicit as I think this is | probably important. Ha! short: you don't change a copyright notice. -- Lgb
[PATCH] Re: bibtex parser broken?
Juergen Spitzmueller wrote:
> One small, unimportant and strictly cosmetic issue is left.
> Pybliographer doesn't write the year entry as:
>
> year ={2002},
>
> but
>
> year =2002,
>
> Therefor, the parser interprets the year with the comma, so the choice
> displays "Voss (2002,)". If it is easy to strip this comma, it'd be
> cool, otherwise I can live with it.
attached a "mini"-patch
Herbert
--
http://www.lyx.org/help/
Index: src/frontends/controllers/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.145
diff -u -r1.145 ChangeLog
--- src/frontends/controllers/ChangeLog 2002/03/11 11:17:49 1.145
+++ src/frontends/controllers/ChangeLog 2002/03/11 14:30:54
@@ -1,3 +1,8 @@
+2002-03-11 Herbert Voss <[EMAIL PROTECTED]>
+
+ * biblio.C (parseBibTeX): fix another minibug with an
+ ending comma
+
2002-03-10 Herbert Voss <[EMAIL PROTECTED]>
* biblio.C (parseBibTeX): fix bug
Index: src/frontends/controllers/biblio.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/biblio.C,v
retrieving revision 1.18
diff -u -r1.18 biblio.C
--- src/frontends/controllers/biblio.C 2002/03/11 11:17:49 1.18
+++ src/frontends/controllers/biblio.C 2002/03/11 14:30:54
@@ -9,6 +9,7 @@
*
* \file biblio.C
* \author Angus Leeming <[EMAIL PROTECTED]>
+ * \author Herbert Voss <[EMAIL PROTECTED]>
*/
#include
@@ -212,7 +213,7 @@
if (year.empty())
year = "50BC";
-
+
return year;
}
@@ -394,7 +395,8 @@
if (data.length() < 2 || data[0] != '=') { // a valid entry?
return string();
} else {
- data = frontStrip(data.substr(1, data.length() - 1));
+ // delete '=' and the following spaces
+ data = frontStrip(frontStrip(data,'='));
if (data.length() < 2) {
return data;// not long enough to find delimiters
} else {
@@ -405,7 +407,9 @@
} else if (data[0] == '"') {
enclosing = '"';
} else {
- return data;// no {} and no "", pure data
+ // no {} and no "", pure data but with a
+ // possible ',' at the end
+ return strip(data,',');
}
string tmp = data.substr(keypos);
while (tmp.find('{') != string::npos &&
Re: sourcedoc questions
On Monday 11 March 2002 2:27 pm, Lars Gullik Bjønnes wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > | On Monday 11 March 2002 1:31 pm, John Levon wrote: > >> I would love this to happen (everywhere). Why ? > >> > >> 1. standardised copyright thing that we agreed on a while ago > >> 2. obvious generated file thing in sourcedoc > >> 3. people altering the code are encouraged to add their name to the > >> authors list if it's a significant change. This /is/ helpful ... > > > | What to do with the year info. > > > | Ie, was > | Copyright 1995-2001 LyX Team > | now > | * Copyright 2002 the LyX Team > | ??? > > We should change what already is. I don't understand your English. Please be explicit as I think this is probably important. Angus
Re: sourcedoc questions
Angus Leeming <[EMAIL PROTECTED]> writes: | On Monday 11 March 2002 1:31 pm, John Levon wrote: >> I would love this to happen (everywhere). Why ? >> >> 1. standardised copyright thing that we agreed on a while ago >> 2. obvious generated file thing in sourcedoc >> 3. people altering the code are encouraged to add their name to the >> authors list if it's a significant change. This /is/ helpful ... > | What to do with the year info. > | Ie, was | Copyright 1995-2001 LyX Team | now |* Copyright 2002 the LyX Team | ??? We should change what already is. -- Lgb
Re: sourcedoc questions
On Monday 11 March 2002 1:31 pm, John Levon wrote: > I would love this to happen (everywhere). Why ? > > 1. standardised copyright thing that we agreed on a while ago > 2. obvious generated file thing in sourcedoc > 3. people altering the code are encouraged to add their name to the > authors list if it's a significant change. This /is/ helpful ... What to do with the year info. Ie, was Copyright 1995-2001 LyX Team now * Copyright 2002 the LyX Team ??? Angus
Re: sourcedoc questions
On Mon, Mar 11, 2002 at 03:06:46PM +0100, Lars Gullik Bjønnes wrote: > agree. but also note that description of the class that (often) comes > below, should not be documented int he \file section. yes, but then there are examples like bufferview_funcs.C where the file description is useful regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.
Re: sourcedoc questions
John Levon <[EMAIL PROTECTED]> writes: | On Mon, Mar 11, 2002 at 01:15:37PM +, Angus Leeming wrote: > >> /** >> * \file Tooltips.h >> * Copyright 2002 the LyX Team >> * Read the file COPYING >> * >> * \author Angus Leeming, [EMAIL PROTECTED] >> * >> * Tooltips for xforms. xforms 0.89 supports them directly, but 0.88 needs >> * a bit of jiggery pokery. This class wraps it all up in a neat interface. >> * Based on code originally in Toolbar_pimpl.C that appears to have been >> * written by Matthias Ettrich and Jean-Marc Lasgouttes. >> */ >> >> or does nobody care? > | I would love this to happen (everywhere). Why ? > | 1. standardised copyright thing that we agreed on a while ago | 2. obvious generated file thing in sourcedoc | 3. people altering the code are encouraged to add their name to the | authors list if it's a significant change. This /is/ helpful ... agree. but also note that description of the class that (often) comes below, should not be documented int he \file section. -- Lgb
Re: [Fwd: CTAN update -- bmeps 1.0.2]
Thanks all for the information. A
Re: [Fwd: CTAN update -- bmeps 1.0.2]
On Mon, Mar 11, 2002 at 02:46:56PM +0100, Juergen Spitzmueller wrote: > Angus Leeming wrote: > > Incidentally, I have some students here who have convinced themselves > > that LyX is better than MS word for writing theses (don't know who > > could have suggested that they try it ;-). Their stumbling block > > however is creating EPS figures from MS draw ones. Anybody out there > > know of such a tool? > > This one is probably what they are looking for (never tried it, though): > > http://www.wvware.com/libwmf.html Other alternatives are - Print to PS/EPS printer in the windows application and then perhaps use ps2eps http://www.tex.ac.uk/tex-archive/help/Catalogue/entries/ps2eps.html - wmf2eps (a Windows program) http://mitglied.lycos.de/wmf2eps/
Re: [Fwd: CTAN update -- bmeps 1.0.2]
Angus Leeming wrote: > Incidentally, I have some students here who have convinced themselves > that LyX is better than MS word for writing theses (don't know who > could have suggested that they try it ;-). Their stumbling block > however is creating EPS figures from MS draw ones. Anybody out there > know of such a tool? This one is probably what they are looking for (never tried it, though): http://www.wvware.com/libwmf.html Juergen.
Re: sourcedoc questions
On Mon, Mar 11, 2002 at 01:15:37PM +, Angus Leeming wrote: > /** > * \file Tooltips.h > * Copyright 2002 the LyX Team > * Read the file COPYING > * > * \author Angus Leeming, [EMAIL PROTECTED] > * > * Tooltips for xforms. xforms 0.89 supports them directly, but 0.88 needs > * a bit of jiggery pokery. This class wraps it all up in a neat interface. > * Based on code originally in Toolbar_pimpl.C that appears to have been > * written by Matthias Ettrich and Jean-Marc Lasgouttes. > */ > > or does nobody care? I would love this to happen (everywhere). Why ? 1. standardised copyright thing that we agreed on a while ago 2. obvious generated file thing in sourcedoc 3. people altering the code are encouraged to add their name to the authors list if it's a significant change. This /is/ helpful ... regards john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.
Re: [Fwd: CTAN update -- bmeps 1.0.2]
On Sunday 10 March 2002 12:56 pm, Herbert Voss wrote: > Angus, it may be interesting for you Indeed, looks like a useful little program. I think that this info should go in the graphics section of the user guide. Of course, this section needs re-writing to describe the power of Baruch's graphics inset and how the user can make it work for him. Incidentally, I have some students here who have convinced themselves that LyX is better than MS word for writing theses (don't know who could have suggested that they try it ;-). Their stumbling block however is creating EPS figures from MS draw ones. Anybody out there know of such a tool? Angus > - Forwarded message from ctan-upload - > A submission was uploaded to > nova.dante.de:/ftp/incoming/upload-20020306.001/. > > The following information was provided by our fellow contributor: > > Name of contribution: bmeps 1.0.2 > Name and email: Dirk Krause > Suggested location on CTAN: CTAN:/tex-archive/support/bmeps > Summary description: Bugfix for the bmeps program > License type: Free > > Announcement text: > -- > bmeps is a program to convert from PNG, TIFF, JPEG, NetPBM > to EPS. It writes PS levels 1, 2 and 3. Depending on the > PS level one can use run-length, flate and ASCII85-compression or encoding. > Alpha channels in PNG and TIFF can be converted to PS level 3 image masks. > This package contains a bugfix related to malformed DSC comments. > -- > - End forwarded message - > > Thanks for the update, I installed it as suggested in > CTAN:/tex-archive/support/bmeps/ > > Reinhard Zierke > for the CTAN team
sourcedoc questions
Do I want to do this (ie, should I do it)? Index: Tooltips.h === RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/Tooltips.h,v retrieving revision 1.2 diff -u -p -r1.2 Tooltips.h --- Tooltips.h 2002/03/11 09:54:42 1.2 +++ Tooltips.h 2002/03/11 12:58:36 @@ -1,5 +1,5 @@ // -*- C++ -*- -/* +/** * \file Tooltips.h * Copyright 2002 the LyX Team * Read the file COPYING If so, should I do it with all the files below. Further, should I convert those /* This file is part of * == * * LyX, The Document Processor * * Copyright 2000-2001 The LyX Team. * * == * * \file FormToc.C * \author Angus Leeming, [EMAIL PROTECTED] */ to /** * \file Tooltips.h * Copyright 2002 the LyX Team * Read the file COPYING * * \author Angus Leeming, [EMAIL PROTECTED] * * Tooltips for xforms. xforms 0.89 supports them directly, but 0.88 needs * a bit of jiggery pokery. This class wraps it all up in a neat interface. * Based on code originally in Toolbar_pimpl.C that appears to have been * written by Matthias Ettrich and Jean-Marc Lasgouttes. */ or does nobody care? Angus All those .h files with /* comments, not /** ones: grep -n "/[*]" *.h | grep -v "/[*][*]" | grep -v "#endif Color.h:2:/* This file is part of FeedbackController.h:2:/* FeedbackController.h:58:virtual string const getFeedback(FL_OBJECT * /* ob */) FormBase.h:2:/* This file is part of FormBaseDeprecated.h:2:/* This file is part of FormBrowser.h:2:/* FormCitation.h:2:/* This file is part of FormDocument.h:2:/* This file is part of FormERT.h:2:/* This file is part of FormError.h:2:/* FormExternal.h:2:/* This file is part of FormFloat.h:2:/* This file is part of FormGraphics.h:2:/* This file is part of FormIndex.h:2:/* This file is part of FormInset.h:2:/* This file is part of FormLog.h:2:/* FormMinipage.h:2:/* This file is part of FormParagraph.h:2:/* This file is part of FormPreferences.h:2:/* This file is part of FormPreferences.h:13:/* FormPreferences.h FormPrint.h:2:/* This file is part of FormRef.h:2:/* This file is part of FormSendto.h:2:/* FormShowFile.h:3:/* FormTabular.h:2:/* This file is part of FormTabular.h:11:/* FormTabular.h FormTabularCreate.h:2:/* This file is part of FormToc.h:2:/* This file is part of FormUrl.h:2:/* This file is part of FormVCLog.h:2:/* Menubar_pimpl.h:2:/* This file is part of RadioButtonGroup.h:2:/* This file is part of Toolbar_pimpl.h:2:/* This file is part of bmtable.h:1:/* bmtable.h:32:/* A flat bitmap table */ bmtable.h:34:/* A grided bitmap table */ bmtable.h:38:/* Same as fl_bitmapbutton */ combox.h:2:/* combox.h:14:/* Change log: input_validators.h:2:/* This file is part of xformsBC.h:2:/* This file is part of
Re: bibtex parser broken?
Herbert,
One small, unimportant and strictly cosmetic issue is left.
Pybliographer doesn't write the year entry as:
year = {2002},
but
year = 2002,
Therefor, the parser interprets the year with the comma, so the choice
displays "Voss (2002,)". If it is easy to strip this comma, it'd be
cool, otherwise I can live with it.
Regards,
Juergen.
Re: About the new tooltips.
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> On Monday 11 March 2002 11:27 am, Jean-Marc Lasgouttes wrote: >> I tried briefly the new tooltips and have two remarks: >> >> 1/ there should be no delay before the tootips appear, since the >> user explicitely asked for them (like MacOS bubble help) Angus> This is easy with your 0.88 super hack, but harder with the Angus> official 0.89 tooltip which uses fl_context-> tooltip_time Angus> to set the timer. This value is hardcoded in fl_initialize to Angus> 600ms. The problem is, how do I get hold of fl_context whose Angus> struct FL_CONTEXT is defined behind the xforms firewall in Angus> flinternal.h. Probably a request to send to the xforms list... >> 2/ Now I see that activating them via menu (or toolbar) is a pain: >> you open a dialog and find you want some help. Therefore you select >> "What's this" in the _main_ window (and your dialog loses focus); >> then you have to set focus again on the dialog to actually get >> help. That's a pain. >> >> The solution could be a "what's this" checkbox (or a ? pixmap icon >> toggle) on each dialog supporting this. Angus> Gr. You asked for this, I give it to you and now Angus> you ask for what was already there? I'm going off to sulk. I know, I goofed. However, remember what your log message was: Give people a rational basis to describe what they dislike about tooltips!!! I admit that being able to use it changed the perception that I had. This 'bubble help' approach works well on MacOS, because using the menu does not make you loose focus. In our case, things are different, but I failed to see that. >> However, I believe a better solution would be to display the >> tooltip on right click on a widget. Angus, would that be possible? >> In this case, we could get rid of the "what's this?" toggle. Angus> Everything is possible. Let's leave things as they are for now Angus> however. This would consistent with the windows/kde/whatever way. Angus> I'm busy ;-) :) JMarc
Re: About the new tooltips.
On Monday 11 March 2002 11:27 am, Jean-Marc Lasgouttes wrote: > I tried briefly the new tooltips and have two remarks: > > 1/ there should be no delay before the tootips appear, since the user > explicitely asked for them (like MacOS bubble help) This is easy with your 0.88 super hack, but harder with the official 0.89 tooltip which uses fl_context->tooltip_time to set the timer. This value is hardcoded in fl_initialize to 600ms. The problem is, how do I get hold of fl_context whose struct FL_CONTEXT is defined behind the xforms firewall in flinternal.h. > 2/ Now I see that activating them via menu (or toolbar) is a pain: you > open a dialog and find you want some help. Therefore you select > "What's this" in the _main_ window (and your dialog loses focus); then > you have to set focus again on the dialog to actually get help. That's > a pain. > > The solution could be a "what's this" checkbox (or a ? pixmap icon > toggle) on each dialog supporting this. Gr. You asked for this, I give it to you and now you ask for what was already there? I'm going off to sulk. > However, I believe a better solution would be to display the tooltip > on right click on a widget. Angus, would that be possible? In this > case, we could get rid of the "what's this?" toggle. Everything is possible. Let's leave things as they are for now however. I'm busy ;-) Angus
Re: Away
On Friday 08 March 2002 15:06, Andre Poenitz wrote: > On Fri, Mar 08, 2002 at 03:12:53PM +0200, Martin Vermeer wrote: > > As I will be travelling next week, I expect to find > > that 1.2.0pre1 will be available for download on > > Friday March 15. > > This leaves us with 11 years and a few days if I am not mistaken. Without doing such calculations I would say that we also have 28 years and a few days, although that is, certainly, a long time. :-) After every 28 years the relation between the days of months and week days restarts. > Andre' -- José Abílio
Re: Why does InsetGraphics say display() == true???
On Friday 08 March 2002 14:10, Jean-Marc Lasgouttes wrote: > AFAIK, such a thing does not exist in latex, you should just put it in > its own paragraph. I do not know whether linuxdoc/docbook has such a > notion, though. In linuxdoc, no. In docbook yes, although it can go inside a paragraph. So for the moment that is least of my concerns. ;-) > JMarc -- José Abílio
About the new tooltips.
I tried briefly the new tooltips and have two remarks: 1/ there should be no delay before the tootips appear, since the user explicitely asked for them (like MacOS bubble help) 2/ Now I see that activating them via menu (or toolbar) is a pain: you open a dialog and find you want some help. Therefore you select "What's this" in the _main_ window (and your dialog loses focus); then you have to set focus again on the dialog to actually get help. That's a pain. The solution could be a "what's this" checkbox (or a ? pixmap icon toggle) on each dialog supporting this. However, I believe a better solution would be to display the tooltip on right click on a widget. Angus, would that be possible? In this case, we could get rid of the "what's this?" toggle. JMarc
Re: DocBook-class weirdness
On Sunday 10 March 2002 10:46, Niklaus Giger wrote: > > > I had a LyX-file based on the LinuxDoc class. It had > > > some Itemize, Description paragraphs. Then I changed > > > the layout to DocBook class and I got quit a few errors > > > like this: > > > > > > /usr/bin/jade:[EMAIL PROTECTED]:228:12:E: end tag for > > > element "LISTITEM" which is not open > > > > can you create a small lyx file that demonstrates the bug > > please ? > > It is attached. Ok, I see. In docbook all descriptions must have the second part, that is mandatory. So, it should be: Describesomething moresomething > Regards -- José Abílio
Re: drawing of the workarea
On Mon, Mar 11, 2002 at 10:23:55AM +, Angus Leeming wrote: > > Also to conveniently use QScrollView or whatever, we need to have one > > long canvas of a known size, and be able to respond to draw requests of > > an arbitrary row in that canvas. This looks a little painful with > > the current code. > > Looks like you've been busy! One quick and obvious question: how did KLyX do > all this? I had a quick look and didn't quite follow the code (yet). But I don't really follow the current code anyway ... > One other quick and ignorant question: can you embed the existing xforms > WorkArea widget in a qt2 one. Simply to get a qt2-ified LyX main window. First thing I tried, it doesn't look easy. > Incidentally, I think task 11 should be task 1 but that's going to happen > sooner rather than later anyway! I'm going to create a set of bugs on bugzilla like Michael K suggested... john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.
Re: drawing of the workarea
On Sunday 10 March 2002 3:41 pm, John Levon wrote: > well I have a really hacky patch to remove all the forms stuff and only > use Qt. It doesn't do anything yet but I did it to see where we need to > make changes. > > The big one turns out to be the relationships between BufferView_pimpl, > WorkArea, and lyxscreen. > > Currently a redraw looks something like this : > > 1. expose event on workarea gets sent to buffer_pimpl > 2. which then asks lyxscreen to draw what's needed > 3. which then uses lyxtext to draw using bufferview's painter > > Well this doesn't really work sensibly with qt. The workarea widget > itself has to be responsible for drawing siimply because the painter to > use is dependent upon the widget. The current scheme would require > exposing this widget/paint device as global to allow lyxtext to use it. > > Also to conveniently use QScrollView or whatever, we need to have one > long canvas of a known size, and be able to respond to draw requests of > an arbitrary row in that canvas. This looks a little painful with > the current code. Looks like you've been busy! One quick and obvious question: how did KLyX do all this? One other quick and ignorant question: can you embed the existing xforms WorkArea widget in a qt2 one. Simply to get a qt2-ified LyX main window. GUII-fying properly the minibuffer, menubar, toolbar, (drop down), a mechanism to create multiple WorkAreas in one LyXView; all these are orthoganol to the WorkArea stuff you describe and it'd be nice if we could move gradually to the best solutions. Incidentally, I think task 11 should be task 1 but that's going to happen sooner rather than later anyway! Angus
Re: #194
On Mon, Mar 11, 2002 at 05:56:15PM +1000, Allan Rae wrote: > I'd rather get a correct TeXRow in the first place. I have an > alternative patch that ensures rAI() is called before the > Export::Preview() and Export::Update() functions. > > Although it would work just as well I think to rAI() within > makeLaTeXFile() before the creation of the TeXRow. Then would you like to apply your patch and close the bug :) john -- I am a complete moron for forgetting about endianness. May I be forever marked as such.
Re: [PATCH] Re: bibtex parser broken?
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> On Mon, 11 Mar 2002, Juergen Spitzmueller wrote: >> Herbert Voss wrote: > I'll send the patch tomorrow. You said that >> this worked > in the past. But this is not possible, because the >> old > check worked only well for >> > >> > Theodor W. Adorno >> >> No, I did not say /this/ worked (and you're right: it didn't), I >> meant the things you fixed yesterday. I just never became aware of >> this special problem until I gave your patch a hard try ;-) Herbert> here it comes Applied in my tree. JMArc
Re: [PATCH] Re: bibtex parser broken?
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> Juergen Spitzmueller wrote: >> >>> I noticed that the (natbib) citation style choice doesn't use the >>> name of the selected citation anymore (it's always "Caesar et >>> al..."). Herbert> attached a patch Applied in my tree. JMArc
Re: Tooltips revamp
> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes: >> Oops not so easy. I'll need another static signal in Dialogs.h >> static bool SigC::Signal0 Dialogs::tooltipsEnabled; Allan> Why? The tooltips should have a lyxrc entry and you can toggle Allan> based on that value instead. Otherwise someone who wants/hates Allan> tooltips has to turn them on/off in every session! No, because the tooltips are designed to be lengthy, helpful and annoying when you do not need them. So it is reasonable to turn them off by default. BTW, we will need an icon for this toggle, since operating tooltips is a mouse-based thing. JMarc
Re: small fix for gcc-3.0.4
> "Kayvan" == Kayvan A Sylvan <[EMAIL PROTECTED]> writes: Kayvan> lyxsum.C won't compile without this patch: Applied. JMarc
Re: Tooltips revamp
On Sunday 10 March 2002 7:51 am, Allan Rae wrote: > > case LFUN_TOOLTIPS_TOGGLE: > > flag.setOnOff(Tooltips::enabled()); > > break; > > > > Oops not so easy. I'll need another static signal in Dialogs.h > > static bool SigC::Signal0 Dialogs::tooltipsEnabled; > > Why? The tooltips should have a lyxrc entry and you can toggle based > on that value instead. Otherwise someone who wants/hates tooltips has > to turn them on/off in every session! Well maybe there should be a bool enable_tooltips_on_start lyxrc entry, but this should be used to initialise the bool tooltips_enabled variable in the xforms Tooltips class behind the frontends firewall. This can go in as a small mod at any time. So, I disagree with you, at least partially. Anyway, I decided a signal was the wrong way too and used a static method returning a bool. Angus
Re: [PATCH] FormGraphics.C
> "Herbert" == Herbert Voss <[EMAIL PROTECTED]> writes: Herbert> Herbert Voss wrote: >> please appy Herbert> here comes a better one, Applied in my tree JMarc
Re: [PATCH] fix bug 261
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Please apply Applied in my tree. JMarc
Re: [PATCH] Re: bibtex parser broken?
Herbert Voss wrote: > here it comes Works like a charm! Danke, Juergen. > Herbert
Re: [PATCH] Re: bibtex parser broken?
On Mon, 11 Mar 2002, Juergen Spitzmueller wrote:
> Herbert Voss wrote:
> > I'll send the patch tomorrow. You said that this worked
> > in the past. But this is not possible, because the old
> > check worked only well for
> >
> > Theodor W. Adorno
>
> No, I did not say /this/ worked (and you're right: it didn't), I meant
> the things you fixed yesterday.
> I just never became aware of this special problem until I gave your
> patch a hard try ;-)
here it comes
Herbert
Index: src/frontends/controllers/ChangeLog
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/ChangeLog,v
retrieving revision 1.144
diff -u -r1.144 ChangeLog
--- src/frontends/controllers/ChangeLog 2002/03/07 18:59:07 1.144
+++ src/frontends/controllers/ChangeLog 2002/03/11 06:22:58
@@ -1,3 +1,7 @@
+2002-03-11 Herbert Voss <[EMAIL PROTECTED]>
+
+ * biblio.C: fix bug in parseBibtex
+
2002-03-07 Lars Gullik Bjxnnes <[EMAIL PROTECTED]>
* ControlSendto.C (allFormats): fix a iterators are not pointers
Index: src/frontends/controllers/biblio.C
===
RCS file:
/usr/local/lyx/cvsroot/lyx-devel/src/frontends/controllers/biblio.C,v
retrieving revision 1.17
diff -u -r1.17 biblio.C
--- src/frontends/controllers/biblio.C 2002/03/05 17:48:21 1.17
+++ src/frontends/controllers/biblio.C 2002/03/11 06:22:59
@@ -145,8 +145,15 @@
{
// Very simple parser
string fname = name;
-
- string::size_type idx = fname.rfind(".");
+ // possible authorname combinations are:
+ // "Surname, FirstName"
+ // "Surname, F."
+ // "FirstName Surname"
+ // "F. Surname"
+ string::size_type idx = fname.find(",");
+ if (idx != string::npos)
+ return frontStrip(fname.substr(0,idx));
+ idx = fname.rfind(".");
if (idx != string::npos)
fname = frontStrip(fname.substr(idx+1));
