Am Samstag, 6. Mai 2006 19:43 schrieb Enrico Forestieri:
This patch works.
OK, it is in now. Edwin/Abdel: I added a FIXME for you in
src/frontends/qt4/QDelimiterDialog.C.
I take that you mean the backslash problem.
Yes.
Is there any glitch with my proposed fix for it?
It might hide
Am Samstag, 6. Mai 2006 19:43 schrieb Enrico Forestieri:
> This patch works.
OK, it is in now. Edwin/Abdel: I added a FIXME for you in
src/frontends/qt4/QDelimiterDialog.C.
> I take that you mean the "backslash" problem.
Yes.
> Is there any glitch with my proposed fix for it?
It might hide
Am Montag, 1. Mai 2006 20:21 schrieb Enrico Forestieri:
I just discovered another small problem.
When using the GUI for fixed size delimiters and there is a selection:
1) if the left delimiter is empty, hitting insert produces nothing;
2) if the right delimiter is empty, hitting insert
On Sat, May 06, 2006 at 02:18:47PM +0200, Georg Baum wrote:
Am Montag, 1. Mai 2006 20:21 schrieb Enrico Forestieri:
I just discovered another small problem.
When using the GUI for fixed size delimiters and there is a selection:
1) if the left delimiter is empty, hitting insert
Am Montag, 1. Mai 2006 20:21 schrieb Enrico Forestieri:
> I just discovered another small problem.
>
> When using the GUI for fixed size delimiters and there is a selection:
>
> 1) if the left delimiter is empty, hitting insert produces nothing;
>
> 2) if the right delimiter is empty, hitting
On Sat, May 06, 2006 at 02:18:47PM +0200, Georg Baum wrote:
> Am Montag, 1. Mai 2006 20:21 schrieb Enrico Forestieri:
> > I just discovered another small problem.
> >
> > When using the GUI for fixed size delimiters and there is a selection:
> >
> > 1) if the left delimiter is empty, hitting
Am Donnerstag, 27. April 2006 14:12 schrieb Enrico Forestieri:
Well, here is the result of my effort. I also attach separately a diff
against src/frontends/qt3/ui/moc/Makefile.in and
src/frontends/qt3/moc/Makefile.in as svn diff doesn't seem to have
catched them. I had to patch them because
On Mon, May 01, 2006 at 03:08:06PM +0200, Georg Baum wrote:
Am Donnerstag, 27. April 2006 14:12 schrieb Enrico Forestieri:
Please, someone should have a look at QDelimiterDialogBase.ui as I
managed to break it wrt resizing and don't know what else (Abdel?).
Sorry guys, but I have never
Am Montag, 1. Mai 2006 18:23 schrieb Enrico Forestieri:
There is a small problem with the \ delimiter as it isn't recognized.
Please find attached an updated patch fixing that. The problem with \
is also in 1.4. I attach a patch for this, too.
Do I understand you correctly that \ is broken
On Mon, May 01, 2006 at 07:54:05PM +0200, Georg Baum wrote:
Am Montag, 1. Mai 2006 18:23 schrieb Enrico Forestieri:
There is a small problem with the \ delimiter as it isn't recognized.
Please find attached an updated patch fixing that. The problem with \
is also in 1.4. I attach a patch
On Mon, May 01, 2006 at 08:09:05PM +0200, Enrico Forestieri wrote:
On Mon, May 01, 2006 at 07:54:05PM +0200, Georg Baum wrote:
Am Montag, 1. Mai 2006 18:23 schrieb Enrico Forestieri:
There is a small problem with the \ delimiter as it isn't recognized.
Please find attached an
Am Donnerstag, 27. April 2006 14:12 schrieb Enrico Forestieri:
> Well, here is the result of my effort. I also attach separately a diff
> against src/frontends/qt3/ui/moc/Makefile.in and
> src/frontends/qt3/moc/Makefile.in as "svn diff" doesn't seem to have
> catched them. I had to patch them
On Mon, May 01, 2006 at 03:08:06PM +0200, Georg Baum wrote:
> Am Donnerstag, 27. April 2006 14:12 schrieb Enrico Forestieri:
> > Please, someone should have a look at QDelimiterDialogBase.ui as I
> > managed to break it wrt resizing and don't know what else (Abdel?).
> > Sorry guys, but I have
Am Montag, 1. Mai 2006 18:23 schrieb Enrico Forestieri:
> There is a small problem with the "\" delimiter as it isn't recognized.
> Please find attached an updated patch fixing that. The problem with "\"
> is also in 1.4. I attach a patch for this, too.
Do I understand you correctly that "\" is
On Mon, May 01, 2006 at 07:54:05PM +0200, Georg Baum wrote:
> Am Montag, 1. Mai 2006 18:23 schrieb Enrico Forestieri:
>
> > There is a small problem with the "\" delimiter as it isn't recognized.
> > Please find attached an updated patch fixing that. The problem with "\"
> > is also in 1.4. I
On Mon, May 01, 2006 at 08:09:05PM +0200, Enrico Forestieri wrote:
> On Mon, May 01, 2006 at 07:54:05PM +0200, Georg Baum wrote:
>
> > Am Montag, 1. Mai 2006 18:23 schrieb Enrico Forestieri:
> >
> > > There is a small problem with the "\" delimiter as it isn't recognized.
> > > Please find
Am Donnerstag, 27. April 2006 20:18 schrieb Andre Poenitz:
On Thu, Apr 27, 2006 at 09:24:42AM +0200, Georg Baum wrote:
In any case, all magic should go to interpret() Co., not to
LCursor::plainInsert().
That works for one-character delimiters, but not for things like
\Vert. It
Am Donnerstag, 27. April 2006 20:18 schrieb Andre Poenitz:
> On Thu, Apr 27, 2006 at 09:24:42AM +0200, Georg Baum wrote:
> > > In any case, all magic should go to interpret() & Co., not to
> > > LCursor::plainInsert().
> >
> > That works for one-character delimiters, but not for things like
Enrico Forestieri wrote:
Now I am beginning to understand the magic. So, after
AC_SUBST(FOO, [bar])
I only need to write
myvar = $(FOO)
in Makefile.am and I will find
FOO = @FOO@
...
myvar = $(FOO)
in Makefile.in. Cool. There should be a better way than info autoconf
to try
Enrico Forestieri wrote:
> Now I am beginning to understand the magic. So, after
>
> AC_SUBST(FOO, [bar])
>
> I only need to write
>
> myvar = $(FOO)
>
> in Makefile.am and I will find
>
> FOO = @FOO@
> ...
> myvar = $(FOO)
>
> in Makefile.in. Cool. There should be a better way than "info
Andre Poenitz wrote:
Restricting input in cell is something we stubled over already in e.g.
the number of macro arguments.
So it looks like some generic solution is wanted, i.e. something like a
'cell property'.
This is not the only problem: If we made the delimiter a cell we would have
Jean-Marc Lasgouttes wrote:
Georg == Georg Baum
[EMAIL PROTECTED]
writes:
Georg If you want I'll revert the changes to plainInsert, but I am
Georg not going to implement the cell based solution, since I don't
Georg like it UI-wise at all.
What do you want to do UI-wise?
Nothing. The
Andre Poenitz wrote:
On Wed, Apr 26, 2006 at 09:30:51AM +0200, Georg Baum wrote:
Andre Poenitz wrote:
Is it? I thought also the item to the left or right was considered.
Then the attached patch should make it work, but it does not.
Hm, so then there is some hardcoded trickery to show
Georg == Georg Baum [EMAIL PROTECTED] writes:
Georg If you want I'll revert the changes to plainInsert, but I am
Georg not going to implement the cell based solution, since I don't
Georg like it UI-wise at all.
What do you want to do UI-wise?
JMarc
On Thu, Apr 27, 2006 at 10:42:58AM +0200, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Georg == Georg Baum
[EMAIL PROTECTED]
writes:
Georg If you want I'll revert the changes to plainInsert, but I am
Georg not going to implement the cell based solution, since I don't
Georg like
Enrico Forestieri a écrit :
On Thu, Apr 27, 2006 at 10:42:58AM +0200, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Georg == Georg Baum
[EMAIL PROTECTED]
writes:
Georg If you want I'll revert the changes to plainInsert, but I am
Georg not going to implement the cell based solution, since I
Enrico Forestieri wrote:
Well, here is the result of my effort. I also attach separately a diff
against src/frontends/qt3/ui/moc/Makefile.in and
src/frontends/qt3/moc/Makefile.in as svn diff doesn't seem to have
catched them. I had to patch them because qt_helpers.h was not found
after I
On Thu, Apr 27, 2006 at 09:24:42AM +0200, Georg Baum wrote:
In any case, all magic should go to interpret() Co., not to
LCursor::plainInsert().
That works for one-character delimiters, but not for things like \Vert. It
should be possible to introduce a second interpret method that is
On Thu, Apr 27, 2006 at 09:55:20AM +0200, Georg Baum wrote:
Hm, so then there is some hardcoded trickery to show symbols like
\alpha somewhere.
Somthing like that existed at least at some point of time.
It does still exist, but the method is called infoize2. The attached works
and
On Thu, Apr 27, 2006 at 05:40:25PM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
Well, here is the result of my effort. I also attach separately a diff
against src/frontends/qt3/ui/moc/Makefile.in and
src/frontends/qt3/moc/Makefile.in as svn diff doesn't seem to have
catched them. I
On Thu, Apr 27, 2006 at 05:24:07PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri a écrit :
On Thu, Apr 27, 2006 at 10:42:58AM +0200, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
Georg == Georg Baum
[EMAIL PROTECTED]
writes:
Georg If you want I'll revert the changes to plainInsert,
Enrico Forestieri [EMAIL PROTECTED] writes:
| On Thu, Apr 27, 2006 at 05:40:25PM +0200, Georg Baum wrote:
| Enrico Forestieri wrote:
|
| Well, here is the result of my effort. I also attach separately a diff
| against src/frontends/qt3/ui/moc/Makefile.in and
|
On Thursday 27 April 2006 20:14, Enrico Forestieri wrote:
Do you mean that Makefile.in is deliberately ignored and that only
Makefile.am needs modifications? (Yes, I am an ignorant but well
supported by a bit of logic ;-) )
This even I know the answer ;-)
Makefile.am is transformed by
On Thu, Apr 27, 2006 at 09:56:07PM +0200, Lars Gullik Bjønnes wrote:
Enrico Forestieri [EMAIL PROTECTED] writes:
| On Thu, Apr 27, 2006 at 05:40:25PM +0200, Georg Baum wrote:
| Enrico Forestieri wrote:
|
| Well, here is the result of my effort. I also attach separately a diff
|
On Thu, Apr 27, 2006 at 08:59:49PM +0100, Jose' Matos wrote:
On Thursday 27 April 2006 20:14, Enrico Forestieri wrote:
Do you mean that Makefile.in is deliberately ignored and that only
Makefile.am needs modifications? (Yes, I am an ignorant but well
supported by a bit of logic ;-) )
Andre Poenitz wrote:
> Restricting input in cell is something we stubled over already in e.g.
> the number of macro arguments.
>
> So it looks like some generic solution is wanted, i.e. something like a
> 'cell property'.
This is not the only problem: If we made the delimiter a cell we would
Jean-Marc Lasgouttes wrote:
>> "Georg" == Georg Baum
>> <[EMAIL PROTECTED]>
>> writes:
>
> Georg> If you want I'll revert the changes to plainInsert, but I am
> Georg> not going to implement the cell based solution, since I don't
> Georg> like it UI-wise at all.
>
> What do you want
Andre Poenitz wrote:
> On Wed, Apr 26, 2006 at 09:30:51AM +0200, Georg Baum wrote:
>> Andre Poenitz wrote:
>> > Is it? I thought also the item to the left or right was considered.
>>
>> Then the attached patch should make it work, but it does not.
>
> Hm, so then there is some hardcoded
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> If you want I'll revert the changes to plainInsert, but I am
Georg> not going to implement the cell based solution, since I don't
Georg> like it UI-wise at all.
What do you want to do UI-wise?
JMarc
On Thu, Apr 27, 2006 at 10:42:58AM +0200, Georg Baum wrote:
> Jean-Marc Lasgouttes wrote:
>
> >> "Georg" == Georg Baum
> >> <[EMAIL PROTECTED]>
> >> writes:
> >
> > Georg> If you want I'll revert the changes to plainInsert, but I am
> > Georg> not going to implement the cell based
Enrico Forestieri a écrit :
On Thu, Apr 27, 2006 at 10:42:58AM +0200, Georg Baum wrote:
Jean-Marc Lasgouttes wrote:
"Georg" == Georg Baum
<[EMAIL PROTECTED]>
writes:
Georg> If you want I'll revert the changes to plainInsert, but I am
Georg> not going to implement the cell based solution,
Enrico Forestieri wrote:
> Well, here is the result of my effort. I also attach separately a diff
> against src/frontends/qt3/ui/moc/Makefile.in and
> src/frontends/qt3/moc/Makefile.in as "svn diff" doesn't seem to have
> catched them. I had to patch them because "qt_helpers.h" was not found
>
On Thu, Apr 27, 2006 at 09:24:42AM +0200, Georg Baum wrote:
> > In any case, all magic should go to interpret() & Co., not to
> > LCursor::plainInsert().
>
> That works for one-character delimiters, but not for things like \Vert. It
> should be possible to introduce a second interpret method that
On Thu, Apr 27, 2006 at 09:55:20AM +0200, Georg Baum wrote:
> > Hm, so then there is some hardcoded trickery to show symbols like
> > \alpha somewhere.
> >
> > Somthing like that existed at least at some point of time.
>
> It does still exist, but the method is called infoize2. The attached
On Thu, Apr 27, 2006 at 05:40:25PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > Well, here is the result of my effort. I also attach separately a diff
> > against src/frontends/qt3/ui/moc/Makefile.in and
> > src/frontends/qt3/moc/Makefile.in as "svn diff" doesn't seem to have
> >
On Thu, Apr 27, 2006 at 05:24:07PM +0200, Abdelrazak Younes wrote:
> Enrico Forestieri a écrit :
> >On Thu, Apr 27, 2006 at 10:42:58AM +0200, Georg Baum wrote:
> >>Jean-Marc Lasgouttes wrote:
> >>
> "Georg" == Georg Baum
> <[EMAIL PROTECTED]>
> writes:
> >>>Georg> If you
Enrico Forestieri <[EMAIL PROTECTED]> writes:
| On Thu, Apr 27, 2006 at 05:40:25PM +0200, Georg Baum wrote:
| > Enrico Forestieri wrote:
| >
| > > Well, here is the result of my effort. I also attach separately a diff
| > > against src/frontends/qt3/ui/moc/Makefile.in and
| > >
On Thursday 27 April 2006 20:14, Enrico Forestieri wrote:
> Do you mean that Makefile.in is deliberately ignored and that only
> Makefile.am needs modifications? (Yes, I am an ignorant but well
> supported by a bit of logic ;-) )
This even I know the answer ;-)
Makefile.am is transformed by
On Thu, Apr 27, 2006 at 09:56:07PM +0200, Lars Gullik Bjønnes wrote:
> Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> | On Thu, Apr 27, 2006 at 05:40:25PM +0200, Georg Baum wrote:
> | > Enrico Forestieri wrote:
> | >
> | > > Well, here is the result of my effort. I also attach separately a
On Thu, Apr 27, 2006 at 08:59:49PM +0100, Jose' Matos wrote:
> On Thursday 27 April 2006 20:14, Enrico Forestieri wrote:
> > Do you mean that Makefile.in is deliberately ignored and that only
> > Makefile.am needs modifications? (Yes, I am an ignorant but well
> > supported by a bit of logic ;-) )
Andre Poenitz wrote:
On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
That is not possible with this approach, since the status line info is
only obtained if the cursor is inside an inset.
Is it? I thought also the item to the left or right was considered.
Then the attached
Andre Poenitz wrote:
Doing special case mathed stuff is not the business of LCursor.
I know that there is already mathed related stuff there but that
does not make it any better.
Moreover, _plainInsert_ is intended to insert stuff without any fuss.
So what else do you propose? I know
On Wed, Apr 26, 2006 at 09:32:59AM +0200, Georg Baum wrote:
Andre Poenitz wrote:
Doing special case mathed stuff is not the business of LCursor.
I know that there is already mathed related stuff there but that
does not make it any better.
Moreover, _plainInsert_ is intended to
On Wed, Apr 26, 2006 at 09:30:51AM +0200, Georg Baum wrote:
Andre Poenitz wrote:
On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
That is not possible with this approach, since the status line info is
only obtained if the cursor is inside an inset.
Is it? I thought also
Andre Poenitz wrote:
> On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
>> That is not possible with this approach, since the status line info is
>> only obtained if the cursor is inside an inset.
>
> Is it? I thought also the item to the left or right was considered.
Then the
Andre Poenitz wrote:
> Doing special case mathed stuff is not the business of LCursor.
>
> I know that there is already mathed related stuff there but that
> does not make it any better.
>
> Moreover, _plainInsert_ is intended to insert stuff without any fuss.
So what else do you propose? I
On Wed, Apr 26, 2006 at 09:32:59AM +0200, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > Doing special case mathed stuff is not the business of LCursor.
> >
> > I know that there is already mathed related stuff there but that
> > does not make it any better.
> >
> > Moreover, _plainInsert_ is
On Wed, Apr 26, 2006 at 09:30:51AM +0200, Georg Baum wrote:
> Andre Poenitz wrote:
>
> > On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
> >> That is not possible with this approach, since the status line info is
> >> only obtained if the cursor is inside an inset.
> >
> > Is it? I
On Sat, Apr 15, 2006 at 10:22:21AM +0200, Lars Gullik Bjønnes wrote:
| if (s == tfrac)
| return MathAtom(new MathTfracInset);
| + if (s == hphantom)
| + return MathAtom(new
MathPhantomInset(MathPhantomInset::hphantom));
Eventually something must be done with
On Sat, Apr 15, 2006 at 07:49:25PM +0200, Georg Baum wrote:
The alternative to this approach (storing the delimiter as uneditable
string) would be to make the delimiter a normal cell. The advantage of
that is that MathNestInset and LCursor don't need to be touched, but the
disadvantage
On Thu, Apr 20, 2006 at 11:55:38AM +0200, Georg Baum wrote:
Make MathBigInset working
* src/cursor.C
(LCursor::plainInsert): combine the previous math atom with the new
one to a MathBigInset if possible
Doing special case mathed stuff is not the business of LCursor.
I
On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
That is not possible with this approach, since the status line info is
only obtained if the cursor is inside an inset.
Is it? I thought also the item to the left or right was considered.
Andre'
On Thu, Apr 20, 2006 at 03:54:24PM +0200, Enrico Forestieri wrote:
On Thu, Apr 20, 2006 at 11:55:38AM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
I am not able to generate a bigger { by \bigl\{ in mathed (I must
use \bigl\lbrace for that) because I think that the code dealing
On Sat, Apr 15, 2006 at 10:22:21AM +0200, Lars Gullik Bjønnes wrote:
> | if (s == "tfrac")
> | return MathAtom(new MathTfracInset);
> | + if (s == "hphantom")
> | + return MathAtom(new
> MathPhantomInset(MathPhantomInset::hphantom));
>
> Eventually something must be
On Sat, Apr 15, 2006 at 07:49:25PM +0200, Georg Baum wrote:
> The alternative to this approach (storing the delimiter as uneditable
> string) would be to make the delimiter a normal cell. The advantage of
> that is that MathNestInset and LCursor don't need to be touched, but the
> disadvantage
On Thu, Apr 20, 2006 at 11:55:38AM +0200, Georg Baum wrote:
> Make MathBigInset working
> * src/cursor.C
> (LCursor::plainInsert): combine the previous math atom with the new
> one to a MathBigInset if possible
Doing special case mathed stuff is not the business of
On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
> That is not possible with this approach, since the status line info is
> only obtained if the cursor is inside an inset.
Is it? I thought also the item to the left or right was considered.
Andre'
On Thu, Apr 20, 2006 at 03:54:24PM +0200, Enrico Forestieri wrote:
> On Thu, Apr 20, 2006 at 11:55:38AM +0200, Georg Baum wrote:
> > Enrico Forestieri wrote:
> >
> > > I am not able to generate a bigger "{" by "\bigl\{" in mathed (I must
> > > use "\bigl\lbrace" for that) because I think that the
Georg Baum [EMAIL PROTECTED] writes:
| Angus Leeming wrote:
|
| The .ui files were all generated and maintained with Qt2's designer, yes.
| However, LyX 1.5 has dropped support for Qt2 so you should feel free to
| use Qt3's designer with the .ui files in the qt2 tree. Perhaps someone
|
Lars Gullik Bjønnes wrote:
Georg Baum [EMAIL PROTECTED]
writes:
| Angus Leeming wrote:
|
| The .ui files were all generated and maintained with Qt2's designer,
| yes.
| However, LyX 1.5 has dropped support for Qt2 so you should feel free
| to use Qt3's designer with the .ui files
Georg Baum <[EMAIL PROTECTED]> writes:
| Angus Leeming wrote:
|
| > The .ui files were all generated and maintained with Qt2's designer, yes.
| > However, LyX 1.5 has dropped support for Qt2 so you should feel free to
| > use Qt3's designer with the .ui files in the qt2 tree. Perhaps someone
|
Lars Gullik Bjønnes wrote:
> Georg Baum <[EMAIL PROTECTED]>
> writes:
>
> | Angus Leeming wrote:
> |
> | > The .ui files were all generated and maintained with Qt2's designer,
> | > yes.
> | > However, LyX 1.5 has dropped support for Qt2 so you should feel free
> | > to use Qt3's designer with
Enrico Forestieri [EMAIL PROTECTED] writes:
Perhaps the old file was generated with an older designer and I don't
know if my changes would be compatible with Qt2.
The .ui files were all generated and maintained with Qt2's designer, yes.
However, LyX 1.5 has dropped support for Qt2 so you
Angus Leeming wrote:
The .ui files were all generated and maintained with Qt2's designer, yes.
However, LyX 1.5 has dropped support for Qt2 so you should feel free to
use Qt3's designer with the .ui files in the qt2 tree. Perhaps someone
might rename the qt2 directory as qt3 to avoid
Enrico Forestieri <[EMAIL PROTECTED]> writes:
> Perhaps the old file was generated with an older designer and I don't
> know if my changes would be compatible with Qt2.
The .ui files were all generated and maintained with Qt2's designer, yes.
However, LyX 1.5 has dropped support for Qt2 so you
Angus Leeming wrote:
> The .ui files were all generated and maintained with Qt2's designer, yes.
> However, LyX 1.5 has dropped support for Qt2 so you should feel free to
> use Qt3's designer with the .ui files in the qt2 tree. Perhaps someone
> might rename the qt2 directory as qt3 to avoid
Enrico Forestieri wrote:
That's strange. I see the same thing in Windows, Debian and Solaris.
It is independent of the fonts chosen for display.
Now I see that you meant \{ etc without \bigl. This is the same here. The
reason is that \lbrace and \rbrace are recognized as a symbol of the cmsy
On Fri, Apr 21, 2006 at 09:17:43AM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
That's strange. I see the same thing in Windows, Debian and Solaris.
It is independent of the fonts chosen for display.
Now I see that you meant \{ etc without \bigl. This is the same here. The
reason
On Thu, Apr 20, 2006 at 06:56:57PM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
This is perfect! I tested it and think that this should also go in 1.4.
Jean-Marc will tell. What is missing now is support for these in the math
panel. It should not be too difficult to add, I would
Enrico Forestieri wrote:
You mean it's a 1.4 regression, I suppose :(
Ah yes, I forgot already that we had tt font in 1.3.
Georg
PS: It's no smiley day.
Enrico Forestieri wrote:
I thought about it and my idea is to retain the existing delimiter
dialog but placing a combobox next to the Keep matched checkbox.
The default combobox item would be Variable size, and the other
items would be labeled big size, Big size, and so on.
For example.
On Fri, Apr 21, 2006 at 04:54:57PM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
I thought about it and my idea is to retain the existing delimiter
dialog but placing a combobox next to the Keep matched checkbox.
The default combobox item would be Variable size, and the other
items
Enrico Forestieri wrote:
> That's strange. I see the same thing in Windows, Debian and Solaris.
> It is independent of the fonts chosen for display.
Now I see that you meant \{ etc without \bigl. This is the same here. The
reason is that \lbrace and \rbrace are recognized as a symbol of the cmsy
On Fri, Apr 21, 2006 at 09:17:43AM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > That's strange. I see the same thing in Windows, Debian and Solaris.
> > It is independent of the fonts chosen for display.
>
> Now I see that you meant \{ etc without \bigl. This is the same here. The
>
On Thu, Apr 20, 2006 at 06:56:57PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > This is perfect! I tested it and think that this should also go in 1.4.
>
> Jean-Marc will tell. What is missing now is support for these in the math
> panel. It should not be too difficult to add, I
Enrico Forestieri wrote:
> You mean it's a 1.4 regression, I suppose :(
Ah yes, I forgot already that we had tt font in 1.3.
Georg
PS: It's no smiley day.
Enrico Forestieri wrote:
> I thought about it and my idea is to retain the existing delimiter
> dialog but placing a combobox next to the "Keep matched" checkbox.
> The default combobox item would be "Variable size", and the other
> items would be labeled "big size", "Big size", and so on.
For
On Fri, Apr 21, 2006 at 04:54:57PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > I thought about it and my idea is to retain the existing delimiter
> > dialog but placing a combobox next to the "Keep matched" checkbox.
> > The default combobox item would be "Variable size", and the
Enrico Forestieri wrote:
I am not able to generate a bigger { by \bigl\{ in mathed (I must
use \bigl\lbrace for that) because I think that the code dealing
with \bigl has not a chance of viewing \{, being it transformed to {}.
This is currently beyond my capabilities (but I continue
On Thu, Apr 20, 2006 at 11:55:38AM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
I am not able to generate a bigger { by \bigl\{ in mathed (I must
use \bigl\lbrace for that) because I think that the code dealing
with \bigl has not a chance of viewing \{, being it transformed to {}.
Enrico Forestieri wrote:
This is perfect! I tested it and think that this should also go in 1.4.
Jean-Marc will tell. What is missing now is support for these in the math
panel. It should not be too difficult to add, I would simply make a copy of
the existing delimiters dialog. The images are
On Thu, Apr 20, 2006 at 06:56:57PM +0200, Georg Baum wrote:
Enrico Forestieri wrote:
This is perfect! I tested it and think that this should also go in 1.4.
Jean-Marc will tell. What is missing now is support for these in the math
panel. It should not be too difficult to add, I would
Enrico Forestieri wrote:
> I am not able to generate a bigger "{" by "\bigl\{" in mathed (I must
> use "\bigl\lbrace" for that) because I think that the code dealing
> with \bigl has not a chance of viewing \{, being it transformed to {}.
> This is currently beyond my capabilities (but I continue
On Thu, Apr 20, 2006 at 11:55:38AM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > I am not able to generate a bigger "{" by "\bigl\{" in mathed (I must
> > use "\bigl\lbrace" for that) because I think that the code dealing
> > with \bigl has not a chance of viewing \{, being it
Enrico Forestieri wrote:
> This is perfect! I tested it and think that this should also go in 1.4.
Jean-Marc will tell. What is missing now is support for these in the math
panel. It should not be too difficult to add, I would simply make a copy of
the existing delimiters dialog. The images are
On Thu, Apr 20, 2006 at 06:56:57PM +0200, Georg Baum wrote:
> Enrico Forestieri wrote:
>
> > This is perfect! I tested it and think that this should also go in 1.4.
>
> Jean-Marc will tell. What is missing now is support for these in the math
> panel. It should not be too difficult to add, I
On Tue, Apr 18, 2006 at 07:06:10AM +0200, Enrico Forestieri wrote:
On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
Am Montag, 17. April 2006 18:24 schrieb Enrico Forestieri:
It would also be nice having a report in the status line about the
size of the delimiter when the
On Tue, Apr 18, 2006 at 07:06:10AM +0200, Enrico Forestieri wrote:
> On Mon, Apr 17, 2006 at 08:57:54PM +0200, Georg Baum wrote:
>
> > Am Montag, 17. April 2006 18:24 schrieb Enrico Forestieri:
>
> > > It would also be nice having a report in the status line about the
> > > size of the
Am Sonntag, 16. April 2006 00:02 schrieb Enrico Forestieri:
I think that your approach is the correct the one. The patch works,
but the dimension of \bigl( is a bit smaller of ( on screen and
this seems odd. Perhaps a tuning is needed.
Have a look at MathBigInset::increase(). What would you
Am Sonntag, 16. April 2006 11:59 schrieb Lars Gullik Bjønnes:
Georg Baum [EMAIL PROTECTED] writes:
| Am Samstag, 15. April 2006 10:22 schrieb Lars Gullik Bjønnes:
| Eventually something must be done with this if .. if ... if list
|
| Using a map or an unordered_map seems like a
1 - 100 of 128 matches
Mail list logo
