gsoc idea adding javascript library / framework in gitweb

gsoc idea adding javascript library / framework in gitweb

[chaitanyaa nalla]

Hello everyone ,


 I am chaitanya nalla, a final year undergraduate student from India and i
am pretty much interested in doing the project "Adding javascript library /
framework in gitweb" suggested by respected Jakub, I have good experience
in javascript ,libraries like jquery,Dojo etc. As per the goals of the
project i will use the efficient ,concise ,cross browser compatible
frameworks where ever needed.Also i am planning to create a local library
version with support for configuration and a good documentation.

Using the Dom features of javascript and traversing the whole document
object is quite cubersome and error prone .so i want to replace them using
well tested libraries that are cross browser compatible.

Emualiting onprogress in XMLHttpRequest :

Jquery and Yui provide only statuses success and error .Even Mootools
provide progress but are constrained to some browers only.It can be handled
by using $.ajax Transport utility .

I will also take care progressive enhancement,by carefully implementing the
basic functionality of the gitweb so that what ever may be the browser
version and type , internet connection the basic functionality will not
disrupted .

yours sincerely,
chaitanya nalla.
India.

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Sat, 24 Mar 2012, Chaitanyaa Nalla wrote:

> Hello everyone,
> 
>  I am Chaitanya Nalla, a final year undergraduate student from India and I
> am pretty much interested in doing the project "Adding javascript library /
> framework in gitweb" suggested by respected Jakub.  I have good experience
> in javascript libraries like jQuery, Dojo etc. As per the goals of the
> project I will use the efficient, concise, cross browser compatible
> frameworks where ever needed.

JavaScript library / framework is required not only to cover differences
between web browsers in DOM manipulation, event handling and Ajax with
XmlHttpRequest, but also add features which are still[1] lacking from
JavaScript such as handling cookies, formatting strings, date manipulation,
etc.

Currently gitweb uses hand-crafted micro-library in `gitweb/static/js/lib/`
Using existing JavaScript library, be it jQuery (most popular), Dojo,
MooTools or YUI (probably too much for gitweb) will give us, as you said,
well tested code, and new abilities like client-side sorting of tables
which we would be able to use in further work.

[1] http://www.nczonline.net/blog/2011/10/03/when-web-standards-fail-us/

>                                Also I am planning to create a local library 
> version with support for configuration and a good documentation.

I don't quite understand what you mean here.  The JavaScript code specific
to gitweb would have to be modified to use chosen JavaScript library, but
I wouldn't say it is "local library".  I'd rather we use stock JavaScript
library, which would allow us to leverage existing CDNs like (for jQuery)

  http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js
  http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js
  http://code.jquery.com/jquery-1.7.2.min.js
 
We probably would ultimately need to be able to serve local fallback copy
(but this might be out of scope of GSoC project).

This gitweb-specific JavaScript code (files in `gitweb/static/js/`)
is IMVHO quite well documented using JSDoc.

> Using the DOM features of JavaScript and traversing the whole document
> object is quite cubersome and error prone, so I want to replace them using
> well tested libraries that are cross browser compatible.

I think there is missing "using hand-crafted code" in this sentence
to make it sense.

> 
> Emulating onprogress in XMLHttpRequest :
> 
> jQuery and YUI provide only statuses success and error.

Right.

> Even MooTools provide progress but are constrained to some browers
> only.

To be more exact MooTools support 'onprogress' event handler only if
web browser supports it.  Not all do (e.g. older browsers), that is why
there is need for emulation using timers.

> It can be handled by using $.ajax Transport utility .

You mean in jQuery here, isn't it?  It would be a bit different, I think,
in MooTools or YUI.

C.f. http://stackoverflow.com/questions/5652229/javascript-framework-with-or-easily-extendable-with-support-for-xmlhttprequest

> I will also take care progressive enhancement, by carefully implementing the
> basic functionality of the gitweb so that what ever may be the browser
> version and type, internet connection the basic functionality will not
> disrupted.

Errr... "progressive enhancement" is about using client-side scripting
in such way, that even if web browser doesn't support JavaScript
(e.g. text browsers such as lynx, elinks or w3m), or has JavaScript
turned off or blocked, we would get a basic functionality.

Note also that "progressive enhancement" part applies only to writing
new features, and this is strictly 'as time permits' part, I think.
But I thin that you would need to lay more complete proposal, i.e.
what features are you planning to add. 

-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

Dear Jakub ,

 could you please suggest any other ideas or features so that i can
think upon them and come up with further good ideas.

