Looking for mentor of Kopete in GSoC-2018

[Himanshu Vishwakarma]

Hi Everyone,

I am looking for a mentor for the project "Write tests and Improve protocol
support" for the kopete.

I am already working on the project, this SoK and further want to continue
the project in GSoC also, but due to the absence of the mentor, it is
currently in dilemma. My current mentor in SoK is not going to mentor me in
GSoC.

It is a good opportunity for me to take the development of Kopete
application forward.

The major task which is going to do in the GSoC-2018 are following:


   - Write the test of all the important class of the libkopete like
   KopetePluginManager, ManagedConnectionAccount, FileTransferInfo,
   ConnectionManager and many others. and also need the test of protocol
   classes like the Jabber protocol, Gadu protocol, and others.
   - Improve the protocol support. Remove outdated technology from the
   protocol and implement the some new like, replace the OTR with the OMEMO.
   Old protocol needed to remove, like AIM protocol. some more protocol neede
   to improvement like the skype need the plugin.
   - Resolve the issue of the connecting problem in the login account and
   restarting the application and some other bugs are in the kopete.
   - Improvement in the workflow of the application and make it easier to
   use.
   - Kopete application needed a good documentation. Present documentation
   is very old it needed some improvement.


Can anyone mentor me this GSoC?

Important link to work is done in Kopete during the season of KDE(SoK) are
follows:
Link to Project Idea: here

Link to blog: here

Link to weekly Status Reports:
​​
here 
Link to Kopete Repository: here 

-- 
Regards,
Himanshu Vishwakarma

Re: Latte Dock and tangerine font

[Nate Graham]

Maybe create a Phabricator task and see which VDG people show up? Andres 
Betts was the primary creator of Falkon's logo; he's really great with 
that sort of thing.


Nate


On 02/27/2018 05:43 PM, Valorie Zimmerman wrote:

This discussion is icky to me.

1. I do not want to login to Github to discuss a KDE project

2. We are not engaging with the authors and maintainer to make this 
application fully within the KDE community (which includes licensing)


3. The discussion is about licensing instead of helping to improve the 
logo by bringing in the VDG. The VDG just created a kickass logo for 
Falkon; surely they can make something better than the Latte Dock 
present logo?


Valorie

On Tue, Feb 27, 2018 at 6:45 AM, Michail Vourlakos > wrote:


Jonathan can you please participate at:
https://github.com/psifidotos/Latte-Dock/issues/884#issuecomment-368876977


for this?

the ubuntu member I think responded there...

2018-02-27 14:52 GMT+02:00 Jonathan Riddell mailto:j...@jriddell.org>>:

On 27 February 2018 at 09:24, Michail Vourlakos
mailto:mvourla...@gmail.com>> wrote:
> Today I received from RikMills that Latte was rejected from ubuntu 
because
> it contains an OPL-licensed font (tangerine).
>
> The discussion is at: 
https://github.com/psifidotos/Latte-Dock/issues/884

>
> The font is used just for a label in the configuration window to draw 
the
> "Latte"  text at the top-left corner. I thought that an alternative 
could be
> to just screenshot the label in a png and use that one and drop 
totally the
> tangerine font distrubution through Latte code...
>
> Do you have any ideas what we can do for this and if this is 
acceptable for
> OPL?

Font licencing is a bit of a quagmire but I really don't see any
issue here.

The font is freely licenced and .ttf can be considered preferred
modifiable form so there's no freedom issue.

He says "Source embeds and uses at runtime a GPL-incompatible
(OPL-Licensed) font; "  but I see no embedding happening, it just
ships the file which doesn't make it a derived work.  Loading a font
file at runtime is done by every GUI program very often, it doesn't
make it a derived work so there's no effect on copyleft licencing
requirements.

I recommend Ubuntu discuss this with their archive admins to see why
they consider it a derived work.  I am an Ubuntu archive admin
and can
take part in that conversation if wanted.  If that doesn't get
anywhere then play a political workaround and just upload it without
the .ttf font, I presume the text where it's used will just fall
back
to some other font.  Maybe Latte-dock code can be changed to
explicitly fall back to a generic cursive font if it doesn't find it
but only if there's a desire to go out of the way for incorrectly
applied rules.

Jonathan





--
http://about.me/valoriez

Re: Latte Dock and tangerine font

[Valorie Zimmerman]

This discussion is icky to me.

1. I do not want to login to Github to discuss a KDE project

2. We are not engaging with the authors and maintainer to make this
application fully within the KDE community (which includes licensing)

3. The discussion is about licensing instead of helping to improve the logo
by bringing in the VDG. The VDG just created a kickass logo for Falkon;
surely they can make something better than the Latte Dock present logo?

Valorie

On Tue, Feb 27, 2018 at 6:45 AM, Michail Vourlakos 
wrote:

