On Tuesday 02 September 2014, Marco Martin wrote:
> > Lets wait till then before anyone continues this thread any further.
>
> Not sure if is more useful to make it during the plasma bof, or during one
> of frameworks.. probably both, we'll need anyways have David participate
> in that
sorry, i f
On Tuesday 02 September 2014, David Edmundson wrote:
> I think we're all a bit uncertain because there's uncertainty lower in
> the stack. JSON + cache is the best of both worlds, but given we don't
> have the cache.. it's a mixed bag.
>
> Akademy is next week, it's been added as part of our BOF a
On Tuesday 02 September 2014, Martin Gräßlin wrote:
> On Tuesday 02 September 2014 15:58:04 Aaron J. Seigo wrote:
> > > Note that these tasks are not currently on my TODO stack. If someone
> > > else wants to work on it, that's totally cool, it's not a priority for
> > > me in this cycle.
> >
> >
I think we're all a bit uncertain because there's uncertainty lower in
the stack. JSON + cache is the best of both worlds, but given we don't
have the cache.. it's a mixed bag.
Akademy is next week, it's been added as part of our BOF agenda, and
we'll bump it to be the top priority topic and hopef
On Tuesday 02 September 2014 15:58:04 Aaron J. Seigo wrote:
> > Note that these tasks are not currently on my TODO stack. If someone else
> > wants to work on it, that's totally cool, it's not a priority for me in
> > this cycle.
>
> I'm sorry to hear that. Leaving that sort of work half-done is u
On Tuesday, September 02, 2014 15:58:04 Aaron J. Seigo wrote:
> > Note that these tasks are not currently on my TODO stack. If someone else
> > wants to work on it, that's totally cool, it's not a priority for me in
> > this cycle.
>
> I'm sorry to hear that. Leaving that sort of work half-done is
On Tuesday, September 2, 2014 14.00:58 Sebastian Kügler wrote:
> On Tuesday, September 02, 2014 12:45:37 Aaron J. Seigo wrote:
> > Whatever path is taken, Plasma::PluginLoader is currently internally
> > inconsistent. Picking a path and then making all plugins load via the same
> > pattern would be
On Tuesday 02 September 2014, Sebastian Kügler wrote:
> I think this actually is "reasonably fast" for our current usecases, we're
> only hitting the disk once on startup, the rest is hot from the caches and
> in those cases, my measurements didn't show a big difference compared to
> ksycoca. That
On Tuesday, September 02, 2014 12:45:37 Aaron J. Seigo wrote:
> > The change for plugins is that at build-time, we're now converting the
> > .desktop file to json, and bake that information into the plugin through
>
> Note that this is currently very limited: no i18n, very limited set of keys
> s
On Tuesday, September 02, 2014 12:45:37 Aaron J. Seigo wrote:
> Whatever path is taken, Plasma::PluginLoader is currently internally
> inconsistent. Picking a path and then making all plugins load via the same
> pattern would be fantastic for 3rd party developers wanting to work with
> the syste
On Tuesday, September 2, 2014 03.14:44 Sebastian Kügler wrote:
> per plugin queried, disk caches alleviate cases where the same plugins are
> read multiple times. Ultimately, the idea is to create a cache, but not
> ksycoca -- ask dfaure.
Last time I spoke with David about this the plan was to do
On Tuesday, September 02, 2014 10:22:07 Marco Martin wrote:
> On Tuesday 02 September 2014, Sebastian Kügler wrote:
> > That means we can use a mechanism similar to the Qt one to query plugins
> > and then load them, KService would be out of the picture, so would ksycoca
> > be -- we can use the qu
On Tuesday 02 September 2014, Sebastian Kügler wrote:
> That means we can use a mechanism similar to the Qt one to query plugins
> and then load them, KService would be out of the picture, so would ksycoca
> be -- we can use the query language parser without KService.
> KPluginTrader::applyConstrai
13 matches
Mail list logo
