Andre Poenitz schrieb:
On Sun, Mar 18, 2007 at 06:26:27PM +0100, Michael Gerz wrote:
The difficulties are partly caused by the many helper methods that
result in a high degree of indirection. It is very difficult to get to
the core. Less (similar) methods would be better.
I am open fo
On Sun, Mar 18, 2007 at 06:26:27PM +0100, Michael Gerz wrote:
> The difficulties are partly caused by the many helper methods that
> result in a high degree of indirection. It is very difficult to get to
> the core. Less (similar) methods would be better.
I am open for concrete proposals.
Andre
Abdelrazak Younes schrieb:
Andre Poenitz wrote:
On Thu, Mar 15, 2007 at 06:36:15PM +0100, Abdelrazak Younes wrote:
My point is that is not equivalent. A tree-like approach will
inevitably lead to cleaner and shorter code, I am 100% sure of that.
Besides, I still have difficulty to grasp the cu
On Fri, Mar 16, 2007 at 10:46:57AM +0100, Abdelrazak Younes wrote:
> >It surely has. In the main inset go down to cell slice[0].cell, walk
> >down to paragraph slice[0].pit, go to pos slice[0].pos, Take the inset
> >there. Go to its cell slice[1].cell, paragraph slice[1].pit, position
> >slice[1].p
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am fine with this. I've done it because that's the current behaviour
in 1.4.x.
Only partially. If you put a section in a tabular float and insert a label,
you get the "sec:" prefix (as it should be).
So shall I commit only the caption pa
Georg Baum wrote:
Abdelrazak Younes wrote:
Are you saying that the chosen prefix (sub: in this case) is used by
Prettyref?
Yes. That is the main reason to use these prefixes. So this _is_ about what
is on printed text. Of course it would be nice if it would be possible to
distinguish further.
Abdelrazak Younes wrote:
> Are you saying that the chosen prefix (sub: in this case) is used by
> Prettyref?
Yes. That is the main reason to use these prefixes. So this _is_ about what
is on printed text. Of course it would be nice if it would be possible to
distinguish further. But that means to
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am wondering, for subsection, wouldn't it be better to use "ssec" for
example and "sssec:" for subsubsection?
That could be configurable, but by default, no. Prettyref only supports
the "sec" prefix (by default), and I would not refer to "S
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> Abdelrazak Younes wrote:
>> I am wondering, for subsection, wouldn't it be better to use "ssec"
>> for example and "sssec:" for subsubsection?
Jürgen> That could be configurable, but by default, no. Prettyref only
Jürgen> su
Abdelrazak Younes wrote:
> I am wondering, for subsection, wouldn't it be better to use "ssec" for
> example and "sssec:" for subsubsection?
That could be configurable, but by default, no. Prettyref only supports
the "sec" prefix (by default), and I would not refer to "Subsection x.x" in
text, b
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
But that does not solve the nested inset problem, does it?
It does.
OK, fine with me then.
OK, I committed a cleanup version that will allow to add more types easily.
I am wondering, for subsection, wouldn't it be better to use "ssec" for
Abdelrazak Younes wrote:
> > But that does not solve the nested inset problem, does it?
>
> It does.
OK, fine with me then.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I am fine with this. I've done it because that's the current behaviour
in 1.4.x.
Only partially. If you put a section in a tabular float and insert a label,
you get the "sec:" prefix (as it should be).
So shall I commit only the caption pa
Abdelrazak Younes wrote:
> I am fine with this. I've done it because that's the current behaviour
> in 1.4.x.
Only partially. If you put a section in a tabular float and insert a label,
you get the "sec:" prefix (as it should be).
> So shall I commit only the caption part?
But that does not s
Andre Poenitz wrote:
On Thu, Mar 15, 2007 at 06:36:15PM +0100, Abdelrazak Younes wrote:
My point is that is not equivalent. A tree-like approach will inevitably
lead to cleaner and shorter code, I am 100% sure of that. Besides, I
still have difficulty to grasp the cursor slice concept. Make a p
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
With my last patch we don't need to check explicitly for the
LABEL_SENSITIVE because everything within a float (or a wrap) will get
the label prefix, LABEL_SENSITIVE or not.
I don't think that's a good idea. There might be other things than th
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
With my last patch we don't need to check explicitly for the
LABEL_SENSITIVE because everything within a float (or a wrap) will get
the label prefix, LABEL_SENSITIVE or not.
I don't think that's a good idea. There might be other things than th
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> Abdelrazak Younes wrote:
>> With my last patch we don't need to check explicitly for the
>> LABEL_SENSITIVE because everything within a float (or a wrap) will
>> get the label prefix, LABEL_SENSITIVE or not.
Jürgen> I don't
Abdelrazak Younes wrote:
> With my last patch we don't need to check explicitly for the
> LABEL_SENSITIVE because everything within a float (or a wrap) will get
> the label prefix, LABEL_SENSITIVE or not.
I don't think that's a good idea. There might be other things than the caption
inside floats
On Thu, Mar 15, 2007 at 06:36:15PM +0100, Abdelrazak Younes wrote:
> My point is that is not equivalent. A tree-like approach will inevitably
> lead to cleaner and shorter code, I am 100% sure of that. Besides, I
> still have difficulty to grasp the cursor slice concept. Make a poll in
> the lis
Am Donnerstag, 15. März 2007 20:06 schrieb Abdelrazak Younes:
> With my last patch we don't need to check explicitly for the
> LABEL_SENSITIVE because everything within a float (or a wrap) will get
> the label prefix, LABEL_SENSITIVE or not.
Now I understand. Does anybody know why the check for
Georg Baum wrote:
Am Donnerstag, 15. März 2007 19:53 schrieb Abdelrazak Younes:
Georg Baum wrote:
I don't understand how it works. Why is the test for
LABEL_SENSITIVE no longer needed?
Because there is no paragraph with LABEL_SENSITIVE layout any more
within the float.
No! This is not true
Am Donnerstag, 15. März 2007 19:53 schrieb Abdelrazak Younes:
> Georg Baum wrote:
> > I don't understand how it works. Why is the test for
> > LABEL_SENSITIVE no longer needed?
>
> Because there is no paragraph with LABEL_SENSITIVE layout any more
> within the float.
No! This is not true, as I
Georg Baum wrote:
Am Donnerstag, 15. März 2007 19:27 schrieb Abdelrazak Younes:
My newer patch fixes this I think.
If it does
it does.
I don't understand how it works. Why is the test for
LABEL_SENSITIVE no longer needed?
Because there is no paragraph with LABEL_SENSITIVE layout any mor
Am Donnerstag, 15. März 2007 19:27 schrieb Abdelrazak Younes:
> My newer patch fixes this I think.
If it does I don't understand how it works. Why is the test for
LABEL_SENSITIVE no longer needed?
Georg
Georg Baum wrote:
Am Donnerstag, 15. März 2007 18:41 schrieb Abdelrazak Younes:
Anyway, I agree that something like the attached (not tested) should
solve the current caption label problem.
At the cost of introducing the same problem for LABEL_SENSITIVE layouts,
e.g. Captionbelow of scrclass
Abdelrazak Younes wrote:
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes
<[EMAIL PROTECTED]> writes:
And if anybody forgot: Now is not the time to make such decisions
or even to discuss them. There are plenty of open bugs and
regressions with 1.5.0 target in bugzilla.
Abdelra
Am Donnerstag, 15. März 2007 18:41 schrieb Abdelrazak Younes:
> Anyway, I agree that something like the attached (not tested) should
> solve the current caption label problem.
At the cost of introducing the same problem for LABEL_SENSITIVE layouts,
e.g. Captionbelow of scrclass.inc. If you fix
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
And if anybody forgot: Now is not the time to make such decisions
or even to discuss them. There are plenty of open bugs and
regressions with 1.5.0 target in bugzilla.
Abdelrazak> OK, let's postpone th
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
I do not see why you want to find a suboptimal method which only
interest is to fit some theory of yours.
Abdelrazak> My theory is simple: use what we have access to. Scanning
Abdelrazak> all the enclos
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> I do not see why you want to find a suboptimal method which only
>> interest is to fit some theory of yours.
Abdelrazak> My theory is simple: use what we have access to. Scanning
Abdelrazak> all the enclosing inset in search f
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> And if anybody forgot: Now is not the time to make such decisions
>> or even to discuss them. There are plenty of open bugs and
>> regressions with 1.5.0 target in bugzilla.
Abdelrazak> OK, let's postpone the discussion to 1.
Georg Baum wrote:
Abdelrazak Younes wrote:
I miss some info about point 3 (KOMA-Script) and 4 (layout appearance)
to properly decide if it is difficult or not to implement.
I added a bit of information. This is how I think it could be implemehted,
Thanks.
if you have a better way please e
Abdelrazak Younes wrote:
> I miss some info about point 3 (KOMA-Script) and 4 (layout appearance)
> to properly decide if it is difficult or not to implement.
I added a bit of information. This is how I think it could be implemehted,
if you have a better way please explain it.
> Maybe we need a
Georg Baum wrote:
Abdelrazak Younes wrote:
Georg Baum wrote:
It would be nice if somebody could make a list of
Les grands esprits se rencontrent ;-)
I even went one step further and created a wiki page for comparison:
http://wiki.lyx.org/Devel/Captions
It would be nice if everybody could
Abdelrazak Younes wrote:
> Georg Baum wrote:
>> It would be nice if somebody could make a list of
>
>
> Les grands esprits se rencontrent ;-)
I even went one step further and created a wiki page for comparison:
http://wiki.lyx.org/Devel/Captions
It would be nice if everybody could fill in his
Georg Baum wrote:
Abdelrazak Younes wrote:
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I understand but I still don't like the scanning... :-)
I don't like it either. But I don't see an alternative yet.
We could just provide the feature if the label is not deeper than
one-level. If t
Jean-Marc Lasgouttes wrote:
"Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I understand but I still don't like the scanning... :-)
I don't like it either. But I don't see an alternative yet.
Abdelrazak> We could
> "Abdelrazak" == Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Abdelrazak> Jürgen Spitzmüller wrote:
>> Abdelrazak Younes wrote:
>>> I understand but I still don't like the scanning... :-)
>> I don't like it either. But I don't see an alternative yet.
Abdelrazak> We could just provide the f
Abdelrazak Younes wrote:
> Jürgen Spitzmüller wrote:
>> Abdelrazak Younes wrote:
>>> I understand but I still don't like the scanning... :-)
>>
>> I don't like it either. But I don't see an alternative yet.
>
> We could just provide the feature if the label is not deeper than
> one-level. If the
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I understand but I still don't like the scanning... :-)
I don't like it either. But I don't see an alternative yet.
We could just provide the feature if the label is not deeper than
one-level. If the user wants to deeply bury the label insi
Abdelrazak Younes wrote:
> I understand but I still don't like the scanning... :-)
I don't like it either. But I don't see an alternative yet.
Jürgen
Jürgen Spitzmüller wrote:
Abdelrazak Younes wrote:
I'd rather do:
- if (layout->labeltype == LABEL_SENSITIVE) {
+ if (cur.innerInsetOfType(InsetBase::CAPTION_CODE) ||
layout->labeltype == LABEL_SENSITIVE) {
Yes. That's what I meant in my previous comment (obviously InsetCaption
derives
Enrico Forestieri wrote:
I would say that when choosing a float thing, it should come up
empty, such that you have to explicitly put the caption in there.
After all, I could well have a floating figure or table without
any caption.
Sure but that's independent of inset versus no inset. I agree t
Andre Poenitz wrote:
On Wed, Mar 14, 2007 at 11:09:03AM +0100, Abdelrazak Younes wrote:
I'd rather do:
- if (layout->labeltype == LABEL_SENSITIVE) {
+ if (cur.innerInsetOfType(InsetBase::CAPTION_CODE) ||
layout->labeltype == LABEL_SENSITIVE) {
Yes. That's what I meant in my previous comm
On Wed, Mar 14, 2007 at 07:22:32PM +0200, Martin Vermeer wrote:
> On Wed, 2007-03-14 at 15:39 +0100, Enrico Forestieri wrote:
> > On Wed, Mar 14, 2007 at 03:18:54PM +0100, Jean-Marc Lasgouttes wrote:
> > > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
> > >
> > > Enrico> One adva
On Wed, 2007-03-14 at 15:39 +0100, Enrico Forestieri wrote:
> On Wed, Mar 14, 2007 at 03:18:54PM +0100, Jean-Marc Lasgouttes wrote:
> > > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
> >
> > Enrico> One advantage is that you get numbered figures on screen.
> >
> > It would have b
On Wed, Mar 14, 2007 at 11:09:03AM +0100, Abdelrazak Younes wrote:
> >I'd rather do:
> >
> >-if (layout->labeltype == LABEL_SENSITIVE) {
> >+if (cur.innerInsetOfType(InsetBase::CAPTION_CODE) ||
> >layout->labeltype == LABEL_SENSITIVE) {
>
> Yes. That's what I meant in my previous comment
On Wed, Mar 14, 2007 at 03:18:54PM +0100, Jean-Marc Lasgouttes wrote:
> > "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
>
> Enrico> One advantage is that you get numbered figures on screen.
>
> It would have been very easy to do even in 1.4; the only reason why I
> did not do it i
> "Enrico" == Enrico Forestieri <[EMAIL PROTECTED]> writes:
Enrico> One advantage is that you get numbered figures on screen.
It would have been very easy to do even in 1.4; the only reason why I
did not do it is because (1) not enough time (2) procrastination about
the syntax to choose in th
Abdelrazak Younes wrote:
> OK, let's list the regressions then:
>
> 1) the automatic label: this should be solved soon easily (and cleanly
> see other thread)
> 2) configurability in the layout file: I am not a layout or latex expert
> (ignorant is a better qualifier for me ;-)), so what exactly is
Abdelrazak Younes wrote:
> > Having said that, the labels could of course also be set a bit less
> > hackish: The inset could return a proper prefix. But this is entails more
> > changes up to the insetbase level.
>
> Which would be a good solution.
But we still need the hacks, as long as we canno
Abdelrazak Younes wrote:
> > I'd rather do:
> >
> > - if (layout->labeltype == LABEL_SENSITIVE) {
> > + if (cur.innerInsetOfType(InsetBase::CAPTION_CODE) ||
> > layout->labeltype == LABEL_SENSITIVE) {
>
> Yes. That's what I meant in my previous comment (obviously InsetCaption
> derives from
Abdelrazak Younes wrote:
I'd rather do:
-if (layout->labeltype == LABEL_SENSITIVE) {
+if (cur.innerInsetOfType(InsetBase::CAPTION_CODE) ||
layout->labeltype == LABEL_SENSITIVE) {
Yes. That's what I meant in my previous comment (obviously InsetCaption
derives from InsetText, not LyXT
Georg Baum wrote:
Enrico Forestieri wrote:
One advantage is that you get numbered figures on screen.
This is actually one part of the code that could also be used for layout
type captions. It was not implemented before, but it could be adapted
easily to layouts.
It would be nice if somebody
Enrico Forestieri wrote:
> One advantage is that you get numbered figures on screen.
This is actually one part of the code that could also be used for layout
type captions. It was not implemented before, but it could be adapted
easily to layouts.
It would be nice if somebody could make a list of
Georg Baum wrote:
Abdelrazak Younes wrote:
Personally I like the inset approach. We just need some more cleanup and
design. I am confident that the benefit will show up in the future so I
am not in favour of reverting it.
In principle I like the inset too, but it looks like it is not as power
Enrico Forestieri wrote:
On Wed, Mar 14, 2007 at 11:02:19AM +0100, Jean-Marc Lasgouttes wrote:
"Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Am Dienstag, 13. März 2007 19:57 schrieb Jürgen Spitzmüller:
The attached patch seems the most easiest way to implement this.
Comments?
Georg
Jean-Marc Lasgouttes wrote:
"Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> The attached patch seems the most easiest way to implement
Jürgen> this. Comments?
I'd rather do:
- if (layout->labeltype == LABEL_SENSITIVE) {
+ if (cur.innerInsetOfType(InsetBase::CAPT
Abdelrazak Younes wrote:
> Personally I like the inset approach. We just need some more cleanup and
> design. I am confident that the benefit will show up in the future so I
> am not in favour of reverting it.
In principle I like the inset too, but it looks like it is not as powerful
as the layou
On Wed, Mar 14, 2007 at 11:02:19AM +0100, Jean-Marc Lasgouttes wrote:
> > "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
>
> Georg> Am Dienstag, 13. März 2007 19:57 schrieb Jürgen Spitzmüller:
> >> The attached patch seems the most easiest way to implement this.
> >> Comments?
>
> Georg> T
> "Georg" == Georg Baum <[EMAIL PROTECTED]> writes:
Georg> Am Dienstag, 13. März 2007 19:57 schrieb Jürgen Spitzmüller:
>> The attached patch seems the most easiest way to implement this.
>> Comments?
Georg> This patch finally convinced me that the move to insets was
Georg> wrong. I am sorry
> "Jürgen" == Jürgen Spitzmüller <[EMAIL PROTECTED]> writes:
Jürgen> The attached patch seems the most easiest way to implement
Jürgen> this. Comments?
I'd rather do:
- if (layout->labeltype == LABEL_SENSITIVE) {
+ if (cur.innerInsetOfType(InsetBase::CAPTION_CODE) || layout->labe
Jürgen Spitzmüller wrote:
The attached patch seems the most easiest way to implement this.
Comments?
Jürgen
Index: src/text.C
===
--- src/text.C (Revision
Jürgen Spitzmüller wrote:
Georg Baum wrote:
This patch finally convinced me that the move to insets was wrong. I am
sorry that I caused others to work on this, but at that time I was not
aware that we would need so many hacks.
Personally, I don't mind if we revert to the caption layout. I don'
Michael Gerz wrote:
> Argh... reverting all caption inset patches will be bloody. We have to
> be VERY careful!
I would not revert these patches, but rather remove the caption inset and
fix all compile errors, readding the old code on a case by case basis.
I know that this is some work, and that
Georg Baum wrote:
> This patch finally convinced me that the move to insets was wrong. I am
> sorry that I caused others to work on this, but at that time I was not
> aware that we would need so many hacks.
Personally, I don't mind if we revert to the caption layout. I don't see any
advantage in
Georg Baum wrote:
This patch finally convinced me that the move to insets was wrong. I am
sorry that I caused others to work on this, but at that time I was not
aware that we would need so many hacks.
Argh... reverting all caption inset patches will be bloody. We have to
be VERY careful!
Am Dienstag, 13. März 2007 19:57 schrieb Jürgen Spitzmüller:
> The attached patch seems the most easiest way to implement this.
> Comments?
This patch finally convinced me that the move to insets was wrong. I am
sorry that I caused others to work on this, but at that time I was not
aware that we
The attached patch seems the most easiest way to implement this.
Comments?
Jürgen
Index: src/text.C
===
--- src/text.C (Revision 17417)
+++ src/text.C (Arbeitskopie)
@@ -1744,8 +1744,18 @@
docstring name = from_ascii(layout->latex
70 matches
Mail list logo
