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