Thanks! You can close this now.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
May 31 2021
Jul 8 2020
May 29 2020
May 27 2020
@ngraham Done, thank you!
May 26 2020
Thanks! This might get a bit more attention if you re-submit it as a merge request at https://invent.kde.org/utilities/yakuake/-/merge_requests, now that KDE has moved patch review to GitLab. Here's some documentation if you're unfamiliar with the workflow: https://community.kde.org/Infrastructure/GitLab
May 14 2020
Fix crash when unplugging monitor on which Yakuake is set to open
May 13 2020
May 12 2020
Fixed a problem in MainWindow::getScreen() due to the fact the list of screens is 0 based while Yakuake stores the screen number starting from 1.
May 11 2020
Afraid I don't have HiDPI displays to test with. Glad the issue is finally seeing work though!
Apr 10 2020
Mar 10 2020
Fixed copyright statements.
On a related note, I uploaded another patch that reformats the rest of Yakuake's if statements to match the ones here.
Added copyright statement
Mar 8 2020
@ryanmccoskrie can you provide an email address so we can land this patch with correct attribution? Thanks again for the lovely contribution!
Awesome!
LGTM. @mweepigeon? Since you requested changed, you'll nedd to re-review and change your status to Accepted if you're happy with it now.
Fixed formatting and added comments
- Merge branch 'master' into 154686-Resize_on_title_drag
- * Now conforms to KDE style guidelines
- * C++ dynamic cast instead of C cast
- * renamed parent to window in TitleBar::mouseMoveEvent()
- Merge branch 'master' into 154686-Resize_on_title_drag
- Merge branch 'master' into 154686-Resize_on_title_drag
- TitleBar now uses the vertical-resize cursor
- Fixed titlebar buttons using vertical-size cursor
Dragging and icon seem to be working for me! I think it should be good once you take care of the style change requests
Fixed menu buttons using vertical-size cursor.
The Title Bar now indicates it is resizeable with a vertical size cursor.
In D22227#620201, @ngraham wrote:@ryanmccoskrie sorry this got lost. Would you be interested in finishing it up so we can get it landed?
Mar 1 2020
@ryanmccoskrie sorry this got lost. Would you be interested in finishing it up so we can get it landed?
Feb 29 2020
Resizing the window works great, and the 'flickering' effect is relatively minor. However, the cursor should change when it is over the titlebar to indicate to the user that they are able to drag to resize it - ideally the vertical double arrow cursor icon
Looks great to me!
@mglb ping
Feb 11 2020
In D25123#607216, @davidre wrote:If you land this please update the summary before. No need to have all the variants in the commit message it should be about the actual change. Thanks :)
Feb 7 2020
If you land this please update the summary before. No need to have all the variants in the commit message it should be about the actual change. Thanks :)
Huh, I was waiting for @hein :) oh well, here it is - C icon with cleaned up source
Feb 4 2020
@mglb ping! I feel like we're really close for this.
Dec 5 2019
Nov 10 2019
Agreed, C for me too.
Nov 9 2019
In D25123#560491, @ndavis wrote:I think I prefer C the most now that I've seen it next to other icons. It has a similar level of detail to other Breeze icons.
I think I prefer C the most now that I've seen it next to other icons. It has a similar level of detail to other Breeze icons.
In D25123#558363, @ndavis wrote:switching to that system means we would need to change many icons.
Nov 4 2019
In D25123#558353, @mglb wrote:Breaking nice-looking proportions just to fill vertical space is not good IMO. Making the bar a bit higher might make it look more reasonably. Your second proposition (icon C) looks nice though.
In D25123#558205, @ndavis wrote:
Nov 3 2019
In D25123#558205, @ndavis wrote:VDG, Should we allow some types of icons to be vertically off center? If not that, should we allow some icons to not reach all the way to the top and bottom margins? There are already some icons like that, but that doesn't necessarily mean we should want that.
A or C for me.
I like A.
My vote is for A. I love it. It looks like a pull-down terminal just like the parent icon, re-uses the >_ iconography common to our terminal icons, but adds a flair that makes the > look like a Y, conjuring up the app's name. I think this is fantastic.
Nov 2 2019
Oct 17 2019
That makes sense, but it's slightly out of scope of what I wanted to implement. I will revisit once maintaining a local patch proves too much of a hassle.
Oct 15 2019
Had the first scenario in mind. I would use that to move yakuake around when I want it temporarily on a different screen , but when I reopen yakuake it should just honor the original setting value (Should note here that I use yakuake with the "Keep open when losing focus" option). So if Screen 1 is set open on Screen 1 again and if At Mouse Location is set open at mouse location again.
Interesting point, but could you elaborate on what should happen when the option to change the setting is disabled?
Having a shortcut to move yakuake around seems quite useful, but I'm not a fan that this overwrites the "Open on screen" setting.
Maybe making this behavior optional?
Aug 14 2019
In D22227#495177, @hein wrote:The resize should happen in the same steps as the config allows (and reads/writes), otherwise the UI will end up being confused, in particular the menu.
Switched from C style cast to dynamic cast.
Jul 14 2019
The resize should happen in the same steps as the config allows (and reads/writes), otherwise the UI will end up being confused, in particular the menu.
Jul 9 2019
Thanks Owen, very nice first patch! May it be just the first of many. :)
Jul 8 2019
In D21867#491007, @ngraham wrote:@owenchia, can you provide your email address so we can land this patch with correct authorship information? Thanks!
Jul 7 2019
Adjusted formatting to fit KDE style guidelines.
Jul 5 2019
Jul 4 2019
@owenchia, can you provide your email address so we can land this patch with correct authorship information? Thanks!
Jul 3 2019
Got the whole change into request, not just a one-line touch up.
Jul 2 2019
I've resisted patches like this for years now hoping someone would implement this properly in the Konsole KPart as part of the profile system where translucency is regulated, but no one did, so let's go with this.
Jul 1 2019
Jun 30 2019
Jun 25 2019
Jun 17 2019
In D21867#481235, @ngraham wrote:Maybe, but that's a design change, not just the addition of a new feature, so now the title/commit message is not accurate; you're not just adding support for blur, you're turning it on by default.
You need to either change the commit message to reflect the actual changes, or (preferably) only add support in this patch, and turn it on by default in another patch.
change Blur option's default value to false.
In D21867#481071, @owenchia wrote:In D21867#481044, @ngraham wrote:Thanks very much for the patch!
Is having this on the best default? This is not actually a sarcastic rhetorical question; I'm genuinely asking since I don't actually use Yakuake.
I'm not a expert, but i think it's the best to having this blur effect on default.
In D21867#481044, @ngraham wrote:Thanks very much for the patch!
Is having this on the best default? This is not actually a sarcastic rhetorical question; I'm genuinely asking since I don't actually use Yakuake.
Thanks very much for the patch!
May 23 2019
It's not that easy I'm afraid.
Mar 24 2019
Mar 22 2019
ok I make some cleanup