From: Timothy R. <tr...@si...> - 2010-05-31 14:03:42
|
The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are. The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably. We need a means of determining what key bindings are used, and what module uses them. I think we're back to the JSON files, or a data structure that is part of the struct returned by getPluginInfo(). Is there anything else I'm missing? |
From: Bogdan M. <dag...@gm...> - 2010-05-31 14:18:18
|
On Mon, May 31, 2010 at 5:03 PM, Timothy Reaves <tr...@si...> wrote: > The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are. The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably. "Not called reliably"? > We need a means of determining what key bindings are used, and what module uses them. I think we're back to the JSON files, or a data structure that is part of the struct returned by getPluginInfo(). Is there anything else I'm missing? As I see it: - require that all plug-ins add all their QActions in the same function (reminder: QActions can be enabled/disabled and their signals connected/disconnected, if some actions need to be active only in some parts of the flow of control) - add a module name parameter to addGuiAction() so actions can be grouped by module (there's something like that at the moment - helpGroup) - JSON files store only the key bindings - the ones that are _different from the default_ - using action names as unique identifiers. - when addGuiAction is called, it saves the given key binding as the default one, checks the JSON for the given action and module, and if another key binding is specified for them, uses it instead of the given/default. - when the user changes a key binding different than the default, it is saved to the JSON file(s). Anything wrong with this? Regards, Bogdan Marinov |
From: Fabien C. <fab...@go...> - 2010-05-31 14:23:27
|
On Mon, May 31, 2010 at 16:18, Bogdan Marinov <dag...@gm...> wrote: > On Mon, May 31, 2010 at 5:03 PM, Timothy Reaves > <tr...@si...> wrote: >> The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are. The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably. > > "Not called reliably"? > >> We need a means of determining what key bindings are used, and what module uses them. I think we're back to the JSON files, or a data structure that is part of the struct returned by getPluginInfo(). Is there anything else I'm missing? > > As I see it: > - require that all plug-ins add all their QActions in the same > function (reminder: QActions can be enabled/disabled and their signals > connected/disconnected, if some actions need to be active only in some > parts of the flow of control) > - add a module name parameter to addGuiAction() so actions can be > grouped by module (there's something like that at the moment - > helpGroup) > - JSON files store only the key bindings - the ones that are > _different from the default_ - using action names as unique > identifiers. > - when addGuiAction is called, it saves the given key binding as the > default one, checks the JSON for the given action and module, and if > another key binding is specified for them, uses it instead of the > given/default. > - when the user changes a key binding different than the default, it > is saved to the JSON file(s). > > Anything wrong with this? I thought exactly the same. Thanks |
From: Timothy R. <tr...@si...> - 2010-05-31 14:28:43
|
On May 31, 2010, at 10:18 AM, Bogdan Marinov wrote: > On Mon, May 31, 2010 at 5:03 PM, Timothy Reaves > <tr...@si...> wrote: >> The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are. The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably. > > "Not called reliably"? Not called in a reliable time frame. Actually, in a predictable time frame may have been a better phrase. > >> We need a means of determining what key bindings are used, and what module uses them. I think we're back to the JSON files, or a data structure that is part of the struct returned by getPluginInfo(). Is there anything else I'm missing? > > As I see it: > - require that all plug-ins add all their QActions in the same > function (reminder: QActions can be enabled/disabled and their signals > connected/disconnected, if some actions need to be active only in some > parts of the flow of control) > - add a module name parameter to addGuiAction() so actions can be > grouped by module (there's something like that at the moment - > helpGroup) > - JSON files store only the key bindings - the ones that are > _different from the default_ - using action names as unique > identifiers. > - when addGuiAction is called, it saves the given key binding as the > default one, checks the JSON for the given action and module, and if > another key binding is specified for them, uses it instead of the > given/default. > - when the user changes a key binding different than the default, it > is saved to the JSON file(s). > > Anything wrong with this? This is the way I have it implemented now. The thing is, it gets tricky making sure that all plugins have added their actions. If a plugin is not loaded, even if it is a static plugin, you will not get its actions until the plugin is loaded. In other words, how do you insure that you have all actions? The GUI for editing them will want to show all of them, not just the ones that have been created from the plugins loaded at startup. |
From: Timothy R. <tr...@si...> - 2010-05-31 14:38:11
|
On May 31, 2010, at 10:28 AM, Timothy Reaves wrote: > > On May 31, 2010, at 10:18 AM, Bogdan Marinov wrote: > >> On Mon, May 31, 2010 at 5:03 PM, Timothy Reaves >> <tr...@si...> wrote: >>> The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are. The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably. >> >> "Not called reliably"? > > > Not called in a reliable time frame. Actually, in a predictable time frame may have been a better phrase. > > >> >>> We need a means of determining what key bindings are used, and what module uses them. I think we're back to the JSON files, or a data structure that is part of the struct returned by getPluginInfo(). Is there anything else I'm missing? >> >> As I see it: >> - require that all plug-ins add all their QActions in the same >> function (reminder: QActions can be enabled/disabled and their signals >> connected/disconnected, if some actions need to be active only in some >> parts of the flow of control) >> - add a module name parameter to addGuiAction() so actions can be >> grouped by module (there's something like that at the moment - >> helpGroup) >> - JSON files store only the key bindings - the ones that are >> _different from the default_ - using action names as unique >> identifiers. >> - when addGuiAction is called, it saves the given key binding as the >> default one, checks the JSON for the given action and module, and if >> another key binding is specified for them, uses it instead of the >> given/default. >> - when the user changes a key binding different than the default, it >> is saved to the JSON file(s). >> >> Anything wrong with this? > > > This is the way I have it implemented now. The thing is, it gets tricky making sure that all plugins have added their actions. If a plugin is not loaded, even if it is a static plugin, you will not get its actions until the plugin is loaded. > > In other words, how do you insure that you have all actions? The GUI for editing them will want to show all of them, not just the ones that have been created from the plugins loaded at startup. > > Anything wrong with modifying StelApp::initPlugins() to call the method on each plugin that creates the actions? It currently iterates over each one, but only acts on it if it is supposed to be loaded. Having is set the actions - to get the list - and then calling a tear down function if the plugin is not supposed to be active - would insure we have all actions, and that the plugins not loaded/active do not have their plugins active. |
From: Bogdan M. <dag...@gm...> - 2010-05-31 14:41:46
|
On Mon, May 31, 2010 at 5:28 PM, Timothy Reaves <tr...@si...> wrote: > > On May 31, 2010, at 10:18 AM, Bogdan Marinov wrote: > >> On Mon, May 31, 2010 at 5:03 PM, Timothy Reaves >> <tr...@si...> wrote: >>> The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are. The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably. >> >> "Not called reliably"? > > > Not called in a reliable time frame. Actually, in a predictable time frame may have been a better phrase. Thanks. > This is the way I have it implemented now. The thing is, it gets tricky making sure that all plugins have added their actions. If a plugin is not loaded, even if it is a static plugin, you will not get its actions until the plugin is loaded. > > In other words, how do you insure that you have all actions? The GUI for editing them will want to show all of them, not just the ones that have been created from the plugins loaded at startup. What's the point of editing a plug-in's key bindings if it's not used (i.e. loaded)? :) This applies both to load-on-start-up and load-at-any-time. The only reason for having all actions at the same time is avoiding conflicts in the key bindings, but this is not an issue, if duplicate resolution is done properly. It's easy to have addGuiActions() emit a signal when a new action is added. The GUI can connect to it and update itself. Bogdan |
From: Timothy R. <tr...@si...> - 2010-05-31 14:46:58
|
On May 31, 2010, at 10:41 AM, Bogdan Marinov wrote: > On Mon, May 31, 2010 at 5:28 PM, Timothy Reaves > <tr...@si...> wrote: >> >> On May 31, 2010, at 10:18 AM, Bogdan Marinov wrote: >> >>> On Mon, May 31, 2010 at 5:03 PM, Timothy Reaves >>> <tr...@si...> wrote: >>>> The issue with some of the recommended approaches is that - other than the JSON files I was originally using - there is no way of determining what the key bindings are. The addGuiAction() is a good place to intercept and replace with a replacement value, but this method is not called reliably. >>> >>> "Not called reliably"? >> >> >> Not called in a reliable time frame. Actually, in a predictable time frame may have been a better phrase. > > Thanks. > >> This is the way I have it implemented now. The thing is, it gets tricky making sure that all plugins have added their actions. If a plugin is not loaded, even if it is a static plugin, you will not get its actions until the plugin is loaded. >> >> In other words, how do you insure that you have all actions? The GUI for editing them will want to show all of them, not just the ones that have been created from the plugins loaded at startup. > > What's the point of editing a plug-in's key bindings if it's not used > (i.e. loaded)? :) This applies both to load-on-start-up and > load-at-any-time. The only reason for having all actions at the same > time is avoiding conflicts in the key bindings, but this is not an > issue, if duplicate resolution is done properly. > > It's easy to have addGuiActions() emit a signal when a new action is > added. The GUI can connect to it and update itself. When you go into any application on Linux or a Mac, and edit the key bindings, you are presented a list of all key bindings. This is what a user expects. Otherwise, a user could be using Strellarium, and have the bey bindings defined the way they want. One day, they decide to enable the satellites plugin. They turn in on, but it doesn't work. The key bindings for it have already been assigned to other actions. The user would have no way of knowing this; they'd assume the plugin was broken. This is what I'm trying to avoid. Now, using your signal idea, when a new action comes in that is a duplicate, we could flash a quick text on the screen alerting the user to the state, and that they should edit their key bindings. That could work. |
From: Timothy R. <tr...@si...> - 2010-05-31 21:38:30
Attachments:
ShortCutKeys.diff.bz2
|
Here is a diff based on simply using the creation of QActions. * StelJsonParser.cpp had to be updated to correctly handle saving & loading "\", as this is an in-use hotkey. * The ConfigDialog* changes are here too; it's just not that much code. * I've added virtual void setupGuiActions() to StelModule; this is where modules should define all QAction. It should also be pure virtual, but it is not at the moment. * I've only updated Oculars, until I get feed back. This is largely irrelevant, as all actions will still be picked up as they are added. * The code in the GUI could be simplified by subclassing QTableWidgetItem to contain the QAction it represents; then signals/slots could be used to track changes in the GUI. Thoughts? * StelGuiBase reads in the JSON file, and saves it: a) when the class is destructed, and b) when saveActionKeyBindings() is called. I do not particularly like the one in the destructor, but, the other choice was to save after each action is added. |
From: Timothy R. <tr...@si...> - 2010-06-03 14:25:33
|
On May 31, 2010, at 5:38 PM, Timothy Reaves wrote: > Here is a diff based on simply using the creation of QActions. > > * StelJsonParser.cpp had to be updated to correctly handle saving & loading "\", as this is an in-use hotkey. > > * The ConfigDialog* changes are here too; it's just not that much code. > > * I've added virtual void setupGuiActions() to StelModule; this is where modules should define all QAction. It should also be pure virtual, but it is not at the moment. > > * I've only updated Oculars, until I get feed back. This is largely irrelevant, as all actions will still be picked up as they are added. > > * The code in the GUI could be simplified by subclassing QTableWidgetItem to contain the QAction it represents; then signals/slots could be used to track changes in the GUI. Thoughts? > > * StelGuiBase reads in the JSON file, and saves it: a) when the class is destructed, and b) when saveActionKeyBindings() is called. I do not particularly like the one in the destructor, but, the other choice was to save after each action is added. Fabien, you have time to look at this? |
From: Fabien C. <fab...@go...> - 2010-06-03 14:36:52
|
Sorry, not until a couple of days.. Fab On Thu, Jun 3, 2010 at 16:25, Timothy Reaves <tr...@si...> wrote: > > On May 31, 2010, at 5:38 PM, Timothy Reaves wrote: > >> Here is a diff based on simply using the creation of QActions. >> >> * StelJsonParser.cpp had to be updated to correctly handle saving & loading "\", as this is an in-use hotkey. >> >> * The ConfigDialog* changes are here too; it's just not that much code. >> >> * I've added virtual void setupGuiActions() to StelModule; this is where modules should define all QAction. It should also be pure virtual, but it is not at the moment. >> >> * I've only updated Oculars, until I get feed back. This is largely irrelevant, as all actions will still be picked up as they are added. >> >> * The code in the GUI could be simplified by subclassing QTableWidgetItem to contain the QAction it represents; then signals/slots could be used to track changes in the GUI. Thoughts? >> >> * StelGuiBase reads in the JSON file, and saves it: a) when the class is destructed, and b) when saveActionKeyBindings() is called. I do not particularly like the one in the destructor, but, the other choice was to save after each action is added. > > > Fabien, you have time to look at this? > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Barry G. <bar...@ho...> - 2010-06-04 04:39:54
|
Hi Fabien I can't build 6456 in windows. Some of the includes in stelmainwindow.cpp don't exist in the windows environment (X11) Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" _________________________________________________________________ If It Exists, You'll Find it on SEEK. Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/ |
From: Bogdan M. <dag...@gm...> - 2010-06-04 05:09:36
|
On Fri, Jun 4, 2010 at 7:39 AM, Barry Gerdes <bar...@ho...> wrote: > > Hi Fabien > I can't build 6456 in windows. Some of the includes in stelmainwindow.cpp > don't exist in the windows environment (X11) Fixed. I put the offending lines in an #ifdef. I think that this is within the original intention. :) http://stellarium.svn.sourceforge.net/viewvc/stellarium?view=rev&revision=6457 Bogdan |
From: Barry G. <bar...@ho...> - 2010-06-04 05:25:30
|
thanks Bogdan I had looked at the file and guessed the problem. I am compiling in linux now to see if it works OK there Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" > Date: Fri, 4 Jun 2010 08:09:29 +0300 > From: dag...@gm... > To: ste...@li... > Subject: Re: [Stellarium-pubdevel] Windows build 6456 > > On Fri, Jun 4, 2010 at 7:39 AM, Barry Gerdes <bar...@ho...> wrote: > > > > Hi Fabien > > I can't build 6456 in windows. Some of the includes in stelmainwindow.cpp > > don't exist in the windows environment (X11) > > Fixed. I put the offending lines in an #ifdef. I think that this is > within the original intention. :) > http://stellarium.svn.sourceforge.net/viewvc/stellarium?view=rev&revision=6457 > > Bogdan > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel _________________________________________________________________ If It Exists, You'll Find it on SEEK. Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/ |
From: Barry G. <bar...@ho...> - 2010-06-04 05:34:36
|
frurther to the last I had great trouble compiling 6456 in Windows before I got to the stage that required those items. The compiler could not find libintl.h or zlib.h. I checked the Qt/4.6.2/mingw/includes where they should have been and they were missing. They were there last time I checked but I don't know where they went. I re-installed gettext, iconv and zlib and everything went OK Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" From: bar...@ho... To: ste...@li... Date: Fri, 4 Jun 2010 15:25:23 +1000 Subject: Re: [Stellarium-pubdevel] Windows build 6456 thanks Bogdan I had looked at the file and guessed the problem. I am compiling in linux now to see if it works OK there Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" > Date: Fri, 4 Jun 2010 08:09:29 +0300 > From: dag...@gm... > To: ste...@li... > Subject: Re: [Stellarium-pubdevel] Windows build 6456 > > On Fri, Jun 4, 2010 at 7:39 AM, Barry Gerdes <bar...@ho...> wrote: > > > > Hi Fabien > > I can't build 6456 in windows. Some of the includes in stelmainwindow.cpp > > don't exist in the windows environment (X11) > > Fixed. I put the offending lines in an #ifdef. I think that this is > within the original intention. :) > http://stellarium.svn.sourceforge.net/viewvc/stellarium?view=rev&revision=6457 > > Bogdan > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel Australia's #1 job site If It Exists, You'll Find it on SEEK _________________________________________________________________ View photos of singles in your area! Looking for a hot date? http://clk.atdmt.com/NMN/go/150855801/direct/01/ |
From: Fabien C. <fab...@go...> - 2010-06-04 13:17:33
|
Ooops, thanks Bogdan! On Fri, Jun 4, 2010 at 07:09, Bogdan Marinov <dag...@gm...> wrote: > On Fri, Jun 4, 2010 at 7:39 AM, Barry Gerdes <bar...@ho...> wrote: >> >> Hi Fabien >> I can't build 6456 in windows. Some of the includes in stelmainwindow.cpp >> don't exist in the windows environment (X11) > > Fixed. I put the offending lines in an #ifdef. I think that this is > within the original intention. :) > http://stellarium.svn.sourceforge.net/viewvc/stellarium?view=rev&revision=6457 > > Bogdan > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |
From: Barry G. <bar...@ho...> - 2010-06-04 21:33:00
|
Hi I have noticed the compiling options for MAEMO for some time now. Is it possible to compile a version of stellarium for the Nokia N900. I am in the market for a new mobile phone and this looks like a lovely "toy" to compete with the Apple device. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" _________________________________________________________________ If It Exists, You'll Find it on SEEK. Australia's #1 job site http://clk.atdmt.com/NMN/go/157639755/direct/01/ |
From: Fabien C. <fab...@go...> - 2010-06-05 08:38:07
|
Yes, I am currently working on a port. My first completed step was to make the standard version of stellarium running on N900. It is actually already packaged for meamo: http://maemo.org/packages/view/stellarium/ However the standard version is not suited for such a small device, so I am currently working on step 2 which is making a proper GUI for it. This is not yet finished but I am currently actively working on that with my brother Guillaume. I don't want to distribute any versions at the moment because I still haven't clarified my license strategy, but it will definitely be released on the N900 at some point. Fabien On Fri, Jun 4, 2010 at 23:32, Barry Gerdes <bar...@ho...> wrote: > Hi > I have noticed the compiling options for MAEMO for some time now. Is it > possible to compile a version of stellarium for the Nokia N900. I am in the > market for a new mobile phone and this looks like a lovely "toy" to compete > with the Apple device. > > Barry Gerdes > Beaumont Hills Observatory > S 33' 41' 44" E 150' 56' 32" > > > > > ________________________________ > Australia's #1 job site If It Exists, You'll Find it on SEEK > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > |
From: Barry G. <bar...@ho...> - 2010-06-05 09:04:57
|
Hi Fabien Thanks for that info. That's a very interesting project. I have seen pictures of those N900's and read up a bit on them. They look very interesting. They are availsble here from the Optus Telco who also are my mobile phone provider and I have been thinking of getting an upgrade sometime. I will keep my eye on yoiur progress and hope to try it out some time. Barry Gerdes Beaumont Hills Observatory S 33' 41' 44" E 150' 56' 32" > From: fab...@go... > Date: Sat, 5 Jun 2010 10:37:41 +0200 > To: ste...@li... > Subject: Re: [Stellarium-pubdevel] Windows build 6456 and maemo > > Yes, I am currently working on a port. My first completed step was to > make the standard version of stellarium running on N900. It is > actually already packaged for meamo: > http://maemo.org/packages/view/stellarium/ > However the standard version is not suited for such a small device, so > I am currently working on step 2 which is making a proper GUI for it. > This is not yet finished but I am currently actively working on that > with my brother Guillaume. I don't want to distribute any versions at > the moment because I still haven't clarified my license strategy, but > it will definitely be released on the N900 at some point. > > Fabien > > > On Fri, Jun 4, 2010 at 23:32, Barry Gerdes <bar...@ho...> wrote: > > Hi > > I have noticed the compiling options for MAEMO for some time now. Is it > > possible to compile a version of stellarium for the Nokia N900. I am in the > > market for a new mobile phone and this looks like a lovely "toy" to compete > > with the Apple device. > > > > Barry Gerdes > > Beaumont Hills Observatory > > S 33' 41' 44" E 150' 56' 32" > > > > > > > > > > ________________________________ > > Australia's #1 job site If It Exists, You'll Find it on SEEK > > ------------------------------------------------------------------------------ > > ThinkGeek and WIRED's GeekDad team up for the Ultimate > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > > lucky parental unit. See the prize list and enter to win: > > http://p.sf.net/sfu/thinkgeek-promo > > _______________________________________________ > > Stellarium-pubdevel mailing list > > Ste...@li... > > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel _________________________________________________________________ Need a new place to live? Find it on Domain.com.au http://clk.atdmt.com/NMN/go/157631292/direct/01/ |