Thanks for the tips!
Re: configuration import/export. At the start I envisioned it only for
lock-down settings not to override other existing user settings, but
this might as well be used as a full configuration importer/exporter.
Re: note from Stefan Skoglund about documentation – point taken. I
understand the importance of documentation, but haven't coded in
documentation driven development model before.
I think I could try to patch gnome-shell to disable workspaces and/or
disable overview mode – this could be useful for a single application
(kiosk) environment, where the top panel should be visible (time, volume
and accessibility controls are required). Should this be done until
Friday?
Updated work schedule:
1) Understand the target audience (May 1)
2) Gather requirements (May 5)
2.1) Look into Pessulus features
2.2) Read Pessulus feature requests
2.3) Ask users for user input
D0) List of desired features (May 30)
D1) Mock-up of the software, no functionality (June 10)
3) Start implementing functionality for lock-down editor (June 10)
4) Check if applications support the required lockdown features(June 20)
4.1) If not, negotiate implementation with the developers
D2) List of results (application support status for each feature)
(June 30)
D3) First functional lock-down options (Mid-term deliverable in July 10)
5) Write patches for other software if needed functionality is lacking
(July 10)
Note: going to GUADEC and persuading other programmers to implement last
missing lockdown features (July 26 – August 1)
D4) Full lock-down functionality (August 1)
6) Write basic configuration import/export (August 1)
7) Polish the lock-down editor (i18n, finish documentation and such)
(August 1)
D5) Program ready for use (August 13)
8) [post GSoC feature] Make a configuration server and implement
configuration fetching from a URL
Finally, a quick and dirty mockup in the attachment.
P , 2012-04-02 15:23 +0200, Vincent Untz rakstīja:
> Le dimanche 01 avril 2012, à 23:46 +0300, Rūdolfs Mazurs a écrit :
> > 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?
>
> Fixing a bug in the current pessulus is kind of useless, imho. But there
> are a few options:
>
> - write some small code snippets showing things that will be needed in
> the lockdown editor.
>
> - patch apps to make sure they respect the lockdown settings.
> Obviously, you need to find an app not respecting the settings
> first; just change an lockdown setting and check if it's respected by
> the apps on your desktop.
>
> > Also, this is my draft of proposal (D means deliverable):
>
> First comment: there's no timeline in what you propose :-) Even if you
> don't have a good idea right now of what it will be, it's important to
> be able to show good progress at mid-term, for instance. And we can give
> feedback on whether your timeline is reasonable or not.
>
> > 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)
>
> I would actually do this after your next step (swap 3 and 4).
>
> > 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
>
> I'm not completely sure what you mean with this. Is this the full
> configuration? Or "just" lockdown? Why should it live in the lockdown
> editor?
>
> > 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?
>
> Cheers,
>
> Vincent
>
Attachment:
UI 1. draft.png
Description: PNG image
