- User Since
- Apr 15 2017, 7:18 PM (62 w, 8 h)
Fri, Jun 22
I don't favor making this a full-screen overlay. In addition to the annoyance factor and (legitimate) complaints about wasteful use of space that this would provoke, it would destroy the ability to see what your changes will look like in actual use, since it obscures whatever you were doing at the time when you decided to change the settings.
I had a feeling the config option approach would make the most sense. I'll start work and see if I can produce a user interface that makes sense.
Any opinions on the latest version? The screenshots are all up to date.
Seems nobody objects and the 5.48 string freeze is tomorrow. Landing this diff.
BUG: 395681 can't be a link, I don't think. It's gotta just be plain old dumb text. :) Also, it seems that this is dependent on D13573. So please also add Depends on D13573 to the Summary section somewhere. Then do arc amend locally. Thanks!
Thanks, that seems to fix the bug!
Fix logic error
Better now, thanks!
Thu, Jun 21
@mmustac very nice! Should we consider 191632 to be resolved, or wait until you're implemented support for plain old non-.desktop files in ~/Templates?
+1 for @januz's idea about not following the alternating background color for header rows (i.e. make them always be white or gray). I think that would help to make albums more distinct from one another in the list.
Also, this regresses the Install button width in Discover, and other main action buttons, which you can see in your screen recording. They're now very narrow and don't have enough side padding.
I don't know if it was supposed to, but FWIW this does not fix https://bugs.kde.org/show_bug.cgi?id=395455.
Icon patches always need screenshots! :)
I've never been terribly convinced by the "someone could be looking over your shoulder!" argument because conceptually, there is no automatic way to protect against it. If what you're currently doing is really so sensitive or embarrassing that nobody should be able to see it while you're doing it, then only situational awareness can save you: don't do it in a public place or where your screen could be made visible to others. Don't watch porn at the library or do your online banking at a coffee ship. It's just asking for trouble.
Wed, Jun 20
An enormous improvement!!!
Thanks for the patches! You can add Closes T9050 to one of those to make it automatically close this ticket once it's landed.
Right. That's not a workflow I think I've ever seen anyone do with a windowed game. For anyone who wants to do that, they can always turn the borders back on. Or just resize one of the windows slightly so the dead zone doesn't overlap the game window. Or not try to play a windowed game right next to a window that's explicitly marked as always on top. Or any number of other very simple tweaks.
What is the problem with an FPS in windowed mode? If anything, the potential problem would be a windowed RTS or other game where you're expected to move the view by touching a window edge. But even in this case, the "dead zone" is outside the window rather than inside it, so that critical pixel is always available to the game, and I don't see what the issue is. I sometimes plan Endless Sky windowed with No Borders and I've never encountered a single issue related to the dead zone. Can you clarify which potential issues you're worried about?
Hmm, I think maybe I confused you, @sharvey. I was referring to this project, and I was wondering why you seemed to have abandoned it! ;-)
Please replace BUG: https://bugs.kde.org/show_bug.cgi?id=395580 with BUG: 395580. See https://community.kde.org/Infrastructure/Phabricator#Add_special_keywords
Tue, Jun 19
Unmodified arrow keys: move/resize by single pixel
Arrow keys with shift held down: move/resize by large increment
All good now?
Also move the General section to the top in the docbook, to match the UI change
Move the new mMessageWidget->hide(); call to a separate commit
Sure, I'll make the doc change too.
I've moved my ideas into sub-tasks of T9042: Kickoff improvements so as not to clutter up this ticket, which really should be used to track convergence.
Pitch it to the Plasma devs, I guess. Maybe at the upcoming 5.14 kickoff meeting?
Oh sure, we could and should also add new apps to the existing History tab and badge them there, just like in the mockup for the Home tab here.
Hmm, most drawing programs I'm familiar with move by single pixels with the unmodified arrow keys, and increase the movement with the ⇧ key. I think that's what we were proposing. In other words, just change the modifier for the "large movement step" action.
Maybe we could combine the content from the kscreenlocker and SDDM KCMs into a new "Lock & Login screen" KCM? Then the KWallet KCM could be a top-level KCM under Personalization or be combined with something else.
I proposed a crude mockup for an improved desktop version of Kickoff in T7913#147930. With a Full Screen button visible somewhere on there, it could easily become a full-screen UI like our Application Dashboard or GNOME's Activities Overview serve the convergence mission.
How about in a tooltip?
- Security & Privacy (Contains Screen Locking, SDDM, and KWallet KCMs in a tabbed view)
I am not sure if I would expect the screen lock in security & privacy... The Screen Lock KCM also includes some appearance elements, maybe separate those?
We have a request in https://bugs.kde.org/show_bug.cgi?id=395405 for an additional token: the current directory name. Possibly also one for the full path to the current directory.
Looks good to me too.
Does this/should this also implement the diff from D13278?
Any more thoughts on my proposed re-organization above?
Proceeding with the labels-on-the-left approach. IMHO it's hugely improved by increasing the spacing between sections.
Formally abandoning this in favor of D13493, which really is a much better approach.
- Improve awkward "Expandable folders:  Enable" string
- Replace "General:" with "Miscellaneous:" so we don't have three instances of the word "general" visible at once
- Use a bit more padding between sections to improve their distinctiveness