On Sat, Apr 09, 2005 at 11:49:53PM +0200, Andre Poenitz wrote:
> On Sat, Apr 09, 2005 at 04:32:50PM +0300, Martin Vermeer wrote:
> > I am not even pretending that I understand this problem field. Does
> > anyone else? And is this patch, trial-and-error as it is, welcome in
> > 1.4.0cvs?
>
> The f
On Sat, Apr 09, 2005 at 04:32:50PM +0300, Martin Vermeer wrote:
> I am not even pretending that I understand this problem field. Does
> anyone else? And is this patch, trial-and-error as it is, welcome in
> 1.4.0cvs?
The foot-like stuff seems to be needed in any case, and for the other
stuff the
c/rowpainter.C,v
retrieving revision 1.143
diff -u -r1.143 rowpainter.C
--- rowpainter.C22 Mar 2005 10:57:10 - 1.143
+++ rowpainter.C9 Apr 2005 13:13:27 -
@@ -115,6 +115,9 @@
double separator_;
double hfill_;
double label_hfill_;
+
+
On Monday 22 September 2003 8:01 pm, Martin Vermeer wrote:
> On Mon, Sep 22, 2003 at 08:18:08PM +, Angus Leeming spake thusly:
> > shrug. Fair enough. If the container is complaining that it needs
> > LyXFont, then maybe we should believe it. Perhaps paragraph_pimpl.
On Mon, Sep 22, 2003 at 08:18:08PM +, Angus Leeming spake thusly:
> shrug. Fair enough. If the container is complaining that it needs LyXFont,
> then maybe we should believe it. Perhaps paragraph_pimpl.h itself is
> inconsistent on your box. Ie, it wouldn't compile on i
7;d hope that if you removed your changes to paragraph.C but left
>> the changes you've made in paragraph_pimpl.[Ch], all should 'just work'.
>> thereafter, if you could position lyxfont.h in alphabetical order again,
>> that'd be great.
>>
>> --
&g
/// set tracking mode
void trackChanges(Change::Type type = Change::UNCHANGED);
paragraph.C:1144: warning: #warning FIXME we should check the prev par as well (Lgb)
In file included from paragraph.C:21:
../boost/boost/checked_delete.hpp: In function `void
boost::checked_delete(LyXFon
Martin Vermeer wrote:
> Attached my patch (did I get it right?) and the error output.
Almost ;-)
What I meant when I said the original was nasty was that it was a fragile
solution. The code compiled if you positioned #include "lyxfont.h" in
paragraph.C in one position and not if it were positi
ph::Pimpl {
/// Copy constructor
Pimpl(Pimpl const &, Paragraph * owner);
///
+ ~Pimpl();
+ ///
void setContentsFromPar(Paragraph const & par);
/// set tracking mode
void trackChanges(Change::Type type = Change::UNCHANGED);
paragraph.C:1144
On Monday 22 September 2003 5:24 pm, Martin Vermeer wrote:
> On Mon, Sep 22, 2003 at 04:56:04PM +, Angus Leeming spake thusly:
> > On Monday 22 September 2003 3:36 pm, Martin Vermeer wrote:
> > > Angus, I still need lyxfont.h in paragraph and paragraph_pimpl as
> > > follows:
> >
> > The fix is
om paragraph.C:22:
../boost/boost/checked_delete.hpp: In function `void
boost::checked_delete(LyXFont *)':
../boost/boost/checked_delete.hpp:52: instantiated from
`boost::checked_deleter::operator ()(LyXFont *) const'
../boost/boost/detail/shared_count.hpp:342: instantiated from
`boost::de
On Monday 22 September 2003 3:36 pm, Martin Vermeer wrote:
> Angus, I still need lyxfont.h in paragraph and paragraph_pimpl as
> follows:
The fix is really nasty (read fragile). Especially the position-dependence in
paragraph.C. Could we dig a little deeper first and ascertain what exactly is
go
Angus, I still need lyxfont.h in paragraph and paragraph_pimpl as
follows:
Index: paragraph.C
===
RCS file: /usr/local/lyx/cvsroot/lyx-devel/src/paragraph.C,v
retrieving revision 1.326
diff -u -p -r1.326 paragraph.C
--- paragraph.C 2
On Wed, Mar 20, 2002 at 09:20:35AM +0100, Andre Poenitz wrote:
> Namespaces can be - as opposed to class definitions - distributed over
> several files. So simple things could be put into small headers, and more
ok so like I said, we can have a char_metrics.h if it's useful to
mathed.
john
--
On Wed, Mar 20, 2002 at 09:54:53AM +0100, Lars Gullik Bjønnes wrote:
> Did I ever say that?
I don't think so.
Andre'
--
André Pönitz .. [EMAIL PROTECTED]
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Using a namespace instead of a class full of static function is certainly
| _not_ a hack.
Did I ever say that?
--
Lgb
On Wed, Mar 20, 2002 at 08:09:44AM +, John Levon wrote:
> I don't know how we can avoid using string in this interface anyway !
Namespaces can be - as opposed to class definitions - distributed over
several files. So simple things could be put into small headers, and more
complicated things t
On Wed, Mar 20, 2002 at 08:34:12AM +0100, Lars Gullik Bjønnes wrote:
> Yes, but IMHO the solution is not to avoid the include, but to
> restructure etc. (pimpl f.ex.) so that the include will only be needed
> in a very few places, never to use other types to avoid includes...
Pimpl is a cure for
On Wed, Mar 20, 2002 at 08:34:12AM +0100, Lars Gullik Bjønnes wrote:
> And I actually belive that we already now are more stable than 1.1.6
> were when it was released.
I agree, we are in good shape. Until we get all the bug reports from
pre1 that is :)
> in a very few places, never to use othe
Andre Poenitz <[EMAIL PROTECTED]> writes:
| On Tue, Mar 19, 2002 at 07:42:09PM +0100, Lars Gullik Bjønnes wrote:
>> | Not really. I am trying to get as close to the outer world as possible. And
>> | with the last commit today I can already get rid of most of the 'tweaking
>> | wrapper functions'.
On Tue, Mar 19, 2002 at 07:42:09PM +0100, Lars Gullik Bjønnes wrote:
> | Not really. I am trying to get as close to the outer world as possible. And
> | with the last commit today I can already get rid of most of the 'tweaking
> | wrapper functions'.
>
> Feel free to stop tweaking at mathed now.
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Not really. I am trying to get as close to the outer world as possible. And
| with the last commit today I can already get rid of most of the 'tweaking
| wrapper functions'.
Feel free to stop tweaking at mathed now.
| But I won't do that if that mean
Andre Poenitz <[EMAIL PROTECTED]> writes:
| Couldn't we replace struct lyxfont and all of its static members by a
| proper namespace? This would be even transparent to 'user' code!
Not now.
--
Lgb
On Tue, Mar 19, 2002 at 07:13:21PM +0100, Andre Poenitz wrote:
> But I won't do that if that means having to pull in Lstring.h and X11.h
> in almost all insets...
frontends/font_metrics.h doesn't even know X11 exists. string is a
different matter...
Please, just leave this stuff alone till 1.3
On Tue, Mar 19, 2002 at 06:06:37PM +, John Levon wrote:
> > If we did that, we could split the file font.h into two, one completely
> > self-contained for the 'basic' stuff like ascend, and one that needs the
> > string and X11 headers. Then I could #include just the small one and scrap
> > mo
On Tue, Mar 19, 2002 at 06:59:08PM +0100, Andre Poenitz wrote:
> Couldn't we replace struct lyxfont and all of its static members by a
> proper namespace? This would be even transparent to 'user' code!
done in my GUII patch.
> If we did that, we could split the f
Couldn't we replace struct lyxfont and all of its static members by a
proper namespace? This would be even transparent to 'user' code!
If we did that, we could split the file font.h into two, one completely
self-contained for the 'basic' stuff like ascend, and one
char const * LyXSizeNames[14] =
{ "tiny", "scriptsize", "footnotesize", "small", "normal", "large",
"larger", "largest", "huge", "giant",
"increase-error", "decrease-error", "default", "error" };
Why???
why not increase, decrease?
Angus
28 matches
Mail list logo
