hpereiradacosta (Hugo Pereira Da Costa)
User

Projects

User does not belong to any projects.

Today

  • Clear sailing ahead.

Tomorrow

  • Clear sailing ahead.

Thursday

  • Clear sailing ahead.

User Details

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

Recent Activity

Yesterday

hpereiradacosta added a comment to T11124: Unify highlight effect style.

Can I change the selection background color and use the selection color for the background of highlights? Then the regular highlight color could be used mainly for line highlights and outlines.

Mon, Jul 15, 1:49 PM · VDG
hpereiradacosta added a comment to T11124: Unify highlight effect style.

Thanks for the color overview. I'll avoid changing the highlighted text color in the colorscheme.

Personal opinion follows.

In my personal opinion, the current breeze widget style highlight model is fine as it is, internally consistent, and consistent with the breeze visual goal. It is simple (in particular in lists and menus), it minimizes the use of frames, and is also consistent with text selection (something on which you have no handle). I also note that it is quite trendy, when comparing e.g. to highlight model of many web-based applications (slack, github, etc.), or to the other widget styles shipped by Qt.
To ensure consistency with plasma, rather than modifying the complex beast that is the widget style highlight model, I would have changed the plasma model instead. Simpler, both implementation-wise and visually wise.
My two cents.

That's a fair point, but the current style does have rather poor contrast with light text. While dark text has significantly better contrast, I don't like the way it looks against Plasma Blue. The highlight color could be changed, which would be much easier than changing the highlight style, but that would affect everything that currently uses the highlight color, including icons.

Mon, Jul 15, 12:52 PM · VDG
hpereiradacosta added a comment to T11124: Unify highlight effect style.

Personal opinion follows.

Mon, Jul 15, 12:09 PM · VDG
hpereiradacosta added a comment to T11124: Unify highlight effect style.

Few words about colors (sorry if you know all about it already)

Mon, Jul 15, 12:01 PM · VDG

Sun, Jul 14

hpereiradacosta added a comment to T11124: Unify highlight effect style.
  • For the record: toolbar buttons (or rather QToolButtons) can have focus too, when they are used outside of toolbars (and there are examples of such everywhere, for instance when you have an "open" button next to a text entry for selecting a file.

your enumeration did not mention

  • checkboxes and radiobuttons who also have hove/focus + the various selected states.
  • tabbar entries (hover, focus, selected)
  • toolboxes
Sun, Jul 14, 1:39 PM · VDG

Fri, Jul 5

hpereiradacosta committed R31:d6b2a3a36a1c: Remove unneeded 1 pixel margin around side panels (authored by hpereiradacosta).
Remove unneeded 1 pixel margin around side panels
Fri, Jul 5, 5:59 PM
hpereiradacosta closed D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.
Fri, Jul 5, 5:59 PM · Plasma
hpereiradacosta updated the diff for D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.

Simplified the patch: special case in ::pixelMetrics is in fact not needed, because it is overridden in ::frameContentsRect anyway

Fri, Jul 5, 3:50 PM · Plasma
hpereiradacosta added a comment to D22083: introduce concept of header and footer for kpageview.
In D22083#491299, @mart wrote:

code issues are fixed.
Now for removing the further margin around the whole window:
should that be done here or in breeze?
if done here, it may make it look bad on all other widget styles?

Fri, Jul 5, 3:39 PM · Frameworks
hpereiradacosta updated the summary of D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.
Fri, Jul 5, 3:35 PM · Plasma
hpereiradacosta updated the diff for D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.

New patch, adding proper margin to avoid overlap with viewport

Fri, Jul 5, 3:34 PM · Plasma
hpereiradacosta added a comment to D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.
In D22138#491285, @mart wrote:

Indeed. This is a problem. As soon as treeviews are animated Qt makes a pixmap copy of the treeview viewport. This does not include the blue line on the side, which is painted in the frame, below the (transparent) viewport. Will investigate further.

would still adding a pixel on the right work around the issue?

Fri, Jul 5, 3:21 PM · Plasma
hpereiradacosta added a comment to D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.

Indeed. This is a problem. As soon as treeviews are animated Qt makes a pixmap copy of the treeview viewport. This does not include the blue line on the side, which is painted in the frame, below the (transparent) viewport. Will investigate further.

Fri, Jul 5, 7:27 AM · Plasma

Thu, Jul 4

hpereiradacosta added a comment to D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.

Very nice! In conjunction with Marco's patch (D22083), I now see the following for Dolphin's settings window:

I notice that your screenshot depicts the sidebar with no top, bottom, or left margins, which is the indended appearance. Is that the result of some other required patch I haven't applied yet, or did I do something wrong?

Thu, Jul 4, 6:46 PM · Plasma
hpereiradacosta added a comment to D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.

Since this apparently doesn't need review,

This is not what I said. What I said is "thanks, it looks fantastic" is not a proper review and hence irrelevant. What I expect for a proper review is

  • does the patch achieve the behavior matching its title, and is it the intended behavior
  • does the code look legit (compiles, properly formatted, etc.)
  • is there a better way to achieve the same
  • does the patch break other things, and how can it be improved so that it doesn't

If you can provide such a review I'd be happy to modify the patch accordingly.

Thu, Jul 4, 6:44 PM · Plasma

Mon, Jul 1

hpereiradacosta added a comment to D22083: introduce concept of header and footer for kpageview.

Hi Marco,
see https://phabricator.kde.org/D22138
(I also included the white background in there, because it turned out a bit tricky).

Mon, Jul 1, 11:02 AM · Frameworks

Fri, Jun 28

hpereiradacosta added a comment to D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.

Thanks @hpereiradacosta! This looks fantastic. Adding @ndavis and @filipf for comment since they've been working on this project too from other angles.

Fri, Jun 28, 2:37 PM · Plasma
hpereiradacosta committed R31:62ac0c1820de: - fixed "missing override" warnings - removed useless "virtual" specifications… (authored by hpereiradacosta).
- fixed "missing override" warnings - removed useless "virtual" specifications…
Fri, Jun 28, 12:49 PM
hpereiradacosta requested review of D22138: Remove 1 pixel margin around side panels, use QPalette::Base for background.
Fri, Jun 28, 12:29 PM · Plasma
hpereiradacosta added a comment to T11124: Unify highlight effect style.
Fri, Jun 28, 11:24 AM · VDG
hpereiradacosta added a comment to D22083: introduce concept of header and footer for kpageview.

ather simple and attached. Feel free to add this or something similar to any other modification you plan to do.

Thank you very much Hugo.. that pixel was driving me mad ;)
Do you want to push it yourself or I just include it in the breeze modifications I'll do for the sidebar style?

