> Have you contacted an XMMS2 mentor (use IRC or soc2...@xmms.se) and discussed the project already?
Yes.
> Have you read and understood the rules and requirements?
Link Broken. I don't think there will be any clashes though! :)
> Just write a small introduction to yourself.
I'm a 20 year old guy who likes drinking coffee, listening to music and
writing code, not just because all these things rock but also because he
can do all of them at the same time. I use Vim and run StumpWM.
> State your preferred email address.
san...@playingwithpointers.com
> State your IRC nickname.
sanjoyd (or sanjoyd_ sometimes).
> What are you studying, subject, level and school?
I'm doing an integrated MS in Mathematics and Computing in the Indian
Institute of Technology, Kharagpur. I am in my second year now and I
will graduate in 2013.
> Have you developed software in a team environment before? (As opposed
to hacking on something on your own)
I've developed an application for the Google Android platform with
another developer working on the Ruby based back-end. Other than that,
no.
> Are you already involved with any open source development? If yes,
please describe the project and the scope of your involvement.
I've patched MonoDevelop and the Mono runtime. I'm currently working on
a QtScript based plugin framework (which I eventually plan to use to
implement the XMMS2 client).
> Have you participated to the Google Summer of Code before? As a mentor
or a student?
No.
> Describe what you consider your three main shortcomings (relevant to
GSoC) and how you cope with them.
1. I used to over-engineer at times. These days I tend to cancel this
out by applying the YAGNI principle as much as possible.
2. Though I've worked on a few small user facing applications
(http://github.com/sanjoy/Xants-Simulator-Log-Player-Qt4 for
instance), I'm not terribly experienced in designing user
interfaces. This is taken care of in two ways:
* My proposal proposal essentially revolves in providing an
infrastructure on which user interfaces may be written easily
and dynamically. While I will design a basic user interface, the
dynamic nature of the (proposed) infrastructure will ensure that
the UI can easily be changed or extended if need be.
* Notwithstanding the above point, I will read up extensively on
the best practices in UI design to bring myself up to speed
before the actual coding session starts.
3. I sometimes tend to get lost in the details - this directly
pertains from the perfectionism inherent in me. This can be
taken care of by me not losing track of the big picture and at least
semi-rigidly sticking to the timeline.
> Describe what you consider your three main strengths (relevant to
GSoC) and how they show in previous projects of yours.
While I don't like self-appraisal; mainly because I like my code to
speak for itself and also because I think it is difficult to list one's
strengths without going overboard, here is a list of three strengths I
thought would be relevant.
1. I learn fast - I had no idea of the QtScript module (and only a
little idea of Qt) till started working on Boom (the Qt plugin
project) and bootstrapped the project in a total work of eight
hours, complete with a QtTestLib (again something I had know
pre-knowledge of) test framework.
2. I write clean and well documented code - Though I am no one to judge
myself, I suggest you check out http://github.com/sanjoy/Boom and
decide for yourself.
3. I'm a good software architect - This is, again, evident from the
above link.
> Please describe the project and the scope.
I plan to create an ultimately extensible XMMS2 client which essentially
operates through QtScript based plugins. These plugins provide most of
the user-facing functionality the client has to offer.
The final deliverables shall look like the following:
i. The ability to connect to the Xmms2 server and perform all the
IPC using libxmmsclient++
ii. A very basic GUI with demarcations (possibly using QPanels) which
divide it into areas responsible for hosting various parts of
the application, like the Collection Browser, maybe the media
info, or maybe the player controls.
iii. Various extension points which plugins can hook onto. We provide
the GUI elements (like the QPanel, in the above case) as global
objects or arguments to the relevant plugins. Since the scripts
have access to the entire Qt library, the scripts may build up
the UI in whichever way they want. By segregating the UI elements
(say, by assigning one QCanvas to the visualization plugin and one
QPanel to the lyrics plugin), we can segregate the plugins in a
neat modular way. Possibly an infrastructure which allows auto
installation and updating of the plugins.
iv. A default set up consisting of basic, high quality plugins which
provide essential functionality and possibly a _little_ more.
> Why did you choose this project?
My interest writing and maintaining the official client specifically
comes from the 'scratching your own itch' idiom. Despite the
me finding Xmms2 a fantastic music player, I have not come around to
using it due to the lack of a decent client. I wish to change all that.
The whole inspiration behind writing a plugin based client is that while
it allows regular click-to-run users to stick to the defaults, it also
allows people like me, who like changing every little bit about how they
work _and_ how they play, to configure their ultimately extensible
client to be what they had only dreamt of.
> Include a timeline for your work on the project
I will work out a timeline as soon as all the details are finalized
(sometime in the 2 days).
> Include as much technical detail about your implementation as you can
The client shall loosely revolve around a plugin architecture I'm
currently developing called Boom. While a very basic, proof of concept,
version should be ready within 3 days, some of the more advanced stuff
in Boom (like automatic updating and installation of plugins etc.) will
be developed as a part of the GSoC.
Here is the 'docs/Architecture' file from http://github.com/sanjoy/Boom
"""""
ARCHITECTURE
Sanjoy Das <san...@playingwithpointers.com>
A lot of the core architectural idioms have been lifted from the
(awesome) Mono addin framework.
The entire plugin architecture revolves around the concept of extension
points. An extension point is a virtual path where a plugin 'hooks
onto'. Multiple plugins may register or hook onto the same the extension
point(s).
For instance, a path might be something like '/network/broadcaster' and
we might have two plugins 'LANBroadcaster' and 'HTTPBroadcaster' hooked
onto the same extension point. The core application may, then, query the
plugin framework and figure out the plugins registered onto the specific
extension point. It is then up to the core to decide what kind of
services it wishes to extract from each of the plugins and whether to
use them at all.
The plugins are essentially ECMA Scripts which have the entire Qt
library available to them. Furthermore, the application may make some
additional API available to it by creating QObjects and adding them to
the globals.
The Qt API shall be make available to the plugins using
qtscriptgenerator, a Qt Labs project
(http://qt.gitorious.org/qt-labs/qtscriptgenerator).
To allow true extensibility, one to-be-conceptualized feature is to
allow plugins to have their own extension points.
This is very much a work in progress and as such these specification are
to change from time to time.
"""""
So, for instance, in the client application, we might have an extension
point named '/xmms2/visualization' where all the visualization plugins
hook onto. We provide a global object named 'visualizationWindow' and
plugins do something like the following in their initializing function:
function initialize () {
visualizationWindow.reDraw.connect (function (canvas) {
// ...
canvas.drawLine ( ... );
// ...
}
}
Please have a look at Architecture.png (attached) for a visual
representation.
> What do you expect to gain from this project?
The awesome feeling one gets when he sees someone using his software and
points out that he helped make it possible. The more awesome feeling one
gets when himself using software he wrote.
> What would make you stay in the xmms2-community after the conclusion
of SOC?
Essentially maintaining the developed client, both by writing new
plugins, maintaining old ones, keeping the code in sync with Qt. The
above point still applies.
> Are you familiar with any of the following tools?
+ git
Yes, my preferred version control system.
+ waf
Enough to compile XMMS2. Unless it is a major problem, I plan to
use qmake.
> Which tools do you normally use for development? Why do you use them?
Vim / GCC / GDB. I work on a Debian (Testing) amd64 system. In case
testing in M$ windows becomes necessary, I've a Virtual installation of
the same.
> What development model would you use?
I generally practice defensive programming. I first bootstrap the
project by writing a few core modules and then I immediately write unit
tests for the same. Then I keep iterating over this again and again. I
also tend to use a lot ASSERT macros - especially where I'm making
(seemingly obvious) assumptions - I like getting a clean abort rather
than a dirty segfault.
> What programming languages are you fluent in?
C, C++, Java, C#. I know enough python for most purposes, though I will
not call myself fluent.
> What spoken languages are you fluent in?
English, Hindi, Bengali.
> At what hours are you awake (please specify in UTC)
0530 hours to 2130 hours generally. This won't be a problem during the
actual GSoC session - I can shift as required.
> Would you mind talking with your mentor on telephone / internet
phone?
No.
> Will you be available full summer, or do you still have
lectures/exams/whatever when GSoC starts?
No.
> Are you planning on some vacation (when you won't be coding on GSoC
project) during the summer?
No vacation as such. I might have to take a day or two off if I travel
back home - but such a gap will occur only twice (at most four days of
no work) and I will inform well in advance.
--
Regards,
Sanjoy Das
http://playingwithpointers.com
http://playingwithpointers.com/custom/public_key.txt
signature.asc
Description: This is a digitally signed message part
-- _______________________________________________ Xmms2-devel mailing list Xmms2-devel@lists.xmms.se http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
