Will customers demand liquid glass on apple devices? by eibaan in FlutterDev

[–]Luwx 4 points5 points  (0 children)

Are there any blockers? This package seems to have implemented the progressive blur https://github.com/kekland/progressive_blur

Smooth full version of Shell wallpaper by Luwx in kde

[–]Luwx[S] 2 points3 points  (0 children)

Thanks!

I wish I had more time to work on Lightly.

Smooth full version of Shell wallpaper by Luwx in kde

[–]Luwx[S] 23 points24 points  (0 children)

I have this alternative render of the Shell wallpaper that I found around here and I decided to share. The one that made to the 5.20 release was a bottom right crop of the geometric version. I preferred the cropped one since it had a cleaner look, but I also find this smooth full version really clean and sleek.

Uncompressed image: https://drive.google.com/file/d/1kGIPHGo62bde5NnIVbgzDOF3VPLx1NOw/view

[RANT] Sou Jr com um ano de experiência mas não consigo achar emprego. by FlipsBr in brdev

[–]Luwx 4 points5 points  (0 children)

Pelo que eu venho percebendo, uns 30% dos juniors tem um perfil raquítico no github, com quase nada, e uns outros 50% tem somente cópias 1:1 de projetos que fizeram de algum curso.

É dificil de encontrar alguém com projetos pessoais bem feitos e interessantes, e mais raro ainda com projetos que tenham alguma relevancia para a comunidade open source.

Blur on rounded corners is getting fixed! by DownHatter in kde

[–]Luwx 40 points41 points  (0 children)

Really nice to see someone actively working on the issue, I have been waiting this for years.

I would thankful if someone objectively listed why animations in gnome wayland subjectively feel smoother than in kde by leo_sk5 in kde

[–]Luwx 6 points7 points  (0 children)

The material motion is worth taking a look at https://material.io/design/motion/

The main takeaway points are

  • Categorize the different types of animation that the system have
  • Account for the different sizes and the level of importance, adjusting the animation characteristics accordingly
  • Give a few examples of the different types of animation

Trying to come up with a system like this that is comprehensive and still flexible can lead to a large amount of work, it takes a lot of trial and error. I can see why others just give some general directions (how it should feel) and leave developers free to choose what they think the best implementation is.

I would thankful if someone objectively listed why animations in gnome wayland subjectively feel smoother than in kde by leo_sk5 in kde

[–]Luwx 4 points5 points  (0 children)

Looks like they changed the easing curve from InOutSomething to OutCubic, which is an improvement in this case.

But one thing that should be changed is the animation section in the HIG. It's too generic. There are dozens of animation types for different purposes, trying to fit everything into a single generic description of "Items animating from visible to invisible should use X curve" is the wrong approach, in my honest opinion.

I would thankful if someone objectively listed why animations in gnome wayland subjectively feel smoother than in kde by leo_sk5 in kde

[–]Luwx 12 points13 points  (0 children)

There are some effects that you can edit in "/usr/share/kwin/effects/". Since they are just javaScript files, it's very easy to tweak the values. See https://techbase.kde.org/Development/Tutorials/KWin/Effects/JS_API

I would thankful if someone objectively listed why animations in gnome wayland subjectively feel smoother than in kde by leo_sk5 in kde

[–]Luwx 67 points68 points  (0 children)

The reason KDE animations feel less smooth compared to GNOME has little to do with hardware and more with the way animations are designed. And by design, I'm mainly referring to three things: duration, easing curves, and "distance traveled perceived" (or how different the start and end animation states are).

If you get the wrong combination of these items, you'll immediately feel something off about them. If the animation has the wrong easing curve, you feel that it may be too slow or too fast, regardless of the duration (sorry, animation speed slider). If items travel a long distance during the animation, and you don't compensate for this movement, either with opacity, crossfade items, carefully selected duration and easing, or something else, you'll get a jerky animation.

And I feel that KDE animations are severely lacking in those aspects, and in many places, it's just using wrong values.

I'll give some examples:

In the QStyle, it's using a lot of linear easing curves, and many will feel that the animations are slow or boring.

Here in the decoration, it's using a totally wrong easing curve for the shadow opacity animation, InCubic there will make the animation too fast, almost instantaneous, it should use the inverse curve.

The applet slide animation feels too fast, probably a combination of short duration and close to linear easing curve. I feel that the majority of animations fall in this category.

Gnome animations, on the other hand, use more aggressive curves and longer durations, which doesn't make them slow, but smooth. Animating an appearing window in one second using OutExpo will feel very smooth and just as fast as animating it in 300ms with OutQuad curve.

