HI!
2015-01-09 17:59 GMT+06:00 Bernhard Reutner-Fischer :
> >> > with StelGui::addGuiActions(...)? What will happen if we don't
> >> > un-register them?
> >
> > Hell breaks loose :)
> >
> > Cheers,
>
> AFAICS this was not applied yet.
> Pointer to the initial proposal, for reference:
> http://th
On 17 February 2012 at 09:01, Bernhard Reutner-Fischer
wrote:
> On Feb 14, 2012 6:36 PM, "Bogdan Marinov" wrote:
>>
>> On Tue, Feb 14, 2012 at 1:17 PM, Matthew Gates
>> wrote:
>> > Do we need to un-register keyboard commands which have been registered
>
> Yes, this is required.
> My branch does
On Feb 14, 2012 6:36 PM, "Bogdan Marinov" wrote:
>
> On Tue, Feb 14, 2012 at 1:17 PM, Matthew Gates
wrote:
> > Do we need to un-register keyboard commands which have been registered
Yes, this is required.
My branch does this correctly (IIRC)
> > with StelGui::addGuiActions(...)? What will happ
Thanks for the clarification Bogdan, and the reminder about the help
page - we'll need to implement a mechanism to remove plugin help info
from the help dialog.
On 14 February 2012 09:36, Bogdan Marinov wrote:
> On Tue, Feb 14, 2012 at 1:17 PM, Matthew Gates wrote:
>> Do we need to un-register k
On Tue, Feb 14, 2012 at 1:17 PM, Matthew Gates wrote:
> Do we need to un-register keyboard commands which have been registered
> with StelGui::addGuiActions(...)? What will happen if we don't
> un-register them?
If there are signals still connected to them, they may get called,
with varying resu
2012/2/14 Matthew Gates :
> Do we need to un-register keyboard commands which have been registered
> with StelGui::addGuiActions(...)? What will happen if we don't
> un-register them?
I think we will get strange work, maybe crash
--
With best regards, Alexander
Do we need to un-register keyboard commands which have been registered
with StelGui::addGuiActions(...)? What will happen if we don't
un-register them?
On 11 February 2012 09:07, Bogdan Marinov wrote:
> On Thu, Feb 9, 2012 at 1:31 PM, Alexander Wolf wrote:
>> 2012/2/9 Bogdan Marinov :
>>> Bernh
On Thu, Feb 9, 2012 at 1:31 PM, Alexander Wolf wrote:
> 2012/2/9 Bogdan Marinov :
>> Bernhard Reutner-Fischer had proposed a dynamic loading mechanism some time
>> ago:
>> https://code.launchpad.net/~rep-dot-nop/stellarium/http_proxy
>> http://thread.gmane.org/gmane.science.astronomy.stellarium.d
According to a comment in StelModule.hpp, deinit is:
Called before the module will be delete, and before the openGL
context is suppressed. Deinitialize all openGL texture in this
method.
So my guess is that GUI stuff can be deleted in the destructor for the
child of StelModule. Does
2012/2/9 Bogdan Marinov :
> Bernhard Reutner-Fischer had proposed a dynamic loading mechanism some time
> ago:
> https://code.launchpad.net/~rep-dot-nop/stellarium/http_proxy
> http://thread.gmane.org/gmane.science.astronomy.stellarium.devel/319
>
> I thought that this was (based on) his branch, b
On Wed, Feb 8, 2012 at 12:47 AM, Matthew Gates wrote:
> Hi all,
>
> Alex pointed me at the dynamic-mgr-plugins branch and asked that I
> take a look at it with respect to stabilization - the goal being to
> merge dynamic-mgr-plugins at some point. I like the dynamic loading
> feature very much, a
Not sure how long I'll have to spend on the project, but I'll do my
best to make some more time for it over the coming weeks.
On 8 February 2012 02:07, Bogdan Marinov wrote:
> On Wed, Feb 8, 2012 at 12:47 AM, Matthew Gates wrote:
>> Hi all,
>>
>> Alex pointed me at the dynamic-mgr-plugins branch
On Wed, Feb 8, 2012 at 12:47 AM, Matthew Gates wrote:
> Hi all,
>
> Alex pointed me at the dynamic-mgr-plugins branch and asked that I
> take a look at it with respect to stabilization - the goal being to
> merge dynamic-mgr-plugins at some point. I like the dynamic loading
> feature very much, a
2012/2/8 Matthew Gates :
> v) anything else?
Re-build base for search tool
--
With best regards, Alexander
--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Micr
First things I've noticed:
1. [cosmetic] when the disable button is pressed for a plugin, it
re-sizes the window, which is very ugly.
2. [more serious] for the Satellites plugin, if the configuration
dialog is opened when the disable button is pressed, the window
becomes unresponsive, and cannot
One question I have is this: where /should/ we be removing toolbar
buttons / GUI elements - the destructor or the ::deinit member, and
why? I never quite understood the distinction between these members.
If someone knows, please share.
On 7 February 2012 14:47, Matthew Gates wrote:
> Hi all,
>
>
16 matches
Mail list logo
