>>>>> "John" == John Levon <[EMAIL PROTECTED]> writes:
>> Should be easy. John> Perhaps you have some idea how. My 3-minute look didn't help me. No, I have no idea anymore :( John> The problems we need to solve : John> 1) Toolbars. We've seen a little discussion on how to proceed John> here, I wonder if I could juice you for comments. Ideally we John> need to make shown/not shown / position consistent across John> sessions, and this will need a little QSettings work I think. What I propose is (will not be foolproof, it is a start), in no particular order 1/ name toobars, like menubars are named. For example, we would have a "literate_programming" toolbar. 2/ Any toolbar can be on/off/auto (this is in qt land, not backend); if it is auto, show the toolbar only if at least one of its elements is activated (we could have a OptToolbar tag for this case). The "literate_programming" toolbar would then be shown automatically when using a literate class. 3/ the tooltips should be provided in the ui files, like for menus. The current hardcoding is not good enough IMO. 4/ The toolbar description syntax should converge towards the menu description syntax (use Item "foo" "bar", etc). Actually we should make the backends converge, but this may be more complicated 5/ We should have some kind of generic backend object to describe combox, the hardcoded layout combox is not good enough 6/ a toolbar can have a subtoolbar, which will be shown as an icon palette. A subtoolbar probably cannot hold a combox. I am sure there are plenty of holes in there. However, I believe that we can do everything (except possibly 5/) without too much effort. John> 2) edit-properties. As I mentioned we can either have a lot of John> different LFUNs for opening the dialogs and make them all John> OptItems, but there was some problem with that that I've John> forgotten right now. I tend to think it is the best solution. Note that it could be "edit-properties tabular", where edit-properties searches the nearest inset with name "tabular" around. This means there will not be much lfun duplication. The "edit-properties" macro without argument will open the nearest inset with properties. This will be the one which has a key binding, probably. The problem that remains is that the binding will not be automatically shown in front of the "edit-properties foo" which is default (I do not see how to do that). John> Or we can just have some special code to manage "%s Settings" or John> equivalent, and put support in the backend for that. I fear that this will be too complicated to implement. Moreover, there are cases where several of these 'properties' entries should be available at the same time. John> Which would you prefer ? What code changes do you see being a John> good idea ? I might do some work to this end ... Feel free to aks for more help. I'm not sure yet I have said all I have in mind. but I think we can have a straightforward plan to solve 90% of our problems. JMarc