Fri, Jun 28, 9:25 AM · Frameworks

Thu, Jun 27

hpereiradacosta added a comment to D22083: introduce concept of header and footer for kpageview.

On the breeze side, asside from the layout margins/spacing issues, there is at least one hard-coded pixel in the frame rendering that must be removed. In fact I have this committed in my local breeze version already. The corresponding patch is rather simple and attached. Feel free to add this or something similar to any other modification you plan to do.

Thu, Jun 27, 2:49 PM · Frameworks

Jun 7 2019

hpereiradacosta added a comment to D13481: Recommend window border size "None".
Jun 7 2019, 6:01 AM · Plasma

Jun 3 2019

hpereiradacosta committed R113:72a70ceacc04: Disable extended resize borders for maximized windows CCBUG: 407989 (authored by hpereiradacosta).
Disable extended resize borders for maximized windows CCBUG: 407989
Jun 3 2019, 10:39 AM
hpereiradacosta committed R31:c95b7652b7af: Disable extended resize borders for maximized windows CCBUG: 407989 (authored by hpereiradacosta).
Disable extended resize borders for maximized windows CCBUG: 407989
Jun 3 2019, 10:26 AM

May 14 2019

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

So, how does that work when user select a specific size, and then change decoration ? Is his choice erased by the default of the new decoration ? Or is his choice maintained (in which case he never gets a chance to actually see the "preferred" width of the new decoration ? And then, if erased by the new default, does that mean that if I switch from decoration A (with custom setting) to decoration B, and then back to A, my custom setting is lost ?

Best,

Hugo

Default is to use the recommended sizes of decorations (falls back to Normal if decoration does not recommend one). User might opt in to specifiy a border size manually instead. This choice is being remembered even if he changes to another decoration. But in this configuration screen he can also opt out to automatic border size again.

May 14 2019, 5:12 AM · KWin

May 13 2019

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

So, how does that work when user select a specific size, and then change decoration ? Is his choice erased by the default of the new decoration ? Or is his choice maintained (in which case he never gets a chance to actually see the "preferred" width of the new decoration ? And then, if erased by the new default, does that mean that if I switch from decoration A (with custom setting) to decoration B, and then back to A, my custom setting is lost ?

May 13 2019, 6:47 PM · KWin

Apr 3 2019

hpereiradacosta added a comment to D19890: Reduce the indicator arrow size for press-and-hold menus in QToolButtons.

Did anyone check how this patch look with other icons than those in the screenshot ?
E.g. the preview icon in dolphin, or list sorting or search icons ? Does the new arrow overlap with the said icons ?

Apr 3 2019, 3:44 PM · Plasma

Sep 17 2018

hpereiradacosta accepted D15568: Fix finding QtQuick.

Thanks for tracking this down !

Sep 17 2018, 8:05 AM · Plasma

Aug 27 2018

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.

Aug 27 2018, 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