Re: Fwd: looking for phonon gstreamer maintainer
25.09.2013 15:25 пользователь Aaron J. Seigo ase...@kde.org написал: On Wednesday, September 25, 2013 12:35:25 Harald Sitter wrote: since everyone who ever was/is/wanted to be Phonon GStreamer maintainer is either busy or has no interest in it, the backend has as of right now no actual maintenance. you may not get much a reply without some more information: * is there some underlying reason why there is no interest in maintaining Phonon GStreamer? e.g. is there a GStreamer annoyance that needs to be known about / taken into consideration? * what are the real-world ramifications of not having GStreamer support? which platforms might suffer due to a lack of integration / codec support / etc as a result? * what effort is currently required to support Phonon GStreamer? Is it stable and needing continued testing and bug fixing maintenance; is it need of more major surgery; is the big work ahead a port to Qt5 or a change in Phonon? * One more serious question: how well does this backend copes with (recent versions of) GStreamer 1.x?
Re: QML-using app developers: use private.* imports
On 2013-09-25, Sebastian Kügler se...@kde.org wrote: On Wednesday, September 25, 2013 17:51:41 Mark wrote: Doesn't your naming proposal completely ruin the org.kde.* stuff? Up until now i could fairly safely assume that all QML KDE imports where hidden under org.kde.* but that isn't the case anymore if you introduce private.org.kde.* That's exactly the point: we don't want you to find it, much less to rely on it. It's basically application internal stuff you have no business with. It looks like you miss a part in the url.. I would say something like this: org.kde.public.* = public imports org.kde.private.* = private imports But that would require changing all existing components to reflect this idea.. That, and it would encourage to maybe use it as second class API, and still cause us the same problems. QML is not my specialty, but clearly stuffing private/internal stuff away is a great thing. Given QML is a interpreted thing, you need to have all the bits installed, so clearly marking something for 'stay away' is needed. We can't do like in c++ where we choose to just not install some headers. It would btw be great if upstream could agree on private.* for 'please stay out of this'. /Sune
Re: QML-using app developers: use private.* imports
On Thursday 26 September 2013 02:23:31 Aleix Pol wrote: The question would be then, why is it that there's some API that's only needed for internal usage? If it's needed internally, it will be most likely needed externally, at some point. The fact that you decide to label it as private makes frustrated developers. Either way, I have no idea of what we're talking about here. :D is the fact that the most feasible way to bridge the c++ of an app and the qml part is trough imports. you once told me you did some imports for use in muon for instance, and while there may be some parts of those that does have an use outside that application for everybody to use, all of it surely isn't, being its use just bridge functionality of that particular application, and that's fine. However, i would like everything in org.kde.* to be considered a library, with all the requirements of api stability for the entire lifecycle, and requiring this kind of discipline from all random developers is simply not realistic. then, of course if an app developer decides that a part of his private.foo may make sense for everybody to use can always move it, but by accepting all the social contract that maintaining a library means -- Marco Martin
