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, 10 August 2013 12:42:47 CEST, Pali Rohár wrote:
In this case when plugin metadata will be stored separatly, it
still does not
solve problem when user uninstall (or remove or upgrading ...)
plugin together
with metadata file. So metadata content needs to be stored in
trojita confi
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, 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, even if it was
called during stop() (is it?).
Ja
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 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?)
From pali-gsoc-merge:src/Common/PluginLoader.cpp:
// NOTE: qobject_cast not
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?)
From pali-gsoc-merge:src/Common/PluginLoader.cpp:
// NOTE: qobject_cast not working when trojita is compiled as shared
library,
On Monday, 5 August 2013 18:34:04 CEST, Kevin Krammer wrote:
Such code will work flawlessly for them but not for others, increasing
the
test matrix.
Understood, you guys have a good point -- thanks.
This is disconnecting everything connected to any signal of that job.
Did
you mean to disc
On Montag, 5. August 2013 16:40:02 CEST, 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?
Did i miss th
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 would be great.
Kevin suggested that. To have async behaviour and also
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
Hi, review time again.
Three comments in general:
1) Some of the commits look a bit too fine grained to me. I don't see any
benefits in e.g. adding the plugin interface .h declaration in once commit,
settings keys in a second one, a plugin loader in the third one and only
enabling them in cma
18 matches
Mail list logo