> Jonathan can you please participate at:
> https://github.com/psifidotos/Latte-Dock/issues/884#issuecomment-368876977
>
> for this?
>
> the ubuntu member I think responded there...
>
> 2018-02-27 14:52 GMT+02:00 Jonathan Riddell :
>
>> On 27 February 2018 at 09:24, Michail Vourlakos 
>> wrote:
>> > Today I received from RikMills that Latte was rejected from ubuntu
>> because
>> > it contains an OPL-licensed font (tangerine).
>> >
>> > The discussion is at: https://github.com/psifidotos/
>> Latte-Dock/issues/884
>> >
>> > The font is used just for a label in the configuration window to draw
>> the
>> > "Latte"  text at the top-left corner. I thought that an alternative
>> could be
>> > to just screenshot the label in a png and use that one and drop totally
>> the
>> > tangerine font distrubution through Latte code...
>> >
>> > Do you have any ideas what we can do for this and if this is acceptable
>> for
>> > OPL?
>>
>> Font licencing is a bit of a quagmire but I really don't see any issue
>> here.
>>
>> The font is freely licenced and .ttf can be considered preferred
>> modifiable form so there's no freedom issue.
>>
>> He says "Source embeds and uses at runtime a GPL-incompatible
>> (OPL-Licensed) font; "  but I see no embedding happening, it just
>> ships the file which doesn't make it a derived work.  Loading a font
>> file at runtime is done by every GUI program very often, it doesn't
>> make it a derived work so there's no effect on copyleft licencing
>> requirements.
>>
>> I recommend Ubuntu discuss this with their archive admins to see why
>> they consider it a derived work.  I am an Ubuntu archive admin and can
>> take part in that conversation if wanted.  If that doesn't get
>> anywhere then play a political workaround and just upload it without
>> the .ttf font, I presume the text where it's used will just fall back
>> to some other font.  Maybe Latte-dock code can be changed to
>> explicitly fall back to a generic cursive font if it doesn't find it
>> but only if there's a desire to go out of the way for incorrectly
>> applied rules.
>>
>> Jonathan
>>
>
>


-- 
http://about.me/valoriez

[ANNOUNCE] CMake 3.11.0-rc2 is now ready for testing

[Robert Maynard]

I am proud to announce the second CMake 3.11 release candidate.
  https://cmake.org/download/

Documentation is available at:
  https://cmake.org/cmake/help/v3.11

Release notes appear below and are also published at
  https://cmake.org/cmake/help/v3.11/release/3.11.html

Some of the more significant changes in CMake 3.11 are:

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" Generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.

* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.

* The "COMPILE_DEFINITIONS" source file property learned to support
  "generator expressions".

* A "COMPILE_OPTIONS" source file property was added to manage list
  of options to pass to the compiler.

* When using "AUTOMOC" or "AUTOUIC", CMake now starts multiple
  parallel "moc" or "uic" processes to reduce the build time. A new
  "CMAKE_AUTOGEN_PARALLEL" variable and "AUTOGEN_PARALLEL" target
  property may be set to specify the number of parallel "moc" or "uic"
  processes to start.  The default is derived from the number of CPUs
  on the host.


CMake 3.11 Release Notes


Changes made since CMake 3.10 include the following.


New Features



Platforms
-

* TI C/C++ compilers are now supported by the "Ninja" generator.


Generators
--

* The "CodeBlocks" extra generator learned to check a
  "CMAKE_CODEBLOCKS_COMPILER_ID" variable for a custom compiler
  identification value to place in the project file.

* The Makefile Generators and the "Ninja" generator learned to add
  compiler launcher tools along with the compiler for the "Fortran"
  language ("C", "CXX", and "CUDA" were supported previously). See the
  "CMAKE__COMPILER_LAUNCHER" variable and
  "_COMPILER_LAUNCHER" target property for details.

* Visual Studio Generators learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS",
  "INCLUDE_DIRECTORIES", "COMPILE_OPTIONS", and "file(GENERATE)".  See
  generator expression documentation for caveats.

* The "Xcode" generator learned to support the "COMPILE_LANGUAGE"
  "generator expression" in target-wide "COMPILE_DEFINITIONS" and
  "INCLUDE_DIRECTORIES".  It previously supported only
  "COMPILE_OPTIONS" and "file(GENERATE)". See generator expression
  documentation for caveats.


Commands


* "add_library()" and "add_executable()" commands can now be called
  without any sources and will not complain as long as sources are
  added later via the "target_sources()" command.

* The "file(DOWNLOAD)" and "file(UPLOAD)" commands gained "NETRC"
  and "NETRC_FILE" options to specify use of a ".netrc" file.

* The "target_compile_definitions()" command learned to set the
  "INTERFACE_COMPILE_DEFINITIONS" property on Imported Targets.

