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
Dear all,
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.
The attached patch:
1. Adds a default Text "unknown" layout in the construc
29 matches
Mail list logo
