Re: Kamoso in KDE Applications

[Ben Cooksley]

On Tue, Jan 16, 2018 at 10:49 AM, Albert Astals Cid  wrote:
> El dilluns, 15 de gener de 2018, a les 4:05:05 CET, Aleix Pol va escriure:
>> On Sun, Jan 14, 2018 at 11:31 PM, Albert Astals Cid  wrote:
>> > El divendres, 12 de gener de 2018, a les 3:51:03 CET, Aleix Pol va
> escriure:
>> >> On Thu, Jan 11, 2018 at 7:44 PM, Albert Astals Cid  wrote:
>> >> > El dijous, 11 de gener de 2018, a les 17:01:52 CET, Aleix Pol va
> escriure:
>> >> >> Hey,
>> >> >> I'd like to move it there. It's in extragear/multimedia now and I keep
>> >> >> forgetting to release as often as I should.
>> >> >>
>> >> >> But the application is working, maintained and developed.
>> >> >>
>> >> >> Thoughts?
>> >> >
>> >> > I'm not vey happy about the copied code of QtGStreamer.
>> >> >
>> >> > Why did you decide to copy it?
>> >>
>> >> It's unmaintained, I had sent several fixes that went in but never got
>> >> released. So if you used it with master Kamoso worked but stable
>> >> didn't.
>> >
>> > Ok so you decided to fork it instead of becoming the upstream maintainer,
>> > fair enough i guess.
>> >
>> > But maybe you should rename
>> >
>> >./src/elements/gstqtvideosink/CMakeLists.txt:66:install(TARGETS gst$
>> >
>> > {QTVIDEOSINK_NAME} DESTINATION ${CMAKE_INSTALL_LIBDIR}/gstreamer-$
>> > {GSTREAMER_ABI_VERSION})
>> > so that it does not conflict with what other distros may be shipping from
>> > the "real" QtGStreamer ?
>>
>> I did, the code looks a bit weird but I didn't want to change it too
>> much from upstream.
>> We have this:
>> set(QTVIDEOSINK_NAME kamoso-qt5videosink)
>
> Ah, i see.
>
> Ok, personally i don't have any objection to adding yet another app to KDE
> Applications, anyone else has something to comment?

I can't see any issues with this, shall we proceed with the move in
say 24 hours?

>
> Cheers,
>   Albert

Cheers,
Ben

>
>>
>> > Also can you please get a build on https://build.kde.org/ going ?
>>
>> Yes, just requested it.
>>
>> Thanks!
>> Aleix
>
>

Re: New KDE application

[Rahul Chowdhury]