* The "target_compile_features()" command learned to set the
  "INTERFACE_COMPILE_FEATURES" property on Imported Targets.

* The "target_compile_options()" command learned to set the
  "INTERFACE_COMPILE_OPTIONS" property on Imported Targets.

* The "target_include_directories()" command learned to set the
  "INTERFACE_INCLUDE_DIRECTORIES" property on Imported Targets.

* The "target_sources()" command learned to set the
  "INTERFACE_SOURCES" property on Imported Targets.

* The "target_link_libraries()" command learned to set the
  "INTERFACE_LINK_LIBRARIES" property on Imported Targets.


Variables
-

* A "CMAKE_GENERATOR_

Re: Latte Dock and tangerine font

[Michail Vourlakos]

Jonathan can you please participate at:
https://github.com/psifidotos/Latte-Dock/issues/884#issuecomment-368876977

for this?

the ubuntu member I think responded there...

2018-02-27 14:52 GMT+02:00 Jonathan Riddell :

> On 27 February 2018 at 09:24, Michail Vourlakos 
> wrote:
> > Today I received from RikMills that Latte was rejected from ubuntu
> because
> > it contains an OPL-licensed font (tangerine).
> >
> > The discussion is at: https://github.com/psifidotos/
> Latte-Dock/issues/884
> >
> > The font is used just for a label in the configuration window to draw the
> > "Latte"  text at the top-left corner. I thought that an alternative
> could be
> > to just screenshot the label in a png and use that one and drop totally
> the
> > tangerine font distrubution through Latte code...
> >
> > Do you have any ideas what we can do for this and if this is acceptable
> for
> > OPL?
>
> Font licencing is a bit of a quagmire but I really don't see any issue
> here.
>
> The font is freely licenced and .ttf can be considered preferred
> modifiable form so there's no freedom issue.
>
> He says "Source embeds and uses at runtime a GPL-incompatible
> (OPL-Licensed) font; "  but I see no embedding happening, it just
> ships the file which doesn't make it a derived work.  Loading a font
> file at runtime is done by every GUI program very often, it doesn't
> make it a derived work so there's no effect on copyleft licencing
> requirements.
>
> I recommend Ubuntu discuss this with their archive admins to see why
> they consider it a derived work.  I am an Ubuntu archive admin and can
> take part in that conversation if wanted.  If that doesn't get
> anywhere then play a political workaround and just upload it without
> the .ttf font, I presume the text where it's used will just fall back
> to some other font.  Maybe Latte-dock code can be changed to
> explicitly fall back to a generic cursive font if it doesn't find it
> but only if there's a desire to go out of the way for incorrectly
> applied rules.
>
> Jonathan
>

Re: Latte Dock and tangerine font

[Jonathan Riddell]

On 27 February 2018 at 09:24, Michail Vourlakos  wrote:
> Today I received from RikMills that Latte was rejected from ubuntu because
> it contains an OPL-licensed font (tangerine).
>
> The discussion is at: https://github.com/psifidotos/Latte-Dock/issues/884
>
> The font is used just for a label in the configuration window to draw the
> "Latte"  text at the top-left corner. I thought that an alternative could be
> to just screenshot the label in a png and use that one and drop totally the
> tangerine font distrubution through Latte code...
>
> Do you have any ideas what we can do for this and if this is acceptable for
> OPL?

Font licencing is a bit of a quagmire but I really don't see any issue here.

The font is freely licenced and .ttf can be considered preferred
modifiable form so there's no freedom issue.

He says "Source embeds and uses at runtime a GPL-incompatible
(OPL-Licensed) font; "  but I see no embedding happening, it just
ships the file which doesn't make it a derived work.  Loading a font
file at runtime is done by every GUI program very often, it doesn't
make it a derived work so there's no effect on copyleft licencing
requirements.

I recommend Ubuntu discuss this with their archive admins to see why
they consider it a derived work.  I am an Ubuntu archive admin and can
take part in that conversation if wanted.  If that doesn't get
anywhere then play a political workaround and just upload it without
the .ttf font, I presume the text where it's used will just fall back
to some other font.  Maybe Latte-dock code can be changed to
explicitly fall back to a generic cursive font if it doesn't find it
but only if there's a desire to go out of the way for incorrectly
applied rules.

Jonathan

Latte Dock and tangerine font

[Michail Vourlakos]

Today I received from RikMills that Latte was rejected from ubuntu because
it contains an OPL-licensed font (tangerine).

The discussion is at: https://github.com/psifidotos/Latte-Dock/issues/884

The font is used just for a label in the configuration window to draw the
"Latte"  text at the top-left corner. I thought that an alternative could
be to just screenshot the label in a png and use that one and drop totally
the tangerine font distrubution through Latte code...

Do you have any ideas what we can do for this and if this is acceptable for
OPL?

regards,
michail