Proposing a New App Developer Upload Process

[Michael Hall]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256


On 09/04/2012 09:55 PM, Steve Langasek wrote:
> On Tue, Sep 04, 2012 at 01:19:50PM -0400, Michael Hall wrote:
> 
>>> As for patches in system tools, at least for icon cache, path,
>>> and desktop file discovery, this is one or two lines in a
>>> configuration file that already carries Ubuntu-specific
>>> patches.  Is there a specific example of a discovery mechanism
>>> that is more complicated to change?
> 
>> .desktop files, .service files (for dbus), .lens and .scope files
>> (for Unity) all needed to be changed to point to executables or
>> images in /opt/extra.ubuntu.com/${appname}/ when being packaged
>> for Extras.  Unity APIs that require a .desktop or image file
>> name had to use absolute paths to the files in
>> /opt/extras.ubuntu.com/{$appname}.  These all required changes to
>> the app's source in order to support the installation under
>> /opt/.
> 
> Note that, independent of any packaging issues for Ubuntu, upstream
> best practice would have the absolute paths in these files
> generated at build time, once it's known where they will be
> installed.  Is there any chance that we could help these app
> developers with implementing such best practices?  Perhaps an
> improvement to the quickly templates?
> 

We can provide helpful abstraction layers, yes, and Quickly's
ubuntu-application template already provides this with
get_media_file() and get_data_file().  But remember that most APIs are
telling the developer to give them a file path, and the developer is
usually going to know the file path, and hard-coding that path will
technically work.  Getting them to consider an abstraction layer
instead is going to be an uphill battle, even if we provide the
methods to do it.


Michael Hall
mhall119 at ubuntu.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBCAAGBQJQRrVmAAoJEInUYcGJgfVyWqQP/R8FoW4wJeld2HUME2HcKMvP
ypdImgSiYUjGU/0w3p0ZNjiFHqtYe+SvHOEduYmspuAo1uVh/xQ9AZ2+svq3sc+c
uARurNvyyOUO8amUF58kNRNKNS5Nj7hVxcDiX3Oi5FTfcZBRLbZQ93cs7aUZorrt
i6ps9xieoVNOIVPPfBmBhyCd20owzfktipBaKxG7G98UyMwXIfafWWMkQvkTaav4
pLhefOpIsMxEuDVGo/fnYvsMYJuuwSWGtx9WqMHebDUNTbhFS7RxekjaeFk/BjJR
L6PPy04WGUjE7ucrdtV+004yhY4sQ72G0N0f9WXa2go7wRZNxT3Wd3WiK0G7F4IU
4Te7YEtoPc9cSS34wOlSouQHqozWaKQdytcC32l+OEyhn+xhWiG6iOBZeS/YR+4V
YKyOF6fuRHnIidPngiIiSdbTufiQjUpZsmE5HzGy0v4HsFdIfV0NoQiMQRl6gyYJ
xU0GTsEicTAykELWEWMGcY4LxINEqnDabDnyrur2QqelaEOE3w9aVzwsVn5NiNlA
P7kusaoS8FCKH6aBheoJsdkjW83TmbR4actQdGcElW1pS8/CEaKTcBCtniX60T5Y
N6+w1eYwkpdV0LYKyw5yUVTeZrXbLELZlnOa++oAtCuxd1QHeVdL2xyujiiaOPEG
5ImFhBj/cTNzX9MBJdSb
=7ndq
-----END PGP SIGNATURE-----