_sharvey_ on IRC.
_sharvey_ on IRC.
</me looks up Activities since he doesn't use them>
I can take a look at it. I didn't do anything regarding its visual appearance, just made it appear and disappear at will - by hiding or showing the row it was placed on.
@ngraham : Now that I understand what went wrong here, I really do think this particular diff be abandoned. It mistakenly contains unrelated material from a different diff (D12311) - which we probably shouldn't re-submit. I will get a fresh master, which will have D12311 already incorporated and make @bruns 's small change. That should resolve the issue without any drama.
This was copied from D12311: Align lock icon with bold message text; reduce overall size of dialog, which languished unapproved and un-landed for a long time. Indeed, I should have made this a separate patch, but I'd only been a contributor for about 2-3 months at this time. It duplicates a lot of what's in D12311, which is now finally closed.
I believe what you're perceiving in the XML file is in fact the result of a lot of changes made to the layout. Unneeded columns, rows, and spacers were deleted, causing "gaps" in the old XML file. In places, I added options like column spans and justifications. The XML file changed a lot.
Anyone have any suggestions?
Anything you can trim away? IIRC, Kubuntu ships with a full boat of System and Utility apps, which a lot of users might not need. I don't know how much space you can shave away with small apps like that - just thinking out loud.
I'd vote for Krita over all the others. It's a fantastic piece of software, on par with Photoshop and arguably outdoes GIMP.
I vote for KPatience and KMahjong. They're two very good-looking games, proving that Linux games aren't pixellated messes from the 1980s. Plus, they're sort-of "classics", included in a lot of distros and even competing OSes like iOS and Windows. It would give Kubuntu a well-rounded feeling as a complete and user-friendly distro.
Update "Mouse Click Emulation" to "Tap to Click"
Thanks for the investigation. I've been hoping someone else would lend a pair of eyes to this problem for ages.
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.