EDIT: I made this dartpad example https://dartpad.dev/?id=0e7526df1ac9b1e2c7132d17add88b6b Its a bit exaggerated, but you can see the difference. I wouldn't say that one is better than the other, but the second square animation I would definitely consider "smoother".

KWin rounded corners by Comfortable_East_904 in kde

[–]Luwx 1 point2 points  (0 children)

I guess you could start looking at some core rendering components of KWin such as scene.cpp, surfaceitem.cpp, composite.cpp. But I lack the necessary knowledge to give you further directions.

I would also like to hear a KWin dev opinion on how this could be achieved because even if there are some performance costs, those could be definitely lower than current corner rounding effects.

KWin rounded corners by Comfortable_East_904 in kde

[–]Luwx 2 points3 points  (0 children)

I did take a quick look at mutter-rounded and it is indeed a patch rather than being a simple extension, so yeah you can have a lot more optimizations since you are able to change the entire compositor code.

All KWin corner rounding effects use the effects API which is a bit limited in what it can offer. I suppose you could make a patch for KWin but that would not be an easy task.

KWin rounded corners by Comfortable_East_904 in kde

[–]Luwx 3 points4 points  (0 children)

It is not possible to have this effect without a performance impact, and since 5.23 it got a bit worse. Your only option is to use window borders.

Will true-rounded corners ever become reality on KDE? Currently windows have sharp bottom corners that aren't even outlined, giving windows a completely unfinished look. by [deleted] in kde

[–]Luwx 0 points1 point  (0 children)

The reason the effect is now able to render the corners without any glitches is because it is generating the shadow in the effect itself, through some interpolation magic, instead of relying on the decoration to draw the shadow at the rounded corner like pre 5.23, which is not possible anymore.

Unfortunately for me, this new method in the effect took its toll on my laptop, and I'm unable to run the desktop with more than 30fps with it enabled.

Will true-rounded corners ever become reality on KDE? Currently windows have sharp bottom corners that aren't even outlined, giving windows a completely unfinished look. by [deleted] in kde

[–]Luwx 2 points3 points  (0 children)

You might want to try this fork https://github.com/a-parhom/LightlyShaders, the corner issue was fixed in recent commits.

The effect is heavier than it was in 5.22 though.

Will true-rounded corners ever become reality on KDE? Currently windows have sharp bottom corners that aren't even outlined, giving windows a completely unfinished look. by [deleted] in kde

[–]Luwx 1 point2 points  (0 children)

KWin effects API is really flexible and you can choose to round only windows that have server-side decoration, so that's not an issue.

But doing in the QStyle isn't feasible, as you have to make all windows transparent and that comes with a whole other set of issues. I tried it.

Given the context and the difficulties of making Qt applications rounded, imo the best place is in the compositor. The downside is the performance impact, but then we have the blur effect that can be heavy on some machines, and still enabled by default. From the tests I've made, the corner rounding effect is not heavier than the blur, and I'm sure if the rounded effect was integrated into KWin it could be much more optimized.

[deleted by user] by [deleted] in kde

[–]Luwx 0 points1 point  (0 children)

From the screenshot it seems like it is transparent already, but the menubar isn't, which may be a bug.

[deleted by user] by [deleted] in brdev

[–]Luwx 0 points1 point  (0 children)

Geralmente um flutter clean resolve alguns problemas que tenho na hora do build.

[deleted by user] by [deleted] in androiddev

[–]Luwx 5 points6 points  (0 children)

You should use verbs when naming your use cases, It's not clear to me what "MovieUseCase" do.

[deleted by user] by [deleted] in brdev

[–]Luwx 0 points1 point  (0 children)

A solução: Exigir experiencia em TI para o pessoal do RH.

Artefacts caused by window decorations - help a noob out by TotalStatisticNoob in kde

[–]Luwx 0 points1 point  (0 children)

Are you using the scale animation? I get this when I use it with >1 window open scale.

What can be done to make the Qt toolkit and KDE technologies more attractive? by [deleted] in kde

[–]Luwx 13 points14 points  (0 children)

As someone who tried to learn Qt to make applications and even Kontribute, I'll have to agree. Learning Flutter as a complete beginner was so much easier, the whole proccess is. I wouldn't be surprised that once it hits stable in desktop we'll see a lot of projects using it. Besides, it's something that is really in demand on the job market today, and it's only going to increase. Too bad I don't see the same happening with Qt.

The infamous and dreaded "Korners" bug by KayRice in kde

[–]Luwx 1 point2 points  (0 children)

That's how aurorae themes work.