Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Incorrect artwork sizes in drawable folders #263

Closed
SecUpwN opened this issue Jan 7, 2015 · 13 comments
Closed

Incorrect artwork sizes in drawable folders #263

SecUpwN opened this issue Jan 7, 2015 · 13 comments
Assignees

Comments

@SecUpwN
Copy link
Member

SecUpwN commented Jan 7, 2015

Sorry folks, another Issue. If @tobykurien or @Ueland can calrify some things to me, I will assign this to myself and solve this quickly, especially since I am currently working with GIMP anyhow. Here it is:

After checking 463fec0, I noticed that we are using different sizes in the drawable folders. But as far as I know Icons sizes really depend on what type of Icon it is and where it is placed within the App. With this Issue I would like to check and fix all of our Icons, map pins and anything else in the drawable folders.


Resources:


Question for @tobykurien: After you've had a close look into our drawables, is it only the map pins that are incorrect, or also the menu Icons or anything else as well? Please post a list what needs to be fixed!

@tobykurien
Copy link
Contributor

Only the map pins that were recently modified. You should use this tool to correctly resize the drawables: https://romannurik.github.io/AndroidAssetStudio/

@SecUpwN
Copy link
Member Author

SecUpwN commented Jan 7, 2015

@E3V3A, I am fixing your pins from 463fec0 right now, but need them in higher resolution.

The problem is that you've apparently placed tiny pins in folders where the App expects high resolution Images (e. g. pictures of 44x44 in size do not belong in drawable-xxhdpi where a size of 144x144 is expected). So please, post a link to the pins in their highest resolution here, I will take care of the rest.

@E3V3A
Copy link
Contributor

E3V3A commented Jan 7, 2015

@SecUpwN
No, the problem is that the pins relative (to map) size are too large.
So it is probably much easier for you to make new pins with same colors:

GREEN 33BB00
ORANGE E68000

Here are the tricky parts:

  • The GREEN, ORANGE, and RED pins should be displayed as ~30% diameter size of the BLUE pin.
  • The physical largest icon size (canvas size) should be about 144 pixels, for these small pins.
  • The actual icon (solid filled circle) only takes up about 35-50% width of the canvas.
  • All pins (now filled circles) have to be centered on the canvas, because of this.

Conclusion, canvas size doesn't matter apart the size of the file. The exact and relative icon sizes does. But here you go.

@SecUpwN SecUpwN self-assigned this Jan 7, 2015
@SecUpwN
Copy link
Member Author

SecUpwN commented Jan 7, 2015

@E3V3A, thanks for the instructions, I'm crafting these at the very moment. Would these work?

  • BLUE pin at largest scale: 144x144 canvas size and centered
  • The pins GREEN ORANGE and RED are not changing size but placed on proper canvas
  • All filled circle pins are getting the same canvas size as our Status Icons in each folder

Please give me a hint if I misunderstood your instructions. EDIT: I will push now, please check!

SecUpwN pushed a commit that referenced this issue Jan 7, 2015
@E3V3A
Copy link
Contributor

E3V3A commented Jan 7, 2015

I haven't recompiled, but just from looking at them, I bet they are still too big, since the not-blue icons are all bigger than the blue one, when they should be < 33% of the blue one's size... (Which is how I tested before I made them all the same size.)

@SecUpwN
Copy link
Member Author

SecUpwN commented Jan 7, 2015

@E3V3A, I do not get what to change. @tobykurien, would you please take a minute to correct it?

@E3V3A
Copy link
Contributor

E3V3A commented Jan 7, 2015

@SecUpwN If you don't get what to change, why did you change it? Now the icons are HUGE. You should revert that icon PR... (Did you even test it on your own device?)

@He3556
Copy link
Collaborator

He3556 commented Jan 7, 2015

The (absolute) sizes are correct of the icons. And the icons itself is a little smaller (about 30%) than the blue ones. The difference you can see from the distance between the circle and the border - the red line.
Let's try and compile it
cl
cl2

i am doing it right now...

@He3556
Copy link
Collaborator

He3556 commented Jan 7, 2015

Mhh, ok they are getting bigger when i zoom out. So i think we need to use the clustering feature of openStreetMap. No matter how small the icon are, it will always be to big as long as we show them all on the map and don't use the clustering.

@E3V3A
Copy link
Contributor

E3V3A commented Jan 7, 2015

I did, that's why I answered. Now at the largest zoom-in factor, the green dots are the size of a house, and the blue bigger. What you have to account for are not the border of the canvas, but the relative diameters in pixels. Thus the green diameter should be < 30% of the blue one, possibly more. Of course this is not fixed, but that is kind of what I found look better on my device. So if you have a larger screen it will probably look better as the dots become relatively smaller. AND all icons even smaller than what they are now.

@E3V3A
Copy link
Contributor

E3V3A commented Jan 7, 2015

With the way these pins are drawn at the moment, using a fixed overlay (?) that doesn't scale along with the map (shadow layer), the icons we always look huge. Which is probably why Michael of Antennas decided to use circles drawn instead of icons. I don't know if you can scale the icons with the map, only OSM expert can answer. Perhaps @ziem?

Please see his response in my email.

  • We're trying to get filled circles drawn in different colors and
    sizes, precisely centered on the position.

Omsdroid doesn't support marker coloring like google maps. But this can be achieved using tinting or ColorFilter:
http://stackoverflow.com/questions/25482489/what-is-new-in-drawable-tinting-in-android-l-developer-preview-compared-to-previ (available only in Android L)
http://blog.danlew.net/2014/08/18/fast-android-asset-theming-with-colorfilter/

  • We'd like to have connecting lines to a few of these points.

This can be done with PathOverlay class. Which is deprecated ;(. Osmdroid authors recommended using https://code.google.com/p/osmbonuspack/ which is under GNU Lesser GPL license. Is it OK?

Sound good to me, but it depend on the license, size and whether there
are any hidden and privacy invading bloat in that package. We have to
discuss with our developers.

@He3556
Copy link
Collaborator

He3556 commented Jan 7, 2015

To change it to vector/drawn icons would be a lot of work (for nothing than colored dots).
Instead i rather try to get some dots done with one of the tools, Toby linked to. Give me some time...

@SecUpwN
Copy link
Member Author

SecUpwN commented Jan 8, 2015

If you don't get what to change, why did you change it?

@E3V3A, because I had a problem with the old Icons not respecting the drawable properties at all, no matter if the new pins would work as expected or not. We all have to be more patient with each other.

So i think we need to use the clustering feature of openStreetMap.

@He3556, I am very thankful you're digging into this, and a special THANKS flies out to @ziem, I've heard he will be coding the clustering of the Icons. Awesome thing, will wait for the pull request!

Instead i rather try to get some dots done with one of the tools, Toby linked to. Give me some time...

Time granted! 👍 @He3556, I will then just overwrite the other pins, this time with the correct ones.

@E3V3A, do not wonder why the pins might not scale correctly after I pushed them. When we added the clustering from @ziem, those should work perfectly. A new test version will be available internally shortly.

SecUpwN pushed a commit that referenced this issue Jan 8, 2015
@SecUpwN SecUpwN closed this as completed Jan 11, 2015
SecUpwN pushed a commit that referenced this issue Apr 17, 2015
SecUpwN pushed a commit that referenced this issue Apr 17, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants