Re: [PATCH] Make filediff viewers adjustable widths

[Kai Willadsen <kai willadsen gmail com>]

2009/3/30 Mark Doliner <mark kingant net>:
> I agree, it would look better if the adjustment grippy was centered in
> the diffbar and didn't break the appearance of the central bar.  But
> that sounds hard and I was just scratching an itch.
>
> I'm not familiar with how the diffbar is implemented.  Is it a custom
> widget?

Sort of - it's just a GtkDrawingArea that we do a bunch of custom painting on.

> It seems like it would need to be extended to display the
> grippy image in the middle, and to handle mouse drag/undrag events.
> I'm not sure how feasible that is, or how easy it would be to
> implement.

That's not actually what I meant - though I agree that that would
probably also look fine. A similar option would be to draw on top of
the HPaned after it has rendered so that it looks consistent with the
diffbar. My problem with this approach is that you're putting the
draggable grippy right next to the arrows for copying between panes,
which seems a little risky.

However, what I actually meant was that the pane could go in the area
*above* each diffbar, between the "Browse" button and the next entry
widget . This would make it small - arguably not sufficiently
discoverable - but would not interfere with anything else. For
example, see the tiny handles on Gnumeric's scroll bar that are used
for splitting the view.

So, having packed a HPaned between the file entries, you could then
make an invisible HPaned (maybe just setting the handle-size style
property to zero would work, otherwise a subclass), pack it between
the actual content, and hook it up to change size when the top pane
was dragged. However, I'm just assuming that this would work, and I
have no idea how much effort making a HPaned invisible would be.

Kai