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 17:09:58 CEST, Jan Kundrát wrote:
You're right that a defensive design would enforce this via
asserts and mention this in the docs. Patches for both are
welcome.
=P
+enum Type {
+Request,
+Store,
+Delete
+};
enums are extendable (th
On Montag, 5. August 2013 18:28:23 CEST, Jan Kundrát wrote:
1) Where shall we install application-specific plugins?
Something like $LIBDIR/trojita/plugins/?
+1
It's what Qt and KDE do. Gtk calls them "modules", but those gtk guys are
freaks anyway and it's effectively the same ;-)
2) Right
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:
> Hi,
> it turns out that the existing /usr/share/trojita/* is probably not that
> great place for plugins, binary objects which depends on the platform's ABI
> etc (thanks to Pali for bringing this up).
>
> 1) Where shall we install application-specific p
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,
it turns out that the existing /usr/share/trojita/* is probably not that
great place for plugins, binary objects which depends on the platform's ABI
etc (thanks to Pali for bringing this up).
1) Where shall we install application-specific plugins? Something like
$LIBDIR/trojita/plugins/?
On Saturday, 29 June 2013 10:26:26 CEST, Pali Rohár wrote:
- What's the point of storing the plugin path in the settings?
Check how the localization is loaded to see what I mean with
the path discovery.
I see that trojita loading localization from PKGDATADIR. But I do
not see where it is defi
On Monday, 8 July 2013 16:05:28 CEST, Kevin Krammer wrote:
- AbookAddressbook has lots of public API that is not in
AddressbookInterface (e.g. model).
It is needed in AddressbookInterface (somewhere for Trojita)? Or
where is problem? AbookAddressbook is also used by be.contacts
standalone appli
On Tuesday, 30 July 2013 22:58:42 CEST, Thomas Lübking wrote:
What if there're successive sendMail calls before the password turned in?
The MSA classes are designed to only support a single submission during
their lifetime, so this is not a problem.
You're right that a defensive design would
On Tuesday, 30 July 2013 23:23:13 CEST, Kevin Krammer wrote:
Hmm. I guess the class could indeed be called KABCAddressbook or
KResourceAddressbook. But since those are framework names the user
visible
string should probably be something like "Legacy KDE Addressbook".
Agreed.
Cheers,
Jan
--
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
15 matches
Mail list logo
