Re: [RFC] New menu layout updated
John == John Levon [EMAIL PROTECTED] writes: John Here's an update. I added a couple of comments this time. John OptSubMenu isn't too useful yet because something is going awry John in the getStatus() stuff (perhaps mathed lfuns ?). It is because math matrices and tabulars share the same lfun. I thought you threatened to remove it before 1.3.0... John We also need getStatus for increase/decrease depth etc. What lfuns do you put in the 'etc.'? JMarc
Re: [RFC] New menu layout updated
On Thu, Feb 20, 2003 at 03:26:26PM +0100, Jean-Marc Lasgouttes wrote: John OptSubMenu isn't too useful yet because something is going awry John in the getStatus() stuff (perhaps mathed lfuns ?). It is because math matrices and tabulars share the same lfun. I thought you threatened to remove it before 1.3.0... I simply placed back the tabular functions in a sensible place. Andre does not want to fix the sharing. John We also need getStatus for increase/decrease depth etc. What lfuns do you put in the 'etc.'? Not sure yet, I was hand waving :) john
Re: [RFC] New menu layout updated
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Here's an update. I added a couple of comments this time. John> OptSubMenu isn't too useful yet because something is going awry John> in the getStatus() stuff (perhaps mathed lfuns ?). It is because math matrices and tabulars share the same lfun. I thought you threatened to remove it before 1.3.0... John> We also need getStatus for increase/decrease depth etc. What lfuns do you put in the 'etc.'? JMarc
Re: [RFC] New menu layout updated
On Thu, Feb 20, 2003 at 03:26:26PM +0100, Jean-Marc Lasgouttes wrote: > John> OptSubMenu isn't too useful yet because something is going awry > John> in the getStatus() stuff (perhaps mathed lfuns ?). > > It is because math matrices and tabulars share the same lfun. I > thought you threatened to remove it before 1.3.0... I simply placed back the tabular functions in a sensible place. Andre does not want to fix the sharing. > John> We also need getStatus for increase/decrease depth etc. > > What lfuns do you put in the 'etc.'? Not sure yet, I was hand waving :) john
Re: [RFC] New menu layout updated
John == John Levon [EMAIL PROTECTED] writes: John Here's an update. I added a couple of comments this time. I like it. It will rwquire a lot of docs updates, though. John OptSubMenu isn't too useful yet because something is going awry John in the getStatus() stuff (perhaps mathed lfuns ?). I have to admit that I never actually tested it :) John We also need getStatus for increase/decrease depth etc. Should be easy. John Any way, all comments gratefully received. JMarc, the John ellipsisation[1] should meet what you want. Yes, it is fine. JMarc
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 03:24:34PM +0100, Jean-Marc Lasgouttes wrote: John Here's an update. I added a couple of comments this time. I like it. It will rwquire a lot of docs updates, though. I am prepared to do this grunt work. If only to show off change tracking :) John We also need getStatus for increase/decrease depth etc. Should be easy. Perhaps you have some idea how. My 3-minute look didn't help me. The problems we need to solve : 1) Toolbars. We've seen a little discussion on how to proceed here, I wonder if I could juice you for comments. Ideally we need to make shown/not shown / position consistent across sessions, and this will need a little QSettings work I think. 2) edit-properties. As I mentioned we can either have a lot of different LFUNs for opening the dialogs and make them all OptItems, but there was some problem with that that I've forgotten right now. Or we can just have some special code to manage %s Settings or equivalent, and put support in the backend for that. Which would you prefer ? What code changes do you see being a good idea ? I might do some work to this end ... regards john
Re: [RFC] New menu layout updated
Jean-Marc == Jean-Marc Lasgouttes [EMAIL PROTECTED] writes: John We also need getStatus for increase/decrease depth etc. Jean-Marc Should be easy. I probably have to retract this statement. the incDepth/decDepth code is ugly. JMarc
Re: [RFC] New menu layout updated
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
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 03:48:56PM +0100, Jean-Marc Lasgouttes wrote: 1/ name toobars, like menubars are named. For example, we would have a literate_programming toolbar. Yes. 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. Sounds good. 5/ We should have some kind of generic backend object to describe combox, the hardcoded layout combox is not good enough Definitely agreed. This would allow mathed comboxes to exist (well the ones where a combox is possible). 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. Ah ok. So getStatus() has access to the argument ? 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). A relatively small problem. Moreover, there are cases where several of these 'properties' entries should be available at the same time. Yes, that's true. I'll have a look at what is required for edit-properties. regards john
Re: [RFC] New menu layout updated
John == John Levon [EMAIL PROTECTED] writes: 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. John Ah ok. So getStatus() has access to the argument ? Yes, it has access to a FunRequest. It does heavy use of it in some cases. If only getStatus was not implemented as a big ugly switch, it would be great stuff... JMarc
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 04:09:23PM +0100, Jean-Marc Lasgouttes wrote: If only getStatus was not implemented as a big ugly switch, it would be great stuff... getStatus should get locallized as localDispatch is... This is not hard in theory but probably will take a while to get right... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [RFC] New menu layout updated
Jean-Marc Lasgouttes wrote: John == John Levon [EMAIL PROTECTED] writes: 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. John Ah ok. So getStatus() has access to the argument ? Yes, it has access to a FunRequest. It does heavy use of it in some cases. If only getStatus was not implemented as a big ugly switch, it would be great stuff... Just a thought... Could we not have a heirarchy of FuncRequest-derived classes as a one to one replacement for each LFUN? -- Angus
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 03:19:42PM +, Angus Leeming wrote: Could we not have a heirarchy of FuncRequest-derived classes as a one to one replacement for each LFUN? And dispatch on those how? What would that buy us? [The main problem _I_ have with current dispatch is the limited scope of return values. I cannot, e.g. return a vectorstring as result of a LFUN] And I don't really like big switches. But the obviuos alternative (100 virtual functions...) is not nice either. I think we should aim for dynamic lfun registration at some point in the future just to cut down this interface to a bare minimum... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [RFC] New menu layout updated
> "John" == John Levon <[EMAIL PROTECTED]> writes: John> Here's an update. I added a couple of comments this time. I like it. It will rwquire a lot of docs updates, though. John> OptSubMenu isn't too useful yet because something is going awry John> in the getStatus() stuff (perhaps mathed lfuns ?). I have to admit that I never actually tested it :) John> We also need getStatus for increase/decrease depth etc. Should be easy. John> Any way, all comments gratefully received. JMarc, the John> ellipsisation[1] should meet what you want. Yes, it is fine. JMarc
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 03:24:34PM +0100, Jean-Marc Lasgouttes wrote: > John> Here's an update. I added a couple of comments this time. > > I like it. It will rwquire a lot of docs updates, though. I am prepared to do this grunt work. If only to show off change tracking :) > John> We also need getStatus for increase/decrease depth etc. > > Should be easy. Perhaps you have some idea how. My 3-minute look didn't help me. The problems we need to solve : 1) Toolbars. We've seen a little discussion on how to proceed here, I wonder if I could juice you for comments. Ideally we need to make shown/not shown / position consistent across sessions, and this will need a little QSettings work I think. 2) edit-properties. As I mentioned we can either have a lot of different LFUNs for opening the dialogs and make them all OptItems, but there was some problem with that that I've forgotten right now. Or we can just have some special code to manage "%s Settings" or equivalent, and put support in the backend for that. Which would you prefer ? What code changes do you see being a good idea ? I might do some work to this end ... regards john
Re: [RFC] New menu layout updated
> "Jean-Marc" == Jean-Marc Lasgouttes <[EMAIL PROTECTED]> writes: John> We also need getStatus for increase/decrease depth etc. Jean-Marc> Should be easy. I probably have to retract this statement. the incDepth/decDepth code is ugly. JMarc
Re: [RFC] New menu layout updated
> "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
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 03:48:56PM +0100, Jean-Marc Lasgouttes wrote: > 1/ name toobars, like menubars are named. For example, we would have a > "literate_programming" toolbar. Yes. > 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. Sounds good. > 5/ We should have some kind of generic backend object to describe > combox, the hardcoded layout combox is not good enough Definitely agreed. This would allow mathed comboxes to exist (well the ones where a combox is possible). > 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. Ah ok. So getStatus() has access to the argument ? > 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). A relatively small problem. > Moreover, there are cases where several of these 'properties' entries > should be available at the same time. Yes, that's true. I'll have a look at what is required for edit-properties. regards john
Re: [RFC] New menu layout updated
> "John" == John Levon <[EMAIL PROTECTED]> writes: >> 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. John> Ah ok. So getStatus() has access to the argument ? Yes, it has access to a FunRequest. It does heavy use of it in some cases. If only getStatus was not implemented as a big ugly switch, it would be great stuff... JMarc
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 04:09:23PM +0100, Jean-Marc Lasgouttes wrote: > If only getStatus was not implemented as a big ugly switch, it would > be great stuff... getStatus should get locallized as localDispatch is... This is not hard in theory but probably will take a while to get right... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
Re: [RFC] New menu layout updated
Jean-Marc Lasgouttes wrote: >> "John" == John Levon <[EMAIL PROTECTED]> writes: > >>> 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. > > John> Ah ok. So getStatus() has access to the argument ? > > Yes, it has access to a FunRequest. It does heavy use of it in some > cases. > > If only getStatus was not implemented as a big ugly switch, it would > be great stuff... Just a thought... Could we not have a heirarchy of FuncRequest-derived classes as a one to one replacement for each LFUN? -- Angus
Re: [RFC] New menu layout updated
On Tue, Feb 18, 2003 at 03:19:42PM +, Angus Leeming wrote: > Could we not have a heirarchy of FuncRequest-derived classes as a one > to one replacement for each LFUN? And dispatch on those how? What would that buy us? [The main problem _I_ have with current dispatch is the limited scope of return values. I cannot, e.g. return a vector as result of a LFUN] And I don't really like big switches. But the obviuos alternative (100 virtual functions...) is not nice either. I think we should aim for "dynamic lfun registration" at some point in the future just to cut down this interface to a bare minimum... Andre' -- Those who desire to give up Freedom in order to gain Security, will not have, nor do they deserve, either one. (T. Jefferson)
