[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lyx-devel
Subject:    Re: More eye candy
From:       Jean-Marc Lasgouttes <lasgouttes () freesurf ! fr>
Date:       2002-03-28 10:09:51
[Download RAW message or body]

>>>>> "John" == John Levon <levon@movementarian.org> writes:

>> I thought that all toolbar in KDE apps were supposed to be setable
>> by the user as floating top, bottom, whatever... However, we could
>> have

John> right, but it is up to the app to store the state of the session
John> ...

Feel free to have a qt2-specific pref file. Angus already did that for
setting xforms-specific colors.

John> I don't get you. I am trying to /expand/ a menu. This will crash
John> if there's no buffer currently : see expand:ExportFormats

John> besides, the menu code should not know about buffers, readonly
John> etc. - the core should provide only enabled/disabled info for
John> this. (as it does now afaik)

I see now. Why did not yoou say it upfront: there is a bug in
Menubackend::expand! It should be fixed in cvs.

Undoubtedly, you will find many of those, since you are bound to do
things differently that what I did.

>> Yes, but we will have to eventually find a solution.

John> couldn't we connecto to Angu's updateParagraph signal ? That
John> seems good enough doesn't it ? Or does it not do what it sounds
John> like ?

Maybe, I do not know this code.

>> Convince me.

John> I would if I was sure myself ...

That's the point. I am not either.

John> I certainly think we can take a signal approach for say,
John> lastfiles. It's easy to do and not intrusive I don't think.

Don't bother with it. generating this does not cost anything. The only
proble is with the various TOCS, I think (although I'd like to have
hard numbers on a large file: how much does TOC generation cost?). 

If menubackend where to cache the TOCS, using some signal, would
regenerating the menus at each Menu::update() really cost too much?
The time will depend on the number of headings, not number of
paragraphs in document.

JMarc

[prev in list] [next in list] [prev in thread] [next in thread]