> On Feb. 11, 2015, 4:14 p.m., Andrew Lake wrote: > > It might be worth investigating the use-case a bit further to try to > > understand if this is the best way to solve this. Is it useful? Yes. But > > there are potentiall negative impacts that should be balanced against the > > relative increase in utility. > > > > We also need to belly up to identifying primary and secondary target > > personas and scenarios for Plasma (maybe a thing for the upcomign sprint). > > At best, I'd suggest that exposing the host name here would target a > > secondary persona and any associated scenarios. > > > > While I can't argue that the scenario in the bug report isn't legitimate, > > I'm not sure it warrants adding information to the lock-screen that is of > > little-to-no value to primary target personas and scenarios. The cost we're > > trying to mitigate in the bug report is that the user logs in/unlocks to > > identify the computer versus knowing it one interaction step earlier. > > > > For the lab/shared computers, the scenario requires that more than one > > computer is shared (probably in relative proximity to each other) and some > > particular need that requires knowing the computer identity *before* > > logging in/unlocking. Even in corporate environments that seems like quite > > a marginal scenario. > > > > So for me, I'm struggling to see how the potentially negative impact of > > added information noise for what I think are the primary target personas > > and scenarios balances what is, I think, a marginal increase in utility for > > a marginal scenario for a secondary target persona. > > > > Hope this helps! > > Martin Gräßlin wrote: > Thanks for your feedback. I'm wondering whether we could make the > information easily available without adding noise in general. I really think > it's worth to invest the effort to provide this data as it's important in the > situations when it's needed (e.g. labs). > > Aleix Pol Gonzalez wrote: > Would it be possible to use something like Kiosk to decide what > information to show? > Such deployments usually mingle with Kiosk.
yeah, didn't chime in on this one so far but i agree with Andrew could be enabled as aleix says with kiosk (that would mean pretty much an hidden config option, which poses the problem that will make it bitrot. or could be just supposed for deployers to customize the look and feel package.. will ask them to maintain qml code that's a bit nasty as well - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122522/#review75870 ----------------------------------------------------------- On Feb. 11, 2015, 1:59 p.m., Martin Gräßlin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/122522/ > ----------------------------------------------------------- > > (Updated Feb. 11, 2015, 1:59 p.m.) > > > Review request for Plasma and Andrew Lake. > > > Bugs: 294778 > https://bugs.kde.org/show_bug.cgi?id=294778 > > > Repository: plasma-workspace > > > Description > ------- > > FEATURE: 294778 > FIXED-IN: 5.3.0 > > > Diffs > ----- > > lookandfeel/contents/components/InfoPane.qml > 18739ad96724f520ce8467ba5d4c9595e8a9e9ed > > Diff: https://git.reviewboard.kde.org/r/122522/diff/ > > > Testing > ------- > > > File Attachments > ---------------- > > Screenshot of LockScreen with new info > > https://git.reviewboard.kde.org/media/uploaded/files/2015/02/11/771f0a24-aaa1-4bc4-afe8-53c44fe68d71__snapshot_TJ8703.png > > > Thanks, > > Martin Gräßlin > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
