Hello, and thanks for pointers. The information for students is lacking in the sense, that this is a new software, therefore fixing existing bugs or contributing to existing modules is problematic. Should I write something for the pessulus as it is, make some dummy application or contribute something to another project?
Also, this is my draft of proposal (D means deliverable): 1) Understand the target audience 2) Gather requirements 2.1) Look into Pessulus features 2.2) Read Pessulus feature requests 2.3) Ask user for user input D0) List of desired features D1) Mock-up of the software, no functionality 3) Check if applications support the required lock-down features 3.1) If not, negotiate implementation with the developers D2) List of results (application support status for each feature) 4) Start implementing functionality for lock-down editor D3) First functional lock-down options 5) Write patches for other software if needed functionality is lacking D4) Full lock-down functionality 6) Write basic configuration import/export 7) Polish the lock-down editor (i18n, basic documentation and such) D5) Program ready for use 8) [optional] Make a configuration server and implement configuration fetching from a URL 9) Plan for expanding configuration delivery It omits any time spent learning GNOME development technologies and I am not sure about schedule. Is there anything to add? -- Rūdolfs Mazurs P , 2012-03-26 14:59 +0200, Vincent Untz rakstīja: > Hi, > > Le dimanche 25 mars 2012, à 19:44 +0300, Rūdolfs Mazurs a écrit : > > Hello all! > > > > In the list of ideas for this year's Google Summer of Code I found the > > suggestion to make a lockdown editor for GNOME 3. I thought I could try > > that. > > > > I have academic experience in writing C code and have done some Python > > as well. I haven't written any GTK applications so far, but I think I > > can learn it quickly enough. I have been using GNOME for 5 years now and > > have administered an Ubuntu classroom, so I believe I can understand the > > needs of the end user and system administrator. > > > > What I'd like to find out: > > * What is the required functionality of the lockdown editor? > > The basic features that we want is being able to lock down features that > are already ready to be locked down. See for instance: > http://git.gnome.org/browse/gsettings-desktop-schemas/tree/schemas/org.gnome.desktop.lockdown.gschema.xml.in.in > > You can run pessulus to get an idea of how this was working for GNOME 2. > > Compared to the current code in pessulus, the following needs to be > done: > > - handle GSettings settings too, not just gconf > Note that lockdown is GSettings is actually handled by dconf, see > https://live.gnome.org/dconf/SystemAdministrators > > - this first point likely involves writing a small polkit helper to > actually configure the lockdown. As an example, see what was used for > gconf: > http://git.gnome.org/browse/gconf/tree/defaults > > - use pygobject with introspection for the GUI, instead of pygtk > > There are optional additional steps, related to making sure lockdown is > properly handled by apps, or adding some additional lockdown features to > GNOME. > > > * What do I need to do to get this GSoC task? > > We documented this on the wiki: > https://live.gnome.org/SummerOfCode2012/Students > > Cheers, > > Vincent > _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/desktop-devel-list