Re: Sprint notes: how to improve getting new contributors

[Filip Fila]

One thing I think is worth mentioning is that the KDE Store is not utilized
at all as a hub for recruiting new contributors.

There's some talented and competent people there but I haven't really
seen the community reach out to them.

On Mon, Jun 15, 2020 at 10:02 AM Bhushan Shah  wrote:

> Note that I attended only half of the session due to dinner break, so if
> you have more to add in notes, please add it
>
> Notes:
>
> - TODO Better READMEs, linking to wikis + information/description specific
> about the repo
> - Write more blog posts (even if short posts do it!)
> - too many different ways to do things
> - documentation is fragmented
> - investigate kdesrc-build env driver vs thing in plasma-workspace
> - improve dependency list in kdesrc-build --initial-setup
>
>
> --
> Bhushan Shah
> http://blog.bshah.in
> IRC Nick : bshah on Freenode
> GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D
>

D29847: Fixes compile problem for freebsd because of missing crypt.h

[Adriaan de Groot]

adridg added a comment.


  This review should be closed: a change landed via invent that makes it 
unnecessary (`` is no longer used in the users kcm).

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D29847

To: usta, #plasma, bcooksley, ngraham, adridg, #freebsd
Cc: meven, tcberner, adridg, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, arrowd, sebas, apol, 
ahiemstra, mart

D29847: Fixes compile problem for freebsd because of missing crypt.h

[Méven Car]

meven added a comment.


  In D29847#674811 , @usta wrote:
  
  > In D29847#674807 , @adridg wrote:
  >
  > > https://invent.kde.org/adridg/plasma-desktop/-/tree/normalize-includes
  > >
  > > There's already a CMake-time check for ``, it's just not used. 
(`HAVE_CRYPT_H`)
  >
  >
  > @adridg having or not having crypt_h I think won't solve this problem 
because it looks like Linux needs it on the other hand BSD system doesn't have 
it and use unistd.h
  >  instead of crypt.h so doesn't we still need to check if the system is 
linux or not ? I have almost 0 knowledge about bsd systems so i think anyone 
who has knowledge 
  >  on this topic might be more suitable for this patch request. ( at first, I 
have just think about freebsd and now i can see there are other alternatives 
(net,open,... bsd has similar issue ) )
  
  
  Linux will have HAVE_CRYPT_H set and *BSD won't, so this simply solves the 
issue :
  
#ifdef HAVE_CRYPT_H
#include 
#endif
  
  It is used in `kscreenlocker/kcheckpass/kcheckpass.h` for instance.
  
  kscreenlocker defines HAVE_CRYPT_H as :
  
set(CRYPT_LIBRARIES)
check_library_exists(crypt crypt "" HAVE_CRYPT)
if (HAVE_CRYPT)
set(CRYPT_LIBRARIES crypt)
check_include_files(crypt.h HAVE_CRYPT_H)
endif (HAVE_CRYPT)
  
  You will need to add it to plasma-desktop cmake file in the appropriate 
section.

REPOSITORY
  R119 Plasma Desktop

REVISION DETAIL
  https://phabricator.kde.org/D29847

To: usta, #plasma, bcooksley, ngraham, adridg, #freebsd
Cc: meven, tcberner, adridg, plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, 
cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, 
lesliezhai, ali-mohamed, jensreuterberg, abetts, arrowd, sebas, apol, 
ahiemstra, mart

Sprint notes - PowerDevil

[Kai Uwe Broulik]

Find below the sprint notes for the "PowerDevil" session. We decided to 
broaden the scope a little from PowerDevil KCM to overall PowerDevil 
discussion:


Cheers
Kai Uwe

