Did the following steps:
- Moved KNS Widgets to separate library
- Moved Widgets source code to a subdirectory
- Moved KNS3::Widgets to a different namespace
- Moved KNS3::Entry{,Private} to KNSCore::
Did the following steps:
I am here.
removed 2nd hunk
In D17217#412961, @davidedmundson wrote:It would just be nice not to have to think about this stuff
There is an OOM killer. That OOM killer is faster than a human, has access to more info about processes and has higher privileges than userspace.
Happens to be a regression after 2f3bcfa
In D26618#596380, @mqualmann wrote:My suggestion is to activate the detailed view only in the expanded Progress Manager view and to leave the percentage view in the status bar.
Depending on the widget style, the progress text is also written next to the progress bar, which means that the progress bar is very short
for a large number of elements.
ping
In D26618#593806, @cgilles wrote:
Can't tell, never used such functionality, considering as "not fixed"
Make it apply to master branch
In D26618#592948, @cgilles wrote:Thanks for your patch.
Did you make this patch with the code from git/master ? As i can see in your screenshots, 6.4.0 is used...
In D21872#481213, @ngraham wrote:In D21872#481173, @McPain wrote:In D21872#481154, @davidedmundson wrote:It might be better to do it in
XkbKeyboardBackend.cpp:184 in SDDM which is where the model comes from.
I don't see any matching files in sddm
https://github.com/sddm/sddm/blob/develop/src/greeter/XcbKeyboardBackend.cpp
In D21872#481154, @davidedmundson wrote:It might be better to do it in
XkbKeyboardBackend.cpp:184 in SDDM which is where the model comes from.
In D15247#472461, @ngraham wrote:IMO what's seen in your screenshot is not useful behavior. If the full text fits in the regular UI, there's no need to show a tooltip; it's just redundant.
In D21497#472546, @ngraham wrote:
style: for
foreach -> for
use const
In D15247#472255, @ngraham wrote:
updated paths
In D15247#364814, @mart wrote:In D15247#341864, @McPain wrote:Additionally, tooltips are glitching if you move the mouse pointer too fast between items{F6324386}
there was a recent fix in the kwin morphingpopup effect that should have fixed it, i would say go for it
In D15247#364814, @mart wrote:In D15247#341864, @McPain wrote:Additionally, tooltips are glitching if you move the mouse pointer too fast between items{F6324386}
there was a recent fix in the kwin morphingpopup effect that should have fixed it, i would say go for it
validate WPA-PSK and WEP keys
In D20788#458047, @jgrulich wrote:You said it's broken so I would preffer not landing a broken patch.
Tomorrow I'll land this patch, but I submitted another one
In D20788#457772, @jgrulich wrote:I think resetting the model might not be necessary, when addAvailableConnection() is called, it then updates item with a new available connection, which invalidates the filter anyway or at least it should.
The patch "as-is" is broken.
I had reports about resetting model right after clicking "Connect" button - model resets and there are no connection attempts.
In D18979#441799, @hein wrote:Thanks! Do you need help landing this?
In D18979#428230, @hein wrote:Can you explain more what this is trying to achieve / what it solves with an example?
Seems like I can't use distinct screen mapping for each activity yet
Somebody review this for me, please, I'm too far away from actually testing it
In D17217#378768, @davidedmundson wrote:Thanks. Any examples in KDE? I can't implement this from scratch right now.
There is not, it would requires writing new C code.
It's something I can help with.
In D17689#391265, @hein wrote:Here's my take: https://phabricator.kde.org/D18182
In D17689#379900, @hein wrote:Cool, thanks for the update. I'm a bit flooded before the Christmas holidays, but I'll try to make sense of this in early 2019.
Fixed condition mistake
Anybody?
Default limit: 25% -> 10%
Fix typos
Auto detect swap, removed "includeSwap" setting
KSysGuard: show kill button (implemented in D17366)
In D17217#367842, @davidedmundson wrote:There's also an alternative that I'd like to suggest:
According to https://www.kernel.org/doc/Documentation/cgroup-v1/memory.txt there's a system called "memory pressure" you can watch for events on a specific FD with various levels of out-of-memory-ness. A lot cheaper than polling, far more reliable, and following the system's OOM configuration. Getting that in at a frameworks level so it can be hooked up to notifications in this case, but also garbage collections in UI code could be pretty cool.
In D17217#367545, @abetts wrote:Is having this feature an optional feature? Can it be turned off?
In D17217#367525, @ngraham wrote:Thanks for all the work!
...But is this actually useful or actionable for the majority of users? Free space is a fairly understandable concept: if you run out, you need to delete things to make more room before you can add more stuff. It won't fix itself unless the user does something. But memory pressure requires a much greater technical understanding and isn't subject to the same conditions. When the system is using up 75% of the available memory, there isn't necessarily a problem at all. Apps will move to swap automatically. Even if there is a problem, it's only temporary, and it may fix itself if the user does nothing as the system shuffles things around.
I worry that this notifier would just be yet another annoying pop-up that people dismiss because they don't understand it.
Any ideas how to fix the bugs I mentioned above, please?
Additionally, tooltips are glitching if you move the mouse pointer too fast between items{F6324386}
Found out that sometimes displayed text appears to be elided (not always reproducible)
Resolution: 1920x1080, dpi: 142
(height * 2) + spacer.height -> (height - spacer.height) / 2
In D14064#322643, @davidedmundson wrote:Urgh. Just read the code.
We don't reset when we type a new letter. To do so would have a jumpy ui. Instead we reset when we get results back.
That leaves a problem when you search for "firefo" ( with 1 result) to "firefodfhhxtffrdh" with zero results. Which is what this timer "solves"
Clearly its not a good solution to the problem. Changing it to 5 seconds isn't helping.
In D14895#320987, @ngraham wrote:+1 for the concept. No opinion about the notification, but I think it's fine. Removing myself as a reviewer since I don't feel qualified to offer a code review. But sounds like you've got a shipit! You need someone to land it for you, right?
In D15240#320542, @ngraham wrote:I would favor automatically creating a default wallet with the user's current password using a "good enough" cipher that we can hopefully all agree on. This would probably require changes to user-manager, or whatever it is that receives the string used for a new account's password. At the moment when a new user account is created, it would not only create the new user account, but it would also create a wallet using the same password.
In D15240#320542, @ngraham wrote:Stuff that doesn't work with KWallet should be fixed. But the point would be moot if we create a default wallet in a more user-friendly manner...
In D15247#320523, @ngraham wrote:Thanks, the patch applies now.
Can you verify that this works for you? When I apply the patch (and reboot for good measure), I still don't see tooltips for items whose names are elided in KRunner.
In D15247#319839, @ngraham wrote:The patch does not apply because of an extraneous milou in the path for your diff:
Consider setting up arc; it makes the patch submission process so much simpler and less error-prone. :)
https://community.kde.org/Infrastructure/Phabricator#Using_Arcanist_to_post_patches
Just in case, I don't have commit access