We really only support Aspell, so showing the compatibility line from
ispell is of little value to end users.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has somehow managed to make us execute ispell instead
of aspell, even though our code is invoking aspell, and ispell is
not recognizing the aspell command line options we use to invoke
it then we don't want a giant usage message back from ispell.
Instead we show the ispell version number, letting the user know
we don't actually support that spell checker.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we feed a bad dictionary name to aspell on startup it may appear
to start (as Tcl found the executable in our $PATH) but it fails to
give us the version string. In such a case the close of the pipe
will report the exit status of the process (failure) and that is
an error in Tcl.
We now trap the subprocess failure and display the stderr message
from it, letting the user know why the failure is happening. We then
disable the spell checker, but keep our object instance so the user
can alter their preferred dictionary through the options dialog, and
possibly restart the spell checker.
I was also originally wrong to use "error" here for the display
of the problem to the user. I meant to use "error_popup", which
will open a message box and show the failure in a GUI context,
rather than killing git-gui and showing the message on the console.
Noticed by Ilari on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we reconnect to the spellchecker there is no reason to resetup
the binding for button 3 on our text widget to show the suggestion
list (if available).
Plus, by moving it out of _connect and into init we can now break
out of _connect earlier if there is something wrong with the pipe,
for example if the dictionary we were asked to load is not valid.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users may or may not be using aspell here. About the only thing
we are using that is aspell specific (and not supported by ispell
or an ispell variant) is some command line options when we start
up aspell, and a forced encoding of UTF-8. Both of these can be
corrected and/or cleaned up by users through an aspell wrapper
script, or through further improvements to git-gui. There is no
reason to require our translated strings to reference a specific
spell checker, especially if that spell checker implementation is
not very suitable for the language being translated.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we somehow managed to get our spellchecker instance created but
aspell wasn't startable we may not finish _connect and thus may
find one or more of our fields was not initialized in the instance.
If we have an instance but no version, there is no reason to show
a version to the user in our about dialog. We effectively have no
spellchecker available.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are opening an error dialog we want it to appear above all of
the other windows, even those that we may have opened with a grab
to make the window modal. Failure to do so may allow an error
dialog to open up (and grab focus!) under an existing toplevel,
making the user think git-gui has frozen up and is unresponsive,
as they cannot get to the dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
And markup one missing string for translation.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We don't need to fill this entire horizontal cavity, it looks really
bad on some platforms to stretch the widget out to fill the window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We don't want the list length, we need the string length.
Found due to a bad " character discovered in the text and
Tcl throwing 'unmatched open quote in list'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Many user friendly tools like word processors, email editors and web
browsers allow users to spell check the message they are writing
as they type it, making it easy to identify a common misspelling
of a word and correct it on the fly.
We now open a bi-directional pipe to Aspell and feed the message
text the user is editing off to the program about once every 300
milliseconds. This is frequent enough that the user sees the results
almost immediately, but is not so frequent as to cause significant
additional load on the system. If the user has modified the message
text during the last 300 milliseconds we delay until the next period,
ensuring that we avoid flooding the Aspell process with a lot of
text while the user is actively typing their message.
We wait to send the current message buffer to Aspell until the user
is at a word boundary, thus ensuring that we are not likely to ask
for misspelled word detection on a word that the user is actively
typing, as most words are misspelled when only partially typed,
even if the user has thus far typed it correctly.
Misspelled words are highlighted in red and are given an underline,
causing the word to stand out from the others in the buffer. This is
a very common user interface idiom for displaying misspelled words,
but differs from one platform to the next in slight variations.
For example the Mac OS X system prefers using a dashed red underline,
leaving the word in the original text color. Unfortunately the
control that Tk gives us over text display is not powerful enough
to handle such formatting so we have to work with the least common
denominator.
The top suggestions for a misspelling are saved in an array and
offered to the user when they right-click (or on the Mac ctrl-click)
a misspelled word. Selecting an entry from this menu will replace
the misspelling with the correction shown. Replacement is integrated
with the undo/redo stack so undoing a replacement will restore the
misspelled original text.
If Aspell could not be started during git-gui launch we silently eat
the error and run without spell checking support. This way users
who do not have Aspell in their $PATH can continue to use git-gui,
although they will not get the advanced spelling functionality.
If Aspell started successfully the version line and language are
shown in git-gui's about box, below the Tcl/Tk versions. This way
the user can verify the Aspell function has been activated.
If Aspell crashes while we are running we inform the user with an
error dialog and then disable Aspell entirely for the rest of this
git-gui session. This prevents us from fork-bombing the system
with Aspell instances that always crash when presented with the
current message text, should there be a bug in either Aspell or in
git-gui's output to it.
We escape all input lines with ^, as recommended by the Aspell manual
page, as this allows Aspell to properly ignore any input line that is
otherwise looking like a command (e.g. ! to enable terse output). By
using this escape however we need to correct all word offsets by -1 as
Aspell is apparently considering the ^ escape to be part of the line's
character count, but our Tk text widget obviously does not.
Available dictionaries are offered in the Options dialog, allowing
the user to select the language they want to spellcheck commit
messages with for the current repository, as well as the global
user setting that all repositories inherit.
Special thanks to Adam Flott for suggesting connecting git-gui
to Aspell for the purpose of spell checking the commit message,
and to Wincent Colaiuta for the idea to wait for a word boundary
before passing the message over for checking.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the horizontal scrollbar isn't currently visible (because it has
not been needed) but we get an update to the scroll port we may find
the scrollbar window exists but the Tcl command doesn't. Apparently
it is possible for Tk to have partially destroyed the scrollbar by
removing the Tcl procedure name but still leaving the widget name in
the window registry.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code we use to test if a hook is executable or not differs on
Cygwin from the normal POSIX case. Rather then repeating that for
all three hooks we call in our commit code path we can place the
common logic into a global procedure and invoke it when necessary.
This also lets us get rid of the ugly "|& cat" we were using before
as we can now rely on the Tcl 8.4 feature of "2>@1" or fallback to
the "|& cat" when necessary.
The post-commit hook is now run through the same API, but its outcome
does not influence the commit status. As a result we now show any of
the errors from the post-commit hook in a dialog window, instead of on
the user's tty that was used to launch git-gui. This resolves a long
standing bug related to not getting errors out of the post-commit hook
when launched under git-gui.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
During i18n translation work this message was partially broken
by using "append" instead of "strcat" to join the two different
parts of the message together.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Under core Git the git-commit tool will invoke the commit-msg hook
if it exists and is executable to the user running git-commit. As
a hook it has some limited value as it cannot alter the commit, but
it can modify the message the user is attempting to commit. It is
also able to examine the message to ensure it conforms to some local
standards/conventions.
Since the hook takes the name of a temporary file holding the message
as its only parameter we need to move the code that creates the temp
file up earlier in our commit code path, and then pass through that
file name to the latest stage (where we call git-commit-tree). We let
the hook alter the file as it sees fit and we don't bother to look at
its content again until the commit succeeded and we need the subject
for the reflog update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we apply a hunk in either direction this may change the file's
status. For example if a file is completely unstaged, and has at
least two hunks in it and the user stages one hunk the file will
change from "Modified, not staged" to "Portions staged for commit".
Resetting the file path causes our trace on this variable to fire;
that trace is used to update the file header in the diff viewer to
the file's current status.
Noticed by Johannes Sixt.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Often users setup a few source files and get a project rolling
before they create a Git repository for it. In such cases the
core Git tools allow users to initialize a new repository by
simply running `git init` at the desired root level directory.
We need to allow the same situation in git-gui; if the user is
trying to make a new repository we should let them do that to any
location they chose. If the directory already exists and already
has files contained within it we still should allow the user to
create a repository there. However we still need to disallow
creating a repository on top of an existing repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I broke this extremely cool feature in 1ac17950,
but it is rather easy to fix this. Sorry for that.
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Concatenating commit log messages from multiple commits works better
when all of the commits end with a clean line break.
Its good to be strict in what you create, and lenient in what you
accept, and since we're creating here, we should always try to
Do The Right Thing(tm).
Signed-off-by: Bernt Hansen <bernt@alumni.uwaterloo.ca>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out the diff headers "old mode ..." and
"new mode ..." were not being parsed properly by git-gui. We
now include them in the diff viewer for a file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Previusly, there was only a 16x16 image, which looked very distorted.
Here we add a 32x32 version, and also make the image sharper.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm seeing a lot of silent failures from git-update-index on
Windows and this is leaving the index.lock file intact, which
means users are later unable to perform additional operations.
When the index is locked behind our back and we are unable to
use it we may need to allow the user to delete the index lock
and try again. However our UI state is probably not currect
as we have assumed that some changes were applied but none of
them actually did. A rescan is the easiest (in code anyway)
solution to correct our UI to show what the index really has
(or doesn't have).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git progress bars from tools like git-push and git-fetch use CR
to skip back to the start of the current line and redraw it with
an updated progress. We were doing this in our Tk widget but had
failed to skip the CR, which Tk doesn't draw well.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Post Git 1.5.3 a new style progress bar has been introduced that
uses only one line rather than two. The formatting of the completed
and total section is also slightly different so we must adjust our
regexp to match. Unfortunately both styles are in active use by
different versions of Git so we need to look for both.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-write-tree fails (such as if the index file is currently
locked and it wants to write to it) we were not getting the error
message as $tree_id was always the empty string so we shortcut
through the catch and never got the output from stderr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently native Tcl/Tk on Windows is using \ as the return value
from [file separator] but [file normalize] on that same system is
using / rather than \ to represent a directory separator. I really
think that is nuts, but its what is happening.
So we can actually just hardcode our separator to / as all systems
we support (Windows, Mac OS X, UNIX) use /.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user tries to clone a Git repository that is actually a
workdir of another repository (by way of contrib git-new-workdir)
then the contents of .git is a series of Windows .lnk files which
Tcl can't read if this is a native Tcl process. To read the real
objects directory we need to resolve the link to that location.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows its better to use a shortcut (.lnk file) over a batch
script (.bat) as we can specify the icon file for the .lnk and
thus have these git specific objects appear on the desktop with
that git specific icon file.
Unfortunately the authors of Tcl did not bless us with the APIs
needed to create shortcuts from within Tcl. But Microsoft did
give us Windows Scripting Host which allows us to execute some
JavaScript that calls some sort of COM object that can operate
on a .lnk file.
We now build both Cygwin and non-Cygwin "desktop icons" as proper
Windows .lnk files, using the "Start in" property of these files
to indicate the working directory of the repository the user wants
to launch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Windows we need to actually setup binds for the accelerator
keys, otherwise the OS doesn't respond to them when the user
presses the key combinations. Apparently we automatically get
these on Mac OS X when we configure the menu commands, but not
on Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Although we are using a text widget here we really do not
want the end-user to be able to modify the text it displays.
So we need to disable it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We need to remove any variable traces we may have installed
when the panel is destroyed as the trace may attempt to use
a widget that no longer exists on this panel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we show the repository chooser as the primary toplevel (".") we
now offer the major choices not just on the window as hyperlinks but
they also now are shown in the Repository menu, including the recent
repository list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Making a user click twice to select which action they want to perform
when starting git-gui is just wasting their time. Clicking once on a
radio button and then clicking again on the "Next >" button is quite
unnecessary.
Since the recent repository list is shown as a list of hyperlinks we
now offer the 3 basic startup actions as hyperlinks. Clicking on a
link will immediately jump to the next UI panel, saving the user time
as they don't need to click an additional button.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If git-gui is started outside a work tree the repository chooser
will offer a list of recently opened repositories. Clicking on
any list entry directly opens the repository.
The list of recently opened repositories is stored in the config
as the multi-valued option gui.recentrepo. If the list grows beyond
10 entries it will be truncated by removing one of the older entries.
Only repositories that are opened through the repository chooser
will get added to the recent list. Repositories opened from the
shell will not yet be added to the recent list, as users are likely
to have a way to easily return to the same directory via their shell.
[sp: This is actually a combined work from both Steffen and myself.
Most of the ideas are Steffen's, as is the basic outline of
the code, but any outstanding bugs are entirely my fault.]
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A Mac OS X UI convention is to have Cmd-, be the accelerator key
for the preferences window, which by convention is located in the
apple menu under a separator below the about command. We also now
call this "Preferences..." as that is the conventional term used
in English.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes the Fetch menu looks really odd, such as if you are in a
repository that has no remotes configured when you start git-gui.
Here we didn't have any items to add to the Fetch menu so it was a
tad confusing for the end-user to see an empty menu on the menu bar.
We now place all of the commands related to fetching and pushing of
changes into a single "Remote" menu. This way we have a better class
of bucket that we can drop additional remote related items into such
as doing a remote merge or editing the remote configuration specs.
The shortcuts to execute fetch/remote prune/push on existing remote
specifications are now actually submenus listing the remotes by name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are updating the index to stage or unstage changes or reverting
files in the working directory we can use the progress handling parts
of our status bar to perform this display work, reducing the amount of
code duplication we have in the index handling module.
Unfortunately the status bar is still a strict approximation as it is
unable to know when git-update-index has processed the data we fed to
it. The progress bar is actually a progress of the pipe buffer filling
up in the OS, not of the actual work done. Still, it tells the user we
are working and that has some value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most applications tend to have some sort of pretty image in the
about dialog, because it spruces the screen up a little bit and
makes the user happy about reading the information shown there.
We already have a logo in the repository selection wizard so we
can easily reuse this in the about dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The about dialog is getting somewhat long in size and will probably
only get more complex as I try to improve upon its display. As the
options dialog is even more complex than the about dialog we move
the about dialog into its own module to reduce the complexity of the
option dialog module.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
By moving the logo into its own procedure we can use it in
multiple locations within the UI, but still load it only if
the logo is going to be used by the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some workflows allow the user to forcefully update a remote branch,
such as in a "proposed updates" (aka "pu") branch where the branch
is rewound and rebuilt on a daily basis against the current master
branch. In such a case the "--force" or leading + must be used to
make git-push execute anyway, even though it may be discarding one
or more commits on the remote side.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than displaying the stock red "Tk" icon in our window
title bars and on the task bar we now show a Git specific logo.
This is Henrik Nyh's logo that we also use in the startup wizard,
scaled to a 16x16 image for Windows task bar usage with a proper
transparent background.
Signed-off-by: Shawn O. Pearce <shawn.o.pearce@bankofamerica.com>
The setup wizard looks better if we layout the progress bar as
two lines: the first line holds the message text and our text
formatting of the progress while the second line holds the bar
itself. Both extend the full width of the window and we try to
pad out the message text so the window doesn't expand when the
completed progress number jumps to the next order of magnitude.
This change required updating the progress meter format string
to allow the application to supply the precision. So we also
are updating all of the translations at once to use the newer
formatting string.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Henrik came up with this alternative logo for gitweb and posted
it on his blog:
http://henrik.nyh.se/2007/06/alternative-git-logo-and-favicon
The msysGit port uses his logo within some of their components,
and frankly it looks better here in git-gui for our repository
setup wizard screen. The logo fits quite nicely along the left
edge of our window, leaving significantly more vertical space
for things like the git-fetch console output.
Because the logo changes the layout charateristics of the setup
window I also needed to adjust some of the padding for our widgets
and stop using a fixed width window size. We now let Tk compute
the correct size of the main window whenever the layout changes,
and drop the window into roughly the upper left 1/3 of the desktop
so its not quite centered but is likely to be far enough away from
any sort of task bars/menu bars/docks that the user may have along
any edge of the screen.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
