Eduard Moraru wrote:
> Regarding GIFs (a bit off topic).
>
> The main advantage GIFs provide is animation. (transparency is already
> done by regular PNG).
Internet Explorer 6 does not support PNG transparency
natively
(
http://support.microsoft.com/kb/294714).
No, they don't support alpha transparency. Neither do GIFs. Simple
true/false transparency is supported.
PS: reminder: this has been voted on the list couple of months ago :
http://tinyurl.com/dee3j6
No, the vote was about using the Silk icon set, from a graphical point
of view, there was no vote on the format.
> Check out APNG (Animated PNG). Some samples are at
>
http://animatedpng.com/index.php/category/samples/
> I tested some APNGs from the samples (.png extensions) and they run well
> on Linux and Vista, so it seems to have good support.
>
> This could be a nice alternative to the evil GIFs.
>
> Sergiu Dumitriu wrote:
>> Jerome Velociter wrote:
>>
>>> Hey,
>>>
>>> Yesterday, Vincent introduced a "Modules" section on
code.xwiki.org
to
>>> host XWiki components documentation. From that we had a conversation on
>>> IRC about terminology of categories on
code.xwiki.org. My observation
>>> was that we have some applications that are not really such since they
>>> do not offer features to users, but only to developers. Take the date
>>> picker application
>>> (
http://code.xwiki.org/xwiki/bin/view/Applications/DatePickerApplication)
>>> : it is not self-standing, this is just for developers that needs a date
>>> picker in their apps. I proposed we add an "Extensions" category
that
>>> would host Skin eXtensions (JSX and SSX) and applications such as the
>>> datepicker would fit in there. But as Vincent remarked, we already have
>>> an extension category for "an application or script that integrates or
>>> interacts with XWiki". In the end, I'll come here with Vincent's
idea of
>>> merging such extensions with plugins, and then have the following
>>> categories :
>>>
>>> * Plugins: A plugin is everything that brings new functionality to the
>>> wiki, but that does not necessarily expose it to end users. There will
>>> be two main kinds of plugins: Front-end plugins (that will mostly come
>>> under the form of SX), as the date picker will be for example, and
>>> Back-end plugins, which can be of various form, such as an old fashioned
>>> xwiki plugin (grand'ma style), or a xwiki component with a velocity
>>> bridge, etc. To sum up, plugins bring *functionalities to developers*.
>>>
>>> * Applications: An application will stay what it is today : something an
>>> administrator can install on its wiki and that provides functionality to
>>> end-users, directly visible/exploitable without the need of more
>>> programming. This mean a SX that do such is an application, for instance
>>> this is how the Ratings application
>>> (
http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-application-ratings/)
>>> is made. To sum up, applications bring *functionalities to the end users*.
>>>
>>> Conclusions: Skin eXtensions will remain only a technical term to
>>> designate what they are as platform feature. This is for us, the
>>> knowledgeable gurus ; on
code.xwiki.org we will offer only plugins and
>>> applications.
>>>
>>> As for icons to represent those two ideas (both on
code.xwiki.org and in
>>> the future in XE) - since this is what matters in the end, icons :) - I
>>> propose we use application.gif for Applications and plugin.gif for
>>> Plugins from the silk set. Pretty straightforward, eh ;)
>>>
>>> WDYT ?
>>>
>> From a user perspective, having less names and categories is good.
>> However, given that so many different types of things will go under
>> "plugins", it will be more confusing IMO. There's a huge difference
>> between a calendar sx and a kerberos auth class, or the SVG plugin, or
>> the localization component.
>>
>> Another name I've been suggesting for a while for interface extensions
>> that add new components is, well, "UI components".
>>
>> And another thing I just noticed: we provide GIFs?! GIFs are evil. GIFs
>> are deprecated. GIFs are very limited. It's true that the Burn All Gifs
>> campaign was started a very long time ago, but it is still valid.
>>
http://burnallgifs.org/archives/
>>