Univention Bugzilla – Bug 39796
App Center - support for SVG icons
Last modified: 2017-04-05 14:39:51 CEST
Currently, an ISV has to state Logo=mylogo.svg in the ini file. This is not really necessary. The logo file is found by create_index_json and then downloaded from the UCS server - with a completely different name. If it is mylogo.svg, myotherlogo.svg or anything else does not matter anymore as soon as the index.json.gz is created. When a script would access app.logo, it has no meaning. We should remove this attribute from the ini file, it is just confusing. Instead we may want to introduce a convention. In 4.0 every app_xxx.ini had its app_xxx.png. We could do this for app_xxx.svg and app_xxx.details.svg, too. We may also use this approach: meta-inf/4.1/appid/appid.svg meta-inf/4.1/appid/appid_yyy.svg meta-inf/4.1/appid/appid_xxx.ini -> uses appid.svg meta-inf/4.1/appid/appid_yyy.ini -> uses appid_yyy.svg meta-inf/4.1/appid/appid_zzz.ini -> uses appid_yyy.svg because zzz > yyy +++ This bug was initially created as a clone of Bug #39525 +++ For a more flexible and improved view, we will support (and prefer) with UCS 4.1 SVG images as app icons. This may include different icons for gallery view and app page. +++ This bug was initially created as a clone of Bug #38894 +++ The UMC App Center usability should be improved. The app list is getting longer and longer. :)
(In reply to Dirk Wiesenthal from comment #0) > Currently, an ISV has to state > > Logo=mylogo.svg > > in the ini file. This is not really necessary. The logo file is found by > create_index_json and then downloaded from the UCS server - with a > completely different name. > > If it is mylogo.svg, myotherlogo.svg or anything else does not matter > anymore as soon as the index.json.gz is created. When a script would access > app.logo, it has no meaning. > > We should remove this attribute from the ini file, it is just confusing. > > Instead we may want to introduce a convention. In 4.0 every app_xxx.ini had > its app_xxx.png. We could do this for app_xxx.svg and app_xxx.details.svg, > too. > > We may also use this approach: > meta-inf/4.1/appid/appid.svg > meta-inf/4.1/appid/appid_yyy.svg > > meta-inf/4.1/appid/appid_xxx.ini -> uses appid.svg > meta-inf/4.1/appid/appid_yyy.ini -> uses appid_yyy.svg > meta-inf/4.1/appid/appid_zzz.ini -> uses appid_yyy.svg because zzz > yyy I am against implicit conventions and find the current approach just fine. The properties can be clearly documented in an example .ini file and are much more transparent.
I do not think this is ever going to be implemented now that we have the App Provider Portal.