On Sat, Mar 24, 2012 at 6:47 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 24 Mar 2012, Chaitanyaa Nalla wrote:
>
>> Hello everyone,
>>
>>  I am Chaitanya Nalla, a final year undergraduate student from India and I
>> am pretty much interested in doing the project "Adding javascript library /
>> framework in gitweb" suggested by respected Jakub.  I have good experience
>> in javascript libraries like jQuery, Dojo etc. As per the goals of the
>> project I will use the efficient, concise, cross browser compatible
>> frameworks where ever needed.
>
> JavaScript library / framework is required not only to cover differences
> between web browsers in DOM manipulation, event handling and Ajax with
> XmlHttpRequest, but also add features which are still[1] lacking from
> JavaScript such as handling cookies, formatting strings, date manipulation,
> etc.
>
> Currently gitweb uses hand-crafted micro-library in `gitweb/static/js/lib/`
> Using existing JavaScript library, be it jQuery (most popular), Dojo,
> MooTools or YUI (probably too much for gitweb) will give us, as you said,
> well tested code, and new abilities like client-side sorting of tables
> which we would be able to use in further work.
>
> [1] http://www.nczonline.net/blog/2011/10/03/when-web-standards-fail-us/
>
>>                                Also I am planning to create a local library
>> version with support for configuration and a good documentation.
>
> I don't quite understand what you mean here.  The JavaScript code specific
> to gitweb would have to be modified to use chosen JavaScript library, but
> I wouldn't say it is "local library".  I'd rather we use stock JavaScript
> library, which would allow us to leverage existing CDNs like (for jQuery)
>
>  http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js
>  http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js
>  http://code.jquery.com/jquery-1.7.2.min.js
>
> We probably would ultimately need to be able to serve local fallback copy
> (but this might be out of scope of GSoC project).
>
> This gitweb-specific JavaScript code (files in `gitweb/static/js/`)
> is IMVHO quite well documented using JSDoc.
>
>> Using the DOM features of JavaScript and traversing the whole document
>> object is quite cubersome and error prone, so I want to replace them using
>> well tested libraries that are cross browser compatible.
>
> I think there is missing "using hand-crafted code" in this sentence
> to make it sense.
>
>>
>> Emulating onprogress in XMLHttpRequest :
>>
>> jQuery and YUI provide only statuses success and error.
>
> Right.
>
>> Even MooTools provide progress but are constrained to some browers
>> only.
>
> To be more exact MooTools support 'onprogress' event handler only if
> web browser supports it.  Not all do (e.g. older browsers), that is why
> there is need for emulation using timers.
>
>> It can be handled by using $.ajax Transport utility .
>
> You mean in jQuery here, isn't it?  It would be a bit different, I think,
> in MooTools or YUI.
>
> C.f. http://stackoverflow.com/questions/5652229/javascript-framework-with-or-easily-extendable-with-support-for-xmlhttprequest
>
>> I will also take care progressive enhancement, by carefully implementing the
>> basic functionality of the gitweb so that what ever may be the browser
>> version and type, internet connection the basic functionality will not
>> disrupted.
>
> Errr... "progressive enhancement" is about using client-side scripting
> in such way, that even if web browser doesn't support JavaScript
> (e.g. text browsers such as lynx, elinks or w3m), or has JavaScript
> turned off or blocked, we would get a basic functionality.
>
> Note also that "progressive enhancement" part applies only to writing
> new features, and this is strictly 'as time permits' part, I think.
> But I thin that you would need to lay more complete proposal, i.e.
> what features are you planning to add.
>
> --
> Jakub Narebski
> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

ok,  first i will think and come up with good ideas and then ask you
about your suggestions :)

On Sat, Mar 24, 2012 at 9:39 PM, chaitanyaa nalla <nallachaitu@gmail.com> wrote:
> Dear Jakub ,
>
>  could you please suggest any other ideas or features so that i can
> think upon them and come up with further good ideas.
>
> On Sat, Mar 24, 2012 at 6:47 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sat, 24 Mar 2012, Chaitanyaa Nalla wrote:
>>
>>> Hello everyone,
>>>
>>>  I am Chaitanya Nalla, a final year undergraduate student from India and I
>>> am pretty much interested in doing the project "Adding javascript library /
>>> framework in gitweb" suggested by respected Jakub.  I have good experience
>>> in javascript libraries like jQuery, Dojo etc. As per the goals of the
>>> project I will use the efficient, concise, cross browser compatible
>>> frameworks where ever needed.
>>
>> JavaScript library / framework is required not only to cover differences
>> between web browsers in DOM manipulation, event handling and Ajax with
>> XmlHttpRequest, but also add features which are still[1] lacking from
>> JavaScript such as handling cookies, formatting strings, date manipulation,
>> etc.
>>
>> Currently gitweb uses hand-crafted micro-library in `gitweb/static/js/lib/`
>> Using existing JavaScript library, be it jQuery (most popular), Dojo,
>> MooTools or YUI (probably too much for gitweb) will give us, as you said,
>> well tested code, and new abilities like client-side sorting of tables
>> which we would be able to use in further work.
>>
>> [1] http://www.nczonline.net/blog/2011/10/03/when-web-standards-fail-us/
>>
>>>                                Also I am planning to create a local library
>>> version with support for configuration and a good documentation.
>>
>> I don't quite understand what you mean here.  The JavaScript code specific
>> to gitweb would have to be modified to use chosen JavaScript library, but
>> I wouldn't say it is "local library".  I'd rather we use stock JavaScript
>> library, which would allow us to leverage existing CDNs like (for jQuery)
>>
>>  http://ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js
>>  http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.7.2.min.js
>>  http://code.jquery.com/jquery-1.7.2.min.js
>>
>> We probably would ultimately need to be able to serve local fallback copy
>> (but this might be out of scope of GSoC project).
>>
>> This gitweb-specific JavaScript code (files in `gitweb/static/js/`)
>> is IMVHO quite well documented using JSDoc.
>>
>>> Using the DOM features of JavaScript and traversing the whole document
>>> object is quite cubersome and error prone, so I want to replace them using
>>> well tested libraries that are cross browser compatible.
>>
>> I think there is missing "using hand-crafted code" in this sentence
>> to make it sense.
>>
>>>
>>> Emulating onprogress in XMLHttpRequest :
>>>
>>> jQuery and YUI provide only statuses success and error.
>>
>> Right.
>>
>>> Even MooTools provide progress but are constrained to some browers
>>> only.
>>
>> To be more exact MooTools support 'onprogress' event handler only if
>> web browser supports it.  Not all do (e.g. older browsers), that is why
>> there is need for emulation using timers.
>>
>>> It can be handled by using $.ajax Transport utility .
>>
>> You mean in jQuery here, isn't it?  It would be a bit different, I think,
>> in MooTools or YUI.
>>
>> C.f. http://stackoverflow.com/questions/5652229/javascript-framework-with-or-easily-extendable-with-support-for-xmlhttprequest
>>
>>> I will also take care progressive enhancement, by carefully implementing the
>>> basic functionality of the gitweb so that what ever may be the browser
>>> version and type, internet connection the basic functionality will not
>>> disrupted.
>>
>> Errr... "progressive enhancement" is about using client-side scripting
>> in such way, that even if web browser doesn't support JavaScript
>> (e.g. text browsers such as lynx, elinks or w3m), or has JavaScript
>> turned off or blocked, we would get a basic functionality.
>>
>> Note also that "progressive enhancement" part applies only to writing
>> new features, and this is strictly 'as time permits' part, I think.
>> But I thin that you would need to lay more complete proposal, i.e.
>> what features are you planning to add.
>>
>> --
>> Jakub Narebski
>> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Sat, 24 Mar 2012, chaitanyaa nalla wrote:

> Dear Jakub ,
> 
>  could you please suggest any other ideas or features so that i can
> think upon them and come up with further good ideas.

One idea for additional feature that I have already mentioned, and which
I have put on https://github.com/peff/git/wiki/SoC-2012-Ideas is
client-side sorting of tables, e.g. of list of all projects, a la
jQuery / MediaWiki (Wikipedia) "sorttable".

Another would be using deferreds or queues for interactive blame, so
that repainting (editing DOM) happens asynchronously to avoid locking
up browser, like in 
  http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/

There was also some time ago a patch that added ability to mark a commit
to compare current commit to (using JavaScript and cookies), to have an
UI to compare arbitrary commits using 'commitdiff' view.  Or something
similar to MediaWiki (Wikipedia) page history view. 


Yet another would be support for graphical representation of history in
'log', 'shortlog' and 'history' views e.g. using Raphael.js

Perhaps it would be possible to employ some JavaScript syntax highlighter
to pretty-print contents of 'blob' view.


Hope That Helps.


P.S. You can see gitweb at work here:

  http://git.kernel.org/?p=git/git.git
  http://repo.or.cz/w/git.git
-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

that's great ,thanks for your time and concern.I will carefully
consider each and every suggestion and approach you if i need any
clarification .

On Sun, Mar 25, 2012 at 12:19 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 24 Mar 2012, chaitanyaa nalla wrote:
>
>> Dear Jakub ,
>>
>>  could you please suggest any other ideas or features so that i can
>> think upon them and come up with further good ideas.
>
> One idea for additional feature that I have already mentioned, and which
> I have put on https://github.com/peff/git/wiki/SoC-2012-Ideas is
> client-side sorting of tables, e.g. of list of all projects, a la
> jQuery / MediaWiki (Wikipedia) "sorttable".
>
> Another would be using deferreds or queues for interactive blame, so
> that repainting (editing DOM) happens asynchronously to avoid locking
> up browser, like in
>  http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/
>
> There was also some time ago a patch that added ability to mark a commit
> to compare current commit to (using JavaScript and cookies), to have an
> UI to compare arbitrary commits using 'commitdiff' view.  Or something
> similar to MediaWiki (Wikipedia) page history view.
>
>
> Yet another would be support for graphical representation of history in
> 'log', 'shortlog' and 'history' views e.g. using Raphael.js
>
> Perhaps it would be possible to employ some JavaScript syntax highlighter
> to pretty-print contents of 'blob' view.
>
>
> Hope That Helps.
>
>
> P.S. You can see gitweb at work here:
>
>  http://git.kernel.org/?p=git/git.git
>  http://repo.or.cz/w/git.git
> --
> Jakub Narebski
> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

Dear Jakub,

    if we handle the sorting of the tables on the client side itself
,will that be a  load on the browser?
Other ideas which i have in mind are

1.Highligting matched portions of project name while searching the
project name ,even more intuitively
2.project pagination.

On Sun, Mar 25, 2012 at 12:19 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sat, 24 Mar 2012, chaitanyaa nalla wrote:
>
>> Dear Jakub ,
>>
>>  could you please suggest any other ideas or features so that i can
>> think upon them and come up with further good ideas.
>
> One idea for additional feature that I have already mentioned, and which
> I have put on https://github.com/peff/git/wiki/SoC-2012-Ideas is
> client-side sorting of tables, e.g. of list of all projects, a la
> jQuery / MediaWiki (Wikipedia) "sorttable".
>
> Another would be using deferreds or queues for interactive blame, so
> that repainting (editing DOM) happens asynchronously to avoid locking
> up browser, like in
>  http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/
>
> There was also some time ago a patch that added ability to mark a commit
> to compare current commit to (using JavaScript and cookies), to have an
> UI to compare arbitrary commits using 'commitdiff' view.  Or something
> similar to MediaWiki (Wikipedia) page history view.
>
>
> Yet another would be support for graphical representation of history in
> 'log', 'shortlog' and 'history' views e.g. using Raphael.js
>
> Perhaps it would be possible to employ some JavaScript syntax highlighter
> to pretty-print contents of 'blob' view.
>
>
> Hope That Helps.
>
>
> P.S. You can see gitweb at work here:
>
>  http://git.kernel.org/?p=git/git.git
>  http://repo.or.cz/w/git.git
> --
> Jakub Narebski
> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Sun, 25 Mar 2012, chaitanyaa nalla wrote:

> Dear Jakub,
> 
> if we handle the sorting of the tables on the client side itself,
> will that be a  load on the browser?

Well, if it turns out to be too heavy a load, we can use the same trick
of "timed array processing":

  http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/

See for example this page to see sorttable in action:

  http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities

> Other ideas which I have in mind are
> 
> 1. Highligting matched portions of project name while searching the
>    project name, even more intuitively

You probably couldn't have known that match highlighting in project
search is done on server side by gitweb.cgi since commit 6759f95
(Merge branch 'jn/gitweb-hilite-regions', 2012-03-04):

  gitweb: Highlight matched part of shortened project description
  gitweb: Highlight matched part of project description when searching projects
  gitweb: Highlight matched part of project name when searching projects

It is not used by either git.kernel.org or repo.or.cz because it is
too fresh (it is to be in yet to be released v1.7.10).

> 2. project pagination.

Is there any sense in pagination on client side?  Unless you turn it into
lazy loading / loading on demand Ajax-y pagination...


Yet another idea is to implement creating side-by-side diff from unified
diff in JavaScript, so that swicthing between unified and side-by-side
diff view could be done entirely client-side, without hitting the server.


Note however that I think that it wouldn't be possible in time given to
implement all those ideas.  You need to select those of them that you
will put in project application.

-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

Dear Jakub,

thanks again.
 creating side-by-side diff from unified  diff in JavaScript, so that
swicthing between unified and side-by-side
 diff view  could be done entirely client-side, without hitting the server
could you please elaborate on this , i didn't understand this completley.

On Sun, Mar 25, 2012 at 11:25 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Sun, 25 Mar 2012, chaitanyaa nalla wrote:
>
>> Dear Jakub,
>>
>> if we handle the sorting of the tables on the client side itself,
>> will that be a  load on the browser?
>
> Well, if it turns out to be too heavy a load, we can use the same trick
> of "timed array processing":
>
>  http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/
>
> See for example this page to see sorttable in action:
>
>  http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
>
>> Other ideas which I have in mind are
>>
>> 1. Highligting matched portions of project name while searching the
>>    project name, even more intuitively
>
> You probably couldn't have known that match highlighting in project
> search is done on server side by gitweb.cgi since commit 6759f95
> (Merge branch 'jn/gitweb-hilite-regions', 2012-03-04):
>
>  gitweb: Highlight matched part of shortened project description
>  gitweb: Highlight matched part of project description when searching projects
>  gitweb: Highlight matched part of project name when searching projects
>
> It is not used by either git.kernel.org or repo.or.cz because it is
> too fresh (it is to be in yet to be released v1.7.10).
>
>> 2. project pagination.
>
> Is there any sense in pagination on client side?  Unless you turn it into
> lazy loading / loading on demand Ajax-y pagination...
>
>
> Yet another idea is to implement creating side-by-side diff from unified
> diff in JavaScript, so that swicthing between unified and side-by-side
> diff view could be done entirely client-side, without hitting the server.
>
>
> Note however that I think that it wouldn't be possible in time given to
> implement all those ideas.  You need to select those of them that you
> will put in project application.
>
> --
> Jakub Narebski
> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Sun, 25 Mar 2012, chaitanyaa nalla wrote:

> "creating side-by-side diff from unified  diff in JavaScript, so that
>  switching between unified and side-by-side diff view  could be done
>  entirely client-side, without hitting the server"
>
>  could you please elaborate on this, I didn't understand this completly. 

Side-by-side diff is a new gitweb feature, available in v.7.9 (since
commit 6ba1eb5 (gitweb: Add a feature to show side-by-side diff, 2011-10-31))

Both git.kernel.org and repo.or.cz are based on an older version of
gitweb.  You need to install gitweb to test this (and perhaps git-instaweb
for easier HTML preview).

In short: unified diff like this:

  @@ -119,8 +119,8 @@ UI, Workflows & Features
   ctx
  -foo
  +bar

is turned into side-by-side diff:

   ctx                    ctx
  -foo                   +bar

Commit  6ae683c (gitweb: Add navigation to select side-by-side diff,
2011-10-31) allows switching between unified and side-by-side diff;
the goal of this feature would be to make it client-side (hijacking
the link).

-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

