On Friday 25 of April 2014 15:43:39 Marco Martin wrote:
> On Friday 25 April 2014 15:24:50 Luigi Toscano wrote:
> > On Friday 25 of April 2014 15:14:46 Àlex Fiestas wrote:
> > > Moving plasma-framework to frameworks means that we will loose
> > > flexibility
> > > since we won't be able to break ap
On Saturday, April 26, 2014, David Faure wrote:
>> David is acting on the move as I'm typing that email. Stay tuned! :-)
>
> plasma-framework is now under frameworks/.
>
> kdesrc-build users, remember to do
> rm -rf kdereview/plasma-framework playground/libs/plasma-framework
> to avoid hacking in
On Saturday 26 April 2014 10:56:00 Kevin Ottens wrote:
> Hello,
>
> On Saturday 26 April 2014 02:33:07 Kevin Ottens wrote:
> > On Saturday 26 April 2014 01:57:09 Albert Astals Cid wrote:
> > > El Divendres, 25 d'abril de 2014, a les 12:34:32, Marco Martin va
>
> escriure:
> > > > since it was don
On 4/26/14, David Edmundson wrote:
> foreach (KConfigSkeletonItem *item, loader.items()) {
> d->operationsMap[item->group()][item->key()] = item->property();
> }
>
> I ran plasmaengineexplorer and the UI for the activities service
> appeared properly.
ok, if it works, good for me
Hello,
On Saturday 26 April 2014 02:33:07 Kevin Ottens wrote:
> On Saturday 26 April 2014 01:57:09 Albert Astals Cid wrote:
> > El Divendres, 25 d'abril de 2014, a les 12:34:32, Marco Martin va
escriure:
> > > since it was done earlier this week, better announce it formally, so
> > > everybody ca
Hello,
On Saturday 26 April 2014 01:57:09 Albert Astals Cid wrote:
> El Divendres, 25 d'abril de 2014, a les 12:34:32, Marco Martin va escriure:
> > since it was done earlier this week, better announce it formally, so
> > everybody can actually do the -review part ;)
>
> Had a look and i18n wise
I don't think we can tap into the parser too easily, we're not using
the ConfigLoaderHandler for actually loading a config; we're just
sharing the XML parser.
It seems there's a very simple option that works.
KConfigSkeleton keeps track of groups already.
If we replace the core of Service::setOpe
On Friday 25 April 2014 20:32:32 you wrote:
>
> so, on one hand exposing ConfigLoaderHandler in kconfig doesn't seem too
> clean, on the other hand, not being able to tap in the parsing in subclasses
> may be a limitation as well tough
so, how do we proceed?
personally i'll sleep on it a few day
On Friday 25 April 2014 22:01:42 you wrote:
> >
> > Any idea what it might be for?
>
> ha.
> looking in p1, was used for extender items, so it can be removed, both the
> method and the member
removed it
--
Marco Martin
___
Plasma-devel mailing list
P
On Friday 25 April 2014 21:44:13 David Edmundson wrote:
> In Plasma::Service there's a method called dummyGroup() which will
> always return an empty KConfigGroup in an overly complicated way. It
> seems to be completely unused.
>
> Any idea what it might be for?
ha.
looking in p1, was used for e
In Plasma::Service there's a method called dummyGroup() which will
always return an empty KConfigGroup in an overly complicated way. It
seems to be completely unused.
Any idea what it might be for?
___
Plasma-devel mailing list
Plasma-devel@kde.org
https
Hi Everyone,
Indeed, there was an intention to use some plasma components in Skrooge, but it
never materialized in any official release. Today, this is mostly abandoned
code, to my disappointment, but I never committed myself enough on finishing
this part...
As far as Skrooge is concerned, you
On Friday 25 April 2014 20:10:31 Martin Gräßlin wrote:
> > argh :/, I wasn't aware at all about that :/
> > I would have ported the users of it removing it from libplasma.
> > when was this done? why wasn't notified/things weren't ported to it?
>
> sorry about that, would be me to blame. I did th
>> argh :/, I wasn't aware at all about that :/
>> I would have ported the users of it removing it from libplasma.
>> when was this done? why wasn't notified/things weren't ported to it?
>
> sorry about that, would be me to blame. I did the integration into KConfig. No
> idea how it could happen th
On Friday 25 April 2014 10:39:32 Marco Martin wrote:
> On Friday 25 April 2014 19:28:59 David Edmundson wrote:
> > > parse kconfigskeletons at runtime for what i'm concerned), that's the
> > > call
> > > of the application developer, as any workspace.
> >
> > That KConfigLoader already moved to KC
On Friday 25 April 2014 19:16:43 Kevin Ottens wrote:
> I think these statements show you totally ignore the history behind
> libplasma or how applications can use it... They (at least Amarok, not 100%
> sure for Skrooge) benefit from the component model used in libplasma:
> packages, dataengines,
On Friday 25 April 2014 19:28:59 David Edmundson wrote:
> > parse kconfigskeletons at runtime for what i'm concerned), that's the call
> > of the application developer, as any workspace.
>
> That KConfigLoader already moved to KConfigGui.
>
> (and I agree that class is really really useful)
argh
On Fri, Apr 25, 2014 at 6:56 PM, Marco Martin wrote:
> On Friday 25 April 2014 17:46:23 David Edmundson wrote:
>> > Well... it's been planned this way for three years if not more. Before
>> > that it was in kdelibs.
>> >
>> >> Also, right now there is only one user of this framework
>> >> (plasma-
On Friday 25 April 2014 17:46:23 David Edmundson wrote:
> > Well... it's been planned this way for three years if not more. Before
> > that it was in kdelibs.
> >
> >> Also, right now there is only one user of this framework
> >> (plasma-desktop),
> >
> > That's because the other users weren't po
On Friday 25 April 2014 17:46:23 David Edmundson wrote:
> > Well... it's been planned this way for three years if not more. Before
> > that it was in kdelibs.
> >
> >> Also, right now there is only one user of this framework
> >> (plasma-desktop),
> >
> > That's because the other users weren't po
> Well... it's been planned this way for three years if not more. Before that it
> was in kdelibs.
>
>> Also, right now there is only one user of this framework (plasma-desktop),
>
> That's because the other users weren't ported to KF5 yet. But there's
> definitely more plasma users (amarok comes t
On Friday 25 April 2014 15:14:46 Àlex Fiestas wrote:
> On Friday 25 April 2014 12:34:32 Marco Martin wrote:
> > Hi all,
> > since it was done earlier this week, better announce it formally, so
> > everybody can actually do the -review part ;)
> >
> > the plasma-framework repository has been moved
On Friday 25 April 2014 15:24:50 Luigi Toscano wrote:
> On Friday 25 of April 2014 15:14:46 Àlex Fiestas wrote:
> > Moving plasma-framework to frameworks means that we will loose flexibility
> > since we won't be able to break api/abi.
> >
> > So, do we really have to move it there? Imho would be
On Friday 25 of April 2014 15:14:46 Àlex Fiestas wrote:
> Moving plasma-framework to frameworks means that we will loose flexibility
> since we won't be able to break api/abi.
>
> So, do we really have to move it there? Imho would be prudent to keep it
> somewhere else where api/abi stability is n
On Friday 25 April 2014 15:14:46 you wrote:
> > * there was the plasma shell: has been removed and moved to
> > plasma-workspace, decreasing dependencies
>
> Moving plasma-framework to frameworks means that we will loose flexibility
> since we won't be able to break api/abi.
that's exactly why i
On Friday 25 April 2014 12:34:32 Marco Martin wrote:
> Hi all,
> since it was done earlier this week, better announce it formally, so
> everybody can actually do the -review part ;)
>
> the plasma-framework repository has been moved in kdereview, headed
> hopefully in frameworks.
> what it contain
Hi all,
since it was done earlier this week, better announce it formally, so everybody
can actually do the -review part ;)
the plasma-framework repository has been moved in kdereview, headed hopefully
in frameworks.
what it contains:
* libplasma: it's the old plasma library that used to be in k
27 matches
Mail list logo
