hpereiradacosta (Hugo Pereira Da Costa)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Tuesday

  • Clear sailing ahead.

User Details

User Since
Mar 30 2016, 2:05 PM (129 w, 4 d)
Availability
Available

Recent Activity

Mon, Sep 17

hpereiradacosta accepted D15568: Fix finding QtQuick.

Thanks for tracking this down !

Mon, Sep 17, 8:05 AM · Plasma

Mon, Aug 27

hpereiradacosta added a comment to D14389: Invert shade button by same logic as keep-above button.

IMHO: you should either

  • keep the same icon, use the invert-color to set active state (meaning: remove the "unshade" icon
  • keep to different icons, and not invert-color (in which case the active state is driven by the drawn icon)

but not both.
Right now when I shade a window, I see an "unshade" icon, which appears as toggled. What am I suppose to expect when I click on it ? Will it "uncheck" the "unshade state" (meaning go to "shade") ? But then my window is shaded ... confusion.

Mon, Aug 27, 8:18 PM · Plasma, Breeze

Aug 21 2018

hpereiradacosta removed a watcher for KDE Human Interface Guidelines: hpereiradacosta.
Aug 21 2018, 7:26 PM

Jul 11 2018

hpereiradacosta edited reviewers for D13881: oxygen-demo : add KMessage preview, added: VDG, plasma-devel; removed: hpereiradacosta.
Jul 11 2018, 9:00 AM · Plasma
hpereiradacosta added a comment to D13881: oxygen-demo : add KMessage preview.

A couple of snapshot (with my current KMessageWidget facelift; styles and themes switched "on-the-fly"):

Oxygen with the Oxygen theme:

Breeze with Breeze-Dark:

QtCurve with my Mac OS X Graphite theme:

Jul 11 2018, 8:59 AM · Plasma

Jul 4 2018

hpereiradacosta added a comment to D13881: oxygen-demo : add KMessage preview.

1/ As far as I know, the widget style has no way to style these widgets. Correct ?

Yes. I would have preferred if Breeze applied the new flat style to the widget instead of changing the look in the class itself.

Jul 4 2018, 1:32 PM · Plasma
hpereiradacosta added a comment to D13881: oxygen-demo : add KMessage preview.

1/ As far as I know, the widget style has no way to style these widgets. Correct ? As such I wonder if oxygen-demo is the right place for showing this. Might better have a showcase in kwidgetsaddon.
(but in fact we also discussed that ultimately oxygen-demo should go "elsewhere", like e.g. frameworks-integration/kstyle).

Jul 4 2018, 1:29 PM · Plasma

Jun 17 2018

hpereiradacosta added a comment to R31:6d2b04fab801: Fixed detection of horizontal progressbar by re-introducing check on….
Jun 17 2018, 11:14 AM
hpereiradacosta committed R31:6d2b04fab801: Fixed detection of horizontal progressbar by re-introducing check on… (authored by hpereiradacosta).
Fixed detection of horizontal progressbar by re-introducing check on…
Jun 17 2018, 10:30 AM

Jun 12 2018

hpereiradacosta added a comment to D11198: [libbreezecommon] Add box shadow helper.
In D11198#277321, @zzag wrote:
In D11198#238841, @zzag wrote:


on the left hand side: box blur, on the right hand size: fft blur

Also, if you think box blur looks okay, I will switch box shadow helper to box blur. (that way, we don't need fftw)

Jun 12 2018, 9:53 AM · Plasma

Jun 6 2018

hpereiradacosta added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

QWidget apps will look pixel for pixel identical.

I don't understand that. You still can not resize from these extra two pixels. Can you ?

I meant they'd visually be the same

As for resize handles, that's a valid question.

With the current code as-is:

  • Hit area would be actually bigger!
  • They would be shifted to not include kwin's current non-visual border
Jun 6 2018, 5:34 AM · KWin

Jun 5 2018

hpereiradacosta added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration.

It will.

That thread is an absolute mess, but underneath it's a really simple problem that's been very poorly explained and evidently poorly understood.

  • Kirigami looks fine with a border. It is not broken outside of the Breeze decoration on Plasma.
  • Breeze is using a clever hack to make it look like there is no visual border even when one is set. This behaviour relies on a false assumption and therefore results in things looking broken.

    That is the part we need to finish so it's done properly. I'm fully on board with this patch that does it on a per theme basis.
Jun 5 2018, 8:13 PM · KWin
hpereiradacosta added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

If you set breeze style to no size borders and you add to breeze

BreezeStyle::polish() { if (widget->isWindow() { widget->setContentMargins(2,0,2,0);}

QWidget apps will look pixel for pixel identical.

Jun 5 2018, 7:56 PM · KWin
hpereiradacosta added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

Nevertheless I want to add that I still think that switching to no border is IMHO the wrong solution to the problem the VDG wants to address. No border won't help for Kirigami apps running outside of Plasma and won't help with a change of the decoration. In addition I see an accessibility issue. With no side borders it's difficult to recognize which window will be resized for adjacent windows.

This may not be entirely true if the window selected keeps a shadow underneath. The selected window will overshadow the window adjacent to it. Therefore, you will see that one is selected and which one is not. The one that is selected will get the focus, so will the ability to use the border handles to resize. If you want to resize the other window, in this example, you click on it to give it focus and the borders activate for the user to resize.

Jun 5 2018, 7:32 PM · KWin

Jun 4 2018

hpereiradacosta resigned from D13336: Check for option->styleObject before accessing it.
Jun 4 2018, 3:54 PM · Plasma

Jun 3 2018

hpereiradacosta abandoned D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.
Jun 3 2018, 6:19 PM · Plasma
hpereiradacosta added a comment to D13277: Turn off the extended resize handle/black triangle when there are no borders.

Long time ago, you could not resize windows from outside the window area. So when switching to no border, the only way you could resize a window was: the titlebar, keyboard shortcuts, and this handle. (which provided a reasonably large hit area at the bottom of the windw.
That's why it was on by default.
Now, no there is no reason not to turn it off by default, except that it will piss people relying on it (and now they will have to look for the option for turning it on again).
On the other hand I have seen no good reason, not to keep it on by default either. (might have missed them though). except from "this is ugly" (a word which I hear more and more these days and really come to dislike).
On the section of devising a general rule by the example, I for one use this handle systematically to resize my borderless konsoles. got used to it, will turn it on systematically if the default is change.

Jun 3 2018, 3:21 PM · Plasma
hpereiradacosta added a comment to T8707: Window borders.

I would veto anything with solution #1.

No objection.

Jun 3 2018, 9:52 AM · VDG
hpereiradacosta added a comment to D13284: [decorations] Let KDecoration plugins recommend a border size per default.

Hi Roman, Martin
First, I think the approach is sound (and moves the discussion about default window borders from kwin to breeze ;))
Only (minor) drawback that I can see is that users now have two actions to change the window border size instead of one: uncheck the use recommanded size, then select in the combobox. No big deal.

Jun 3 2018, 8:56 AM · KWin
hpereiradacosta added a comment to T8707: Window borders.

The drag resize area for "No Borders" is identical to the drag resize area for "Normal" borders. It becomes bigger if you make the borders larger, but it doesn't get any smaller. This is why I keep saying that there is no functional change from moving from "Normal" to "No Borders". It is a purely visual change.

Jun 3 2018, 8:16 AM · VDG

Jun 2 2018

hpereiradacosta added a comment to T8707: Window borders.

The fact that kirigami apps look ugly with borders is a problem. It is not fixed by making the default "no borders".
As long as we (kde) offer the option of having non zero borders (disregarding the default) then our own apps *must* look good with these options enabled. period.
We cannot say we offer an option, but if you turn it on, then all our apps will look ugly.

There's no accounting for taste, but...

Some of the color schemes in the color KCM make apps look hideous. We let people use 24pt Comic Sans as their system font if they want. We ship, by default, the incredibly ugly Plastik and "MS Windows 9x" window decoration and widget styles.

I could go on, but I think you get the point. :) We already have a thousand options where, "if you turn it on, then all our apps will look ugly". We're not GNOME; if you want to make your system look ugly, you can.

Jun 2 2018, 10:08 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

On the subject of 3rd-party apps, I think it does us no favors to ignore about them. It hurts our platform as a whole when Firefox, LibreOffice, GIMP, Blender, Inkscape, VLC, Telegram, and other flagship non-KDE Linux apps don't look right because of constraints or design decisions we've made in KDE-land. We of course have no control over the layout of the widgets in the windows, but we do have a measure of control over their visual styling, and total control over the window decorations. It's not about them breaking our design decisions but rather the opposite: since they've all been developed around the expectation of not having a visible window border (because no other desktop platform has window borders like we do), we break them when we add one.

Jun 2 2018, 8:23 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

Thanks for coming back, Hugo!

There are two primary arguments:

  • Many apps (Kirigami, 3rd-party) look ugly with borders.
  • The borders hinder KDE's ability to design our own apps to have content areas which touch the window edge, which has a very nice clean modern look that we want to move towards, and that IMHO is actually a fulfillment of Breeze's minimalistic design vision.

Disregarding the discussion on third party apps.
The fact that kirigami apps look ugly with borders is a problem. It is not fixed by making the default "no borders".
As long as we (kde) offer the option of having non zero borders (disregarding the default) then our own apps *must* look good with these options enabled. period.
We cannot say we offer an option, but if you turn it on, then all our apps will look ugly.
Îf I as a user see that there is this option available, turn it on, and then see that all application becomes broken (or ugly, quoting your own words), I get a pretty bad impression on the software I am using.
So either we fix the app, or we remove the option (non-zero border) entirely.
In either case, changing the default value has nothing to do with this.
It is just hiding a problem under the carpet.

Jun 2 2018, 8:06 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

On the argument: kirigami apps look ugly when there are window border.
I don't see how changing the default window border fixes this. It just hides the issue.
The issue remains, and will be there as long as we offer the option of having window borders, disregarding what the defaults are.
To fix this issue, one must fix kirigami apps so that they can accomodate having window borders.
Once this is done (fixing kirigami), then should we revisit what the default should be, among a set of equally good looking options.

Jun 2 2018, 12:28 PM · VDG
hpereiradacosta added a comment to D13276: Display "No Borders" by default.
Jun 2 2018, 8:53 AM · KWin
hpereiradacosta added a comment to D13276: Display "No Borders" by default.

As indicated in the discussion on the task I'm against this change.

Jun 2 2018, 8:51 AM · KWin

May 25 2018

hpereiradacosta added a comment to D13026: Make menu-bearing toolbar buttons show their menus with normal click rather than click-and-hold.

Hello,
I would appreciate that you rephrase the description for this patch (and others where the same comment appear): the dissapearing arrow with breeze is not a *bug* in breeze, but a (conscious) design choice, that is discussed in D13064 and in the bug attached. D13064 is not fixing that bug, it is a proposal to revert that design choice.

May 25 2018, 8:42 PM · Frameworks, Kate

May 24 2018

hpereiradacosta added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

One last word about the necessity of this arrow. To me the arrow is mandatory as soon as it refers to an action that is different from the one of the icon. (either long press, or extra menu beside the icon main action). Still to me, opening a menu when pressing the icon is a single action, so you should not need two controls. This is as much a single action as when pressing an icon opens a dialog, (like in save as), or a confirmation dialog (like "do you really want to discard changes to the document), and for which we have no visual indication either that it will be different from say, sending the email.

May 24 2018, 7:59 AM · Plasma
hpereiradacosta added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

Got the chance to test this out. Functionally, it works great, and resolves the issue!

Visually, I can understand you guys's hesitation about bringing the arrows back, because they do seem to lack that je-ne-sais-quoi, somehow. I wonder if the arrow might look nicer if it was vertically centered, instead of appearing towards the bottom of the button. The downward-pointing arrow is centered in other Breeze contexts (comboboxes and drop-down menu buttons, for example).

Perhaps we could experiment with different arrow appearances so that they feel more natural? I feel like these arrows can work great in other non-Breeze contexts. Thunderbird, for example:

May 24 2018, 7:55 AM · Plasma

May 23 2018

hpereiradacosta added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

'Fraid I gotta disagree with you on this one, @abetts. I think it's important to signal that these buttons will bring up a menu because without that, there is no way to distinguish it from an ordinary action button. It's the same reason why comboboxes have arrows rather than looking like a pushbutton.

But there's a deeper reason. With the downward-pointing arrow, users are signaled that the button doesn't initiate an action (which may be unknown, non-undoable, possibly dangerous, etc), but rather displays a menu of textual, easy-to-understand options. In essence, the arrow says, "this > is safe, go ahead and click me even if you don't know what I might do". Without the arrow, fearful users might avoid clicking on the menu button because they don't know what it will do and nothing hints at them that the button brings up a benign menu rather than immediately executing a > If we must use the arrow, can there be a visual merge that is more consistent? Like this:

Notice how the arrow butts into the icon keeping the overall rectangular shape the same. When we do icon + arrow visually we are making the button longer and seems disconnected.

May 23 2018, 8:59 PM · Plasma
hpereiradacosta added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

I really don't understand the fear factor and unknown action argument. There are tooltips, possibly text alongside (or below icon), and the icon itself. Also, if you have to fear what an application might do to the point that you will only click on menus and not menu actions, I doubt you will achieve much. Should we also add a symbol on icons to say that they are non-dangerous ? (even if not a menu ?)

May 23 2018, 8:48 PM · Plasma
hpereiradacosta added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

I am not particularly excited by the change, because on how it breaks the spacing between buttons in a toolbar.
I am also not completely convinced that it is important to convey the information that a menu will open when you press on the button (because you usually learn that 'instantly' when pressing on it the first time), but since I have no other strong argument against re-adding this arrow, so be it.
Any suggestion on improving the rendering is welcome, and no, one cannot move the arrow closer to the icon without actually overlapping with the icon. (breeze icons have a 2 pixels margins around their content, but this is not the case for all icon themes)

May 23 2018, 3:37 PM · Plasma
hpereiradacosta added reviewers for D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup: ngraham, abetts.
May 23 2018, 3:31 PM · Plasma
hpereiradacosta added a comment to D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

How it looks for the sorting button in Open dialog:

May 23 2018, 3:30 PM · Plasma
hpereiradacosta updated the diff for D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.

Removed unrelated change

May 23 2018, 3:25 PM · Plasma
hpereiradacosta requested review of D13064: reimplemented drop-down menu arrow in toolbuttons in case of instant inline popup.
May 23 2018, 3:18 PM · Plasma

May 18 2018

hpereiradacosta committed R31:32d8b02880a2: Draw mouse-over rect over the full toolbutton even if it has a menu (authored by hpereiradacosta).
Draw mouse-over rect over the full toolbutton even if it has a menu
May 18 2018, 7:45 AM

May 17 2018

hpereiradacosta committed R113:e33ea4dba89d: changed demo button icon (authored by hpereiradacosta).
changed demo button icon
May 17 2018, 9:34 AM

May 16 2018

hpereiradacosta added a comment to T8707: Window borders.

thanks for the screenshots.
For vlc this is due to broken installation. Mine does not look like that

It's not a broken installation, it's the Flatpak version. Today's apps may look like that.

I want to further comment on this point because it is important:
I am sorry: this _is_ a broken installation. If flatpak gives you that then flatpak must be fixed. Vlc folks (and Qt folks) have done some effort for vlc to integrate nicely in kde (not perfect, but better than the screenshot). If a technology to distribute the application breaks this effort the technology is broken. It must be changed or fixed. In no case should the broken technology be used as an argument for doing changes upstream (in our case in KDE style).

May 16 2018, 3:28 AM · VDG

May 15 2018

hpereiradacosta added a comment to T8707: Window borders.

My sense is that you don't actually want the bottom border, you just want the rounded bottom corners, and are willing to put up with a bottom border to get them, right?

May 15 2018, 9:03 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

thanks for the screenshots.
For vlc this is due to broken installation. Mine does not look like that
for spectacle there really should not be any difference unless the default palettes are mixed up. I don't have any here.
For the open/save dialogs: you will deal extra space against having a round corner just next to a square corner (which IMO looks quite bad)
For blender, this is because you use application's palette and not system palette. (and don't make decoration palette match application palette although at some point at least, kwin was allowing to do so)

May 15 2018, 8:30 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

Any chance you could post screenshots of the applications listed above with both no-side borders and no-borders, so that people can form their own oppinion ?

May 15 2018, 7:34 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

I think No Side Borders is not going to work because it doesn't actually solve the visual problems we want to solve, and it introduces some new ones (e.g. widgets will have unequal padding between the side and bottom window edges). I don't think it would be a real improvement.

May 15 2018, 7:31 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.
May 15 2018, 5:48 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

The issue with No Side Borders is that it doesn't actually fix all the problems outlined in the task description above. For example we still wouldn't have the ability to draw vertical lines that touch the bottom of the window, and apps like Discover that draw non-gray content at the bottom of the window still wouldn't look good.

My preference is also for the corners to be rounded even when there are no side or bottom borders, but I omitted this in the interests of avoiding what I expected to be a long, bruising argument over it. We can still have that conversation if we anticipate that it will go somewhere and if people can be open-minded about the change.

May 15 2018, 5:48 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

(note that having the ability to have antialiased rounded corners in the decoration was a big thing, back in the days. Something mandatory to make your desktop look modern, at that time)

May 15 2018, 5:20 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

To me at least, giving up on the round corner at the bottom is a loss, and is inconsistent with the rest of breeze, for which there is no sharp corners (as already noted above). For this reason, I would prefer "no side borders" to no borders. (that what I would switch to immediately if one would change the default to 'no borders')

May 15 2018, 5:18 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

Just to illustrate the existing "contrast" pixel. (look for instance in the top left corner of the left most window)

May 15 2018, 3:06 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

I am more in favor of 1px borders for applications that are web-based and just need a container window. They can look quite awkward without borders.

If no borders is also an option, I would have to look at a few examples before deciding.

May 15 2018, 2:56 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.
This change will actually require very little of most of our apps, and will reward them with improved aesthetics.
May 15 2018, 2:51 PM · VDG
hpereiradacosta added a comment to T8707: Window borders.

When compositing is OFF, no window border means: you can't resize the window on the corresponding sides.

That's odd: Turning off compositing with +Alt+F12, I still get the regular resize handles.

May 15 2018, 11:12 AM · VDG
hpereiradacosta added a comment to T8707: Window borders.

From what I understand, window border is here to allow easy resizing of the window. When compositing is ON, (and you can have window shadows), window resizing can be performed from "outside" the window, so the borders are not mandatory per se (though they might help people with poor pointing). When compositing is OFF, no window border means: you can't resize the window on the corresponding sides.

May 15 2018, 6:40 AM · VDG

May 14 2018

hpereiradacosta added a comment to D12804: Fix window frame rounding when scaling is used.

IIRC, decoration renderer sets device pixel ratio, so in theory, you should not multiply frame radius by dpr.

For some reason my comment went missing, but as zzag said, with high DPI here the only things we should ever change are pixmap sizes and QPixmap::setDevicePixelRatio not changing the (logical) size of what's actually being painted.

May 14 2018, 2:08 PM · Plasma

May 13 2018

hpereiradacosta added a comment to D12835: Draw borders around side panels by default.

I am not saying that the current design is the best one. However it was designed as an improvement to the framed one. Reverting to the framed version is basically discarding this work. I would rather see some work done on improving upon what has been done rather than discarding it.

May 13 2018, 9:17 AM · Plasma
hpereiradacosta added a reviewer for D12835: Draw borders around side panels by default: hpereiradacosta.
May 13 2018, 9:16 AM · Plasma
hpereiradacosta added a comment to D12835: Draw borders around side panels by default.

Note that there is no bug report, to my knowledge, complaining about this. (neither usability wise nor design wise).

May 13 2018, 9:15 AM · Plasma
hpereiradacosta added a comment to D12835: Draw borders around side panels by default.

Maybe it is just me who has been around for too long ...

May 13 2018, 9:01 AM · Plasma
hpereiradacosta added a comment to D12835: Draw borders around side panels by default.

This is really interesting how things go back and forth if you wait long enough ...
Removing this frame (by default) was a _big_ thing at the time breeze was designed, and there was countless discussion on how to do it.
Wait five years, and the same discussion comes again, full reverse, with using the same arguments, reverse, in the sense that what was used to say "its good" before, has now become "bad" and vice versa.
To me, at least, who has attended both debates, the whole point seems a bit pointless. (and demotivating).

May 13 2018, 9:00 AM · Plasma

May 10 2018

hpereiradacosta updated subscribers of D12804: Fix window frame rounding when scaling is used.

could you add @davidedmundson as a reviewer ? I think he knows a lot about how pixel scaling is/should be handled in kwin and plasma.
(definitly more than myself).

May 10 2018, 1:24 PM · Plasma
hpereiradacosta added a comment to D12804: Fix window frame rounding when scaling is used.

Also: how does it work with multiple monitors ? (I see you get the info from ::primaryScreen, not for the screen the window is actually on ?

May 10 2018, 1:19 PM · Plasma
hpereiradacosta added a comment to D12804: Fix window frame rounding when scaling is used.

mmm. Ok. It works. Now, why is it not handled upstream (by kwin or Qt), as it is in the widget style ?
(see how the QStyle rounding, for e.g. the inner frame of your list) is rounded properly when changing the scale factor.
And then, should it not be fixed there, that is, upstream, so that it applies to all decoration styles, rather than in every single decoration ?
I am ready to accept this patch, but am afraid it is a bit of a hack, and that it does not scale. (meaning: does not fix other decorations, such as oxygen, and will have to be copied if one implements other decoration components, such as e.g. rounded square buttons)
I'd prefer to have this handled upstream ...

May 10 2018, 1:18 PM · Plasma

Apr 17 2018

hpereiradacosta accepted D12263: [kstyle] Don't suppress deprecation warnings.

Hopping I did not miss any dependent revisions.
Thanks for cleaning this up .

Apr 17 2018, 9:56 AM · Plasma
hpereiradacosta accepted D12261: [kstyle] Drop QStyleOptionFrameV3 in Qt 5 style plugin.

Thanks !

Apr 17 2018, 9:55 AM · Plasma
hpereiradacosta accepted D12256: [kstyle] Drop QStyleOptionProgressBarV2 in Qt 5 style plugin.

thanks !

Apr 17 2018, 9:55 AM · Plasma
hpereiradacosta accepted D12257: [kstyle] Drop QStyleOptionTabV3 in Qt 5 style plugin.

Thanks !

Apr 17 2018, 9:53 AM · Plasma
hpereiradacosta accepted D12258: [kstyle] Drop QStyleOptionTabWidgetFrameV2 in Qt 5 style plugin.

thanks !

Apr 17 2018, 9:52 AM · Plasma
hpereiradacosta accepted D12259: [kstyle] Drop QStyleOptionViewItemV4 in Qt 5 style plugin.

Thanks !

Apr 17 2018, 9:51 AM · Plasma
hpereiradacosta accepted D12260: [kstyle] Drop QStyleOptionFrameV2 in Qt 5 style plugin.
Apr 17 2018, 9:51 AM · Plasma
hpereiradacosta accepted D12262: [kstyle] Drop QStyleOptionDockWidgetV2 in Qt 5 style plugin.

Thanks !

Apr 17 2018, 9:50 AM · Plasma

Apr 10 2018

hpereiradacosta accepted D11533: [kstyle] create shadow tiles more explicitly.

Thanks !

Apr 10 2018, 12:36 PM · Plasma
hpereiradacosta added a comment to D11533: [kstyle] create shadow tiles more explicitly.
In D11533#243511, @zzag wrote:

Well, after thinking for a while, I think shadowTiles should be called in loadConfig. It doesn't make much sense to create something in reset method.

Apr 10 2018, 8:02 AM · Plasma

Apr 9 2018

hpereiradacosta added a comment to D11533: [kstyle] create shadow tiles more explicitly.

Hi Vlad,

Apr 9 2018, 4:36 PM · Plasma

Mar 22 2018

hpereiradacosta added a comment to D11175: [kstyle] Refine shadows.

I have pushed a fix to the "current" shadows already. so you would need to rebase this patch to master. (I did it locally, this will create some minor conflicts).
I also have a local patch for fixing the MDI shadows on top of this patch, if you are interested.

MDI shadows have another problem? Is it because of this patch?

Mar 22 2018, 3:46 PM · Plasma
hpereiradacosta accepted D11175: [kstyle] Refine shadows.

Ship it, thanks !

Mar 22 2018, 3:36 PM · Plasma
hpereiradacosta added a comment to D11175: [kstyle] Refine shadows.
In D11175#231610, @zzag wrote:

Fix MDI child window shadows.

Mar 22 2018, 2:41 PM · Plasma
hpereiradacosta added a comment to D11069: [kdecoration] Refine shadows.

First, I am now running this set of patch routinely and think these new shadows are gorgeous on a dayly usage. (I think the default is too large to my taste, but using a 70% shadow strenght and medium size, I'm quite happy with the result). So no regret with accepting it.
Second, concerning code review:
I now see that you kept the door opened for horizontal offsets in your shadowParams definition and in the code implementation. I think this is quite superfluous, and could be dropped. Not sure that the current shadow model works for non centered shadows anyway.
This would result in changing .offset frop QPoint to int, and modifying the rendering code accordingly. IMHO there is no point being too generic here.

Mar 22 2018, 2:39 PM · Plasma
hpereiradacosta committed R31:7f18aa39ed26: - Moved shadowSize from anonymous namespace to static member function… (authored by hpereiradacosta).
- Moved shadowSize from anonymous namespace to static member function…
Mar 22 2018, 2:17 PM
hpereiradacosta committed R31:f5ad0557c4d4: - Moved shadowSize from anonymous namespace to static member function… (authored by hpereiradacosta).
- Moved shadowSize from anonymous namespace to static member function…
Mar 22 2018, 2:17 PM

Mar 20 2018

hpereiradacosta added a comment to D11198: [libbreezecommon] Add box shadow helper.

I have updated the diff so the "Accepted" should have gone away because I could introduce a bug, etc. Most likely it's a bug, I don't know ... Or Phabricator has AI so it could recognize what changes you wanted and what changes the new diff introduced.

No no that's not how it works.
I deliberately accepted the revision, despite having still some comments about what should be implemented, because I trusted you that you would implement this and only this.
Basically when a revision is accepted, disregarding how many new diffs are uploaded to it, untill someone changes the status back to "request changes".
So ... Fill free to push

Mar 20 2018, 1:56 PM · Plasma
hpereiradacosta added a comment to D11198: [libbreezecommon] Add box shadow helper.
In D11198#229870, @zzag wrote:

@hpereiradacosta could you please accept this diff again? (I updated the diff)

Mar 20 2018, 12:58 PM · Plasma
hpereiradacosta accepted D11175: [kstyle] Refine shadows.

ship it.
Thanks !

Mar 20 2018, 9:11 AM · Plasma
hpereiradacosta accepted D11069: [kdecoration] Refine shadows.

Ship it. Thanks !

Mar 20 2018, 9:10 AM · Plasma
hpereiradacosta accepted D11198: [libbreezecommon] Add box shadow helper.

Fix it (std::erf), then ship it !
I have had no time to work on an alternative QGradient blur, and wont in the near future. In the meanwhile lets use this code (that you have spent quite some time on already).
There is still time to revisit it in the future.
Thanks !

Mar 20 2018, 9:06 AM · Plasma

Mar 18 2018

hpereiradacosta added inline comments to D11198: [libbreezecommon] Add box shadow helper.
Mar 18 2018, 8:20 PM · Plasma

Mar 9 2018

hpereiradacosta added a comment to D11175: [kstyle] Refine shadows.
In D11175#222124, @zzag wrote:

I am confused. Where is the shadow rending code ?

BoxShadowHelper::boxShadow() does pretty much all rendering.

How is it shared between style and deco ?

Only box shadow rendering is shared. It's not obvious to me what I can share beside that. Params? Then shadow paint function should receive qpainter and the params. What about QMargins? They will be calculated twice and it also would require copying logic between kstyle, kdecoration, and libbreezecommon. The same applies to the top-left corner of the shadow inner rect and size of it. Also, kdecoration renders outline while kstyle not.

Mar 9 2018, 9:12 PM · Plasma
hpereiradacosta added inline comments to D11175: [kstyle] Refine shadows.
Mar 9 2018, 8:58 PM · Plasma
hpereiradacosta added inline comments to D11175: [kstyle] Refine shadows.
Mar 9 2018, 3:52 PM · Plasma
hpereiradacosta added a comment to D11175: [kstyle] Refine shadows.

I am confused. Where is the shadow rending code ? How is it shared between style and deco ?
In general, the sharing should be a separate patch, that could be applied even with the current shadows, before modifying how shadows are drawn ...
That would make a two steps patch: first share shadow code (with existing shadow) between kstyle and decoration, then modify shadow code.

Mar 9 2018, 3:49 PM · Plasma

Mar 8 2018

hpereiradacosta added a comment to D11069: [kdecoration] Refine shadows.

Some questions:

  • Do we really need different shadow sizes for menus, etc? Can we use single shadow size in kstyle?
Mar 8 2018, 3:45 PM · Plasma

Mar 6 2018

hpereiradacosta added a comment to D11069: [kdecoration] Refine shadows.

Hello,

  • I agree with Nathan that the bottom part is likely too hard.
  • I think the same shadows should be used for windows and menus
  • Also, thanks for posting the pictures. Is there any chance you could also post new vs old shadows side by side for the different sizes ? I have the feeling that for a given shadow size the new shadows appear larger ...

Tanks in advance !

Mar 6 2018, 1:40 PM · Plasma

Mar 5 2018

hpereiradacosta added a comment to D11069: [kdecoration] Refine shadows.

Hello,
Thanks for the patch.

  • As we discussed already in telegram, I am not convinced you absolutely need fast fourier transform nor blur, and could probably handled thing with "simple" QGradients.

If you do not have time to try implement such a solution, I can give it a shot myself whenever there is time.

  • I can also help with moving the loading and destroying of the shadow to the pluggin loading/unloading rather than to first and last window opening. (this could also go in with the current shadows in fact, and would rather be a separate patch).
  • Also, these shadows look nice but are rather strong. To me they represent a shift of paradigm with respect to the original (subtle) breeze ideas. But that is not me to decide. Still: could you also post screenshots with the smaller sizes ? And then we can discuss what the default size should be.
  • finally, I really don't think we need too separate setting for the two shadow strength. These are just implementation details. IMHO. And will make the code very hard to maintain. (how do you test that all combinations of settings look good ?)

Others opinion welcome, of course.

Mar 5 2018, 8:37 PM · Plasma
hpereiradacosta added a reviewer for D11069: [kdecoration] Refine shadows: hpereiradacosta.
Mar 5 2018, 8:32 PM · Plasma

Mar 3 2018

hpereiradacosta added a comment to D10830: Disable SplitterProxy by default since it's broken.

Hmmmmmmm

I just realized this is weird, so the splitter in the kate sidebar is exactly 1 pixel wide so as you mentioned it can be a bit hard to grab (specially if using a touchpad) but the splitters in KMail and Konversation are several pixels wide (i'd say even 4 or 5).

Do you know why this may be?

Mar 3 2018, 6:25 PM · Plasma
hpereiradacosta accepted D10830: Disable SplitterProxy by default since it's broken.

ok, ship it, then.
In case we get complains, we'll increase the splitter size a posteriori.

Mar 3 2018, 4:18 PM · Plasma

Feb 26 2018

hpereiradacosta added a comment to D10830: Disable SplitterProxy by default since it's broken.

yeah so ... Qt Broke it. Was not broken in past version (not with the version I have) (5.9.4)
Note that what is broken is the rendering (basically Qt having issues with transparent widgets), not the functionality. (the ability to resize splitter in a region that is larger than the actual splitter width).

Feb 26 2018, 3:03 PM · Plasma

Feb 18 2018

hpereiradacosta added a watcher for KDE Human Interface Guidelines: hpereiradacosta.
Feb 18 2018, 8:12 PM

Feb 17 2018

hpereiradacosta committed R31:a4c90497c647: Fixed kde4 compilation. Fixed warning about blurhelper initialization. (authored by hpereiradacosta).
Fixed kde4 compilation. Fixed warning about blurhelper initialization.
Feb 17 2018, 8:45 AM
hpereiradacosta accepted D10584: fix double spacing bug.

Ship it !
Thanks for this patch, and sorry for the mess on the Blur patch (should have used arc).

Feb 17 2018, 8:36 AM · Plasma

Feb 16 2018

hpereiradacosta committed R31:336cf7b63a6a: Added option to set transparency and blur behind menu frames such as right… (authored by hpereiradacosta).
Added option to set transparency and blur behind menu frames such as right…
Feb 16 2018, 4:28 PM
hpereiradacosta closed D10170: Added optional transparency/blur to menu frames.
Feb 16 2018, 4:28 PM · Breeze, Plasma