Dan Miron wrote:

Jerome Velociter wrote:

...

Hi Dan,

Dan Miron wrote:

...

Hi, Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2964 issue, this is how I see it: - Grabbing the icons from the silk iconset - Creating a macro called 'icon' with the following parameters: - fileName (required) the name of the file which holds the

Personally, I would prefer just "file"

...

icon; here I see two possible approaches: - with (optional) - height (optional)

I don't think we should have those parameters. Silk icons are pixel art, they won't look good streched.

...

An example of usage would be the following: {{icon fileName="arrow_out.gif" with="20" height="20" /}} WDYT?

Don't forget the emoticons case.

As far as I see, this set of icons has a couple of emoticons, too.

Right, but the usage as a macro is different. Users should not have to know the silk set file names to insert an emoticon. I want to be able to write something like {{emo}}:){{/emo}} or {{smiley emo=":D"/}} ; not {{icon file="happy.gif"/}} Jerome.

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Vincent Massol wrote:

On Feb 18, 2009, at 5:20 PM, Dan Miron wrote:

...

Hi, Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2964 issue, this is how I see it: - Grabbing the icons from the silk iconset - Creating a macro called 'icon' with the following parameters: - fileName (required) the name of the file which holds the

I don't like that parameter name. I prefer the more anonymous "name"

...

icon; here I see two possible approaches: - with (optional) - height (optional)

I don't think we should specify width and height since we're using bitmaps. Would be nice to use SVG for sure but 1) the silk icon set is not SVG and 2) I don't think ie6 supports SVG out of the box.

...

An example of usage would be the following: {{icon fileName="arrow_out.gif" with="20" height="20" /}}

I'd prefer:

{{icon name="arrow_out"//}}

Now for easy emoticons usage I think (I'm not sure) that we could use a Rendering Transformation instead that would recognize special characters (such as :) ) and internally transform them into icon macros. However there's a use case I haven't thought about which is that the xwiki syntax renderer should probably not use transformed XDOM to generate wiki syntax since otherwise that makes Transformations persistent. Then there's the question of the WYSIWYG editor... Need to think some more about this...

At least you could start implementing the icon macro before we agree on the emoticon part.

I could go on with {{icon name="arrow_out"//}} but this means that the extension will be assumed as ".gif" but it offers the advantage that it's quite intuitive. As for the smileys, we could postpone implementing them until things become more clear. On the other hand, this is what Anca says: ------------------------- Would it be any difference between this macro and the image markup ([[image:reference]] or image:reference), besides the way the image file resolution (image: looks it up as an attachment whereas the {{icon}} macro would getit from the silk icon set) ? Any way we could make these icons accessible as image: references instead of building a whole new macro for it, for syntax simplicity? ------------------------- So what do you think? Should I go ahead with what I proposed above? I'd say yes, because it's more intuitive than using image:reference. Tnx, Dan

Vincent Massol wrote:

On Feb 19, 2009, at 4:28 PM, Dan Miron wrote:

...

I could go on with {{icon name="arrow_out"//}} but this means that the extension will be assumed as ".gif"

IMO the mapping between names and resources is the role of the macro itself, so it can have a map to do whatever mapping it needs. Of course it means users cannot add new resources without changing the macro but I think simplicity is better than genericity here in this case. We could make it generic too by doing the following:

* Create a {{image}} macro that takes a "location" parameter. This location is relative to the resources directory in the webapp. For example:

{{image location="icons/silk/arrow_out.gif"/}}

* Create a {{icon}} macro that extends the image macro but only offers a "name" parameter. This macro will do the mapping between names and image resources.

WDYT?

-0.5, since this kind of location is VERY hardcoded, thus hard to migrate if we decide to reorganize directories. -- Sergiu Dumitriu http://purl.org/net/sergiu/

Dan Miron wrote:

Vincent Massol wrote:

...

On Feb 18, 2009, at 5:20 PM, Dan Miron wrote:

...

Hi, Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2964 issue, this is how I see it: - Grabbing the icons from the silk iconset - Creating a macro called 'icon' with the following parameters: - fileName (required) the name of the file which holds the

I don't like that parameter name. I prefer the more anonymous "name"

...

icon; here I see two possible approaches: - with (optional) - height (optional)

I don't think we should specify width and height since we're using bitmaps. Would be nice to use SVG for sure but 1) the silk icon set is not SVG and 2) I don't think ie6 supports SVG out of the box.

...

An example of usage would be the following: {{icon fileName="arrow_out.gif" with="20" height="20" /}}

I'd prefer:

{{icon name="arrow_out"//}}

Now for easy emoticons usage I think (I'm not sure) that we could use a Rendering Transformation instead that would recognize special characters (such as :) ) and internally transform them into icon macros. However there's a use case I haven't thought about which is that the xwiki syntax renderer should probably not use transformed XDOM to generate wiki syntax since otherwise that makes Transformations persistent. Then there's the question of the WYSIWYG editor... Need to think some more about this...

At least you could start implementing the icon macro before we agree on the emoticon part.

I could go on with {{icon name="arrow_out"//}} but this means that the extension will be assumed as ".gif" but it offers the advantage that it's quite intuitive.

Not necessarily. You can search for all files with the base name equal to the one given as an argument, and any (or a set of possible) extension.

On the other hand, this is what Anca says:

------------------------- Would it be any difference between this macro and the image markup ([[image:reference]] or image:reference), besides the way the image file resolution (image: looks it up as an attachment whereas the {{icon}} macro would getit from the silk icon set) ?

Any way we could make these icons accessible as image: references instead of building a whole new macro for it, for syntax simplicity?

-------------------------

So what do you think? Should I go ahead with what I proposed above? I'd say yes, because it's more intuitive than using image:reference.

I'd go with a new macro. They have different meanings and usage scenarios, since the image macro is supposed to display user attachments, while the icon is supposed to display platform images. The way I see it, {{icon}} should not always use silk icons, but: - we should establish a set of core icons (names) that should always be available, an abstract icon set that XWiki supports - we should provide a default "implementation" for it, using the silk icons - we should (in the future) allow to plug in and choose different icon sets (for each skin, for each user, for each space, etc.) -- Sergiu Dumitriu http://purl.org/net/sergiu/

On Feb 18, 2009, at 8:03 PM, Anca Paula Luca wrote:

Dan Miron wrote:

...

Hi, Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2964 issue, this is how I see it: - Grabbing the icons from the silk iconset - Creating a macro called 'icon' with the following parameters: - fileName (required) the name of the file which holds the icon; here I see two possible approaches: - with (optional) - height (optional)

An example of usage would be the following: {{icon fileName="arrow_out.gif" with="20" height="20" /}} WDYT?

Would it be any difference between this macro and the image markup ([[image:reference]] or image:reference), besides the way the image file resolution (image: looks it up as an attachment whereas the {{icon}} macro would getit from the silk icon set) ?

This is possible but we would need a different uri. So yes we could introduce: icon:arrow_out But I don't like it too much because it means changing the rendering engine code for something that is not core IMO. Thanks -Vincent

Any way we could make these icons accessible as image: references instead of building a whole new macro for it, for syntax simplicity?

Happy coding, Anca Luca

On Feb 19, 2009, at 5:45 PM, Anca Paula Luca wrote:

Vincent Massol wrote:

...

On Feb 18, 2009, at 8:03 PM, Anca Paula Luca wrote:

...

Dan Miron wrote:

...

Hi, Regarding the http://jira.xwiki.org/jira/browse/XWIKI-2964 issue, this is how I see it: - Grabbing the icons from the silk iconset - Creating a macro called 'icon' with the following parameters: - fileName (required) the name of the file which holds the icon; here I see two possible approaches: - with (optional) - height (optional)

An example of usage would be the following: {{icon fileName="arrow_out.gif" with="20" height="20" /}} WDYT? Would it be any difference between this macro and the image markup ([[image:reference]] or image:reference), besides the way the image file resolution (image: looks it up as an attachment whereas the {{icon}} macro would getit from the silk icon set) ?

This is possible but we would need a different uri. So yes we could introduce:

icon:arrow_out

I was referring to image: arrow_out.gif, or just image: arrow_out (although this second one would be even more complicated).

But you can't do that... :) How would the rendering know that this is not an attachment? See XWikiImageParserDefaultAttachmentParser in the code. Thanks -Vincent

Of course is not core, but I don't see why two, and, as a user, I think I'd find it hard to grasp when {{icon}} and when image: and why not only one of them.

This shouldn't be a stopper anyway, it's not that that important...

Happy coding, Anca Luca

...

But I don't like it too much because it means changing the rendering engine code for something that is not core IMO.

Thanks -Vincent

...

Any way we could make these icons accessible as image: references instead of building a whole new macro for it, for syntax simplicity?

Happy coding, Anca Luca

On Feb 20, 2009, at 1:35 PM, Dan Miron wrote:

Guys, this is what I'm thinking of after reading your proposals: - the macro to look like {{icon name="smile" /}}, thus having a mapping between the name parameter and the image file - having a base set of icons from the silk icon set - allowing plugging in other icon sets, too

+1

So, there you have a sketch on how the macro would look like:

class IconMacro implements Macro { List<Block> execute(IconMacroParameters parameters) { Map resources = getResourcesMap(); return new ImageBlock(resources.get(parameters.getName())); }

I'd rather use a IconResourceSet component. You create one implementation called SilkIconResourceSet and register it with a "silk" hint. You make IconMacro impelment Initializable, Composable and in initialize() you lookup all components implementing IconResourceSet and you build your map with them. -Vincent

Map getResourcesMap() { // uses IconResourceDiscoverer to dinamically build the icon set and the mapping between names / icon URLs } }

class AbstractIconResource { public abstract Map<String, URL> getResourcesMap(); }

class DefaultIconResource extends AbstractIconResource { // gets the the default icon set from silk // ..................... }

//singleton class class IconResourceDiscoverer { public Map<String, URL> loadIcons() { foreach (Class c which extends AbstractIconResource) { c.getResourcesMap(); } return all the grabbed resources; } }

- optionally, we can put the IconResourceDiscoverer and the DefaultIconResource in a component if we're going to need using icons in other features too. - if we want to take care of the ambiguities (e.g. multiple icons with the same name located in different icon sets) we can add an optional parameter to the macro called "iconSet" or how else you prefer which to allow explicitly specifying the icon set (the default one being Silk)

Please tell me what you think, 'cause i'm keen on starting working on it :-)

Tnx, Dan

Thanks -Vincent http://xwiki.com http://xwiki.org http://massol.net

On Feb 20, 2009, at 2:03 PM, Jerome Velociter wrote:

Vincent Massol wrote:

...

On Feb 20, 2009, at 1:35 PM, Dan Miron wrote:

...

Guys, this is what I'm thinking of after reading your proposals: - the macro to look like {{icon name="smile" /}}, thus having a mapping between the name parameter and the image file - having a base set of icons from the silk icon set - allowing plugging in other icon sets, too

+1

...

So, there you have a sketch on how the macro would look like:

class IconMacro implements Macro { List<Block> execute(IconMacroParameters parameters) { Map resources = getResourcesMap(); return new ImageBlock(resources.get(parameters.getName())); }

I'd rather use a IconResourceSet component. You create one implementation called SilkIconResourceSet and register it with a "silk" hint.

Yes, sounds good. "silk" should be the default value for the "set" parameter of the macro.

There's no need for a default value AFAICS. -Vincent

The resource set implementation can be responsible to add the correct file extension too, so that you call {{icon name="cog"}} and not {{icon name="cog.gif"}}

Jerome.

...

You make IconMacro impelment Initializable, Composable and in initialize() you lookup all components implementing IconResourceSet and you build your map with them.

-Vincent

...

Map getResourcesMap() { // uses IconResourceDiscoverer to dinamically build the icon set and the mapping between names / icon URLs } }

class AbstractIconResource { public abstract Map<String, URL> getResourcesMap(); }

class DefaultIconResource extends AbstractIconResource { // gets the the default icon set from silk // ..................... }

//singleton class class IconResourceDiscoverer { public Map<String, URL> loadIcons() { foreach (Class c which extends AbstractIconResource) { c.getResourcesMap(); } return all the grabbed resources; } }

- optionally, we can put the IconResourceDiscoverer and the DefaultIconResource in a component if we're going to need using icons in other features too. - if we want to take care of the ambiguities (e.g. multiple icons with the same name located in different icon sets) we can add an optional parameter to the macro called "iconSet" or how else you prefer which to allow explicitly specifying the icon set (the default one being Silk)

Please tell me what you think, 'cause i'm keen on starting working on it :-)

Tnx, Dan