* KCM is all about plugins but I'd suggest making a static "coherent" UI
* figure out disabling vs "don't touch" (e.g. screen brightness 
shouldn't be messed with all the time when plugging AC)

* dim brightness dims in multiple steps, why?
* Add turn screen off AND lock option - ask VDG how to do that with good UX
* figure out "restoring state" rather than overwriting when you switch 
between profiles, e.g. don't always mess with screen brightness if user 
manually changed it...
* the "run script" stuff is pretty much a workaround for us not having a 
proper "do stuff on certain events" KCM. Should remove the UI in the kcm 
and just document how to set these scripts in some wiki.


* move bluetooth/wifi etc to bluedevil/plasma-nm
* make it smarter, dont disable if something is paired or I dont know

* UPower backend which is not exactly backend, and also does not use 
anything upower specific much

* kill XRandrBrightness control
* multi screen brightness support - FN keys prefer laptop screen and 
then you have multiple sliders for each screen or something


* can we show something like "app xyz is using a lot of power" right 
now? do we also get hardware info? does cgroups help? The wakeups stuff 
we had in Energy Info seems to be disabled on most kernels these days


* login1 inhibition support:
	* listen to inhibitors change and translate them to internal powerdevil 
state, just track them like xdg inhibition


* Wake lock support for mobile:
	* when user activity is happening, register a wakelock, drop when it 
hits idle timeout and let the kernel handle sleep/wakeup

monday meeting notes for 15/6/2020

[Marco Martin]

David R
* I started working on lockscreen kcm porting it to qml
* Aside from that fixed an annoyance when combobox had a scrollbar
https://invent.kde.org/frameworks/qqc2-desktop-style/-/merge_requests/9
* d_ed wanted to review models in shortcuts kcm

Kai Uwe
Notifications:
* Can now toggle do not disturb by middle clicking notification icon
plasma-pa:
* Did a proof of concept push to talk feature to aid online meetings:
https://invent.kde.org/plasma/plasma-pa/-/merge_requests/4
* It uses keyboard repeat which isn't very ideal... e.g. causes
Telegram to spam between away and online because the window briefly
loses focus when X does the transient grab for shortcut.. can't think
of a better way though
Other:
* Did a small blog post about Plasma sprint on the weekend:
https://blog.broulik.de/2020/06/virtual-plasma-sprint-2020/
* Wil send PowerDevil notes out to ml later

Bhushan
 - Plasma Virtual Sprint
 - Added labels in  Plasma group to aid in review workflow :
https://invent.kde.org/groups/plasma/-/labels
 - https://phabricator.kde.org/T13285 Virtual Sprint feedback
Task 13285 "Plasma virtual sprint 2020 feedback" [Open,Needs
Triage] {Akademy Tools,Plasma} https://phabricator.kde.org/T13285
 - Please help akademy team by answering all questions there (Even if
it worked smoothly for you, please state hardware software used by
you)
 - I will work out little bit more on notifications watcher thing as
discussed yesterday

David E
* I've been fixing up some issues with the .0 release
* there was a race condtion on system tray icon startup
* and a few problems with the new system monitor applets
* bugzilla is very busy right now :/
* but it always is after a release
* I don't think I have too much new to say as there was a sprint yesterday!
* I've typed up a load of notes onto the ML

Arjen
I mainly did some stuff on ksysguard
* can't recall precisely what tbh ^^
* then there was the plasma sprint
* which was nice
* I may also have started an experiment regarding the qt style
stuff... but at this moment it's too early to tell if that's going to
go anywhere

Marco
* continued with treeview out of kdescendantsproxymodel
* plasma desktop scripting now support accessing read only the applet geometry
* systemmonitor faces now supports sensors as regular expressions (to
make easiers to have graphs with for instance all the cpu cores)
* helping on polishing work for the new ksysguardqml app, espedially
some graphical fixes in the face config UI

Sprint notes - widget and plasma styling in Plasma 6

[David Edmundson]

We all agree we should have a custom QStyle and QtQuick Controls style that
can load a theme written in some declarative text + image format then we
use the native toolkit support to render that in the best way. Only this
would be supported.

However:
 - Realistically this is not feasible for Plasma 6.0
 - We should go as-is for Plasma 6.0 with our QtQuick plasma style and
QtQuick desktop style which will do QPainter things and upload large
textures. Maybe Qt6's new API can help, maybe not.

This still leaves the problem of plasma configuration where we want the
desktop view in the same process as where the QQC2 theme is the plasma
style.

 - Continue using Plasma imports to explicitly set the theme. We
universally decided we don't want this in Plasma 6.

  - something clever with QUrlInterceptor. This may need changes to
QUrlInterceptor, so we should look into it early

 - Run config UIs as a separate process

 - just use the plasma theme in configs.


All have pros and cnos.

David

Re: Plasma 5.20 and Qt versions

[Andreas Sturmlechner]

On Fri, 12 Jun 2020 at 13:34, David Edmundson
 wrote:
> We're in the process of determining our dependencies for Plasma 5.20, our 
> release in about 4 months.
>
> Ideally we would like to depend on Qt5.15, we can land some wayland fixes 
> that would be otherwise hard to  #ifdef as well as do some big code cleanup.

No problem for Gentoo, Qt 5.15.0 is available since release day and
will be stable in ~2 months together with Release Service 20.04.3 and
after fixing all other consumers.

Regards,
Andreas

Sprint notes: Wayland and KWin

[Bhushan Shah]

Discussed KWayland split
Features
- clipboard
- layer shell, we all want it. David will make a detailed broken down phab 
task
- screencasting, we'll have window sharing, thumbnails.
- virtual keyboard
- touchscreen gestures
- touchpad gestures
- tiling for tablet mode (or for who uses tiling on desktop)
- reach out the developers of the big kwin tiling script

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Sprint notes: how to improve getting new contributors

[Bhushan Shah]

Note that I attended only half of the session due to dinner break, so if
you have more to add in notes, please add it

Notes:

- TODO Better READMEs, linking to wikis + information/description specific 
about the repo
- Write more blog posts (even if short posts do it!)
- too many different ways to do things
- documentation is fragmented
- investigate kdesrc-build env driver vs thing in plasma-workspace
- improve dependency list in kdesrc-build --initial-setup


-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Sprint notes: notifications

[Bhushan Shah]

Below is Notifications breakout we had on Sunday

Sounds
* remove phonon, keep canberra as only codepath
* support sound schemes
* app says play "new email sound" rather than 
"Oxygen-horrible-sound.ogg"
* move sound handling to notification server
* suport "sound-name" and "sound-file"
* figure out use case of "just playing sound"
* e.g. for KMessageBox, QMessageBox
* can we have some QPT thing for sounds? There's QApplication::beep() 
...
* QSoundEffect::fromTheme("...") with xdg sound spec, similar to QIcon?
* add setSoundName/setSoundFile to KNotification

Lock Screen / KDE Connect
* add shared notification component (e.g. notification header item or 
notification body item) in plasma-workspace components similar to battery icon 
component
* support android hint for "show all", "show only count", "show nothing"
* have on app config page a checkbox for which watchers to send it to
* cf https://mail.kde.org/pipermail/plasma-devel/2020-April/114374.html
* can we use dbus service file to check that service owner is genuine kde 
connect or whatever?
* install desktop file or wahtever for all watchers so we can enumerate for 
settings and identify watchers

Other
* maybe increase maximum screen popup fill percentage
* "timeout" hint?

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Sprint notes for gitlab discussion

[Bhushan Shah]

On Mon, Jun 15, 2020 at 09:21:53AM +0300, Vlad Zahorodnii wrote:
> I agree that the interactive rebase tool is difficult to master, but we
> could provide an example of recommended gitlab workflow on our wiki and
> point newcomers to it. By doing so, we will help the newcomers grow
> professionally and hopefully give them a reason to continue contributing to
> KDE. :-)