On Tue, Mar 27, 2012 at 8:23 PM, chaitanyaa nalla <nallachaitu@gmail.com> wrote:
>>There was also some time ago a patch that added ability to mark a commit
>>to compare current commit to (using JavaScript and cookies), to have an
>> UI to compare arbitrary commits using 'commitdiff' view.  Or something
>> similar to MediaWiki (Wikipedia) page history view.
>
> Hey jakub,
> will that patch be included in future version , if it is the case can
> i consider implementing with some enhancements??
>
>
>
> On Sun, Mar 25, 2012 at 11:25 PM, Jakub Narebski <jnareb@gmail.com> wrote:
>> On Sun, 25 Mar 2012, chaitanyaa nalla wrote:
>>
>>> Dear Jakub,
>>>
>>> if we handle the sorting of the tables on the client side itself,
>>> will that be a  load on the browser?
>>
>> Well, if it turns out to be too heavy a load, we can use the same trick
>> of "timed array processing":
>>
>>  http://www.nczonline.net/blog/2009/08/11/timed-array-processing-in-javascript/
>>
>> See for example this page to see sorttable in action:
>>
>>  http://en.wikipedia.org/wiki/Comparison_of_open_source_software_hosting_facilities
>>
>>> Other ideas which I have in mind are
>>>
>>> 1. Highligting matched portions of project name while searching the
>>>    project name, even more intuitively
>>
>> You probably couldn't have known that match highlighting in project
>> search is done on server side by gitweb.cgi since commit 6759f95
>> (Merge branch 'jn/gitweb-hilite-regions', 2012-03-04):
>>
>>  gitweb: Highlight matched part of shortened project description
>>  gitweb: Highlight matched part of project description when searching projects
>>  gitweb: Highlight matched part of project name when searching projects
>>
>> It is not used by either git.kernel.org or repo.or.cz because it is
>> too fresh (it is to be in yet to be released v1.7.10).
>>
>>> 2. project pagination.
>>
>> Is there any sense in pagination on client side?  Unless you turn it into
>> lazy loading / loading on demand Ajax-y pagination...
>>
>>
>> Yet another idea is to implement creating side-by-side diff from unified
>> diff in JavaScript, so that swicthing between unified and side-by-side
>> diff view could be done entirely client-side, without hitting the server.
>>
>>
>> Note however that I think that it wouldn't be possible in time given to
>> implement all those ideas.  You need to select those of them that you
>> will put in project application.
>>
>> --
>> Jakub Narebski
>> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Tue, 27 Mar 2012, chaitanyaa nalla wrote:
> Jakub Narebski wrote:

> > There was also some time ago a patch that added ability to mark a commit
> > to compare current commit to (using JavaScript and cookies), to have an
> > UI to compare arbitrary commits using 'commitdiff' view.  Or something
> > similar to MediaWiki (Wikipedia) page history view.
> 
> Hey jakub,
>
> Will that patch be included in future version, if it is the case can
> i consider implementing with some enhancements??
 
This idea is in my TODO list for gitweb, but I don't have specific plans
on when it would be implemented (if at all).

P.S. Please leave only relevant part of cited (quoted) response.  Thanks
in advance.
-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

Dear Jakub,

I prepared a schedule for gsoc ,please take a look and suggest me in
case if you feel some tasks couldn't be completed with in indicated
time .

Week 1  understanding how the whole gitweb and related server side
scripts are implemented , their design philosophy , coding standards ,
documentation standards to maintain the best practise coding
practices.  Brainstorming sessions regarding which libraries to use on
specific scenarios by keeping many criteria’s in mind and creating an
abstract design on the additional features  that have to be added.
Week 2  Improving Javascript browser detection and incremental blame.
Week 3 Improving UI of adjusting timezone by deciding which library /
framework to use on UI.
Week 4 & 5 design and implementation of client side sorting of tables
and client side syntax highlighting of the blob view by handling how
git web splits the output into lines and providing line numbers.
Week 6  testing the code robustly on as many browsers as possible
(with their versions) and documenting the code neatly .
MidTerm Delivarables : Improving javascript browser detection,
incremental blame,ui of adjusting timezone .Adding client side sorting
of tables and client side syntax highlighting of blob view .
Week 7 & 8 Using deferrands or queues in the interactive blame to
avoid the editing of DOM which happens asynchronously to avoid
locking and automatic extending of clickable area for places where the
link is constrained to a single cell or of that type.
Week 9 & 10 & 11 design and implementation support for graphical
representation of history in log ,shortlog and history using Raphael
javascript library, adding UI to compare arbitrary commits in the page
using commitdiff view similar to MediaWiki page history view and
creating a side by side diff from unified diff in javascript so that
switching between unified diff and side by side diff could be handled
on client side.
Week 12  documentation , writing a detail report , testing
exhaustively and checking whether the written code follows the
characteristics .
Note: considerable amount of time will be spent each week
concentrating on design for adding a new feature since its design
greatly affects many things.

Thanks in advance.

yours sincerely,
chaitanya nalla.


On Wed, Mar 28, 2012 at 12:44 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 27 Mar 2012, chaitanyaa nalla wrote:
>> Jakub Narebski wrote:
>
>> > There was also some time ago a patch that added ability to mark a commit
>> > to compare current commit to (using JavaScript and cookies), to have an
>> > UI to compare arbitrary commits using 'commitdiff' view.  Or something
>> > similar to MediaWiki (Wikipedia) page history view.
>>
>> Hey jakub,
>>
>> Will that patch be included in future version, if it is the case can
>> i consider implementing with some enhancements??
>
> This idea is in my TODO list for gitweb, but I don't have specific plans
> on when it would be implemented (if at all).
>
> P.S. Please leave only relevant part of cited (quoted) response.  Thanks
> in advance.
> --
> Jakub Narebski
> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Tue, 27 Mar 2012, chaitanyaa nalla wrote:

> Dear Jakub,
> 
> I prepared a schedule for gsoc ,please take a look and suggest me in
> case if you feel some tasks couldn't be completed with in indicated
> time .
> 
> Week 1  understanding how the whole gitweb and related server side
> scripts are implemented , their design philosophy , coding standards ,
> documentation standards to maintain the best practise coding
> practices.

I think you need to at least skim the JavaScript part of gitweb code
to be able to create a decent proposal.

> Brainstorming sessions regarding which libraries to use on 
> specific scenarios by keeping many criteria’s in mind and creating an
> abstract design on the additional features  that have to be added.

