ulc-devs team mailing list archive
-
ulc-devs team
-
Mailing list archive
-
Message #00015
Re: Initial planning
On 9 November 2011 19:37, Frederik Elwert <frederik.elwert@xxxxxx> wrote:
> Hi all,
>
> thanks for your feedback regarding the language question.
>
> So let us now plan how to start the project. I will just write down some
> ideas, feel free to comment on them.
>
> initial source structure
> ------------------------
>
> I had very good experiences with quickly[1] in other projects. It takes
> away much of the pain of software development, especially the boring
> things like packaging, PPA uploading, and the like. I know there are
> plans to create a unity lens template for quickly, and I am just trying
> to find out if any steps in that direction were already made.
>
> If not, we could probably just use the cli template of quickly and adopt
> it to form an initial unity lens skeleton. If all works out, we should
> get packaging from the start, making it easy to install and uninstall
> our preliminary work. Many python projects can be run from their source
> directories, but for the lens to work we need to install some files. But
> I think once the base files are in place, we should be able to run the
> lens daemon from the source directory, so we can test our work without
> installing it.
>
> [1] https://launchpad.net/quickly
>
Nice idea, I've never used quickly but if you don't have enough free time I
can try and check it out.
>
> initial lens prototype
> ----------------------
>
> Once we have the code structure in place, we should built a basic lens.
> I think this could be achieved by re-implementing Pablo’s work. This
> would give us a starting point for our next iterations.
>
> blueprints
> ----------
>
> Before coding all details, we should probably make a round of design
> proposals and discussion. We need to decide on the categories and
> filters we want to support in the lens. We also need to decide on the
> actions we want to be able to perform on contacts. (For details on the
> lens architecture, see [2].)
>
> I think the basinc (and maybe even the only) action would be displaying
> the contact in GNOME Contacts. We should see if this works out, if we
> want to create our own contact display component, or if we want to work
> on G-C to make it suit our needs better.
>
I was on the idea of chating/sending email depending on the contact's
presence. But we can discuss that, maybe the gnome-contacts approach is
better (it's what gnome-shell does)
>
> [2] https://wiki.ubuntu.com/Unity/Lenses
>
> version control
> ---------------
>
> When using launchpad, bzr is set. bzr allows for a centralized
> (SVN-like) and a decentralized (git-like) approach. So we could either
> set up a group branch and commit all to it, or we could work on personal
> branches and merge them into master once they are ready for inclusion.
>
> I personally like the decentralized approach better. So I would suggest
> to create a team branch as trunk, but do the work on personal branches
> and merge them into trunk from time to time.
>
+1
>
>
> These are my preliminary ideas. I will try to create the initial source
> structure and upload it to a team branch. I have currently limited free
> time, so it might take a few days.
>
> Once the basic structure is in place, maybe someone with more
> experiences with lenses can start to implement a rudimentary lens.
> (Patrick, maybe that is a job for you, since you already wrote a python
> lens? Pablo might help you with libfolks.)
>
No problem, I can help on the coding too, if you can bear with my speed.
>
> These are my current suggestions. Feel free to speak out if you disagree
> or have different ideas.
>
> I also just registered #ulc-devs on freenode, so we might use that for
> exchange and help. (Since not everybody will be on the channel all the
> time, important decisions should still be discussed on the list.)
>
Great, I think it's a good idea to say which time zones we are in. I'm in
GMT-3
Regards.
Follow ups
References