[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    GSoC 2012 Ideas page: time to add those ideas!
From:       todd rme <toddrme2178 () gmail ! com>
Date:       2012-03-02 12:26:08
Message-ID: CADb7s=vf_-=9PMUQXSACmoxXMRS=VHU4xi6=NmhBXBn23hjEyA () mail ! gmail ! com
[Download RAW message or body]

On Thu, Mar 1, 2012 at 10:15 AM, Teo Mrnjavac <teo@kde.org> wrote:
> Hello!
>
> This is a friendly reminder that the GSoC mentoring organization
> application period closes in a week. I see that many of you have added
> lots of interesting ideas but there are still empty spots in that wiki
> page so I'm confident that we can do even better!
>
> If any of you still have ideas for this year's GSoC please add them to
> the wiki page [1] as soon as possible and before March 9.
>
> [1] http://community.kde.org/GSoC/2012/Ideas
>
> Cheers,
> --
> Teo

I have some ideas for potential projects if someone wants to mentor them:

1. Language bindings for kwin scripting and/or decoration scripting.
Currently only javascript is supported.  However, despite javascript
being the recommended language for scripted plasmoids, python is
actually thje most popular language for plasmiods (even more than
C++).  So it would seem that other languages are more popular amongst
small-time developers, so providing bindings in other languages would
probably increase the attractiveness of the scripting.

2. Rewrite existing effects using scripts.

3. Use effects scripting API for other non-kwin transitions.  Other
programs like calligra and okular need to support transition effects.
The idea here would be to have a specific type of kwin effect for page
(i.e. desktop or activity) effects that can also be used for page
transition effect in other programs like calligra and okular.  This
could be made more general, using the kwin api for other applications
for all sorts of animations.

4. Improved dialog box handling.  I heard someone saying that macs
have an effect where dialog boxes slid down from behind the toolbar,
tying them more closely to the window they originated from, and that
this might be good in KDE.  However, at least with oxygen the
toolbar/window distinction is not so great, and this effect doesn't
necessarily work well with non-modal dialogs.  So the purpose of this
project would be to analyze how the handling of such dialogs could be
handled in a manner appropriate to KDE and to implement it.

5. Activity handling effect.  The goal of this project would be to
provide a desktop-oriented full-screen activity manager interface.

-Todd
_______________________________________________
kwin mailing list
kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]