On Thursday 12 September 2013 13:50:41 Jan Kundrát wrote:
> On Thursday, 12 September 2013 13:15:16 CEST, Pali Rohár wrote:
> > What about only changing order of applicationDirPath and
> > PLUGIN_DIR in QCoreApplication::libraryPaths()? So we will
> > have also env QT_PLUGIN_PATH in list?
>
> Why
On Thursday, 12 September 2013 13:15:16 CEST, Pali Rohár wrote:
What about only changing order of applicationDirPath and
PLUGIN_DIR in QCoreApplication::libraryPaths()? So we will have
also env QT_PLUGIN_PATH in list?
Why would you need QT_PLUGIN_PATH in there? That's for Qt's own plugins,
no
On Wednesday 11 September 2013 23:43:40 Jan Kundrát wrote:
> Or just don't bother with this nonsesne and just use the
> following:
>
> a) if the BINDIR as defined at build time matches the current
> app's dir -> load from the compile-time-specified PLUGINDIR
> (typically app being located at /usr/
On Wednesday, 11 September 2013 18:25:52 CEST, Thomas Lübking wrote:
The security argument by itself is actually weak - if you start
doing sth. stupid as running a production binary from a user
writable path, you're screwed anyway - regardless of whether you
can read plugins from there as well:
On Wednesday, 11 September 2013 17:50:52 CEST, Pali Rohár wrote:
And PluginManager will use list QCoreApplication::libraryPaths()
for searching for plugins in subdir "/trojitaplugins" - like any
other qt plugins (style, etc.). This looks like common method for
using qt plugins.
You mentioned
On Tuesday 10 September 2013 17:23:53 Pali Rohár wrote:
> On Tuesday 10 September 2013 17:21:20 Pali Rohár wrote:
> > On Tuesday 10 September 2013 17:15:41 Jan Kundrát wrote:
> > > On Tuesday, 10 September 2013 11:52:35 CEST, Pali Rohár
>
> wrote:
> > > > And what about using *only*
> > > > QCoreA
On Wednesday 11 September 2013 17:54:40 Jan Kundrát wrote:
> On Wednesday, 11 September 2013 17:50:52 CEST, Pali Rohár
wrote:
> > And PluginManager will use list
> > QCoreApplication::libraryPaths() for searching for plugins
> > in subdir "/trojitaplugins" - like any other qt plugins
> > (style, e
On Tuesday 10 September 2013 17:21:20 Pali Rohár wrote:
> On Tuesday 10 September 2013 17:15:41 Jan Kundrát wrote:
> > On Tuesday, 10 September 2013 11:52:35 CEST, Pali Rohár
wrote:
> > > And what about using *only*
> > > QCoreApplication::libraryPaths() for searching trojita
> > > plugins?
> >
>
On Tuesday 10 September 2013 17:15:41 Jan Kundrát wrote:
> On Tuesday, 10 September 2013 11:52:35 CEST, Pali Rohár wrote:
> > And what about using *only* QCoreApplication::libraryPaths()
> > for searching trojita plugins?
>
> Would you like to store plugins as
> /usr/bin/trojita-plugins/trojita_pl
On Tuesday, 10 September 2013 11:52:35 CEST, Pali Rohár wrote:
And what about using *only* QCoreApplication::libraryPaths() for
searching trojita plugins?
Would you like to store plugins as
/usr/bin/trojita-plugins/trojita_plugin_foo.so? I wouldn't.
--
Trojitá, a fast Qt IMAP e-mail client -
On Tuesday 10 September 2013 11:13:59 Pali Rohár wrote:
> On Tuesday 10 September 2013 11:03:56 Jan Kundrát wrote:
> > On Sunday, 8 September 2013 14:19:02 CEST, Pali Rohár wrote:
> > > Maybe another (funny) solution for loading plugins from
> > > build directory (without installing). Support for l
On Tuesday, 10 September 2013 11:20:37 CEST, Pali Rohár wrote:
It is not current working directory, but current directory where
is application stored.
You're right, I thought you were talking about CWD, not the location where
the main binary is stored.
Jan
--
Trojitá, a fast Qt IMAP e-mail
On Tuesday 10 September 2013 10:58:34 Jan Kundrát wrote:
> On Saturday, 7 September 2013 10:15:47 CEST, Pali Rohár wrote:
> > Really why is problem first trying to load plugins from
> > executable directory?
>
> Security. The idea is that once you include "." (or any
> variant thereof, or even an
On Tuesday 10 September 2013 11:03:56 Jan Kundrát wrote:
> On Sunday, 8 September 2013 14:19:02 CEST, Pali Rohár wrote:
> > Maybe another (funny) solution for loading plugins from
> > build directory (without installing). Support for loading
> > shared libraries from build directory is already done
On Sunday, 8 September 2013 14:19:02 CEST, Pali Rohár wrote:
Maybe another (funny) solution for loading plugins from build
directory (without installing). Support for loading shared
libraries from build directory is already done by cmake via
adding build directory to rpath to all ELF binaries.
On Saturday, 7 September 2013 10:15:47 CEST, Pali Rohár wrote:
Really why is problem first trying to load plugins from executable
directory?
Security. The idea is that once you include "." (or any variant thereof, or
even an empty strings which is the same for the linker) in the search path
f
On Friday, 6 September 2013 12:56:56 CEST, Pali Rohár wrote:
You forgot to include [1] link.
Oops, http://labplot.sourceforge.net/developer/plugins/.
-> Is there really a problem with adding a *static plugin*
into a *shared library*?
I think yes, because that qt plugin instance function co
On Friday 06 September 2013 20:23:19 Jan Kundrát wrote:
> On Friday, 6 September 2013 12:56:56 CEST, Pali Rohár wrote:
> > You forgot to include [1] link.
>
> Oops, http://labplot.sourceforge.net/developer/plugins/.
>
> >> -> Is there really a problem with adding a *static plugin*
> >> into a *sh
On Saturday, 7 September 2013 00:12:29 CEST, Pali Rohár wrote:
Problem with relinking is because output from git describe is
compiled as string into AppVersion library. So any target will
depends on AppVersion will be recompiled/relinked. And if there
will be one shared library it means that ev
On Friday, 6 September 2013 12:27:08 CEST, Jan Kundrát wrote:
Pali, Thomas, Caspar, Kevin -- which of these do you prefer? I
believe that 3) actually provides fastest compile times during
regular development (i.e. the lest to rebuild upon an isolated
change), which is somewhat of a one of the m
On Friday 06 September 2013 12:27:08 Jan Kundrát wrote:
> On Thursday, 5 September 2013 17:02:47 CEST, Pali Rohár wrote:
> >> - libtrojitaprivate.so shall include code for the basic
> >> plugins which implement e.g. password storage via QSettings
> >
> > Not possible without linker or other hacks.
On Friday, 2013-09-06, Jan Kundrát wrote:
> On Thursday, 5 September 2013 17:02:47 CEST, Pali Rohár wrote:
> >> - libtrojitaprivate.so shall include code for the basic
> >> plugins which implement e.g. password storage via QSettings
> >
> > Not possible without linker or other hacks.
>
> [...]
>
On Thursday, 5 September 2013 17:02:47 CEST, Pali Rohár wrote:
- libtrojitaprivate.so shall include code for the basic
plugins which implement e.g. password storage via QSettings
Not possible without linker or other hacks.
[...]
2. "static" plugin which has own qt_instance_ function
(mangled
On Thursday 05 September 2013 17:02:47 Pali Rohár wrote:
> > - Move most of Trojita into a shared library,
> > libtrojitaprivate.so - Let both the standalone GUI version
> > and the Kontact plugin link with libtrojitaprivate.so
>
> Ok, no problem.
>
One problem is there. CMake should not create
On Thursday 05 September 2013 15:17:07 Jan Kundrát wrote:
> I've browsed through the rest of the pali/pali-gsoc branch,
> and it looks that commit
> 9b769afddc338871148de4a34131d1cdb30cd904 requires a fragile
> hack to make this static linking work. I still do not like
> this approach. Trojita *alr
On Tuesday, 13 August 2013 13:43:14 CEST, Thomas Lübking wrote:
Pretending this is a reasonable target:
a) -whole-archive is not specific to GCC, but GNU ld - no
matter which compiler invokes it, so that should be tested
instead.
b) the equivalent on CLANG is -for
On Tuesday 13 August 2013 12:39:58 Jan Kundrát wrote:
> On Tuesday, 13 August 2013 08:26:51 CEST, Pali Rohár wrote:
> > Yes, I want to support also this configuration. But not only
> > this.
>
> What are the benefits of this? "There will be no shared
> library" is not a benefit, that's a statement
On Tuesday, 13 August 2013 08:26:51 CEST, Pali Rohár wrote:
Yes, I want to support also this configuration. But not only this.
What are the benefits of this? "There will be no shared library" is not a
benefit, that's a statement of fact. I want to know *why* it is important
to you to work wit
On Monday 12 August 2013 22:36:26 Jan Kundrát wrote:
> On Monday, 12 August 2013 22:06:17 CEST, Thomas Lübking wrote:
> > Jus compile them directly into the core then? (implicitly
> > linking the shared library since the core does)
>
> They way I understand it, Pali wants to support a
> configurat
On Monday, 12 August 2013 22:06:17 CEST, Thomas Lübking wrote:
Jus compile them directly into the core then? (implicitly
linking the shared library since the core does)
They way I understand it, Pali wants to support a configuration where there
are no shared libraries, just the /usr/bin/trojit
On Montag, 12. August 2013 15:48:25 CEST, Pali Rohár wrote:
On Monday 12 August 2013 15:34:18 Jan Kundrát wrote:
On Monday, 12 August 2013 15:30:16 CEST, Pali Rohár wrote:
...
This providing support for fallback default plugins such as clear
text password storage. This means when system troj
On Monday, 12 August 2013 15:48:25 CEST, Pali Rohár wrote:
This providing support for fallback default plugins such as clear
text password storage. This means when system trojita plugins are
not available it is still posible to use trojita with weak
password storage.
That's a reason why these
On Monday 12 August 2013 15:34:18 Jan Kundrát wrote:
> On Monday, 12 August 2013 15:30:16 CEST, Pali Rohár wrote:
> > It is needed for static linked plugins. It does not make
> > sense to statically link some plugin (e.g default password
> > storage in config file) into trojita executable and then
On Monday, 12 August 2013 15:30:16 CEST, Pali Rohár wrote:
It is needed for static linked plugins. It does not make sense to
statically link some plugin (e.g default password storage in
config file) into trojita executable and then depends on shared
commit dynamic library for plugins...
Let m
On Monday 12 August 2013 15:16:36 Jan Kundrát wrote:
> On Monday, 12 August 2013 15:11:03 CEST, Pali Rohár wrote:
> > Now I added last part to plugin manager: support for static
> > linked plugins.
>
> What is the point of supporting WITH_STATIC_PLUGIN_LIBRARY? I
> understand what it does, but I d
On Monday, 12 August 2013 15:11:03 CEST, Pali Rohár wrote:
Now I added last part to plugin manager: support for static
linked plugins.
What is the point of supporting WITH_STATIC_PLUGIN_LIBRARY? I understand
what it does, but I do not understand the technical benefits of providing
this option
Hello,
I found problem in current plugin loader & plugins and need help
how to solve it.
My current code have common "interface" classes for password and
addressbook plugins. Because trojita working only with pointers
of these common objects, code of interface classes must be
statically linke
37 matches
Mail list logo
