Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tray menu right angle corner overlaps when pushed #2173

Closed
AHeimberger opened this issue Jul 8, 2020 · 12 comments · Fixed by #2235
Closed

Tray menu right angle corner overlaps when pushed #2173

AHeimberger opened this issue Jul 8, 2020 · 12 comments · Fixed by #2235
Assignees
Labels
bug good first issue papercut small changes that make a difference
Milestone

Comments

@AHeimberger
Copy link

AHeimberger commented Jul 8, 2020

Hey guys, sorry but my eyes seem to be too good. The right button to open (Gallery, Data, Activity) overlaps the corner radius. Left button shows the expected behaviour, right button overlaps.

bitmap

@AHeimberger AHeimberger changed the title Tray menu right angle corner not masked Tray menu right angle corner overlaps Jul 8, 2020
@AHeimberger AHeimberger changed the title Tray menu right angle corner overlaps Tray menu right angle corner overlaps when pushed Jul 8, 2020
@er-vin er-vin added bug good first issue papercut small changes that make a difference labels Jul 9, 2020
@er-vin
Copy link
Member

er-vin commented Jul 9, 2020

Ah yes, good point, looks like there's a radius or a mask missing.

@AHeimberger
Copy link
Author

Screenshot (13)

Also Bottom List View Overlaps.

@DominiqueFuchs
Copy link
Contributor

DominiqueFuchs commented Jul 17, 2020

Indeed, search shows the simplifications introduced by be2e526 do not consider the case where the button (HeaderButton since that commit) is at the edge, e.g. having a rounded corner. Originally I implemented a (bulky but simple) custom background splitting that accommodates for that b/c Qt doesn't support rounding specific, single corners (still the case for the Account dropdown button on the left):

background:
Item {
id: leftHoverContainer
height: Style.trayWindowHeaderHeight
width: Style.currentAccountButtonWidth
Rectangle {
width: Style.currentAccountButtonWidth / 2
height: Style.trayWindowHeaderHeight / 2
color: "transparent"
clip: true
Rectangle {
width: Style.currentAccountButtonWidth
height: Style.trayWindowHeaderHeight
radius: Style.trayWindowRadius
color: "white"
opacity: 0.2
visible: accountBtnMouseArea.containsMouse
}
}
Rectangle {
width: Style.currentAccountButtonWidth / 2
height: Style.trayWindowHeaderHeight / 2
anchors.bottom: leftHoverContainer.bottom
color: "white"
opacity: 0.2
visible: accountBtnMouseArea.containsMouse
}
Rectangle {
width: Style.currentAccountButtonWidth / 2
height: Style.trayWindowHeaderHeight / 2
anchors.right: leftHoverContainer.right
color: "white"
opacity: 0.2
visible: accountBtnMouseArea.containsMouse
}
Rectangle {
width: Style.currentAccountButtonWidth / 2
height: Style.trayWindowHeaderHeight / 2
anchors.right: leftHoverContainer.right
anchors.bottom: leftHoverContainer.bottom
color: "white"
opacity: 0.2
visible: accountBtnMouseArea.containsMouse
}
}

Not sure rn what should be best solution to this without reverting the component outsourcing made by @nicolasfella (i.e. one could again apply the workaround above for the apps button on the right, but this would render the HeaderButton component rather useless b/c it is used by one single button and we do not even have more space for possible future buttons)

Maybe someone comes up with a more clever/concise idea for the corner overlay.

@er-vin er-vin added this to the 2.7 🌟 UI improvements milestone Jul 20, 2020
@camilasan camilasan self-assigned this Jul 20, 2020
@er-vin
Copy link
Member

er-vin commented Jul 22, 2020

Well the problem at the bottom of the window that @AHeimberger points out was there before commit be2e526...

I'm wondering if we shouldn't remove everything related to the rounded corners in the inner components and only have the rounded corners obtained by clipping or a mask on the root element (this one would still be rounded obviously).

@DominiqueFuchs
Copy link
Contributor

Well the problem at the bottom of the window that @AHeimberger points out was there before commit be2e526...

Yes I was only talking about the rounded corners here.

I'm wondering if we shouldn't remove everything related to the rounded corners in the inner components and only have the rounded corners obtained by clipping or a mask on the root element (this one would still be rounded obviously).

When you try this please note the current thin border of the window. This is merely visible in most cases but has it‘s reason for white (or whatever color the tray window background may have in the future) desktops.

@er-vin
Copy link
Member

er-vin commented Jul 22, 2020

When you try this please note the current thin border of the window.

Yeah, I know it, remember I tuned the color in f147e5a. ;-)

This is merely visible in most cases but has it‘s reason for white (or whatever color the tray window background may have in the future) desktops.

The correct approach would use the outter rounded rectangle for clipping or masking, this would keep the border.

@AHeimberger
Copy link
Author

Well, it is just a matter of taste, but I would be happy with corners. No radius. I guess you can not solve the radius with clipping. In my oppinion it is not a good first issue, it is a toth bitter issue.

@er-vin
Copy link
Member

er-vin commented Jul 23, 2020

Well, it is just a matter of taste, but I would be happy with corners. No radius.

In fact me too (I even think there's a trend to move away from rounded containers), but I'm respecting the decisions taken before I was around. ;-)

I guess you can not solve the radius with clipping.

Good point, clipping areas are indeed rectangular, stupid me.

In my oppinion it is not a good first issue, it is a toth bitter issue.

Not sure what you meant here. It's a bit technical due to the mask but it won't involving a lot of code either. :-)

@DominiqueFuchs
Copy link
Contributor

DominiqueFuchs commented Jul 23, 2020

