[CHEETAH PATCH 1/7] explorer: copy submenu->last from parent

42 views
Skip to first unread message

Erik Faye-Lund

unread,
Jul 19, 2010, 9:58:21 AM7/19/10
to msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
Like with submenu->first, we need to copy submenu->last from
the parent menu or there'll be a matter of chance if a submenu
element gets created or not.

This but dates back to commit 3e195d3b, and looks like a simple
slip-up.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---
explorer/menu.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/explorer/menu.c b/explorer/menu.c
index a4df461..aa3d0af 100644
--- a/explorer/menu.c
+++ b/explorer/menu.c
@@ -82,6 +82,7 @@ void *start_submenu(struct git_data *this_, const struct menu_item *item,

submenu->index = 0;
submenu->first = parent_menu->first;
+ submenu->last = parent_menu->last;

return submenu;
}
--
1.7.1.msysgit.0.387.g185df

Erik Faye-Lund

unread,
Jul 19, 2010, 9:58:22 AM7/19/10
to msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
The item_callback-member wasn't strictly speaking unused,
but it was always set to the same value.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---

nautilus/menu.c | 12 +++---------
nautilus/plugin.h | 3 ---
2 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/nautilus/menu.c b/nautilus/menu.c
index 57f236d..54add7a 100644
--- a/nautilus/menu.c
+++ b/nautilus/menu.c
@@ -50,7 +50,7 @@ BOOL build_item(struct git_data *me, const struct menu_item *item,
item->helptext,
NULL /* icon name */);
g_signal_connect(one_menu_item, "activate",
- nautilus_data->item_callback, nautilus_data->provider);
+ G_CALLBACK(invoke_command), nautilus_data->provider);

