On Friday 09 August 2013 18:15:41 Jan Kundrát wrote:
> On Thursday, 8 August 2013 17:00:10 CEST, Pali Rohár wrote:
> > As Kevin wrote, protection against emitting signals.
>
> Looking at the code, it seems to me that the only connections
> are to ComposeWidget::completionDone which looks like a sa
On Monday 05 August 2013 19:00:40 Jan Kundrát wrote:
> >> - Why are you employing the singletton (anti)pattern within
> >> the PluginLoader? What are the advantages of using it (i.e.
> >> a global variable in disguise) over an ordinary member of
> >> the MainWindow?
> >
> > Access to PluginLoader
On Saturday, 2013-08-10, Pali Rohár wrote:
> On Friday 09 August 2013 10:03:10 Kevin Krammer wrote:
> > Hmm, speaking of which: separate meta data could also help in the above
> > case of plugin getting uninstalled between sessions.
> > The program could always cache metadata of the use plugin user
On Friday 09 August 2013 10:03:10 Kevin Krammer wrote:
> On Thursday, 2013-08-08, Pali Rohár wrote:
> > On Monday 05 August 2013 16:40:02 Jan Kundrát wrote:
> > > - Why do you store the plugin's *description* in settings? I
> > > understand the plugin ID, but not the human readable
> > > descriptio
On Friday, 2013-08-09, Jan Kundrát wrote:
> On Thursday, 8 August 2013 17:00:10 CEST, Pali Rohár wrote:
> > As Kevin wrote, protection against emitting signals.
>
> Looking at the code, it seems to me that the only connections are to
> ComposeWidget::completionDone which looks like a safe thing, e
On Thursday, 2013-08-08, Pali Rohár wrote:
> On Monday 05 August 2013 16:40:02 Jan Kundrát wrote:
> > - Why do you store the plugin's *description* in settings? I
> > understand the plugin ID, but not the human readable
> > description. Perhaps it's needed -- but if so, a comment
> > saying that *
On Monday 05 August 2013 22:29:20 Jan Kundrát wrote:
>
> >> you mean to disconnect(job, 0, this, 0)?
> >
> > I think this is to protect against stop() emitting any
> > signals. Probably easier to call job->disconnect();
> > Or avoiding sigals in stop().
>
> I was thinking about another valid use
On Monday 05 August 2013 23:15:00 Thomas Lübking wrote:
> On Montag, 5. August 2013 22:32:48 CEST, Jan Kundrát wrote:
> > On Monday, 5 August 2013 19:54:05 CEST, Thomas Lübking wrote:
> >> Did i miss this?
> >> Where's mentioned "does not work" (reason is perhaps
> >> lacking Q_OBJECT macro?)
> >
On Monday 05 August 2013 19:00:40 Jan Kundrát wrote:
> On Saturday, 13 July 2013 12:45:18 CEST, Pali Rohár wrote:
> >> - Why are TrojitaPluginJob::start/stop postponing the
> >> actual operation via the event loop? I'm not saying it's
> >> bad, but I'm wondering why. A comment explaining this
> >>
On Monday, 2013-08-05, Jan Kundrát wrote:
> - The fact that qobject_cast doesn't work across shared library boundaries
> is suspicious. Wasn't supporting *that* use case one of the reasons
> (besides not requiring RTTI) for introducing qobject_cast over
> dynamic_cast?
Indeed. It is the way all Q
10 matches
Mail list logo