I think it would be a good idea to propose JavaScript library / framework
to use for client-side scripting in gitweb (jQuery, MooTools, Dojo, YUI),
explaining shortly why this one and not other (popularity, "weight", your
knowledge, etc.).  Though perhaps not commit to said library.

You say "libraries", but I think gitweb should use single JavaScript
library, perhaps with exception of specialized libraries or plugins for
extra stuff like Raphael.js for drawing.

Also here or later there should be time for short discussion about
marrying use of external JavaScript library to gitweb.perl script and
to our build system (gitweb/Makefile).

> Week 2  Improving Javascript browser detection and incremental blame.

Errr... gitweb does not employ browser detection.  Well, at least not
in strict sense; it does employ some feature detection e.g. to create
XmlHttpRequest -- but that is what library is for, it is assumed to do
cross-browser behavior for us.

Anyway improving existing features, and adding new features should be
much later.  The very first thing is to transform existing code (JavaScript
detection, adjusting timezones and incremental blame) from hand written
JavaScript to using JavaScript library, incrementally if possible, and
removing our own mini-library in `gitweb/static/js/lib/`.

[...]
> Week 3 Improving UI of adjusting timezone by deciding which library /
> framework to use on UI.

I don't think timezone select UI needs much improvement.  

Anyway I think that we would either use library, or UI addons for library
(like jQuery UI if you choose jQuery), or plugins for library.

> Week 4 & 5 design and implementation of client side sorting of tables

That should be fairly easy (though I am not sure if "1 week" easy).
This is what "sorttable" does in jQuery and I guess also other libraries
(built-in or via plugin); what needs to be adjusted is replacing or 
overriding (perhaps via onclick handler) links to server-side sorting
by trigger to client-side sorting.  Keeping table zebra-colored might
be a problem, but I think JavaScript libraries solved that already.

> and client side syntax highlighting of the blob view by handling how
> git web splits the output into lines and providing line numbers.

That can be hard, and here there might be question of choosing separate
library for JavaScript-based source highlighting.  There is also a 
question of integrating it with server-side source highlighting (turning
off JS-based if server side already does syntax highlighting, and using
the same CSS).

> Week 6  testing the code robustly on as many browsers as possible
> (with their versions) and documenting the code neatly .

This is a good idea.

> MidTerm Delivarables : Improving javascript browser detection,
> incremental blame,ui of adjusting timezone .Adding client side sorting
> of tables and client side syntax highlighting of blob view .

I would be happy if at midterms you would have existing JavaScript
features ported to JavaScript library, without adding any new features
or extending existing ones.

> Week 7 & 8 Using deferrands or queues in the interactive blame to
> avoid the editing of DOM which happens asynchronously to avoid
> locking

O.K.  You will have to check chosen JavaScript library documentation
for its name for such things; different libraries uses different names
for asynchronous processing helpers.

This might be hard part, but if you think you can do it in week
or two...

> and automatic extending of clickable area for places where the 
> link is constrained to a single cell or of that type.

Nice.  This also means that on server side we can remove link within
link (which does not work in some overly strict web browsers), but
this server-side change doesn't need to be done by you.

> Week 9 & 10 & 11 design and implementation support for graphical
> representation of history in log ,shortlog and history using Raphael
> javascript library, adding UI to compare arbitrary commits in the page
> using commitdiff view similar to MediaWiki page history view and
> creating a side by side diff from unified diff in javascript so that
> switching between unified diff and side by side diff could be handled
> on client side.

O.K., though graphical representation of history might be harder than
that (than allowed 1 week or 2).

Side-by-side diff is just porting from Perl to JavaScript.

> Week 12  documentation , writing a detail report , testing
> exhaustively and checking whether the written code follows the
> characteristics .
> Note: considerable amount of time will be spent each week
> concentrating on design for adding a new feature since its design
> greatly affects many things.

-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

i forgot to add this feature to employ javascript syntax highlighter
to pretty-print contents of the blob view.Here are my views regarding
which library to use . i want to stick to one or two libraries as i
dont want to  mix things  up which is a bad practise.

for DOM manipulation jquery is better than others.
for graphics representation raphael library or Dojo is better.
if one need robust Object oriented platform , Dojo is better.
Based on popularity , light weighted library jquery is pretty famous
because of its simplicity and power ,it got added advantage that
microsoft Asp.net and nokia are supporting it.
YUI is modular .
mootools lets have us our own way .. http://jqueryvsmootools.com/
please take a look at this Link.
http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks.

Based on the goal of the project , i would prefer jquery as it is well
tested ,robust , simple to use , widely popular,good support for DOM
manipulating , fast(performance) in most cases , even though for
graphics i would go for raphael as it have clean and neat api similar
to jquery , it has good graphics support.

please enlighten me if i'm going on the wrong track.  I am sure you will :)

