On Thu, Sep 10, 2009 at 1:50 AM, Peer Sommerlund <peer.sommerl...@gmail.com> wrote: > > > 2009/9/9 Steve Borho <st...@borho.org> >> >> On Wed, Sep 9, 2009 at 1:36 PM, Adrian Buehlmann<adr...@cadifra.com> >> wrote: >> > On 08.09.2009 06:10, Steve Borho wrote: >> >> I'm having seconds thoughts about holding menu bars for an 0.10 >> >> release. I'm thinking we could use them today to clean up a number of >> >> problems. >> >> >> >> * It would give us a standard place for 'View' menus that toggle >> >> displays >> >> * It would give us a standard place for online help >> >> * We could add a 'launch' menu for launching other tools in a >> >> standardized way >> >> * It could be leveraged in the future as a way to switch repositories. >> >> >> >> Initially I'm thinking we would only add menu bars for the gdialog >> >> based apps like status, commit, shelve, history, datamine. >> >> >> >> What do you all think about moving in this direction? >> >> >> > >> > Some ideas: >> > >> > If we have a menu bar, we might kill the synchronized >> > dialog and integrate it more into the history dialog. >> > >> > Incoming, Outgoing, Email and Shelve commands could then go >> > as menu items into a "Synchronize" menu of the history >> > dialog. >> > >> > Push and Pull might then be added as buttons to the >> > toolbar of the history dialog (or just go into the >> > "Synchronize" menu as well). >> > >> > We could then add a "sync bar" that can be hidden >> > (analogous to the filter bar), that contains the url >> > of the repo / bundle to sync with (as in the sync >> > dialog). >> > >> > I would then open a modal window, showing the command >> > log, as soon as the user triggers a sync (pull, push, >> > etc.) >> > >> > This would reduce the number of dialogs a bit. >> > >> > Like this, we could emphasize that history and >> > commit are the two most important dialogs. >> > >> > History is the one I open most often -- even if I >> > intend to do a pull or push, I almost always first open >> > the history dialog and then click synchronize there. >> > >> > I would even say that history is the top candidate >> > for the primary "TortoiseHg application", as this >> > is the one that provides you a view in your repo >> > (the repo is the "Document" -- like the file in your >> > editor). >> > >> > We might even go and add a "Repository" menu with >> > an "Open.." command, which would open a "file open >> > dialog", where the user can select a repository >> > root directory to open. >> >> I like the idea. We would definitely need a synchronize bar for the >> path and after-pull selections, but you're right the two features are >> tied together quite closely. I find myself opening hgtk log when I >> intend to do pushes and pulls. A combined changelog/synchronize >> dialog would probably deserve to be promoted to the top shell menu by >> default as well. That gives us 'top 2' dialogs. >> >> Commit - for working directory maintenance >> Changelog - for repository maintenance > > This sounds real good in my ears. > > I have privately speculated if the datamine dialog somehow could be merged > into the history dialog. > > >> >> Is there time for this in 0.9 (mid-October is the cut-off)? > > It sounds unlikely, but if somebody with an overview of all the code could > describe what steps would be needed, then it would be easier to coordinate > the effort. > > E.g. > > 1. add menu bar to all (some? just history&commit?) dialogs
This step is basically done for history and commit. I'm not convinced we need to add it to any of the other tools, but not really apposed to it either. > 2. Move syncronize dialog into menu of history dialog Not sure how this can be disconnected from #3, but you can launch synchronize from the history dialog's menu now. > 3. Add sync bar to history dialog The bulk of the work is giving hgcmd the same stdout capturing features as synch.py so it can capture hook output. Fiddly work, but will probably take a bit of time. The sync bar is probably pretty easy. Finding a place for the 'advanced' fields may be a challenge. > If these steps would not tear the application apart, then it would be > possible to release 0.9 between any of these steps. Perhaps. -- Steve Borho ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Tortoisehg-discuss mailing list Tortoisehg-discuss@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tortoisehg-discuss
