>>>>> "John" == John Levon <[EMAIL PROTECTED]> 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
