01-20-2014 11:29 AM - edited 01-20-2014 11:30 AM
your link gets errored out as 404 because of a space at the end again ...
Would it be possible for you to push through a request to bake this into imageviews instead of having devlopers run around trying to figure out why exif data isn't working properly for some reason or another.
I remember around the beginning of 10.1/10.2 there was another temporary exif issue.
And also developers are getting apps denied because some devices just aren't handling this information properly, this could easily be avoided by baking this in and then allowing us developers to rotate our correctly displayed images in whatever obscured direction we please instead of providing us with the image in an obsucred direction and saying hey deal with this....
01-20-2014 11:34 AM
I don't know how that keeps happening. I am just copying and pasting the link right out of Chrome!
The best way to have this get escalated would be for one of you to log it as a feature request in DIT. Then everyone who is interested can vote on it. Having a feature request in DIT with a whole buch of people voting on it is a lot more compelling than me trying to push it through myself.
01-20-2014 11:46 AM
I think the problem was with my app. My bad. I didn't handle the orientation tag == 3 which is taking landscape left top. I always take landscape right top.
01-20-2014 11:48 AM
I think the feature request system is relied on too much for the wrong reasons but i'll create a ticket and post the link here
Jira takes a while to load and this discourages others to vote, you guys seem to rely on votes too highly to consider requests and alot of people would rather not deal with jira, especially when they've already talked about the issue in a Blackberries publicly open forum (I say this because there's still issues out there that crop up on the forums and havent been fixed because issue tracker is relied on too much... the forums should come in as a priority over the tracking system), maybe assigning someone to create priority tickets based on forum information would be a better route to making sure things get dealt with instead of ignored.
(just my thoughts on that area)
Jira Ticket on this issue.
01-20-2014 12:01 PM
I don't want to derail this thread, so this is all I'll say on the matter (if you'd like to discuss it further we can create a new thread, we definitely want to make things useful): The main reason we want feature requests is to make things trackable and make sure we are doing things developers actually want. I'm not saying it's a perfect process (it isn't, and you've identified several of the problems), but what we don't want to do is spend our time building features that no one, or just one or two squeaky wheels asked for.
It lets us better say things like "Implementing this feature would help X many developers, and you can see that because they took the time to log the feature and vote on it and whatever. Also, this is what they actually want rather than the aggregate interpretation of a bunch of forum threads where we might have missed key details". It also lets is go back and close them saying "Yes, this was done in 10.X" or whatever.
I don't think the approach of "Please log a feature in DIT" is fundamentally flawed, just that DIT itself is slow and can be a pain to use. That is something we are aware of and working on fixing.
Anyway, the issue should be public now, please vote on it if you like it
01-20-2014 12:10 PM
regarding an ImageView that "just works"...
Someone should just write a new custom control derived from ImageView which just overloads how images are loaded to account for EXIF.
I say "someone", because I think the internal teams are super busy on other things right now. Even if we did put something out, it would be many many months from now, whereas if someone from the community just published a new custom control, it would be available immediately. for everyone. independent of the OS version people are running.
01-20-2014 12:12 PM
01-20-2014 12:21 PM - edited 01-20-2014 12:25 PM
ExifImageViewer (if working on the Z30 I dont have one to test) could be classified as a 'solution' but not really because it prioritizes C++ users over qml users.
lack of orientation support affects qml users as widely as c++ users and it would be lovely for them to not have to worry about this without having to worry about integrating cpp and header files into their app. (it is failry straightforward) but for the new learners not really and this is a feature that shouldn't be as difficult as it has proven to be.
Also the internal teams are probably pretty tied up, they're always going to be as long as this OS is rolling but this is something that is making developers go out of their way just to do something the system should be doing itself (the lack of orientation for imageviews is basically opposite of what it should have been from the start) so they should take the time to fix this (and many other current things) before proceeding with new things.
I'm not trying to harpoon you guys
just trying to point out some issue area's with the current way things work in hopes of everything getting better for everyone.
01-20-2014 01:47 PM - edited 01-20-2014 01:48 PM
I'm not sure you're supposed to access ExifEntry::data directly.
See my sample here:
Note that I have to check exif_get_data_byte_order() (this may differ on the Z30 perhaps?), and entry->format (may also be different for some reason).
You should only access exif data using the exif_get_xxxx() functions, never directly.
I'm not sure if the ExifImageViewer sample does this correctly or not, though it does seem to be using exif_entry_get_value() which is supposed to return a stringified value.