| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
|
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 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>
|
|
Commit is used as both verb and noun. While these happen to be
the same in some languages, they are not the same in all
languages, so disambiguate them using context-sensitive i18n.
Signed-off-by: Harri Ilari Tapio Liusvaara <hliusvaa@cc.hut.fi>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
Currently the Git plumbing is not localized so it does not know how
to output weekday and month names that conform to the user's locale
preferences. This doesn't fit with the rest of git-gui's UI as some
of our dates are formatted in Tcl and some are just read from the Git
plumbing so dates aren't consistently presented.
Since git-for-each-ref is presenting us formatted dates and it offers
no way to change that setting even in git 1.5.3.1 we need to first do
a parse of the text strings it produces, correct for timezones, then
reformat the timestamp using Tcl's formatting routines.
Not exactly what I wanted to do but it gets us consistently presented
date strings in areas like the blame viewer and the revision picker
mega-widget's tooltips.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
Someone on #git today pointed out that the revision chooser's tooltips
are were being drawn with untranslated strings for the fixed labels we
include, such as "updated", "commit" and "remote". These strings are
now passed through mc to allow them to be localized.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
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>
|
|
If we are started for only a blame/browser/citool run we don't
usually initialize the list of remotes, or determine which refs
are tracking branches and which are local branch heads. This is
because some of that work is relatively expensive and is usually
not going to be needed if we are started only for a blame, or to
make a single commit.
However by not loading the remote configuration we were crashing
if the user tried to open a browser for another branch through
the Repository menu, as our load_all_heads procedure was unable
to decide which refs/heads/ items were actually local heads. We
now force all remote configuration data to be loaded if we have
not done so already and we are trying to create a revision mega
widget.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
If we can we now show the last modification date of a loose ref as
part of the tooltip information shown in the revision picker. This
gives the user an indication of when was the last time that the ref
was modified locally, and may especially be of interest when looking
at a tracking branch.
If we cannot find the loose ref file than we try to fallback on the
reflog and scan it for the date of the last record. We don't start
with the reflog however as scanning it backwards from the end is not
an easy thing to do in Tcl. So I'm being lazy here and just going
through the entire file, line by line. Since that is less efficient
than a single stat system call, its our fallback strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
Our revision chooser mega-widget now sets up tooltips for itself so
that it displays details about a commit (or a tag and the commit
it refers to) when the user mouses over that line in the filtered
ref list. If the item is from a remote tracking branch then we also
show the remote url and what branch on that remote we fetch from, so
the user has a clear concept of where that revision data originated.
To help the merge dialog I've also added a new constructor that
makes the dialog only offer unmerged revisions (those not in HEAD),
as this allows users to avoid performing merges only to get "Already
up to date" messages back from core Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
Showing only five lines of heads/tags is not very useful to a user
when they have about 10 branches that match the filter expression.
The list is just too short to really be able to read easily, at
least not without scrolling up and down. Expanding the list out
to 10 really makes the revision picker easier to read and access,
as you can read the matching branches much more quickly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
If the user double clicks a branch in the checkout dialog then they
probably want to start the checkout process on that branch. I found
myself doing this without realizing it, and of course it did nothing
as there was no action bound to the listbox's Double-Button-1 event
handler. Since I did it without thinking, others will probably also
try, and expect the same behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
If we have specifications listed in our revision picker mega-widget
then we should default the selection within that widget to the first
ref available. This way the user does not need to use the spacebar
to activate the selection of a ref within the box; instead they can
navigate up/down with the arrow keys and be done with it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
This is a major rewrite of the way we perform switching between
branches and the subsequent update of the working directory. Like
core Git we now use a single code path to perform all changes: our
new checkout_op class. We also use it for branch creation/update
as it integrates the tracking branch fetch process along with a
very basic merge (fast-forward and reset only currently).
Because some users have literally hundreds of local branches we
use the standard revision picker (with its branch filtering tool)
to select the local branch, rather than keeping all of the local
branches in the Branch menu. The branch menu listing out all of
the available branches is simply not sane for those types of huge
repositories.
Users can now checkout a detached head by ticking off the option
in the checkout dialog. This option is off by default for the
obvious reason, but it can be easily enabled for any local branch
by simply checking it. We also detach the head if any non local
branch was selected, or if a revision expression was entered.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
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>
|
|
One of my production repositories has hundreds of remote tracking
branches. Trying to navigate these through a popup menu is just
not possible. The list is far larger than the screen and it does
not scroll fast enough to efficiently select a branch name when
trying to create a branch or delete a branch.
This is major rewrite of the revision chooser mega-widget. We
now use a single listbox for all three major types of named refs
(heads, tracking branches, tags) and a radio button group to pick
which of those namespaces should be shown in the listbox. A filter
field is shown to the right allowing the end-user to key in a glob
specification to filter the list they are viewing. The filter is
always taken as substring, so we assume * both starts and ends the
pattern the user wanted but otherwise treat it as a glob pattern.
This new picker works out really nicely. What used to take me at
least a minute to find and select a branch now takes mere seconds.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
Some workflows have users create a local branch that matches a remote
branch they have fetched from another repository. If the user wants
to push their changes back to that remote repository then they probably
want to use the same branch name locally so that git-gui's push dialog
can setup the push refspec automatically.
To prevent typos with the local branch name we now offer an option to
use the remote tracking branch name as the new local branch name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
In the next change I want to let the user create their local branch
name to match the remote branch name, so that the existing push
dialog can push the branch back up to the remote repository without
needing to do any sort of remapping. To do that we need to know
exactly what branch name the remote system is using.
So all_tracking_branches returns a list of specifications, where
each specification is itself a list of:
- local ref name (destination we fetch into)
- remote name (repository we fetch from)
- remote ref name (source ref we fetch from)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
A simple refactoring of the delete branch dialog to allow use of
the class construct to better organize the code and to reuse the
revision selection code of our new choose_rev mega-widget.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
|
This rather large change pulls the "Starting Revision" part of the
new branch dialog into a mega widget that we can use anytime we
need to select a commit SHA-1. To make use of the mega widget I
have also refactored the branch dialog to use the class system,
much like the delete remote branch dialog already does.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
|
Pat Thoyts
Shawn O. Pearce
Harri Ilari Tapio Liusvaara
Christian Stimming