> On July 3, 2015, 9:15 p.m., Alexander Potashev wrote:
> > Why don't we store plugin metadata in JSON files? Look how they're used for
> > KDevelop: https://svn.reviewboard.kde.org/r/7126/
> >
> > I'm afraid that if we keep this patch and it gets released, but then we
> > realize that X-KDE-F
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review82057
---
Why don't we store plugin metadata in JSON files? Look how the
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/
---
(Updated June 29, 2015, 10:44 p.m.)
Status
--
This change has been m
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review81869
---
Ship it!
Ship It!
- David Faure
On June 17, 2015, 11 p.m.,
> On June 22, 2015, 5:01 p.m., Sebastian Kügler wrote:
> > ping.
ping..
- Sebastian
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review81661
--
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review81661
---
ping.
- Sebastian Kügler
On June 17, 2015, 11 p.m., Sebasti
> On June 17, 2015, 7:24 a.m., David Faure wrote:
> > I don't really have the overview anymore, but the kdelibs4 solution was
> > fully extensible, a servicetype desktop file could define new keys and
> > their type. It looks like desktopfileparser.cpp doesn't have the same
> > flexibility, if
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/
---
(Updated June 17, 2015, 11 p.m.)
Review request for KDE Frameworks, Alex
> On June 17, 2015, 7:24 a.m., David Faure wrote:
> > I don't really have the overview anymore, but the kdelibs4 solution was
> > fully extensible, a servicetype desktop file could define new keys and
> > their type. It looks like desktopfileparser.cpp doesn't have the same
> > flexibility, if
> On June 17, 2015, 7:24 a.m., David Faure wrote:
> > I don't really have the overview anymore, but the kdelibs4 solution was
> > fully extensible, a servicetype desktop file could define new keys and
> > their type. It looks like desktopfileparser.cpp doesn't have the same
> > flexibility, if
> On June 17, 2015, 8:24 a.m., David Faure wrote:
> > I don't really have the overview anymore, but the kdelibs4 solution was
> > fully extensible, a servicetype desktop file could define new keys and
> > their type. It looks like desktopfileparser.cpp doesn't have the same
> > flexibility, if
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review81520
---
I don't really have the overview anymore, but the kdelibs4 sol
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review81519
---
pingpong? :)
- Sebastian Kügler
On June 11, 2015, 4:16 a.m.
> On June 11, 2015, 4:25 a.m., Bhushan Shah wrote:
> > +1
> >
> > I was looking for similar API when implementing plasmoids in pmc. Not all
> > plasmoids would support mediacenter containment, so they might need to tell
> > somehow which formfactors are supported.. About naming, name it
> > X
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/#review81373
---
+1
I was looking for similar API when implementing plasmoids
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/124066/
---
Review request for KDE Frameworks, Alex Richardson and David Faure.
Repos
16 matches
Mail list logo
