On Thursday 08 August 2013 11:48:00 Kevin Krammer wrote:
> On Thursday, 2013-08-08, Pali Rohár wrote:
> > On Tuesday 06 August 2013 15:29:55 Jan Kundrát wrote:
> > > Hi Pali,
> > > there's some chat about students blogging about what they
> > > are doing, any obstacles they hit, new stuff they lear
On Monday, 2013-08-12, Pali Rohár wrote:
> On Thursday 08 August 2013 11:48:00 Kevin Krammer wrote:
> > On Thursday, 2013-08-08, Pali Rohár wrote:
> > > On Tuesday 06 August 2013 15:29:55 Jan Kundrát wrote:
> > > > Hi Pali,
> > > > there's some chat about students blogging about what they
> > > > a
On Monday 12 August 2013 11:33:59 Kevin Krammer wrote:
> On Monday, 2013-08-12, Pali Rohár wrote:
> > On Thursday 08 August 2013 11:48:00 Kevin Krammer wrote:
> > > On Thursday, 2013-08-08, Pali Rohár wrote:
> > > > On Tuesday 06 August 2013 15:29:55 Jan Kundrát wrote:
> > > > > Hi Pali,
> > > > >
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 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
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: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: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: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 Sunday, 11 August 2013 11:57:59 CEST, Pali Rohár wrote:
Both plugins passes information in signals params. This is
unified. But only in ComposeWidget.cpp code I need sender()
because pointer of Job is removed from queue. This is needed
because ComposeWidget had sync API for completion and it
On Sunday, 11 August 2013 12:45:23 CEST, Pali Rohár wrote:
So do you think that this is real problem?
Maybe not really, after all. However, what about adding a code which checks
whether the qApp->applicationDir() matches the cmake's binary output path
and if that is the case, it disabled the
On Sunday, 11 August 2013 14:00:57 CEST, Thomas Lübking wrote:
Googles "threading" substitute.
I'm in favor of this feature. I'm not sure whether I'll have time &
motivation for implementing it myself, though. If it gets implemented,
there's a couple of requirements which I'd like it to satis
On Monday, 2013-08-12, Jan Kundrát wrote:
> On Sunday, 11 August 2013 11:57:59 CEST, Pali Rohár wrote:
> > Both plugins passes information in signals params. This is
> > unified. But only in ComposeWidget.cpp code I need sender()
> > because pointer of Job is removed from queue. This is needed
> >
On Montag, 12. August 2013 18:44:07 CEST, Jan Kundrát wrote:
like a "Show Conversation" button in the header widget and on
clicked() fire a new thread to "uid fetch (X-GM-THRID)"
and on response trigger "uid search X-GM-THRID
<64_bit_thread_id_here>" (by setting the search text to
":=X-GM-TH
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 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 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 18:25:40 Jan Kundrát wrote:
> On Sunday, 11 August 2013 12:45:23 CEST, Pali Rohár wrote:
> > So do you think that this is real problem?
>
> Maybe not really, after all. However, what about adding a code
> which checks whether the qApp->applicationDir() matches the
> cmake'
On Wednesday 07 August 2013 15:02:53 you wrote:
> On Wednesday 07 August 2013 14:55:40 Jan Kundrát wrote:
> > Anyway, here are my suggestions:
> >
> > - Set the POSITION_INDEPENDENT_CODE on a global basis to
> > prevent excess cmake clutter. Some distributions (Fedora)
> > strongly suggest to enab
On Monday 12 August 2013 18:22:59 Jan Kundrát wrote:
> On Sunday, 11 August 2013 11:57:59 CEST, Pali Rohár wrote:
> > Both plugins passes information in signals params. This is
> > unified. But only in ComposeWidget.cpp code I need sender()
> > because pointer of Job is removed from queue. This is
20 matches
Mail list logo
