rgheck <[EMAIL PROTECTED]> writes:
> I think maybe you're extending the wrong thing, then. The extended
> layouts should go into the DocumentClass object associated with the
> Buffer, rather than into the LayoutFile object. I think that will
> "just work".
Very interesting indeed. Thanks.
JMarc
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> This is why the paragraph should store the name of the layout, and the
>> pointer should just be a cache (that gets populated on demand, maybe).
>> There is of course a memory overhead, but this has to be evaluated.
>
> I do not know, these changes might be
Jean-Marc Lasgouttes wrote:
"Bo Peng" <[EMAIL PROTECTED]> writes:
I do not really understand why you need to create several unknown
layouts. Each textclass should have its own.
Currently, I extend a standard textclass such as article when it is
applied to another document. This exten
Bo Peng wrote:
I do not really understand why you need to create several unknown
layouts. Each textclass should have its own.
Currently, I extend a standard textclass such as article when it is
applied to another document. This extended layout list is then
available when a standard article
> Can't you just rename the merged layouts into something like
> 'OtherUnknown', 'OtherList' or whatever.
When I write the document back, I would like to keep the layout names.
Bo
On Tue, Jul 08, 2008 at 10:59:12AM -0500, Bo Peng wrote:
> > I do not really understand why you need to create several unknown
> > layouts. Each textclass should have its own.
>
> Currently, I extend a standard textclass such as article when it is
> applied to another document. This extended layou
> This is why the paragraph should store the name of the layout, and the
> pointer should just be a cache (that gets populated on demand, maybe).
> There is of course a memory overhead, but this has to be evaluated.
I do not know, these changes might be too big for 1.6.0. I will
propose a patch as
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> I do not really understand why you need to create several unknown
>> layouts. Each textclass should have its own.
>
> Currently, I extend a standard textclass such as article when it is
> applied to another document. This extended layout list is then
> avai
> I do not really understand why you need to create several unknown
> layouts. Each textclass should have its own.
Currently, I extend a standard textclass such as article when it is
applied to another document. This extended layout list is then
available when a standard article is created. The pr
"Bo Peng" <[EMAIL PROTECTED]> writes:
>> If you can get it to work properly, this is definitely the way to go.
>> This shall be done for unknown classes and for unknown layouts.
>
> I have it almost working here, but there are some subtle problems such
> as when two 'article' documents having some
>
> If you can get it to work properly, this is definitely the way to go.
> This shall be done for unknown classes and for unknown layouts.
I have it almost working here, but there are some subtle problems such
as when two 'article' documents having some different 'unknown'
layouts. Currently, the
"Bo Peng" <[EMAIL PROTECTED]> writes:
> Will anyone object the idea of totally removing hasLayout() and the
> layout conversion process? Basically, any unknown textclass and
> unknown layout will act like a standard layout but will keep their
> names. Different textclasses can be applied to a docum
> Currently, when a LyX document without a proper (system or local)
> layout file is opened, the default textclass (article) is used. This
> changes the document and will result in data loss if the document is
> saved.
Will anyone object the idea of totally removing hasLayout() and the
layout conv
> There is a risk for sure and a profiling session would be required if we
> switch to name based access. But the bottlenecks of years back may have
> disappeared now.
I do not see anything wrong with a pointer based system as long as we
use a container that will not invalidate these pointers. st
[EMAIL PROTECTED] wrote:
rgheck <[EMAIL PROTECTED]> writes:
Yes, I'm not at all sure how often we actually need to access a
paragraph's layout. And I thought about converting LayoutList to a
map a while ago, but didn't do it. And index-based access is
also worth a thought, too. That would be
[EMAIL PROTECTED] wrote:
rgheck <[EMAIL PROTECTED]> writes:
Yes, I'm not at all sure how often we actually need to access a
paragraph's layout. And I thought about converting LayoutList to a
map a while ago, but didn't do it. And index-based access is
also worth a thought, too. That would be
rgheck <[EMAIL PROTECTED]> writes:
> Yes, I'm not at all sure how often we actually need to access a
> paragraph's layout. And I thought about converting LayoutList to a
> map a while ago, but didn't do it. And index-based access is
> also worth a thought, too. That would be OK, as long as we only
Abdelrazak Younes wrote:
Bo Peng wrote:
This makes the use of layout pointers seem kind of fragile. Maybe we
should just store the name of the layout instead, and then use
TextClass::operator[] to find the layout when we need it. There may
be other
benefits to doing it that way, too.
If
>> The performance impact will be big because this layout pointer is used
>> everywhere. Even storing layout index is better than storing their
>> names.
>
> Using names would mean a map or a hash table (better) instead of a vector
> (which could lead to index based access). Maybe the perfomance im
Bo Peng wrote:
This makes the use of layout pointers seem kind of fragile. Maybe we
should just store the name of the layout instead, and then use
TextClass::operator[] to find the layout when we need it. There may be other
benefits to doing it that way, too.
If there's no performance pro
>> This makes the use of layout pointers seem kind of fragile. Maybe we
>> should just store the name of the layout instead, and then use
>> TextClass::operator[] to find the layout when we need it. There may be other
>> benefits to doing it that way, too.
>
> If there's no performance problem, tha
"Bo Peng" <[EMAIL PROTECTED]> writes:
> 1. A document without valid layout will be opened with a warning. (The same)
> 2. All layouts are usable, although they all look like "standard" (changed)
> 3. Save such a document will not lose data. The original layout name
> will be used. (improved)
> 4.
rgheck wrote:
Bo Peng wrote:
The biggest problem with this patch is that because layout pointers
are used directly, LayoutList, which is std:;vector can not be
expanded dynamically. I change it to std::list to allow
dynamic growth of the "unknown" textclass but this may lead to
performance pro
Bo Peng wrote:
The biggest problem with this patch is that because layout pointers
are used directly, LayoutList, which is std:;vector can not be
expanded dynamically. I change it to std::list to allow
dynamic growth of the "unknown" textclass but this may lead to
performance problems.
> This looks like a sensible approach in general. Is the document class then
> not reset? So if I have ClassX, and this is not found, will LyX keep this
> ClassX unless I manually switch to another class? (This is the way it
> should be IMHO).
Yes. All layouts are kept, although the textclass is n
>> 4. Another layout can be chosen from Document -> settings, if a
>> correct textclass is selected, all layouts will work fine. (improved,
>> because the current approach will change some unknown layouts to
>> standard.)
>>
>
> I think this is not enough. If the local layout is to be supported, th
Bo Peng wrote:
> 1. A document without valid layout will be opened with a warning. (The
> same) 2. All layouts are usable, although they all look like "standard"
> (changed) 3. Save such a document will not lose data. The original layout
> name will be used. (improved)
> 4. Another layout can be c
Bo Peng wrote:
Dear all,
3. Use this expandable "unknown" layout for a document without valid layout.
} else {
// a warning will be given for unknown class
- setBaseClass(defaultBaseclass());
+ setBaseClass(unk
28 matches
Mail list logo
