Hello,
I like the way many programs update the save icon with a "grey" one when the document is saved, just like inkscape does it with undo and redo buttons.
I wanted to propose a patch to do that, but I got lost in the code base... Could anyone give me some hint ? Where are the undo and redo buttons updated ?
Thanks, Romain
On Tue, Mar 13, 2007 at 12:06:35PM +0100, Romain Thouvenin wrote:
Hello,
I like the way many programs update the save icon with a "grey" one when the document is saved, just like inkscape does it with undo and redo buttons.
I wanted to propose a patch to do that, but I got lost in the code base... Could anyone give me some hint ? Where are the undo and redo buttons updated ?
Hi Romain,
Sorry if this didn't get answered already.
The undo and redo buttons appear to be updated in event-log.cpp in Event:Log::updateUndoVerbs().
Bryce
On 4/9/07, Bryce Harrington <bryce@...961...> wrote:
On Tue, Mar 13, 2007 at 12:06:35PM +0100, Romain Thouvenin wrote:
I wanted to propose a patch to do that, but I got lost in the code base... Could anyone give me some hint ? Where are the undo and redo buttons updated ?
This needs to be solved not only for these two commands but for ALL commands (verbs). Each verb must have a way to find out if this verb is currently available, and the menus/buttons must display that status by graying out unavailable commands. The person to contact about that is Ted Gould; he started some work in that direction but it's not yet finished. Ted, can you give an update on what's needed to make this possible?
On Apr 9, 2007, at 10:42 AM, bulia byak wrote:
This needs to be solved not only for these two commands but for ALL commands (verbs). Each verb must have a way to find out if this verb is currently available, and the menus/buttons must display that status by graying out unavailable commands. The person to contact about that is Ted Gould; he started some work in that direction but it's not yet finished. Ted, can you give an update on what's needed to make this possible?
This actually touches on some of the changes I've been doing, and carrying on of what Ted started.
And interestingly enough, it also is key to getting the stock toolbars and dynamic UI going.
What we want to do is abstract the business logic of the program and decouple it from the UI directly. This is the general approach of the Model View Controller design pattern.
In this case, we have 'verbs' as one Model/business object, and the UI widgets as the Controls and Views. Ted had done a fair bit of work getting to SPAction under src/helper/action.h
To make the things work for dynamic UI and stock toolbars I'd been shifting things to use stock GtkActions and their subclasses. In fact, as soon as I commit src/widgets/select-toolbar.cpp you'll get an example of how to grab a SPAction and hook up a proper GtkAction to it.
First pass will get the proper icon, label, tootip, etc. and create the action with those. Also it will chain the triggering of the GtkAction to the proper SPAction.
Next pass will be to reflect state changes of the given SPAction and pass those onto the GtkAction(s). One thing to check now, however, would be if the SPAction for "Save" currently gets updated. If not, then that would be the place to hook the functional changes in.
One note on views, though. A given SPAction is bound to a single view, whereas a verb is global. If you have some UI that might apply to more than a single view, you'll need to track changes to active view and not hold an SPAction directly. The layers dialog code does this, and can be looked to for help.
This is good to hear. Can you also jot down these notes into the developer manual in wiki, or a file in inkscape/docs/ for future reference?
Bryce
On Mon, Apr 09, 2007 at 03:04:30PM -0700, Jon A. Cruz wrote:
On Apr 9, 2007, at 10:42 AM, bulia byak wrote:
This needs to be solved not only for these two commands but for ALL commands (verbs). Each verb must have a way to find out if this verb is currently available, and the menus/buttons must display that status by graying out unavailable commands. The person to contact about that is Ted Gould; he started some work in that direction but it's not yet finished. Ted, can you give an update on what's needed to make this possible?
This actually touches on some of the changes I've been doing, and carrying on of what Ted started.
And interestingly enough, it also is key to getting the stock toolbars and dynamic UI going.
What we want to do is abstract the business logic of the program and decouple it from the UI directly. This is the general approach of the Model View Controller design pattern.
In this case, we have 'verbs' as one Model/business object, and the UI widgets as the Controls and Views. Ted had done a fair bit of work getting to SPAction under src/helper/action.h
To make the things work for dynamic UI and stock toolbars I'd been shifting things to use stock GtkActions and their subclasses. In fact, as soon as I commit src/widgets/select-toolbar.cpp you'll get an example of how to grab a SPAction and hook up a proper GtkAction to it.
First pass will get the proper icon, label, tootip, etc. and create the action with those. Also it will chain the triggering of the GtkAction to the proper SPAction.
Next pass will be to reflect state changes of the given SPAction and pass those onto the GtkAction(s). One thing to check now, however, would be if the SPAction for "Save" currently gets updated. If not, then that would be the place to hook the functional changes in.
One note on views, though. A given SPAction is bound to a single view, whereas a verb is global. If you have some UI that might apply to more than a single view, you'll need to track changes to active view and not hold an SPAction directly. The layers dialog code does this, and can be looked to for help.
On Mon, 2007-04-09 at 15:04 -0700, Jon A. Cruz wrote:
One note on views, though. A given SPAction is bound to a single view, whereas a verb is global. If you have some UI that might apply to more than a single view, you'll need to track changes to active view and not hold an SPAction directly. The layers dialog code does this, and can be looked to for help.
You can access this all through the verbs themselves. So a verb has a "set_sensitive" function that can take the document that it is effecting in. So if you sent it's sensitivity to false and pass a single document in, the action will be made insensitive for that document. NULL results in all the documents having that verb as insensitive.
I don't remember ever testing this with icons though. If it doesn't work, I can give more pointers on where to look, but it should work with menu items. Try getting that working, and if the icons don't work, we'll fix that :)
--Ted
On 4/10/07, Ted Gould <ted@...11...> wrote:
On Mon, 2007-04-09 at 15:04 -0700, Jon A. Cruz wrote:
One note on views, though. A given SPAction is bound to a single view, whereas a verb is global. If you have some UI that might apply to more than a single view, you'll need to track changes to active view and not hold an SPAction directly. The layers dialog code does this, and can be looked to for help.
You can access this all through the verbs themselves. So a verb has a "set_sensitive" function that can take the document that it is effecting in. So if you sent it's sensitivity to false and pass a single document in, the action will be made insensitive for that document. NULL results in all the documents having that verb as insensitive.
I don't remember ever testing this with icons though. If it doesn't work, I can give more pointers on where to look, but it should work with menu items. Try getting that working, and if the icons don't work, we'll fix that :)
--Ted
OK, thanks for all the info. I'm not sure I'll have time to look at that this week, but I'll try.
Romain
participants (5)
-
Bryce Harrington -
bulia byak -
Jon A. Cruz -
Romain Thouvenin -
Ted Gould