Open mymike00 opened 7 years ago
Stupid question: Can you start a landscape app and then lock it in landscape and further on use it in landscape until you unlock and start a portrait app, etc. It's clunky, but maybe one could hack a workaround together
@doniks He've phone accelerometer broken. So he want a way to select manually the correct rotation. He cannot simply block the rotation in the existing position, because if he rotates the phone, the screen doesn't change orientation ;-)
Sure, I get that.
Some apps do ALWAYS start in landscape (Machines vs Machines). Other apps do ALWAYS start in portrait (Dialer I think). I expect that this behavior does not change when the accelerometer is broken.
I'm just trying to suggest a workaround. My suggestion does NOT involve him to physically rotate the phone. I acknowledge that my description is rather brief, is it clear now though?
Instead of using Machines vs Machines and Dialer one could create two tiny "apps" that do nothing other than rotate by putting
X-Ubuntu-Supported-Orientations=landscape or X-Ubuntu-Supported-Orientations=portrait and Exec=sleep 7
into the .desktop files
Some apps do ALWAYS start in landscape (Machines vs Machines). Other apps do ALWAYS start in portrait (Dialer I think). I expect that this behavior does not change when the accelerometer is broken.
Yeah, that's right. But when I lock the rotation it doesn't lock the actual screen rotation state, but it locks the value it gets from the accelerometer (that is always portrait...). I've already tried... That way worked on Android but not here...
@NeoTheThird , @mariogrip you tagged it as good first issue and help wanted, but I'm wondering, what is the "normal" use case to support here? Isn't this only useful for broken accelerometers?!
Well, not imo. Like when I'm in the bed I need the rotation fixed and to do it I have to put the phone vertical and lock the rotation. Worth the manual selector it's easier and, imho, a nice feature...
got it
I plan to fix this myself, but now I cannot set up the right working env. As soon as I have some time i'll try to set it up and try to fix the bug
Don't take it personal, but in my opinion the benefit of this still doesn't outweigh my preference for a simple and clean UI.
So I understand the use case is: I want the device locked in landscape.
Current way:
Newly proposed solution would also allow me to
That doesn't even sound like a big benefit. It feels quite unnatural to me. Rotation is all about physically interacting with the device, but now I make the UI turn sideways by interacting with software....
Totally extraneous concern: what about the other two orientations, remember there are four!
@doniks: Maybe we should also think of monitors used in portrait not having any sensors... Btw. gnome3 has this switches, but hides them if sensors are detected. But also for people who don't like the auto rotation at all, having it disabled all the time and want to change the orientation, it may be a bit more natural to
than to
But I think would hide or grey out the options 'portrait' and 'landscape' if 'lock rotation' is disabled and remove the option 'rotation' in that case. Or removing the 'lock rotation' switch and having only the option selector (radio buttons) with the options 'auto', 'portrait' and 'landscape'.
Maybe we should also think of monitors used in portrait not having any sensors...
True. I didn't think of this. But now we're talking about setting up a desktop with a non-default monitor setup. I don't think these (mostly one off) setting need to get prime screen real estate in the notification section of the smart phone layout. Also if we talk about fancy monitor setups, we probably talk about multi-monitor as well in short order. I think this would better fit in system settings.
But also for people who don't like the auto rotation at all, having it disabled all the time and want to change the orientation, it may be a bit more natural to
Well, yes that would be more natural, but I wonder where this "don't like auto rotation" comes from? Is this because "auto rotation doesn't work well". If that's the case then we should fix that bug (Here's a recent example of a call for more locking, which I think is actually a different bug : https://forums.ubports.com/topic/1654/rotation-lock-for-specific-apps )
The only two use cases for rotation lock that I can think of are:
Once I'm done with either of these I unlock the rotation again. Locking the current orientation is perfectly suitable for these use cases.
You seem to be talking about a use case where you want to transition through multiple forced orientations: Now I force it into portrait, next up I want to force it into landscape .... I still don't see this use case
Another thought for the two item suggestions: landscape and portrait.
A monitor rotates into at least three different positions. On my tablet there are four different orientations that have their good justifications:
As @Arc676 rightfully pointed out, my issue #957 is a dupe of this one. So I'm merging here and closing that one.
@myii sure,but I think you could also don't post again the whole issue, just add your opinion
@mymike00 Thank you for your comment. I'm not exactly sure what the problem is. If there is some specific etiquette that I've gone against, I would appreciate it if you could share a link that explains that.
My justification is that I was merging the issues. If there was nothing new/different, I would simply have closed my issue and not bothered including anything here at all. However:
That's most of the content I pasted. Didn't even occur to me to remove the few other lines.
Update: Have removed the text above.
@myii if I understood your dup correctly, you would be interested in implementing this right? Are you still in doubt whether it would be accepted? While @doniks argued it may not need the indicator prominence, I think on the other hand it does not do any harm, since the the rotation indicator is basically empty now (or are there any plans to merge it with another indicator?). I think it would be accepted... May anyone confirm that implementing this in the rotation indicator would be accepted @NeoTheThird maybe? @cibersheep do we want to add some official mockups? So we need radio buttons that are greyed out or not visible if automatic rotation is switched on...(?)
@myii When you reference one issue from another with the hash linking, GitHub shows a direct link between the issues, in each issue. There is no need to copy/paste the entire content of your other issue into this one. This is what @mymike00 as asking you to avoid.
Also, in general, I would say that bug reports/issues should not provide suggestions for what should be implemented, or how to implement it. Rather, they should state the problem which you are trying to solve, so that the designers/developers can solve the problem in the most appropriate way.
For example, in the original report here, the problem is that the accelerometer is not working, and there is no way to rotate the screen, even with Rotation Lock disabled. Your "issue" is simply a statement of a suggested solution. However, neither of these takes into account the full convergence aspect of Unity8. For instance, a related problem under Unity8, is that there is no way to change display configuration at all. If you run it on a PC (or in a VM), you are stuck only with the resolution detected. There is no way to change resolution, handle multiple displays, or alter rotation of individual displays. These two problems are very closely related, and I think we need much greater examination of the full set of what we want out of Unity8, before implementing any possible solutions to individual points of these issues.
@hummlbach there's an open discussion about notification area (and it looks it will go on a bit longer :D) for now it's in this week fashion extravaganza. but as @dobey says, it looks a wider problem we want to address here.
Unity8 should converge but misses orientation and resolution options. Do we have a plan on that?
Mhmm, okay, but... If there is someone who is willing to implement it the easy way... what keeps us from pulling that in, until the greater examination is done and implemented? The implementer should just be aware that his implementation will most likely be removed again later.(?)
@hummlbach
if I understood your dup correctly, you would be interested in implementing this right? Are you still in doubt whether it would be accepted?
Judging upon the comment from @dobey, it appears that there are wider issues to consider first.
@dobey
When you reference one issue from another with the hash linking, GitHub shows a direct link between the issues, in each issue. There is no need to copy/paste the entire content of your other issue into this one. This is what @mymike00 as asking you to avoid.
Fixed above.
Also, in general, I would say that bug reports/issues should not provide suggestions for what should be implemented, or how to implement it. Rather, they should state the problem which you are trying to solve, so that the designers/developers can solve the problem in the most appropriate way.
Here I am unclear. Starting an issue has a feature request template that contains: Describe what feature you'd like to see
. Describing a feature leads to making such suggestions, as has happened in many comments above. The designers/developers will always implement them according to what they know best.
... However, neither of these takes into account the full convergence aspect of Unity8. ...
Fully understand and give full deference to those in the know.
Here I am unclear. Starting an issue has a feature request template that contains:
Describe what feature you'd like to see
. Describing a feature leads to making such suggestions, as has happened in many comments above. The designers/developers will always implement them according to what they know best.
OK. I think that template is wrong then. "I want this feature," almost always ends up leading toward the problem of broken features which don't suit the needs of others as well, nor necessarily fit well with the core design of the platform. Take MS Office for example, as it's something which has had decades of feature requests, where people ask for features without describing the problem they are trying to solve. You always end up with way too many features, most of which are rarely used. It is far better to describe the problem, so that discussion is around how to solve that problem, rather than what color the implementation should be.
Malfunctioning accelerometer is an endemic problem on Nexus 7 (2013). Most of the times it can be fixed by disassembling the tablet and reinserting the flex cable on top of the battery.
That being said, I'd prefer having a way to manually set the rotation I want. On android I used an app called "Rotation Control" to add the feature.
I see a lot of discussion from both parts but no progress to a solution. If you don't want to clutter the user interface, it could at least be shown inside the System Settings app, instead of the quick settings.
I also have Nexus 2013 Wi-Fi, and it is the reason I do not use Ubuntu Touch. I was hoping to find at least a command line solution.
I also have the same problem with BQ Aquaris 10" tablet, with UT "edge" branch.
As improvements are discussed about the screen rotation:
Is it possible to make the screen rotation less sensitive? Or offer the possibility to adjust the sensitivity? With Pixel 3a I find that the screen changes orientation easily which can create discomfort. I would appreciate a stickier screen that requires a little bit of tilting of the phone to make it change orientation.
Is it relevant to put the screen upside down in portrait mode? It's a bit awkward when answering a call upside down... or, considering possible use cases as exposed here https://github.com/ubports/ubuntu-touch/issues/69#issuecomment-419696354, could it be configurable (disable this orientation)?
2. Is it relevant to put the screen upside down in portrait mode?
Yes it is :)
My phone accelerometer is broken, so I can only use it in portrait mode except for apps that require landscape mode. In the drop-down menu under the 'Rotation' tab would very useful for me adding a
ItemSelector
or anOptionSelector
to select the rotation mode (landscape/portrait), maybe also withexpanded: true
.Something like this (more or less)