Re: CVS: XFormsView.C:205: no matching function for call to `MiniBuffer::message (int)'
On Wed, Jul 17, 2002 at 03:30:59PM +0900, R. Lahaye wrote: > But, eh, has that not led to an executable with a booby trap in > XFormsView? No. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: One for André
On Wed, Jul 17, 2002 at 08:45:42AM +0200, Juergen Vigna wrote: > You need also some space between enclosing text and inset. I normally > add 2 pixels at each side to the width (see InsetText and/or > InsetTabular). As LaTeX does not add such space when changing into math mode I'd rather don't do it on screen either. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: 1.3.0cvs can't use template lyx files due to version conflict!
R. Lahaye wrote: >iletter.lyx I added this in old 0.12 times and also the supporting iletter.cls, but I think now as I will not support this anymore and so it is unsupported we should just remove this and the tex and template files from the lyx distrib. Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: One for André
Andre Poenitz wrote: > On Tue, Jul 16, 2002 at 06:18:00PM +0100, Angus Leeming wrote: > >>Ok, understood. Since this box is not present in Preview display, I'll remove >>the extras then. > > > Ok. You need also some space between enclosing text and inset. I normally add 2 pixels at each side to the width (see InsetText and/or InsetTabular). Jug -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Mitterstrich 151/A Tel/Fax: +39-0471-450260 / +39-0471-450253 I-39050 SteineggWeb: http://www.lyx.org/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
Re: CVS: XFormsView.C:205: no matching function for call to `MiniBuffer::message (int)'
Andre Poenitz wrote: > > On Wed, Jul 17, 2002 at 03:03:36PM +0900, R. Lahaye wrote: > > You've committed a new XFormsView to CVS. > > Is it due to that commit that CVS does not compile anymore here: > > [Note that you can make it compile by commenting out the offending line] Ok, thanks; compilation successfully completed now. But, eh, has that not led to an executable with a booby trap in XFormsView? Rob.
Re: CVS: XFormsView.C:205: no matching function for call to `MiniBuffer::message (int)'
On Wed, Jul 17, 2002 at 03:03:36PM +0900, R. Lahaye wrote: > You've committed a new XFormsView to CVS. > Is it due to that commit that CVS does not compile anymore here: [Note that you can make it compile by commenting out the offending line] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: xfig graphics
On Wed, Jul 17, 2002 at 07:59:23AM +0200, Andre' Poenitz wrote: > Ah... I just noticed. My 'fig2eps' is not called but rather some > auto-generated script using 'fig2dev -L xpm'. > > How do I tell the converter that I prefer my own script? One step further: If I use a direct conversion script .fig -> .xpm it show up nicely on screen. The LaTeX export, however, still uses the LaTeX-only variant. Not nice... Any ideas? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
CVS: XFormsView.C:205: no matching function for call to `MiniBuffer::message (int)'
John, You've committed a new XFormsView to CVS. Is it due to that commit that CVS does not compile anymore here: source='XFormsView.C' object='XFormsView.lo' libtool=yes depfile='.deps/XFormsView.Plo' tmpdepfile='.deps/XFormsView.TPlo' depmode=gcc /bin/sh ../../../config/depcomp /bin/sh ../../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src/ -I../../../src/frontends/ -I../../../src/frontends/controllers -I../../../boost -isystem /usr/X11R6/include -g -O -Wno-non-template-friend -W -Wall -c -o XFormsView.lo `test -f XFormsView.C || echo './'`XFormsView.C g++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../images -I../../../src/ -I../../../src/frontends/ -I../../../src/frontends/controllers -I../../../boost -isystem /usr/X11R6/include -g -O -Wno-non-template-friend -W -Wall -c XFormsView.C -Wp,-MD,.deps/XFormsView.TPlo XFormsView.C: In method `void XFormsView::update_view_state()': XFormsView.C:205: implicit declaration of function `int currentState(...)' XFormsView.C:205: no matching function for call to `MiniBuffer::message (int)' ../../../src/frontends/MiniBuffer.h:39: candidates are: void MiniBuffer::message(const string &) *** Error code 1 Regards, Rob
Re: xfig graphics
On Wed, Jul 17, 2002 at 07:23:54AM +0200, Andre' Poenitz wrote: > Is there a way to get .fig working "properly" (i.e. with separate LaTeX/PS > export) with 1.3.0cvs? > > If I include a .fig graphics it shows up in LyX and in print as if it were > converted to PS only. Ah... I just noticed. My 'fig2eps' is not called but rather some auto-generated script using 'fig2dev -L xpm'. How do I tell the converter that I prefer my own script? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Font loading messages
On Wed, Jul 17, 2002 at 06:22:11AM +0100, John Levon wrote: > On Wed, Jul 17, 2002 at 06:15:21AM +0100, John Levon wrote: > > Sure. I'm finding various bits of the minibuffer state display rather > > confusing and awkward actually. Some random things : > > o what use is show_sc param to verboseDispatch() ? If it is false, all > it will do is add a ' ', iff there is no dispatch result message. Can I > remove it ? *shrug* Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
1.3.0cvs can't use template lyx files due to version conflict!
Hi, The template lyx files in lib/templates/*lyx can't be used with 1.3.0cvs, due to the version conflict. Some have even very old version numbers. Do these need updating? Here's the list: LyX Version 0.12: iletter.lyx latex8.lyx LyX Version 1.1: aa.lyx kluwer.lyx revtex4.lyx LyX Version 1.2: IEEEtran.lyx aa.lyx aastex.lyx dinbrief.lyx docbook_article.lyx g-brief-de.lyx g-brief-en.lyx hollywood.lyx iletter.lyx kluwer.lyx latex8.lyx letter.lyx linuxdoc_article.lyx revtex.lyx revtex4.lyx slides.lyx Regards, Rob.
xfig graphics
Is there a way to get .fig working "properly" (i.e. with separate LaTeX/PS export) with 1.3.0cvs? If I include a .fig graphics it shows up in LyX and in print as if it were converted to PS only. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Font loading messages
On Wed, Jul 17, 2002 at 06:15:21AM +0100, John Levon wrote: > Sure. I'm finding various bits of the minibuffer state display rather > confusing and awkward actually. Some random things : o what use is show_sc param to verboseDispatch() ? If it is false, all it will do is add a ' ', iff there is no dispatch result message. Can I remove it ? regards john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: Font loading messages
On Wed, Jul 17, 2002 at 06:15:21AM +0100, John Levon wrote: > Sure. I'm finding various bits of the minibuffer state display rather > confusing and awkward actually. Some random things : > > o why is commandshortcut a member of lyxfunc rather than an auto ? > o the string return from ::dispatch seems only used to get the ' ' > added. This should be handled by the frontend instead I think > o miniDispatch can be cleaned away I think > o addSet should be show_cmd_dispatched() or something more readable > and it should be a frontend decision on whether to add it to the > current thing or not or whatever Can't comment on these as I did not have a look. > o we show "at rest" something like "LyX: newfile.lyx (changed)" which > duplicates the titlebar. I'd much prefer the "at rest" display to be > the font mode status etc, especially as this will simplify > implementation I find this rather annoying, too. Mathed currently exposes bits of the structure nesting in the status line (not just the innermost font change, but some other things, too) and I got already used to it so I really don't like it being overwritten after a couple of seconds... So maybe we should have a poll whether this feature can go? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Font loading messages
On Wed, Jul 17, 2002 at 07:01:19AM +0200, Andre Poenitz wrote: > ... but this sounds like a worthy goal. So I would not mind removing the > message, but wait for other opinions. Sure. I'm finding various bits of the minibuffer state display rather confusing and awkward actually. Some random things : o why is commandshortcut a member of lyxfunc rather than an auto ? o the string return from ::dispatch seems only used to get the ' ' added. This should be handled by the frontend instead I think o miniDispatch can be cleaned away I think o addSet should be show_cmd_dispatched() or something more readable and it should be a frontend decision on whether to add it to the current thing or not or whatever o we show "at rest" something like "LyX: newfile.lyx (changed)" which duplicates the titlebar. I'd much prefer the "at rest" display to be the font mode status etc, especially as this will simplify implementation regards john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> I'm using a fairly recent version of ImageMagick (5.4.7). This > R> version's convert produces a color output line > R> " c opaque" > R> which causes a horrible quality in the LyX-View. > > Hmm, I just see that the code in GraphicsImageXPM does: > > // some image magick versions use this > xpm_col[1].name = 0; > xpm_col[1].value = "opaque"; > xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); Uh, the problem seems to be gone with yesterday's cvs update. Don't know what has changed. Leave this problems for what it is. I'll make noise again as soon as the same problem resurfaces with CVS. Regards, Rob.
Re: Font loading messages
On Wed, Jul 17, 2002 at 05:55:57AM +0100, John Levon wrote: > Is font loading really a significant part of a document load time ? I believe so... > If we could remove this message, we can kill a current_view use and > remove messagePush/Pop as well ... but this sounds like a worthy goal. So I would not mind removing the message, but wait for other opinions. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: show_banner Andre ?
On Wed, Jul 17, 2002 at 05:54:27AM +0100, John Levon wrote: > Why not ? (seriously) It eats too many colors. And there are some kind of gimmicks I don't like in general. Looks as banners fall in this category... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Font loading messages
Is font loading really a significant part of a document load time ? If we could remove this message, we can kill a current_view use and remove messagePush/Pop as well thanks john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: show_banner Andre ?
On Wed, Jul 17, 2002 at 06:52:54AM +0200, Andre Poenitz wrote: > I don't want the banner to show up. Why not ? (seriously) john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: show_banner Andre ?
On Wed, Jul 17, 2002 at 05:01:23AM +0100, John Levon wrote: > Why did this get added back ? Because it was still half there and I don't want the banner to show up. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: "Counters" work
On Tue, Jul 16, 2002 at 05:07:23PM +0100, Duncan Simpson wrote: > In my experience if you do not know who has a reference to an object and what > the scope of those references are the code is almost certaintly wrong anyway. > Heavy STL users might not be so lucky but that may be just my prejudice. I > often want a variantion on a structure on an unusual operation to be > particularly fast so end up deciding STL is unsuitable and doing it manually > instead. I think this results in faster and cleaner code in most cases. I usually end up with one hand-made container and 20 std::containers... As I profile my stuff at least for things that are likely to run for a couple of week I don't have the impression that hand-made containers are worth the trouble in general. > Of coure my view might be due to PRG propaganda and PRG are not OO fans. Actually, there are two aspects of OO: Encapsulation and Inheritance. And while I am a big fan of the former I avoid the latter if possible. Now I don't know whether this puts me in the 'OO fan block'. > Yes, I know there is a certain amount of flame bait here. I will evn > add to it by saying that the UML descirption is dangeruous ambiguous and > the use of UML can only obfusciate any problem. Objects sending messages > to each other are very nasty to analyse and UML just about makes it > impossiblke by being vague on some critical points. Be warned that I have > some reasons for the UML deflamation :-) I've seen no flame bait so far... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: "Counters" work
On Tue, Jul 16, 2002 at 10:43:50PM +0300, Martin Vermeer wrote: > > counterList[newc] = new Counter; > > I assume this means the d'tor Counters::~Counters() can go? I did not understand what this was good for anyway. Assuming 'Counter' is a name for a thing, and 'CounterList' a name of a container of such things, the 'containee' should not know about its container and it should be possible to have Counters not stored in a CounterList. The kind of cyclic dependency between two classes is best avoided. If there is indeed such a strong coupling necessary (which I doubt btw), they probably should merged into a single class. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
show_banner Andre ?
Why did this get added back ? regards john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: qt2/xforms/ no longer exists ?
On Wed, Jul 17, 2002 at 11:57:21AM +0900, R. Lahaye wrote: > > qt2/xforms/ no longer exists > > Then please remove corresponding entry from configure.in! You got me ! Thanks. john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
qt2/xforms/ no longer exists ?
John Levon wrote: > qt2/xforms/ no longer exists Then please remove corresponding entry from configure.in! Patch: Index: configure.in === RCS file: /cvs/lyx/lyx-devel/configure.in,v retrieving revision 1.136 diff -u -r1.136 configure.in --- configure.in2002/07/14 01:44:14 1.136 +++ configure.in2002/07/17 02:54:30 @@ -345,7 +345,6 @@ src/frontends/xforms/Makefile \ src/frontends/xforms/forms/Makefile \ src/frontends/qt2/Makefile \ - src/frontends/qt2/xforms/Makefile \ src/frontends/qt2/moc/Makefile \ src/frontends/qt2/ui/Makefile \ src/frontends/qt2/ui/moc/Makefile \ Rob.
LFUN_FONT_STATE
The usual: what's the intended purpose ? john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: compile error with QLImage.C
On Tue, Jul 16, 2002 at 11:08:01PM +0200, geof wrote: > QLImage.C:62: `endl' undeclared (first use this function) Fixed, thanks john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
compile error with QLImage.C
Hi, I had a problem compiling lyx-CVS this night with gcc-3.1 and qt-2 : Error in file QLImage.C. I've just changed endl by "\n". Perhaps putting "using std::endl" also solves the problem? @+ geoffroy /usr/local/gcc-3.1/bin/c++ -DHAVE_CONFIG_H -I. -I. -I../../../src -I../../../src/ -I../../../src/frontends/ -I../../../images -I./qt2 -I/usr/local/qt2/include -I../../../boost -I../../../src/frontends/controllers -isystem /usr/X11R6/include -DQT_CLEAN_NAMESPACE -DQT_GENUINE_STR -O3 -mcpu=750 -W -Wall -Winline -Winline -c QLImage.C -MT QLImage.lo -MD -MP -MF .deps/QLImage.TPlo -fPIC -DPIC QLImage.C: In static member function `static std::vector > grfx::QLImage::loadableFormats()': QLImage.C:62: `endl' undeclared (first use this function) QLImage.C:62: (Each undeclared identifier is reported only once for each function it appears in.) make[5]: *** [QLImage.lo] Error 1 make[5]: Leaving directory `/src/lyx/lyx-devel/src/frontends/qt2' make[4]: *** [all-recursive] Error 1 make[4]: Leaving directory `/src/lyx/lyx-devel/src/frontends/qt2' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/src/lyx/lyx-devel/src/frontends' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/src/lyx/lyx-devel/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/src/lyx/lyx-devel/src' make: *** [all-recursive] Error 1 -- ~ 'v'mailto: gpiroux_at_mac_dot_com // \\ Powered by GNU/Linux-ppc /( )\ http://lfs.linux-provider.net/ #112 ^'^
Re: "Counters" work
> >One more suggestion: naked pointers are evil. Naked pointers in an STL >container are doubly evil. Wrap that pointer in a boost::shared_ptr. Memory >is automatically delete-d as the list goes out of scope. IMHO wasting cycles mainating reference counts when I know the lifetime of an item and who is responsible for calling free or delete (depending on which was used in the frist instance) is even worse than using bare pointers. I would apply the same statement to C++ automagically copying things for me without a good reason to do so. In my experience if you do not know who has a reference to an object and what the scope of those references are the code is almost certaintly wrong anyway. Heavy STL users might not be so lucky but that may be just my prejudice. I often want a variantion on a structure on an unusual operation to be particularly fast so end up deciding STL is unsuitable and doing it manually instead. I think this results in faster and cleaner code in most cases. Of coure my view might be due to PRG propaganda and PRG are not OO fans. PRG, aka the Oxford computer science department, are keen on formal methods and introduced various formal methods, including CSP. Yes, I know there is a certain amount of flame bait here. I will evn add to it by saying that the UML descirption is dangeruous ambiguous and the use of UML can only obfusciate any problem. Objects sending messages to each other are very nasty to analyse and UML just about makes it impossiblke by being vague on some critical points. Be warned that I have some reasons for the UML deflamation :-) -- Duncan (-: "software industry, the: unique industry where selling substandard goods is legal and you can charge extra for fixing the problems."
Re: "Counters" work
On Tue, Jul 16, 2002 at 03:51:05PM +0100, Angus Leeming wrote:
> On Tuesday 16 July 2002 3:58 pm, Andre Poenitz wrote:
> > On Tue, Jul 16, 2002 at 03:29:12PM +0100, Angus Leeming wrote:
> > > One more suggestion: naked pointers are evil. Naked pointers in an STL
> > > container are doubly evil. Wrap that pointer in a boost::shared_ptr.
> > > Memory is automatically delete-d as the list goes out of scope.
> >
> > Why are pointers used anyway? [I did not look at the source, so maybe the
> > question is silly]
>
> You mean you'd prefer to pass around (possibly large) structs? Seems a little
> excessive. Anyway, if you prefer that then this will probably also be fine
> Martin.
>
> ///
> typedef std::map CounterList;
> ///
> CounterList counterList;
>
> counterList[newc] = new Counter;
Did just this (with André's further remarks). Attached.
Let me make this perfectly clear: this just compiles. And looks
beautiful (doesn't it?). And is believed to be politically correct.
Thanks... I'm slowly getting this C++ philosophy :-)
Martin
:wq
Index: counters.C
===
RCS file: /cvs/lyx/lyx-devel/src/counters.C,v
retrieving revision 1.7
diff -u -p -r1.7 counters.C
--- counters.C 2002/03/21 17:25:09 1.7
+++ counters.C 2002/07/16 20:12:35
@@ -17,6 +17,7 @@
#include "counters.h"
#include "debug.h"
+#include "support/lstrings.h"
using std::endl;
@@ -48,7 +49,6 @@ int Counter::value() const
void Counter::step()
{
++value_;
- onstep.emit();
}
@@ -57,15 +57,39 @@ void Counter::reset()
value_ = 0;
}
+string Counter::master() const
+{
+ return master_;
+}
+
+void Counter::setMaster(string const & m)
+{
+ master_ = m;
+}
+
-Counters::~Counters()
+Counters::Counters()
{
- // We need this since we store the Counter's as pointers in
- // the counterList.
- for (CounterList::iterator it = counterList.begin();
-it != counterList.end();
-++it)
- delete it->second;
+ // Ehh, should this take a textclass arg?
+
+ // Sectioning counters:
+ newCounter("part");
+ newCounter("chapter");
+ newCounter("section", "chapter");
+ newCounter("subsection", "section");
+ newCounter("subsubsection", "subsection");
+ newCounter("paragraph", "subsubsection");
+ newCounter("subparagraph", "paragraph");
+
+ // Enumeration counters:
+ newCounter("emumi");
+ newCounter("emumii", "enumi");
+ newCounter("enumiii", "enumii");
+ newCounter("enumiv", "enumiii");
+
+ // Float counters:
+ newCounter("figure");
+ newCounter("table");
}
@@ -73,36 +97,35 @@ void Counters::newCounter(string const &
{
// First check if newc already exist
CounterList::iterator cit = counterList.find(newc);
- // if alrady exist give warning and return
+ // if already exist give warning and return
if (cit != counterList.end()) {
- lyxerr << "The new counter already exist." << endl;
+ lyxerr << "The new counter already exists." << endl;
return;
}
- counterList[newc] = new Counter;
+ counterList[newc];
+ cit->second.setMaster("");
}
-void Counters::newCounter(string const & newc, string const & oldc)
+void Counters::newCounter(string const & newc, string const & masterc)
{
- // First check if newc already exist
+ // First check if newc already exists
CounterList::iterator cit = counterList.find(newc);
// if already existant give warning and return
if (cit != counterList.end()) {
- lyxerr << "The new counter already exist." << endl;
+ lyxerr << "The new counter already exists." << endl;
return;
}
- // then check if oldc exist
- CounterList::iterator it = counterList.find(oldc);
+ // then check if masterc exists
+ CounterList::iterator it = counterList.find(masterc);
// if not give warning and return
if (it == counterList.end()) {
- lyxerr << "The old counter does not exist." << endl;
+ lyxerr << "The master counter does not exist." << endl;
return;
}
- Counter * tmp = new Counter;
- it->second->onstep.connect(SigC::slot(tmp,
- &Counter::reset));
- counterList[newc] = tmp;
+ counterList[newc];
+cit->second.setMaster(masterc);
}
@@ -113,7 +136,7 @@ void Counters::set(string const & ctr, i
lyxerr << "Counter does not exist." << endl;
return;
}
- it->second->set(val);
+ it->second.set(val);
}
@@ -124,7 +147,7 @@ void Counters::addto(string const & ctr,
lyxerr << "Counter does not exist." << endl;
return;
}
-
Re: "Counters" work
On Tue, Jul 16, 2002 at 03:51:05PM +0100, Angus Leeming wrote: > On Tuesday 16 July 2002 3:58 pm, Andre Poenitz wrote: > > On Tue, Jul 16, 2002 at 03:29:12PM +0100, Angus Leeming wrote: > > > One more suggestion: naked pointers are evil. Naked pointers in an STL > > > container are doubly evil. Wrap that pointer in a boost::shared_ptr. > > > Memory is automatically delete-d as the list goes out of scope. > > > > Why are pointers used anyway? [I did not look at the source, so maybe the > > question is silly] > > You mean you'd prefer to pass around (possibly large) structs? Seems a little > excessive. Anyway, if you prefer that then this will probably also be fine > Martin. > > /// > typedef std::map CounterList; > /// > CounterList counterList; > > counterList[newc] = new Counter; I assume this means the d'tor Counters::~Counters() can go? Martin :wq msg41116/pgp0.pgp Description: PGP signature
Re: LyX Qt2 on Native win32 screenshot
> Nobody seems to be actively working on a GTK port as far as I can see... I'm trying too. Honest! :) It was chugging along quite nicely until the GUII stuff from sixpack was commited, then work kinda got crazy. I'm in Michigan now (don't ask, just wonder :/) and was in Nevada last week. I've got plans sketched out for a gtkmm Painter, WorkArea etc., it's just a matter of getting a few days to implement them then a stack more time to fix all the build errors, implement the dialogs etc. Any and all help I can get would be greatly appreciated of course. However I'm trying to do this for my own education, so I don't mind things slowing down for a while. Nothing in the work looks too difficult (though nothing ever does till you try it!). Cheers Koz -- Cheers Koz - This mail sent through IMP: http://horde.org/imp/
Re: LyX Qt2 on native win32 screenshot
On Tue, Jul 16, 2002 at 08:08:34PM +0200, David Kastrup wrote:
> > Nobody seems to be actively working on a GTK port as far as I can
> > see...
>
> Oops. What sort of toolkits are in consideration, then? xforms and
> Qt, obviously. Anything else?
*shrug* None that I know of. Except of course the ncurses version ;-)
But there are other things to do before I spent a thought on that...
Actually, one of the main goals of toolkit independence ('GUII' in
LyX-speak) was to get a cleaner code base by seperation of core and GUI.
Looks as we are there now. Of course, a GTK gui could be added if
somebody cares to write one, but currently seemingly nobody cares...
Andre'
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: LyX Qt2 on native win32 screenshot
On Tuesday 16 July 2002 7:08 pm, David Kastrup wrote: > > Nobody seems to be actively working on a GTK port as far as I can > > see... > > Oops. What sort of toolkits are in consideration, then? xforms and > Qt, obviously. Anything else? There is a gnome port too. Michael Koziarski keeps adding bits, but it's a long way behind the Qt port. Note that "the hard part" of separating LyX's core from the toolkit is now done. Making dialogs, toolbars etc is now little more than using glade and linking up the widgets to some controller. What I'm saying is that a gnome port would take a couple of weeks from a committed coder. Nothing more. Angus
Re: LyX Qt2 on native win32 screenshot
Andre Poenitz <[EMAIL PROTECTED]> writes: > On Tue, Jul 16, 2002 at 07:06:07PM +0200, David Kastrup wrote: > > Strictly speaking, you are on shaky ground here in case that LyX > > comes with any third-party GPLed licenced software. In that case, > > the copyright holders of those software may insist that their stuff > > be not combined and redistributed in one binary with Qt(Windows) or > > xforms or whatever else. > > I think it would be absolutely no problem if there were no > Qt-Windows-binaries available on lyx.org. Not for you. This would only concern potential LyX-Qt-Windows-binary redistributors. > And we certainly can't prevent *cough* people from distributing > precompiled binaries in other places. So it is possible for us to > stay on the safe side. Yes. > > I can't really tell about Qt, but xforms sucks, IMO, in its general > > behavior. I think GTK LyX would be a large improvement, and an > > obviously legally unproblematic candidate for binary redistribution. > > Nobody seems to be actively working on a GTK port as far as I can > see... Oops. What sort of toolkits are in consideration, then? xforms and Qt, obviously. Anything else? -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: One for André
On Tue, Jul 16, 2002 at 06:18:00PM +0100, Angus Leeming wrote: > Ok, understood. Since this box is not present in Preview display, I'll remove > the extras then. Ok. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: One for André
On Tuesday 16 July 2002 6:31 pm, Andre Poenitz wrote: > On Tue, Jul 16, 2002 at 06:06:20PM +0100, Angus Leeming wrote: > > André, > > why do we add 1 to ascent, descent and then remove them when calling the > > painter? > > The pink "active mathed" box? > > > Similarly, why do we arbitrarily remove 2 from the width passed to the > > painter? > > Similarly? Ok, understood. Since this box is not present in Preview display, I'll remove the extras then. Angus
Re: One for André
On Tue, Jul 16, 2002 at 06:06:20PM +0100, Angus Leeming wrote: > André, > why do we add 1 to ascent, descent and then remove them when calling the > painter? The pink "active mathed" box? > Similarly, why do we arbitrarily remove 2 from the width passed to the > painter? Similarly? Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: LyX Qt2 on native win32 screenshot
On Tue, Jul 16, 2002 at 07:06:07PM +0200, David Kastrup wrote: > Strictly speaking, you are on shaky ground here in case that LyX > comes with any third-party GPLed licenced software. In that case, > the copyright holders of those software may insist that their stuff > be not combined and redistributed in one binary with Qt(Windows) or > xforms or whatever else. I think it would be absolutely no problem if there were no Qt-Windows-binaries available on lyx.org. And we certainly can't prevent *cough* people from distributing precompiled binaries in other places. So it is possible for us to stay on the safe side. Whether this is needed or not certainly should be discussed but I see no unsolvable problems... > I can't really tell about Qt, but xforms sucks, IMO, in its general > behavior. I think GTK LyX would be a large improvement, and an > obviously legally unproblematic candidate for binary redistribution. Nobody seems to be actively working on a GTK port as far as I can see... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
One for André
André,
why do we add 1 to ascent, descent and then remove them when calling the
painter?
Similarly, why do we arbitrarily remove 2 from the width passed to the
painter?
Angus
int InsetFormula::ascent(BufferView *, LyXFont const &) const
{
return preview_->usePreview() ?
1 + preview_->pimage_->ascent() : 1 + par_->ascent();
}
int InsetFormula::descent(BufferView *, LyXFont const &) const
{
return preview_->usePreview() ?
1 + preview_->pimage_->descent() : 1 + par_->descent();
}
void InsetFormula::draw(BufferView * bv, LyXFont const & font,
int y, float & xx, bool) const
{
int const w = width(bv, font);
int const d = descent(bv, font);
int const a = ascent(bv, font);
int const h = a + d;
MathPainterInfo pi(bv->painter());
if (use_preview) {
pi.pain.image(x + 1, y - a + 1, w - 2, h - 2,
*(preview_->pimage_->image(*this, *bv)));
Re: Is this the right preview info for LyX?
On Tuesday 16 July 2002 5:53 pm, David Kastrup wrote: > The snippet info outputs the exact dimensions of the TeX box. The > tightpage option adds additional side bearings to that in order to > arrive at the PostScript page size so as not to cut off anything that > might slightly protrude out of the TeX box. So the total size of the > graphics is larger by those side bearings, and the ascent ratio is > also slightly influenced by it. Probably not more than very few > pixels at most, if at all. > > If I call the tp numbers tp1, tp2, tp3, tp4, and the snippet values > ht, dp, wd, then we have, strictly speaking, > > ascent = max(0,ht,-dp)+tp4 > descent = max(0,-ht,dp)-tp2 > > The tightpage dimensions can be modified by the user; in that case, > before the next snippet, the changed values will be printed out in a > new Tightpage line (the separate prlyx.def that you have had in your > hands before printed out the tightpage info itself, and just once at > the start of the document. Which should not make a difference, as I > don't think anybody ever fiddled with those settings, least of all in > mid-document). Thanks for the clear explanation. I'll modify the shell script so: grep -E 'Preview: [S-T]' 1lyxpreview.log > 1lyxpreview.metrics and use this .metrics file to perform the calculation within LyX. cat 1lyxpreview.metrics Preview: Tightpage -32890 -32890 32890 32890 Preview: Snippet 1 492688 0 744653 Preview: Snippet 2 1441792 163840 16026923 Preview: Snippet 3 282168 0 377591 Preview: Snippet 4 1619363 449545 16026923 If the Tightpage changes, then Ihat will be accommodated automatically. Angus
Re: LyX Qt2 on native win32 screenshot
John Levon <[EMAIL PROTECTED]> writes: > On Tue, Jul 16, 2002 at 02:26:01PM +0200, Moritz Moeller-Herrmann wrote: > > > But I don't think you are allowed to distribute binaries of your > > QT-Windows lyx. QT(Windows) is not GPL compatible. > > We can extend our xforms exception to Qt too possibly. Strictly speaking, you are on shaky ground here in case that LyX comes with any third-party GPLed licenced software. In that case, the copyright holders of those software may insist that their stuff be not combined and redistributed in one binary with Qt(Windows) or xforms or whatever else. Whether this would hold in court is a different matter. > Btw, Matthias Ettrich made a vague offer of a free development > license for Qt/Windows for an aspiring hacker. It might be worth > contacting him so we're not stuck on Qt 2.3 forever I can't really tell about Qt, but xforms sucks, IMO, in its general behavior. I think GTK LyX would be a large improvement, and an obviously legally unproblematic candidate for binary redistribution. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: LyX Qt2 on native win32 screenshot
On Tue, Jul 16, 2002 at 02:26:01PM +0200, Moritz Moeller-Herrmann wrote: > But I don't think you are allowed to distribute binaries of your QT-Windows > lyx. QT(Windows) is not GPL compatible. We can extend our xforms exception to Qt too possibly. Btw, Matthias Ettrich made a vague offer of a free development license for Qt/Windows for an aspiring hacker. It might be worth contacting him so we're not stuck on Qt 2.3 forever regards john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: Is this the right preview info for LyX?
Angus Leeming <[EMAIL PROTECTED]> writes: > I installed the cvs version of preview.sty et al. without any problems. > Running latex on a "snippet" file and then grepping the resultant log file > shows: > > aleem@pneumon:tmp-> grep review 1lyxpreview.log > **1lyxpreview.tex > (1lyxpreview.tex > ))) (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/preview.sty > Package: preview 2002/07/15 preview-latex CVS-1.59 > (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/prtightpage.def > \PreviewBorder=\dimen106 > ) (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/prlyx.def) > (/usr/local/ > teTeX/share/texmf/tex/latex/preview-latex/prshowlabels.def > No file 1lyxpreview.aux. > Preview: Fontsize 10pt > Preview: Tightpage -32890 -32890 32890 32890 > Preview: Snippet 1 492688 0 744653 > Preview: Snippet 2 1441792 163840 16026923 > Preview: Snippet 3 282168 0 377591 > Preview: Snippet 4 1619363 449545 16026923 > Output written on 1lyxpreview.dvi (4 pages, 1744 bytes). > > So, I'd say that all is fine. > > I don't follow your Tightpage description and certainly haven't used > it to date. The snippet info outputs the exact dimensions of the TeX box. The tightpage option adds additional side bearings to that in order to arrive at the PostScript page size so as not to cut off anything that might slightly protrude out of the TeX box. So the total size of the graphics is larger by those side bearings, and the ascent ratio is also slightly influenced by it. Probably not more than very few pixels at most, if at all. If I call the tp numbers tp1, tp2, tp3, tp4, and the snippet values ht, dp, wd, then we have, strictly speaking, ascent = max(0,ht,-dp)+tp4 descent = max(0,-ht,dp)-tp2 The tightpage dimensions can be modified by the user; in that case, before the next snippet, the changed values will be printed out in a new Tightpage line (the separate prlyx.def that you have had in your hands before printed out the tightpage info itself, and just once at the start of the document. Which should not make a difference, as I don't think anybody ever fiddled with those settings, least of all in mid-document). > ps, If you're planning on releasing preview-latex 0.73 in the next > week or so, then that 's great. It will quite probably not be possible this week, but certainly the next one. We have some documentation issues to sort out, and I have some other stuff (like native XEmacs/Windows support instead of Cygwin) that we want to have basically tested. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum Email: [EMAIL PROTECTED]
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tue, Jul 16, 2002 at 03:32:35PM +0100, Angus Leeming wrote: > If you can think of a more elegant solution, then I'm all ears. > Angus I've already suggested a XGraphicsImage class which GraphicsImageXPM and xformsImage derive from ... then case to XGraphicsImage regards john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tue, Jul 16, 2002 at 01:36:44PM +0200, Jean-Marc Lasgouttes wrote: > xpm_col[1].value = "opaque"; > xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); > > Shouldn't that be LColor::black? John, why did you choose white > instead of black? Hmm, because it's going to get printed on white paper no ? I'm not bothered either way john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
Re: Is this the right preview info for LyX?
On Monday 15 July 2002 11:54 pm, David Kastrup wrote: > Angus Leeming <[EMAIL PROTECTED]> writes: > > On Sunday 14 July 2002 1:13 am, David Kastrup wrote: > > > Could you adjust your local copy of prlyx.def (and, more importantly, > > > the scripts that evaluate its output) so that it will not finish the > > > lines with a period? > > > > > > I'll probably commit to CVS tomorrow, have to do a bit of testing > > > before. > > > > When you do so, could you post the new copy here. It's better to > > have /exactly/ the same file to work with when developing a parser > > for it. > > Yes, it would. Unfortunately, it is not that easy. > > > I'll probably add prlyx.def to the LyX repository until you formally > > release the next version of preview.sty. Thereafter I'll strike it > > off again. > > The problem is that the output that is now generated by your copy of > prlyx.def is in the new preview.dtx version generated both by a > changed tightpage option as well as the lyx option. So you would > need to distribute also a changed tightpage option. Unless you are > not really looking at the Tightpage info, because you either > disregard it in ascender/image size calculations, or you just take > its default values of 0.5 PostScript points as additional borders in > the image beyond those specified by the TeX dimensions into account. > > Ugly. I'll try to get the next release out this week to cut off the > need for separate distribution. It would be nice if you told me > whether the stuff generated from the current CVS version (you can just > unpack it as described in README.preview, ignoring the > autoconf/configure/Makefile stuff) does the trick for you before I > release it. > > Thanks, David, I installed the cvs version of preview.sty et al. without any problems. Running latex on a "snippet" file and then grepping the resultant log file shows: aleem@pneumon:tmp-> grep review 1lyxpreview.log **1lyxpreview.tex (1lyxpreview.tex ))) (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/preview.sty Package: preview 2002/07/15 preview-latex CVS-1.59 (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/prtightpage.def \PreviewBorder=\dimen106 ) (/usr/local/teTeX/share/texmf/tex/latex/preview-latex/prlyx.def) (/usr/local/ teTeX/share/texmf/tex/latex/preview-latex/prshowlabels.def No file 1lyxpreview.aux. Preview: Fontsize 10pt Preview: Tightpage -32890 -32890 32890 32890 Preview: Snippet 1 492688 0 744653 Preview: Snippet 2 1441792 163840 16026923 Preview: Snippet 3 282168 0 377591 Preview: Snippet 4 1619363 449545 16026923 Output written on 1lyxpreview.dvi (4 pages, 1744 bytes). So, I'd say that all is fine. I don't follow your Tightpage description and certainly haven't used it to date. FYI, I simply take the ratio af=ascent/ (ascent + descent), where ascent is the first number following Snippet X and descent is the number following it. So: Preview: Snippet 1 af=1 Preview: Snippet 2 af=0.89795918367 Preview: Snippet 3 af=1 Preview: Snippet 4 af=0.78271387611 I calculate ascent and descent info as: ascent = af * image->getHeight(); descent = image->getHeight() - ascent; where image->getHeight() returns the height of the image in the PPM file. How would I use the Tightpage info in this prescription? Angus ps, If you're planning on releasing preview-latex 0.73 in the next week or so, then that 's great.
Re: "Counters" work
On Tue, Jul 16, 2002 at 04:11:50PM +0100, Angus Leeming wrote: > > How large is '(possibly large)'? > > Angus looks at the source... (perhaps André could too ;-)... Oh well... I looked, you know... > Ok, not large. A counter contains an int. Not exactly '(possibly large)', no? ;-) > > And yes, I prefer things over pointers to things if that's not too > > expensive... > > > counterList[newc] = new Counter; > > counterList[newc] = Counter(); > > No? > > This probably qualifies for a call of smart-arse ;-) Because the assigment is superflous since the result is identical to counterList[newc]; ? [The item in the map gets created when operator[] is used...] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 4:31 pm, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Good idea, actually. John, since you broke it would you like to > Angus> fix it? A > > Another thought: didn't you write that ImageXPM will go away before > 1.3.0? In this case, your patch may just be good enough... How much noise has the xforms list been making at your end? Here it's been nearly deadly silent. The fact that I don't even receive acknowledgement when I submit a small and safe patch doesn't endear me to the bloody thing.
Re: "Counters" work
On Tuesday 16 July 2002 4:22 pm, Andre Poenitz wrote: > On Tue, Jul 16, 2002 at 03:51:05PM +0100, Angus Leeming wrote: > > You mean you'd prefer to pass around (possibly large) structs? Seems a > > little excessive. Anyway, if you prefer that then this will probably also > > be fine Martin. > > How large is '(possibly large)'? Angus looks at the source... (perhaps André could too ;-)... Ok, not large. A counter contains an int. > And yes, I prefer things over pointers to things if that's not too > expensive... > > counterList[newc] = new Counter; > counterList[newc] = Counter(); > No? This probably qualifies for a call of smart-arse ;-)
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Good idea, actually. John, since you broke it would you like to Angus> fix it? A Another thought: didn't you write that ImageXPM will go away before 1.3.0? In this case, your patch may just be good enough... JMarc
Re: "Counters" work
On Tue, Jul 16, 2002 at 03:51:05PM +0100, Angus Leeming wrote: > You mean you'd prefer to pass around (possibly large) structs? Seems a little > excessive. Anyway, if you prefer that then this will probably also be fine > Martin. How large is '(possibly large)'? And yes, I prefer things over pointers to things if that's not too expensive... Andre' PS: > /// > typedef std::map CounterList; > /// > CounterList counterList; > > counterList[newc] = new Counter; counterList[newc] = Counter(); No? -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 4:14 pm, Jean-Marc Lasgouttes wrote: > > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: > > Angus> Because John and Qt don't have a Pixmap getPixmap() method. > Angus> Apparently Pixmaps are X-specific and that's a limitation they > Angus> can do without. > > Angus> If you can think of a more elegant solution, then I'm all ears. > > Have a XImage class which derives from Image and have ImageXPM and > xformsImage derive from it? More code, but less #ifdef. > > JMarc Good idea, actually. John, since you broke it would you like to fix it? A
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Because John and Qt don't have a Pixmap getPixmap() method. Angus> Apparently Pixmaps are X-specific and that's a limitation they Angus> can do without. Angus> If you can think of a more elegant solution, then I'm all ears. Have a XImage class which derives from Image and have ImageXPM and xformsImage derive from it? More code, but less #ifdef. JMarc
Re: "Counters" work
On Tuesday 16 July 2002 3:58 pm, Andre Poenitz wrote: > On Tue, Jul 16, 2002 at 03:29:12PM +0100, Angus Leeming wrote: > > One more suggestion: naked pointers are evil. Naked pointers in an STL > > container are doubly evil. Wrap that pointer in a boost::shared_ptr. > > Memory is automatically delete-d as the list goes out of scope. > > Why are pointers used anyway? [I did not look at the source, so maybe the > question is silly] You mean you'd prefer to pass around (possibly large) structs? Seems a little excessive. Anyway, if you prefer that then this will probably also be fine Martin. /// typedef std::map CounterList; /// CounterList counterList; counterList[newc] = new Counter;
Re: "Counters" work
On Tue, Jul 16, 2002 at 03:29:12PM +0100, Angus Leeming wrote: > One more suggestion: naked pointers are evil. Naked pointers in an STL > container are doubly evil. Wrap that pointer in a boost::shared_ptr. Memory > is automatically delete-d as the list goes out of scope. Why are pointers used anyway? [I did not look at the source, so maybe the question is silly] Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 3:50 pm, Jean-Marc Lasgouttes wrote:
> > "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes:
>
> Angus> On Tuesday 16 July 2002 3:26 pm, R. Lahaye wrote:
> >> Jean-Marc Lasgouttes wrote: > > "R" == R Lahaye
> >>
> >> <[EMAIL PROTECTED]> writes:
> >> > R> I would test that right away, but GraphicsImageXPM.C is badly
> >> > R> broken in CVS right now. Please fix that first:
> >> >
> >> > Try the following patch.
> >> >
> >> > grxpm.patchName: grxpm.patch > Type: text/x-patch
> >>
> >> Nope. Get a little further though, but now it breaks at:
> >>
> >> ): undefined reference to `grfx::xformsImage::getPixmap(void)
> >> const' ***
>
> Angus> Well that's just nasty of it. The reason it does this is
> Angus> because of a static_cast in xforms/XPainter.C.
>
> Can you enlighten me on why the cast to xformsImage is needed at all?
>
> JMarc
Because John and Qt don't have a Pixmap getPixmap() method. Apparently
Pixmaps are X-specific and that's a limitation they can do without.
If you can think of a more elegant solution, then I'm all ears.
Angus
Here's the QT Painter code:
class QLImage : public Image
{
public:
QPixmap const & qpixmap() const { return xformed_pixmap_; }
};
Painter & QLPainter::image(int x, int y,
int w, int h,
grfx::Image const & i)
{
qp_->drawPixmap(x, y, static_cast(i).qpixmap(), 0, 0,
w, h);
return *this;
}
Re: "Counters" work
On Tuesday 16 July 2002 12:48 pm, Martin Vermeer wrote:
> On Mon, Jul 15, 2002 at 05:57:01PM +0100, Angus Leeming wrote:
>
> ...
>
> > Do you really need to make char Counters::hebrewCounter(int n) a class
> > method? It doesn't use any class variables.
> >
> > I'd suggest, in the .C file only:
> >
> > namespace {
> >
> > char Counters::hebrewCounter(int n)
> > {
> > ...
> > }
> >
> > } // namespace anon
> >
> > Ditto for other, similar helper functions. Keep the header file minimal.
> >
> > Angus
>
> Did this. Diff attached.
>
> Martin
One more suggestion: naked pointers are evil. Naked pointers in an STL
container are doubly evil. Wrap that pointer in a boost::shared_ptr. Memory
is automatically delete-d as the list goes out of scope.
There are /lots/ of examples in the code base. Something like this:
class Counter {
///
typedef std::map > CounterList;
///
CounterList counterList;
}
@@ -73,36 +108,35 @@ void Counters::newCounter(string const &
{
// First check if newc already exist
CounterList::iterator cit = counterList.find(newc);
- // if alrady exist give warning and return
+ // if already exist give warning and return
if (cit != counterList.end()) {
- lyxerr << "The new counter already exist." << endl;
+ lyxerr << "The new counter already exists." << endl;
return;
}
counterList[newc] = boost::shared_ptr(new Counter());
+ cit->second->setMaster("");
Why don't you move on and try and use it ;-)
Angus
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> On Tuesday 16 July 2002 3:26 pm, R. Lahaye wrote: >> Jean-Marc Lasgouttes wrote: > > "R" == R Lahaye >> <[EMAIL PROTECTED]> writes: >> > >> > R> I would test that right away, but GraphicsImageXPM.C is badly >> > R> broken in CVS right now. Please fix that first: >> > >> > Try the following patch. >> > >> > grxpm.patchName: grxpm.patch > Type: text/x-patch >> >> Nope. Get a little further though, but now it breaks at: >> >> ): undefined reference to `grfx::xformsImage::getPixmap(void) >> const' *** Angus> Well that's just nasty of it. The reason it does this is Angus> because of a static_cast in xforms/XPainter.C. Can you enlighten me on why the cast to xformsImage is needed at all? JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
On Tuesday 16 July 2002 3:26 pm, R. Lahaye wrote:
> Jean-Marc Lasgouttes wrote:
> > > "R" == R Lahaye <[EMAIL PROTECTED]> writes:
> >
> > R> I would test that right away, but GraphicsImageXPM.C is badly
> > R> broken in CVS right now. Please fix that first:
> >
> > Try the following patch.
> >
> >grxpm.patchName: grxpm.patch
> > Type: text/x-patch
>
> Nope. Get a little further though, but now it breaks at:
>
>): undefined reference to `grfx::xformsImage::getPixmap(void) const' ***
Well that's just nasty of it. The reason it does this is because of a
static_cast in xforms/XPainter.C.
try this.
A
Index: src/frontends/xforms/XPainter.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/XPainter.C,v
retrieving revision 1.9
diff -u -p -r1.9 XPainter.C
--- src/frontends/xforms/XPainter.C 15 Jul 2002 17:17:56 - 1.9
+++ src/frontends/xforms/XPainter.C 16 Jul 2002 14:43:12 -
@@ -23,7 +23,11 @@
#include "encoding.h"
#include "language.h"
+#ifdef USE_XFORMS_IMAGE_LOADER
#include "xformsImage.h"
+#else
+#include "graphics/GraphicsImageXPM.h"
+#endif
#include "support/LAssert.h"
#include "support/lstrings.h"
@@ -152,7 +156,12 @@ Painter & XPainter::image(int x, int y,
int w, int h,
grfx::Image const & i)
{
+#ifdef USE_XFORMS_IMAGE_LOADER
grfx::xformsImage const & image = static_cast(i);
+#else
+ grfx::ImageXPM const & image = static_cast(i);
+#endif
+
XGCValues val;
val.function = GXcopy;
GC gc = XCreateGC(fl_get_display(), owner_.getPixmap(),
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> I would test that right away, but GraphicsImageXPM.C is badly > R> broken in CVS right now. Please fix that first: > > Try the following patch. > >grxpm.patchName: grxpm.patch > Type: text/x-patch Nope. Get a little further though, but now it breaks at: [...] g++ -g -O -Wno-non-template-friend -W -Wall -o lyx BufferView.o BufferView2.o BufferView_pimpl.o Bullet.o Chktex.o CutAndPaste.o DepTable.o FloatList.o Floating.o FuncStatus.o LColor.o LaTeX.o LaTeXFeatures.o LyXAction.o MenuBackend.o ParagraphParameters.o Spacing.o TextCache.o Thesaurus.o ToolbarDefaults.o box.o buffer.o bufferlist.o bufferparams.o bufferview_funcs.o chset.o converter.o debug.o encoding.o exporter.o gettext.o importer.o intl.o iterators.o kbmap.o kbsequence.o language.o lastfiles.o lengthcommon.o lyx_cb.o lyx_main.o lyx_sty.o lyxcursor.o lyxfont.o lyxfind.o lyxfunc.o lyxgluelength.o lyxlayout.o lyxlength.o lyxlex.o lyxlex_pimpl.o lyxrc.o lyxrow.o lyxserver.o lyxtextclass.o lyxtextclasslist.o lyxvc.o main.o paragraph.o paragraph_pimpl.o sp_spell.o tabular.o tabular-old.o tabular_funcs.o tex-accent.o tex-strings.o texrow.o text.o text2.o trans.o trans_mgr.o undo.o undo_funcs.o vc-backend.o version.o vspace.o mathed/.libs/libmathed.a insets/.libs/libinsets.a frontends/.libs/libfrontends.a -lforms graphics/.libs/libgraphics.a support/.libs/libsupport.a ../boost/libs/regex/src/.libs/libboostregex.a ../boost/libs/signals/src/.libs/libboostsignals.a ../intl/libintl.a -lXpm -lSM -lICE -lc -lm -L/usr/X11R6/lib -lX11 frontends/.libs/libfrontends.a(XPainter.o): In function `XPainter::image(int, int, int, int, grfx::Image const &)': /home/lahaye/SOFTWARE/lyx-devel/src/frontends/xforms/XPainter.C(.text+0x42c): undefined reference to `grfx::xformsImage::getPixmap(void) const' *** Error code 1 Regards, Rob.
Re: lyx-devel src/frontends/qt2/: ChangeLog QLImage.C QLImage.h TO ...
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> On Monday 15 July 2002 6:48 pm, John Levon wrote: >> On Mon, Jul 15, 2002 at 06:22:50PM +0100, Angus Leeming wrote: > > >> Ugh, how do I fix that ? >> > >> > The same way as you fixed xformsImage.[Ch]. >> >> But I static_cast to xformsImage const & Angus> So static_cast to ImageXPM or whatever the class is called. I'll commit an (untested) fix soon. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Also have a look at the warnings that autogen.sh produce; it's in R> an earlier message of mine: R> http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg40925.html I've seen and fixed it. I have removed a couple warnings in my tree. Concerning the autoconf 2.53 warnings, I plan to have a go at that soon. JMarc
Re: lyx-devel src/frontends/qt2/: ChangeLog QLImage.C QLImage.h TO ...
On Monday 15 July 2002 6:48 pm, John Levon wrote: > On Mon, Jul 15, 2002 at 06:22:50PM +0100, Angus Leeming wrote: > > > Ugh, how do I fix that ? > > > > The same way as you fixed xformsImage.[Ch]. > > But I static_cast to xformsImage const & So static_cast to ImageXPM or whatever the class is called. Angus
Re: LyX Qt2 on native win32 screenshot
> But I don't think you are allowed to distribute binaries of your QT-Windows > lyx. QT(Windows) is not GPL compatible. Very true! However, Trolltech suggests that the GPL license has the option for an expection on the linkage to non-system libraries with a different license. This exception has to be provided by the copyright holder (Matthias Ettrich?). See: http://www.trolltech.com/developer/download/qt-win-noncomm.html So, if I eventually manage to get everything to work, this issue definitely has to be solved. > It would probably be better to do a QT-cygwin port with a rootless Xserver > on Windows. I don't agree. I've looked into this option, but: * there's no such thing as a free rootless Xserver on windows; libw11 is far from complete. * a lot of overhead is introduced. * native win32 qt is much fancier. * there's no advantage over the current xforms port besides maybe the looks. * Claus Hentschel & me where already moving towards a mingw port, instead of cygwin. In the ideal world, one would need a gcc compiled qt lib for windows, preferably in cygwin and mingw flavours, with a GPL license. Alas If you want to compile lyx under cygwin with qt, just grab qt from the kde-cygwin project. This works 'out-of-the-box'. Ruurd
Re: patches: make lyx 1.2.0 work for Turkish again
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: Jean-Marc> I'd appreciate comments on this patch (and testing). I plan Jean-Marc> to apply it to 1.2.1, and apply something cleaner (if Jean-Marc> possible; ideas are welcome) to 1.3.0cvs. I applied it to 1.2.x branch and will do the same for trunk tonight. JMarc
Re: FileInfo.[Ch], Part II
On Tue, Jul 16, 2002 at 02:55:43PM +0200, Jean-Marc Lasgouttes wrote:
> - Alert::err_alert(_("Warning! Couldn't open directory."),
> - directory_);
> + Alert::err_alert(_("Warning! Couldn't open directory."), directory_);
>
> Why do you want lines to be more than 80 chars wide?
Unintentional.
Andre'
PS: It's 72 chars (70 non-tabs + 2 tabs). But we should care for
big-tabbies...
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
Re: FileInfo.[Ch], Part II
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes:
Andre> Attached
Looks good, except this part:
- Alert::err_alert(_("Warning! Couldn't open directory."),
-directory_);
+ Alert::err_alert(_("Warning! Couldn't open directory."), directory_);
Why do you want lines to be more than 80 chars wide?
JMarc
FileInfo.[Ch], Part II
Attached
--
Those who desire to give up Freedom in order to gain Security,
will not have, nor do they deserve, either one. (T. Jefferson)
? t
? frontends/qt2/xforms/Makefile.in
? frontends/xforms/.FormFiledialog.C.swp
? mathed/.math_metricsinfo.h.swp
? mathed/.math_metricsinfo.C.swp
? mathed/.math_cursor.C.swp
? support/t
Index: frontends/xforms/FormFiledialog.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/frontends/xforms/FormFiledialog.C,v
retrieving revision 1.26
diff -u -p -r1.26 FormFiledialog.C
--- frontends/xforms/FormFiledialog.C 16 Jul 2002 08:31:21 - 1.26
+++ frontends/xforms/FormFiledialog.C 16 Jul 2002 11:37:15 -
@@ -13,7 +13,6 @@
#include
#include
#include
-//#include
#include
#include
@@ -187,8 +186,7 @@ void FileDialog::Private::Reread()
// Opens directory
DIR * dir = ::opendir(directory_.c_str());
if (!dir) {
- Alert::err_alert(_("Warning! Couldn't open directory."),
-directory_);
+ Alert::err_alert(_("Warning! Couldn't open directory."), directory_);
directory_ = lyx::getcwd();
dir = ::opendir(directory_.c_str());
}
@@ -204,13 +202,13 @@ void FileDialog::Private::Reread()
// Splits complete directory name into directories and compute depth
depth_ = 0;
string line, Temp;
- char szMode[15];
+ string mode;
string File = directory_;
if (File != "/") {
File = split(File, Temp, '/');
}
while (!File.empty() || !Temp.empty()) {
- string dline = "@b"+line + Temp + '/';
+ string dline = "@b" + line + Temp + '/';
fl_add_browser_line(file_dlg_form_->List, dline.c_str());
File = split(File, Temp, '/');
line += ' ';
@@ -220,16 +218,16 @@ void FileDialog::Private::Reread()
// Parses all entries of the given subdirectory
time_t curTime = time(0);
rewinddir(dir);
- while (dirent * pDirEntry = readdir(dir)) {
+ while (dirent * entry = readdir(dir)) {
bool isLink = false, isDir = false;
// If the pattern doesn't start with a dot, skip hidden files
if (!mask_.empty() && mask_[0] != '.' &&
- pDirEntry->d_name[0] == '.')
+ entry->d_name[0] == '.')
continue;
// Gets filename
- string fname = pDirEntry->d_name;
+ string fname = entry->d_name;
// Under all circumstances, "." and ".." are not wanted
if (fname == "." || fname == "..")
@@ -244,10 +242,10 @@ void FileDialog::Private::Reread()
if (!fileInfo.isOK())
continue;
- fileInfo.modeString(szMode);
- unsigned int nlink = fileInfo.getNumberOfLinks();
- string user = lyxUserCache.find(fileInfo.getUid());
- string group = lyxGroupCache.find(fileInfo.getGid());
+ mode = fileInfo.modeString();
+ unsigned int const nlink = fileInfo.getNumberOfLinks();
+ string const user = lyxUserCache.find(fileInfo.getUid());
+ string const group = lyxGroupCache.find(fileInfo.getGid());
time_t modtime = fileInfo.getModificationTime();
string Time = ctime(&modtime);
@@ -265,21 +263,22 @@ void FileDialog::Private::Reread()
Time.erase(16, string::npos);
}
- string Buffer = string(szMode) + ' ' +
+ string buffer = mode + ' ' +
tostr(nlink) + ' ' +
user + ' ' +
group + ' ' +
Time.substr(4, string::npos) + ' ';
- Buffer += pDirEntry->d_name;
- Buffer += fileInfo.typeIndicator();
+ buffer += entry->d_name;
+ buffer += fileInfo.typeIndicator();
- if ((isLink = fileInfo.isLink())) {
+ isLink = fileInfo.isLink();
+ if (isLink) {
string Link;
if (LyXReadLink(File, Link)) {
- Buffer += " -> ";
- Buffer += Link;
+ buffer += " -> ";
+ buffer += Link;
// This gives the FileType of the file that
// is really pointed too after resolving all
@@ -289,7 +288,7 @@ void FileDialog::Private::Reread()
// JV 199902
fileInfo.newFile(File);
if (fileInfo.isOK())
- Buffer
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Argh, no I can't. The machine where I have FreeBSD 4.6 + latest R> ImageMagick (thus that opaque problem), does not compile 1.2.x. The R> reason is not that clear to me, but there seem to be a problem in R> src/config with HAVE_UNISTD_H and defining pid_t, off_t and mode_t. R> These redefinitions jam my make. I have no idea how to solve this, R> so I gave up on 1.2.x .. Aha! This is a problem with autoconf 2.5x that I know about, but do not see. Can you send me the relevant config.log? R> For some obscure reason, this is going well in 1.3.0cvs. Obscure is the right word in this case, indeed. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes:
R> I would test that right away, but GraphicsImageXPM.C is badly
R> broken in CVS right now. Please fix that first:
Try the following patch.
JMarc
Index: src/graphics/ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/ChangeLog,v
retrieving revision 1.95
diff -u -p -r1.95 ChangeLog
--- src/graphics/ChangeLog 15 Jul 2002 17:17:56 - 1.95
+++ src/graphics/ChangeLog 16 Jul 2002 12:29:45 -
@@ -1,3 +1,8 @@
+2002-07-16 Jean-Marc Lasgouttes <[EMAIL PROTECTED]>
+
+ * GraphicsImageXPM.C (isDrawable): implement
+ (setPixmap): the opaque color is black, not white
+
2002-07-15 John Levon <[EMAIL PROTECTED]>
* GraphicsImage.h: remove getPixmap/X, add isDrawable()
@@ -272,6 +277,7 @@
pretty temperamemtal at the moment.
2002-04-16 Rob Lahaye <[EMAIL PROTECTED]>
+
* GraphicsImageXPM.C: fix clipping for boundingbox y-coordinates
2002-04-08 Angus Leeming <[EMAIL PROTECTED]>
Index: src/graphics/GraphicsImageXPM.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/GraphicsImageXPM.C,v
retrieving revision 1.25
diff -u -p -r1.25 GraphicsImageXPM.C
--- src/graphics/GraphicsImageXPM.C 15 Jul 2002 10:19:45 - 1.25
+++ src/graphics/GraphicsImageXPM.C 16 Jul 2002 12:29:45 -
@@ -95,6 +95,12 @@ unsigned int ImageXPM::getHeight() const
}
+bool ImageXPM::isDrawable() const
+{
+ return pixmap_;
+}
+
+
Pixmap ImageXPM::getPixmap() const
{
if (!pixmap_status_ == PIXMAP_SUCCESS)
@@ -207,7 +213,7 @@ bool ImageXPM::setPixmap(Params const &
// some image magick versions use this
xpm_col[1].name = 0;
xpm_col[1].value = "opaque";
- xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white);
+ xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::black);
attrib.numsymbols = 2;
attrib.colorsymbols = xpm_col;
Index: src/graphics/GraphicsImageXPM.h
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/graphics/GraphicsImageXPM.h,v
retrieving revision 1.5
diff -u -p -r1.5 GraphicsImageXPM.h
--- src/graphics/GraphicsImageXPM.h 15 Jul 2002 10:19:45 - 1.5
+++ src/graphics/GraphicsImageXPM.h 16 Jul 2002 12:29:45 -
@@ -48,6 +48,8 @@ public:
/// Get the image height
unsigned int getHeight() const;
+ bool isDrawable() const;
+
/** Load the image file into memory.
* In this case (ImageXPM), the process is blocking.
*/
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> Jean-Marc Lasgouttes wrote: > >> > >> > >> Hmm, I just see that the code in GraphicsImageXPM does: > >> > >> // some image magick versions use this xpm_col[1].name = 0; > >> xpm_col[1].value = "opaque"; xpm_col[1].pixel = > >> lyxColorHandler->colorPixel(LColor::white); > >> > >> Shouldn't that be LColor::black? John, why did you choose white > >> instead of black? > > R> I would test that right away, but GraphicsImageXPM.C is badly > R> broken in CVS right now. Please fix that first: > > I'll try to do it. In the meantime, could you try that on 1.2.1cvs? Argh, no I can't. The machine where I have FreeBSD 4.6 + latest ImageMagick (thus that opaque problem), does not compile 1.2.x. The reason is not that clear to me, but there seem to be a problem in src/config with HAVE_UNISTD_H and defining pid_t, off_t and mode_t. These redefinitions jam my make. I have no idea how to solve this, so I gave up on 1.2.x .. For some obscure reason, this is going well in 1.3.0cvs. If you have clue, let me know. Otherwise, I'll wait till the fix in 1.3.0 for GraphicsImageXPM.C. Thanks, Rob.
Re: LyX Qt2 on native win32 screenshot
Ruurd A. Reitsma wrote: > Hi, > > just to show you all that I'm quite content with the Qt2 frontend nearing > completion, here's a screenshot of 1.3.0 cvs on win32: > > http://www.xs4all.nl/~ps28/ruurd/lyx_win32.png > > It has been built using qt 2.3.0 non-commercial for windows, M$ Visual > Studio, the intel 6.0 compiler and stlport. A patch will follow shortly. Congratulations. I am looking forward to QT lyx. I think I am gonna compile CVS soon But I don't think you are allowed to distribute binaries of your QT-Windows lyx. QT(Windows) is not GPL compatible. It would probably be better to do a QT-cygwin port with a rootless Xserver on Windows.
Re: patches: make lyx 1.2.0 work for Turkish again
> "Togan" == Togan Muftuoglu <[EMAIL PROTECTED]> writes: Togan> * Jean-Marc Lasgouttes; <[EMAIL PROTECTED]> on 16 Jul, Togan> 2002 wrote: >> Andre> Looks straight forward, doesn't it? >> Mostly, except that in some cases we want case changing to respect >> the locale (search&replace). Also, I'd like some turkish locale >> users to try it out and check that it does what I think it does. >> Togan> Well to be honest I am using the Lyx version that Mike Fabian Togan> packaged as an RPM with his patch. You are forgiven :) Togan> I am willing to try the patch(es) as sonn as I can rebuild my Togan> chrooted buildsytem ( currently the DVD is not obeying my Togan> orders grrr) Togan> Will let you know asap Thanks. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Jean-Marc Lasgouttes wrote: >> >> >> Hmm, I just see that the code in GraphicsImageXPM does: >> >> // some image magick versions use this xpm_col[1].name = 0; >> xpm_col[1].value = "opaque"; xpm_col[1].pixel = >> lyxColorHandler->colorPixel(LColor::white); >> >> Shouldn't that be LColor::black? John, why did you choose white >> instead of black? R> I would test that right away, but GraphicsImageXPM.C is badly R> broken in CVS right now. Please fix that first: I'll try to do it. In the meantime, could you try that on 1.2.1cvs? JMarc
Re: patches: make lyx 1.2.0 work for Turkish again
* Jean-Marc Lasgouttes; <[EMAIL PROTECTED]> on 16 Jul, 2002 wrote: > >Andre> Looks straight forward, doesn't it? > >Mostly, except that in some cases we want case changing to respect the >locale (search&replace). Also, I'd like some turkish locale users to >try it out and check that it does what I think it does. > Well to be honest I am using the Lyx version that Mike Fabian packaged as an RPM with his patch. I am willing to try the patch(es) as sonn as I can rebuild my chrooted buildsytem ( currently the DVD is not obeying my orders grrr) Will let you know asap -- Togan Muftuoglu Unofficial SuSE FAQ Maintainer http://dinamizm.ath.cx
Re: "Counters" work
On Mon, Jul 15, 2002 at 05:57:01PM +0100, Angus Leeming wrote:
...
> Do you really need to make char Counters::hebrewCounter(int n) a class
> method? It doesn't use any class variables.
>
> I'd suggest, in the .C file only:
>
> namespace {
>
> char Counters::hebrewCounter(int n)
> {
> ...
> }
>
> } // namespace anon
>
> Ditto for other, similar helper functions. Keep the header file minimal.
>
> Angus
Did this. Diff attached.
Martin
--
Martin Vermeer [EMAIL PROTECTED]
Helsinki University of Technology
Department of Surveying
P.O. Box 1200, FIN-02015 HUT, Finland
:wq
Index: counters.C
===
RCS file: /cvs/lyx/lyx-devel/src/counters.C,v
retrieving revision 1.7
diff -u -p -r1.7 counters.C
--- counters.C 2002/03/21 17:25:09 1.7
+++ counters.C 2002/07/16 11:36:37
@@ -17,10 +17,10 @@
#include "counters.h"
#include "debug.h"
+#include "support/lstrings.h"
using std::endl;
-
Counter::Counter()
{
reset();
@@ -48,7 +48,7 @@ int Counter::value() const
void Counter::step()
{
++value_;
- onstep.emit();
+ //onstep.emit();
}
@@ -57,6 +57,41 @@ void Counter::reset()
value_ = 0;
}
+string Counter::master() const
+{
+ return master_;
+}
+
+void Counter::setMaster(string const & m)
+{
+ master_ = m;
+}
+
+
+Counters::Counters()
+{
+ // Ehh, should this take a textclass arg?
+
+ // Sectioning counters:
+ newCounter("part");
+ newCounter("chapter");
+ newCounter("section", "chapter");
+ newCounter("subsection", "section");
+ newCounter("subsubsection", "subsection");
+ newCounter("paragraph", "subsubsection");
+ newCounter("subparagraph", "paragraph");
+
+ // Enumeration counters:
+ newCounter("emumi");
+ newCounter("emumii", "enumi");
+ newCounter("enumiii", "enumii");
+ newCounter("enumiv", "enumiii");
+
+ // Float counters:
+ newCounter("figure");
+ newCounter("table");
+}
+
Counters::~Counters()
{
@@ -73,36 +108,35 @@ void Counters::newCounter(string const &
{
// First check if newc already exist
CounterList::iterator cit = counterList.find(newc);
- // if alrady exist give warning and return
+ // if already exist give warning and return
if (cit != counterList.end()) {
- lyxerr << "The new counter already exist." << endl;
+ lyxerr << "The new counter already exists." << endl;
return;
}
counterList[newc] = new Counter;
+ cit->second->setMaster("");
}
-void Counters::newCounter(string const & newc, string const & oldc)
+void Counters::newCounter(string const & newc, string const & masterc)
{
- // First check if newc already exist
+ // First check if newc already exists
CounterList::iterator cit = counterList.find(newc);
// if already existant give warning and return
if (cit != counterList.end()) {
- lyxerr << "The new counter already exist." << endl;
+ lyxerr << "The new counter already exists." << endl;
return;
}
- // then check if oldc exist
- CounterList::iterator it = counterList.find(oldc);
+ // then check if masterc exists
+ CounterList::iterator it = counterList.find(masterc);
// if not give warning and return
if (it == counterList.end()) {
- lyxerr << "The old counter does not exist." << endl;
+ lyxerr << "The master counter does not exist." << endl;
return;
}
- Counter * tmp = new Counter;
- it->second->onstep.connect(SigC::slot(tmp,
- &Counter::reset));
- counterList[newc] = tmp;
+ counterList[newc] = new Counter;
+cit->second->setMaster(masterc);
}
@@ -147,4 +181,118 @@ void Counters::step(string const & ctr)
return;
}
it->second->step();
+ if (it->second->master() != "") {
+ set(it->second->master(), 0);
+ }
+}
+
+namespace {
+
+inline
+char loweralphaCounter(int n)
+{
+ if (n < 1 || n > 26)
+ return '?';
+ else
+ return 'a' + n - 1;
+}
+
+inline
+char alphaCounter(int n)
+{
+ if (n < 1 || n > 26)
+ return '?';
+ else
+ return 'A' + n - 1;
+}
+
+inline
+char hebrewCounter(int n)
+{
+ static const char hebrew[22] = {
+ 'à', 'á', 'â', 'ã', 'ä', 'å', 'æ', 'ç', 'è',
+ 'é', 'ë', 'ì', 'î', 'ð', 'ñ', 'ò', 'ô', 'ö',
+ '÷', 'ø', 'ù', 'ú'
+ };
+ if (n < 1 || n > 22)
+ return '?';
+ else
+ return hebrew[n-1];
+}
+
+inline
+string const romanCounter(int n)
+{
+ static char const * roman[20] = {
+ "i", "ii", "iii", "iv", "v",
+ "vi", "vi
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > Hmm, I just see that the code in GraphicsImageXPM does: > > // some image magick versions use this > xpm_col[1].name = 0; > xpm_col[1].value = "opaque"; > xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); > > Shouldn't that be LColor::black? John, why did you choose white > instead of black? I would test that right away, but GraphicsImageXPM.C is badly broken in CVS right now. Please fix that first: source='GraphicsImageXPM.C' object='GraphicsImageXPM.lo' libtool=yes depfile='.deps/GraphicsImageXPM.Plo' tmpdepfile='.deps/GraphicsImageXPM.TPlo' depmode=gcc /bin/sh ../../config/depcomp /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include -g -O -Wno-non-template-friend -W -Wall -c -o GraphicsImageXPM.lo `test -f GraphicsImageXPM.C || echo './'`GraphicsImageXPM.C g++ -DHAVE_CONFIG_H -I. -I. -I../../src -I./../ -I../../boost -isystem /usr/X11R6/include -g -O -Wno-non-template-friend -W -Wall -c GraphicsImageXPM.C -Wp,-MD,.deps/GraphicsImageXPM.TPlo GraphicsImageXPM.C: In function `static class boost::shared_ptr grfx::ImageXPM::newImage()': GraphicsImageXPM.C:45: cannot allocate an object of type `grfx::ImageXPM' GraphicsImageXPM.C:45: since the following virtual functions are abstract: GraphicsImage.h:73: bool grfx::Image::isDrawable() const GraphicsImageXPM.C: In method `class grfx::Image * grfx::ImageXPM::clone() const': GraphicsImageXPM.C:82: cannot allocate an object of type `grfx::ImageXPM' GraphicsImageXPM.C:82: since type `grfx::ImageXPM' has abstract virtual functions GraphicsImageXPM.C: In method `void grfx::ImageXPM::clip(const grfx::Params &)': GraphicsImageXPM.C:273: warning: comparison between signed and unsigned *** Error code 1 Cheers, Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Hi, R> After a useful communication with Herbert on my problem displaying R> xpm-files on the LyX canvas, we came to the following conclusion: R> I'm using a fairly recent version of ImageMagick (5.4.7). This R> version's convert produces a color output line R> " c opaque" R> which causes a horrible quality in the LyX-View. R> Manually I have to do R> convert -opaque black Hmm, I just see that the code in GraphicsImageXPM does: // some image magick versions use this xpm_col[1].name = 0; xpm_col[1].value = "opaque"; xpm_col[1].pixel = lyxColorHandler->colorPixel(LColor::white); Shouldn't that be LColor::black? John, why did you choose white instead of black? JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > Note that autoconf 2.53 is not really supposed to work for lyx, > but we might as well try to make it work. 2.53 ships with FreeBSD 4.6 and it's around for quite some time already. It's too much work to get the older version of autoconf on my system (need to compile myself; the older packages have the wrong dependecies blabla). Anyway, I don't think it's related to 2.53, since I remember to have had the same problem when I still used the older version! > Send me your config.log and I'll have a look. Attached. Also have a look at the warnings that autogen.sh produce; it's in an earlier message of mine: http://www.mail-archive.com/lyx-devel@lists.lyx.org/msg40925.html Thanks Rob. config.log.bz2 Description: Binary data
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Jean-Marc Lasgouttes wrote: >> With xforms 1.0.0, you should not be using the XPM loader. 'lyx >> -version' should confirm that you are using the xforms loader, R> Confirm? How? This is my output: R> Special build flags: warnings assertions OK, so your are not using the xforms image loader. That should not happen. Could you send your config.log file? Note that autoconf 2.53 is not really supposed to work for lyx, but we might as well try to make it work. R> PS: I have to modify *manually* my configure script after the R> autogen.sh, to make the -lforms check work with xforms 1.0.0; it R> needs a "-lXpm": LIBS="-lforms -lXpm $LIBS" R> Shouldn't we add that anyway? But where? configure.in? or R> config/*.m4 ? Send me your config.log and I'll have a look. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > With xforms 1.0.0, you should not be using the XPM loader. 'lyx > -version' should confirm that you are using the xforms loader, Confirm? How? This is my output: $ lyx -version LyX 1.3.0cvs of Fri, May 3, 2002 Built on Jul 15 2002, 18:12:56 Configuration Host type: i386-unknown-freebsd4.6 Special build flags:warnings assertions C Compiler: gcc C Compiler flags: -g -O2 C++ Compiler: g++ (2.95.3) C++ Compiler flags: -g -O -Wno-non-template-friend -W -Wall Linker flags: Frontend: xforms libXpm version: 4.11 libforms version: 1.0.0 LyX binary dir: /opt/bin LyX files dir: /opt/share/lyx Rob. PS: I have to modify *manually* my configure script after the autogen.sh, to make the -lforms check work with xforms 1.0.0; it needs a "-lXpm": LIBS="-lforms -lXpm $LIBS" Shouldn't we add that anyway? But where? configure.in? or config/*.m4 ?
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> How do I know whether I'm using that code from GraphicsImageXPM or R> not? With xforms 1.0.0, you should not be using the XPM loader. 'lyx -version' should confirm that you are using the xforms loader, actually. The question now is to know whether we can make it understand this opaque color. JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "R" == R Lahaye <[EMAIL PROTECTED]> writes: > > R> Jean-Marc Lasgouttes wrote: > >> > "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: > Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This > Rob> version's convert produces a color output line " c opaque" which > Rob> causes a horrible quality in the LyX-View. Manually I have to do > Rob> convert -opaque black > >> Do you use the xforms image loader or the LyX one? There is code > >> in GraphicsImageXPM to handle the opaque thing, normally. > > R> I'm now using xforms 1.0.0, but the same behaviour was there with > R> 0.88.1. > > R> How do I know whether I'm using that code from GraphicsImageXPM or > R> not? > > Is this from latest cvs? Trunk or 1.2.x branch? The problem is there for both, though I'm now only working with 1.3.0cvs. I believed it's a problem with ImageMagick recent convert implementation. However, if it's related to code in GraphicsImageXPM, we need to investigate further Any hints as of where the culprit could be, if it's somewhere in LyX? Rob.
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Jean-Marc Lasgouttes wrote: >> > "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This Rob> version's convert produces a color output line " c opaque" which Rob> causes a horrible quality in the LyX-View. Manually I have to do Rob> convert -opaque black >> Do you use the xforms image loader or the LyX one? There is code >> in GraphicsImageXPM to handle the opaque thing, normally. R> I'm now using xforms 1.0.0, but the same behaviour was there with R> 0.88.1. R> How do I know whether I'm using that code from GraphicsImageXPM or R> not? Is this from latest cvs? Trunk or 1.2.x branch? JMarc
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
Jean-Marc Lasgouttes wrote: > > > "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: > Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This > Rob> version's convert produces a color output line > Rob> " c opaque" > Rob> which causes a horrible quality in the LyX-View. > Rob> Manually I have to do > Rob> convert -opaque black > > Do you use the xforms image loader or the LyX one? There is code in > GraphicsImageXPM to handle the opaque thing, normally. I'm now using xforms 1.0.0, but the same behaviour was there with 0.88.1. How do I know whether I'm using that code from GraphicsImageXPM or not? Cheers, Rob.
Re: [Patch] .cvsignore additions
> "R" == R Lahaye <[EMAIL PROTECTED]> writes: R> Hi, R> Please add the file "src/frontends/qt2/xforms/.cvsignore": .deps R> Makefile Makefile.in I did not do that. R> With autoconf-2.53 (plus automake-1.5 and libtool-1.3.4), I need R> the following patch to two .cvsignore files: I applied the patch. JMarc
Re: Fileinfo.[Ch]
On Tue, Jul 16, 2002 at 12:04:58PM +0200, Jean-Marc Lasgouttes wrote: > This looks reasonable. Of course, things like modeString should > actually return a string, instead of relying on having a char array > passed to them... Sure. I did not want to change too much. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Fileinfo.[Ch]
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> And with the usual member renaming and removal of two unneeded Andre> public functions it looks like that: This looks reasonable. Of course, things like modeString should actually return a string, instead of relying on having a char array passed to them... JMarc
Re: Underlined text never gets a newline. Bug or feature?
On Tue, Jul 16, 2002 at 11:02:27AM +0100, José Abílio Oliveira Matos wrote: > > And what if the user happend to define a macro called \underbar which is > > better/different than the one from ulem? > > Then we should put that definition above the user preamble, so that > the user defined shades the previous definition. Or am I dreaming here? The user still could have used a custom style. But that's not the point. I do not want to have "clever things" without a sane way to disable that. So acceptable option for me are e.g. (a) Do nothing. (b) Have a help item on how to achieve that on lyx.org/help (c) Have a "Use ulem.sty for underlining" checkbox in some "Advanced document options". This even could default to "on". Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: Underlined text never gets a newline. Bug or feature?
On Tue, Jul 16, 2002 at 09:23:02AM +0200, Andre Poenitz wrote:
> On Tue, Jul 16, 2002 at 03:49:37PM +0900, R. Lahaye wrote:
> > When underbar is used, why not let LyX add automagically to the preamble:
> >
> > \usepackage{ulem}
> > \let\underbar\uline
> > \let\underline\uline
> >
> > Or would that break any compatibility/generality issue?
>
> And how would a user get "real" \underbar then?
>
> And what if the user happend to define a macro called \underbar which is
> better/different than the one from ulem?
Then we should put that definition above the user preamble, so that
the user defined shades the previous definition. Or am I dreaming here?
> Andre'
>
> --
> Those who desire to give up Freedom in order to gain Security,
> will not have, nor do they deserve, either one. (T. Jefferson)
--
José Abílio Matos
LyX and docbook a perfect match. :-)
Fileinfo.[Ch]
And with the usual member renaming and removal of two unneeded public
functions it looks like that:
Index: ChangeLog
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/ChangeLog,v
retrieving revision 1.118
diff -u -p -r1.118 ChangeLog
--- ChangeLog 4 Jul 2002 09:58:16 - 1.118
+++ ChangeLog 16 Jul 2002 09:50:35 -
@@ -1,3 +1,8 @@
+
+2002-07-16 André Pönitz <[EMAIL PROTECTED]>
+
+ * FileInfo.Ch: remove unneeded code
+
2002-06-20 Herbert Voss <[EMAIL PROTECTED]>
* filetools.[C]: (readExtFromContents) add support for
Index: FileInfo.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/support/FileInfo.C,v
retrieving revision 1.15
diff -u -p -r1.15 FileInfo.C
--- FileInfo.C 21 Mar 2002 17:06:35 - 1.15
+++ FileInfo.C 16 Jul 2002 09:50:35 -
@@ -87,26 +87,35 @@
#define S_ISNWK(m) (((m) & S_IFMT) == S_IFNWK)
#endif
-// Since major is a function on SVR4, we can't use `ifndef major'.
-// might want to put MAJOR_IN_MKDEV for SYSV
-#ifdef MAJOR_IN_MKDEV
-#include
-#define HAVE_MAJOR
-#endif
-#ifdef MAJOR_IN_SYSMACROS
-#include
-#define HAVE_MAJOR
-#endif
-#ifdef major
-#define HAVE_MAJOR
-#endif
-
-#ifndef HAVE_MAJOR
-#define major(dev) (((dev) >> 8) & 0xff)
-#define minor(dev) ((dev) & 0xff)
-#define makedev(maj, min) (((maj) << 8) | (min))
+
+namespace {
+
+/// builds 'rwx' string describing file access rights
+void flagRWX(mode_t i, char * str)
+{
+ str[0] = (i & S_IRUSR) ? 'r' : '-';
+ str[1] = (i & S_IWUSR) ? 'w' : '-';
+ str[2] = (i & S_IXUSR) ? 'x' : '-';
+}
+
+/// updates mode string to match suid/sgid/sticky bits
+void setSticky(mode_t i, char * str)
+{
+#ifdef S_ISUID
+ if (i & S_ISUID)
+ str[3] = (str[3] == 'x') ? 's' : 'S';
#endif
-#undef HAVE_MAJOR
+#ifdef S_ISGID
+ if (i & S_ISGID)
+ str[6] = (str[6] == 'x') ? 's' : 'S';
+#endif
+#ifdef S_ISVTX
+ if (i & S_ISVTX)
+ str[9] = (str[9] == 'x') ? 's' : 'S';
+#endif
+}
+
+} // namespace anon
FileInfo::FileInfo()
@@ -116,7 +125,7 @@ FileInfo::FileInfo()
FileInfo::FileInfo(string const & path, bool link)
- : fname(path)
+ : fname_(path)
{
init();
dostat(link);
@@ -126,48 +135,47 @@ FileInfo::FileInfo(string const & path,
FileInfo::FileInfo(int fildes)
{
init();
- status = fstat(fildes, &buf);
- if (status) err = errno;
+ status_ = fstat(fildes, &buf_);
+ if (status_)
+ err_ = errno;
}
void FileInfo::init()
{
- status = 0;
- err = NoErr;
+ status_ = 0;
+ err_ = NoErr;
}
void FileInfo::dostat(bool link)
{
- if (link) {
- status = ::lstat(fname.c_str(), &buf);
- } else {
- status = ::stat(fname.c_str(), &buf);
- }
- if (status) err = errno;
+ if (link)
+ status_ = ::lstat(fname_.c_str(), &buf_);
+ else
+ status_ = ::stat(fname_.c_str(), &buf_);
+ if (status_)
+ err_ = errno;
}
FileInfo & FileInfo::newFile(string const & path, bool link)
{
- fname = path;
-
- status = 0;
- err = NoErr;
-
+ fname_ = path;
+ status_ = 0;
+ err_= NoErr;
dostat(link);
-
return *this;
}
FileInfo & FileInfo::newFile(int fildes)
{
- status = 0;
- err = NoErr;
- status = fstat(fildes, &buf);
- if (status) err = errno;
+ status_ = 0;
+ err_= NoErr;
+ status_ = fstat(fildes, &buf_);
+ if (status_)
+ err_ = errno;
return *this;
}
@@ -176,19 +184,22 @@ FileInfo & FileInfo::newFile(int fildes)
char const * FileInfo::typeIndicator() const
{
lyx::Assert(isOK());
-
- if (S_ISDIR(buf.st_mode)) return ("/");
+ if (S_ISDIR(buf_.st_mode))
+ return "/";
#ifdef S_ISLNK
- if (S_ISLNK(buf.st_mode)) return ("@");
+ if (S_ISLNK(buf_.st_mode))
+ return "@";
#endif
#ifdef S_ISFIFO
- if (S_ISFIFO(buf.st_mode)) return ("|");
+ if (S_ISFIFO(buf_.st_mode))
+ return "|";
#endif
#ifdef S_ISSOCK
- if (S_ISSOCK(buf.st_mode)) return ("=");
+ if (S_ISSOCK(buf_.st_mode))
+ return "=";
#endif
- if (S_ISREG(buf.st_mode) && (buf.st_mode & (S_IEXEC | S_IXGRP | S_IXOTH)))
- return ("*");
+ if (S_ISREG(buf_.st_mode) && (buf_.st_mode & (S_IEXEC | S_IXGRP | S_IXOTH)))
+ return "*";
return "";
}
@@ -196,20 +207,20 @@ char const * FileInfo::typeIndicator() c
mode_t FileInfo::getMode() const
{
lyx::Assert(isOK());
-
- return buf.st_mode;
+ return buf_.st_mode;
}
// should not be in FileInfo
-void FileInfo::modeString(char * szString) const
+void FileInfo::modeString(char * str) cons
Re: Graphics: newer ImageMagick version causes trouble for LyX-View
> "Rob" == R Lahaye <[EMAIL PROTECTED]> writes: Rob> Hi, Rob> After a useful communication with Herbert on my problem Rob> displaying xpm-files on the LyX canvas, we came to the following Rob> conclusion: Rob> I'm using a fairly recent version of ImageMagick (5.4.7). This Rob> version's convert produces a color output line Rob> " c opaque" Rob> which causes a horrible quality in the LyX-View. Rob> Manually I have to do Rob> convert -opaque black Do you use the xforms image loader or the LyX one? There is code in GraphicsImageXPM to handle the opaque thing, normally. JMarc
Re: #defines in Fileinfo.C
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> Does anybody see a need for lines 90-109 in support/Fileinfo.C? Andre> The stuff defined there is nowhere used and it works well for Andre> me if I just remove it. I think you can remove them. We are not interested in block devices. JMarc
#defines in Fileinfo.C
Does anybody see a need for lines 90-109 in support/Fileinfo.C? The stuff defined there is nowhere used and it works well for me if I just remove it. Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
error compiling cvs
Angus? g++ -DHAVE_CONFIG_H -I. -I../../../lyx-devel/src/graphics -I../../src -I../../../lyx-devel/src/graphics/../ -I../../../lyx-devel/boost -isystem /usr/X11R6/include -g -finline-limit=500 -fno-exceptions -W -Wall -Winline -Winline -c ../../../lyx-devel/src/graphics/GraphicsImageXPM.C -MT GraphicsImageXPM.lo -MD -MP -MF .deps/GraphicsImageXPM.TPlo ../../../lyx-devel/src/graphics/GraphicsImageXPM.C: In static member function `static boost::shared_ptr grfx::ImageXPM::newImage()': ../../../lyx-devel/src/graphics/GraphicsImageXPM.C:45: cannot allocate an object of type `grfx::ImageXPM' ../../../lyx-devel/src/graphics/GraphicsImageXPM.C:45: because the following virtual functions are abstract: ../../../lyx-devel/src/graphics/GraphicsImage.h:73: virtual bool grfx::Image::isDrawable() const ../../../lyx-devel/src/graphics/GraphicsImageXPM.C: In member function `virtual grfx::Image* grfx::ImageXPM::clone() const': ../../../lyx-devel/src/graphics/GraphicsImageXPM.C:82: cannot allocate an object of type `grfx::ImageXPM' ../../../lyx-devel/src/graphics/GraphicsImageXPM.C:82: since type ` grfx::ImageXPM' has abstract virtual functions ../../../lyx-devel/src/graphics/GraphicsImageXPM.C: In member function `virtual void grfx::ImageXPM::clip(const grfx::Params&)': ../../../lyx-devel/src/graphics/GraphicsImageXPM.C:273: warning: comparison between signed and unsigned integer expressions make[3]: *** [GraphicsImageXPM.lo] Error 1 make[3]: Leaving directory `/usr/local/cvs/lyx-qt2/src/graphics' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/cvs/lyx-qt2/src' make[1]: *** [all] Error 2 make[1]: Leaving directory `/usr/local/cvs/lyx-qt2/src' make: *** [all-recursive] Error 1
Re: [OT] bye for now
> "Garst" == Garst R Reese <[EMAIL PROTECTED]> writes: Garst> I'll be travelling a bit, but before unsubscribing I wanted to Garst> say thanks and congratulations on a great product. It is Garst> difficult to express my appreciatation for how you have dealt Garst> with my problems or the value that lyx has provided to my Garst> writing community. Thanks Garst. You input is very appreciated, too. JMarc
Re: patches: make lyx 1.2.0 work for Turkish again
> "Andre" == Andre Poenitz <[EMAIL PROTECTED]> writes: Andre> On Tue, Jul 16, 2002 at 12:01:10AM +0200, Jean-Marc Lasgouttes Andre> wrote: >> I'd appreciate comments on this patch Andre> Looks straight forward, doesn't it? Mostly, except that in some cases we want case changing to respect the locale (search&replace). Also, I'd like some turkish locale users to try it out and check that it does what I think it does. JMarc
Re: [Patch] .cvsignore additions
On Tue, Jul 16, 2002 at 04:54:02PM +0900, R. Lahaye wrote: > Please add the file "src/frontends/qt2/xforms/.cvsignore": > .deps > Makefile > Makefile.in Please don't, qt2/xforms/ no longer exists regards john -- "i am sorey I cant reads yuor emale because my emale box has filtar on it whitch says, "NO EMALES FROM PEOAPAL UNDER IQ OF 1" - jeffk
