D24223: [RFC] Add global themes that mimic other platforms' workflows
ngraham added a comment. I'm open to re-doing this to expose alternative layouts that don't explicitly mimic other platforms. The problem is, I'm not very creative in my use of this functionality. All I really do is put my panel on the left screen edge. I would need ideas for alternative layouts. Another idea is to put these explicitly-other-platform-mimicking layouts on store.kde.org so they're available but people need to manually download them. Not sure how much that would actually satisfy the original goal, though. REPOSITORY R114 Plasma Addons REVISION DETAIL https://phabricator.kde.org/D24223 To: ngraham, #vdg, #plasma Cc: Boxie, wstephenson, davidre, LeGast00n, enriqueme, mart, fabianr, Zren, mmustac, niccolove, rikmills, cblack, broulik, mvourlakos, plasma-devel, Orage, The-Feren-OS-Dev, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra
Re: Gitlab merge workflow: reverse it?
I'm in favor of merging to master first. It's just easier for me to work that way because the cherry picking is something I can just add on top of my normal git workflow instead of having to remember a different git workflow for situations where we may want to patch a stable branch. On Thu, Jun 25, 2020 at 10:46 AM Bhushan Shah wrote: > > Hello everyone! > > This is a proposal to change our workflow regarding release branches and > our merge workflow, > > # Current workflow > > - Current workflow is that we commit to stable branch and then merge it > upwords until master branch > - i.e commit to Plasma/5.18 branch, merge 5.18 into 5.19 and then > master > > # Proposed workflow > > - Proposed workflow is to instead commit all changes in master, and > cherry-pick related changes in the stable branch as needed > > # Why? > > We occasionally hit several issues with current workflow, > > - Merge conflicts when merging changes upwords > - Changes which are valid only for stable branch needs to be reverted in > master branches > - Accidential merges from the master branch to stable branch which needs > to be force-pushed > > For now I am proposing this change only for Plasma repositories if we > like it, we can propose this workflow for rest of KDE repositories, but > that needs discussions in kde-devel/kde-core-devel separately. > > Thoughts? > > -- > Bhushan Shah > http://blog.bshah.in > IRC Nick : bshah on Freenode > GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
D12405: [WIP] Per-screen scale factors on X11 using QT_SCREEN_SCALE_FACTORS
anthonyfieroni added a comment. I test, current situation, i don't think the parch is needed as is. 2 monitors FullHD and 4K (HDMI) now KScreen does not allow different scale factor, to distinct monitor but you can changed config [KScreen] ScaleFactor=1 ScreenScaleFactors=eDP1=1;HDMI1=2;VIRTUAL1=1; That seems to work, but not well enough. When you move window from low res monitor to high res one window is scaled automatically, but it seems glitchy. REPOSITORY R104 KScreen REVISION DETAIL https://phabricator.kde.org/D12405 To: fvogt, #plasma Cc: anthonyfieroni, luxus, snugghash, gladhorn, mart, hein, ngraham, graesslin, davidedmundson, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra
