reorganized resources

Thanks for everyone feedback I am closing this CL since we have decided to go a different way.

[sail, 2011-04-14 19:56:16]

I like this reorganization.

Quick question, will the IDs for the large icons be different than the IDs for
the fixed size icons?

[Emmanuel Saint-loubert-Bié, 2011-04-14 20:00:56]

the idea is that 'fixed' is shared by all resolutions (ultimately this
set would be decreasing). Standard is the current size, and 'large' is
double of standard (see README), we could define xlarge as some
greater value, etc... Since standard and large are exclusive of each
other *and* they should really contain the same definition (you will
notice the 2 GRD files are exactly identical) then I suppose the IDs
will be the same. I am not sure if this is a good or bad property.

-- E

On Thu, Apr 14, 2011 at 3:56 PM,  <sail@chromium.org> wrote:
> I like this reorganization.
>
> Quick question, will the IDs for the large icons be different than the IDs
> for
> the fixed size icons?
>
> http://codereview.chromium.org/6851009/
>

[oshima_google, 2011-04-14 20:06:46]

I'd recommend to put this in the CL's description and send to glen as well.

- oshima

On Thu, Apr 14, 2011 at 1:00 PM, Emmanuel Saint-loubert <
saintlou@chromium.org> wrote:

> the idea is that 'fixed' is shared by all resolutions (ultimately this
> set would be decreasing). Standard is the current size, and 'large' is
> double of standard (see README), we could define xlarge as some
> greater value, etc... Since standard and large are exclusive of each
> other *and* they should really contain the same definition (you will
> notice the 2 GRD files are exactly identical) then I suppose the IDs
> will be the same. I am not sure if this is a good or bad property.
>
> -- E
>
> On Thu, Apr 14, 2011 at 3:56 PM,  <sail@chromium.org> wrote:
> > I like this reorganization.
> >
> > Quick question, will the IDs for the large icons be different than the
> IDs
> > for
> > the fixed size icons?
> >
> > http://codereview.chromium.org/6851009/
> >
>

[Glen Murphy, 2011-04-14 20:17:20]

It's a bit weird to separate icons into folders by sizing - it's
already annoyingly hard to find PNGs in our directory structure with
the split across app/resources and chrome/app/theme; I'd almost rather
have an indication in the filename. It's also a bit strange to have
the folders yet leave some icons in the root (which is unlabelled).

However, I'll defer to Ben and Scott, the viewmasters.



On Thu, Apr 14, 2011 at 1:06 PM, Mitsuru Oshima <oshima@google.com> wrote:
> I'd recommend to put this in the CL's description and send to glen as well.
> - oshima
>
> On Thu, Apr 14, 2011 at 1:00 PM, Emmanuel Saint-loubert
> <saintlou@chromium.org> wrote:
>>
>> the idea is that 'fixed' is shared by all resolutions (ultimately this
>> set would be decreasing). Standard is the current size, and 'large' is
>> double of standard (see README), we could define xlarge as some
>> greater value, etc... Since standard and large are exclusive of each
>> other *and* they should really contain the same definition (you will
>> notice the 2 GRD files are exactly identical) then I suppose the IDs
>> will be the same. I am not sure if this is a good or bad property.
>>
>> -- E
>>
>> On Thu, Apr 14, 2011 at 3:56 PM,  <sail@chromium.org> wrote:
>> > I like this reorganization.
>> >
>> > Quick question, will the IDs for the large icons be different than the
>> > IDs
>> > for
>> > the fixed size icons?
>> >
>> > http://codereview.chromium.org/6851009/
>> >
>
>

[sail, 2011-04-14 20:17:20]

This looks good to me but you probably need an ship it from some one other than
me.

[sail, 2011-04-14 20:20:22]

On 2011/04/14 20:17:20, Glen Murphy wrote:
> It's a bit weird to separate icons into folders by sizing

How about this:
 - keep the proposed GRD changes
 - have all icons in a single directory
 - change the naming scheme from foo.png large_foo.png to foo.png foo_large.png

[oshima, 2011-04-14 20:58:27]

http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README
File chrome/app/theme/README (right):

http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13
chrome/app/theme/README:13: c) Resources common to all screen sizes / density
are in:
I believe our icons (including touch) assume the same density. They don't work
for high density screen because it'll be too small. The reason we need large
icons for touch
is purely UX design, right?

I think what we need from long term perspective is a way to specify
the set of icons for given device specification. We don't need this now,
but will be important if we have more form factors in the future.

[Emmanuel Saint-loubert-Bié, 2011-04-14 21:04:17]

