On Mittwoch, 11. September 2013 18:07:36 CEST, Pali Rohár wrote:
Now I looked into qt4 source code and default priority is:
1. QLibraryInfo::location(QLibraryInfo::PluginsPath)
2. QCoreApplication::applicationFilePath()
3. QT_PLUGIN_PATH
In addition, in Kontact the output of tha list will lik
On Dienstag, 10. September 2013 17:15:41 CEST, 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_plug
On Sunday 08 September 2013 14:19:02 Pali Rohár wrote:
> On Saturday 07 September 2013 14:11:14 Thomas Lübking wrote:
> > On Samstag, 7. September 2013 10:15:47 CEST, Pali Rohár
wrote:
> > > So why adding new code "impl = new" for each plugin, if Qt
> > > support Q_IMPORT_PLUGIN which adding plugi
On Montag, 9. September 2013 21:00:17 CEST, Pali Rohár wrote:
On Monday 09 September 2013 20:52:37 Kevin Krammer wrote:
On Monday, 2013-09-09, Pali Rohár wrote:
On Monday 09 September 2013 20:26:27 Thomas Lübking wrote:
On Montag, 9. September 2013 12:55:47 CEST, Pali Rohár
wrote:
...
Would
On Monday 09 September 2013 21:06:42 Kevin Krammer wrote:
> On Monday, 2013-09-09, Pali Rohár wrote:
> > On Monday 09 September 2013 20:52:37 Kevin Krammer wrote:
> > > On Monday, 2013-09-09, Pali Rohár wrote:
> > > > On Monday 09 September 2013 20:26:27 Thomas Lübking
wrote:
> > > > > On Montag,
On Monday, 2013-09-09, Pali Rohár wrote:
> On Monday 09 September 2013 20:52:37 Kevin Krammer wrote:
> > On Monday, 2013-09-09, Pali Rohár wrote:
> > > On Monday 09 September 2013 20:26:27 Thomas Lübking wrote:
> > > > On Montag, 9. September 2013 12:55:47 CEST, Pali Rohár
>
> wrote:
> > > > > And
On Monday, 2013-09-09, Pali Rohár wrote:
> On Monday 09 September 2013 20:26:27 Thomas Lübking wrote:
> > On Montag, 9. September 2013 12:55:47 CEST, Pali Rohár wrote:
> > > And my question is what do you think about searching for
> > > plugins in "./plugins/" directory (instead ".") and in
> > > $
On Monday 09 September 2013 20:26:27 Thomas Lübking wrote:
> On Montag, 9. September 2013 12:55:47 CEST, Pali Rohár wrote:
> > And my question is what do you think about searching for
> > plugins in "./plugins/" directory (instead ".") and in
> > $SOME_ENV_PATH directory? It is acceptable?
>
> $SO
On Monday 09 September 2013 20:52:37 Kevin Krammer wrote:
> On Monday, 2013-09-09, Pali Rohár wrote:
> > On Monday 09 September 2013 20:26:27 Thomas Lübking wrote:
> > > On Montag, 9. September 2013 12:55:47 CEST, Pali Rohár
wrote:
> > > > And my question is what do you think about searching for
>
On Montag, 9. September 2013 12:55:47 CEST, Pali Rohár wrote:
And my question is what do you think about searching for plugins
in "./plugins/" directory (instead ".") and in $SOME_ENV_PATH
directory? It is acceptable?
$SOME_ENV_PATH seems reasonable (Qt allows envs to control plugin paths) an
On Sunday 08 September 2013 19:47:12 Thomas Lübking wrote:
> On Sonntag, 8. September 2013 14:19:02 CEST, Pali Rohár wrote:
> > Ok, so I see that everybody is against loading plugins from
> > application directory.
> >
> > What about this solution?
> >
> > Load plugins from system path specified
On Sonntag, 8. September 2013 14:19:02 CEST, Pali Rohár wrote:
Ok, so I see that everybody is against loading plugins from
application directory.
What about this solution?
Load plugins from system path specified at compile time and also
from some application subdirectory (plugins). And thi
On Saturday 07 September 2013 14:11:14 Thomas Lübking wrote:
> On Samstag, 7. September 2013 10:15:47 CEST, Pali Rohár wrote:
> > So why adding new code "impl = new" for each plugin, if Qt
> > support Q_IMPORT_PLUGIN which adding plugin into
> > QPluginLoader?
>
> To bypass your apparent linker ha
On Samstag, 7. September 2013 10:15:47 CEST, Pali Rohár wrote:
So why adding new code "impl = new" for each plugin, if Qt
support Q_IMPORT_PLUGIN which adding plugin into QPluginLoader?
To bypass your apparent linker hazzles?
No linker trouble, no hard requirement.
It's btw. also what QStyleFa
On Saturday 07 September 2013 03:51:16 Thomas Lübking wrote:
> On Samstag, 7. September 2013 02:18:48 CEST, Pali Rohár wrote:
> > On Friday 06 September 2013 20:23:19 Jan Kundrát wrote:
> >> ...which is why I like Thomas' suggestion to use actual
> >> instantiation of the basic plugins like
> >> pa
On Samstag, 7. September 2013 02:18:48 CEST, Pali Rohár wrote:
On Friday 06 September 2013 20:23:19 Jan Kundrát wrote:
...which is why I like Thomas' suggestion to use actual
instantiation of the basic plugins like
passwords-in-qsettings, i.e. the call to a "impl = new
FooPlugin(...)". FooPlug
On Freitag, 6. September 2013 12:27:08 CEST, Jan Kundrát wrote:
Pali, Thomas, Caspar, Kevin -- which of these do you prefer?
Assuming that ppl. will likely use either the trojita standalone XOR the
kontact plugin, (3) seems fine.
Not sure about the compile/link overhead (degree), though - CMa
On Saturday 07 September 2013 00:03:49 Thomas Lübking wrote:
> On Freitag, 6. September 2013 12:27:08 CEST, Jan Kundrát wrote:
> > Pali, Thomas, Caspar, Kevin -- which of these do you prefer?
>
> Assuming that ppl. will likely use either the trojita
> standalone XOR the kontact plugin, (3) seems f
On Tuesday 13 August 2013 13:57:48 Thomas Lübking wrote:
> On Dienstag, 13. August 2013 12:39:58 CEST, Jan Kundrát wrote:
> > - it works only on GCC
>
> Semi, see my other mail.
>
> > - the linker flags one needs could be considered hackish
>
> Yesno.
> It's used to wrap static archives into sha
On Tuesday 13 August 2013 13:43:14 Thomas Lübking wrote:
> On Dienstag, 13. August 2013 08:26:51 CEST, Pali Rohár wrote:
> > On Monday 12 August 2013 22:36:26 Jan Kundrát wrote:
> >> They way I understand it, Pali wants to support a
> >> configuration where there are no shared libraries, just the
>
On Dienstag, 13. August 2013 12:39:58 CEST, Jan Kundrát wrote:
- it works only on GCC
Semi, see my other mail.
- the linker flags one needs could be considered hackish
Yesno.
It's used to wrap static archives into shared objects, esp. when using them for
toolkits.
It's (afaics) rather uncom
On Dienstag, 13. August 2013 08:26:51 CEST, Pali Rohár wrote:
On Monday 12 August 2013 22:36:26 Jan Kundrát wrote:
They way I understand it, Pali wants to support a
configuration where there are no shared libraries, just the
/usr/bin/trojita with some plugins statically linked in.
Yes, I wa
Now I added last part to plugin manager: support for static
linked plugins. It is possible to choose at compile time which
plugins will be static linked into trojita executable (and
kontact kpart) and which will be shared libraries. Also it
possible to comple one plugin in both modes (static li
On Saturday 10 August 2013 20:04:38 Jan Kundrát wrote:
> On Saturday, 10 August 2013 18:15:57 CEST, Pali Rohár wrote:
> > I wanted to have trojita mail client as small as possible
> > without too many dependencies & libraries. And this also
> > drop support for static linked plugin(s) into trojita
On Saturday, 10 August 2013 18:15:57 CEST, Pali Rohár wrote:
I wanted to have trojita mail client as small as possible without
too many dependencies & libraries. And this also drop support for
static linked plugin(s) into trojita executable (because plugins
will need one shared library). So it
On Samstag, 10. August 2013 18:15:57 CEST, Pali Rohár wrote:
On Saturday 10 August 2013 17:48:27 Jan Kundrát wrote:
On Saturday, 10 August 2013 17:13:28 CEST, Pali Rohár wrote: ...
I wanted to have trojita mail client as small as possible without
too many dependencies & libraries.
ldd /usr/
On Samstag, 10. August 2013 17:13:28 CEST, Pali Rohár wrote:
I think this option is cleaner solution
Having core and Plugins operating on a common interface via a common shared library is a
clean dependency chain. Whatever you can bring against it, it's for sure not
"dirty".
I understood you
On Saturday 10 August 2013 17:48:27 Jan Kundrát wrote:
> On Saturday, 10 August 2013 17:13:28 CEST, Pali Rohár wrote:
> > I think this option is cleaner solution as creating some new
> > shared library only for exporting symbols to other shared
> > plugin libraries...
>
> Have you read Thiago's re
On Saturday, 10 August 2013 17:13:28 CEST, Pali Rohár wrote:
I think this option is cleaner solution as creating some new
shared library only for exporting symbols to other shared plugin
libraries...
Have you read Thiago's response [1] on the qt-interest ML? It seems that
the recommended way
On Wednesday 17 July 2013 21:42:04 Pali Rohár wrote:
> 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 c
On Friday 09 August 2013 17:49:23 Jan Kundrát wrote:
> On Thursday, 8 August 2013 10:04:10 CEST, Pali Rohár wrote:
> > This means that all code which is needed by plugins must be
> > moved into shared library. So then trojita will have one
> > executable binary and one shared library. Both binaries
On Friday 09 August 2013 21:34:08 Thomas Lübking wrote:
> On Donnerstag, 8. August 2013 10:04:10 CEST, Pali Rohár wrote:
> > On Wednesday 07 August 2013 15:07:39 Jan Kundrát wrote:
> >> On Wednesday, 17 July 2013 21:42:04 CEST, Pali Rohár wrote:
> >>> My current code have common "interface" classes
On Donnerstag, 8. August 2013 10:04:10 CEST, Pali Rohár wrote:
On Wednesday 07 August 2013 15:07:39 Jan Kundrát wrote:
On Wednesday, 17 July 2013 21:42:04 CEST, Pali Rohár wrote:
My current code have common "interface" classes for password
and addressbook plugins. Because trojita working only w
On Thursday, 8 August 2013 10:04:10 CEST, Pali Rohár wrote:
This means that all code which is needed by plugins must be moved
into shared library. So then trojita will have one executable
binary and one shared library. Both binaries will be needed to
run trojita and trojita version without plug
On Wednesday 07 August 2013 15:07:39 Jan Kundrát wrote:
> On Wednesday, 17 July 2013 21:42:04 CEST, Pali Rohár wrote:
> > My current code have common "interface" classes for password
> > and addressbook plugins. Because trojita working only with
> > pointers of these common objects, code of interfa
On Wednesday, 17 July 2013 21:42:04 CEST, Pali Rohár wrote:
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 linked into trojita executable binar
36 matches
Mail list logo
