On Mon, Nov 26, 2012 at 1:48 PM, BRM <bm_witn...@yahoo.com> wrote: > > From: Charley Bay <charleyb...@gmail.com> > > >On Mon, Nov 26, 2012 at 10:40 AM, Matt Broadstone <mbroa...@gmail.com> > wrote: > > > >On Mon, Nov 26, 2012 at 12:01 PM, Charley Bay <charleyb...@gmail.com> > wrote: > >> > >>>>> <snip, updating the "QtService<>" Component >, > >>>>>> I would like to open a new Qt Playground project to create a new > equivalent > >>> > >>> > >>>+1 > >>> > >>>IMHO this would be a cross-platform useful module that I'd vote to > ultimately end-up within "Qt-proper". > >>> > >>> > >>>Disclosure: I traded emails with BRM off-list, and would like to help. > >>> > >>>--charley > >> > >>Would you guys like to get into your design a little here? Did you mean > that you would be creating two classes: QCoreService/QGuiService (though > I'm not sure why one would want a gui service, maybe to use some of the > graphics classes?). Also, could you speak to your ideas for the pluggable > backend? Will you target systemd as a reference implementation? > >> > >>Matt > > > >[UPDATE], I was typing this while BRM responded. Read his email, it's a > more specific "design-ideas" answer. However, I'll still reply with this > email, since it talks about other "higher-level" issues-to-be-resolved, and > brings the discussion "current" with what this proposed-playground is to do. > > > > > >[...what follows is what I was typing when BRM responded...] > > > > > >I'm "second-seat" (Ben/BRM is taking the lead). I defer to Ben/BRM for > any corrections needed from malicious dis-information created as a result > of this email, but here's a bullet-list of early thoughts: > > > > > >TODAY: > > > > > > (a)- The existing "QtService<>" is an add-on (not in "Qt-proper"), but > people use it, and it serves a purpose to help provide a cross-platform > "service/daemon" application API. > > > > > > (b)- The existing "QtService<>" works for Qt4x (likely "needs-work" to > support Qt5) > > > > > >GOAL: > > > > > >After this effort, the result could be considered as a Qt5+ "add-on" for > cross-platform service/daemon support, and possibly considered for > inclusion in a future Qt release (e.g., perhaps Qt5.1+) > > > > > >POSSIBLE ISSUE: > > > > > >An "unfortunate" name collision (or user-confusion) is possible with > class names created from this effort to provide a cross-platform > service/daemon API, and those classes within the "Qt Service Framework" > (which has a different purpose). > > > > > Note: Only the use of the QtService /QService name would have such > collision. That is why the new API would be DaemonApplication > (QDaemonApplication), as discussed previously on the mailing lists. > > Ben >
thoughts: a) I think the only reason the old QtService uses a template based approach is to support the different types of Q*Application. It would be quite useful to have someone who worked on the original solution discuss why they went with this approach rather than subclassing Q*Application. I imagine with a subclass approach you would solve a lot of your "cleanup" problems as well. b) Not sure what you guys are talking about with IPC/QLocalSocket, this seems beyond the scope of these classes c) I believe Service was used originally because it corresponds to the windows world-view of daemons/services (it also explains why the class itself seems to be more of a fair player on windows rather than *nix). The renaming is fine, but I guess you are committing the reverse sin here. d) at this point talk is cheap, show me the code! :) Is there any word on whether you guys get a spot in playground? Matt > _______________________________________________ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development >
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
