Hello, Please file the application at the google site. (http://socghop.appspot.com) and we will review and get back to you with comments during the interim period. Remember that you have fill out the form at socghop before the 9th of April.
-- Tobias On Mon, Mar 29, 2010 at 1:32 PM, Sanjoy Das <san...@playingwithpointers.com>wrote: > > 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 > > -- _______________________________________________ Xmms2-devel mailing list Xmms2-devel@lists.xmms.se http://lists.xmms.se/cgi-bin/mailman/listinfo/xmms2-devel