+1, I would be happy to provide such tutorial / personal guide if people
want help with it.

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Sprint notes for gitlab discussion

[Bhushan Shah]

On Sun, Jun 14, 2020 at 11:06:28PM +0100, David Edmundson wrote:
>  - We had a discussion about how to make review queues a big more
> manageable.
> We intend to use some labels.
> 
> Action plan is to copy + paste the labels Krita uses...as if it works for
> them, they're probably good enough. Bshah is to do this.

This is now done:

https://invent.kde.org/groups/plasma/-/labels

> Labels are technically per-project, but as long as they have the same name
> it's fine.

Not per-project, but per-group, but if two groups have same named labels
then search/filtering take them as one entity.


-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Sprint notes for gitlab discussion

[David Edmundson]

So to clarify, there are two allowed gitlab workflows.

MRs for chains of nicely done rebased commits
MRs where one MR represents a single logical commit to be squashed and the
list of actual commits uploaded is garbage.


>
> One issue with such a workflow is that code reviewers will have to
> accumulate all commits in their mind. Speaking for myself, that is
> really difficult.
>

Not really, we either just either review individual commits, or we review
the whole merge request depending on what is relevant from the style used.
It's normally clear from the commit names.


> Another issue is that it's not clear how the commits are going to be
> squashed, which makes it even more hard to add "ship it."
>



> For example, let's consider that a person has created a merge request
> with two commits
>

If the person is good at git, they'll squash C locally before force pushing.
If the person is not, they should just have made two merge requests to
begin with.

I think we can certainly encourage the good git pattern especially for an
advanced complicated multi-commit branch.
it's just a case of finding a balance for the people just doing really
simple changes.

David

Virtual Sprint feedback

[Bhushan Shah]

Good morning!

As mentioned in sprint yesterday, it would be nice if we can provide a
feedback for Virtual Sprint at : https://phabricator.kde.org/T13285

This will help us to better organize such events in future, as well as
it will help Akademy team for better planning of Virtual Akademy!

Thanks

-- 
Bhushan Shah
http://blog.bshah.in
IRC Nick : bshah on Freenode
GPG key fingerprint : 0AAC 775B B643 7A8D 9AF7 A3AC FE07 8411 7FBC E11D


signature.asc
Description: PGP signature

Re: Sprint notes for gitlab discussion

[Vlad Zahorodnii]

Hi,

On 6/15/20 1:06 AM, David Edmundson wrote:
  - There was a discussion on the two different styles of use gitlab 
use. Some people squash locally and have a nice neat commit history. 
Others don't, and then just squash at end.


      - Conclusion was it's unreasonable to get devs to squash and 
rebase "nicely" as it's perceived as too hard (even though it really 
isn't - ed)


One issue with such a workflow is that code reviewers will have to 
accumulate all commits in their mind. Speaking for myself, that is 
really difficult.


Another issue is that it's not clear how the commits are going to be 
squashed, which makes it even more hard to add "ship it."


For example, let's consider that a person has created a merge request 
with two commits


   A -> B

a code reviewer spots an issue and asks the author of the merge request 
to address it


   A -> B -> C' (C' is the commit that fixes the issue)

another code reviewer shows up and notices another problem

  A -> B -> C' -> D'

after a couple of more code review rounds, we end up with the following 
commit history


  A -> B -> C' -> D' -> E' -> ... -> Approved'

The question is: how commits C', D' and so on are going to be squashed? 
What if some of those commits cannot be squashed cleanly because of 
merge conflicts? Will resolved merge conflicts go in unreviewed?


I agree that the interactive rebase tool is difficult to master, but we 
could provide an example of recommended gitlab workflow on our wiki and 
point newcomers to it. By doing so, we will help the newcomers grow 
professionally and hopefully give them a reason to continue contributing 
to KDE. :-)


Cheers,
vlad