I put the gfi label b/c technically it is just plain Qt/QML design. No complex correlations with the rest of the code base or smth., but may be debatable for sure. Right now I think the main task here is simply to pinpoint what one really wants. (Edit: Ah it wasn't even me but I agree with the gfi)

Well, it is just a matter of taste, but I would be happy with corners. No radius.

In fact me too (I even think there's a trend to move away from rounded corners)

Well why not just ping with design lead @jancborchardt : Solve design issue or throw away rounded corners completely?

Edit 2:

I even think there's a trend to move away from rounded containers)

As always this seems highly biased based on the platform/distro you're on. macOS/iOS is rounder than ever (even more with upcoming major releases), Windows is edgier then ever (no pun intended). Just like I won't burn our whole tray code b/c some major DE kicks out tray icons I won't rely on current trends for NCs decisions but just ask: What is consistent with the overall NC design and fits our collective design feeling?

@er-vin
Copy link
Member

er-vin commented Jul 23, 2020

I put the gfi label b/c technically it is just plain Qt/QML design. No complex correlations with the rest of the code base or smth., but may be debatable for sure. Right now I think the main task here is simply to pinpoint what one really wants. (Edit: Ah it wasn't even me but I agree with the gfi)

I beat you to it apparently. ;-)

Well, it is just a matter of taste, but I would be happy with corners. No radius.

In fact me too (I even think there's a trend to move away from rounded corners)

Well why not just ping with design lead @jancborchardt : Solve design issue or throw away rounded corners completely?

Well, I'm all for pushing back on designers ideas when it's technically difficult or leads to violating where responsibilities should be (like in the packaging discussion this week)... but in that case there's really no good technical reason to say we can't have rounded corners. That's why I think we can have them (whatever opinion I might hold otherwise, I'm not acting designer here).

Edit 2:

I even think there's a trend to move away from rounded containers)

As always this seems highly biased based on the platform/distro you're on. macOS/iOS is rounder than ever (even more with upcoming major releases),

Ah that's what tripped me up then, I thought upcoming major releases where slowly backing away from that. I'm not following what they do closely enough.

Windows is edgier then ever (no pun intended). Just like I won't burn our whole tray code b/c some major DE kicks out tray icons I won't rely on current trends for NCs decisions but just ask: What is consistent with the overall NC design and fits our collective design feeling?

OTOH: the question of not having a systray anymore would hold if all major DEs would get rid of it. In my view it's a question of maintenance effort: having systray code say for instance "just for KDE" would be wasteful. We're far from that situation of course.

Similarly here all the environments we run in support undecorated non rectangular windows, so the decision is completely with us.

And just to make things crystal clear if they're not yet: I wasn't advocating to get rid of the rounded corners at all. I was more expressing the surprise that it's still a thing apparently. :-)

@jancborchardt
Copy link
Member

jancborchardt commented Jul 27, 2020

To make it short and simple: Let’s stay with the rounding, if possible. It fits our general design, as well as that of macOS, and Windows moves towards rounding as well.

An interesting but not really scientific blog post on the matter: http://uiandus.squarespace.com/blog/2009/7/27/realizations-of-rounded-rectangles.html

Well, I'm all for pushing back on designers ideas when it's technically difficult or leads to violating where responsibilities should be (like in the packaging discussion this week)

Sorry if that was an exhausting discussion: I don’t consider that either "developer" or "designer" responsibilities, but a matter of overall quality of product and how it should ideally be. How and when it is implemented is separate, and I don’t put any deadlines on that or so – it’s just important to agree on how it should ideally be.

@er-vin
Copy link
Member

er-vin commented Jul 27, 2020

To make it short and simple: Let’s stay with the rounding, if possible. It fits our general design, as well as that of macOS, and Windows moves towards rounding as well.

I'm not sure how you infer they're moving back to rounding from that article. At least I don't see any indication of that, for the windows themselves it'd be more about the defaults the Windows window manager use.

An interesting but not really scientific blog post on the matter: http://uiandus.squarespace.com/blog/2009/7/27/realizations-of-rounded-rectangles.html

Thanks for that! Interesting stuff.

Well, I'm all for pushing back on designers ideas when it's technically difficult or leads to violating where responsibilities should be (like in the packaging discussion this week)

Sorry if that was an exhausting discussion:

No worries, it wasn't. :-)

I don’t consider that either "developer" or "designer" responsibilities,

This is not what I meant though. I meant "piece of code" or subsystems responsibilities. IOW having the right thing done in the right layer.

If I feel like someone pushes toward some kind of layer violations I'll push back. Said person being a designer or a developer doesn't matter much in that regard, it's just that IME designers are less aware of where the boundaries are (and that's fine).

So what I've been trying to say for the past few days in too many words: I don't push back designer demands on how I find them "pleasing to my eyes" or not but only on technical feasibility. I was trying to stress that I never meant to not have rounded corners. I personally don't like them much but my broken sense of aesthetics doesn't matter, they're doable without crazy stupid code so I'm fine with them.

I guess I'll shut up now, this ticket had enough off-topic comments as it is and I think I'm making less and less sense to everyone around anyway. ;-)

github-actions bot pushed a commit that referenced this issue Jul 28, 2020
- Fix for #2173.
- Removed the workaround for the left round corner which was also
fixed with the OpacityMask.

Signed-off-by: Camila <hello@camila.codes>
er-vin pushed a commit that referenced this issue Jul 28, 2020
- Fix for #2173.
- Removed the workaround for the left round corner which was also
fixed with the OpacityMask.

Signed-off-by: Camila <hello@camila.codes>
PraMiD pushed a commit to PraMiD/nextcloud-desktop that referenced this issue Dec 30, 2020
- Fix for nextcloud#2173.
- Removed the workaround for the left round corner which was also
fixed with the OpacityMask.

Signed-off-by: Camila <hello@camila.codes>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug good first issue papercut small changes that make a difference
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants