Size: 530
Comment: Initial status of File Manager Integration for Linux
|
Size: 5756
Comment: Add a diagram that show the relation between dialogs/windows
|
Deletions are marked like this. | Additions are marked like this. |
Line 5: | Line 5: |
The code: TDB. | Last milestone: Packages for Ubuntu/Debian. |
Line 7: | Line 7: |
Last milestone: Fixed Nautilus to support submenus properly in extensions. A new version with this bug fixed was released by June 30 (Nautilus 2.22.4). [http://bugzilla.gnome.org/show_bug.cgi?id=508878 The bug report], [http://bugzilla.gnome.org/attachment.cgi?id=112340 the test case] and [http://bugzilla.gnome.org/attachment.cgi?id=112370 the patch]. |
Current development: Polishing the UI and exploring the use of libglade. |
Line 10: | Line 9: |
Current development: Polishing the Nautilus extension. | == Current implementation == |
Line 12: | Line 11: |
== Roadmap == | === Source code === * Nautilus improvements (Fixed the Nautilus support for submenus used in extensions): * [http://bugzilla.gnome.org/show_bug.cgi?id=508878 The bug report] * [http://bugzilla.gnome.org/attachment.cgi?id=112340 the test case] * [http://bugzilla.gnome.org/attachment.cgi?id=112370 Patch for libnautilus-extensions] * A new version with this bug fixed was released by June 30 (Nautilus 2.22.4). * [http://www.calcifer.org/hg/tortoisehg/ TortoiseHG with my patches using Mercurial Queues] * You can get your copy through ''hg qclone http://www.calcifer.org/hg/tortoisehg/'' * You will find several guards (''hg qguard'' to see them), which is the way I divided the group of patches. * [http://www.calcifer.org/hg/tortoisehg-debian/ Debianization of TortoiseHG] === Ubuntu packages === There are packages available for Ubuntu at [https://launchpad.net/~gpoo/+archive Personal Package Archive]: * ''nautilus''. A fixed version with support for submenus working fine in extensions. * ''mercurial-tortoisehg''. A version to use hgtk from the shell. * ''nautilus-mercurial-tortoisehg''. A plugin for working It is possible to use those packages to build them for Debian or any other Debian based distribution. These packages have some caveats: * ''hgtk about'' doesn't work, because it has problems to load the COPYING.txt file. As a document file, it is stored compressed, in a different directory whic * Icons are not shown in Nautilus' menus. === Observations === Packages and distributions: * The paths used to load icons and files should not be hardcoded, because packages must be relocalatables. The same is applied for distutils (setup.py). * The hard part is the use of the environment variables TORTOISEHG_PATH and THG_ICON_PATH. Probably having a single file (__init__.py) could be helpful. Nautilus menus: * There is no order to load the menu items. * It doesn't matter the order the menuitems are created. * I thought it was sorted according the name of each menuitem, but using names such as 10foo, 20bar, ... neither seems to work. == Milestones == |
Line 15: | Line 51: |
== User Interface Improvements == From a technical point of view, it seems it is not clearity when a GtkDialog and/or a GtkWindow is used in TortoiseHG. Some of them are GtkDialog and some of them GtkWindow without any clear distinction. The following diagram shows the relation between dialogs/windows. There are two windows that can be invoked from the shell (''hgtk'') or from another window (''history''). Please note that ''history'' is also invoked from the shell (''hgtk log'') but for simplicity doesn't appear linked in the diagram. {{{#!dot digraph { node [shape=box]; graph [rankdir=LR]; hgtk -> synch; synch -> config; synch -> FileChooser; hgtk -> status; status -> "add dialog"; status -> "revert dialog"; hgtk -> clone; clone -> FileChooser; hgtk -> merge; merge -> browse; hgtk -> update -> browse; hgtk -> userconfig; userconfig -> config [style=dotted]; hgtk -> repoconfig; repoconfig -> config [style=dotted]; hgtk -> commit; commit -> "add dialog"; commit -> "revert dialog"; hgtk -> serve; serve -> config; hgtk -> recovery; hgtk -> datamine; hgtk -> about; history -> datamine; history -> display; history -> diff; history -> update; history -> export; export -> FileChooser [style=dotted]; history -> tag; history -> backout -> browse; history -> email; email -> config; history -> strip; } }}} Because both ''update'' and ''datamine'' can be invoked directly or indirectly from ''hgtk'' is needed to know how to close the dialog (hide it or destroy it) according the circunstances. === Cloning repositories === The following screenshot show the current user interface of ''hgtk clone'': attachment:current-hgtk-clone.png The usability may be improved just agruping common items and using proper buttons instead of a toolbar. The button 'X' in the upper right corner is reduntant, because the window managar provides such button and in a dialog a button 'Cancel' or 'Close' could give better feedback. attachment:new-hgtk-clone.png === Merging repositories === The same criteria as Cloning repositories may be applied in this dialog. The current one is: attachment:current-hgtk-merge.png and the proposal: attachment:new-hgtk-merge.png It worth noting that the former window has two different behaviors: merge and undo a merge. The button in the toolbar is activated/deactivated according to that. The same happen with the label "Merge with revision". It could be confusing having two dialogs in one. One possible change could be: attachment:new-hgtk-merge-unmerge.png === Updating repositories === attachment:current-hgtk-update.png attachment:new-hgtk-update.png === Selecting a changeset === The actions ''merge'' and ''update'' allows to select the changeset to be used, which may be choosen by the user filling the entry field or browsing the logs. The logging browsing is a common window: attachment:current-hgtk-log.png The data is the same shown as ''hgtk log'', but shorter. It would be nicer to share the same widget to choose the current. |
File Manager Integration for Linux (TortoiseHG)
Summary
Last milestone: Packages for Ubuntu/Debian.
Current development: Polishing the UI and exploring the use of libglade.
Current implementation
Source code
- Nautilus improvements (Fixed the Nautilus support for submenus used in extensions):
[http://bugzilla.gnome.org/show_bug.cgi?id=508878 The bug report]
[http://bugzilla.gnome.org/attachment.cgi?id=112340 the test case]
[http://bugzilla.gnome.org/attachment.cgi?id=112370 Patch for libnautilus-extensions]
- A new version with this bug fixed was released by June 30 (Nautilus 2.22.4).
[http://www.calcifer.org/hg/tortoisehg/ TortoiseHG with my patches using Mercurial Queues]
You can get your copy through hg qclone http://www.calcifer.org/hg/tortoisehg/
You will find several guards (hg qguard to see them), which is the way I divided the group of patches.
[http://www.calcifer.org/hg/tortoisehg-debian/ Debianization of TortoiseHG]
Ubuntu packages
There are packages available for Ubuntu at [https://launchpad.net/~gpoo/+archive Personal Package Archive]:
nautilus. A fixed version with support for submenus working fine in extensions.
mercurial-tortoisehg. A version to use hgtk from the shell.
nautilus-mercurial-tortoisehg. A plugin for working
It is possible to use those packages to build them for Debian or any other Debian based distribution.
These packages have some caveats:
hgtk about doesn't work, because it has problems to load the COPYING.txt file. As a document file, it is stored compressed, in a different directory whic
- Icons are not shown in Nautilus' menus.
Observations
Packages and distributions:
- The paths used to load icons and files should not be hardcoded, because packages must be relocalatables. The same is applied for distutils (setup.py).
The hard part is the use of the environment variables TORTOISEHG_PATH and THG_ICON_PATH. Probably having a single file (init.py) could be helpful.
Nautilus menus:
- There is no order to load the menu items.
- It doesn't matter the order the menuitems are created.
- I thought it was sorted according the name of each menuitem, but using names such as 10foo, 20bar, ... neither seems to work.
Milestones
TBD.
User Interface Improvements
From a technical point of view, it seems it is not clearity when a GtkDialog and/or a GtkWindow is used in TortoiseHG. Some of them are GtkDialog and some of them GtkWindow without any clear distinction.
The following diagram shows the relation between dialogs/windows. There are two windows that can be invoked from the shell (hgtk) or from another window (history). Please note that history is also invoked from the shell (hgtk log) but for simplicity doesn't appear linked in the diagram.
Because both update and datamine can be invoked directly or indirectly from hgtk is needed to know how to close the dialog (hide it or destroy it) according the circunstances.
Cloning repositories
The following screenshot show the current user interface of hgtk clone:
- attachment:current-hgtk-clone.png
The usability may be improved just agruping common items and using proper buttons instead of a toolbar. The button 'X' in the upper right corner is reduntant, because the window managar provides such button and in a dialog a button 'Cancel' or 'Close' could give better feedback.
- attachment:new-hgtk-clone.png
Merging repositories
The same criteria as Cloning repositories may be applied in this dialog. The current one is:
- attachment:current-hgtk-merge.png
and the proposal:
- attachment:new-hgtk-merge.png
It worth noting that the former window has two different behaviors: merge and undo a merge. The button in the toolbar is activated/deactivated according to that. The same happen with the label "Merge with revision".
It could be confusing having two dialogs in one. One possible change could be:
- attachment:new-hgtk-merge-unmerge.png
Updating repositories
- attachment:current-hgtk-update.png attachment:new-hgtk-update.png
Selecting a changeset
The actions merge and update allows to select the changeset to be used, which may be choosen by the user filling the entry field or browsing the logs. The logging browsing is a common window:
- attachment:current-hgtk-log.png
The data is the same shown as hgtk log, but shorter. It would be nicer to share the same widget to choose the current.