Re: [RFH] QGit: how to cram a patch in a crowded screen

[Jan Hudec <bulb@ucw.cz>]

[-- Attachment #1: Type: text/plain, Size: 1728 bytes --]

On Sun, May 27, 2007 at 17:56:05 +0200, Marco Costalba wrote:
> On 5/27/07, Jan Hudec <bulb@ucw.cz> wrote:
> >On Sat, May 26, 2007 at 22:44:28 +0200, Marco Costalba wrote:
> >> On 5/26/07, Andy Parkins <andyparkins@gmail.com> wrote:
> >> >
> >> >For example, the log view widget would show:
> >> >
> >> ><Header>
> >> ><Log Message>
> >> ><Patch>
> >> >
> >> >All visually distinct to improve searching by eye (perhaps including
> >> >clear separators between files patched).  Then the file list could
> >> >include a "<header>" psuedo-file that would jump back to the top of the
> >> >viewer.
> >>
> >> This seems really gitk like. Not that I don' t like it, but _if_ it's
> >> possible I would prefer something a little bit more original.
> >
> >IMHO there's no point in being original.
> 
> True. But there's no point also in avoiding experimenting a little bit.
> 
> I've pushed some patches to use different ways to switch between diff
> and messages, please read the last patch log message for a summary of
> the changes.
> 
> If interested give it a try. it would be grat to hear your comment on that 
> also.

I have to say that I like the gitk way better. There is the issue of
over-scrolling. I often want to quickly scan through the diff, so I scroll
pretty quickly and it switches over when I reach the end.

I understand the reason to not calculate the diff until it's requested.
I think I might like it if only message is shown initially and when user
scrolls at -- or rather past -- the end, the diff would be APPENDED to it.
That way the scrolling would look more natural, while still only generating
the diff only on request.

-- 
						 Jan 'Bulb' Hudec <bulb@ucw.cz>

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]