Drop topics in here
- Goals for first release?
- Design decisions?
- Vertial/Horizontal layout
- Files in a dialog?
- How do we provide commit actions?
- Allow loading more than one repository?
- this would require quite a few changes in how things are handled now...
Gitg meeting, June 20th, 2013 Attendance Ignacio Casal Quintero, Jesse van den Kieboom, Paolo Borelli, Sindhu S, Techlive Zheng Architecture * Too many layers? * Actions: - keep libgit2-glib as a thin libgit2 wrapper - keep the current architecture for now, but be pragmatic about doing things in the core if it is easier - Consider moving the main activities (overview, history, commit) in the core and provide extension points for those "pages" - Document the architecture - Fix parallel build of the libs UI Design * gitg evolved away from Jesse's initial ideas * how to introduce features (commit, "branch" actions, etc) * Actions - do not radically change the current approach - focus on missing features for the release - design/prototype/discuss specific UI decisions (not enough time to get into detais in this meeting) - discuss some preliminary implementation infrastructure for branch actions - gather "previous art" for commit from the other git GUIs Release * define blocker features for next release * Outcome: - commit - all agree it is a blocker - branch actions - some of them are important, but not all blockers - blame - not a blocker, but Techlive Zheng wants to take a look - search - not a blocker Website * investigate a minimal webpage, mallard based? project.gnome.org? gitg.nl? * Reorganize wiki