QBzr Main Window planing
Gary van der Merwe
agree with Alex about focusing on the qbzr main window, rather than say tortoise
bzr.
I would like to mention some ideas I have for the main window. I hope these will
kick of a discussion, and that we may reach a plan.
First - I think that we should rename the qbzr command to qmain, simply to avoid
confusion with qbzr the project. This will not visible to most users, as we will
have a menu item on the applications menu item on linux and the start menu on
windows to launch the main window.
At the moment, the main window is like a typical file browser. It has the
folders tree on the left, and the file list on the right. I think what we should
rather have is:
Left hand panel
===============
* The left hand panel, should be a list of branches. There are many different
things that we may do here, but the key is it is not a directory tree. Some of
the things that we may do are:
* You open and close branches, and and this is persisted between sessions.
This is the same as adding and removing bookmarks, but the open / colse
words may make the user more comfortable.
* May be a combination of open/close, and add/remove bookmarks, where
open/close is not persistant, and add/remove bookmarks is. Maybe
make it one list
* If you open/bookmark a shared repository, it can be expanded to show it's
branches
* We could have a way that you could add your launchpad project, expand that,
and see all the branches in that project. We would need it investage a way
to make it not to closely tied to launchpad.
* We could make it possible to open a scm-proj file.
* We could maybe record some metadata for branches to help devlopers track the
state of the branch, similar to the status of branches in launchpad.
In other words, we provide a way to manage ones branches.
Right hand panel
================
* The right hand panel will be a tab panel. I have 3 panels in mind. There
may be more.
* Info tab
* Working tree tab
* Log tab
Info tab
--------
* The info panel will show you:
* The format of the branch.
* The related locations, with relavant actions next to them. E.g.:
Location:
light checkout root: .
checkout of branch: /home/garyvdm/qbzr/trunk [Switch]
shared repository: /home/garyvdm/qbzr
Related branches:
push branch: lp:~garyvdm/qbzr/dev [Change] [Push]
parent branch: lp:qbzr [Change] [Pull] [Merge]
submit branch: lp:qbzr [Change] [Push] [Land#] [Send Merge Directive]
# Land is a command that was dicussed brefly at the sprint. It will be similar
to merge, but the left hand parent will the tip of the branch you are merging,
and not the tip of your own branch.
* A overview of the status working tree. I think we just want the number of
files changed/added/removed, and a diff button.
* Pitty graphs that make people ooooh. Maybe a spike line of commits. Pie
graph of committers etc. (Low priorty for devlopment) (May be a separate
tab)(Maybe re-use bzr-stats.)
Working tree tab
----------------
* The working tree tab will show the status of the working tree.
* We currently have a view in qbzr (the main window) where you can see the
status of the working tree. But you view one folder at a time, and you are
not really "linked" to a branch. I think that this should be more like
qbrowse where you are fixed on the root of the branch, and a folder can be
expanded to view the sub files and folders indented.
* The code for this, qbrowse, and the working tree widget overlap largely.
This should become 1 common widget.
Log tab
-------
Basicly have every thing from the qlog window in a tab.
Thoughts?
Gary van der Merwe
are interested in gui.
Alexander Belchenko
> After some poking from Alex, and discussion with Martin Pool and John Meinel, I
> agree with Alex about focusing on the qbzr main window, rather than say tortoise
> bzr.
>
> I would like to mention some ideas I have for the main window. I hope these will
> kick of a discussion, and that we may reach a plan.
>
> First - I think that we should rename the qbzr command to qmain, simply to avoid
> confusion with qbzr the project. This will not visible to most users, as we will
> have a menu item on the applications menu item on linux and the start menu on
> windows to launch the main window.
>
> At the moment, the main window is like a typical file browser. It has the
> folders tree on the left, and the file list on the right. I think what we should
> rather have is:
>
> Left hand panel
> ===============
[snip]
> In other words, we provide a way to manage ones branches.
>
> Right hand panel
> ================
> * The right hand panel will be a tab panel. I have 3 panels in mind. There
> may be more.
> * Info tab
> * Working tree tab
> * Log tab
[snip]
> Thoughts?
Thnaks for starting this discussion.
I like it in general. Perhaps we need to design some details more
carefully, but as overall plan -- I'm 100% agree. It's very fresh move:
to not dulicate Olive/Tortoise, but provide "branch management" tool.
Although, I think we can (and should) go further. Most of the time I'm
working with projects, not with plain branches. Project is more
complicated thing, usually it has many related branches, sometimes
several separate components in their own shared repositories. So I think
supporting plain branches and projects be great. May be projects support
won't be high priority, but definitely I'd like to work on it.
About other proposals:
1) rename qbzr command to qmain: I think we just need to create new
qmain command, and later deprecte/remove old qbzr application.
I think we'll need to provide standalone QBzr.exe application for
Windows (in their own installer, or maybe? as part of official
installer). Such application should be compiled as GUI application
(bzr.exe is compiled as console application, so running `bzr qmain` will
always create black console window behind GUI window).
2) Left hand panel: we can have it as 2 tabs panel: 1st tab is for plain
branches, 2nd tab is for projects.
For plain branches we probably need to use tree view with several nodes,
e.g. "Bookmarks", "Recent branches", "Local branches", "Remote
branches", etc. Maybe user can add its own category to group some
branches together.
For projects I'd like to suggest next UI: separate main menu item
"Project" to create/open project. For each project user can create tree
with folders and branch names for easy navigation.
E.g. my work with qbzr project could be as follows: I will add to
project all my development and release branches on local disk +
lightweight checkout which used to load qbzr plugin by bzr. Also I can
add launchpad branches of qbzr (to track them easily).
I like the git UI about managing branches in one repo: user can work
with all colocated branches in the repo, plus user can add remote
branches and track it. Such model looks nice.
But we can create our own "project model" and make it more suitable for
bzr idea "one directory - one branch".
3) Right hand panel: your proposal make big sense for me. I'd just add
some notes:
a) I think Working Tree tab should be first visible tab. For this tab
perhaps we'd like to get 2 view modes: full tree/list of all entries
(even unversioned), and short list of changed only items.
b) We need to think about treeless branches. In this case perhaps WT tab
should provide qbrowse view (of latest revision).
c) Log tab: perhaps log loading should be lazy?
d) Info tab: I agree with your proposal about buttons with actions.
Sounds interesting.
You wrote following in your description of Left hand panel:
"We could maybe record some metadata for branches to help devlopers
track the state of the branch, similar to the status of branches in
launchpad."
I think we should put such info into some additional "Status" widget
with some. Such widget present in current qbzr window as bottom
horizontal window. User can use it as "whiteboard" similar to LP
branches pages etc.
So...
As I said above, in general I like your plan. Perhaps we need to figure
out some technical details about operation available to user.
E.g. left hand panel should act not only as branch selector, but provide
ways to merge/clone/track other branches, IMO. Also will be nice to
create some "branch crawler" to find all branches on local disk (by user
request or as low priority additional process).