Re: [patch included]
On Fri, Sep 15, 2000 at 07:32:28PM +0300, Marko Vendelin wrote: > > The following patch adds support for regexp search in FormCitation (Gnome > frontend). Why not filter the entries in the citation list (i.e. show only the ones containing the regexp) instead of search?
Re: [patch included]
On Sat, 16 Sep 2000, Dekel Tsur wrote: > On Fri, Sep 15, 2000 at 07:32:28PM +0300, Marko Vendelin wrote: > > > > The following patch adds support for regexp search in FormCitation (Gnome > > frontend). > > Why not filter the entries in the citation list (i.e. show only the ones > containing the regexp) instead of search? Actually, it is a filter. Marko
Gnome frontend: Menubar implementation, patch included
Hi! this patch adds Gnome/Gtk menu to LyX. Since menu is a part of Gnome application main window, a small main window class (GLyxAppWin) is added too. Eventually, when LyXView will be ported to Gnome or LyX main window will be GUI independent, GLyxAppWin will be replaced. Thus, when compiled with gnome frontend support, LyX has two windows: LyXView (without menubar) and new GLyxAppWin (with menubar). The following two problems occured: Manubar::update : Since Gnome menu may be easily used as toolbar by "tearing off" the menu, I had to update constantly state of the widgets as it is done for Toolbar. This means that after each keypress by user LyX has to check state of all the actions presented in the menu. Is there any way to register a callback function which is called when the corresponding action state has changed? Will it be more effective than walking through vector with actions and asking the state of each action? Shortcuts: Gnome applications have common shortcuts, such as F3 for Open File, for example. Which shortcuts should be default for LyX --- as it is now or common Gnome ones? Marko gnome-menus.gz gnome-menu-new-files.tar.gz
Master TOC and trivial changes patch (included)
Greetings, I've commited a Master Table of Contents to the lyxdoc repository (TOC.lyx) along with the shell script that got me 98% of the way there. (As an exercize for Amir, rewrite it with 5 lines of Perl code ...). Let me know if you like it. I've also attached a patch against 1.1.4fix2 which addresses some of the "trivial changes" I proposed last week. Specifically, it adds pslatex as a font option, adds Help entries for the FAQ and TOC, changes Insert->Figure to Insert->Graphic, changes Insert->Table to Insert->Table Box, changes Insert->Float to Insert->Floating Material, and deletes the "Float" from each of the items (e.g. Figure Float becomes Figure). I did not attempt to move Insert->Floating Material to the top of the pulldown menu, nor did I attempt a \clearpage hack. This is just a "diff -rc"; since make_patch got nuked, this is the best I could do. Someone who knows what they are doing should take a look at this and decide if it's worthwhile. If so it should go into fix3 as well as 1.1.5 (IMO). Concerning \clearpage, it behaves exactly like \newpage except that it processes all floats before changing to a new page. Thus is should be treated exactly like the pagebreak entry in LyX. You could in theory just add a radio button to the pagebreak area to determine whether to "clear floating material" or not to emit either a \newpage or a \clearpage. Boy, I'm being long winded today ... Mike [EMAIL PROTECTED] ressler.patch.gz
Solution to my compile problems (patch included)
I got tired of having my daily lyx RPM build fail, so I started looking for the real cause. I think I know what happened here. The cite.C file reference was embedded into my *.po files, making it impossible to ``make dist'' and then expect to compile. This made me think that src/cite.[hC] should be inserted into src/Makefile.am. When I deleted cite.h and cite.C after a fresh get and tried to do ``make rpmdist'', it failed with the compile error. However, the same source compiles correctly with ``make''. So, the problem was somehow with the RPM creation and not necessarily a generic compile problem. I compared the makes and found that the culprit was the "-ansi" flag. kayvan@camel ~/src/lyx/sigc++]$ c++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -I./.. -ansi -Wall -c marshal.cc -o marshal.o In file included from ../sigc++/marshal.h:14, from marshal.cc:1: ../sigc++/thread.h:124: type specifier omitted for parameter ../sigc++/thread.h:124: parse error before `*' But... [kayvan@camel ~/src/lyx/sigc++]$ c++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -I./.. -Wall -c marshal.cc -o marshal.o [kayvan@camel ~/src/lyx/sigc++]$ By more looking and some trial and error, I found that the following sequence works: ``./autogen.sh; ./configure; make'' But, this does not: ``./autogen.sh; CXXFLAGS=-O2 CFLAGS=-O2 ./configure; make'' Producing this error: /bin/sh ./libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -I./..-O2 -ansi -W -Wall -Wno-return-type -c marshal.cc c++ -DHAVE_CONFIG_H -I. -I. -I. -I./.. -I./.. -O2 -ansi -W -Wall -Wno-return-type -Wp,-MD,.deps/marshal.pp -c marshal.cc -o marshal.o In file included from ../sigc++/marshal.h:14, from marshal.cc:1: ../sigc++/thread.h:124: type specifier omitted for parameter ../sigc++/thread.h:124: parse error before `*' I consider this a bug with the makefiles, since a user's optimization choice should not effect the user's ability to compile. In any case, my patch to work around this (which I think should go into the CVS) is attached. NOTE: Even with this patch, I have to remove src/cite.[hC] manually *after* my cvs update. Otherwise, the ``make rpmdist'' fails while in the po/ directory, looking for ../src/cite.C. It would be great if someone would just delete the cite.[hC] files from the CVS. ---Kayvan -- Kayvan A. Sylvan | Proud husband of | Father to my kids: Sylvan Associates, Inc.| Laura Isabella Sylvan | Katherine Yelena http://www.successlinks.com/kayvan | Reach your goals now! | Robin Gregory Index: ChangeLog === RCS file: /usr/local/lyx/cvsroot/lyx-devel/ChangeLog,v retrieving revision 1.373 diff -u -u -r1.373 ChangeLog --- ChangeLog 2000/06/16 15:13:23 1.373 +++ ChangeLog 2000/06/17 08:54:48 @@ -1,3 +1,10 @@ +2000-06-17 Kayvan A. Sylvan <[EMAIL PROTECTED]> + + * development/lyx.spec.in: Call configure with ``--without-warnings'' + to work around a bug with the Makefiles when doing ``make lyxrpm''. + This should be fine, however, since we generally don't want to be + verbose when making an RPM. + 2000-06-16 Juergen Vigna <[EMAIL PROTECTED]> * src/insets/insettabular.C (UpdateLocal): Index: development/lyx.spec.in === RCS file: /usr/local/lyx/cvsroot/lyx-devel/development/lyx.spec.in,v retrieving revision 1.6 diff -u -u -r1.6 lyx.spec.in --- development/lyx.spec.in 2000/03/15 01:15:13 1.6 +++ development/lyx.spec.in 2000/06/17 08:54:57 @@ -37,7 +37,8 @@ %build unset LINGUAS || true -CXXFLAGS="$RPM_OPT_FLAGS" CFLAGS="$RPM_OPT_FLAGS" ./configure --prefix=/usr +CXXFLAGS="$RPM_OPT_FLAGS" CFLAGS="$RPM_OPT_FLAGS" \ +./configure --prefix=/usr --without-warnings make %install
RE: Gnome frontend: Menubar implementation, patch included
> Hi! > > this patch adds Gnome/Gtk menu to LyX. Since menu is a part of Gnome Applied will commit soon (just let me test it ;) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ "Roman Polanski makes his own blood. He's smart -- that's why his movies work." -- A brilliant director at "Frank's Place"
RE: Gnome frontend: Menubar implementation, patch included
On Wed, 9 Aug 2000, Juergen Vigna wrote: > Applied will commit soon (just let me test it ;) You need to set up two symbolic links to compile&link it: src/frontends/gnome/Toolbar_pimpl.[Ch]-->src/frontends/xforms/Toolbar_pimpl.[Ch] Marko
RE: Gnome frontend: Menubar implementation, patch included
On 09-Aug-2000 Marko Vendelin wrote: > > src/frontends/gnome/Toolbar_pimpl.[Ch]-->src/frontends/xforms/Toolbar_pimpl.[Ch] I thought so! You also can link in all not ported dialogs from the xforms tree and so have a fully functional lyx with just the stuff ported to gnome you did till now ;) Jürgen P.S.: Are you on the devel-list? (just so we don't have to cc and don't get all the mails twice) -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Paranoia doesn't mean the whole world isn't out to get you.
RE: Gnome frontend: Menubar implementation, patch included
> Manubar::update : Since Gnome menu may be easily used as toolbar by > "tearing off" the menu, I had to update constantly state of the widgets as > it is done for Toolbar. This means that after each keypress by user LyX Well I had a bit problems compiling this (forgot to use the right options --without-included-libsigc --disable-sigctest), but now I have it running. Well my first impression is it works ;), it is VERY slow on update, but probably you will solve this. IMO as first work it looks good #:O), let's see how the toolbar works then ;) > > Shortcuts: Gnome applications have common shortcuts, such as F3 for Open > File, for example. Which shortcuts should be default for LyX --- as it is > now or common Gnome ones? Well you make the port, you should make the decicions, but maybe you could just add a gnome.bind file, what do you think? Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If you took all the students that felt asleep in class and laid them end to end, they'd be a lot more comfortable. -- "Graffiti in the Big Ten"
RE: Gnome frontend: Menubar implementation, patch included
On Wed, 9 Aug 2000, Juergen Vigna wrote: > > Shortcuts: Gnome applications have common shortcuts, such as F3 for Open > > File, for example. Which shortcuts should be default for LyX --- as it is > > now or common Gnome ones? > > Well you make the port, you should make the decicions, but maybe you could > just add a gnome.bind file, what do you think? You mean gnome.ui don't you? Of course you did. Must be nearly lunchtime and you were in a hurry. Allan. (ARRae)
RE: Gnome frontend: Menubar implementation, patch included
> > You mean gnome.ui don't you? Of course you did. Must be nearly lunchtime > and you were in a hurry. Well telling you the truth I just returned from lunch, so no excuse for this ;), but I really meant gnome.bind or isn't 'F3' -> file-open not a binding? UI files are only for menus aren't they? Jürgen P.S.: Well quite late there did you already have some dinner? #:OP -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ One possible reason that things aren't going according to plan is that there never was a plan in the first place.
RE: Gnome frontend: Menubar implementation, patch included
On Wed, 9 Aug 2000, Juergen Vigna wrote: > > Shortcuts: Gnome applications have common shortcuts, such as F3 for Open > > File, for example. Which shortcuts should be default for LyX --- as it is > > now or common Gnome ones? > > Well you make the port, you should make the decicions, but maybe you could > just add a gnome.bind file, what do you think? Actually if it's a Gnome application and not a GTK+ app, it should use the Gnome key binds, the idea of Gnome is to be a unified desktop where the apps all act more or less the same so that the whole UI feeling is consistent, if we do a Gnome version we should be consistent with the rest of Gnome by default. We should however allow changing the bindings by the .bind files. -- Baruch Even http://techst02.technion.ac.il/~sbaruch/ (My Site) http://rpghost.com/jindor/ (My brothers AD&D site) " Learn to laugh ... it's the path to true love! " - The Angel in the movie Michael
RE: Gnome frontend: Menubar implementation, patch included
On Wed, 9 Aug 2000, Juergen Vigna wrote: > > You mean gnome.ui don't you? Of course you did. Must be nearly lunchtime > > and you were in a hurry. > > Well telling you the truth I just returned from lunch, so no excuse > for this ;), but I really meant gnome.bind or isn't 'F3' -> file-open > not a binding? > > UI files are only for menus aren't they? The menus may need to have entries renamed to suit GNOME (or other desktops) and such. The bindings for the menus are in the .ui files. So you see gnome.ui is probably the one to work on. There may be other bindings needed but these aren't likely to be common to other GNOME apps. Does GNOME specify a binding for the equivalent of "layout standard" for example? I thought JMarc wanted to move all the bindings into the ui file(s). Maybe that was Lars. I suppose you want GNOME menus with emacs keybindings just to mess things up further? > P.S.: Well quite late there did you already have some dinner? #:OP Thai-style, stir-fried beef with egg noodles. > One possible reason that things aren't going according to plan > is that there never was a plan in the first place. Uh oh! You've found me out! Allan. (ARRae)
RE: Gnome frontend: Menubar implementation, patch included
> > The menus may need to have entries renamed to suit GNOME (or other > desktops) and such. The bindings for the menus are in the .ui files. > So you see gnome.ui is probably the one to work on. There may be other > bindings needed but these aren't likely to be common to other GNOME apps. > Does GNOME specify a binding for the equivalent of "layout standard" for > example? > Sure! But IMO we can have more than one keybinding for the same function if it's not overlaying. So View Postscript could still be Ctrl-T as I now use with cua-bindings. > > Thai-style, stir-fried beef with egg noodles. > Not to bad, a pitty we don't have Thai restaurants here in Bolzano. >> One possible reason that things aren't going according to plan >> is that there never was a plan in the first place. > > Uh oh! You've found me out! > Well I guess it happend without plan #:O) Jürgen -- -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen VignaE-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel/Fax: +39-0471-450260 / +39-0471-450296 I-39100 Bozen Web: http://www.sad.it/~jug -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ If man is only a little lower than the angels, the angels should reform. -- Mary Wilson Little
Re: Gnome frontend: Menubar implementation, patch included
Allan Rae <[EMAIL PROTECTED]> writes: | I thought JMarc wanted to move all the bindings into the ui | file(s). Maybe that was Lars. No, no, we want _menu item_ to have their shortcuts/bindings in te .ui file. Emacs keybindings does not go in .ui files and does not interact wite menuitems' bindings. | I suppose you want GNOME menus with emacs keybindings just to mess things | up further? bindings like "F3" to "File->New" would go in gnome.bind bindings like "M-f n" would go in the gnome.ui (and most likely te defualt.ui would be good enough unless the menu names need to change) Lgb
Re: Gnome frontend: Menubar implementation, patch included
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Allan Rae <[EMAIL PROTECTED]> writes: | I thought Lars> JMarc wanted to move all the bindings into the ui | file(s). Lars> Maybe that was Lars. Lars> No, no, we want _menu item_ to have their shortcuts/bindings in Lars> te .ui file. Emacs keybindings does not go in .ui files and does Lars> not interact wite menuitems' bindings. The reason why I called that ui is that I'd like to move bindings to the ui framework. Key binding is as much User Interface as menus. More on that when I have a better understanding on what has been going on during this month... JMarc
Re: Gnome frontend: Menubar implementation, patch included
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Allan Rae <[EMAIL PROTECTED]> writes: | I thought | Lars> JMarc wanted to move all the bindings into the ui | file(s). | Lars> Maybe that was Lars. | | Lars> No, no, we want _menu item_ to have their shortcuts/bindings in | Lars> te .ui file. Emacs keybindings does not go in .ui files and does | Lars> not interact wite menuitems' bindings. | | The reason why I called that ui is that I'd like to move bindings to | the ui framework. Key binding is as much User Interface as menus. But they are _not_ GUI! Lgb
Re: Gnome frontend: Menubar implementation, patch included
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> Key binding is as much User Interface as menus. Lars> But they are _not_ GUI! That's why the directory is not named gui/ but ui/. The idea is that bindings do not belong in lyxrc (they are not stored in the lyxrc object, in fact) and that having everything in ui files allows to specify some kind of theme/skin/whatever. If I design a msword skin, it should change the toolbar, the menu _and_ the bindings. JMarc
Re: Gnome frontend: Menubar implementation, patch included
Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: | > "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: | | Lars> Key binding is as much User Interface as menus. | | Lars> But they are _not_ GUI! | | That's why the directory is not named gui/ but ui/. | | The idea is that bindings do not belong in lyxrc (they are not stored | in the lyxrc object, in fact) Agree. | and that having everything in ui files | allows to specify some kind of theme/skin/whatever. If I design a | msword skin, it should change the toolbar, the menu _and_ the | bindings. skins are something different. (and has different meanings to different people) Do not design too many interdependencies between stuff that has nothign really to do with each other. F.eks. Menu bindings sould not be in the same file as command bindings. Lgb
Re: Gnome frontend: Menubar implementation, patch included
> "Lars" == Lars Gullik Bjønnes <[EMAIL PROTECTED]> writes: Lars> F.eks. Menu bindings sould not be in the same file as command Lars> bindings. Menu bindings should be done directly by the menu code (I have to see how it works now that menu.bind is gone; unfortunately my time is scarce this week). Command bindings are a way to get to commands, just like menus and toolbars are. For me they are different ways to do the same thing and belong together. JMarc
Re: Master TOC and trivial changes patch (included)
> "Mike" == <[EMAIL PROTECTED]> writes: Mike> I've also attached a patch against 1.1.4fix2 which addresses Mike> some of the "trivial changes" I proposed last week. OK I've applied it. It would have been better to have (1) a "diff -ur" patch, because it's more readable and (2) a ChangeLog entry, so that I do not have to do it myself. What I would still appreciate, though, is a LaTeXConfig.lyx.in entry for pslatex.sty. I'll add the lib/configure test myself. Mike> Concerning \clearpage, it behaves exactly like \newpage except Mike> that it processes all floats before changing to a new page. Thus Mike> is should be treated exactly like the pagebreak entry in LyX. Mike> You could in theory just add a radio button to the pagebreak Mike> area to determine whether to "clear floating material" or not to Mike> emit either a \newpage or a \clearpage. Then we should have \cleardoublepage too. JMarc
Re: Master TOC and trivial changes patch (included)
On 11 Apr 2000, Jean-Marc Lasgouttes wrote: > Mike> I've also attached a patch against 1.1.4fix2 which addresses > Mike> some of the "trivial changes" I proposed last week. > > OK I've applied it. It would have been better to have (1) a "diff -ur" > patch, because it's more readable and (2) a ChangeLog entry, so that I > do not have to do it myself. > > What I would still appreciate, though, is a LaTeXConfig.lyx.in entry > for pslatex.sty. I'll add the lib/configure test myself. Oops. I didn't even think about looking at LaTeXConfig. Thanks for your efforts in cleaning this up. This is why I write docs, not code :-) Mike [EMAIL PROTECTED]
Re: Master TOC and trivial changes patch (included)
> "Mike" == <[EMAIL PROTECTED]> writes: Mike> Oops. I didn't even think about looking at LaTeXConfig. Thanks Mike> for your efforts in cleaning this up. This is why I write docs, Mike> not code :-) So, where is the LaTeXConfig entry? ;) BTW, if you feel like rewriting (part of) LaTeXConfig, feel free to do so. JMarc
RE: Solution to my compile problems (patch included)
On 17-Jun-2000 Kayvan A. Sylvan wrote: > > NOTE: Even with this patch, I have to remove src/cite.[hC] manually *after* my > cvs update. Otherwise, the ``make rpmdist'' fails while in the po/ directory, > looking for ../src/cite.C. It would be great if someone would just delete > the cite.[hC] files from the CVS. Well cite.[Ch] was already removed and I commited this patch right now! Jürgen -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._ Dr. Jürgen Vigna E-Mail: [EMAIL PROTECTED] Italienallee 13/N Tel:+39-0471-450260 I-39100 Bozen Fax:+39-0471-450296 ITALY Web:http://www.sad.it/~jug The fortune program is supported, in part, by user contributions and by a major grant from the National Endowment for the Inanities. -._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._-._
RE: Gnome frontend: Menubar implementation, patch included (fwd)
On Wed, 9 Aug 2000, Juergen Vigna wrote: > Well my first impression is it works ;), it is VERY slow on update, but > probably you will solve this. IMO as first work it looks good #:O), let's > see how the toolbar works then ;) I think it is slow due to XForms event handler. To make it fast one needs just to add a loop for (int i=0; i<5; ++i) Gnome::Main::instance()->iteration(FALSE); instead of running Gnome::Main::instance()->iteration(FALSE) only once per loop in LyXGUI::runTime(). So, I think that this problem will disappear as soon as all LyX events are handled by Gnome. Marko
[patch included] Re: [Jules Bean ] Various(math-mode) HMI improvements
On 15 Sep 2000, Lars Gullik Bjønnes wrote: > | Any good library (C/C++) which is able to check whether a string matches > | given regexp. Return value TRUE/FALSE/invalid regexp is expected :) > > We already have that included under src/support so it is easy to use. The following patch adds support for regexp search in FormCitation (Gnome frontend). Marko PS: BTW, what about my patches submitted earlier (tracking TOC changes and adding TOC to Gnome Menubar) ? formcitation2.patch.gz
Re: [patch included] Re: [Jules Bean ] Various (math-mode) HMI improvements
Marko Vendelin <[EMAIL PROTECTED]> writes:
| On 15 Sep 2000, Lars Gullik Bjønnes wrote:
|
| > | Any good library (C/C++) which is able to check whether a string matches
| > | given regexp. Return value TRUE/FALSE/invalid regexp is expected :)
| >
| > We already have that included under src/support so it is easy to use.
|
| The following patch adds support for regexp search in FormCitation (Gnome
| frontend).
Ok, I will apply this patch.
One not however: do not use defines, ever!
#define CONF_COLUMN "column"
should be
static string const CONF_COLUMN("column");
similar for the other defines
| PS: BTW, what about my patches submitted earlier (tracking TOC changes and
| adding TOC to Gnome Menubar) ?
I have to dog them up to have a look.
Lgb
Re: [patch included] Re: [Jules Bean ]Various (math-mode) HMI improvements
On 15 Sep 2000, Lars Gullik Bjønnes wrote:
> One not however: do not use defines, ever!
>
> #define CONF_COLUMN "column"
>
> should be
>
> static string const CONF_COLUMN("column");
I will submit a patch with all these defines removed. But can you tell me
why should we avoid the defines (I presume only with strings) ?
Marko
Re: [patch included] Re: [Jules Bean ] Various (math-mode) HMI improvements
Marko Vendelin <[EMAIL PROTECTED]> writes:
| On 15 Sep 2000, Lars Gullik Bjønnes wrote:
|
| > One not however: do not use defines, ever!
| >
| > #define CONF_COLUMN "column"
| >
| > should be
| >
| > static string const CONF_COLUMN("column");
|
| I will submit a patch with all these defines removed. But can you tell me
| why should we avoid the defines (I presume only with strings) ?
with ints enums and other objects too and especially macros.
Defines are bad because:
- untyped
- arg expansion problem with macros
And in C++ we have the needed support for doing this _in_ the language
no need to do it in the preprocessor:
- const
- static
- inline
Lgb
