Thread Previous • Date Previous • Date Next • Thread Next |
Am Donnerstag, den 10.11.2011, 19:48 +0100 schrieb Patrick Seemann: > 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 > > > Quickly is a very cool tool (ha, that rhymes ;)) I have used it before > to create a gtk app. But I've not yet played with the command line > template. I just found out that the lens template is not yet available. I have not used the cli template as well, but I think we should try to make use of it. > 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 assume we are discussing the features on this list. What about > documenting what we come up with? Should we create a wiki or something > like this? I'm really new to all this, so don't exactly know what > would be best. Yes, we should discuss features on the list. I would recommend using the launchpad blueprints for writing down the final specs. > 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 on the decentralized approach. Again, something which I've never > done before, so I have some questions ;) > Where do we keep the local branches? Does it local literally mean, > that we keep them only on our hard disk and once we are done with our > changes, we commit them to the main branch? Or do we keep them > somewhere on launchpad (probably in a branch related to our launchpad > account, e.g. ~launchpad_id/+junk/branchname)? We keep them on launchpad (~launchpad_id/unity-lens-contacts/branchname, branches will then be listed on the ulc code page. +junk is mainly for experiments that are not related to an existing project.) Once the code is ready to be included in trunk, one can create a merge request in launchpad. > > 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.) > > > I'm already working on the lens daemon... Unfortunately, I can't use > my old lens as a reference because they've changed the lens api a lot. > But there are enough python lenses on launchpad which are helpful. > What I'm still missing though, is a more detailed documentation on the > lenses api (for python)... The Ubuntu wiki only has vala > examples: https://wiki.ubuntu.com/Unity/Lenses (these are still > helpful sometimes). Great. Yes, the API changed a lot, but I hope it is set now. > These are my current suggestions. Feel free to speak out if > you disagree > or have different ideas. > > > Thanks again for your detailed emails!! I think you are making a very > good leader for this project ! Thank you. :-) Regards Frederik
Thread Previous • Date Previous • Date Next • Thread Next |