summaryrefslogtreecommitdiff
path: root/lib/option.tcl
AgeCommit message (Collapse)AuthorFilesLines
2010-01-27git-gui: use themed tk widgets with Tk 8.5Libravatar Pat Thoyts1-30/+37
This patch enables the use of themed Tk widgets with Tk 8.5 and above. These make a significant difference on Windows in making the application appear native. On Windows and MacOSX ttk defaults to the native look as much as possible. On X11 the user may select a theme using the TkTheme XRDB resource class by adding an line to the .Xresources file. The set of installed theme names is available using the Tk command 'ttk::themes'. The default on X11 is similar to the current un-themed style - a kind of thin bordered motif look. A new git config variable 'gui.usettk' may be set to disable this if the user prefers the classic Tk look. Using Tk 8.4 will also avoid the use of themed widgets as these are only available since 8.5. Some support is included for Tk 8.6 features (themed spinbox and native font chooser for MacOSX and Windows). Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-11-16git-gui: Implement system-wide configuration handling.Libravatar Alexander Gavrilov1-6/+6
With the old implementation any system-wide options appear to be set locally in the current repository. This commit adds explicit handling of system options, essentially interpreting them as customized default_config. The difficulty in interpreting system options stems from the fact that simple 'git config' lists all values, while 'git config --global' only values set in ~/.gitconfig, excluding both local and system options. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-24git-gui: Add a menu of available encodings.Libravatar Alexander Gavrilov1-1/+12
To make encoding selection easier, add a menu that lists available encodings to the Options window. Menu structure is borrowed from Firefox. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-24git-gui: Cleanup handling of the default encoding.Libravatar Alexander Gavrilov1-0/+24
- Make diffs and blame default to the system (locale) encoding instead of hard-coding UTF-8. - Add a gui.encoding option to allow overriding it. - gitattributes still have the final word. The rationale for this is Windows support: 1) Windows people are accustomed to using legacy encodings for text files. For many of them defaulting to utf-8 will be counter-intuitive. 2) Windows doesn't support utf-8 locales, and switching the system encoding is a real pain. Thus the option. This patch also adds proper encoding conversion to Apply Hunk/Line. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Tested-by: Johannes Sixt <johannes.sixt@telecom.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-04git-gui: Support calling merge tools.Libravatar Alexander Gavrilov1-0/+1
Adds an item to the diff context menu in conflict mode, which invokes a merge tool for the selected file. Tool command-line handling code was ported from git-mergetool. Automatic default tool selection and custom merge tools are not supported. If merge.tool is not set, git-gui defaults to meld. This implementation uses a checkout-index hack in order to retrieve all stages with autocrlf and filters properly applied. It requires temporarily moving the original conflict file out of the way. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-09-01Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+1
* maint: git-gui: Fix string escaping in po2msg.sh git gui: show diffs with a minimum of 1 context line Conflicts: lib/option.tcl
2008-09-01git gui: show diffs with a minimum of 1 context lineLibravatar Clemens Buchacher1-1/+1
Staging hunks without context does not work, because line number information would have to be recomputed for individual hunks. Since it is already possible to stage individual lines using 'Stage Line for Commit', zero context diffs are not really necessary for git gui. Signed-off-by: Clemens Buchacher <drizzd@aon.at> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-08-24git-gui: Support starting gitk from Gui BlameLibravatar Alexander Gavrilov1-0/+1
Add a context menu command to load commits that are within a certain time range from the selected commit into gitk. It can be useful for understanding of the code, especially if the repository is imported from a VCS that does not support atomic commits. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-07-16Add options to control the search for copies in blame.Libravatar Alexander Gavrilov1-0/+2
On huge repositories, -C -C can be way too slow to be unconditionally enabled, and it can also be useful to control its precision. Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-03-07git-gui: Add option for changing the width of the commit message text boxLibravatar Adam Piątyszek1-0/+1
The width of the commit message text area is currently hard-coded to 75 characters. This value might be not optimal for some projects. For instance users who would like to generate GNU-style ChangeLog file from git commit message might prefer commit messages of width no longer than 70 characters. This patch adds a global and per repository option "Commit Message Text Width", which could be used to change the width of the commit message text area. Signed-off-by: Adam Piątyszek <ediap@users.sourceforge.net> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-02-14git-gui: Correct size of dictionary name widget in options dialogLibravatar Shawn O. Pearce1-3/+1
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>
2008-02-12git-gui: Automatically spell check commit messages as the user typesLibravatar Shawn O. Pearce1-0/+41
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>
2007-10-10git-gui: Bind Cmd-, to Preferences on Mac OS XLibravatar Shawn O. Pearce1-5/+7
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>
2007-10-10git-gui: Refactor about dialog code into its own moduleLibravatar Shawn O. Pearce1-78/+0
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>
2007-09-14git-gui: Paper bag fix missing translated stringsLibravatar Shawn O. Pearce1-1/+1
The Tcl expression "[append [mc Foo] Bar]" does not return the string "FooBar" after translation; instead it is setting the variable Foo to the value Bar, or if Foo is already defined it is appending Bar onto the end of it. This is *not* what we wanted to have happen here. Tcl's join function is actually the correct function but its default joinStr argument is a single space. Unfortunately all of our call sites do not want an extra space added to their string. So we need a small wrapper function to make the call to join with an empty join string. In C this is (roughly) the job of the strcat function. Since strcat is not yet used at the global level it is a reasonable name to use here. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-09-13Merge branch 'maint'Libravatar Shawn O. Pearce1-11/+17
* maint: git-gui: Paper bag fix "Commit->Revert" format arguments git-gui: Provide 'uninstall' Makefile target to undo an installation git-gui: Font chooser to handle a large number of font families
2007-09-13git-gui: Font chooser to handle a large number of font familiesLibravatar Shawn O. Pearce1-11/+17
Simon Sasburg noticed that on X11 if there are more fonts than can fit in the height of the screen Tk's native tk_optionMenu does not offer scroll arrows to the user and it is not possible to review all choices or to select those that are off-screen. On Mac OS X the tk_optionMenu works properly but is awkward to navigate if the list is long. This is a rewrite of our font selection by providing a new modal dialog that the user can launch from the git-gui Options panel. The dialog offers the user a scrolling list of fonts in a pane. An example text shows the user what the font looks like at the size they have selected. But I have to admit the example pane is less than ideal. For example in the case of our diff font we really should show the user an example diff complete with our native diff syntax coloring. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Acked-by: Simon Sasburg <simon.sasburg@gmail.com>
2007-09-02Mark strings for translation.Libravatar Christian Stimming1-25/+24
The procedure [mc ...] will translate the strings through msgcat. Strings must be enclosed in quotes, not in braces, because otherwise xgettext cannot extract them properly, although on the Tcl side both delimiters would work fine. [jes: I merged the later patches to that end.] Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
2007-07-09git-gui: Always use absolute path to all git executablesLibravatar Shawn O. Pearce1-0/+1
Rather than making the C library search for git every time we want to execute it we now search for the main git wrapper at startup, do symlink resolution, and then always use the absolute path that we found to execute the binary later on. This should save us some cycles, especially on stat challenged systems like Cygwin/Win32. While I was working on this change I also converted all of our existing pipes ([open "| git ..."]) to use two new pipe wrapper functions. These functions take additional options like --nice and --stderr which instructs Tcl to take special action, like running the underlying git program through `nice` (if available) or redirect stderr to stdout for capture in Tcl. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-07-08git-gui: Option to default new branches to match tracking branchesLibravatar Shawn O. Pearce1-0/+1
In some workflows users will want to almost always just create a new local branch that matches a remote branch. In this type of workflow it is handy to have the new branch dialog default to "Match Tracking Branch" and "Starting Revision"-Tracking Branch", with the focus in the branch filter field. This can save users working on this type of workflow at least two mouse clicks every time they create a new local branch or switch to one with a fast-forward. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-06-11Merge branch 'maint'Libravatar Shawn O. Pearce1-0/+3
* maint: (38 commits) git-gui: Changed blame header bar background to match main window git-gui: Favor the original annotations over the recent ones git-gui: Improve our labeling of blame annotation types git-gui: Use three colors for the blame viewer background git-gui: Jump to original line in blame viewer git-gui: Display both commits in our tooltips git-gui: Run blame twice on the same file and display both outputs git-gui: Display the "Loading annotation..." message in italic git-gui: Rename fields in blame viewer to better descriptions git-gui: Label the uncommitted blame history entry git-gui: Switch internal blame structure to Tcl lists git-gui: Cleanup redundant column management in blame viewer git-gui: Better document our blame variables git-gui: Remove unused commit_list from blame viewer git-gui: Automatically expand the line number column as needed git-gui: Make the line number column slightly wider in blame git-gui: Use lighter colors in blame view git-gui: Remove unnecessary space between columns in blame viewer git-gui: Remove the loaded column from the blame viewer git-gui: Clip the commit summaries in the blame history menu ...
2007-06-06git-gui: Display the "Loading annotation..." message in italicLibravatar Shawn O. Pearce1-0/+3
If the user clicks on a line region that we haven't yet received an annotation for from git-blame we show them "Loading annotation". But I don't want the user to confuse this loading message with a commit whose first line is "Loading annotation" and think we messed up our display somehow. Since we never use italics for anything else, I'm going with the idea that italic slant can be used to show data is missing/elided out at the time being. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-31Merge branch 'maint'Libravatar Shawn O. Pearce1-1/+1
* maint: git-gui: Allow as few as 0 lines of diff context
2007-05-31git-gui: Allow as few as 0 lines of diff contextLibravatar Shawn O. Pearce1-1/+1
Johannes Sixt pointed out that dropping to 0 lines of context does allow the user to get more fine-grained hunk selection, especially since we don't currently support "highlight and apply (or revert)". Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-28git-gui: Expose the merge.diffstat configuration optionLibravatar Shawn O. Pearce1-0/+1
Recently git-merge learned to avoid generating the diffstat after a merge by reading the merge.diffstat configuration option. By default this option is assumed to be true, as that is the old behavior. However we can force it to false by setting it as a standard boolean option. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-28git-gui: Show the git-gui library path in 'About git-gui'Libravatar Shawn O. Pearce1-1/+14
Because we now try to automatically guess the library directory in certain installations users may wonder where git-gui is getting its supporting files from. We now display this location in our About dialog, and we also include the location we are getting our Git executables from. Unfortunately users cannot use this 'About git-gui' dialog to troubleshoot library loading problems; the dialog is defined by code that exists in the library directory, creating a catch-22. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-28git-gui: GUI support for running 'git remote prune <name>'Libravatar Shawn O. Pearce1-0/+1
In some workflows it is common for a large number of temporary branches to be created in a remote repository, get fetched to clients that typically only use git-gui, and then later have those branches deleted from the remote repository once they have been fully merged into all destination branches. Users of git-gui would obviously like to have their local tracking branches cleaned up for them, otherwise their local tracking branch namespace would grow out of control. The best known way to remove these tracking branches is to run "git remote prune <remotename>". Even though it is more of a Porcelain command than plumbing I'm invoking it through the UI, because frankly I don't see a reason to reimplement its ls-remote output filtering and config file parsing. A new configuration option (gui.pruneduringfetch) can be used to automatically enable running "git remote prune <remotename>" after the fetch of that remote also completes successfully. This is off by default as it require an additional network connection and is not very fast on Cygwin if a large number of tracking branches have been removed (due to the 2 fork+exec calls per branch). Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2007-05-07git-gui: Refactor into multiple files to save my sanityLibravatar Shawn O. Pearce1-0/+290
I'm finding it difficult to work with a 6,000+ line Tcl script and not go insane while looking for a particular block of code. Since most of the program is organized into different units of functionality and not all users will need all units immediately on startup we can improve things by splitting procs out into multiple files and let auto_load handle things for us. This should help not only to better organize the source, but it may also improve startup times for some users as the Tcl parser does not need to read as much script before it can show the UI. In many cases the user can avoid reading at least half of git-gui now. Unfortunately we now need a library directory in our runtime location. This is currently assumed to be $(sharedir)/git-gui/lib and its expected that the Makefile invoker will setup some sort of reasonable sharedir value for us, or let us assume its going to be $(gitexecdir)/../share. We now also require a tclsh (in TCL_PATH) to just run the Makefile, as we use tclsh to generate the tclIndex for our lib directory. I'm hoping this is not an unncessary burden on end-users who are building from source. I haven't really made any functionality changes here, this is just a huge migration of code from one file to many smaller files. All of the new changes are to setup the library path and install the library files. Signed-off-by: Shawn O. Pearce <spearce@spearce.org>