g_object_set_data((GObject *) one_menu_item, "git_extension_id",
(void *) nautilus_data->item_id);
@@ -131,11 +131,8 @@ GList *git_extension_get_file_items(NautilusMenuProvider *provider,

struct nautilus_menu_data nautilus_data = {
provider,
- window,
NULL,
- G_CALLBACK(invoke_command),
- 0,
- &git_data
+ 0
};


@@ -165,11 +162,8 @@ GList *git_extension_get_background_items(NautilusMenuProvider *provider,

struct nautilus_menu_data nautilus_data = {
provider,
- window,
NULL,
- G_CALLBACK(invoke_command),
- 0,
- &git_data
+ 0
};

git_data.name[0] = '\0';
diff --git a/nautilus/plugin.h b/nautilus/plugin.h
index d7d9c1a..01b766a 100644
--- a/nautilus/plugin.h
+++ b/nautilus/plugin.h
@@ -19,11 +19,8 @@

struct nautilus_menu_data {
NautilusMenuProvider *provider;
- GtkWidget *window;
GList *menu_items;
- GCallback item_callback;
int item_id;
- struct git_data *git_data;
};

#endif /* NAUTILUS_PLUGIN_H */
--
1.7.1.msysgit.0.387.g185df

Erik Faye-Lund

unread,
Jul 19, 2010, 9:58:23 AM7/19/10
to msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
The menu engine already expose a variable representing the next
item identifier. Use that one instead.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---

nautilus/menu.c | 25 +++++--------------------
nautilus/plugin.h | 1 -
2 files changed, 5 insertions(+), 21 deletions(-)

diff --git a/nautilus/menu.c b/nautilus/menu.c
index 54add7a..a18e86b 100644
--- a/nautilus/menu.c
+++ b/nautilus/menu.c
@@ -25,17 +25,9 @@ BOOL build_item(struct git_data *me, const struct menu_item *item,
char item_reference_string[1024];
NautilusMenuItem *one_menu_item;
struct nautilus_menu_data *nautilus_data = platform;
- static int not_shown_offset = 0;

- if (!platform) {
- not_shown_offset++;
+ if (!platform)
return TRUE;
- }
-
- if (not_shown_offset) {
- nautilus_data->item_id += not_shown_offset;
- not_shown_offset = 0;
- }

item_name = strdup(item->string);

@@ -53,16 +45,13 @@ BOOL build_item(struct git_data *me, const struct menu_item *item,


G_CALLBACK(invoke_command), nautilus_data->provider);

g_object_set_data((GObject *) one_menu_item, "git_extension_id",

- (void *) nautilus_data->item_id);
+ (void *)next_active_item);
g_object_set_data((GObject *) one_menu_item,
"git_extension_git_data", me);

nautilus_data->menu_items = g_list_append(nautilus_data->menu_items,
one_menu_item);

- /* this needs to be uniqe for each item */
- nautilus_data->item_id++;
-
free(item_name);
return TRUE;
}
@@ -71,9 +60,7 @@ BOOL build_separator(struct git_data *me, const struct menu_item *item,
void *platform)
{
/* not implemented, yet */
- struct nautilus_menu_data *nautilus_data = platform;
- nautilus_data->item_id++;
- return TRUE;
+ return FALSE;
}

void reset_platform(void *platform)
@@ -131,8 +118,7 @@ GList *git_extension_get_file_items(NautilusMenuProvider *provider,



struct nautilus_menu_data nautilus_data = {
provider,

- NULL,
- 0
+ NULL
};


@@ -162,8 +148,7 @@ GList *git_extension_get_background_items(NautilusMenuProvider *provider,



struct nautilus_menu_data nautilus_data = {
provider,

- NULL,
- 0
+ NULL


};

git_data.name[0] = '\0';
diff --git a/nautilus/plugin.h b/nautilus/plugin.h

index 01b766a..c4aac63 100644
--- a/nautilus/plugin.h
+++ b/nautilus/plugin.h
@@ -20,7 +20,6 @@
struct nautilus_menu_data {
NautilusMenuProvider *provider;
GList *menu_items;
- int item_id;

Erik Faye-Lund

unread,
Jul 19, 2010, 9:58:24 AM7/19/10
to msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
There's still no support for checking menu items, so the branch
submenu isn't all that useful yet.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---

nautilus/menu.c | 51 ++++++++++++++++++++++++++++++++++++++++++++++-----
nautilus/plugin.h | 1 +
2 files changed, 47 insertions(+), 5 deletions(-)

diff --git a/nautilus/menu.c b/nautilus/menu.c
index a18e86b..b527931 100644
--- a/nautilus/menu.c
+++ b/nautilus/menu.c
@@ -49,8 +49,11 @@ BOOL build_item(struct git_data *me, const struct menu_item *item,


g_object_set_data((GObject *) one_menu_item,
"git_extension_git_data", me);

- nautilus_data->menu_items = g_list_append(nautilus_data->menu_items,
- one_menu_item);
+ if (nautilus_data->submenu)
+ nautilus_menu_append_item(nautilus_data->submenu, one_menu_item);
+ else
+ nautilus_data->menu_items = g_list_append(nautilus_data->menu_items,
+ one_menu_item);

free(item_name);
return TRUE;
@@ -71,13 +74,49 @@ void reset_platform(void *platform)
void *start_submenu(struct git_data *me, const struct menu_item *item,
void *platform)
{
- /* not implemented, yet */
- return NULL;
+ struct nautilus_menu_data *nautilus_data = platform;
+
+ NautilusMenuItem *submenu_item;
+ NautilusMenu *submenu;
+ char name[512], *item_name = strdup(item->string), shortcut_key;
+
+ shortcut_key = parse_and_remove_shortcuts(item_name);
+
+ sprintf(name, "GitExtension::%s", item_name);
+
+ debug_git("creating submenu item '%s' '%s' '%s'", item_name, name, item->helptext);
+ submenu_item = nautilus_menu_item_new(
+ name,
+ item_name,
+ item->helptext,
+ NULL);
+
+ free(item_name);
+
+ submenu = nautilus_menu_new();
+
+ g_object_set_data((GObject *)submenu, "git_menu_parent",
+ (void *)nautilus_data->submenu);
+
+ nautilus_menu_item_set_submenu(submenu_item, submenu);
+
+ if (nautilus_data->submenu)
+ nautilus_menu_append_item(nautilus_data->submenu, submenu_item);
+ else
+ nautilus_data->menu_items = g_list_append(nautilus_data->menu_items,
+ submenu_item);
+
+ nautilus_data->submenu = submenu;
+
+ return platform;
}

void end_submenu(void *parent, void *submenu)
{
- /* not implemented, yet */
+ struct nautilus_menu_data *nautilus_data = parent;
+ nautilus_data->submenu = (NautilusMenu *)g_object_get_data(
+ (GObject *)nautilus_data->submenu,
+ "git_menu_parent");
}

void check_menu_item(void *platform, int checked)
@@ -118,6 +157,7 @@ GList *git_extension_get_file_items(NautilusMenuProvider *provider,



struct nautilus_menu_data nautilus_data = {
provider,

+ NULL,
NULL
};

@@ -148,6 +188,7 @@ GList *git_extension_get_background_items(NautilusMenuProvider *provider,



struct nautilus_menu_data nautilus_data = {
provider,

+ NULL,
NULL
};

diff --git a/nautilus/plugin.h b/nautilus/plugin.h
index c4aac63..5a4c6e2 100644
--- a/nautilus/plugin.h
+++ b/nautilus/plugin.h
@@ -20,6 +20,7 @@


struct nautilus_menu_data {
NautilusMenuProvider *provider;
GList *menu_items;

+ NautilusMenu *submenu;

Erik Faye-Lund

unread,
Jul 19, 2010, 9:58:25 AM7/19/10
to msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
There's no point in stressing the stack more than necessary.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---

common/cheetahmenu.c | 2 +-
common/menuengine.c | 6 +++---
common/menuengine.h | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/common/cheetahmenu.c b/common/cheetahmenu.c
index 1b6e207..674e91c 100644
--- a/common/cheetahmenu.c
+++ b/common/cheetahmenu.c
@@ -268,7 +268,7 @@ static BOOL build_branch_menu(struct git_data *data,
item.helptext = strdup((*it)->buf + 2);
if (build_item(data, &item, submenu)) {
check_menu_item(submenu, '*' == (*it)->buf[0]);
- append_active_menu(item);
+ append_active_menu(&item);
} else
/*
* if the platform failed to create an item
diff --git a/common/menuengine.c b/common/menuengine.c
index b6eb60f..4de168a 100644
--- a/common/menuengine.c
+++ b/common/menuengine.c
@@ -29,11 +29,11 @@ void reset_active_menu()
next_active_item = 0;
}

-void append_active_menu(const struct menu_item item)
+void append_active_menu(const struct menu_item *item)
{
active_menu = realloc(active_menu,
(next_active_item + 1) * sizeof(struct menu_item));
- active_menu[next_active_item] = item;
+ active_menu[next_active_item] = *item;
next_active_item++;
}

@@ -57,7 +57,7 @@ void build_menu_items(struct git_data *data,
if ((menu_def[i].selection & selection) ==
menu_def[i].selection) {
if (menu_def[i].builder(data, &menu_def[i], platform))
- append_active_menu(menu_def[i]);
+ append_active_menu(&menu_def[i]);
}
}

diff --git a/common/menuengine.h b/common/menuengine.h
index fcf0c33..c16d628 100644
--- a/common/menuengine.h
+++ b/common/menuengine.h
@@ -94,6 +94,6 @@ void handle_menu_item(void *data, unsigned int id);
* from menu_item_builder, but a custom builder might need to
* instruct the engine to track a particular item
*/
-void append_active_menu(const struct menu_item item);
+void append_active_menu(const struct menu_item *item);

#endif /* MENUENGINE_H */
--
1.7.1.msysgit.0.387.g185df

Erik Faye-Lund

unread,
Jul 19, 2010, 9:58:26 AM7/19/10
to msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---
explorer/menu.h | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/explorer/menu.h b/explorer/menu.h
index 8bb3ae1..d295ee2 100644
--- a/explorer/menu.h
+++ b/explorer/menu.h
@@ -3,12 +3,12 @@

extern struct git_menu_virtual_table
{
- STDMETHOD(query_interface)(void *, REFIID, PVOID*);
- STDMETHOD_(ULONG, add_ref)(void *);
- STDMETHOD_(ULONG, release)(void *);
+ STDMETHOD(query_interface)(void *, REFIID, PVOID*);
+ STDMETHOD_(ULONG, add_ref)(void *);
+ STDMETHOD_(ULONG, release)(void *);
STDMETHOD(query_context_menu)(void *,
HMENU, UINT, UINT, UINT, UINT);
- STDMETHOD(invoke_command)(void *, LPCMINVOKECOMMANDINFO);
+ STDMETHOD(invoke_command)(void *, LPCMINVOKECOMMANDINFO);
STDMETHOD(get_command_string)(void *,
UINT, UINT, PUINT, LPSTR, UINT);
} git_menu_virtual_table;
--
1.7.1.msysgit.0.387.g185df

Erik Faye-Lund

unread,
Jul 19, 2010, 9:58:27 AM7/19/10
to msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
To avoid cluttering the context menu, let's have only one menu item
at the root level.

Make Git init the only entry if we're not in a repo, and create a
root menu otherwise.

Signed-off-by: Erik Faye-Lund <kusm...@gmail.com>
---

This patch is probably controversial. There's still no submenu-support
for finder so this patch will probably break the context menu support
there.

I don't have access to any MacOS X machine, so I can't really fix the
submenu support for finder myself.

common/cheetahmenu.c | 31 +++++++++++++++++++++++++++----
1 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/common/cheetahmenu.c b/common/cheetahmenu.c
index 674e91c..e5a5ab1 100644
--- a/common/cheetahmenu.c
+++ b/common/cheetahmenu.c
@@ -327,8 +327,6 @@ UINT cheetah_menu_mask(struct git_data *this_)
}

const struct menu_item cheetah_menu[] = {
- { MENU_ITEM_ALWAYS, NULL, NULL, build_separator, NULL },
-
{ MENU_ITEM_REPO, "Git &Add all files now",
"Add all files from this folder now",
build_item, menu_addall },
@@ -361,6 +359,31 @@ const struct menu_item cheetah_menu[] = {
{ MENU_ITEM_ALWAYS, "Git Ba&sh",
"Start GIT shell in the local or chosen directory",
build_item, menu_bash },
+};
+
+static BOOL build_root_menu(struct git_data *data,
+ const struct menu_item *item,
+ void *platform)
+{
+ void *submenu = start_submenu(data, item, platform);
+
+ build_menu_items(data, cheetah_menu_mask,
+ cheetah_menu,
+ sizeof(cheetah_menu) / sizeof(cheetah_menu[0]),
+ submenu);
+
+ end_submenu(platform, submenu);
+
+ /* nothing to track for the menu engine */
+ return FALSE;
+}
+
+const struct menu_item cheetah_root_menu[] = {
+ { MENU_ITEM_ALWAYS, NULL, NULL, build_separator, NULL },
+ { MENU_ITEM_NOREPO, "Git I&nit Here",
+ "Initialize GIT repo in the local directory.",
+ build_item, menu_init },
+ { MENU_ITEM_REPO, "Git", "Git-Cheetah GUI", build_root_menu, NULL },
{ MENU_ITEM_ALWAYS, NULL, NULL, build_separator, NULL },
};

@@ -368,7 +391,7 @@ void build_cheetah_menu(struct git_data *data, void *platform_data)
{
reset_platform(platform_data);
build_menu_items(data, cheetah_menu_mask,
- cheetah_menu,
- sizeof(cheetah_menu) / sizeof(cheetah_menu[0]),
+ cheetah_root_menu,
+ sizeof(cheetah_root_menu) / sizeof(cheetah_root_menu[0]),
platform_data);
}
--
1.7.1.msysgit.0.387.g185df

Eric Sunshine

unread,
Jul 19, 2010, 10:54:14 AM7/19/10
to Erik Faye-Lund, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de, Erik Faye-Lund
On 7/19/2010 9:58 AM, Erik Faye-Lund wrote:
> To avoid cluttering the context menu, let's have only one menu item
> at the root level.
> Make Git init the only entry if we're not in a repo, and create a
> root menu otherwise.
> Signed-off-by: Erik Faye-Lund<kusm...@gmail.com>

I don't have especially strong feelings about this ideologically, but I
will note that I invoke the "Git Bash" item many time throughout the day
both on the desktop and in folders not tracked by Git. Generally, it
happens to be a very convenient way to start a shell and, more
specifically, to start a shell with working-directory already set to the
location of interest. (In fact, I have never used the "Git Init Here" item.)

-- ES

Erik Faye-Lund

unread,
Jul 19, 2010, 11:20:52 AM7/19/10
to Eric Sunshine, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de

I see your point, but I'm not entirely convinced.

This is partly because the Microsoft conversion for this is to hide
the "Open Command Window Here" entry by default, and IMO this falls
under the same category. Unfortunately, we don't seem to have an
"advanced menu"-filter, so putting it under "Git" seems like the best
do-not-clutter-the-menu option to me.

But also: starting a new shell is something I do three-four times a
day - adding files and viewing the history is something I do up to 100
times each dat. So for me, these are the entries that should be very
accessible, not starting the shell -- but even for those I'd rather
have them hidden. Git isn't the only purpose for my computer, so I
don't really want it to take up a considerable amount of attention.

And third, isn't git-cheetah's purpose more or less to reduce the need
for the Git Bash?

The point of putting "Git init" at the root isn't that Git init is a
very useful item; having a Git-submenu with just one element simply
makes very little sense to me. It's just needless clutter IMO.

--
Erik "kusma" Faye-Lund

Eric Sunshine

unread,
Jul 19, 2010, 11:45:28 AM7/19/10
to kusm...@gmail.com, Erik Faye-Lund, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de
On 7/19/2010 11:20 AM, Erik Faye-Lund wrote:
> But also: starting a new shell is something I do three-four times a
> day - adding files and viewing the history is something I do up to 100
> times each dat.
> And third, isn't git-cheetah's purpose more or less to reduce the need
> for the Git Bash?

I did not say so explicitly, though it was implied, that I use Git Bash
on Windows, not just for Git, but for almost all of my command-line
needs throughout the day, of which there are plenty. It is, after all,
still a general purpose shell. This is not intended as a strong argument
one way or the other, but rather is meant only to illustrate that
certain items carry more or less weight under different usage patterns.
The counter argument is that I could just as easily add a Git Bash
shortcut to my desktop for almost the same effect. Of course, the real
solution for the issue overall is for the menus to be configurable.

> The point of putting "Git init" at the root isn't that Git init is a
> very useful item; having a Git-submenu with just one element simply
> makes very little sense to me. It's just needless clutter IMO.

At present, for non-Git folders, it shows items "Git Init Here", "Git
GUI", and "Git Bash", all of which make sense for folders not tracked by
Git. Even if moving items to a "Git" menu, it would still likely have
these three items, not just "Git Init Here".

-- ES

Erik Faye-Lund

unread,
Jul 19, 2010, 12:33:19 PM7/19/10
to Eric Sunshine, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de
On Mon, Jul 19, 2010 at 5:45 PM, Eric Sunshine <ericsu...@gmail.com> wrote:
> On 7/19/2010 11:20 AM, Erik Faye-Lund wrote:
>>
>> But also: starting a new shell is something I do three-four times a
>> day - adding files and viewing the history is something I do up to 100
>> times each dat.
>> And third, isn't git-cheetah's purpose more or less to reduce the need
>> for the Git Bash?
>
> I did not say so explicitly, though it was implied, that I use Git Bash on
> Windows, not just for Git, but for almost all of my command-line needs
> throughout the day, of which there are plenty. It is, after all, still a
> general purpose shell. This is not intended as a strong argument one way or
> the other, but rather is meant only to illustrate that certain items carry
> more or less weight under different usage patterns.

I completely agree with this, but I don't think this is of
git-cheetah's concern. It's a git front-end, and should primarily be
concerned with git use-cases then way I see it.

> The counter argument is
> that I could just as easily add a Git Bash shortcut to my desktop for almost
> the same effect.

Indeed, and I think this is what makes the most sense. We already have
support for adding a quick-launch entry for Git Bash. But it would not
make Bash start up at the directory you want.

Another way of doing this would be for users who want a quick way of
launching MSYS to add the needed keys to
HKEY_CLASSES_ROOT/Directory/shell. This could be an optional step in
the installer, for example.

> Of course, the real solution for the issue overall is for
> the menus to be configurable.
>

This might not be what you meant, but I think making the entire
menu-layout configurable is over the top. Perhaps my proposal (making
the Bash entry configurable from the installer) is sufficient for now?

>> The point of putting "Git init" at the root isn't that Git init is a
>> very useful item; having a Git-submenu with just one element simply
>> makes very little sense to me. It's just needless clutter IMO.
>
> At present, for non-Git folders, it shows items "Git Init Here", "Git GUI",
> and "Git Bash", all of which make sense for folders not tracked by Git. Even
> if moving items to a "Git" menu, it would still likely have these three
> items, not just "Git Init Here".

This is a very good point. Perhaps there should always be a "Git"-menu, then?

I didn't realize that I completely removed these entries in that the
no-repo case (I don't use these short-cuts at all myself), so thanks
for pointing it out. It makes your previous points make much more
sense to me :)

--
Erik "kusma" Faye-Lund

Eric Sunshine

unread,
Jul 19, 2010, 1:14:29 PM7/19/10
to kusm...@gmail.com, Erik Faye-Lund, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de
On 7/19/2010 12:33 PM, Erik Faye-Lund wrote:
> On Mon, Jul 19, 2010 at 5:45 PM, Eric Sunshine<ericsu...@gmail.com> wrote:
>> I did not say so explicitly, though it was implied, that I use Git Bash on
>> Windows, not just for Git, but for almost all of my command-line needs
>> throughout the day, of which there are plenty. It is, after all, still a
>> general purpose shell. This is not intended as a strong argument one way or
>> the other, but rather is meant only to illustrate that certain items carry
>> more or less weight under different usage patterns.
> I completely agree with this, but I don't think this is of
> git-cheetah's concern. It's a git front-end, and should primarily be
> concerned with git use-cases then way I see it.

Indeed, it does not really fall under the purview of Git Cheetah, which
is one of the reasons why I can not strongly argue that it belongs one
place or another, despite its convenience for my particular usage pattern.

>> The counter argument is
>> that I could just as easily add a Git Bash shortcut to my desktop for almost
>> the same effect.
> Indeed, and I think this is what makes the most sense. We already have
> support for adding a quick-launch entry for Git Bash. But it would not
> make Bash start up at the directory you want.
> Another way of doing this would be for users who want a quick way of
> launching MSYS to add the needed keys to
> HKEY_CLASSES_ROOT/Directory/shell. This could be an optional step in
> the installer, for example.

> This might not be what you meant, but I think making the entire
> menu-layout configurable is over the top. Perhaps my proposal (making
> the Bash entry configurable from the installer) is sufficient for now?

I am not sure that I entirely understand the proposal. It seems like
such an option would interfere with, or at least duplicate, the existing
"Git Bash" item of Git Cheetah.

>> At present, for non-Git folders, it shows items "Git Init Here", "Git GUI",
>> and "Git Bash", all of which make sense for folders not tracked by Git. Even
>> if moving items to a "Git" menu, it would still likely have these three
>> items, not just "Git Init Here".
> This is a very good point. Perhaps there should always be a "Git"-menu, then?

I can formulate reasonable arguments for and against always having a
"Git" menu, so I can't really answer this other than to relate my
experience with TortoiseSVN and TortoiseCVS, which allow the Explorer
menu to be configured. In my case, there are a few items which I use
very frequently ("update", "commit", "check for local changes") which
get placed at top-level, while all other items are relegated to the submenu.

-- ES

Erik Faye-Lund

unread,
Jul 19, 2010, 2:36:35 PM7/19/10
to Eric Sunshine, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de

Yes, it would indeed interfere with Git Cheetah. I was basically
suggesting to move this functionality out of Git Cheetah, and making
them separate context-menu entries. That way, people can choose if
they want them or not, without us having to make a big menu-editing
system.

>>> At present, for non-Git folders, it shows items "Git Init Here", "Git
>>> GUI",
>>> and "Git Bash", all of which make sense for folders not tracked by Git.
>>> Even
>>> if moving items to a "Git" menu, it would still likely have these three
>>> items, not just "Git Init Here".
>>
>> This is a very good point. Perhaps there should always be a "Git"-menu,
>> then?
>
> I can formulate reasonable arguments for and against always having a "Git"
> menu, so I can't really answer this other than to relate my experience with
> TortoiseSVN and TortoiseCVS, which allow the Explorer menu to be configured.
> In my case, there are a few items which I use very frequently ("update",
> "commit", "check for local changes") which get placed at top-level, while
> all other items are relegated to the submenu.
>

I still can't really say that I see any good arguments against moving
everything inside a Git-menu item, because I suspect the "oh no, it's
so much work to enter a submenu"-argument to be greatly exaggerated.
Even at hundreds of accesses per day, I don't think it saves you much
to avoid having an extra level. It quickly becomes a mechanical
process. Of course, how much it saves you depends on often you use Git
compared to other context-menu items.

With TortoiseSVN it's a completely different story. TortoiseSVN has so
many entries in the submenu that it takes a considerable amount of
time to find the entry you need. We're not there yet, so I don't think
we need to worry about this now... but I suspect it might be better
solved by adding more submenus than to put things at the top-level.
But that might just be me ;)

--
Erik "kusma" Faye-Lund

Eric Sunshine

unread,
Jul 19, 2010, 2:47:42 PM7/19/10
to kusm...@gmail.com, Erik Faye-Lund, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de
On 7/19/2010 2:36 PM, Erik Faye-Lund wrote:
> On Mon, Jul 19, 2010 at 7:14 PM, Eric Sunshine<ericsu...@gmail.com> wrote:
>> I am not sure that I entirely understand the proposal. It seems like such an
>> option would interfere with, or at least duplicate, the existing "Git Bash"
>> item of Git Cheetah.
> Yes, it would indeed interfere with Git Cheetah. I was basically
> suggesting to move this functionality out of Git Cheetah, and making
> them separate context-menu entries. That way, people can choose if
> they want them or not, without us having to make a big menu-editing
> system.

Given that Git Cheetah is intended to be platform-agnostic, relocating
this one particular bit of functionality to a platform-specific
installer seems less than desirable. Whether "Git Bash" is at top-level
or on a submenu, it should continue to be managed solely by Git Cheetah.

-- ES

Erik Faye-Lund

unread,
Jul 19, 2010, 3:02:10 PM7/19/10
to Eric Sunshine, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de

...but is this really something that SHOULD be platform-agnostic? For
nautilus there's already the "open terminal"-extension that does the
same thing. I mean, on a Linux system there's nothing Git-specific
about Bash, so it doesn't make that much sense to have a "Git Bash"
entry at all IMO. I assume the same goes for Finder, since MacOS X
already provide a POSIX shell. It's really only on Windows that the
Bash is a Git thing, and if I've understood the situation correctly,
that's something we're looking to get rid of over time.

--
Erik "kusma" Faye-Lund

Eric Sunshine

unread,
Jul 19, 2010, 3:14:13 PM7/19/10
to kusm...@gmail.com, Erik Faye-Lund, msy...@googlegroups.com, hvo...@hvoigt.net, johannes....@gmx.de
On 7/19/2010 3:02 PM, Erik Faye-Lund wrote:
> On Mon, Jul 19, 2010 at 8:47 PM, Eric Sunshine<ericsu...@gmail.com> wrote:
>> Given that Git Cheetah is intended to be platform-agnostic, relocating this
>> one particular bit of functionality to a platform-specific installer seems
>> less than desirable. Whether "Git Bash" is at top-level or on a submenu, it
>> should continue to be managed solely by Git Cheetah.
> ...but is this really something that SHOULD be platform-agnostic? For
> nautilus there's already the "open terminal"-extension that does the
> same thing. I mean, on a Linux system there's nothing Git-specific
> about Bash, so it doesn't make that much sense to have a "Git Bash"
> entry at all IMO. I assume the same goes for Finder, since MacOS X
> already provide a POSIX shell.

It is not something which Mac OS X does natively, but there are a number
of extensions providing such functionality:
http://stackoverflow.com/questions/420456/open-terminal-here-in-mac-os-finder

> It's really only on Windows that the
> Bash is a Git thing, and if I've understood the situation correctly,
> that's something we're looking to get rid of over time.

Even if the "Git Bash" item is specific to (conditionalized for)
Windows, it still makes sense for it to be the responsibility of Git
Cheetah. If indeed all items move to a "Git" menu, then it likely would
be best for that menu to be managed by this one entity. Localization is
another consideration. Both for the implementation and for the sake of
translators, it would be simplest for all menu items to be managed together.

-- ES

Reply all
Reply to author
Forward
0 new messages