On Wed, Mar 28, 2012 at 4:08 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Tue, 27 Mar 2012, chaitanyaa nalla wrote:
>
>> Dear Jakub,
>>
>> I prepared a schedule for gsoc ,please take a look and suggest me in
>> case if you feel some tasks couldn't be completed with in indicated
>> time .
>>
>> Week 1  understanding how the whole gitweb and related server side
>> scripts are implemented , their design philosophy , coding standards ,
>> documentation standards to maintain the best practise coding
>> practices.
>
> I think you need to at least skim the JavaScript part of gitweb code
> to be able to create a decent proposal.
>
>> Brainstorming sessions regarding which libraries to use on
>> specific scenarios by keeping many criteria’s in mind and creating an
>> abstract design on the additional features  that have to be added.
>
> I think it would be a good idea to propose JavaScript library / framework
> to use for client-side scripting in gitweb (jQuery, MooTools, Dojo, YUI),
> explaining shortly why this one and not other (popularity, "weight", your
> knowledge, etc.).  Though perhaps not commit to said library.
>
> You say "libraries", but I think gitweb should use single JavaScript
> library, perhaps with exception of specialized libraries or plugins for
> extra stuff like Raphael.js for drawing.
>
> Also here or later there should be time for short discussion about
> marrying use of external JavaScript library to gitweb.perl script and
> to our build system (gitweb/Makefile).
>
>> Week 2  Improving Javascript browser detection and incremental blame.
>
> Errr... gitweb does not employ browser detection.  Well, at least not
> in strict sense; it does employ some feature detection e.g. to create
> XmlHttpRequest -- but that is what library is for, it is assumed to do
> cross-browser behavior for us.
>
> Anyway improving existing features, and adding new features should be
> much later.  The very first thing is to transform existing code (JavaScript
> detection, adjusting timezones and incremental blame) from hand written
> JavaScript to using JavaScript library, incrementally if possible, and
> removing our own mini-library in `gitweb/static/js/lib/`.
>
> [...]
>> Week 3 Improving UI of adjusting timezone by deciding which library /
>> framework to use on UI.
>
> I don't think timezone select UI needs much improvement.
>
> Anyway I think that we would either use library, or UI addons for library
> (like jQuery UI if you choose jQuery), or plugins for library.
>
>> Week 4 & 5 design and implementation of client side sorting of tables
>
> That should be fairly easy (though I am not sure if "1 week" easy).
> This is what "sorttable" does in jQuery and I guess also other libraries
> (built-in or via plugin); what needs to be adjusted is replacing or
> overriding (perhaps via onclick handler) links to server-side sorting
> by trigger to client-side sorting.  Keeping table zebra-colored might
> be a problem, but I think JavaScript libraries solved that already.
>
>> and client side syntax highlighting of the blob view by handling how
>> git web splits the output into lines and providing line numbers.
>
> That can be hard, and here there might be question of choosing separate
> library for JavaScript-based source highlighting.  There is also a
> question of integrating it with server-side source highlighting (turning
> off JS-based if server side already does syntax highlighting, and using
> the same CSS).
>
>> Week 6  testing the code robustly on as many browsers as possible
>> (with their versions) and documenting the code neatly .
>
> This is a good idea.
>
>> MidTerm Delivarables : Improving javascript browser detection,
>> incremental blame,ui of adjusting timezone .Adding client side sorting
>> of tables and client side syntax highlighting of blob view .
>
> I would be happy if at midterms you would have existing JavaScript
> features ported to JavaScript library, without adding any new features
> or extending existing ones.
>
>> Week 7 & 8 Using deferrands or queues in the interactive blame to
>> avoid the editing of DOM which happens asynchronously to avoid
>> locking
>
> O.K.  You will have to check chosen JavaScript library documentation
> for its name for such things; different libraries uses different names
> for asynchronous processing helpers.
>
> This might be hard part, but if you think you can do it in week
> or two...
>
>> and automatic extending of clickable area for places where the
>> link is constrained to a single cell or of that type.
>
> Nice.  This also means that on server side we can remove link within
> link (which does not work in some overly strict web browsers), but
> this server-side change doesn't need to be done by you.
>
>> Week 9 & 10 & 11 design and implementation support for graphical
>> representation of history in log ,shortlog and history using Raphael
>> javascript library, adding UI to compare arbitrary commits in the page
>> using commitdiff view similar to MediaWiki page history view and
>> creating a side by side diff from unified diff in javascript so that
>> switching between unified diff and side by side diff could be handled
>> on client side.
>
> O.K., though graphical representation of history might be harder than
> that (than allowed 1 week or 2).
>
> Side-by-side diff is just porting from Perl to JavaScript.
>
>> Week 12  documentation , writing a detail report , testing
>> exhaustively and checking whether the written code follows the
>> characteristics .
>> Note: considerable amount of time will be spent each week
>> concentrating on design for adding a new feature since its design
>> greatly affects many things.
>
> --
> Jakub Narebski
> Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

Please remove those parts of quoted (cited) message that are irrelevant
to your response.  Try to not top-post, either.

On Wed, 28 Mar 2012, chaitanyaa nalla wrote:

> I forgot to add this feature to employ JavaScript syntax highlighter
> to pretty-print contents of the blob view.

O.K.  Anyway, I think adding this feature is optional, as time permits;
especially that it is, I think, not easy.

> Here are my views regarding which JavaScript library to use.
> I want to stick to one or two libraries, as I don't want to
> mix things up which is a bad practise.

This is a good idea.

> For DOM manipulation jQuery is better than others.
> For graphics representation Raphael library or Dojo is better.
> If one need robust Object Oriented platform, Dojo is better.
> Based on popularity, light weight jQuery library is pretty famous
> because of its simplicity and power, it got added advantage that
> Microsoft's ASP.Net and Nokia are supporting it.
> YUI is modular.
> MooTools lets have us our own way .. http://jqueryvsmootools.com/
> Please take a look at this link:
>
>    http://en.wikipedia.org/wiki/Comparison_of_JavaScript_frameworks.

What is lacking in above description and comparison of various 
JavaScript frameworks is note about *your familiarity* with said 
libraries.

> Based on the goal of the project, I would prefer jQuery as it is well
> tested, robust, simple to use, widely popular, has good support for
> DOM manipulating, is fast (performance) in most cases.

Additional advantage is that there are many CDN (Content Delivery
Network) for jQuery that one can use.

I also think that for gitweb, where goal is to enhance its views
(rather than creating JavaScript app like e.g. GMail or Google Docs),
lightweight and popular jQuery library might be a best choice.

> Though for graphics I would go for Raphael.js, as it has clean
> and neat API similar to jQuery, and it has good graphics support.

Well, if there is time for adding client-side graphical history view
to gitweb, Raphael.js seems like a good choice.  But I am afraid that
this feature it as large as separate GSoC project.


P.S. Another source of inspiration for JavaScript usage in gitweb might
be git-browser project.  Just FYI.

-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanyaa nalla]

 adding UI to compare arbitrary commits in the page
 using commitdiff view similar to MediaWiki page history view.

could you please tell me a rough estimate of how much time can it be
completed? I am expecting to complete it with in 1 week.

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Thu, 29 Mar 2012, chaitanyaa nalla wrote:
> Jakub Narebski wrote:

> > Another source of inspiration for JavaScript usage in gitweb might
> > be git-browser project.  Just FYI.
> 
> Dear Jakub,
> 
> please tell me more about this idea , it is interesting :)


git-browser is an experimental gitk-like web interface which was developed
in December 2005 by Artem Khodush <greenkaa@gmail.com> and then largely
forgotten and abandoned.  User interface is done in JavaScript, and is
rather heavy on the client side.  Server-side scripting is done in Perl
(and uses gitweb IIRC).

  https://git.wiki.kernel.org/articles/i/n/t/Interfaces,_frontends,_and_tools.html#git-browser
  http://repo.or.cz/gitweb.cgi/git-browser.git

I don't think there is existing demo deployment remaining...

-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[Jakub Narebski]

On Thu, 29 Mar 2012, chaitanyaa nalla wrote:
> Jakub Narebski wrote:

>>  adding UI to compare arbitrary commits in the page
>>  using commitdiff view similar to MediaWiki page history view.
> 
> could you please tell me a rough estimate of how much time can it be
> completed? I am expecting to complete it with in 1 week.

Well, the goal is to add an UI to the existing gitweb ability of
showing (commit)diff between two arbitrary commits.


One solution would be to make use (perhaps only as inspiration) of
Martin Koegler <mkoegler@auto.tuwien.ac.at> patch from 2007:

  [PATCH 5/7] gitweb: Prototyp for selecting diffs in JavaScript
  http://thread.gmane.org/gmane.comp.version-control.git/44517/focus=44523


Another would be create in 'log' or 'shortlog' view ability to
diff between arbitrary commits, similar to MediaWiki (and other wikis)
page history view, e.g.:

  http://en.wikipedia.org/w/index.php?title=JQuery&action=history

Or you can take GitHub as source of inspiration.

Anyway any solution extending or creating a new log-like view will
require server-side changes, therefore I think 1 week might be a bit
too optimistic.

-- 
Jakub Narebski
Poland

Re: GSoC idea: adding JavaScript library / framework in gitweb

[chaitanya nalla]

Dear jakub,

I have changed schedule based on the good suggetions given by you.
please look at it.

Before May 21st  interacting with the beloved community members and
get familiarize  with the code base.
Week 1  Gaining a proper understanding regarding how various are
implemented , their design philosophy , coding standards ,
documentation standards to maintain the best  coding practices
.Detailed discussions on which  JavaScript library / framework to use
for client-side scripting in gitweb (jQuery, MooTools, Dojo, YUI)
based on several criteria.(as you mentioned , a short paragraph
describing which framework to use is also added)
Week 2   Transform existing code of JavaScript detection, adjusting
timezones and from hand written JavaScript to using JavaScript
library,improving their features wherever possible, incrementally  and
removing the  mini-library in `gitweb/static/js/lib/` by  proper
design and analysis.

Week 3 transform the existing code of incremental blame and improving
its features wherever possible by proper design and analysis
Week 4 & 5 design and implementation of client side sorting of tables
and client side syntax highlighting of the blob view by handling how
git web splits the output into lines and providing line numbers.
There is also a question of integrating it with server-side source
highlighting (turning off JS-based if server side already does syntax
highlighting, and using
the same CSS).
Week 6  testing the code robustly on as many browsers as possible
(with their versions) and documenting the code neatly .If possible
automated testing will also be done using selenium web driver.
MidTerm Delivarables : Transform existing code of JavaScript
detection, adjusting timezones and from hand written JavaScript to
using JavaScript library,improving their features wherever possible,
incrementally  and removing the  mini-library in
`gitweb/static/js/lib/` by  proper design and analysis. Adding client
side sorting of tables and client side syntax highlighting of blob
view .
Week 7 & 8 Using deferrands or queues in the interactive blame to
avoid the editing of DOM which happens asynchronously to avoid
locking and automatic extending of clickable area for places where the
link is constrained to a single cell or of that type.
Week 9 & 10 & 11 adding user interface  to compare arbitrary commits
in the page using commitdiff view similar to MediaWiki page history
view . Creating a side by side diff from unified diff in javascript so
that switching between unified diff and side by side diff could be
handled on client side.
Week 12  documentation , writing a detail report , testing
exhaustively and checking whether the written code follows the best
coding practises and good design.
Note: considerable amount of time will be spent each week
concentrating on design for adding a new feature since its design
greatly affects many things.