> The reason we need large icons for touch is purely UX design, right?

Not UX, this is because we need to have larger touch targets for
fingers, if we stretch the existing icons the screen will look ugly.
Also Dave does not like (and rightly so) to see the GRD file with so
many <if>.

-- Emmanuel

On Thu, Apr 14, 2011 at 4:58 PM,  <oshima@chromium.org> wrote:
>
> http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README
> File chrome/app/theme/README (right):
>
>
http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13
> chrome/app/theme/README:13: c) Resources common to all screen sizes /
> density are in:
> I believe our icons (including touch) assume the same density. They
> don't work
> for high density screen because it'll be too small. The reason we need
> large icons for touch
> is purely UX design, right?
>
> I think what we need from long term perspective is a way to specify
> the set of icons for given device specification. We don't need this now,
> but will be important if we have more form factors in the future.
>
> http://codereview.chromium.org/6851009/
>

[oshima_google, 2011-04-14 21:13:09]

On Thu, Apr 14, 2011 at 2:04 PM, Emmanuel Saint-loubert <
saintlou@chromium.org> wrote:

> > The reason we need large icons for touch is purely UX design, right?
>
> Not UX, this is because we need to have larger touch targets for
> fingers, if we stretch the existing icons the screen will look ugly.
>

We need larger icon for fingers, but not because touch will have different
screen size/density.
That's what I meant by UX.


> Also Dave does not like (and rightly so) to see the GRD file with so
> many <if>.
>
> -- Emmanuel
>
> On Thu, Apr 14, 2011 at 4:58 PM,  <oshima@chromium.org> wrote:
> >
> > http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README
> > File chrome/app/theme/README (right):
> >
> >
>
http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13
> > chrome/app/theme/README:13: c) Resources common to all screen sizes /
> > density are in:
> > I believe our icons (including touch) assume the same density. They
> > don't work
> > for high density screen because it'll be too small. The reason we need
> > large icons for touch
> > is purely UX design, right?
> >
> > I think what we need from long term perspective is a way to specify
> > the set of icons for given device specification. We don't need this now,
> > but will be important if we have more form factors in the future.
> >
> > http://codereview.chromium.org/6851009/
> >
>

[davemoore (google), 2011-04-14 22:34:10]

Emmanuel's right...the GRD file is currently a mess. There was a risk it was
about to get even worse, with more resources customized for cros, but after
talking to alcor and sail I think we'll be back to sharing all the toolbar
images. Still we have several images which currently have the entirely
non-descriptive suffix "2" as part of the filename. In addition the touch
images have the prefix "large". I'd like to fix all that and simplify it.

I think a model where the multiple image sizes are either in one file
(although png doesn't support it) or side by side in the same directory
makes sense. As Ben says I wouldn't think to look at those grouped by dir.
If we standardized the names we could automate that process and radically
simplify the grd file.

We could take a slightly different approach for platform specific images,
with subdirectories for the different platforms, to allow each to override
the shared resource. I think it makes sense to look in subdirs for those,
and it will allow that platform's resources to all be visible at once. We
could do that automatically too, again to simplify the grd file.

I think the goal should be that the api that we currently use doesn't
change. I don't know if the Mac ever needs access to both sizes on a given
machine. I know that an individual Mac build needs access to both because we
won't know until runtime if we're in a hires environment or not. For touch I
think we only need the hi res versions at build time (we never show the
small images do we?)

In any event if we need api instead of doing on each lookup we could have
something that specifies which set of images we want to give preference to
that is global to that resource manager.

Dave

On Thu, Apr 14, 2011 at 2:04 PM, Emmanuel Saint-loubert <
saintlou@chromium.org> wrote:

> > The reason we need large icons for touch is purely UX design, right?
>
> Not UX, this is because we need to have larger touch targets for
> fingers, if we stretch the existing icons the screen will look ugly.
> Also Dave does not like (and rightly so) to see the GRD file with so
> many <if>.
>
> -- Emmanuel
>
> On Thu, Apr 14, 2011 at 4:58 PM,  <oshima@chromium.org> wrote:
> >
> > http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README
> > File chrome/app/theme/README (right):
> >
> >
>
http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13
> > chrome/app/theme/README:13: c) Resources common to all screen sizes /
> > density are in:
> > I believe our icons (including touch) assume the same density. They
> > don't work
> > for high density screen because it'll be too small. The reason we need
> > large icons for touch
> > is purely UX design, right?
> >
> > I think what we need from long term perspective is a way to specify
> > the set of icons for given device specification. We don't need this now,
> > but will be important if we have more form factors in the future.
> >
> > http://codereview.chromium.org/6851009/
> >
>

