_sharvey_ on IRC.
_sharvey_ on IRC.
Hopefully .arclint is gone for good this time.
Okay, a clean copy. Apologies for the mess. I can do the coding, but the infrastructure is another story...
There's no functionality to remove files. I'll submit a new diff.
Remove untracked .arclint and CMakeLists.txt.user
Changes to .arclint look unintended, and I'm not sure you meant to check in CMakeLists.txt.user.
Plasma team: Please help me review and fix the failing autotests. I'm not familiar enough with the internals of KWayland - or autotests - to successfully debug what's happening. The patch builds and compiles without error.
I think this has to be considered an "advanced" topic. We've first got to get the new people submitting patches and having them accepted. I've been banging away at patches and bugfixes for the past 8 months and have never even investigated how to package something for distribution. I'm working on a personal project that I'll want to distribute, but I've got plenty of coding before I get there.
Thanks, can confirm that the issue with doubled resizing is fixed. Accepting for now, even though the code is not the most concise yet.
Please commit to the stable branch.
a more general tip, it should be easier to branch off of the stable branch (Applications/18.08) if you are submitting a bugfix, like so:
git checkout Applications/18.08 git pull arc feature fix-stuck-edges
Currently your patch is branched from master, which makes landing to stable more difficult, as it requires extra steps for rebasing and specifying the target branch.
@rkflx - I fixed the double-size movement for Alt + ↑ (and Alt + ⇧ + ↑ as well).
As soon as D12311: Align lock icon with bold message text; reduce overall size of dialog is landed, I'll change this string.
I'm still in favor of the brief but descriptive "Not Provided". This is an advanced developer field. I could add a tooltip with some additional information. My point is to convey the fact that "the vendor is supposed to provide this information, but did not."
I believe it's done.
Here you go - a freshly rewritten arrow/rectangle handler. It's still got a fair bit of repetition, which I'd like to work on at some point. This version does not get "stuck" at the screen edges. It also stops resizing the rectangle to a minimum of 20x20px, the same as the initial mouse click to start the rectangle.
First draft looks great! I like how bold the names of the apps appear on the slides. Really jumps out and looks like "confidence".
It seems you forgot to merge stable into master, which I now have done with
Thanks, looking much better now.
Please make sure to commit to the stable branch, i.e. Applications/18.08 (let me know if you are unsure what that means).
Tagging is on Thursday at 23:59 UTC. I will accept the patch tomorrow so you can still land it in time (let me know if you are busy and I should commit on your behalf).
Yeah, the magnifier shows up while dragging the selection rect (or not, depending on whether or not you've holding down ⇧), but it currently doesn't show up when you're using Alt to resize the rect using the keyboard arrow keys.
IMHO, if you have the magnifier turned on in the settings, it should show up when you're in "fine tune" mode (holding down both ⇧ and Alt and using the arrow keys to resize the rect by single pixels), because conceptually, if you're doing this, it's because you want a pixel-perfect rect.
I still disagree regarding the default speed selection. We determined by looking at other apps that ⇧ is the modifier to use, and I argued (in line with what I meant when triaging the bug) that for making the rectangle feature useful for keyboard users by default the movement should be fast. BTW, this is also what KWin is doing, and I see no reason at all why Spectacle should deviate from that standard. (See above for even more arguments.) I don't feel comfortable approving the current default, sorry.
I'm noticing that the magnifier doesn't er show up while you're using the keyboard to resize the selection rect. Might wanna hook that up.
- Selecting with the mouse sets a minimum size, however resizing with the arrow keys allows to resize to 0x0px.
I will attempt to get these completed early tomorrow morning (my time). It's already the end of the day here and I know (from unfortunate experience) that I don't do my best work "after hours".
About the date: that's not the release date, but the date where the document was last updated.
There's only one remaining thing to do from my perspective: update the docbook to document this nice new feature! It would be great if you could do that in this patch. Keep in mind that 18.08 has already been branched and the freeze is in two days, so if you'd like to get this in for the next release, you'll have to work quickly. :)
I apologize for the delay in getting this finalized. It's been a tumultuous month in real life. Including emergency heart surgery for my father, a flare-up of my own illnesses (I'm on disability), and finally - a kernel upgrade that somehow failed, rendering my machine unbootable. Lots of reinstalling and reconfiguring.
Also, looks like the current policy for HiDPI is to "scale up" the moves, so if I set QT_SCALE_FACTOR=5, the smallest move is 5 real pixels. We probably want to change that, so that we move by factor / Screen.devicePixelRatio which would ensure we move by factor "real" pixels. Apart from that, 15px seems pretty good on my 2560x1440 monitor.
I probably need to do a little whitespace & indenting cleanup. I'll hold off until everyone's satisfied with the behavior. Just want you to know I'm aware of it.
Hm, my intention when I triaged the bug was indeed to make it possible to set the selection rectangle from the keyboard. When I mentioned the separate patch, this was only about how to start the actual selection process. I don't think it makes sense to change the speed later again, we should get it right here.
@abalaji: I have to respectfully disagree with the idea of multi-directional movement. My intent behind this patch remains geared toward incremental adjustments to the original mouse-drawn rectangle, not a full-blown replacement for drawing a rectangle entirely from the keyboard and having to make dramatic changes.
Okay, I've finally gotten a working, reusable, reasonably sensible function for keeping the rectangle constrained inside the screen.
Can you have a look at the code in kdeclarative, specifically src/qmlcontrols/kcoreaddons/kuserproxy.cpp - that's where the KDirWatch monitoring the face.icon file is. I think you need to place some qDebug() there to see if the file change gets picked up on your system and the signal emitted. If this is working, then we know the problem has to be in the QML side.
Can you elaborate what you tried and what you wanted to happen and what didn't happen? I'm a bit confused now @ touch.
Trying to use touch made no difference. I called it manually between changes, and actually added it (temporarily) to the actual Kickoff code, so it "touched" every time Kickoff was opened. No change.
+1 from me as well. I knew this shortcut from, ahem, other desktops. I thought it was something KDE simply didn't do. Nice fix.
Perhaps I can go into the UserManager KCM, let it change the avatar like always, then run a brief timer (250ms?), and then ‘touch’ the face file so the KDirWatch runs a second time.
@hein : Thanks for the time spent investigating. The User Manager KCM appears to write out proper (non-corrupt) files, at least in my testing. I know there's a KDirWatch in one of the included Frameworks (KCoreAddons, I think), but that seems to work properly. It does indeed copy the file to the other places where it belongs. I'm still at a loss as to why it goes blank, but works when plasmashell is restarted. So Kickoff is picking up on the fact that there's been a change, but the operation doesn't complete.
I'll get back to work on this. I've got a current open patch I need to finish up first, then I'll resume work on this. Should be a couple days at most.
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! ;-)
@abetts - Nate has told me that there's a project in the works to redesign and standardize the entire collection of dialog boxes.
Unmodified arrow keys: move/resize by single pixel
Arrow keys with shift held down: move/resize by large increment
Okay then. ⇧ will slow the movement/resizing down to 1px. Will probably use CTRL for mode switching.
As an FYI... the way Kicker/Kickoff/Dashboard are coded is very clever. The individual icon entries are all created from the same code. Eike is very good at writing reusable code. The different launchers just sort and display them in different layouts. So if we add a "new" badge (an idea to which I give a +1), I believe it will show up in all the launchers. I don't see that as a bad thing, however.
I'll pitch in if I can. I've spent enough time in the Kickoff code trying to make circular avatars... argh.
Okay, so my short-term to-do list for this is:
A couple of random ideas:
Strike everywhere I mentioned the new QML rectangle. The existing rectangle is QML. As I said, I'm a bit foggy at the moment.
- Did Nate mention that currently there is work underway in D12626: Port QML Rectangle cropper to QWidget + QPainter? Not sure what's the best course of action though, i.e. whether to rebase on the port now, or finish the QML-based patch and port later.
Although I haven't tested it, that patch sounds like it operates more quickly. If that's the case, it might make sense for me to hold off on this and refactor it based on the new & improved rectangle.
It seems I have some system rebuilding to do first. I'm not up for tackling it tonight. I'll work on it in the morning and try to get you some more data.
Hi Scott, thanks for the help!
If you can apply the patch, we could see if you have the same behavior than Nate with his hardware: when setting a very low value (for him, it's in the range 1 to 5) to /sys/class/backlight/<hardware>/brightness his screen does not turn on at all. I would like to know if /sys/class/backlight/<hardware>/actual_brightness is then saying something different than /sys/class/backlight/<your hardware>/brightness.
On my computer the backlight goes on as soon as I put 1 to /sys/class/backlight/<hardware>/brightness, so I cannot reproduce this.
I hope I'm clear enough :)
Hope you don't mind me jumping in - I'm another one of Nate's protegees... here's some data for you. These values are before your patch. Let me know if you'd like me to apply your patch and redo the testing.
Great! That's taken care of the string and technical issues I spotted. Now that I play around with it, I notice that the explanatory text box on the bottom is getting pretty tall. I wonder if it might make sense to instead add a second column (i.e. a second GridLayout next to the original one) for these new lines. That way, compared to the status quo, it would grow horizontally instead of vertically. This might also impose a pleasing separation, since one column would be exclusively about the move/resize actions, so they wouldn't get lost in the middle.
What do you think?
The proper way to do this like so:i18n("Move selection rectangle %1 pixels", largeChange)
largeChange value plugged in for help text. Reformatted strings in normal case, not Title Case.
Very cool! Works nicely for me. I've got a few string change suggestions below: