Re: [fossil-users] ui side-by-side diffs
On Oct 10, 2011, at 1:01 , Jan Danielsson wrote: Feedback/ideas/protests are welcome from anyone who has any preferences with regards to design/layout. I've only used cvsweb, so it'll be my primary source of inspiration. For those with wider experience of such tools, let me know if there are others I should be looking at. Here are some features that I like, which can be added later once we have a basic implementation: I like how Google Code highlights changes inside diffs: http://code.google.com/p/spiped/source/diff?spec=svn18r=17format=sidepath=/trunk/main.cold_path=/trunk/main.cold=2 Also, Google's Code Review tool collapses lots of unchanged lines: http://codereview.appspot.com/5218041/diff/26002/src/pkg/html/parse_test.go -- Dmitry Chestnykh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On 10/10/11 02:48, v...@lavabit.com wrote: [---] Side-by-side diffs (especially of long lines) may look worse on non-multimonitor setups or on non-widescreen monitors. Having done a lot of reviews using side-by-side view in cvsweb on a non-widescreen monitor, I can't really say I identify with that. (Though the code I reviewed was limited to 80 columns per line). Also, we shouldn't avoid adding features because there are people/projects for whom/which the feature is less optimal. Also, changes in html code may raise some concern among those who use third party javascript libraries to get colored diffs. Now it is simple - a snippet of code in diff format surrounded by certain html tags is detected by the javascript highlighter and colored accordingly. I don't know how side-by-side diffs look in html code so I'd like to have the option to stick to current layout, which proved to work. When you say Now it is simple - a snippet of code in diff format surrounded by certain html tags is detected by the javascript highlighter and colored accordingly. I think you've missed the point of the feature I'm suggesting. Take a look at http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/cgd.c.diff?r1=1.72r2=1.72.2.1f=h That's the basic functionality I'm aiming for (but slightly less .. colorful); but the main point is simplicity -- it should Just Work(tm) without having to add any special javascript parsers to the project. With regards to your specific concern: No, the current feature will not be removed. I have no intention of removing features -- only add new ones. What are the specific prerequisites for the highlighter you're using? -- Kind regards, Jan Danielsson ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On Mon, Oct 10, 2011 at 1:01 AM, Jan Danielsson jan.m.daniels...@gmail.comwrote: I'll post a draft spec in the next few days, then start working on the actual implementation. FWIW: this could be implemented in JavaScript, using the JSON API to fetch the actual diffs, and then laying them out in JS (rather than C): http://fossil.wanderinghorse.net/cgi-bin/fossil-json.cgi/json/diff?v1=b0e9b45baed6f885v2=5f225e261d836287context=5 -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Equivalent of `git gui' for fossil?
Hello, is there a tool for fossil similar to `git gui'? which is a GUI helper for commiting changes -- lists changes in files (in colored diff format) and lets user choose which changes to commit. Regards, -- dexen deVries [[[↓][→]]] http://xkcd.com/732/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On Mon, 10 Oct 2011 15:48:58 +0200 Jan Danielsson jan.m.daniels...@gmail.com wrote: FWIW: this could be implemented in JavaScript, using the JSON API to fetch the actual diffs, and then laying them out in JS (rather than C): http://fossil.wanderinghorse.net/cgi-bin/fossil-json.cgi/json/diff?v1=b0e9b45baed6f885v2=5f225e261d836287context=5 In my mind, the side-by-side diff shouldn't require javascript. I think it's a good idea to allow sections to be hidden/shown using javascript, but by default the diff should work even with javascript unavailable/disabled or noscript (in firefox) blocking the site. Or am I being too old-fashioned? I'm with you on this. Your example [1] looks just right to me. All those flashy JS bells and whistles consistently make me think they're really there for the sake of being there. 1. http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/dev/cgd.c.diff?r1=1.72r2=1.72.2.1f=h ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On Mon, Oct 10, 2011 at 4:04 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: All those flashy JS bells and whistles consistently make me think they're really there for the sake of being there. But what better reason could there possibly be ;). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Gdiff after commited files?
Hello fossil gdiff myfile.txt works fine while myfile.txt hasn't yet been commited. Is there a simple way to tell Fossil to call the gdiff application with the last and before-last revisions of the file by default? Thank you. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On Mon, Oct 10, 2011 at 8:20 AM, Stephan Beal sgb...@googlemail.com wrote: On Mon, Oct 10, 2011 at 4:04 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: All those flashy JS bells and whistles consistently make me think they're really there for the sake of being there. But what better reason could there possibly be ;). Providing the reader a better experience. Yes, I know you weren't really serious. But enough web authors seem to take that attitude seriously that it's a sore point for me. Such things are generally there to hide the fact that the content isn't worth reading. In this case, there's useful information there, so why not actually present it? Personally, I find the colorize the code on the client hacks incredibly wasteful. You could colorize it once when you generate it, but instead you colorize it every time someone wants to read it? Talk about a silly waste of CPU. Or has CPU really gotten so cheap that this is now acceptable, and I'm doing nothing more than showing my age by worrying about it? Now, there *is* something useful that could be done here. Let the reader control the colorization. Of course, that can be done with dynamic CSS, and you could provide it and still only colorize things once. But I haven't seen a colorizing tool that does even that much. In this case, you're generating the diff at read time, so there's no savings in avoiding doing things in JS. But if you're going to do that, at least take the opportunity and let the reader control what they see. mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] Gdiff after commited files?
On Oct 10, 2011, at 17:38 , Gilles wrote: Is there a simple way to tell Fossil to call the gdiff application with the last and before-last revisions of the file by default? fossil gdiff --from previous myfile.txt -- Dmitry Chestnykh ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On Mon, Oct 10, 2011 at 5:49 PM, Mike Meyer m...@mired.org wrote: On Mon, Oct 10, 2011 at 8:20 AM, Stephan Beal sgb...@googlemail.comwrote: But what better reason could there possibly be ;). Providing the reader a better experience. Yes, I know you weren't really serious. But enough web authors seem to take that attitude seriously that it's a sore point for me. Actually i was only half kidding :). Every line of code i write outside of the office is written because it sounds like a fun way to spend my time, not because it's something the world needs. i've written TONS of code which will never be used by anyone, but i nonetheless enjoyed writing it. But i sympathize with your sentiment. In the defense of web developers everywhere: they add all the fluff _normally_ because the marketing department forces them to. Such things are generally there to hide the fact that the content isn't worth reading. In this case, there's useful information there, so why not actually present it? True enough. Personally, I find the colorize the code on the client hacks incredibly wasteful. You could colorize it once when you generate it, but instead you colorize it every time someone wants to read it? Talk about a silly waste of CPU. Or has CPU really gotten so cheap that this is now acceptable, and I'm doing nothing more than showing my age by worrying about it? One could just as easily argue that doing it server-side is wasting server CPU cycles and why not make the client work a bit for his presentation? i'm not arguing either way (they're both valid), just playing Devil's advocate. The JSON API, as a whole, is intended for use in clients where a server-side colorization process is most likely just troublesome noise (i.e. non-HTML clients). In this case, you're generating the diff at read time, so there's no savings in avoiding doing things in JS. But if you're going to do that, at least take the opportunity and let the reader control what they see. If the client gets a raw text diff he can control (with complete granularity) what he wants to see. Again, i'm not arguing against your (perfectly valid) points, just pointing out opposing viewpoints (because that's my nature - one of my old teachers once recommended that i become a arbitrator). (i have yet to meet a woman who appreciates such a quality in a man. ;) (and that time i'm most definitely not kidding ;) -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On Mon, Oct 10, 2011 at 9:16 AM, Stephan Beal sgb...@googlemail.com wrote: Personally, I find the colorize the code on the client hacks incredibly wasteful. You could colorize it once when you generate it, but instead you colorize it every time someone wants to read it? Talk about a silly waste of CPU. Or has CPU really gotten so cheap that this is now acceptable, and I'm doing nothing more than showing my age by worrying about it? One could just as easily argue that doing it server-side is wasting server CPU cycles and why not make the client work a bit for his presentation? i'm not arguing either way (they're both valid), just playing Devil's advocate. The JSON API, as a whole, is intended for use in clients where a server-side colorization process is most likely just troublesome noise (i.e. non-HTML clients). I guess I didn't make the point clear. I agree with you - if the choice is to do it on either the server or client, putting it on the client helps distribute the load. In the case of colorizing code, I was referring to a third option: generating static html on the authors desktop. That way, you can do it just the one time, instead of every time the thing is read. But it's not a sexy solution. This option isn't available for the case under discussion - the diff listings are generated at read time in the first place. Doing formatting work on the client makes a lot of sense, but I'd be happier if the code allowed the user to control as much as possible, rather than wiring it to what the author prefers. Unless, of course, you're feeding an iPhone, when you have to wire it to what Apple prefers :-). mike ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] ui side-by-side diffs
On Mon, Oct 10, 2011 at 6:29 PM, Mike Meyer m...@mired.org wrote: the case of colorizing code, I was referring to a third option: generating static html on the authors desktop. That way, you can do it just the one time, instead of every time the thing is read. But it's not a sexy solution. On a related note: it just occurred to me the other day that many (most?) requests from fossil could be _permanently_ cached client-side because the requests refer to static data which (by definition) does not change. Some requests can't be safely cached (timeline, wiki, etc.), but anything referring to a diff or any other static content could (theoretically) be cached indefinitely with no loss of precision. For any two calls to diff with the same 2 versions (and other significant parameters, e.g. # of context lines), the content (maybe not the layout) will be identical (if they're not, there's a bug!). makes a lot of sense, but I'd be happier if the code allowed the user to control as much as possible, rather than wiring it to what the author prefers. Which is very much the case with fossil's current UI. Unless, of course, you're feeding an iPhone, when you have to wire it to what Apple prefers :-). LOL! i was at a Qt dev conference in 2008 where the Qt devs kept saying things like, it works like so-and-so, except on Mac because Apple won't let us do it that way. snide comments about said tech company stripped.../ -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