On Tue, Jan 16, 2018 at 3:24 AM, Albert Astals Cid  wrote:
> El dilluns, 15 de gener de 2018, a les 13:00:13 CET, Rahul Chowdhury va
> escriure:
>> On Mon, Jan 15, 2018 at 5:25 AM, Albert Astals Cid  wrote:
>> > El dimecres, 10 de gener de 2018, a les 23:49:06 CET, Sayan Biswas va
>> >
>> > escriure:
>> >> Hi,
>> >
>> > Hi
>>
>> Hi,
>>
>> >> A very happy new year to all. Hope you guys are doing good. :)
>> >>
>> >> Me and Rahul (CC'ed; IRC nick - rahulch) came up with an idea for a
>> >> new application in KDE, and we were hoping to get an opinion on it.
>> >>
>> >> The central idea behind the app will be to manage the expenses of a
>> >> group of users. As a user, you can create one or more groups, add
>> >> members to them, and add entries for expenses for a given group. You
>> >> can also check the outstanding balances and choose to settle-up with one
>> >> or more members. There will be options for fine-tuning a given entry -
>> >> decide who all have born the total expenditure and by what
>> >> proportions, how should the total expense be divided among the members
>> >> (equally/specific amounts/etc), add pictures for receipts, add
>> >> comments, and so on and so forth.
>> >
>> > So somthing like a Splitwise Free Software clone, have you checked if one
>> > already exists? I know starting is half the fun, but maybe joining an
>> > existing project that does something similar and help them build a
>> > desktop application would also be nice.
>>
>> Yes, the idea is very much similar to Splitwise. They do not have any
>> desktop version yet.
>> We wanted to have some similar free desktop application in KDE.
>>
>> >> We are planning to start off with desktop application with a
>> >> decentralised
>> >> approach, i.e. the users will hold the data of the shared expenses. Now
>> >> again, there is a possibility of tampering with the expenditure so we
>> >> might
>> >> need to set a centralised archived or something similar data set to
>> >> maintain the integrity and persistence of a transaction. We are open to
>> >> opinions and discussions for this also. Further to that we will be
>> >> building
>> >> mobile application for the users ease of usage and add expenditure on the
>> >> go. After all, mobiles are more widely used by user than desktop
>> >> application.
>> >>
>> >>
>> >> For settling up we were thinking of integrating some standard payment
>> >> gateways (PayPal, etc) but I am not sure of how much of this
>> >> integration is possible in KDE.
>> >
>> > I don't understand this question, just open a webview to paypal and be
>> > done?
>> Not just open a webview or redirect to some paypal webpage in a
>> browser, but handle the entire transaction from the application itself
>> with some third party integration like PayU. If we could integrate one
>> or more such payment services/e-wallets with the application and
>> handle the paments it would be great.
>
> Honestly, up to you, but opening a webview is easier and more secure, or at
> least you shift the blame to paypal if they have a hackable page. Rolling up
> your own payment code means it's much more easy to make a mistake and get
> hacked like it seems happened to oneplus.
>
> Cheers,
>   Albert

Yes, that makes sense. We will go ahead with the webview approach.
Thanks for the suggestion.


Regards,
Rahul

Re: Plasma5 user sessions

[Roman Gilg]

Hi Max,

if you're using Plasma 5.11, then you don't need to look into the
 "plasma-workspace/startkde/waitforname" folder, because 5.11 has it. So
the notifications should be delayed on your system already. But of course
you can still take a look and check the patch out, which added it [1],
because maybe you find a clue why it doesn't work in your setup.

There is also the folder "$HOME/.config/plasma-workspace/env", whose
scripts gets executed as well on session start, but late in the process to
my knowledge. So it might be an idea to put your notification script there.

Regarding the logout/shutdown: we are talking about a single desktop PC
with multiple users being logged in at the same time and one of them in his
currenctly active session requests a shutdown, right? The user also has the
right to shutdown while other users are logged in, right? First you didn't
specify where you hook into at the moment to execute your logout tasks.
logind provides the D-Bus signal PrepareForShutdown, so maybe try to hook
into this if you don't do it already. Also two years ago there was a change
to systemd's behavior in killing processes directly [2], so maybe try to
reverse this behavior with the respective flag. I assume a properly
configured system should have no problem with this though.

Also consider using systemd user services instead of putting scripts in "
/etc/X11/Xsession.d" [3].

Cheers
Roman

[1] https://phabricator.kde.org/D5012
[2]
https://www.golem.de/news/aufraeumen-von-prozessen-beim-logout-systemd-neuerung-sorgt-fuer-nutzerkontroversen-1605-121176.html
[3]
https://superuser.com/questions/1037466/how-to-start-a-systemd-service-after-user-login-and-stop-it-before-user-logout

On Mon, Jan 15, 2018 at 5:58 PM, Max Harmathy 
wrote:

> Am 15.01.2018 15:29, schrieb David Edmundson:
>
>>
>> org.freedesktop.Notifications. However on our development release
>> those
>> messages get displayed as windows instead of the usual bubbles. It
>> seems
>> that the notification handling is not ready when the autostarts are
>> running.
>>
>> There is a fix for this in Plasma 5.10 onwards.
>> Or you can backport the "plasma-workspace/startkde/waitforname"  folder
>>
>> Make sure any Dbus calls are sent asyncronously, otherwise you'll block
>> your startup.
>>
>>
>>
> Thank you David for your quick reply!
>
> We are currently using plasma 5.11 from bionic (Ubuntu 18.04).
> I will have a look into "plasma-workspace/startkde/waitforname".
>
>
> As for the logind problem: I can reproduce this with a current kde-neon:
> * log in with two local users
> * one user logs out by selecting "Reboot"
> * both sessions get killed instantly
>
>
> --
> Max Harmathy
> IT@M - Dienstleister für Informations- und Telekommunikationstechnik
> der Landeshauptstadt München
>
> Geschäftsbereich Werkzeuge und Infrastruktur
> Servicebereich Städtische Arbeitsplätze
> Serviceteam LiMux-Arbeitsplatz I23
>
> Agnes-Pockels-Bogen 21, 80992 München
>
> Tel.: +49 89 233-782223
> E-Mail: max.harma...@muenchen.de
>
> 
> 
> Diese E-Mail wurde von einem LiMux-Arbeitsplatz aus versandt.
> 
> 
> Elektronische Kommunikation mit der Landeshauptstadt München siehe:
> http://www.muenchen.de/ekomm
>
> Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken. Pro
> Blatt sparen Sie durchschnittlich 15g Holz, 260ml Wasser, 0,05kWh Strom und
> 5g CO2.
>

Re: New KDE application

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 13:00:13 CET, Rahul Chowdhury va 
escriure:
> On Mon, Jan 15, 2018 at 5:25 AM, Albert Astals Cid  wrote:
> > El dimecres, 10 de gener de 2018, a les 23:49:06 CET, Sayan Biswas va
> > 
> > escriure:
> >> Hi,
> > 
> > Hi
> 
> Hi,
> 
> >> A very happy new year to all. Hope you guys are doing good. :)
> >> 
> >> Me and Rahul (CC'ed; IRC nick - rahulch) came up with an idea for a
> >> new application in KDE, and we were hoping to get an opinion on it.
> >> 
> >> The central idea behind the app will be to manage the expenses of a
> >> group of users. As a user, you can create one or more groups, add
> >> members to them, and add entries for expenses for a given group. You
> >> can also check the outstanding balances and choose to settle-up with one
> >> or more members. There will be options for fine-tuning a given entry -
> >> decide who all have born the total expenditure and by what
> >> proportions, how should the total expense be divided among the members
> >> (equally/specific amounts/etc), add pictures for receipts, add
> >> comments, and so on and so forth.
> > 
> > So somthing like a Splitwise Free Software clone, have you checked if one
> > already exists? I know starting is half the fun, but maybe joining an
> > existing project that does something similar and help them build a
> > desktop application would also be nice.
> 
> Yes, the idea is very much similar to Splitwise. They do not have any
> desktop version yet.
> We wanted to have some similar free desktop application in KDE.
> 
> >> We are planning to start off with desktop application with a
> >> decentralised
> >> approach, i.e. the users will hold the data of the shared expenses. Now
> >> again, there is a possibility of tampering with the expenditure so we
> >> might
> >> need to set a centralised archived or something similar data set to
> >> maintain the integrity and persistence of a transaction. We are open to
> >> opinions and discussions for this also. Further to that we will be
> >> building
> >> mobile application for the users ease of usage and add expenditure on the
> >> go. After all, mobiles are more widely used by user than desktop
> >> application.
> >> 
> >> 
> >> For settling up we were thinking of integrating some standard payment
> >> gateways (PayPal, etc) but I am not sure of how much of this
> >> integration is possible in KDE.
> > 
> > I don't understand this question, just open a webview to paypal and be
> > done?
> Not just open a webview or redirect to some paypal webpage in a
> browser, but handle the entire transaction from the application itself
> with some third party integration like PayU. If we could integrate one
> or more such payment services/e-wallets with the application and
> handle the paments it would be great.

Honestly, up to you, but opening a webview is easier and more secure, or at 
least you shift the blame to paypal if they have a hackable page. Rolling up 
your own payment code means it's much more easy to make a mistake and get 
hacked like it seems happened to oneplus.

Cheers,
  Albert

Re: Kamoso in KDE Applications

[Albert Astals Cid]

El dilluns, 15 de gener de 2018, a les 4:05:05 CET, Aleix Pol va escriure:
> On Sun, Jan 14, 2018 at 11:31 PM, Albert Astals Cid  wrote:
> > El divendres, 12 de gener de 2018, a les 3:51:03 CET, Aleix Pol va 
escriure:
> >> On Thu, Jan 11, 2018 at 7:44 PM, Albert Astals Cid  wrote:
> >> > El dijous, 11 de gener de 2018, a les 17:01:52 CET, Aleix Pol va 
escriure:
> >> >> Hey,
> >> >> I'd like to move it there. It's in extragear/multimedia now and I keep
> >> >> forgetting to release as often as I should.
> >> >> 
> >> >> But the application is working, maintained and developed.
> >> >> 
> >> >> Thoughts?
> >> > 
> >> > I'm not vey happy about the copied code of QtGStreamer.
> >> > 
> >> > Why did you decide to copy it?
> >> 
> >> It's unmaintained, I had sent several fixes that went in but never got
> >> released. So if you used it with master Kamoso worked but stable
> >> didn't.
> > 
> > Ok so you decided to fork it instead of becoming the upstream maintainer,
> > fair enough i guess.
> > 
> > But maybe you should rename
> > 
> >./src/elements/gstqtvideosink/CMakeLists.txt:66:install(TARGETS gst$
> > 
> > {QTVIDEOSINK_NAME} DESTINATION ${CMAKE_INSTALL_LIBDIR}/gstreamer-$
> > {GSTREAMER_ABI_VERSION})
> > so that it does not conflict with what other distros may be shipping from
> > the "real" QtGStreamer ?
> 
> I did, the code looks a bit weird but I didn't want to change it too
> much from upstream.
> We have this:
> set(QTVIDEOSINK_NAME kamoso-qt5videosink)

Ah, i see.

Ok, personally i don't have any objection to adding yet another app to KDE 
Applications, anyone else has something to comment?

Cheers,
  Albert

> 
> > Also can you please get a build on https://build.kde.org/ going ?
> 
> Yes, just requested it.
> 
> Thanks!
> Aleix

Re: Plasma5 user sessions

[Max Harmathy]

Am 15.01.2018 um 20:07 schrieb Kai Uwe Broulik:
> Hi,
Thanks for your replay
>> We found out, that running a process with a systemd inhibitor as root e.g
>>
>>> # systemd-inhibit --what=shutdown --mode=block sleep 365d
> Try mode "delay", this will temporarily delay the action until you release 
> your inhibition. Typically used for certain cleanup tasks, like disconnecting 
> the network, before sending the computer to sleep but according to 
> documentation this works also for "shutdown" command. Check out the Logind 
> inhibition documentation [1].
Sadly the mode "delay" is no option: since there is a globally set
timeout for any delay, which is per default set to 5 sec and can be
changed in /etc/systemd/logind.conf by setting InhibitDelayMaxSec.
Setting this to a very high value would probably mean a high risk of
breaking other uses cases (set to sleep?).

Another Problem is, that in order to prevent the system from being
shutdown the inhibitor has to be set by root (or at least by a different
user than the dbus command is sent). In my opinion this is a
implementation flaw in systemd and contradicts some uses cases listed at
the beginning of https://www.freedesktop.org/wiki/Software/systemd/inhibit

At this point it would be extremely complicated to use inhibitors to
achieve our goal. The only way would be a system daemon which sets a
block inhibitor for shutdown and watches all user sessions and releases
the inhibitor only if there is no user session running. This would
however render the shutdown button in plasma useless.

> As for the warning when shutting down with multiple users, I  that might be 
> an 
> SDDM limitation/bug/missing feature.
Probably this is how KDM worked with utmp or ConsoleKit before. Correct
me if I am wrong, but in the old days the user session would always
reuse the x-server from the display manager. So naturally when the user
session ends the display manager would naturally regain control.

But now the kdisplaymanager code send messages to logind via dbus, which
then just killes the session. Any code after the comment in "startkde":
> #Anything after here is logout/shutdown
is definitely not executed on shutdown.

> Cheers,
> Kai Uwe
>
> [1] https://www.freedesktop.org/wiki/Software/systemd/inhibit/
>

Re: New KDE application

[Rahul Chowdhury]

On Mon, Jan 15, 2018 at 1:35 PM, Thomas Baumgart  wrote:
> Hi,
>

Hi Thomas,

> Do you know about the kde-finance-apps (developer) group? Maybe your
> application is something that fits in that area as well. See https://
> community.kde.org/Alkimia for some ideas what is/can become part of a common
> code base.
>
> Some of the functions you are looking for have already been developed as part
> of other applications (e.g. KMyMoney).
>

Thank you for the link to Alkimia page. We will surely check it out
and discuss with the finance-apps group if we can contribute to some
existing code-base.

>
> --
>
> Regards
>
> Thomas Baumgart
>
> https://www.telegram.org/   Telegram, the better WhatsApp
> -
> It is better to remain silent and be thought a fool,
> than to speak, and remove all doubt.
> -


Regards,
Rahul

Re: Plasma5 user sessions

[Max Harmathy]

Am 15.01.2018 15:29, schrieb David Edmundson:


org.freedesktop.Notifications. However on our development release those
messages get displayed as windows instead of the usual bubbles. It seems
that the notification handling is not ready when the autostarts are running.

There is a fix for this in Plasma 5.10 onwards.
Or you can backport the "plasma-workspace/startkde/waitforname"  folder

Make sure any Dbus calls are sent asyncronously, otherwise you'll block your 
startup.




Thank you David for your quick reply!

We are currently using plasma 5.11 from bionic (Ubuntu 18.04).
I will have a look into "plasma-workspace/startkde/waitforname".


As for the logind problem: I can reproduce this with a current kde-neon:
* log in with two local users
* one user logs out by selecting "Reboot"
* both sessions get killed instantly


--
Max Harmathy
IT@M - Dienstleister für Informations- und Telekommunikationstechnik
der Landeshauptstadt München

Geschäftsbereich Werkzeuge und Infrastruktur
Servicebereich Städtische Arbeitsplätze
Serviceteam LiMux-Arbeitsplatz I23

Agnes-Pockels-Bogen 21, 80992 München

Tel.: +49 89 233-782223
E-Mail: max.harma...@muenchen.de


Diese E-Mail wurde von einem LiMux-Arbeitsplatz aus versandt.

Elektronische Kommunikation mit der Landeshauptstadt München siehe: 
http://www.muenchen.de/ekomm

Bitte denken Sie an die Umwelt, bevor Sie diese E-Mail ausdrucken. Pro Blatt 
sparen Sie durchschnittlich 15g Holz, 260ml Wasser, 0,05kWh Strom und 5g CO2.

Re: KDE and Google Summer of Code 2018

[Dmitry Kazakov]

Hi, Valorie!

I have just edited the list of Krita ideas, now we have 8 ideas, 4 of 
which are low-hanging fruits with localized optimizations of the code. I 
hope that will help people who do not want to learn all half-million 
lines of Krita code.


Speaking truly, I think I understand why there is so little effort from 
people with the ideas. Since the last year Google forbids students to 
apply more than 2 times, it means that most of the applicants will be 
newcomers and, most probably, they will not be able to prepare some 
extensive proposal/design for a project. It is just too difficult to 
prepare a good proposal for a project so big in size. So it might be 
that the quality of last year proposals discouraged people from doing 
this work again.


The only way how we can solve the issue is to prepare very scope-limited 
tasks, such that the students would not need to learn all the code (in 
our case we just added AVX optimizations, which are limited to a scope 
of a couple of classes). But that is not always possible or makes sense 
for the some projects.



On 15.01.2018 03:39, Valorie Zimmerman wrote:
I'm very discouraged to see so little movement on this. After skipping 
GCi this past fall, are we now also considering skipping GSoC? Or 
downsizing the number of students we are mentoring?


Without Ideas we will not get students. More important, we must 
complete the Org application soon, and the Ideas page is the core of 
that application.


This is good for your team and your project, in the long run. It 
brings in new contributors and fresh ideas.


If you need some guidance, please read 
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html


I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman 
mailto:valorie.zimmer...@gmail.com>> wrote:



Hello GSoC mentors, and teams supporting mentors,

TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas
; read
https://community.kde.org/GSoC. Now.

Every year, we've asked for more time to get ramped up for GSoC,
and so now is the time for organizations to apply[1]. We have
begun to write our application, and  that means that our Ideas
page needs to be filled NOW, because that is the prime
consideration for the GSoC team once the Org Applications deadline
has passed.

The quality of our ideas and the guidance they give our students
are the most important part of our application. Please begin
filling in your ideas now if you have not already, and ensure that
that page is comprehensive, accurate and attractive. Including
screenshots and other images is allowed, if it enriches the idea
for a project. *Please ensure complete information about how to
contact the team*; this is crucial.

Also, take a look at the landing page
https://community.kde.org/GSoC. Experienced mentors agree that:

1. commits must be made before the student proposal is submitted,
and linked on that proposal, and

2. that regular communication from the student must be initiated
by the student at least weekly, and we expect daily or nearly
daily communication with the team in a more informal way.

Be sure to point students to that information, as this should
lower the number of proposals, while raising the quality.

1. https://developers.google.com/open-source/gsoc/timeline


PS: If your team has an Idea, ensure that you have mentors for it,
and that those mentors are subscribe to KDE-Soc-Mentor list.
Remove any ideas without mentors available, please. Now, before
you forget!

Valorie



--
http://about.me/valoriez


--
Dmitry Kazakov

Re: Plasma5 user sessions

[David Edmundson]

> org.freedesktop.Notifications. However on our development release those
> messages get displayed as windows instead of the usual bubbles. It seems
> that the notification handling is not ready when the autostarts are
> running.
>
> There is a fix for this in Plasma 5.10 onwards.
Or you can backport the "plasma-workspace/startkde/waitforname"  folder

Make sure any Dbus calls are sent asyncronously, otherwise you'll block
your startup.

Plasma5 user sessions

[Max Harmathy]

Greetings from Munich's LiMux developers team.

short story:

* during user session initialisation notifications get displayed as windows
* if one user requests a shutdown (reboot, poweroff) all sessions get killed

long story:

We are currently in development of our next (final?) release. Our
current release is based on Ubuntu 14.04 trust, whereas our next release
will be based on Ubuntu 18.04 bionic.

Thus we switch from
* upstart to systemd
* ConsoleKit to logind
* KDM to SDDM
* Plasma 4.x to Plasma 5.x

We have to execute some tasks for every user who logs into a computer.
This includes configuring start menu applications, configuring printers,
mounting network shares and synchronise the users home directory with a
filer (downsync). We also provide slots where administrators can run
scripts in the user context.

Up until now we hooked into the user session by putting some files into
/etc/X11/Xsession.d which is as far as we understand executed by the
display-manager when a x11 user session gets initialised.

During these configuration steps there are some notifications we want to
be displayed after the desktop is ready. Therefore we collect such
messages. The a script in /etc/xdg/autostart displays them after the
plasma session started as normal desktop notifications. Therefore the
script sends them through the DBus session bus via
org.freedesktop.Notifications. However on our development release those
messages get displayed as windows instead of the usual bubbles. It seems
that the notification handling is not ready when the autostarts are running.

When the user ends the session we also run code to synchronise the home
directory (upsync), umnount network shares etc. This works as expected
if the user does a simple logout. However if the user requests a
shutdown (reboot, poweroff) then the session and other user sessions are
killed and the computer shuts down. The KSMServer
(plasma-workspace/ksmserver/server.cpp, void KSMServer::cleanUp()) uses
a KDisplayManager (plasma-workspace/libkworkspace/kdisplaymanager.cpp)
which sends a "Reboot" or "PowerOff" through the system bus to logind.
This results in an immediate shutdown and neither our code nor parts of
the startkde script is executed.

Comments in kdisplaymanager.cpp state that there should be a policykit
dialog preventing a shutdown if other sessions are running, which is not
displayed in our case. But also without other sessions running, the
logout should finish in a clean way(wait for startkde to terminate).

We found out, that running a process with a systemd inhibitor as root e.g
> # systemd-inhibit --what=shutdown --mode=block sleep 365d
prevents the system from killing the session and a clean logout is
conducted. However in this case also the shutdown request is silently
ignored.

There are some questions we where not able to find answers by ourselves:

Is there a definition when xdg-autostart applications are started?

Is there a way to make sure that the session is ready to display
notifications?

It seems that sending dbus messages to logind in kdisplaymanager.cpp is
too early. Could this be a general issue? Should this not be the last
part of startkde?

Could this be a misconfiguration of policykit?

Could it be that the behaviour of logind changed recently?

It looks like there are currently some weak spots with plasma5 sessions.
We hope that we can work together to make the users session handling
more robust.



Max

Re: KDE and Google Summer of Code 2018

[Johnny Jazeix]

Hi,

on GCompris side, we hope/plan to mentor 2 students like last year. I
updated the page to add one more task.

Regarding the events: this year, we were planning to skip SoK to focus more
on GCi and GSoC, having the 3 events is too consuming and do not allow us
to progress on our main tasks. There was a bit of change due to the fact
that it was GCi that was skipped but the main point is still there, we
don't have enough time/resource to handle the 3 events.

Johnny


2018-01-15 1:39 GMT+01:00 Valorie Zimmerman :

> I'm very discouraged to see so little movement on this. After skipping GCi
> this past fall, are we now also considering skipping GSoC? Or downsizing
> the number of students we are mentoring?
>
> Without Ideas we will not get students. More important, we must complete
> the Org application soon, and the Ideas page is the core of that
> application.
>
> This is good for your team and your project, in the long run. It brings in
> new contributors and fresh ideas.
>
> If you need some guidance, please read https://google.github.io/
> gsocguides/mentor/defining-a-project-ideas-list.html
>
> I should have linked to it for the last email.
>
> Valorie
>
> On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
> valorie.zimmer...@gmail.com> wrote:
>
>>
>> Hello GSoC mentors, and teams supporting mentors,
>>
>> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
>> https://community.kde.org/GSoC. Now.
>>
>> Every year, we've asked for more time to get ramped up for GSoC, and so
>> now is the time for organizations to apply[1]. We have begun to write our
>> application, and  that means that our Ideas page needs to be filled NOW,
>> because that is the prime consideration for the GSoC team once the Org
>> Applications deadline has passed.
>>
>> The quality of our ideas and the guidance they give our students are the
>> most important part of our application. Please begin filling in your ideas
>> now if you have not already, and ensure that that page is comprehensive,
>> accurate and attractive. Including screenshots and other images is allowed,
>> if it enriches the idea for a project. *Please ensure complete information
>> about how to contact the team*; this is crucial.
>>
>> Also, take a look at the landing page https://community.kde.org/GSoC.
>> Experienced mentors agree that:
>>
>> 1. commits must be made before the student proposal is submitted, and
>> linked on that proposal, and
>>
>> 2. that regular communication from the student must be initiated by the
>> student at least weekly, and we expect daily or nearly daily communication
>> with the team in a more informal way.
>>
>> Be sure to point students to that information, as this should lower the
>> number of proposals, while raising the quality.
>>
>> 1. https://developers.google.com/open-source/gsoc/timeline
>>
>> PS: If your team has an Idea, ensure that you have mentors for it, and
>> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
>> without mentors available, please. Now, before you forget!
>>
>> Valorie
>>
>
>
> --
> http://about.me/valoriez
>

Re: KDE and Google Summer of Code 2018

[Valorie Zimmerman]

I'm very discouraged to see so little movement on this. After skipping GCi
this past fall, are we now also considering skipping GSoC? Or downsizing
the number of students we are mentoring?

Without Ideas we will not get students. More important, we must complete
the Org application soon, and the Ideas page is the core of that
application.

This is good for your team and your project, in the long run. It brings in
new contributors and fresh ideas.

If you need some guidance, please read
https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list.html

I should have linked to it for the last email.

Valorie

On Wed, Jan 10, 2018 at 3:03 PM, Valorie Zimmerman <
valorie.zimmer...@gmail.com> wrote:

>
> Hello GSoC mentors, and teams supporting mentors,
>
> TL;DR: Fill out https://community.kde.org/GSoC/2018/Ideas; read
> https://community.kde.org/GSoC. Now.
>
> Every year, we've asked for more time to get ramped up for GSoC, and so
> now is the time for organizations to apply[1]. We have begun to write our
> application, and  that means that our Ideas page needs to be filled NOW,
> because that is the prime consideration for the GSoC team once the Org
> Applications deadline has passed.
>
> The quality of our ideas and the guidance they give our students are the
> most important part of our application. Please begin filling in your ideas
> now if you have not already, and ensure that that page is comprehensive,
> accurate and attractive. Including screenshots and other images is allowed,
> if it enriches the idea for a project. *Please ensure complete information
> about how to contact the team*; this is crucial.
>
> Also, take a look at the landing page https://community.kde.org/GSoC.
> Experienced mentors agree that:
>
> 1. commits must be made before the student proposal is submitted, and
> linked on that proposal, and
>
> 2. that regular communication from the student must be initiated by the
> student at least weekly, and we expect daily or nearly daily communication
> with the team in a more informal way.
>
> Be sure to point students to that information, as this should lower the
> number of proposals, while raising the quality.
>
> 1. https://developers.google.com/open-source/gsoc/timeline
>
> PS: If your team has an Idea, ensure that you have mentors for it, and
> that those mentors are subscribe to KDE-Soc-Mentor list. Remove any ideas
> without mentors available, please. Now, before you forget!
>
> Valorie
>


-- 
http://about.me/valoriez

Re: New KDE application

[Thomas Baumgart]

Hi,

On Montag, 15. Januar 2018 13:00:13 CET Rahul Chowdhury wrote:

> On Mon, Jan 15, 2018 at 5:25 AM, Albert Astals Cid  wrote:
> > El dimecres, 10 de gener de 2018, a les 23:49:06 CET, Sayan Biswas va
> > 
> > escriure:
> >> Hi,
> > 
> > Hi
> 
> Hi,
> 
> >> A very happy new year to all. Hope you guys are doing good. :)
> >> 
> >> Me and Rahul (CC'ed; IRC nick - rahulch) came up with an idea for a
> >> new application in KDE, and we were hoping to get an opinion on it.
> >> 
> >> The central idea behind the app will be to manage the expenses of a
> >> group of users. As a user, you can create one or more groups, add
> >> members to them, and add entries for expenses for a given group. You
> >> can also check the outstanding balances and choose to settle-up with one
> >> or more members. There will be options for fine-tuning a given entry -
> >> decide who all have born the total expenditure and by what
> >> proportions, how should the total expense be divided among the members
> >> (equally/specific amounts/etc), add pictures for receipts, add
> >> comments, and so on and so forth.
> > 
> > So somthing like a Splitwise Free Software clone, have you checked if one
> > already exists? I know starting is half the fun, but maybe joining an
> > existing project that does something similar and help them build a
> > desktop application would also be nice.
> 
> Yes, the idea is very much similar to Splitwise. They do not have any
> desktop version yet.
> We wanted to have some similar free desktop application in KDE.
> 
> >> We are planning to start off with desktop application with a
> >> decentralised
> >> approach, i.e. the users will hold the data of the shared expenses. Now
> >> again, there is a possibility of tampering with the expenditure so we
> >> might
> >> need to set a centralised archived or something similar data set to
> >> maintain the integrity and persistence of a transaction. We are open to
> >> opinions and discussions for this also. Further to that we will be
> >> building
> >> mobile application for the users ease of usage and add expenditure on the
> >> go. After all, mobiles are more widely used by user than desktop
> >> application.
> >> 
> >> 
> >> For settling up we were thinking of integrating some standard payment
> >> gateways (PayPal, etc) but I am not sure of how much of this
> >> integration is possible in KDE.
> > 
> > I don't understand this question, just open a webview to paypal and be
> > done?
> Not just open a webview or redirect to some paypal webpage in a
> browser, but handle the entire transaction from the application itself
> with some third party integration like PayU. If we could integrate one
> or more such payment services/e-wallets with the application and
> handle the paments it would be great.

Do you know about the kde-finance-apps (developer) group? Maybe your 
application is something that fits in that area as well. See https://
community.kde.org/Alkimia for some ideas what is/can become part of a common 
code base.

Some of the functions you are looking for have already been developed as part 
of other applications (e.g. KMyMoney).


> >> Until then we can just maintain a
> >> transaction record indicating that members A and B have settled up. We
> >> were also considering developing a cryptocurrency (we could call it
> >> KCoin or something) that would serve as a means of payment. Opinions
> >> are welcome in this particular segment as possibilities can be immense.
> > 
> > There are 1432 cryptocurrencies around, why would you do yet another one?
> > 
> >> As for maintaining the ledgers, we wanted to implement it using
> >> blockchain, but again, I am not sure if it can be done in KDE, or if
> >> we have some libraries that support blockchain implementation, etc.
> > 
> > What do you exactly mean by "it can be done in KDE"?
> 
> Just wanted to know if the KDE frameworks/libraries currently support
> blockchain implementation, or we will need to develop such libraries
> first.
> This is not a top priority in my opinion right now. We can go ahead
> with a normal design and maintain a centralized database in the KDE
> servers. Once we have a working prototype we can come back and try to
> use blockchain in the app.
> 
> >> An application like this comes in handy when a group of people need to
> >> manage their regular expenses, and we thought it might be a good idea
> >> to have something similar in KDE. The target audience for this will be
> >> college groups, work groups, school groups, etc whoever is entitled to
> >> shared expenditure. We would love to get your feedback, mainly on the
> >> feasibility of the features mentioned above.
> > 
> > Sure those applications make sense as shown by the millions of free as in
> > beer version of them you can find in the mobile appstores, having a Free
> > one totally makes sense.
> > 
> > Cheers,
> > 
> >   Albert
> >> 
> >> Regards,
> >> Sayan
> 
> Regards,
> Rahul

-- 

Regards

Thomas Baumgart

https://www.teleg