Re: New KDE application

2018-01-14 Thread Rahul Chowdhury
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.

>> 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


Re: Kamoso in KDE Applications

2018-01-14 Thread Aleix Pol
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)

>
> Also can you please get a build on https://build.kde.org/ going ?

Yes, just requested it.

Thanks!
Aleix


Re: New KDE application

2018-01-14 Thread Albert Astals Cid
El dimecres, 10 de gener de 2018, a les 23:49:06 CET, Sayan Biswas va 
escriure:
> 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.


> 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?

> 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"?

> 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




Re: Looking for mentor for new KDE developer

2018-01-14 Thread Valorie Zimmerman
Hi, adding kde-community as this is actually a community matter as well as
a -devel issue.

On Sun, Jan 7, 2018 at 3:15 PM, Albert Astals Cid  wrote:

> El dilluns, 8 de gener de 2018, a les 0:07:00 CET, Albert Astals Cid va
> escriure:
> > El dilluns, 8 de gener de 2018, a les 8:15:54 CET, Ben Cooksley va
> escriure:
> > > Hi all,
> > >
> > > Just following up on this - is there anyone who is looking into
> > > helping Christian here?
> >
> > I don't understand why we're forcing this "he needs a mentor". As Dominik
> > says, he seems to know stuff since he actually ported the code.
> >
> > If he needs help with "kde bureaucracy stuff" it means that we actually
> need
> > to improve our onboarding documentation, so instead of giving him someone
> > he can ask things in private, we should try to improve that
> documentation,
> > or at least answer the questions in this list so they are public and can
> be
> > referenced in the future.
>

So this new contributor would be a *perfect* person to point out kinks in
our onboarding documentation. For instance, that it is hard to find, where
it is incomplete or out-of-date. In line with our new push (
https://phabricator.kde.org/T7116) please Albert if you are going to
mentor, gently push for that while the pain is still fresh for our new
contributor.

All other mentors, formal or informal, please also help out here.
Old-timers already know some or all, so are not as helpful in finding those
pain-points. For those, beginners have the super-powers we need!


> > I will be happy to answer any question he may have related to that (and
> > hopèfully I know the question)
> >
> > Regarding the "In addition, translations would need to be imported into
> our
> > infrastructure, or recovered from our SVN history. That needs
> intervention
> > by our i18n experts, possibly before the code is imported." that Nicolás
> > mentioned, yes, that needs the i18n team helping, but that's what the
> kde-
> > i18n-doc mailing list is for, unless the mentor was part of the i18n team
> > that wouldn't get solved anyway.
>
> P.S: I guess that was my long way of saying "i can be his mentor if we
> really
> need to write someone elses name in the 'who to blame if he screws up'
> list".
>
> Cheers,
>   Albert
>
> >
> > Cheers,
> >   Albert
> >
> > > Thanks,
> > > Ben Cooksley
> > > KDE Sysadmin
>

Thank you for stepping up, Albert. <3

Valorie

-- 
http://about.me/valoriez


Re: Kamoso in KDE Applications

2018-01-14 Thread Albert Astals Cid
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 ?

Also can you please get a build on https://build.kde.org/ going ?

Cheers,
  Albert

> 
> Aleix




Re: Looking for mentor for new KDE developer

2018-01-14 Thread Nate Graham
We are still looking for a maintainer. Henrik Fehlauer is kindly helping 
Gwenview limp along--submitting many patches, and reviewing others. 
Peter Mühlenpfordt and I have also submitted a few patches. But it's 
mostly just maintenance work, not actual maintainership or technical 
leadership.


At this point Henrik seems like the natural candidate, but he's 
mentioned that he lacks the time. Maybe Blue Systems should hire him to 
do it... ;-)


Nate


On 01/14/2018 01:32 PM, Kai Bojens wrote:

Am 2018-01-04 15:35, schrieb Nate Graham:

Gwenview is similarly unmaintained and in need of a new maintainer, 
but already

using KF5 and more commonly used today.


Is there any ongoing discussion about its current development? The 
mailing list seems to be dead and the forum is filled with feature 
requests and user support.




Re: Looking for mentor for new KDE developer

2018-01-14 Thread Kai Bojens

Am 2018-01-04 15:35, schrieb Nate Graham:

Gwenview is similarly unmaintained and in need of a new maintainer, but 
already

using KF5 and more commonly used today.


Is there any ongoing discussion about its current development? The 
mailing list seems to be dead and the forum is filled with feature 
requests and user support.