Re: plasma-framework in kdereview
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 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 not mandatory. > > > > > > Also, right now there is only one user of this framework > > > (plasma-desktop), > > > I would wait until at least we have 2 more shells based on it to commit > > > to any stability. > > > > Wasn't/isn't libplasma supposed to be used also by other applications > > (amarok was the main user I guess)? > > It always was. > wether they want to use it or not it's their problem > > and this attitude of "pest dependency" deeply bothers me and makes me not > much really motivated to keep working on it. > > yes, it has a lot of dependencies and is not optimal. > f i would have it primarly as ligthtweight libraries i would split it at > lest in 3-4 parts, but i think it's better preventing the fragmentation of > little libraries in this case No, no, I was not talking against 3rd-party usage - it's just another point for API and ABI stability :) Ciao -- Luigi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 an outdated checkout :) Awesome, thanks :) ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 done earlier this week, better announce it formally, so > > > > everybody can actually do the -review part ;) > > > > > > Had a look and i18n wise it looks ok-ish (i.e it's kind of as broken as > > > the rest of frameworks ;-)) > > > > Thanks for looking into it. > > > > I checked with Burkhard Lück too and he said it was fine on the doc side > > as > > well. > > We just ended a clean up pass with Aurélien to make sure it was compliant > > with all the active policies, so it's now OK on our side as well. > > > > As far as I'm concerned it's ready to move in frameworks now. > > So you know, I got the OK from Ben for an early move as the main > stakeholders did their duty of reviewing and we got a sprint going on. > 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 an outdated checkout :) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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.
if you do a rr with the diff, i'll try it as well with a bunch of
services, then we are good to go
--
Marco Martin
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 can actually do the -review part ;) > > > > Had a look and i18n wise it looks ok-ish (i.e it's kind of as broken as > > the rest of frameworks ;-)) > > Thanks for looking into it. > > I checked with Burkhard Lück too and he said it was fine on the doc side as > well. > We just ended a clean up pass with Aurélien to make sure it was compliant > with all the active policies, so it's now OK on our side as well. > > As far as I'm concerned it's ready to move in frameworks now. So you know, I got the OK from Ben for an early move as the main stakeholders did their duty of reviewing and we got a sprint going on. David is acting on the move as I'm typing that email. Stay tuned! :-) Cheers. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 it looks ok-ish (i.e it's kind of as broken as the
> rest of frameworks ;-))
Thanks for looking into it.
I checked with Burkhard Lück too and he said it was fine on the doc side as
well.
We just ended a clean up pass with Aurélien to make sure it was compliant with
all the active policies, so it's now OK on our side as well.
As far as I'm concerned it's ready to move in frameworks now.
> I'll be fixed once Aurelien does the patch for all frameworks defining the
> cmake variable for the domain.
>
> There's one thing that someone needs to think about and is this two strings
> in the qml files
>
> QueryDialog.qml:52:property string acceptButtonText: i18n("Ok")
> QueryDialog.qml:53:property string rejectButtonText: i18n("Cancel")
>
> That either need to load the catalog manually (the cmake define won't help
> here) or they need to specify the domain or they need to be killed and use
> som kguistdthing that provides those translations.
OK, thanks.
Cheers.
--
Kévin Ottens, http://ervin.ipsquad.net
KDAB - proud supporter of KDE, http://www.kdab.com
signature.asc
Description: This is a digitally signed message part.
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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::setOperationsScheme with the
following it looks to work.
KSharedConfigPtr config = KSharedConfig::openConfig("/dev/null");
KConfigLoader loader(config, xml);
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.
The /dev/null is a bit of a hack, I'm required to pass a string so
KSharedConfigPtr can try to share objects properly, but it doesn't get
used.
This is theoretically slower quite a bit slower but in practice a
service won't have so many entries so I don't think it will make a
real difference.
Alternatively we can fork just the ConfigLoaderHandler; we don't need
all of KConfigLoader, this part is only ~300 lines which isn't /too/
bad.
David
___
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 days, but in a way or another, i would like to get this sorted in first few days of next week. That leaves, i think a couple of solutions: * putting in KConfigLoader the m_groupsMap stuff * having a way to tap ointo the parser: expose ConfigLoaderHandler? -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 extender items, so it can be removed, both the method and the member -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 may change anything you want in libplasma for kf5, we will either adapt, or consider a totally different approach, using QML. Guillaume Le vendredi 25 avril 2014, 19:49:05 Marco Martin a écrit : > 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, plugins. > > Skrooge used a kpart (that i want to get eventually ported) that basically > loaded a corona, so having an area with widgets is pretty easy > > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 the integration into KConfig. > No idea how it could happen that you weren't aware of it. And I also don't > remember why I didn't adjust plasma-framework, but I assume that it was too > much in flux at that time to do such a change. Seems the problem is that Service is using a subclass to support multiple groups (each operation is a different group, plasmoids support one group) the problem is that it subclasses the parser, ConfigLoaderHandler that is private. 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 -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: plasma-framework in kdereview
>> 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 that you weren't aware of it. And I also don't > remember why I didn't adjust plasma-framework, but I assume that it was too > much in flux at that time to do such a change. > FYI I'm on it now. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Re: plasma-framework in kdereview
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 KConfigGui. > > > > (and I agree that class is really really useful) > > 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 that you weren't aware of it. And I also don't remember why I didn't adjust plasma-framework, but I assume that it was too much in flux at that time to do such a change. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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, plugins. Skrooge used a kpart (that i want to get eventually ported) that basically loaded a corona, so having an area with widgets is pretty easy -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 :/, 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? > That was not my intention. Sorry. *hugs* hugs > What I understood of Alex's email was to say; do we want to commit to > ABI compatibility given it has gone through more changes than the > others. > > On reflection we did have that thread in Plasma recently not that > long ago and I remember there was a discussion about the plasmaquick > lib not being released as ABI stable. As long as that statement still > holds I withdraw my comments. yes, it doesn't install headers -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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-desktop), >> > >> > That's because the other users weren't ported to KF5 yet. But there's >> > definitely more plasma users (amarok comes to mind, skrooge too iirc), not >> > really shells. >> >> That was before QtQuickControls and KDeclarative's imports. Back then >> Plasma was the convenient way to get some sort of button > > /me notes that the widgets were just a later aftertought in that library and > not even remotely the point of that library ever. > that decision had exactly zero to do with plasma being the way to do buttons, > in fact, even tough it still depends from too much for my taste, one thing it > does *not* depends from is what? ah, QML. > > as now maintainer of that library and components i call that library has > framework quality and is very general purpose. > one may want to use it or not (to do applets made with qwidgets, or only to > 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) > It just comes as an huge (disappointing) surprise that just today > * after the move has been started > * after years the decision has been made > * ignoring the fact that such decision was made after, and in part because of, > was possible to remove all the widget stuff, making it finally a small > library. > >> If Amarok or Skrooge wants to use anything from Plasma we are doing >> something wrong. > yes, I think this team is seriously doing something really wrong. > > Let's see what we have that has zero to do with qml controls: > * packages > * configloader > * dataengines > * services > * qpainter based (and going to stay qpainter based) svg stuff > * plugin based (the whole point of having anything) > > you can hate every single one of those things, and believe till the end of the > days that can be solved with $magicbullet in qml, for some things, are complex > problems, everywhere that there is a similar problem, you'll end up > reimplementing a non negligible proportion of it, almost identical. > > now i have no idea if that is needed or not by amarok or skrooge, again, if > for instance the user interaction paradigm they would choose would be "a page > in which you can add widgets that say things" > one starts to say "how hard can it be", will end up with a quite near > reimplementation of corona, containments and packages (replicating in the > meantime many of the bugs we had and solved). > For instance the mediacenter wanted to be a shell again to support widgets > again, I'm sure you would advise them against and reimplement the whole > mechanism instead, i'm wondering why the project is in such state tough. > > what i'm seeing, (and it's not new of this, it's going on since a while) > is that the history of things, and why thay are in a certain thing and not > another is being ignored, and that's excusable (and somewhat comprehensible, I > know I'm not that good in neither explanation or documentation, sorry) > But what is less is the systematically not caring of the why. Not aware of rather than ignoring. > Ending up having to defend the project against the project itself, I am > seriously starting to wonder what the hell I'm doing here. > That was not my intention. Sorry. *hugs* What I understood of Alex's email was to say; do we want to commit to ABI compatibility given it has gone through more changes than the others. On reflection we did have that thread in Plasma recently not that long ago and I remember there was a discussion about the plasmaquick lib not being released as ABI stable. As long as that statement still holds I withdraw my comments. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 ported to KF5 yet. But there's > > definitely more plasma users (amarok comes to mind, skrooge too iirc), not > > really shells. > > That was before QtQuickControls and KDeclarative's imports. Back then > Plasma was the convenient way to get some sort of button > > If Amarok or Skrooge wants to use anything from Plasma we are doing > something wrong. 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, plugins. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 ported to KF5 yet. But there's > > definitely more plasma users (amarok comes to mind, skrooge too iirc), not > > really shells. > > That was before QtQuickControls and KDeclarative's imports. Back then > Plasma was the convenient way to get some sort of button /me notes that the widgets were just a later aftertought in that library and not even remotely the point of that library ever. that decision had exactly zero to do with plasma being the way to do buttons, in fact, even tough it still depends from too much for my taste, one thing it does *not* depends from is what? ah, QML. as now maintainer of that library and components i call that library has framework quality and is very general purpose. one may want to use it or not (to do applets made with qwidgets, or only to parse kconfigskeletons at runtime for what i'm concerned), that's the call of the application developer, as any workspace. It just comes as an huge (disappointing) surprise that just today * after the move has been started * after years the decision has been made * ignoring the fact that such decision was made after, and in part because of, was possible to remove all the widget stuff, making it finally a small library. > If Amarok or Skrooge wants to use anything from Plasma we are doing > something wrong. yes, I think this team is seriously doing something really wrong. Let's see what we have that has zero to do with qml controls: * packages * configloader * dataengines * services * qpainter based (and going to stay qpainter based) svg stuff * plugin based (the whole point of having anything) you can hate every single one of those things, and believe till the end of the days that can be solved with $magicbullet in qml, for some things, are complex problems, everywhere that there is a similar problem, you'll end up reimplementing a non negligible proportion of it, almost identical. now i have no idea if that is needed or not by amarok or skrooge, again, if for instance the user interaction paradigm they would choose would be "a page in which you can add widgets that say things" one starts to say "how hard can it be", will end up with a quite near reimplementation of corona, containments and packages (replicating in the meantime many of the bugs we had and solved). For instance the mediacenter wanted to be a shell again to support widgets again, I'm sure you would advise them against and reimplement the whole mechanism instead, i'm wondering why the project is in such state tough. what i'm seeing, (and it's not new of this, it's going on since a while) is that the history of things, and why thay are in a certain thing and not another is being ignored, and that's excusable (and somewhat comprehensible, I know I'm not that good in neither explanation or documentation, sorry) But what is less is the systematically not caring of the why. Ending up having to defend the project against the project itself, I am seriously starting to wonder what the hell I'm doing here. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
> 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 to mind, skrooge too iirc), not > really shells. That was before QtQuickControls and KDeclarative's imports. Back then Plasma was the convenient way to get some sort of button If Amarok or Skrooge wants to use anything from Plasma we are doing something wrong. David ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 in kdereview, headed > > hopefully in frameworks. > > what it contains: > > > > * libplasma: it's the old plasma library that used to be in kdelibs > > * QML plugins that depend from libplasma, they are old too, and come from > > kde- runtime > > * libplasmaquick: a library that depends from libplasma and QtQuick: it's > > completely for internal use right now (just like the majority of the > > qtquick library) eventually it may become public in the future, so it > > doesn't install any header, not part of the public api. > > * at least one plasma theme: the shipped QML components don't really work > > without it, so one is "core" > > * 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. Huh? > So, do we really have to move it there? Imho would be prudent to keep it > somewhere else where api/abi stability is not mandatory. 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 to mind, skrooge too iirc), not really shells. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 prudent to keep it > > somewhere else where api/abi stability is not mandatory. > > > > Also, right now there is only one user of this framework (plasma-desktop), > > I would wait until at least we have 2 more shells based on it to commit > > to any stability. > > Wasn't/isn't libplasma supposed to be used also by other applications > (amarok was the main user I guess)? It always was. wether they want to use it or not it's their problem and this attitude of "pest dependency" deeply bothers me and makes me not much really motivated to keep working on it. yes, it has a lot of dependencies and is not optimal. f i would have it primarly as ligthtweight libraries i would split it at lest in 3-4 parts, but i think it's better preventing the fragmentation of little libraries in this case -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 not mandatory. > > Also, right now there is only one user of this framework (plasma-desktop), I > would wait until at least we have 2 more shells based on it to commit to > any stability. Wasn't/isn't libplasma supposed to be used also by other applications (amarok was the main user I guess)? Ciao -- Luigi ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 want it there, and the fact that is a framework has been decided like, 3 years ago? > So, do we really have to move it there? Imho would be prudent to keep it yes > somewhere else where api/abi stability is not mandatory. that's exactly the reason why libplasmaquick doesn't install any header, that doesn't have committed compatibility, for sure I don't want any api/abi change whatsoever in libplasma, and for sure not in any qml component. > Also, right now there is only one user of this framework (plasma-desktop), I > would wait until at least we have 2 more shells based on it to commit to > any stability. the user of libplasma doesn't have anything to do being a shell the user of any of its qml components doesn't have anything in being a shell. I want us to be mature enough to commit to some stability. If we can't commit to this minimum level of discipline, I wouldn't expect anybobody else to take it seriously in any way. I wouldn't even manage to encourage with a straight face anyone to ever write a 3rd party plasmoid. -- Marco Martin ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: plasma-framework in kdereview
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 contains: > > * libplasma: it's the old plasma library that used to be in kdelibs > * QML plugins that depend from libplasma, they are old too, and come from > kde- runtime > * libplasmaquick: a library that depends from libplasma and QtQuick: it's > completely for internal use right now (just like the majority of the qtquick > library) eventually it may become public in the future, so it doesn't > install any header, not part of the public api. > * at least one plasma theme: the shipped QML components don't really work > without it, so one is "core" > * 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. So, do we really have to move it there? Imho would be prudent to keep it somewhere else where api/abi stability is not mandatory. Also, right now there is only one user of this framework (plasma-desktop), I would wait until at least we have 2 more shells based on it to commit to any stability. Cheers. signature.asc Description: This is a digitally signed message part. ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
