When you want to commit changes with Monticello, you have essentially two ways:
- Monticello Browser (or Nautilus)
- Komitter
The problem with Monticello is that it is really an all-or-nothing solution… you just enter the commit description and that’s it. This is fine most of the time, but not always — maybe you want to commit across several packages, or maybe you want to commit just a single method. Not to mention that you don’t actually see what you are committing, unless you open a separate changes diff.
To address this problem, there’s a Komitter
tool (World > Tools > Komitter). Unfortunately, this tool has a different problem — it shows you the changes in the entire system, which considering I have a lot of custom system overrides is a lot.
Of course, I can manually not include everything I don’t want, but that’s a lot of work since I would have to do it every time.
Komitter on a single package
So, let’s find a middle ground. Looking at the Komitter class
, I found a suspicious method
Komitter class>>openAndCommitToMonticelloWorkingCopiesFilteredBy: aFilterBlock
This method opens the Komitter just on working copies (=the uncommitted packages) matching aFilterBlock
, which means I can do something like this
|
|
That’s so much better! But who would want to type something like that every time?
Extending Nautilus menus
Nautilus can be extended in many ways, one of which is extending the context menus. I want to add an entry just above the “Changes with…” that would open Komitter
on the selected package(s).
All we have to do is to define somewhere a class-side method containing the <nautilusGlobalPackageMenu>
pragma.
For inspiration, we can take a look at the class side of AbstractNautilusUI
or NautilusMonticello
where we can find the definitions of the currently visible menu.
So, to add new entry, let’s create a new method on the class side of Komitter
in *MyKomitter-menu
protocol (it doesn’t matter where it is, but I like to keep extensions close to what they operate on).
|
|
The target
in the above script is NautilusUI
instance (you can always throw in self halt
to explore). The order
has been taken from NautilusMonticello
, so it’s just where I wanted it to be.
And we are done!
Adding it to Startup Scripts
Finally, since I wouldn’t want to add it manually every time, I’ve made it into a startup script — simply compile the method into the class on first startup (don’t forget to save the file wherever your Pharo’s startup scripts are stored). (There’s a small bugfix included for Pharo 5.)
|
|