[Emmanuel Saint-loubert-Bié, 2011-04-14 22:39:23]

In the CL I removed the '2' and the 'large' prefixes since they were
no longer needed. I personally don't care which way we go. I do think
to depart from the current situation because we have just too many
combinations of configs

And yes for touch UI a compile time decision is good enough for now.

-- E

On Thu, Apr 14, 2011 at 6:34 PM, David Moore <davemoore@google.com> wrote:
> Emmanuel's right...the GRD file is currently a mess. There was a risk it was
> about to get even worse, with more resources customized for cros, but after
> talking to alcor and sail I think we'll be back to sharing all the toolbar
> images. Still we have several images which currently have the entirely
> non-descriptive suffix "2" as part of the filename. In addition the touch
> images have the prefix "large". I'd like to fix all that and simplify it.
> I think a model where the multiple image sizes are either in one file
> (although png doesn't support it) or side by side in the same directory
> makes sense. As Ben says I wouldn't think to look at those grouped by dir.
> If we standardized the names we could automate that process and radically
> simplify the grd file.
> We could take a slightly different approach for platform specific images,
> with subdirectories for the different platforms, to allow each to override
> the shared resource. I think it makes sense to look in subdirs for those,
> and it will allow that platform's resources to all be visible at once. We
> could do that automatically too, again to simplify the grd file.
> I think the goal should be that the api that we currently use doesn't
> change. I don't know if the Mac ever needs access to both sizes on a given
> machine. I know that an individual Mac build needs access to both because we
> won't know until runtime if we're in a hires environment or not. For touch I
> think we only need the hi res versions at build time (we never show the
> small images do we?)
> In any event if we need api instead of doing on each lookup we could have
> something that specifies which set of images we want to give preference to
> that is global to that resource manager.
>
> Dave
> On Thu, Apr 14, 2011 at 2:04 PM, Emmanuel Saint-loubert
> <saintlou@chromium.org> wrote:
>>
>> > The reason we need large icons for touch is purely UX design, right?
>>
>> Not UX, this is because we need to have larger touch targets for
>> fingers, if we stretch the existing icons the screen will look ugly.
>> Also Dave does not like (and rightly so) to see the GRD file with so
>> many <if>.
>>
>> -- Emmanuel
>>
>> On Thu, Apr 14, 2011 at 4:58 PM,  <oshima@chromium.org> wrote:
>> >
>> > http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README
>> > File chrome/app/theme/README (right):
>> >
>> >
>> >
http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13
>> > chrome/app/theme/README:13: c) Resources common to all screen sizes /
>> > density are in:
>> > I believe our icons (including touch) assume the same density. They
>> > don't work
>> > for high density screen because it'll be too small. The reason we need
>> > large icons for touch
>> > is purely UX design, right?
>> >
>> > I think what we need from long term perspective is a way to specify
>> > the set of icons for given device specification. We don't need this now,
>> > but will be important if we have more form factors in the future.
>> >
>> > http://codereview.chromium.org/6851009/
>> >
>
>

[alcor, 2011-04-15 13:11:21]

Mac will need to switch on the fly if the display configuration changes.



On Apr 14, 2011, at 3:34 PM, David Moore <davemoore@google.com> wrote:

Emmanuel's right...the GRD file is currently a mess. There was a risk it was
about to get even worse, with more resources customized for cros, but after
talking to alcor and sail I think we'll be back to sharing all the toolbar
images. Still we have several images which currently have the entirely
non-descriptive suffix "2" as part of the filename. In addition the touch
images have the prefix "large". I'd like to fix all that and simplify it.

