Stop clogging the thread with your uninformed security theater nonsense. Come back with a threat model of what you actually want to do, because this is a joke.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Dec 15 2020
Aug 28 2019
This is a total joke. Oh just put it on a "not easily editable website". And you have the audacity to say I'm uninformed 😂 There is no threat model. This is a joke.
@sitter Uninformed babbling? Insulting people you don't even know? Uninformed about what? The security theater you want to set up without a threat model? Good one.
@kossebau You say stay focused and then repeat my criticism of this being security theater, except needlessly wordy. That's... interesting. I'm very focused on what we can do to improve the security situation, I think pointing out others that actively work against it (some sysadmins to say the least) is a part of that focus. I think you ignoring my criticism and acting like you came up with it on your own is part of this social capital problem I'm talking about.
What a civil discussion from the sysadmins with no mention of how they are swamped and don't have any resources. It's almost like you're actually taken seriously if you have social capital, regardless of how well-founded what is being proposed is.
Aug 12 2019
In T10891#194991, @onvitaik wrote:In T10891#194989, @lavender wrote:The first highlighted pushbutton (where the cursor is) is less visible in your version than noah's due to the contrast. And the radiobuttons has weird artifacts but maybe that's a compression thing.
Visible as in readable, or discernible? I agree with the former as it has lower text/BG contrast, but not with the latter as the contrast between the button and the area around it went up. Plasma Blue (#3daee9), as it is, might be just too bright for a dark theme. A darker/paler blue (#428AAE) has a better contrast rating with both the background and the text (3.41 and 3.74 respectively, using https://jxnblk.github.io/colorable/demos/text). As for the artifacts, they are due to me quite literally selecting a color range and replacing it with another, so there was some collateral damage...
Aug 10 2019
In T10891#194749, @onvitaik wrote:
Aug 5 2019
How can KDE guarantee that malicious keys aren't being served?
Aug 4 2019
This is ridiculous, you say coordination is not enough but lydia says that's what's needed and we have enough people coding? which way is it? Own up to your mistakes instead of acting like nothing happened.
Here is a tool that may be useful with all the different components: https://github.com/cncf/landscapeapp
Aug 2 2019
KDE Quantum
Could colors be moved up together with the other 'theme-ish' items in preparation for T11052 (there is already a kcm module that is rough around the edges but works)?
In D22653#505659, @ndavis wrote:I try not to be too aggressive with optimization when it comes to diffs from other people because the process of making an icon is currently quite tedious and the optimizations can be pretty small after the metadata is removed.
Aug 1 2019
Functionally it looks good to me, there are a few improvements/optimizations that can be made for example 16 and 22 have unnecessary attributes such as:
fill="currentColor" style="fill:currentColor;
Jul 30 2019
I noticed that only the 22px icons use the viewbox, is this intentional?
Jul 29 2019
Besides night mode and color correction this can also help test how something looks for different types of colorblindness, it can make it easy to make sure everything looks nice in those cases.
@mglb maybe the konsole code could be adapted to kcm-colorful? It has a lot of the features we want
Jul 28 2019
In T10891#193270, @ndavis wrote:In T10891#193267, @lavender wrote:In T10891#193248, @ndavis wrote:That might be because the colors are dark and the shadows are just more dark (black). I don't think there's anything that can be done about that and you should probably stick to light themes.
What if the shadow/blur used a color that contrasts the background?
well, in order to have good contrast, the shadow would have to be a glow instead of a shadow. I think most users want to have a shadow and anyone who wants to change the shadow color can already do that.
In T10891#193248, @ndavis wrote:
@johan.boule you are talking about two things if I understand you correctly: inefficiency and inconsistency/bugs. If there isn't an issue open for the konsole issue, you should open one or join the discussion because everyone agrees that manpages should be readable. As for efficiency: where do you feel that Breeze is lacking compared to "classic" themes? Maybe there is a way of improving that too. Glad that you decided to join the discussion.
Yeah I think you are right, I've thought about it and I don't want to lead this goal. Only someone with the social capital of the big names can lead goals, everyone else can be effectively ignored with zero accountability.
Jul 27 2019
The example of school project happened in the other task that's why I mention it. I addressed all the claims made but someone else said they made a school project about tor and the sysadmin immediately disregarded what I had to say and the ticket was removed from sysadmin grouo, that is to say it's not in the wishlist even. It means that they are done talking about it (there was no discussion at all). I don't think this represents the KDE community but what is the next step at that point?
@ngraham I see what you are saying but de facto I've been doing all the things you can expect someone coordinating a goal to do - make a coherent proposal, make the issues, track the progress, keep my eye on other projects and chime in when there are issues that intersect with the goal. The difference is I don't have the social capital of some of the 'big names' who make the decisions, so even though I might know more about a subject it might still get ignored.
At this point I think I wrote most of the actual proposal (the original one) besides the fluff, if we are talking about actionable items instead of marketing speak. When I started working on it it was just marketing speak with no way to do anything with it.
Jul 22 2019
It seems like these kind of malware are already being seen in the wild on linux desktops: EvilGnome
Jul 21 2019
Jul 19 2019
In T4437#191463, @ngraham wrote:For this, a better UX might be provided by taking inspiration from mobile, where the user is generally asked once to allow the current app some kind of blanket permission (access the camera, access contacts, etc). If we did that, then the user would authorize Spectacle to be able to take screenshots once, and never have to think about it again.
This is exactly kind of bad faith structural obstacles I'm talking about. Yes you removed both sysadmins and websites so it just sits there ignored. It's not even on the wishlist as is customary. But why play word games?
There was no discussion, it was made without even understanding the possibilities or how much bandwidth it would take. One of reasons given was that subdomains wouldn't work which just isn't true. It was a top down decision. I'm not too concerned with being called passive aggressive by someone I'm criticising. I'm not talking to you but to the wider KDE community. You passive aggressively removed the sysadmin task to block any further discussion and you're trying to stifle discussion again.
The KDE sysadmins recently closed the onion service task no after it stood open for 1 year with no comments. Does KDE not care about users in places such as Kazakhstan? https://bugzilla.mozilla.org/show_bug.cgi?id=1567114
I thought privacy was a goal so I put time in turning the vague privacy goal into something actionable only to see nothing happen and worse yet active pushback against improving privacy.
Jul 16 2019
Jun 26 2019
In T10783#189353, @ngraham wrote:The problem with two-finger tap/click on a touchscreen is that it's not predictable which part of the screen will get clicked. This isn't a problem with a touchpad because there's an always-visible cursor to show you what will get clicked, but on a touchscreen this isn't the case. I think we need to consider touchscreens as separate input devices with their own quirks. People at this point are quite familiar with how touchscreens work and what gestures they generally recognize (e.g. tap, single-finger scroll, and pinch), probably more so than laptop touchpads.
What is the argument against it?
In T10783#190236, @ngraham wrote:On most touch devices I'm familiar with, it either does nothing or is the start of a pinch gesture. This seems sensible enough to me.
The screen area covered by two fingers is too big to use it for anything that may interact with any given control, many of which are smaller than the area of the fingers. Imagine if your cursor on a desktop PC was like a 150×100 rectangle lol
In T10783#189584, @sbergeron wrote:A touchpad is:
- smaller than a touchscreen
- not visually mapped to the content (no hover semantics, no guide markers contents to help orient a touch relative to viewport)
What this ends up causing is from the first point, we can't possibly map an absolute (x, y) on the touchpad to an absolute (x, y) on a viewport because the accuracy is too low (imagine having to tap the right part of a touchpad that corresponds to where a link is on the screen),
Jun 25 2019
Isn't this the same but less fleshed out as the current privacy goal?
Jun 24 2019
This blog post seems relevant: https://www.inkandswitch.com/end-user-programming.html
Jun 23 2019
In T11075#189834, @ervin wrote:That would be a nice follow-up to the privacy goal.
Jun 20 2019
Why not both? Removing consistency for no reason doesn't make any sense to me.
Jun 19 2019
In T11074#189319, @chempfling wrote:In T11074#189317, @jrioux wrote:Also, should KDE review it's default key mapping ? I end up having to configure switch desktop up/down/left/right to crtl+alt+arrow. Are there many other default mapping that could be added ? also never found what was : alt+shift+backtab ...
I like using meta+arrow to title a window, but more commands should be added for true keyboard navigation. like move to desktop/screen, fullscreen, put focus on screen X...
Perhaps review defaults shortcuts, do pools to find what ppl change and try to define a complete set of shortcut commands that would please most ? Or provide different default key-profile ?
IMO a good default key mapping is a huge part of Accessibility. I think those should be intuitive and easy to remember.
agree here. many parts are not reachable using shortcuts at all.
try to access the notification area or networks using shortcuts..it is what i m going to tell here... we talk about enterprise desktop. but simple tasks are not possible using keyboard only at all... until this happens..we don't need even to think about kerberos or special auth algorithms.
we strugle at the basics here.
by the way... also if wikipedia is an other opinion. accessibility is not only a part for blind or impaired people. i m not blind and want to use my desktop like an pro using my keyboard....
Jun 18 2019
I think that is very valuable and i like your response, it's well articulated and I understand what the main focus is.
Jun 17 2019
No worries.
@neofytosk Can you give some explanation?
In T10783#189119, @russh wrote:In T10783#188134, @lavender wrote:On trackpads we already have two point touch. If we want to introduce a different/special case for touch screens we should also discuss whether it should be a special case or if for example long press should be right click on trackpads as well.
Trackpads are a different use-case, and users may spend time with their fingers resting on them and will not expect a right-click to be generated. I wouldn't expect the same conventions on a trackpad and a touchscreen.
The problem is that the proposal doesn't tell us how we should prioritise differently. Because people have different experiences (broadly speaking) they will think different things should be prioritised so with setting the goals we are already trying to have a discussion on what we want to prioritise. So just saying "prioritise the things that are good" is too vague because good means different things to different people.
Jun 14 2019
An option is to add per project watchlists so we have more of an overview of the changes on a per project basis which can be reviewed periodically.
In T11080#188569, @davidedmundson wrote:Organizations
Happy to find something else. For me organisation implies non-profit. Maybe "deployment"?
Jun 13 2019
In T11067#188577, @crozbo wrote:@lavender Sorry if I write stuff on complicated way, my english is bad. To summerize, we can chose i3 as a clear goal, but we dont need to make 100% of i3 in plasma. We can implement some different tiling solutions/features to be better with plasma.
@crozbo I just think saying i3 support is a better way to summarize what you want to do, it's a nice clear goal to work towards that would satisfy the functionality that most people want. I'm not hung up on the implementation details.
In T11067#188560, @strobach wrote:This does not apply exclusively to the KWin tiling functionality. There could be a list of "approved" and supported 3rd-party extensions which would be actively advertised to the user.
I think there is merit in having a robust tiling experience out of the box no matter how it is implemented, whether baked into kwin or through kwin scripts. Having support in Plasma for it would also mean then exposing it to the user in a discoverable way and documenting it (some users might have never heard of tiling but would like it), I think there is something to be said about it being an accessibility feature as well.
What would this look like in a language that isn't LTR? Would it be better to maybe have it on the right side in that case?
Jun 12 2019
My suggestions for this proposal would be to focus it around Organizations which is far more general instead of Big Enterprise and change the "how would we know we succeeded" to something like "we see more distributions switch to Plasma as default" or something like that instead of naming specific ones. We have no control over whether a certain distribution picks Plasma because those choices are not just based on popularity or how good our software is - for example Red Hat is heavily involved in GNOME and I don't see them switching to Plasma even if a lot of people on a forum asked for it.
@skadinna really nice work! it's clear what needs to be done now :)
Jun 11 2019
In D21608#475980, @mgallien wrote:As far as I know (and a confirmation by reading Qt source), pressed and clicked should probably be different. I remember having read (not remembering the reference at the moment) that "clicked" is the action of pressing and un pressing the button.
On trackpads we already have two point touch. If we want to introduce a different/special case for touch screens we should also discuss whether it should be a special case or if for example long press should be right click on trackpads as well.
In T11074#188109, @chempfling wrote:@lavender thanks for helping out with the text :). i m not the "best" english speaker XD.
Jun 10 2019
An issue I see is that on the second view there is no indication of what ISO image you selected, so if you selected the wrong file you have no idea of knowing.
Thanks for the explanation @The-Feren-OS-Dev, this is tangentially related you might be interested in T11052 as well
Adding VDG because we will need a design for this
The best implementation of this I've seen is fw-daemon
Should we have input methods as a goal or maybe something a bit more broad such as Accessibility?
Hey, thanks for taking the time to write this! I have to say though I think this is way too specific to be a Goal. If you search around here and the bugtracker you will find multiple discussions about this and what the current roadblocks are.
I created T11052 to discuss the idea of an Accent Color system and related components for Plasma.
Tangentially related; I created T11052 to discuss the idea of an Accent Color system which would kind of fill the void of the additional color schemes we don't ship anymore with Breeze ;)
Jun 9 2019
Radically improve the UX for switching between common panel UIs (e.g. Windows XP style task var vs Dock). This probably needs its own Phab task.
Jun 7 2019
Really good effort, here are two relevant links: https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO
https://github.com/Whonix/uwt/blob/master/README.md
May 30 2019
In D21489#471864, @ngraham wrote:Instead of just using it when it's there, it would probably make more sense to add a CMake variable that allows the distro to choose which code path to use. See for example https://cgit.kde.org/kdenetwork-filesharing.git/tree/CMakeLists.txt#n50
May 29 2019
In D21408#470219, @broulik wrote:In D21408#470122, @ngraham wrote:When there are 2 or digits, maybe the circle can expand to become pill-shaped
The circle comes from Plasma theme, cannot transform it.
@Zren Since you have experience with https://github.com/Zren/plasma-applet-alphablackcontrol I'm interested in your thoughts about how it could be upstreamed in some form. Eventually we can maybe get to an experience like we were talking about:
May 27 2019
We could use this one: https://github.com/eosrei/twemoji-color-font
May 26 2019
In T10891#186175, @mglb wrote:If you mean automatically adjusting rows with checkboxes and radio buttons, this could be nice. However, I see some possible technical problems (sizeHint() races as the size depends on other elements, etc).
May 25 2019
In T10891#186101, @mglb wrote:More overall ideas:
- Widgets heights should be somehow unified. Here's Konsole's profile editor without custom code which makes heights equal:
+1 From me it's definitely easier on the eyes
May 24 2019
In D21378#469640, @filipf wrote:In D21378#469611, @ndavis wrote:In D21378#469607, @filipf wrote:So I have a light widget color scheme, but I want to be using a dark Plasma theme. My color scheme is a bit funky and when I use Breeze Dark it doesn't respect my colors. So this is a good solution, +1 for the idea.
I gave it a quick spin with Breeze Dark however and it's just not picking up some color schemes. It remains stuck on the colors of some previous scheme that worked. This seems to be random and may be a bug originating elsewhere so I'm hitting accept.
After changing the system colorscheme, did you try restarting plasmashell or switching to a different desktop theme and switching back? I'll admit, it's a bit janky, but it should work if you do that. It definitely seems like a bug that originates from elsewhere.
Restarting plasmashell yes, switching to a different theme nope. But I did now and that seems to be working.
In D21378#469517, @mart wrote:the idea is kinda nice and with some schemes it will work just perfect...
however i think it risks a lot of having loss in contrast on certain color schems with your patch try for instance breezedark and the honeycomb system theme, the current task highlight would probably almost disappear
Tested and it looks good to me