[Player-dev] player SDK
Michael Maloney mmaloney at real.comI would argue that creating the helix-client, -server, -producer categories was a step in the right direction and that we could use this same nomenclature for SDK's as they are created: gtkhelix-client gtkhelix-server gtkhelix-producer (although I have always thought 'encoder' more appropriate...) gtkhxplay is just *really* awkward. On Wednesday, August 11, 2004, at 01:51 PM, Rob Lanphier wrote: > I agree with Ryan. gtkhxplay. We've been burned in the past taking a > "client is everything" view of project naming, creating much confusion. > > Rob > > On Wed, 2004-08-11 at 10:57, Ryan Gammon wrote: >> I like gtkhelix in the sense that it rolls of the tongue a little >> easier, and it's more obviously a part of helix. >> >> I also like gtkhxplay, as it leaves the name space open for other >> helix >> projects to create gtk widget libraries, and puts us on the path of >> having numerous discreet small libraries rather than a single >> monolithic >> libgtkhelix. >> >> I vote gtkhxplay -- makes a little more engineering sense to me as >> well. >> >> Sebastien Martel wrote: >> >>> Hello Nicholas, >>> >>> Tuesday, August 10, 2004, 2:11:23 PM, you wrote: >>> >>> >>> >>>> I vote for gtkhxplay. As I suggested before I think that simply >>>> "helix" >>>> is too broad a name to use and will force us to use some >>>> inconsistent >>>> nomenclature should we ever want to create a GTK component for some >>>> other helix product. >>>> >>>> >>> >>> IMO gtkhxplay has many characters used to prefix the 'meat'. It also >>> isn't that >>> friendly a name. Why not using a more verbose name, something the >>> uninitiated can pronounce ? >>> >>> Even if hx is central to the helix codebase, I feel it is not that >>> useful in the gtk context. >>> Helix, however is: it resonates directly to the project that >>> produced the software. >>> >>> gtk_helix_player ? >>> gtkhelixplayer ? >>> >>> Why not come up with an alternate unique name for the helix player >>> project and use the gtk naming custom of "gtk_<<insert project >>> name>>"? >>> >>> It might be a shameless thing to appropriate 'helix' for the helix >>> player project, but it's a very important widget for gtk and it does >>> leverage alot of the helix technology. >>> >>> I say let other helix project come up with their own distinct >>> project name for their *hypothetical* gtk widget! >>> >>> - *shameless* seb >>> >>> >>> >>> >>>> On Mon, 2004-08-09 at 13:26, Michael Maloney wrote: >>>> >>>> >>>>> My recollection is that we were leaning toward GTKHelix. >>>>> >>>>> On Monday, August 9, 2004, at 12:49 PM, Ryan Gammon wrote: >>>>> >>>>> >>>>> >>>>>> Is gtkhxplay the consensus here? Any objections? >>>>>> >>>>>> Ryan Gammon wrote: >>>>>> >>>>>> >>>>>> >>>>>>> That works for me too. >>>>>>> >>>>>>> gtkhelix >>>>>>> gtkhx >>>>>>> gtkhxplay >>>>>>> gtkhxplayer >>>>>>> >>>>>>> ... all equally appealing to me. >>>>>>> >>>>>>> Nicholas Hart wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> how about gtkhxplay? it's a little shorter and it mirrors the >>>>>>>> name >>>>>>>> of >>>>>>>> the application (hxplay). >>>>>>>> >>>>>>>> >>>>>>>> On Wed, 2004-07-28 at 09:14, Ryan Gammon wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Nicholas Hart wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> Resurrecting an old thread... I need to finish up the sdk >>>>>>>>>> work so >>>>>>>>>> that >>>>>>>>>> we'll have something people can use when we go gold. Below >>>>>>>>>> is one >>>>>>>>>> unresolved issue that I'd like to make a decision on by EOD >>>>>>>>>> tomorrow at >>>>>>>>>> the latest. I've also added a general overview of my current >>>>>>>>>> thinking >>>>>>>>>> and plans for the sdk. >>>>>>>>>> >>>>>>>>>> Issue: what name to use for the widget's dirs? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I'd prefer to have the gtk first, as there's precedent in that >>>>>>>>> direction. GtkCairo, GtkMozilla, GtkDatabox, etc, and I don't >>>>>>>>> know >>>>>>>>> of a project that did it the other way (gtk last). >>>>>>>>> >>>>>>>>> Maybe gtkhxplayer ? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> There was a bit of debate about what name to use for the helix >>>>>>>>>> player's >>>>>>>>>> gtk widget include and sample directories. This decision >>>>>>>>>> affects >>>>>>>>>> how >>>>>>>>>> people will include files (eg: #include >>>>>>>>>> <hxplayergtk/hxplayer.h>) >>>>>>>>>> and >>>>>>>>>> where we will keep samples and docs (eg: samples/hxplayergtk >>>>>>>>>> and >>>>>>>>>> doc/hxplayergtk). Below are some proposals: >>>>>>>>>> >>>>>>>>>> 1. hxplayergtk >>>>>>>>>> 2. hxplaygtk >>>>>>>>>> 3. hxgtk >>>>>>>>>> 4. gtkhx >>>>>>>>>> >>>>>>>>>> Personally I like #1 (or #2) the best because *if* we were to >>>>>>>>>> ever >>>>>>>>>> create a gtk widget for the helix producer it could be >>>>>>>>>> differentiated by >>>>>>>>>> naming its dirs hxproducergtk (or hxprodgtk, hxencgtk, >>>>>>>>>> etc...). >>>>>>>>>> >>>>>>>>>> Overview/plan: >>>>>>>>>> >>>>>>>>>> The sdk will be available as both a simple tarball and rpm >>>>>>>>>> package >>>>>>>>>> (potentially debian package and/or SRV4 package if we get some >>>>>>>>>> assistance with this). It will come with a config file for >>>>>>>>>> pkg-config, >>>>>>>>>> which will enable people to easily use it. The layout will >>>>>>>>>> look >>>>>>>>>> like >>>>>>>>>> this (depending on what we decide upon for the "hxplayergtk" >>>>>>>>>> name). >>>>>>>>>> >>>>>>>>>> ./doc >>>>>>>>>> ./doc/hxclient >>>>>>>>>> ./doc/hxwidget >>>>>>>>>> ./lib >>>>>>>>>> ./samples >>>>>>>>>> ./samples/hxclient >>>>>>>>>> ./samples/hxwidget >>>>>>>>>> ./support >>>>>>>>>> ./include >>>>>>>>>> ./include/hxwidget >>>>>>>>>> ./include/hxclientkit >>>>>>>>>> >>>>>>>>>> The pkg-config config file will go in "support" and the rest >>>>>>>>>> should be >>>>>>>>>> pretty self-explanitory. The rpm will handle installing the >>>>>>>>>> pkg-config >>>>>>>>>> file, but with the tarball it will be up to the user to setup >>>>>>>>>> their >>>>>>>>>> build environment. >>>>>>>>>> >>>>>>>>>> My desire is to also use a gnu-style autoconf setup for the >>>>>>>>>> samples. I >>>>>>>>>> see no reason to burden the casual user with ribosome (or >>>>>>>>>> figuring >>>>>>>>>> out >>>>>>>>>> how to distribute and integrate it with the sdk). >>>>>>>>>> >>>>>>>>>> Also, quite a while back we made plans to do some >>>>>>>>>> re-organization >>>>>>>>>> of the >>>>>>>>>> player repository, as we are integrating the symbian player >>>>>>>>>> and >>>>>>>>>> other >>>>>>>>>> player projects into what was originally just the gtk player's >>>>>>>>>> repository. With that in mind I think we should place the >>>>>>>>>> source >>>>>>>>>> for >>>>>>>>>> building the sdk in player/gtk/sdk. In the future the main UI >>>>>>>>>> components of the player will then be in player/gtk/common, >>>>>>>>>> player/gtk/app, player/gtk/installer, etc... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I like the idea of providing a config file to enable support >>>>>>>>>> for >>>>>>>>>> pkg-config. However, not everyone will have pkg-config, so we >>>>>>>>>> should >>>>>>>>>> also have a scheme >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, 2004-06-29 at 16:17, Ryan Gammon wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Nicholas Hart wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> We need to whip up an SDK and "devel" rpm package for the >>>>>>>>>>>> player, so >>>>>>>>>>>> folks can easily build products based on helix technology. >>>>>>>>>>>> There's >>>>>>>>>>>> already an SDK that allows one to build clients, datatype, >>>>>>>>>>>> filesystem >>>>>>>>>>>> and other plugins using the helix dna COM APIs. What this >>>>>>>>>>>> SDK >>>>>>>>>>>> would >>>>>>>>>>>> provide are the headers and libs necessary to build on top >>>>>>>>>>>> of >>>>>>>>>>>> the helix >>>>>>>>>>>> (or real) player. eg: use our player gtk+ widget in one's >>>>>>>>>>>> own >>>>>>>>>>>> application, or build an entire GUI from scratch on top of >>>>>>>>>>>> the >>>>>>>>>>>> much >>>>>>>>>>>> simpler (than COM) HXClientKit C APIs. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Ideally it could also include the pkg-config infrastructure, >>>>>>>>>>> etc. >>>>>>>>>>> needed to build properly with an autoconf-based project. >>>>>>>>>>> >>>>>>>>>>> The lib name is libgtkhx, I'd lean towards gtkhx as the >>>>>>>>>>> prefix >>>>>>>>>>> myself (versus hxplayergtk). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> Below is my initial take on how the SDK files should be >>>>>>>>>>>> organized. It >>>>>>>>>>>> could be unpacked pretty much anywhere and then symlinks to >>>>>>>>>>>> the >>>>>>>>>>>> appropriate subdirs placed in /usr/lib, /usr/include and >>>>>>>>>>>> /usr/share. Comments/suggestions are appreciated. (I'm not >>>>>>>>>>>> settled on the >>>>>>>>>>>> "hxplayergtk" name, so feel free to suggest something else. >>>>>>>>>>>> This will >>>>>>>>>>>> likely end up in one's includes, ie: #include >>>>>>>>>>>> "hxplayergtk/hxplayer.h") >>>>>>>>>>>> >>>>>>>>>>>> ./ >>>>>>>>>>>> ./doc >>>>>>>>>>>> ./doc/hxplayergtk >>>>>>>>>>>> ./doc/hxclientkit >>>>>>>>>>>> ./lib >>>>>>>>>>>> ./samples >>>>>>>>>>>> ./samples/hxplayergtk >>>>>>>>>>>> ./samples/hxclientkit >>>>>>>>>>>> ./include >>>>>>>>>>>> ./include/hxplayergtk >>>>>>>>>>>> ./include/hxplayergtk/hxstatisticsobserver.h >>>>>>>>>>>> ./include/hxplayergtk/hxgprefs.h >>>>>>>>>>>> ./include/hxplayergtk/hxgerror.h >>>>>>>>>>>> ./include/hxplayergtk/hxbin.h >>>>>>>>>>>> ./include/hxplayergtk/hxgvalue.h >>>>>>>>>>>> ./include/hxplayergtk/hxplayer.h >>>>>>>>>>>> ./include/hxclientkit >>>>>>>>>>>> ./include/hxclientkit/HXClientConstants.h >>>>>>>>>>>> ./include/hxclientkit/HXClientTypes.h >>>>>>>>>>>> ./include/hxclientkit/HXClientGuidIncludes.h >>>>>>>>>>>> ./include/hxclientkit/HXClientCOMAccess.h >>>>>>>>>>>> ./include/hxclientkit/HXClientCProcPtrs.h >>>>>>>>>>>> ./include/hxclientkit/HXClientCallbacks.h >>>>>>>>>>>> ./include/hxclientkit/HXClientCFuncs.h >>>>>>>>>>>> ./include/hxclientkit/HXErrorCodeStrings.h >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> Ryan Gammon >>>>>> rgammon at real.com >>>>>> Developer for Helix Player >>>>>> https://player.helixcommunity.org >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Player-dev mailing list >>>>>> Player-dev at lists.helixcommunity.org >>>>>> http://lists.helixcommunity.org/mailman/listinfo/player-dev >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Michael Maloney - RealNetworks >>>>> Helixcommunity QA Coordinator >>>>> RaBBiT on irc.helixcommunity.org >>>>> AIM:r4bid1 >>>>> >>>>> >>>>> _______________________________________________ >>>>> Player-dev mailing list >>>>> Player-dev at lists.helixcommunity.org >>>>> http://lists.helixcommunity.org/mailman/listinfo/player-dev >>>>> >>>>> >>> >>> >>> >>> >>> > -- > Rob Lanphier, Development Support Manager - RealNetworks > Helix Community: http://helixcommunity.org > Development Support: > http://www.realnetworks.com/products/support/devsupport > > > _______________________________________________ > Player-dev mailing list > Player-dev at lists.helixcommunity.org > http://lists.helixcommunity.org/mailman/listinfo/player-dev > > Michael Maloney - RealNetworks Helixcommunity QA Coordinator RaBBiT on irc.helixcommunity.org AIM:r4bid1