I think a model where the multiple image sizes are either in one file
(although png doesn't support it) or side by side in the same directory
makes sense. As Ben says I wouldn't think to look at those grouped by dir.
If we standardized the names we could automate that process and radically
simplify the grd file.

We could take a slightly different approach for platform specific images,
with subdirectories for the different platforms, to allow each to override
the shared resource. I think it makes sense to look in subdirs for those,
and it will allow that platform's resources to all be visible at once. We
could do that automatically too, again to simplify the grd file.

I think the goal should be that the api that we currently use doesn't
change. I don't know if the Mac ever needs access to both sizes on a given
machine. I know that an individual Mac build needs access to both because we
won't know until runtime if we're in a hires environment or not. For touch I
think we only need the hi res versions at build time (we never show the
small images do we?)

In any event if we need api instead of doing on each lookup we could have
something that specifies which set of images we want to give preference to
that is global to that resource manager.

Dave

On Thu, Apr 14, 2011 at 2:04 PM, Emmanuel Saint-loubert <
saintlou@chromium.org> wrote:

> > The reason we need large icons for touch is purely UX design, right?
>
> Not UX, this is because we need to have larger touch targets for
> fingers, if we stretch the existing icons the screen will look ugly.
> Also Dave does not like (and rightly so) to see the GRD file with so
> many <if>.
>
> -- Emmanuel
>
> On Thu, Apr 14, 2011 at 4:58 PM,  <oshima@chromium.org> wrote:
> >
> > http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README
> > File chrome/app/theme/README (right):
> >
> >
>
http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13
> > chrome/app/theme/README:13: c) Resources common to all screen sizes /
> > density are in:
> > I believe our icons (including touch) assume the same density. They
> > don't work
> > for high density screen because it'll be too small. The reason we need
> > large icons for touch
> > is purely UX design, right?
> >
> > I think what we need from long term perspective is a way to specify
> > the set of icons for given device specification. We don't need this now,
> > but will be important if we have more form factors in the future.
> >
> > http://codereview.chromium.org/6851009/
> >
>

[davemoore (google), 2011-04-15 13:33:09]

Right. I don't think that really complicates things much. We could add an
instance method to ResourceBundle that sets the preferred image size. At run
time only Mac needs to have both sizes available and we would call this
method to change it when necessary. I expect we'll need (or already have) a
notification for that event so all currently displayed images can update.

Dave

On Fri, Apr 15, 2011 at 6:11 AM, Nicholas Jitkoff <alcor@google.com> wrote:

> Mac will need to switch on the fly if the display configuration changes.
>
>
>
> On Apr 14, 2011, at 3:34 PM, David Moore <davemoore@google.com> wrote:
>
> Emmanuel's right...the GRD file is currently a mess. There was a risk it
> was about to get even worse, with more resources customized for cros, but
> after talking to alcor and sail I think we'll be back to sharing all the
> toolbar images. Still we have several images which currently have the
> entirely non-descriptive suffix "2" as part of the filename. In addition the
> touch images have the prefix "large". I'd like to fix all that and simplify
> it.
>
> I think a model where the multiple image sizes are either in one file
> (although png doesn't support it) or side by side in the same directory
> makes sense. As Ben says I wouldn't think to look at those grouped by dir.
> If we standardized the names we could automate that process and radically
> simplify the grd file.
>
> We could take a slightly different approach for platform specific images,
> with subdirectories for the different platforms, to allow each to override
> the shared resource. I think it makes sense to look in subdirs for those,
> and it will allow that platform's resources to all be visible at once. We
> could do that automatically too, again to simplify the grd file.
>
> I think the goal should be that the api that we currently use doesn't
> change. I don't know if the Mac ever needs access to both sizes on a given
> machine. I know that an individual Mac build needs access to both because we
> won't know until runtime if we're in a hires environment or not. For touch I
> think we only need the hi res versions at build time (we never show the
> small images do we?)
>
> In any event if we need api instead of doing on each lookup we could have
> something that specifies which set of images we want to give preference to
> that is global to that resource manager.
>
> Dave
>
> On Thu, Apr 14, 2011 at 2:04 PM, Emmanuel Saint-loubert
<<saintlou@chromium.org>
> saintlou@chromium.org> wrote:
>
>> > The reason we need large icons for touch is purely UX design, right?
>>
>> Not UX, this is because we need to have larger touch targets for
>> fingers, if we stretch the existing icons the screen will look ugly.
>> Also Dave does not like (and rightly so) to see the GRD file with so
>> many <if>.
>>
>> -- Emmanuel
>>
>> On Thu, Apr 14, 2011 at 4:58 PM,  < <oshima@chromium.org>
>> oshima@chromium.org> wrote:
>> >
>> > <http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README>
>> http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README
>> > File chrome/app/theme/README (right):
>> >
>> >
>>
<http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13>
>>
http://codereview.chromium.org/6851009/diff/1/chrome/app/theme/README#newcode13
>> > chrome/app/theme/README:13: c) Resources common to all screen sizes /
>> > density are in:
>> > I believe our icons (including touch) assume the same density. They
>> > don't work
>> > for high density screen because it'll be too small. The reason we need
>> > large icons for touch
>> > is purely UX design, right?
>> >
>> > I think what we need from long term perspective is a way to specify
>> > the set of icons for given device specification. We don't need this now,
>> > but will be important if we have more form factors in the future.
>> >
>> > <http://codereview.chromium.org/6851009/>
>> http://codereview.chromium.org/6851009/
>> >
>>
>
>